AWS认证解决方案架构助理 - AWS EC2笔记

Cloud Computing Service
Choose your OS, Storage, Memory, Network Throughput.
Launch and SSH into your server within minutes.

Elastic Compute Cloud (EC2) is a highly configurable server.
EC2 is resizable compute capacity. It takes minutes to launch new instances.
Anything and everything on AWS uses EC2 Instance underneath.

Choose your OS via Amazon Machine Image(AMI):

  • RedHat
  • Ubuntu
  • Windows
  • Amazon Linux
  • SUSE

Choose your Instance Type

  • t2.nano
  • C4.8xlarge

Add Storage (EBS, EFS):

  • SSD
  • HDD
  • Virtual Magnetic Tape
  • Multiple Volumes

Configure your Instance

  • Security Groups
  • Key Pairs
  • UserData
  • IAM Roles
  • Placement Groups

Instance Types and Usage

General Purpose

balance of compute, memory and networking resources
Use-cases web servers and code repositories.

  • A1
  • T3
  • T3a
  • T2
  • M5
  • M5a
  • M4
Compute Optimized

ideal for compute bound applications that benefit from high performance processor
Use-cases scientific modeling, dedicated gaming servers and ad server engines

  • C5
  • C5n
  • C4
Memory Optimized

fast performance for workloads that process large data sets in memory
Use-cases in-memory caches, in-memory databases, real time big data analytics

  • R5
  • R5a
  • X1e
  • X1
  • High Memory
  • Z1d
Accelerated Optimized

hardware accelerators, or co-processors
Use-cases Machine learning, computational finance, seismic analysis, speech recognition

  • P3
  • P2
  • G3
  • F1
Storage Optimized

high, sequential read and write access to very large data sets on local storage
Use-cases NoSQL, in-memory transaction databases, data warehosing

  • I3
  • I3en
  • D2
  • H1

Instance Sizes

EC2 Instance Size generally double in price and key attributes

Name vCPU RAM(GIB) On-Demand per hour On-Demand per month
t2.small 1 12 $0.023 $16.79
t2.medium 2 24 $0.0464 $33.87
t2.large 2 36 $0.0928 $67.74
t2.xlarge 4 54 $0.1856 $135.48

Instance Profile

Instead of embedding your AWS credentials (Access Key and Secret) in your code so your Instance has permission to access certain services you can Attach a role to an instance via an Instance Profile.

You want to always avoid embedding your AWS credentials when possible.

IAM Policy -> IAM Role -> Instance Profile <- EC2 Instance

An Instance Profile holds a reference to a role. The EC2 instance is associated with the Instance Profile. When you select an IAM role when launching an EC2 instance, AWS will automatically create the Instance Profile for you. Instance Profile are not easily viewed via the AWS Console.

Placement Groups

Placement Group let you to choose the logical placement of your instances to optimize your communication, performance or durability. Placement groups are free.

Cluster

  • packs instances choose together inside an AZ
  • low-latency network performance for tightly-coupled node-to-node communication
  • well suited for High Performance Computing (HPC) applications
  • Clusters cannot be multi-AZ

Partition

  • spread instances across logical partitions
  • each partition do not share the underlying hardware each other (rack per partition)
  • well suit for large distributed and replicated workloads (Hadoop, Cassandra, Kafka)

Spread

  • each instance is placed on a different rack
  • when critical instances should be keep separate from each other
  • you can spread a max of 7 instances. spreads can be multi-AZ

UserData

You can provide an EC2 with UserData which is a script that will be automatically run when launching an EC2 instance. You could install package, apply updates or anything you like.

From within the EC2 instance, if you want to SSH in and CURL this special URL you can see the UserData script e.g.

curl http://169.254.169.254/latest/user-data/

MetaData

From within your EC2 instance you can access information about the EC2 via a special url endpoint at
169.254.169.254
You would SSH into your EC2 instance and can see use the CURL command:

curl http://169.254.169.254/latest/meta-data/
[ec2-user@ip ~]$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hibernation/
hostname
iam/
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-keys/
reservation-id
security-groups
services/
  • /public-ipv4
    get the current public IPV4 address
  • /ami-id
    the AMI ID used to launch this EC2 instance
  • /instance-type
    the Instance Type of this EC2 instance

