Cloud Networking Basics

Most of the cloud is easy to picture once you have a name for it. A virtual machine is a server. Storage is somewhere to put files. A database is a database.

Networking is the part that tends to stay invisible, because its whole job is to connect everything else together so quietly that you forget it is there. Then something cannot reach something else, and suddenly networking is the only thing anyone wants to talk about.

This article is a tour of the main ideas, kept deliberately conceptual. We are not going to configure anything. Every provider has its own networking products with their own names and quirks, and those belong in the later Azure and AWS series rather than here.

What stays the same across all of them is the shape of the problem, and that is what is worth getting clear first.

Your own private network

When you create resources in a public cloud, you are sharing an enormous platform with a great many other customers. That raises an obvious question. If everyone is running things in the same data centres, what stops my servers from being mixed in with everyone else’s?

The answer is a virtual network. It is a private, isolated network space that belongs to you, carved out of the provider’s much larger infrastructure.

You can think of it as your own fenced-off area inside a very large shared estate. The land and roads underneath may belong to the cloud provider, but other customers cannot simply wander into your part of it.

The isolation is created in software rather than with separate physical cables and switches. The hardware underneath may be shared with other customers, but their resources are kept logically separate from yours. Resources outside your virtual network cannot simply reach into it, you have to create a path for that traffic and deliberately allow it.

AWS calls this an Amazon Virtual Private Cloud, usually shortened to VPC. Azure calls it an Azure Virtual Network, usually shortened to VNet. The names differ, but the underlying idea is the same: your own isolated network space inside the provider’s cloud.

Resources inside a virtual network can communicate with one another using private IP addresses. These addresses are used only inside the network, allowing one resource to find and contact another without going through the public internet.

In a traditional network, physical equipment such as cables, switches, and routers helped define which devices belonged to the network. In modern cloud, software creates and controls that boundary instead.

Inside the virtual network, you usually divide things into subnets. A subnet is a smaller section of the network used to group resources that belong together. Each subnet is assigned its own range of network addresses.

If the virtual network is the whole office building, the subnets are the individual floors or departments. They are still part of the same building, but each section can have a different purpose and different rules about who is allowed in.

A common way to organise a web application is to keep its public-facing and private parts separate.

Most web applications have a frontend and a backend. The frontend is the part the user sees and interacts with in the browser. When it needs to load or change information, it sends a request to the backend.

For example, when a user signs in, the frontend might send the username and password to a backend. When the user opens an orders page, the frontend might ask the backend to retrieve their orders.

A load balancer can act as the public entry point for these backend requests. Instead of the frontend connecting to one particular backend server, it sends each request to the load balancer. The load balancer then passes the request to an available backend server.

There may be several backend servers, but this does not necessarily mean the backend has been divided into separate services. Each server can run its own copy of the same backend application.

For example, three backend servers might all run the same API code. The load balancer spreads requests between them. This allows the application to handle more traffic and means it can continue working if one server becomes unavailable.

The backend servers can remain in a private subnet because users do not need to connect to them directly. The load balancer receives the public requests and passes them into the private subnet.

The database can sit in a separate private subnet. It stores information used by the application, such as user accounts or orders, and can be configured to accept connections only from the backend servers.

This creates a simple chain:

The separation is not only for organisation. It lets you control which parts can be reached from the internet and which parts are allowed to communicate with each other.

In this example, users can reach the load balancer, the load balancer can reach the backend servers, and the backend servers can reach the database. Users cannot connect directly to the backend servers or the database.

Public and private addresses

Anything that communicates over an IP network needs an IP address. It is the address other systems use to find that resource and send traffic to it.

The important distinction for a beginner is between public and private IP addresses.

Public and private IP addresses use the same basic format. For example, both may appear as four numbers separated by dots. The difference is that private addresses come from special groups of addresses reserved for use inside private networks, while public addresses can be used across the internet.

A private IP address is used inside your virtual network or another private network connected to it. Backend servers and databases can use private addresses to find and communicate with each other, but someone on the public internet cannot use those addresses to reach them directly.

Private addresses are a bit like room or desk numbers inside an office. They help people find the right place once they are inside the building, but they do not tell someone outside where the building itself is.

