Cloud Networking and VPC Design Questions

Direct answer

The public/private subnet split for a multi-tier app puts only the resources that must accept unsolicited inbound internet traffic (the web tier) in a public subnet, and everything else (application, database) in private subnets that are unreachable from the internet by construction. Security is improved because the blast radius (how far an attacker who breaches one tier can then reach) of an internet-facing compromise stops at the first tier: even with a perfect security-group rule set, only the route table decides whether an internet path exists at all, and the private tiers simply have none. Manageability improves because each tier gets its own routing and firewall boundary, so a change to one tier's exposure cannot silently affect another.

Structured elaboration

Per-tier breakdown:

Route tables, concretely. Each subnet associates with exactly one route table (though one route table can serve several subnets). The public subnet's table has a route for the VPC's own CIDR (added automatically, cannot be deleted) plus 0.0.0.0/0 -> igw-xxxx. Each private subnet's table has the local VPC route plus 0.0.0.0/0 -> nat-xxxx if it needs outbound internet, pointed at the NAT gateway that lives in a public subnet (a NAT gateway needs a public subnet and its own Elastic IP to reach the internet on behalf of everyone routing through it).

Security group vs NACL in this pattern, briefly (the full comparison is its own topic, but the shape that matters here): security groups are stateful and attached to the instance or its network interface, so you write one inbound rule and return traffic is automatically allowed back out. NACLs are stateless and attached to the subnet, evaluated before the security group, so you must explicitly allow both the inbound request and the ephemeral-port outbound return traffic, or connections will hang. Most teams run security groups as the primary control and leave NACLs at their permissive default unless they have a specific reason (blocking a known-bad IP range at the subnet boundary, or enforcing a hard compliance boundary that must hold even if every security group is misconfigured).

Worked example

A two-Availability-Zone (AZ) checklist for a 3-tier app, since anything less than two AZs is not actually highly available:

1. One public subnet per AZ (e.g. 10.0.0.0/24 in AZ-a, 10.0.1.0/24 in AZ-b) holding the load balancer and, if used, a bastion or jump host.
2. One private application subnet per AZ (10.0.10.0/24, 10.0.11.0/24).
3. One private database subnet per AZ (10.0.20.0/24, 10.0.21.0/24), often placed in a dedicated "DB subnet group" so the managed database service only ever launches replicas into subnets you intended for it.
4. One NAT gateway per AZ (not one shared NAT gateway for the whole VPC): if the only NAT gateway lives in AZ-a and AZ-a fails, AZ-b's private resources lose outbound internet access even though their own AZ is healthy. Each AZ's private route tables point only at their own AZ's NAT gateway.
5. Security groups chained tier to tier as in the table above: load-balancer security group accepts the internet, web/app security group accepts only the load-balancer's security group, database security group accepts only the app security group.

Secure administrator access, without a public jump box. A classic weak point in this pattern is putting a bastion host in the public subnet with SSH open to a corporate IP range, which is one more standing internet-facing attack surface to patch and monitor. The current recommended pattern (AWS Systems Manager Session Manager, or Azure Bastion / GCP Identity-Aware Proxy on the other clouds) removes that: the administrator authenticates through the cloud provider's identity and access management (IAM), and the agent already running on the instance opens an outbound-only connection to the Session Manager service, so no inbound port needs to be open on the instance at all, not even from a "trusted" IP range. That also gets you centralized, immutable session logging for free, which a bare SSH bastion does not.

Trade-offs and pitfalls

The single most common mistake in this pattern is a shared, single-AZ NAT gateway "to save cost," which quietly turns a multi-AZ design into one with a single point of failure for all outbound internet access; it also concentrates all cross-AZ private-subnet egress traffic onto one gateway and one AZ's data-transfer path. A second pitfall is treating "private subnet" as sufficient security on its own and skipping the security-group chaining: a private subnet stops internet ingress, but without tier-to-tier security group rules, anything else already inside the VPC (a compromised instance in the same VPC, or an overly broad peering connection) could still reach the database directly. Finally, teams sometimes forget that NACLs are stateless when they add a "temporary" outbound-only NACL rule and wonder why responses never arrive: without the matching ephemeral-port inbound rule, the return leg of the connection is dropped at the subnet boundary even though the security group would have allowed it.

Direct answer

