DEV Community: Anthony Uketui

Designing Active-Active Multi-Region for a Payment Gateway: An Architecture Decision Record

Anthony Uketui — Thu, 02 Jul 2026 18:21:22 +0000

TL;DR: I designed a multi-region Active-Active architecture for a fintech payment gateway to survive full AWS region failures. This ADR documents why we chose Active-Active over Active-Passive, the technical approach using Route 53 + ECS Fargate + Aurora Global Database, and the trade-offs we accepted.

1. Context: Why This Decision Matters

Our payment gateway is a critical-path service. A prolonged outage — especially a full AWS region failure — directly impacts revenue and customer trust.

Our posture at the time:

Largely single-region
Reactive: we recover from incidents, but aren't designed to withstand a full regional failure without manual intervention
Production in one region, staging in another

What we needed:

Payment gateway stays available during an AWS regional outage
Recovery time and data loss reduced to defined RTO/RPO targets
Improved latency by serving users from geographically closer regions
Fits within our existing tooling: Terraform/Terragrunt, ECS, Aurora

2. The Two Options

Option A: Active-Passive (Disaster Recovery)

A secondary region exists but is idle or minimally used. Failover is manual or semi-automated.

Pros	Cons
Lower cost (secondary region is idle)	Downtime during failover (minutes to hours)
Simpler to implement	Manual intervention required
Less operational complexity	Risk of "cold start" failures in untested DR region

Option B: Active-Active (High Availability) ← Chosen

Multiple regions actively serve traffic. If one region fails, others continue serving with minimal or no downtime.

Pros	Cons
Minimal/zero downtime on failover	Higher cost (duplicate resources)
Lower latency (serve from nearest region)	Increased operational complexity
Protection against full regional failures	Requires stronger CI/CD and observability discipline

Decision: Given the criticality of the payment gateway and the business impact of downtime, we chose Active-Active despite its higher complexity and cost.

3. Architecture Overview

3.1 Traffic Routing — Route 53

Latency-Based Routing for the payment gateway's public API DNS record
Each region exposes an independent endpoint (ALB) registered under the same DNS name
Route 53 directs clients to the lowest-latency region
Health checks against a regional health endpoint (/healthz) detect regional or service failure
Automatic failover: 100% of traffic routes to the surviving region when one is marked unhealthy

3.2 Compute Layer — ECS Fargate

Identical ECS clusters and services in each target region
Terraform/Terragrunt modules parameterized by region ensure infrastructure parity
Same container images and versions deployed via pinned ECR image digests
This eliminates the "it works in Region A but not Region B" class of issues

3.3 Data Layer — Aurora Global Database

This is the hardest part. Payment data must be consistent across regions.

Aurora Global Database with a single primary write region
One or more secondary read replicas in other regions
Write forwarding from secondary regions: reads are local, writes are forwarded to primary
Replication lag: typically <1 second

RTO/RPO Targets:

Metric	Target	How
RTO (Recovery Time Objective)	< 1 minute	Route 53 health checks + automatic failover
RPO (Recovery Point Objective)	< 1 second	Aurora Global Database replication lag

4. Key Design Decisions

Why Not Active-Passive?

For a payment gateway, even 5 minutes of downtime during manual failover is unacceptable. Active-Passive also carries the risk of "cold start" — the DR region hasn't been serving real traffic, so untested configurations, expired credentials, or capacity issues surface at the worst possible moment.

Active-Active eliminates this: both regions are always warm, always serving traffic, always tested.

Why Aurora Global Database Over DynamoDB Global Tables?

Our application is built on relational data models (MySQL/Aurora). Migrating to DynamoDB would require rewriting core application logic. Aurora Global Database provides multi-region replication without changing the data layer.

Why Latency-Based Routing Over Failover Routing?

Latency-based routing provides two benefits: performance (lowest latency) AND resilience (automatic failover via health checks). Pure failover routing only provides the second.

5. Implementation Phases

Phase 1: Database Replication (Foundation)

Set up Aurora Global Database with secondary cluster
Validate replication lag and write forwarding behavior
Run DR drills to measure actual RTO/RPO

Phase 2: Compute Symmetry

Deploy identical ECS services in secondary region via Terraform modules
Validate container image parity across regions
Configure ALBs and health check endpoints

Phase 3: Traffic Management

Configure Route 53 latency-based routing
Set up health checks with appropriate thresholds
Gradual traffic shifting (10% → 50% → 100%)

Phase 4: Operational Readiness

Quarterly DR drills (mandatory)
Cross-region observability (New Relic dashboards per region)
Runbooks for manual failover scenarios

6. Trade-offs We Accepted

Higher Cost

Duplicate compute and database resources across regions. We estimated roughly 1.5–1.8x the single-region cost (not 2x, because the secondary region handles real traffic that would otherwise need scaling in the primary).

Increased Complexity

More moving parts = more potential failure modes. We mitigated this with:

Infrastructure as Code (Terraform) for consistency
Pinned image digests for deployment determinism
Regional health dashboards for visibility

Write Forwarding Latency

Writes from the secondary region incur cross-region latency (typically 30–100ms). For a payment gateway, this is acceptable — payment processing already involves multiple external API calls with higher latency.

7. What I'd Do Differently

Start DR drills immediately. Don't wait until the architecture is "complete." Drill with whatever you have — it exposes assumptions faster than any design review.
Define RTO/RPO with the business, not engineering. The business cares about revenue impact per minute of downtime, not technical recovery metrics. Translate RTO/RPO into dollars.
Plan for split-brain. What happens if both regions think they're primary? Aurora Global Database handles this at the data layer, but application-level state (caches, queues) needs explicit handling.
Budget for observability. Multi-region is only as good as your visibility into it. Without per-region dashboards, you're flying blind.

8. When Active-Active Is Overkill

Not every service needs this. Active-Active makes sense when:

The service is revenue-critical (payment processing, checkout)
Downtime is measured in dollars-per-minute
You have the engineering capacity to maintain two regions

For internal tools, staging environments, or low-criticality services, Active-Passive (or even single-region with good backups) is the right call.

I designed this architecture for a fintech payment gateway processing transactions across Africa. If you're building multi-region systems for financial services, I'd love to exchange notes on the data consistency challenges.

Migrating 500+ AWS Resources from ClickOps to Terraform: A Status Report

Anthony Uketui — Thu, 02 Jul 2026 18:09:31 +0000

TL;DR: I led the migration of a fintech platform's entire AWS infrastructure — IAM roles, ECS services, networking, databases, CI/CD pipelines — from manually created "ClickOps" resources to Terraform-managed Infrastructure as Code. Here's what worked, what broke, and the framework I used to import 500+ existing resources without downtime.

Why We Migrated

Our infrastructure was created by clicking through the AWS Console over 3+ years. It worked, but:

No reproducibility. If a region went down, we couldn't recreate the environment.
No audit trail. Who changed that security group rule? When? Why? Nobody knew.
Configuration drift. "Production" and "staging" had diverged in undocumented ways.
Disaster recovery was impossible. Without IaC, spinning up a new region meant weeks of manual work.
Multi-region architecture requires IaC. Our Active-Active strategy was dead on arrival without Terraform.

The Scale of the Problem

Category	Resource Count
IAM Roles & Policies	191
ECS Services	50
EC2 Instances	18
Security Groups	30+
Load Balancers	18
RDS Databases	22
S3 Buckets	15+
CI/CD Pipelines	20+
Lambda Functions	15+
Route 53 Records	50+

Two regions: Production in eu-west-2 (London), Staging in us-east-2 (Ohio).

The Migration Framework

Step 1: Resource Inventory

Before writing a single line of Terraform, I cataloged every AWS resource. I used:

AWS CLI commands to list resources by service
AWS Config for resource inventory
Manual console review for resources that don't appear in standard APIs

Step 2: Bulk Import with Terraformer

For the initial heavy lifting, I used Terraformer to pull existing resource configurations:

terraformer import aws \
  --resources=iam,ec2,ecs,alb \
  --regions=eu-west-2,us-east-2

This generates .tf files and .tfstate that represent your current infrastructure. It's a massive time-saver but the output needs significant cleanup.

Step 3: Cleanup & Restructuring

Terraformer's output is verbose and flat. I restructured it:

