Reference Architecture: Enterprise-Ready SaaS on AWS

Illustrative scenario. A representative engagement shape, not a client deployment. Design and rationale are real and reusable; the company is not. Grounded in the AWS Well-Architected Framework and AWS multi-account guidance.

1. Scenario and constraints

A Series A B2B SaaS company, roughly 40 engineers, runs a containerizable web application and a PostgreSQL database. Everything — production, staging, and one-off experiments — lives in a single AWS account and a single VPC, provisioned by hand in the console over two years.

Enterprise deals are now on the table, and each one stalls at the same two gates: a SOC 2 Type II report, and a contractual 99.9% uptime SLA.

The "no platform team" line matters as much as the SLA. Forty engineers who have only ever used the console will not absorb a Kubernetes control plane and a hand-rolled Terraform monorepo at the same time. The design has to be operable by the team that exists.

2. Account topology

The move from one account to many is the foundational decision, and it is what most directly unblocks SOC 2. AWS gives you the account as the hardest security and billing boundary it has, so environments and trust domains become separate accounts, governed centrally through AWS Organizations and provisioned with AWS Control Tower. This follows AWS's own multi-account guidance.

Seven accounts, not one per service. The split is by trust boundary and environment, which is what an auditor reasons about and what contains a blast radius. Guardrails are applied once at the OU level as Service Control Policies — deny leaving the approved regions, deny disabling CloudTrail, deny public S3 — so a policy is inherited by every account rather than reapplied by hand.

The log-archive account is the linchpin for SOC 2: the first thing a serious incident touches is the audit trail, and logs that live in the account being investigated are evidence you may not be able to trust. Here no workload role can reach it.

3. Tagging and naming

AWS does not impose a naming scheme, so one is defined and then enforced by AWS Config rules and SCPs, not by convention. A tagging standard that relies on discipline decays; one that fails a Config rule does not.

<org>-<workload>-<environment>-<region>-<resource>

Every resource carries a mandatory tag set, following AWS tagging best practices: Environment, Owner, CostCenter, DataClassification, and ManagedBy:terraform. CostCenter turns cost allocation into a report rather than an investigation; DataClassification is what lets a reviewer find every resource that touches customer data in one query.

4. Network design

One VPC per workload account, connected through a Transit Gateway in the network account — the AWS counterpart to a hub-and-spoke. Region us-east-1, spanning two Availability Zones for the 99.9% target.

Non-overlapping ranges assigned from a plan, because Transit Gateway will not route between two VPCs with overlapping CIDRs, and re-addressing a live VPC is a migration, not an edit.

The data subnets have no route to a NAT gateway or the internet in either direction. The database is reachable only from the app tier, inside the VPC.

5. Design decisions

6. Resource inventory

db.r6g is deliberate: Graviton (ARM) instances run the same PostgreSQL at a lower price than the equivalent Intel class, and the database is the largest steady-state line item.

7. Identity and access

• IAM Identity Center federates SSO into every account; there are no standing IAM users
• Human access is role assumption, time-bound, with production behind an elevated permission set that is granted per-session, not held
• Workload access is ECS task roles — each service assumes exactly the permissions it needs, and reads secrets at runtime
• CI/CD authenticates by OIDC federation (see the Terraform section) — no AWS keys are stored in the pipeline
• Cross-account read for auditors terminates in the audit account, which can see everything and change nothing

8. Resilience: meeting the SLA

Availability is designed at the Availability Zone level. Full multi-Region active-active is deliberately not in the baseline — it roughly doubles cost and complexity, and 99.9% does not require it. The threshold where that changes is in section 11.

9. Cost: what dominates and what moves it

Budgets and anomaly alerts are provisioned by the same Terraform that creates the resources, so cost is a designed property rather than a monthly surprise.

10. Delivery: Terraform

The current environment is entirely click-ops, so the highest-leverage change is making every resource Terraform-managed. This is also a SOC 2 control in its own right: every infrastructure change arrives with an author, a reviewer, and a diff.

State. Remote state in S3 with DynamoDB locking, in the shared-services account, one state file per account and environment. A single monolithic state is a single blast radius — a bad apply against prod should be unable to touch staging, and separate state guarantees it.

Structure. Reusable child modules (network, ecs-service, rds, observability) composed by thin per-environment root modules. Staging and prod call the same modules with different variables, so "it worked in staging" is a meaningful statement.

Directory-per-environment, not workspaces. Each environment is its own directory with its own backend. Workspaces share a backend and a codebase and make it far too easy to run an apply against the wrong one; a directory boundary is visible in the path.

CI/CD. GitHub Actions authenticating by OIDC federation — no long-lived AWS keys anywhere. terraform plan runs on every pull request and the plan is posted as a comment; apply runs on merge, gated behind an environment approval for production.

Policy as code, before apply. Every plan is scanned against policy rules so a public bucket or an unencrypted volume fails the pull request rather than reaching an account — the pattern behind our Infrastructure Policy Check API.

Drift detection. A scheduled plan surfaces any change made in the console out of band. Click-ops is the disease being cured here, so detecting its return is part of the cure.

For the deeper Terraform-versus-alternatives argument, see our post on Terraform vs Bicep.

11. What changes if

12. What we deliver

• This topology as reviewed Terraform, structured as reusable modules and per-environment roots, parameterised to your constraints
• The multi-account Organization and Control Tower guardrails, with SCPs applied at the OU level
• A CI/CD pipeline with OIDC, plan-on-PR, policy scanning, and drift detection
• The evidence a SOC 2 auditor asks for — centralized immutable logs, continuous config monitoring, and a change history — produced as a byproduct of the pipeline rather than assembled by hand
• A cost baseline with budgets and anomaly alerts deployed alongside the infrastructure