AWS Certified Solutions Architect Associate

AWS Cloud Overview: Regions & AZ

AWS Availability Zones

Each region has usually 3 (min: 3, max: 6) availability zones, each of them stand for one or more discrete data centers with redundant power, networking, and connectivity. Each AZ are separate from each other -> isolated from disasters.

IAM & AWS CLI

IAM: Users & Groups

IAM = Identity and Access Management, Global service Root account created by default, should be only use for creating user. Can categorized users into group, but group can only contain user, can't contain another group.

IAM: Permissions

• Users/Groups can be assigned JSON documents called policies.
• Policy defines the permission of the user.
• Should apply least privilege principle

IAM Policy Structure

AWS Console Simultaneous Sign-in

Now AWS Console allow more than 1 user login in different browser tab

Defense for Users

IAM Password Policy

• minimum pwd length
• require specific char types
• allow all IAM users to change their own pwd
• require users to change pwd after a period (set pwd expiration)
• prevent pwd re-use

MFA - Multi Factor Authentication

• To protect your Root Accounts and IAM users
• MFA = pwd + security device you own
• devices options in AWS
  • Virtual MFA device: Google Authenticator, Authy
  • Universal 2nd Factor (U2F) Security Key: YubiKey (3rd party), support single security key
  • Hardware Key Fob MFA Device
  • Hardware Key Fob MFA Device for AWS GovCloud(US)

3 Options to Access AWS

• AWS Management Console (by pwd + MFA)
• CLI (by access keys)
• SDK (by access keys)

IAM Security Tools

• IAM Credentials Report (account-level)
  • Lists all your account's users and status of their credentials.
• IAM Access Advisor/Last Access (user-level)
  • Shows service permissions granted to a user and their last accessed time.

IAM Guidelines & Best Practices

• 1 physical user = 1 AWS user
• Assign users to groups, and assign permissions to groups
• enforce MFA
• use Role to give permissions to AWS services
• Access keys for CLI/SDK

Amazon EC2

• EC2 = Elastic Compute Cloud = IaaS (Infrastructure as a Service)
• Main capability:
  • Renting VM (EC2)
  • Storing data on virtual drives (EBS)
  • Distributing load across machines (ELB)
  • Scaling services with ASG (auto-scaling group)

EC2 Sizing & Configuration Options

• storage space
  • Network-attached (EBS & EFS)
  • hardware (EC2 Instance Store)
• Network card: speed, Public IP address
• Firewall rules
• Bootstrap script (configure at first launch only): EC2 User Data
  • bootstrapping: launching commands when a machine starts
  • To automate boot tasks:
    • installing updates & software & common files from the internet
    • Anything else

Security Groups

• Control how traffic is allowed in/out EC2 instances
• Only contain "allow" rules
• rules can reference by IP or security group
• It's good to maintain 1 separate security group for SSH access
• If your app is not accessible (time out), high chances is bc of a security group issue
• If app show "connection refused" error -> app error or not launched
• default to block all inbound, and authorised all outbound traffic

Classic Ports to Know

• 22 = SSH (Secure Shell) - log into a Linux instance
• 21 = FTP (File Transfer Protocol) - upload files into a file share
• 22 = SFTP (Secure File Transfer Protocol) - upload files using SSH
• 80 = HTTP - access unsecured web
• 443 = HTTPS - access secured web
• 3389 = RDP (Remote Desktop Protocol) - log into a Windows instance

SSH Summary Table

• SSH: Mac, Linux, Windows >=10
• Putty: Windows
• EC2 Instance Connect (using web browser): Allow all above (after Amazon NX2)

EC2 Instances Purchasing Options

