- Newest
- Most votes
- Most comments
This is a very broad question that you are asking here - as there are so many facets to consider, so I am answering broadly.
I am unsure what types of shared services you had in mind - so cannot comment definitively, however, the purpose of a shared VPC/Subnet is to allow multiple AWS accounts to create their application resources, such as Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, Amazon Redshift clusters, and AWS Lambda functions, into shared, centrally-managed virtual private clouds (VPCs).
So in your scenario - that would mean up to 10,000 different AWS accounts working in a single shared VPC.
This would not be a best practice - and dramatically increases blast radius if something happens such as a compromise to one of the resources that belongs to one account - and that compromise then affects other resources.
If your goal is to provide centralized services that can be consumed by your member accounts - then you should consider using AWS Private Link to vend services out to consumers within each of your many accounts in your organization.
For intra-account network connectivity - consider looking at transit gateway - or even CloudWAN.
...the purpose of a shared VPC/Subnet is to allow multiple AWS accounts to create their application resources, such as Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, Amazon Redshift clusters, and AWS Lambda functions, into shared, centrally-managed virtual private clouds (VPCs).
Thank you for the response. I was hoping that subnets could be shared across VPC boundaries so that the customer accounts could have their own VPCs and subnets, with an additional shared subnet added to their own. However, it sounds like they would simply be allowed to place resources in the central VPC.
Some key considerations to get this scale of 10k accounts:
- Don't rely on traditional CIDR network scheme to enforce routing everything.
- Think of each VPC and the workload inside this VPC as a microcell that is autonomous and can operate by itself without direct dependency of other VPCs
- Use VPC endpoints if you need network isolation for this particular workload and need to access to AWS services or other services that your systems provide
- Design your AWS accounts and VPCs as constructs of isolation. AWS account is your first level of domain isolation. It can be by environment, line of business or department.
- Shared services are inevitable. But using VPC endpoints or connecting them through Transit Gateways are the best path. If the network overlaps, use VPC endpoint, if not, use Transit Gateway.
But when you think about 10k accounts, it is only required when you are building a multinational or large-scale organization where:
- Isolation is more important than connecting everyone and everything.
- Data can still be shared through event bridge, S3 and other services. Networking is less relevant in modern systems.
- Probably you need to think more about ingress and egress data patterns than making all VPC's be able to talk each other.
Hi,
You don't want to share a single subnet across so many accounts: it will bring you lots of management and security headaches.
I would strongly suggest to read this excellent wp: https://docs.aws.amazon.com/pdfs/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/building-scalable-secure-multi-vpc-network-infrastructure.pdf#vpc-to-vpc-connectivity
The architecture with Transit Gateway seems more appropriate to your use case: see https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html for pros and cons.
Best,
Didier
Relevant content
- asked 10 months ago
- Accepted Answerasked 6 months ago
- Accepted Answerasked 5 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
Can you explain a little more on the services that you wish to expose in the central shared subnet?
The central service is comprised of multiple compute instances. The central service would provide compute instances in the customer account with an address to where they can create a TCP connection to send and receive messages to central service.