DEV Community: Victor Ojeje

I Passed AWS SAA-C03. Here's What Actually Mattered.

Victor Ojeje — Fri, 03 Apr 2026 21:16:46 +0000

I sat the SAA-C03 recently and passed. Before I forget what actually worked, here's the honest breakdown.

The exam is not a memory test

AWS publishes the exam guide openly. Four domains, weighted percentages: Secure Architectures is 30%, Resilient Architectures 26%, High-Performing 24%, Cost-Optimized 20%. The questions drop you inside a scenario with a compliance constraint, a budget ceiling, or a failure condition, then ask you to pick the right architecture.

If you study by memorising service features, you will fail on the scenario questions because you have never practiced making the decision. I knew this going in because I had already built a fraud detection pipeline with SQS, Lambda, DynamoDB, and SNS. When a question asked me to choose between Lambda and Fargate for a PCI-constrained workload, I had a real reference point. That matters more than any flashcard.

Tutorials Dojo was the core resource, not a supplement

I used Jon Bonso's practice exams as the primary study mechanism, not a final check before sitting. The reason it works is the explanations. When you get a question wrong, it does not just show you the correct answer. It tells you exactly why each wrong answer is wrong.

That distinction is the whole exam. You are not picking the right option out of five. You are eliminating three plausible options. If you do not understand why the wrong ones fail, you will keep making the same mistakes on different question wording.

Community benchmark on Tutorials Dojo is consistent 80% before sitting the real exam. I used that as my gate.

Every wrong answer became an architecture pattern

When I got a question wrong I did not just note the correct service. I mapped the whole scenario.

Wrong on a DynamoDB composite key question? That becomes a working mental model for when a Global Secondary Index is the actual fix versus just restructuring the partition key. Wrong on an S3 lifecycle transition? That maps to the 30-day minimum billing rule for Standard-IA and why an aggressive lifecycle policy can cost more than doing nothing and oh boy does the exam love S3.

You build a schema that generalises to questions you have never seen. That is the only way to handle the 65 questions in 130 minutes without running out of time on edge cases.

Breadth over depth, done deliberately

SAA-C03 tests roughly 35 to 40 services with meaningful depth. Going deep on everything is a waste. Going shallow on the high-weight domains is how people fail.

Secure Architectures is 30% of the exam. If you cannot immediately distinguish when to use a Customer Managed KMS key versus an AWS Managed Key for an audit requirement, you are losing points on the biggest single domain. I spent more time on IAM policies, KMS, VPC endpoints, and CloudTrail than on anything else, specifically because the exam weights said to.

What I would skip next time

I spent too long on ECS versus EKS distinctions early on and very hyper focused portions of services like lambda, Eventbridge and Config for example. That is not where the exam goes. The exam goes into architectural tradeoffs including Multi-AZ RDS versus Read Replicas versus Aurora Global Database. That type of decision appears repeatedly.

If you're preparing for SAA-C03, start with Tutorials Dojo's AWS Certified Solutions Architect Associate Practice Exams from day one, not after you've finished a course. The feedback loop from testing yourself early is faster than any other method.

Follow me on Reddit: reddit.com/user/Escanut/
GitHub: github.com/escanut

How I Built a PCI-Ready Merchant Onboarding API on AWS for Under $5/Month

Victor Ojeje — Sun, 22 Mar 2026 17:40:23 +0000

Payment processors get rejected from enterprise contracts because it wasn't auditable. PCI DSS cares whether every data access event is logged, every record is encrypted with a key you control, and whether you can recover a merchant record to a specific second if a dispute arises.

This post walks through a serverless merchant onboarding API built to those standards, with full cost transparency.

What This Solves

A payment processor needs to register merchants: collect business details, store KYC documents, and expose that data to internal admin systems. Straightforward on the surface. The compliance overhead is where most implementations fall apart:

PCI DSS Requirement 3.5.1 — stored data must be encrypted with a key the organization controls, not a cloud-provider default
PCI DSS Requirement 8 — every API call must be authenticated and tied to an identity
PCI DSS Requirement 10 — every data access event must produce audit evidence

Building infra that can survive a compliance audit without emergency rework is the goal to strive for.

Architecture

The full flow:

Merchant authenticates with email and password via Amazon Cognito, receives a JWT (JSON Web Token)
Merchant calls API Gateway with that JWT in the Authorization header
API Gateway validates the JWT against Cognito ensuring Lambda never receives an unauthenticated request
Lambda processes the request and creates merchant profile in DynamoDB, stores KYC documents in S3 if present
DynamoDB stores profiles encrypted at rest with a customer-managed KMS key, PITR enabled
S3 stores KYC documents encrypted with SSE-KMS, Bucket Key enabled
CloudTrail captures every API call, Lambda invocation, and DynamoDB operation as mandated by PCI DSS Requirement 10
CloudWatch monitors operational metrics

Assumptions and Traffic Model

Dimension	Value	Basis
Monthly Active Users (MAU)	10,000	Initial operating scale
Projected new merchants/month	500	Growth estimate
DynamoDB writes/month	500	One write per new merchant registration
DynamoDB reads/month	330,000	10,000 users × 3 reads + 500 new records × 20 reads × 30 days
S3 PUT requests/month	2,000	500 merchants × 4 KYC documents each
S3 GET requests/month	6,000	2,000 PUTs × 3 retrieval average
API Gateway + Lambda requests	330,500	Matches read/write totals

They were derived from real behavioral assumptions: how often a merchant logs in, how often admins pull records, document retrieval patterns.

Security Decisions and Why They Were Made

1. JWT Validation at API Gateway, Not Lambda

Authentication is enforced at the API Gateway layer using a Cognito authorizer. This means Lambda is never invoked for an unauthenticated request meaning there is no compute cost and no attack surface for unauthenticated traffic.

If you push JWT validation into Lambda, you pay for Lambda invocations even for rejected requests, and you've moved your authentication boundary inward, increasing blast radius.

2. Customer-Managed KMS Key on DynamoDB (Not AWS-Owned)

The DynamoDB table uses a customer-managed KMS key

AWS-Owned Keys (the free default) fail PCI DSS Requirement 3.5.1 for a specific reason: you cannot produce key usage evidence for an auditor because you have no visibility into key operations. CloudTrail does not log AWS-Owned Key usage. Customer-managed keys generate CloudTrail entries on every encrypt and decrypt operation. That's the audit evidence.

