O'REILLY 3 AWS Networking Services The odds are 100% that you will be using networking services at AWS. Networking at AW‘ his -VP called the virtual private cloud, or Et chapter explores in detail the available networking options for virtual private clouds (VPCs) and how they are set up and configured at AWS. At the end of this chapter, you will have a strong understanding of VPCs, net- working services and options available, and understand the necessity of properly planning your networking services. The reality is that you may need to read this chapter a few times to be- come comfortable with the networking services at AWS. There are a few changes when setting up and managing networking in the cloud even though the terms might look familiar. In the previous chapter, we looked at the big picture of regions and zones, and edge locations—the bedrock services at AWS that we really can’t touch. Networking at AWS, the subnet is the lowest level we can gain access to, and it’s all at a virtual level. Yes, there is a physical network at AWS, but we don’t get to access it directly. Starting with the lowest point of the stack that we are allowed to control, let’s get into networking. One of the first configuration questions that will be asked of you when or- dering an EC2 instance; AWS WorkSpaces, their hosted VDI solution; or RDS, their hosted database solution is this question: what VPC or what subnet do you want to use? The topics for this chapter include the following: * VPC networking © Subnets and IP address types * Route tables * Security groups and NACLs * VPN connectivity options * Route 53—the domain name system (DNS) serviceQuestions we will ponder and reflect on for this networking chapter focus on our case study Terra Firma and its human resources customer rela- tionship management (CRM) software system. To recap, the company’s current CRM system was developed in-house several years ago and is run- ning successfully on VMware server images in the corporate data center. Other details include: * Management agrees that the current HR system must be migrated to AWS as soon as possible. + The company’s HR system needs to be able to properly scale to handle the increased demand of upper management. © The human resources system must be available 24 hours a day and needs to be accessed across the Internet and from corporate head and branch offices. Some of the questions they need to get answered include these: 1. How many VPCs should Terra Firma consider using? 2. How many AZs should Terra Firma use to design for failover? 3. How many subnets should Terra Firma use? 4,Do the Web servers need public or private IP addresses? 5. Can we privately access AWS resources from within a VPC? 6. Are NAT services required? 7. Compliance rules mandate security at the subnet level. Is that possible at AWS? VPC Networking The networking layer at AWS is a VPC, and we generally work with net- working services using the VPC console, as shown in Figure 3-1. The offi- cial name of a VPC is an EC2-VPC, even if we typically just use the VPC moniker. The EC2 (Elastic Cloud Compute) designation indicates that EC2 instances are usually hosted within a VPC. Each VPC is a logically isolated “data center” where your computer instances and various AWS services reside. Software that can run successfully on a Windows or Linux virtual server can be hosted on EC2 instances hosted in VPCs running asWeb/application servers, databases, NAT servers, or any third-party soft- ware appliance you can think of. vec Dashboard 5 Service Health rer Qseecs Launch £63 stan carer seus becne ‘iar oe Yn nn nb US Eo gi en fa 2 EatSos y oud Resources by Region ‘ew como ee eat eas sues Account Attributes aon ia | |conmnony was sgesow nana ‘Additional Information oercmeom Gam ana itn Figure 3-1 The VPC console When you order a VPC, AWS’s job is securing your VPC as a private iso- lated software data center linked to your AWS account. AWS’s job is to provision, host, and secure the VPC; the rest is up to us. There is also plenty of AWS management going on below the surface of a VPC; your network traffic must be routed and protected based on your network de- sign and needs. In addition, Amazon must ensure the continued separa- tion of your VPC from all other AWS customers. Any failure on Amazon’s end in safeguarding and protecting VPC networks just can’t happen. There are lots of moving parts and pieces at AWS, which I like to describe as a large toolbox containing a variety of tools and attachments that you can mesh or cobble together any way they suit your needs. Within the VPC “toolbox” are many configurable options, including route tables, pub- lic and private subnets, VPN connections, gateways, and private end- points, to name just a few of the available options. In addition, there are multiple security choices available at every network level allowing you to fully protect your EC2 instances; choices include security groups and net-work access control lists (ACLs). A VPC also has multiple connectivity op- tions, allowing you to connect your VPC to the Internet, to your own pri- vate data center, to other VPCs within your region or outside your region, or to other AWS accounts holders’ VPCs. Partnering with AWS Hosting your applications in the Amazon public cloud means you have implicitly accepted to work in partnership with AWS in what is typically defined as a shared security model. AWS has responsibilities of building and securing its cloud infrastructure; this is typically defined as Security of the Cloud, Your responsibility as an AWS customer is to design accept- able security provisions for your applications and data hosted within the AWS cloud. The level of acceptable security provisions is entirely your choice. The definition for the customer’s responsibilities of securing their resources at AWS is called Security in the Cloud. Customers can choose to use any of the managed services and utilities provided to accomplish their deployment and security goals. Within each VPC, your compute in- stances (EC2) are hosted on subnets that you create in selected availabil- ity zones (AZs) within the AWS region you chose to operate within. Although the VPC is a managed service, customers make most of the choices and decisions on their own after AWS carries out the initial cre- ation of the VPC. Because a VPC is defined as a virtual private network (VPN), it’s easy to forget sometimes that you're still participating within a shared environ- ment when hosting applications in the AWS cloud. AWS customers all share the private network backbone linking shared compute, storage, and services, as shown in Figure 3-2. Of course, the one issue you don’t want to experience in the AWS cloud is an unexpected loss of privacy.Mie DBinstance DB instance star 0 O-e Instance Instance ‘Amazon Amazon Elastic Elastic Block File System Store AWS AWS AWS Certificate Identity Trusted Manager ‘and Access Advisor ‘Management AWS ‘Amazon AWS GloudTral ——_GloudWatch Auto Sealing Figure 3-2 AWS networking concepts Amazon's private global network that hosts all the VPCs has terabytes of networking capacity available. AWS also owns and operates all the fiber connections connecting their data centers, AZs, regions, and edge location equipment together. However, the networking services that are exposed to each customer at AWS are not running on the same network hardware devices that are deployed in your own data centers. Some of the network- ing service terms we are going to define may also be new to you. And some of the other networking components that are utilized at AWS will hopefully sound familiar—terms like subnets, public and private IP ad- dresses, and route tables. But you will find that your overall design of net- working services at AWS will still be different from what you would use on-premise, Hosting hundreds of thousands of customers in a massive shared networking environment means networking can’t be the same asyour on-premise network due to the size and scope of Amazon’s overall operation. Note If you're a new customer at AWS, the VPC is the only net- working choice currently available for hosting your work- loads. There used to be another networking option available at AWS called EC2-Classic, We won't be spending any time on this older style of networking because you don’t want and can’t access EC2-Classic networking; it hasn’t been available for new customers since December 2013. And you wouldn’t instead of a VPC. To begin with, EC2-Classic want to use networking was a flat network design that was shared with all other EC2-Classic AWS customers. The EC2-Classic feature set available is quite minimal compared to the expansive op- tions available with a VPC. However, your company may have EC2-Classic networking if it began working with Amazon before 2013. To Host or to Associate? Some services can be hosted within a VPC, and others can be associated to a VPC. There are many additional AWS management and compliance ser- vices that you will probably want to use. Some of these services will have relationships with the services and components hosted inside a VPC, but the services themselves are not actually installed in the VPC. AWS services such as AWS Config (a compliance tool) and ELB (Elastic Load Balancing) aren’t installed or hosted within a VPC; instead, they reside on the private or public Amazon network and, once ordered or selected, are then associ- lists ated or linked to the chosen VPC carrying out their task. Table several examples of AWS services that are either hosted or associated with a VPC. Table 3-1 AWS Services That Host or Link to a VPCHosted VPC Services Associated Services EC2 instances Trusted Advisor Elastic Beanstalk AWS Config Amazon Redshift VPN connections ElastiCache Auto Scaling Amazon EMR Elastic load balancing Amazon RDS $3 Amazon Workspaces DynamoDB The reality is that most of Amazon’s offerings are not actually installed in- side a VPC. The primary service hosted in a VPC is the EC2 instance. What’s Behind the Networking Curtain? How is it possible to manage thousands of customers who require hosted private networking services? To complicate this reality, customers change their minds all the time. It's a daunting task. Customers who order a VPC are working within their own private walled garden of virtual network- ing. The first major concept of networking at AWS is that within each VPC, the networking exposed to each customer is designed and managed at the subnet level—specifically, the Layer 3 subnet address space con- tained within each availability zone. That's as deep as we're going to get in the network stack at AWS. Full stop. Your on-premise networking environment is probably composed of vir- tual local area networks (VLANs), Layer 2 networks, and Multiprotocol Label Switching (MPLS) connections. Why does a customer’s exposure to the AWS network then start and end at Layer 3? Because thousands ofcustomers are running on a massively shared network infrastructure, and AWS is running at a scale that far exceeds the scale utilized within your own data centers, As a result, the internal network design offered to each customer needs to be different as well. AWS is not using VLANs on the internal private network because these technologies cannot scale to the number of customers that Amazon hosts. AVPC also doesn’t use MPLS for communications; however, you may be utilizing MPLS connections when connecting to a VPC using an external Direct Connect connection from your on-premise network to AWS. You can find more details on external VPC connections later in this chapter. If you have worked with public cloud providers for several years, you may have experienced ordering networks with an email request and waiting a few days to get set up; or perhaps you waited just a few hours. Waiting a few hours or even days might be acceptable within your own data center. In the hosted public cloud, however, we demand and get cloud resources instantly. Amazon had to figure out a way to combine scale, automation, and instant gratification, and they did. Ordering a VPC takes seconds; if a VLAN had to be set up for each customer network, the process would ulti- mately take too much time and, as discussed, not be able to scale as required. Note If you expect to design a VMware-like network utilizing a stretch layer 2 network design at AWS, it’s technically possi- ble between two separate AWS data centers, but it is not rec- ommended. For example, each data center has separate power and cooling, and you don’t have access or control of these components at the physical layer; that’s Amazon’s do- main, What happens if a connection goes down between the two stretched data centers? There are multiple redundant connections between the data centers at AWS, but again, the customer does not have access to the physical components or connections between AWS data centers.Each VPC is a software-defined network built on Amazon’s own code and custom network hardware developed by AWS to match its required scale of network operations. There are two networks at AWS: the real physical network that is maintained by AWS, along with physical switches and routers and familiar networking components. The underlying physical network at AWS would be quite recognizable component wise. However, we don’t have access to the physical network; that’s the folks at AWS’s job. It may be obvious, but I’m going to mention it anyway: each VPC runs on top of the physical AWS network infrastructure. Your instances are running on a hypervisor installed on custom-designed bare-metal servers, as shown in Figure 3-3. The standard hypervisor AWS used was a customized version of XEN for a number of years, but many changes are happening. For several instance types—the C5d (massive computer-optimized instances), the MSd (massive memory-optimized in- stances), and the new, bare-metal EC2 instances—AWS has moved to what is called the Invocation platform with the Nitro system. Nitro is a custom- ized version of the KVM hypervisor with a published benchmark of le: than 1% when comparing virtual EC2 instance performance to bare-metal system performance. Nitro systems are also matched with a customized Nitro security chipset that monitors the firmware and hardware at boot, supports enhanced networking, and has NVMe block storage specifically designed for access to high-speed local storage over a PCI interface with transparent encryption provided on the fly by hardware processes. Scotty, I need more power! Wait a minute. I’m more than okay. we |[ eee |[ em || eee °°? Instance |} instance || instance || Instance £a ‘Nitro Hypervisor KVM) 1 Software Platform ag warvor | venegenent| | storage jo =] Chipset |] Encryption || Shipset f(s Monkoring ae] Custom Hardware Chipsats |_| &Figure 3-3 Instances hosted by the hypervisor Note If your job involves managing VMware and Hyper-V hypervi- sor, you have no exposure to the hypervisor at AWS. Maintaining and operating the hypervisor is Amazor’s job. Therefore, customized bare-metal servers host multiple AWS customers and their EC2 instances, and all instances are hosted on VPCs. And there are approximately 80,000 bare-metal servers residing in a typical AWS data center. For many years when the hypervisor of choice was XEN at AWS, an emulated software router providing additional security resided just below the hypervisor. However, on the latest and greatest Nitro plat- form, a hardware router is directly embedded in the physical host. These routers sitting below the hypervisor provide the majority of VPC function- ality and at a much greater speed. It’s All About Packet Flow I find that reducing the concept of the network to the packet level a sim- ple, functional way of thinking about networking at AWS. You have pack- ets that need to be sent from a specific EC2 instance, on a specific subnet, from a specific VPC, to a specific destination or location. At the subnet is where routing decisions are performed for the EC2 instances on each sub- net. For example, instances may need access to the Internet, access to the head office, or access to data records stored somewhere on the AWS network. How’s each packet going to get to its preferred destination? The answer is through those specialized routers/routing services hosted on each bare- metal server and some custom external hardware. Before each packet ex-