DEV Community: Le Huy Ho

Learning AWS - DVA - Day 15: Route 53 Routing Policies

Le Huy Ho — Tue, 22 Oct 2024 06:31:17 +0000

Overview

Define how Route 53 responds to DNS queries
Don't get confused by the word "Routing"
- It's not the same as Load Balancer routing which routes the traffic
- DNS does not route any traffic, it only responds to the DNS queries
Route 53 supports the following Routing Policies
- Simple
- Weighted
- Failover
- Latency based
- Geolocation
- IP-based
- Multi-Value Answer
- Geoproximity (using Route 53 Traffic Flow feature)

Routing Policies - Simple

Typically, route traffic to a single resource
Can specify multiple values in the same record
If multiple value are returned, a random one is chosen by the client
When Alias enabled, specfy only one AWS resource
Can't be associated with Health Checks

Routing Policies - Weighted

Control the % of the requests that go to each specific resource
Assign each record a relative weight:
traffic(%) = weight of the records / sum of all the weight
Weights don't need to sum up to 100
DNS records must have the same name and type
Can be associated with Health Checks
Use cases: load balancing between regions, testing new application versions, ...
Assign a weight of 0 to a record to stop sending traffic to a resource
If all records have weight of 0, then all records will be returned equally

Routing Policies - Latency-based

Redirect to the resource that has the least latency close to us
Super helpful when latency for users is a priority
Latency is based on traffic between users and AWS Regions
Germany users may be directed to the US (if that is the lowest latency)
Can be associated with Health Checks (has a failover capability)

Routing Policies - Failover (Active - Passive)

You designate a primary resource and a secondary (or failover) resource. The primary resource is the one that Route 53 will route traffic to under normal conditions
Route 53 performs health checks on the primary resource to determince its availability
If the primary resource becomes unhealthy, Route 53 will redirect traffic to the secondary resource without manual intervention
Use cases: high vailability dns, desaster recovery

Routing Policies - Geolocation

Different from Latency-based
This routing is based on user location
Specify location by Continent, Contry or by US State (if there is overlapping, most precise location selected)
Should create a "Default" record (in case there is no match on location)
Use cases: website localization, restrict content distribution, load balancing, ...
Can be associated with Health Checks

Routing Policies - Geoproximity

Route traffic to your resources based on the geographic location of users and resources
Ability to shift more traffic to resources based on the defined bias
To change the size of the geographic region, specify bias values:
- To expand (1 to 99) - more traffic to the resource
- To shrink (-1 to -99) - less traffic to the resource
Resources can be:
- AWS resources (specify AWS Region)
- Non-AWS resources (specify Latitude and Longitude)
You must use Route 53 Traffic Flow (advanced) to use this feature

Routing Policies - IP-basd Routing

Routing is based on client's IP addresses
You provide a list of CIDRs for your clients and the corresponding endpoints/locations (user-IP-to-endpoint mappings)
Use cases: Optimize performance, reduce network costs, ...
Example: route end users from a particular ISP to a specific endpoint

Routing Policies - Multi-Value

Use when routing traffic to multiple resources
Route 53 return multiple values/resources
Can be associated with Health Checks (return only values for healthy resources)
Up to 8 healthy records are returned for each Multi-Value query
Multi-Value is not a substitue for having an ELB

Domain Registrar vs DNS Service

You buy or register your domain name with a Domain Registrar typically by paying annual charges (e.g., GoDaddy, Amazon Registra Inc, Hostinger, ...)
The Domain Registrar usually provides you with a DNS service to manage your DNS records
But you can use another DNS service to manage your DNS records
Example: purchase the domain from GoDaddy and use Route 53 to manage your DNS records
So if you buy your domain on a 3rd party registrar, you can still use Route 53 as the DNS Service provider
Create a Hosted Zone in Route 53
Update NS Records on 3rd party website to use Route 53 Name Servers

Learning AWS - DVA - Day 14: Route 53

Le Huy Ho — Tue, 22 Oct 2024 03:35:42 +0000

What is DNS?

Domain Name System which translates the human friendly hostnames into the machine IP addresses
www.google.com => 172.217.18.36
DNS is the backbone of the internet
DNS uses hierarchical naming structure: .com, .example.com, www.example.com, api.example.com

DNS Terminologies

