A lot of choices when it comes to choosing the cloud providers

Hello everyone, hope all of you are doing well and keeping healthy and safe. I am kicking off these series of blogs on understanding cloud offerings by different cloud providers. There are at least three ulterior motives behind this and I am hoping it becomes apparent as you read through these articles.

Ever wondered why Google, Amazon and IBM calls something VPC (virtual private cloud) on GCP, AWS and IBM cloud respectively, while Oracle calls it VCN (virtual cloud network) on OCI and Microsoft calls it VNET (virtual network) on Azure. 

Well, not all of us may know it as they might practically be the same feature in the cloud to provide an isolated network in the cloud in a shared network infrastructure but there might still be subtle differences between how these private cloud environments are orchestrated by these different cloud providers. This is the first and foremost objective of this blog and that is to break the myth around the private cloud. In order to accomplish this, we will proceed in a step by step manner –

Understanding network IP and subnet addressing

Internet Protocol Addressing

An IP address serves two main functions. It identifies the host and location of the host in the network and thereby an ability to establish a path to that host.

  • An IPv4 address has a size of 32 bits and that is because and that is because the IPv4 address in dotted-decimal notation has 4 – 8 bits separated by dots.
  • These 4*8 comes to 32 bits which limits the address space to 232 IPv4 address space which is approximately ~ 4.29 billion addresses.
  • Out of these 4.29B addresses, some are reserved: all 0s and 1s, private address, broadcast and so forth. Remaining Addresses are known as Public IP Addresses (~4B).
  • Since each IP address has 4*8 bit combination, each 8 bit can expand to 28 bit IP beginning with zero to 255.

Public IPv4 addresses are globally unique and can be reachable from anywhere. That’s why these global addresses have a DNS configured that interprets the domain name to a public IPv4 address. Routing works by delivering packets to a destination network and the organization that owns the destination network is responsible for internally routing/delivering the packet to a machine.

Three classes of network were defined as per internet protocol RFC791:

Classes of Network Used By Cloud Providers
Classes of Network Used By Cloud Providers

Classless Inter domain range (CIDR)

  • Classless inter domain routing (CIDR) was introduced to accommodate a flexible addressing scheme to conserve address space.
  • Number of bits used to identify network is explicitly stated with   /<number> notation
  • Address is allocated based on organization’s actual need
  • IPv6 also uses CIDR Notation and more comprehensively handles address space shortage
  • Example of CIDR notation –
CIDR notation
CIDR notation


  • Network are more or less sub-divided into subnets inside an organization
  • This subnetting of address assists in manageability of network, security, isolation etc.
  • CIDR block convention is followed to identify subnets
CIDR Block to identify subnets

A private cloud configuration on a cloud platform requires you to specify a CIDR and a subnet CIDR.

Private Address Space

  • Private address is a reserved space (RFC1918)
  • Organizations are free to use this space for their own internal private network
  • These addresses cannot be used for public addresses
CIDR Block to identify subnets
CIDR Block to identify subnets

You can read more about IP addresses and usage from the WIKI page. I have added my interpretation here for clarity and also to build a background for what we want to discuss about virtual private clouds.

Identifying Overlapping CIDR ranges

You may always run into a situation where you are configuring VPCs and need to accurately identify if the CIDRs overlap before you can peer the VPCs or use some other networking options to peer them. I am have enlisted a few examples below in order to demonstrate a simplification of identifying overlapping CIDRs.

How to identify overlapping CIDRs
How to identify overlapping CIDRs

I think you all may already know this but let me document it so that we all understand what I have understood how to identify starting and ending addresses quickly in CIDR range. The subnet mask in a CIDR range in a way identifies what parts of the 4 – 8 bits will change in CIDR.

Take this example –

The most significant 16 bits – highlighted in RED – identifies the network – 11000000.10101000.00000000.00000000

The remaining 16 bits identify the variable portion of the network for hosts and since each 8 bit is 28 number of hosts, the ending address of CIDR can span to 255 max on last 16 bits.

