Cloud networking

Cloud networking connects users, offices and workloads to services through defined routes, names and access controls. First, decide which connection each application needs. A public web service, an internal office system and a service-to-service data path should not inherit the same exposure by default.

Draw the actual flows: source, destination, protocol, name, expected address, identity and owner. Decide which workloads need public entry points and which should stay private. Then choose connectivity and security controls for those flows. A private address alone does not guarantee that an application is authorised, reachable or correctly named.

Most cloud networks are assembled from a small set of building blocks: virtual networks, subnets, routes and network security controls. A virtual network gives an environment an isolated address space. Subnets divide that space by workload role, exposure or team.

The platform names differ: AWS uses Amazon VPC, Microsoft Azure uses Azure Virtual Network (VNet), and Google Cloud uses Virtual Private Cloud (VPC). These provide the platform-specific setting for defining network address space and connecting cloud workloads.

Routes define how traffic moves between subnets, between virtual networks, to on-premises networks and to the internet. Network security controls—such as security groups, network ACLs and firewalls—filter traffic and enforce which flows are allowed. Private endpoints provide private connectivity to services.

Azure Private Link is a named option for private connectivity to services. Named load-balancing options include Azure Load Balancer and Cloud Load Balancing. Choose platform services to match the flows and workloads in the design.

Plan IP address space and subnet sizes around current workloads and anticipated additions. Azure Virtual Network provides control over IP addressing, routing and security; record the intended allocation and workload role for each subnet so growth does not obscure the design.

Use these building blocks to map the flows you have drawn. For example, separate public-facing and internal subnets, route only the traffic that needs to cross a boundary, and attach security controls to the narrowest scope that meets the requirement. The design should make the intended path explicit rather than relying on default connectivity.

For a public web service, record the client as the source and the service as the destination, then specify the required protocol, service name, expected public address, caller identity and owner. Place the service in a public-facing subnet, route only the required traffic to it and apply the chosen security controls to that flow.

Treat network capacity as a cloud resource

Cloud computing can provide on-demand access to a shared pool of configurable resources, including networks. This means network access belongs in the resource design alongside the computing and storage that applications use.

For small businesses, cloud services can be started on demand, and operations scaled while paying for what is used. When planning cloud workloads, consider how network capacity and access should accommodate services being added or scaled, rather than assuming the initial configuration will remain unchanged.

Plan network capacity alongside workload growth: review address space, subnet allocations and routes as services are added or scaled. Confirm that the planned network design can accommodate the intended workloads before expanding it.

Key Benefits of Cloud Networking for Australian Businesses

Make name resolution part of the design

DNS often decides whether a client reaches a public endpoint or a private one. Document which resolver each network uses and how cloud-specific names are forwarded.

AWS Route 53 and Azure DNS are named DNS services. For Azure private endpoints, link the private DNS zone to the querying VNet, maintain the relevant A record, and ensure custom DNS or conditional forwarders send privatelink.* queries to Azure DNS; the documented address is 168.63.129.16.