Skip to content

AWS Infrastructure and IaC Decision

Purpose

This document answers two infrastructure questions that affect the ECS migration:

  1. Should the application be isolated in its own VPC?
  2. Should Terraform be used to build and manage the infrastructure?

Decision Summary

  • Use separate AWS accounts for staging and production.
  • Use a dedicated VPC for this project inside each account.
  • Use Terraform for the AWS infrastructure unless the organisation already has a stronger standard that should take precedence.
  • Keep staging and production separate at the account level, and keep this project isolated in its own VPC within each account.
  • Use subnets to isolate tiers inside each VPC.
  • Use IAM Identity Center for human access into AWS accounts.
  • Use IAM roles and policies for workloads, task roles, and service access.

Account Boundary

Production Account

  • AWS account ID: 951665295205
  • Purpose: production workloads and production data plane

Staging Account

  • AWS account ID: 802732539686
  • Purpose: staging validation and pre-production testing
  • Note: this is a shared staging account, so do not assume it maps to a single VPC or a single project.

Boundary Rule

Treat the account boundary as the primary isolation boundary.

VPCs then provide network isolation within each account.

Access Model

Human Access

Use IAM Identity Center for console and CLI access by engineers and operators.

That should be the primary mechanism for:

  • AWS account access
  • permission sets
  • role assumption into staging and production
  • onboarding and offboarding users

Workload Access

Use IAM roles and policies for:

  • ECS task roles
  • ECS execution roles
  • application access to AWS services
  • access to S3, Secrets Manager, Parameter Store, CloudWatch, and similar services

VPC Decision

Recommendation

Yes, isolate this project into its own VPC inside each AWS account, with staging and production separated by account.

That means:

  • one staging account and one project VPC in staging
  • one production account and one project VPC in production

Do not place staging and production workloads in the same account or the same VPC. Do not share this project's VPC with unrelated workloads.

Why

AWS guidance is explicit that VPCs are a logically isolated network boundary and that separate VPCs are appropriate for isolating infrastructure by workload or organizational entity. AWS also recommends using private subnets for resources that should not be accessed directly from the internet, and using subnets to isolate tiers within a single VPC.

For this migration, the cleanest split is:

  • separate AWS accounts for staging and production
  • separate VPCs for this project within those accounts
  • separate public and private subnets inside each VPC

That gives us:

  • better blast-radius control
  • simpler security group rules
  • clearer staging/production parity
  • less risk of accidental cross-environment traffic

What Not to Do

  • Do not share a single VPC between staging and production.
  • Do not use public subnets for database or Redis services.
  • Do not treat VPC isolation as a substitute for account isolation.

Network Layout

  • public subnets for ALB
  • private subnets for ECS tasks
  • restricted private access for the database host
  • private access for Redis
  • dedicated to this project within the shared staging account
  • public subnets for ALB
  • private subnets for ECS tasks
  • private subnets for the Patroni cluster nodes
  • private access for AWS Redis
  • dedicated to this project within the production account

Cross-Environment Connectivity

Do not create direct network peering between staging and production unless there is a very specific operational need.

Keep the environments independent.

Terraform Decision

Recommendation

Yes, use Terraform for the infrastructure unless the organisation has already standardised on another infrastructure-as-code tool for AWS.

Why Terraform Fits Here

Terraform is designed to build, change, and version infrastructure safely and efficiently. It supports a workflow where infrastructure is defined in code, planned before changes are applied, and then applied with approval. Terraform also manages AWS resources through the AWS provider.

For this migration, Terraform is a good fit because we need to manage:

  • VPCs and subnets
  • security groups
  • ECS clusters and services
  • ALBs and target groups
  • IAM roles and policies for workloads
  • Route 53 records
  • Secrets Manager and Parameter Store
  • CloudWatch log groups and alarms
  • RDS or EC2-based database hosts
  • Redis-managed service configuration

Why Terraform May Feel Scary

That reaction is normal. Terraform is powerful enough to change large parts of the environment, so mistakes can have wide impact.

The safe way to use it is to:

  • start with a small module set
  • review plans before apply
  • separate staging and production state
  • keep modules simple
  • avoid clever abstractions early

What Terraform Should Manage

Use Terraform for:

  • network resources
  • IAM Identity Center permission sets and assignments, if the organisation manages them through Terraform
  • IAM roles and policies for workloads
  • ECS
  • load balancing
  • DNS
  • secrets and parameters
  • logging and alarms

What Terraform Should Not Rush

Do not try to model every operational concern on day one.

Avoid over-abstracting:

  • module nesting
  • shared mega-modules
  • environment-agnostic templates that hide too much

Practical Implementation Pattern

Suggested Repository Layout

  • one root module per environment
  • shared modules for reusable infrastructure pieces
  • separate state for staging and production

Example shape:

infra/
  modules/
    ecs-service/
    alb/
    vpc/
    iam/
    rds/
    redis/
  envs/
    staging/
    prod/

If the staging account hosts other projects, keep this project's VPC and Terraform state separate from theirs. See 09 AWS Terraform State Ownership and Project Layout for the explicit state boundary.

State Management

Use separate state for staging and production.

That prevents a staging change from affecting production state management and keeps plan/apply operations easier to reason about.

Rollout Strategy

Start with:

  1. VPC and subnets
  2. security groups
  3. validate existing IAM Identity Center access paths
  4. ECS cluster
  5. ALB
  6. logs and alarms
  7. secrets and parameters
  8. database and Redis wiring

Decision Rationale

Why This Is the Right Boundary

  • ECS tasks already get their own ENIs in Fargate.
  • Subnets and security groups are the right place to isolate tiers.
  • Separate VPCs are the right boundary for environment isolation.
  • Terraform is a standard way to make that structure repeatable.

Open Points

Org Standard Check

If the organisation already uses a different IaC standard for AWS, that standard should win over Terraform for consistency reasons.

Database Implementation Detail

We still need to decide whether the staging database is:

  • a managed single-AZ PostgreSQL instance
  • or a single EC2-hosted PostgreSQL instance

The VPC decision does not depend on that choice.