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.