ConsoleGoogle Cloud PlatformAmazon Web ServicesMS AzureOracle Cloud InfrastructureIBM Cloud
Data CentersGoogle Regions & ZonesAWS Regions, Availability Zones, and Local ZonesAzure Regions, Geographies & Availability ZonesOCI Regions & Availability DomainsIBM Cloud Regions & Zones
VPC DocumentationVirtual Private Cloud (VPC)Virtual Private Cloud (VPC)Virtual Networks (VNet)Virtual Cloud Network (VCN)Virtual Private Cloud (VPC)
VPC Scope1. Global (VPCs are global with regional subnets).
2. Shared VPCs allow sharing resources across projects.
1. Regional
2. Amazon also allows creating shared VPCs.
VPC Types1. Auto & Custom mode VPC
2. Global VPC not tied to a CIDR
3. Support for IPV4
1. Only custom or dedicated VPC tied to a CIDR
2. Support for IPv4 and IPv6
1. VPC created in a resource group
2. Support for IPv4 and IPv6
VPC created in a compartment Supports IPv4 and IPv6    VPC created in account Supports only IPv4
Network Service TiersStandard and PremiumNoneNoneNoneNone
Subnets on VPCs1. Subnets are regional.
2. Subnets can expand but not shrink.
3. Reserves 4 IP addresses within each CIDR subnet range  
1. Subnets are zonal.
2. AWS reserves 5 IP addresses within each subnet.
1. Subnets are zonal
2. Azure reserves 5 IP addresses within each subnet.
1. Subnets are zonal.
2. OCI reserves 3 IP addresses within each subnet.
1. Subnets are zonal
2. BM reserves 5 IP addresses within each subnet.
Maximum & Minimum VPC CIDR Ranges1. Default Network IP Range
2. Auto Network IP Range
3. Subnet Creation Mode
4. VPC networks can be moved from auto mode to custom but not vice versa.
AWS VPC Size: Max – 16 Min – /28   IPv6 – /64Allowed VNET Size: Max – /8 Min – /29   IPv6 – /64Allowed VCN Size: Max – /16 Min – /30   IPv6 – /64VPC Quotas   [Limits not apparent from documentation]
VPC Size – ExpandPrimary IP range of subnet can be extendedVPCs can be expanded by adding four (4) secondary IPv4 IP ranges (CIDRs). VPC can be shrunk by deleting the secondary CIDR blocks you have added to your VPC.Subnets can be added, removed or expanded if no VMs/services deployedVCN sizes cannot be extended or shrunk. 
Secondary IP AddressesSecondary IP addresses can be added to a subnet from primary IP range (a.k.a alias IP ranges)Allows one of more static or dynamic public and private IP to be assigned to the network interfaces (NIC) attached to a VMYou can associate secondary IPv4 CIDR blocks with your VPCYou can add secondary VNICs to an existing instance and also add secondary private IPs to a VNIC.IBM offers portable and static IP addresses under secondary subnets.
Static Public IP Addresses1. Static External IP addresses
2. Static Ephemeral IP addresses
Elastic IP AddressesBasic and StandardAllows static IP AddressesAllows static IP addresses
Network RoutingRouting in GCP :
1. Default Route
2. Subnet Route
3. Custom Route  
AWS uses route tables for network traffic.Uses network virtual appliances(NVAs) and route tables.OCI uses route tables and route rules to manage traffic.Uses VPC Routes with many limitations.
Internet AccessCloud NAT1. AWS NAT Gateway
2. AWS NAT instances
NAT instances vs NAT gateways
NAT GatewayOCI NAT GatewayIBM NAT masquerade on virtual router appliance
Network Traffic Control1. Firewall Rules
2. Implied Rules  
Components of firewall rules.
1. AWS Security Groups
2. AWS Network Access Control Lists (NACLs)
1. Azure security groups
2. Application security groups      
1. Network security groups (NSGs) and supported services
2. Security Lists  
1. Security Groups
2. Network ACLs  
DDoS/Web Application FirewallGoogle Cloud Armor1. AWS WAF
2. AWS Shield & Shield Advanced
Azure DDoS protection StandardOCI provides a DDoS mitigation service1. IBM Cloud DDoS protection
2. IBM Partners with CloudFlare to provide WAF and DDoS Services
VPC Peering1. GCP allows VPC peering for VPCs in the same project or same organization
2. Shared VPC peering between projects     VPC peering restrictions  
1. AWS allows VPC peering
2. AWS also offers  transit gateways & transit gateway manager for managing traffic between VPCs & VPN connections   VPC peering limitations
1. Azure allows VNETs peering
Peering requirements & constraints
OCI provides two options for VCN peering: 1. Local VCN peering for VCNs in same region
2. Remote VCN peering for cross-regions VCNs  
IBM allows VPC peering with AWS cloud but not with VPCs within its own infrastructure, however, it allows  to connect VPCs using VPN gateways, floating IPs, or IBM Cloud Transit Gateway.
Access to managed services on cloud providers platformGCP offers private access options: 1. Private Google Access
2. Private Google Access for on-premises hosts
3. Private services access
4. Serverless VPC access  
1. AWS VPC gateway endpoints for S3 & DynamoDB
2. AWS VPC interface endpoints using PrivateLink  
1. Azure service endpoints
2. Azure private endpoints Limitations
OCI offers: Service GatewayPrivate AccessIBM Cloud offers:
1. Regional Endpoints
2. Cross-region endpoints
3. Single Data center endpoints
Hybrid Networking (VPN)GCP offers Cloud VPN:
2. Classic VPN
AWS Offers:
1. Site-to-Site VPN
2. Client VPN
3. VPN CloudHub
4. Third party software VPN appliance
Azure offers:
1. Site-to-Site and Multi-Site (IPsec/IKE VPN tunnel)
2. Point-to-Site VPN
3. VNet-to-VNet connections (IPsec/IKE VPN tunnel)
OCI offers: VPN Connect  IBM Cloud offers VPN:
2. IPSec VPN  

