Unlock the Hidden Power of VPC Sharing in AWS
Tags: aws, vpc
Published: 2023-05-22 19:40:13

As rightly stated [here](https://awsteele.com/blog/2022/01/02/shared-vpcs-are-underrated.html) by Aidan Steele (AWS Hero), VPC Sharing appears to be the forgotten superpower.

While I think it is probably more suited for the hybrid Enterprise, this article will show why we use it, its benefits, and what could still do with some work on the AWS side.

## What is VPC Sharing?

VPC sharing is a feature that lets multiple accounts use a single Virtual Private Cloud (VPC). It's like a big, virtual playground where different accounts can deploy their applications and resources, while still keeping everything neatly separated.

The cool thing is, you can have one account (the owner) manage the VPC, while others (participants) just get to enjoy the benefits.

## The Why

Everyone is all in on the multi-account strategy; however, especially in typical enterprises, not everyone is responsible for looking after networking.

When I use the word networking, I'm talking VPC, Endpoints, IGW, Direct Connect, Managing IP CIDRS etc.

Quite often internal application teams want to own, run & build within a space that is already provided and, of course, that is all doable with multiple accounts, VPCs all plumbed in through a Transit Gateway, however, VPC sharing does provide another angle for this.

### Simple Example

Two application teams running workloads that need to communicate and be accessed from on-premise. A typical multi-account setup would look like this.

![Multi Account VPCs](https://cdn.hashnode.com/res/hashnode/image/upload/v1681303846288/6IS-dJ66V.png?auto=compress align="center")

A few key points about this design.

**Data Transfer Costs:** For anything that goes over the TGW we are going to get charged. We would probably be putting VPC Endpoints in each VPC so again more cost and duplication.

**Operational Overheads:** Some good security practices are going to require each application team to ensure that VPC Flowlogs are enabled, and monitored, that routes are propagated correctly and that we implement appropriate NACLs and security groups.

### Using a shared VPC

![Shared VPC Multi Account](https://cdn.hashnode.com/res/hashnode/image/upload/v1681303864973/RoJC6Pi4O.png?auto=compress align="center")

A few key points about this design.

**Data Transfer Costs:** As we are now within the same VPC, communication between App1 & 2 is only going to incur VPC data charges. If they happen to be in the same Availability Zone we get it for free.  
  
As above, for anything that goes over the TGW we are going to get charged. We would probably be putting VPC Endpoints in the VPC but again only one set as they can be accessed by both our applications.

**Operational Overheads:** Each application team is still responsible for their Security Groups however the VPC owner can now ensure that VPC Flowlogs are enabled and monitored, that routes are propagated correctly and implement appropriate NACLs for both applications.

## The benefits

**Simplified management:** One VPC owner handles the overall VPC configuration, reducing the complexity of managing multiple VPCs across accounts.

**Resource efficiency:** Share a single VPC across accounts, minimizing duplicate resources and enabling better resource utilization.

**Cost savings:** Consolidate resources and minimize network infrastructure expenses, leading to lower overall costs.

**Enhanced security:** Maintain account-level isolation while sharing a common VPC, ensuring a secure and controlled environment.

**Improved collaboration:** Facilitate seamless cooperation among teams or projects by enabling easy access to shared resources within the VPC.

## What still needs work

So there are a few points that AWS still needs to address

**Not all services support it:** This is a small list with the top offender being FSx for NetApp however anything that wants to control route table entries is going to trip you up.

**Network Access Control Lists:** The VPC Owner will need to configure these on behalf of the participants or delegate access via an assumed role. Annoying but doable.

**Security Hub Checks:** It would seem that the VPC and Security Hub team don't have a good relationship as checks like FlowLogs are enabled and use of the EC2 API Private Endpoint will show as non-compliant for all participant accounts if you have the SecurityHub Best Practises enabled.

## Summary

I hope this post has shown you another way to share resources and work together in a secure and organized way using VPC Sharing. It's a great solution for teams or projects that want to collaborate without the headache of managing multiple VPCs!

I hope this helps someone else!

Cheers