Removed redundant auto-generated arguments and defaults
Moved IAM policies into policies/*.json files and referenced them via locals
Organized configurations into service-specific modules
Standardized naming conventions

Step 4: Manual Imports

For resources that needed precision or were missed in bulk imports:

terraform import aws_iam_role.my_role my_role_name
terraform import aws_ecs_service.my_service my-cluster/my-service
terraform import aws_security_group.my_sg sg-xxxxxxxxx

Step 5: State Verification

The most critical step: terraform plan must show no changes.

If the plan wants to destroy and recreate resources, the configuration doesn't match reality. I iterated until the plan was clean — no deletions, no replacements.

Step 6: Remote State Backend

Migrated .tfstate to S3 with DynamoDB locking:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "env/production/terraform.tfstate"
    region         = "eu-west-2"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Critical protections:

S3 versioning enabled (rollback state if something goes wrong)
AES256 encryption at rest
DynamoDB locking prevents concurrent terraform apply
Public access blocked on the bucket
.terraform directory excluded from Git

Migration Status by Service

Completed ✅

AWS Service	Scope	Notes
IAM	Roles, policies, instance profiles	Standardized into reusable modules
Security Groups	All production + staging	Per-service isolation enforced
VPC & Networking	Subnets, route tables, gateways	Private subnet architecture

In Progress ⏳

AWS Service	Scope	Notes
ECS	Services, task definitions, clusters	Complex due to frequent deployments
ALB	Load balancers, target groups, listeners	Dependency on ECS completion
ACM	Certificates	Cutover risk — DNS validation
Route 53	DNS records	Cutover risk — must be atomic

Pending 📋

AWS Service	Scope	Notes
RDS	Databases	Snapshot-first approach
S3	Buckets	Encryption + versioning policies
CodePipeline	CI/CD pipelines	Artifact bucket dependencies
CodeBuild	Build projects	IAM role dependencies
ECR	Container registry	Lifecycle rules
CloudWatch	Logs, metrics, alarms	Retention policies
Lambda	Functions	Event source mappings
SNS	Notifications	Slack/email integrations

What Broke (And How I Fixed It)

Problem 1: State Drift After Manual Changes

Someone modified a security group via the Console after it was imported into Terraform. Next terraform plan wanted to revert the change.

Fix: Establish a rule: once a resource is in Terraform, the Console is read-only. All changes go through code → PR → apply.

Problem 2: ECS Task Definitions Are Append-Only

ECS task definitions create new revisions on every change. Terraform wants to manage a specific revision, but ECS services reference the "latest" revision.

Fix: Use ignore_changes for task definition in the ECS service resource, and manage task definitions separately.

Problem 3: Import Order Matters

Importing an ALB listener rule before the ALB itself causes dependency errors.

Fix: Build a dependency graph and import in order: VPC → Subnets → Security Groups → ALB → Target Groups → Listener Rules → ECS.

Problem 4: The "Phantom Diff" Problem

terraform plan showed changes for arguments that were set to AWS defaults. Terraformer exports everything, including defaults that Terraform would normally infer.

Fix: Remove explicit default values from the HCL. If Terraform's default matches AWS's default, don't set it.

Module Structure

terraform/
├── backend.tf                 # S3 + DynamoDB backend config
├── .terraform.lock.hcl        # Provider version lock
├── environments/
│   ├── production/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── staging/
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── modules/
│   ├── iam/
│   ├── networking/
│   ├── ecs/
│   ├── alb/
│   ├── rds/
│   └── security/
└── policies/
    ├── codebuild-policy.json
    ├── codepipeline-policy.json
    └── ecs-execution-policy.json

Key design decisions:

Separate state files per environment (production and staging can be managed independently)
Shared modules parameterized by environment
IAM policies as JSON files referenced by locals (easier to review and audit)
Standard tagging enforced via module defaults

Tagging Strategy

Every resource gets these tags (enforced by Terraform):

tags = {
  Environment = var.environment    # production, staging
  Service     = var.service_name   # payment-service, auth-service
  ManagedBy   = "terraform"        # distinguishes IaC from ClickOps
  Owner       = var.team           # platform, backend, frontend
}

The ManagedBy = terraform tag is crucial. It instantly tells you whether a resource is safe to modify via Console (if it's not tagged) or must be changed via code (if it is).

Lessons Learned

Import before modify. Never recreate a production resource. Always import first, verify plan is clean, then start making changes.
Start with IAM. Everything depends on IAM. Get roles and policies into Terraform first — they're the foundation for every other resource.
Separate state per environment. A single state file for production + staging is a disaster waiting to happen.
Plan for the long tail. The first 80% of resources are fast. The last 20% (Lambda event sources, CloudWatch alarms, SNS topics) take as long as the first 80%.
Document what's NOT migrated. Maintain a clear list of resources still managed via Console. This prevents the "is this in Terraform?" question.

Impact

Once complete, this migration enables:

Disaster recovery: Spin up a new region from code in hours, not weeks
Multi-region architecture: Active-Active requires identical infrastructure in both regions
Audit trail: Every change is a Git commit with a PR, reviewer, and timestamp
Compliance: PCI DSS requires documented, repeatable infrastructure processes
Onboarding: New engineers can understand the infrastructure by reading code

Migrating from ClickOps to Terraform isn't glamorous, but it's the foundation that makes everything else possible — multi-region, DR, compliance, and team scale. If you're staring at a Console full of manually created resources, start with IAM and work outward.

How I Built a DevOps Handover Document That Could Run Without Me.

Anthony Uketui — Thu, 02 Jul 2026 17:54:47 +0000

TL;DR: When I left my role as the sole DevOps/Platform Engineer for a fintech payment gateway, I created a handover document that could orient any engineer — from "where are the logs?" to "how do we fail over to another region?" — in under 60 seconds. Here's the framework I used and why most handover docs fail.

The Problem with Most Handovers

I've seen handover documents that are:

A brain dump of links with no context
A 50-page novel nobody reads
A set of credentials with zero operational guidance
A Confluence page last updated 6 months ago

None of these help the engineer at 2 AM when the payment gateway is down and you're unreachable.

My design principle: If I get hit by a bus tomorrow, can someone who's never seen this infrastructure keep the platform stable, deployable, observable, secure, and cost-controlled?

The Framework: 6 Domain Runbooks + 1 Quick Start

I structured the handover as a single entry point page with drill-down links to domain-specific runbooks.

The 60-Second Quick Start

At the top of the page, in a highlighted box:

If you are new or taking over in an emergency, read this first.

Core ownership: AWS infrastructure, ECS services, CI/CD pipelines, security posture, observability, Terraform migration, and cost optimization

Primary environments: Staging in us-east-2; production in eu-west-2

How code reaches production: Source control → CodePipeline → CodeBuild → ECR → ECS service deployment behind ALB

When something breaks: Check monitoring first, confirm the latest deployment, inspect ECS service events/ALB target health, then follow the Incident Ops Runbook

Top current risks: Incomplete Terraform migration, shared security groups/IAM roles, remaining observability gaps

This is the most important section. Everything else is a drill-down.

The 6 Domain Runbooks

1. Platform & Infrastructure Runbook

Covers: AWS architecture, ECS clusters, EC2 fleet, networking, security groups

Key content:

Architecture diagrams (what lives where)
Service maps: ECS cluster → services → load balancers → domains
EC2 instance inventory with IPs, types, and purposes
Security group matrix: which ports, which sources, which services
How to add a new service, resize an instance, or modify networking

Critical detail: I included a service map that mapped every ECS service to its load balancer, domain path, CI/CD pipeline, and operational status. When someone asks "what handles /checkout/*?", the answer is one table lookup.

2. CI/CD & Release Engineering Runbook

Covers: CodePipeline, CodeBuild, ECR, deployment flow

Key content:

End-to-end pipeline flow: source → build → test → deploy
Buildspec template with SonarQube integration
How to create a new pipeline for a new service
How to roll back a bad deployment
Common failure patterns and fixes

Critical detail: Rolling back is ECS is simple — select the prior task definition revision and force a new deployment. But this needs to be documented, not assumed.

3. Observability & Monitoring Runbook

Covers: New Relic, CloudWatch, alerting, dashboards

Key content:

What's monitored and what isn't (the gaps are as important as the coverage)
How to instrument a new service
Alert routing: which alerts go where, who responds
Dashboard locations for each environment

4. Security & Compliance Runbook

Covers: IAM, security groups, GuardDuty, WAF, encryption

Key content:

Current security posture (honest assessment of gaps)
Remediation plan and priority matrix
How to rotate credentials
Incident response procedures

5. FinOps & Cost Management Runbook

Covers: AWS billing, optimization strategies, governance

Key content:

Current monthly spend and breakdown by service
Active cost optimizations (staging shutdown schedules, reserved instances)
Budget alerts and thresholds
How to investigate a cost spike

6. Terraform/IaC Runbook

Covers: Terraform state, modules, migration status

Key content:

What's in Terraform and what's still ClickOps
State file locations and backend config
How to import a new resource
How to plan and apply safely

The Responsibility Matrix (RACI-style)

This is the section most handovers miss. It's not enough to document what — you need to document who.

I created a table mapping each domain to:

Domain	Primary Owner	Backup	When to Escalate
Platform & Infra	[Assign]	[Assign]	Any production service instability, scaling issues, VPC/SG changes
CI/CD	[Assign]	[Assign]	Pipeline failures lasting >30min, new service onboarding
Security	[Assign]	[Assign]	GuardDuty critical finding, suspected breach, credential exposure
Observability	[Assign]	[Assign]	Monitoring gaps, alert fatigue, instrumentation requests
FinOps	[Assign]	[Assign]	30%+ cost increase, daily spend spike, commitment purchases
Terraform	[Assign]	[Assign]	State corruption, import failures, drift detection
Incident Command	[Assign]	[Assign]	Any customer-impacting issue, suspected production instability

Critical rule: No domain should have a single named operator. Before the handover is considered complete, every domain needs at least one backup.

Common Failure Patterns (Cheat Sheet)

I included a quick-reference troubleshooting table:

Symptom	Check First	Fix
ALB health check failing	Health path, container port, target group port, SG rules	Fix path or port mapping
SonarQube gate failing	Token, project key, coverage threshold	Rotate token, verify key
Image mismatch	ECR pushed tag vs. ECS task definition image URI	Update task definition
Task crash loop	App logs, env vars, secrets access, CPU/memory limits	Fix config, increase resources
Cost spike	Cost Explorer by service, check for zombie resources	Terminate unused resources

Known Gaps and Backlog

The most honest section of any handover: what's not done.

I listed:

Terraform migration: pending services and resources
Security: remaining shared security groups and IAM roles
Observability: services not yet instrumented
FinOps: Graviton migration candidates not yet evaluated
Automation: edge cases in reconciliation system

Why this matters: The person taking over needs to know where the landmines are, not just where the paved roads go.

Linked Source Pages

Every claim in the handover links to its authoritative source page:

EC2 Infrastructure Risk Assessment
ECS Security Assessment Reports (per cluster)
Complete CI/CD Pipeline Setup Guide
Deployment Architecture Case Study
SonarQube + CI/CD Integration Standard
AWS Cost Optimization Initiative
Cost Optimization Strategy ($3K Reduction Plan)
Terraform Migration Status Report
Multi-Region Architecture Decision Record
ALB Health Check Troubleshooting Guide

What Makes This Different

It's a living document. Not a one-time brain dump. The handover page links to source pages that are independently maintained.
It starts with the emergency. The 60-second quick start is for the 2 AM incident. The domain runbooks are for the Tuesday morning onboarding.
It's honest about gaps. Most handovers present a rosy picture. Mine included a "Known Gaps and Backlog" section because the person taking over needs to know what's fragile.
It separates "what" from "who." Documentation without ownership assignment is just a wiki page. The RACI matrix ensures every domain has a human responsible for it.
It includes the "why." Not just "we use SonarQube" but "we use SonarQube because we needed a SAST tool that scales on LOC-based pricing for a growing Java team in a cost-sensitive fintech."

The Template

If you're building your own handover, here's the skeleton:

# DevOps/Cloud Handover — [Your Name]

## TL;DR — Platform in 60 Seconds
[5-bullet emergency orientation]

## Responsibility Matrix
[Domain → Owner → Backup → Escalation triggers]

## Domain Runbooks
1. Platform & Infrastructure
2. CI/CD & Release Engineering
3. Observability & Monitoring
4. Security & Compliance
5. FinOps & Cost Management
6. Infrastructure as Code

## Common Failure Patterns
[Symptom → Check → Fix table]

## Known Gaps and Backlog
[Honest list of what's not done]

## References
[Links to all authoritative source pages]

I built this handover when leaving my role as sole DevOps/Platform Engineer for a fintech payment gateway. The test of a good handover isn't whether it's comprehensive — it's whether the person reading it at 2 AM can keep the platform running. Design for the emergency first, then add depth.

End-to-End CI/CD on AWS: From Bitbucket to ECS in 10 Steps

Anthony Uketui — Thu, 02 Jul 2026 17:28:50 +0000

TL;DR: A complete, step-by-step guide to building a production-grade CI/CD pipeline on AWS — from source code in Bitbucket through CodeBuild and CodePipeline to a running ECS Fargate service. I built this for a fintech platform running 50+ microservices. Here's everything I learned.

What We're Building

[Bitbucket Repo]
       │
       ▼ (CodeStar Connection)
[AWS CodePipeline]
       │
       ├── Stage 1: Source
       │     └── Fetch code, store as ZIP in S3
       │
       ├── Stage 2: Build (CodeBuild)
       │     ├── Maven build → JAR
       │     ├── Docker build → Image
       │     ├── ECR push → Registry
       │     └── Generate imagedefinitions.json
       │
       └── Stage 3: Deploy (ECS)
             └── Rolling update → Zero downtime

Stack: Java/Spring Boot, Maven, Docker, AWS (CodePipeline, CodeBuild, ECR, ECS Fargate, S3, IAM)

Step 1: Create ECR Repository

ECR stores your Docker images. Every service gets its own repository.

aws ecr create-repository \
  --repository-name my-service \
  --region <YOUR_REGION> \
  --image-scanning-configuration scanOnPush=true

Save the repositoryUri — you'll need it throughout.

Pro tip: Enable scanOnPush=true to automatically scan images for CVEs when they're pushed. Free security.

Step 2: Create S3 Artifact Bucket

CodePipeline needs a bucket to store artifacts between stages.

aws s3 mb s3://codepipeline-<YOUR_REGION>-<YOUR_ACCOUNT_ID> --region <YOUR_REGION>

Block all public access (default). This bucket should never be public.

Step 3: Create IAM Roles

You need three roles. This is where most people get stuck.

3.1: CodePipeline Service Role

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "codepipeline.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

Permissions: S3 (read/write artifacts), CodeBuild (start builds), ECS (deploy), CodeStar Connections (Bitbucket access).

3.2: CodeBuild Service Role

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "codebuild.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

Permissions: ECR (push images), S3 (read/write artifacts), CloudWatch Logs (build logs), Secrets Manager (if using SonarQube or other secrets).

3.3: ECS Task Execution Role

This is what ECS uses to pull images and write logs:

Permissions: ECR (pull images), CloudWatch Logs (write container logs).

Critical lesson: Follow least-privilege. Don't use * resources in production IAM policies. Scope to specific ARNs.

Step 4: Create the Buildspec

The buildspec.yml lives in your repo root and tells CodeBuild what to do:

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com

  build:
    commands:
      - echo Build started on `date`
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG

  post_build:
    commands:
      - echo Build completed on `date`
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - printf '[{"name":"my-container","imageUri":"%s"}]' $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

Key environment variables (set in CodeBuild project):

AWS_ACCOUNT_ID: Your 12-digit account number
AWS_DEFAULT_REGION: Target region
IMAGE_REPO_NAME: Must match ECR repository name exactly
IMAGE_TAG: Usually latest for staging, commit SHA for production

Step 5: Write the Dockerfile

For Java/Spring Boot services, use a multi-stage build:

# Stage 1: Build
FROM maven:3.9-amazoncorretto-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

# Stage 2: Runtime
FROM amazoncorretto:17-alpine
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Critical lessons from production:

Java version must match pom.xml. Using a Java 8 base image with a Spring Boot 3.x project will silently fail.
Multi-module builds need the root pom. If your service depends on internal modules, copy ALL module directories and build from root.
Pin your base images. amazoncorretto:17-alpine not amazoncorretto:latest. Unpinned tags cause "works on my machine" bugs.
Platform matters. If you build on an M1/M2 Mac, the image is ARM. ECS Fargate (usually x86) will crash. Always use --platform linux/amd64 in your build.

Step 6: Create ECS Task Definition

aws ecs register-task-definition \
  --family my-service-task \
  --network-mode awsvpc \
  --requires-compatibilities FARGATE \
  --cpu 512 \
  --memory 1024 \
  --execution-role-arn arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole \
  --container-definitions '[{
    "name": "my-container",
    "image": "<ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/my-service:latest",
    "portMappings": [{"containerPort": 8080, "protocol": "tcp"}],
    "essential": true,
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/my-service",
        "awslogs-region": "<REGION>",
        "awslogs-stream-prefix": "ecs"
      }
    }
  }]'

Step 7: Create ECS Service

aws ecs create-service \
  --cluster my-cluster \
  --service-name my-service \
  --task-definition my-service-task \
  --desired-count 1 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[<SUBNET_1>,<SUBNET_2>],securityGroups=[<SG_ID>],assignPublicIp=ENABLED}"

Step 8: Create CodeBuild Project

Configure in the Console or CLI:

Source: Bitbucket (via CodeStar Connection)
Environment: Amazon Linux 2023, Standard image
Buildspec: Use the buildspec.yml from the repo
Service role: The CodeBuild role from Step 3

Step 9: Create CodePipeline

Wire everything together:

Source stage: Bitbucket → CodeStar Connection → triggers on push to main
Build stage: CodeBuild project from Step 8
Deploy stage: Amazon ECS → select your cluster and service

Step 10: Deployment Strategy — Rolling Updates

ECS uses rolling updates by default:

ECS spins up new containers with the new image
New containers must pass ALB health checks
Once healthy, the load balancer drains traffic from old containers
Old containers are terminated

Zero downtime. If the new containers fail health checks, the old ones keep running.

How to Rollback

If something goes wrong:

Go to ECS Service → Update Service
Select the previous Task Definition revision
Check "Force new deployment"
ECS reverts to the last known-good version

Common Failure Checklist

Symptom	Likely Cause	Fix
Pipeline stuck at Source	Bitbucket connection expired	Re-authorize in Settings → Connections
Build fails (Maven)	Dependency or syntax error	Check CodeBuild logs
Build fails (Docker)	Java version mismatch or missing modules	Match pom.xml Java version to Dockerfile base image
Deploy fails (ECS)	Health check failing	Verify ALB target group health path matches your app's health endpoint
Container crash loops	Missing env vars or insufficient memory	Check CloudWatch/New Relic logs, increase CPU/memory
Image not found	ECR repo name mismatch	Verify `IMAGE_REPO_NAME` matches exactly

Staging vs. Production

Aspect	Staging	Production
Region	us-east-2 (Ohio)	eu-west-2 (London)
Trigger	Auto-deploy on merge to staging branch	Manual release from console
Quality Gate	SonarQube enforced	SonarQube enforced
Rollback	Auto (ECS)	Manual + stakeholder coordination

What I'd Do Differently

Start with the IAM roles. Every pipeline failure I debugged in the first month was a permissions issue. Get IAM right first.
Pin container images by digest, not tag. :latest is convenient but non-deterministic. For production, use @sha256:... to guarantee you're deploying exactly what you tested.
Add an approval stage for production. A manual approval gate between staging and production prevents accidental deploys.
Integrate SAST from day one. Bolting on SonarQube later means retrofitting 30+ buildspecs. Build it into the template from the start.

This pipeline runs 50+ microservices for a fintech payment gateway. If you're building CI/CD on AWS, especially in regulated industries, feel free to connect — always happy to compare approaches.

From Zero to CI/CD: How I Built and Deployed a Containerized App to Azure

Anthony Uketui — Thu, 16 Apr 2026 19:36:27 +0000

Setting up a cloud pipeline often involves connecting several moving parts that must work together perfectly. I recently completed a project where I moved a Python application from a local development environment to a professional cloud hosting setup. The goal was to build a system that was secure, automated, and reliable. Here is a breakdown of how I built it, the technical decisions I made, and the lessons I learned.

The Project Overview

I built a web application using the FastAPI framework and hosted it on Azure Container Apps. This service allows the application to run in a managed environment that handles networking and scaling automatically.

Technical Features:

Docker Containerization: The application is packaged into a standardized unit that includes everything it needs to run.
Infrastructure as Code: I used Terraform scripts to create all the Azure resources instead of setting them up manually in a browser.
Secure CI/CD: I configured a GitHub Actions pipeline that uses OpenID Connect (OIDC) for authentication, which eliminates the need for long-term passwords.
Custom Interface: The application features a black and gold theme for a professional look.

Live URL: lab1-anthony.ashyocean-d74db9c0.westus2.azurecontainerapps.io

Note: The live URL may be unavailable if infrastructure has been destroyed to avoid ongoing Azure charges. The entire setup can be recreated with a single terraform apply command.

The Technology Stack

Tool	Purpose
FastAPI	The web framework used to build the application.
Uvicorn	The ASGI server that handles incoming HTTP requests and passes them to FastAPI.
Docker	Used to create a consistent environment for the code.
Azure (ACR/ACA)	Used for storing the application images and hosting the live app.
Terraform	The tool used to define and deploy the cloud infrastructure.
GitHub Actions	The automation tool that deploys code updates.

Step 1: Application Architecture

I designed the application to be configuration-driven. This means it does not have hardcoded names or settings. When the app starts, it retrieves its settings from environment variables provided by the host.

def get_app_config() -> dict[str, str]:
    return {
        "app_name": os.getenv("APP_NAME", "Cloud Lab Starter App"),
        "intern_name": os.getenv("INTERN_NAME", "Replace Me"),
        "cloud_platform": os.getenv("CLOUD_PLATFORM", "Replace Me"),
    }

Each variable has a fallback default value. If someone clones the repository and runs the application without configuring anything, it still works — it simply displays placeholder text as a hint to update the values.

This approach allows the same code to run in a local test environment or a production cloud environment without modification. For local testing, I used a .env file with python-dotenv that is excluded from the code repository to keep local settings private.

Step 2: Building the Docker Image

I used Docker to package the application. To ensure the image was secure and efficient, I followed three main practices:

Non-Root User: By default, Docker containers run with full administrative privileges. I created a specific "appuser" with limited permissions and no shell access (/bin/false) to run the application. This ensures that even if the app is compromised, the attacker has very limited access to the system and cannot open an interactive session.
Layer Optimization: I structured the Dockerfile to install dependencies before copying the application code. Docker remembers these finished steps, so when I change a line of code, it only updates that specific part. This reduces build times from minutes to seconds.
Clean Image: The .env file is not copied into the Docker image. All configuration is injected at runtime by the hosting platform. This means the image contains zero sensitive information and can be safely reused across different environments.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app ./app
RUN useradd --no-create-home -s /bin/false appuser
USER appuser
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", "--proxy-headers", "--forwarded-allow-ips", "*"]

Platform Compatibility

One early lesson was about CPU architecture. My development machine is an Apple Silicon Mac, which uses the ARM architecture. Azure Container Apps requires the linux/amd64 architecture. Without specifying the target platform during the build, Azure would reject the image entirely. The fix was straightforward:

docker build --platform linux/amd64 -t lab1-starter-app .

Step 3: Pushing to Azure Container Registry

Azure Container Registry (ACR) is a private image storage service. Before the application can be deployed, the Docker image must be uploaded to ACR so Azure can pull it.

az acr login --name cogneticsregistry
docker tag lab1-starter-app cogneticsregistry.azurecr.io/lab1-starter-app:v1.4
docker push cogneticsregistry.azurecr.io/lab1-starter-app:v1.4

The docker tag step is essential. It embeds the registry address into the image name so Docker knows where to send it.

Registry Permissions

I initially created the ACR with the "ABAC Repository Permissions" mode. This caused persistent authorization failures even after assigning the correct roles. The solution was to recreate the registry with standard RBAC mode, which provided the necessary permissions for image pushes without overcomplicating access control.

Step 4: Infrastructure as Code with Terraform

Instead of manually creating resources in the Azure Portal, I used Terraform. This tool uses code to describe the exact setup required.

Resources Created

Resource	Purpose
Resource Group	The container that holds all Azure resources for the project.
Azure Container Registry	Stores the Docker images with admin access enabled.
Log Analytics Workspace	A central place to store and view application logs.
Container App Environment	The surrounding network and security boundary.
Container App	The specific instance where the code runs, pulling the image from ACR.

All resources are fully managed by Terraform. One terraform apply creates everything, and one terraform destroy removes everything.

Configuration Management

Sensitive and personal values are stored in a terraform.tfvars file that is excluded from the repository. The Terraform code itself uses variable references to keep the deployment clean:

env {
  name  = "INTERN_NAME"
  value = var.intern_name
}

The HTTPS Proxy Issue

During this step, I encountered an issue where the application's CSS would not load. Azure Container Apps terminates HTTPS at the load balancer and forwards plain HTTP to the container. FastAPI was generating http:// URLs for static files, which the browser blocked as mixed content.

The fix was adding --proxy-headers and --forwarded-allow-ips * to the Uvicorn startup command. This tells the server to trust the proxy from Azure's load balancer, allowing it to generate the correct HTTPS URLs.

Step 5: Automated Deployment with OIDC

I set up a GitHub Actions pipeline so that every time I push code to the repository, the application is automatically rebuilt and deployed.

Why OIDC Over Stored Credentials

To make this secure, I used OpenID Connect (OIDC). Traditionally, you would store a client secret in GitHub. With OIDC, GitHub and Azure establish a trust relationship. When a deployment starts, Azure verifies the identity of the GitHub repository and issues a temporary token. This removes the risk of a permanent password being stolen or leaked.

Image Tagging Strategy

Instead of manual version tags, the pipeline tags each image with the git commit SHA. This means every deployed version is directly traceable to an exact commit in the code history.

Problems Encountered and Solutions

Problem	Cause	Solution
`docker push` failed	ACR was in ABAC mode	Switched to standard RBAC mode
Architecture mismatch	Built for ARM (Mac) instead of AMD64	Used `--platform linux/amd64` in build
CSS not loading	HTTPS termination at load balancer	Added `--proxy-headers` to Uvicorn
`MissingSubscriptionRegistration`	Provider not registered	Ran `az provider register`

Security and Operational Summary

Practice	Benefit
Restricted User Account	Protects the server by limiting what the app can do.
OIDC Authentication	Replaces permanent passwords with temporary tokens.
Infrastructure as Code	Allows for perfectly repeatable deployments.
Commit SHA Tagging	Provides a clear audit trail for every deployment.

What I Would Do Differently in Production

Remote Terraform State — Store the state file in Azure Blob Storage for team collaboration.
Separate Environments — Maintain distinct dev, staging, and production configurations.
Azure Key Vault — Store sensitive credentials in a managed vault rather than variables.
Image Scanning — Use security tools like Trivy to check for vulnerabilities before deploying.

Conclusion

This project demonstrates how to move beyond simply "making an app work" to building a professional deployment system. By focusing on automation and security from the start, I created a workflow that is easy to manage and resistant to common security threats.

View the Source Code

🔗 GitHub Repository

Lambda + ALB 503 Error Debugging Guide

Anthony Uketui — Tue, 10 Mar 2026 11:12:04 +0000

Debugging AWS Lambda + ALB 503 Errors: A Step‑by‑Step Guide to Event Format Mismatches

When I first put an AWS Lambda behind an Application Load Balancer (ALB), everything looked correct:

The Lambda worked perfectly when tested directly.
The ALB target group was configured for Lambda.
Listener rules and routing looked fine.
Permissions were in place.

But calling the Lambda through the ALB kept returning:

503 Service Unavailable

Meanwhile, the same Lambda worked through a Function URL and API Gateway v2. The root cause turned out to be a subtle event format mismatch between what the Lambda handler expected and what ALB actually sends.

This post walks through the exact debugging steps, how I identified the mismatch, and how to fix it.

Step 1: Verify Lambda Function Health

Estimated Time: 2–3 minutes

Action: Test the Lambda function directly.

Use a Function URL or the Lambda console test feature.
Confirm that the function executes successfully.

Expected Outcome: Lambda works fine in isolation.

Key Insight:

If the Lambda works when tested directly, the issue is in the integration layer (ALB), not the Lambda code itself.

Step 2: Check ALB Target Group Configuration

Estimated Time: 5 minutes

Action: Verify your ALB target group.

Target type: lambda
Lambda function registered as target
Health checks: disabled (normal for Lambda)
Target status: unavailable (expected for Lambda targets)

Key Insight:

“Unavailable” status with disabled health checks is normal for Lambda targets — it is not the cause of 503 errors.

Step 3: Verify ALB Permissions

Estimated Time: 3 minutes

Action: Check the Lambda resource policy to ensure ALB can invoke the function:

aws lambda get-policy --function-name my-lambda-function

Verify:

The ALB has lambda:InvokeFunction permission.
The ALB ARN is present in the policy.

Key Insight:

Missing permissions would usually result in 403 or 502 errors, not 503. Still, it’s worth ruling out early.

Step 4: Analyze ALB Listener Rules

Estimated Time: 10 minutes

Action: Check routing configuration on the ALB listener.

For example:

Rule priority: 155
Path pattern: /plugin/*
Host header: api.example.com
Target group: MY-LAMBDA-TG

Key Insight:

ALB routing is strict — both path and host header must match exactly. A mismatch here can easily cause requests to hit the wrong target or no target at all.

Step 5: Test with Correct Routing

Estimated Time: 5 minutes

Action: Hit the ALB with the correct host and path.

curl -H "Host: api.example.com" https://my-alb-123456.eu-west-2.elb.amazonaws.com/plugin/test

Result: In my case, this still returned 503, even though routing looked correct.

Key Insight:

Correct routing alone does not guarantee success. If the Lambda works directly but fails through the ALB, start suspecting an event format mismatch.

Step 6: Compare Working vs Non‑Working Scenarios

Estimated Time: 5 minutes

Pattern Recognition:

Function URL: works
API Gateway v2: works
ALB: fails (503)

Key Insight:

The working integrations (Function URL and API Gateway v2) share the same event format, which ALB does not use. That difference becomes important.

Step 7: Examine the Lambda Handler Signature

Estimated Time: 3 minutes

Action: Inspect the Lambda handler to see what type of event it expects.

For example (pseudo-steps):

aws lambda get-function --function-name my-lambda-function
# Then inspect / decompile the handler class if needed
javap -cp . -public com.example.demo.LambdaRequestHandler

Handler Signature Example (Java):

public class LambdaRequestHandler implements RequestHandler<APIGatewayV2HTTPEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(APIGatewayV2HTTPEvent event, Context context) {
        // ...
    }
}

Key Insight:

The handler here expects APIGatewayV2HTTPEvent, which is the event format used by API Gateway HTTP APIs and Function URLs — not the ApplicationLoadBalancerRequestEvent style payload that ALB sends.

Step 8: Analyze CloudWatch Logs

Estimated Time: 2 minutes

Action: Look for exceptions in CloudWatch Logs.

aws logs filter-log-events \
  --log-group-name "/aws/lambda/my-lambda-function" \
  --filter-pattern "Exception" \
  --max-items 5

Example Error:

NullPointerException: Cannot invoke "String.hashCode()" because "<localX>" is null
    at com.example.demo.LambdaRequestHandler.handleRequest(LambdaRequestHandler.java:77)

Root Cause:

Because the handler expects a specific JSON structure (APIGatewayV2HTTPEvent), it tries to access fields that don’t exist in the ALB event → resulting in NullPointerException and ultimately a 503 from ALB.

Step 9: Identify the Event Format Mismatch

Estimated Time: 2 minutes

Let’s compare the incoming event shapes.

Expected by Lambda (API Gateway v2 / Function URL):

{
  "version": "2.0",
  "routeKey": "POST /plugin",
  "rawPath": "/plugin/payment",
  "httpMethod": "POST",
  "headers": { "...": "..." },
  "body": "..."
}

Sent by ALB:

{
  "requestContext": { "elb": { /* ... */ } },
  "httpMethod": "POST",
  "path": "/plugin/payment",
  "headers": { "...": "..." },
  "body": "..."
}