3. S3 SSE-KMS with Bucket Key Enabled

KYC documents in S3 are encrypted with SSE-KMS. Bucket Key is enabled, which reduces the number of KMS API calls by batching envelope encryption at the bucket level rather than generating a unique data key per object.

Without Bucket Key, every S3 object PUT and GET generates a KMS API call. At 8,000 S3 requests/month, that's 8,000 additional KMS calls on top of DynamoDB operations. Bucket Key collapses that significantly.

4. Point-in-Time Recovery (PITR) on DynamoDB

PITR is enabled on the merchants table. This provides continuous backups with one-second granularity for the last 35 days.

In a payment dispute or fraud investigation, you may need to prove what a merchant record looked like at a specific timestamp. Without PITR, you either rebuild from CloudTrail (tedious) or you can't answer the question. PITR makes this a 30-second console operation.

5. GSI for Read Efficiency

The GET /merchants endpoint (admin listing) queries a Global Secondary Index (GSI) called entity-type-index rather than scanning the full table:

query_kwargs = {
    "IndexName": GSI_NAME,
    "KeyConditionExpression": Key("entity_type").eq("MERCHANT"),
    "Limit": limit,
    "ScanIndexForward": False,
}

DynamoDB Scan reads every item in the table regardless of what you need. At scale, that becomes expensive. A GSI query reads only matching items. With 300,000+ reads per month, using Scan instead of a GSI query would multiply your read capacity consumption by the full table size factor.

Cursor-based pagination is implemented using ExclusiveStartKey and base64-encoded tokens, which is the correct DynamoDB pagination pattern.

6. Duplicate Registration Prevention at the Database Level

table.put_item(
    Item=item,
    ConditionExpression="attribute_not_exists(cac_number)",
)

A merchant's CAC (Corporate Affairs Commission) registration number is unique to their business. This condition expression makes DynamoDB reject the write if a record with that CAC number already exists. This is enforced at the storage layer, not in application logic, so it cannot be bypassed by a Lambda bug or a parallel request race condition.

7. CloudTrail for PCI DSS Requirement 10

CloudTrail is configured to log management events and Lambda data events. Every PutItem, GetItem, and Query operation on the merchants table appears in CloudTrail. Every S3 object PUT and GET is logged.

PCI DSS Requirement 10.2 specifies the exact event types that must be logged: user access to cardholder data, invalid logical access attempts, use of privilege escalation mechanisms. CloudTrail at this configuration covers all of them.

The Full Lambda Function

This single function handles all three API routes. Every design decision in the security section above maps directly to something in this code.

import json
import uuid
import boto3
import os
import re
import base64
from datetime import datetime, timezone
from boto3.dynamodb.conditions import Key

dynamodb = boto3.resource("dynamodb")
TABLE_NAME = os.environ.get("TABLE_NAME", "merchants")
table = dynamodb.Table(TABLE_NAME)

# GSI (Global Secondary Index) used for GET /merchants — avoids a full table
# Scan which reads every item regardless of what you need. At 300,000 admin
# reads/month, Scan would multiply read capacity consumption by the full
# table size factor.
GSI_NAME = "entity-type-index"
DEFAULT_PAGE_SIZE = 20
MAX_PAGE_SIZE = 100
EMAIL_REGEX = re.compile(r"^[\w\.-]+@[\w\.-]+\.\w+$")


def respond(status_code, body):
    return {
        "statusCode": status_code,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps(body),
    }


def validate_post_body(body):
    required = ["business_name", "cac_number", "contact_email"]
    missing = [f for f in required if not body.get(f, "").strip()]
    if missing:
        return None, f"Missing or empty fields: {', '.join(missing)}"

    email = body["contact_email"].strip().lower()
    if not EMAIL_REGEX.match(email):
        return None, "Invalid contact_email format"

    # CAC = Corporate Affairs Commission registration number (Nigeria).
    # Exactly 6 digits — validated here before it ever touches DynamoDB.
    cac = body["cac_number"].strip()
    if not cac.isdigit() or len(cac) != 6:
        return None, "cac_number must be exactly 6 digits"

    return {
        "business_name": body["business_name"].strip(),
        "cac_number": cac,
        "contact_email": email,
    }, None


def post_merchant(event):
    try:
        body = json.loads(event.get("body") or "{}")
    except json.JSONDecodeError:
        return respond(400, {"error": "Request body must be valid JSON"})

    validated, error = validate_post_body(body)
    if error:
        return respond(400, {"error": error})

    merchant_id = str(uuid.uuid4())
    created_date = datetime.now(timezone.utc).isoformat()

    item = {
        "merchant_id": merchant_id,
        "created_date": created_date,
        "entity_type": "MERCHANT",
        "business_name": validated["business_name"],
        "cac_number": validated["cac_number"],
        "contact_email": validated["contact_email"],
        "status": "active",
    }

    # ConditionExpression enforces uniqueness at the storage layer.
    # If a record with this CAC number already exists, DynamoDB rejects
    # the write with ConditionalCheckFailedException — no application-layer
    # race condition can bypass this.
    table.put_item(
        Item=item,
        ConditionExpression="attribute_not_exists(cac_number)",
    )

    return respond(201, {"merchant_id": merchant_id, "created_date": created_date})


def get_all_merchants(event):
    params = event.get("queryStringParameters") or {}

    try:
        limit = min(int(params.get("limit", DEFAULT_PAGE_SIZE)), MAX_PAGE_SIZE)
    except ValueError:
        return respond(400, {"error": "limit must be an integer"})

    query_kwargs = {
        "IndexName": GSI_NAME,
        "KeyConditionExpression": Key("entity_type").eq("MERCHANT"),
        "Limit": limit,
        "ScanIndexForward": False,  # newest first
    }

    # Cursor-based pagination using DynamoDB's ExclusiveStartKey.
    # The cursor is base64-encoded JSON of the last evaluated key — safe
    # to pass to clients without exposing internal DynamoDB key structure.
    cursor = params.get("cursor")
    if cursor:
        try:
            exclusive_start_key = json.loads(
                base64.b64decode(cursor.encode()).decode()
            )
            query_kwargs["ExclusiveStartKey"] = exclusive_start_key
        except Exception:
            return respond(400, {"error": "Invalid cursor"})

    response = table.query(**query_kwargs)

    next_cursor = None
    if "LastEvaluatedKey" in response:
        next_cursor = base64.b64encode(
            json.dumps(response["LastEvaluatedKey"]).encode()
        ).decode()

    return respond(200, {
        "merchants": response["Items"],
        "count": len(response["Items"]),
        "next_cursor": next_cursor,
    })


