Environments and network

This page defines how WardMitra should be laid out across environments and AWS networking boundaries.

Environment model

WardMitra should operate with three environments:

Environment	Purpose	Practical starting point
dev	team development and fast iteration	start here first
staging	pre-production validation and release checks	add after dev is stable
prod	live citizen and operations traffic	lock down with approvals

Recommended rollout order

For the current SPWHI team maturity, start simple:

1. build dev first
2. standardize Terraform structure and CI auth
3. add staging
4. bring prod under the same model once releases are repeatable

This is safer than trying to fully automate all three environments on day 1.

AWS region

The target AWS region is ap-south-1.

VPC design

Use a 3-tier VPC:

• public subnets for ALB, NAT gateways, and controlled ingress points
• private subnets for EKS worker nodes and application workloads
• data subnets for RDS and data services that should not be publicly reachable

Availability design

• production: multi-AZ
• staging: preferably multi-AZ if budget allows
• dev: can begin with a cost-aware setup, but keep the Terraform structure multi-AZ ready

Network principles

• no direct public access to application nodes
• only the load balancer is internet-facing
• databases stay in isolated subnets
• service-to-service access is allowed only where required
• environment naming and CIDR allocation should be consistent from the beginning

Practical guidance for SPWHI

Associate-level engineers should avoid over-designing the network on day 1. The right starting point is:

• one VPC pattern reused across environments
• the same subnet naming convention in each environment
• security groups per tier, not per developer preference
• clear ownership of ingress, application, and data paths