Back to Projects
AWSIaCPlatform EngineeringActiveAdvanced

AWS Landing Zone + Guardrails

Multi-account AWS Organizations foundation with SCP guardrails, centralized audit logging, and gated Terraform deployments

In progress
Started Jan 2026
Team of 1
Platform/Cloud Engineer - design + implementation
View on GitHub

TL;DR

fast skim
Problem: Most AWS projects show services, not governance + change control.
Constraints: Low-cost, reproducible, safe-by-default (no click-ops).
Built: AWS Organizations landing zone + SCP guardrails + centralized audit logging + gated Terraform CI.
Results: Evidence-first guardrails baseline with CI receipts and ops docs.
Proof: Repo + CI runs + Evidence library + Security guardrails write-up.

Recruiter note: this block is designed for remote evaluation — problem, constraints, what shipped, and proof.

Recruiter quick links

Recruiter ModeSecurity GuardrailsEvidence Library

Remote-friendly: each link is a short path to proof (design, runtime, evidence).

Proof

CI status
CI RunsLatest Report

Recruiter note: this section is intentionally “evidence-first” (builds, runs, reports).

Ops Evidence (this is what “runs systems” looks like)

I don’t ship infrastructure and walk away. I treat it like a production system: guardrails, change control, observability, cost awareness, and runbooks so someone else can operate it.

Open evidenceSource repo
Cost guardrails
Budgets + alerts. I keep cloud costs predictable and I can explain the bill.
Security + auditability
Org-level CloudTrail, centralized logs, and SCP guardrails to prevent unsafe actions.
Change control
Plan-on-PR + gated apply. Infrastructure changes are production changes.
Alerts + monitoring
Health checks + dashboards that catch regressions before a human does.
Runbooks
Rollback, drift detection, incident triage, and cost spike investigation — written down.
Recovery mindset
I design for failure: blast radius control, safe defaults, and quick recovery paths.

Note: this section is intentionally operations-focused. It’s what senior reviewers look for when they ask “can this person run systems, not just build demos?”

Quality Gates

This project is presented like a production system: measurable, reproducible, and backed by evidence. (Next step: make these gates fully project-specific and auto-fed into the Quality Dashboard.)

CI runsReport
CI pipeline
Test report artifact
API tests
E2E tests
Performance checks
Security checks
Accessibility checks
Run locally
git clone https://github.com/JasonTeixeira/Landing-Zone-Guardrails
# See repo README for setup
# Typical patterns:
# - npm test / npm run test
# - pytest -q
# - make test

AWS Landing Zone + Guardrails (Flagship)

Executive summary

This project builds a small but real AWS landing zone using AWS Organizations + Terraform, with guardrails (SCPs), centralized audit logging, and a gated CI workflow.

The goal isn’t “I can click around AWS” — it’s to show I can build a foundation a company could actually run.

Interview hooks (talk track)

If we talk about this in an interview, here’s the quick story:

  • Problem: Most “cloud projects” don’t show governance. Teams need multi-account, auditability, and safe change control.
  • Constraints: Keep it low-cost, reproducible, and safe-by-default (no “click ops” and no hidden steps).
  • What I built: AWS Organizations layout + centralized CloudTrail → S3 + SCP guardrails + CI plan/apply gates.
  • Proof: CI receipts + docs + evidence screenshot (see links below).
  • What I learned: Guardrails are about defaults + blast radius (not over-restricting teams).
  • What I’d do next: Add SSO (Identity Center) + Config/SecurityHub + drift detection.

What I built (v1)

This repo is intentionally scoped to a practical, low-cost baseline you can actually stand up:

  • Organizations foundation (org + accounts + OU structure)
  • Central audit trail: org-level CloudTrail → central S3
  • Preventative guardrails: Service Control Policies (SCPs)
  • Change control: Terraform fmt/validate/plan in CI + a gated apply path
  • Ops-ready documentation: architecture/security/ops/cost notes

What this proves

  • AWS Organizations / multi-account governance
  • Guardrails that prevent risky behavior without slowing teams down
  • Centralized audit logging and baseline detective controls
  • Cost controls (budgets + notifications)
  • CI/CD discipline for infrastructure changes (plan on PR, apply with approval)

Architecture (high level)

Developer PR → GitHub Actions → terraform fmt/validate/plan → review/approval → apply

AWS side:

Organizations ├─ OU: Security │ ├─ Account: Audit │ └─ Account: Log Archive └─ OU: Workloads ├─ Account: Dev └─ Account: Prod

Org CloudTrail └─ centralized S3 bucket (log archive)

SCPs └─ deny patterns that block high-risk actions (examples below)

Proof & evidence

In scope (v1)

  • AWS Organizations
  • OUs + account layout (security/logging + workloads)
  • Org CloudTrail → central S3
  • SCP guardrails (examples)
    • deny leaving the organization / removing required controls
    • deny disabling CloudTrail / audit log delivery
    • restrict regions (allowlist) to reduce blast radius
    • deny turning off encryption / public access on log buckets
  • Budget alerts (target: $75/mo)

Guardrails philosophy (how I think about SCPs)

SCPs are coarse safety rails, not fine-grained IAM. I use them to enforce:

  • Non-negotiables (audit/logging cannot be disabled)
  • Blast radius control (region restriction)
  • Safe defaults (encryption + public access blocks)

The goal is to stop obviously dangerous actions before they happen, while leaving teams free to operate inside the guardrails.

Change control philosophy (why gated apply matters)

Infrastructure changes are production changes.

I treat Terraform like an engineering system:

  • Plan is generated on PR so reviewers can see intent
  • Apply is separated and can be gated (approval) to reduce accidental changes
  • The repo contains docs/runbooks so “how it works” is not tribal knowledge

What’s next (v2 / planned)

These are natural next increments once the foundation is stable:

  • AWS IAM Identity Center (SSO) baseline
  • Detective controls: AWS Config + Security Hub + GuardDuty
  • Guardrail expansions: org-wide deny lists + break-glass process
  • Drift detection and scheduled policy checks

How to run

See the repo README for step-by-step deploy instructions.

Technologies Used:

AWSTerraformGitHub Actions

Impressed by this project?

I'm available for consulting and full-time QA automation roles. Let's build quality together.

Get in TouchView More Projects