Chapter 28: AWS Production Deployment

Your News Aggregator API works perfectly. You can show it to a friend, if they sit next to you. You can demo it to a recruiter, if you schedule a call and hope your WiFi holds. You can handle user traffic, if users only visit when your laptop is awake. Production-ready code trapped in a local environment isn't production-ready at all.

Local vs. Production Environments

Running code locally and running it in production are fundamentally different challenges. Local development means one user, predictable load, direct access to logs, and manual restarts when things break. Production means thousands of concurrent users, unpredictable traffic spikes, servers in data centers you'll never see, and systems that must recover automatically when failures occur.

Your laptop isn't a server

Your laptop goes to sleep when you close the lid. It has no redundancy when the hard drive fails. It has one public IP address that changes when you switch networks. It can't handle 1,000 requests per second. Professional applications run on infrastructure designed for reliability, scalability, and availability. That infrastructure lives in the cloud.

Production requires supporting services

Your News API needs a database. In production, that database needs automated backups, failover to standby instances when the primary fails, and the ability to scale storage without downtime. Your API needs SSL certificates for HTTPS. It needs load balancing so traffic distributes across multiple containers. It needs monitoring to detect problems before users notice them. These supporting services require infrastructure expertise.

Manual deployment doesn't scale

SSH into a server, copy files, restart services, and pray everything works. That process breaks down with multiple servers, multiple deployments per day, and team members who need to deploy safely. Professional applications run on cloud infrastructure designed for reliability and scale: managed databases, serverless containers, load balancers, and centralized logging. This chapter builds that production infrastructure.

Chapter 27 solved one problem: containerization. Your application runs identically on any machine with Docker installed. One command starts your entire stack: FastAPI, PostgreSQL, Redis. No more "works on my machine" debugging. No more missing dependencies. The containers work perfectly, but they only run where you run them.

This chapter solves the deployment problem: You'll deploy your containerized News API to AWS with professional infrastructure: serverless containers on ECS Fargate, managed databases with RDS PostgreSQL and ElastiCache Redis, and public HTTPS access through an Application Load Balancer. You'll learn to view container logs in CloudWatch for troubleshooting. This isn't a proof-of-concept deployment like Railway in Chapter 26. This is production-grade infrastructure demonstrating senior-level skills.

AWS replaces capital-intensive physical infrastructure with pay-as-you-go cloud services, enabling elastic capacity that scales with demand.

By the end, you'll have a live API at a public URL, complete with automatic documentation. You'll understand how to deploy containerized applications to production, configure managed databases, set up load balancing, and view application logs. When you share this with recruiters, you're showing them: "I understand how to deploy systems to the cloud using industry-standard infrastructure patterns." That's the career transformation this chapter enables.

This chapter takes you from a containerized application running on your laptop to a fully deployed production system on AWS. You'll progress through cloud fundamentals, account security, and then build each infrastructure layer one service at a time until your News API is live at a public URL.

You're deploying the exact News API from Chapter 27 with no code changes. Containerization makes that possible. What changes is where your containers run and how they're supported. You'll build complete production infrastructure across multiple AWS services.

Your complete Chapter 28 infrastructure: containerized application deployed to ECS Fargate with managed databases, load balancing, and logging. Chapter 29 will add CI/CD automation, monitoring dashboards, and auto-scaling to this foundation.

By the end of this chapter, you'll be able to:

• Explain cloud computing fundamentals and when to use AWS versus PaaS alternatives
• Set up AWS accounts securely with IAM users, billing alerts, and MFA protection
• Push Docker images to AWS ECR and manage container registry versioning
• Deploy containerized applications using ECS Fargate with proper task definitions and service configuration
• Migrate from local databases to managed RDS PostgreSQL and ElastiCache Redis
• Configure Application Load Balancers with health checks for high availability
• Set up CloudWatch Logs to capture and view container output for troubleshooting
• Configure security groups implementing least-privilege network access control
• Test deployed APIs through load balancer URLs and verify production functionality
• Optimize AWS costs using Free Tier resources and right-sizing strategies

Infrastructure skills separate good developers from great ones. Anyone can write code that works locally. Professional developers write code that works reliably in production, scales under load, recovers from failures automatically, and provides visibility into system behavior. Those skills require infrastructure knowledge.

This chapter teaches production deployment patterns used by companies of all sizes. The specific services change—AWS versus Azure versus Google Cloud—but the patterns remain constant: containerize applications, use managed databases, distribute traffic through load balancers, centralize logging. Learning these patterns with AWS means understanding infrastructure at a fundamental level that transfers to any cloud platform.

When you complete this chapter, you'll have a live News API accessible at a public URL. You'll understand how containers run in the cloud, how databases are managed at scale, how load balancing enables reliability, and how logging provides visibility. These skills demonstrate infrastructure competency that most developers lack. In technical interviews, you can discuss production deployments confidently because you've built one yourself. That competency opens doors to senior engineering roles where infrastructure expertise is expected.

The journey from "works on my laptop" to "deployed on AWS" is transformative. You'll understand not just how to write code, but how to deploy it professionally. That's the difference between completing tutorials and building systems that serve real users. This chapter bridges that gap.

AWS is the world's largest cloud computing platform, offering over 200 services for running applications in the cloud. Instead of buying and maintaining your own servers, you rent computing resources from AWS and pay only for what you use. This chapter uses AWS because it's the industry standard:learning AWS means learning infrastructure patterns that transfer to any cloud platform and any scale of application.

You'll use six core AWS services to deploy your News API. Each service solves a specific production problem: storing Docker images, running containers, managing databases, distributing traffic, and monitoring system health. These six services form the foundation of production deployments at companies of all sizes.

These six services form the core of a production deployment. Additional services support them (IAM for security, VPC for networking, Secrets Manager for credentials) but these six do the heavy lifting. Learn these patterns and you'll understand 80% of typical AWS deployments.

Test your understanding of AWS services and their roles in production infrastructure. If you can answer confidently, you've mastered the material:

