- Le plus récent
- Le plus de votes
- La plupart des commentaires
Thank you for more input! Now I can see how the 200 subnets/VPC and 100 Participant accounts per VPC sharing could be a problem.
You can still make it work. I suggest you contact support and see the max subnets you could get per VPC (I doubt you will get 10,000) - pick your initial CIDR to be /16, so you have enough room in each subnet to assign IP to your workloads.
- Have your Main App and all the infrastructure resource in one VPC - enable your endpoint service for the App resources
- Create a separate VPC where you have the subnets to share with each accounts(mapping to each of your customers); have a separate subnet in the VPC where you drop the Endpoints pointing to your application in the main VPC.
- Now, every time you hit the max quota for subnets/VPC (whatever support allows you to, along with sharing quota), you just create a new VPC with shared subnets (for new customer); again, just have one reserved subnet in that VPC with Endpoints pointing to your application in the main VPC.
- With this, you could get by with VPC peering and zero transfer cost if you keep everything in one AZ (of course, a risk to consider for your App)
BTW: You still have network reachability within and among the subnets in your VPC - Yes, you could use SG in each subnet to protect your workloads, but to achieve true segmentation, you might want to use network ACL to prevent subnets from reaching each other.
I would try testing the above during this week on my end and advise if you don't do it before me.
Can you, please, add a little more input onto your ask - illustration/diagram for your scenario? I didn't quite get what you meant by the statement below in this context:
I need to communicate privately between customer account VPCs and the main VPC The main purpose of VPC sharing, beside the ability/ease to centrally managing resources, is sharing subnets with other account participants , which in turn give them the ability to create/modify/delete resource in the shared subnets for their Apps...
Let's assume you manage to create that many subnets in the Main shared VPC (since you want to assign one subnet per customer - aiming for 10,000), the segmentation alone could be a nightmare - the quota for the number of rules per network ACL alone could be a problem (20 entries with max quota of 40)
So, if your ask revolves around connecting multiple VPC as mentioned in your question - "...between customer account VPCs...", then you might have to look a the transit gateway for that - TGW. You could try achieving the scenario with the below:
- Configure the main VPC
- Configure a separate VPC for each subsequent account
- Configure another VPC for "Inspection/security/segmentation", where you can drop in there an appliance such as a firewall to make sure customer resource is really protected.
- Plan your associations and routing in your TGW carefully.
- Remember the 5000 quota for attachments per transit gateway can't be increased.
My goal is to create a main organization account with some resources within a VPC that handle incoming requests. NLB and Fargate to be precise. From there, the requests will be routed to another AWS account within an organization. Ideally, I would like this to be done without traversing the public internet.
The main purpose of VPC sharing, beside the ability/ease to centrally managing resources, is sharing subnets with other account participants , which in turn give them the ability to create/modify/delete resource in the shared subnets for their Apps...
Yes this is my goal, as I am using sub accounts within the organization for isolation and also to manage hard quotas per customer. My application is the organization managing account, and when new customers are created, an AWS account is also created within the AWS organization so I can manage the customer's resources on their behalf.
I don't think segmentation would be that much of an issue as VPC sharing only allows the participant to only launch resources with security groups that they own. So all the access rules should be logically stored within each account.
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html
Contenus pertinents
- demandé il y a un an
- demandé il y a un an
- demandé il y a 6 mois
AWS OFFICIELA mis à jour il y a 2 ans- AWS OFFICIELA mis à jour il y a 6 mois
Thanks for the awesome feedback. I will reach out to Support to see what the limitations are. Thank you again!