Problem:

The JSON structure is different. Fields your code assumes exist (e.g., version, routeKey, rawPath) are not present in the ALB event. Accessing them directly leads to NullPointerException and a 503 at the ALB level.

Step 10: Verify with Test Events

Estimated Time: 3 minutes

You can simulate both event types in the Lambda console.

ALB Test Event (will fail if your handler expects API Gateway v2):

{
  "requestContext": {
    "elb": {
      "targetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-target-group/1234567890abcdef"
    }
  },
  "httpMethod": "POST",
  "path": "/plugin/payment",
  "headers": {
    "content-type": "application/json"
  },
  "body": "{\"test\": \"data\"}"
}

API Gateway v2 Test Event (will work with APIGatewayV2HTTPEvent handler):

{
  "version": "2.0",
  "routeKey": "POST /plugin",
  "rawPath": "/plugin/payment",
  "httpMethod": "POST",
  "headers": {
    "content-type": "application/json"
  },
  "body": "{\"test\": \"data\"}"
}

Result:

If the API Gateway v2 event works but the ALB event fails with an exception, you’ve confirmed the event format mismatch as the root cause.

The Fix: Update the Lambda Handler to Support ALB

Once you know the issue is an event format mismatch, you have two main options:

Option 1: Change the Handler Input Type to ALB’s Event