VPN endpoints on IBM Cloud    
Hybrid Networking (Dedicated Private Connectivity)GCP Offers Cloud Interconnect:
1. Dedicated Interconnect
2. Partner Interconnect
AWS Offers:
1. Direct Connect
2. Direct Connect Gateways
Azure Offers: ExpressRoute with premium, local and Office 365 options  OCI Offers: FastConnectIBM Offers:
1. Direct Link Dedicated
2. Direct Link Dedicated Hosting
3. Direct Link Connect
4. Direct Link Exchange
Network GatewaysGCP Offers:
1. Cloud router
2. VPN Gateways for HA & Classic VPN
AWS Offers: Virtual Private Gateways & Customer GatewaysAzure Offers VPN gateways: VPN ExpressRouteOCI offers Dynamic Routing GatewaysIBM Offers VPN gateway connection options
Load BalancersGCP Offers multiple global & regional cloud load balancing options:
1. Internal HTTP(s)
2. External HTTP(s)
3. Internal TCP/UDP
4. External TCP/UDP – Network LB
5. External SSL Proxy
6. External TCP Proxy
AWS Offers three load balancer types: Application Classic Network  Azure Offers:
1. Public load balancer
2. Internal (Private) load balancer  
OCI Offers:
1. Public LB
2. Private LB  
IBM Cloud Offers:
1. IBM Cloud LB
2. Citrix Netscaler VPX  
Globally distributed content delivery network (CDN)GCP Cloud CDNAWS CloudFrontAzure CDNOracle bought zenedge but there is no single source to identify OCI CDNIBM CDN
Network LogsGCP VPC Flow Logs GCP Firewall LogsAWS VPC Flow LogsAzure Flow Logs for Network Security GroupsOCI VCN Flow LogsIBM VPC Flow Logs
Servers/ InstancesCompute EngineElastic Cloud Compute (EC2) instancesVirtual MachinesVirtual MachinesVirtual Server Instances
Instance TypesGCP Compute Engine Machine TypesAWS Instance TypesAzure VM ShapesOCI VM ShapesIBM Cloud Virtual Servers
Compare and Contrast Cloud Providers

Now, that we have few basic networking concepts out of the way, lets look at the private cloud and networking options of different cloud providers. I have tabulated the data below and provided links to the specific cloud providers documentation for every feature identified below.

I am sincerely hoping that this documentation to serve a few specific purposes –

  1. This should help the readers identify the commonalities of design and networking concepts behind creating a private cloud on a cloud providers platform.
  2. We still need a collective voice from the certification community as well as customers deploying these multi-cloud patterns to ensure that these cloud providers work towards common nomenclature of service offerings on their platforms. This will definitely help adoptions faster. It has to be understood that the more exclusivity in these naming conventions – just to sound and look different – will not only increase the time in demystifying a service offering but also increase the chances of falling behind a competition as well as a larger probability of extinction.
  3. If you are preparing for certification for a specific cloud provider platform, you might as well use this documentation to prepare for certification for others cloud providers. This will become more and more relevant as you see organizations choosing multiple cloud providers instead of just selecting one and get locked.

There is also another motive behind this documentation. Please see our effort to create a global data center map of the five cloud providers.

World map of Datacenters for Cloud Providers
World map of Datacenters for Cloud Providers

As organizations mature towards multiple cloud platforms it become necessary that these cloud providers have some clairvoyance towards a globally unified world where these data centers are created with more globally distributed locations versus being concentrated in specific geographic locations. This will connect and unify the world especially in times of dire need like what we are going through!!

That’s all I have for today. I plan to bring similar perspective to other cloud options like storage, databases (relational or otherwise), big data analytics, security options, IaaS, PaaS or SaaS offerings. I hope all of you find this useful.


If you are interested in other cloud certifications and how to prepare for them, check out our website.

Have questions? Participate in Cloud discussions on our Forums. Click here.

More from same author:

AUTHOR: Mukesh Sharma is a multi and hybrid cloud enthusiast with a bias for building robust hybrid cloud systems around mainframes for financial services organizations. You can reach him on LinkedIn