1. Home
  2. Training Library
  3. AWS Networking and Virtual Private Cloud (VPC) (ANS-C01)

Introducing VPC Sharing

Contents

keyboard_tab
VPC Fundamentals
2
What is a VPC?
PREVIEW2m 25s
VPC Security and Control
VPC Connectivity
VPC Sharing using the AWS Resource Access Manager
Feature Spotlight:
Introducing VPC Sharing
Overview
Difficulty
Advanced
Duration
2h 44m
Students
174
Ratings
5/5
starstarstarstarstar
Description

In this section of the AWS Certified Advanced Networking - Specialty learning path, we introduce you to the various networking and VPC services currently available in AWS that are relevant to the ANS-C01 exam.

Learning Objectives

  • Identify and describe the various networking services available in AWS
  • Describe how to configure an Amazon Virtual Private Cloud (VPC)
  • Understand how to control network traffic via Security Groups and Network Access Control Lists (NACLs)
  • Describe options for VPC connectivity, subnets, and routing
  • Understand how to share VPC resources using the AWS Resource Access Manager (RAM)
  • Identify how to evaluate the configuration of VPC resources using the VPC Reachability Analyzer

Prerequisites

The AWS Certified Advanced Networking - Specialty certification has been designed for anyone with experience designing, implementing, and operating complex AWS and hybrid networking architectures. Ideally, you’ll also have some exposure to the nuances of AWS networking, particularly regarding the integration of AWS services and AWS security best practices. Many exam questions will require advanced level knowledge of many AWS services, including AWS networking services. The AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.

Transcript

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.

 

About the Author
Students
207448
Labs
1
Courses
211
Learning Paths
163

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.