AWS Fundanmentals

ELB & ASG

Scalability & High Availability

Vertical Scalability
- increasing the size of the instance
- hardware limitation
Horizontal Scalability
- increasing the number of instances
- distributed system
HA
- auto scaling group multi AZ
- load balancer multi AZ

Health Checks (TCP/HTTP)

Elastic Load Balancer

4 kinds of Managed Load Balancers

classic (v1, deprecated)
- http, https, tcp, ssl
application v2
- OSI layer 7
- http/2, https, WebSocket
network v2
- OSI layer 4
- TCP, TLS, UDP
gateway
- OSI layer 3 (network layer), IP

Application Load Balancer (v2)

OSI Layer 7 (HTTP)
support HTTP/2, WebSocket
support redirects (http to https)
Routing tables to different target groups
- url path
- hostname
- query string, headers
port mapping feature to redirect to a dynamic port in ECS
target groups
- EC2 instances
- ECS tasks
- Lambda functions
- (private) IP Addresses
ALB can route to multiple target groups
health checks are at the target group level
fixed hostname xxx.region.elb.amazonaws.com
the client info x-forwarded-for, x-forwarded-port, x-forwarded-proto

Network Load Balancer (v2)

Layer 4 (TCP, UDP)
- handles millions of request per seconds
- less latency ~ 100ms (vs 400ms for ALB)
one static IP per AZ, supports assigning ElasticIP
target groups
- EC2
- private IPs
- ALB
health checks TCP, HTTP, HTTPS

Gateway Load Balancer

Layer 3 (IP Packets)
transparent network gateway - single entry/exit for all traffic
load balancer - distribute traffic to your virtual appliances
GENEVE protocol on port 6081
target groups
- EC2
- (private) IP Addresses
usage
- firewalls
- intrusion detection
- prevention systems
- deep packet inspection systems
- payload manipulation

Sticky Sessions

based on “cookie” with an expiration date (CLB, ALB)
application-based cookies
- custom cookie
- application (AWSALBAPP)
duration-based cookies

Cross-Zone LB

with cross-zone Load Balancing: each load balancer instance distributes evenly across all registered instances in all AZ
otherwise, distribute evenly on AZ
only enabled by default for ALB

SSL/TLS

load balancer uses an X.509 certificate
can manage certificates using ACM (AWS Certificate Manager)
HTTPS listener
- You must specify a default certificate
- You can add an optional list of certs to support multiple domains
- Clients can use SNI (Server Name Indication) to specify the hostname they reach
- Ability to specify a security policy to support older versions of SSL /TLS (legacy clients)

SNI (Server Name Indication)

SNI solves the problem of load multiple SSL certificates onto one web server (multiple websites)
A “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake
The server will then find the correct certificate, or return the default one
only works for ALB, NLB, CloudFront

Auto Scaling Group

ASG is free (pay for the underlying EC2)

scale out to match an increased load
scale in to match a decreased load
ensure a minimum and a maximum number of running EC2
automatically register new instances to a load balancer
re-create EC2 in case a previous one is terminated (unhealthy)

ASG Attributes: Launch Template + Capacity + Scaling Policy

AMI + Instance Type
EC2 User data
EBS Volumes
Security Groups
SSH Key pair
IAM Roles for EC2
Network + Subnets Information
Load Balancer Information

Auto Scaling - base on CloudWatch Alarms (metrics such as average cpu for the overall ASG instances)

CPUUtilization
RequestCountPerTarget
Average Network In/Out
any custom metric

Dynamic Scaling Policies

Target Tracking Scaling
- average cpu stays at around 40%
Simple / Step Scaling (cloud watch alarm)
- CPU > 70%, then add 2 units
- CPU < 30%, then remove 1 unit
Scheduled Actions
- increase the min capacity to 10 at 5pm on Fridays
Predictive Scaling
- continuously forecast load and schedule scaling ahead

Scaling cooldown

After a scaling activity happens, you are in the cooldown period (default 300 seconds).
During the cooldown period, the ASG will not launch or terminate additional instances (to allow for metrics to stabilize).
use a ready-to-use AMI to reduce configuration time in order to be serving request faster and reduce the cooldown period

why LB

Spread load across multiple downstream instances
Expose a single point of access (DNS) to your application • Seamlessly handle failures of downstream instances
Do regular health checks to your instances
Provide SSL termination (HTTPS) for your websites
Enforce stickiness with cookies
High availability across zones
Separate public traffic from private traffic

integrated services

[[aws-ec2|EC2]], EC2 ASG, ECS
ACM, CloudWatch
[[aws-route53|Route53]], WAF, AWS Global Accelerator

