all case studies
INFRASTRUCTURE// case study

AWS Landing Zone & Guardrails

Infrastructure that survives the on-call rotation.

A Terraform-based AWS foundation covering VPC architecture, GitHub OIDC, security guardrails, and CI-tested infrastructure modules.

Role
Design + build + operate
Client
Sage Ideas (Internal)
Category
Infrastructure
Status
Operational
AWS Landing Zone & Guardrails hero

Terraform Modules

4

Critical Vulns

0

Products Using Modules

3

Long-Lived Keys

Eliminated

Living architecture

Surface ⇄ System

AWS Landing Zone & Guardrails is presented as both the product people touch and the operating system underneath it: UI, data model, integration path, evidence, and outcome.

Discuss a Build engagement
  1. 01Visible productScreenshots and product frames show the user-facing surface without pretending concept art is production proof.
  2. 02Operating architectureThe case includes a system map so the architecture is visible, not buried in prose.
  3. 03Evidence registerMetrics, build logs, diagrams, CI artifacts, and links separate actual work from agency theater.
  4. 04Commercial pathThe page routes qualified buyers toward a matching build, automation, or lab entry.

// scroll to x-ray the build

AWS Landing Zone & Guardrails product surfacesurface
AWS architecturesystem
Multi-account AWS landing zone with hub-spoke topology, centralized logging, security boundaries, and per-account guardrails. The Terraform that makes this reproducible is the deliverable.

case flow

Surface ⇄ System

ProblemInfrastructureSurface2 screensSystemmappedProof4 metricsRouteservice
A case study should prove both layers: the surface people see, and the system that keeps the product alive after launch.

AWS Landing Zone & Guardrails operating map

The diagram is intentionally simplified: it shows the buying logic and operating path, not a decorative fantasy architecture.

client

Sage Ideas (Internal)

category

Infrastructure

evidence

3 assets

Proof board

Receipts before claims.

This page separates shipped surface, system map, real metrics, and available artifacts so the work can be inspected instead of just admired.

proof assets

8

Screens, gallery, artifacts

screens

2

Real product surfaces

artifacts

3

Available during discovery

Primary evidence

Infrastructure that doesn't need babysitting.

Terraform Modules

4

Terraform Modules

4

Critical Vulns

0

Products Using Modules

3

Long-Lived Keys

Eliminated

Surface

Product screenshots and interface frames show the user-facing layer. If real assets are unavailable, the page says so instead of dressing mockups as production proof.

System

Architecture diagrams, build logs, and artifacts make the hidden operating layer visible to technical buyers.

View Terraform modules on GitHub
01// the problem

What was broken.

The pattern is familiar: a startup spins up AWS resources manually, the "just this once" approach becomes the permanent approach, and two years later nobody knows what's in the account, the IAM policies are a maze, and the first security audit is a bad day.

Good infrastructure should be boring. Reproducible, documented, version-controlled, and provably secure. The AWS Landing Zone project establishes that baseline from day one.

The challenge: building a Terraform-based AWS foundation that covers the real requirements — proper VPC architecture, secure S3+CloudFront patterns, Lambda API scaffolding, GitHub Actions OIDC (no long-lived AWS keys), account-level guardrails, and CI gates that prevent misconfiguration from reaching production — all packaged as reusable modules.

02// the approach

How it was built.

VPC Module: multi-AZ VPC with public/private subnet split, NAT gateway configuration, VPC flow logs, security group baseline. S3 + CloudFront Module: static asset distribution with proper bucket policies, CloudFront OAI, cache invalidation patterns, HTTPS enforcement. Lambda API Module: function configuration, IAM execution role, API Gateway V2, environment variable management, log group with retention.

GitHub OIDC Module: federated identity between GitHub Actions and AWS — eliminates long-lived access keys from CI pipelines entirely. Landing Zone Module: AWS Control Tower-compatible baseline — root account security, SCP guardrails, CloudTrail, Config Rules, Security Hub findings.

Every module CI-tested with: terraform fmt check, terraform validate, tfsec security scanning, checkov compliance scanning, automated plan on PR, apply on merge to main (with approval gate).

03// architecture

The system map.

How the pieces talk to each other.

AWS Landing Zone ArchitectureTerraform plans expand into VPC networking, GitHub OIDC trust, IAM guardrails, and KMS keys, applied across a multi-account AWS Organization, with CI smoke tests gating the apply.Terraform PlanHCL modulesVPC Modulesubnets + NATGitHub OIDCfederated trustIAM GuardrailsSCPs + permissionsKMS Keyscustomer-managedLoggingCloudTrail + S3AWS Organizationaccount · prodworkloadsaccount · stagingnon-prodaccount · securityaudit + GuardDutyaccount · log-archivecentral trailaccount · sandboxdev playgroundCI Smoke Testsapply + verifyDrift DetectionnightlyplanapplyverifyscanPLANTF MODULEAPPLY
04// the numbers

Measured, not asserted.

The real figures from the engagement, printed verbatim. Bars are scaled against the largest comparable magnitude in the set — a secondary cue, never the source of truth.

metric · valuescale 0 – 4
Terraform Modules
4
Critical Vulns
0
Products Using Modules
3
Long-Lived Keys
Eliminated
05// built ui

Selected screens.