Domain Registrar: Amazon Route 53, GoDaddy, Hostinger, ...
DNS Records: A, AAAA, CNAME, NS, ...
Zone File: contains DNS records
Name Server: resolves DNS queries (Authoritative or Non-Authoritative)
Top Level Domain (TLD): .com, .us, .in, .gov, ...
Second Level Domain (SLD): amazon.com, google.com, ...
Sub Domain: www.example.com, ...
Full Qualified Domain Name (FQDN): api.www.example.com

Amazon Route 53 Overview

A highly available, scalable, fully managed and Authoritative DNS
- Authoritative = the customer (you) can update the DNS records
Route 53 is also a Domain Registrar
Ability to check the health of your resources
Why 53? 53 is a reference to the traditional DNS port

Route 53 - Records

Records describes how you want to route traffic for a domain
Each record contains:
- Domain/subdomain Name - e.g., example.com
- Record Type - e.g, A or AAAA,...
- Value - e.g, 12.34.56.78
- Routing Policy - how Route 53 responses to queries
- TTL - amount of time the record cached at DNS Resolvers
Route 53 supports the following DNS record type
- (must know) A / AAAA / CNAME / NS
- (advanced) CAA / DS / MX / NAPTR / PRT / SOA / TXT / SPF / SRV

Record Types

A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
- The target is a domain name which must have an A or AAAA record
- Can't create a CNAME record for the top node of a DNS namespace (Zone Apex)
- Example: you can't create for the example.com, but you can create for www.example.com
NS - Name Servers for the Hosted Zone
- Control how traffic is routed for a domain

Hosted Zones

A container for records that define how to route traffic to a domain and its subdomains
Public Hosted Zones - contains records that specify how you route traffic on the Internet (public domain names)
Private Hosted Zones - contains records that specify how you route traffic within one or more VPCs (private domain names)

CNAME vs Alias

AWS Resources (Load Balancer, CloudFront,...) expose an AWS hostname.
ex. lb1-1234.us-east-2.alb.amazonaws.com and you want myapp.mydomain.com
CNAME:
- Points a hostname to any other hostname . (app.mydomain.com => blabla.anything.com)
- ONLY FOR NON ROOT DOMAIN
Alias:
- Points a hostname to an AWS Resoure (app.mydomain.com => blabla.amazonaws.com)
- Works for ROOT DOMAIN and NON ROOT DOMAIN
- Free of charge
- Native health check
- Alias Record is always of type A/AAAA for AWS resources (IPv4/IPv6)
- You can't set TTL

Alias Records Targets

Elastic Load Balancers
CloudFront Distribution
API Gateway
Elastic Beanstalk environments
S3 Websites
VPC Interface Endpoints
Global Accelerator accelerator
Route 53 Record in the same hosted zone
You cannot set an ALIAS record for an EC2 DNS name

Learning AWS - DVA - Day 13: ElastiCache Strategies

Le Huy Ho — Mon, 21 Oct 2024 16:09:47 +0000

Cache Implementation Considerations

Is it safe to cache data? Data maybe out of date, eventually consistent
Is caching effective for that data?
- Pattern: data changing slowly, few keys are frequently needed
- Anti Patterns: data changing rapidly, all large key space frequently needed
Is data structured well for caching?
- ex: key value caching, or caching of aggregations results
Which caching design pattern is the most appropriate?

Lazy Loading / Cache Aside / Lazy Population

PROS:
- Only requested data is cached (the cache is not filled up with unused data)
- Node failures are not fatal (just increased latency to warm the cache)
CONS:
- Cache miss penalty that results in 3 round trips, noticeable delay for that request
- Stale data: data can be updated in database and outdate in the cache

Write Through - Add or Update cache when database is updated

PROS:
- Data in cache never stale, reads are quick
- Write penalty vs Read penalty (each write requires 2 calls)
CONS:
- Missing Data until it is added/updated in the DB. Mitigation is to implement Lazy Loading strategy as well
- Cache churn - a lot of the data will never read

Cache Evictions and Time-To-Live (TTL)

Cache Evictions can occur in three ways:
- You delete the item explicitly in the cache
- Item is evicted because the memory is full and it is not recently used (LRU)
- You set an item time-to-live (TTL)
TTL are helpful for any kind of data:
- Leaderboards
- Comments
- Activity Stream
TTL can range from few seconds to hours or days

Learning AWS - DVA - Day 12: ElastiCache

Le Huy Ho — Mon, 21 Oct 2024 15:25:46 +0000

Overview

