Design Better Networks: Integrating Account and Network Layers in AWS Design

99% of people who start to build in AWS are going to build a VPC and start dropping in compute resources to get going.

And why not? AWS makes it ridiculously simple to do just that. I think that low friction approach to building is what makes it a great platform.

Where this becomes problematic is when that usage begins to get serious. Suddenly we're introducing both internal and external customers, more complex identities and traffic patterns, and that infrastructure now becomes not only unwieldy but also a huge vulnerability.

If you're going to build serious infrastructure on AWS, you have to start with the account layer first.

This isn't intuitive to the network engineer because there isn't an equivalent in the datacenter. While you might compare the account layer to controlling access to a router or switch or a whole stack of equipment, it's more like controlling access to all of that in the first place.

What I mean by the account layer to be clear is the actual account structure of AWS. You define an Organization, which is made up of Organizational Units, and within those are accounts. Those accounts define actual permissions boundaries for identities within AWS. Accounts are much bigger than just infrastructure!

Example architecture with a central networking account

The network layer on the other hand does not do that. The network layer is just that--a layer where you can control how traffic moves between workloads in AWS. You can tie yourself in knots trying to segregate your networks and do every possible security modification to make them more secure, but a user with inappropriate levels of access can still wreck a whole network infrastructure easily.

Building a network in a single account is a recipe for disaster. It extends the blast radius to the entire account! Whereas if you design with account structure in mind, you can easily limit that impact.

One of the best ways to get off on the right footing is to set up a Landing Zone first. By intentionally creating an account structure for your environment, you're ensuring that future growth and development will make use of an Organization and account structure that can be easily scaled and governed. For clarity, this isn't just a networking effort. A Landing Zone involves the whole team to design properly so it best mirrors how the business will actually run in public cloud.

From that initial Landing Zone development, I'd highly recommend creating a dedicated Networking Account, or perhaps a series of them (Non-Prod, Test, etc.) to suit your preferred deployment methods.

This Networking Account becomes a central, foundational structure to support all your core network infrastructure. This makes it easier to manage, better controls access, and reduces the complexity of managing core network infrastructure in multiple accounts. On top of that, you can also use it as part of an attribution method for chargeback. Check out this blog I wrote about network chargeback here.

Core infrastructure in a production Networking Account typically includes a Hub design. It might include inspection architectures for Inbound and OBEW, or SD-WAN connections, or a Direct Connect out. Whatever your unique organizational needs, this account should include any shared network infrastructure for the organization and be the primary focus of the cloud network engineer to observe, manage, optimize, and ultimately automate.

Workloads will reside in their own accounts, within a Workloads OU or something similiar. This depends on the OU structure and overall business design. This workload per account design is a best practices way of isolating them and reducing that blast radius I mentioned earlier.

The workloads will also require their own network infrastructure. In the real world, developers often take up the responsibility of deploying networks for their workloads. Rather than fight that tooth and nail, it's a better approach to embrace it and reduce the overall workload of network engineers.

By making templated network designs and deploying them from a service catalog (like AWS Service Catalog or with something like ServiceNow), organizations can enable their devs to work more efficiently while ensuring that basic design principles are upheld throughout the environment. Maybe the business selects a default VPC design that will connect to a Transit Gateway that can be used reliably without many issues. That repeatability of validated design is what we're trying to solve for.

As you can see in both examples of the Network and Workload accounts and their infrastructure, the network layer follows the account structure. For any serious usecases of AWS, having that account structure laid out before building network infrastructure is key to achieving better, more secure, more scalable, and more resilient designs.

This is why I say that you should start with the account layer before the network layer in your design. I know it's extra legwork but it's well worth the effort when done properly.