A VPC endpoint lets resources inside a Virtual Private Cloud (VPC) reach a supported service privately, over the provider's internal network, without the traffic ever crossing the public internet and without needing a NAT gateway or internet gateway at all. There are two kinds: a Gateway Endpoint, which works only for a small set of services (Amazon S3 and DynamoDB) and is implemented as a route-table entry with no additional cost, and an Interface Endpoint (built on AWS PrivateLink), which works for the vast majority of AWS services plus many third-party and customer-hosted services, and is implemented as an actual network interface with a private IP address inside your subnet, billed per Availability Zone-hour plus data processed.

Structured elaboration

Worked example

Private access to S3 without touching the public internet: a Gateway Endpoint. A data-processing application running in a private subnet needs to read training data from an S3 bucket. Without an endpoint, that traffic would need a NAT gateway to reach S3's public endpoint over the internet, incurring NAT data-processing charges and taking a path that leaves the provider's network. Adding an S3 Gateway Endpoint to the VPC and associating it with the private subnet's route table adds a route that sends traffic destined for S3's published IP prefix list directly to the endpoint instead of the NAT gateway, at no additional cost for the endpoint itself, and the traffic never leaves AWS's network. The bucket's own policy can then be tightened to require that requests arrive via this specific endpoint (using a condition on the endpoint's ID), which closes off the possibility of the same bucket being reached from some other, less trusted network path.

Private access to a private API in your VPC: an Interface Endpoint. A separate team owns an internal pricing API running behind a Network Load Balancer in its own VPC, and another team's application, in a different VPC, needs to call it without any public exposure and without a full VPC peering or Transit Gateway relationship (which would give broader network access than intended). The pricing team publishes their load balancer as a PrivateLink endpoint service; the consuming team creates an Interface Endpoint for that specific service in their own VPC, which places a private-IP network interface directly in their subnet. With private DNS enabled, the consuming application calls the pricing API using its normal hostname, which now silently resolves inside the VPC to that private IP instead of any public address, and the security group on the interface endpoint's network interface controls exactly which of the consumer's resources may even attempt the call. Crucially, the consuming team gets access to that one API and nothing else in the pricing team's VPC: there is no routed network path between the two VPCs at all, which is the isolation property a full peering connection would not have given them.

Trade-offs and pitfalls

The most common mistake is defaulting to an Interface Endpoint for S3 or DynamoDB out of habit, paying the per-Availability-Zone-hour charge for a case where the free Gateway Endpoint does the same job (Interface Endpoints for S3 do exist and are occasionally the right call, for example when you specifically need endpoint access from on-premises over Direct Connect or from a different VPC in a way a Gateway Endpoint cannot reach, but that is the exception, not the default). A second pitfall is enabling an Interface Endpoint but forgetting to enable its private DNS option, which leaves applications still resolving the service's public hostname to a public IP and routing out through the NAT gateway or internet gateway exactly as before, quietly defeating the entire point of adding the endpoint, since nothing is actually broken, it is just not being used. Finally, teams sometimes assume an endpoint alone is a complete security boundary and skip the endpoint policy, relying only on the target service's own resource policy; a scoped endpoint policy is what stops an over-permissioned identity from reaching services or resources it should not, even if it otherwise has valid credentials.

Direct answer

Transport Layer Security (TLS), the protocol that encrypts data in transit, is almost never implemented as one unbroken encrypted tunnel from the end user's browser all the way to the database; it's implemented as a chain of TLS connections with a deliberate choice, at each hop, of where to terminate (decrypt) and where to keep encrypting further. The two poles are end-to-end TLS, where the same encrypted session runs unbroken from client to the final backend, and termination at a load balancer, where the load balancer decrypts, inspects or routes based on the plaintext, and re-encrypts (or doesn't) before forwarding.

Structured elaboration

• End-to-end versus termination at a load balancer. Terminating at a load balancer, most commonly an Application Load Balancer (ALB), lets the load balancer do content-based routing (path or host header rules), attach a Web Application Firewall (WAF) that can only inspect plaintext, and centralizes certificate management to one place. The cost is that the plaintext exists, briefly, inside your infrastructure at that hop. End-to-end TLS (or "TLS passthrough," where a Network Load Balancer forwards the encrypted bytes at Layer 4 without ever decrypting them) means nothing in between the client and the final server ever sees plaintext, which matters for payment card data or other regulated traffic, at the cost of losing content-based routing and WAF inspection at that layer.
• Certificate management: rotation and trust. Certificates expire and must be rotated before they do, or every client sees a trust failure. Managed services like AWS Certificate Manager (ACM) or a cloud provider's equivalent handle issuance and automatic renewal for load-balancer-terminated certificates; for services further inside the network (a database, an internal microservice) a private certificate authority combined with short-lived, automatically-rotated certificates (via a service mesh or a tool like HashiCorp Vault) avoids the classic failure mode of a manually-issued internal certificate nobody remembers to renew.
• Server Name Indication (SNI). The TLS handshake needs to know which certificate to present before the HTTP layer (and its Host header) is even visible, because the handshake happens first. SNI is the extension that lets the client state, in the clear, which hostname it's connecting to during the handshake, so a single IP address and load balancer can serve many different certificates for many different domains rather than requiring one IP per certificate.
• Where to decrypt for inspection, while minimizing attack surface. If you need to inspect traffic (a WAF, an intrusion-detection appliance, deep packet inspection for compliance), decrypt at the smallest number of points possible and as close to the edge as the inspection requirement allows, then re-encrypt immediately for the next hop ("TLS bridging"). Decrypting once at the edge load balancer and re-encrypting over a private, VPC-internal (Virtual Private Cloud) hop to the backend is a common middle ground: the plaintext only exists briefly, inside infrastructure you control, and never crosses a network boundary you don't own.

Worked example

An e-commerce site puts a CDN (content delivery network) and an ALB in front of its application. For general browsing traffic, TLS terminates at the ALB using an ACM-issued certificate that renews automatically before its expiry, and the ALB re-encrypts over a private VPC hop to the application servers, so the WAF sitting in front of the ALB can inspect requests for SQL injection and other attack patterns in plaintext. For the checkout and payment page specifically, the same site instead routes through a Network Load Balancer in TLS-passthrough mode straight to a PCI-scoped (Payment Card Industry) backend, so no intermediate component, including the company's own WAF, ever sees the decrypted card data, trading away WAF inspection on that one path in exchange for a materially smaller compliance and breach-exposure surface.

Trade-offs and pitfalls

Terminating everywhere for convenience (every hop decrypts and re-encrypts "just in case") multiplies the number of places a certificate can expire unnoticed and the number of places plaintext technically exists, without a corresponding security benefit, since most internal hops don't need content-based inspection. The opposite mistake, insisting on end-to-end TLS everywhere including for traffic that genuinely needs edge inspection, gives up the WAF's ability to see and block malicious payloads. The practical answer is almost always a mix: terminate where you need to inspect or route, pass through where the sensitivity of the payload outweighs the value of inspection, and automate rotation everywhere so trust never depends on a human remembering an expiry date.

Direct answer

Work outward from "does the traffic even take the path I think it does" before touching identity and permissions. A gateway endpoint reaches Amazon S3 (Simple Storage Service) by injecting a special route into specific route tables, not through a DNS (Domain Name System) trick or a network interface, so the single most common root cause is a private subnet whose route table was never associated with the endpoint. Check that first, then work through the endpoint policy, the IAM (Identity and Access Management) role, network ACLs (access control lists), security groups, and DNS resolution in that order: a hang or timeout points at routing or filtering, while a fast, clean rejection points at a permissions layer.

Structured elaboration

1. Route tables. A gateway endpoint (unlike an interface endpoint) has no ENI (elastic network interface) of its own. At creation time you explicitly associate it with one or more route tables, and AWS inserts a route whose destination is a managed prefix list (something like pl-xxxxxxxx representing "S3 in this Region") with the target set to the endpoint ID (vpce-xxxxxxxx). If the instance's subnet uses a different route table than the one the endpoint was associated with, that route simply doesn't exist there, and traffic falls through to whatever the default route is: a NAT (Network Address Translation) gateway if one exists (works, but silently bypasses the endpoint and starts costing data-processing fees), or nowhere if the subnet is fully private. Pull the route table for the exact subnet the instance is in and look for the prefix-list route before doing anything else.
2. Endpoint policy. The endpoint carries its own resource policy, separate from IAM. The default is "allow all actions on all resources," but many organizations tighten it to specific buckets or actions. If the target bucket was added to a bucket policy's allow list but never added to the endpoint policy (or vice versa), you get an accurate but confusing Access Denied.
3. IAM role permissions. Check the instance profile's role for s3:GetObject/s3:PutObject/s3:ListBucket (as applicable) on the correct resource ARN (Amazon Resource Name), then check for an explicit Deny from a service control policy or permission boundary. Separately, check the S3 bucket policy for an aws:sourceVpce condition: if it's pinned to a different endpoint ID than the one actually serving this VPC (common once an org has more than one gateway endpoint), requests fail even with correct IAM.
4. NACLs. These are stateless, so the subnet's NACL needs an outbound rule allowing port 443 to the destination (S3's IP range or the same prefix list) and an inbound rule allowing the ephemeral return ports (commonly 1024 to 65535), evaluated independently in both directions. A NACL that allows the outbound request but not the ephemeral inbound reply produces a classic "request sent, response silently dropped" hang.
5. Security groups. Stateful, so only the outbound rule matters (the return traffic is auto-allowed); confirm egress on 443 is actually open, since hardened baseline security groups often remove the default allow-all-outbound rule.
6. DNS resolution. This is usually a red herring for a gateway endpoint specifically: the instance still resolves the normal public S3 hostname to its normal public IP range, and the route table's prefix-list route is what silently intercepts and redirects that traffic. Don't spend time here unless you confirm someone has also created an S3 interface endpoint (which does use a private hosted zone to override DNS) alongside the gateway endpoint, or that enableDnsSupport/enableDnsHostnames are disabled on the VPC, either of which can make DNS the actual culprit.
7. Cloud provider quirks.
   • Endpoint routes are scoped per route table, not per VPC (Virtual Private Cloud). A new subnet you add later gets no S3 access through the endpoint until its route table is explicitly associated.
   • Gateway endpoints are not reachable through VPC peering or a Transit Gateway attachment by default; a peered VPC's traffic to S3 does not automatically ride the endpoint route unless you deliberately route it through an appliance that has one.
   • The endpoint only covers S3 in its own Region. A bucket in another Region is unaffected by the endpoint and goes out whatever egress path (NAT, proxy) is available, or fails if none exists.

Worked example

Instance sits in subnet subnet-0a1, associated with route table rtb-priv1. The gateway endpoint vpce-0abc was created and associated with rtb-priv2, a route table used by a different application tier. aws s3 ls from the instance hangs and times out rather than returning a 403. Tracing it: describe-route-tables --route-table-ids rtb-priv1 shows only 10.0.0.0/16 -> local and 0.0.0.0/0 -> nat-0123, no pl-xxxxxxxx -> vpce-0abc row; the same command against rtb-priv2 shows that row present. That confirms the endpoint was wired to the wrong route table. The fix is aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-0abc --add-route-table-ids rtb-priv1 (or, in TerraForm, adding rtb-priv1 to the endpoint's route_table_ids list). Because this environment has no live AWS credentials, treat the CLI output above as illustrative of the diagnostic shape, not an executed transcript; the way to confirm the fix for real is to re-run the same describe-route-tables call and see the prefix-list route appear, then re-run the failing S3 call and check VPC Flow Logs for an ACCEPT record on the instance's ENI with a destination matching the S3 IP range.

Trade-offs and pitfalls

The instinct is to check IAM first because that's where errors are loudest, but the symptom should drive the order: a clean, fast Access Denied means IAM, the endpoint policy, or the bucket policy; a hang or timeout means routing, NACLs, or security groups. Also watch for a NAT gateway masking the real bug: if a default route exists, a missing endpoint route doesn't break the instance's S3 access, it just quietly routes it over the internet path instead, so "it works" doesn't mean the endpoint is configured correctly, only that you're now paying NAT data-processing charges for traffic that should have been free and private.

Direct answer

A Virtual Private Cloud (VPC), called a VNet (Virtual Network) on Azure, is a logically isolated, software-defined slice of a cloud provider's physical network that you carve out for your own resources. You define its private IP address range, split it into subnets, control what can route in and out, and layer firewall rules on top. The building blocks are the same on AWS, Azure, and GCP even though the names differ: an address space, subnets that place resources in specific zones, route tables that decide where traffic goes, an internet-facing gateway, NAT (Network Address Translation: swapping a private IP address for a public one) for outbound-only internet access, and two layers of firewalling (one per instance, one per subnet).

Structured elaboration

Core components, mapped across the three providers:

The one structural difference worth knowing cold: AWS and Azure subnets are pinned to a single AZ, so a highly available design needs one subnet per tier per AZ. GCP subnets are regional and automatically span every zone in that region, so a GCP design needs far fewer subnet objects to get the same zonal spread.

Public vs private subnet, the actual definition. A subnet is "public" only because its route table sends 0.0.0.0/0 (all internet-bound traffic) to an internet gateway. A subnet is "private" when its route table has no such route: outbound internet access, if any, goes through a NAT gateway instead, and there is no path for unsolicited inbound traffic from the internet at all. Nothing about the subnet's IP range or a checkbox makes it public or private; it is entirely a routing decision. That means you can silently turn a private subnet public by adding one route, which is why route tables are the thing to audit, not subnet names.

• Public subnet: route table has a 0.0.0.0/0 -> IGW route. Resources here can receive inbound connections from the internet if a security group allows it (a public web server, a load balancer, a bastion host).
• Private subnet: no route to an IGW. Resources here cannot be reached directly from the internet. If they need outbound internet access (to pull OS patches or call a third-party API), traffic is routed through a NAT gateway that lives in a public subnet, which translates their private addresses to its own public one and hides them from unsolicited inbound connections.

Worked example

A standard 3-tier web application, one AZ shown (repeat per AZ for high availability):

graph TD
    INTERNET((Internet)) --> IGW[Internet Gateway]
    IGW --> ALB[Load Balancer - public subnet]
    ALB --> WEB[Web tier - public subnet]
    WEB --> APP[App tier - private subnet]
    APP --> DB[(Database tier - private subnet)]
    APP --> NAT[NAT Gateway - public subnet]
    NAT --> IGW

• Web tier: public subnet. It must accept inbound HTTP/HTTPS from arbitrary internet clients, so it needs the IGW route. Security group allows inbound 443 from 0.0.0.0/0 and nothing else.
• App tier: private subnet. It only ever receives traffic that the web tier forwards to it; nothing on the internet should be able to open a connection to it directly. Its security group allows inbound only from the web tier's security group, on the application port. It still needs outbound internet access for things like calling a payment API or pulling a dependency, which is why the private subnet's route table sends 0.0.0.0/0 to the NAT gateway, not the IGW.
• Database tier: private subnet, and stricter than the app tier. It has no legitimate reason to reach the internet at all (patches usually come through a maintenance window or a private mechanism, not a live outbound call), so many teams give it no NAT route whatsoever, only local VPC routes. Its security group allows inbound only from the app tier's security group, on the database port.

The reasoning behind this layout is defense in depth and blast-radius containment: if an attacker compromises the internet-facing web tier, the private subnets' lack of a route back from the internet, plus security groups that only trust the tier directly upstream, mean the attacker cannot reach the database in one hop. A common refinement worth naming even though it wasn't in the layout above: instead of routing the app tier's outbound calls to specific AWS services (object storage, a private API) through the NAT gateway and out to the internet and back, add a VPC endpoint. For example, a data-processing app pulling training data from S3 gets a Gateway Endpoint for S3, a routing-table entry that sends S3 traffic over AWS's internal network instead of through the NAT gateway and the public internet. That traffic no longer counts against NAT data-processing charges and never leaves AWS's backbone, which is both cheaper and a smaller attack surface. The same core-components list above (VPC, subnets, route tables, an internet gateway, NAT, security groups, NACLs) applies unchanged whether the workload sitting behind it is a web app, a data-processing cluster reading from object storage, or any other three-tier shape: the tier names change, the routing and isolation logic does not.

When you plan this layout, decide four things up front rather than reactively: how many Availability Zones you need (at least two, for anything that has to survive a zone outage), how big a CIDR block to give the VPC and each subnet (oversize subnets rather than sizing them to exactly today's instance count, since resizing a live subnet is disruptive), which tiers actually need internet reachability at all (fewer than people assume), and where you will need private connectivity to managed services later so you are not retrofitting a NAT bottleneck.

Trade-offs and pitfalls

The most common mistake is putting the application tier in a public subnet "to make debugging easier" and locking it down with security groups alone. Security groups are the right control for who can talk to an instance, but they do not stop a misconfigured resource, like a database with a public IP by accident, from being reachable from the internet in the first place; only the route table (no IGW route) guarantees that. A second pitfall is forgetting that a private subnet with no NAT route also has no outbound internet: this is fine for a database but will silently break an application tier that needs to call an external API, so "private" and "internet-reachable outbound" are two separate decisions you make per tier, not one. Finally, teams sometimes conflate "private subnet" with "encrypted" or "compliant"; subnet placement controls network reachability only; encryption, IAM (identity and access management: who is allowed to do what), and logging are separate controls layered on top.