For Java, for example:

Before (expects API Gateway v2):

import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayV2HTTPEvent;

public class LambdaRequestHandler implements RequestHandler<APIGatewayV2HTTPEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(APIGatewayV2HTTPEvent event, Context context) {
        // Your existing logic
    }
}

After (expects ALB event):

import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.ApplicationLoadBalancerRequestEvent;

public class LambdaRequestHandler implements RequestHandler<ApplicationLoadBalancerRequestEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(ApplicationLoadBalancerRequestEvent event, Context context) {
        // Adapt your logic to read from ALB's event shape:
        // event.getPath(), event.getHttpMethod(), event.getHeaders(), event.getBody(), etc.
    }
}

This makes the function compatible with ALB’s event structure.

Option 2: Use an Adapter Layer

If you need to support multiple event sources (e.g., API Gateway v2 and ALB) with the same business logic:

Accept the raw event (or use a common internal model).
Detect which event type you received (ALB vs API Gateway v2).
Map it into a unified internal request object.
Pass that object to your core handler logic.

Conceptually:

public class LambdaEntryPoint implements RequestHandler<Map<String, Object>, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(Map<String, Object> rawEvent, Context context) {
        InternalRequest request = EventAdapter.toInternalRequest(rawEvent);
        return CoreHandler.handle(request);
    }
}

