I've been learning AWS and want to check whether my mental model is accurate. My understanding is that a VPC is an isolated virtual network in AWS, with subnets, private IP addresses, and internal DNS-based communication between resources. An Internet Gateway provides a path between the VPC and the public internet, while public subnets contain internet-facing resources such as Application Load Balancers or NAT Gateways, and private subnets contain resources such as application servers and databases.
For incoming traffic, I believe requests reach an Application Load Balancer first. The ALB uses target groups to determine which EC2 instances or containers should receive each request, then distributes traffic among healthy targets. Security groups control which inbound and outbound connections are allowed for resources such as the ALB and backend instances.
For compute, EC2 provides virtual machines where I can deploy and run applications directly. For Docker workloads, ECR stores container images and ECS runs them as tasks. With the ECS EC2 launch type, I manage the underlying EC2 instances. With Fargate, I provide a task definition containing details such as the image, CPU, and memory, while AWS manages the underlying infrastructure.
Please point out anything that is inaccurate or missing, especially how an Internet Gateway actually connects a VPC to the internet and the differences between the main compute options.
4 Answers
A public subnet is not inherently public just because it is called public. It is public when its route table has a route to an Internet Gateway. A private subnet usually has no route to an Internet Gateway. If instances in a private subnet need outbound internet access for updates or downloads, their route table can point to a NAT Gateway in a public subnet. A NAT Gateway allows outbound connections but does not normally allow unsolicited inbound connections from the internet.
One small terminology correction: security groups are not part of a target group. A target group is simply a collection of destinations and health-check settings for the load balancer. Security groups are stateful virtual firewalls attached to network interfaces, such as those belonging to an ALB or EC2 instance. A common setup is to allow internet traffic to the ALB security group, then allow the instance security group to receive traffic only from the ALB security group.
Your overall model is solid. The important detail is that a VPC is not connected to the internet automatically. A public subnet needs a route table with a default route such as 0.0.0.0/0 pointing to an Internet Gateway, and the resource also needs a public IPv4 address or another supported public path. The Internet Gateway is attached to the VPC and provides the VPC’s connection to the internet, but it does not decide where traffic goes by itself—the route table does that.
That clears up the missing piece: the Internet Gateway provides the VPC connection, while the subnet route table actually sends internet-bound traffic to it.
Your compute summary is mostly right, but ECS and EKS are different services: ECS is AWS’s container orchestration service, while EKS provides managed Kubernetes control planes. Both can use EC2 nodes or Fargate, depending on the configuration. Lambda is another major model: you deploy functions rather than managing long-running servers or containers. Fargate also does not mean AWS automatically scales your application in every situation—you still define the desired task count or configure a service with autoscaling policies.
Got it—I meant that the servers have security groups, not that the groups belong to the target group. The security-group-to-security-group rule makes sense.