Regional Communication


Course Introduction
VPC Fundamentals
What is a VPC?
PREVIEW16m 20s
VPC Security and Control
VPC Connectivity
Introduction to AWS PrivateLink
VPC Sharing using the AWS Resource Access Manager
Understanding Direct Connect, Implementation and Configuration
Why Direct Connect?
5m 25s
Understanding AWS Direct Connect - Connectivity Options
7m 3s
Examining AWS Routing
AWS Default Routing

The course is part of this learning path

Regional Communication
3h 55m

This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam. 

Want more? Try a Lab Playground or do a Lab Challenge

Learning Objectives

  • Get a foundational understanding of VPCs, their security, and connectivity
  • Learn about VPC sharing using the AWS Resource Access Manager
  • Discover inter-regional and intra-regional communication patterns in AWS
  • Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
  • Understand routing in AWS, including static and dynamic routing
  • Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
  • Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront

In this lecture, we will outline some of the options for inter and intraregional communication. Intraregional communication refers to traffic that stays within a region. Interregional communication refers to traffic that is sent between regions. Almost all services in AWS are regional services. This includes VPCs and resources you deploy to them. Because of this, we have some questions to consider. First, if we deploy resources for VPC, do these resources need access to the Internet, your offices, or resources of the regions?

Next, do we need to connect resources in different VPCs? If so, are those resources in the same or different regions? And do we need to access AWS services from the resources we have deployed to our VPCs? Answering these questions will help us determine the resources we need to deploy and configure to facilitate the correct communication. When you create a VPC in a region such as EU West 2 and create subnets in each of the availability zones in that region, resources deployed to them can communicate automatically. For example, two EC2 instances deployed to different subnets in different availability zones would have no trouble routing traffic to each other through the default route created when the VPC was created.

The traffic between these instances is encrypted and stays on the address backbone even when that traffic is traveling between data centers in the same region. If the resources you have deployed to your VPC need Internet access, we will need to deploy Internet gateways and perhaps NAT gateways. If the resources you've deployed to your VPC need to access your offices, we might use site-site VPNs or Direct Connects. Deploying all of our resources in a single VPC simplifies communication, but there are plenty of reasons why you might need to deploy resources to multiple VPCs. Reasons like isolation. 

Resources might need to be isolated from each other. Using multiple VPCs for this, either VPC is in the same or different regions is ideal because by default communication isn't enabled between VPCs. Multi-region deployments. VPCs are regional, so if you need to deploy resources such as EC2 instances to multiple regions, then you will need multiple VPCs. If you need resources in each VPC to be able to communicate each other regardless of whether the VPC is in the same region or not, you will need to implement either VPC peering, transit gateway, or customer-managed site-to-site VPNs.

Of these, customer-managed site-to-site VPNs are the least desirable as they route traffic between the VPCs through the Internet. Whereas VPC peering and transit gateways keep all the traffic on the AWS backbone. One advantage of customer-managed site-to-site VPNs is that you can control the protocols that your connection uses for authentication, integrity checks, and encryption. When using VPC peering, you have no control of security protocols use to secure traffic. When using transit gateways, you must use IPSec. 

It is desirable to keep as much traffic as possible on AWS's networks. When connecting multiple VPCs, VPC peering and transit gateway keep traffic on the AWS backbone. When traffic is traveling between your VPCs and AWS services such as S3 and DynamoDB, you can use the public endpoints of these services. But to keep your traffic on the AWS backbone and away from public networks, we can use VPC endpoints. Most organizations will use a mixture of these technologies for inter and intraregional communications, but to understand which technologies are correct for you, you will need to understand each technology in a bit more detail.


About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.