AWS Solutions Architect Associate

By the end of this lab you will be able to:

1. Explain the AWS Shared Responsibility Model
2. Secure a root account with MFA
3. Create a least-privilege IAM administrative user (for learning)
4. Set up billing alarms and budgets so you never get surprised
5. Install and correctly configure the AWS CLI with a named profile
6. Verify your identity from the command line

Shared Responsibility Model

Key takeaway: AWS secures of the cloud. You secure in the cloud.

Global Infrastructure Hierarchy

• Region = geographic area. Choose one close to you or your users. Data does not leave a Region unless you explicitly move it.
• Availability Zone (AZ) = one or more discrete data centers with redundant power, networking, and connectivity. Designed to be isolated from failures in other AZs.
• Edge Location = CDN points of presence (CloudFront).

For this entire course we will primarily use one Region (recommend us-east-1 or the Region closest to you). Multi-Region comes later if needed.

Steps (AWS Console)

1. Go to aws.amazon.com and sign in (or create a new account).
2. Immediately go to the account dropdown (top right) → Security credentials.
3. Under Multi-factor authentication (MFA), click Assign MFA device.
4. Choose Authenticator app (recommended) or Hardware MFA.
5. Scan the QR code with your authenticator app (Google Authenticator, Authy, 1Password, Bitwarden, etc.).
6. Enter two consecutive MFA codes.
7. Download / save the MFA recovery codes and store them offline (password manager + printed copy in a safe place).

Common Pitfalls

• Skipping MFA "just for now" → do it now.
• Losing recovery codes → you can be locked out permanently.
• Using root for daily work → this is one of the fastest ways to fail a security review (and the exam).

We will create a powerful IAM user for learning. Later weeks will teach you to replace long-lived credentials with roles.

Console Steps

1. Search for IAM in the top search bar and open the IAM console.
2. In the left navigation, click Users → Create user.
3. User name: teq-admin (or saa-admin, whatever you prefer).
4. Check Provide user access to the AWS Management Console.
5. Choose I want to create an IAM user.
6. Set a strong custom password (or auto-generate). Uncheck "Users must create a new password at next sign-in" only if you want convenience for learning (in real life leave it checked).
7. Click Next.
8. On the permissions page, choose Attach policies directly.
9. Search for and select AdministratorAccess.
10. Click Next → Review → Create user.

Important Notes

• AdministratorAccess is a managed policy that gives full access. Perfect for learning, dangerous in production. We will tighten later.
• After creation, download the .csv credentials file if offered, or note the console sign-in URL.

Create Access Keys for CLI (for this learning user)

1. Click on the new user → Security credentials tab.
2. Under Access keys, click Create access key.
3. Use case: Command Line Interface (CLI).
4. Check the confirmation box and create.
5. Download the .csv or copy Access Key ID + Secret Access Key now. You will not see the secret again.

This is the single most important cost-control step.

1. Enable Billing Alerts (one-time)

1. Click your account name (top right) → Billing and Cost Management.
2. In the left menu go to Billing preferences.
3. Enable Receive Billing Alerts.
4. Save.

2. Create CloudWatch Billing Alarms

1. Go to CloudWatch console.
2. Make sure you are in us-east-1 (billing metrics only appear here).
3. Left menu → Alarms → All alarms → Create alarm.
4. Click Select metric → Billing → Total Estimated Charge.
5. Select the USD metric → Select metric.
6. Threshold type: Static.
7. Whenever EstimatedCharges is Greater than 5.
8. Configure notification: Create a new SNS topic (e.g. billing-alerts) and subscribe your email.
9. Confirm the SNS subscription from your email.
10. Name the alarm Billing-Alarm-5-Dollars.
11. Create the alarm.

Repeat the process for a second alarm at $20.

3. Create an AWS Budget

1. Go to Billing and Cost Management → Budgets.
2. Create budget.
3. Use template: Zero spend budget or customize.
4. Better: Choose Customize (advanced).
5. Budget type: Cost budget.
6. Set amount to something low (e.g. $10 or $20 per month).
7. Scope: All AWS services, all linked accounts (or just this one).
8. Add alert thresholds at 50%, 80%, 100%.
9. Email recipients: your address.
10. Create budget.

Verification: You should receive a confirmation email from SNS and see the alarms in CloudWatch as "OK" or "Insufficient data" initially.

Installation (Linux / macOS / WSL)

# Download
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# Unzip
unzip awscliv2.zip

# Install
sudo ./aws/install

# Verify
aws --version

(Windows users: download the MSI from the official AWS CLI page.)

Configure a Named Profile

Never use the default profile for important work. Always use named profiles.

aws configure --profile teq-learning

You will be prompted for:

• AWS Access Key ID → paste from the IAM user
• AWS Secret Access Key → paste from the IAM user
• Default region name → e.g. us-east-1
• Default output format → json (recommended)

Verify Everything Works

aws sts get-caller-identity --profile teq-learning

Expected output looks like:

{
    "UserId": "AIDA..............",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/teq-admin"
}

If you get an error, check:

• Correct Access Key / Secret
• No extra spaces when pasting
• System clock is accurate (STS is time-sensitive)

Optional but Recommended: Environment Variable Shortcut

Add to your ~/.bashrc or ~/.zshrc:

export AWS_PROFILE=teq-learning

Then you can simply run aws sts get-caller-identity.

1. Go to Billing and Cost Management → Free Tier.
2. Explore what is currently available for your account age.
3. Note the difference between Always Free and 12-month Free Tier.

Always Free examples (approximate, check current):

• Lambda: 1M requests + 400,000 GB-seconds / month
• DynamoDB: 25 GB storage + read/write capacity
• S3: 5 GB Standard storage
• CloudFront: 1 TB data transfer out

12-month Free Tier examples:

• EC2: 750 hours of t2.micro / t3.micro (or newer equivalents)
• RDS: 750 hours of db.t2.micro / db.t3.micro
• EBS: 30 GB

You are done with Week 1 when all of the following are true:

• Root account has MFA enabled and recovery codes stored safely
• You can log into the console as the IAM user (not root)
• Two billing alarms ($5 and $20) exist and SNS subscription is confirmed
• At least one AWS Budget is active
• aws sts get-caller-identity --profile teq-learning returns your IAM user ARN
• You understand the Shared Responsibility Model and Region/AZ hierarchy
• Quiz score ≥ 80%

Write 3–5 sentences answering:

"How does securing an AWS account differ from securing my home server?"

Common themes: no physical access, blast radius of credentials, shared responsibility, global infrastructure, billing as a first-class concern.

By the end of this lab you will be able to:

1. Choose an appropriate Free Tier eligible instance type and AMI
2. Create and secure a key pair
3. Launch an EC2 instance with the correct networking and storage settings
4. Configure a Security Group using least privilege
5. Connect via SSH and bootstrap the instance
6. Install Docker and deploy a containerized application
7. Understand the difference between Security Groups and NACLs
8. Use Elastic IPs and understand their cost implications
9. Stop, start, and terminate instances correctly

Instance Types

• t3.micro / t4g.micro (and newer Free Tier equivalents): Burstable performance, good for learning and low-traffic apps.
• Always check the current Free Tier page in your account — eligible types change over time.
• vCPU, memory, and network performance matter more than "bigger is better."

AMI (Amazon Machine Image)

