adminPublic and private subnets are network zones inside a cloud network.
A public subnet can route traffic directly to and from the internet. A private subnet does not directly expose its resources to the internet and is usually used for application servers, databases, internal systems, and sensitive workloads.
The practical rule is simple: expose only the entry point, not the whole system.
Cloud Architecture Brief
Beginners often put everything in one public subnet, making databases, admin ports, and internal services easier to attack.
Companies need subnet design to separate internet-facing services from private application and data layers.
A subnet is a smaller network segment inside a cloud network. Public or private behavior is determined mainly by routing and exposure, not by the name alone.
If you understand route tables, internet gateway, NAT, firewall rules, and workload placement, you can design safe network segmentation across cloud providers and data centers.
Architecture Decision
three_tier
api_backend
public_cloud
Public subnet contains load balancer and NAT gateway. Private app subnet contains application servers. Private data subnet contains database and cache. Route tables control which subnet can reach the internet.
Place only necessary public entry points in public subnets and keep application and data layers private.
This reduces attack surface and limits what an external attacker can directly reach.
Put all servers in public subnets; use public IPs for databases; rely only on passwords; avoid subnet separation for simplicity.
More subnet segmentation improves security but requires better routing, firewall, DNS, and troubleshooting skill.
Cloud Building Blocks
Web servers or app servers usually run in private subnets behind a load balancer unless direct public access is required.
Internet gateway enables direct internet routing; NAT enables outbound internet access from private subnets; route tables define the actual traffic path.
Private workloads should access object storage through private endpoints when security and compliance require it.
Databases should be placed in private data subnets and accept traffic only from application subnets or controlled admin paths.
Use security groups, network ACLs, firewall rules, private endpoints, and no public IPs for sensitive systems.
Use flow logs, firewall logs, NAT metrics, load balancer logs, and DNS logs to understand traffic behavior.
Enterprise Readiness
Create subnets across multiple availability zones so one zone failure does not remove the whole application layer.
Plan CIDR ranges with enough IP space for autoscaling, Kubernetes pods, managed services, and future environments.
Block public database access, restrict admin ports, separate production and development, and review route tables before launch.
Avoid unnecessary NAT traffic, use private endpoints when cheaper and safer, and avoid overbuilding network appliances.
When a private server cannot connect, check route table, NAT, firewall rule, DNS, endpoint policy, and target service status.
Failure & Job Readiness
Subnet named private but routed publicly, no NAT for updates, database with public IP, IP exhaustion, wrong route table association, and open admin ports.
Confirm subnet route tables; confirm no public IP on private systems; confirm database access source; confirm NAT or private endpoint path; confirm flow logs.
Remove public IP, fix route table, close firewall rule, move resource to correct subnet, restore NAT path, or isolate exposed system.
A company wants customer traffic to reach an API but does not want customers to directly access app servers, databases, or internal admin tools.
Explain why a private subnet is not secure by name alone and how route tables decide public or private behavior.
Design a VPC with one public subnet, one private app subnet, and one private database subnet. Mark route table, NAT, firewall rules, and allowed traffic.
VPC; Route Table; NAT Gateway; Firewall; Private Endpoint