def get_merchant_by_id(merchant_id):
    response = table.query(
        KeyConditionExpression=Key("merchant_id").eq(merchant_id),
        Limit=1,
    )
    items = response.get("Items", [])
    if not items:
        return respond(404, {"error": "Merchant not found"})
    return respond(200, items[0])


# Route table — static dispatch is faster than regex matching at Lambda
# invocation frequency and easier to read during a code review.
ROUTES = {
    ("POST", "/merchants"): post_merchant,
    ("GET", "/merchants"): get_all_merchants,
}


def lambda_handler(event, context):
    method = event.get("httpMethod", "")
    path = event.get("path", "")
    path_params = event.get("pathParameters") or {}

    if (method, path) in ROUTES:
        return ROUTES[(method, path)](event)

    # Dynamic route: /merchants/{id}
    if method == "GET" and path_params.get("id"):
        return get_merchant_by_id(path_params["id"])

    return respond(404, {"error": "Route not found"})

Three things worth noting in this code that matter for regulated environments:

Input validation happens before any AWS SDK call. Email format, CAC number format, and required field presence are all checked before Lambda touches DynamoDB. Malformed requests never generate KMS decrypt operations, which keeps the KMS call count accurate to your cost model.

entity_type: "MERCHANT" is set by the server, not the client. The GSI partition key cannot be spoofed by a bad actor sending a crafted payload. If it were client-supplied, a request sending entity_type: "ADMIN" could pollute the index.

The route table (ROUTES dict) replaces a chain of if/elif checks. At 330,500 invocations per month this is not a performance concern, but during a code review at a financial institution, explicit dispatch tables are easier to audit than nested conditionals.

How Authentication Was Tested

# Generate SECRET_HASH (required for Cognito app clients with secret)
import hmac, hashlib, base64
message = username + client_id
secret_hash = base64.b64encode(
    hmac.new(client_secret.encode(), message.encode(), hashlib.sha256).digest()
).decode()

# Get JWT from Cognito
aws cognito-idp initiate-auth \
  --client-id 3einfu39fvd2opcoldicn0fh2q \
  --auth-flow USER_PASSWORD_AUTH \
  --auth-parameters USERNAME=<username>,PASSWORD=<password>,SECRET_HASH=<hash>

# Call the API with the JWT
curl -X POST https://93z9qxnyv4.execute-api.us-east-1.amazonaws.com/prod/merchants \
  -H "Authorization: <IdToken>" \
  -H "Content-Type: application/json" \
  -d '{"business_name": "Jiji", "cac_number": "128957", "contact_email": "jiji@example.com"}'

# List all merchants
curl -X GET https://93z9qxnyv4.execute-api.us-east-1.amazonaws.com/prod/merchants \
  -H "Authorization: <IdToken>"

# Retrieve a specific merchant
curl -X GET https://93z9qxnyv4.execute-api.us-east-1.amazonaws.com/prod/merchants/01fcd787-47d1-4db5-a396-f2adcf0c3e18 \
  -H "Authorization: <IdToken>"

Requests without a valid JWT are rejected at the API Gateway layer before Lambda is invoked.

Cost Breakdown

Source: AWS Pricing Calculator export, 03/22/2026, us-east-1. 10,000 MAU, 330,500 requests/month.

Service	Monthly Cost	% of Bill	Notes
KMS	$2.01	41.3%	669,000 symmetric API calls
API Gateway	$1.16	23.8%	330,500 requests, avg 34KB
Lambda	$0.76	15.6%	330,500 invocations, 512MB
CloudTrail	$0.34	7.0%	Lambda data events at volume
CloudWatch	$0.32	6.6%	0.63GB log ingestion
DynamoDB	$0.24	4.9%	On-demand, PITR, KMS
S3	$0.04	0.8%	1GB storage, 8,000 requests
Cognito	$0.00	0.0%	10,000 MAU = within free tier
Total	$4.87/month

What most engineers miss about this bill:

KMS is 41% of the monthly cost at this scale. The moment you add customer-managed encryption to DynamoDB and S3 (which PCI DSS requires), KMS becomes the dominant cost driver. Every DynamoDB read and write generates KMS API calls. Without Bucket Key on S3, every object operation would add to that count.

At 10,000 MAU this is $4.87/month. At 100,000 MAU, KMS call volume scales roughly linearly with request volume. Planning for this in the initial architecture prevents a compliance requirement from arriving as a surprise bill.

Cognito at this scale is free. The first 10,000 MAU are within the AWS free tier perpetually.

What Breaks at Scale

This architecture is appropriate for the stated scale. Three things need revisiting before 10x growth:

1. CloudTrail cost at high Lambda data event volume

CloudTrail logs Lambda data events at $0.10 per 100,000 events. At 330,500 Lambda invocations, that's $0.34/month. At 3.3M invocations, it's $3.30/month. At 33M, $33/month. Worth modelling before reaching that range.

2. GSI read capacity under admin query load

300,000 admin reads per month assumes 20 reads per admin per day. If admin tooling increases query frequency, the GSI read cost scales. Add DynamoDB DAX (DynamoDB Accelerator) at that point, DAX adds $150+/month at minimum instance size.

3. KMS request limits

KMS has a default quota of 5,500 symmetric requests per second in us-east-1. At the traffic levels modelled here, this is not a constraint. At high-throughput payment processing scale, it becomes one. Request a quota increase before hitting the ceiling, not after.

Why This Architecture Over EC2-Based Alternatives

The comparable EC2 architecture (t3.micro + RDS + ALB) runs approximately $50-80/month before adding KMS, CloudTrail, and WAF. Serverless brings this to $4.87/month at 10,000 MAU.

More importantly: there are no servers to patch. A common PCI DSS finding in EC2-based environments is unpatched OS vulnerabilities. Lambda eliminates that finding category entirely with AWS managing the runtime, and the function execution environment is ephemeral.

The tradeoff is cold starts. Lambda cold starts for Python average 100-300ms. For a merchant onboarding API (not a real-time payment path), this is acceptable. For a transaction authorization endpoint, it is not.

