VPC Security and Control
Basic Networking Concepts
Introduction to AWS PrivateLink
VPC Sharing using the AWS Resource Access Manager
Inter-Regional and Intra-Regional Communication Patterns
Understanding Direct Connect, Implementation and Configuration
Understanding AWS Direct Connect - Connectivity Options
Examining AWS Routing
DNS & Content Delivery on AWS
Managing Public and Private SSL/TLS Certificates using AWS Certificate Manager
The course is part of this learning path
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!
- 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 section, we will discuss what VPC sharing is and the benefits of VPC sharing. When I first started working in cloud computing, I read a lot about delegation, empowering teams to work independently to build their own resources in the cloud, from deploying their own cloud networking services to deploying their own virtual machines and applications. The idea was that if a team could just get on with things, it would free up our time to work on the next innovative project and optimize existing deployments.
However, it quickly became clear that even cloud computing, certain services would be best centralized, centralized so that we can provide consistent security that meets our business requirements, consistent adherence to compliance standards, and consistent and appropriate networking configurations. In short, some services should be managed by centralized specialized teams so that a secure, scalable, and robust cloud foundation can be deployed that are different teams and business units can then use. A good example of this is the centralized creation and management of VPCs. Without VPC sharing, administrators of each AWS accounts are responsible for creating the VPCs they need.
Administrators of AWS accounts are responsible for assigning cider blocks of their VPCs, managing security of their VPCs, managing connectivity between their VPCs and more. Let's think about this for a second. What could go wrong? Well, maybe a team not trained in networking might use overlapping IP ranges. This will make it difficult to connect their VPCs to over VPCs all on-premise in the future, or a team not trained in security might misconfigure network access control lists, making their VPCs vulnerable to attack. By centralizing the creation of VPCs and then sharing those VPCs, we can eliminate issues related to misconfigurations, make sure security best practices are followed, and remove the burden of VPC creation from application teams.
I think it's important to know that although this feature is called VPC sharing, what we're actually doing is sharing subnets in the VPCs along with VPC level resources. We are sharing these subnets and VPC resources with other AWS accounts in our AWS organization. When working with VPC sharing, we have the VPC Owner and the VPC Participant. The VPC Owner is the AWS account that has created and shared the VPC. The VPC participant is the AWS account that has been given shared access to the subnets in the VPC. Subnets and VPC can be shared with multiple VPC participants. VPC owners are responsible for the administration of VPC level resources such as subnets, route tables, network access control lists, VPC peering connections, Internet, NAT, Transit and Virtual Private Gateways.
VPC Endpoints and Endpoint Services, and also the enabling of VPC flow logs for the VPC and subnets. VPC Participants are responsible for the creation and administration of resources they wish to deploy to subnet shared with them. Resources such as EC2 and VPC deployed resources such as RDS instances, security groups they will use with their resources, and ENI specific flow logs. If you are going to use VPC sharing, the best practice is to create a dedicated networking AWS account where VPCs are created, secured, and shared. There are lots of use cases for VPC sharing such as cost optimization. Imagine a scenario where we have three AWS accounts and each of these accounts have a VPC with private subnets and deployed EC2 instances that require Internet access.
In this scenario, we would need three NAT gateways. One for each AWS account VPC to allow Internet access from the private subnets. However, if we used a shared VPC instead, we can create public subnets in the VPC we've deployed NAT gateways and then share subnets with each of our three AWS accounts. The shared subnets will have access to NAT Gateways because of the shared VPC route tables. 1 NAT Gateway instead of three, thus reducing costs. Network segmentation. It's common for organizations to use separate VPCs for different compute environments. For example, VPCs for development and production and perhaps a VPC for security services such as AWS Network Firewall.
If we have three AWS accounts and each requires the same three environments, that would mean nine VPCs in total that need managing, securing, and monitoring. With VPC sharing, we can reduce this to just three VPCs. VPC 1 for development, VPC 2 for production, and VPC 3 for security services. We would create these VPCs in a fourth AWS account dedicated to networking services. In VPC 1 and 2, we can create subnets for our three AWS accounts and share them appropriately. In VPC 3, we would create resources such as AWS Network Firewall. We would also deploy AWS Transit Gateway into our networking services AWS account so that when required, we can attach VPCs so they can route to each other and so that traffic can be routed through the AWS Network Firewall.
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.