A public IP address is more like the building’s street address. It gives internet traffic a publicly reachable destination, provided the network has a path to it and the connection is allowed.

In the setup above, the client does not need to know the private addresses of the backend servers or database. It sends requests to the publicly reachable load balancer instead.

The load balancer receives each request and passes it to one of the backend servers using that server’s private address. The backend server can then communicate with the database using the database’s private address.

Having a public IP address does not mean that every kind of traffic is automatically allowed. It gives traffic somewhere to go, but other network controls still determine whether the connection can reach the resource and whether the resource will accept it.

A useful rule is to give as few resources a public address as possible. A database almost never needs one. Backend servers may not need public addresses either when a load balancer can receive internet traffic on their behalf.

This reduces the number of resources directly exposed to the outside world and gives the application one controlled public entrance rather than several.

Routes and gateways

An IP address identifies where traffic is trying to go. The network must then decide which path the traffic should take to reach that destination.

This process is called routing.

A route is one instruction for sending traffic. It describes a destination and where traffic for that destination should be sent next.

For example, a route might say:

• Traffic for another subnet in this virtual network should remain inside the virtual network.
• Traffic for the public internet should be sent towards the network’s internet connection.
• Traffic for a connected company network should be sent through a private network connection.

A route table stores these instructions together. When a resource sends traffic, the network looks at its destination and uses the matching route to decide where to send it next.

Some routes keep traffic inside the virtual network. Other routes send traffic towards another network. To do that, the traffic may need to pass through a gateway.

A gateway is a connection point between two networks. An internet gateway, for example, connects a virtual network to the public internet. A route can tell the network to send internet-bound traffic to this gateway.

You can think of the virtual network as a private estate. The internet gateway is the main entrance connecting the estate to the public road outside.

In common cloud designs, a public subnet has a route that can send internet traffic to the internet gateway. Resources in that subnet can be made reachable from the internet when they also have a public IP address and the relevant security rules allow the connection.

A private subnet does not allow the public internet to start direct connections to its resources. Those resources can still communicate with other permitted parts of the virtual network.

Private resources are not necessarily cut off from the internet completely. They can be given controlled outbound access so they can download updates or contact external services without accepting direct connections started by internet users.

The important distinction is who starts the connection. A private resource may be allowed to contact something on the internet, while someone on the internet is still prevented from directly contacting that private resource.

In AWS, Internet Gateway is the name of a resource attached to a VPC. Azure provides the same broad capability through its virtual-network routing and public networking features, although it does not use one directly equivalent resource with the same name.

A route only provides a possible path. It does not automatically allow the connection. Security controls still decide which traffic is permitted to use that path.

Load balancers

A load balancer receives incoming requests and distributes them across several running copies of a backend application.

A request is a message asking the application to do something. It might ask for a web page, submit a form, load account information, or place an order.

The request usually comes from a client, such as a browser or mobile app. When the client contains the interface that the user sees and interacts with, it is also commonly called the frontend.

The backend application may be running more than once. Each running copy is often called an instance. An instance might run on a virtual machine, inside a container, or through another cloud compute service.

For example, an application might have three backend instances running the same code. They are separate copies of the backend, not necessarily three different parts of it.

Without a load balancer, the client might connect directly to one particular backend instance. That creates a problem. One instance could become overloaded while the others sit idle. Anyone connected to that instance would also be affected if it failed.

With a load balancer, the client connects to one entry point instead. The load balancer receives each request and passes it to an available backend instance.

You can think of it as a receptionist directing each visitor to someone who is available. The visitor needs to know only how to reach reception, not which particular person will deal with them.

The load balancer does not necessarily divide requests perfectly evenly. It follows a balancing method chosen by the platform. Depending on the method, it may consider which instances are available, how many connections they are already handling, or whether requests from the same client should continue going to the same instance.

A load balancer can also perform health checks. A health check is a small test used to confirm that a backend instance is still responding correctly.

For example, the load balancer might regularly request a simple status page from each instance. If an instance stops responding or returns an unhealthy result, the load balancer can stop sending new requests to it and use the healthy instances instead.

Users may be able to continue using the application without realising that one of the backend instances has failed.

