Table of Contents
Introduction
Cloud networking basics describe how your Linux system connects to and communicates inside a cloud environment. The core ideas are similar to traditional networking, but cloud providers give you virtual versions of routers, switches, and firewalls that you control mostly through their web consoles, APIs, or command line tools.
This chapter focuses on concepts that are specific to cloud networking and how they affect Linux servers that you run in the cloud.
Virtual Private Clouds and Virtual Networks
In public clouds you rarely work on the raw internet. Instead, you create an isolated virtual network that belongs only to your account. Each provider has its own name, such as Virtual Private Cloud, Virtual Network, or VPC network, but the idea is the same. Inside this private network you choose your own IP address ranges, organize subnets, and decide which systems can reach each other.
Your Linux instances receive private IP addresses inside this virtual network. They use these private addresses to talk to other systems in the same network. Traffic to and from the public internet passes through cloud controlled gateways at the edge of the VPC. From the point of view of the Linux system, the virtual network looks like a regular local network interface with an IP address and a default route, but everything behind it is implemented in software by the provider.
A key point is that most of the routing and firewall behavior is not configured inside Linux itself, but in the cloud network configuration. You often adjust routes and access rules in the provider console, then use Linux tools only to verify connectivity.
Cloud virtual networks are isolated environments where most routing and security rules live outside the Linux guest. Always check both the Linux configuration and the cloud network configuration when troubleshooting.
Subnets and Availability Zones
Inside a virtual network you create subnets. A subnet is a slice of the address space, such as 10.0.1.0/24. Cloud providers tie subnets to specific availability zones, which are separate data centers in a region. When you launch a Linux instance, you place it in a particular subnet, and that choice defines both its private IP range and its physical location.
For a Linux server, the subnet determines which other machines it can reach directly with layer 2 style communication, such as ARP based resolution, although the actual implementation is virtual. Subnets are often labeled by their purpose such as public subnets for internet facing resources and private subnets for internal services.
In public subnets, the routing table sends outbound traffic to an internet gateway and allows public IP association. In private subnets, the routing table is usually restricted and outbound internet access, if allowed at all, goes through intermediary components such as NAT instances or managed NAT gateways. From inside Linux, these paths show up as default routes and gateway IP addresses, but the behavior is controlled in the subnet routing settings.
Private and Public IP Addresses
Every cloud instance normally has at least one private IP address, which belongs to the subnet. This address is reachable only within the virtual network. Some instances also have a public IP address, which is reachable from the internet.
The public IP is often not attached directly to the Linux interface. Instead, the cloud provider uses network address translation at its edge. The Linux system usually sees only the private IP on its eth0 or similar interface. Public access works because the provider maps the public IP to the private IP in the background.
You can think of this as an automatic form of iptables style NAT, but you do not configure it inside the Linux system. Instead, you assign or remove public IPs in the cloud console or API. The Linux routing table still sends traffic to a default gateway in the private network. The provider handles the translation to and from the public address.
Security Groups and Network ACLs
In cloud environments the first firewall that affects your Linux server is usually outside the server itself. Providers implement virtual firewalls that control which inbound and outbound connections are allowed. These are often called security groups or similar terms.
Security groups are attached to instances or interfaces. They contain rules that specify which protocols, ports, and source or destination addresses are allowed. For example, you might allow inbound TCP port 22 from your office IP for SSH access to a Linux server, and allow outbound HTTPS to any destination.
Security groups are stateful, which means that if you allow outbound connections from the server, return traffic for those connections is automatically allowed. Network ACLs, on the other hand, are often stateless and attach to subnets rather than individual instances. They apply an additional filter that can allow or block specific traffic types.
Inside the Linux system you can still configure firewalls and access rules, but the cloud side controls are always applied first. When diagnosing connectivity issues, you must consider both sets of rules.
Cloud security groups and network ACLs act as primary firewalls outside the Linux host. If a connection fails, always confirm that the relevant inbound and outbound rules are open in these controls before changing anything on the server.
Gateways and Internet Access
For a Linux server in the cloud, internet access is controlled by gateways in the virtual network. An internet gateway connects your VPC to the wider internet and handles address translation for instances with public IPs. Within the subnet routing table, the default route points to this gateway.
Private subnets often use a NAT device for outbound only internet access. In this case, the Linux instance has only a private IP, and traffic to the internet is forwarded to the NAT instance or managed NAT gateway. The NAT device then performs source address translation so that external sites see the NAT host’s public IP, not the private address of the Linux server.
Despite these transformations, the Linux routing table is simple. It typically has a default route such as 0.0.0.0/0 via a gateway IP in the same subnet. The intelligence about which external gateway is used is stored in the cloud’s routing configuration.
Load Balancers and Service Endpoints
Cloud providers offer managed load balancers that distribute traffic across multiple Linux instances. These load balancers can be public, with an internet facing IP, or internal, with only private addresses inside the virtual network. In both cases, the target Linux servers usually have only private IPs and are not directly visible to the internet.
The load balancer performs health checks on your Linux instances and forwards only to healthy targets. From the instance point of view, incoming connections appear as originated from the load balancer or from translated client IPs, depending on the provider and configuration. This pattern lets you scale horizontally by adding more instances behind the same front end.
Service endpoints and similar features let your Linux servers reach cloud managed services, such as databases or storage systems, over private addresses instead of going over the internet. This improves security and can reduce latency. In that setup, the DNS names of services resolve to private IPs, and the traffic stays entirely within the cloud provider’s network.
DNS and Name Resolution in the Cloud
Inside a virtual network, DNS is usually provided by the cloud. Each instance receives DNS server addresses through its network configuration, and hostname resolution works for both internal hosts and public domains.
Cloud DNS can provide automatic records for your instances so that you can reach them using names that reflect their internal IPs or assigned hostnames. You can also define your own DNS zones and records so that service names remain stable even if the underlying instance IPs change.
Your Linux system typically uses the cloud DNS as configured in /etc/resolv.conf or through the system’s resolver service. The important point is that the actual DNS infrastructure is in the provider network, and you manage zones and records through the cloud tools, while Linux only acts as a client.
Network Security Responsibilities
Cloud networking introduces a shared responsibility model. The provider secures the underlying hardware, core routing, and basic isolation between tenants. You are responsible for configuring network level access for your workloads.
This responsibility includes choosing appropriate subnet designs, defining security group rules that expose only the required ports, using internal load balancers for private services, and ensuring that public IPs are attached only where needed. On the Linux side, you complement these measures with host level firewalls and application security.
Because so many networking controls live outside the Linux system, you must always think in two layers. The first layer is the cloud network configuration, and the second is the OS level configuration. Only when both are correct will your applications receive and send traffic as intended.