• Pre-configured template for the root volume (OS + software).
• Recommended for this course: Amazon Linux 2023 or Ubuntu 24.04 LTS.

Security Groups vs Network ACLs

For almost everything in this course you will work primarily with Security Groups.

Key Pairs

• Public key is stored by AWS; private key (.pem) stays with you.
• Losing the private key = you cannot SSH into the instance (unless you have another way in).

Elastic IP

• Static public IPv4 address.
• Free while associated with a running instance.
• Charged if allocated but not associated (or associated with a stopped instance in some cases).

Console Steps

1. Open the EC2 console.
2. Make sure you are in your chosen Region (e.g. us-east-1).
3. Left menu → Network & Security → Key Pairs.
4. Click Create key pair.
5. Name: teq-saa-key
6. Key pair type: RSA
7. Private key file format: .pem (for OpenSSH on Linux/macOS/WSL) or .ppk if using PuTTY on Windows.
8. Click Create key pair.
9. The private key downloads automatically. Move it to a safe location and never commit it to Git.

Secure the Key File (Linux / macOS / WSL)

chmod 400 ~/path/to/teq-saa-key.pem

Common Pitfalls

• Creating the key pair in the wrong Region (key pairs are Region-specific).
• Losing the .pem file.
• Setting permissions too open (chmod 400 is required).

1. EC2 console → Network & Security → Security Groups.
2. Create security group.
3. Name: teq-web-sg
4. Description: Web tier - SSH from my IP only, HTTP/HTTPS open
5. VPC: default VPC for now (we replace this in Week 3).
6. Inbound rules:
   • Type: SSH | Port: 22 | Source: My IP (the console will auto-fill your current public IP)
   • Type: HTTP | Port: 80 | Source: 0.0.0.0/0 (temporary for testing — we will tighten later)
   • Type: HTTPS | Port: 443 | Source: 0.0.0.0/0 (optional)
7. Outbound rules: leave the default (All traffic).
8. Create the security group.

1. EC2 console → Instances → Launch instance.
2. Name: hello-api-ec2
3. Application and OS Images (AMI):
   • Quick Start → Amazon Linux 2023 (or Ubuntu Server 24.04 LTS)
   • Confirm it shows "Free tier eligible"
4. Instance type: t3.micro or t4g.micro (or whatever is currently Free Tier eligible in your account)
5. Key pair: Select teq-saa-key
6. Network settings:
   • VPC: default
   • Subnet: No preference (or pick one)
   • Auto-assign public IP: Enable
   • Firewall (security groups): Select existing → teq-web-sg
7. Configure storage: 8–30 GB gp3 is fine. Free Tier includes 30 GB.
8. Advanced details → User data (optional but recommended):

#!/bin/bash
# Amazon Linux 2023
dnf update -y
dnf install -y docker
systemctl enable docker
systemctl start docker
usermod -aG docker ec2-user

# Simple health check page (optional)
mkdir -p /var/www/html
echo "<h1>hello-api is alive on EC2</h1>" > /var/www/html/index.html

For Ubuntu, replace dnf with apt-get and the user is usually ubuntu.

9. Click Launch instance.

Find the Public IP

In the EC2 console, select the instance → copy the Public IPv4 address.

SSH Connection

ssh -i teq-saa-key.pem ec2-user@<PUBLIC_IP>

(Use ubuntu@ if you chose Ubuntu.)

First connection will ask you to confirm the host key fingerprint — type yes.

Verify Docker

docker --version
docker ps

If the usermod in user data worked, you may need to log out and back in (or use sudo docker).

Deploy a Simple Container

# Quick test with nginx
sudo docker run -d --name web -p 80:80 nginx:alpine

# Or if you have your own hello-api image
# sudo docker run -d --name hello-api -p 80:3000 your-image:tag

Test from Your Browser / curl

curl http://<PUBLIC_IP>

You should see the nginx welcome page or your application response.

1. EC2 → Network & Security → Elastic IPs.
2. Allocate Elastic IP address.
3. Select the new address → Actions → Associate Elastic IP address.
4. Choose your instance and private IP.
5. Associate.

Now the public IP will survive stop/start cycles.

• Stop: Powers off the instance. EBS volumes persist. Public IP (if not Elastic) is released. You stop being charged for instance hours (still charged for EBS storage).
• Start: Powers on again. New public IP unless you used an Elastic IP.
• Terminate: Deletes the instance. Root volume is deleted by default (unless you changed the setting). This is permanent.

Practice stopping and starting the instance at least once.

# From your local machine
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=hello-api-ec2" \
  --query "Reservations[].Instances[].{ID:InstanceId,State:State.Name,IP:PublicIpAddress}" \
  --profile teq-learning

• Instance state is running
• You can SSH using the key pair
• Security group allows SSH only from your IP
• Application responds on port 80
• Docker is installed and running

1. Wrong username — ec2-user (Amazon Linux), ubuntu (Ubuntu), admin (Debian), etc.
2. Security group missing the application port.
3. SSH open to the world (0.0.0.0/0).
4. Key pair in the wrong Region.
5. Leaving the instance running 24/7 when you are not using it → burns Free Tier hours.
6. User data scripts that fail silently — always check /var/log/cloud-init-output.log on the instance.

You are finished with Week 2 when all of the following are true:

• Key pair created and secured with chmod 400
• Security group restricts SSH to your IP only
• EC2 instance is running and reachable via SSH
• Docker is installed
• A containerized application (or nginx) responds on port 80
• You have practiced stopping and starting the instance
• Quiz score ≥ 80%
• Instance is stopped when you are not actively using it

Write 4–6 sentences:

"How does running this application on EC2 differ from running the same Docker container on my home server? What is better, what is worse, and what is simply different?"

1. Design and create a custom VPC with a sensible CIDR plan
2. Create public and private subnets across multiple Availability Zones
3. Attach an Internet Gateway and configure route tables correctly
4. Understand the difference between public and private subnets
5. Optionally set up a NAT Gateway or NAT Instance for private subnet outbound access
6. Launch (or migrate) an EC2 instance into the custom VPC
7. Stop using the default VPC for new resources

CIDR Planning

• VPC: typically /16 (e.g. 10.0.0.0/16) gives 65,536 addresses — plenty for learning.
• Subnets: /24 (256 addresses) is a common, easy size.
• Leave room to grow. Do not use overlapping ranges with other networks you care about.

Public vs Private Subnet

• Public subnet: Has a route table entry for 0.0.0.0/0 that points to an Internet Gateway. Resources can have public IPs.
• Private subnet: No direct route to the Internet Gateway. Outbound internet access (if needed) goes through a NAT Gateway or NAT Instance in a public subnet.

Core Components

• Internet Gateway (IGW): Horizontally scaled, redundant, and highly available VPC component that allows communication between the VPC and the internet.
• Route Table: Controls where network traffic is directed.
• NAT Gateway: Managed NAT service (costs money). Allows private subnet resources to initiate outbound internet connections while remaining unreachable from the internet.
• NAT Instance: Self-managed alternative (cheaper for pure learning, more operational overhead).

1. Open the VPC console.
2. Your VPCs → Create VPC.
3. Choose VPC only (we will create subnets manually for learning).
4. Name tag: teq-saa-vpc
5. IPv4 CIDR: 10.0.0.0/16
6. Tenancy: Default
7. Create VPC.

After creation, note the VPC ID.