A load balancer that accepts requests from the public internet is described as internet-facing. It provides a publicly reachable entry point, while the backend instances behind it can remain private.

Load balancers can also be internal. An internal load balancer distributes traffic between private systems inside a virtual network and cannot be reached directly from the public internet.

In AWS, managed load balancing is provided through a family of services called Elastic Load Balancing. An Application Load Balancer is commonly used for HTTP and HTTPS traffic from websites and web applications.

Azure provides Azure Load Balancer for general network traffic and Application Gateway for web traffic.

A load balancer is not the same thing as a firewall. Security controls decide whether a network connection is allowed. Once a request has been accepted, the load balancer decides which healthy backend instance should receive it.

This is why the load balancer often acts as the application’s controlled public entrance. The backend instances can remain in a private subnet without accepting direct connections from internet users.

A load balancer also supports scaling, but it does not normally create or remove backend instances itself. A separate scaling service can add instances when demand increases and remove them when they are no longer needed. The load balancer then distributes requests across whichever healthy instances are currently available.

Here is roughly how the pieces fit together in a small web application:

The client, usually a browser or app running the frontend, sends requests to the load balancer.

The load balancer passes each request to one available backend server. In this example, the backend servers are separate instances running copies of the same backend application.

The backend server processes the request and can read from or write to the database when necessary. The database sits in a separate private data subnet and can be configured to accept connections only from the backend servers.

The important shape is one controlled public entrance, several private backend instances behind it, and a database that only those backend instances are intended to reach.

DNS, or how names turn into addresses

People do not normally type IP addresses into browsers. They type names such as example.com.

Something has to translate that friendly name into the address a computer actually needs, and that something is DNS, the Domain Name System.

The way I find it easiest to think about DNS is as the phone book of the internet, back when phone books were a thing. You know the name of who you want to reach, you look it up, and you get the number that actually connects you.

When you type a website name into a browser, your computer asks a DNS service which address or destination that name currently points to. It then sends the request there. The lookup happens in the background, usually so quickly that most people never think about it.

The entry that connects a name to a destination is called a DNS record. A DNS record might tell the internet that example.com should send visitors to the public entrance of your application.

What makes DNS genuinely useful, rather than just a convenience, is that the name and the destination are not permanently glued together.

You can change where a name points without your users needing to learn anything new. If you move your application to a different load balancer or set of servers, you update the DNS record. The name people remember stays the same while the machinery behind it changes.

AWS provides a DNS service called Amazon Route 53, while Azure provides Azure DNS. Both let you manage the records that connect domain names to cloud resources and other destinations.

Serving content closer to users

There is a stubborn problem that DNS and load balancers do not solve, and it is distance.

Data travels quickly, but not instantly. If all your servers are in one cloud region and a user is on the other side of the world, every request and response has a long way to travel.

The delay between sending a request and receiving a response is called latency. Distance is not the only cause of latency, but it is an important one. A site can feel sluggish even when the servers themselves are powerful, simply because the data has to travel too far.

A content delivery network, usually shortened to CDN, addresses this by keeping copies of content in locations around the world.

These nearby locations are often called edge locations because they sit closer to the edges of the provider’s network and therefore closer to users.

When someone requests an image, video, stylesheet, or another reusable file, the CDN can serve a nearby copy instead of fetching it from your original server every time.

Keeping and reusing a temporary copy in this way is called caching. The original place the content comes from is called the origin. The origin might be a web server, an object storage bucket, or another service.

You can think of the origin as the main warehouse and the edge locations as smaller local depots. The warehouse holds the original item, but customers can receive popular items from a nearby depot rather than waiting for every order to travel across the country.

The first request for a file may cause the CDN to retrieve it from the origin. The CDN then keeps a cached copy for a period of time. Later users near that edge location can receive the cached version without the request travelling all the way back to the origin.

The content has, in effect, been moved closer to the people asking for it.

Beyond speed, this also reduces the work performed by the origin. The copies distributed around the world handle much of the delivery, which can help the application cope with sudden increases in traffic.

A CDN does not suit every kind of content equally well. It works best when the same response can be reused for many people. Images, videos, downloads, stylesheets, and other static website files are good examples.

