Web Application
A containerized web application running on Amazon EKS, released through GitOps, hardened before the pen test rather than after it.
What it is
The Web Application Blueprint is a production architecture for a containerized web application, delivered as three repositories — infrastructure, application code and GitOps configuration — and deployed into the workload accounts of your BuiltForProd Baseline. It covers 17 AWS services and 8 Kubernetes components per stage, from the content delivery network in front of the single-page application to the database behind the API.
Teams usually reach for Kubernetes and then spend a quarter deciding how to autoscale it, how to get secrets into it, how to route traffic to it and how to promote a release through it. Those decisions are already made here, written down, and running.
The stack
14 modules, 16 units and 5 application workflows, deployed per stage.
| Layer | What is deployed |
|---|---|
| Compute | Amazon EKS with a managed node group, Karpenter for just-in-time capacity (often on Spot) and the Cluster Autoscaler. Production is sized at three nodes with a 128 vCPU ceiling and a horizontal pod autoscaler between 3 and 10 replicas. |
| Data | Amazon DocumentDB for the application database, three instances in production, and ElastiCache for Redis for caching and sessions. The DocumentDB password is never written to state. |
| Edge and ingress | The AWS Load Balancer Controller provisions an HTTPS-only Application Load Balancer behind WAF, with certificates from ACM. The React single-page application is served by CloudFront from a private S3 bucket. |
| Delivery | ArgoCD GitOps against a Helm chart, with ExternalDNS managing records and Fluent Bit shipping container logs. Images are built once and stored in ECR with immutable tags. |
| Configuration | External Secrets Operator pulls configuration and credentials from Parameter Store into the cluster, so no secret is committed to the chart or baked into an image. |
| Application | A Flask API on Python 3.12 and a React front end ship as working reference code, so the whole path from commit to production request is visible on day one. |
Build once, promote by approval
The same image that was tested is the image that runs in production. It is built once, tagged immutably in ECR, and moved forward by approval rather than rebuilt per environment.
That single decision removes an entire category of incident: the one where staging and production differ because they were built from the same branch at different times.
If deployment requires a hero, it isn’t automated.
-
Merge to main
The image is built, scanned by Trivy and deployed to dev automatically.
-
Cut a release
The same image is promoted to staging. Nothing is rebuilt.
-
Approve for production
Required reviewers approve, then the production ArgoCD application is synced manually. The artifact is identical to the one staging ran.
Hardened by default
Network
- Default-deny NetworkPolicy; traffic is allowed deliberately, not by omission
- Private EKS endpoint; the load balancer is HTTPS only and sits behind WAF
- IMDSv2 enforced on every node
Workload
- Non-root containers with read-only root filesystems, seccomp profiles and all capabilities dropped
- One EKS Pod Identity role per workload — no shared node role
- Immutable ECR tags, with a Trivy gate on high and critical findings
Data
- Encryption at rest and in transit throughout
- The DocumentDB password is written through write-only arguments and never lands in state
- Secrets reach pods through External Secrets Operator, not through the chart
Operations
- Fluent Bit ships container logs centrally; production keeps 365 days
- Karpenter and the horizontal pod autoscaler size capacity to demand
- Runbooks, troubleshooting entries and a golden-path guide for adding the next service
When teams choose this Blueprint
| Situation | What it changes |
|---|---|
| The team wants Kubernetes but has no production-grade cluster design | A running, hardened EKS platform with GitOps in your own accounts, and a sample app showing the whole path. |
| Releases are manual and everyone is nervous on Fridays | Promotion becomes a routine, reviewable action against an artifact that has already run in staging. |
| A launch or campaign is coming | Capacity follows demand by design, decided before the spike instead of during it. |
| A pen test or customer review targets your containers | The hardening findings are prevented up front, with the code to show the reviewer. |
| Developers wait weeks on the platform team for every new service | A golden path new services follow, so the platform team reviews instead of builds. |
Questions about this Blueprint
What is the Web Application Blueprint?
The Web Application Blueprint is a production architecture for a containerized web application, delivered as three repositories — infrastructure, application code and GitOps configuration — and deployed into the workload accounts of your BuiltForProd Baseline. It runs on Amazon EKS with ArgoCD-based GitOps.
How does a release reach production?
The image is built once and promoted by approval. Merging to the main branch deploys automatically to dev, cutting a release promotes the same immutable image to staging, and production requires a manual approval and a manual ArgoCD sync by required reviewers. What runs in production is the artifact that was tested.
Does it work with our application instead of the sample?
Yes. The sample Flask API and React front end exist so the whole path is visible, and they are meant to be replaced by your application. The golden-path guides cover adding a new service: eight steps in the infrastructure repository and nine in the code repository, with a table of the pitfalls teams hit.
How is the cluster hardened?
Default-deny network policies, non-root containers with read-only root filesystems, seccomp profiles and all Linux capabilities dropped, one Pod Identity role per workload, IMDSv2 enforced, a private EKS endpoint, encryption in transit and at rest, and a Trivy gate that blocks high and critical findings.
Can we run more than one application on it?
Yes. The cluster, the ingress path and the GitOps repository are designed for more than one workload, each with its own Pod Identity role and its own network policy. The golden path exists so a second and third service are added the same way as the first.
What does it need from the Baseline?
The workload accounts, the spoke VPC and subnets, the hosted zones, the artifact registry and the pipeline identity all come from the Baseline, and the Blueprint reads them from Parameter Store. A Baseline has to be in place before the Blueprint is deployed.
See the whole catalog, the Baseline it deploys into, or the Standard it is built to. Secrets for this workload are handled by the Secrets Blueprint.
Find out what production would take.
Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.