あなたのステージング環境は本番環境よりも高くついている — そして誰も気づかない

Originally published on TechSaaS Cloud Originally published on TechSaaS Cloud Your Staging Environment Costs More Than Production — And Nobody Notices In 8 out of our last 10 infrastructure audits, the staging environment cost more than production. Not by a little — often 30-50% more. Nobody noticed because staging bills get lumped into "infrastructure costs" and nobody questions them. How Staging Sneaks Past Production Here's the typical pattern: When production was set up: careful capacity planning, right-sized instances, auto-scaling configured, alarms set. When staging was set up: "Just copy the production config so it's a faithful replica." And then: Factor Production Staging Instance size t3.xlarge (right-sized) t3.xlarge (copied from prod) Traffic 50K requests/day 200 requests/day Running hours 24/7 (needed) 24/7 (nobody turned it off) Auto-scaling Configured Copied but never triggers Data retention 30-day rotation "Never expire" (nobody set policy) Snapshots Weekly, pruned Daily (default), never pruned Production was optimized. Staging was forgotten. The Real Cost Comparison One client's actual AWS bill breakdown: Production Environment: EC2 (auto-scaled): $480/mo RDS (t3.medium): $70/mo ElastiCache: $150/mo ALB: $25/mo CloudWatch: $45/mo EBS + Snapshots: $60/mo NAT Gateway: $180/mo ───────────────────────────── Total: $1,010/mo Staging Environment: EC2 (same size, no scaling): $720/mo ← bigger because no auto-scale down RDS (r5.large "just in case"): $400/mo ← someone picked a bigger instance ElastiCache: $150/mo ALB: $25/mo CloudWatch: $120/mo ← verbose logging nobody reads EBS + Snapshots: $180/mo ← daily snapshots, never pruned NAT Gateway: $180/mo ───────────────────────────── Total: $1,775/mo ← 76% MORE than production Staging: $1,775/mo. Production: $1,010/mo. For an environment that handles 0.4% of the traffic. Fix 1: Schedule-Based Shutdown (65% Savings Immediately) Your staging environment doesn't need to run at 3 AM on Sunday. # AWS Lambda function triggered by EventBridge schedule # Stop staging at 8 PM, start at 8 AM, weekdays only # Stop Rule (cron: 0 20 ? * MON-FRI *) aws ec2 stop-instances --instance-ids i-staging-web i-staging-worker # Start Rule (cron: 0 8 ? * MON-FRI *) aws ec2 start-instances --instance-ids i-staging-web i-staging-worker Running hours: 24/7 = 720 hours/month → Weekday 8-8 = 240 hours/month. Savings: 67% reduction on compute costs. Immediately. No impact on anyone. For Docker-based staging, even simpler: # Crontab on staging server 0 20 * * 1-5 docker compose -f docker-compose.staging.yml stop 0 8 * * 1-5 docker compose -f docker-compose.staging.yml start Fix 2: Right-Size Staging Instances (Additional 50-70% Savings) Staging doesn't need production capacity. It needs enough to run your test suite and let QA click through flows. Rule of thumb: Staging instances should be 2 instance classes below production. Production Staging Monthly Savings t3.xlarge ($120/mo) t3.small ($15/mo) $105 (87%) r5.large ($180/mo) t3.medium ($30/mo) $150 (83%) m5.2xlarge ($280/mo) t3.large ($60/mo) $220 (78%) "But staging should mirror production!" No. Staging should mirror production's architecture , not its capacity . Same services, same networking, same config — smaller instances. If your app works on a t3.small, it'll work on a t3.xlarge. The reverse is also true. Instance size doesn't affect correctness. Fix 3: Ephemeral Staging (90%+ Savings) The best staging environment is one that doesn't exist until you need it. # GitHub Actions: spin up staging per PR name : PR Staging on : pull_request : types : [ opened , synchronize ] jobs : staging : runs-on : ubuntu-latest steps : - name : Deploy ephemeral staging run : | docker compose -f docker-compose.staging.yml up -d echo "Staging URL: https://pr-${{ github.event.number }}.staging.example.com" - name : Run E2E tests run : npm run test:e2e -- --base-url https://pr-${{ github.event.number }}.staging.example.com Cost: Only pay when PRs are open. No PR, no staging, no cost. Combined Savings Fix Savings Effort Schedule-based shutdown 65% 30 minutes Right-size instances 50-70% on remaining 1 hour Combined ~90% 1.5 hours Ephemeral (advanced) 95%+ Half day For our client: $1,775/mo → $180/mo. 90% reduction. 90 minutes of work. The Meta-Problem: Nobody Owns Staging Costs This happens because: Dev team provisions staging — optimized for "works like prod" Finance sees one "AWS" line item — doesn't break down by environment Nobody reviews staging specifically — it's invisible Fix the process: Add environment tags to every AWS resource. Set up a Cost Explorer view that splits by environment. Review monthly. # Tag all staging resources aws ec2 create-tags --resources i-xxxxx \ --tags Key = Environment,Value = staging Then in Cost Explorer, group by the Environment tag. You'll immediately see the problem. Free Environment Audit We'll review your AWS environments (prod, staging, dev) and show you exactly where the waste is. 15 minutes, free, no pitch. Book a slot: techsaas.cloud/contact Originally published on TechSaaS Cloud Originally published on TechSaaS Cloud Your Staging Environment Costs More Than Production — And Nobody Notices In 8 out of our last 10 infrastructure audits, the staging environment cost more than production. Not by a little — often 30-50% more. Nobody noticed because staging bills get lumped into "infrastructure costs" and nobody questions them. How Staging Sneaks Past Production Here's the typical pattern: When production was set up: careful capacity planning, right-sized instances, auto-scaling configured, alarms set. When staging was set up: "Just copy the production config so it's a faithful replica." And then: Factor Production Staging Instance size t3.xlarge (right-sized) t3.xlarge (copied from prod) Traffic 50K requests/day 200 requests/day Running hours 24/7 (needed) 24/7 (nobody turned it off) Auto-scaling Configured Copied but never triggers Data retention 30-day rotation "Never expire" (nobody set policy) Snapshots Weekly, pruned Daily (default), never pruned Production was optimized. Staging was forgotten. The Real Cost Comparison One client's actual AWS bill breakdown: Production Environment: EC2 (auto-scaled): $480/mo RDS (t3.medium): $70/mo ElastiCache: $150/mo ALB: $25/mo CloudWatch: $45/mo EBS + Snapshots: $60/mo NAT Gateway: $180/mo ───────────────────────────── Total: $1,010/mo Staging Environment: EC2 (same size, no scaling): $720/mo ← bigger because no auto-scale down RDS (r5.large "just in case"): $400/mo ← someone picked a bigger instance ElastiCache: $150/mo ALB: $25/mo CloudWatch: $120/mo ← verbose logging nobody reads EBS + Snapshots: $180/mo ← daily snapshots, never pruned NAT Gateway: $180/mo ───────────────────────────── Total: $1,775/mo ← 76% MORE than production Staging: $1,775/mo. Production: $1,010/mo. For an environment that handles 0.4% of the traffic. Fix 1: Schedule-Based Shutdown (65% Savings Immediately) Your staging environment doesn't need to run at 3 AM on Sunday. # AWS Lambda function triggered by EventBridge schedule # Stop staging at 8 PM, start at 8 AM, weekdays only # Stop Rule (cron: 0 20 ? * MON-FRI *) aws ec2 stop-instances --instance-ids i-staging-web i-staging-worker # Start Rule (cron: 0 8 ? * MON-FRI *) aws ec2 start-instances --instance-ids i-staging-web i-staging-worker Running hours: 24/7 = 720 hours/month → Weekday 8-8 = 240 hours/month. Savings: 67% reduction on compute costs. Immediately. No impact on anyone. For Docker-based staging, even simpler: # Crontab on staging server 0 20 * * 1-5 docker compose -f docker-compose.staging.yml stop 0 8 * * 1-5 docker compose -f docker-compose.staging.yml start Fix 2: Right-Size Staging Instances (Additional 50-70% Savings) Staging doesn't need production capacity. It needs enough to run your test suite and let QA click through flows. Rule of thumb: Staging instances should be 2 instance classes below production. Production Staging Monthly Savings t3.xlarge ($120/mo) t3.small ($15/mo) $105 (87%) r5.large ($180/mo) t3.medium ($30/mo) $150 (83%) m5.2xlarge ($280/mo) t3.large ($60/mo) $220 (78%) "But staging should mirror production!" No. Staging should mirror production's architecture , not its capacity . Same services, same networking, same config — smaller instances. If your app works on a t3.small, it'll work on a t3.xlarge. The reverse is also true. Instance size doesn't affect correctness. Fix 3: Ephemeral Staging (90%+ Savings) The best staging environment is one that doesn't exist until you need it. # GitHub Actions: spin up staging per PR name : PR Staging on : pull_request : types : [ opened , synchronize ] jobs : staging : runs-on : ubuntu-latest steps : - name : Deploy ephemeral staging run : | docker compose -f docker-compose.staging.yml up -d echo "Staging URL: https://pr-${{ github.event.number }}.staging.example.com" - name : Run E2E tests run : npm run test:e2e -- --base-url https://pr-${{ github.event.number }}.staging.example.com Cost: Only pay when PRs are open. No PR, no staging, no cost. Combined Savings Fix Savings Effort Schedule-based shutdown 65% 30 minutes Right-size instances 50-70% on remaining 1 hour Combined ~90% 1.5 hours Ephemeral (advanced) 95%+ Half day For our client: $1,775/mo → $180/mo. 90% reduction. 90 minutes of work. The Meta-Problem: Nobody Owns Staging Costs This happens because: Dev team provisions staging — optimized for "works like prod" Finance sees one "AWS" line item — doesn't break down by environment Nobody reviews staging specifically — it's invisible Fix the process: Add environment tags to every AWS resource. Set up a Cost Explorer view that splits by environment. Review monthly. # Tag all staging resources aws ec2 create-tags --resources i-xxxxx \ --tags Key = Environment,Value = staging Then in Cost Explorer, group by the Environment tag. You'll immediately see the problem. Free Environment Audit We'll review your AWS environments (prod, staging, dev) and show you exactly where