Before deploying any infrastructure, you need an AWS account configured securely. This isn't bureaucratic overhead:it's essential risk management. AWS accounts with weak security configurations become targets for cryptocurrency mining attacks, data exfiltration, and resource abuse. Students have received $15,000 bills from attackers who compromised root credentials and launched hundreds of EC2 instances for cryptocurrency mining. Proper account setup prevents these disasters.

This section establishes three critical security practices: root account protection, IAM users for daily work, and billing alerts to catch runaway costs. These practices take 30 minutes to implement and prevent catastrophic failures. Every professional AWS deployment starts here.

AWS requires a credit card for account creation but provides a Free Tier covering many services during your first 12 months. The Free Tier includes 750 hours per month of EC2 compute (enough for one instance running continuously), RDS database instances, limited ElastiCache usage, and more. Staying within Free Tier limits means minimal costs.

Make: Create an AWS account by visiting aws.amazon.com and clicking "Create an AWS Account." You'll need:

• Email address: Use a personal email you control long-term, not a school or employer address that might expire
• Account name: Choose something descriptive like "Personal Development" or "Portfolio Projects"
• Payment information: AWS requires a credit card even for Free Tier usage to prevent abuse
• Identity verification: AWS will call or text to verify your account, this is normal

Check: After creating your account, sign in to the AWS Management Console at console.aws.amazon.com. You'll see the AWS console dashboard with links to all services. This is your root account:it has complete administrative access to everything in your AWS account.

Root account security has three components: strong password, multi-factor authentication (MFA), and restricted usage. These protections stack to prevent unauthorized access.

Step 1: Enable MFA for root account

MFA requires both your password and a time-based code from an authenticator app to sign in. Even if someone obtains your password, they can't access your account without your phone. This single change prevents most account compromises.

Make: Enable MFA on your root account:

1. In the AWS console, click your account name in the top-right corner
2. Select "Security Credentials"
3. Under "Multi-factor authentication (MFA)", click "Assign MFA device"
4. Choose "Authenticator app" (recommended over hardware tokens for cost and convenience)
5. Scan the QR code with an authenticator app like Google Authenticator, Authy, or 1Password
6. Enter two consecutive MFA codes to verify the device works

Check: Sign out of AWS and sign back in. You'll be prompted for your MFA code in addition to your password. This two-factor authentication now protects your root account.

Billing alerts notify you when AWS charges exceed specified thresholds. Without alerts, you won't discover runaway costs until the credit card bill arrives. A compromised account or misconfigured auto-scaling policy can generate thousands of dollars in charges overnight. Billing alerts provide early warning.

Make: Configure billing alerts through AWS Budgets:

1. In the AWS Console, search for "Billing" in the top search bar
2. Click "Billing" to open the Billing dashboard
3. In the left sidebar, select "Budgets"
4. Click "Create budget"
5. Choose "Cost budget" template
6. Set budget amount to $25 (or your preferred threshold)
7. Configure alerts at 80% ($20) and 100% ($25) of budget
8. Enter your email address for notifications
9. Review and create the budget

Check: You'll receive a confirmation email for the budget alerts. Click the confirmation link to activate notifications. Now you'll get emails when AWS spending approaches or exceeds your threshold.

Cost strategy for this chapter: Most services in this chapter qualify for AWS Free Tier during your first 12 months. Expected costs staying within Free Tier: $5-15 per month for Application Load Balancer hours and data transfer. Setting a $25 budget provides room for experimentation while alerting you if costs spike unexpectedly.

IAM (Identity and Access Management) controls who can access your AWS account and what they can do. Instead of using your root account, you create IAM users with specific permissions. This follows the principle of least privilege: grant only the permissions necessary for the task at hand.

Make: Create an IAM user for deployment work:

1. While still signed in as root, navigate to the IAM service in the AWS Console
2. Click "Users" in the left sidebar, then "Add users"
3. Set username to "deployment-user" (or your preferred name)
4. Select "Programmatic access" (creates access keys for CLI/SDK)
5. Select "AWS Management Console access" (allows web console login)
6. Click "Next: Permissions"
7. Select "Attach existing policies directly"
8. Search for and attach: AdministratorAccess
9. Click "Next: Tags" (skip), then "Next: Review", then "Create user"

Check: AWS displays your access credentials. You'll see:

• Access Key ID: Like a username for programmatic access
• Secret Access Key: Like a password, shown only once
• Console sign-in link: URL for web console access

Critical: Download these credentials immediately. The Secret Access Key is shown only once. If you lose it, you'll need to generate new keys. Store credentials securely in a password manager.

The AWS CLI (Command Line Interface) lets you interact with AWS services from your terminal. You'll use it to push Docker images to ECR, deploy ECS tasks, and manage infrastructure. The CLI needs your IAM credentials to authenticate requests.

Make: Install and configure the AWS CLI:

# macOS
brew install awscli

# Linux
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Verify installation
aws --version

Configure your credentials:

aws configure

# You'll be prompted for:
AWS Access Key ID: [paste your Access Key ID]
AWS Secret Access Key: [paste your Secret Access Key]
Default region name: us-east-1
Default output format: json

Check: Verify AWS CLI access:

aws sts get-caller-identity

# Output shows your IAM user:
{
    "UserId": "AIDAI...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/deployment-user"
}

Your AWS CLI is configured. Commands you run use your IAM user credentials, not root. This follows security best practices and provides an audit trail of actions performed programmatically.

Your News API Docker image currently exists only on your local machine. To deploy to AWS, ECS needs access to that image. Container registries solve this distribution problem. They store Docker images in the cloud, making them accessible to deployment infrastructure worldwide.

ECR (Elastic Container Registry) is AWS's container registry service. It integrates seamlessly with ECS, provides built-in scanning for vulnerabilities, and uses IAM for access control. While Docker Hub is free for public images, ECR offers better performance when pulling images to AWS services and includes private registries by default.

ECR organizes images into repositories. Each repository holds versions of one application. You'll create a repository for your News Aggregator API, then push your Docker image there.

Make: Create an ECR repository via AWS CLI:

aws ecr create-repository \
    --repository-name news-aggregator-api \
    --region us-east-1 \
    --image-scanning-configuration scanOnPush=true

