Blog AWS Continuous Compliance
Last updated on February 4th, 2023 at 3:31pm
Do you feel like your network doesn’t quite scale like you need it to? Do you struggle with developers who alter the VPC that connects to your on-prem network or interacts with resources with which they’re not associated? These issues, and many others, can be solved by looking further into VPC sharing.
Advice on Governance at Scale and Networking
The AWS governance at scale framework prescribes that every workload should have its own AWS account. Using an account as a security and compliance, identity and access management, and financial boundary is the recommended method for achieving a well-governed cloud.
But adopting the full governance at scale architecture poses challenges in additional areas. While cloudtamer.io is a great solution to handle the financial, identity and access management, and compliance and security needs of your AWS environment within this framework, there are additional architectural considerations you must address.
Networking is one area that can be a roadblock to adopting a full governance at scale model. Often, workloads need hybrid connectivity to leverage both on-prem and cloud resources and to provide secure access from an organization to cloud resources. There are a number of methods to extend on-prem networking to the cloud, but to do this at scale can:
- Add additional complications for an organization’s networking team
- Exhaust available IP space
- Complicate network topology
How VPC Sharing Helps Governance
In January of 2019, AWS released VPC sharing ability for subnets between AWS accounts using Resource Access Manager (RAM). The ability to share networks securely between AWS accounts allows you to “have your cake and eat it too” by delivering a simplified, maintainable network architecture and adopting a governance at scale cloud posture.
At cloudtamer.io, we see many organizations' cloud topologies structured into different organizational units where each organizational unit needs a development, test, and production AWS account. In each of these accounts, a VPC is created and configured so that it has on-premise connectivity either via a direct connect, a VPN, a transit gateway, or other method to create an on-prem connected VPC. Customers then put multiple workloads into that on-prem connected VPC, causing security, budgetary, and identity and access management challenges.
Using VPC sharing, we can still create our development, test, and production networking AWS accounts. However, instead of putting multiple workloads in each account, we’ll put nothing but the networking in them.
In order to put workloads in these networks, we recommend following governance at scale best practices and creating additional AWS accounts for each workload. To place workloads in the network, you can share the appropriate VPC subnets with each additional AWS account you created that needs to leverage that networking.
VPC Sharing Benefits
Sharing VPC subnets has some significant benefits over having one account with multiple workloads running in this account. These are:
Governance at Scale
To begin, you get the benefits of governance at scale without the complications that can arise when networking doesn’t quite scale like you need it. For many companies, this benefit alone is enough to prove their need for VPC sharing!
Selectively Share the Subnets with Specific AWS Accounts
Second, you can selectively share the subnets with the AWS accounts in which you’ll run your workloads. Doing so improves the security and compliance for these accounts. For example, if you have a network with public and private subnets and you have an application that shouldn’t be exposing resources publicly, you can easily enforce compliance by not sharing the public subnet with that particular AWS account.
Prevent Alterations to the VPC
Finally, you don’t have to worry about writing complicated IAM policies to prevent developers from altering the VPC that connects to your on-prem network or interacts with resources with which they’re not associated. Changing the on-prem connected VPC can have a significant impact to your environment. The best way to protect against unwanted alterations to the VPC is to not allow anyone but your networking team access to the AWS account in which it lives. Additionally, the principle of least privilege dictates that end users should have access to only what they need to do their jobs -- something made easier by adopting this networking architecture.
VPC Sharing Caveats
There are some caveats to using subnet sharing via RAM:
#1 Not all services are supported. Currently, participant AWS accounts with which subnets have been shared can’t create a CloudHSM or a FSx in shared subnets. Update: In late February 2020, AWS announced support for FSx in shared VPCs.
#2 Sharing must be between accounts within an organization, and sharing must be enabled within that organization.
#3 You can’t share subnets that belong to the default VPC in an account.
While you should consider these caveats for your individual workload, the ability to keep networking simple while adopting governance at scale is a big win for an organization.
Start your cloud enablement journey and request a demo today!