This pattern decouples your core business logic from AWS-specific event shapes.

Quick Diagnosis Checklist for Lambda + ALB 503 Errors

Step	Action
Function Health	Test Lambda directly
Permissions	Confirm ALB invoke policy
Routing Rules	Path & host header check
Event Format	Compare working vs failing integration
Logs	Check for NPE or other stack traces

Common Gotchas:

Ignoring ALB event format.
Assuming Lambda target health status matters for 503s.
Missing Host header or path mismatch.
Testing with the wrong event data in the console.
Handler tightly coupled to one event type (e.g., API Gateway v2 only).

Key Takeaways

Lambda + ALB 503 errors can also happen due to event format mismatch, not just networking or permissions.
The handler signature dictates the expected input. If it expects APIGatewayV2HTTPEvent, it won’t magically understand ALB’s event format.
Function URLs and API Gateway v2 share the same event format, so a handler that works there may still fail behind an ALB.
ALB sends a different JSON structure (e.g., requestContext.elb, different path fields), which can break your code if you assume API Gateway-style fields.
CloudWatch logs reveal stack traces and NPEs — always check them first when debugging 503s.

IAM Policies vs Resource Policies: Lessons from Production (and the Gym)

Anthony Uketui — Tue, 09 Dec 2025 13:08:37 +0000

Early in my AWS journey, I ran into a problem that had me scratching my head for hours.

A frontend engineer came up to me:

"Tony, I just want users to see our app logos and images, but it’s not working. They keep getting denied."

I double-checked the IAM permissions—everything looked fine. The user had the right access. So why were people still blocked?

It wasn’t IAM at all. It was the S3 bucket’s resource policy.

That’s when it clicked: managing AWS access is a lot like managing a gym or sticking to a disciplined fitness routine.

Before you say how...

Let me explain.

IAM Policies = Your Personal Trainer

IAM policies are like your personal trainer. They define what you (the identity) are allowed to do:

Can you lift weights today?

Can you run on the treadmill?

Can you skip cardio?

In AWS, IAM policies attach to users, groups, or roles. They control what actions an identity can perform and on which resources.

In production, I also enforced MFA for all IAM users. Think of it like adding a second checkpoint before entering a VIP gym area—you might have the keycard (password), but without the fingerprint (MFA), you can’t get in. Simple, but it drastically increases security.

Resource Policies = The Gym Rules

Resource policies are like the rules posted on the gym wall. Even if your trainer gives you permission, the rules might still restrict your access:

Only VIP members can use certain equipment
Some areas are off-limits

In AWS, resource policies attach directly to resources, like S3 buckets, Lambda functions, or SQS queues. They define who can access the resource, including other AWS accounts or the public.

Here’s what I did in production:

ALB Logs: Edited the bucket policy so our Application Load Balancer could send access logs safely, without extra permissions.

Frontend Images/Logos: Created a bucket policy allowing users to read logos and images—but blocked access to sensitive files. Users got exactly what they needed.

Scaling Access: IAM vs Resource Policies

One thing I learned quickly: scale changes everything.

