The Hidden Economics of AWS Mumbai: Understanding Infrastructure Waste in ap-south-1

1. The Regional Reality of ap-south-1

Infrastructure reference architectures designed for US-East cannot be deployed blindly in AWS Mumbai without introducing systematic economic drift.

AWS Asia Pacific (Mumbai) — ap-south-1 — hosts the digital backbones of India's quick commerce, payment gateways, logistics aggregators, and enterprise platforms. Across 3 availability zones (ap-south-1a, ap-south-1b, ap-south-1c), thousands of engineering teams manage high-throughput, low-latency microservices.

However, most cloud cost optimization literature and platform engineering defaults originate from us-east-1 (N. Virginia). When teams blindly replicate multi-AZ VPC topologies, auto-scaling lifecycles, and database storage tiers in Mumbai, they encounter regional pricing structures and currency exchange sensitivities that compound into lakhs of rupees of silent monthly waste.

At an institutional exchange rate of ₹84.0/USD, every $1,000 of recurring monthly waste equals ₹84,000/month (₹10,08,000 annually). In this technical teardown, we analyze the five most pervasive infrastructure leaks observed across Indian engineering environments, provide exact mathematical formulations, and supply copyable AWS CLI verification commands you can execute in your own accounts today.

2. Vector 1: The Idle NAT Gateway Dilemma

The textbook AWS VPC pattern prescribes one NAT Gateway per Availability Zone. In non-production environments, this creates substantial recurring waste with zero byte throughput.

AWS best practice guides recommend placing one NAT Gateway in each public subnet across three AZs to ensure multi-AZ redundancy for outbound internet traffic from private subnets (such as container image pulls or package updates).

In AWS Mumbai, a NAT Gateway incurs a fixed hourly charge of $0.045 per gateway-hour, regardless of whether any traffic is routed through it, plus a data processing charge of $0.045 per GB transferred. At ₹84.0/USD, the fixed availability cost is ₹2,721.60 per gateway each month (720 hours × $0.045 × 84).

In staging, UAT, and testing VPCs, night and weekend traffic drops to near zero. A typical mid-market stack running 3 isolated non-production VPCs across 3 AZs deploys 6 to 9 NAT Gateways. When six of these gateways sit virtually idle, the organization burns ₹16,330/month (₹1,95,955/year) entirely on idle compute reservations.

# List all NAT Gateways in ap-south-1 with their VPC and State
aws ec2 describe-nat-gateways \
  --region ap-south-1 \
  --filter "Name=state,Values=available" \
  --query "NatGateways[*].{Id:NatGatewayId,Vpc:VpcId,Subnet:SubnetId,Created:CreateTime}" \
  --output table

# Query CloudWatch for BytesOutToDestination over the last 14 days
# Replace NAT_GATEWAY_ID with the actual resource ID
aws cloudwatch get-metric-statistics \
  --region ap-south-1 \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0123456789abcdef0 \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d "14 days ago" +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 86400 \
  --statistics Sum \
  --query "Datapoints[*].{Date:Timestamp,Bytes:Sum}" \
  --output table

3. Vector 2: Unattached EBS & gp2-to-gp3 Arbitrage

Kubernetes worker node cycling and developer instances frequently leave detached EBS disks running indefinitely at legacy gp2 price points.

When an EC2 instance or EKS node terminates without the DeleteOnTermination block device flag set to true, its root and data EBS volumes transition into the 'available' state and remain provisioned indefinitely.

In ap-south-1, General Purpose SSD (gp2) costs $0.114/GB-month. The newer generation gp3 costs $0.0912/GB-month while providing 3,000 baseline IOPS and 125 MB/s throughput independently of volume size. gp2 not only costs 20% more per gigabyte, but its baseline IOPS scale down to a measly 3 IOPS/GB for smaller disks.

A fast-growing engineering team cycling ephemeral staging nodes often accumulates 2,500 GB of unattached legacy gp2 volumes across its accounts. At $0.114/GB-month, this represents $285.00/month (₹23,940/month) expended for zero operational value.

# Query all unattached EBS volumes in ap-south-1
aws ec2 describe-volumes \
  --region ap-south-1 \
  --filters Name=status,Values=available \
  --query "Volumes[*].{ID:VolumeId,SizeGB:Size,Type:VolumeType,AZ:AvailabilityZone,Created:CreateTime}" \
  --output table

