I recently started creating an AWS organization with separate organizational units (OUs) for each product, resulting in four distinct products within my organization.
For each product, I have set up separate AWS accounts for both PROD and NON-PROD environments to ensure isolated workloads.
To facilitate remote working, I have configured a VPN connection using the OpenVPN Access Server in the NON-PROD account for product A.
This VPN connection allows developers to access the AWS resources located within the associated VPC.
However, I now face the challenge of sharing the VPN connection with all developers, allowing them to access AWS resources specific to each product.
I’m seeking guidance on how to achieve this. Here are my specific questions:
How can I share the VPN connection across multiple developers, ensuring they have access to the AWS resources segregated by product?
Are there any recommended best practices or AWS services that can help me achieve this goal?
What security considerations should I keep in mind while implementing this solution?
I would look at creating a dedicated networking account for this, just to keep it separate from the deployed product workloads. This account would contain a VPC to host the OpenVPN server that has connectivity to the VPCs in the other accounts via VPC peering or TGW (hopefully none of them have overlapping CIDRs).
You would then assign users to groups in OpenVPN based on the accounts they should have access to, and restrict access to the relevant CIDRs as appropriate in OpenVPN (see “Access Control” on this page).
For this scenario, When the remote developer connect the VPN so they will sit in the VPC in the “networking account” and then use “Peering connection” from this VPC to another VPC (product A account)?
Correct - by default, traffic from the developers will appear to originate from the OpenVPN server and will be automatically routed over the relevant peering connection depending on which product VPC they are trying to access.
Thank you, man! I looked into the solution suggested by you.
VPC peering is beneficial for a small number of VPCs; however, if my business will develops the product E F G H, the peering connection may be responsible for operations and tasks involving route updates.
for the Transit Gateway is excellent for addressing that operational pain point, but it is not cost-effective for my business.
The default AWS limit for peering connections per VPC is 50 (and can be increased to 125), so you shouldn’t hit any limits there. I understand your concerns about operational complexity, but ultimately your use case is relatively simple as you’re connecting everything back to a single VPC rather than trying to do a full mesh - if you standardise provisioning a new product/VPC using IaC, the overhead should ultimately be quite low.