The same way RDS is to get managed Relational Databases
ElasticCache is to get managed Redis or Memcached
Caches are in-memory databases with really high performance, low latency
Helps reduce load off of database for read intensive workloads
Helps make your application stateless
AWS take care of OS maintenance / patching, optimizations, setup, configuration, monitoring, failure recovery and backups
Using ElasticCache involves heavy application code changes

ElastiCache Solution Architect - DB Cache

Applications queries ElastiCache, if not available, get from RDS and store in ElastiCache
Helps relieve load in RDS
Cache must have an invalidation strategy to make sure only the most current data is used in there

ElastiCache Solution Architect - User Session Store

User logs into any of the application
The application writes the session data into ElastiCache
The user hit another instance of our application
The instance retrieves the data and the user is already logged in

ElastiCache - Redis vs Memcached

Learning AWS - DVA - Day 11: Amazon Aurora - RDS Security - RDS Proxy

Le Huy Ho — Mon, 21 Oct 2024 14:57:16 +0000

Overview

Aurora is a proprietary technology from AWS (not open sourced)
Postgres and MySQL are both supported as Aurora DB (that mean your drives will work as if Aurora was a Postgres or MySQL database)
Aurora is "AWS cloud optimized" and claims 5x performance improvement over MySQL on RDS, over 3x performance of Postgres on RDS
Aurora storage automatically grows in increments of 10GB, up to 128TB
Aurora can have up to 15 read replicas and replication process is faster than MySQL (sub 10ms replica lag)
Failover in Aurora is instantaneous. It is HA native
Aurora costs more than RDS (20%) - but more efficient

Feature of Aurora

Automatic fail-over
Backup and Recovery
Automatic patching with Zero Downtime
Advanced Monitoring
Routine maintenance
Backtrack: restore data any point time without using backups

RDS & Aurora Security

At-rest encryption:
- Database master and replicas encryption using AWS KMS - much be define at launch time.
- If the master NOT encrypted, the replicas CAN NOT be encrypted
- To encrypt an un-encrypted database, go through DB snapshot & restore as encrypted
In-flight encryption: TLS-ready by default, use AWS TLS root certificates client-side
IAM Authentication: IAM role to connection to your database (instead of username/password)
Security Group: Control network access to your RDS/Aurora DB
No SSH available except RDS custom
Audit Logs can be enabled and sent to CloudWatch Logs for long retention

Amazon RDS Proxy

Fully managed database proxy for RDS
Allow apps to pool and share DB connections established with the database
Improving database efficiency by reduce the stress on database resource (eg. CPU, RAM) and minimize open connections (and timeouts)
Serverless, auto scaling, highly availability (multi-AZ)
Reduce RDS and Aurora failover time by up 66%
Support RDS and Aurora
No code changes required for most apps
Enforce IAM Authentication for DB, and securely store credentials in AWS Secrets Manager
RDS Proxy never publicly accessible (must be access from VPC)

Learning AWS - DVA - Day 10: Amazon RDS

Le Huy Ho — Mon, 21 Oct 2024 14:14:07 +0000

Overview

RDS stands for Relational Database Service
It is a managed DB service for DB use SQL as a query language
It allows you to create databases in the cloud that are managed by AWS:
- Postgres
- MySQL
- MariaDB
- Oracle
- Microsoft SQL Server
- IBM DB2
- Aurora (AWS Proprietary database)

Advantage over using RDS vs deploying DB on EC2

RDS is a managed service:
- Automated provisioning, OS patching
- Continuous backups and restore to specific timestamp (point-in-time restore)
- Monitoring dashboards
- Read replicas for improved read performance
- Multi AZ setup for Disaster Recovery
- Maintenance windows for upgrades
- Scaling capability (vertical and horizontal)
- Storage backed by EBS
BUT you CAN NOT SSH into your instance

Storage Auto Scaling

Help you increase storage on your RDS DB instance dynamically
When RDS detects you are running out of free database storage, it scales automatically
Avoid manually scaling your database storage
You have to set Maximum Storage Threshold (maximum limit for DB storage)
Automatically modify storage if:
- Free storage less than 10% of allocated storage
- Low-storage lasts at least 5 minutes
- 6 hours have passed since last modification
Useful for applications with unpredictable workloads

RDS Read Replicas vs Multi AZ

RDS Read Replicas for read scalability

Up to 15 Read Replicas
Within AZ, Cross AZ or Cross Region
Replication is ASYNC, so reads are eventually consistent
Replicas can be promoted to their own DB
Application must update connection string to leverage read replicas

