Container platform
ECS on Fargate.
Why. Least operational overhead for teams that do not need Kubernetes features.
Trade-off. Less ecosystem tooling than EKS and higher unit price than well-packed EC2 at steady high load.
Cloud platforms · AWS
Three-tier web application on ALB, ECS Fargate and Aurora
The workhorse for line-of-business web apps: public load balancer, containers across three Availability Zones, a private Aurora PostgreSQL cluster, ElastiCache for sessions and S3 for files.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- SA ISMF and ACSC ISM alignment
- Australian Privacy Principles (APP 11)
- Sydney (ap-southeast-2)
Architecture
- People and clients
- Network and edge
- Compute and containers
- Databases and data
- Object and file storage
- Security and identity
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Users reach CloudFront, which terminates TLS and applies WAF managed rules and rate limits.
CloudFront forwards to the ALB over HTTPS with a custom header that the ALB listener rule requires, and the ALB security group only allows the CloudFront managed prefix list.
The ALB distributes to healthy tasks in all three Availability Zones, with connection draining on deployments.
The application reads and writes Aurora through RDS Proxy or a pooled connection over TLS. Credentials come from Secrets Manager with rotation.
Sessions and hot reads use ElastiCache so tasks stay stateless and can be replaced at any time.
Image pulls, logs, secrets and KMS calls go through VPC endpoints, so the tasks need no route to the internet for AWS services.
Uploads go straight from the browser to S3 with presigned URLs, then are virus-scanned before being made available to the app.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Application Load Balancer | Layer 7 routing, health checks, TLS and WAF association. | Path routing and native ECS integration with slow-start and draining. |
| Amazon ECS on Fargate | Runs containers without managing hosts, one task per replica with a task role. | No node patching and per-task isolation. EKS is preferred only when Kubernetes is a requirement. |
| Amazon Aurora PostgreSQL | Multi-AZ relational database with shared storage, fast failover and up to 15 readers. | Failover is typically faster than classic Multi-AZ RDS and storage grows automatically. |
| Amazon ElastiCache (Valkey or Redis OSS) | In-memory cache for sessions and read-heavy lookups. | Keeps the app tier stateless and protects the database from hot keys. |
| Amazon S3 | Uploads and generated documents, versioned and encrypted. | Takes file traffic off the app and the database. |
| Amazon ECR | Private image registry with scan on push. | Immutable tags and vulnerability findings in the pipeline. |
| VPC endpoints | Private access to S3, ECR, CloudWatch Logs, KMS and Secrets Manager. | Removes NAT cost and exposure for AWS traffic. |
| AWS Backup | Policy-based backups with cross-account copy. | Gives a backup the application account cannot delete. |
Design decisions and trade-offs
Database
Aurora PostgreSQL with a writer and two readers across AZs.
Why. Fast failover, read scaling and managed backups.
Trade-off. Aurora I/O pricing needs checking against Aurora I/O-Optimized for heavy workloads, and it is not portable to another cloud.
Connection management
RDS Proxy or in-app pooling.
Why. Prevents connection storms during scaling or failover.
Trade-off. An extra component and cost.
Egress
Endpoints first, NAT only for third-party APIs.
Why. Reduces cost and blast radius.
Trade-off. More endpoints to manage in Terraform.
Well-architected pillars
Security
Three subnet tiers, security-group-to-security-group rules, no public IPs on tasks, WAF, KMS and Secrets Manager rotation.
Reliability
Three AZs for tasks and database, health-checked rollouts with circuit breaker, automated backups and tested restores.
Performance
Autoscaling on request count and CPU, read replicas for reporting, cache for hot reads, CloudFront for static assets.
Cost optimisation
Fargate vCPU and memory, Aurora instances and I/O, NAT and data transfer. Savings Plans cover the steady baseline.
Operational excellence
Blue/green deployments with CodeDeploy or ECS rolling updates, Terraform for the platform, runbooks for failover and restore.
Sustainability
Right-size tasks, scale in at night for non-production, use Graviton, and stop dev databases out of hours.
Network, identity and data
Networking
A /16 VPC with three tiers per AZ. Public subnets hold only the ALB and NAT. App subnets route to NAT or endpoints. Data subnets have no internet route at all. Flow Logs go to the central log account.
Identity and least privilege
Task execution role (pull images, write logs) is separate from the task role (application permissions). Database access uses IAM database authentication or Secrets Manager rotation. Administrators use Identity Center with break-glass roles.
Data and encryption
Classify per table and column. Aurora, ElastiCache and S3 encrypted with customer-managed KMS keys, TLS enforced everywhere, and snapshots shared only to the backup account.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Application control | Immutable container images from a scanned registry, only the pipeline can deploy. Essential Eight application control approach for cloud workloads. |
| Patch applications and operating systems | Rebuild images on a schedule and on critical advisories, Fargate platform patched by AWS. Essential Eight. |
| Multi-factor authentication | MFA for administrators and the application's users. Essential Eight. |
| Regular backups | AWS Backup with cross-account copy and restore tests. Essential Eight. |
| Privacy and security of personal information | Encryption, access logging and least privilege support APP 11 expectations. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOUnder a few minutes for AZ failure; 1 to 4 hours for a Region rebuild from IaC and backups
- Target RPONear zero within the Region; minutes for a cross-Region replica
- Scaling and limitsAurora writer is a single node, so write scaling is vertical. Beyond that consider sharding or a different store.
| Failure mode | Mitigation |
|---|---|
| AZ failure | Tasks and the database span three AZs. ALB removes unhealthy targets. Aurora promotes a reader. |
| Bad release | Deployment circuit breaker rolls back automatically. Blue/green with traffic shifting for riskier changes. |
| Connection exhaustion | RDS Proxy, pool limits sized to the max task count, alarms on database connections. |
| Region failure | Pilot light or warm standby pattern from the DR page, with a cross-Region Aurora replica if the RTO demands it. |
Observability and runbooks
- Container Insights, ALB target response time and 5xx, Aurora performance insights and slow query log.
- Alarms on error budget burn rather than raw CPU.
- Trace sampling with OpenTelemetry and correlation IDs from the edge.
- Runbooks: failover test, restore from snapshot into a new cluster, rotate credentials.
Cost drivers and levers
Fargate compute, Aurora instance hours and I/O, NAT data processing, CloudFront and WAF.
- Compute Savings Plans for the baseline.
- Replace NAT traffic with endpoints.
- Aurora Serverless v2 for spiky non-production.
- Schedule down non-production overnight.
Implementation and fit
Phased approach
- Foundation: VPC, endpoints, KMS and logging in the landing zone.
- Platform: ECS cluster, ALB, Aurora and pipeline with a hello-world service.
- Migrate or build the application and run load and failover tests.
- Harden: WAF tuning, backup restores, penetration test, then go live.
Anti-patterns to avoid
- Tasks with public IPs.
- One shared security group for everything.
- Database in a public subnet for convenience.
- Storing sessions or uploads on the container disk.
When to use it
- Line-of-business and citizen-facing web apps with relational data.
- Teams standardising on containers.
- Applications needing predictable latency.
When not to
- Tiny sites (use the static pattern).
- Workloads that need Kubernetes operators or custom networking.
- Very spiky traffic with long idle periods (consider serverless).
More in cloud platforms
Azure
Web application on Azure Front Door, Container Apps and Azure SQL
The Azure equivalent of the three-tier pattern: Front Door with WAF, Container Apps or App Service on a private network, Azure SQL, Entra ID for identity and Key Vault for secrets.
AWS and Azure
Multi-account landing zone: AWS Organizations and Azure management groups
The foundation every other pattern sits on: separate accounts or subscriptions for blast-radius control, preventive guardrails, central identity, central logging and a security account that workloads cannot switch off.
AWS and Azure
CI/CD and infrastructure as code with GitHub Actions, Terraform, ECR and blue/green
A delivery pipeline with no long-lived credentials: pull requests plan, merges apply, images are scanned and signed, and releases shift traffic gradually with automatic rollback.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.