There was team looking for sharing VPC on AWS. This was a new concept for me, have done VPC peering on Azure and cross account and peering on AWS. The AWS sharing was something new concept. I knew it existed . So, based on all documents its looked like it will need to be setup at organization level. This is a security non started as you cannot have it enabled at organization level as it had both dev and prod accounts.So, my research led me to service control policies on AWS.
Amazon Web Services (AWS) customers who establish shared infrastructure services in a multi-account environment through AWS Organizations and AWS Resource Access Manager (RAM) may find that the default permissions assigned to the management account are too broad. This may allow organizational accounts to share virtual private clouds (VPCs) with other accounts that shouldn’t have access. Many AWS customers, such as those in regulated industries or who handle sensitive data, may need tighter control of which AWS accounts can share VPCs and which accounts can access shared VPCs. As a security best practice, cloud administrators should follow the principle of least privilege and use granular controls for VPC sharing.
AWS RAM provides the ability to share VPC subnets across accounts. This helps to leverage the implicit routing within a VPC for applications that require a high degree of interconnectivity. VPC subnet sharing across accounts allows individual teams to co-locate their microservice application stacks in a single VPC, and provides several advantages:
- Easier administration and management of VPCs in a central network account.
- Separation of duties—in other words, network admins retain control over management of VPCs, network access control lists (network ACLs), and security groups, while application teams have permissions to deploy resources and workloads in those VPCs.
- High density of Classless Inter-Domain Routing (CIDR) block usage for VPC subnets and avoidance of the problem of CIDR overlap that is encountered with multiple VPCs.
- Reuse of network address translation (NAT) gateways, VPC interface endpoints, and avoidance of inter-VPC connectivity costs.
Refer: link
Use service control policies to control VPC sharing
In the scenario we described earlier, cloud admins want to allow VPC sharing with the following constraints:
- Allow only VPC subnet shares created from a network account
- Allow VPC subnet shares to be shared only with certain OUs or AWS accounts
You can achieve these constraints by using the following service control policies.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "OnlyNamedAccountsCanShareSubnets", "Effect": "Deny", "Action": [ "ram:AssociateResourceShare", "ram:CreateResourceShare" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": [ "<Networking AWS Account ID>" ] }, "StringEquals": { "ram:RequestedResourceType": "ec2:Subnet" } } } ] }