Combine metadata with userdata scripts to perform all sorts of advanced AWS staging automation.

Priding Model

On-Demand (Least Commitment)

When you launch an EC2 instance it is by default using On-Demand Pricing.
On-Demand has no up-front payment and no long-term commitment.

You are charged by the hour or by the minute (varies based on EC2 Instance Types)

On-Demand is for applications where the workload is for short-term, spikey or unpredictable
When you have a new app for development or you want to run experiment.

  • low cost and flexible
  • only pay per hour
  • short-term, spiky, unpredictable workloads
  • cannot be interrupted
  • for first time apps
Spot Instances, upto 90% (Biggest Savings)

AWS has unused compute capacity that they want to maximize the utility of their idle servers.
It’s like when a hotel offers discounts for to fill vacant suites or planes offer discount to fill vacant seats.

Spot Instances provide a discount of 90% compared to On-Demand Pricing
Spot Instance can be terminated if the computing capacity is needed by on-demand customers.

Designed for applications that have flexible start and end times or applications that are only feasible at very low compute costs.

AWS Batch is an easy and convenient way to use Spot Pricing
Termination Conditions
Instances can be terminated by AWS at anytime
If your instance is terminated by AWS, you don’t get charged for a partial hour of usage.
If you terminate an instance you still be charge for any hour that it ran.

  • request spare computing capacity
  • flexible start and end times
  • can handle interruptions (server randomly stopping and starting)
  • for non-critical background jobs
Reserved Instances (RI), upto 75% off (Best Long-term)

Designed for applications that have a steady-state, predictable usage, or require reserve capacity.
Reduced Pricing is based on Term x Class Offering x Payment Option

Standard Up to 75% reduced pricing compared to on-demand. Cannot
Convertible Up to 54% reduced pricing compared to on-demand. Allows you to change RI Attributes if greater or equal in value.
Scheduled You reserve instances for specific time period e.g. once a week for a few hours. Saving vary
Terms You commit to a 1 Year or 3 Year contract. The longer the term the greater savings.
Payment Options All Upfront, Partial Upfront, and No Upfront. The greater upfront the great the savings.

RIs can be shared between multiple accounts within an org
Unused RIs can sold in the Reserve Instance Marketplace.

  • steady state or predictable usage
  • commit to EC2 over 1 or 3 year term
  • can resell unused reserved instances
Dedicated (Most Expensive)

Designed to meet regulatory requirement. When you have strict server-bound licensing that won’t support multi-tenancy or cloud deployments.

Multi-Tenant
When multiple customer are running workloads on the same hardware. Virtual Isolation is what separate customers.
Single Tenant
When a single customer has dedicated hardware. Physical Isolation is what separate customer

Offered in both On-demand and Reserved (70% off on-demand pricing)

Enterprises and Large Organizations may have security concerns or obligations about against sharing the same hardware with other AWS Customers.

  • Dedicated servers
  • can be on-demand or reserved (upto 70% off)
  • when you need a guarantee of isolate hardware (enterprise requirements)

Amazon Machine Image (AMI)

A template to configure new Instances.

Amazon Machine Image (AMI) provides the information required to launch an instance.
You can turn your EC2 instances into AMIs so you can create copies of your servers

An AMI holds the following information:

  • A template for the root volume for the instance (EBS Snapshot or Instance Store template). e.g. an operating system, an application server, and applications.
  • Launch permissions that control which AWS accounts can use the AMI to launch instances.
  • A block device mapping that specifies the volumes to attach to the instance when it’s launched.
Use Cases

AMIs help you keep incremental changes to your OS, application code and system packages.

  • web-server-000
    Ruby, Node, Postgres Client Installed
  • web-server-001
    Redis for Sidekiq Installed
  • web-server-002
    ImageMagick for Image Processing Installed
  • web-server-003
    CloudWatch Agent Installed

Using System Manager Automation you can routinely patch your AMIs with security updates and bake those AMIs.

