Show Notes
A podcast about cloud adoption and cybersecurity.
Website: https://www.globaltech.tv/
Social networks: https://linktr.ee/globaltechtv
View Full Transcript
Episode Transcript
[00:00:02] Hello everyone and welcome to another episode of global Tech TV. In the previous episode, we talked about cloud computing, specifically about the shelf responsibility model and cloud service model such as Iaas, SaaS and PaaS. Today we're going to talk about cloud infrastructure terminology and the first concept is called a region. What is a region? Region is a physical and more specifically geographic location made out of multiple data centers connected with each other with a fast network connectivity. If we're looking at AWS specifically Dell standard of region is at least three data centers or availability zones per region.
[00:00:48] Azure has their own concept called paired region.
[00:00:53] To achieve high availability in case of major failover in one of the region, they replicate data to another closed region. For example, east Us is paired with west Us and north Europe is paired with west Europe.
[00:01:12] Example of region names AWS has Us east one which is Virginia, Azure has North Europe which is in Ireland, and Google has Europe Westry which is in Frankfurt.
[00:01:25] What are availability zones? So availability zones are one or more data centers with their own redundant power, networking and connectivity to each of the other availability zones in the same region. AWS and Azure call this concept availability zones or Azhortez. In Google Cloud platform we simply call it zones.
[00:01:49] When we deploy a resource such as a virtual machine or database, we need to select a target region and a target availability zone. Although from a customer point of view we can select an AZ in a specific region from a list, which may get updated from time to time as the cloud expands its presence in specific region.
[00:02:10] All we know are the AZ names or numbers for resiliency, availability and capacity reservation purpose. Even if two customers decide to select the same AZ name, the cloud provider may choose to allocate the resources for each of the customer in different physical data centers. To avoid a scenario where all customers choose the same AZ and the specific data center will run out of resources, why should we care about availability zones? So in order to create resilient infrastructure for our production applications, we need to design accordingly by deploying multiple instances of our application different components like virtual machines and database etcetera in different availability zones to decrease the risk of failure and the impact on our customers.
[00:03:05] Why is it important to understand regions and availability zone?
[00:03:10] So most resources deployed in the public cloud are considered regional, meaning when we deploy them, we need to select which region we want to deploy them at.
[00:03:22] Due to this built in limitation, data may not be automatically synced across regions. For example, if we choose to deploy a database in a european region, the data will not be synced to a US. Regions automatically unless we specifically design our architecture to allow data sync, which is not the default scenario.
[00:03:47] Are there any other concepts relate to the physical infrastructure? So specifically who are looking at AWS? They have two additional concepts. One of them is called local zones, AWS local zones a position, compute, storage and database, and other selected AWS resources near major population and industrial hubs. These setups allows us to deliver low latency access to our application for users in those specific areas.
[00:04:21] Another concept that exists only in AWS is called AWS wavelength zones.
[00:04:28] Wavelengths empowers developers to create applications with minimal delay for mobile devices end users by position standard AWS compute and storage capabilities at telecom providers 5g networks. These setups allows developers to expand their virtual private cloud into wavelengths where they can leverage AWS resources such as EC two instances to operate applications that demand extremely low latency while maintaining connectivity to regional AWS resources.
[00:05:06] So now that we understand the physical layer, let's move up in the stack and talk about virtual private networks or vpcs. So each of the cloud providers has its own concept of virtual private network or a VPC. A VPC is a logical presentation of a network environment where each customer deploy his resources such as compute, storage, database and more.
[00:05:33] When we deploy an account in a cloud in one of the cloud providers, we receive a virtual private network with a range of IP addresses for the resources that we will later on deploy it. Each virtual private network contains a multiple subnets, one for each availability zone.
[00:05:53] Each subnet contain a small portion of the virtual private network IP address range.
[00:05:59] In AWs we call this concept AWS VPC. In Azure it's called Azure Vnet or Azure virtual network and in Google simply called Google Cloud VPC aside, more specifically for Azure they have a concept called a resource group which as the name implies is grouping of multiple resources. In Azure we first need to create a resource group and only then we can create an Azure VNEt and deploy resources inside this VNet.
[00:06:33] Question been asked are we limited to a specific virtual private network per account? So the answer is no. Although there may be limitations for each cloud provider other than the default VPC through receive, when you create a new account in the cloud, we can manually create additional virtual private networks with your own IP addresses.
[00:06:56] Although not recommended, we can create several virtual private networks for segmentation between different applications, different customers, and between different stages of the same application such as environment for DeV, for test and for production.
[00:07:15] Can we connect between virtual private networks in different accounts? So the answer is yes. We can configure what is referred to as a VPC peering, we reconfigure network connection between two vpcs located at the same region, which allows us to share resources.
[00:07:33] An example for resource sharing, we can create a specific VPC just for management services, for example backup monitoring, anti malware, patch management, and we can create another VPC per application and then we can peer between those two vpcs, which will allow the customer accounts or customer vpcs to be able to share resources or consume resources from the shared VPC for their management services.
[00:08:06] Something we do need to recall regarding vpcs is that vpcs are not transitive. Meaning if we have three VPCs, VPC A, VPC B and VPCc.
[00:08:17] If we would like to make sure that all the vpcs can communicate between each other and share resources and consume resources, we need to configure VPC pairing between each two vpcs in a mesh topology so that each VPC is able to communicate with the rest of the vpcs in the network.
[00:08:43] So in this chapter we talked about the physical and logical infrastructure as a base to understand how the public cloud are built. In the next chapter we will begin talking about cloud basic building blocks, which is compute services.
[00:08:58] As always, you're welcome to follow us on social media at global Tech TV. Feel free to write to us, ask question and suggest future topics for discussion. See you at the next episode. Bye.