Stack

Amazon Cognito (authentication, JWT issuance)
Amazon API Gateway (JWT validation, request routing)
AWS Lambda (Python 3.14, business logic)
Amazon DynamoDB (merchant profiles, SSE-KMS, PITR, on-demand)
Amazon S3 (KYC documents(for demonstration), SSE-KMS, Bucket Key, versioning)
AWS CloudTrail (audit logging, PCI DSS Requirement 10)
Amazon CloudWatch (operational monitoring)
AWS KMS (customer-managed encryption keys)

If you're hiring for Cloud Engineer, DevOps, or SRE roles with infrastructure security depth, I'm open to remote opportunities.

LinkedIn | GitHub | ojejevictor@gmail.com

I Built a Serverless Fraud Detection Pipeline on AWS. Here's What It Actually Costs to Do It Right.

Victor Ojeje — Tue, 17 Mar 2026 22:19:14 +0000

Most cloud portfolio projects look like this: spin up an EC2 instance, deploy a web app, take a screenshot. Done.

That tells a hiring manager you can follow a tutorial.
This is not that.

I built a real-time transaction screening pipeline modeled after how financial institutions actually handle suspicious activity routing.
The entire processing backbone costs $2.48/month to run at 500 000 transactions.
Here is how it works, why every decision was made, and what it actually costs to secure it properly.

The Problem This Solves

Payment processors and banks screen every transaction before it clears. A transaction above a defined threshold, or matching a suspicious pattern, needs to be flagged, stored, and routed to an analyst in near real-time. Latency here is not a UX problem. It is a compliance and fraud exposure problem.
The architecture needs to handle three things without failing:

Ingest transactions reliably, even under burst load
Evaluate and persist every transaction regardless of outcome
Alert immediately when a transaction crosses the threshold, with zero alert loss

A traditional EC2-based approach handles this with always-on servers. You pay for compute whether transactions are flowing or not. You manage patching, availability zones, and process monitoring yourself.

The serverless approach inverts this entirely.

Architecture

Every transaction enters through SQS. Lambda processes each message, writes the full record to DynamoDB regardless of whether it is flagged, and fires an SNS alert only if the amount exceeds the threshold. If Lambda fails to process a message three times, SQS routes it to a Dead Letter Queue for manual investigation. Nothing is silently dropped.

Lambda was deployed inside a VPC across two availability zones. All connections to SQS, DynamoDB, SNS, and CloudWatch run through VPC interface and gateway endpoints. No traffic touches the public internet at any point in the pipeline.

Lambda Function

import json
import boto3
import os
from decimal import Decimal

dyn = boto3.resource('dynamodb')
sns = boto3.client('sns')

TABLE = os.environ.get("TABLE", "fraud-detections")
SNS_ARN = os.environ.get("SNS_ARN", "arn:aws:sns:us-east-1:461840362463:fraud-alerts")

# Threshold represents configurable screening rule for the institution
THRESHOLD = 500000

def lambda_handler(event, context):
    for record in event["Records"]:
        body = json.loads(record["body"])
        txn_id = body["transaction_id"]
        amount = Decimal(str(body["amount"]))
        merchant = body["merchant"]

        flagged = amount > THRESHOLD

        dyn.Table(TABLE).put_item(
            Item={
                "transaction_id": txn_id,
                "amount": amount,
                "merchant": merchant,
                "flagged": flagged
            }
        )

        if flagged:
            sns.publish(
                TopicArn=SNS_ARN,
                Message=f"Suspicious transfer Flagged: {txn_id} — NGN {amount} — {merchant}",
                Subject="Fraud Alert"
            )
    return {'statusCode': 200}

Every transaction is written to DynamoDB first, before the flag check. This matters. In a real system you need a complete audit trail. A transaction that does not trigger an alert is not necessarily clean. It needs to exist in the record. Regulators do not accept gaps.

The threshold is a variable, not a hardcoded business rule. In production this would be pulled from a configuration store or Parameter Store, allowing compliance teams to adjust screening rules without a code deployment.

Decimal is used instead of float for the amount. DynamoDB does not accept Python floats. Using float here causes silent precision errors on large transaction amounts. This is a real production bug that shows up in systems built by engineers who have not actually handled financial data before.

Verified Results

Two transactions were sent through the pipeline.

TXN-001 crossed the NGN 500,000 threshold. The SNS alert fired immediately to email with the subject line "Fraud Alert" and the full transaction details in the message body.
TXN-002 was written to DynamoDB with flagged: false. No alert sent. Complete audit record preserved.

Both records confirmed live in DynamoDB

Email alert received from SNS Topic.

What It Actually Costs

Service	Monthly Cost
AWS Lambda (500k requests)	$1.14
Amazon SQS (1.5M requests)	$0.60
Amazon DynamoDB (1GB)	$0.56
Amazon SNS (10k alerts)	$0.18
Pipeline Total	$2.48
VPC Interface Endpoints (3x)	$43.81
Secured Total	$46.29/month

The pipeline itself costs $2.48/month to process 500,000 transactions.

The VPC endpoints cost $43.81/month.
That is 94.6% of the total bill for a security control, not compute.

This is an intentional tradeoff. Without VPC endpoints, Lambda communicates with SQS, DynamoDB, SNS, and CloudWatch over the public internet. In a financial context that is not a configuration choice. It is an audit finding. VPC endpoints keep all traffic private within the AWS network, satisfy network isolation requirements common in PCI-DSS and SOC 2 environments, and eliminate the data exfiltration risk that comes with public endpoint exposure.

If this were a cost-only conversation, you would skip the endpoints and save $43.81/month. In a production fintech environment, that decision gets flagged in the first security review.

What This Is Not

This pipeline has a single threshold rule. Production fraud detection at scale uses ML-based anomaly scoring, velocity checks across merchant categories, device fingerprinting, and graph-based relationship analysis. Those are layered on top of an event-driven backbone exactly like this one.

This is the infrastructure layer. It is the part that has to work before any model or rule engine gets plugged in. Getting this layer wrong means no amount of ML sophistication above it recovers cleanly.

Why Serverless for This

Three concrete reasons:

Burst handling without pre-provisioning. Payment transaction volume is not linear. End-of-month salary runs, Black Friday, public holiday spikes. Lambda scales to concurrency automatically. An EC2-based system requires capacity planning or auto-scaling lag measured in minutes.
No idle cost. An EC2 t3.micro running 24/7 costs approximately $7.59/month before you add storage, monitoring, or patching overhead. Lambda at 500,000 transactions costs $1.14/month. At zero transactions it costs nothing.
Operational surface reduced to code. There is no OS to patch, no SSH access to harden, no process monitor to configure. The attack surface is the IAM role and the function code. Both are auditable and version-controlled.

What Carries Into Production

The patterns here are not demo-specific:

SQS as a durable ingest buffer decouples transaction producers from the processing layer. A downstream Lambda failure does not lose the transaction.
DLQ after three failures means no silent message loss. Every failed transaction is recoverable.
VPC-private connectivity means the pipeline satisfies network isolation requirements out of the box.
IAM roles scoped to least privilege mean Lambda cannot touch anything outside its defined resource set.

These are the same architectural decisions you find in production payment infrastructure. The scale is different. The patterns are not.

Victor Ojeje is a Cloud and Infrastructure Engineer based in Lagos. He builds production-grade AWS infrastructure with a focus on security, automation, and cost-conscious design.

LinkedIn: linkedin.com/in/victorojeje | GitHub: github.com/escanut

How I went from Docker Compose to production EKS without burning AWS budget on mistakes

Victor Ojeje — Wed, 18 Feb 2026 06:12:33 +0000

The Problem with Learning Kubernetes Directly on AWS

Most tutorials for Kubernetes on AWS tell you to:

Spin up an EKS cluster
Apply your manifests
Debug why nothing works
Watch your bill climb while you figure it out

EKS charges $0.10 per hour just for the control plane, before a single EC2 node is added. That is about $72/month for a cluster sitting idle while you troubleshoot ingress routing, secret injection failures, and container networking issues.

That is fine for a company budget. It hurts when you are learning on your own.

There is a better workflow. Test locally, prove it works, then pay for AWS.

What I Built

A production-grade containerized web application with a staged deployment workflow:

Stage 1: Docker Compose for fast local iteration
Stage 2: Minikube to validate Kubernetes behavior before touching AWS
Stage 3: EKS with full CI/CD, AWS Secrets Manager, and automated ALB provisioning

App repo: https://github.com/escanut/fastapi-k8s-project

Infra repo: https://github.com/escanut/fastapi-aws-infra

The app is a FastAPI backend with async request handling and connection pooling connected to PostgreSQL, plus a vanilla JS frontend. Simple product catalog with create, retrieve, delete items. Nothing fancy on purpose. The focus is the infrastructure pattern and delivery workflow.

Stage 1: Docker Compose

Goal: instant feedback on code changes with zero cluster overhead.

services:
  postgres:
    image: postgres:15-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin -d products"]

  backend:
    build: ./backend
    environment:
      DB_HOST: postgres
    volumes:
      - ./backend:/app

  frontend:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf

Nginx routes /api traffic to FastAPI. Credentials are plain env variables here, intentionally different from production. That contrast is the lesson.

Validates: app logic, queries, routing, frontend-backend communication.
Does not validate: Kubernetes behavior.

Stage 2: Minikube

Goal: catch Kubernetes failures at zero cost before provisioning AWS.

minikube start
eval $(minikube docker-env)
minikube addons enable ingress
kubectl apply -f dev/k8s/

Setup mirrors production closely:

Secrets from Kubernetes Secrets, not env vars

Postgres as a pod with a PVC

Ingress configured like production

Broken ingress, wrong ports, and secret issues show up here instead of on a paid cluster. Minikube is not identical to ALB, but it is close enough to surface real problems early.

The CI/CD Pipeline

On every push to main:

  Configure AWS Credentials
  This uses aws-actions/configure-aws-credentials@v4

  Build and push frontend & backend image
  This runs docker build + push

  Updates deployment
  This runs kubectl set image ...

  Verify
  This runs kubectl rollout status ...

Each image is tagged with commit SHA. Rollback just means redeploying a previous SHA. No guesswork.

OIDC is used for short-lived credentials. No static keys stored.

VPC Endpoints: Why They Matter Beyond Security

Without endpoints:

Worker → NAT → Internet → AWS API → Internet → NAT → Worker

NAT data processing costs $0.045/GB. Image pulls, logs, and secrets traffic add up fast.

Eight endpoints route AWS-internal traffic privately. NAT remains only for external access during bootstrap.

This results to lower cost and reduced exposure.

Secrets Management Progression

Stage 1: Plain env var  
Stage 2: K8s Secret  
Stage 3: ExternalSecret synced from Secrets Manager

Production password is randomly generated and stored in Secrets Manager. Terraform state is encrypted. Password is not floating around in plaintext.

IAM Design: Least Privilege

GitHub Actions: scoped OIDC role
Node role: read-only ECR
Backend pods: read specific secret via IRSA
ALB Controller: ALB-only permissions

Each component gets only what it needs to perform its task.

Post-Install: Why Not Everything in Terraform

post-install.sh installs:

AWS Load Balancer Controller
External Secrets Operator

CRDs plus dependency ordering make Terraform Helm messy here. This approach is predictable and aligns with upstream guidance.

Infrastructure Cost Snapshot

Service	Monthly
EKS	$72
EC2 nodes	~$30
RDS	~$12
NAT	~$65
VPC endpoints	~$11.60
ALB	~$16

Endpoints reduce NAT data charges on AWS API traffic. In active pipelines, that tradeoff makes sense.

What This Demonstrates

Cost-aware Kubernetes learning path
OIDC instead of static keys
IRSA for pod-level IAM
VPC endpoints for cost and security
External Secrets integration
Fully automated ALB provisioning

Try it

Repos are public and documented. Start local, move to Minikube, then EKS.

If something breaks or you want to discuss design choices, reach out. I am always refining this setup myself.

Open to Work

Currently seeking remote roles in Cloud, DevOps, and Platform Engineering.

LinkedIn: https://linkedin.com/in/victorojeje
Email: ojejevictor@gmail.com
GitHub: https://github.com/escanut

I built auto-scaling infrastructure that actually survives failures

Victor Ojeje — Sat, 31 Jan 2026 21:19:07 +0000