# Output:
{
    "repository": {
        "repositoryArn": "arn:aws:ecr:us-east-1:123456789012:repository/news-aggregator-api",
        "registryId": "123456789012",
        "repositoryName": "news-aggregator-api",
        "repositoryUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/news-aggregator-api",
        "createdAt": "2024-12-10T10:30:00+00:00",
        "imageScanningConfiguration": {
            "scanOnPush": true
        }
    }
}

Key field: The repositoryUri is where you'll push images. Save this URI: you'll use it for tagging and pushing your Docker image.

What scanOnPush=true does: ECR automatically scans images for known security vulnerabilities (CVEs) when you push them. You'll get a report showing any security issues in your dependencies. This is free within the Free Tier scanning limits.

Check: Verify the repository exists:

aws ecr describe-repositories --region us-east-1

# Shows your news-aggregator-api repository

ECR repositories are private by default. Before pushing images, Docker needs authentication credentials. The AWS CLI generates temporary credentials that expire after 12 hours. You'll authenticate each session before pushing images.

Make: Authenticate Docker with ECR:

aws ecr get-login-password --region us-east-1 | \
    docker login --username AWS --password-stdin \
    123456789012.dkr.ecr.us-east-1.amazonaws.com

# Replace 123456789012 with your actual AWS account ID
# Get it from: aws sts get-caller-identity --query Account --output text

# Output on success:
Login Succeeded

What this does: The AWS CLI retrieves temporary Docker login credentials and pipes them to docker login. Docker stores these credentials locally until they expire. Now Docker can push and pull images from your ECR repository.

Credentials expire after 12 hours. If you get authentication errors later, rerun this command to refresh your Docker authentication with ECR.

Before pushing to ECR, you need to tag your local Docker image with the ECR repository URI. Docker uses tags to map images to registries. The tag format is: repositoryUri:version.

Make: Tag and push your News API image:

# Get your ECR repository URI
ECR_URI=$(aws ecr describe-repositories \
    --repository-names news-aggregator-api \
    --query 'repositories[0].repositoryUri' \
    --output text)

echo "ECR URI: $ECR_URI"

# Tag your local image
# If your image is called "news-api:latest" from Chapter 27:
docker tag news-api:latest $ECR_URI:latest
docker tag news-api:latest $ECR_URI:v1.0.0

# Push both tags to ECR
docker push $ECR_URI:latest
docker push $ECR_URI:v1.0.0

Check: Verify images in ECR:

aws ecr list-images \
    --repository-name news-aggregator-api \
    --region us-east-1

# Output shows your images:
{
    "imageIds": [
        {
            "imageDigest": "sha256:abc123...",
            "imageTag": "latest"
        },
        {
            "imageDigest": "sha256:abc123...",
            "imageTag": "v1.0.0"
        }
    ]
}

Your Docker image is now in ECR, accessible to AWS services. ECS will pull from this registry when deploying containers. The image is private:only your AWS account can access it.

Docker tags identify image versions. Professional deployments use multiple tagging strategies simultaneously for flexibility and traceability.

Recommended strategy: Tag with all three: latest for convenience, semantic version for release management, and commit SHA for traceability.

# Get current Git commit SHA
COMMIT_SHA=$(git rev-parse --short HEAD)

# Tag with all three strategies
docker tag news-api:latest $ECR_URI:latest
docker tag news-api:latest $ECR_URI:v1.2.3
docker tag news-api:latest $ECR_URI:sha-$COMMIT_SHA

# Push all tags
docker push $ECR_URI:latest
docker push $ECR_URI:v1.2.3
docker push $ECR_URI:sha-$COMMIT_SHA

Your News API currently connects to local PostgreSQL and Redis from Chapter 27. Those containerized databases work perfectly for development, but production requires different trade-offs. Databases hold your application's most valuable asset: data. Losing database data means losing user accounts, articles, rate limit tracking, and everything else your application depends on. Production databases need automated backups, failover when hardware fails, and professional monitoring.

Managed database services handle this operational complexity. AWS RDS manages PostgreSQL with automated daily backups, point-in-time recovery, and multi-availability-zone replication. AWS ElastiCache manages Redis with automatic failover and monitoring. You connect to them exactly like local databases, but AWS handles operations, maintenance, and disaster recovery. This is infrastructure you don't want to manage yourself.

You could run PostgreSQL and Redis in ECS containers alongside your application. Many teams start this way. But containerized databases create operational burden that managed services eliminate.

Backups require manual implementation. Containerized PostgreSQL means you're responsible for backup scripts, testing restore procedures, storing backups securely, and ensuring backups actually work when disaster strikes. RDS handles this automatically: daily snapshots, transaction logs for point-in-time recovery, and automated testing of backup integrity.

Scaling storage requires downtime. When your containerized database fills its disk, you need to stop the container, resize the volume, and restart. With RDS, you modify the storage size through the console. RDS scales storage online without downtime. Your application never notices.

High availability requires complex orchestration. To survive container failures, you need primary-replica setup, health checks, automatic failover, and data synchronization. RDS Multi-AZ handles this automatically. The primary fails, RDS promotes the replica, and updates the DNS endpoint. Your application connection string doesn't change. Failover happens in under 60 seconds without manual intervention.

Maintenance requires planning. PostgreSQL security patches, minor version updates, and configuration tuning all require careful timing and testing. RDS provides maintenance windows where AWS applies patches automatically during low-traffic periods you specify.

The cost trade-off favors managed services. Running PostgreSQL in ECS means paying for the container and managing operations yourself. RDS costs slightly more but includes backups, monitoring, and 24/7 AWS support. The operational time savings alone justify the cost difference.

Your News API needs PostgreSQL for storing articles, API keys, and rate limit tracking. You'll create an RDS PostgreSQL instance using the Free Tier eligible configuration: db.t3.micro (or db.t4g.micro) with 20GB storage. This provides enough capacity for hundreds of thousands of articles while staying within Free Tier limits during your first year.

Make: Create RDS PostgreSQL instance via AWS CLI:

aws rds create-db-instance \
    --db-instance-identifier news-api-db \
    --db-instance-class db.t3.micro \
    --engine postgres \
    --engine-version 15.4 \
    --master-username newsadmin \
    --master-user-password 'YourSecurePassword123!' \
    --allocated-storage 20 \
    --storage-type gp3 \
    --no-publicly-accessible \
    --backup-retention-period 7 \
    --preferred-backup-window "03:00-04:00" \
    --preferred-maintenance-window "sun:04:00-sun:05:00" \
    --region us-east-1

# This takes 5-10 minutes to provision
# Check status:
aws rds describe-db-instances \
    --db-instance-identifier news-api-db \
    --query 'DBInstances[0].DBInstanceStatus' \
    --output text

# Output: "creating" -> "available"

Important settings explained:

--no-publicly-accessible: The database isn't accessible from the internet. Only resources within your AWS VPC can connect. This is critical security: your database should never be exposed to public internet, even with strong passwords.

--backup-retention-period 7: RDS keeps daily backups for 7 days. You can restore to any point within the last week. Free Tier allows up to 7 days. Production systems often use 14-30 days.

--storage-type gp3: General Purpose SSD (gp3) provides good performance at reasonable cost. It's Free Tier eligible and suitable for most applications. You could use gp2 (older generation) or io1 (provisioned IOPS for high-performance needs), but gp3 is the sweet spot.

Check: Get your database endpoint:

aws rds describe-db-instances \
    --db-instance-identifier news-api-db \
    --query 'DBInstances[0].Endpoint.Address' \
    --output text

# Output (save this):
news-api-db.c9z8v7x2y3z4.us-east-1.rds.amazonaws.com

This endpoint address is your PostgreSQL connection string. It looks like a regular database hostname because that's exactly what it is. Your application will connect to news-api-db.c9z8v7x2y3z4.us-east-1.rds.amazonaws.com:5432 exactly like connecting to localhost:5432, just with the RDS endpoint instead.

RDS created your database with a default security group that blocks all inbound connections. This is correct security posture: deny everything by default, then explicitly allow only necessary traffic. You need to allow inbound connections from your ECS containers on port 5432 (PostgreSQL's default port).

Security groups act as virtual firewalls. Each security group has inbound rules (what traffic can reach your resource) and outbound rules (what traffic your resource can send). For RDS, you'll create an inbound rule allowing PostgreSQL traffic from ECS.

Make: First, get your RDS security group ID:

RDS_SG=$(aws rds describe-db-instances \
    --db-instance-identifier news-api-db \
    --query 'DBInstances[0].VpcSecurityGroups[0].VpcSecurityGroupId' \
    --output text)

echo "RDS Security Group: $RDS_SG"

Now allow PostgreSQL traffic from ECS containers. For now, we'll allow traffic from anywhere within your VPC (we'll tighten this in Section 6 when we create the ECS security group):

# Get your default VPC CIDR (usually 172.31.0.0/16)
VPC_CIDR=$(aws ec2 describe-vpcs \
    --filters "Name=isDefault,Values=true" \
    --query 'Vpcs[0].CidrBlock' \
    --output text)

# Add inbound rule for PostgreSQL
aws ec2 authorize-security-group-ingress \
    --group-id $RDS_SG \
    --protocol tcp \
    --port 5432 \
    --cidr $VPC_CIDR

# Verify the rule exists
aws ec2 describe-security-groups \
    --group-ids $RDS_SG \
    --query 'SecurityGroups[0].IpPermissions'

