AWS Cloud Infrastructure Platform

// 01 · ARCHITECTURE

Pipeline Overview

The pipeline is intentionally serverless: no EC2 instances, no idle compute costs. An HTTP API Gateway endpoint (POST /ingest) is the only public surface. It invokes a Lambda function via AWS_PROXY integration, which validates the payload, attaches a UUID and UTC timestamp, then writes a structured JSON object to S3 partitioned by date (events/YYYY-MM-DD/uuid.json). All within free tier at this traffic level.

Throttling is enforced at the API Gateway stage: 10 requests/second rate, 20 burst, enough for any legitimate demo load, prevents abuse. CloudWatch monitors Lambda error rate and duration, alarming if errors occur or if average duration exceeds 2000ms (1 second below the 3s timeout).

// 02 · STATUS MONITOR

A Second, Independent Pipeline

A separate uptime monitor for atabany.net (and other targets), built as two independent loops that only share one DynamoDB table: a check loop (EventBridge on a 5-minute schedule → a checker Lambda → HTTPS request to each target → write to DynamoDB, alerting via SNS only when a target's status actually flips up↔down, not on every failed check during an outage), and a read loop (a static S3 status page → its own API Gateway → a read-only Lambda → DynamoDB). Neither loop calls the other directly.

The real difficulty here wasn't boilerplate CRUD — it was a genuine near-miss caught before it became a bill: DynamoDB's on-demand billing mode looks like the safer default for a low-traffic table, but AWS's always-free 25 RCU/25 WCU allowance applies specifically to provisioned capacity; on-demand has no equivalent ongoing free allowance outside a new account's first 12 months, and this account isn't new. Switched to provisioned (1 RCU/1 WCU, far more than the ~288 writes/day this needs) before that ever reached production.

// 03 · TERRAFORM MODULES

Infrastructure as Code

The project uses modular Terraform: each concern is a separate module with its own variables.tf, main.tf, and outputs.tf. Modules communicate only through explicit output → variable wiring in the root module. No module references another's resources directly. Remote state in S3 with DynamoDB locking prevents concurrent apply corruption.

// 04 · LEAST PRIVILEGE & SECURITY BASELINE

Auditing What Already Existed, Not Just What's New

A real finding, not a hypothetical one: the GitHub Actions deploy role — written before the status monitor existed — still granted lambda:UpdateFunctionCode on Resource: "*" (every function in the account) plus S3 permissions the deploy workflow never actually calls. A five-line grep confirmed it: those S3 actions had been unused since the policy was written. Scoped the role down to exactly the three function ARNs it deploys to, and dropped the S3 grant entirely. The monitored-site list also moved out of Lambda environment variables into SSM Parameter Store, so changing which sites get watched no longer requires a code redeploy.

The account-wide baseline added on top: IAM Access Analyzer (free, continuous, flags any resource policy granting access outside this account's trust zone), and a password policy (14-char minimum, all four character classes, 5-password reuse prevention) — deliberately without forced rotation. NIST 800-63B argues against mandatory periodic password rotation (it pushes people toward predictable incremented passwords); that's a documented decision, not an oversight the next scanner should flag. CloudTrail relies on the always-free 90-day default event history rather than a paid Trail, since a project with a $0.01-actual budget-alarm threshold shouldn't wave through "probably a fraction of a cent a month" as if it were free.

GuardDuty, Security Hub, and AWS Config are explicitly out of scope — all three bill per-event, per-check, or per-resource, a real ongoing cost against this project's $0 ceiling, not a rounding error. Naming that trade-off out loud, with the actual cost reason, is itself the practice worth demonstrating: "what would you add if the budget changed" is a real interview question, and a deferred control with a documented reason is a different thing entirely from a gap nobody noticed.

The credential-report audit this baseline enabled also surfaced two real, still-open gaps on the account's day-to-day IAM user: no MFA enabled, and an access key past its 90-day rotation point. Both are flagged here rather than silently fixed — MFA enrollment needs a physical device, and this project's own rule was to defer rotation until explicitly raised, not to rotate credentials out from under an account automatically.

// 05 · CI/CD · OIDC FEDERATION & POLICY AS CODE

Zero Static Credentials

GitHub Actions authenticates to AWS using OIDC federation: no AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere in GitHub. When a workflow runs, GitHub presents a signed JWT to AWS STS. AWS verifies the token against the registered OIDC provider and issues temporary credentials scoped to the portfolio-platform-dev-github-actions IAM role.

The role's trust policy uses a StringLike condition on the token.actions.githubusercontent.com:sub claim, locking it to repo:omaratabany/portfolio-aws-platform:*. A fork of the repo cannot assume this role. Credentials are valid only for the duration of the job, typically under 2 minutes. The deployment workflow only triggers on pushes to main that change files under functions/, avoiding unnecessary deploys on documentation or Terraform-only changes.

CI also runs a Checkov scan against the Terraform on every PR, in soft_fail mode: findings are visible in the job log, but don't block merges. The first run against already-deployed infrastructure — not a fresh init — came back 130 passed, 45 failed across 25 checks. Hard-enforcing from that baseline would have turned every future PR red over findings nobody had triaged yet, so the real work was triage, not a uniform fix-everything pass:

An automated reviewer (Codex) also caught a real gap on this same pipeline before merge: the workflow's GITHUB_TOKEN had the default scope, which can include write access depending on repo settings, even though neither CI job ever writes back to the repository. Scoped to contents: read with persist-credentials: false on every checkout — a step that runs PR-supplied code with a live, writable token sitting in local git config is exactly the shape of a supply-chain risk, not a hypothetical one.

// 06 · OBSERVABILITY & GRAFANA BRIDGE

Alarms That Actually Catch Failures

CloudWatch alarms cover both status-monitor Lambdas: Errors, Duration, and Throttles each, plus an API Gateway 5xx alarm — eight alarms total, still well inside the free 10-alarm allowance. Three of those didn't exist in the first version of this work; an automated reviewer caught all three as real gaps before merge, not stylistic nitpicks:

The stretch goal for this phase: bridge these AWS metrics into the homelab's self-hosted Grafana, so cloud and on-prem observability sit side by side. The real constraint was structural, not technical — there's no AWS compute for an on-prem Grafana instance to assume an IAM role from, so the usual "role instead of a static key" pattern used everywhere else in this project isn't available here. Built a scoped IAM user instead (read-only: cloudwatch:GetMetricData/ListMetrics/DescribeAlarms and the two non-CloudWatch permissions Grafana's plugin documents needing), with the access key generated directly via the CLI rather than as Terraform state — so the one long-lived credential this project creates never sits in a file under version-control review. Both homelab Grafana instances (a Docker deployment and a separate Kubernetes/kube-prometheus-stack deployment) now query CloudWatch as a data source.

// 07 · LIVE DEMO

Hit the Real Endpoint

The form below sends a real POST request through this Cloudflare Worker (as a proxy) to the AWS API Gateway endpoint in eu-central-1. Lambda processes it, writes a JSON event to S3, and returns the event ID and S3 key. You're invoking a live serverless pipeline.