Enable DNS hostnames (important for later): Select the VPC → Actions → Edit VPC settings → Enable DNS hostnames → Save.

Create four subnets:

Steps for each:

1. VPC console → Subnets → Create subnet.
2. Select your VPC.
3. Fill in name, AZ, and CIDR.
4. Create.

Repeat until all four exist.

1. VPC console → Internet gateways → Create internet gateway.
2. Name: teq-saa-igw
3. Create.
4. Select the new IGW → Actions → Attach to VPC → choose teq-saa-vpc.

1. Route tables → Create route table.
2. Name: teq-saa-public-rt
3. VPC: teq-saa-vpc
4. Create.
5. Select the route table → Routes tab → Edit routes → Add route:
   • Destination: 0.0.0.0/0
   • Target: Internet Gateway → select teq-saa-igw
6. Save.
7. Subnet associations tab → Edit subnet associations → select public-a and public-b → Save.

Your public subnets now have a path to the internet.

1. Create another route table: teq-saa-private-rt
2. Associate it with private-a and private-b.

Option A — No NAT (simplest for pure learning)

Private subnets will have no outbound internet access. This is fine if your private resources do not need to download packages or call external APIs.

Option B — NAT Gateway (realistic but costs money)

1. Allocate an Elastic IP.
2. Create a NAT Gateway in one of the public subnets and associate the Elastic IP.
3. In the private route table, add route 0.0.0.0/0 → NAT Gateway.
4. Remember to delete the NAT Gateway when you are finished testing — it has hourly + data processing charges.

Option C — NAT Instance (cheaper learning alternative)

Launch a small EC2 instance in a public subnet, disable source/destination check, configure IP forwarding and iptables (or use a pre-built NAT AMI), and point the private route table at that instance.

For most people learning SAA-C03, Option A or a temporary NAT Gateway is sufficient.

Recommended: Launch a new instance in the custom VPC

1. EC2 → Launch instance.
2. Same AMI and instance type as Week 2.
3. Network settings:
   • VPC: teq-saa-vpc
   • Subnet: public-a (or public-b)
   • Auto-assign public IP: Enable
   • Security group: Create a new one or copy rules from teq-web-sg (you will need to recreate the security group in the new VPC).
4. Key pair: same as before.
5. Launch and deploy your application again (Docker + container).

Why recreate the Security Group?

Security groups are VPC-scoped. You cannot use a security group from the default VPC inside your new VPC.

From your local machine:

# Confirm instance is in the correct VPC and subnet
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=hello-api-ec2*" \
  --query "Reservations[].Instances[].{ID:InstanceId,VpcId:VpcId,SubnetId:SubnetId,PublicIP:PublicIpAddress,State:State.Name}" \
  --profile teq-learning

• Instance has a public IP
• You can SSH to it
• You can reach the application on port 80
• The instance is not in the default VPC

On the instance itself, confirm outbound internet works (if you expect it to):

curl -I https://aws.amazon.com

1. Forgetting to attach the Internet Gateway.
2. Associating the public route table with private subnets (or vice versa).
3. Creating all subnets in the same Availability Zone (defeats multi-AZ design).
4. Trying to use a security group from a different VPC.
5. Leaving a NAT Gateway running when not needed → unexpected charges.
6. Not enabling DNS hostnames on the VPC (causes problems with some AWS services later).

• Custom VPC teq-saa-vpc exists with CIDR 10.0.0.0/16
• At least two public and two private subnets in different AZs
• Internet Gateway attached and public route table configured
• Application instance running inside the custom VPC (public subnet)
• You can SSH and reach the application
• Default VPC is no longer used for new resources
• Quiz ≥ 80%

"How does this VPC design compare to the networking on my home server or mini-PC setup? What concepts transfer directly, and what is completely new?"

1. Create and configure an S3 bucket with appropriate settings
2. Host a static website on S3 (or S3 + CloudFront)
3. Apply versioning and lifecycle policies
4. Generate and use presigned URLs
5. Understand bucket policies vs IAM policies
6. Choose the correct storage class for different access patterns
7. Decide when to use S3 vs EBS vs EFS

Storage Classes (High-Level Decision Framework)

• S3 Standard: Frequent access, low latency. Default.
• S3 Intelligent-Tiering: Automatic cost optimization when access patterns are unknown.
• S3 Standard-IA / One Zone-IA: Infrequent access, lower storage cost, retrieval fee.
• S3 Glacier Instant Retrieval / Flexible Retrieval / Deep Archive: Archival, increasing retrieval times and decreasing cost.

S3 vs EBS vs EFS

Bucket Policies vs IAM Policies

• IAM policies: Attached to users, groups, or roles. "Who can do what."
• Bucket policies: Attached to the bucket itself (resource-based). Can grant cross-account access or public access under controlled conditions.

1. Open the S3 console.
2. Create bucket.
3. Bucket name: must be globally unique. Example: teq-landing-jude-2026 or teq-saa-static-YOURNAME.
4. Region: same as your other resources (e.g. us-east-1).
5. Object Ownership: ACLs disabled (recommended).
6. Block Public Access: For a static website you will need to adjust this carefully later. For now you can leave it blocked and use CloudFront, or unblock only what is required.
7. Versioning: Enable.
8. Default encryption: SSE-S3 (AES-256) is fine.
9. Create bucket.

Prepare Content

Create a simple index.html:

<!DOCTYPE html>
<html>
<head>
  <title>Teq Project Landing</title>
  <style>
    body { font-family: system-ui; max-width: 800px; margin: 40px auto; padding: 0 20px; }
    h1 { color: #1F4E79; }
  </style>
</head>
<body>
  <h1>Hello from S3</h1>
  <p>This static site is hosted on Amazon S3 as part of the SAA-C03 course.</p>
</body>
</html>

You can also upload a real landing page from one of your Teq projects.

Upload

1. Open the bucket → Upload → Add files → Upload index.html (and any CSS/JS/assets).

Enable Static Website Hosting

1. Bucket → Properties tab → scroll to Static website hosting.
2. Edit → Enable.
3. Hosting type: Host a static website.
4. Index document: index.html
5. Error document: index.html (or a custom 404 page).
6. Save.

You will receive a bucket website endpoint URL (looks like http://bucket-name.s3-website-region.amazonaws.com).

Make Objects Public (if using website hosting directly)

1. Permissions tab → Block public access → Edit → uncheck the relevant settings (or allow public policies).
2. Create a bucket policy that allows s3:GetObject for Principal: "*" on the objects you want public.

Example bucket policy (adjust the bucket name):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}

Test the website endpoint in a browser.

1. Bucket → Management tab → Lifecycle rules → Create lifecycle rule.
2. Rule name: expire-old-versions or transition-to-ia.
3. Rule scope: Apply to all objects (or use a prefix/filter).
4. Example actions:
   • Transition current versions to Intelligent-Tiering after 30 days (optional).
   • Permanently delete noncurrent versions after 90 days.
   • Or simply expire delete markers and incomplete multipart uploads.
5. Create the rule.

Presigned URLs give temporary access to private objects without making the bucket public.

Using the AWS CLI

# Upload a private test file
echo "secret content" > private-test.txt
aws s3 cp private-test.txt s3://YOUR-BUCKET-NAME/private-test.txt --profile teq-learning

# Generate a presigned URL valid for 15 minutes (900 seconds)
aws s3 presign s3://YOUR-BUCKET-NAME/private-test.txt --expires-in 900 --profile teq-learning

Copy the URL and open it in a browser or with curl. After it expires, access should be denied.

1. Open the CloudFront console → Create distribution.
2. Origin domain: select your S3 bucket (use the REST endpoint, not the website endpoint, if using Origin Access Control).
3. For modern setups, use Origin Access Control (OAC) so the bucket can remain private.
4. Default root object: index.html
5. Viewer protocol policy: Redirect HTTP to HTTPS.
6. Create distribution.
7. After the distribution deploys (can take a few minutes), use the CloudFront domain name to access your site over HTTPS.

This pattern (private S3 + CloudFront + OAC) is the preferred production approach and appears frequently on the exam.

• Bucket exists with versioning enabled
• Static content is reachable via the website endpoint or CloudFront
• Lifecycle rule is active
• Presigned URL works and then expires
• You understand the difference between the website endpoint and the REST endpoint

1. Bucket name already taken (names are global).
2. Forgetting to set the index document.
3. Block Public Access still enabled when trying to use the website endpoint directly.
4. Using the wrong endpoint type with CloudFront.
5. Making the entire bucket public instead of only the necessary objects.
6. Leaving versioning disabled and then accidentally overwriting important files.

• Static site is publicly reachable
• Versioning is enabled
• At least one lifecycle rule exists
• Presigned URL demonstrated
• Quiz ≥ 80%

"How does S3 compare to storing static files on my home server or using a traditional web host? What becomes easier and what requires a different mental model?"

1. Create a DB subnet group using private subnets
2. Launch an Amazon RDS Postgres instance in private subnets only
3. Lock down the database security group so only the application tier can connect
4. Connect your application to RDS and verify read/write
5. Understand Multi-AZ, automated backups, and snapshots
6. Know when to choose DynamoDB instead of a relational database
7. Map your existing Supabase / self-hosted Postgres usage to AWS options

RDS

• Managed relational database service (Postgres, MySQL, MariaDB, Oracle, SQL Server, Aurora).
• You manage schema, queries, and optimization; AWS manages patching, backups, hardware, Multi-AZ failover, etc.

Multi-AZ

• Synchronous standby in a different Availability Zone.
• Automatic failover on infrastructure failure.
• Primary use case: high availability, not read scaling (use Read Replicas for that).

DynamoDB

• Fully managed NoSQL key-value and document database.
• Single-digit millisecond performance at any scale.
• On-demand or provisioned capacity modes.
• Partition key (required) + optional sort key.

Decision Framework (Simplified)

• Structured data, complex queries, joins, transactions → RDS / Aurora
• Simple key-value or document access patterns, extreme scale, unpredictable traffic → DynamoDB

1. Open the RDS console.
2. Left menu → Subnet groups → Create DB subnet group.
3. Name: teq-saa-db-subnets
4. Description: Private subnets for RDS
5. VPC: teq-saa-vpc
6. Add the two private subnets (private-a and private-b) across different AZs.
7. Create.

1. EC2 console → Security Groups → Create.
2. Name: teq-rds-sg
3. VPC: teq-saa-vpc
4. Inbound rule:
   • Type: PostgreSQL
   • Port: 5432
   • Source: the security group of your application instance (e.g. teq-web-sg)
5. Create.

1. RDS console → Databases → Create database.
2. Creation method: Standard create.
3. Engine: PostgreSQL (choose a recent version).
4. Templates: Free tier (if available) or Dev/Test.
5. Settings:
   • DB instance identifier: teq-saa-postgres
   • Master username: postgres (or your preferred admin user)
   • Master password: generate a strong one and store it securely (we will move it to Secrets Manager in Week 6)
6. Instance configuration: Free Tier eligible class (e.g. db.t3.micro or current equivalent).
7. Storage: gp3 or gp2, 20 GB is fine. Disable storage autoscaling for learning if you want predictable cost.
8. Connectivity:
   • VPC: teq-saa-vpc
   • DB subnet group: teq-saa-db-subnets
   • Public access: No
   • VPC security group: choose teq-rds-sg
9. Additional configuration:
   • Initial database name: helloapi (or whatever your app expects)
   • Backup retention: 7 days is fine
   • Enable encryption if desired
10. Create database.

Wait until the status becomes Available (can take 5–10 minutes).

1. In the RDS console, select the database and copy the Endpoint.
2. SSH into your EC2 application instance.
3. Update your application's connection configuration:

# Example environment variables
export DB_HOST="<RDS-ENDPOINT>"
export DB_PORT="5432"
export DB_NAME="helloapi"
export DB_USER="postgres"
export DB_PASSWORD="<your-password>"

Or update your .env, Docker Compose file, or application config.

4. Restart your application / container.
5. Run migrations if needed and perform a simple read/write test.

Test Connectivity from the Instance

# Install client if needed (Amazon Linux)
sudo dnf install -y postgresql15

psql -h <RDS-ENDPOINT> -U postgres -d helloapi

If you can connect from the EC2 instance but not from your laptop, that is expected and correct (private subnet + security group).

1. RDS console → select the database → Actions → Take snapshot.
2. Give it a name and wait for completion.
3. Explore automated backups (RDS creates them automatically within the retention period).
4. Note that restoring from a snapshot creates a new database instance.

1. DynamoDB console → Create table.
2. Table name: teq-feature-flags or teq-sessions.
3. Partition key: pk (String).
4. Settings: Default (on-demand capacity is fine for learning).
5. Create.
6. Explore putting and getting items via the console or AWS CLI:

aws dynamodb put-item \
  --table-name teq-feature-flags \
  --item '{"pk": {"S": "dark-mode"}, "enabled": {"BOOL": true}}' \
  --profile teq-learning

aws dynamodb get-item \
  --table-name teq-feature-flags \
  --key '{"pk": {"S": "dark-mode"}}' \
  --profile teq-learning

• RDS instance is in Available state
• It is in private subnets only (Publicly accessible = No)
• Security group allows 5432 only from the application security group
• Application successfully connects and can read/write
• You have taken at least one manual snapshot

1. Making the RDS instance publicly accessible.
2. Opening port 5432 to the world.
3. Forgetting to create a DB subnet group that spans at least two AZs.
4. Using the wrong security group or forgetting to reference the application security group as the source.
5. Hard-coding the master password in application code or Docker environment variables that get committed.
6. Leaving the RDS instance running 24/7 when not needed (it costs money even when idle).

• RDS Postgres running in private subnets
• Security group correctly restricts access
• Application connected and functional
• At least one snapshot taken
• Quiz ≥ 80%

"How does RDS compare to running Postgres yourself (or using Supabase) on your home server? What do you gain and what do you give up?"

1. Create and attach an IAM Role to an EC2 instance (instance profile)
2. Remove long-lived access keys from the instance
3. Store database credentials and other secrets in AWS Secrets Manager
4. Update the application to retrieve secrets at runtime using the AWS SDK or CLI
5. Understand identity-based vs resource-based policies and policy evaluation logic
6. Enable encryption at rest with KMS where appropriate
7. Apply the principle of least privilege in practice

IAM Roles for EC2

• An instance profile is a container for an IAM role that you can attach to an EC2 instance.
• Applications on the instance can obtain temporary credentials automatically via the Instance Metadata Service (IMDS).
• This is strongly preferred over embedding access keys.

Secrets Manager vs Systems Manager Parameter Store

For database credentials, Secrets Manager is the better teaching choice.

Policy Evaluation Logic (Critical for the Exam)

1. Explicit Deny always wins.
2. If no explicit Deny, then at least one explicit Allow is required.
3. Otherwise the request is denied (default deny).

1. IAM console → Roles → Create role.
2. Trusted entity type: AWS service.
3. Use case: EC2.
4. Click Next.
5. Permissions: for now attach SecretsManagerReadWrite (or a more restrictive custom policy later) and any other permissions your app needs (e.g. S3 read if required).
6. Role name: teq-ec2-app-role
7. Create role.

1. EC2 console → select your application instance.
2. Actions → Security → Modify IAM role.
3. Select teq-ec2-app-role.
4. Update IAM role.

Alternatively, you can specify the instance profile at launch time via a Launch Template (preferred for Auto Scaling later).

Verify the Role Is Available on the Instance

SSH into the instance and run:

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Should return the role name

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/teq-ec2-app-role
# Should return temporary AccessKeyId, SecretAccessKey, and Token

1. Secrets Manager console → Store a new secret.
2. Secret type: Credentials for Amazon RDS database (or Other type of secret if you prefer full control).
3. If using the RDS helper: select your RDS instance and it can populate the connection details.
4. Or choose Other type of secret and enter key-value pairs:

username = postgres
password = <your-strong-password>
host     = <RDS-endpoint>
port     = 5432
dbname   = helloapi

5. Secret name: teq/saa/db-credentials
6. Leave rotation disabled for now (you can enable it later).
7. Store the secret.

If you attached the broad SecretsManagerReadWrite managed policy, you already have access. For better practice:

1. Create a custom IAM policy that allows only secretsmanager:GetSecretValue on the specific secret ARN.
2. Attach that policy to teq-ec2-app-role.

Example policy document:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT:secret:teq/saa/db-credentials-*"
    }
  ]
}

