Cloud Networking and VPC Design Questions

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

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.

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

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

Work in the order traffic actually travels, from the network edge inward, before touching the operating system: confirm the packet can physically reach the subnet (Internet Gateway attachment, route table, Elastic IP association), confirm nothing at the subnet or instance boundary is blocking it (NACLs, security groups, the source/destination check), and only then look inside the instance itself (OS firewall, instance health). Most "can't reach it from the internet" cases resolve in the first three checks; the instance-level checks matter mostly when everything upstream is provably correct.

Structured elaboration

Worked example

An engineer reports an EC2 (Elastic Compute Cloud) instance with a public IP and a security group allowing SSH (Secure Shell, port 22) and HTTP (port 80) is unreachable from the internet on both ports. Working top to bottom: the route table shows a valid 0.0.0.0/0 -> igw-0123 route, and the IGW is confirmed attached to the right VPC, so routing and the gateway are fine. The Elastic IP, however, shows as associated with a different network interface than the one currently attached to the running instance, a leftover from a previous instance replacement that reused the same EIP without re-associating it. That's the root cause: traffic addressed to the public IP is being delivered to an ENI that's no longer attached to anything live. Re-associating the EIP with the instance's current primary ENI resolves it immediately, without needing to touch the NACL, security group, or OS firewall at all, none of which were ever the problem.

Trade-offs and pitfalls

The natural instinct is to start at the security group, because it's the most visible and most frequently misconfigured layer in general, but that instinct wastes time whenever the actual fault is upstream (as in the worked example) or downstream (an OS-level firewall or a crashed service) of it. Working the checklist in traffic order, rather than in order of "what I suspect," catches both cases without bias. A second pitfall specific to this scenario: source/destination check is frequently the forgotten setting, because AWS enables it by default on every instance and it silently stays that way unless someone deliberately disables it, so the setting only becomes something you have to think about when an instance is meant to forward or NAT traffic for something else, which means it rarely shows up in a general reachability checklist unless you already know to look for it there.