Most deployment tutorials get you to "it works on my machine" status. Few show you how to build infrastructure that survives database connection failures, instance crashes during deployment, or availability zone outages.

I deployed a production-grade Flask API on AWS with auto-scaling that maintains availability through failures. Here's what separates infrastructure that works in demos from infrastructure that works in production.

What I Built

A three-tier Flask API deployment on AWS with PostgreSQL, designed to survive common failure scenarios.

Live Repository: github.com/escanut/terraform-aws-flask-oidc

Architecture:

Application Load Balancer (Multi-AZ)
        ↓
Auto Scaling Group (2-4 instances)
        ↓
RDS PostgreSQL (Multi-AZ with automatic failover)

Key Stats:

Zero-downtime deployments (50% minimum healthy capacity)
6-8 minute deployment from commit to live
380-second instance warmup prevents premature failures
Multi-AZ redundancy across database and networking
Runtime credential retrieval (no secrets in code or Docker images)
Monthly cost: $158 (us-east-1)

Health Check Integration: The Critical Path

Health checks are where most auto-scaling setups fail. You need three layers working together:

1. Docker Container Health Check

HEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3

40-second start period accounts for ECR image pull (15-20 seconds) and application initialization.

2. Flask Application Health Check

@app.route('/health')
def health():
    # Executes real database query
    conn = get_db()
    cur.execute('SELECT 1')
    return jsonify({'status': 'healthy'}), 200

Validates the application can actually reach RDS. An instance passing Docker checks but unable to connect to the database is useless.

3. ALB Health Check

health_check {
  healthy_threshold   = 2
  unhealthy_threshold = 3
  interval            = 10
  path                = "/health"
}

2 consecutive successes (20 seconds) confirms stability. 3 consecutive failures (30 seconds) removes flapping instances.

Deregistration delay: 30 seconds allows in-flight requests to complete before removing unhealthy instances.

Instance Warmup: Preventing Cascading Failures

This configuration prevented deployment failures:

instance_refresh {
  strategy = "Rolling"
  preferences {
    min_healthy_percentage = 50
    instance_warmup        = 380
  }
}

Instance warmup: 380 seconds (6+ minutes)

What happens during warmup:

EC2 instance launches (30-60 seconds)
User data script: apt updates, Docker install, AWS CLI install, ECR login, image pull (4-5 minutes)
Docker health checks stabilize (40 seconds)
ALB health checks pass 2 consecutive times (20 seconds)

What happens if warmup is too short (e.g., 120 seconds):

Auto Scaling Group marks instance "healthy" before Docker finishes pulling the image
ASG immediately terminates old instances
New instances aren't ready for traffic
ALB routes traffic to instances returning connection refused
502 Bad Gateway errors cascade to users

380-second warmup ensures:

Old instances stay alive until new instances are genuinely ready
Zero user-facing errors during deployments
Rolling updates complete without capacity loss

This number was determined empirically by monitoring actual instance launch times, not guessing.

Multi-AZ Architecture: Eliminating Single Points of Failure

RDS Multi-AZ Configuration:

resource "aws_db_instance" "rds" {
  multi_az              = true
  instance_class        = "db.t4g.micro"
  storage_encrypted     = true
}

Cost: $24.82/month (vs $12.41 for single-AZ)

What Multi-AZ provides:

Synchronous replication to standby in different availability zone
Automatic failover in 1-2 minutes (zero manual intervention)
Zero data loss during AZ failure

What happens during AZ failure without Multi-AZ:

Database becomes unreachable
Application returns 503 errors to all users
Manual recovery required (10-30+ minutes)
Potential data loss depending on last backup

AWS availability zone failures occur 2-3 times per year per region. Production systems justify the cost.

Dual NAT Gateways:

resource "aws_nat_gateway" "nat" {
  count = 2  # One per AZ
}

Cost: $65.70/month (vs $32.85 for single NAT)

EC2 instances in private subnets use NAT Gateways for internet access (apt updates, Docker installation, security patches). Single NAT Gateway creates single point of failure. If the NAT Gateway's AZ fails, instances in the other AZ can't bootstrap or update.

Total redundancy cost: $45/month ($12.41 for Multi-AZ RDS + $32.85 for second NAT Gateway)

This is insurance against extended outages, manual recovery procedures, and potential data loss.

Security: Runtime Credentials, Not Hardcoded Secrets

Database credentials are retrieved at runtime from AWS Secrets Manager:

secret_name = os.getenv('DB_SECRET_NAME')
client = boto3.client('secretsmanager')
secret = json.loads(client.get_secret_value(SecretId=secret_name)['SecretString'])

Where credentials are NOT:

Application code
Docker image layers
Environment variables (visible in process listings)

Where credentials ARE:

AWS Secrets Manager (encrypted at rest, access logged via CloudTrail)
EC2 instance memory only (ephemeral, destroyed on termination)

IAM instance profile grants read-only access to one specific secret. Even if an instance is compromised, the attacker can't access other secrets.

Rolling Deployment Strategy

Configuration:

min_healthy_percentage = 50

Deployment flow:

GitHub Actions builds Docker image, pushes to ECR (tagged with commit SHA)
Triggers Auto Scaling Group instance refresh
ASG replaces 50% of instances at a time
New instances pull latest image, complete 380-second warmup
ALB confirms new instances are healthy
Old instances terminated
Process repeats for remaining instances

Deployment time: 6-8 minutes

Docker build/push: 3 minutes
Rolling update with warmup: 3-5 minutes

Zero downtime: ALB continues routing traffic to healthy instances throughout deployment.

Failure Scenarios and Recovery

EC2 instance crash:

ALB health checks fail after 30 seconds
ALB stops routing traffic to failed instance
Auto Scaling Group replaces unhealthy instance
New instance completes warmup and joins rotation
Impact: Zero user-facing errors

Availability zone failure:

Multi-AZ RDS fails over to standby (1-2 minutes)
EC2 instances in failed AZ marked unhealthy
Auto Scaling Group launches replacements in healthy AZ
NAT Gateway redundancy ensures new instances bootstrap successfully
Impact: 1-2 minutes degraded performance (reduced capacity)

Docker image pull failure:

Instance warmup prevents premature traffic routing
Failed instance never receives traffic
Auto Scaling Group retries launch
Impact: Zero (deployment time increases, no user errors)

Key Lessons

Instance warmup must account for real bootstrapping time