RDS Read Replicas - Use Cases

You have a production database that is taking on normal workload
You want to run a reporting application to run some analytics
You create a Read Replica to run the new workload there
The production application is unaffected
Read Replicas are used for SELECT (=read) only kind of statements (not INSERT, UPDATE, DELETE)

RDS Read Replicas - Network Cost

In AWS there is a network cost when data goes from one AZ to another
BUT For RDS Read Replicas within the same region, you don't pay that fee

RDS Multi AZ (Disaster Recovery)

SYNC replication
One DNS name - automatic app failover to standby
Increase availability
Failover in case of loss AZ, loss of network, instance or storage failure
No manual intervention in apps
Not used for scaling

*What I noted: *

Increase read workloads -> Read Replicas. Increase High Availability and disaster recovery -> Multi AZ
Read Replicas is ASYNC replication (read eventually consistent). Multi AZ is SYNC replication.
Read Replicas (manual). Multi AZ (automatically)

Learning AWS - DVA - Day 9: Auto Scaling Groups

Le Huy Ho — Mon, 21 Oct 2024 09:39:36 +0000

What is an Auto Scaling Group?

In real-life, the load of your websites and applications can be change
In the cloud, you can create and get rid of servers very quickly
The goal of an Auto Scaling Groups (ASG) is to:
- Scale out (add EC2 intances) to match an increased load
- Scale in (remove EC2 instances) to match a decreased load
- Ensure we have a minimum and a maximum number of EC2 instances running
- Automatically register new instances to a load balancer
- Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy)
Auto Scaling Group are free - you only pay for the underlying EC2 intances.

Auto Scaling Group Attributes

A Launch Template, includes:
- AMI + Instance Type
- EC2 User Data
- EBS Volumes
- Security Groups
- SSH Key Pair
- IAM Role for your EC2 instance
- Network + Subnet Information
- Load Balancer Information
Min Size / Max Size / Initial Capacity
Scaling Policies

CloudWatch Alarm and Scaling

It is posible to scale an ASG based on CloudWatch alarms
An alarm monitors a metric (such as Average CPU, or a custom metric)
Metric such as Average CPU are computed for the overall ASG instances
Based on the alarm:
- We can create scale-out policies (increase the number of instances)
- We can create scale-in policies (decrease the number of instances)

Auto Scaling Policies

Dynamic Scaling

Target Tracking Scaling
- Simple to set-up
- Example: I want the average ASG CPU to stay at around 40%
Simple / Step Scaling
- When a CloudWatch alarm is triggered (ex: CPU > 70%) then add 2 units
- When a CloudWatch alarm is triggerd (ex: CPU < 30%) then remove 1

Scheduled Scaling

Anticipate a scaling based on known usage patterns
Example: increase the min capacity to 10 at 5pm on Fridays

Predictive Scaling: continously forecast load and schedule scaling ahead

Good metrics to scale on

CPUUtilization: Average CPU utilization across your instances
RequestCountPerTarget: to make sure the number of requests per EC2 instances is stable
Average Network In/Out (if your application is network bound
Any custom metric (that you push using CloudWatch)

Learning AWS - DVA - Day 9: ELB Advanced

Le Huy Ho — Mon, 21 Oct 2024 09:25:26 +0000

ELB - Sticky Sessions

Session Affinity

It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer
This works for Classic Load Balancer, Application Load Balancer, Network Load Balancer
The "cookie" used for stickiness has an expiration date you control
Use case: make sure the user doesn't lose his session data
Enabling stickiness may bring imbalance to the load over the backend EC2 instances

Cookie Names

Application-based Cookies:
- Custom cookie: generated by the target - don't use AWSALB, AWSALBAPP, AWSALBTG(reserved for use by ELB)
- Applicaiton cookie: generated by the load balancer - cookie name is AWSALBAPP
Duration-base Cookies: generated by the load balancer. Cookie name is AWSALB (for ALB), AWSEL (for CLB)

Cross-Zone Load Balancing

Application Load Balancer
- Enabled by default (can be disabled at the Target Group Level)
- No charges for inter AZ data
Network Load Balancer & Gateway Load Balancer
- Disabled by default
- You pay charges ($) for inter AZ data if enabled
Classic Load Balancer
- Disabled by default
- No charges for inter AZ data if enabled

Learning AWS - DVA - Day 8: Gateway Load Balancer

Le Huy Ho — Mon, 21 Oct 2024 08:58:07 +0000

Overview

Deploy, scale and manage a fleet of 3rd party network virtual appliances in AWS. (ex: Firewalls, Intrusion Detection and Prevention System, Deep Packet Inspection Systems, payload manipulation, ...)
Operates at Layer 3 (Network Layoer) - IP Packets
Uses the GENEVE **protocol on port **6081

Target Groups

EC2 Instances
IP Addresses - must be private IPs

Use Cases

Network Security: Easily deploy and manage security appliances like firewalls or intrusion detection systems in your network architecture.
Traffic Inspection: Route traffic through appliances for deep packet inspection and monitoring.
Hybrid Architectures: Facilitate the integration of on-premises network appliances with AWS.

Learning AWS - DVA - Day 7: Network Load Balancer

Le Huy Ho — Mon, 21 Oct 2024 08:52:46 +0000

Overview

Network Load Balancers is Layer 4 (OSI Model), allow to:
- Forward TCP and UDP traffic to your instances
- Handle milions of request per seconds
- Ultra-low latency
Network Load Balancer has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelist specific IP)
NLB are used for extreme performance, TCP or UDP traffic