Real product surfaces from the engagement — not stock illustrations.

AWS Console showing 13 accounts and 4 organizational units governed by Control Tower
01 / 02

Control Tower view — 13 accounts, 4 OUs, all guardrails green and SCPs in effect.

06// evidence

What it actually looks like.

Architecture diagrams, CI runs, and dashboards from the engagement.

architectureAWS architecture
Multi-account AWS landing zone with hub-spoke topology, centralized logging, security boundaries, and per-account guardrails. The Terraform that makes this reproducible is the deliverable.
Multi-account AWS landing zone with hub-spoke topology, centralized logging, security boundaries, and per-account guardrails. The Terraform that makes this reproducible is the deliverable.
terminalTerraform plan
CI run on a Terraform PR — plan output is reviewed, security scan runs, and only then does the apply happen. Infrastructure changes get the same review treatment as application code.
CI run on a Terraform PR — plan output is reviewed, security scan runs, and only then does the apply happen. Infrastructure changes get the same review treatment as application code.
reportSecurity scan
tfsec / Checkov scan output enforced as a CI gate. Misconfigured S3 buckets, open security groups, and weak IAM policies fail the build before they touch a real account.
tfsec / Checkov scan output enforced as a CI gate. Misconfigured S3 buckets, open security groups, and weak IAM policies fail the build before they touch a real account.
07// the build log

What shipped.

The verbatim ship record, given timeline structure.

  1. log · entry 01

    4 public Terraform modules (terraform-aws-vpc, terraform-aws-s3-cloudfront, terraform-aws-lambda-api, terraform-aws-github-oidc). AWS Landing Zone module with full guardrail set. CI/CD pipeline: GitHub Actions workflows for all modules.

  2. log · entry 02

    Security scanning: tfsec + checkov integrated into every PR. Documentation: README for each module with example configurations and variable references.

08// the outcome

What it proved.

All modules CI-tested and security-scanned with zero known critical vulnerabilities. GitHub OIDC pattern eliminates long-lived AWS credentials from every pipeline that adopts it.

Landing Zone module provides a documented, reproducible baseline for new AWS accounts. Modules in use across 3 Sage Ideas products (Nexural, Jobpoise, Trayd).

Infrastructure-as-Code disciplines — version control, CI testing, security scanning, modular design — should apply to AWS configuration exactly as they apply to application code. The modules here represent the baseline applied to every new project, not an optional enhancement.

09// artifacts

Available on request.

  • GitHub: All 4 Terraform modules (public)
  • Module documentation and example configurations
  • CI pipeline templates
// references

Talk to people on this work.

No fabricated quotes. Reference contacts are shared during discovery, with both parties' consent.

Reference available

Engineering lead

Fintech · 5 years

Worked alongside on production trading systems for 5+ years. Available for technical reference calls — code quality, on-call discipline, incident behavior.

Reference call shared during discovery, both consenting.
Reference available

Founder

Studio engagement

Engaged Sage Ideas for a Ship + Operate combination. Willing to talk about scope discipline, timeline accuracy, and what handoff actually looked like.

Reference call shared during discovery, both consenting.
“Click-ops is how AWS bills get to $40k. Every resource we create is a pull request, every change has a plan, every plan has an approver.”
// build log · entry 04
// honesty

What almost happened.

Every project has near-misses — decisions that, if we'd kept going, would have shipped a hole. This is the diff between the version that almost made it to prod and the version that did.

// near-miss · 01diff

beforeCI was going to use long-lived AWS access keys stored in GitHub secrets. The kind that leak in build logs and live in `~/.aws/credentials` forever.

afterGitHub OIDC federation. Workflows assume a scoped IAM role per environment, valid for the job duration, with no key material on disk anywhere.

costOne afternoon of setup. Permanent removal of the worst secret-leak class.

// near-miss · 02diff

beforeDefault VPC was going to stay enabled in every account. The classic AWS footgun — wide-open egress and a 10.0.0.0/16 nobody documented.

afterService Control Policy denies VPC default creation. Bootstrap module provisions a hardened VPC with explicit subnets, flow logs, and a NAT pattern that scales down on weekends.

costA few hours of SCP debugging. ~$180/mo saved on a NAT we no longer keep warm at 3am.

// from the repo

Inline excerpts.

Trimmed, but real. The patterns that made the system survive retries, multi-tenant queries, and a bot that won't hallucinate.

GitHub OIDC → IAM role
yaml
# .github/workflows/deploy.yml
permissions:
  id-token: write   # required for OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ vars.PROD_ACCOUNT }}:role/gha-deploy-prod
          role-session-name: gha-${{ github.run_id }}
          aws-region: us-east-1
      # role is valid for ~1 hour; no AWS_ACCESS_KEY_ID in this repo, ever.
      - run: terraform apply -auto-approve
// No long-lived keys. The trust policy pins workflow + branch + repo.
SCP — deny default VPC creation
json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDefaultVpc",
      "Effect": "Deny",
      "Action": ["ec2:CreateDefaultVpc", "ec2:CreateDefaultSubnet"],
      "Resource": "*"
    }
  ]
}
// Org-wide guardrail. No workload account can create a default VPC, period.
livebuild a1556e22026-06-19 03:29Z
// solo studio// no analytics resold// every commit human-reviewed