This article has two parts – the second part can be read here : https://sg12.cloud/aws-vs-azure-vs-google-cloud-platform-networking-concepts-and-services-part-2/.
What each cloud provides sells is access to their data centers and their services. Companies rent the hardware (or pay for services) instead of heavily investing in infrastructure and training personnel.
The backbone of the cloud services is the networking components and services. The networking involves connecting various servers and storage systems in a cloud environment, allowing data and resources to be shared efficiently.
This network is often based on high-speed connections and advanced protocols, ensuring rapid data transfer and reliable communication between different data center parts. Key elements include switches, routers, other networking hardware, and virtual networks created through software.
Although the core principles of networking have remained unchanged over the past decade, the implementation methods have evolved. This article covers the main networking components of AWS, Azure, and GCP, and you will see that the fundamentals are the same for all three providers – only the marketing names are different. There are differences and nuances, but again, the fundamentals are the same – so understanding the core networking concept will help you understand networking in any cloud provider.
Regions and Zones
Cloud providers structure their services around the concept of regions, which are typically made up of multiple data centers. These regional data centers can be organized into availability zones for further redundancy and fault tolerance. By distributing resources across multiple regions and availability zones, you can enhance the availability and resilience of your services.
AWS
Regions: AWS regions are specific geographic locations around the world. Each AWS region consists of multiple isolated and physically separate availability zones within a geographic area.
Availability Zones: AWS uses the term “Availability Zones” to refer to zones within a region. Each Availability Zone is made up of one or more data centers equipped with independent power, cooling, and networking to ensure fault tolerance and stability.
Azure
Regions: Azure also uses regions, which are specific geographic locations worldwide containing one or more data centers, as a fundamental component of its global infrastructure.
Availability Zones: Like AWS, Azure availability zones are unique physical locations within a region. Each zone consists of one or more data centers equipped with independent power, cooling, and networking.
GCP
Regions: Google Cloud designates geographic locations around the world as regions. Each region is a separate geographic area that ensures data residency, operational reliability, and availability.
Zones: Within each region, there are zones that are deployments of cloud resources. They are designed to be isolated from each other within the same region to support high-availability architectures and reduce the impact of outages.
Virtual Networks
The next concept is virtual networks. These virtual networks are where services connect and communicate with each other. Think of them as networks in your data center.
All the cloud providers offer this service: AWS has the Virtual Private Cloud, Azure the Virtual Networks, and GCP also calls it the Virtual Private Cloud.
AWS
An AWS VPC is created in one region of AWS and uses availability zones, which are distinct physical locations inside a region. When creating a VPC, you use a private IP Range. Everything inside your VPC will use this CIDR range. All communication will need to use this CIRD, and all outgoing communication will be from this range.
You can further segment your network into private and public subnets based on the select CIDR range. Public subnets have access to the internet, while private subnets do not.
You have one default VPC per region, but you can create more. The non-default VPCs do NOT have internet access enabled by default. In this case, you can create an Internet Gateway and attach it to that VPC. The IG is a virtual device specific only to AWS that ensures connectivity to the internet.
An Internet Gateway serves as a designated target within your VPC route tables for traffic that can be routed over the internet. It enables instances in the VPC with public IPv4/IPv6 to communicate directly with the internet.
The Internet Gateway facilitates direct mapping for your instance, ensuring that when traffic exits your VPC subnet for the internet, the responding address is marked with your instance’s public IPv4 address or Elastic IP address rather than its private IP address.
This means that for incoming traffic aimed at your instance’s public IPv4 address or Elastic IP address, the destination address is converted to the instance’s private IPv4 address before being routed within the VPC.
For IPv6 internet connectivity, your VPC and its subnets need to incorporate an IPv6 CIDR block, and your instance should be allocated an IPv6 address from your subnet’s range. Since IPv6 addresses are inherently public and uniquely assigned globally, they do not require address translation for internet communication.
Azure
Like AWS, Azure’s Virtual Network exists in one region only. You create subnets added to VNET and resources in different subnets. All resources can communicate with each other by default, including resources in different subnets.
The resources created in a VN have internet access by default. However, the mechanism is slightly different from what’s implied. Azure does not use “Internet Gateway” devices like AWS does. Instead, internet access for VMs and other resources in a VNet is provided directly through the VNet itself.
No additional configuration is needed for outgoing internet access. However, you would typically use a public IP address or a service with a public endpoint for incoming internet access to a resource.
GCP
GCP takes a different approach than AWS and Azure. It implements a global VPC that spawns multiple regions and is not associated with one. When a VPC is created, multiple system subnets are made in each region (the subnets are region-specific). While the network can cover numerous regions, individual subnetworks must belong to a single region.
New projects are initiated with a default network (an auto-mode VPC network) containing one subnetwork (subnet) in each region unless an organizational policy is set to prevent this configuration.
Unlike AWS and Azure, Google does not constrain the private IP address ranges of subnets to the address space of the parent network. Therefore, it is possible to have one subnet with a range of 10.240.0.0/16 and another with 192.168.0.0/16 on the same network.
As you can see, all providers implement the same concept of regions and zones. They also implement the same virtual network concept as the backbone of your cloud infrastructure.
CIDR Classless Inter-Domain Routing (CIDR)
When creating a virtual network on any cloud platform, you must select an IP range (IPv4 or IPv6). CIDR, or Classless Inter-Domain Routing, is a method for allocating IP addresses and routing Internet Protocol packets. It was introduced to improve the efficiency and flexibility of IP address allocation compared to the older system based on classful network design.
The cloud providers reserve some IP addresses inside each VN / VPC, which you cannot use.
AWS and Azure set aside the first four addresses and the last address in a subnet. For instance, within the IP address range 192.168.1.0/24, the following addresses are reserved:
192.168.1.0: Network address.
192.168.1.1: Reserved by Azure for the default gateway.AWS uses this address for the Amazon VPC router.
192.168.1.2, 192.168.1.3: Azure reserves these to map the Azure DNS IP addresses to the virtual network space. AWS also uses them for DNS and keeps one in reserve.
192.168.1.255: Network broadcast address.
On GCP, we have four addresses reserved – the first two and the last two. The first two addresses are network and default gateway addresses, while the last ones are used for broadcast addresses and in reserve.
Network Routing
Network routing is a fundamental process used in telecommunications to forward IP packets from their source to their destination across multiple networks. It relies on routing protocols and devices such as routers and switches to determine the best path for data to travel from one network to another. It also uses routing tables, a data table stored in a router or a networked computer that lists the routes to particular network destinations. It contains information about the topology of the network immediately around it.
AWS
In Aws, route tables are created at the VPC level but are associated with each subnet. Each VPC has one main route table associated with all the subnets. The default one will be used if you do not associate a route table with a subnet.
Also, a subnet can have only one route associated at a time, but you can use a route table for many different subnets.
When multiple routes in a route table match a destination, the most specific route is used, determined by the longest prefix match.
Azure
Azure automatically creates system routes and assigns them to each subnet in VN. You cannot create system routes or remove them. However, you can override some of them by using custom routes for each subnet.
In Azure, you can establish custom or user-defined (static) routes, which allow you to either override the default system routes provided by Azure or add additional routes to a subnet’s route table.
To set up a custom route, you need to generate a route table and link it to one of the subnets. A subnet can be associated with either one or no route table.
The route with the lowest “route metric” is used if multiple routes match in a route table. This concept is similar to the “priority” used in routing in other systems, where lower numbers indicate higher priority.
GCP
In a GCP, Each VPC network comes with a set of system-generated routes to direct traffic among its subnets (inter-subnet communication) and to direct traffic to the internet via an internet gateway.
Users can create custom static routes in a VPC to direct traffic to specific destinations. The new routes can route traffic through a VPN tunnel, to an instance (such as a virtual appliance), or through a Cloud Interconnect for on-premises networking.
Each route in a GCP VPC has a priority, with lower numbers indicating higher priority. The numbers determine which path should be used if multiple routes match.
In cloud environments like AWS, Azure, and GCP, the routers that manage network traffic within and between cloud networks are virtual devices. These cloud platforms utilize software-defined networking (SDN) to create, manage, and scale virtual networks that provide the same functionality as physical networks but with greater flexibility and control. The same concepts of subnetting and route tables exist, and they are the same thing even if the implementation is slightly different.
NAT – Network address translation
Network Address Translation (NAT) is a technique used in computer networking to modify network address information in packet headers while passing a traffic routing device, typically a router or firewall. The primary purpose of NAT is to conserve IP addresses and enhance security by hiding the internal network structure.
AWS
On AWS, we have three components that handle network address translation: the Internet Gateway, the NAT Gateway, and the Egress-only Internet gateway.
When an internet gateway is attached to a subnet, it creates a public subnet by performing static NAT, a type of Network Address Translation (NAT).
When the data leaves that resource and passes through the internet gateway, the internet gateway switches the source IP address from the private IP address to the public IP address and sends the packet on. When the packet returns, it changes the destination address from the public IP address to the private IP address.
A public IPv4 address is required for a virtual machine to connect to the Internet. You can achieve this by setting up your VPC to automatically allocate public IPv4 addresses to instances or manually assigning Elastic IP addresses to them. Inside the VPC and its corresponding subnet, your instance recognizes only the private (internal) IP address space.
The Internet Gateway (IG) effectively performs one-to-one Network Address Translation (NAT) for your instance. It makes sure that when traffic exits your VPC subnet and heads to the Internet, the responding address field is populated with your instance’s public IPv4 address or Elastic IP address rather than its private IP address.
On AWS, there is also a NAT Gateway device. This appliance is similar to the Internet Gateway: While IG allows resources in your VPC to access the internet and vice versa, the NAT Gateway only enables instances in a private subnet to access the internet but prevents devices on the internet from initiating connections with those instances.
In other words, IG supports bidirectional communication by allowing outbound and inbound traffic, while the NAT Gateway is unidirectional, allowing only outbound traffic.
For IPV6 connectivity, we have an egress-only internet gateway. This highly available component allows outbound communication over IPv6 from instances in your VPC to the internet and prevents the Internet from initiating an IPv6 connection with your instances.
Azure
The Azure NAT Gateway is a fully managed, highly reliable service for Network Address Translation (NAT). It enables all instances within a private subnet to establish outbound connections to the internet while maintaining their privacy. This service automatically rejects all inbound connections, allowing only traffic responding to outbound connections to pass through.
GCP
The network translation service’s name in GCP is Cloud NAT. It lets specific resources create connections to the Internet or other VPCs while blocking all unsolicited inbound connections.
In the Cloud NAT interface, you can create two types of NAT Gateways.
Public NAT
This gateway helps GCP resources that do not have public IP addresses communicate with the Internet. A Public NAT gateway allocates a set of external IP addresses and source ports to each VM that uses the gateway to create outbound connections to the Internet. Public NAT is very similar to AWS NAT Gateway or Azure NAT Gateway.
Private Nat
Private NAT enables private-to-private translations across Google Cloud networks. Imagine you have a network in your company and need to talk to another company’s network.
But both networks use some of the same IP addresses. This is where Private NAT helps. You set up a Private NAT gateway in your network, and it makes sure your network traffic goes to the right places in the other company’s network, avoiding any IP address conflicts.
Networks Access Controls
Network Access Controls refer to the mechanisms and policies regulating access to network resources, making sure that only authorized users or devices can access specific network parts. These controls are essential for maintaining data security, integrity, and confidentiality within a network.
AWS
Network Access Controls List
In AWS, the network access control list (NACL) is a security filter similar to a firewall. It checks the traffic that enters and exits a subnet and is attached at the subnetwork level.
NACL only filters data crossing the subnetwork boundary and not the traffic inside one (for example, two instances in the same network that communicate with each other.)
NACLs are stateless, meaning that they only see traffic going one way. Because of that, you need rules for both inbound and outbound traffic. The rules are processed in order from the lowest number to the highest and can either let (“allow”) or block (“deny”) specific IP addresses from accessing your network.
When a rule is matched, action is taken, and processing stops. If a match is found, no other rule will be evaluated.
Security Groups
The AWS security groups are another security feature of AWS. Unlike networked ACLs, which are attached to the subnet level, the security groups are connected at the network interface level.
While the NACL sits at the subnet boundary, the security groups sit at the boundary of the instance.
AWS Security groups are stateful, meaning they track traffic in and out and see it as one stream. If a piece of traffic is allowed in, it will be allowed back out by default.
Security groups cannot explicitly deny an IP address. However, they have an explicitly denied rule, meaning that traffic not expressly allowed will be rejected.
Azure
In Azure, the equivalent of the NACL from AWS is called Network security groups. These groups are designed to filter inbound and outbound traffic in an Azure Virtual Network.
Like AWS’s NACL, we can create multiple rules for both inbound and outbound traffic by specifying priority, Source/Destination, protocol, port, and whether to allow or deny.
The Network security groups can control traffic passing through a Network interface, a VM(classic), or a subnet.
Additionally, “Application Security Groups” are available, enabling the grouping of virtual machines and establishing network security policies according to these groups.
While the name is similar to the AWS Security Groups, their functionality is not. The AWS Security Groups control inbound and outbound traffic, while the Azure Application Security Groups allow only the grouping of similar application resources. After grouping the resources, you write fine-grained network security policies using that group name.
GCP
The Google alternative for AWS NACL and Azure Network Security Groups is the VPC Firewall. Same as in the previous cases, you have rules that let you allow or deny connections,
A VPC network acts like a big, spread-out firewall. Even though the rules for this firewall are set for the whole network, each computer (or instance) decides whether to allow or block connections. Imagine that these firewall rules control information coming in and going out of your network and manage the information being shared between computers inside your network.
A firewall rule in GCP comprises four items: an action (allow or deny traffic) and a protocol to which it applies, a source or destination, and a direction (ingress or egress)
The rules can be applied to all the instances in the network, or they can be used for a specific instance by specifying a tag. You can also apply a rule to a service account.
The firewall rules are stateful, meaning the GCP firewall will see the traffic as one stream and allow return traffic to match the original connection. Since the VPC is global, the firewall rules are also global and can support only IP4 connections.
So, all three major cloud service providers offer network security groups (NSGs) as a fundamental component of their respective networking and security architectures. NSGs provide granular control over inbound and outbound traffic within their respective cloud environments, allowing administrators to define rules based on various criteria such as IP addresses, protocols, ports, and directions.
While the platforms differ in terminology and specific features, NSGs’ core functionality remains consistent. They are essential for securing virtual networks and protecting cloud-based resources from unauthorized access and potential threats.
The second part can be read here: https://sg12.cloud/aws-vs-azure-vs-google-cloud-platform-networking-concepts-and-services-part-2/.
