Dev vs Staging vs Production in AWS: Differences, Setup, and Best Practices

Dev, staging, and production are three environments that each serve a different role in your release process. Dev is where developers build and test individual changes. Staging is where those changes run together against production-like conditions. Production is where real users are. The safest AWS setup puts each environment in a separate account under AWS Organizations, giving you clean per-environment billing and isolation that VPC separation alone cannot provide.

What dev, staging, and production are#

Most teams run three environments. Here is what each one is for:

Dev is for individual developers testing their work. A developer building a new feature deploys it to dev to verify it works end-to-end before opening a pull request. Dev breaks often, and that is fine. The cost of a broken dev environment is one developer’s afternoon.

Staging is the final gate before production. It runs the same code that is about to go live against production-like data volumes and infrastructure. Staging catches the bugs that dev misses because dev is too small or too simplified to surface them.

Production serves real users. Failures here mean lost revenue, data incidents, or damaged user trust. Every change to production should have already passed through staging.

How the environments work together#

Code moves in one direction: dev to staging to production. This is called the promotion flow.

A developer finishes a feature, tests it in dev, and opens a pull request. Automated tests run. When the PR merges, the CI/CD pipeline builds the artifact and deploys it to staging automatically. See Managing Environments in CI/CD Pipelines for how to structure CodePipeline promotion stages with cross-account deployment roles.

In staging, the full application runs together against realistic conditions. QA runs final checks. For significant releases, a human approval gate in CodePipeline requires an authorized person to approve before the deployment proceeds to production.

Production deployments typically use blue-green or canary strategies to reduce risk. The pipeline handles the rollout. No developer logs into the production console to run commands manually.

Recommended AWS setup#

The recommended pattern is one AWS account per environment, grouped under AWS Organizations.

AWS Organization
├── Management Account (billing, Organizations, IAM Identity Center)
├── Dev Account        (123456789001)
├── Staging Account    (123456789002)
├── Production Account (123456789003)
└── Tools Account      (123456789004)  ← CI/CD pipelines live here

Account-level separation provides guarantees that VPC separation cannot. A dev IAM role literally cannot call production AWS APIs because it exists in a completely different account.

Access control: Set up AWS IAM Identity Center (formerly SSO) so developers sign in once and get environment-appropriate permissions automatically:

• Dev account: full developer access
• Staging account: read-only (writes through the pipeline only)
• Production account: read-only or no access (all changes through the pipeline)

Apply the principle of least privilege: give each person the minimum access they need in each environment.

Guardrails: Apply Service Control Policies at the OU level to enforce environment-specific limits. A production SCP can require MFA for all API calls, prevent CloudTrail deletion, and block disabling of GuardDuty. These guardrails apply to everyone in the account, including administrators, and cannot be bypassed by IAM policies.

Define all of this in Infrastructure as Code from the start. Manual account configuration drifts quickly as teams grow.

How staging should match production#

“Staging mirrors production” means the same services in the same architectural pattern, not the same instance sizes. If production uses an ALB, ECS Fargate with auto-scaling, RDS Multi-AZ, and ElastiCache, staging needs all of those same services. Just smaller.

If production uses PostgreSQL, every environment must use PostgreSQL. Not SQLite. If production auto-scales, staging needs auto-scaling configured even if it rarely triggers. These architectural gaps are where “works in staging, broken in prod” bugs hide.

Use separate Terraform state files per environment so dev, staging, and production infrastructure changes stay independent.

Managing data safely across environments#

Dev should always use synthetic data: records generated for testing that contain no real user information. Integration tests seed the database with known records and clean up after themselves.

Staging requires production-like data to be useful, but copying raw production data into staging carries compliance risk under GDPR, CCPA, HIPAA, and similar regulations.

The recommended approach: restore a production snapshot to staging, then run a masking script.

# 1. Snapshot production
aws rds create-db-snapshot \
  --db-instance-identifier prod-postgres \
  --db-snapshot-identifier staging-refresh-$(date +%Y%m%d)

aws rds wait db-snapshot-completed \
  --db-snapshot-identifier staging-refresh-$(date +%Y%m%d)

# 2. Restore to staging
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier staging-postgres-temp \
  --db-snapshot-identifier staging-refresh-$(date +%Y%m%d)

# 3. Mask PII before granting access
psql $STAGING_DB_URL -f mask-pii.sql

The masking script replaces real emails with user_123@example.com, real names with generic values, phone numbers with 555-0100, and payment data with test card numbers. The data structure and volume stay realistic; the actual values are not real user data.

Store environment credentials separately. Use Secrets Manager or Parameter Store per environment, injected through the pipeline. Never hardcode credentials or share secrets across environments.

Managing dev cost#

Dev environments run 24/7 but are only used during business hours. Automated shutdown schedules typically cut dev costs by 60–70%.

Use Amazon EventBridge Scheduler to stop dev resources outside business hours:

# Stop dev RDS at 8pm UTC on weekdays
aws scheduler create-schedule \
  --name stop-dev-rds \
  --schedule-expression "cron(0 20 ? * MON-FRI *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:rds:stopDBInstance",
    "RoleArn": "arn:aws:iam::ACCOUNT:role/SchedulerRole",
    "Input": "{\"DbInstanceIdentifier\": \"dev-postgres\"}"
  }'

For ECS Fargate services, scale the desired count to 0. For EC2 workloads, stop the instances. Define these schedules in Terraform alongside the resources they manage, not manually in the console.

Tag every resource with an Environment tag and use Cost Explorer reports to see how much dev, staging, and production each cost per month:

tags = {
  Environment = var.environment  # "dev", "staging", or "production"
  Application = "my-app"
  ManagedBy   = "terraform"
  Team        = "platform"
}

Tag-based IAM conditions can also prevent a dev pipeline role from accidentally deploying to a resource tagged as production.

When to use this setup#

Starting out: A small team prototyping or running a low-traffic product can begin with two environments in the same account, separated by naming conventions and IAM policies. This is simpler to manage and costs less. It works until it doesn’t.

When separate accounts become essential:

• You hire a second or third developer and access control becomes important
• A security audit or compliance review requires account-level isolation (SOC 2, ISO 27001, HIPAA)
• A staging incident nearly touched production data
• Your cloud bill is large enough that per-environment cost visibility matters
• Your team is large enough that someone could accidentally misconfigure production

For most teams building real products, the one-time cost of setting up separate accounts is worth it. Account setup takes a few hours. Cleaning up an environment bleed incident takes much longer.

See Securing Production Systems for production hardening patterns that complement the account-separation model.

Staging vs test vs UAT#

These terms are often used interchangeably, but they refer to distinct phases:

In practice, many teams run UAT on staging. That is fine as long as staging is locked and stable during UAT, not actively receiving deployments from other developers at the same time.

Common mistakes#

Last verified: 25 April 2026 · Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.