On the EC2 instance, you can retrieve the secret with the AWS CLI (now that the role is attached):

aws secretsmanager get-secret-value \
  --secret-id teq/saa/db-credentials \
  --query SecretString \
  --output text

In application code (Node.js example using AWS SDK v3):

import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

const client = new SecretsManagerClient({ region: "us-east-1" });
const response = await client.send(
  new GetSecretValueCommand({ SecretId: "teq/saa/db-credentials" })
);
const secret = JSON.parse(response.SecretString);
// Use secret.username, secret.password, etc.

Update your application so it no longer relies on hardcoded environment variables for the database password.

Restart the application and verify it still connects successfully.

1. Ensure the application works with the IAM role + Secrets Manager.
2. Delete any access key files, .env files containing secrets, or environment variables that held the database password.
3. Confirm that the instance itself no longer has permanent AWS credentials configured for the application.

1. For RDS: when creating or modifying the instance, enable encryption (you may need to create a new encrypted instance from a snapshot if the original was unencrypted).
2. For S3: bucket properties → Default encryption → enable SSE-S3 or SSE-KMS.
3. Explore customer managed KMS keys if you want more control (key policies, rotation, etc.).

• IAM role is attached to the EC2 instance
• Instance can retrieve the secret via the role (no long-lived keys required)
• Application successfully connects to RDS using the retrieved secret
• No plaintext database password remains on the instance
• Encryption is enabled on sensitive resources where appropriate

1. Forgetting that the role must be attached before the application tries to use it.
2. Using the older Instance Metadata Service version 1 without considering IMDSv2 (more secure).
3. Granting * on Secrets Manager instead of the specific secret ARN.
4. Leaving the original access keys active on the IAM user after switching to roles.
5. Not handling secret retrieval errors gracefully in application code.

• EC2 instance uses an IAM role (no long-lived keys for the app)
• Database credentials stored in Secrets Manager
• Application retrieves secrets at runtime
• Plaintext secrets removed from the instance
• Quiz ≥ 80%

"How does managing secrets and credentials on AWS differ from how you handle them on your home server or in Docker Compose files?"

1. Create a Launch Template from your current configuration
2. Create an Auto Scaling Group that spans multiple Availability Zones
3. Create an Application Load Balancer and Target Group
4. Configure health checks so unhealthy instances are replaced
5. Restrict security groups so only the ALB can reach the application instances
6. Demonstrate that terminating an instance causes automatic replacement
7. Understand the difference between ALB, NLB, and Classic Load Balancer

Elastic Load Balancing Types

• Application Load Balancer (ALB): Layer 7 (HTTP/HTTPS), content-based routing, ideal for most web applications.
• Network Load Balancer (NLB): Layer 4 (TCP/UDP), ultra-high performance, static IPs, preserves source IP.
• Gateway Load Balancer: For virtual appliances (firewalls, etc.).

For this course we use ALB.

Auto Scaling Group (ASG)

• Maintains a desired number of healthy instances.
• Can scale out/in based on metrics (CPU, request count, custom metrics).
• Works with Launch Templates (preferred) or Launch Configurations (legacy).

Health Checks

• EC2 status checks (hypervisor level).
• ELB health checks (application level — you define the path and expected response).

1. EC2 console → Launch Templates → Create launch template.
2. Name: teq-app-lt
3. Template version description: v1 - initial
4. AMI: same as your current working instance (or create an AMI from it first for cleanliness).
5. Instance type: Free Tier eligible type.
6. Key pair: your existing key.
7. Network settings: do not specify a subnet here if the ASG will choose subnets. You can leave security groups to be specified later or include a base one.
8. Advanced details → IAM instance profile: select teq-ec2-app-role (from Week 6).
9. User data: include the same bootstrap script you used before (Docker install, etc.).
10. Create launch template.

1. EC2 console → Target Groups → Create target group.
2. Target type: Instances.
3. Name: teq-app-tg
4. Protocol: HTTP | Port: 80 (or whatever port your app listens on).
5. VPC: teq-saa-vpc
6. Health check path: / or /health (make sure your app returns 200 on this path).
7. Advanced health check settings: Healthy threshold 2–3, interval 30s is fine for learning.
8. Create.
9. On the next screen you can register targets later (the ASG will do this automatically).

1. EC2 console → Load Balancers → Create load balancer → Application Load Balancer.
2. Name: teq-app-alb
3. Scheme: Internet-facing.
4. IP address type: IPv4.
5. Network mapping: select your VPC and at least two public subnets in different AZs.
6. Security groups: create a new one (teq-alb-sg) that allows inbound HTTP (80) and HTTPS (443) from 0.0.0.0/0.
7. Listeners: HTTP on port 80 → forward to teq-app-tg.
8. Create load balancer.

Your application instances should no longer accept traffic directly from the internet on the application port.

1. Edit the application security group (teq-web-sg or equivalent):
   • Remove the inbound rule that allows HTTP/HTTPS from 0.0.0.0/0.
   • Add an inbound rule: HTTP (or your app port) | Source = the ALB security group (teq-alb-sg).
2. Keep SSH restricted to your IP if you still need direct access for debugging.

Now only the load balancer can talk to the instances on the application port.

