Plan your deployment — CHT on AWS
2 min read
The decisions the client makes before deployment. Three of them are independent axes — topology, network access, and data hosting — plus how DEV and PRD are segregated.
Choice 1 — Account topology
Option | What it means | Choose when |
|---|---|---|
Standalone | Single account, no separate network hub | POC / dev only |
Hub-and-spoke | Connectivity + workload accounts | Production baseline (recommended) |
Hub-and-spoke + shared services | Adds a shared-services account | Multiple workloads sharing ECR / Route 53 / logging |
Choice 2 — Network access model
Option | Ingress | Choose when |
|---|---|---|
Internal | Direct Connect → Transit Gateway → internal ALB | Users reach the app over private connectivity (recommended) |
CloudFront | Public ALB + AWS WAF | Public access is required |
Dual | Both paths | Mixed internal + external audiences |
Choice 3 — Data hosting model
Chosen per service; PaaS lowers operational burden, cloud-native maximizes portability and data locality.
Service | PaaS | Cloud-native |
|---|---|---|
Relational DB | Aurora PostgreSQL | CloudNativePG on EKS |
Cache | ElastiCache for Redis | Redis on EKS |
Search / vector | OpenSearch Service | Qdrant + ElasticSearch on EKS |
Environment segregation (DEV / PRD)
Segregation is independent of the network topology above — it can be layered on any topology. Three models sit on a spectrum:
Criterion | Logical (shared) | Hybrid | Physical (isolated) |
|---|---|---|---|
AWS account | Single | Shared or split | Separate per env |
EKS cluster | One, namespaces | One or split | Separate per env |
VPC / network | Shared VPC | Shared VPC, separate subnets | Separate VPC per env |
Data services | Shared instance, separate DBs | Separate instances | Separate instances + accounts |
KMS | Shared scoped CMK | Per-env CMK | Per-account CMK |
Blast radius / cost / overhead | Highest / lowest / lowest | Medium | Lowest / highest / highest |
Account patterns
One account — DEV+PRD share one workload account (namespace/RBAC separation). Maps to standalone. Pilots only.
Two accounts — DEV and PRD in separate accounts sharing the connectivity account. SCPs enforce the PRD boundary.
Three accounts — DEV, PRD, and shared/connectivity. Strongest isolation; matches the reference topology.
Recommendation: the two- or three-account (hybrid → physical) pattern for most clients — aligns with the hub-and-spoke reference, enforces the PRD boundary via SCPs, keeps blast radius low, and stays operationally manageable. Reserve single-account logical for pilots.
Identity note
The application IdP (Zitadel) and cloud IdP (IAM Identity Center) are distinct layers. Decide whether a single Zitadel instance serves both environments or each gets its own — this affects user/tenant mapping and is decided alongside the account pattern.