Large-scale public cloud services can provide good resilience if application developers take advantage of the service’s resilience features. Most cloud services deploy data centers into cloud regions and split each region into several availability zones.
Figure 17-1 illustrates the relationship between regions and availability zones.
Figure 17-1 Cloud Service Resilience
Figure 17-1 shows
• Region 1 and Region 2. These two regions represent one or more physical data centers connected by a metropolitan area network (a fiber ring or similar). Regions are independently connected to the provider’s network core and can operate without any connection to the provider. Because these regions are connected to different power grids and use independent network access, one region failing should not impact the operation of any other region.
• Several availability zones within each region. Each availability zone is connected to a separate power source (although generally on the same power grid) and has separate network connectivity. One availability zone failing should not impact other availability zones within the same region.
Providers usually build separate data center fabrics for each availability zone. These fabrics may be in the same building, on the same campus, in separate buildings within the same geographic region—or a combination of all three. In every case, availability zones are always built-in provider-owned facilities.
• Local and on-premises zones are not considered resilient and are not built-in provider-owned data centers.
• Local zones usually are built in co-colocation facilities operated by access and exchange providers but managed using the cloud provider’s software. These zones can be considered extensions to an availability zone within a region. Like a content distribution network, local zones bring data closer to users.
• On-premises zones are built on the cloud provider customer’s property. This physical hardware is owned and operated by the cloud provider for the exclusive use of a single customer. These are on-premises public cloud services.
Cloud service users need to consider regional and global resilience, how close they need their application to be to their users, and whether an on-premises solution might be better than a provider-owned physical facility.
Connecting to the Cloud
Once you have deployed a service in a public cloud, you need to send data to the service, retrieve data from the service, and allow users to connect. Network engineers will often be responsible for setting up these different kinds of connections.
Figure 17-2 illustrates different kinds of cloud connectivity.
Figure 17-2 Common Cloud Connectivity Options
Cloud providers typically provide virtual private network (VPN) and direct connections to their service.
A direct connection is a purpose-built circuit leased from a transit or access provider, connecting the customer’s and cloud provider’s network.
A VPN connection is a virtual link, normally built using IPsec, over the global Internet.
Note
Some vendors also offer connectivity to a public cloud through a software-defined wide area network (SD-WAN). SD-WAN is outside the scope of this book.
Table 17–2 summarizes the differences between these options.
Table 17-2 Cloud Connectivity Summary
Connectivity to a cloud service can also be directed at a regional data center or a separate regional hub. Cloud providers often locate regional hubs at colocation points like regional access providers and IXPs. Connecting to a regional provider has advantages, including
• Circuit runs might be shorter and less expensive.
• Suppose the customer can connect to a regional hub within the access provider they already use, or a local IXP with good connectivity to the access provider they already use. In that case, they will likely get a higher-quality connection.
The primary disadvantage to connecting through a regional hub is that they are usually built in some form of colocation facility, so the resilience of the regional hub might not be as good as the cloud provider’s data center.