Skip to content

AWS Staging Terraform Resource Checklist

Purpose

This document lists the concrete AWS resources Terraform should create for the staging build.

It is intentionally practical: if Terraform can build these resources in the staging account, we can validate the ECS migration without needing the full production picture yet.

Core Staging Resources

Terraform should create:

  • a dedicated staging VPC for this project
  • public subnets for the load balancer
  • private subnets for ECS tasks
  • route tables and gateways
  • security groups
  • ECR repositories for each image
  • ECS cluster and service definitions
  • Application Load Balancer and target groups
  • CloudWatch log groups
  • Secrets Manager entries
  • Parameter Store entries
  • EFS resources for Anisette persistence
  • the staging database EC2 host
  • the staging Valkey service on that host
  • the private Anisette ECS service

Staging Data Services

Database

Create the staging PostgreSQL target that supports the application schema and required extensions.

The exact platform can be decided inside Terraform based on what the staging account can support and what is simplest operationally. For staging, it is acceptable for the database to be created only in the staging account and not mirrored outside it.

Valkey

Use a self-hosted Valkey service on the staging database host.

Terraform should create the resources needed for private access, credentials, and service configuration. This is the explicit staging branch, not a managed MemoryDB deployment.

Anisette

Terraform should also create:

  • private service discovery
  • an EFS file system
  • an EFS access point
  • mount targets in the private subnets
  • task role permissions for the EFS mount

ECS Delivery Targets

Terraform should create ECS service resources for the deployable runtime components that staging needs to prove:

  • API
  • frontend
  • admin panel
  • background workers
  • private Anisette service with persistent state

Network Outputs

The staging Terraform stack should output the values the application deployment needs, including:

  • VPC ID
  • subnet IDs
  • security group IDs
  • ALB DNS name
  • internal database hostname or connection target
  • Valkey endpoint or equivalent cache endpoint

Build Order

Use this order for staging:

  1. backend state
  2. VPC and routing
  3. security groups
  4. ECR
  5. ECS cluster
  6. ALB
  7. database service
  8. Valkey
  9. ECS services
  10. smoke tests

What This Checklist Excludes

This document does not define the production rebuild details.

It also does not define the peering model to the production database VPC, because staging is the current focus.