AMIs are used LaunchConfigurations. When you want to roll out updates to multiple instances you make a copy of your LaunchConfiguration with new AMI

Creating an AMI

You can create an AMI from an existing EC2 instance that’s either running or stopped.

Choosing an AMI

AWS has hundreds of AMIs you can search and select from.

Community AMI are free AMIs maintained by the community
AWS Marketplace free or paid AMIs maintained by vendors.

AMIs have an AMI ID. AMIs are region specific will have different AMI ID per region.

AMIs can be selected based on:

  • Region
  • Operating System
  • Architecture (32-bit or 64-bit)
  • Launch Permissions
  • Root Device Volume
    • Instance Store (Ephemeral Storage)
    • EBS Backed Volumes

AMIs are categorized as either backed by Amazon EBS or backed by Instance Store.

Copying an AMI

AMIs are region specific. If you want to use an AMI from another region. You need to Copy the AMI and then select the destination region.

Auto Scaling Groups

Set scaling rules which will automatically launch additional EC2 instance or shutdown instances to meet current demand.

Auto Scaling Groups (ASG) contains a collection of EC2 instances that are treated as a group for the purpose of automatic scaling and management.

Automatic scaling can occur via:

  1. Capacity Settings
  2. Health Check Replacements
  3. Scaling Policies
Capacity Settings

The size of an Auto Scaling Group is based on Min, Max and Desired Capacity

Min is how many EC2 instances should at least be running
Max is number EC2 instances allowed to be running.

Desired Capacity is how many EC2 instances you want yo ideally run.

ASG will always launch instances to meet minimum capacity.

Health Check Replacements
  • EC2 Health Check Type
    ASG will perform a health check on EC2 instances to determine if there is a software or hardware issue. This is based on the EC2 Status Checks. If an instance is considered unhealthy. ASG will terminate and launch a new instance.

  • ELB Health Check Type
    ASG will perform a health check based on the ELB health check. ELB can perform health checks by pinging an HTTP(S) endpoint with an expected response. If ELB determines a instance is unhealthy it forwards this information to ASG which will terminate the unhealthy instance.

  • Scaling Policies
    Scaling Out: Adding More Instances
    Scaling In: Removing Instances

    1. Target Tracking Scaling Policy
      Maintains a specific metric at a target value

      e.g. If Average CPU Utilization exceeds 75% then add another server.

    2. Simple Scaling Policy
      Scales when an alarm is breached. (Not recommend, legacy policy)

    3, Scaling policies with steps
    Scales when an alarm is breached, can escalates based on alarm value changing

ELB Integration

ASG can be associated with Elastic Load Balancers (ELB). When ASG is associated with ELB richer health checks can be set.

  • ASG -> CLB
    Classic Load Balancers (CLB) are associated directly to the ASG

  • ASG -> Target Group -> ALB, NLB
    Application Load Balancers (ALB) and Network Load Balancers (NLB) are associated indirectly via Target Groups

Use Case
  1. Burst of traffic from the internet hits our domain
  2. Route53 points that traffic to our load balancer
  3. Our load balancer passes the traffic to this target group
  4. The target group is associated with our ASG and sends the traffic to instances registered with our ASG
  5. The ASG Scaling Policy will check if our instance are near capacity
  6. The Scaling Policy determine we need another instance, and it Launches an new EC2 instance with associated Launch Configuration to our ASG
Launch Configuration

A launch configuration is an instance configuration template that Auto Scaling group uses to launch EC2 instances.

A Launch Configuration is the same process as Launching an EC2 instance except you are saving that configuration to Launch an Instance for later. Hence Launch Configuration.

Launch Configurations cannot be edited. When you need to update your Launch Configuration you create a new one or clone the existing configuration and then manually associate that new Launch Configuration.
Launch Templates are Launch Configuration with Versioning. Everyone appears to still use Launch Configurations.

Elastic Load Balancer (ELB)

Distributes incoming application traffic across multiple target, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions.

Load Balancers can be physical hardware or virtual software that accepts incoming traffic, and then distributes the traffic to multiple targets. They can balance the load via different rules. These rules vary based on types of load balacers.