What this means: Any resource within your VPC (including ECS containers we'll create in Section 6) can now connect to RDS PostgreSQL on port 5432. Resources outside your VPC still can't access the database because RDS has --no-publicly-accessible set.

Check: Test connection from your local machine (requires AWS VPN or bastion host, so we'll test from ECS in Section 6).

Chapter 27 demonstrated Redis's performance impact: response times improved from 700ms to 5ms for cached articles. ElastiCache provides managed Redis with the same performance benefits plus automatic failover and monitoring. You'll create a cache.t3.micro instance (Free Tier eligible) for the News API's caching layer.

Make: Create ElastiCache Redis cluster:

aws elasticache create-cache-cluster \
    --cache-cluster-id news-api-cache \
    --cache-node-type cache.t3.micro \
    --engine redis \
    --engine-version 7.0 \
    --num-cache-nodes 1 \
    --region us-east-1

# Takes 5-10 minutes
# Check status:
aws elasticache describe-cache-clusters \
    --cache-cluster-id news-api-cache \
    --query 'CacheClusters[0].CacheClusterStatus' \
    --output text

# Output: "creating" -> "available"

Get your Redis endpoint:

aws elasticache describe-cache-clusters \
    --cache-cluster-id news-api-cache \
    --show-cache-node-info \
    --query 'CacheClusters[0].CacheNodes[0].Endpoint' \
    --output json

# Output:
{
    "Address": "news-api-cache.abc123.0001.use1.cache.amazonaws.com",
    "Port": 6379
}

Save this endpoint. You'll use it in your ECS task definition environment variables: redis://news-api-cache.abc123.0001.use1.cache.amazonaws.com:6379.

Configure security group for Redis:

# Get ElastiCache security group
REDIS_SG=$(aws elasticache describe-cache-clusters \
    --cache-cluster-id news-api-cache \
    --show-cache-node-info \
    --query 'CacheClusters[0].SecurityGroups[0].SecurityGroupId' \
    --output text)

# Allow Redis traffic from VPC
aws ec2 authorize-security-group-ingress \
    --group-id $REDIS_SG \
    --protocol tcp \
    --port 6379 \
    --cidr $VPC_CIDR

Your local PostgreSQL database contains articles, API keys, and rate limit data from Chapter 26-27 testing. You can migrate this data to RDS for continuity, or start fresh in production. For learning purposes, starting fresh is simpler:your ECS application will create tables automatically using SQLAlchemy migrations on first startup.

Option 1: Start fresh (recommended for learning)

Your News API's SQLAlchemy models include Base.metadata.create_all() or Alembic migrations. When ECS containers start and connect to the empty RDS database, they'll automatically create the required tables. You'll generate new API keys through your admin endpoint after deployment.

Option 2: Migrate existing data (for production continuity)

If you want to preserve local data, use pg_dump to export and psql to import:

# Export from local database
pg_dump -h localhost -U newsuser -d newsdb > news_backup.sql

# Import to RDS (requires network access - typically via EC2 bastion or VPN)
psql -h news-api-db.c9z8v7x2y3z4.us-east-1.rds.amazonaws.com \
     -U newsadmin -d postgres < news_backup.sql

For this chapter, we'll use Option 1 (fresh start). Your application handles database initialization automatically, and generating new API keys in production is a security best practice anyway.

Your News API reads database connection strings from environment variables. Update these for RDS and ElastiCache endpoints:

You'll configure these in your ECS task definition (Section 6). The application code remains unchanged: only connection strings change between local and production.

Test your understanding of managed databases and production infrastructure. If you can answer confidently, you've mastered the material:

Your News API Docker image sits in ECR. Your databases are running in RDS and ElastiCache. Now you need computing infrastructure to run your containers. AWS ECS (Elastic Container Service) is AWS's container orchestration platform:think of it as Docker Compose for AWS, managing container deployment, health checks, and scaling across multiple servers.

ECS supports two launch types: EC2 (you manage the servers) and Fargate (AWS manages the servers). Fargate is serverless containers:you specify container requirements (CPU, memory, image), and AWS handles provisioning, patching, and scaling servers automatically. You never SSH into servers, worry about kernel updates, or calculate how many containers fit on an instance. Fargate is the modern default for containerized applications.

ECS has three core concepts that work together to run your containers:

How they work together: You create a cluster (environment), define a task definition (blueprint), create a service that uses that task definition (manager), and ECS runs the specified number of tasks (containers) continuously. If tasks crash, the service restarts them. If you update the task definition, you deploy a new revision to the service.

Fargate clusters are simple to create:they're just logical namespaces. No server provisioning, networking configuration, or capacity planning required.

Make: Create an ECS cluster:

aws ecs create-cluster \
    --cluster-name news-api-cluster \
    --region us-east-1

# Output:
{
    "cluster": {
        "clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/news-api-cluster",
        "clusterName": "news-api-cluster",
        "status": "ACTIVE",
        "registeredContainerInstancesCount": 0,
        "runningTasksCount": 0,
        "pendingTasksCount": 0
    }
}

Check: Verify cluster creation:

aws ecs list-clusters --region us-east-1

# Shows your news-api-cluster

The cluster is ready. Now you'll create the task definition that specifies how to run your News API container.

Task definitions are JSON documents specifying container configuration. You'll create a task definition for your News API with:

• Your ECR image URI from Section 4
• CPU allocation: 256 units (.25 vCPU)
• Memory allocation: 512 MB
• Environment variables for database connections and API keys
• Port mapping: container port 8000 to host port 8000
• CloudWatch Logs configuration for centralized logging

Make: Create a task definition JSON file:

{
  "family": "news-api-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "news-api",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/news-aggregator-api:latest",
      "portMappings": [
        {
          "containerPort": 8000,
          "protocol": "tcp"
        }
      ],
      "environment": [
        {
          "name": "DATABASE_URL",
          "value": "postgresql://newsadmin:YourSecurePassword123!@news-api-db.c9z8v7x2y3z4.us-east-1.rds.amazonaws.com:5432/postgres"
        },
        {
          "name": "REDIS_URL",
          "value": "redis://news-api-cache.abc123.0001.use1.cache.amazonaws.com:6379"
        },
        {
          "name": "NEWSAPI_KEY",
          "value": "your-newsapi-key-here"
        },
        {
          "name": "GUARDIAN_KEY",
          "value": "your-guardian-key-here"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/news-api",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Key configuration explained:

family: Task definition name. Updates to this task definition create new revisions (news-api-task:1, news-api-task:2, etc.).

networkMode: awsvpc: Each task gets its own elastic network interface with a private IP address. This is required for Fargate and provides task-level network isolation.

cpu and memory: Fargate has specific valid combinations. 256 CPU (.25 vCPU) with 512MB memory is Free Tier eligible and sufficient for light-to-moderate API traffic. See AWS documentation for other valid combinations.

executionRoleArn: IAM role that grants ECS permission to pull images from ECR and write logs to CloudWatch. Create this role or use the AWS-managed default.

environment variables: Your application reads these at runtime. Replace placeholder values with your actual RDS endpoint, ElastiCache endpoint, and API keys.

logConfiguration: Sends container stdout/stderr to CloudWatch Logs. You'll query these logs for debugging in Section 9.

Before registering the task definition, create the CloudWatch log group:

aws logs create-log-group \
    --log-group-name /ecs/news-api \
    --region us-east-1

Register the task definition:

aws ecs register-task-definition \
    --cli-input-json file://task-definition.json \
    --region us-east-1

# Output shows task definition registered as revision 1

Check: List task definitions:

aws ecs list-task-definitions --region us-east-1

# Shows: news-api-task:1

The task definition describes what to run. The service describes how many to run and where to run them. You'll create a service that maintains 2 tasks (containers) running continuously in your cluster.

Make: Create an ECS service:

# Get default VPC and subnet IDs
VPC_ID=$(aws ec2 describe-vpcs \
    --filters "Name=isDefault,Values=true" \
    --query 'Vpcs[0].VpcId' \
    --output text)

SUBNET_IDS=$(aws ec2 describe-subnets \
    --filters "Name=vpc-id,Values=$VPC_ID" \
    --query 'Subnets[*].SubnetId' \
    --output text | tr '\t' ',')

# Create security group for ECS tasks
ECS_SG=$(aws ec2 create-security-group \
    --group-name news-api-ecs-sg \
    --description "Security group for News API ECS tasks" \
    --vpc-id $VPC_ID \
    --query 'GroupId' \
    --output text)

# Allow outbound traffic (required for pulling ECR images, accessing RDS/Redis)
aws ec2 authorize-security-group-egress \
    --group-id $ECS_SG \
    --protocol -1 \
    --cidr 0.0.0.0/0

# Create the service
aws ecs create-service \
    --cluster news-api-cluster \
    --service-name news-api-service \
    --task-definition news-api-task:1 \
    --desired-count 2 \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[$SUBNET_IDS],securityGroups=[$ECS_SG],assignPublicIp=ENABLED}" \
    --region us-east-1

What this does:

desired-count: 2: ECS maintains 2 running tasks at all times. If a task fails, ECS starts a replacement immediately. This provides high availability:if one container crashes, the other continues serving requests.

launch-type: FARGATE: Use serverless containers. No server management required.

network-configuration: Tasks run in your default VPC subnets. Each task gets a private IP address from the subnet range. assignPublicIp=ENABLED gives tasks public IP addresses so they can pull images from ECR (ECR requires internet access or VPC endpoints).

Check: Monitor service deployment:

aws ecs describe-services \
    --cluster news-api-cluster \
    --services news-api-service \
    --query 'services[0].{Status:status,Running:runningCount,Desired:desiredCount}' \
    --output table

# Output shows deployment progress:
# Status: ACTIVE
# Running: 2
# Desired: 2

When runningCount equals desiredCount, your containers are running. This typically takes 2-3 minutes for initial deployment (pulling image, starting containers, running health checks).

View container logs in CloudWatch:

aws logs tail /ecs/news-api --follow --region us-east-1

# Shows real-time container logs:
# INFO:     Uvicorn running on http://0.0.0.0:8000
# INFO:     Application startup complete
# INFO:     Connected to PostgreSQL database
# INFO:     Connected to Redis cache

Your News API is now running on AWS! The containers are deployed, connected to RDS and ElastiCache, and logging to CloudWatch. However, you can't access them yet:they have private IP addresses within your VPC. Section 7 adds the Application Load Balancer that provides public HTTPS access.

Your containers are running but only accessible within your VPC. To verify they're working before adding the load balancer, you have two options: create a bastion host (EC2 instance in the same VPC for SSH access), or temporarily add an inbound rule to the ECS security group allowing your home IP address.

Quick verification (temporary public access):

# Get your public IP
MY_IP=$(curl -s https://checkip.amazonaws.com)

# Allow HTTP access from your IP temporarily
aws ec2 authorize-security-group-ingress \
    --group-id $ECS_SG \
    --protocol tcp \
    --port 8000 \
    --cidr $MY_IP/32

# Get a task's public IP
TASK_IP=$(aws ecs list-tasks \
    --cluster news-api-cluster \
    --service-name news-api-service \
    --query 'taskArns[0]' \
    --output text | xargs -I {} aws ecs describe-tasks \
    --cluster news-api-cluster \
    --tasks {} \
    --query 'tasks[0].attachments[0].details[?name==`networkInterfaceId`].value' \
    --output text | xargs -I {} aws ec2 describe-network-interfaces \
    --network-interface-ids {} \
    --query 'NetworkInterfaces[0].Association.PublicIp' \
    --output text)

echo "Task public IP: $TASK_IP"

# Test the API
curl http://$TASK_IP:8000/docs

# Remove the temporary rule after testing
aws ec2 revoke-security-group-ingress \
    --group-id $ECS_SG \
    --protocol tcp \
    --port 8000 \
    --cidr $MY_IP/32

If you see the FastAPI documentation page at http://TASK_IP:8000/docs, your containers are working correctly. They're connected to RDS and ElastiCache, serving requests, and ready for production traffic through the load balancer you'll create in Section 7.

Your News API containers are running in ECS Fargate with private IP addresses. Users can't access them directly because containers aren't assigned public DNS names, and their IP addresses change when tasks restart. This is by design: containers are ephemeral infrastructure. You need a stable public endpoint that routes traffic to whatever containers are currently running.

Application Load Balancers (ALBs) solve this problem. An ALB is a managed service that distributes incoming HTTP/HTTPS requests across multiple targets (in this case, your ECS containers). The ALB has a public DNS name that never changes. Behind that stable endpoint, containers can start, stop, restart, and scale:the ALB automatically adjusts routing to healthy containers. Users always connect to the same URL, even as your infrastructure changes underneath.

ALBs handle multiple concerns that your application shouldn't manage itself:

For your News API, the ALB provides a public HTTPS URL like https://news-api-123456789.us-east-1.elb.amazonaws.com (or your custom domain) that forwards to your ECS containers. This is the URL you'll share with recruiters and users.

ALBs require several components: the load balancer itself, target groups (where traffic routes to), security groups (firewall rules), and listeners (routing rules for different protocols/ports). You'll create all of these to connect your public endpoint to your ECS containers.

Make: Create an Application Load Balancer:

# Get VPC and subnets (need at least 2 subnets in different AZs)
VPC_ID=$(aws ec2 describe-vpcs \
    --filters "Name=isDefault,Values=true" \
    --query 'Vpcs[0].VpcId' \
    --output text)

SUBNET_IDS=$(aws ec2 describe-subnets \
    --filters "Name=vpc-id,Values=$VPC_ID" \
    --query 'Subnets[0:2].SubnetId' \
    --output text | tr '\t' ' ')

# Create security group for ALB (allows HTTP/HTTPS from internet)
ALB_SG=$(aws ec2 create-security-group \
    --group-name news-api-alb-sg \
    --description "Security group for News API ALB" \
    --vpc-id $VPC_ID \
    --query 'GroupId' \
    --output text)

# Allow inbound HTTP (port 80) from anywhere
aws ec2 authorize-security-group-ingress \
    --group-id $ALB_SG \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

# Allow inbound HTTPS (port 443) from anywhere
aws ec2 authorize-security-group-ingress \
    --group-id $ALB_SG \
    --protocol tcp \
    --port 443 \
    --cidr 0.0.0.0/0

# Create the Application Load Balancer
ALB_ARN=$(aws elbv2 create-load-balancer \
    --name news-api-alb \
    --subnets $SUBNET_IDS \
    --security-groups $ALB_SG \
    --scheme internet-facing \
    --type application \
    --ip-address-type ipv4 \
    --query 'LoadBalancers[0].LoadBalancerArn' \
    --output text)

echo "Load Balancer ARN: $ALB_ARN"

# Get the ALB's public DNS name
ALB_DNS=$(aws elbv2 describe-load-balancers \
    --load-balancer-arns $ALB_ARN \
    --query 'LoadBalancers[0].DNSName' \
    --output text)

echo "Your API will be accessible at: http://$ALB_DNS"

What this creates: A public-facing load balancer in two availability zones (for high availability). The ALB accepts HTTP and HTTPS traffic from the internet and will forward it to your ECS containers. The DNS name is available immediately, but you need to configure target groups and listeners before traffic flows through.

Target groups define where the ALB sends traffic. For ECS, you create a target group with target type ip (since Fargate tasks use awsvpc networking and get IP addresses). ECS automatically registers and deregisters container IP addresses as tasks start and stop.

Make: Create a target group with health checks:

TARGET_GROUP_ARN=$(aws elbv2 create-target-group \
    --name news-api-tg \
    --protocol HTTP \
    --port 8000 \
    --vpc-id $VPC_ID \
    --target-type ip \
    --health-check-enabled \
    --health-check-protocol HTTP \
    --health-check-path /docs \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3 \
    --query 'TargetGroups[0].TargetGroupArn' \
    --output text)

echo "Target Group ARN: $TARGET_GROUP_ARN"

Health check configuration explained:

health-check-path: /docs: The ALB requests this path every 30 seconds. FastAPI's automatic documentation endpoint always returns 200 OK if the application is running. If the container can't respond (crashed, unresponsive, network issue), health checks fail.

healthy-threshold-count: 2: The container must pass 2 consecutive health checks (60 seconds total) before receiving traffic. This prevents routing to containers that are still starting up.

unhealthy-threshold-count: 3: The container must fail 3 consecutive health checks (90 seconds) before being marked unhealthy and removed from rotation. This prevents brief hiccups from triggering unnecessary container restarts.

These thresholds balance responsiveness (detecting failures quickly) with stability (not overreacting to transient issues). Tuning these values is a production operations skill.

Listeners define how the ALB handles incoming traffic. You'll create an HTTP listener that forwards all requests to your target group. For production, you'd also create an HTTPS listener with SSL certificates, but HTTP works for initial testing.

Make: Create HTTP listener:

aws elbv2 create-listener \
    --load-balancer-arn $ALB_ARN \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=$TARGET_GROUP_ARN

# Output shows listener created successfully

What this does: Requests to http://your-alb-dns.amazonaws.com on port 80 forward to your target group, which routes to healthy ECS containers on port 8000. The routing happens automatically:no additional configuration needed.

Your ECS service and ALB target group exist independently. You need to update the ECS service to register containers with the target group automatically. ECS will handle adding new task IP addresses to the target group when containers start, and removing them when containers stop.

Make: Update ECS service to use load balancer:

# Update ECS security group to allow ALB traffic
aws ec2 authorize-security-group-ingress \
    --group-id $ECS_SG \
    --protocol tcp \
    --port 8000 \
    --source-group $ALB_SG

# Update the service with load balancer configuration
aws ecs update-service \
    --cluster news-api-cluster \
    --service news-api-service \
    --load-balancers "targetGroupArn=$TARGET_GROUP_ARN,containerName=news-api,containerPort=8000" \
    --health-check-grace-period-seconds 60 \
    --region us-east-1

# Note: This requires recreating the service because load balancer
# configuration can't be modified on existing services
# Instead, delete and recreate:

aws ecs delete-service \
    --cluster news-api-cluster \
    --service news-api-service \
    --force

# Wait 2 minutes for service to fully terminate

# Recreate with load balancer
aws ecs create-service \
    --cluster news-api-cluster \
    --service-name news-api-service \
    --task-definition news-api-task:1 \
    --desired-count 2 \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[$SUBNET_IDS],securityGroups=[$ECS_SG],assignPublicIp=ENABLED}" \
    --load-balancers "targetGroupArn=$TARGET_GROUP_ARN,containerName=news-api,containerPort=8000" \
    --health-check-grace-period-seconds 60 \
    --region us-east-1

health-check-grace-period-seconds: ECS waits 60 seconds after starting containers before health checks affect service stability. This grace period prevents ECS from marking containers unhealthy during startup (when they're still initializing databases, loading configuration, etc.).

Check: Wait 2-3 minutes for containers to register, then verify target health:

aws elbv2 describe-target-health \
    --target-group-arn $TARGET_GROUP_ARN \
    --query 'TargetHealthDescriptions[*].{Target:Target.Id,Health:TargetHealth.State}' \
    --output table

# Output shows 2 targets with "healthy" status:
# --------------------------------
# |  Target        | Health      |
# --------------------------------
# | 10.0.1.123     | healthy     |
# | 10.0.2.456     | healthy     |
# --------------------------------

When both targets show healthy, your API is ready to serve traffic through the load balancer.

Your News API is now publicly accessible through the Application Load Balancer. The ALB DNS name provides a stable endpoint that distributes requests across your ECS containers.

Check: Test all endpoints through the load balancer:

# Get your ALB DNS name
ALB_DNS=$(aws elbv2 describe-load-balancers \
    --load-balancer-arns $ALB_ARN \
    --query 'LoadBalancers[0].DNSName' \
    --output text)

echo "Testing API at: http://$ALB_DNS"

# Test automatic documentation
curl http://$ALB_DNS/docs

# Test articles endpoint
curl http://$ALB_DNS/articles

# Test categories endpoint  
curl http://$ALB_DNS/categories

# Test sources endpoint
curl http://$ALB_DNS/sources

# Test with filters
curl "http://$ALB_DNS/articles?category=technology&source=newsapi"

# Test authenticated endpoint (requires API key)
curl -H "Authorization: Bearer YOUR_API_KEY" http://$ALB_DNS/articles

Visit in browser: Open http://YOUR-ALB-DNS/docs in your browser. You'll see FastAPI's interactive documentation. This is your publicly accessible API:anyone with the URL can access it. This is what you'll share with recruiters and users.

Success criteria: If you see JSON responses from the articles, categories, and sources endpoints, your complete infrastructure is working: ECR provides images, ECS runs containers, RDS provides PostgreSQL, ElastiCache provides Redis, and the ALB routes traffic. You've built production infrastructure from scratch.

HTTP works for testing, but production APIs require HTTPS. AWS Certificate Manager (ACM) provides free SSL certificates for use with load balancers. You need a custom domain (like api.yourdomain.com) to use ACM certificates.

If you have a custom domain:

1. Request an SSL certificate in ACM for your domain
2. Validate domain ownership via DNS or email
3. Create an HTTPS listener on port 443 using the ACM certificate
4. Add a redirect rule on the HTTP listener to redirect HTTP → HTTPS
5. Create a Route 53 alias record pointing your domain to the ALB DNS name

Without a custom domain: The ALB DNS name works perfectly for testing and portfolio projects. Many students deploy with the default ALB DNS name and document: "Uses AWS ALB for load balancing and high availability" in their portfolio. Custom domains are polish, not requirements.

You started this chapter with a News API that worked perfectly on localhost:8000 but disappeared when you closed your laptop. You finish with production infrastructure running on AWS: containers deployed on ECS Fargate, managed databases providing reliable data storage, a load balancer distributing traffic across multiple containers, and a public HTTPS endpoint accessible to anyone in the world. You can show recruiters a live API with professional deployment patterns and explain every infrastructure decision in technical interviews.

More importantly, you understand the "why" behind each component. ECR centralizes container images. RDS and ElastiCache eliminate database operations overhead. ECS Fargate removes server management. ALBs provide stable public endpoints with automatic failover. Security groups implement least-privilege access control. These aren't abstract concepts: you implemented them yourself and watched them work.

The patterns you learned here (container registries, serverless compute, managed databases, load balancing, health checks) apply to any cloud platform and any scale of application. You've moved from "I can write code" to "I can build and deploy systems at scale." That expertise opens doors to senior engineering roles where deployment decisions shape entire organizations.

Congratulations on deploying to production. The next chapter makes that deployment world-class.

Test your understanding with these questions. If you can answer confidently, you've mastered the material:

Your News API is deployed on AWS and serving requests at a public URL. You've built production infrastructure: ECS Fargate runs your containers, RDS PostgreSQL and ElastiCache Redis provide managed persistence, an Application Load Balancer distributes traffic, and CloudWatch Logs capture container output. This is a major achievement. Your application runs in the cloud with professional infrastructure patterns.

But if you just deployed a code change, you experienced the manual deployment process: authenticate Docker with ECR, build the image locally, tag it, push to ECR, create a new task definition revision, update the ECS service, wait for health checks, verify deployment success. That workflow took 10-15 minutes and involved multiple AWS CLI commands. Run it once and it feels manageable. Run it ten times and you're tired of repetition. Run it a hundred times across a team and someone will eventually forget a step.

Your infrastructure works, but you're operating it manually. When containers fail, you discover it by checking the ECS console. When response times degrade, users notice before you do. When traffic spikes, your fixed two-container capacity becomes a bottleneck. You have deployment, but you don't have operations. Chapter 29 transforms your AWS infrastructure from basic deployment into professional production operations.

CI/CD with GitHub Actions: Automated deployment pipelines eliminate manual AWS CLI commands entirely. Every git push triggers tests automatically. Passing tests trigger Docker builds with commit SHA tags for complete traceability. Images push to ECR automatically. ECS updates to new task definitions without human intervention. Failed deployments rollback automatically. The entire process completes in 5-8 minutes from code commit to production deployment. You'll build this pipeline yourself, transforming deployment from error-prone manual work into reliable, repeatable automation.

CloudWatch Monitoring with Golden Signals: You'll implement comprehensive production monitoring tracking the four Golden Signals: latency, traffic, errors, and saturation. CloudWatch dashboards visualize system health in real-time with graphs showing request rates, response time percentiles, error rates by type, and CPU utilization across all containers. Alarms notify you immediately when metrics cross thresholds: error rates spike above 1%, P99 latency exceeds 500ms, CPU approaches 80% saturation. CloudWatch Logs Insights enables powerful queries across all container logs to debug production issues. This observability transforms your relationship with production: you detect problems before users complain and diagnose issues quickly when failures occur.

Auto-Scaling Policies: Your fixed two-container deployment becomes elastic infrastructure that grows and shrinks with demand. You'll configure target-tracking policies that maintain 70% CPU utilization: when traffic increases and CPU crosses 70%, ECS adds containers automatically. When traffic subsides and CPU drops below 70%, ECS scales down to reduce costs. You'll test this behavior with load testing tools, watching your infrastructure scale from 2 containers to 10 containers under load, then back down to 2 during quiet periods. This elasticity is what makes cloud infrastructure economically efficient: you pay for capacity you need, when you need it.

AWS Cost Optimization: You'll analyze actual AWS costs service-by-service: ECS Fargate charges per vCPU-hour and GB-hour, RDS charges for instance hours and storage, Application Load Balancer charges for hours and load balancer capacity units, ElastiCache charges for node hours. You'll calculate monthly costs for your infrastructure, understand Free Tier limits, and implement optimization strategies that reduce spending by 40-70% through right-sizing, Reserved Instances, and auto-scaling. Professional engineers balance performance with cost—Chapter 29 teaches those trade-offs with real pricing data.

Blue-Green Deployments: You'll implement zero-downtime deployment strategies where new application versions run alongside old versions. Traffic switches atomically from old to new after health checks pass. If problems occur, traffic switches back instantly—rollback completes in seconds, not minutes. You'll deploy breaking changes to production during business hours without user impact. This deployment safety is how companies ship code multiple times per day with confidence.

Together, Chapters 28 and 29 demonstrate complete cloud infrastructure competency. Chapter 28 proved you can build production infrastructure: containerized applications, managed databases, load balancing, logging. Chapter 29 proves you can operate infrastructure professionally: automated deployment, comprehensive monitoring, elastic scaling, cost management, safe rollout strategies. This progression—from manual deployment to automated operations—is the skill transformation that separates developers who can deploy code from engineers who can run systems reliably at scale. When recruiters ask about your production experience, you'll discuss your deployed News API with automated CI/CD, CloudWatch monitoring, and auto-scaling. That's senior-level infrastructure expertise.