A batch job in a subnet with no internet route must call partner APIs without ever being reachable — what do you add?

## Reachability is three separate switches On a shared platform your workloads sit in a private address range you allocated, and whether one of them can talk outward, or be talked to, is decided by three independent mechanisms that people routinely collapse into one: - **The address it holds.** A private address is not routable on the public internet. A public address is — but holding one is an attribute, not a path. - **The route its subnet uses.** A route table says, for each destination prefix, which door a packet leaves by. With no matching route the packet is discarded inside your own network no matter what address it carries. - **The filter applied to the flow.** A separate permit-or-deny decision, evaluated independently of routing. **Outbound-only reachability** is the deliberate combination: private address, a route to a translating device, and permits only for the flows the workload starts. It is a positive construction, not the absence of configuration. ## The two pieces you add 1. **An address-translating gateway.** A managed device that rewrites the source address of flows leaving your network onto a public address it owns, and records an entry per flow so the reply can be mapped back to the workload that sent it. It must itself sit on the routed side — in a subnet whose own table carries a default route toward the network's internet-facing attachment. A gateway placed in an unrouted subnet translates into a dead end. 2. **A default route naming it.** In the batch job's subnet, an entry whose destination covers everything not matched by a more specific route, and whose target is that gateway. Creating the device attracts nothing on its own; the route is what sends traffic to it. | piece | what it does | symptom when it is missing | |---|---|---| | translating gateway | gives outbound flows a routable source address and remembers them | replies have no way back to a private address | | default route naming it | sends every unmatched destination to that gateway | traffic never leaves the subnet at all | | routed subnet beneath the gateway | carries the translated flow to the internet-facing attachment | the gateway receives traffic and has nowhere to forward it | ## Why inbound cannot piggyback on this The gateway's translation entries are created **only** by flows that start inside. An unsolicited packet arriving from outside carries a destination of the gateway's public address and some port, and the gateway has no entry mapping that pair to an inside workload — so it has nothing to deliver to and discards it. The one-directional property therefore comes from the **absence of state**, not from a rule someone wrote. That is why this shape is popular for a batch job that must call partner APIs: there is no rule to get wrong, and no inbound surface to defend. ## What it does not give you - **It is not authorization.** A path to the partner is not permission to call the partner; the partner still authenticates you, and your own filtering still decides which flows may start. - **It is not a filter.** The gateway permits whatever your filtering allowed out. Restricting which destinations the job may reach is a separate decision on a separate mechanism. - **It is not free of shared fate.** Every private subnet pointed at one gateway funnels its outbound traffic through one device, which becomes a chokepoint you have to size and place deliberately. - **It says nothing about the address the partner sees** beyond the fact that it is the gateway's. Whether that address is stable across rebuilds is a separate choice you have to make explicitly. ## Where this goes wrong in review - Someone gives the workload a public address to make the outbound call work. It works — and now the workload is addressable from the internet, which was the thing being avoided. - Someone creates the gateway and stops, because the console shows it as available. Without the route, nothing changes. - Someone points the route at a gateway sitting in a subnet that has no route of its own toward the internet-facing attachment; traffic reaches the gateway and dies there. - Someone assumes outbound works by default. Platforms differ here, and some default tables are deliberately bare: assume nothing leaves until a route says so. The short version an interviewer wants: name the **route** and the **translating gateway** as two separate things, and explain the one-directional property as a consequence of who creates the translation state.