I initially set warmup to 120 seconds. Deployments failed because Docker image pull took 40-60 seconds and health checks needed 20 seconds to stabilize. 380 seconds was determined by monitoring actual instance launch times.

Health checks must validate actual functionality

A health check that only verifies "the container is running" is useless. The /health endpoint executes a real database query. If the database is unreachable, the instance is genuinely unhealthy.

Multi-AZ costs are insurance premiums

The extra $45/month for Multi-AZ RDS and dual NAT Gateways prevents manual failover procedures, potential data loss, and extended outages. For production systems, this is a rounding error compared to downtime costs.

Conclusion

Production infrastructure is measured by how it handles failures, not how it performs in demos.

Multi-layer health checks, proper warmup periods, Multi-AZ redundancy, and zero-downtime deployments separate infrastructure that works in tutorials from infrastructure that works when databases fail, instances crash, or entire availability zones go offline.

Repository: github.com/escanut/terraform-aws-flask-oidc

Reach out: linkedin.com/in/victorojeje

I'm seeking remote opportunities in Cloud Engineering, DevOps, and Infrastructure Engineering. If your team needs someone who thinks about failure scenarios and production resilience, let's connect.

How I eliminated access keys from my deployment pipeline with OIDC, Terraform, and GitHub Actions

Victor Ojeje — Fri, 23 Jan 2026 21:45:10 +0000

The Problem with Traditional CI/CD

Most tutorials for deploying static sites to AWS tell you to:

Generate AWS access keys
Store them as GitHub secrets
Hope nobody compromises your repository

This approach has serious security implications. Long-lived credentials in CI/CD pipelines are a common attack vector since if your repository is compromised or secrets are accidentally exposed, attackers gain full AWS access with those credentials.

There's a better way: OpenID Connect (OIDC) federation.

What I Built

A fully automated static website deployment pipeline that eliminates access keys entirely by using temporary credentials exchanged through OIDC.

Source Code: GitHub Repository

Architecture Overview

Developer commits → GitHub Actions → OIDC token exchange 
→ Temporary AWS credentials → Deploy to S3 → CloudFront invalidation

Key Components:

S3 for static website hosting
CloudFront for global CDN
Terraform for infrastructure as code
GitHub Actions for CI/CD
OIDC for secure authentication

Why OIDC Over Access Keys?

Traditional Approach (Access Keys):

# Potential security risk

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Problems:

Keys are long-lived (valid until manually rotated)
If leaked, provide persistent AWS access
Require manual rotation and management
Stored as static secrets in GitHub

OIDC Approach:

# This is secure

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
    aws-region: ${{ secrets.AWS_REGION }}

Benefits:

Credentials expire in 1 hour (temporary)
No static secrets to leak
Zero credential rotation needed
AWS manages the trust relationship

Implementation Deep Dive

1. Setting Up the OIDC Provider in Terraform

First, create an OIDC identity provider that trusts GitHub:

resource "aws_iam_openid_connect_provider" "github" {
  url = "https://token.actions.githubusercontent.com"

  client_id_list = ["sts.amazonaws.com"]

  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

The thumbprint verifies GitHub's signing certificate authenticity.

2. Creating the IAM Role with Trust Policy

For this to work, we define exactly which repositories can assume this role:

resource "aws_iam_role" "github_actions" {
  name = "github-actions-s3-deployment"

  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:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          "token.actions.githubusercontent.com:sub" = "repo:${var.github_username}/${var.repo_name}:ref:refs/heads/main"
        }
      }
    }]
  })
}

Critical security feature: The StringLike condition restricts access to:

Your specific GitHub username
Your specific repository
Only the main branch

Even if someone forks your repo, they can't assume this role.

3. Least-Privilege IAM Permissions

The role only gets permissions it absolutely needs:

resource "aws_iam_role_policy" "github_actions" {
  role = aws_iam_role.github_actions.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:PutObject",
          "s3:GetObject",
          "s3:DeleteObject",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.website_storage.arn,
          "${aws_s3_bucket.website_storage.arn}/*"
        ]
      },
      {
        Effect = "Allow"
        Action = "cloudfront:CreateInvalidation"
        Resource = aws_cloudfront_distribution.website_storage.arn
      }
    ]
  })
}

No overly broad permissions.

4. CloudFront Configuration Challenge

Here's something that tripped me up: S3 website endpoints require custom origin configuration, not standard S3 origin configuration.

# This doesn't work for S3 website endpoints

origin {
  domain_name = aws_s3_bucket.website_storage.bucket_regional_domain_name
  origin_id   = "S3-Website"

  s3_origin_config {
    origin_access_identity = aws_cloudfront_origin_access_identity.default.cloudfront_access_identity_path
  }
}

# This works for the s3 website endpoints

origin {
  domain_name = aws_s3_bucket.website_storage.website_endpoint
  origin_id   = "S3-Website"

  custom_origin_config {
    http_port              = 80
    https_port             = 443
    origin_protocol_policy = "http-only"
    origin_ssl_protocols   = ["TLSv1.2"]
  }
}

Why? S3 website endpoints function as HTTP servers, supporting redirects and error documents. Standard S3 origins access the S3 API directly and don't support these features.

5. Remote State Management

For production infrastructure, always use remote state with locking:

terraform {
  backend "s3" {
    bucket         = "escanut-tf-state"
    key            = "s3-website/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-state-lock"
    encrypt        = true
  }
}

This will enable:

Team collaboration without conflicts
State encryption at rest
Prevention of concurrent modifications

The GitHub Actions Workflow

The deployment workflow is remarkably simple:

name: Deploy to S3

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Required for OIDC
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Sync to S3
        run: |
          aws s3 sync ./build s3://${{ secrets.S3_BUCKET }} --delete

      - name: Invalidate CloudFront
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_ID }} \
            --paths "/*"

      - name: Deployment Overview
        run: |
          echo "Website deployment successful" 
          echo "https://${{ secrets.CLOUDFRONT_URL }}"

Deployment time: Approximately 30 seconds from commit to live site (measured from workflow logs).

Cost Analysis

One of the best parts? This infrastructure costs almost nothing to run.

Monthly costs (based on January 2026 AWS pricing):

Service	Usage	Cost
S3 Storage	<1GB	$0.02
S3 Requests	10k/month	$0.05
CloudFront	10GB transfer	$0.85
Total		~$0.92/month