# Verify zero read/write IOPS over the past 7 days before decommissioning
aws cloudwatch get-metric-statistics \
  --region ap-south-1 \
  --namespace AWS/EBS \
  --metric-name VolumeTotalReadTime \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time $(date -u -v-7d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d "7 days ago" +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 86400 \
  --statistics Sum

4. Vector 3: Public IPv4 Scarcity & Abandoned EIPs

AWS instituted universal IPv4 hourly billing. Idle Elastic IPs represent immediate unrecoverable expense.

Historically, AWS only billed for Elastic IP addresses that were unattached to running instances. As of February 2024, AWS instituted a universal charge of $0.005 per IP-hour for all public IPv4 addresses, regardless of whether they are attached or unattached.

For an unattached Elastic IP sitting forgotten in a VPC, the math is straightforward: 730 hours × $0.005/hr = $3.65/month per IP. Converted at ₹84.0/USD, that is ₹306.60 per IP every month.

Engineering teams that frequently provision and tear down ingress load balancers, temporary VPN tunnels, or partner test endpoints often leave 15 to 30 unallocated Elastic IPs lingering across sandbox and dev accounts, silently generating ₹4,500 to ₹9,000 in monthly waste.

# Identify all Elastic IPs without an active AssociationId
aws ec2 describe-addresses \
  --region ap-south-1 \
  --query "Addresses[?AssociationId==null].{AllocationId:AllocationId,PublicIp:PublicIp,Domain:Domain}" \
  --output table

# Release an unattached Elastic IP back to the AWS public pool
aws ec2 release-address \
  --region ap-south-1 \
  --allocation-id eipalloc-0123456789abcdef0

5. Vector 4: The S3 Zombie Multipart Tax

Interrupted multipart uploads do not appear in standard S3 bucket object listings, yet continue to accrue full S3 Standard storage charges indefinitely.

When applications or automated backup pipelines upload large files (>100 MB) to Amazon S3, the AWS SDK segments the file into parts using the Multipart Upload API. If an upload experiences a network timeout, process termination, or script error, the already uploaded parts remain stored in S3.

Crucially, incomplete multipart parts are invisible to standard `aws s3 ls` queries and the AWS S3 Console object view. Unless an explicit bucket lifecycle policy or cleanup routine is configured, these orphaned parts are billed at standard S3 storage rates ($0.023/GB-month in ap-south-1) month after month.

In data engineering environments executing multi-gigabyte ClickHouse, PostgreSQL, or Kafka backup dumps, zombie parts routinely accumulate to 10–25 TB of ghost storage, draining ₹19,000 to ₹48,000 each month for files that can never be assembled.

# List in-flight multipart uploads that have not completed
aws s3api list-multipart-uploads \
  --bucket my-production-data-bucket \
  --query "Uploads[*].{Key:Key,UploadId:UploadId,Initiated:Initiated}" \
  --output table

# Configure a bucket lifecycle configuration to abort incomplete parts after 7 days
cat << 'EOF' > lifecycle.json
{
  "Rules": [
    {
      "ID": "AbortIncompleteMultipartUploadsAfter7Days",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}
EOF

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-production-data-bucket \
  --lifecycle-configuration file://lifecycle.json

6. Vector 5: Non-Production RDS Multi-AZ Overprovisioning

Multi-AZ clustering doubles compute and storage expense. Staging and development environments rarely justify 99.95% high-availability guarantees.

Amazon RDS Multi-AZ deployments synchronously replicate database transactions to a standby instance in a secondary Availability Zone. While mandatory for production fault tolerance, enabling Multi-AZ effectively doubles instance compute and provisioned storage costs.

In ap-south-1, an on-demand PostgreSQL db.r6g.xlarge instance costs $0.268/hour ($195.64/month) in Single-AZ mode. In Multi-AZ mode, the hourly rate jumps to $0.536/hour ($391.28/month). At ₹84.0/USD, that single architectural toggle represents an additional ₹16,434/month (₹1,97,203/year).

When developers clone production configurations to create staging, QA, and UAT databases, the Multi-AZ flag frequently persists unnoticed. In an organization managing 4 non-production databases, this single oversight burns over ₹65,000 every month.

7. Cumulative Economic Impact Ledger

When these five vectors combine across an engineering organization, the recurring financial footprint is substantial.

Cloud waste is rarely the result of a single catastrophic misconfiguration; it is the compounding accumulation of dozens of small, reasonable developer choices that were never decommissioned after a release or migration.

The table below synthesizes the typical waste profiles observed across three common organizational scales operating primarily in AWS Mumbai (ap-south-1).

8. 3-Minute CLI Verification Script

A reproducible, non-destructive bash script you can run in your terminal with standard read-only IAM permissions.

You do not need to install third-party agents or grant write permissions to verify whether your AWS Mumbai accounts exhibit these five patterns. Run the following inspection script in any terminal configured with read-only AWS CLI access to ap-south-1.

#!/usr/bin/env bash
# ArthaOps Open Source ap-south-1 Quick Diagnostic Script
# Read-Only Inspection for AWS Mumbai (ap-south-1)
set -euo pipefail

REGION="ap-south-1"
echo "=== ArthaOps ap-south-1 Cost Diagnostic ==="
echo "Target Region: ${REGION}"
echo "Timestamp:     $(date -u)"

echo -e "\n[1/5] Checking Unattached EBS Volumes..."
UNATTACHED_EBS=$(aws ec2 describe-volumes \
  --region "${REGION}" \
  --filters Name=status,Values=available \
  --query "length(Volumes)" --output text)
echo "  Found: ${UNATTACHED_EBS} unattached volume(s)"

echo -e "\n[2/5] Checking Unassociated Elastic IPs..."
UNATTACHED_EIPS=$(aws ec2 describe-addresses \
  --region "${REGION}" \
  --query "length(Addresses[?AssociationId==null])" --output text)
echo "  Found: ${UNATTACHED_EIPS} unassociated Elastic IP(s)"

echo -e "\n[3/5] Checking Available NAT Gateways..."
ACTIVE_NATS=$(aws ec2 describe-nat-gateways \
  --region "${REGION}" \
  --filter "Name=state,Values=available" \
  --query "length(NatGateways)" --output text)
echo "  Found: ${ACTIVE_NATS} active NAT Gateway(s) in region"

echo -e "\n[4/5] Checking Multi-AZ RDS Instances in Non-Prod..."
MULTIAZ_RDS=$(aws rds describe-db-instances \
  --region "${REGION}" \
  --query "length(DBInstances[?MultiAZ==`true` && (contains(DBInstanceIdentifier, 'dev') || contains(DBInstanceIdentifier, 'staging') || contains(DBInstanceIdentifier, 'test') || contains(DBInstanceIdentifier, 'qa'))])" \
  --output text)
echo "  Found: ${MULTIAZ_RDS} suspected non-prod Multi-AZ DB instance(s)"

echo -e "\n==========================================="
echo "Diagnostic Complete. For full mathematical evidence and"
echo "blast-radius safe remediation recipes, explore our free sample report:"
echo "https://arthaops.com/sample-report"
echo "==========================================="

9. Architectural Takeaways: Determinism vs Dashboards

Why traditional alerting dashboards fail to cure infrastructure waste, and how Two-Plane Governance enforces safety.

The FinOps market is saturated with monitoring dashboards that send weekly email digests containing hundreds of cost anomalies. Engineering teams almost universally ignore them. Why? Because an alert without a deterministic proof of blast radius creates fear.

When a DevOps lead receives an alert saying 'Volume vol-08a... has been idle for 20 days', their primary concern is not saving ₹1,500. Their primary concern is: 'If I delete this, will I crash an internal analytics pipeline and be blamed for downtime?'

This is why ArthaOps was engineered around a Two-Plane Architecture:

1. **The Discovery Plane (100% Read-Only):** Continuously scans cloud infrastructure using deterministic mathematical invariants without requiring write permissions or intrusive node agents.

2. **The Remediation Plane (Separately Governed):** Before any resource is mutated or decommissioned, the system verifies pre-remediation checkpoints (such as snapshot creation and dependency checking) and requires explicit human approval via signed STS delegation.

True cloud efficiency is not about producing more dashboard graphs; it is about providing platform teams with the mathematical certainty and safety guarantees required to act.