RDS

Relational Database Service

VS self-deployed on EC2

automated provisioning, OS patching
continuous backups and restore to specific timestamp (point in time restore)
monitoring dashboards
read replicas
- up to 15 read replicas
- within AZ, cross AZ, cross Region
- ASYNC
- replicas can be promoted to their own DB
- application must update the connection string to leverage read replicas
- same region cross AZ is free, cross Region ($$$)
multi-AZ for DR (disaster recovery)
- SYNC replication
- one DNS name - automatic app failover to standby
maintenance windows for upgrades
scaling capacity (vertical / horizontal)
storage backed by EBS (GP2, or IO1)
storage auto scaling Automatically
- avoid manually scaling your database storage
- have to set Maximum Storage Threshold
RDS backups
- automatic
  - daily full backup (during the backup window)
  - transaction logs are backed-up by RDS every 5 minutes
  - ability to restore to any point in time (oldest to 5 minutes ago)
  - 1 ~ 35 days of retention, set 0 to disable automated backup
- manual DB snapshots (retention of backup for as long as you want)
RDS proxy
- allows app to pool and share DB connections
- improving database efficiency by reducing stress on database resources and minimize open connections
- serverless, autoscaling, HA (multi-AZ)
- reduced RDS & Aurora failover time by up 66%
- enforce IAM authentication for DB, and securely store credentials in AWS secrets manager
- is never publicly accessible, must be accessed from VPC

in a stopped RDS database, you will still pay for storage. If you plan on stopping it for a long time, you should snapshot & restore instead

Aurora

AWS cloud optimized
claims 5x performance improvement over MySQL on RDS, 3x over Postgres
storage automatically grows in increments of 10GB, up to 128TB
can have up to 15 replicas and the replication process is faster than MySQL
HA native
- failover is Aurora is instantaneous
- 6 copies of your data across 3 AZ
- support for cross region replication
Costs more than RDS (20% more)
Endpoints
- writer endpoint, points to the master
- reader endpoint, connection load balancing to replica node
- custom endpoints - run analytics queries on specific replicas
Aurora Serverless - pay per second
Global Aurora
- Cross Region read replicas
- Global Database
  - 1 primary region (RW)
  - up to 5 secondary (RO) regions, replication lag is less than 1 seconds
  - up to 16 read replicas per secondary region
  - promoting another region (DR) has an RTO of 1 minute
  - cross region replication takes less than 1 second
Machine Learning
- enables you to add ML-based predictions to your applications via SQL
- SageMaker (ML models)
- Comprehend - sentiment analysis
Backups
- automatic
  - 1 ~ 35 days of retention
  - point-in-time recovery in that timeframe
- manual DB snapshots (retention of backup for as long as you want)
Restore options
- backup or snapshot
- S3
Database Cloning
- create a new Aurora DB Cluster from an existing one
- faster than snapshot & restore
- copy-on-write protocol
- cost-effective
security
- at-rest encryption
- in-flight encryption - TLS ready by default
- IAM authentication - IAM Roles instead of user/pass
- security groups
- no ssh available, except RDS custom
- audit logs can be enabled and sent to CloudWatch logs for longer retention

Features

Automatic fail-over
Backup and Recovery
Isolation and Security
Industry compliance
Push-button scaling
Automated Patching with Zero Downtime
Advanced Monitoring
Routine Maintenance
Backtrack: restore data at any point of time without using backups

RDS Proxy

improving database efficiency
enforce IAM
never publicly accessible

`ElastiCache`

Amazon managed Redis or Memcached
- AWS takes care of OS maintenance / patching, optimizations, setup, configuration, monitoring, failure recovery and backups
- Redis
  - multi-AZ with auto-failover
  - read replicas
  - AOF, persistent
  - backup and restore feature
- Memcached
  - multi-node for partition of data sharding
  - no HA, non persistent, no backup
  - multi-thread arch
security
- supports IAM Authentication for [[Redis]]
- Redis AUTH
- Memcached supports SASL-based authentication

Quick Catchup

Network Load Balancer has one static IP address per AZ and you can attach an Elastic IP address to it. Application Load Balancers and Classic Load Balancers have a static DNS name.
Server Name Indication (SNI) allows you to expose multiple HTTPS applications each with its own SSL certificate on the same listener. Read more here: https://aws.amazon.com/blogs/aws/new-application-load-balancer-sni/
RDS 15 read replicas
Aurora Cloning Feature
RDS Replication is ASYNC
RDS Multi-AZ is SYNC