For comparison, a single t3.micro EC2 instance costs $8-15/month and requires active management.
.

AWS's eventually consistent nature means public access settings must be applied before the bucket policy.

Security Wins

This architecture eliminates several attack vectors:

No long-lived credentials - temporary credentials expire in 1 hour

Repository-scoped access - only your specific repo can deploy

Branch-specific trust - only main branch can trigger deployments

Least-privilege permissions - role can only write to specific S3 bucket

Encrypted state - Terraform state encrypted at rest in S3

No credential rotation - AWS handles credential lifecycle automatically

The current implementation shows:

Infrastructure as Code proficiency
Cloud security best practices
CI/CD automation
Cost optimization awareness

Conclusion

OIDC federation with GitHub Actions is the modern standard for CI/CD authentication to AWS. It's more secure, requires zero maintenance, and is easier to implement than managing long-lived access keys.

If you're still using AWS access keys in your deployment pipelines, it's time to upgrade.

Try it yourself: Fork the repository, update the variables, and deploy your own infrastructure in under 5 minutes.

Drop a comment below or reach out on LinkedIn.

If this was helpful, consider giving the GitHub repo a ⭐!

Deploying Secure WordPress on AWS: A Multi-Tier Architecture Approach

Victor Ojeje — Tue, 20 Jan 2026 18:07:20 +0000

This project started as a learning exercise and ended up looking very close to how small production workloads are actually deployed. The goal was simple: run WordPress on AWS with proper network isolation, least-privilege access, and basic monitoring, without spending money or cutting corners.

Everything here was built inside Free Tier limits, but the design decisions follow the same patterns used in real environments.

Architecture Overview

I deployed WordPress using a classic two-tier setup inside a custom VPC.

Core components:

Custom VPC: 10.0.0.0/16
Public subnet: 10.0.1.0/24 for the web server
Private subnets: 10.0.10.0/24 and 10.0.11.0/24 for RDS
EC2 t2.micro running Ubuntu 24.04
RDS MySQL db.t4g.micro
Elastic IP for stable external access
Apache 2.4, PHP 8.1, WordPress

Traffic flow:

Internet → Internet Gateway → EC2 Compute (public subnet) → RDS (private subnets)

[Architecture and traffic flow]

The database has no public IP and no route to the internet. All access is controlled with security groups. I intentionally did not rely on NACLs or host firewalls to keep the design aligned with how AWS environments are usually managed.

Security Implementation

Security Groups

The security group setup is minimal and intentional.

Web tier security group:

SSH (22): allowed only from my admin IP
HTTP (80) and HTTPS (443): open to the internet

Database tier security group:

MySQL (3306): allowed only from the web tier security group

No IP-based rules between tiers. Only security group references.

[EC2 security group details]

[RDS security group details]

This matters. The first version used the EC2 private IP as the database allow list. That failed immediately after a reboot when the IP changed. Switching to security group IDs fixed the issue permanently and reflects how AWS expects environments to scale and change.

WordPress Hardening

I applied basic but meaningful WordPress security controls:

Disabled file editing in the admin dashboard
Limited login attempts to reduce brute-force risk
Disabled XML-RPC
Enforced sane file permissions (755 for directories, 644 for files)
Enabled HTTPS using a self-signed certificate

Let's Encrypt does not issue certificates for AWS public DNS names. Using a self-signed cert keeps traffic encrypted while avoiding extra costs. Which is fine in this case, as its a demo, not production.

Monitoring and Alerting

Both EC2 and RDS are monitored with CloudWatch.

Alarm configuration:

CPU utilization threshold: 70 percent
Action: SNS email notification

I chose 70 percent instead of waiting for 80 to 90 percent. On small instance types, sustained CPU spikes quickly translate into performance problems.

[CloudWatch dashboard]

[CloudWatch alarms]

During normal usage, EC2 CPU sat around 12 to 18 percent. During load testing, alarms triggered correctly and SNS emails arrived within about 2 to 3 minutes. That confirms the alerting path actually works, not just that it exists.

Real Problems Encountered

Security Group Misconfiguration

Using IP addresses for internal trust broke the moment the instance restarted. This is a common mistake in AWS environments and a good lesson. In AWS, security groups are the trust boundary, not IPs.

WordPress URL Handling

WordPress stores absolute URLs inside the database. Changing the Elastic IP meant internal links broke even after updating wp-config.php.

The fix required a full database search and replace using WP-CLI. This isn't documented in most WordPress migration guides but breaks production migrations regularly.

Free Tier Cost Awareness

AWS does not stop you from spending money. An unattached Elastic IP started generating charges within hours.

Billing alarms should be set up immediately, even for learning projects. Free Tier does not mean free by default.

Design Trade-offs

Single-AZ RDS

Multi-AZ was skipped to stay within Free Tier. This means backups exist, but there is no automatic failover. Recovery requires restoring from a snapshot and takes several minutes. That is acceptable here, not for systems with tight recovery objectives.

Apache instead of Nginx

Apache was chosen for simplicity and WordPress compatibility. Nginx would scale better under high concurrency, but that advantage does not matter at this size.

Self-signed SSL

Encrypted traffic without a domain cost. Browser warnings are expected. This was a deliberate trade-off, not an oversight.

Results

[WordPress live test]

WordPress reachable over HTTPS via Elastic IP
RDS fully isolated in private subnets
Database access restricted to the web tier only
CloudWatch alarms and SNS notifications verified
Automated RDS backups tested via snapshot restore
Total cost stayed at $0 within Free Tier limits

Skills Demonstrated

Cloud and Infrastructure:

VPC and subnet design
Security group based access control
EC2 and RDS provisioning
Elastic IP management

Linux and Systems:

Ubuntu server setup
Apache and PHP configuration
MySQL client usage
Service and permission management

Security:

Network isolation
Least-privilege enforcement
TLS configuration
Application-level hardening

Operations:

CloudWatch monitoring
SNS alerting
Backup validation
Cost awareness

Final Notes

This project reflects how small but real AWS environments are built. The focus was fully on correct fundamentals including isolation, access control, monitoring, and understanding trade-offs.

Victor Ogechukwu Ojeje

Email: ojejevictor@gmail.com

LinkedIn: linkedin.com/in/victorojeje

GitHub: github.com/escanut

Deployment screenshots and configuration details available in the project repository.