Target Groups

EC2 Instances
IP Addresses - must be private IPs
Application Load Balancer

Health Check support the TCP, HTTP and HTTPS protocols

Learning AWS - DVA - Day 6: Application Load Balancer

Le Huy Ho — Mon, 21 Oct 2024 08:45:54 +0000

Overview

Application Load Balancers is Layer 7 in OSI model (HTTP)
Load balancing to multiple HTTP applications across machines (target groups)
Load balancing to multiple applications on the same machine (ex: containers)
Support for HTTP/2 and Websocket
Support redirects (from HTTP to HTTPS for example)
Routing based on path in URL (example.com/users & example.com/posts)
Routing based on hostname in URl (one.example.com * other.exmaple.com)
Routing based on Query String, Headers (example.com/users?id=123&order=false)

Use cases

ALB are great fit for micro service & container-based application:

Microservice Architecture: route traffic to different services base on URL paths
Containerized Application: Works well with Amazon ECS and EKS for managing traffic to containers
Multi-Region Applications: Distribute traffic across multiple AWS regions.

Good to know

The application servers don't see the IP of the client directly. The true IP of the client is inserted in the header X-Forwarded-For. We can also get Port (X-Forwarded-Port) and protocol (X-Forwarded-Proto).

Learning AWS - DVA - Day 5: ELB (Elastic Load Balancer)

Le Huy Ho — Mon, 21 Oct 2024 08:23:59 +0000

What is load balancing?

Load Balancers are servers that forward traffic to multiple backend or downstream EC2 instances or servers.

Why use a load balancer?

Spread load across multiple downstream instances
Expose a single point of access (DNS) to your application
Seamlessly handle failures of downstream instances because the load balancer will have some health check mechanisms.
Provide SSL termination (HTTPS) for your websites
Enforce stickiness with cookies
High availability across zones
Separate public traffic from private traffic

Why use an AWS Elastic Load Balancer?

An Elastic Load Balancer is a managed load balancer (AWS will be managing it - AWS takes care of upgrades, maintenance, HA - AWS guarantees that it will be working,...)
It cost less to setup your own load balancer but it will be a lot more effort on your end.
It is integrated with many AWS offering / services:
- EC2, EC2 Auto Scaling Groups, Amazon ECS
- AWS Certificate Manager (ACM), CloudWatch
- Route 53, AWS WAF, AWS Global Accelerator ## Health Checks
Health Checks are crucial for Load Balancers
They enable the load balancer to know if instances it forwards traffic to are available to reply to request.
The health check is done on a port and a route (/health is common)
If the response is not 200 OK, then the instance is unhealthy

Types of Load Balancer on AWS

AWS has 4 kinds of managed Load Balancers:

Classic Load Balancer - CLB (v1 - old generation): HTTP, HTTPS, TCP, SSL (Secure TCP) (deprecated at AWS and will soon not be available in the AWS console)
Application Load Balancer - ALB (v2 - new generation): HTTP, HTTPS, Websocket
Network Load Balancer - NLB (v2 - new generation): TPC, TLS (Secure TCP), UDP
Gateway Load Balancer - GWLB: Operates at layer 3 (Network layer) - IP protocol

Some load balancers can be setup as internal (private) or external (public) ELBs