Architecture · Lesson 01

How does cloud networking connect services?

Cloud platforms turn familiar network ideas into programmable resources. Virtual networks, subnets, routes, gateways, and service policies decide how workloads communicate.

Virtual boundaries

Cloud networking is still networking.

A cloud virtual network provides an address space and routing boundary for workloads. Subnets place resources into smaller ranges, route tables select next hops, and gateways connect to other networks or managed services.

Cloud control planes create these resources through APIs (Application Programming Interfaces), but packets still follow paths, policies, and trust boundaries. A service being in the same cloud account does not automatically make it reachable or trusted.

Ask which plane decides.The control plane defines resources and policy; the data plane carries traffic. A successful configuration change does not prove that an application flow works.

Trace each direction

Ingress and egress are separate questions.

Egress describes traffic leaving a workload or virtual network; it may use a NAT gateway, a firewall, a peering link, or a private service endpoint. Ingress describes traffic entering it, and may be limited even when outbound connections work.

Check the route, policy, and return path for the direction being tested. A workload that can fetch updates through a controlled gateway is not automatically reachable from the public Internet, and a permitted inbound request still needs a valid response path.

Test the direction you are claiming.“Can it reach the service?” and “Can the service reach it?” are different flows with different controls.

Choose the service path

Private access changes the path, not just the address.

A private service endpoint can keep traffic inside selected virtual networks or provider links instead of sending it through a public route. That changes which route tables, policies, DNS answers, and monitoring signals determine reachability.

Do not treat a private endpoint as an automatic permission grant. Verify that the workload resolves the intended address, has a route to it, and is allowed by the service and network policies.

Trace the resolved destination.The same service name can lead to different network paths depending on where the client resolves it.

Build the model

Four cloud networking decisions

01

Address space

Which virtual network and subnet contain the workload?

02

Route

Which table and gateway carry traffic to its destination?

03

Policy

Which security groups, firewalls, and identities allow the flow?

04

Dependency

Which managed service, resolver, or external network must respond?

Mini investigation

Inspect a cloud flow

Select the observed behavior and identify the most direct next check.

CLOUD CLUERoute check

The workload may not have a route from its subnet to the destination network or gateway.

Inspect the subnet route table, next hop, and return path.

Knowledge check

Test your cloud networking model

Answer eleven questions. The answer order changes each time.

0 / 11