IAM policies scale best for identities. One policy can manage multiple users, groups, or roles. Perfect for internal teams.

Resource policies scale best for resources. When sharing across accounts or publicly, resource policies give the resource control over access.

Using both together is essential. IAM ensures users only do what they should, while resource policies ensure resources themselves are protected—even if IAM permissions exist.

Example: Our financial reports bucket had IAM permissions for finance guys, but the resource policy restricted access to our AWS account only. Layered security prevented accidental or malicious access and gave us peace of mind.

Layered Security = Layered Discipline
OOps that sounded cringe. haha

But just like weight loss or fitness, success in AWS access control comes from layers of discipline:

IAM = your workout plan → defines what identities can do
Resource policy = gym rules → defines who can access resources

Both together produce sustainable results which ultimately prevents mistakes, leaks, or misuse.

Ignoring one layer is like skipping cardio or not tracking calories.

You might get some results, but you’ll eventually hit problems.

In AWS, ignoring resource policies while relying solely on IAM can lead to “mystery denied” errors and frustrated users.

Takeaways from the battlefield

Always check both IAM and resource policies. A deny in either will block access.

Enforce MFA. It’s a small step with huge security payoff.

Use resource policies for cross-account or public access—especially when sharing logs, images, or APIs.

Test every access path. Users may have the right IAM permissions but still get blocked.

Think in layers.

Identity control + resource control = secure, scalable access.

Cheers

CI/CD for Infrastructure That Actually Works.

Anthony Uketui — Sat, 13 Sep 2025 10:58:09 +0000

Moving beyond demos: secure identity and cost visibility

Why Infrastructure Pipelines Still Fail

Too often, Terraform runs still happen on laptops with static AWS keys. The result?

Credentials at risk — long-lived keys sitting in repos or local machines
Undocumented changes — no audit trail, no shared visibility
Environment drift — dev, staging, and prod no longer match
Forgotten test resources — quietly inflating cloud bills

Running IaC this way feels fast — until it breaks consistency, costs money, or exposes credentials.

CI/CD fixes this, but to move beyond a “demo pipeline,” two practices make the difference in production:

OIDC-based authentication → no long-lived credentials
Cost visibility in PRs → prevent financial surprises

The 8 Steps of CI/CD (Infrastructure Edition)

Code pushed → pipeline triggers
Build → package artifact / generate Terraform plan
Validate → syntax check, terraform validate
Scan → security/compliance checks
Deploy to dev/staging → safe sandbox
Integration tests → real environment validation
Deploy to prod → gated promotion
Monitor → logs, costs, drift

This is the same framework as app pipelines — only the artifact changes.

Production-Ready Differentiators

1. OIDC: Secure, Short-Lived Credentials

Instead of storing AWS keys in GitHub secrets, pipelines use OIDC to assume roles dynamically.

Short-lived credentials, nothing to leak
Environment-specific IAM roles (dev/staging/prod)
Every assumption logged in CloudTrail

Minimal AWS trust policy for GitHub OIDC (example):

resource "aws_iam_role" "terraform_dev" {
  name = "uketui-terraform-cicd-dev"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = aws_iam_openid_connect_provider.github.arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:sub" = "repo:Anthonyuketui/Terraform-Project-with-Multi-Environment-Support-on-AWS:environment:dev"
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
        }
      }
    ]
  })
}

2. Cost Visibility: Infracost in PRs

With a single step, you can post cost estimates into pull requests after terraform plan.

Example PR comment:

This puts financial awareness into the code review process. A financial mistake gets caught before merge, not on the next AWS bill.

Example Dev Pipeline (GitHub Actions)

This workflow runs in a dev environment for iteration. It’s intentionally lightweight, but notice how it already includes the production-grade practices (OIDC, cost checks, environment isolation) that make the same design safe to scale into staging and prod.

name: Terraform Dev DevSecOps Pipeline

on:
  pull_request:
    branches:
      - dev
  push:
    branches:
      - dev

