AWS Landing Zone
A repeatable AWS foundation with isolated environments, scoped identity and infrastructure changes reviewed as code.
Terraform · AWS · GitHub Actions
Scope: architecture and validation design. The indicators summarize design targets. Implementation evidence will be added as the lab develops.
The scenario
A fictional product team needs separate development and production environments. Manual console changes make environments drift and ownership difficult to trace.
Architecture
The proposed foundation separates environment accounts, places workloads in private subnets across three Availability Zones, and exposes only an application entry point. Terraform modules describe networking, IAM and shared logging. An S3 backend stores versioned state with native lock files.
Key decisions
GitHub Actions assumes a narrowly scoped AWS role through OIDC. The trust policy restricts the repository and deployment environment. Plan review happens before an approved apply. Each environment has its own state and deployment role to limit blast radius.
Validation plan
The validation plan checks module formatting and validation, unintended public subnets, state-lock contention and a second plan after apply. A deliberate drift exercise tests whether a changed security-group rule appears in the next plan.
Trade-offs
A managed NAT gateway per Availability Zone improves failure isolation but increases baseline cost. A small lab can use a cheaper topology; that compromise must be explicit before calling the design production-ready.
Next iteration
Build the modules, attach a reproducible test run and measure provision time and monthly cost. No customer deployment or measured business result is claimed in this design study.
El escenario
Un equipo de producto ficticio necesita separar desarrollo y producción. Los cambios manuales desde la consola generan diferencias entre entornos y dificultan rastrear su origen.
Arquitectura
La propuesta separa cuentas por entorno, ubica las cargas en subredes privadas de tres zonas de disponibilidad y expone únicamente la entrada de la aplicación. Módulos de Terraform describen red, IAM y logs compartidos. Un backend S3 conserva el estado versionado con archivos de bloqueo nativos.
Decisiones técnicas
GitHub Actions asume un rol de AWS acotado mediante OIDC. La política de confianza restringe el repositorio y el entorno de despliegue. El plan se revisa antes de aprobar el apply. Cada entorno tiene su propio estado y rol para limitar el alcance de un error.
Plan de validación
El plan de validación revisa formato y validez de módulos, subredes públicas no previstas, concurrencia del bloqueo y un segundo plan después del apply. Un ejercicio de drift modifica una regla de seguridad para comprobar que aparezca en el siguiente plan.
Concesiones del diseño
Un NAT gateway administrado por zona mejora el aislamiento de fallos, pero eleva el costo base. Un laboratorio pequeño puede usar una topología más económica; esa concesión debe ser explícita antes de considerar el diseño listo para producción.
Próxima iteración
Construir los módulos, adjuntar una ejecución reproducible y medir tiempo de aprovisionamiento y costo mensual. Este caso de diseño no presenta un despliegue para un cliente ni resultados de negocio medidos.