Network Segmentation using AWS Cloud WAN
Simplify the creation, configuration, and maintenance of your segmented global cloud network using AWS Cloud WAN.
AWS Cloud WAN is a managed wide area networking (WAN) service that makes it easy for you to build, manage, and monitor a global network that connects resources running across your cloud and on-premises environments. This article explores the network segmentation capabilities of Cloud WAN applied on one of our client engagements. It is not a step-by-step guide to provisioning global and core networks via AWS Cloud WAN. Rather, it describes a segmented network architecture that was implemented via Cloud WAN.
Context
Slalom was engaged to automate the provisioning of high-performance compute capacity. This client was already a successful AWS customer prior to this engagement but had determined that their original account and network structure was insufficient to meet their business forecast. Their vision for the next iteration of the cloud ecosystem included fully automated provisioning of new network attached HPC workload accounts on demand. Isolation of network traffic between compute, data and shared services accounts was a key requirement.
The engagement included a complete redesign of the client’s cloud account and transit network topology as well as the means to automate provisioning. For the networking requirements, Slalom had originally proposed a network architecture that leveraged native AWS Transit Gateway. We also considered using a third-party software-defined network solution to simplify automation and configuration. However, while preparing the proposed architecture, we were made aware of a new service from AWS that was in preview — AWS Cloud WAN. We immediately recognized its network segmentation capability as an accelerator that could greatly reduce the effort and complexity of network provisioning and routing automation. It did not disappoint.
After reviewing the Cloud WAN preview documentation, our estimate for the networking aspect of this project was accurately reduced from months to weeks. The ease of defining the core network, network segmentation, and attachment policies via a network policy document and applying it via the provided CLI greatly simplified global network creation. In addition, attaching VPCs of new HPC accounts (upon account creation) to the appropriate network segment with required network isolation could not have been simpler. In short, the use of Cloud WAN reduced time spent on what was originally perceived to be one of the more complex aspects of this engagement and allowed us to focus more time and energy on other challenges associated with auto-provisioning of multi-account HPC.
New Account Structure
As noted above, the engagement required an entirely new account structure and network topology. The new account structure consisted of common shared service accounts, application- and environment-specific accounts (Dev, QA, Stage, Integration and Prod for each suite of applications) as well as sandbox accounts for POCs and guardrail testing.
Logical Network Design
The routing architecture for the network is depicted below. Network requirements dictated that:
- Sandbox accounts must be completely isolated.
- VPCs in all other accounts must have access to shared services accounts.
- VPCs in accounts within the same environment (e.g. QA) can always communicate with one another.
- VPCs between Non-prod accounts (Dev & QA) can always communicate with one another.
- By default, VPCs between Prod accounts (Integration, Staging and Prod) cannot communicate with one another (however, it must be possible to enable such connectivity when necessary — for example, data migrations between accounts).
Network Segmentation
The “physical” architecture of the segmented network is depicted below. Leveraging Cloud WAN segmentation capabilities greatly simplifies network routing rules. Each set of Account VPCs is automatically attached to the appropriate network segment based on tags associated with the attachment request.
Learn more: To learn more about the network segmentation capabilities of Cloud WAN click here.
Network Policy Matrix
The core network policy is a declarative language that defines segments, regional routing, and how attachments should map to segments. The policy can be defined in a policy document. With a core network policy, you can describe your intent for access control and traffic routing, and AWS Cloud WAN handles the configuration details when applied.
The matrix below depicts the required routing rules which are specified in the network policy document.
Network Policy
A Cloud WAN Network policy is a JSON file that consists of four sections
- core-network-configuration
- segments
- segment-actions
- attachment-policies
Core Network Configuration
The core network configuration for this network spans 3 regions
Segments Configuration
The segments section defines the different segments in the network. The network in our example consists of six segments (sharedservices, dev, qa, int, stg, prd). All network segments are isolated by default. stg and prd segments require approval of attachments. dev and qa segments explicitly allow routes between one another and to the sharedservices segment. int, stg and prd segments explicitly deny routes to/from dev and qa.
Segment Actions Configuration
segment-actions define how routing works between segments. By default, attachments can only communicate with other attachments in the same segment. The share action allows attachments from two different segments to reach each other.
In this example, we are explicitly sharing the sharedservices segment with all other segments (a wildcard could be used here as well). We are also explicitly sharing dev with qa.
Attachment Policies Configuration
In a core network, all attachments use the attachment-policies section to map an attachment to a segment. Instead of manually associating a segment to each attachment, attachments use tags, and then the tags are used to associate the attachment to the specified segment.
The attachment-polices section for this network contains two policies.
- The first uses an “or” operator to specify that if any of the conditions are true (based on the user-defined Environment tag on the attachment) then the attachment to the sharedservices segment is allowed.
- The second attachment action uses the combination of the tag-exists condition (on the user-defined Environment tag) and the action-method of tag that allows attachments to segments where the tag-value-of-key “Environment” is the same as the name of the segment. (e.g. an attachment with the “Environment” tag of “dev” will attach to the dev segment)
Learn more: To learn more about Cloud WAN Network Policies click here.
Network Provisioning
Once the network policy is defined, we apply it using the AWS Network Manager CLI. If modifications are required, the network policy document is modified and reapplied.
Learn more: To learn more about the Cloud WAN CLI click here.
Summary
In this post we illustrated how we approached the cloud network redesign and rebuild for a client. It also illustrates the integral role that AWS Cloud WAN played in simplifying the creation and configuration of the segmented network design.
Working With Slalom
Slalom is a global consulting firm that helps people and organizations dream bigger, move faster, and build better tomorrows for all. In over 43 markets around the world. A member of the Amazon Web Services Partner Network (APN) since 2010 and an AWS Premier Tier Services Partner, we’ve worked together with AWS and over 500+ mutual customers to maximize the value of the cloud. Learn more at slalom.com/aws or reach out directly to hello@slalom.com.