1. EC2 console → Auto Scaling Groups → Create Auto Scaling group.
2. Name: teq-app-asg
3. Launch template: select teq-app-lt (latest version).
4. Network: VPC = teq-saa-vpc. Select the public subnets (or private if you have NAT and want instances private).
5. Load balancing: Attach to an existing load balancer → choose the target group teq-app-tg.
6. Health checks: Enable ELB health checks. Set health check grace period (e.g. 300 seconds) so new instances have time to start before being considered unhealthy.
7. Group size: Desired 1, Minimum 1, Maximum 3.
8. Scaling policies: for now you can skip or add a simple target tracking policy on Average CPU Utilization (target 50–70%).
9. Create.

Wait until the ASG shows 1 healthy instance in service and the target group shows the instance as healthy.

1. Note the DNS name of the ALB (e.g. teq-app-alb-xxxxx.us-east-1.elb.amazonaws.com).
2. Confirm you can reach your application via the ALB DNS name.
3. In the EC2 console, terminate the running instance that belongs to the ASG.
4. Watch the Auto Scaling Group activity history — it should launch a replacement instance automatically.
5. After a few minutes the new instance should become healthy and start receiving traffic.

This is the core resilience demonstration.

# Check ASG status
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names teq-app-asg \
  --profile teq-learning

# Check target health
aws elbv2 describe-target-health \
  --target-group-arn <your-tg-arn> \
  --profile teq-learning

• ALB DNS name serves the application
• Only the ALB security group can reach the app port on instances
• Terminating an instance causes a replacement to be launched
• Target group shows healthy targets

1. Putting the ALB in private subnets (it needs public subnets for an internet-facing load balancer).
2. Forgetting to update the instance security group so only the ALB can reach it.
3. Health check path that returns something other than 200.
4. Health check grace period too short → instances marked unhealthy before they finish starting.
5. Launch template missing the IAM role or user data.
6. Leaving Desired Capacity > 0 when you are finished for the day → ongoing cost.

• Launch Template created
• Target Group + ALB working
• Auto Scaling Group maintains desired capacity across AZs
• Security groups correctly restrict traffic to ALB → instances
• Instance termination triggers automatic replacement
• Quiz ≥ 80%

"How does Auto Scaling + Load Balancing change the operational model compared to running a single container or VM on my home server?"

1. Create and deploy a Lambda function
2. Understand execution roles, environment variables, and basic configuration
3. Expose the function via an HTTP API (API Gateway)
4. Test the endpoint and observe cold starts
5. Know when serverless is a better fit than EC2 or containers for specific workloads
6. Understand Lambda limits and pricing model at a high level

Lambda

• Event-driven, fully managed compute.
• You upload code; AWS handles the servers, scaling, and availability.
• Billed for request count + duration (GB-seconds).
• Cold starts occur when a new execution environment is created.

API Gateway

• HTTP APIs: Lower cost, lower latency, simpler — preferred for most new workloads.
• REST APIs: More features (API keys, usage plans, request validation, etc.).

When Serverless Wins for You

• Infrequent or spiky traffic (webhooks, scheduled tasks, lightweight utility endpoints).
• You want zero server management.
• Cost scales to near zero when idle.

1. IAM → Roles → Create role.
2. Trusted entity: AWS service → Lambda.
3. Attach basic permissions: AWSLambdaBasicExecutionRole (for CloudWatch Logs).
4. If the function needs other AWS services (S3, DynamoDB, Secrets Manager, etc.), add those permissions now or later.
5. Role name: teq-lambda-role
6. Create.

1. Lambda console → Create function.
2. Author from scratch.
3. Function name: teq-hello or something useful from your real apps (e.g. a calculation endpoint).
4. Runtime: Node.js 20.x, Python 3.12, or your preferred supported runtime.
5. Architecture: x86_64 or arm64.
6. Execution role: Use the existing role teq-lambda-role.
7. Create function.

Example Node.js Handler

exports.handler = async (event) => {
  console.log("Event:", JSON.stringify(event));
  
  const name = event.queryStringParameters?.name || "World";
  
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: `Hello, ${name}! From Lambda.`,
      requestId: event.requestContext?.requestId
    })
  };
};

Example Python Handler

import json

def lambda_handler(event, context):
    print("Event:", json.dumps(event))
    name = "World"
    if event.get("queryStringParameters") and "name" in event["queryStringParameters"]:
        name = event["queryStringParameters"]["name"]
    
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({
            "message": f"Hello, {name}! From Lambda.",
            "requestId": context.aws_request_id
        })
    }

Deploy the code (click Deploy if editing in the console).

1. In the Lambda console, go to the Test tab.
2. Create a test event (API Gateway AWS Proxy style or a simple event).
3. Invoke and confirm the response and logs in CloudWatch.

1. API Gateway console → Create API → HTTP API → Build.
2. Add integration → Lambda → select your function.
3. API name: teq-http-api
4. Configure routes:
   • Method: GET
   • Path: /hello
   • Integration: your Lambda function
5. Configure stages: default $default stage is fine (auto-deploy).
6. Create.