jobs:
  cost-analysis:
    runs-on: ubuntu-latest
    environment: dev
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Run Infracost
        uses: infracost/actions/setup@v2
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Generate Infracost diff
        run: |
          cd environments/dev
          terraform init -backend=false
          infracost breakdown --path . \
            --format table \
            --out-file cost-estimate.txt
      - name: Output cost estimate
        run: cat environments/dev/cost-estimate.txt

      - name: Post cost estimate on PR
        if: github.event_name == 'pull_request'
        run: |
          body="#### Infracost Estimate
          \`\`\`
          $(cat environments/dev/cost-estimate.txt)
          \`\`\`"

          echo "comment=${body}" >> $GITHUB_OUTPUT
        id: cost_estimate

      - name: Add PR comment
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v6
        with:
          script: |
            const body = `${{ steps.cost_estimate.outputs.comment }}`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: body
            });

  terraform-dev:
    runs-on: ubuntu-latest
    environment: dev
    needs: cost-analysis

    permissions:
      id-token: write
      contents: read

    env:
      TF_IN_AUTOMATION: true

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.TERRAFORM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Format Check
        working-directory: environments/dev
        run: terraform fmt -recursive


      - name: Terraform Init
        working-directory: environments/dev
        run: terraform init -backend-config=backend.tfvars

      - name: Terraform Validate
        working-directory: environments/dev
        run: terraform validate

      - name: Terraform Plan
        working-directory: environments/dev
        run: terraform plan -var-file=terraform.tfvars -out=tfplan

      # -------------------------
      # Optional: Conftest (policy checks)
      # -------------------------
      # - name: Run Conftest
      #   uses: instrumenta/conftest-action@master
      #   with:
      #     files: environments/dev/tfplan
      #     policy: policy/

      # -------------------------
      # Optional: Security checks (uncomment for strict DevSecOps)
      # -------------------------
      # security-checks:
      #   runs-on: ubuntu-latest
      #   steps:
      #     - name: Checkout code
      #       uses: actions/checkout@v4
      #
      #     - name: Run Checkov
      #       uses: bridgecrewio/checkov-action@v12
      #       with:
      #         directory: environments/dev
      #         framework: terraform
      #         skip_check: CKV_AWS_79,CKV_AWS_126
      #
      #     - name: Run tfsec
      #       uses: aquasecurity/tfsec-action@v1.0.3
      #       with:
      #         working_directory: environments/dev
      #
      #     - name: Run Terrascan
      #       uses: tenable/terrascan-action@main
      #       with:
      #         iac_type: 'terraform'
      #         iac_dir: 'environments/dev'

      - name: Terraform Apply (on push only)
        if: github.event_name == 'push'
        working-directory: environments/dev
        run: terraform apply -auto-approve tfplan

For staging/prod, add approval gates and stricter IAM roles.

Multi-Environment Setup

Use separate directories and state backends:

├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
├── modules/
└── .github/workflows/

Each environment:

Own terraform.tfvars + backend.tfvars
Own S3 bucket + DynamoDB lock table
Role isolation via IAM

Why This Matters

For engineers: this structure eliminates environment drift and makes infra deployments reproducible.
For managers: it reduces credential risk, prevents surprise costs, and creates a clear audit trail.

Building a Production-Ready Terraform Project with Multi-Environment Support on AWS

Anthony Uketui — Fri, 29 Aug 2025 12:52:53 +0000

When I started this project, my goal was simple but ambitious. I wanted to build a production-ready infrastructure that could automatically scale based on demand. I also wanted to organize everything in a way that supports multiple environments like dev and prod.

I’ll walk you through my full process, including the reasoning behind each step, challenges I faced, and how I resolved them.

I'd also share snippets of my code

But, here's the code if you want to follow along: https://tinyurl.com/aedduwdm

Step 1: Project Structure and Multi-Environment Setup

I wanted to keep my project modular and clean. To achieve this, I structured my directory in this way:

Modules contain reusable building blocks like VPC, ALB, EC2, RDS, and Monitoring.
Environments (dev and prod) each have their own main.tf and terraform.tfvars files that reference the modules.

This structure makes it easy to manage different configurations without duplicating code.

Step 2: Defining the VPC

My first step was to create a dedicated VPC with public and private subnets. Public subnets are for load balancers, and private subnets are for EC2 and RDS.

Code Snippet (VPC module)

resource "aws_vpc" "this" {
  cidr_block = var.vpc_cidr
  tags       = { Name = "${var.env}-vpc" }
}

I chose to keep the database and application instances in private subnets for security reasons.

Step 3: Application Load Balancer (ALB)

The ALB distributes traffic across EC2 instances. This ensures high availability.

Code Snippet (ALB module)

resource "aws_lb" "this" {
  name               = "${var.env}-alb"
  load_balancer_type = "application"
  subnets            = var.public_subnets
}

By using public subnets, the ALB became internet-facing, while the EC2 instances behind it stayed private.

Step 4: EC2 Auto Scaling Group

Next, I set up EC2 instances with auto scaling. This way, when CPU usage is high, new instances are launched automatically.

Code Snippet (EC2 module)

resource "aws_autoscaling_group" "this" {
  desired_capacity     = var.desired_capacity
  max_size             = var.max_size
  min_size             = var.min_size
  vpc_zone_identifier  = var.private_subnets
}

I used Amazon Linux 2 AMI and passed in user data through a template to bootstrap the instances.

Step 5: RDS Database Setup

For the database, I used Amazon RDS with MySQL. One challenge here was how to handle credentials securely.

At first, I hardcoded them, but I quickly realized that wasn’t safe. I switched to AWS Secrets Manager combined with a random password generator.

Code Snippet (RDS module)

resource "random_password" "db_password" {
  length  = 16
  special = true
}

resource "aws_secretsmanager_secret" "db_pwd" {
  name = "${var.env}/db_password"
}

This allowed me to store the password securely and avoid exposing it in my code.

Step 6: Monitoring and Alerts

I didn’t want to stop at just provisioning resources. I also wanted monitoring and alerts for key components like EC2, ALB, and RDS.

I used CloudWatch Alarms with SNS topics to send email alerts.

Code Snippet (Monitoring module)

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "${var.env}-cpu-high"
  metric_name         = "CPUUtilization"
  threshold           = 70
  comparison_operator = "GreaterThanThreshold"
  namespace           = "AWS/EC2"
  statistic           = "Average"
  period              = 300
  evaluation_periods  = 2
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

This way, I get notified if something goes wrong.

Step 7: Multi-Environment Variables

Each environment has its own terraform.tfvars file. For example, my dev environment uses smaller instances while prod uses larger ones.

Dev `terraform.tfvars`

environment = "dev"
region      = "us-east-1"
instance_type = "t3.micro"
desired_capacity = 1
db_instance_class = "db.t3.micro"

Prod `terraform.tfvars`

environment = "prod"
region      = "us-east-1"
instance_type = "t3.medium"
desired_capacity = 2
db_instance_class = "db.t3.medium"

This separation made it easy to spin up lightweight dev infrastructure without affecting production.

Dev Environment

Prod Environment

Step 8: Running the Project

Here are the commands I used to apply everything:

cd envs/dev
terraform init
terraform plan -var-file="terraform.tfvars"
terraform apply -var-file="terraform.tfvars"

cd ../prod
terraform init
terraform plan -var-file="terraform.tfvars"
terraform apply -var-file="terraform.tfvars"

This workflow gave me a smooth way to deploy separate environments using the same modules.

Challenges and How I Solved Them

Hardcoding DB credentials: Initially I put the password directly in code. I later switched to using Secrets Manager with random_password to improve security.
Auto scaling not attaching correctly to ALB: At first, my instances weren’t registering as healthy. The fix was to ensure the security groups allowed the right ports and the target group health checks matched the app.
Multi-environment management: I struggled with duplication until I split logic into modules and kept only environment-specific variables in tfvars.

Conclusion

This project gave me a hands-on understanding of how to structure a Terraform project for scalability, security, and maintainability. By modularizing infrastructure, securing credentials, and setting up monitoring, I ended up with a production-grade setup.

How I passed my AZ-104 (Associate Administrator) exams in less than 21 days.

Anthony Uketui — Sun, 13 Apr 2025 14:39:34 +0000

The title might seem misleading, but it's the truth. To top it off, I scored an 854/1000, too. But that's by the way. I'm not her8e to brag, after all, it's just a paper.

I'm writing this so you become armed enough to write this exam in one sitting.

For clarity's sake, I've outlined this in steps.

Ready?

Go.

Step 1: Book the exam.

Create that pressure and set a deadline for yourself; that way, you don't end up in a vicious cycle of procrastination.

Step 2: Gather thy resources.

I watched tons of videos researching for the best resources. I watched to the extent that it became a form of procrastination. Instead of reading, studying, and practicing, I was all over YouTube scrolling for "Best Az-104" resources. I don't want you wasting time, so here are the resources I used.

1)Video Course
2)Text course
3)Labs(Hands-on Practice)
4)Practice questions.

People learn differently, but I'm sure with a mix of all things, you can never go wrong.

Before I continue... Labs are really important to do. Get familiar with the portal and the cloud shell.

Get your hands dirty. The exam is not so easy, and it's an associate exam. So if you have zero experience playing with Azure.

Please create an Azure account and start getting your hands muddy.

For the text course, I used Ms learn. And I solidified the concepts with something visual, like a video course.

For the Video course, I had access to Kodekloud, so I took a course on Az-104 on it, and I supplemented it with an Udemy course by Scott Duffy.

As you finish a certain topic, like compute or Storage, try to build projects related to the topic.

These are some labs I did

MicrosoftLearning / AZ-104-MicrosoftAzureAdministrator

AZ-104 Microsoft Azure Administrator

AZ-104: Microsoft Azure Administrator

Welcome

This repository is for instructors teaching Microsoft courses. If you are in class, please ask your instructor for assistance.

Link to demonstrations and labs (HTML format)
Are you an MCT? - Have a look at our GitHub User Guide for MCTs
To preview this course in a self-paced format, see our interactive lab simulations. You may find slight differences between the interactive simulations and the hosted labs, but the core concepts and ideas being demonstrated are the same.

Security Issue - April 2023

Effective immediately, the Admin password will be removed from the JSON template parameter files. This means students will have to provide a password when the template is deployed. This affects Labs 4, 5, 6, 7, 10 and 11. The lab instructions will be changed to reflect this change.

What are we doing?

To support this course, we will need to make…

View on GitHub

After two weeks of study, I immersed myself in practice questions, thinking I was ready. Alas, I scored 45%. Haha.

Practice questions point out your flaws and loopholes. Things you might have avoided because you thought it was unimportant. And it also shows you how the questions would be structured.

When you do this. Review your weak areas and go back to your text or video course to cement them. Go back to doing labs if it demands that. I supplemented with Azure documentation

Azure documentation | Microsoft Learn

Learn how to build and manage powerful applications using Microsoft Azure cloud services. Get documentation, example code, tutorials, and more.

learn.microsoft.com

and a Free YouTube video course playlist by Susanth Sutheesh

Never try to memorize the practice questions. Strive to understand the concepts instead.

Aside from the certification, you wouldn't want to be a scam when you eventually get a job and you're told to do something basic.

So in a nutshell, lock in!

For Practice questions, I used TechBlackboard AZ-104 YouTube playlist as my go-to guide because it explained each option and why they aren't the correct one. I warn you, some answers can be wrong, so go through the comments from time to time.

I also supplemented with a YouTube playlist that I found interesting. You can consume this probably a day before your exams, just to further solidify concepts

Hopefully, this made sense to you. You can always reach out to me on LinkedIn

I'm rooting for you and hope you crush your exam!

Building an Automated Football Match Schedule Notification System with AWS

Anthony Uketui — Thu, 13 Mar 2025 04:57:55 +0000

Introduction

In this post, I’ll walk you through how I built a serverless application that automatically checks for match schedules and sends email notifications using AWS services. This project leverages AWS Lambda, Amazon SNS, and Amazon EventBridge, demonstrating a practical use case of event-driven architecture in the cloud.

Why I did this?

Checking match schedules manually can be tedious, and missing a match can be frustrating. What if we could automate this process so that users receive timely notifications about upcoming matches?

Solution Overview

To solve this, I created an AWS-based system that:

Fetches match schedules using a Lambda function.
Triggers email notifications via Amazon SNS.
Uses EventBridge as a scheduler to run the Lambda function at set intervals.

Implementation Steps

1. Setting Up the SNS Topic

Created an SNS topic in the AWS console.

Added an email subscription to receive notifications.

Confirmed the subscription via email.

I also created IAM roles and policies so that our SNS topic can communicate with our lambda function

2. Writing the Lambda Function

I Used Python to fetch match schedules from an API.
Processed the data and sent a message to SNS.
Deployed the function to AWS Lambda.

Sample Lambda Code (Python):

import os
import json
import urllib.request
import boto3
from datetime import datetime, timezone

def fetch_football_data(api_url, headers):
    request = urllib.request.Request(api_url, headers=headers)
    try:
        with urllib.request.urlopen(request) as response:
            return json.loads(response.read().decode())
    except Exception as e:
        print(f"Error fetching data from API: {e}")
        return None

def format_match_data(match):
    status = match.get("status", "Unknown")
    home_team = match.get("homeTeam", {}).get("name", "Unknown")
    away_team = match.get("awayTeam", {}).get("name", "Unknown")
    home_score = match.get("score", {}).get("fullTime", {}).get("homeTeam", "N/A")
    away_score = match.get("score", {}).get("fullTime", {}).get("awayTeam", "N/A")
    competition = match.get("competition", {}).get("name", "Unknown Competition")
    match_time = match.get("utcDate", "Unknown")

    if status == "FINISHED":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Final Score: {home_score}-{away_score}\n"
                f"Date & Time: {match_time}\n")
    elif status == "IN_PLAY":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Current Score: {home_score}-{away_score}\n"
                f"Match is in progress!\n")
    elif status == "SCHEDULED":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Scheduled Time: {match_time}\n")
    else:
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Status: {status}\n")

def lambda_handler(event, context):
    api_key = os.getenv("FOOTBALL_API_KEY")
    sns_topic_arn = os.getenv("SNS_TOPIC_ARN")
    sns_client = boto3.client("sns")

    # Fetch today's matches
    today_date = datetime.now(timezone.utc).strftime("%Y-%m-%d")
    api_url = f"https://api.football-data.org/v4/matches?dateFrom={today_date}&dateTo={today_date}"
    headers = {"X-Auth-Token": api_key}

    print(f"Fetching football matches for {today_date}")
    data = fetch_football_data(api_url, headers)

    if not data or "matches" not in data:
        return {"statusCode": 500, "body": "Error fetching match data"}

    matches = data["matches"]
    messages = [format_match_data(match) for match in matches]
    final_message = "\n---\n".join(messages) if messages else "No matches available for today."

    # Publish to SNS
    try:
        sns_client.publish(
            TopicArn=sns_topic_arn,
            Message=final_message,
            Subject="Football Match Updates"
        )
        print("Message published to SNS successfully.")
    except Exception as e:
        print(f"Error publishing to SNS: {e}")
        return {"statusCode": 500, "body": "Error publishing to SNS"}

    return {"statusCode": 200, "body": "Football match data processed and sent to SNS"}

I added an environment variable so our function recognizes the API key and the SNS topic URL

3. Scheduling Lambda with EventBridge

Created a new EventBridge rule to trigger the Lambda function at specific times.

Configured it to run daily or at specific match times.

Linked the rule to the Lambda function.

Testing & Results

Deployed and tested the function manually.

Verified that SNS successfully delivered email notifications.

Future Improvements

Store match schedules in DynamoDB for historical data.
Extend notifications to SMS or mobile apps.
Create a User Interface

Conclusion

This project showcases how AWS services can be combined to build an automated notification system. By leveraging Lambda, SNS, and EventBridge, I’ve created a serverless solution that keeps users informed without manual effort.

Developing an API to Retrieve Football Game Schedules - Using Docker and AWS Services

Anthony Uketui — Mon, 10 Mar 2025 07:00:08 +0000

Who Doesn't Love Football? ⚽

Before diving into my passion for the game, let’s tackle an important question:

Why Do We Need an API for Football Schedules?

Manually gathering football schedules from multiple websites is time-consuming and inefficient. Instead, an API allows us to integrate live updates directly into applications, websites, or analytics tools, making it easy to access real-time football schedules seamlessly.

🛠 Breaking It Down with an Analogy

Imagine you want to order food from a restaurant. Instead of going to the kitchen, checking ingredients, and preparing the meal yourself, you simply ask the waiter for what you want. The waiter communicates with the kitchen, retrieves the meal, and serves it to you—quick, accurate, and hassle-free.

An API works like that waiter. When you need football game schedules, instead of manually collecting data from multiple sources, the API acts as a middleman, fetching the latest updates for you instantly.

✅ This saves time, ensures accuracy, and eliminates manual work, making it easier for apps and websites to display real-time football schedules.

Project Overview

In this project, I developed an API that retrieves football game schedules using:

✅ Flask (for the API)
✅ Docker (for containerization)
✅ AWS Services (for scalability and reliability)

Tech Stack Breakdown

🚀 Flask Framework

Flask is a lightweight Python web framework that allows for rapid development. I used it to create API endpoints that handle requests for football game schedules.

📦 Docker

Docker enables packaging applications into containers—ensuring that they run consistently across different environments. By containerizing the Flask app, I simplified deployment and eliminated compatibility issues.

☁️ AWS Services Used

Elastic Container Registry (ECR) – A managed container registry to store our Docker images securely.
Elastic Container Service (ECS) – Used to deploy and manage the Dockerized API efficiently.
Elastic Load Balancing (ELB) – Distributes traffic across multiple instances to ensure high availability.
API Gateway – Exposes the API via a secure and scalable endpoint.

This combination ensures the API can handle real-time requests with high availability.

Development and Deployment Steps

1️⃣ Developing the Flask API

Created a Python-based Flask application to handle API requests.
Ensured the application fetched and processed football schedules from Football-Data.org.

2️⃣ Containerizing the Application with Docker

Wrote a Dockerfile to define the environment and dependencies.
Built and tested a Docker image locally.

3️⃣ Pushing the Docker Image to AWS ECR

Created an ECR repository to store the Docker image.
Tagged and pushed the image to ECR.

4️⃣ Deploying on AWS ECS

Set up an ECS cluster to manage containerized applications.
Defined a task definition specifying the Docker image and resource requirements.
Created a service to maintain the desired number of running tasks.

5️⃣ Configuring Networking & Load Balancing

Implemented an Application Load Balancer (ALB) for traffic distribution.
Configured security groups to allow API access.

6️⃣ Exposing the API via AWS API Gateway

Created an API Gateway to serve as the entry point.

- Routed traffic through API Gateway to the ALB.

Developing the API with Python (Flask)

I used Python to create the API, ensuring it could efficiently fetch and format football schedules.

Key Features

✅ Fetches live football schedules

✅ Formats responses in JSON

✅ Handles errors gracefully

Flask Code:

from flask import Flask, jsonify
import requests
import os

app = Flask(__name__)

FOOTBALL_API_URL = "https://api.football-data.org/v4/matches"
FOOTBALL_API_KEY = os.getenv("FOOTBALL_API_KEY", "your_api_key_here")

@app.route('/football', methods=['GET'])
def get_football_schedule():
    """Fetches upcoming football matches and returns as JSON."""
 8   try:
        headers = {"X-Auth-Token": FOOTBALL_API_KEY}
        response = requests.get(FOOTBALL_API_URL, headers=headers)
        response.raise_for_status()
        data = response.json()

        matches = data.get("matches", [])
        if not matches:
            return jsonify({"message": "No upcoming football matches found.", "matches": []}), 200

        formatted_matches = [
            {
                "competition": match.get("competition", {}).get("name", "Unknown"),
                "home_team": match.get("homeTeam", {}).get("name", "Unknown"),
                "away_team": match.get("awayTeam", {}).get("name", "Unknown"),
                "venue": match.get("venue", "Unknown"),
                "date": match.get("utcDate", "Unknown"),
            }
            for match in matches
        ]

        return jsonify({"message": "Football schedule fetched successfully.", "matches": formatted_matches}), 200

    except Exception as e:
        return jsonify({"message": "An error occurred.", "error": str(e)}), 500

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

To confirm the code works we test it in our local machine by running the command below.

Here's the output. It works!

Why Did I Containerize the Application? 🍽

A Simple Analogy

Using Docker is like a chef preparing a meal in a food container instead of serving it on a plate.

Without a container, the food might spill, mix with other meals, or not fit different kitchens. But with a container, the meal stays intact, portable, and works anywhere—whether in a restaurant, a food truck, or a customer's home.

Similarly, Docker packages our app with everything it needs, ensuring it runs smoothly on any system without issues.

What Does a Dockerfile Do? 📜

A Dockerfile is like a recipe—it provides step-by-step instructions to build our container consistently.

Here’s my Dockerfile:

# Use a lightweight Python image  
FROM python:3.9-slim  

# Set the working directory inside the container  
WORKDIR /app  

# Copy the requirements file into the container  
COPY requirements.txt requirements.txt  

# Install dependencies  
RUN pip install -r requirements.txt  

# Copy all files from the current directory into the container  
COPY . .  

# Expose the port  
EXPOSE 8080  

# Command to run the application  
8CMD ["python", "app.py"]

Deploying on AWS ☁️

Since we're deploying on AWS, I used ECR instead of Docker Hub for:

✅ Better security

✅ Faster performance

✅ Seamless AWS integration

Pushing the Docker Image to AWS ECR

Step 1: Create an ECR Repository

If you haven't already created an ECR repository, do so with:

Step 2: Authenticate Docker with AWS ECR

Before pushing the image, log in to AWS ECR using the AWS CLI:

Step 3: Tag the Docker Image

Retrieve the repository URL and tag your Docker image:

Step 4: Push the Image to ECR

Now, push the tagged image to the repository:

Configuring AWS ECS

Why Do We Need to Configure ECS?

Think of ECS as a restaurant kitchen that runs and manages containers. But before it can start serving meals (running containers), you need to:

✅ Set up the kitchen (configure ECS)

✅ Tell the chefs what recipes to use (define services and tasks)

✅ Assign kitchen equipment (8choose EC2 or Fargate)

Without proper ECS configuration, it won’t know where or how to run our containers.

Steps to Configure ECS

1️⃣ Create a Cluster – The foundation for running containers.

2️⃣ Define a Task Definition – Like a recipe that specifies:

Which container image to use (the image in our ECR)
CPU & memory allocation
Port settings and environment variables

3️⃣ Create a service:

We set up how many tasks we want defined(we used 2)
We set up security groups, Iam Policies(default)
We configured our load balancer from here.

Load Balancing

To distribute incoming traffic evenly across multiple containers, we configured an Application Load Balancer (ALB).

✅ High availability – If one container goes down, traffic is redirected to another.

✅ Better performance – Ensures no single container is overloaded.

To verify, we searched for our load balancer under EC2 Services and accessed our API via the ALB's DNS. It worked! 🎉

Creating an API Gateway Endpoint

Instead of exposing our ECS services directly, we used API Gateway as a front door to handle incoming requests.

Analogy: API Gateway is Like a Receptionist

Just like a receptionist in a big company handles all incoming guests, directs them appropriately, and ensures security, API Gateway:

📌 Receives incoming requests

📌 Routes them to the right backend service (ECS)

📌 Ensures security and authentication

Steps to Set Up API Gateway

1️⃣ Created a REST API

2️⃣ Created a resource & method

3️⃣ Deployed the API

Now, we can invoke our API successfully to access football game schedules. 🚀

Conclusion

Through this process, we successfully:

✅ Built and containerized a football schedule API

✅ Deployed it on AWS using ECS & Fargate

✅ Configured a load balancer for high availability

✅ Integrated API Gateway for security and request management

Now, users can access football schedules via our API! ⚽