Elastic Load Balancer (ELB) is the AWS solution for load balancing traffic, and there are 3 types available:

  1. Application Load Balancer, ALB (HTTP/HTTPS)
  2. Network Load Balancer, NLB (TCP/UDP)
  3. Classic Load Balancer, CLB (Legacy)
The Rules of Traffic
  • Listeners
    Incoming traffic is evaluated against listeners. Listeners evaluate any traffic that is matches the Listener’s port. For Classic Load Balancer, EC2 instances are directly registered to the Load Balancer.

  • Rules (Not available for Classic Load Balancer)
    Listeners will then invoke rules to decide what to do with the traffic. Generally the next step is to forward traffic to a Target Group

  • Target Group (Not available for Classic Load Balancer)
    EC2 instances are registered as targets to a Target Group.

For Application Load Balancer (ALB) or Network Load Balancer (NLB) traffic is sent to the Listeners.
When the port matches it then checks the rules what to do. The rules will forward the traffic to a Target Group. The target group will evenly distribute the traffic to instances registered to that target group.

For Classic Load Balancer (CLB) traffic is sent to the Listeners. When the port matches it then it forwards the traffic to any EC2 instances that are registered to the Classic Load Balancer. CLB does not allow you to apply rules to listeners.

Application Load Balancer (ALB)

Application Load Balancer are designed to balance HTTP and HTTPS traffic.

They operate at Layer 7 (of the OSI Model)

ALB has a feature called Request Routing which allows you to add routing rules to your listeners based on the HTTP protocol.

Web Application Firewall (WAF) can be attached to ALB.

Greate for Web Applications

OSI Layers
Layer 7 Application
Layer 6 Presentation
Layer 5 Session
Layer 4 Transport
Layer 3 Network
Layer 2 Data Link
Layer 1 Physical
Network Load Balancer (NLB)

Network Load Balancer are designed to balance TCP/UDP

They operate at Layer 4 (of the OSI Model)

Can handle millions of requests per second while still maintaining extremely low latency.

Can perform Cross-Zone Load Balancing

Great for Multiplayer Video Games or When network performance is critical.

Classic Load Balancer (CLB)

It was AWS first load balancer (legacy)

Can balance HTTP, HTTPS or TCP traffic (not at the same time)

It can use Layer 7-specific features (OSI Model) such as sticky sessions

It can also use strict Layer 4 (OSI Model) balancing for purely TCP applications.

Can perform Cross-Zone Load Balancing

It will response with a 504 error (timeout) if the underlying application is not responding. (at the web-server or database level)

Not recommended for use, instead use NLB or ALB

Elastic Load Balancer, Sticky Sessions

Sticky Sessions is an advanced load balancing method that allows you to bind a user’s session to a specific EC2 instance.

Ensures all requests from that session are sent to the same instance.

Typically utilized with a Classic Load Balancer

Can be enabled for ALB though can only be set on a Target Group not individual EC2 instances

Cookies are used to remember which EC2 instance.

Useful when specific information is only stored locally on a single instance

Elastic Load Balancer, X-Forwarded-For (XFF) Header

If you need the IPv4 address of a user, check the X-Forwarded-For header

The X-Forwarded-For (XFF) header is a command method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer.

ELB, Health Checks

Instances that are monitored by the Elastic Load Balancer (ELB) report back Health Checks as InService, or OutofService

Health Checks communicate directly with the instance to determine its state

ELB does not terminate (kill) unhealthy instance. It will just redirect traffic to healthy instances.

ELB, Cross-Zone Load Balancing

Only for Classic and Network Load Balancer

  • Cross-Zone Load Balancing Enabled
    requests are distributed evenly across the instances in all enabled AZs

  • Cross-Zone Load Balancing Disabled
    requests are distributed evenly across the instances in only its AZ.

ALB, Request Routing

Apply rules to incoming request and then forward or redirect traffic.

  • Host header
  • Source IP
  • Path
  • Http header
  • Http header method
  • Query string

你可能感兴趣的:(AWS)