After creation, note the Invoke URL (looks like https://abcdef123.execute-api.us-east-1.amazonaws.com).

curl "https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/hello"
curl "https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/hello?name=Jude"

You should receive the JSON response from Lambda.

1. Invoke the endpoint after waiting several minutes (or use a new test).
2. Check the duration in the response or in CloudWatch Logs.
3. CloudWatch → Log groups → /aws/lambda/your-function-name → inspect recent streams.

• Create an API key and usage plan (more common with REST APIs).
• Or add a Lambda authorizer / JWT authorizer for real authentication.
• For learning, the open endpoint is acceptable as long as the function itself is not destructive.

• Lambda function deploys and runs successfully via the test console
• HTTP API endpoint returns the expected response
• Logs appear in CloudWatch
• You understand the difference in operational model vs EC2

1. Forgetting the execution role → function cannot write logs or call other services.
2. Incorrect handler name or runtime mismatch.
3. Returning a non-proxy response format when using Lambda proxy integration.
4. Leaving the function with overly broad IAM permissions.
5. Not considering cold start latency for user-facing interactive endpoints.

• Lambda function created and tested
• HTTP API endpoint working
• You can explain when you would choose this pattern over EC2/ECS for one of your real workloads
• Quiz ≥ 80%

"For which parts of my existing projects would Lambda + API Gateway be a better fit than an always-on container or EC2 instance?"

1. Create an Amazon ECR repository and push a Docker image
2. Create an ECS cluster
3. Write a Task Definition that maps your Docker Compose mental model
4. Run the task as an ECS Service on Fargate
5. Register the service with your existing Application Load Balancer
6. Understand Fargate vs EC2 launch type

Mental Model Mapping

Fargate vs EC2 Launch Type

• Fargate: Serverless containers — you define CPU/memory, AWS runs the tasks. No EC2 instances to manage.
• EC2 launch type: You manage the underlying EC2 instances (more control, more operational work).

For this course we use Fargate.

1. ECR console → Repositories → Create repository.
2. Visibility: Private.
3. Repository name: teq/hello-api (or your app name).
4. Create.

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

# Build (if needed) and tag
docker build -t teq/hello-api .
docker tag teq/hello-api:latest <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/teq/hello-api:latest

# Push
docker push <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/teq/hello-api:latest

Replace <ACCOUNT_ID> with your 12-digit AWS account ID.

Verify the image appears in the ECR console.

1. ECS console → Clusters → Create cluster.
2. Cluster name: teq-saa-cluster
3. Infrastructure: AWS Fargate (serverless).
4. Create.

1. ECS → Task definitions → Create new task definition.
2. Task definition family: teq-hello-api
3. Launch type: AWS Fargate.
4. Operating system/Architecture: Linux / X86_64 (or ARM if your image is multi-arch).
5. Task size: 0.25 vCPU / 0.5 GB is enough for many simple apps (adjust as needed).
6. Task role: you can use the same role that can read Secrets Manager if needed (teq-ec2-app-role or a new one).
7. Container:
   • Name: hello-api
   • Image URI: the ECR URI you pushed
   • Port mappings: container port 3000 (or whatever your app uses) → protocol TCP
   • Environment variables or Secrets (from Secrets Manager / SSM) as needed
   • Log configuration: Awslogs, create a new log group or use default
8. Create.

1. Open your cluster → Services → Create.
2. Compute options: Fargate.
3. Task definition: select the one you just created (latest revision).
4. Service name: teq-hello-service
5. Desired tasks: 1
6. Networking:
   • VPC: teq-saa-vpc
   • Subnets: public subnets (or private + NAT)
   • Security group: one that allows the ALB to reach the container port
   • Public IP: Turn on if using public subnets without NAT
7. Load balancing:
   • Application Load Balancer
   • Select your existing ALB
   • Choose the existing target group or create a new one that matches the container port
8. Create the service.

Wait until the service reaches steady state and the target group shows healthy targets.

# List services
aws ecs list-services --cluster teq-saa-cluster --profile teq-learning

# Describe the service
aws ecs describe-services --cluster teq-saa-cluster --services teq-hello-service --profile teq-learning

• Access the application via the ALB DNS name.
• Confirm tasks are running in the ECS console.
• Check CloudWatch Logs for container output.

1. Image URI incorrect or authentication failure when pushing/pulling.
2. Container port does not match the target group / port mapping.
3. Security group does not allow traffic from the ALB on the container port.
4. Task fails health checks because the application takes longer to start than the grace period.
5. Not giving the task execution role permission to pull from ECR or write logs.
6. Using a target group that still points at old EC2 instances.

• Image successfully pushed to ECR
• ECS Service running on Fargate
• Application reachable via the ALB
• Logs visible in CloudWatch
• Quiz ≥ 80%

"How does the mental model of ECS Task Definitions and Services map to the Docker Compose workflow I already use on my home server?"

1. Create meaningful CloudWatch alarms for your application
2. Build a simple CloudWatch Dashboard
3. Create an SQS queue and understand standard vs FIFO
4. Decouple a synchronous process by sending work to a queue
5. Create a consumer (Lambda or long-running) that processes the queue
6. Understand the role of SNS and Dead Letter Queues
7. Know what CloudTrail is used for

CloudWatch

• Metrics: Numerical data points (CPU, request count, custom metrics).
• Alarms: Trigger actions (SNS notifications, scaling, etc.) based on metric thresholds.
• Logs: Application and service logs; Logs Insights for querying.
• Dashboards: Visual overview of key metrics.

SQS (Simple Queue Service)

• Fully managed message queuing.
• Standard queues: At-least-once delivery, best-effort ordering, nearly unlimited throughput.
• FIFO queues: Exactly-once processing, strict ordering, limited throughput.
• Decouples producers from consumers — classic resilience pattern.

SNS vs SQS

• SNS = pub/sub (one message to many subscribers).
• SQS = queue (one message to one consumer, with buffering).

Example: ALB 5xx Errors

1. CloudWatch → Alarms → Create alarm.
2. Select metric → ApplicationELB → Per AppELB Metrics → HTTPCode_Target_5XX_Count for your load balancer.
3. Statistic: Sum | Period: 1 minute.
4. Threshold: greater than 5 (or whatever makes sense for learning).
5. Notification: use the existing billing SNS topic or create a new one.
6. Name: teq-alb-5xx-alarm
7. Create.

Example: Unhealthy Hosts

Create another alarm on UnHealthyHostCount > 0 for your target group.

Example: ASG or ECS CPU

Create an alarm on high CPU utilization if you want to experiment with scaling.

1. CloudWatch → Dashboards → Create dashboard.
2. Name: teq-saa-dashboard
3. Add widgets:
   • Number widget or graph for ALB request count
   • Graph for target response time
   • Graph for healthy/unhealthy host count
   • Graph for ASG or ECS CPU/memory
   • Log widget pointing at your application log group
4. Save the dashboard.

This becomes your at-a-glance operational view.

1. SQS console → Create queue.
2. Type: Standard (for learning).
3. Name: teq-image-processing or teq-async-tasks
4. Configuration: leave defaults or set a visibility timeout appropriate for your expected processing time (e.g. 60–300 seconds).
5. Dead-letter queue: optional but recommended — create a second queue and configure the main queue to send messages there after 3–5 failed receives.
6. Create.

You can send messages from the console, the AWS CLI, or from your application.

aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/ACCOUNT/teq-async-tasks \
  --message-body '{"task": "resize-image", "id": "12345"}' \
  --profile teq-learning

Modify one part of your real application (or create a small test endpoint) so that a heavy or non-critical task is published to the queue instead of being performed synchronously.

Option A — Lambda Consumer (recommended for learning)

1. Create a new Lambda function.
2. Add an SQS trigger pointing at your queue.
3. Give the Lambda execution role permission to read from the queue and delete messages (sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes).
4. In the function code, process the message body and perform the work.
5. Send a test message and confirm the Lambda is invoked and the message is deleted.

Option B — Long-running consumer on EC2/ECS

A simple loop that polls the queue (using the AWS SDK) and processes messages. This mirrors how many background workers operate.

1. Open the CloudTrail console.
2. Confirm that a trail exists (or create one that logs management events to an S3 bucket).
3. Understand that CloudTrail records API calls made in your account — essential for auditing and security investigations.

You do not need a complex multi-Region organization trail for this course, but you should know what the service does.

• At least two CloudWatch alarms exist and are in OK or ALARM state as expected
• Dashboard shows live metrics
• Messages can be sent to the SQS queue
• A consumer processes messages successfully
• You understand the difference between SNS and SQS

1. Alarm thresholds that are too sensitive or too loose for the learning environment.
2. Forgetting to give the Lambda (or consumer) permission to delete messages → messages reappear after visibility timeout.
3. Visibility timeout shorter than the processing time → duplicate processing.
4. Not configuring a Dead Letter Queue → poison messages stay in the queue forever.
5. Creating FIFO queues when standard queues would be simpler and sufficient.

• CloudWatch alarms active
• Dashboard created
• SQS queue + producer + consumer working
• Quiz ≥ 80%

"Where in my current architecture (home server or AWS) would introducing a queue improve resilience or user experience?"

1. Apply the six pillars of the AWS Well-Architected Framework to your architecture
2. Use Cost Explorer to understand where money is going
3. Tag resources for cost allocation and ownership
4. Identify idle, oversized, or unnecessary resources
5. Create a written keep / stop / delete plan
6. Understand Reserved Instances, Savings Plans, and Spot at a high level
7. Make deliberate cost-control decisions

The Six Pillars

1. Operational Excellence — Run and monitor systems, continually improve processes.
2. Security — Protect information, systems, and assets.
3. Reliability — Recover from failures, meet demand, mitigate disruptions.
4. Performance Efficiency — Use resources efficiently and maintain efficiency as demand changes.
5. Cost Optimization — Avoid unnecessary costs.
6. Sustainability — Minimize environmental impact of cloud workloads.

The exam frequently presents architecture "story problems" that test whether you can apply these pillars.

Pricing Models (High Level)

• On-Demand: Pay for what you use, no commitment. Highest unit cost, maximum flexibility.
• Savings Plans / Reserved Instances: Commitment for 1 or 3 years in exchange for significant discount.
• Spot Instances: Spare capacity at steep discounts, can be reclaimed with short notice. Great for fault-tolerant workloads.

1. Open Billing and Cost Management → Cost Explorer.
2. Set the time range to the last 30 or 60 days (or the lifetime of this learning account).
3. Group by Service. Identify the top cost drivers (likely EC2, RDS, ALB, NAT Gateway, data transfer, etc.).
4. Group by Usage Type or API Operation if you want more detail.
5. Look at the Free Tier usage page as well to see how close you are to limits.

Write down the top 3–5 services generating cost.

1. Decide on a simple tagging strategy. Example:
   • Project = SAA-Learning
   • Environment = Dev
   • Owner = your name
   • Week = 07 (optional)
2. Go through major resources (EC2, RDS, ALB, ECS services, S3 buckets, etc.) and apply the tags.
3. In Cost Explorer you can later filter or group by these tags (after tags are activated for cost allocation — this can take up to 24 hours).

Tagging is both a cost practice and an operational excellence / security practice.

Ask these questions about every resource:

• Is it running 24/7 even though I only use it a few hours a week?
• Is the instance/database class oversized for the actual load?
• Do I still need that NAT Gateway?
• Are there old EBS volumes or snapshots that are no longer required?
• Is the ALB still needed right now?
• Are there unused Elastic IPs?

List every resource that can be stopped, downsized, snapshotted, or deleted.

Create a short document (even a text file or a section in your notes) with three sections:

Keep (needed for Capstone or ongoing learning)

• List the resources and why.

Stop / Snapshot (preserve state but stop billing for compute)

• EC2 instances → stop
• RDS → stop (or final snapshot + delete)
• ASG desired capacity → 0

Delete (no longer needed)

• Old test load balancers
• Unused NAT Gateways
• Temporary security groups
• Old AMIs / snapshots
• Test SQS queues, Lambda functions, etc.

Execute the plan. Confirm in Cost Explorer over the following days that spend has dropped dramatically.

Walk through your current architecture and ask one question per pillar:

1. Operational Excellence: Can I observe the system? Do I have runbooks or at least notes for common tasks?
2. Security: Are secrets in Secrets Manager? Are security groups least-privilege? Is encryption enabled?
3. Reliability: Multi-AZ? Auto Scaling? Health checks? Decoupling?
4. Performance Efficiency: Right-sized compute and storage? Caching where appropriate?
5. Cost Optimization: What did the Cost Explorer review reveal? What did you shut down?
6. Sustainability: Are you running resources only when needed? Using efficient instance families?

Note any gaps. You do not need a formal Well-Architected Framework Review tool for this course, but the thinking process is what the exam tests.

• Cost Explorer reviewed and top cost drivers identified
• Major resources tagged
• Written keep / stop / delete plan exists
• Unnecessary resources have been stopped or deleted
• You can articulate at least one improvement under each of the six pillars

1. Leaving NAT Gateways or ALBs running when not actively testing.
2. Forgetting that stopped RDS instances still incur storage costs.
3. Not tagging resources early — it becomes painful later.
4. Treating Free Tier as "completely free forever" instead of monitoring usage.
5. Optimizing for cost before the architecture actually works (premature optimization).

• Cost Explorer review completed
• Resources tagged
• Keep / Stop / Delete plan written and executed
• Quiz ≥ 80%
• Account spend is near zero or clearly understood and controlled

"What surprised me most about the cost of the resources I built, and what will I do differently on the Capstone and in future projects?"

1. Design a complete multi-tier architecture that meets real requirements
2. Deploy the architecture end-to-end on AWS
3. Document the design decisions and how they map to the Well-Architected Framework
4. Complete multiple full-length practice exams
5. Identify and remediate weak areas
6. Reach a state of readiness to book and pass the SAA-C03 exam

Design and deploy one complete, small-scale but production-style multi-tier application on AWS.

Choose something you actually care about — a real side project, a utility service, an API for one of your own apps, or any real workload that benefits from a proper AWS architecture.

Minimum Required Architecture

1. Write the requirements (even if short):
   • What does the application do?
   • Expected traffic pattern?
   • Data storage needs?
   • Availability requirements?
   • Budget constraints?
2. Draw the architecture (Excalidraw, draw.io, or even paper):
   • Show public vs private subnets
   • Show security group relationships
   • Show which services talk to which
3. Implement using the skills from previous weeks:
   • Reuse Launch Templates, roles, and patterns you already built.
   • Prefer infrastructure that can be torn down cleanly.
4. Document:
   • Architecture diagram
   • Key design decisions and why you made them
   • How the architecture maps to the six pillars
   • Estimated monthly cost if left running 24/7
   • Cleanup / teardown instructions
5. Test:
   • End-to-end functionality
   • Failure scenarios (terminate an instance, force a health check failure)
   • Basic load if possible

1. Official Materials

• Read the official SAA-C03 Exam Guide (domains and task statements).
• Review the list of in-scope services.

2. Practice Exams

Take at least two full-length practice exams under realistic conditions (timed, no notes).

Recommended sources (widely regarded as close to the real exam style): Tutorials Dojo, Neal Davis / Digital Cloud Training, or the official AWS practice exam (if available).

For every incorrect question: write down why the correct answer is correct, note which domain it belongs to, and identify the concept you missed.

3. Weak Area Remediation

Common weak areas for many candidates:

• IAM policy evaluation and permission boundaries
• VPC networking edge cases (NAT, endpoints, connectivity)
• Storage class and lifecycle decision making
• Cost optimization scenario questions
• When to choose one service over another (RDS vs DynamoDB, ALB vs NLB, etc.)

Revisit the corresponding week labs and re-read the AWS documentation for those topics.

4. Final Readiness Criteria

You are ready to book the exam when:

• Practice exam scores are consistently ≥ 80%
• You can explain why the correct answers are correct
• You feel comfortable with the four domain weightings and where your remaining gaps are

• Architecture diagram exists and is clear
• Custom VPC with multi-AZ public and private subnets
• Application is highly available (ALB + ASG or Fargate across AZs)
• Database is in private subnets with restricted security groups
• Secrets are in Secrets Manager; compute uses IAM roles
• CloudWatch alarms and a dashboard exist
• End-to-end functionality works
• Design decisions are documented
• Cost estimate and cleanup plan exist

These pull multiple weeks together — think through each before checking the quiz below:

1. How would you change your Capstone architecture if the application needed to serve users on multiple continents with low latency?
2. Walk through the path of an HTTP request from a user on the internet all the way to a row in your private RDS database.
3. Which of the six Well-Architected pillars is currently the weakest in your Capstone, and what would you improve first?

• Capstone application is deployed and functional
• Architecture and decisions are documented
• At least two full practice exams completed with scores tracked
• Weak areas identified and reviewed
• You are ready to book the SAA-C03 exam (or have already booked it)

"What can I now design and deploy on AWS that I could not confidently do 12 weeks ago? What is still unclear or needs more practice?"