• On-Demand Instances: short workload, predictable pricing, pay by second
  • Billing per seconds (Linux/Windows) or hour (other os)
  • Highest cost but no upfront payment
  • No long-term commitment
  • for short-term and un-interrupted workloads (can't predict)
• Reserved (1 & 3 years)
  • Reserved Instances: long workloads
  • Convertible Reserved Instances: long workloads with flexible instances
    • Allow change instance
  • A specific instance attr (instance type, region, tenancy, os)
  • Reservation Period: 1 or 3
  • Payment Options: No Upfront, Partial Upfront, All Upfront
  • Scope: Regional or Zonal (reserve capacity in an AZ)
  • For steady-state usage app (think db)
  • Allow buy/sell in the Marketplace
• Saving Plans (1 & 3 years): commitment to an amount of usage, long workload
  • Commit to a certain type of usage
  • Usage beyond billed at On-Demand price
  • Locked to a specific instance family & region
  • Flexible:
    • Instance size
    • OS
    • Tenancy (Host, Dedicated, Default)
• Spot Instances: short workloads, cheap, can lose instances (less reliable)
  • Most discount
  • Lose instance when your max price < current spot price
  • Most cost-efficient instances
  • For workloads that are resilient to failure:
    • Batch jobs
    • Data analysis
    • Image processing
    • Any distributed workloads
  • Not suitable for critical job or db
• Dedicated Hosts: entire physical server, control instance placement
  • Compliance requirements, use your server-bound software licenses
  • Purchase Options:
    • On-Demand
    • Reserved
  • Most expensive option
  • For software have complicated licensing model (BYOL - Bring Your Own License)
  • For corp with strong regulatory or compliance needs
• Dedicated Instances: own the hardware
  • May share hardware with other instances in same account
  • No control over instance placement (can move hardware)
• Capacity Reservations: reserve in a specific AZ for any duration
  • Reserve On-Demand
  • Always have access
  • No time commitment, no billing discounts
  • Combine with other to benefits from billing discounts
  • Be charged On-Demand
  • For short-term, uninterrupted workloads

How to Terminate Spot Instances

• You can only cancel Spot Instance requests that are open, active, or disabled
• Cancelling spot request != terminate instances
• Firstly, cancel a spot request, then terminate spot instances

Spot Fleets

• it's set of Spot Instances + (opt) On-Demand Instances
• It will try to meet the target capacity with price constraints
  • Define possible launch pools: instance type, OS, availability zone.
  • Can have multiple launch pools
  • Stop when reaching capacity or max cost
• Strategies to allocate:
  • lowestPrice: cost optimization, short workload
  • diversified: distributed across all pools, great for availability, long workloads
  • capacityOptimized: optimal capacity for the number of instances
  • priceCapacityOptimized (recommend): pools with highest capacity available, then select with the lowest price (best for most workloads)

Elastic IPs

• Fixed public IP for instance (if w/o, every time restart EC2 instance get new public IP)
• IPv4
• Able to mask the failure of an instance or software by rapidly remapping the address to another instance in your account.
• default allow to have 5 Elastic IP (can ask AWS for more)
• Try to avoid Elastic IP
  • It reflect poor architectural decisions
  • Better: use a random public IP and DNS name or Load Balancer

Private vs Public IP in AWS EC2

• Default with
  • a private IP for internal AWS Network
  • a public IP, for WWW
    • SSH connect use public since our device not in the same network with the instance

Placement Groups

• To define EC2 Instance placement strategy
• Strategy
  • Cluster: to a low-latency group in a single Availability Zone
    • Pros: Great network (recommend)
    • Cons: If the AZ fails, all instances fails at the same time
    • Use case: Big Data job that require complete fast or require low latency and high network throughput
  • Spread: across underlying hardware (max 7 instances per group per AZ): critical applications
    • Pros: across AZ, reduced risk is simultaneous failure
    • Cons: limited to 7 instances per AZ per group
    • Use case: app need maximize high availability, critical app need to be isolated from failure from others
  • Partition: spreads instances across many diff partitions within an AZ, Scales to 100s instances per groups
    • Pros:
      • Up to 7 partitions per AZ
      • Up to 100s of EC2 instances
      • across multiple AZs in same region
      • don't share racks with instances in other partitions
      • failure won't affect other partitions
      • instance can access partition info as metadata

Elastic Network Interfaces (ENI)

• Represents a virtual network card in a VPC
• provide network connectivity
• attr:
  • Primary private IPv4, >=1 secondary IPv4
  • 1 Elastic IP per private IPv4
  • 1 Public IPv4

  • “

    =1 security groups

  • 1 MAC address
  • Bound to a specific AZ

EC2 Hibernate

• Normally, when stop/terminate instances
  • stop: the data on disk (EBS) is kept intact
  • terminate: any EBS volumes (root) also set-up to be destroyed is lost
• What EC2 Hibernate do?
  • in-memory (RAM) state is preserved
  • instance boot faster (OS isn't stopped/restarted)
  • background: RAM state is written to a file in the root EBS volume (must be encrypted)
• Use cases:
  • Long-running processing
  • Saving the RAM state
  • Services that take time to init
• RAM Size <= 150GB
• Instance Size: not supported for bare metal instances
• Available for On-Demand, Reserved, and Spot instances
• hibernated <= 60 days
• Root EBS volume must have enough storage to hold the RAM state

EBS (Elastic Block Store) Overview

EBS Volume

• a network drive could be attached to instance while running
• enable instance have persist data even after termination
• bound to a specific AZ, unless snapshot before move AZ
• Only be mounted to 1 instance at a time
• CCP: 1 EBS can be mounted to 1 EC2 instance, but have some multi-attach feature for some EBS
• Have a provisioned capacity (size in GBs, and IOPS)
• Default to delete on Termination

EBS Snapshots

• Make a backup (snapshot) of EBS volume at a point in time
• Recommend to detach volume to do snapshot
• Can copy across AZ or Region

Snapshots Feature

• Archive
  • archive tier is 75% cheaper
  • 24 - 72 hrs for restoring
• Recycle Bin for EBS snapshots
  • setup rules to retain deleted so can be recovered
  • retention dur: 1 day to 1 year
• Fast Snapshot Restore (FSR)
  • Force full init of snapshot to have no latency on the first use ($$$)

AMI (Amazon Machine Image)

• Customization of an EC2 instance
  • Allow adding own software, config, os, monitoring, etc
  • faster boot/config bc pre-packaged
• Built for a specific region (allow copy across region)
• Launch EC2 instances from
  • Public AMI: AWS provided
  • Your own AMI: self made and maintain
  • AWS Marketplace AMI

EC2 Instance Store

• High performance hardware disk
• Better I/O performance
• Ephemeral - Lose storage if stopped
• Use cases: buffer, cache, scratch data, temporary content
• Risk of data loss if hardware fails
• Need to Backup and Replication

6 Types of EBS Volume

• gp2/gp3 (SSD): General purpose, balance price and performance
  • cost effective, low-latency
  • use cases: system boot volumes, Virtual desktops, Dev and Test env
  • 1GiB - 16TiB
  • gp3: Independently adjust IOPS and throughput speed
  • gp2: Adjust of IOPS and throughput are linked
• io1/io2 Block Express (SSD): Highest performance for mission-critical, low latency, or high-throughput workloads
  • Provisioned IOPS (PIOPS) SSD
  • Critical business app with sustained IOPS performance or need >= 16000 IOPS
  • Great for databases workloads (storage perf, and consistency)
  • io1(4 GiB - 16TiB): Independently increase PIOPS and storage
  • io2 Block Express (4GiB - 64TiB): Sub-millisecond latency, linked PIOPS and storage - 1000:1
  • Supports EBS Multi-attach (to instances)
• HDD
  • st1 (HDD): Low cost, for frequently accessed, intensive workloads
    • throughput optimized
    • Big data, data warehouses, log processing
    • Max throughput 500MiB/s - max IOPS 500
  • sc1 (HDD): Lowest cost, less frequently accessed workloads
    • For infrequently access data
    • Target: Lowest cost
    • Max throughput 250MiB/s - max IOPS 250
  • Can't be boot volume
  • 125GiB - 16TiB

More about EBS Volume

• Naming are characterized in Size | Throughput | IOPS (I/O Ops per sec)
• Only gp2/gp3 and io1/io2 Block express can be used as boot volumes

EBS Multi-Attach - io1/io2

• Attach 1 EBS volume to >=1 EC2 instances in SAME AZ
• Each instance has full read & write permissions to high-performance volume
• Use cases:
  • Achieve higher app availability in clustered Linux app (e.g. Teradata)
  • App must manage concurrent write operations
• Up to 16 EC2 instances at once
• File system must be cluster-aware (Not XFS, EX4, etc)

EBS Encryption

• create encrypted EBS volume, return:
  • encrypted data, snapshots, volumes from snapshot
• Encryption/Decryption transparently (you have nothing to do)
• Minimal impact on latency
• Encryption keys from KMS (AES-256)
• Copy unencrypted snapshot allow encryption
• snapshot encrypted volumes is encrypted

EFS - Elastic File System

• Manage NFS (network file system) - NFSv4.1 protocol - allow many EC2
• Allow EC2 instances in multiple AZ
• Highly available, scalable, expensive, pay per use
• Use cases: content management, web serving, data sharing, Wordpress
• Use security group to control access
• Compatible with Linux based AMI only
• POSIX file system (~Linux) has a standard file API
• file system scales automatically, pay-per-use, no capacity planning

Performance Mode (set at EFS creation time)

• General Purpose (default): latency sensitive use cases
• Max I/O: higher latency, throughput, highly parallel (big data, media processing)
• Throughput Mode
  • Bursting
  • Provisioned: set throughput regardless of storage size
  • Elastic: auto scales throughput based on workloads
    • Used for unpredictable workloads

Storage Classes

• Storage Tiers (lifecycle management feature - move file after N days)
  • Standard: for frequently accessed files
  • Infrequent access (EFS-IA): cost to retrieve files, lower price to store
  • Archive: rarely accessed data (few times each year), 50% cheaper
  • lifecycle policies to move files bw storage tiers
• Availability and durability
  • Standard: Multi-AZ, for prod
  • One Zone: for dev, backup, compatible with IA (EFS One Zone-IA)
• Over 90% is cost saving

EBS vs EFS Summary

EBS Volumes

• 1 instance for most case (except multi-attach io1/io2)
• locked at AZ level
• gp2: IO ⬆️ if disk size ⬆️
• gp3 & io1: IO and disk size isn't tie together

To migrate an EBS volume across AZ

• Take a snapshot
• Restore the snapshot to another AZ
• Don't use backup while app have high traffic since backup use IO

Root EBS Volumes of instances get terminated by default if EC2 instance gets terminate

EFS

• Mounting >=100 instances across AZ
• EFS share web files (WordPress)
• Only for Linux Instances (POSIX)
• higher price point than EBS
• Leverage Storage Tiers for save cost

Scalability & High Availability

Scalability

• Vertical
  • Common for non-distributed systems, e.g. database
  • e.g. RDS, ElastiCache
  • hardware limit exist
• Horizontal (= elasticity)

High Availability

• Goes with horizontal scaling
• Running app/system >= 2 data centers (AZ)
• Survive even a data center loss
• Passive -> e.g. RDS Multi AZ
• Active -> horizontal scaling

Load Balancer

Why Use a Load Balancer?

• Expose a single point of access (DNS) to your app
• Regular health checks to instances
• Provide SSL termination (HTTPS) for web
• Enforce stickiness with cookies

4 Types of Load Balancer on AWS

• Classic (v1, deprecated) - 2009 - CLB
  • HTTP, HTTPS, TCP, SSL (secure TCP)
• Application (v2) - 2016 - ALB
  • HTTP, HTTPS, WebSocket
• Network (v2) - 2017 - NLB
  • TCP, TLS (secure TCP), UDP
• Gateway - 2020 - GWLB
  • Operates at layer 3 (Network layer) - IP Protocol

Some Load Balancers can be setup as internal (private) or external (public) ELBs

Application Load Balancer (v2)

• Layer 7 (HTTP)
• multiple HTTP apps across machines (target groups)
• multiple apps on same machine (e.g. containers)
• Support HTTP/2, WebSocket, redirects (HTTP -> HTTPS)
• Routing tables to diff target groups
  • path in URL
  • hostname in URL
  • Query String, Headers
• Great for microservices & container-based app (e.g. Docker & Amazon ECS)
• In compare, need multiple ClassicLB per app
• Able to route to multiple target groups
• Health checks are at target group level
• Fixed hostname
• app servers don't see the IP of the client directly
  • header X-Forwarded-For: true IP of the client
  • Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

ALB Target Groups

• EC2 instances (e.g. Auto Scaling Group): HTTP
• ECS tasks: HTTP
• Lambda Functions: HTTP req -> JSON event
• IP Addresses: must be private IPs

Network Load Balancer (NLB)

• Layer 4: allow Forward TCP & UDP traffic to instance
• High performance (millions req/sec), low latency
• 1 static IP per AZ, support Elastic IP
  • helpful for whitelisting specific IP
• Target Groups:
  • EC2 instances
  • IP Address: must be private IPs
  • Add in front of ApplicationLB as combination
• Health checks support: TCP, HTTP, HTTPS

Gateway Load Balancer (GLB)

• Layer 3 (Network Layer): IP Packets
• 3rd party network virtual appliances
  • To analyze the traffic
• E.g. Firewalls, Intrusion Detection and Prevention Systems, payload manipulation
• Combines func
  • Transparent Network Gateway: single entry/exit for all traffic
  • LB: distributes traffic to virtual appliances
• GENEVE protocol on port 6081
• Target Groups
  • EC2 instances
  • IP Address

Sticky Sessions (Session Affinity)

• Make same client always redirect to the same instance behind the LB
• Works for CLB, ALB, NLB
• cookie has expiration date
• use case: make sure user doesn't lose session data
• May bring imbalance to the load over the backend EC2 instances

Cookie Names

• Application-based Cookies
  • Custom cookie
    • Generated by target
    • incl custom attr required by the app
    • name specified individually for each target group
    • don't use AWSALB, AWSALBAPP, AWSALBTG (it's reserved)
  • Application cookie
    • generated by LB
    • name: AWSALBAPP
• Duration-based Cookies
  • generated by LB
  • name: AWSALB for ALB, AWSELB for CLB

Cross-Zone Load Balancing

• Enabled:
  • each LB instance distributed same across AZ
• Disabled:
  • request is distributed in the instance of node
  • e.g. 2 AZ, 1AZ have 2 instance, another AZ have 10 instance, both AZ would have 50% load, so the diff is that instance in AZ-1 get 25% load for each, as for the instance in AZ-2 get 5% per each

ALB

• default enabled Cross-Zone LB, could change to disabled in Target Group setting
• no extra charge for cross AZ data
  • CLB as well

NLB & GLB

• default disabled Cross-Zone LB
• Pay extra if enabled

SSL/TLS Basics

• allow traffic be encrypted during transit
• SSL -> Secure Sockets Layer
  • Issued by Certificate Authorities (CA)
  • Have expired date set by you, need to renew
• TLS -> Transport Layer Security (newer, most case)
• Comodo, Symantec, GoDaddy, GlobalSign, etc
• LB use X.509 cert (SSL/TLS server cert)
• Manage use ACM (AWS Certificate Manager)
  • Support update your own cert
• HTTPS Listener
  • Require default cert
  • add optional list cert for diff domain
  • Clients can use SNI (Server Name Indication) to specify the hostname they reach
  • able to specify a secure policy to support older ver of SSL/TLS (legacy clients)

SNI (Server Name Indication)

• Solve: multiple SSL cert on 1 web server (to serve multiple website)
• require client to indicate the hostname of the target server in the initial handshake
• find correct cert and return default one
• newer, only support ALB, NLB, CloudFront
• for CLB to achieve the same, it need to run multiple CLB with multiple SSL cert, since 1 CLB only support 1 SSL cert

Connection Draining

• Feature Naming
  • Connection Draining: for CLB
  • Deregistration Delay: for ALB, NLB
• Time for completing "in-flight requests" while instance is de-registering or unhealthy
• Stop sending req to the draining EC2 instance
• time bw 1-3600 sec (default 300 sec)
• Allow to disabled (set value to 0)
• If request time is short -> set to a low value

Auto Scaling Group (ASG)

• Scale out for increased load, Scale in for decreased load
• Ensure min/max running instance setting
• Auto register instance to LB
• Re-create if terminated bc of bad (e.g. unhealthy)
• Free (only pay for EC2 instance)
• Could use stress Amazon Linux 2 to test, it could trigger the scaling metrics

ASG Attributes

• Launch Template
  • AMI + Instance Type
  • EC2 User data
  • EBS Volumes
  • Security Group
  • SSH Key Pairs
  • IAM roles for EC2
  • Network + Subnet info
  • LB info
• Min/Max/Initial Capacity
• Scaling Policies

CloudWatch Alarm & Scaling

• Possible to scale ASG based on CloudWatch alarm
• Alarm based on metric (e.g. Average CPU, or other custom metric)

Scaling Policies

• Dynamic Scaling
  • Target Tracking
    • Simple to setup
    • e.g. keep avg ASG cpu at 40%
  • Simple/Step Scaling
    • e.g. CloudWatch alarm is triggered, when > 40% +2 unit, when < 30% -1 unit
• Scheduled Scaling
  • Predict scaling based on known usage pattern
• Predictive Scaling
  • Continuously forecast load and schedule scaling ahead

Good Metrics to Scale

• CPU utilization: avg cpu across instances
• Request Count Per Target: num of req per EC2 instance
• Average Network In/Out
• Custom metric you pushed on CloudWatch

Scaling Cooldowns

• Happens after scaling activity, default 300s
• ASG won't launch/terminate during cooldown period
• Advice: Use ready-to-use AMI to reduce configuration to serve request faster and reduce cooldown time

#Amazon RDS + Aurora + ElastiCache

Amazon RDS

• RDS -> Relation Database Service
• Manage DB that use SQL as query language
• Allow creating DB in the cloud
• incl: Postgres, MySQL, Oracle, MariaDB, IBM DB2, Microsoft SQL, Aurora (AWS Proprietary SQL) ###Advantages of RDS
• Automated provising, OS patching
• Continuous backup, and restore to a timepoint
• Monitor dashboard
• Read replicas for read performance
• Multi AZ for Disaster Recovery
• Maintainance window for upgrade
• Scaling ability
• Storage backed by EBS Cons: Can't SSH to instance ###RDS Storage Auto Scaling
• Require setting Max storage threshold
• Trigger if
• Free storage < 10% of allocated storage
• Low storage last > 5mins
• 6hrs after last modification
• Useful for unpredictable workloads ###Read Replicas for read scalability
• Max 15 read replicas
• Allow within/across AZ or region
• ASYNC -> read are consistent
• Need to update connection string to leverage replicas ####Network Cost
• Happen when data goes from one AZ to another
• For RDS read replicas, same Region diff AZ don't have to pay ###RDS Multi AZ (Disaster Recovery)
• SYNC replication
• 1 dns name, automatic failover to standby
• increase availability
• no manual intervention
• not used for scaling
• Read Replicas can be setup as Multi AZ for Disaster Recovery
• 1AZ to multi AZ
• 0 downtime operations (no need to stop db)
• Just click the "modify"
• Step: snapshot -> new DB restore from snapshot -> synchronization bw 2 db ####RDS Custom
• For Oracle, Microsoft SQL server with OS and DB customization
• RDS: auto setup, operation, scaling of DB in AWS
• Access to underlying db and OS to allow
• configuration setting
• intall patches
• enable native feature
• access underlying EC2 instance with SSH or SSM Session Manager
• De-activate automation mode to perform you customization
• RDS vs RDS Custom
• RDS: db and OS managed by AWS
• RDS Custom: full admin access to db and OS ##Amazon Aurora
• Postgres and MySQL support Aurora DB
• AWS cloud optimized, 5x preformance improvement over MySQL, 3x over Postgres
• auto grow in 10GB, up to 256TB
• max 15 replicas, replica faster than MySQL (sub 10ms lag)
• Failover is instantaneous, High availability native
• Cost 20% more than RDS but more efficient ###Aurara High Availability & Read Scaling
• 6 copies of data across 3AZ:
• 4/6 needed for writes
• 3/6 needed for reads
• self healing by peer
• Storage is stripped across 100s of volumes
• 1 Aurora instance takes writes (master)
• Automated failover for master is < 30s
• max 15 read replicas
• Support cross region replication ####Aurora DB Cluster
• Writer Endpoint pointing to the master
• Support auto-scaling on top of each read replicas
• Reader Endpoint: Connection Load Balancing ####Features of Aurora
• Automatic fail-over
• Backup and Recovery
• Isolation & security
• Industry compliance
• Push-button scaling
• Automated Patching with 0 downtime
• Advanced monitoring
• Routine maintenance
• Backtrack: restore data at any point of time w/o using backups ##Aurora Advanced Concepts
• Custom Endpoints
• Define a subset of instances as a Custom Endpoint
• e.g. run analytical queries
• Reader Endpoint is mostly not used after defining Custom EP ###Global Aurora
• Aurora Cross Region Read Replicas:
• Useful for disaster recovery
• simple to put in place
• Aurora Global DB (recommend):
• 1 Primary Region (read/write)
• max 10 secondary (read-only) regions, replication lag < 1s
• max 16 read Replicas per secondary region
• Promoting another region (for DR) have recovery time objective (RTO) < 1min
• ⭐ Typical cross-region replication time < 1s ###Aurora Machine Learning
• Enable to add ML-based predictions to your app via SQL
• simple, optimized, secure integration bw Aurora and AWS ML services
• Support services
• Amazon SageMaker: use with any ML model
• Amazon Comprehend: for sentiment analysis
• Don't require ML exp
• Use cases: fraud detection, ads targeting, sentiment analysis, product recommendations ####Babelfish for Aurora PostgreSQL
• Allow Aurora Postgres to understand commands for MS SQL Server (e.g. T-SQL)
• Microsoft SQL server based app can work on Aurora Postgres
• No/little code changes, use same MS SQL Server client driver
• Same apps can be used after a migration of you db (using AWS SCT and DMS) ##RDS Backups
• Automated backups:
• Daily full backup of the db
• Transaction logs backup per 5 mins -> able to restore any time
• 1-35 days of retention, set 0 to disabled automated backups
• Manual DB Snapshots
• Retention backup as long as you want
• Note: stopped RDS db still cost for storage, if plan to stop for a long time, snapshot it to store then delete db, when needed restore from snapshot

##Aurora Backups

• Automated backups
• 1-35 days (can't be disabled)
• point in time recovery
• Manual db snapshots
• retention backup as long as you want

###RDS & Aurora Restore Options

• Restore a RDS/Aurora backup or snapshot create a new db
• Restore MySQL RDS db from S3
• Restore MySQL Aurora cluster from S3
• create backup using Percona XtraBackup
• Store on S3 ###Aurora db cloning
• Create a new Aurora db cluster from existing
• Faster than snapshot & restore
• Uses "copy-on-write" protocol
• initially new db use same data volume as the oringal db cluster (fast, no copy is needed)
• When updates to new db cluster data, additional storage is allocated and data is copied to be separated
• Very fast and cost-effective
• Useful to create a "staging" db from a "prod" db w/o impacting the prod db ###RDS & Auroraa Security
• At-rest encryption
• use AWS KMS, must be defined as lunch time
• If master isn't encrypted, replicas can't as well
• To encrypt, use db snapshot and restored as encrypted
• In-flight encryption: TLD-ready be default, use AWS TLS root cert client-side
• IAM Auth: IAM roles to connect to db (instead of username/pwd)
• Security Groups: Control Network access
• No SSH available except on RDS Custom
• Audit Logs can be enabled and sent to CloudWatch Logs for longer retention ###Amazon RDS Proxy
• Fully managed db proxy for RDS
• Allows apps to pool and share db connections
• Improving db efficiency by reducing the stress on db resources (e.g. CPU, RAM) and minimize open connections (and timeouts)
• Serverless, autoscaling, highly available (multi-AZ)
• Reduced RDS & Aurora failover time by 66%
• Supports RDS (MySQL, Postgres, MariaDB, MS SQL Server) and Aurora(MySQL, Postgres)
• Enforce IAM auth for db, and securely store credentials in AWS Secret Manager
• Never publicly accessible (access by VPC) ##ElastiCache
• Manage Redis or Memcached
• in-memoryy db with high performance, low layency
• Reduce load off of db for read intensive workloads
• Make app stateless
• AWS cover OS maintenance/patching, optimizations, setup, configuration, monitoring, failure recovery and backups
• Involves heavy app code changes

Redis

• Multi-AZ with auto-failover
• Read replicas to scale read and hvae high availability
• data durability using AOF persistence
• backup and restore feature
• support Sets and Sorted sets ####Memcached
• Multi-node for opartitioning of data (sharding)
• No high availability (replication)
• Non persistent
• Backup and restore (Serverless only)
• Multi-threaded architecture ###ElastiCache Cache Security
• Supports IAM auth for Redis
• Only used for AWS API-level security
• Redis AUTH
• pwd/token when create cluster (extra level security on top of security groups)
• Support SSL in flight encryption
• Sorted sets: uniqueness + ordering, e.g. Gaming Leaderboards
• Memcached
• Supports SASL-based auth (advanced) ####Patterns for ElastiCache
• Lazy Loading: all read data is cached, can be stale
• Write Through: add/update data in cache when write to db (no stale data)
• Session Store: temp session data in cache (TTL)

#Route 53 ##DNS Terminologies

• Domain Register: "Route 53", GoDaddy, etc
• Zone File: contains DNS records
• Name Server: resolves DNS queries (auth or non-auth)
• Top Level Domain (TLD): .com, .us ,etc
• Second Level Domain (SLD): google.com
• Root: the last dot after TLD

##Amazon Route 53

• highly available, scalable, managed and auth DNS
• Authoritative = you can update the DNS records
• able to check health of your resources
• only AWS services provide 100% availability SLA
• 53 means refer to traditional DNS port
• Support DNS record types
• A: hostname to IPv4
• AAAA: hostname to IPv6
• CNAME: hostname to hostname
• target domain must have A/AAAA
• Can't create it for the top node of a DNS namespace (Zone Apex)
• NS: Name servers for the hosted zone
• Control how traffic is routed for a domain
• advanced: CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, SRV ###Hosted Zones
• A container for records that define how to route traffic to a domain and its subdomains
• Public Hosted Zones
• Private Hosted Zones: private use like company use
• $0.5 per month per hosted zone

####CNAME vs Alias

• AWS Resources(LB, CloudFront) expose an AWS hostname
• CNAME:
• hostname -> hostname
• ONLY for NON root domain (e.g. something.domain.com)
• Alias:
• hostname -> AWS Resource
• Works for BOTH root and non-root domain
• Free
• Native health check
• Automatically recognize changes in the resource's IP addresses
• Always of type A/AAAA for AWS resources
• can't set TTL (be auto set)
• CANT be set for an EC2 DNS name ##Routing Policies
• the Routing here means respond to DNS queries, not traffic
• Policies incl:
• Simple
• Weighted
• Failover
• Latency based
• Geolocation
• Multi-Value Answer
• Geoproximity(Route 53 traffic flow feature) ###Routing Policy - Simple
• typically, route traffic to 1 resource
• specify >=1 values in same record
• if return multipled, random pick 1
• if Alias enabled, specify 1 AWS resource
• Not associated with Health Checks ###Routing Policy - Weighted
• Control the % of requests for each resource
• assign each record relative weight:
• traffic(%) = weight for a record / sum(all weights for all records) )
• wieghts sum don't have to be 100
• DNS records -> same name and type
• Enable Health Checks
• LB bw regions, testing new app ver
• weight 0 = stop sending triffic ##Routing Policy - Latency
• based on location latency
• Common to use ##Routing Policy - Health
• monitor:
• endpoint (app, server, other AWS resource)
• other health check (Calculated Health Check)
• CloudWatch, Alarms (full control)
• helpful for private resources
• Integrated with CW metrics
• ~ 15 global health checkers for endpoint health
• Threshold: 3
• interval: 30 sec (lower -> more cost)

• “

  18% report healthy -> Route 53 consider Healthy, otherwise Unhealthy

• can choose locations
• Pass only respond 2xx and 3xx
• Allow set pass/fail based on text in first 5120 bytes of the res
• Configure router/firewall to allow request from Health Checkers
• Calculated Health Checks
• condition: AND, OR, NOT
• max 256 health checkers
• specify the pass rate of child health checks
• Privated Hosted Zone
• Route 53 can't access Private VPC
• Workaround: CloudWatch Metric + CloudWatch Alarm ##Routing Policy - Failover
• Have Primary and Secondary
• When Primary unhealthy the traffic would switch to Secondary ##Routing Policy - Geolocation
• Diff from Latency-based
• Based on user location
• Specify by continent, country, state
• Should set default record
• Use cases: web localization, restrict content distribution, LB
• Can add Health Check ##Routing Policy - Geoproximity Routing
• Based on User & Resources
• Able to shift more traffic to resources based on the defined bias
• Specify "bias" values to change size bw region:
• Expand (1-99): more traffic
• Shrink (-1 - -99): less traffic
• Resources can be:
• AWS resources (specify AWS region)
• Non-AWS resources (specify Lat and Lng)
• Need Route 53 Traffic Flow (advanced) ##Routing Policy - IP-based
• Based on client's IP address
• Provide a list of CIDRs for clients and corresponding ep/locations
• Use cases: Optimize performance, reduce network costs ##Routing Policy - Multi-Value
• route to multiple resources
• Able Health Checks
• Max 8 healthy records for each Multi-Value query
• not a substitute of ELB ##Hybrid DNS
• default: Route 53 Resolver auto answer DNS query for:
• Local domain names for EC2 instances
• Records in Private Hosted Zones
• Records in Public Name Servers
• Hybrid DNS: resolve DNS query bw VPC and your networks (other DNS Resolvers) ###Resolver Endpoints
• Inbound Endpoint: resolve domain names for AWS resources and records in Private Hosted Zones
• Outbound Endpoint: fowards DNS query to your DNS Resolvers

#Classic Solutions Architecture Discussions ##Instantiating Applications quickly

• EC2 Instances:
• Golden AMI: Install apps, OS dep, etc, beforehand and launch EC@ from the Golden AMI
• Bootstrap using User Data: for dynamic configuration use User Data scripts
• Hybrid: max Golder AMI + User Data (Elastic Beanstalk)
• RDS db:
• Restore from a snapshot: db have schema and data ready
• EBS Volumes:
• Restore from a snapshot: disk ready be formatted and have data

##Beamstalk

• Developer centric view of deploying an app on AWS
• Managed service
• Auto handles capacity provisioning, LB, scaling, health monitoring, instance config
• Dev only focus on app code
• Full control over configuration
• Free but pay for underlying instances
• Components
• Env:
• 1 app ver at a time
• Tiers: Web Server Env Tier & Worker Env Tier
• Enable multiple env (dev, test, prod)
• Deployment Modes
• Single Instance: for dev
• High Availability w/ LB: for prod ###Worker Tier
• Scale based on the num of SQS messages
• Able to push msgs to SQS queue from another Web Server Tier

#S3 ###Use cases

• backup & storage
• Disaster Recovery
• Archive
• Hybrid Cloud storage
• Application hosting
• Media hosting
• Data lakes & big data analytics
• Software delivery
• Static web ##Buckets
• store obj(files)
• Defined at region level
• Naming:
• Shared Global Namespace: globally unique name (across regions all accounts)
• Account Regional Namespace: allows reuse of the same bucket name across regions
• Naming constraints:
• No uppercase, underscore
• Not IP, not prefix "xn--", not suffix "-s3alias"
• Must start with lowercase letter or num ##Objects
• Objects (files) have a Key
• Key is the FULL path = prefix + object name
• No concept of directories in buckets, just key contain slashes("/")
• cont.
• Max object size: 50TB
• upload > 5GB must use multi-part upload
• Metadata (list of text key/value pairs, system/user metadata)
• Tags (unicode key/value pair up to 10): for security/lifecycle
• Version ID (if enabled versioning) ##S3 Security
• User-based:
• IAM Policies: define allow API calls for user from IAM
• Resource-based:
• Bucket Policies: bucket wide rules from S3 console, allow cross account
  • JSON based policies
    • Resources: buckets and objs
    • Effect: Allow/Deny
    • Actions: Set of API to Allow/Deny
    • Principal: account/user to apply to
  • Usecase:
    • Grant public access to the bucket
    • Force obj to be encrypted at upload
    • Grant access to another account (Cross Account)
• Object Access Control List (ACL): finer grain (can disable)
• Bucket Access Control List (ACL): less common (can disable)
• Note: IAM principal can access S3 obj if
• User IAM permission ALLOW or resource policy ALLOW
• AND no explicit DENY
• Encryption: encrypt obj in S3 using encryption keys

###S3 Static Website Hosting

• S3 host the static web and the url will be:
• http://${bucket-name}.s3-website${-/.}${aws-region}.amazonaws.com
• 403 Forbidden error: public policy need to allow public read ###S3 Versioning
• Enabled at bucket level
• Same key overwrite would change version
• Pros:
• Protect uninteneded delete (able to restore)
• Easy rollback to previous ver
• Suspend versioning won't delete previous ver ###S3 Replication (CRR, SRR)
• Must enable Versioning in both source & destination
• Name:
• CRR: Cross Region Replication
• usecase: compliance, lower latency, replication across accounts
• SRR: Single Region Replication
• usecase: log aggregation, live replication bw prod and test accounts
• Bucket can in diff account
• Copy is asynchronous
• Must add IAM permission to S3
• Only new obj would be replication after enable replication
• Have Batch replication func
• Delete marker can be replicated from source to destination
• Delete w/ ver id are not replicated
• No "chaining" of replication
• e.g. 1 rep into 2, 2 rep into 3, obj in 1 won't in 3 ###S3 Durability & Availability
• Durability: High durability, and same for all storage class
• Availability: various dep on storage class ##S3 Standard - General Purpose
• 99.99% Availability
• For frequently accessed data
• Low latency & high throughput
• Sustain 2 concurrent facility failure
• Use case: Big data analytic, mobile/game app, content distribution ##S3 Standard Infrequently Accessed
• For less frequent but rapid access
• Lower cost than S3 standard
• Availability: 99%
• Use case: disaster recovery, backups
• One Zone Infrequently Access (AWS One Zone IA)
• High durability in 1 AZ, but data lost when AZ is destroyed
• Availability: 95%
• Use case: Storing secondary backup copy of on-premise data or data you can recreate

##S3 Glacier

• Low cost obj stor for archiving/backup
• Price: storage + retrieval cost
• 3 Types of Glacier
• Instant Retrieval
• Millisecond retrieval, great for data access once in Q
• Min store dur 90days
• Flexible Retrieval
• Expedited: 1-5 minutes
• Standard: 1-5 hrs
• Bulk: 5-12hrs (free)
• Min store dur 90 days
• Deep Archive
• Standard: 12hrs
• Bulk: 48hrs
• Min store dur 180days

##S3 Intelligent Tiering

• Small monthly monitoring + auto-tiering fee
• Auto move bw tier based on usage
• No retrieval fee
• Tiers:
• Auto
• Frequent Access (default)
• Infrequent Access: obj not accessed 30days
• Archieve Instand Access: obj not accessed 90days
• Optional
• Archieve Access: config for 90-700+days
• Deep Archieve Access: 180-700+days

##S3 Express One Zone

• High performance, 1 AZ storage class
• Obj stored in directory bucket (bucket in 1 AZ)
• 100,000req/s w/ <10millisecond latency
• 10x better performance + 50% less cost than S3 Standard
• High Durability & Availability
• Co-locate storage and resource in same AZ to reduce latency
• Use case: latency sensitive app, data intensive app, AI/ML training, financial modeling, media processing

#Advanced AWS S3 ###Analytics - Storage Class Analysis

• Help you decide when to transition obj to the right storage class
• Recommend for Standard and Standard IA
• NOT work for One-Zone IA or Glacier
• Report update daily
• 24-48hrs have data analysis
• Good 1st step to put together Lifecycle Rules ###S3 - Requester Pays
• General: bucket owner pay for S3 storage + data transfer costs
• W/ Requester Pays buckets:
• bucket owner pay Storage
• Requester pay Networking Cost (data transfer cost)
• Use case: When sharing large datasets w/ other accounts
• Requester must authed in AWS (can't anonymous) ###S3 Event Notifications
• IAM Permissions
• Put below policies as Event Notification targets
• SNS Resource (Access) Policy
• SQS Resource (Access) Policy
• Lambda Resource Policy
• All events end up in EventBridge
• by setting rules can send to > 18 AWS services as destinations
• Advanced filtering opt w/ JSON rules (metadata, obj size, name, etc)
• Multiple destinations
• EventBridge Capabilities: Archive, Replay Events, Reliable delivery

###S3 Performance

• Baseline
• Auto scales to high req rates, latency 100-200ms
• No limits to num of prefixes in a bucket
• Multi-Part upload:
• Recommend for file > 100MB, must when > 5GB
• Parallelize uploads(speed up transfer)
• Transfer Acceleration
• Increase transfer speed by transferring file to AWS adge location(private AWS faster) then forward to S3 bucket in target region
• Compatible w/ multi-part upload
• Byte-Range Fetches
• Parallelize GETs by requesting specific byte ranges
• Better resilience in case of failures
• Use cases:
• speed up downloads (separate to multi parts)
• retrieve only partial data (e.g. only header of the web) ###S3 Batch Operations
• Bulk operations on existing S3 obj w/ 1 request, e.g.:
• Modify obj metadata & properties
• Copy obj bw S3 buckets
• Encrypt un-encrypted obj
• Modify ACLs, tags
• Restore obj from S3 Glacier
• Invoke Lambda func perform custom action on each obj
• A job consist of a list of obj, the action to perform, optional parameters
• Manages retries, track progress, send completino notification, generate reports, etc
• S3 Inventory -> get obj list report -> Athena query & filter list -> S3 Batch Operations -> Processed Obj ###S3 - Storage Lens
• To understand, analyze, optimize storage across AWS Org
• Apply all kinds of best practices
• Aggregate data for Org, specific accounts, regions, buckets, or prefixes
• Default dashboard to create your dashboards
• Configured to export metric daily to an S3 bucket (CSV, Parquet)

#Amazon S3 Security

• 4 methods of encryption obj in S3 bucket
• Server Side Encryption (SSE)
• Amazon S3 Managed Keys (SSE-S3) Default
• KMS Keys stored inAWS KMS (SSE-KMS)
• Customer Provided Keys (SSE-C)
• Client Side Encryption

##SSE-S3

• keys managed/owned by AWS
• Type: AES-256
• set header: "x-amz-server-side-encryption": "AES256"
• Default for new buckets & obj ##SSE-KMS (Key Management Service)
• Pros: user control + audit key usage w/ CloudTrail
• set header: "x-amz-server-side-encryption": "aws:kms"
• Limitation
• Impact by KMS limit
• upload -> GenerateDataKey KMS API
• download -> Decrypt KMS API
• Count KMS quota per second (Can rqe quota increase w/ Service Quotas Console)
• Custom KMS require extra cost
• New type DSSE-KMS: double encryption based on KMS ##SSE-C
• S3 NOT store the encryption key you provide
• require HTTPS
• Encryption key must in HTTP headers for every req
• Could only be used in CLI, can't in console ##Client side Encryption
• use lib e.g. Amazon S3 Client-Side Encryptino Library
• Encrypt before sneding to S3
• Decrypt after retrieving from S3 ###S3 Encryption in transit (SSL/TLS)
• S3 exposes 2 endpoints:
• HTTP: non encrypted
• HTTPS: encryption in flight
• Recommanded
• must for SSE-C
• Most client default
• Force Encryption in Transit Policy: aws:SecureTransport ###MFA Delete
• Versioning must be enabled on the bucket
• Only root account can enable/disable MFA Delete
• only allowed to enable with CLI
• MFA required to
• Permanently delete an object version
• Suspend Versioning on the bucket ###S3 Pre-signed URLs
• Generate using S3 Console, AWS CLI or SDK
• Expiration:
• S3 Console: 1min - 12hrs
• AWS CLI: config with --expires-in param, default 3600s, max 168hrs
• Inherit the permissions of the user that generate the url for GET/PUT
• Use cases:
• Allow only logged-in users to download a premium video from your S3 bucket
• Allow users to download files by creating URLs dynamically
• Allow temp a user to upload to a precise location ##S3 Glacier Vault Lock
• Adopt a WORM (Write Once Read Many) model
• Create a Vault Lock Policy
• Lock the policy for future edits (no longer change/delete)
• Helpful for compliance and data retention

###S3 Object Lock

• Require versioning enabled
• Adopt WORM
• Block obj ver delete for a specified time
• Retention mode - Compliance
• obj ver can't be overwritten/delete by any user (incl root)
• Retention mode can't be changed and period can't be shorten
• Retention mode - Governance
• Most user can't, some user can -> change/delete
• Retention Period: protect obj for a fixed period, can extendend
• Legal Hold:
• Protect obj indefinitely
• Can be placed/removed w/ s3:PutObjectLegalHold IAM permission ##S3 Access Points
• Simplify security management for S3 Buckets
• Each AP has
• its own DNS name (internet origin or VPC origin)
• AP policy: manage security at scale

##S3 Object Lambda

• use to change obj before it is retrieved by the called app
• Only 1 S3 bucket is needed, then create S3 AP, S3 Obj Lambda AP
• Use cases:
• Redacting info for analytics or non-prod env
• Converting across data formats, e.g. XML to JSON
• Resizing and watermarking images on the fly using caller-specific details ##CloudFront
• Content Delivery Network (CDN)
• Improves read performance, cached content at the edge
• Improves UX
• Hundreds of Points of Presence globally (edge locations, cahces)
• DDoS protection, integration with Shield, AWS Web App Firewall ###CloudFront - Origins
• S3 bucket
• Secured using Origin Access Control (OAC)
• VPC Origin
• For app hosted in VPC private subnets
• Private ALB/NLB/EC2 instances
• Custom Origin (HTTP)
• S3 web
• public HTTP backend ###CloudFront vs S3 Cross Region Replication
• CloudFront
• Global Edge Network
• cached for a TTL (maybe a day)
• Great for static content must be avail everywhere
• S3 Cross Region Replication
• Must be setup for each region
• Files update in real-time
• Read only
• Great for dynamic contents need low latency in few region ###CloudFront Geo Restriction
• Restrict access of your distribution
• Allowlist: allow if in countries in approved list
• Blocklist: Prevent if in the banned countries
• "country" is determined using a 3rd party Geo-IP db
• Use case: Copyright Laws to control access to content

###CloudFront Cache Invalidations

• CloudFront will only get new content after TTL expired
• -CloudFront Invalidation: To force entire/partial cache refresh
• Invalidate all files(*) or a specific path

###Unicast IP vs Anycast IP

• Unicast IP: 1 server holds 1 IP address
• Anycast IP: all servers hold the same IP address, and the client is routed to the nearest one

##Global Accelerator

• Leverage AWS internal network to route to your app
• 2 Anycast IP are created for your app, and it would send traffic directly to Edge Locations
• Works w/ Elastic IP, EC2 instances, ALB, NLB, public or private
• Consistent Performance
• route to lowest latency + fast regional failover
• Can client cache
• Internal AWS network
• Health Checks
• Helps make your app global (failover < 1min for unhealthy)
• Great for disaster recovery
• Security
• Only 2 external IP need to be whitelisted
• DDoS protection by AWS Shield
• Improve performance for a wide range of apps over TCP/UDP
• Proxying packets at the edge to app in >=1 AWS Regions
• Good for:
• non-HTTP use cases, e.g. gaming (UDP), IoT(MQTT), Voice over IP
• HTTP require static IP address
• HTTP require fast regional failover

#AWS Storage Extras ##Amazon FSx - Overview

• Launch 3rd party high-performance file system on AWS
• Fully managed service

###FSx for Windows (File Server)

• Supports SMB protocol & Windows NTFS
• Microsoft Active Directory integration, ACLs, user quotas
• Can be mounted on Linux EC2 instances
• Supports Microsoft's Distributed File System (DFS) Namespaces
• Storage Options: SSD, HDD
• Support access from on-premises infra (VPN, Direct Connect)
• Support Multi-AZ
• Data is backup daily to S3

###FSx for Lustre

• Lustre = Linux + cluster
• Parallel distributed file system, for large scale computing
• Use case: Machine Learning, High Performance Computing (HPC)
• Video Processing, Financial Modeling, Electronic Design Automation
• Storage Options: SSD, HDD
• Seamless integration w/ S3
• Can "read" S3 as a file system (through FSx)
• Can write the output of the computations back to S3 (through FSx)
• Can be used from on-premises servers (VPN, Direct Connect)

###FSx File System Deployment Options

• Scratch File System
• Temp storage
• Data is not replicated (not persist if file server fails)
• High burst (6x faster)
• Usage: short-term processing, optimize costs
• Persistent File System
• Long-term storage
• Data is replicated within same AZ
• Replace failed files within mins
• Usage: long-term processing, sensitive data

###FSx for NetApp ONTAP

• File System compatible w/ NFS, SMB, iSCSI protocol
• Move workload running on ONTAP/NAS to AWS
• Works w/:
• Linux
• Windows
• MacOS
• VMware Cloud on AWS
• Amazon Workspaces & App Stream 2.0
• Amazon EC2, ECS and EKS
• Storage shrinks/grows auto
• Snapshots, replications, low-cost, compression and data de-duplication
• Point-in-time instantaneous cloning (helpful for testing new worklaods)

###FSx for OpenZFS

• Compatible w/ NFS
• Move workload on ZFS to AWS
• Works w/:
• Linux
• Windows
• MacOS
• VMware Cloud on AWS
• Amazon Workspaces & AppStream 2.0
• Amazon EC2, ECS and EKS
• 1million IOPS w/ <0.5ms latency
• Snapshots, compression, low-cost
• Point-in-time instantaneous cloning (helpful for testing new worklaods) ##Hybrid Cloud for Storage
• Hybrid cloud: Partial infra on cloud, partial infra on-premises
• For:
• Long cloud migration
• Security requirement
• Compliance requirement
• IT strategy
• Use Strorage Gateway to achieve it ###AWS Storage Gateway
• Bridge bw on-premises and cloud data
• Use cases:
• disaster recovery
• backup & restore
• tiered storage
• on-premises cache & low-latency files access
• Types of Storage Gateway
• S3 File Gateway
• Volume Gateway
• Tape Gateway

###S3 File Gateway

• Configured S3 buckets are accessible using NFS and SMB protocol
• Most recently used data is cached in the file gateway
• Support S3 serious
• Transition to S3 Glacier using a Lifecycle Policy
• Bucket access using IAM roles
• SMB protocol has integration w/ Active Directory (AD) for user auth

###Volume Gateway

• iSCSI protocol backed by S3
• Backed by EBS snapshots for help restore on-premises volumes
• Cached volumes: low latency to recent data
• Stored Volumes: entire dataset is on premise, scheduled backup to S3

###Tape Gateway

• Backup process using physical tapes, same process but in cloud
• Virtual Tape Library (VTL) backed by S3 and Glacier
• iSCSI interface
• Works w/ leading backup software vendors ###AWS Transfer Family
• Fully managed service for file transfer in/out of S3 or EFS using FTP protocol
• Supported protocol
• FTP
• FTPS (FTP +SSL)
• SFTP (Secure FTP)
• Managed infra, scalable, reliable, highly available (multi-AZ)
• Pay per provisioned ep per hour + data transfers in GB
• Store users' credentials within service
• Integrate w/ existing auth systems
• Usage: sharing files, public datasets, CRM, ERP ###AWS DataSync
• Move large data to/from
• On-premises/other cloud to AWS - Require agent
• AWS to AWS (diff storage services)
• Can Synchronize to: S3, EFS, FSx
• Replication tasks scheduled hourly/daily/weekly
• File permission and metadata are preserved (NFS POSIX, SMB, etc)
• 1 agent task can use 10Gbps, with bandwidth limit

###All Storage Options Comparison

• S3: Object Storage
• S3 Glacier: Object Archival
• EBS volumes: Network storage for 1 EC2 at a time
• Instance Storage: Physical storage for EC2 (high IOPS)
• EFS: Network File System for Linux, POSIX file sys
• FSx for Lustre: High performance computing Linux file sys
• FSx for NetAPP ONTAP: High OS Compatibility
• Snowcone/Snowball/Snowmobile: to move large amount of data to the cloud, physically

#Decoupling applications: SQS, SNS, Kinesis, Active MQ ####Messaging

• Synchronous communications: app to app
• Problematic if sudden spikes of traffic
• Asynchronous/Event based: app to queue to app
• To decouple app:
• SQS: queue model
• SNS: pub/sub model
• Kinesis: real-time streaming model

##Amazon SQS ###Standard Queue

• To decouple app
• Attr:
• unlimited throughput
• Default retention of msg: 4days, max 14days
• Low latency (<10ms)
• Limit of 1024KB per msg
• Can have duplicate msg (>=1 delivery)
• Can have out of order msg

###Producing Messages

• Produce using SDK (SendMessageAPI)
• Persist in SQS until a conumser delete ###Consuming Messages
• Poll SQS for msg, receive max 10 msg at a time
• Process msgs (e.g. insert msg into an RDS db w/ order)
• Delete msg using DeleteMessageAPI after process ###SQS Security
• Encryption
• In-flight encryption using HTTPS API
• At-rest encryptino using KMS keys
• Client-side encryption
• Access Control: IAM policy to regulate SQS API
• SQS Access Policies
• For cross-account assess to SQS queues
• For allowing other services to write to an SQS queue ###SQS Message Visability Timeout
• After msg is polled by a consumer -> turn invisible to other consumers
• Default timeout is 30s, which means 30s to be processed
• After timeout and if msg still exist (not deleted), turn visible again to other consumer
• Consumer call ChangeMessageVisibility API to extend the timeout
• visibility timeout too
• high -> crash would cause long time to re-process
• low -> get depulicates ###Long Polling
• Optional to wait for msg to arrive if msg not in the queue
• Decrease num of API calls made to SQS while increase the efficiency and reducing latency of app
• Wait time bw 1s to 20s
• More preferable to Short Polling
• Enabled at the queue level or API level using WaitTimeSeconds

###FIFO Queue

• Limited throughput: 300msg/s w/o batching, 3000 msg/s w/ batching
• 1 send capability (by removing duplicates w/ Deduplication ID)
• Ordering by Message Group ID (all msgs in same group are ordered), must parameter
• Queue name suffix need to incl ".fifo" ##Amazon SNS
• Event producer only send msg to 1 SNS topic
• An many event receivers (subscriptions) listen to the SNS topic notifications
• How to publish
• Topic Publish (w/ SDK)
• create topic -> create subscription -> publish topic
• Direct Publish (w/ mobile apps SDK)
• create platform app -> create platform endpoint -> publish platform endpoint -> works w/ Google GCM, Apple APNS, Amazon ADM, etc

###SNS - Security

• Encryption:
• in-flight HTTPS API
• at-rest KMS keys
• Client side
• Access Controls: IAM policies to regulate to SNS API
• SNS Access Policies
• Cross account access to SNS topic
• Useful for allowing other services to write to an SNS topic

##SNS + SQS: Fan Out

• Push 1 in SNS, receive in all SQS queues that subscribes
• Fully decoupled, no data loss
• SQS allows for: data persistence, delayed processing and retries of work
• Ability to add more SQS subscribers over time
• Need SQS queue access policy allow SNS to write
• Cross-Region Delivery: works w/ SQS Queues in other regions
• Use case:
• S3 Events to multiple queues:
• In general: Same combination of event type + prefix can only have 1 S3 Event rule
• Use fan out to enable same S3 event to many SQS queues
• SNS to S3 through Kinesis Data Firehouse
• FIFO Topic:
• SNS FIFO + SQS FIFO
• Silimar feature as SQS FIFO
• SQS Standard and FIFO queues as subscribers
• Limited throughput
• Message Filtering
• JSON policy to filter msg send to SNS topic's subs
• no filter policy -> receive every msgs ##Kinesis Data Streams
• Collect and store streaming data in real-time
• Retention max 365 days
• Able to reprocess data by consumers
• Data can't be deleted from Kinesis until expires
• Data up to 10MiB, but most case small
• Guarantee ordering for data w/ same Partition ID
• At-rest KMS 🔐, in-flight HTTPS 🔐
• Kinesis Producer Library (KPL) to write an optimized producer app
• Kinesis Client Library (KCL) to write an optimized consumer app
• Capacity Modes
• Provisioned mode:
• Choose num of shards
• each shard get 1MB/s in, 2MB/s out
• Able to scale manually to shards
• Pay per shard per hr
• On-demand mode:
• No need to provision/manage capacity
• Default capacity provisioned
• Scales auto based on throughput peak in last 30days
• Pay per stream per hr & data in/out per GB ##Amazon Data Firehouse
• Fully managed service
• Custom HTTP endpoint
• Auto scaling, serverless, pay for usage
• Near Real-Time w/ buggering capability based on size/time
• Supports CSV, JSON, Parquet, Avro, Raw Text, Binary Text
• Conversions to Parquet/ORC, compression with gzip/snappy
• Custom data transformation w/ AWS Lambda ##Amazon MQ
• Traditinoal app run on-premises use open protocols e.g. MQTT, AMQP, STOMP, Openwire, WSS
• Migrating to the cloud, use Amazon MQ so don't need to re-engineering the app to use SQS/SNS
• A Managed broker service for RabbitMQ + ActiveMQ
• Don't scale as much as SQS/SNS
• Runs on servers, can run multi-AZ w/ failover
• Have both queue feature(~SQS) and topic feature (~SNS)

#Containers on AWS: ECS, Fargate, ECR & EKS ##Amazon ECS (Elastic Container Service)

• EC2 Launch Type
• Launch Docker containers on AWS = Launch ECS Tasks on ECS Clusters
• Must provision & maintain the infra (EC2)
• Each EC2 must run the ECS Agent to register in the ECS Cluster
• AWS do start/stop container
• Fargate Launch Type
• Don't provisino the infra (no EC2)
• All serverless
• Only create task definitions
• AWS run ECS tasks based on CPU/RAM need
• To scale -> increase num of tasks

###IAM Roles for ECS

• EC2 Instance Profile (EC2 Launch Type only)
• Used by ECS agent
• Make API calls to ECS
• Send container log to CloudWatch Logs
• Pull Docker image from ECR
• Reference data in Secret Manager or SSM parameter store
• ECS Task Role
• Allow diff role per task
• Diff roles link to diff services

###ECS - Load Balancer Integrations

• ALB: support for most use cases
• NLB: recommend only for high throughput, high performance use cases, and pair w/ AWS Private Link
• CLB: support, not recommend

###ECS - Data Volumes (EFS)

• For data persistence -> EFS file sys onto ECS tasks
• Tasks running in diff AZ share same data in the EFS
• Best: Fargate + EFS = Serverless
• Use case: persistent multi-AZ shared storage for containers
• Note: S3 CANT be mounted as a file system ##ECS Service Auto Scaling
• Auto increase/decrease the num of ECS tasks
• Using AWS Application Auto Scaling
• svc avg CPU utilization
• svc avg Memory utilization - Scale on RAM
• ALB req count per target
• Target Tracking: target of CloudWatch metric
• Step Scaling: CloudWatch Alarm
• Scheduled Scaling
• ECS Service Auto Scaling(task level) != EC2 Auto Scaling (EC2 instance level)
• Fargate auto scaling is easier bc serverless

###EC2 Launch Type

• Accommodate by adding underlying EC2 instances
• Auto Scaling Group Scaling
• Scale ASG based on CPU util
• Add EC2 over time
• ECS Cluster Capacity Provider
• Auto scale for ECS tasks
• Capacity Provider paired w/ Auto Scaling Group ##Amazon ECR
• ECR = Elastic Container Registry
• Store & manage Docker images on AWS
• Private repo, and Public repo (Amazon ECR Public Gallery)
• Fully integrated w/ ECS, backed by S3
• Access is controlled by IAM
• Support image vulnerability scanning, versioning, image tags, image lifecycle, etc
• Tip: Storing Docker images -> ECR

##Amazon EKS

• EKS = Elastic Kubernetes Service
• Support Ec2 for worker nodes, or Fargate for serverless containers ###EKS Data Volumes
• Need specify StorageClass manifest on EKS Cluster
• Container Storage Interface (CSI) compliant driver
• Support for: EBS, EFS (works w/ Fargate), FSx for Lustre, FSx for NetApp ONTAP

#Serverless

• Serverless does NOT mean no servers, it means you don't manage/provision/see them
• Incl in AWS
• Lambda
• DynamoDB
• Cognito
• API Gateway
• S3
• SNS & SQS
• Kinesis Data Firehose
• Aurora Serverless
• Step Functions
• Fargate

##Lambda

• Virtual Functions, no servers to manage
• Limited by time: short execution up to 15mins
• Run on-demand
• Auto scale ###Benefits of Lambda
• Pricing:
• Pay per req and compute time
• Free tier 1M Lambda req + 0.4M GBs compute time
• Monitor w/ CloudWatch
• Easy to get more resources per func (max 10GB RAM)
• Increase RAM will improve CPU and network
• Language support
• Lambda Container Image:
• must w/ Lambda Runtime API
• ECS/Fargate is preferred for running arbitrary Docker images ###Lambda Limits ####per region
• Execution
• Memory allocation: 128MB - 10GB (1MB increments)
• Max executeion time: 15mins
• env vars: 4KB
• Disk capacity in function container (in /tmp): 512MB to 10GB
• Concurrency executions: 1000 (can increase)
• Deployment
• size (compressed .zip): 50MB
• uncompressed size(code + dep): 250MB
• Can use /tmp to load files at startup
• Size of env vars: 4KB

###Lambda Concurrency & Throttling

• Reserved concurrency at the function level (=limit)
• over limit -> trigger Throttle
• Throttle behavior:
• synchronous invocation -> return ThrottleError 429 (attempt again for up to 6hrs)
• asychronous invocation -> return auto then DLQ
• Open support ticket for higher limit
• Concurrency Issue: if no reserve(= limit) concurrency, 1 func throttle could make other func throttle as well

####Cold Starts & Provisioned Concurrency

• Cold Start:
• New instance run init -> if init is large take long time -> first req have higher latency
• Provisioned Concurrency
• Concurrency is allocated before the func is invoked (in advance)
• Cold start never happens, all invocation have low latency
• Application Auto Scaling can manage concurrency (schedule or target utilization)
• Note: Cold start in VPC be reduced