Module 1 – Elastic Load Balancing
Module 2 – Auto Scaling and High-Availability
Module 3 – Containers and Images
Module 4 – AWS Lambda
Module 5 – Event-driven Architectures
Module 6 – Amazon API Gateway, AWS AppSync, and AWS X-Ray
Module 7 – Serverless Authentication with Amazon Cognito
Module 8 – AWS CloudFormation and Infrastructure-as-Code Services
Module 9 – AWS Elastic Beanstalk
Module 10 – AWS Systems Manager
Module 11 – Amazon SQS and Amazon SNS
Module 12 – Amazon Kinesis
Module 13 – Amazon MSK and Amazon MQ
Module 14 – Amazon Step Functions and AWS Batch
Module 15 – Application and Network Caching
Module 16 – Miscellaneous Services

Module 1 – Elastic Load Balancing

Reviewing AWS Global Infrastructure

AWS infrastructure is organized at several levels of abstraction:

Regions: The highest-level geographic grouping. Currently 31+ active geographic regions. Each region provides full redundancy and connectivity to the AWS network and the internet.
Availability Zones (AZs): Fully isolated partitions within a region, each with separate power, networking, and internet connectivity. Typically at least 3 AZs per region. Note: The actual data centers referenced by an AZ name (e.g., us-east-1a) can differ per account. Use AZ IDs to reference the same physical data center across accounts.
Edge Locations: AWS partners with thousands of telecom carriers worldwide to host edge locations for caching and content delivery.

graph TD
    AWS[AWS Global Network]
    AWS --> R1[Region: us-east-1]
    AWS --> R2[Region: eu-west-1]
    R1 --> AZ1[AZ: us-east-1a]
    R1 --> AZ2[AZ: us-east-1b]
    R1 --> AZ3[AZ: us-east-1c]
    R1 --> EL[Edge Locations]
    AZ1 --> DC1[Data Centers]
    AZ2 --> DC2[Data Centers]
    AZ3 --> DC3[Data Centers]

Elastic Load Balancing (ELB) Introduction

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets (EC2 instances, containers, IP addresses, Lambda functions) across multiple Availability Zones.

Key properties:

Managed service – AWS handles the operational burden
Custom DNS – Point your DNS to the load balancer. Use an alias record in Route 53 to reference the ELB
Health checks – ELBs monitor back-end targets and only route to healthy ones
SSL/TLS termination – Handle cryptographic operations at the load balancer level
Best practice: Create separate tiers for public and private network traffic

There are three modern (v2) ELB types plus a legacy Classic Load Balancer:

Type	OSI Layer	Protocols	Use Case
ALB	Layer 7 (Application)	HTTP, HTTPS, HTTP/2, WebSocket	Smart routing, containers, microservices
NLB	Layer 4 (Transport)	TCP, TLS, UDP, TCP_UDP	High performance, static IPs
GWLB	Layer 3 (Network)	GENEVE (port 6081)	Security appliances, intrusion detection

Application Load Balancers (ALB)

ALBs operate at Layer 7 of the OSI model and are considered “smart” load balancers.

Key characteristics:

Supports routing based on: content type, cookies, custom headers, path, hostname, query strings, methods, source IP
Protocols: HTTP, HTTPS, HTTP/2, WebSockets
Does not support unbroken TLS/SSL – encryption terminates at the load balancer; traffic to back end is unencrypted within the AWS network
Perfect for containerized applications (Docker, ECS, EKS)

Important ALB components:

Component	Description
Listener	Checks for incoming connections on a configured port and protocol
Target Group	Group of registered targets (EC2 instances, IP addresses, Lambda functions)
Rules	Define how the listener routes traffic to target groups (path-based, host-based, etc.)

