Cheat Sheet (short v1) Flashcards
300 Instance Types across 5 Instance Families
AWS offers over 300 EC2 instance types across 5 instance families (general purpose family, memory-optimized, storage-optimized, compute-optimized, and accelerated computing), each with varying resource and performance focuses
For example, within the compute-optimized family, you have C4 instance types (running on Haswell chips) and more recent C5 instance types (running on Skylake with Nitro system).
Instance Purchasing Options
- On-Demand Instances - the default option, for short-term ad-hoc requirements where the job can’t be interrupted
- On-Demand Capacity Reservations - the only way to reserve capacity for blocks of time such as 9am-5pm daily
- Spot instance - highest discount potential (50-90%) but no commitment from AWS, could be terminated with 2min notice. Could use for grid and high-performance computing.
- Reserved Instances - for long-term workloads, 1 or 3 year commitment in exchange for 40-60% discount
- Dedicated Instances - run on hardware dedicated to 1 customer (more $$)
- Dedicated Host - fully dedicated and physically isolated server. Allows you to use your server-bound software licenses (e.g. IBM, Oracle) and addresses compliance and regulatory requirements and potentially reduce cost (note: billing is per-hour not per-instance)
- Bare metal EC2 instance - for when the workload needs access to the hardware feature set (e.g. Intel hardware)
Launching Instances
- Configurations / Launch Templates used to create new EC2 instances using stored parameters such as instance family, instance type, AMI, key pair and security groups. Auto-scaling groups can launch instances using config templates. You can’t edit a launch config, but you can create a new one and point to it.
- User data - pass up to 16KB of user data at launch that the instance can run on startup such as config scripts
- Instance metadata (e.g. instance ID, hostname, events, security groups, public keys, network interfaces,) can be accessed via a direct URI or by using the Instance Metadata Query Tool
- When you launch an EC2 instance into a default VPC, it has a public and private DNS hostname and IP address. When you launch in a non-default VPC, it may not have a public hostname depending on the DNS and VPC configs.
- Errors when launching include InsufficientInstanceCapacity, InstanceLimitExceeded
- Instances terminate with no error if there are EBS problems (EBS volume limit, EBS snapshot is corrupt), or if the AMI you’re launching from is missing a required part
- Each EC2 instance that you launch has an associated root device volume, either EBS volume or an Instance Store volume (more these under Storage section below). You can use block device mapping to specify additional EBS volumes or instance store volumes to attach to a live instance, attach additional EBS volumes to a running instance, but can’t directly add additional Instance Store volumes.
- Run Command - run from the AWS Management Console, CLI or SDK, to install software, execute Powershell commands and scripts, configuring Windows settings, on live EC2 instances
Placement Groups
- Cluster placement group = packs instances close together inside an AZ to achieve low latency, high throughput - use for HPC
- Partition placement group = separate instances into logical partitions such that instances in one partition do not share hardware with instances in another partition. Gives you control and visibility into instance placement, but not great for performance. Used by large distributed workloads such as Hadoop.
- Spread placement group = place 1 or few instances each in distinct hardware to reduce correlated failures. Not great for performance
*
Scaling Instances Auto-Scaling Group (ASG)
In high-availability contexts you use an Auto-Scaling Group (ASG) to automatically launch and stop instances, and an Elastic Load Balancer (ELB) to distribute traffic among the instances
* specify which subnets the ASG should launch instances into
* attach Target Groups to the ASG
ASG scaling policies
- Simple - maintain the # of instances, manually change the min/desired/max and attach/detach instances
- Scheduled - scale based on a scheduled event or recurring schedule (e.g. if you know that you have traffic spike every morning at 9am)
- Dynamic - scale in response to an event or alarm
- Step - configure multiple changes to scaling based on multiple events
- Target Tracking - uses a custom metric to add/remove instances
- NOTE: AWS recommends using target tracking over step scaling, and step scaling over simple scaling in most cases
ASG Cooldown period
reducing the cooldown period will more quickly terminate unneeded instances, reducing costs
ASG Enhanced networking
provides higher bandwidth, higher packet-per-second (PPS) erformance, and lower inter-instance latency. Consider if PPS is maxed out.
VPC
- A VPC is a virtual network that closely resembles a traditional network that you’d operate in your own data centre.
- After you create a VPC, you can add subnets. A subnet is a range of IP addresses in your VPC. After you add subnets, you can deploy AWS resources in your VPC.
- Use route tables to determine where network traffic from your subnet or gateway is directed.
- A gateway connects your VPC to another network. For example, use an internet gateway to connect your VPC to the internet.
- Use a VPC endpoint to connect to AWS services privately, without the use of an internet gateway or NAT device.
- Use a VPC peering connection to route traffic between the resources in two VPCs.
- Use a Transit Gateway, which acts as a central hub, to route traffic between your VPCs, VPN connections, and AWS Direct Connect connections.
- Connect your VPCs to your on-premises networks using AWS Virtual Private Network (AWS VPN).
Subnets
- A VPC is housed within a Region, and a subnet maps 1-to-1 with an AZ. Therefore, for high availability, you need at least 2 subnets in your VPC so that you can span 2 AZs.
- When you create a new subnet, it is automatically associated to the main route table.
- Example VPC/subnet configurations recommended by AWS
- VPC with single public subnet: e.g. for single-tier, public-facing web app such as a blog or a simple website
- VPC with public and private subnets: e.g. for multi-tier web apps where the web servers are in the public subnet and the DBs in the private subnet
Public Subnet vs. Private Subnet
Public Subnets
* has a route table that routes to an Internet Gateway (note the Internet Gateway is attached to the VPC, not directly to the subnet)
* When EC2 instances launched in a Public Subnet, they are auto-assigned a public IP address or ENI
* Security groups and network ACLs on Public Subnet must allow SSH traffic (on port 22) for admin config.
Private Subnets
* outbound traffic is routed to a NAT device. The NAT device is installed in the Public Subnet and connected to an Internet Gateway for outbound access to the internet.
* NAT Gateway vs. NAT Instance = NAT Gateway is managed for you by AWS and highly available, whereas NAT Instance is a lot more manual work but can be used as a bastion host / jump box
* EC2 instances don’t have public IP or ENI
* You have to use a bastion host (“jump box”) to access instances in the Private Subnet over SSH (port 22)
VPC Endpoints Interface endpoints
- privately connect your VPC to AWS services, services hosted by other AWS accounts, and supported AWS Marketplace services as if they were in your VPC
- powered by AWS Privatelink
- applies to many AWS services (API Gateway, CloudFormation, CloudWatch, S3)
- does not go over the internet
- no need to use an internet gateway, NAT device, DX connection, or VPN
- Is an ENI with a private IP address, in the subnet that you specify, directing traffic to the service that you specify. Uses DNS to direct traffic to the service. Protected by a Security Group.
VPC Endpoints Gateway endpoints
- direct traffic to S3 or DynamoDB only, using private IP addresses.
- Does not enable AWS Privatelink
- You route traffic from your VPC to the gateway endpoint using route tables. Protected by VPC endpoint policies rather than Security Groups.
3 Types of Network Adapters
- ENI - basic type
- ENA - for enhanced networking, high bandwidth and low latency
- EFA (fabric adapter) - for high performance computing
*
Security Groups vs. Network ACL (NACL)
- Security Group is at the instance level, Network ACL is at the subnet level and applies to all instances within that subnet
- Security Groups don’t have deny rules, Network ACL have accept and deny
- Security Groups are stateful, Network ACL stateless
- Security Groups evaluate all rules together, Network ACL processes rules in order
- Neither can block traffic by country
- Security Groups have inbound allow rules allowing traffic from within the group, whereas custom security groups don’t allow any inbound traffic by default. All outbound traffic is allowed by default.
- Security Group default state: outbound rule allows all traffic to all IPs, but inbound has no rules and traffic therefore denied by default
- NACLs function at the subnet level with separate allow/deny rules for inbound and allow/deny rules for outbound. They are stateless so it’s all about what the rules say each time. Don’t apply -within- the subnet, only in/iout of the subnet.
- Default security groups have inbound allow rules (from within the group). Custom security groups do not allow any inbound traffic. All outbound traffic is allowed.
- VPC automatically comes with a default NACL which allows all inbound/outbound traffic. A custom NACL denies all inbound/outbound traffic by default.
Amazon Route 53
- Geolocation routing is by location of the user, geoproximity routing is by proximity of the resources
- weighted routing = split traffic by %
- Health check = check the health of your resources and only return healthy resources in response to DNS queries
- apply a routing policy such as latency, weighted, failover
Amazon Route 53 Configurations
- active/passive: in case of failure, return backup resource. Requires failover policy. Manual intervention can be required to then cause a fail-back to the active site.
- active/active: return >1 resource. Requires latency policy, weighted policy, or some other policy besides failover. In the case of failover, returns only the healthy resource
- combination: multiple policies are combined into a tree for more complex DNS failover
*
Routing Records Best practice
use DNS names/URLs whenever possible rather than IP addresses. Some exceptions include pointing ELBs directly to the IP address of a peered VPC, or an on-prem resource linked via DX or VPN connection.
Alias records
- provide a Route 53–specific extension to DNS functionality.
- They let you route traffic to selected AWS resources: ELBs, APIs, CloudFront distributions, S3 buckets, Elastic Beanstalk, VPC interface endpoints, etc.
- Unlike a CNAME record, they also let you route traffic from one record in a hosted zone (usually the zone apex / naked domain name, such as “example.com”) to another record (e.g. “www.example.com”)
- When Route 53 receives a DNS query for an alias record, it responds with 1 or more IP addresses that the record maps to
CNAME records (canonical name records)
- redirect DNS queries to any DNS record. For example, you can create a CNAME record that redirects queries from acme.example.com to zenith.example.com or acme.example.org.
- You don’t need to use Route 53.
- Unlike Alias records, they can’t be used for resolving apex domain names
PTR records
reverse lookup where you map an IP address to a DNS name
AWS Services Calling into a VPC
To enable AWS serverless services such as Lambda to access resources inside your private VPC, you provide it with VPC-specific info such as your subnet IDs and security group IDs.
Elastic Load Balancers
ELBs send traffic to AWS and on-prem resources. Unlike Route 53, they use resource IP addresses and you don’t get to specify policies such as a weighted policy. VPC flow logs show traffic going to/from an ELB
Application Load Balancer (ALB)
- makes routing decisions at the application layer aka Layer 7 (HTTP/HTTPS)
- supports path-based routing and host-based routing (i.e. based on the content of the request in the host field)
- can route requests to one or more ports on each ECS container instance in a cluster
- supports authentication from OIDC compliant IDPs such as Google and Facebook via an integration with Cognito
- periodically sends messages to its targets to check their status - health checks. - and routes only to healthy targets
- enable access logs which can get pushed to S3. They log info on requester, IP, request type, etc.
Network Load Balancer (NLB)
make routing decisions at the transport layer aka Layer 4 (TCP/SSL). They can handle millions of requests per second with extremely low latency. They don’t support path-based routing or host-based routing the way ALB does.
Classic Load Balancer (CLB)
operates using TCP, SSL, HTTP and HTTPS. Not as good at high throughput / low latency as NLB. Also unlike NLB, it does not support load balancing to multiple ports on an instance.
AWS Direct Connect (DX) Gateway
- You can use Direct Connect (DX) to connect an on-prem data centre to one or multiple VPCs
- DX can take > 1 month to setup
- For resilience, add a 2nd DX connection. As this can take time to setup and is costly, in the short term consider also adding an IPSec VPN connection (with the same BGP prefix) for resiliency.
- A hosted virtual interface (hosted VIF) allows another AWS account to access your DX
- Use AWS DataSync to copy large amount of data from on-prem to S3, EFS, FSx, NFS shares, SMB shares, AWS Snowcone (via Direct Connect). For copying data, use DMS to copy databases.
You must create one of the following virtual interfaces to begin using DX:
* Private virtual interface (private VIF): access a VPC using private IP addresses
* Public virtual interface (public VIF): access all AWS public services using public IP addresses
* Transit virtual interface (transit VIF): access one or more VPC Transit Gateways associated with DX gateways, within a Region.
AWS Transit Gateway
Central Hub connecting on-prem networks and VPCs.
* Reduces operational complexity as you can easily add more VPCs, VPN capacity, Direct Connect gateways, without complex routing tables.
* Provides additional features over-and-above VPC peering
- A transit virtual interface is used to access VPC Transit Gateways
- Pattern for connecting 1 DX to multiple VPCs in the same Region is to associate the DX with a transit gateway
- on-prem -> DX -> DX location -> transit virtual interface -> transit gateway association -> Transit Gateway -> multiple VPCs
