Terraform foundation
Backends, account baseline, VPC, DNS, certificates, edge, registries, storage, secrets, EKS, and data services.
A cost-aware AWS platform from stage to production.
Case file / AWS + GitOps
A SaaS platform needed a lean stage environment and a production path with stronger managed-service boundaries. Modular Terraform established the AWS foundation; Argo CD reconciled EKS platform services and workloads through one reviewable operating model.
Project snapshot
- Client
- SaaS platform
- Workload
- Web front end, API, workers, identity, and specialist services
- Environment model
- Separate stage and production AWS environments
- Foundation
- Modular Terraform with remote state boundaries
- Runtime and delivery
- Amazon EKS, Karpenter, and Argo CD app-of-apps
- Data path
- In-cluster stage services and managed production services
The challenge
Keep stage lean without making production a second platform project.
The platform needed to support the same workload shape across environments while allowing cost, data, and protection decisions to become stricter in production.
- Keep stage economical enough for regular engineering use without creating a disposable platform design.
- Give production stronger data, backup, and deletion safeguards without rebuilding the delivery model.
- Separate AWS provisioning from Kubernetes reconciliation so each change has a clear owner and failure boundary.
- Run essential platform controllers on stable capacity while allowing application nodes to scale with demand.
- Deliver secrets to workloads without storing secret values in Git or application manifests.
Architecture note
AWS foundations below, GitOps reconciliation above.
Terraform and Argo CD have different ownership boundaries, but they describe one environment model. Stage and production share the control path while making different cost and resilience choices.
Environment architecture
Two control sources, one stage-to-production operating model
GitOps desired state
Environment projects, root applications, platform controllers, workload manifests, and sync ordering.
Reviewed desired stateTerraform provisions AWSArgo CD reconciles Kubernetes
Cost-aware stage
Small fixed core, elastic workloads.
A compact controller node group keeps cluster services stable. Karpenter adds workload capacity, while lower-cost egress and in-cluster data services reduce idle infrastructure.
- Private EKS workload subnets
- CloudNativePG with object-storage backups
- In-cluster Valkey and mail capture
- API, workers, identity, and specialist services
Production path
Managed data and explicit safeguards.
The same EKS and GitOps operating model connects to managed PostgreSQL and Valkey, private service boundaries, protected object storage, and an edge path with CDN and WAF controls.
- Private EKS and database subnets
- Managed PostgreSQL with backups and deletion protection
- Encrypted managed Valkey
- Private object storage behind CDN and WAF
Shared platform controls
Secrets
AWS Secrets Manager to External Secrets
Images
ECR and immutable workload references
Traffic
DNS, TLS, load balancing, CDN, and WAF
Identity
Scoped CI and workload AWS roles
Engineering decisions
Cost and control decisions stay visible in code.
Separate provisioning from reconciliation
Terraform owns AWS resource lifecycles and remote-state boundaries. Argo CD owns platform controllers and Kubernetes desired state. The split makes drift and recovery easier to reason about.
Keep only the control plane permanently warm
A small managed node group is dedicated to essential controllers. Karpenter provides application capacity, preserving a stable control layer without fixing all workload capacity in advance.
Make stage cost choices explicit
Stage uses lower-cost egress and Kubernetes-hosted PostgreSQL, Valkey, and mail capture. Those choices are isolated behind the same service and GitOps boundaries used by the wider platform.
Strengthen production data boundaries
Production moves PostgreSQL and Valkey to managed AWS services with private networking, encryption, backup retention, and deletion safeguards encoded in Terraform.
Bridge secrets at runtime
External Secrets reads approved values from AWS Secrets Manager through scoped workload identity. Git contains references and desired state, not the secret values themselves.
Sequence the platform before workloads
Argo CD sync waves establish namespaces, controllers, storage, secrets, and scaling components before application workloads reconcile. Automated prune and self-heal keep accepted desired state in place.
Delivery path
Bootstrap once, then operate through reviewed desired state.
The order matters: state and AWS boundaries first, GitOps control plane second, platform controllers third, then application workloads.
Repository review remains the change decision point.
- 01
Establish state
Create global and regional Terraform backends, then isolate environment stack state.
- 02
Build the AWS boundary
Provision networking, DNS, certificates, edge controls, registries, storage, secrets, EKS, and environment-specific data services.
- 03
Bootstrap GitOps
Register the environment project and root Argo CD application against the intended cluster destination.
- 04
Reconcile in waves
Install platform controllers and shared services before identity, API, workers, and specialist workloads.
- 05
Operate through Git
Repository review changes desired state; Argo CD applies, prunes, and self-heals that accepted state.
Operating outcome
A lean stage and a production-ready path, without hiding the trade-offs.
Architecture risk avoided
Stage is not a separate hand-built sandbox, and production is not a late rewrite. Both environments follow the same infrastructure and GitOps ownership model.
After handover
- A repeatable AWS bootstrap order with clear Terraform state boundaries.
- One GitOps structure for stage and production, with environment-specific destinations.
- Stable controller capacity separated from elastic application capacity.
- Stage cost decisions that do not erase the production architecture path.
- Managed production data, backup, encryption, and deletion safeguards in code.
- Secret values retained in AWS while workloads receive only the approved Kubernetes projection.
Ownership after handover
The AWS foundations, GitOps desired state, and environment decisions stay with the team.
Terraform, Argo CD applications, workload manifests, secret references, bootstrap notes, and recovery boundaries remain in the client-owned delivery model.
Schedule a platform call