The question this answers
What does attaching an internet gateway actually give me, and what else has to be true before a packet arrives?
The load balancer must be dialable from any browser in the world, and the deployment host must be able to fetch packages from the internet. Both need a path between the virtual network and everything outside it.
A horizontally scaled, always-available attachment point that lets traffic pass between the virtual network and the internet — for resources that also have a route to it and a public address.
What it is, and what it deliberately is not
An internet gateway is an attachment on the virtual network, not a device in a subnet. It has no address of its own that you manage, no instance type, no bandwidth setting and no maintenance window; the provider runs it redundantly across the region's zones. It performs one function: it allows traffic to pass between the network and the internet, translating between a resource's private address and its assigned public address in both directions.
It is not a firewall. It does not filter, log by itself, or make any decision about what should be allowed — that is entirely the job of security groups and network ACLs. It is not a NAT device either, although both involve address translation: a gateway translates for a resource that *has* its own public address, while a NAT Gateway translates on behalf of resources that have none, and only for connections they initiated.
And it is not, by itself, connectivity. Attaching one changes nothing until a route table points at it, and even then a resource without a public address is unreachable through it. This is the gap where the classic lab lives.
Four things must all be true
Reachability through a gateway is a conjunction, and each clause is owned by a different object, frequently by a different team. The gateway must be attached to the network. The subnet's route table must send 0.0.0.0/0 to it. The resource must have a public address, either assigned at launch or attached afterwards. And the security group — plus the subnet's network ACL — must permit the traffic in the direction it is flowing.
The reason this is the module's most reliable lab is that three of the four failures look identical. A missing route, a missing public address and a blocking security group all produce a hang and then a timeout, with nothing logged anywhere useful. Only the fourth outcome — an immediate connection refused — tells you something different, and what it tells you is that all four network conditions passed and the process is not listening.
Walking the four in a fixed order turns a vague outage into a two-minute check. Confirm the attachment, read the route table *that this subnet is associated with*, check the resource for a public address, then read the security group and the ACL. Flow logs collapse it further: a REJECT entry names the firewall, and the complete absence of an entry names the route.
| Condition | Object that owns it | Symptom when missing | How to confirm |
|---|---|---|---|
| Gateway attached to the network | The virtual network | Nothing in the network can reach the internet at all. | Read the network's attachments — it is a single boolean. |
| Route 0.0.0.0/0 → gateway | The route table associated with this subnet | Hang, then timeout. Nothing logged. | Read the table the subnet is actually associated with, not the one you assume. |
| Resource has a public address | The instance, interface or load balancer | Hang. Reachable from inside the network, from nowhere else. | Check for an assigned public or elastic address on the interface. |
| Security group permits the traffic | The resource's security group | Hang. Stateful, so allowing inbound is enough for the reply. | Read the inbound rules; a flow log REJECT names this directly. |
| Network ACL permits both directions | The subnet's ACL | Often works one way only — stateless, so the return needs its own rule. | Check the ephemeral port range on the outbound rules. See Network ACLs: The Stateless Filter. |
| A process is listening on the port | The application | Immediate connection refused — which proves the network is fine. | Check the bind address; 127.0.0.1 is the usual culprit. |
The lab, walked
Here is the report as it actually arrives: "the instance is in the public subnet, the gateway is attached, the security group allows everything, and it still cannot reach the internet." Every claim is true. The instance still has no path, because it was launched without a public address — the subnet's auto-assign setting was off, which is a per-subnet default that nobody remembers setting.
The evidence sequence below is what turns that into a two-minute diagnosis. Note what each step rules out rather than what it confirms: the value of checking the route table is not that a route exists, it is that the route is no longer a candidate explanation. And note the last line, which is the general lesson — the gateway is necessary infrastructure and it is never the whole answer.
$ curl -m 5 https://example.com/ from the instance
curl: (28) Connection timed out after 5001 ms <- a hang, not a refusal:
route, address or firewall
STEP 1 gateway attached?
network vpc-a1b2 : internet gateway igw-9f3c ATTACHED -> not the problem
STEP 2 which table is this subnet associated with?
subnet public-a -> rtb-public-a
rtb-public-a: 10.20.0.0/16 local | 0.0.0.0/0 igw-9f3c -> not the problem
STEP 3 does the instance have a public address?
interface eni-77c1 private 10.20.1.42 public (none) <- FOUND IT
subnet public-a: map_public_ip_on_launch = false
STEP 4 security group, for completeness
egress: 0.0.0.0/0 all | ingress: 443 from 0.0.0.0/0 -> would have been fine
DIAGNOSIS in a public subnet, with a correct route, and no public address to
translate to. The gateway had nothing to work with.
FIX assign an address for a genuinely public workload, OR — usually better —
move it to a private subnet and give it a NAT route, since it only
needed to call OUT.Key points
- An internet gateway is a provider-managed attachment on the network, not a device you size, patch or place in a subnet.
- It is necessary but never sufficient: reachability also requires a route, a public address and permissive firewall rules.
- Three of the four possible failures produce an identical hang, which is why a fixed check order beats intuition.
- It does not filter anything — filtering belongs to security groups and network ACLs.
- A workload that only needs to call out does not need a gateway route or a public address; it needs a NAT path.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • The gateway is attached to the virtual network; without an attachment, no path to the internet exists at any address.
- • A subnet becomes public when its route table sends 0.0.0.0/0 to the gateway.
- • For outbound traffic, the gateway rewrites the source from the resource's private address to its assigned public address.
- • For inbound traffic, it rewrites the destination public address back to the private one and delivers it into the subnet.
- • A resource with no public address has nothing to translate to, so packets to and from it never traverse the gateway.
- • Own the auto-assign-public-address setting per subnet, and prefer explicit assignment over an inherited default.
- • Own the inventory of public addresses in the network — this is the practical definition of the internet-facing attack surface.
- • Own flow logs, because they convert the three identical hangs into distinguishable evidence.
- • Own the review discipline on route changes, since one row moves a subnet from private to public with no other signal.
- • Own removal: a gateway attached for a migration and left behind is a standing path that nothing is monitoring.
- • No gateway attached: everything in the network hangs on any internet destination.
- • Route present but the subnet is associated with a different table: one tier is unreachable while its neighbours are fine.
- • Public address missing: the resource is reachable from inside the network and from nowhere else, with no error message anywhere.
- • Security group or ACL blocking: an identical hang, distinguishable only from flow logs.
- • A gateway attached during debugging and never removed, quietly giving a subnet an internet path nobody intended.
- • The gateway itself does not need scaling — it is horizontally scaled and redundant across zones by the provider.
- • What scales is the bill: outbound data transfer is metered per gigabyte, and it grows with traffic, not with the gateway.
- • Public address quotas per account and per region are a real constraint in large environments.
- • It is not a single point of failure in the way a NAT device is, which is a genuine architectural difference between the two.
- • It is the network's internet boundary and therefore the first thing to enumerate in an exposure review.
- • It performs no filtering; assuming otherwise is how a permissive security group ends up in front of an admin port.
- • Bidirectionality is the point and the risk: unlike a NAT device, a gateway permits inbound to any resource that has a public address and an allowing rule.
- • Keep the set of resources with public addresses small and explainable — a short list is auditable, a long one is not. See Public Exposure, Read With Context.
- • The gateway typically carries no hourly charge of its own.
- • Data transfer out to the internet is metered per gigabyte, and it is one of the largest surprise line items in cloud. See Egress: Moving Data Costs Money, Not Just Storing It.
- • Static public addresses are often billed when allocated but not attached, which is a small recurring charge for something nobody remembers holding.
- • Compared with a NAT device it is cheap — the trade is that it exposes rather than protects.
- • Flow logs at the subnet boundary, with accepts and rejects, which is the only way to separate the identical hangs.
- • Data transfer out per resource, which is the cost signal and also the exfiltration signal.
- • Configuration change events on gateway attachment and route tables.
- • The signal that lies: the gateway's own status. It is essentially always healthy, and it stays healthy through every reachability failure described above.
- • A NAT device instead, when the workload only initiates outbound connections — same connectivity, no inbound path.
- • A private endpoint, when the destination is a provider service — no internet transit, no gateway involved, lower cost.
- • A load balancer or managed entry point as the only public resource, with everything else private — one address to defend instead of many.
- • A managed platform that provides its own public URL, when there is no virtual network worth designing.
- • Buys the ability to be reached from anywhere; costs an inbound path that must then be defended by rules rather than by absence.
- • Buys provider-managed redundancy at no operational cost; costs a metered egress bill that grows with success.
- • Buys simplicity relative to a NAT device; costs the one-directional safety property a NAT gives for free.
What people believe, and what is true
Attaching an internet gateway makes the network reachable.
It makes reachability possible. A route, a public address and a permissive security group are all still required, and the first two failures look identical.
An internet gateway is a firewall.
It filters nothing. Security groups and network ACLs are the only things making allow-or-deny decisions.
Anything in a public subnet is on the internet.
Only resources with a public address are. An instance in a public subnet without one is unreachable from outside — a state that confuses architecture diagrams badly.