"It needs internet" is one of the most expensive sentences in cloud networking. It sounds like a single requirement. It is usually four different requirements bundled together, and the fastest way to satisfy all four at once is to give the workload a public IP address and open a few ports. That works on the first day. It also exposes the workload to the whole internet, which none of the four requirements actually asked for.
This part pulls the sentence apart. Each of the four needs has its own mechanism, each mechanism has its own controls and costs, and one of them, the private endpoint, comes with a DNS problem that catches most teams the first time.
Hadeda Freight is fictional, and its address ranges and figures are illustrative. Hadeda's Track portal and API run in a Johannesburg cloud region, with production in 10.40.0.0/16 and a dedicated private-endpoint subnet at 10.40.40.0/24.
Four different questions
When a Track engineer says the app tier "needs internet", ask which of these they mean:
- Users on the internet must reach the workload. Customers and drivers open Track.
- The workload must start outbound connections. The app calls the payment provider and fetches operating system updates.
- The workload must reach a cloud provider's service. The app reads and writes object storage and a managed database.
- Administrators need remote access. An engineer must diagnose a misbehaving instance at 2am.
Every one of these has a narrower answer than a public IP on the workload. Combining them is how unnecessary exposure happens.
Inbound: publish through a controlled front door
When the public must reach a service, the workload itself still does not need to face the internet. A public DNS record points to a controlled ingress component: some combination of a content delivery network, DDoS protection, a web application firewall, a load balancer and an API gateway. That front door is the only thing with a public address. The application and data tiers stay private behind it.
For Track, api.hadeda.example resolves to the edge service, the edge passes clean traffic to a regional load balancer and WAF, and only that layer can reach the app subnet on port 443. If the app instances had public addresses as well, attackers could simply go around the front door. So they do not.
Outbound: NAT, and what NAT is not
Network address translation (NAT) rewrites the private source address of outbound traffic to a public address, so a private workload can open connections to the internet. A managed NAT gateway lets Track's app instances call the payment provider without accepting any unsolicited inbound connection: replies to connections the app opened come back, and nothing else does.
That property makes NAT feel like a security control. It is not one. NAT changes addresses; it does not decide which destinations are acceptable. A NAT gateway will carry a compromised instance's connection to an attacker's server just as happily as a legitimate call to the payment API. Pair it with the things that actually decide:
- explicit routes that send outbound traffic through a controlled path;
- an egress policy that allows approved destinations (Part 5 covers this);
- logging, so you can see where traffic went;
- capacity planning, because NAT gateways have connection and port limits per destination.
NAT also costs money in a way that surprises people. Providers typically charge per hour and per gigabyte processed. A workload that pulls large container images or backs up through a NAT gateway can produce a processing bill bigger than the compute it serves. Public IPv4 addresses themselves are no longer free either: at the time of writing (October 2026), AWS charges for every public IPv4 address, in use or idle, and Azure charges for public IPv4 too. Model the high-volume flows before the design is approved, and see Part 11 for the full cost picture.
There is also a default to know about. Historically, a virtual machine on some clouds could reach the internet without anyone configuring anything, through a default outbound path. On Azure, at the time of writing (October 2026), new virtual networks created with API versions released after 31 March 2026 default to private subnets with no default outbound access, while existing networks keep their old behaviour and older templates can still create the old kind. The safe habit on every provider is the same: decide outbound access explicitly, and never rely on a default you did not choose.
Private endpoints: reaching cloud services without the internet path
Track stores delivery photographs in object storage and customer records in a managed database. Both are services the cloud provider runs. By default, they are reached on public service endpoints, which means traffic leaves the private network to reach them, even if it never truly leaves the provider's backbone.
A private endpoint places a private network interface, or an equivalent private entry point, inside your network for one specific service. Hadeda's photo storage gets the address 10.40.40.8 in the private-endpoint subnet; the app reaches storage at that private address, the public endpoint can be disabled, and no internet path is needed. The provider names differ (AWS PrivateLink and VPC endpoints, Azure Private Link and private endpoints, Google Cloud Private Service Connect, Huawei Cloud VPC Endpoint) and their behaviour differs in detail, but the idea is the same.
A private endpoint is narrower than it sounds. It makes the data path private. It does not necessarily make every part of the service local or private: control-plane operations, provider support access, telemetry and the service's own dependencies may use other paths. If a regulator or customer asks where Track's data goes, "we use private endpoints" is the start of the answer, not the whole of it. Confirm the exact architecture of each service you rely on.
The DNS trap
Private endpoints are mostly a DNS project with some networking attached. Here is why.
Applications reach a service by name. Track reaches its photo storage as storage.hadeda.example, which points at the provider's storage service name. Before the private endpoint, that name resolves to a public address. After it, clients inside the cloud network must get a private answer, 10.40.40.8, for the very same name. Providers make this work with a private DNS zone that overrides the public answer, but only for resolvers that know about that zone.
Track's app, in the cloud network, uses the cloud resolver. The cloud resolver knows the private zone and answers 10.40.40.8. Everything works.
Now imagine a customer-service agent in the Midrand office opening a delivery photo, with office DNS servers that know nothing about the private zone. They pass the query to the internet and get the public address, or no answer at all once the public endpoint is disabled. The photo that loaded yesterday now times out, and the ticket reads "storage is down". It is not down. The office simply cannot resolve its name correctly. This is the failure Hadeda designed out before it happened, and many organisations meet it on the morning they switch the public endpoint off.
The fix, and what Hadeda runs, is a deliberate hybrid DNS design: office DNS conditionally forwards the provider's private zone names to a resolver endpoint inside the cloud network, and the cloud resolver answers with the private address. Part 3 introduced split-horizon DNS; this is it in practice. Then test resolution from every network that consumes the service: the cloud, Midrand, the depots, the Cape Town recovery site and remote staff on VPN. Testing from inside the cloud network alone proves almost nothing.
Administrative access without open ports
The fourth need, administrators reaching workloads, is the one most often solved with a public IP and an open SSH or RDP port. Exposed management ports are among the most scanned and attacked services on the internet, so this is also the most dangerous shortcut.
Better options, roughly in order of preference:
- Management services that need no inbound port at all, where an agent on the workload connects outwards to the provider's session service.
- Managed bastion services or identity-aware proxies, which sit in front of private workloads and require strong sign-in before forwarding a session.
- Just-in-time access, which opens a narrow path for a named person for a limited time, then closes it.
- Privileged access workstations for the most sensitive administration.
Whichever you choose, require strong identity with multifactor authentication, record sessions, and make the path auditable. At Hadeda, an engineer on call reaches a Track instance through the identity-aware proxy, using the same company sign-in as everything else, and the session is logged. Nobody has a reason to ask for port 22 to be opened.
Common mistakes
- One public IP answering all four needs. It creates inbound exposure that only the front door required.
- Treating NAT as a firewall. NAT hides addresses; it does not judge destinations.
- Ignoring NAT processing and public IPv4 charges. A high-volume flow through NAT can cost more than the compute behind it.
- Creating a private endpoint without a DNS design. It works from the cloud and fails from everywhere else.
- Disabling the public endpoint before every consumer resolves privately. That is how a configuration change becomes an outage.
- Assuming "private endpoint" means every part of the service is private. Control planes and provider operations may use other paths.
- Opening SSH or RDP to the internet "just for now". Scanners find it within minutes.
Try it yourself
Take one Hadeda virtual machine that downloads operating system updates, accepts no internet traffic, writes to object storage and occasionally needs an engineer. Propose a separate mechanism for each of the three needs: outbound updates, storage access and administration. For each, state the route, the control that decides what is allowed, the evidence it leaves, and its cost driver. Then explain, in two sentences a finance director would follow, why a single public IP is a poor answer to all three.
Test your understanding
A NAT gateway lets private instances reach the internet but blocks unsolicited inbound connections. Is that enough egress control?
Answer: No. NAT does not decide which destinations are acceptable, so a compromised instance can still reach anything. You still need routing through a controlled path, a destination policy and logging.
After creating a private endpoint for storage, the app works but office users cannot reach the storage account. What is the most likely cause?
Answer: DNS. The office resolver does not know the private zone, so it returns the public address or nothing. Conditional forwarding to a cloud resolver endpoint fixes it.
Does a private endpoint guarantee that no data related to the service leaves your network?
Answer: No. It makes the data path to the service private. Control-plane operations, telemetry, provider support and service dependencies may use other paths, which you should confirm for each service.
Why prefer a management service with no inbound port over a bastion with a public SSH port?
Answer: With no inbound port there is nothing on the internet to scan or attack, and access is decided by identity and logged, rather than by whoever can reach and guess their way into an exposed port.
What to take from this part
"It needs internet" is four questions. Answer each one separately and narrowly.
Only the front door gets a public address. Application and data tiers stay private behind it.
NAT translates; it does not decide. Pair it with egress policy, logging and a cost model.
Private endpoints are a DNS project. Design forwarding first and test from every consumer network.
Administration should need no open ports. Identity, sessions and logs replace exposed SSH and RDP.
Next in the series: Load balancing, TLS and application delivery.
How CloudNala can help
We review how workloads reach and are reached from the internet, separating the four needs and finding the public addresses, open management ports and default outbound paths nobody chose. For private endpoint rollouts, we design the hybrid DNS first and plan the cutover so that every consuming network resolves privately before the public endpoint is disabled.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Network Review or write to us at consult@cloudnala.co.za