Content that changes constantly or is created specifically for one user may be less suitable for caching. The benefit comes from being able to reuse the same copy, so highly personalised information often still needs to come from the application itself.

For the large, reusable parts of most websites, a CDN is often one of the more cost-effective ways to make the experience feel faster.

AWS provides its CDN through Amazon CloudFront, while Azure provides Azure Front Door, which combines global content delivery with other application-delivery features.

Keeping the unwanted out

All of this connectivity is only useful if you also have a way to control it. A network that lets everything talk to everything else is not a network so much as an open invitation.

The basic tool here is a firewall. A firewall examines network traffic and applies rules that decide what is allowed through.

If routing is the system of roads and signs, the firewall is the security guard at the destination. The road may lead to the door, but the guard still decides whether you are allowed through.

In the cloud, firewall rules may be attached to individual resources, groups of resources, or whole subnets. Different providers give them different names, but the underlying idea is similar.

A firewall rule usually describes where traffic is coming from, where it is going, and what kind of communication is allowed.

The source is where the traffic begins. That might be anyone on the internet, a particular IP address, a subnet, or another group of cloud resources.

The destination is the resource the traffic is trying to reach.

A protocol is an agreed set of rules that systems use to communicate. HTTPS, for example, is the protocol browsers commonly use to communicate securely with websites.

A port is a numbered doorway used to direct traffic to the correct service on a machine. Secure web traffic commonly uses port 443. A database usually listens on a different port intended for that particular kind of database.

A firewall rule might allow secure website traffic from the public internet to reach the load balancer on port 443. Another rule might allow the load balancer to connect to the application servers. A third might allow only the application servers to connect to the database.

Everything else can remain blocked.

This is sometimes described as denying by default. Rather than allowing everything and trying to block the dangerous parts, you begin with no access and add only the connections the application actually needs.

The wider security principle is called least privilege. It means giving a person or system only the access required to perform its job, and no more.

AWS commonly provides these network controls through security groups, while Azure uses network security groups, usually shortened to NSGs. Both contain rules controlling which connections may enter or leave particular cloud resources.

These basic firewall rules are mainly concerned with network connections. They do not usually decide whether a visitor looks like a suspicious bot or whether a particular web request is trying to exploit the application.

That kind of inspection is often handled by a web application firewall, usually shortened to WAF. A WAF understands web requests and can block suspicious patterns, known attacks, unwanted bots, or requests from locations you do not want to serve.

AWS provides AWS WAF, while Azure Web Application Firewall can be used with services such as Application Gateway and Front Door.

Network separation still matters even when firewall rules are in place. If an attacker reaches the web application, the database is not automatically exposed directly to the internet.

That does not make the database impossible to reach. The application itself may have permission to connect to it, and an attacker who fully controls the application may try to misuse that connection. The private subnet and firewall rules provide another boundary, not a magical force field.

This connects directly to the security ideas we will come to next. Much of your responsibility is deciding who or what can reach a resource and what they are allowed to do once they get there.

The provider gives you the mechanism. Deciding what to allow, and resisting the temptation to allow everything because it is quicker, is firmly your job.

A very common networking mistake is not some exotic attack. It is a rule left wide open because someone was in a hurry and meant to tighten it later.

Pulling it together

Cloud networking sounds like a lot of separate pieces, and in a sense it is, but they fit together into a fairly sensible whole.

You get a private virtual network of your own, divided into subnets so that different parts of an application can be exposed differently.

IP addresses give resources locations on the network. Routing rules decide where traffic can travel, while gateways provide connections between networks.

A load balancer provides one controlled public entrance to the application and spreads requests across the available instances. DNS turns a memorable name into the destination of that entrance. A CDN keeps reusable content closer to users, reducing distance and taking work away from the original servers.

Firewall rules sit across the arrangement and decide which network connections are actually allowed. A web application firewall can go further by inspecting the web requests themselves.

None of this requires you to memorise a particular provider’s product names.

Those come later, in their own series, where the specifics of how Azure and AWS implement these ideas can get the attention they deserve. For now, the goal is to recognise the shape: a private space you control, a few deliberate doors into it, clear paths between the parts, and rules describing who may use them.

Once that shape is familiar, the products are just different ways of building the same thing.