DevOps Infrastructure Sizing Guide: How to Plan Configurations for Dev, QA, UAT, Staging, Pre-Prod & Production

Introduction

Every digital transformation project starts with the same question from the solution architect:

"We'll have 1 frontend, 20 backend microservices, and 2 databases. What infrastructure do we need?"

And every DevOps architect knows this question is deceptively simple. The answer isn't just "pick some EC2 instances." It's a multi-dimensional decision involving:

• 6 environments with fundamentally different purposes (Dev, QA, UAT, Staging, Pre-Prod, Prod)
• Cost constraints that demand right-sizing without over-provisioning
• Security boundaries that get stricter as you move toward production
• Team dynamics — 50 developers need parallel workstreams without stepping on each other
• Compliance requirements (SOC2, GDPR) that dictate data handling and access controls
• Disaster recovery expectations that vary by environment criticality

This guide is the reference document you hand to your solution architect, your CTO, and your finance team.

---

The Scenario

Throughout this guide, we'll use a concrete project:

---

The DevOps Architect's Decision Framework

Before jumping into instance sizes, a DevOps architect evaluates these dimensions for each environment:

1. Purpose and Usage Pattern

Each environment exists for a specific reason. Understanding its purpose dictates everything else:

2. The Sizing Multiplier Principle

A practical framework that DevOps architects use:

Dev     = Prod × 0.15 (minimum viable for development)
QA      = Prod × 0.25 (enough to run test suites meaningfully)
UAT     = Prod × 0.20 (business users don't generate high load)
Staging = Prod × 0.50 (must simulate production patterns)
Pre-Prod = Prod × 1.0 (identical to Prod, runs intermittently)
Prod    = Baseline (fully sized for peak + 30% headroom)

This isn't a rigid formula — it's a starting point that gets refined based on actual usage data after the first 3 months.

3. Key Decision Inputs

The DevOps architect collects these inputs before sizing:

From the Solution Architect:

• Number of services and their communication patterns (sync vs async)
• Expected request/response sizes (affects memory and network)
• Stateful vs stateless services (affects storage and scaling approach)
• Background job requirements (batch processing, scheduled tasks)

From the Product Manager:

• Expected user growth curve (Year 1 → Year 3 projections)
• Peak traffic scenarios (Black Friday, campaign launches, seasonal patterns)
• Geographic distribution of users (single region vs multi-region)
• Data retention requirements (compliance-driven)

From the Development Team:

• Technology stack specifics (JVM memory requirements, Node.js event loop constraints)
• Build and test pipeline requirements (CI/CD compute needs)
• Local development patterns (do they need personal namespaces?)
• Third-party integrations (external API dependencies, message queues)

From Finance:

• Total infrastructure budget envelope
• CapEx vs OpEx preference
• Reserved instance commitment appetite (1-year vs 3-year)

---

Container Orchestration: EKS vs ECS Fargate Decision

Before sizing individual environments, the DevOps architect makes a fundamental platform decision.

Decision Matrix

Our Recommendation for This Scenario

For a 20-microservice digital transformation project with 50 developers:

• Dev and QA: ECS Fargate — developers focus on code, not cluster management. Fast iteration, no node scaling concerns.
• UAT through Production: EKS — the operational investment pays off at 20 services. Service mesh, advanced scheduling, namespace isolation per team, and cost optimization via reserved nodes.

Azure equivalent: AKS (Azure Kubernetes Service) for all environments. AKS has no control plane cost, making it viable even for Dev.

---

Environment-by-Environment Configuration

Environment 1: Development (Dev)

Philosophy: Fast feedback loops. Developers must deploy and test independently without waiting for shared resources. Cost-optimized, not performance-optimized.

Compute Configuration

Why These Specs for Dev

• 0.5 vCPU per service: Enough to start the JVM/Node process and handle a single developer's test requests. Not enough for concurrent users — that's intentional.
• Single-AZ: No reason to pay for cross-AZ redundancy when downtime does not affect customers.
• No auto-scaling: Developers do not generate traffic spikes. Fixed allocation is predictable and cheaper.
• Burstable instances (Azure B-series): Dev workloads are idle 80% of the time. Burstable credits give burst capacity when a developer actively tests.

Database Configuration (Dev)

Networking (Dev)

Dev Environment Special Considerations

Per-developer namespaces (optional): If budget allows, give each developer a namespace in a shared cluster. They can deploy their branch without conflicts. Cost: approximately 15% more compute.

Scheduled shutdown: Dev environment runs 8 AM to 8 PM on weekdays only. Saves 65% on compute costs.

Shared databases: All developers share one PostgreSQL and one MongoDB instance. Each developer gets their own schema/database within it.

Seed data automation: Script that loads consistent test data on environment refresh (weekly).

---

Environment 2: QA (Quality Assurance)

Philosophy: Reliability for automated pipelines. QA runs 500+ automated tests across 20 services simultaneously. The environment must handle parallel test execution without flakiness caused by resource starvation.

Compute Configuration

Why QA Needs More Than Dev

• 1 vCPU per service (2x Dev): Automated tests hit all 20 services simultaneously. Each service handles 10-50 concurrent test requests — enough to expose race conditions and concurrency bugs that 0.5 vCPU would mask.
• Dedicated test runner compute: Integration test suites (Selenium, Playwright, API tests) need their own compute so they do not compete with the services they are testing.
• Scale-to-zero between runs: QA is batch-oriented. Tests run for 30-45 minutes, then nothing for hours. Pay only for active test windows.

Database Configuration (QA)

QA Environment Special Considerations

Database reset between test runs: Every test suite execution starts with a known state. Use database snapshots (RDS) or containerized databases (Docker) that reset in seconds.

Parallel pipeline execution: 8 squads push code simultaneously. The QA environment must handle 3-4 concurrent pipeline runs without resource contention.

Test data management: Maintain 5-6 curated datasets covering happy paths, edge cases, error scenarios, and boundary conditions. Never use production data.

Artifact caching: Cache Docker images and dependencies aggressively. Build time directly impacts developer productivity when 50 people share the pipeline.

---

Environment 3: UAT (User Acceptance Testing)

Philosophy: Stability and predictability. Business stakeholders perform manual testing and demos here. It must feel production-like without production costs. No surprise outages during a demo to the VP.

Compute Configuration

Why UAT Gets Multi-AZ but Lower Compute

• Multi-AZ (2 zones): A UAT crash during a stakeholder demo destroys confidence. Multi-AZ prevents single-point failures from ruining a business-critical review session.
• Lower compute per service (0.5 vCPU): Business users generate minimal concurrent load (15 people clicking through flows). The compute is for stability, not throughput.
• EKS starts here: UAT is the first environment where we mirror production orchestration. This catches Kubernetes-specific issues before they reach production.

Database Configuration (UAT)

UAT Environment Special Considerations

Data masking pipeline: UAT needs realistic data volumes. Build an automated pipeline that copies production data structure with PII replaced (names become faker names, emails become hashed, phones randomized).

Change freeze windows: Before major demo sessions or sprint reviews, implement 24-hour deployment freezes to UAT.

Access control: Business stakeholders get read-only dashboard access plus application access. They cannot SSH, view logs, or access databases directly.

Scheduled availability: UAT runs 24/7 (unlike Dev) because stakeholders across time zones may test at any hour. But compute is right-sized low because concurrent usage is always minimal.

---

Environment 4: Staging

Philosophy: Production mirror at reduced scale. Performance testing, integration testing with external systems, and deployment rehearsals happen here. This is the last stop where engineers have full debugging access.

Compute Configuration

Why Staging Gets Production-Level Topology

• 3 AZs (same as Prod): Staging must validate that your pod anti-affinity rules, cross-AZ traffic patterns, and zone-failure handling work correctly. If Staging is 2 AZ and Prod is 3 AZ, you will miss topology-specific bugs.
• 2 replicas per service (Prod minimum): Tests Kubernetes rolling updates, pod disruption budgets, and load balancing behavior. Single-replica services mask deployment failures.
• Compute-optimized nodes (c5): Staging runs performance tests. CPU-bound workloads need consistent compute — burstable instances give misleading benchmarks.
• 50% of Prod scale: Enough to catch performance regressions without paying for full production capacity.

Database Configuration (Staging)

Staging Environment Special Considerations

External system integration: Staging connects to sandbox/UAT versions of third-party APIs (payment gateways, email providers, SMS services). Validate integration contracts here.

Performance test baseline: Run weekly load tests at 50% of expected Prod traffic. Track response time percentiles (p50, p95, p99) against SLO targets.

Deployment rehearsals: Every production deployment is first executed in Staging using the exact same CI/CD pipeline, Helm charts, and rollout strategy.

Data migration testing: Schema migrations tested against production-volume data (anonymized). A migration taking 2 seconds on Dev (50GB) might take 45 minutes on Prod (500GB).

Chaos engineering (optional): Kill pods, simulate network partitions, inject latency. Validate circuit breakers and retry logic.

---

Environment 5: Pre-Production (Pre-Prod)

Philosophy: Production-identical. Exists solely to validate that the exact production configuration works with the latest code. Runs intermittently (not 24/7) to control costs.

Compute Configuration

Why Pre-Prod Mirrors Production Exactly

• Configuration validation: The number one cause of "works in Staging, fails in Prod" is configuration drift. Pre-Prod eliminates this by being a 1:1 clone.
• Data migration rehearsal: Execute migrations on Pre-Prod with production-equivalent data volumes. Measure exact timing, validate rollback procedures.
• Disaster recovery drills: Practice full environment recovery from backups. Measure RTO and validate it meets your SLA.
• Security audit target: Penetration testing runs against Pre-Prod to avoid impacting real users.

Database Configuration (Pre-Prod)

Pre-Prod Environment Special Considerations

Runs on-demand, not 24/7: Pre-Prod is expensive. Run for release validation (2-3 days before release), DR drills (monthly), security audits (quarterly). Shutdown between activities saves 70-80%.

Infrastructure-as-Code parity: The Terraform/Bicep code that creates Pre-Prod MUST be the same code that creates Prod. Same modules, same variables.

Network parity: Same VPC CIDR scheme, same security group rules, same NACLs. Only difference is actual IP ranges and resource names.

No developer access by default: Access granted via just-in-time (AWS SSO time-boxed sessions, Azure PIM). Mimics production access patterns.

---

Environment 6: Production (Prod)

Philosophy: Reliability, performance, and security above all else. Every decision optimizes for uptime, response time, and data integrity. Cost is important but secondary to customer experience.

Compute Configuration

Per-Service Sizing Strategy (Production)

Not all 20 microservices need the same resources. Categorize them:

Database Configuration (Production)

Production Networking

Production Security Controls

Production Observability

---

CI/CD Infrastructure (Shared Across Environments)

The CI/CD pipeline itself needs dedicated compute — separate from application environments.

Pipeline Infrastructure

CI/CD Sizing for 50 Developers

---

Cost Estimation: The Complete Picture

Monthly Cost Summary (AWS)

Monthly Cost Summary (Azure)

Cost Optimization Strategies

Year-1 Total Cost Projection

---

Network Architecture Across Environments

Account/Subscription Strategy

DNS Strategy

Production:     api.yourapp.com          → Prod ALB/AppGW
Pre-Prod:       api.preprod.yourapp.com  → Pre-Prod ALB
Staging:        api.staging.yourapp.com  → Staging ALB
UAT:            api.uat.yourapp.com      → UAT ALB
QA:             api.qa.internal          → Private DNS (no public access)
Dev:            api.dev.internal         → Private DNS (no public access)

Dev and QA should NOT be publicly accessible. Access via VPN only. This reduces attack surface and prevents accidental external traffic.

---

Security Posture by Environment

Security scales with environment criticality:

---

Disaster Recovery by Environment

---

Environment Promotion Pipeline

Developer branch → Dev (auto-deploy on push)
                      ↓
         PR merge → QA (auto-deploy, test suites run)
                        ↓
          Tests pass → UAT (manual trigger, stakeholder sign-off)
                          ↓
           Sign-off → Staging (auto-deploy, performance tests)
                            ↓
          All green → Pre-Prod (manual gate, release candidate)
                              ↓
     Release approval → Production (canary → full rollout)

Promotion Gates

---

Common Mistakes DevOps Architects Avoid

1. Making Dev identical to Prod

The mistake: "Let's make all environments identical to avoid surprises."

Why it fails: Six identical production environments costs 6x. For our scenario, $42,000/month instead of $14,460/month.

The right approach: Only Pre-Prod is identical to Prod. Other environments are purposefully right-sized. Dev will occasionally behave differently — Staging and Pre-Prod catch those differences.

2. Using production data in lower environments

The mistake: "Developers need real data to test properly."

Why it fails: GDPR Article 5, SOC2 CC6.1, and common sense. If Dev gets breached, customer PII is exposed.

The right approach: Automated data masking pipeline. Copy production schema and volume patterns, replace PII with faker-generated data. Maintain referential integrity.

3. Skipping Pre-Prod to save money

The mistake: "Staging is good enough."

Why it fails: Staging runs at 50% capacity with different instance types. It will NOT catch memory issues at production limits, throughput bottlenecks at full volume, or configuration drift.

The right approach: Run Pre-Prod intermittently (8 days/month). Costs 25% of always-on but catches what Staging misses.

4. Shared databases across environments

The mistake: "QA and UAT can share a database."

Why it fails: QA resets data during test suites while UAT stakeholders are running demos. Career-ending moment.

The right approach: Each environment gets its own database. Size differently, never share.

5. No scheduled shutdown for lower environments

The mistake: Running Dev and QA 24/7.

Why it fails: Dev sits idle 65% of the month. That is wasted money.

The right approach: Dev shuts down at 8 PM, starts at 8 AM weekdays. QA scales to zero between CI runs. Saves $3,000-4,000/month.

6. Over-sizing from Day 1

The mistake: Sizing for Year-2 aspirational traffic from Month 1.

Why it fails: Paying Year-2 prices with Month-1 traffic. Auto-scaling exists.

The right approach: Size for Month 1 reality. Auto-scale with generous max. Buy reserved capacity after 3 months of data.

---

The DevOps Architect's Checklist

Week 1: Discovery

• [ ] Service count, tech stack, communication patterns from Solution Architect
• [ ] Traffic projections (Day 1, Month 6, Year 1, Year 3) from Product Manager
• [ ] Compliance requirements (SOC2, GDPR, HIPAA, PCI-DSS)
• [ ] Third-party integrations and their sandbox availability
• [ ] Team size and squad structure
• [ ] Budget envelope from Finance
• [ ] Existing infrastructure and portability requirements

Week 2: Architecture Design

• [ ] Container orchestration platform choice
• [ ] Account/subscription isolation strategy
• [ ] VPC/VNet CIDR and connectivity planning
• [ ] Compute sizing per environment (multiplier principle)
• [ ] Database topology per environment
• [ ] CI/CD infrastructure design
• [ ] Observability stack design

Week 3: Security and Compliance

• [ ] IAM strategy per environment
• [ ] Secrets management lifecycle
• [ ] Network security design (SGs, NACLs, WAF)
• [ ] Data masking pipeline design
• [ ] Backup and DR strategy per environment
• [ ] Compliance evidence collection points

Week 4: Cost and Approval

• [ ] Detailed cost model
• [ ] Optimization roadmap
• [ ] Year-1 projection presentation
• [ ] Budget approval
• [ ] Terraform/Bicep modules creation
• [ ] Promotion pipeline documentation

---

Infrastructure-as-Code: Reusability Pattern

Same modules, different variable values per environment:

# environments/prod/terraform.tfvars
environment            = "prod"
node_instance_type     = "c5.2xlarge"
node_count_min         = 6
node_count_max         = 12
rds_instance_class     = "db.r6g.2xlarge"
rds_multi_az           = true
rds_read_replicas      = 2
enable_waf             = true
enable_cdn             = true
scheduled_shutdown     = false

# environments/dev/terraform.tfvars
environment            = "dev"
node_instance_type     = "t3.medium"
node_count_min         = 2
node_count_max         = 3
rds_instance_class     = "db.t4g.medium"
rds_multi_az           = false
rds_read_replicas      = 0
enable_waf             = false
enable_cdn             = false
scheduled_shutdown     = true

One codebase manages all environments. Changes apply uniformly. No configuration drift.

---

Conclusion

Infrastructure sizing is not a one-time decision — it is a living architecture that evolves with your project.

Three principles that guide every decision:

Purpose dictates sizing. Each environment has a job. Size it for that job, not for everything.

Production parity increases as you approach Prod. Dev can be different. Pre-Prod cannot.

Optimize after data, not before. Start with the multiplier principle, right-size after 3 months of actual metrics.

When the solution architect asks "what configuration do we need?" — the answer is this document.

---

Quick Reference: Complete Environment Comparison

---

Frequently Asked Questions

How do I size infrastructure for a new application?

Start with baseline metrics: expected requests per second, average response time target, and data storage growth rate. Use load testing to determine per-instance throughput, then add 40-50% headroom for traffic spikes. Begin with smaller instances and scale up based on actual metrics rather than over-provisioning from day one.

What is the difference between vertical and horizontal scaling?

Vertical scaling (scaling up) means adding more CPU/RAM to existing servers, which is simpler but has hardware limits and requires downtime. Horizontal scaling (scaling out) means adding more servers behind a load balancer, which is more complex but offers near-unlimited growth and fault tolerance. Design for horizontal scaling from the start for production workloads.

How do I calculate the right number of Kubernetes nodes?

Sum the CPU and memory requests of all pods you need to run, add 20-30% for system daemons and overhead, then divide by your chosen instance type's allocatable resources. Factor in N+1 redundancy so losing one node doesn't cause resource pressure. Use the Kubernetes Cluster Autoscaler to dynamically adjust node count based on actual demand.

When should I use reserved instances versus on-demand?

Use reserved instances (or savings plans) for baseline steady-state workloads that run 24/7 — typically databases, core services, and minimum web tier capacity. Use on-demand for variable workloads and development environments. The sweet spot is committing to 1-year terms for 40% savings on your predictable baseline while keeping 30-40% of capacity on-demand for flexibility.