What you receive
You receive a working web application, front end and back end, deployed into your plat accounts on top of the AWS Baseline, together with the three Git repositories that define it, customized for your organization, and the documentation to run and change it. After handover your engineers own all of it.
How delivery works
The blueprint is sold with the Baseline in the full deployment tier, or on its own for customers who already run the Baseline. In both cases the BuiltForProd team deploys it. See blueprints for how the three blueprints fit together and purchasing and licensing for the terms.
The repositories
| Repository | You receive |
|---|---|
acme-aws-blueprint-webapp-infra | Fourteen OpenTofu modules, sixteen Terragrunt units, one stack template, a stack file per stage, guard scripts, and plan and apply workflows |
acme-aws-blueprint-webapp-gitops | The blueprint-app Helm chart with its eight templates, base values, per-stage values, and the image tag file each stage deploys |
acme-aws-blueprint-webapp-code | The Flask API and its tests, the React app, the Dockerfile, five GitHub Actions workflows and the shared action that opens deploy pull requests against the GitOps repository |
acme in the names is your namespace. Your domains, your GitHub organization and the account ids of your plat accounts are set in the code before deployment.
The running application
In each of dev, staging and prod:
- An EKS cluster with a managed node group, Karpenter, Cluster Autoscaler, the AWS Load Balancer Controller, ExternalDNS, the External Secrets Operator, Fluent Bit and ArgoCD.
- The API running as a Kubernetes Deployment, reachable at
blueprint-api.<stage domain>over HTTPS. - The single-page app at
blueprint-app.<stage domain>, served by CloudFront. - A DocumentDB cluster and a Redis replication group, encrypted, in private subnets.
- Wildcard certificates for the stage's public and internal domains.
- ArgoCD running inside each cluster, published on an internal load balancer at
argocd.<internal domain>and reachable over the VPN.
The delivery pipeline
- Pull requests to the code repository run lint, unit tests, a container build and an image vulnerability scan.
- A merge to
mainbuilds the image once and opens a deploy pull request for dev that merges itself. - A GitHub Release tags the same image with its version, deploys it to staging and deploys the front end to staging and, after approval, to prod.
- A manual workflow promotes a release to prod through a pull request that a person merges; ArgoCD in prod then waits for a manual sync.
- Pull requests to the infrastructure repository plan all three stages; a merge applies them.
The documentation
This documentation set: the architecture, every unit and module, the Kubernetes platform, the GitOps model, the application, the pipelines, security, observability, performance tuning, developer guides, the API reference and how-to guides for day-2 work such as releasing, rolling back and scaling a stage.
What stays with the Baseline
The accounts, networks, identity, security services and the container registry come from the AWS Baseline. The blueprint reads what it needs from the Baseline and does not change it. The architecture overview shows how the two connect.