graph LR
    Users[Internet Users] --> ALB[Application Load Balancer\nLayer 7]
    ALB -->|/a/* rule| TGA[Target Group A\nEC2 Instances]
    ALB -->|/b/* rule| TGB[Target Group B\nEC2 Instances]
    ALB -->|Default rule| TGC[Target Group C\nContainers]

Demo: Setting up an Application Load Balancer

The following user data scripts were used to set up two web server instances with different path prefixes (/a/ and /b/) for path-based routing demonstration.

Instance A user data (A-instance-user-data.sh):

#!/bin/bash

# Allowing YUM updates and installations from cloud_user
echo '%password%' | passwd cloud_user --stdin
yum update -y
yum install -y httpd

# Starting and enabling HTTPD service
systemctl start httpd.service
systemctl enable httpd.service

# Adding HTTPD group and adding cloud_user
groupadd www
usermod -a -G www cloud_user

# Get the IMDSv2 token
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

# Setting homepage index.html file.
cat <<EOF > /var/www/html/index.html
<html>
    <title>AWS SAA Prep</title>
    <body>
        <p>Our default homepage</p>
    </body>
<html>
EOF

mkdir -p /var/www/html/a/

# Setting the app index.html file.
cat <<EOF > /var/www/html/a/index.html
<html>
    <title>AWS SAA Prep - Path A</title>
    <body>
        <p>This is Path A</p>
    </body>
</html>
EOF

Instance B user data (B-instance-user-data.sh): Same structure but creates /var/www/html/b/index.html.

Network Load Balancers (NLB)

NLBs operate at Layer 4 (Transport layer). They do not perform content-based routing; they are optimized for raw performance.

Key characteristics:

Protocols: TCP, TLS, UDP, TCP_UDP
Highest-performing ELB – millions of requests per second, ultra-low latency
Supports static IPs per AZ – can assign Elastic IPs for easy whitelisting
Perfect for: firewall whitelisting, gaming, IoT, financial applications

Important: Despite being called “Network” Load Balancer, it operates at Layer 4 (Transport), not Layer 3 (Network). Do not confuse these.

Demo: Setting up a Network Load Balancer

The user data script used for an NLB back-end instance:

#!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd.service
systemctl enable httpd.service

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

echo '<html><h1>Hello Gurus!</h1><h2>I live in this Availability Zone: ' \
  >> /var/www/html/index.html
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/availability-zone \
  >> /var/www/html/index.html
echo '</h2><h2>I go by this Instance Id: ' >> /var/www/html/index.html
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id \
  >> /var/www/html/index.html
echo '</h2></html>' >> /var/www/html/index.html

systemctl restart httpd.service

Gateway Load Balancers (GWLB)

GWLBs operate at Layer 3 (Network layer) and are designed for deploying, scaling, and managing virtual network appliances.

Key characteristics:

Uses the GENEVE protocol (port 6081) for traffic encapsulation
Target types: EC2 instances or private IP addresses
Use cases: Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Deep Packet Inspection

graph LR
    Internet[Internet Traffic] --> GWLB[Gateway Load Balancer\nLayer 3]
    GWLB --> IDS[IDS/IPS Appliances]
    IDS -->|Inspected traffic| ALB[Application Load Balancer]
    ALB --> App[Application\nAuto Scaling Group]

Elastic Load Balancing Optimization

Session Affinity (Sticky Sessions)

Sticky sessions ensure clients always reach the same back-end target. Supported by CLBs, ALBs, and NLBs.

Creates a cookie to determine which target is used for a session
Cookie expiry configurable from 1 second to 7 days
Warning: Sticky sessions can override load balancing algorithms; this can cause uneven distribution

Exam tip: Sticky sessions are perfect for maintaining user sessions (e.g., shopping carts). Remember they override round-robin algorithms.

Connection Draining / Deregistration Delay

CLBs: called Connection Draining
ALBs and NLBs: called Deregistration Delay
Allows in-flight requests to complete before removing a target from service
Default: 300 seconds (5 minutes)
Range: 0 to 3600 seconds

Cross-Zone Load Balancing

Distributes traffic evenly across all registered targets in all AZs
ALBs: enabled by default (no charge)
NLBs and GWLBs: disabled by default (charges apply when enabled)
CLBs: no charge when enabled

Demo: Setting up an HTTPS Listener

Steps to set up an HTTPS listener on an ALB:

Navigate to AWS Certificate Manager (ACM) and request a public certificate for your domain
Validate the domain using DNS validation (add a CNAME record in Route 53)
On the ALB, add a listener on port 443 (HTTPS)
Select the ACM certificate
Configure rules and target group

Remember: ACM certificates for use with ALBs are regional. For CloudFront, they must be in us-east-1.

Module 1 Summary and Exam Tips

Concept	Key Points
AZ IDs	Always reference the same physical data center across accounts – use for multi-account strategies
HA vs FT	High Availability = self-recovers, stays up most of the time. Fault Tolerant = handles failures with NO data loss and NO service interruption
ALB	Layer 7; HTTP/HTTPS; smart routing by hostname, path, query string, method, source IP
NLB	Layer 4; TCP/UDP/TLS; highest performance; millions req/s; supports static EIPs
GWLB	Layer 3; GENEVE protocol; security appliances; IDS/IPS; Deep Packet Inspection
Sticky Sessions	Supported by CLB, ALB, NLB; cookie-based; overrides round-robin
Cross-Zone LB	ALB = on by default; NLB/GWLB = off by default
Connection Draining	Allows in-flight requests to complete; 0-3600 seconds

Module 2 – Auto Scaling and High-Availability

Horizontal Versus Vertical Scaling

Scalability (Gartner): The measure of a system’s ability to increase and decrease performance and cost in response to changes in application processing demands.

Scaling Type	Description	Use Case	Limits
Vertical	Scale resources to be larger (bigger instance)	Databases, single-instance apps	CPU, RAM, networking bandwidth of the instance
Horizontal	Increase the number of instances	Stateless web applications	Practically unlimited

Key: Auto Scaling Groups are for horizontal scaling. Do not confuse the two.

Auto Scaling Groups (ASGs)

An Auto Scaling group is a logical resource containing collections of EC2 instances treated as a single group for scaling and management.

Benefits:

Self-healing: Automatically replaces unhealthy instances
Cost optimization: Scales down when demand decreases, scales up when it increases

Key terms:

Term	Definition
Scale Out	Add instances (horizontal scaling up)
Scale In	Remove instances (horizontal scaling down)
Minimum	Lowest number of instances to maintain
Maximum	Highest number of instances allowed
Desired	Target number of instances at any given time

graph TD
    ASG[Auto Scaling Group]
    ASG --> Min[Minimum: 2 instances]
    ASG --> Des[Desired: 4 instances]
    ASG --> Max[Maximum: 10 instances]
    Des --> LT[Launch Template]
    LT --> AZ1[AZ-a: EC2]
    LT --> AZ2[AZ-b: EC2]
    LT --> AZ3[AZ-c: EC2]

Launch Templates vs Launch Configurations:

Launch Templates are the newer and recommended method
Support versioning (v1, v2, etc.)
Define: AMI, instance type, key pair, security groups, user data, IAM instance profile, etc.

Demo: Create a Launch Template and Auto Scaling Group

Steps:

Go to EC2 → Launch Templates → Create launch template
Select “Provide guidance” to see required fields for ASG use
Configure: AMI, instance type, security groups
Create the ASG referencing the launch template
Configure: VPC/subnets across multiple AZs, desired/min/max capacity

Auto Scaling Group Scaling Policies

Policy Type	Description	Best For
Manual	Manually set desired capacity	Testing, emergency adjustments
Simple	Scale based on a CloudWatch alarm threshold	Basic CPU/memory metrics
Target Tracking	Maintain a specific metric value (e.g., 50% CPU)	Most common, recommended approach
Step Scaling	Multiple scaling steps based on alarm thresholds	Fine-grained control
Predictive	Uses ML to forecast and pre-scale	Known traffic patterns (daily/weekly cycles)

Cooldown period: After a scaling activity, a cooldown period (default 300 seconds) prevents additional scaling events until instances are stable.

Auto Scaling Group Health Checks

Health Check Type	Description
EC2 (default)	Checks EC2 instance status and underlying hardware
ELB	Offloads health checking to the load balancer
VPC Lattice	Uses VPC Lattice service mesh health data
EBS	Checks if attached EBS volumes are reachable
Custom	Define your own health check via CloudWatch

ASG Instance Maintenance Policies

Policy	Behavior	Best For
Launch Before Terminating	New instances launched and healthy before old ones are terminated	Maximum availability
Terminate and Launch	Old instances terminated at same time new ones launch	Cost efficiency
Custom	Define min/max capacity range during replacement	Advanced scenarios

Demo: Fronting an Auto Scaling Group with an ELB

Architecture:

Create an Application Load Balancer with HTTPS listener (port 443) using ACM certificate
Create a target group with IP target type (required for Fargate/containers)
Create an Auto Scaling Group with a launch template
Attach the ASG to the target group during creation

graph LR
    Internet[Internet] --> ALB[ALB\nHTTPS:443]
    ALB --> TG[Target Group]
    TG --> ASG[Auto Scaling Group]
    ASG --> EC2a[EC2 - AZ-a]
    ASG --> EC2b[EC2 - AZ-b]
    ASG --> EC2c[EC2 - AZ-c]

Demo: Creating and Using a Dynamic Scaling Policy

To create a target tracking dynamic scaling policy:

Navigate to the ASG → Automatic Scaling tab
Create a Dynamic Scaling Policy
Choose Target tracking scaling
Select metric (e.g., Average CPU Utilization)
Set target value (e.g., 50%)
The ASG will automatically scale to maintain the target

Auto Scaling Group Lifecycle Hooks

Lifecycle hooks allow you to perform custom actions on instances during scale-out or scale-in events. They pause the instance in a WAIT state for up to 2 hours.

Common use cases:

Installing custom software packages before serving traffic (scale-out hook)
Uploading logs to S3 before termination (scale-in hook)

sequenceDiagram
    participant ASG as Auto Scaling Group
    participant Instance as EC2 Instance
    participant Hook as Lifecycle Hook
    participant Action as Custom Action (Lambda/Script)
    
    ASG->>Instance: Launch initiated
    Instance->>Hook: Enter WAIT state
    Hook->>Action: Trigger custom action
    Action->>Action: Install software / upload logs
    Action->>ASG: complete-lifecycle-action CONTINUE
    ASG->>Instance: Move to InService

Lifecycle states:

Pending:Wait → Pending:Proceed → InService (scale-out)
Terminating:Wait → Terminating:Proceed → Terminated (scale-in)

Demo: Trigger Log Storage via a Lifecycle Hook

This script runs on EC2 instances and waits for the lifecycle state to be InService, then uploads logs to S3 before completing the lifecycle action.

#!/bin/bash

# Get the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

BUCKET_NAME="REPLACE_ME"
LOG_FILE_1="/var/log/audit/audit.log"
LOG_FILE_2="/var/log/cloud-init-output.log"
REGION="us-east-1"

function get_target_state {
    echo $(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s \
      http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state)
}

function get_instance_id {
    echo $(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s \
      http://169.254.169.254/latest/meta-data/instance-id)
}

function complete_lifecycle_action {
    instance_id=$(get_instance_id)
    group_name='REPLACE_ME'
    region='us-east-1'
    
    aws autoscaling complete-lifecycle-action \
        --lifecycle-hook-name REPLACE_ME \
        --auto-scaling-group-name $group_name \
        --lifecycle-action-result CONTINUE \
        --instance-id $instance_id \
        --region $region
}

function main {
    while true; do
        target_state=$(get_target_state)
        if [ "$target_state" = "InService" ]; then
            instance_id=$(get_instance_id)
            FILE_NAME="/home/ec2-user/${instance_id}-$(date +'%Y%m%d%H%M%S').zip"
            zip -r "${FILE_NAME}" $LOG_FILE_1 $LOG_FILE_2
            aws s3 cp $FILE_NAME s3://$BUCKET_NAME/ --region $REGION
            complete_lifecycle_action
            break
        fi
        sleep 10
    done
}

main

IAM role requirements for the EC2 instance:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CompleteLifecycleAction",
        "s3:PutObject",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Improving Service Connectivity Using VPC Lattice

VPC Lattice is a managed application networking service that connects, secures, and monitors microservices within a VPC. It simplifies networking complexities when connecting microservices, operating similarly to a service mesh for Kubernetes workloads (but is not identical).

Key benefit: Reduces the networking complexity of connecting microservices without the overhead of a full service mesh implementation.

Module 2 Summary and Exam Tips

Four questions to ask on the exam:

Is it highly-available and self-healing? → Consider ASGs across multiple AZs
Horizontal or vertical scaling? → ASGs are for horizontal scaling
Most cost-effective approach? → ASG minimum instances for standby/DR
Is this event-driven or time-based? → Consider predictive or scheduled scaling

Key concepts:

Concept	Detail
ASG launch template	Defines instance configuration; supports versioning
Target tracking	Best common scaling policy; maintain a metric value
Health checks	EC2 (default), ELB, VPC Lattice, EBS, Custom
Lifecycle hooks	Up to 2-hour wait; for custom launch/terminate actions
Launch Before Terminating	Maximum availability during replacement
Terminate and Launch	Cost efficiency during replacement

Module 3 – Containers and Images

Containers and Images Overview

A container is a standard unit of software that packages code and all its dependencies so the application runs quickly and reliably across different environments.

VM vs Container architecture:

graph TD
    subgraph VM Architecture
        HW1[Physical Hardware]
        HW1 --> HYP[Hypervisor]
        HYP --> VM1[VM1\nFull OS + App]
        HYP --> VM2[VM2\nFull OS + App]
    end
    
    subgraph Container Architecture
        HW2[Physical Hardware]
        HW2 --> OS[Host OS]
        OS --> CR[Container Runtime]
        CR --> C1[Container 1\nApp only]
        CR --> C2[Container 2\nApp only]
        CR --> C3[Container 3\nApp only]
    end

Containers vs VMs:

Containers share the host OS kernel → lighter weight, faster startup
VMs have full OS per instance → more isolation, more overhead
Containers: portable, consistent across environments, ideal for microservices

Amazon Elastic Container Registry (ECR)

Amazon ECR stores and manages Docker images and OCI-compatible artifacts.

Feature	Detail
Repository types	Public (anyone can pull) and Private (IAM-controlled)
Supported images	OCI images, Docker images, OCI artifacts
Access control	IAM permissions for private repos
Lifecycle policies	Automatically expire and clean up old images
Scan on Push	Automatically scans images for vulnerabilities on push
Integration	Natively integrates with ECS and EKS

Exam tip: If you need to store Docker images or OCI-compatible artifacts in AWS → think ECR.

Amazon Elastic Container Service (ECS) Overview

Amazon ECS is the go-to service for launching and managing Docker containers at scale on AWS compute.

Benefits:

Manage 1 to thousands of containers from a single console
Self-healing architecture: replaces failed tasks automatically
Integrates with ALBs and NLBs
Works with Application Auto Scaling for automatic scaling

ECS Launch Types:

Launch Type	Description
EC2	Containers run on EC2 instances you manage
Fargate	Serverless – AWS manages the compute infrastructure
ECS Anywhere	External launch type for on-premises containers

Amazon ECS Tasks, Task Definitions, and IAM Roles

Task Definition: A JSON-formatted blueprint that specifies:

Launch type (EC2 or Fargate)
CPU and memory requirements
Networking settings (VPC, subnets)
Container image (from ECR)
Environment variables
IAM roles
Logging configuration

IAM Role Types:

Role	Who Uses It	Purpose
Task Role	The application containers	Make AWS API calls (S3, DynamoDB, SQS, etc.)
Task Execution Role	ECS agent/service itself	Pull images from ECR, retrieve secrets from Secrets Manager

graph TD
    TaskDef[Task Definition]
    TaskDef --> TR[Task Role\nassigned to containers]
    TaskDef --> TER[Task Execution Role\nused by ECS agent]
    TR --> S3[S3 GetObject]
    TR --> SQS[SQS ReceiveMessage]
    TER --> ECR[ECR Pull Image]
    TER --> SM[Secrets Manager]

Cluster: Logical grouping of tasks/services. Task: A running instance of a task definition (one or more containers). Service: Maintains a specified number of task instances; manages restarts and integrates with ELBs.

Load Balancing Amazon ECS

ECS services integrate with ELBs to distribute traffic across tasks:

Supported: ALB, NLB, Classic Load Balancer (CLB – avoid; no Fargate support)
Different services can map to different target groups on the same load balancer
Use Application Auto Scaling with ECS services for automatic scaling based on CloudWatch metrics (CPU, memory)

Demo: Creating an ECR Repository

Navigate to ECR → Create repository
Choose Private repository
Enable Scan on Push
After creation, push your Docker image:

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS \
  --password-stdin <account>.dkr.ecr.us-east-1.amazonaws.com

# Build, tag, and push the image
docker build -t my-app .
docker tag my-app:latest <account>.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
docker push <account>.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

Demo: Creating a Load Balanced ECS Cluster

Dockerfile used in the demo:

FROM --platform=linux/amd64 httpd:alpine

COPY index.html /usr/local/apache2/htdocs/

Key steps:

Create Task Definition → choose Fargate, .25 vCPU, .5 GB memory
Assign Task Role (for CloudWatch Logs) and Task Execution Role
Create Cluster → Fargate
Create Service → attach to target group of existing ALB
Set desired task count

Important: IP target type is required for Fargate containers when using an ALB target group.

Amazon ECS Storage

Storage Type	Use Case
EBS Volumes	Persistent storage; relational databases (PostgreSQL, MySQL)
Amazon EFS	Shared storage between containers; CMS (WordPress), analytics
FSx for Windows File Server	.NET applications needing Windows shared file storage
Docker Volumes	Sharing volumes between containers on the same EC2 host

Amazon Elastic Kubernetes Service (EKS) Overview

EKS is the managed Kubernetes service on AWS. Key Kubernetes concepts for the exam:

Component	Description
Cluster	Control plane + worker nodes
Node	Virtual/physical machine hosting containerized apps
Pod	Smallest deployable unit; hosts containers (usually 1 container)
Service	Exposes applications running on one or more pods
Job	One-off task that runs until successful completion
CronJob	Scheduled job running at defined intervals
Deployment	Manages rolling updates for pods

EKS Launch Types:

Managed Node Groups: EC2 nodes managed by EKS
Self-Managed Nodes: Customer manages EC2 instances
Fargate: Serverless pods

Amazon EKS Data Storage

Storage	Use Case
EBS	Data persistence for pods
Amazon EFS	Shared Linux file systems
FSx for Lustre	High-performance computing workloads
FSx for NetApp ONTAP	Enterprise NFS/SMB workloads
FSx for OpenZFS	OpenZFS compatible workloads
S3	Object storage for data retrieval

StorageClass: Kubernetes object defining EBS volume defaults (type, encryption, IOPS). Uses the Amazon EBS CSI driver.

Exam tip: Need highly-available, scalable, shared file system for EKS pods on Linux? → Amazon EFS

Securing Amazon EKS

EKS Pod Identities (IAM Roles for Service Accounts - IRSA):

Assign IAM roles to Kubernetes service accounts
Pods assume the role to make AWS API calls
Similar to EC2 instance profiles but for pods
Use different IAM roles for different services (frontend vs backend)

API Endpoint Access:

Default: publicly accessible (secured via IAM and Kubernetes RBAC)
Can enable private endpoint to restrict access within VPC only
Can configure both public and private access

Amazon EKS Distro

EKS Distro (EKS-D) is a Kubernetes distribution based on EKS, but entirely self-managed by the customer.

Can run anywhere: on-prem, other clouds, your laptop
Same versions and dependencies as EKS
You manage: upgrades, node deployment, pod deployment
Good for self-managed Kubernetes but operationally heavy

Amazon ECS and Amazon EKS Anywhere

Service	Description
EKS Anywhere	Run EKS workloads on-premises; manages lifecycle of clusters
ECS Anywhere	External launch type; run ECS-managed containers on your own infrastructure

EKS Anywhere key differences from EKS-D:

Manages more overhead (cluster lifecycle, node management)
Control plane is in the customer data center (not AWS)
Cluster updates must be done manually via CLI or Flux
Offers curated packages for extended Kubernetes functionality

AWS App Runner

AWS App Runner is a fully managed service that deploys directly from source code or container images to scalable, secure web applications.

graph LR
    GIT[Git Repository] -->|Push| AR[App Runner Connection]
    ECR[ECR Repository] -->|Image update| AR
    AR -->|Automatic deploy| AS[App Runner Service]
    AS --> LB[Built-in Load Balancer]
    AS --> Scale[Auto Scaling]
    AS --> Sec[Security Groups]

Key features:

Automatic deployment on code/image updates
Automatic scaling and load balancing
Implements security configurations automatically
Developer use case: Simplify deploying updated Docker/code versions
DevOps use case: Automatic deployments on every git push

AWS App2Container

App2Container (A2C) is a CLI tool for lifting and shifting applications into containers.

Supported applications:

Java applications
ASP.NET applications
Any other language → NOT supported

Process:

Lists all compatible running Java and ASP.NET applications
Analyzes runtime dependencies
Extracts application artifacts
Generates a Dockerfile
Generates AWS artifacts: CloudFormation templates, ECR images, task definitions

Exam tip: A2C can create a CI/CD pipeline via AWS CodePipeline to automate builds and deployments.

Module 3 Summary and Exam Tips

Service	Key Points
ECR	Store Docker/OCI images; public or private; lifecycle rules; Scan on Push
ECS	Orchestrate Docker containers; EC2, Fargate, ECS Anywhere launch types
Task Role	Used by containers to call AWS services
Task Execution Role	Used by ECS agent to pull images, get secrets
EKS	Managed Kubernetes; pods, nodes, clusters, services
EKS Pod Identity	IAM role for service accounts; like EC2 instance profile for pods
EKS Distro	Self-managed Kubernetes distribution
EKS/ECS Anywhere	Run workloads on-premises
App Runner	Fully managed deploy from source/container image
App2Container	Lift-and-shift Java/ASP.NET to containers

Module 4 – AWS Lambda

AWS Lambda Overview

Serverless allows developers to focus only on code and small configuration options without managing underlying compute. Lambda is AWS’s primary serverless compute service.

Evolution:

Physical servers → Virtualization → Cloud (IaaS) → Serverless (focus on code only)

Key benefits:

No server management
Automatic scaling
Pay per invocation (no cost when not running)
High availability built-in
Supports many runtimes

Lambda limits:

Max execution time: 900 seconds (15 minutes)
Memory: 128 MB to 10,240 MB (scales proportionally with CPU)
Ephemeral storage (/tmp): 512 MB to 10,240 MB
Deployment package size: 50 MB (zipped), 250 MB (unzipped)
Concurrency: 1,000 concurrent executions (soft limit per account per region)

Configuring Lambda Functions

Key configuration elements:

Element	Description
Runtime	Language environment (Python, Node.js, Java, .NET, Ruby, Go, etc.)
Execution Role	IAM role granting AWS permissions to the function
Networking	Optional VPC, subnets, security groups for private resource access
Memory	128 MB to 10,240 MB; CPU scales proportionally
Timeout	1 second to 900 seconds
Environment Variables	Key-value pairs passed to the function
Layers	Shared code/libraries across functions

Available runtimes:

Python 3.x
Node.js
Java
.NET
Ruby
Go
Custom runtimes (bring your own)

Demo: Creating and Invoking a Lambda Function

This Lambda function converts a CSV file from S3 to JSON and uploads the result to a destination bucket:

import json
import boto3
import csv
import io
import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

s3 = boto3.client("s3")

def lambda_handler(event, context):
    bucket = event["Records"][0]["s3"]["bucket"]["name"]
    key = event["Records"][0]["s3"]["object"]["key"]

    logger.info(f"Event received => {json.dumps(event)}")
    logger.info(f"Context received => {context}")

    try:
        # Get CSV file from source bucket
        response = s3.get_object(Bucket=bucket, Key=key)
        csv_content = response["Body"].read().decode("utf-8")

        # Convert CSV to JSON
        reader = csv.DictReader(io.StringIO(csv_content))
        json_data = json.dumps([row for row in reader])

        # Get destination bucket from environment variable
        destination_bucket = os.environ.get("DESTINATION_BUCKET")

        # Save JSON to destination S3 bucket
        json_key = key.replace(".csv", ".json")
        s3.put_object(Bucket=destination_bucket, Key=json_key, Body=json_data)

        logger.info(f"Transformed {key} to {json_key}")

        return {
            "statusCode": 200,
            "body": json.dumps("CSV transformed to JSON and saved to S3!"),
        }
    except Exception as e:
        logger.error("Error during processing: %s", str(e))
        return {"statusCode": 500, "body": json.dumps({"message": "An error occurred"})}

IAM Execution Role Policy (iam-execution-role-policy.json):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject"],
            "Resource": "arn:aws:s3:::SOURCE_BUCKET/*"
        },
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject"],
            "Resource": "arn:aws:s3:::DESTINATION_BUCKET/*"
        }
    ]
}

Architecture:

graph LR
    Upload[User uploads CSV] --> SB[Source S3 Bucket]
    SB -->|S3 Event Trigger| Lambda[Lambda Function\nConvertFiles]
    Lambda -->|Read CSV| SB
    Lambda -->|Write JSON| DB[Destination S3 Bucket]

Lambda Function Networking

By default, Lambda functions are deployed in an AWS-owned VPC with internet access.

To access private resources (RDS, EC2 in private subnets):

Configure the function for VPC access
Specify: VPC, private subnets, security group
Lambda must be in private subnets (not public)

graph LR
    Lambda[Lambda Function\nVPC-enabled] --> Private[Private Subnet]
    Private --> RDS[RDS Instance]
    Private --> EC2[EC2 Application]
    Private --> VPN[VPN/Direct Connect]
    VPN --> OnPrem[On-Premises API]

Best practice: Reference source security groups in target security group rules rather than IP ranges for Lambda-to-RDS access.

Demo: Configure a Lambda Function for VPC Access

This Lambda function fetches a URL from an environment variable (demonstrating access to a private web server):

import json
import logging
import os
import urllib3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

http = urllib3.PoolManager()  # Connection pooling

def lambda_handler(event, context):
    try:
        url = os.environ.get("URL")  # Get URL from environment variable

        if not url:
            raise ValueError("URL not provided in the environment variables")

        logger.info(f"Fetching URL: {url}")

        response = http.request("GET", url, redirect=False)

        logger.info(f"Response => {response}")

        return {
            "statusCode": 200,
            "body": json.dumps({
                "status_code": response.status,
                "content": response.data.decode("utf-8"),
            }),
        }

    except urllib3.exceptions.HTTPError as e:
        logger.error(f"HTTP error fetching URL: {e}")
        return {"statusCode": 500, "body": json.dumps({"error": str(e)})}
    except ValueError as e:
        logger.error(str(e))
        return {"statusCode": 400, "body": json.dumps({"error": str(e)})}
    except Exception as e:
        logger.error(f"An unexpected error occurred: {e}")
        return {"statusCode": 500, "body": json.dumps({"error": "Unexpected error"})}

Lambda Function Concurrency

Concurrency = number of in-flight requests your function handles simultaneously.

Concurrency Type	Description	Use Case
Provisioned	Pre-initialized environments; kept warm; costs money	Reduce cold starts for critical functions
Reserved	Set maximum concurrent instances for a function; reserves from pool	Ensure critical functions never get throttled
Throttling	Requests dropped when no concurrency available	Set reserved concurrency to 0 to throttle manually

Default account limit: 1,000 concurrent executions (soft limit – can request increase).

Cold start: First invocation of a function requires initialization (runtime setup, code loading). Subsequent invocations reuse the execution environment (warm start).

To manually throttle a function (e.g., malicious execution suspected): Set reserved concurrency to 0.

Lambda SnapStart

Lambda SnapStart provides sub-second startup performance with zero code changes.

Supported runtimes only:

Java 11 or greater
Python 3.12 or greater
.NET 8 or greater

How it works:

First invocation runs through the full init phase (extensions, runtime bootstrap, static code)
SnapStart caches a snapshot of the memory and disk state after init
Future invocations skip the init phase entirely using the cached snapshot

graph LR
    subgraph "Normal Lambda Lifecycle"
        I1[Init Phase\nSlow] --> INV1[Invoke] --> SHUT1[Shutdown]
    end
    subgraph "SnapStart Lifecycle"
        SNAP[Cached Snapshot] --> INV2[Invoke\nSub-second start] --> SHUT2[Shutdown]
    end

Note: SnapStart for Java functions is available at no extra cost (unlike Provisioned Concurrency).

Important Lambda Features

Versions

Versions are immutable snapshots of your function (code + runtime + memory + configuration)
The current working version is called $LATEST
Each published version gets an incrementing number (:1, :2, etc.)
Published versions are immutable

Aliases

Aliases are pointers to specific function versions
Can be updated to point to a different version
Access via alias ARN
Can split traffic between two versions (e.g., 90% v1, 10% v2 for canary deployments)

graph LR
    PROD[Alias: prod] --> V3[Version 3\n90% traffic]
    PROD -->|10% canary| V4[Version 4]
    DEV[Alias: dev] --> LATEST[$LATEST]

Common Lambda triggers (event source mappings):

S3 bucket event notifications
Kinesis Data Streams / Data Firehose
SNS / SQS
Amazon EventBridge
API Gateway
DynamoDB Streams
Cognito

Module 4 Summary and Exam Tips

Three questions to ask on the exam:

Do you need servers? If yes → avoid Lambda
Is it better for containers? If yes → use ECS or EKS
How long does the code need to run? If > 15 minutes → NOT Lambda

Key concepts:

Concept	Detail
Execution role	IAM role for AWS API calls from Lambda
Max timeout	900 seconds / 15 minutes
Concurrency limit	1,000 default (soft); can request increase
VPC access	Deploy in private subnets; reference SG for RDS/EC2
SnapStart	Java 11+, Python 3.12+, .NET 8+; sub-second cold starts
Provisioned concurrency	Keep functions warm; costs money
Reserved concurrency	Guarantee concurrency for critical functions
Layers	Shared libraries across functions

Module 5 – Event-driven Architectures

Amazon RDS Events

Amazon RDS events are near real-time notifications about events on your monitored RDS resources (instances, clusters, snapshots).

Important characteristics:

Do not contain actual database data
Event categories: DB instance, snapshot, security group changes, etc.
Can publish to: SNS topics or Amazon EventBridge
Common pattern: EventBridge → trigger Lambda for custom logic

Example RDS events:

Snapshot created
Instance shut down
Cluster failover

graph LR
    RDS[RDS Instance] -->|Event: Low storage| SNS[SNS Topic]
    SNS --> Lambda[Lambda Function]
    Lambda --> Action[Auto-increase storage\nor Alert team]
    RDS -->|Event| EB[EventBridge]
    EB --> Lambda2[Lambda Function\nCustom logic]

Amazon S3 Events

S3 event notifications allow you to receive notifications when specific events occur in your buckets.

Common event types (most tested):

s3:ObjectCreated:* (Put, Post, Copy, CompleteMultipartUpload)
s3:ObjectRemoved:*
s3:LifecycleExpiration
s3:Replication

Supported destinations:

SNS topic
SQS queue (Standard queues only – not FIFO)
Lambda function
Amazon EventBridge

Exam tip: S3 → SQS only supports Standard queues (not FIFO).

Amazon EventBridge

Amazon EventBridge (formerly CloudWatch Events) is a serverless event bus that passes events from a source to an endpoint.

Key components:

Component	Description
Event	A recorded change in an AWS environment, SaaS partner, or custom application (JSON object)
Rule	Criteria to match incoming events and route to targets
Target	Where the event is sent (Lambda, SNS, SQS, API Gateway, etc.)
Event Bus	Router that receives events, evaluates rules, delivers to targets

Rule trigger types:

Event Pattern: Define source + pattern; triggers when pattern matches
Scheduled: Cron-based recurring schedule

Note: Some AWS services are best effort (try to deliver) while others are durable (guaranteed delivery).

Amazon EventBridge Event Buses

Bus Type	Description
Default	Every AWS account has one; automatically receives all compatible AWS service events
Custom	Created for custom workloads; cross-account event centralization; PII vs non-PII separation
Partner	Receives events from SaaS partners (Datadog, Sumo Logic, etc.)

Custom buses require a resource policy to allow other accounts or custom applications to send events.

Amazon EventBridge Events

EventBridge events are always JSON objects with consistent top-level fields:

{
  "version": "0",
  "id": "abcd-1234",
  "source": "aws.health",
  "account": "123456789012",
  "time": "2024-01-15T12:00:00Z",
  "region": "us-east-1",
  "resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-1234"],
  "detail-type": "AWS Health Event",
  "detail": {
    "eventTypeCode": "AWS_EC2_INSTANCE_STORE_DRIVE_PERFORMANCE_DEGRADED"
  }
}

One rule can route to multiple targets simultaneously (e.g., Lambda + SNS topic at the same time).

Demo: Trigger Workloads Using Amazon EventBridge

Architecture: EventBridge rule → Lambda (restart stopped EC2) + SNS (email notification)

Lambda function to restart a stopped EC2 instance:

import boto3
import logging

ec2_client = boto3.client('ec2')

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    try:
        # Extract instance ID from the EventBridge event
        detail = event.get("detail", {})
        instance_id = detail.get("instance-id")

        if not instance_id:
            raise ValueError("No instance-id found in the event.")

        logger.info(f"Instance ID extracted: {instance_id}")

        # Check current instance state
        describe_response = ec2_client.describe_instances(InstanceIds=[instance_id])
        instance_state = (
            describe_response['Reservations'][0]['Instances'][0]['State']['Name']
        )

        logger.info(f"Current instance state: {instance_state}")

        if instance_state == 'stopped':
            logger.info(f"Starting instance {instance_id}...")
            start_response = ec2_client.start_instances(InstanceIds=[instance_id])
            logger.info(f"Start response: {start_response}")
        else:
            logger.info(f"Instance {instance_id} is not stopped. No action taken.")

    except Exception as e:
        logger.error(f"An error occurred: {str(e)}")
        raise e

EventBridge rule event pattern (event-example.json):

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

Module 5 Summary and Exam Tips

Concept	Key Points
RDS Events	Near real-time notifications; no database data; publish to SNS/EventBridge
S3 Events	Monitor Object Created/Removed; destinations: SNS, SQS (Standard only), Lambda, EventBridge
EventBridge	Trigger actions based on account events; event patterns or scheduled rules
Event Buses	Default (every account), Custom (cross-account/custom apps), Partner (SaaS)
Rules	One rule → multiple targets simultaneously

When to think EventBridge: You want to trigger an action based on something happening in your account. Common use case: automate responses to API calls or resource state changes.

Module 6 – Amazon API Gateway, AWS AppSync, and AWS X-Ray

Amazon API Gateway Overview

Amazon API Gateway is a fully managed service to publish, create, maintain, monitor, and secure custom APIs.

Key characteristics:

Integrates natively with Lambda, custom HTTP endpoints, and virtually any AWS service
Compatible with Swagger and OpenAPI frameworks
Can transform and validate requests and responses

Endpoint types:

Endpoint Type	Description	Use Case
Edge-Optimized	Default; deployed globally via CloudFront POPs; reduces latency for global users	Global APIs
Regional	Deployed to a specific region; use with Route 53 latency routing for multi-region	Regional traffic
Private	Only accessible within a VPC via VPC endpoints	Internal APIs

Amazon API Gateway Authentication and Security

Access control options:

Method	Description
Resource Policies	Control which principals can call the API; supports IP ranges, VPCs, specific accounts
Public Access	Edge-optimized APIs are public by default
IAM Permissions	Use IAM to control API access
Lambda Authorizer	Custom Lambda function for token-based authentication
Cognito User Pool Authorizer	Use Cognito user pools for JWT-based authentication
Usage Plans + API Keys	Control and meter API usage per client

Resource policy use case: Deny API traffic from specific IP ranges/CIDR blocks.

Private APIs require both a resource policy AND a VPC endpoint policy for full security control.

Amazon API Gateway Integrations

Common exam scenarios:

1. API Gateway + Lambda + DynamoDB (Serverless stack):

graph LR
    Client --> CF[CloudFront\nStatic Content]
    CF --> S3[S3 Website]
    Client --> APIGW[API Gateway]
    APIGW --> Lambda[Lambda Function]
    Lambda --> DDB[DynamoDB]

2. API Gateway → SQS (Buffered messaging):

graph LR
    Client --> APIGW[API Gateway\nPOST /messages]
    APIGW -->|Execution Role| SQS[Amazon SQS Queue]
    SQS --> Consumer[Consumer Application]

3. API Gateway → Kinesis (Stream ingestion):

graph LR
    IoT[IoT Devices] --> APIGW[API Gateway]
    APIGW --> KDS[Kinesis Data Streams]
    KDS --> KDF[Data Firehose]
    KDF --> S3[S3 Bucket]

Amazon API Gateway Deployments and Versions

Deployment: Publishing an API to make it publicly accessible. Stage: A snapshot of the API (methods, responses, integrations, settings). Examples: dev, test, prod.

Stage features:

Caching: Speed up latency
Throttling: Usage plans for rate limiting
Logging: CloudWatch integration
Canary testing: Split traffic between versions (e.g., 10% to new version)

Demo: Creating a REST API Using Amazon API Gateway

Lambda function that fetches a random quote from the internet:

import boto3
from botocore.exceptions import ClientError
import http.client
import json
import os
import logging

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info(f"Event => {event}")

    try:
        # Get a random quote from the internet
        conn = http.client.HTTPSConnection("zenquotes.io")
        conn.request("GET", "/api/random")
        response = conn.getresponse()

        if response.status == 200:
            data = json.loads(response.read().decode())
            quote = data[0]["q"]
            author = data[0]["a"]

            return {"quote": quote, "author": author}
        else:
            return {"body": f"Failed to fetch a quote. Error code: {response.status}"}

    except Exception:
        return {"body": "An exception occurred"}

Steps to create the REST API:

Go to API Gateway → Create API → REST API
Create a resource (e.g., /quote)
Create a method (GET) → Integration: Lambda Function
Enable Lambda proxy integration
Deploy to a stage (e.g., test)
Test using the provided Invoke URL

Demo: Using TLS and Custom Domain Names for API Gateway

Steps to configure custom domain with TLS:

Request a certificate in ACM for your domain
Validate using Route 53 DNS validation
Create a Custom Domain Name in API Gateway
Create an API Mapping linking the domain to your stage
Create a Route 53 alias record pointing to the API Gateway endpoint
Test with custom URL

SQS integration requires an API Gateway execution role with sqs:SendMessage permissions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sqs:SendMessage",
    "Resource": "arn:aws:sqs:REGION:ACCOUNT:QUEUE_NAME"
  }]
}

AWS AppSync

AWS AppSync is a serverless GraphQL interface for developers.

Key characteristics:

Specifically for GraphQL APIs (key exam indicator)
Fetches data quickly by combining from multiple sources (Lambda, DynamoDB, etc.)
Authentication: API keys, IAM, Cognito, OpenID Connect, Lambda authorizer
Supports only JavaScript or TypeScript for backend logic

Exam tip: If you see a requirement for GraphQL in AWS → immediately think AWS AppSync.

Debug Applications Using AWS X-Ray

AWS X-Ray collects data about requests and provides tools to view, filter, and gain insights to identify issues and optimize applications.

Key concepts:

Traces: End-to-end view of a request across multiple services
Trace ID: Unique identifier to track a specific request
Segments: Data about a unit of work (e.g., Lambda invocation, DynamoDB call)
Subsegments: More granular units within a segment
X-Ray Daemon: Process that listens for raw trace data and sends to X-Ray service

Integrated services (can auto-instrument):

API Gateway
Lambda
EC2 (via SDK and daemon)
ECS
Elastic Beanstalk

Use X-Ray when: You need to trace requests across distributed microservices to identify performance bottlenecks, errors, or latency.

Module 6 Summary and Exam Tips

Service	Key Points
API Gateway	Create/maintain/publish custom APIs; integrate with Lambda, HTTP, any AWS service
Endpoint types	Edge-optimized (default, global), Regional, Private
API Auth	Public, IAM, Lambda Authorizer, Cognito User Pool, Resource Policy
AppSync	GraphQL only; JavaScript/TypeScript only
X-Ray	Distributed tracing; traces, segments, daemon
Stages	Deployments go to named stages; support caching, canary, throttling

Module 7 – Serverless Authentication with Amazon Cognito

Amazon Cognito Overview

Amazon Cognito is an AWS-native identity provider offering authentication, authorization, and user management for web and mobile applications.

Key characteristics:

Serverless (no infrastructure to manage)
Users can sign in with username/password or social providers (Facebook, Google, Amazon, Apple)
Scales to millions of users
No custom authentication code required

Two main components:

User Pools – User directories for sign-up/sign-in to your applications
Identity Pools – Grant users access to AWS services via temporary credentials

Amazon Cognito User Pools

User Pools provide sign-up and sign-in for your application users. Upon successful authentication, they receive a JSON Web Token (JWT).

Features:

Basic authentication (username/password)
Federated identities (Google, Facebook, Amazon, Apple)
Multi-Factor Authentication (MFA)
Self-service password reset
Email/phone verification
Adaptive Authentication: Blocks suspicious sign-ins or requires additional factors based on risk level

graph LR
    User[Mobile/Web User] --> UP[Cognito User Pool]
    UP -->|JWT Token| App[Your Application\nAPI Gateway]
    App -->|Authorize request| UP

Exam scenario – API Gateway + Cognito User Pool:

User authenticates with Cognito User Pool → receives JWT
User includes JWT in API Gateway request
API Gateway uses Cognito authorizer to validate JWT
If valid → request proceeds to Lambda back end

Amazon Cognito Identity Pools

Identity Pools grant authenticated users access to AWS services via temporary credentials (STS).

Flow:

User authenticates via third-party IDP or Cognito User Pool
Identity Pool maps user to an IAM role
User receives temporary credentials to access AWS services directly

Features:

Assign different IAM roles based on user characteristics (premium vs free tier)
Guest access (unauthenticated): Users can receive heavily restricted IAM permissions without logging in
Each role has distinct permission sets

graph LR
    User[User] --> IDP[3rd-party IDP\nor User Pool]
    IDP --> IP[Cognito Identity Pool]
    IP -->|Role A| Premium[Premium Role\nFull S3 access]
    IP -->|Role B| Free[Free Role\nLimited S3 access]
    IP -->|Role C| Guest[Guest Role\nRead-only access]

Key difference:

User Pool → grants access to your application
Identity Pool → grants access to AWS services

Module 7 Summary and Exam Tips

Concept	Key Points
Cognito	Serverless identity provider; auth/authz/user management
User Pools	Sign-up/sign-in; JWT tokens; MFA; adaptive authentication
Identity Pools	Temporary AWS credentials; IAM role mapping
User Pool auth options	Basic auth, Google, Facebook, Amazon, Apple
Identity Pool auth options	Third-party IDPs or Cognito User Pools

Common exam trap: User pools grant access to YOUR APP. Identity pools grant access to AWS SERVICES. Know the difference.

Module 8 – AWS CloudFormation and Infrastructure-as-Code Services

Infrastructure as Code Review

Infrastructure as Code (IaC) is the ability to provision and support infrastructure using code instead of manual processes.

Benefits:

Quick duplication across regions and accounts
Avoid human errors through templated deployments
Integrate with source control for change tracking
Implement consistent resource tagging for cost tracking

AWS CloudFormation Overview

AWS CloudFormation allows declaring infrastructure as code for repeatable, automated deployments via stacks.

Key characteristics:

Free service (pay only for resources created)
Define templates in JSON or YAML
Resources are deployed as a stack
Supports automated resource tagging + stack identifier tag
Not all resources supported (use custom resources for unsupported ones)
Perfect for identical infrastructure across multiple accounts/regions

Template structure:

AWSTemplateFormatVersion: "2010-09-09"  # Always this value
Description: "Description of the template"

Parameters:
  ParamName:
    Description: "What this parameter does"
    Type: String
    Default: "DefaultValue"

Mappings:
  # Key-value pairs for environment-specific configs

Conditions:
  # Logical conditions for conditional resource creation

Resources:  # Required section
  ResourceLogicalID:
    Type: "AWS::ServiceName::ResourceType"
    Properties:
      PropertyKey: PropertyValue
      Tags:
        - Key: Name
          Value: !Ref ParamName

Outputs:
  OutputKey:
    Value: !Ref ResourceLogicalID
    Export:
      Name: "ExportedValueName"

AWS CloudFormation Service Roles

Service roles control what permissions CloudFormation has when deploying stacks.

No service role set: CloudFormation uses temporary credentials of the user deploying the stack
Service role set: CloudFormation uses the specified role’s permissions (enables least-privilege)

Use case: Limit CloudFormation to only create specific EC2 resources; prevent it from creating VPCs or databases.

Demo: Writing an AWS CloudFormation Template

Multi-VPC CloudFormation template (partial):

AWSTemplateFormatVersion: "2010-09-09"
Description: "Template with two VPCs, VPC Peering, and Security Groups allowing SSH"

Parameters:
  VpcAName:
    Description: The name of the first VPC
    Type: String
    Default: VPC-A
  VpcBName:
    Description: The name of the second VPC
    Type: String
    Default: VPC-B

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"
      EnableDnsHostnames: true
      EnableDnsSupport: true
      Tags:
        - Key: "Name"
          Value: !Ref VpcAName

  PublicSubnet1:
    Type: "AWS::EC2::Subnet"
    Properties:
      CidrBlock: "10.0.0.0/24"
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
      Tags:
        - Key: "Name"
          Value: "Public Subnet AZ A"
      AvailabilityZone: !Select ["0", !GetAZs !Ref "AWS::Region"]

  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Properties:
      CidrBlock: "10.0.1.0/24"
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
      Tags:
        - Key: "Name"
          Value: "Public Subnet AZ B"
      AvailabilityZone: !Select ["1", !GetAZs !Ref "AWS::Region"]

CloudFormation intrinsic functions reference:

Function	Description
`!Ref`	Reference a parameter or resource
`!Sub`	String substitution
`!GetAtt`	Get an attribute from a resource
`!Select`	Select from a list
`!GetAZs`	Get list of AZs in a region
`!If`	Conditional selection
`!Join`	Join strings
`!ImportValue`	Import exported stack value

Deleting AWS CloudFormation Stacks

Protection mechanisms:

Feature	Description
Termination Policy	Prevents the entire stack from being deleted; disabled by default
Stack Policy	Prevents specific resources from being updated or deleted
Disable Rollback	On failure, stay at current point instead of rolling back

Stack policy example — allow updates only on non-critical resources:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    }
  ]
}

Organizational Deployments via StackSets

CloudFormation StackSets create, update, and delete stacks across multiple accounts and regions in a single operation.

Key concepts:

Concept	Detail
Admin account	Delegated administrator; manages templates
Target accounts	Accounts where stack instances are deployed
Stack instances	References to stacks in each account/region
Regional scope	Stacks are regional; StackSets deploy to each specified region

Permissions models:

Model	Description
Self-Managed	Manually create IAM roles in admin and target accounts
Service-Managed	AWS Organizations manages permissions automatically

graph TD
    Admin[Admin Account\nStackSet] -->|Deploy| T1[Target Account 1\nus-east-1]
    Admin -->|Deploy| T2[Target Account 1\nus-west-2]
    Admin -->|Deploy| T3[Target Account 2\nus-east-1]

Demo: Deploying a StackSet

Navigate to CloudFormation → StackSets → Create StackSet
Upload template (same as regular stacks)
Specify stack name and parameters
Specify accounts (by account ID or organizational unit)
Specify regions (deploy to all selected regions with single operation)

Preview Infrastructure Changes Using Change Sets

Change Sets preview the impact of proposed template changes on existing resources.

Included in change set output:

Resource replacements
Resource deletions
Property updates (tags, configurations)

Workflow:

Create change set (upload new template or modify existing)
Review proposed changes (additions, modifications, deletions)
Execute the change set to apply changes, OR delete it to discard

Best practice: Always use change sets before updating production stacks to understand the impact.

Demo: Creating a Stack Change Set

Select existing stack → Stack actions → Create change set
Choose to Edit in Infrastructure Composer or upload new template
Review the change summary (blue = new, orange = updated, red = deleted)
If acceptable → Execute change set

CloudFormation Custom Resources

Custom Resources allow custom logic in CloudFormation templates for:

Actions not natively supported by CloudFormation
Complex logic beyond standard resource types
Examples: executing database migration scripts, calling external APIs, initializing databases after RDS creation

Note: Custom resources are moving more toward developer-focused exams but can still appear.

CloudFormation cfn-init

cfn-init (CloudFormation init) is a helper script for defining initialization tasks on EC2 instances.

Key difference from User Data:

User Data: Updates trigger full instance replacement
cfn-init: Updates instances in place without replacement

Common use cases:

Getting metadata from CloudFormation
Installing packages on EC2 instances
Writing files to EBS volumes
Starting/stopping/enabling OS services

Usage in template:

Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Metadata:
      AWS::CloudFormation::Init:
        config:
          packages:
            yum:
              httpd: []
          services:
            sysvinit:
              httpd:
                enabled: true
                ensureRunning: true
    Properties:
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          /opt/aws/bin/cfn-init -v \
            --stack ${AWS::StackName} \
            --resource MyEC2Instance \
            --region ${AWS::Region}

AWS Service Catalog allows organizations to create catalogs of IT services (pre-approved CloudFormation templates).

Purpose:

Centrally manage commonly deployed services
Ensure governance and compliance
End users can only deploy pre-approved catalog items
Catalogs deployed using service roles

What can be in a catalog:

Approved AMIs
Specific EC2 instance types
Specific RDS instances and engine versions
Any CloudFormation-supported resources

Self-Service Templates with AWS Proton

AWS Proton creates and manages infrastructure and deployment tooling for serverless and container-based applications.

Key features:

Automates IaC provisioning AND deployment methods
Defines standardized infrastructure for serverless/container apps
Automatically provisions resources AND configures CI/CD pipelines
Supports CloudFormation templates and Terraform providers

Module 8 Summary and Exam Tips

Four questions to ask on the exam:

Can/should you automate this? → If yes, what kind of automation?
Is the automation repeatable? Does it need to be? → Maybe StackSets
Does it work cross-region or cross-account? → StackSets
What service is the best fit? (CloudFormation vs Service Catalog vs Proton)

Service	When to Use
CloudFormation	Version-controlled templates; automating repeatable deployments
StackSets	Same infrastructure across multiple accounts/regions
Service Catalog	Pre-approved templates for end users; governance
Proton	Standardized IaC + CI/CD for serverless/container teams
Change Sets	Preview changes to existing stacks before applying
cfn-init	In-place instance initialization without replacement
Custom Resources	Non-natively supported logic in CloudFormation

Module 9 – AWS Elastic Beanstalk

Reviewing Platform-as-a-Service (PaaS)

Platform-as-a-Service (PaaS) provides a complete development and deployment environment in the cloud.

Service Model	Customer Manages	AWS Manages
IaaS (EC2)	Application, data, OS, middleware, runtime	Hypervisor, hardware, networking
PaaS (Beanstalk)	Application + data only	Runtime, middleware, OS, hardware
SaaS	Nothing (just uses the service)	Everything

AWS Elastic Beanstalk Overview

Elastic Beanstalk is a managed PaaS offering where you only manage the application code.

What Beanstalk manages for you:

EC2 instances
Application Load Balancer
Auto Scaling Groups
Optionally: RDS database

Supported platforms:

Java
.NET
Node.js
PHP
Python
Ruby
Go
Docker

AWS Elastic Beanstalk Environments

Key components:

Component	Description
Application	Logical collection of all components (environments, versions, configurations)
Application Version	A labeled iteration of code pointing to an S3 object
Environment	AWS resources running a specific application version (1:1 relationship)
Environment Tier	Defines the type of application and resources created

Environment Tiers:

Tier	Description	Resources Created
Web Server	Hosts web applications	CNAME URL (Route 53), ELB, Auto Scaling Group of EC2
Worker	Processes background tasks	Auto Scaling Group, SQS Queue (reads messages to scale)

AWS Elastic Beanstalk Deployments

Environment Types:

Single Instance: One EC2 instance with an Elastic IP; good for development only
Load-Balanced: ELB + Auto Scaling Group; for production

Deployment Policies:

Policy	Description	Downtime	Speed
All-at-once	Deploy to all instances simultaneously	Brief downtime	Fastest
Rolling	Deploy to batches of instances sequentially	None	Slower
Rolling with additional batch	Launch new instances, deploy, then remove old	None	Slower
Immutable	Launch new instances, test, then swap	None	Slowest
Blue/Green (URL swap)	Create new environment, deploy, then swap DNS	None	Slowest

Exam tip: URL swapping is the key concept for Blue/Green deployments in Beanstalk. This comes up frequently on the exam.

graph LR
    subgraph "Blue/Green Deployment"
        DNS[Route 53\nCNAME] -->|Before| Blue[Blue Environment\nv1.0]
        DNS -->|After swap| Green[Green Environment\nv2.0]
    end

Module 9 Summary and Exam Tips

Concept	Key Points
Beanstalk	One-stop PaaS; upload code, Beanstalk handles infrastructure
Web server tier	CNAME URL, ELB, ASG for hosting web apps
Worker tier	SQS queue-based; ASG scales with message count
Single instance	Development only; one EC2 + EIP
Load-balanced	Production; ASG + ELB + URL
Blue/Green	URL/CNAME swap; zero downtime; key exam topic
All-at-once	Fastest but causes brief downtime
Immutable	Slowest but zero downtime; safest

Module 10 – AWS Systems Manager

AWS Systems Manager Overview

AWS Systems Manager is a suite of tools for viewing, controlling, and automating managed nodes within AWS, other cloud providers, and on-premises.

Requirements for managed nodes:

SSM Agent installed, configured, and connected
Network connectivity to the Systems Manager service
IAM permissions (attach AmazonSSMManagedInstanceCore policy)

Supported targets:

EC2 instances
Azure VMs
On-premises servers
VMware VMs

Patch Manager and Maintenance Windows

Patch Manager automates patching of managed instances.

Feature	Detail
Windows support	Service packs, OS patches
Linux support	Minor version upgrades, yum/apt packages
Compute support	EC2, edge devices, on-prem servers, third-party VMs
Scan	Identify missing patches, generate report
Scan and Install	Identify AND install patches automatically
Patch baseline	Define which patches to approve/reject
Patch policy	Define patching rules

Maintenance Windows define schedules for performing potentially disruptive actions (patching, updates) on managed nodes.

Automation and Documents

Automation simplifies maintenance, deployment, and remediation tasks.

Types of automation:

Documents (Runbooks): Define the tasks to execute
AWS predefined automations: Ready-to-use for common tasks
Custom automations: Build on top of predefined ones

Example automation tasks:

Disable public access for security groups
Restart EC2 instances (with or without approval)
Configure S3 bucket logging

Triggering automations:

Maintenance Windows (scheduled)
EventBridge (event-based or scheduled)
AWS Config rules (compliance remediation)
Manually via console/CLI

Run Command

Run Command remotely and securely manages managed nodes – executes scripts or commands across multiple instances simultaneously.

Key characteristics:

Executes PowerShell, Bash scripts, or one-time commands
Connects via SSM Agent (no SSH/RDP ports required)
Target by tags, instance IDs, or resource groups
Logs to S3 and CloudWatch Logs

Security note: Sensitive data in commands will be logged in plain text – handle carefully.

Triggering:

Manual (console or CLI)
EventBridge events
Maintenance Windows

Demo: Executing Remote Scripts via Run Command

Demo setup used CloudFormation to deploy 3 EC2 instances tagged with Application: Web.

# run_command_1.sh - Update packages on Amazon Linux
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd

# Verify Apache is running
sudo systemctl status httpd

# run_command_2.sh - Echo instance metadata
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

INSTANCE_ID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id)

echo "Instance ID: $INSTANCE_ID"
echo "Script executed successfully!"

Parameter Store

Parameter Store provides secure, hierarchical storage for configuration data and secrets.

Parameter Types:

Type	Description	Example
String	Plain text value	AMI IDs, usernames, config values
StringList	Comma-separated list	Patch days (Mon,Tue,Wed)
SecureString	KMS-encrypted value	Passwords, API keys, secrets

Hierarchy structure:

/dev/username
/dev/password
/dev/database_host
/prod/username
/prod/password
/prod/database_host

Access control: IAM policies can be scoped to specific paths (e.g., UserA can only access /dev/* parameters).

Demo: Creating and Using Parameters in Parameter Store

Python script to retrieve parameters:

import boto3
from botocore.exceptions import ClientError

def get_parameter(name, with_decryption=False):
    """Fetch a single parameter from Parameter Store."""
    ssm = boto3.client("ssm")
    try:
        response = ssm.get_parameter(
            Name=name,
            WithDecryption=with_decryption
        )
        return response["Parameter"]["Value"]
    except ClientError as e:
        print(f"Failed to get parameter {name}: {e}")
        return None

def get_parameters(name_list):
    """Fetch multiple parameters from Parameter Store."""
    ssm = boto3.client("ssm")
    try:
        response = ssm.get_parameters(
            Names=name_list,
            WithDecryption=True
        )
        parameters = {p["Name"]: p["Value"] for p in response["Parameters"]}
        invalid_params = response.get("InvalidParameters", [])
        if invalid_params:
            print(f"Invalid parameters: {invalid_params}")
        return parameters
    except ClientError as e:
        print(f"Failed to get parameters {name_list}: {e}")
        return None

def main():
    # Fetch /dev/username (String)
    username = get_parameter("/dev/username")
    print(f"Username: {username}")

    # Fetch /dev/application_patch_days (StringList)
    patch_days = get_parameter("/dev/application_patch_days")
    if patch_days:
        patch_days_list = patch_days.split(",")
        print(f"Patch Days: {patch_days_list}")

    # Fetch /dev/password (SecureString - needs decryption)
    password = get_parameter("/dev/password", with_decryption=True)
    print(f"Password: {password}")

if __name__ == "__main__":
    main()

AWS CLI commands for Parameter Store:

# Get dev parameters
username=$(aws ssm get-parameter \
  --name "/dev/username" \
  --query "Parameter.Value" --output text)

patch_days=$(aws ssm get-parameter \
  --name "/dev/patch_days" \
  --query "Parameter.Value" --output text)

# Get SecureString (requires --with-decryption)
password=$(aws ssm get-parameter \
  --name "/dev/password" \
  --with-decryption \
  --query "Parameter.Value" --output text)

echo "Username: $username"
echo "Patch Days: $patch_days"
echo "Password: $password"

Module 10 Summary and Exam Tips

Tool	Purpose
Patch Manager	Automatically patch Windows and Linux managed nodes
Maintenance Windows	Schedule for potentially disruptive actions
Automation	Runbooks for maintenance/remediation; triggers via EventBridge/Config
Run Command	Execute scripts/commands across managed nodes at scale
Parameter Store	Secure storage for config data and secrets
Session Manager	Secure SSH/RDP replacement (covered in another course)

Two requirements for managed nodes:

SSM Agent installed + network connectivity
IAM permissions (AmazonSSMManagedInstanceCore)

Module 11 – Amazon SQS and Amazon SNS

Decoupled Architectures

Tightly coupled architecture: Components depend heavily on each other. One component failure can cascade.

Loosely coupled (decoupled) architecture: Components are less dependent. Changes and failures have minimal impact. Uses messaging queues as buffers between layers.

graph TD
    subgraph Tightly Coupled
        FE1[Frontend] -->|Direct call| BE1[Backend]
    end
    
    subgraph Loosely Coupled
        FE2[Frontend] --> MQ[Message Queue\nSQS]
        MQ --> BE2[Backend]
    end

Benefits of decoupling:

Resilience to failures
Independent scaling
Asynchronous processing
Buffering during traffic spikes

Amazon SQS Overview

Amazon SQS (Simple Queue Service) is the go-to messaging queue service for asynchronous processing.

Key characteristics:

Pull-based system (consumers poll the queue)
Producer sends → Queue buffers → Consumer pulls
Builds a buffer between components
Standard: at-least-once delivery, best-effort ordering
FIFO: exactly-once delivery, strict ordering

graph LR
    Producer[Producer\nApplication] -->|Send message| SQS[SQS Queue]
    SQS -->|Poll| Consumer1[Consumer 1\nEC2 / Lambda]
    SQS -->|Poll| Consumer2[Consumer 2\nEC2 / Lambda]

Amazon SQS Queues

Feature	Standard Queue	FIFO Queue
Delivery	At-least-once (possible duplicates)	Exactly-once
Ordering	Best-effort (not guaranteed)	Strict FIFO ordering
Throughput	Nearly unlimited	300 msg/sec; 3,000 with batching
Deduplication	Not supported	Content-based or deduplication ID
Max message size	256 KB	256 KB
Storage	Multi-AZ	Multi-AZ
Use case	High throughput, duplicates ok	Ordered processing, no duplicates

Tip: FIFO queue names must end in .fifo

SQS Queue Attributes

Attribute	Description	Default	Max
Delivery Delay	Delay before message becomes visible	0 seconds	15 minutes
Message Retention	How long message stays in queue	4 days	14 days
Visibility Timeout	Time a consumed message is hidden from other consumers	30 seconds	12 hours
Max Message Size	Maximum size per message	256 KB	256 KB
Short Polling	Default; immediate return even if queue empty	Default	–
Long Polling	Wait up to 20 seconds for messages; reduces empty responses	Off	20 seconds

Important: Short polling causes empty responses and increased API call costs. Use long polling to reduce costs.

Extended Client Library: For messages > 256 KB, store payload in S3 and put the S3 reference in the SQS message.

Example Architecture: Scaling ASGs Using Amazon SQS

graph LR
    API[API Gateway] --> SQS[SQS Queue]
    SQS -->|ReceiveMessage| ASG[Auto Scaling Group\nEC2 Instances]
    SQS -->|ApproximateNumberOfMessages| CW[CloudWatch Alarm]
    CW -->|Scale Out trigger| ASG
    ASG -->|Process & DeleteMessage| SQS

How it works:

Messages arrive via API Gateway to the SQS queue
EC2 instances in the ASG poll the queue, process messages, delete them
CloudWatch monitors ApproximateNumberOfMessages metric
When metric breaches threshold, CloudWatch alarm triggers ASG scale out
When queue drains, alarm clears and ASG scales in

Dead Letter Queues

Dead Letter Queues (DLQs) capture messages that cannot be processed successfully.

Key facts:

DLQ for a FIFO queue must also be a FIFO queue
DLQ for a standard queue must be a standard queue
Works with both SQS and SNS
Messages are moved to DLQ after exceeding the maxReceiveCount

Use cases:

Debugging failed message processing
Analyzing problematic message contents
Long-term message retention for investigation (up to 14 days)

graph LR
    Producer --> SQS[SQS Queue]
    SQS -->|Normal processing| Consumer[Consumer]
    SQS -->|After N failures| DLQ[Dead Letter Queue]
    DLQ --> Debug[Debug / Analysis]

Demo: Sending Messages to an Amazon SQS Queue

Lambda function to process SQS messages:

import json

def lambda_handler(event, context):
    print("Lambda function triggered by SQS Standard Queue.")

    for record in event['Records']:
        message_body = record['body']
        message_id = record['messageId']
        receipt_handle = record['receiptHandle']
        attributes = record.get('attributes', {})

        print("============================")
        print("New Message Received:")
        print("============================")
        print(f"Message ID: {message_id}")
        print(f"Receipt Handle: {receipt_handle}")
        print("Attributes:")
        for key, value in attributes.items():
            print(f"  {key}: {value}")
        print("Body:")
        print(
            json.dumps(json.loads(message_body), indent=4)
            if is_json(message_body) else message_body
        )
        print("============================")

    return {
        "statusCode": 200,
        "body": f"Processed {len(event['Records'])} messages."
    }

def is_json(mystring):
    """Check if a string is valid JSON."""
    try:
        json.loads(mystring)
    except ValueError:
        return False
    return True

Amazon SNS (Simple Notification Service) is the go-to push-based messaging service for cloud-native applications.

Key characteristics:

Push-based system (server pushes to subscribers)
Proactively delivers messages to subscribed endpoints
Supports one-to-one or one-to-many delivery
Producer sends to SNS Topic → SNS pushes to all subscribers

Key difference from SQS: In SQS, a pulled message is consumed and removed. In SNS, all subscribers receive the same message.

Use cases:

Alerting systems
Event-driven near real-time workloads

Feature	Standard Topic	FIFO Topic
Topics per account	100,000	1,000
Subscriptions	12.5 million per topic	100 per topic
Message replay	Not supported	Supported
Throughput	Nearly unlimited	300 msg/sec

Supported subscription endpoints:

HTTP/HTTPS
Email / Email-JSON
SQS (most common)
Lambda
SMS
Mobile Push
Amazon Kinesis Data Firehose

The most important endpoint types for the exam: SQS and Lambda.

SNS Fanout = multiple subscribers on the same topic; messages sent to multiple endpoints simultaneously.

graph LR
    App[Application\nPrice Update] --> SNS[SNS Topic]
    SNS --> SQS1[SQS Queue\nStore A]
    SNS --> SQS2[SQS Queue\nStore B]
    SNS --> SQS3[SQS Queue\nAnalytics]
    SQS1 --> Worker1[Worker App A]
    SQS2 --> Worker2[Worker App B]
    SQS3 --> Analytics[Analytics Engine]

Benefits:

Fully decoupled
Parallel processing
Asynchronous
Each subscriber processes the same message independently

Demo: Sending Notifications through Amazon SNS

Lambda function to restore an S3 object after deletion (triggered via SNS):

import json
import boto3
from botocore.exceptions import ClientError

s3 = boto3.client('s3')

def lambda_handler(event, context):
    try:
        # Parse the SNS message
        sns_message = event['Records'][0]['Sns']['Message']
        s3_event = json.loads(sns_message)

        bucket_name = s3_event['Records'][0]['s3']['bucket']['name']
        object_key = s3_event['Records'][0]['s3']['object']['key']
        object_key = object_key.replace('+', ' ')  # Handle URL-encoded keys

        print(f"Triggered by SNS for bucket: {bucket_name}, object: {object_key}")

        # Find the delete marker
        response = s3.list_object_versions(Bucket=bucket_name, Prefix=object_key)
        delete_markers = response.get('DeleteMarkers', [])

        for marker in delete_markers:
            if marker['Key'] == object_key and marker['IsLatest']:
                delete_marker_version_id = marker['VersionId']
                print(f"Found delete marker: {delete_marker_version_id}")

                # Remove the delete marker to restore the object
                s3.delete_object(
                    Bucket=bucket_name,
                    Key=object_key,
                    VersionId=delete_marker_version_id
                )
                print(f"Delete marker removed. Object {object_key} restored.")
                return {
                    "statusCode": 200,
                    "body": f"Successfully restored {object_key}."
                }

        print(f"No delete marker found for {object_key}")
        return {"statusCode": 404, "body": f"No delete marker found for {object_key}."}

    except ClientError as e:
        print(f"Error restoring object: {e}")
        return {"statusCode": 500, "body": f"Error: {str(e)}"}
    except Exception as e:
        print(f"Unexpected error: {e}")
        return {"statusCode": 500, "body": f"Unexpected error: {str(e)}"}

Architecture:

graph LR
    S3[S3 Bucket\nVersioning enabled] -->|ObjectRemoved event| SNS[SNS Topic]
    SNS --> Email[Ops Team Email\nSubscription]
    SNS --> Lambda[Lambda Function\nRestore Object]
    Lambda -->|Remove delete marker| S3

Module 11 Summary and Exam Tips

Four questions to ask on the exam:

Synchronous or asynchronous processing needed?
Push-based or pull-based messaging?
Does message order matter? → FIFO vs Standard
Are duplicates acceptable? → FIFO vs Standard

Service	Key Points
SQS	Pull/poll-based; async; queue; at-least-once (Standard); exactly-once (FIFO)
SNS	Push-based; topic; fan-out; one-to-many
SQS Standard	Unlimited throughput; possible duplicates; unordered
SQS FIFO	300 msg/sec; no duplicates; strict ordering
DLQ	Capture failed messages; same type as source queue
Long polling	Reduces empty API calls; reduces costs
SNS Fanout	One message → multiple SQS queues/Lambda functions

Module 12 – Amazon Kinesis

Amazon Kinesis Overview

Amazon Kinesis allows ingesting, processing, and analyzing real-time and near real-time streaming data and video. It is a pull-based streaming platform.

The four Kinesis offerings:

Service	Use Case
Kinesis Data Streams	Real-time data streaming (< 1 second latency)
Amazon Data Firehose	Near real-time data loading to destinations
Kinesis Data Analytics for SQL	Analyze streaming data with SQL
Kinesis Video Streams	Stream/store live video

Key indicator: Real-time streaming → Data Streams. Near real-time loading → Data Firehose.

Amazon Kinesis Data Streams

Kinesis Data Streams enable real-time streaming data ingestion.

Key concepts:

Concept	Description
Shard	Unit of capacity in a stream; holds sequenced data records
Data Record	Unit of data in a stream; up to 1 MB per record
Producer	Application pushing data to the stream (constantly streaming)
Consumer	Application processing data in real time
Retention	24 hours default; up to 365 days

Shard limits:

Write: 1,000 records/second OR 1 MB/second (either/or)
Read: 5 transactions/second OR 2 MB/second (either/or)

Key characteristics:

Data is never deleted until retention period expires
Guaranteed ordering within a shard
Multiple consumers can read the same data

graph LR
    P1[Producer 1\nIoT Device] --> KDS[Kinesis Data Stream]
    P2[Producer 2\nApp] --> KDS
    KDS --> S1[Shard 1]
    KDS --> S2[Shard 2]
    KDS --> S3[Shard 3]
    S1 --> C1[Consumer 1\nReal-time App]
    S2 --> C2[Consumer 2\nLambda]
    S3 --> C3[Consumer 3\nAnalytics]

Kinesis Data Stream Consumers and Producers

Producers use the Kinesis Producer Library (KPL):

Simplifies data ingestion
Handles aggregation, metric collection (CloudWatch), and retries
Perfect for EC2 instances writing thousands of events/second

Consumers use the Kinesis Client Library (KCL):

Standalone Java library
Simplifies consuming from streams
Handles checkpointing, load balancing between consumers
Uses DynamoDB for tracking stream position

Data Stream Capacity Modes

Mode	Description	Best For
On-Demand	Automatically scales shards; scales to gigabytes/minute	Variable/unpredictable traffic
Provisioned	Manually set shard count; control costs precisely	Predictable traffic patterns

On-demand pricing: Based on GB of data written and read.

Amazon Data Firehose Overview

Amazon Data Firehose is a fully managed, serverless service for near real-time data loading to destinations.

Key characteristics:

Fully managed, automatic scaling
Native transformation using Lambda functions
Pay only for what you use

Common destinations:

Amazon S3 buckets
Amazon Redshift tables
Amazon OpenSearch Service clusters
Third-party providers (Splunk, Datadog, etc.)

graph LR
    IoT[IoT Devices] --> APIGW[API Gateway]
    APIGW --> KDS[Kinesis Data Streams\nReal-time]
    KDS --> KDF[Data Firehose\nNear real-time]
    KDF -->|Transform| Lambda[Lambda]
    Lambda --> KDF
    KDF --> S3[Amazon S3]
    KDF --> RS[Amazon Redshift]
    KDF --> OS[OpenSearch]

Firehose Streams

Three data source types for Firehose:

Direct PUT: Producer writes directly via AWS SDK, CloudWatch, SNS, AWS IoT, Kinesis Agent
Kinesis Data Streams: Use a Data Stream as source; enables real-time → near real-time pipeline
MSK (Managed Streaming for Kafka): Use MSK as source

Amazon Kinesis Data Analytics

Kinesis Data Analytics for SQL Applications processes streaming data using SQL.

Reads from Data Streams or Firehose streams
Outputs to Data Streams, Firehose, Lambda
Supports pre-processing with Lambda
Note: This service is being deprecated; may still appear on the exam

Exam tip: “Analyze streaming data with SQL” → Kinesis Data Analytics.

Amazon Kinesis Video Streams

Kinesis Video Streams streams and stores live video from devices to AWS.

Use cases:

Real-time video processing
Batch video analytics

Exam tip: Need to capture large amounts of live video data globally → Kinesis Video Streams.

Module 12 Summary and Exam Tips

SQS vs SNS vs Kinesis comparison:

	SQS	SNS	Kinesis
Type	Pull-based queue	Push-based topic	Pull-based stream
Real-time	No	No	Yes (Data Streams)
Ordering	FIFO only	FIFO only	Yes (within shard)
Replay	No	FIFO only	Yes (retention period)
Complexity	Simple	Simple	Complex (big data)

Kinesis Data Streams retention: Up to 365 days. Data never deleted until retention expires.

Kinesis Service	Key Indicator
Data Streams	Real-time (< 1 sec); ordered; replay; big data ingestion
Data Firehose	Near real-time; load to S3/Redshift/OpenSearch; serverless
Data Analytics	SQL against streaming data (being deprecated)
Video Streams	Live video streaming; batch video analytics

Module 13 – Amazon MSK and Amazon MQ

Amazon Managed Streaming for Apache Kafka (MSK)

Amazon MSK is a fully managed service for running data streaming applications that use Apache Kafka.

Exam tip: If you need Apache Kafka → use Amazon MSK.

Key characteristics:

Manages control-plane operations (create, update, delete clusters)
Deploys across multiple AZs
Manages broker nodes and Zookeeper nodes
Alternative to Amazon Kinesis (when Kafka-specific requirements exist)

When to use MSK vs Kinesis:

New application, no Kafka requirements → Kinesis (simpler)
Existing Kafka workloads or Kafka-specific requirements → MSK

MSK key features:

MSK Serverless: No capacity planning; AWS manages infrastructure
Multi-AZ deployments: High availability
Public network access: Deploy nodes in public subnets for direct access
Larger message sizes than Kinesis
Plain text data support (Kinesis always encrypts in transit)

Amazon MQ

Amazon MQ is a managed message broker service for migrating existing on-premises messaging systems to the cloud.

Supported engine types:

Apache ActiveMQ
RabbitMQ

Exam tip: If you see ActiveMQ or RabbitMQ → Amazon MQ.

When to use Amazon MQ vs SNS/SQS:

Migrating existing applications that use industry-standard protocols (AMQP, STOMP, OpenWire) → Amazon MQ
New cloud-native applications → SNS/SQS (simpler, more scalable)

Availability options:

Engine	HA Option
ActiveMQ	Active/Standby (2 nodes in separate AZs; separate maintenance windows)
RabbitMQ	Cluster deployment (3 broker nodes across AZs)

Key limitation: MQ is not as scalable as SNS/SQS because it has actual infrastructure components to manage.

Module 13 Summary and Exam Tips

Service	When to Use
MSK	Apache Kafka workloads; large message sizes; plain text support
MSK Serverless	Kafka without capacity planning
Amazon MQ	Migrate existing ActiveMQ/RabbitMQ apps to cloud

Comparison:

	MSK	Kinesis
Message size	Larger	Up to 1 MB
Encryption	Optional (plain text ok)	Always encrypted in transit
Protocol	Kafka topics/partitions	Kinesis shards
Use case	Kafka-specific workloads	AWS-native streaming

Module 14 – Amazon Step Functions and AWS Batch

AWS Step Functions

AWS Step Functions is a serverless orchestration service for complex, multi-step workflows.

Primary use case: Orchestrating Lambda functions working together in serverless workflows.

Key capabilities:

Feature	Description
Retries	Automatically retry failed steps
Parallel execution	Run multiple workflows simultaneously
Human approval	Pause workflow for human review/approval
Error handling	Built-in error handling with catch states
Branching	Conditional logic (Choice state)

State types:

State	Description
Task	Executes an action (Lambda, ECS, DynamoDB, etc.)
Choice	Conditional branching
Wait	Pause execution for a duration
Parallel	Run branches simultaneously
Map	Iterate over a collection
Pass	Pass input to output unchanged
Succeed / Fail	Terminal states

stateDiagram-v2
    [*] --> ValidateOrder
    ValidateOrder --> CheckDiscount: valid
    ValidateOrder --> FailOrder: invalid
    CheckDiscount --> ApplyDiscount: has coupon
    CheckDiscount --> ProcessOrder: no coupon
    ApplyDiscount --> ProcessOrder
    ProcessOrder --> NotifyCustomer
    NotifyCustomer --> [*]
    FailOrder --> [*]

Supported integrations (most common on exam):

Lambda functions
API Gateway
Amazon EventBridge
SQS, SNS
ECS tasks
DynamoDB
Glue, Athena

Demo: Orchestrate Workflows Using AWS Step Functions

Architecture:

ApplyDiscount Lambda: Checks if coupon code is valid; applies discount
ProcessOrder Lambda: Confirms order was processed successfully
SQS Queue: Receives processed orders
SNS Topic: Sends email notifications

Sample order JSON for testing:

{
  "orderId": "ORD-001",
  "item": "Widget",
  "price": 100.00,
  "couponCode": "SAVE10"
}

{
  "orderId": "ORD-002",
  "item": "Gadget",
  "price": 50.00
}

AWS Batch

AWS Batch is a fully managed batch processing service that runs workloads on EC2 (On-Demand or Spot), ECS containers, or Fargate tasks.

Key characteristics:

No time limit (unlike Lambda’s 15 minutes)
Automatically provisions required compute
Submit jobs on-demand or schedule them
No need to install or maintain batch computing software

Key concepts:

Concept	Description
Job	Unit of work (shell script, executable, Docker image)
Job Definition	Specifies how jobs run (resources, retry, container)
Job Queue	Jobs wait here until scheduled to run
Compute Environment	EC2, Spot, or Fargate resources running the jobs

Module 14 Summary and Exam Tips

Lambda vs AWS Batch:

	Lambda	AWS Batch
Max execution time	15 minutes	No limit
Disk space	Limited (512 MB /tmp)	Dependent on compute
Runtime	Fixed built-in runtimes	Any (Docker-based)
Use case	Short event-driven tasks	Long-running batch processes
Compute	Serverless (no instances)	EC2, Spot, Fargate

Exam tip: Long-running batch jobs that exceed 15 minutes → AWS Batch. Short event-driven → Lambda.

Step Functions key points:

Serverless workflow orchestration
Primarily for Lambda function coordination
Supports: retries, parallel execution, human approval, error handling
Common integrations: Lambda, API Gateway, EventBridge

Module 15 – Application and Network Caching

Amazon CloudFront Overview

Amazon CloudFront is a CDN (Content Delivery Network) that caches content at edge locations globally.

How it works:

User requests content → nearest edge location checked
Cache Hit: Content returned directly from edge (fast)
Cache Miss: Check regional edge cache → if miss, fetch from origin
Content stored at edge for future requests

graph LR
    User[User\nGlobal] --> EL[Edge Location\nNearest POP]
    EL -->|Cache miss| REC[Regional Edge Cache]
    REC -->|Cache miss| Origin[Origin\nS3 / ALB / API GW]
    Origin --> REC
    REC --> EL
    EL --> User

Key features:

Integrates with AWS Shield for DDoS protection
Integrates with AWS WAF for application firewall
Supports HTTPS and custom domain names with ACM certificates
Reduces latency for global users

Amazon CloudFront Origins

Origin: The source location where CloudFront fetches content.

Common origins:

Amazon S3 buckets (static content, websites)
Application Load Balancers
API Gateway
VPC Origins (EC2, EIPs)
Custom HTTP endpoints

Distribution: CloudFront configuration defining:

Origin server
Cache behaviors
Security settings (HTTPS, OAC)
Geographic restrictions
Logging

Amazon CloudFront Security

Origin Access Control (OAC) – recommended approach to secure S3 origins:

Not an IAM role or user; a CloudFront-specific entity
Use S3 bucket policies to authorize access for the CloudFront distribution
Supports both GET and PUT operations

Origin Access Identity (OAI) – legacy approach:

Still supported; may appear on exam
Only for GET operations
Being replaced by OAC

Example S3 bucket policy for OAC:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

Other security features:

Geo-restrictions: Block/allow specific countries
Signed URLs: Restrict access to specific files
Signed Cookies: Restrict access to multiple files
AWS WAF: Web Application Firewall integration
AWS Shield: Standard (automatic) and Advanced DDoS protection

CloudFront Custom Domain Names and TLS

Default domain: xxxxx.cloudfront.net (supports HTTPS by default)

Custom domain + HTTPS requirements:

Request certificate in AWS Certificate Manager (ACM)
ACM certificate MUST be in us-east-1 (regardless of CloudFront distribution region)
Create custom domain name in CloudFront → assign ACM certificate
Create Route 53 alias record pointing to the CloudFront distribution

Viewer Protocol Policy options:

HTTP and HTTPS
Redirect HTTP to HTTPS (recommended)
HTTPS only

Demo: Setting up an S3 Bucket Origin in CloudFront

Steps:

Create an S3 bucket and upload content (e.g., image.png)
Create a CloudFront distribution → select S3 bucket as origin
Create an OAC (Origin Access Control)
CloudFront auto-generates a bucket policy – apply it to S3
Configure custom domain in Route 53 (alias record)
Test access via both CloudFront URL and custom domain

CloudFront origin types for the exam:

S3 – static assets
ELB – dynamic applications
API Gateway – API-fronted applications
VPC – EC2 instances and Elastic IPs

CloudFront Functions and Lambda@Edge Functions

Both are edge functions that execute custom logic close to end users.

Request/response flow phases:

graph LR
    VReq[Viewer Request] --> CF[CloudFront]
    CF --> OReq[Origin Request]
    OReq --> Origin[Origin Server]
    Origin --> OResp[Origin Response]
    OResp --> CF
    CF --> VResp[Viewer Response]
    VResp --> Viewer[Viewer/User]

Comparison:

Feature	CloudFront Functions	Lambda@Edge
Runtime	JavaScript only	Node.js, Python
Execution time	< 1 ms	5-30 seconds
Scale	Millions req/sec	Thousands req/sec
Phases	Viewer Request/Response only	All 4 phases
Memory	2 MB	128 MB - 10 GB
Cost	Very low	Higher
Use case	High-scale CDN customization	Complex processing at edge

Common CloudFront Function use cases:

URL rewrites/redirects
Add/modify HTTP headers
A/B testing (weighted traffic)
JWT token validation (simple)

Common Lambda@Edge use cases:

Dynamic content generation
Server-side rendering
Complex authentication/authorization
Database queries at the edge

AWS Global Accelerator

AWS Global Accelerator routes traffic through AWS’s global network infrastructure using anycast IP addresses.

Key characteristics:

Provides 2 static anycast IP addresses for global endpoints
Routes traffic via edge locations → AWS global network → endpoints
Primarily for TCP or UDP traffic (Layer 4 focus – NOT HTTP like CloudFront)
Supports static IP for whitelisting/firewalls

Global Accelerator vs CloudFront:

	CloudFront	Global Accelerator
Protocol	HTTP/HTTPS (Layer 7)	TCP/UDP (Layer 4)
Caching	Yes	No
Static IPs	No	Yes (2 anycast IPs)
Use case	Web content, APIs	Gaming, IoT, VoIP, multi-region failover
Failover control	Limited	Fine-grained

Supported endpoints:

Elastic IP addresses
Application Load Balancers
Network Load Balancers
EC2 instances

AWS Global Accelerator Security and Health Checks

Health checks:

Automatically checks configured endpoints
Routes traffic only to healthy endpoints
Uses Route 53 health checker data
Customizable: protocol, port, timeout, interval

Security:

DDoS protection via AWS Shield Standard (automatic)
ALBs, NLBs, EC2 endpoints behind Global Accelerator do not need to be internet-facing directly
Traffic from health checkers must be allowed in security groups and NACLs

Amazon ElastiCache

Amazon ElastiCache is a managed, distributed in-memory caching service for applications.

Supported engines:

Memcached: Simple, multi-threaded, no persistence
Redis: Rich data structures, persistence, pub/sub, replication
Valkey: Redis-compatible open-source fork

Key characteristics:

For heavy, repeated read requests
Reduces database load
Requires code changes to implement (not a drop-in solution)
Access controlled via security groups

Use cases:

Use Case	Description
Database query caching	Cache frequently accessed query results
Session storage	Store user sessions in distributed web apps
API response caching	Cache common API responses
Leaderboards	Real-time scoring with Redis sorted sets

Redis vs Memcached:

	Redis	Memcached
Persistence	Yes	No
Replication	Yes (multi-AZ)	No
Data structures	Rich (lists, sets, hashes, sorted sets)	Simple key-value
Pub/Sub	Yes	No
Use case	Session store, leaderboards, complex data	Simple caching

Exam tip: ElastiCache requires code changes. If the exam says “no code changes required” → ElastiCache is NOT the answer.

Module 15 Summary and Exam Tips

Four questions to ask:

Can the content be cached? What type of cache is needed?
Application caching or network caching?
How is content updated/retrieved? Static IPs needed?
Any security requirements? (WAF, Shield, OAC)

Service	When to Use
CloudFront	Cache HTTP/HTTPS content globally; reduce latency
Global Accelerator	TCP/UDP; static IPs; multi-region failover
ElastiCache	Application-level caching; reduce DB load

CloudFront key exam points:

OAC/OAI for S3 origin security
ACM certs must be in us-east-1 for CloudFront
Geo-restrictions, WAF, Shield integration
CloudFront Functions (lightweight JS) vs Lambda@Edge (complex logic, all phases)

Module 16 – Miscellaneous Services

Amazon Pinpoint

Amazon Pinpoint enables customer engagement through multiple messaging channels.

Primary audiences:

Marketing teams
Business users sending targeted communications

Messaging channels:

Email
SMS (send and receive)
Push notifications
Voice messages
In-app messaging

Exam indicators:

Marketing campaigns
User engagement tracking
Sending emails to targeted audiences
SMS with reply tracking

graph LR
    App[Your Application] --> PP[Amazon Pinpoint]
    PP --> Email[Email campaigns]
    PP --> SMS[SMS with replies]
    PP --> Push[Mobile push notifications]
    PP --> S3[Store responses\nin S3]

AWS Amplify

AWS Amplify provides tools and libraries for front-end web and mobile developers to build full-stack applications.

What Amplify provides:

Plug-and-play front-end libraries and UI components
Back-end building services (no infrastructure management)
Front-end hosting
Built-in authentication and authorization

Amplify Hosting:

Git-based workflow for continuous deployment
Supports: React, Angular, Vue, Next.js, Gatsby, Hugo, and more
Supports server-side rendering (SSR) – not possible with S3 static hosting

Exam tip: Simplified full-stack development for less-experienced teams, especially when server-side rendering is needed → AWS Amplify.

Supported frameworks:

Next.js (SSR)
Nuxt.js
SvelteKit
React
Vue
Angular

AWS Device Farm

AWS Device Farm is a service for testing Android, iOS, and web applications on real devices hosted by AWS.

Two testing methods:

Method	Description
Automated	Upload test scripts; run parallel tests on multiple devices
Remote Access	Remotely access real devices via browser; swipe, gesture, interact manually

Exam indicators:

App testing on mobile devices in AWS
Automated testing requiring actual phones/tablets
Testing Android, iOS, or mobile web browsers

AWS Wavelength

AWS Wavelength deploys compute and storage to the edge of 5G cellular carrier networks for ultra-low latency to mobile devices.

How it works:

Extends VPCs into Wavelength Zones (carrier-specific edge zones)
Deploys standard EC2, ECS, etc. at carrier edge
Examples: Verizon, Vodafone

Exam indicators:

5G networking requirements
Ultra-low latency to mobile/edge devices
Cellular carrier-specific deployments

Do not confuse with: Local Zones (which are for data sovereignty/regulatory requirements or proximity to specific cities).

Amazon AppFlow

Amazon AppFlow provides fully managed integration for securely exchanging data between SaaS applications and AWS services.

Key characteristics:

No-code/low-code data integration
Supports most common SaaS providers
Schedule, event-based, or on-demand triggers

Supported sources:

Salesforce
Zendesk
ServiceNow
SAP
Google Analytics
Many more

Supported destinations:

Amazon S3
Amazon Redshift
Other SaaS services

Trigger options:

Scheduled (recurring)
Event-based (EventBridge)
On-demand (one-time)

graph LR
    Salesforce[Salesforce] --> AF[Amazon AppFlow]
    Zendesk[Zendesk] --> AF
    ServiceNow[ServiceNow] --> AF
    AF --> S3[Amazon S3]
    AF --> RS[Amazon Redshift]
    AF --> Other[Other SaaS]

Amazon Simple Email Service (SES)

Amazon SES is a cost-effective email platform for sending and receiving emails at scale.

Key features:

Use your own email addresses and domains
DKIM support (key exam indicator for email)
Send from: EC2, on-premises VMs, ECS containers, Lambda functions (via API call)
Statistics: bounces, complaints, successful deliveries

Exam indicators:

Email delivery at scale
DKIM requirements
Reducing complex email delivery issues with minimal operational overhead

SES vs Pinpoint for email: If you see “targeted audiences” or “marketing campaigns” → Pinpoint. If you see “email delivery infrastructure” or “DKIM” → SES.

Module 16 Summary and Exam Tips

Service	Key Indicators
Pinpoint	Marketing campaigns, user engagement tracking, targeted audiences, SMS replies
Amplify	Full-stack serverless web apps, server-side rendering, continuous deployment
Device Farm	Mobile app testing on real devices hosted by AWS
Wavelength	5G cellular network edge computing
AppFlow	SaaS ↔ AWS data transfer (Salesforce, Zendesk, ServiceNow)
SES	Large-scale email sending/receiving, DKIM support

Quick Reference: Service Decision Trees

Load Balancer Selection

graph TD
    Need[Load Balancer Needed?] --> Layer7{HTTP/HTTPS\nrequired?}
    Layer7 -->|Yes| ALB[Application Load Balancer\nLayer 7]
    Layer7 -->|No| Static{Static IP\nor high performance?}
    Static -->|Static IP needed| NLB[Network Load Balancer\nLayer 4]
    Static -->|Security appliance| GWLB[Gateway Load Balancer\nLayer 3 / GENEVE]

Decoupling Pattern Selection

graph TD
    Decouple[Need to Decouple?] --> RT{Real-time\nstreaming?}
    RT -->|Yes| Kinesis[Amazon Kinesis\nData Streams]
    RT -->|No| Push{Push or Pull\nbased?}
    Push -->|Push| SNS[Amazon SNS]
    Push -->|Pull| FIFO{Order/No\nduplicates?}
    FIFO -->|Yes| SQSF[SQS FIFO Queue]
    FIFO -->|No| SQSS[SQS Standard Queue]
    Push -->|Apache Kafka| MSK[Amazon MSK]
    Push -->|ActiveMQ/RabbitMQ| MQ[Amazon MQ]

Compute Service Selection

graph TD
    Compute[Choose Compute Service] --> Duration{Execution\ntime < 15 min?}
    Duration -->|Yes| Servers{Need servers?}
    Duration -->|No| Batch[AWS Batch]
    Servers -->|No| Lambda[AWS Lambda]
    Servers -->|Yes| Container{Container\nworkload?}
    Container -->|Yes| Kubernetes{Kubernetes\nrequired?}
    Container -->|No| BeanOrEC2{Full managed\nPaaS?}
    Kubernetes -->|Yes| EKS[Amazon EKS]
    Kubernetes -->|No| ECS[Amazon ECS]
    BeanOrEC2 -->|Yes| Beanstalk[Elastic Beanstalk]
    BeanOrEC2 -->|No| EC2[Amazon EC2]

Caching Selection

graph TD
    Cache[Caching Needed?] --> Type{Application\nor Network?}
    Type -->|Application| ElastiCache[Amazon ElastiCache\nRedis/Memcached]
    Type -->|Network| Protocol{TCP/UDP\nor HTTP?}
    Protocol -->|HTTP/HTTPS| CloudFront[Amazon CloudFront]
    Protocol -->|TCP/UDP| GA[AWS Global Accelerator]

Search Terms

aws · certified · architect · associate · saa-c03 · scaling · decoupling · architectures · core · services · amazon · web · exam · load · elastic · lambda · gateway · service · api · auto · cloudformation · sqs · cloudfront · data

Table of Contents

Module 1 – Elastic Load Balancing

Reviewing AWS Global Infrastructure

Elastic Load Balancing (ELB) Introduction

Application Load Balancers (ALB)

Demo: Setting up an Application Load Balancer

Network Load Balancers (NLB)

Demo: Setting up a Network Load Balancer

Gateway Load Balancers (GWLB)

Elastic Load Balancing Optimization

Session Affinity (Sticky Sessions)

Connection Draining / Deregistration Delay

Cross-Zone Load Balancing

Demo: Setting up an HTTPS Listener

Module 1 Summary and Exam Tips

Module 2 – Auto Scaling and High-Availability

Horizontal Versus Vertical Scaling

Auto Scaling Groups (ASGs)

Demo: Create a Launch Template and Auto Scaling Group

Auto Scaling Group Scaling Policies

Auto Scaling Group Health Checks

ASG Instance Maintenance Policies

Demo: Fronting an Auto Scaling Group with an ELB

Demo: Creating and Using a Dynamic Scaling Policy

Auto Scaling Group Lifecycle Hooks

Demo: Trigger Log Storage via a Lifecycle Hook

Improving Service Connectivity Using VPC Lattice

Module 2 Summary and Exam Tips

Module 3 – Containers and Images

Containers and Images Overview

Amazon Elastic Container Registry (ECR)

Amazon Elastic Container Service (ECS) Overview

Amazon ECS Tasks, Task Definitions, and IAM Roles

Load Balancing Amazon ECS

Demo: Creating an ECR Repository

Demo: Creating a Load Balanced ECS Cluster

Amazon ECS Storage

Amazon Elastic Kubernetes Service (EKS) Overview

Amazon EKS Data Storage

Securing Amazon EKS

Amazon EKS Distro

Amazon ECS and Amazon EKS Anywhere

AWS App Runner

AWS App2Container

Module 3 Summary and Exam Tips

Module 4 – AWS Lambda

AWS Lambda Overview

Configuring Lambda Functions

Demo: Creating and Invoking a Lambda Function

Lambda Function Networking

Demo: Configure a Lambda Function for VPC Access

Lambda Function Concurrency

Lambda SnapStart

Important Lambda Features

Versions

Aliases

Module 4 Summary and Exam Tips

Module 5 – Event-driven Architectures

Amazon RDS Events

Amazon S3 Events

Amazon EventBridge

Amazon EventBridge Event Buses

Amazon EventBridge Events

Demo: Trigger Workloads Using Amazon EventBridge

Module 5 Summary and Exam Tips

Module 6 – Amazon API Gateway, AWS AppSync, and AWS X-Ray

Amazon API Gateway Overview

Amazon API Gateway Authentication and Security

Amazon API Gateway Integrations

Amazon API Gateway Deployments and Versions

Demo: Creating a REST API Using Amazon API Gateway

Demo: Using TLS and Custom Domain Names for API Gateway

AWS AppSync

Debug Applications Using AWS X-Ray

Module 6 Summary and Exam Tips

Module 7 – Serverless Authentication with Amazon Cognito

Amazon Cognito Overview

Amazon Cognito User Pools

Amazon Cognito Identity Pools

Module 7 Summary and Exam Tips