Use Cloud Foundations network-sharing products to plan, design and one-click deploy cross-regional multiple cloud networks on multiple network accounts

The Chinese version ^[3] of this blog post was originally published on February 29, 2024. We updated the network and product definitions based on the latest specifications when translating and republishing it in English.

In previous blogs, we have introduced a series of efforts and work carried out by Cloud Foundations to support the construction of complex networks ^[¹^] and network traffic inspection configurations ^[²^] in multiple accounts, multiple regions, and multiple availability zones, which have been successfully delivered and highly recognized by customers. In delivery practice, there is customer feedback that multiple networks need to be built with multiple different network accounts to isolate and manage network resources more securely in a more granular manner. To this end, Cloud Foundations has recently further enhanced its network construction capabilities to better support the “five multiples” requirements for this complex networks.

In past delivery projects, we have found that the actual network construction needs of some customers are really complex, and now we would like to share an example. A customer wants to build multiple Amazon Transit Gateway (TGW)-sharing networks, which need to be isolated from each other. It is defined as two different networks according to the functional types of Amazon VPCs (VPC) and whether an Internet connection is provided. The two isolated networks are deployed in different network accounts, where different teams are responsible for network operation and maintenance. Each network connects its VPCs with its own TGW and has a different inspection VPC design. One checks east-west and north-south traffic separately through the Palo Alto firewall, and the other uses the Fortinet firewall to uniformly inspect traffic in all directions.

Cloud Foundations supports both models of VPC-sharing and TGW-sharing with network resources deployed by pipeline products. The VPC-sharing network is deployed by a first-order pipeline, and the TGW-sharing network is deployed by a second-order pipeline, i.e., the two pipelines are executed to deploy in order. For one multi-regional network, one set of pipelines jointly completes the deployment of the network in multiple regions, where each pipeline deploys one region. These are the previous network building capabilities of Cloud Foundations. To support multiple networks, it is necessary to simultaneously support multiple sets of pipelines to deploy different networks separately. For this purpose, we introduce the “stage” property to the pipeline.

To maintain backwards compatibility, a stage with an empty name is defined as the default stage. Therefore, a pipeline before the introduction of stage is equivalent to the default stage pipeline. After the default stage is deployed, you can continue to build other stages, such as the “development”, “production” stages etc. The network products are essentially pipeline products. Using stage property, we can build multiple networks that are independent of each other at different stages. On this basis, when launching the pipeline product, different network accounts can be specified to deploy networks, thus achieving the goal of managing multiple networks by account.

Network architecture organization forms

It is supported to deploy networks on different network accounts naturally after multiple networks are supported. Whether multiple networks should be deployed in one network account or different network accounts, you can make a comprehensive decision based on business requirements, network complexity, management granularity, and security isolation requirements. Different TGWs within the same network must have different autonomous system numbers (ASN). If you later consider connecting those networks together, the TGW ASNs must also be different.

A network architecture organization can be constructed from at least four dimensions: network account (same or different), region (single-region or multi-region), model (VPC-sharing, TGW-sharing), and network count (single, multiple). Therefore, it is possible to build at least 2⁴ = 16 organizational forms to meet the needs of different network architectures, from simple to complex. For example, in addition to the production network, you can build an identical network on another network account for testing purposes. Simulate network changes to assess impact or verify correctness before applying such changes to the production environment. If your production network spans across multiple regions, then you can choose to deploy a single region when preparing the testing network, which saves time, costs, and is more targeted.

Figure 1. Schematic diagram of deploying production and test networks simultaneously

In addition to preparing a testing network, it can also support complex business requirements such as the coexistence of multiple production networks. For example, some businesses require the VPC-sharing model, and other applications require the TGW-sharing model. Supporting multiple networks greatly enhances the flexibility and application scenarios of Cloud Foundations network capability.

Figure 2. Deploying VPC-sharing and TGW-sharing models simultaneously

The above examples are just a fraction of the vast possible forms of network architecture organization, and you can further expand and build upon them. Described by symbols, let s represent the stage, the default stage is s’ (its name is empty), let d represent the network definition, and the default definition is d’ (that is network-vpc profile), let p_a represent the pipeline, a represent the network account, and w represent the network. Previously, Cloud Foundations only supported one default network w’ = p_a(d(s’)) = p_a(d’); now it supports multiple networks W = {w‘, w₁, w₂, … , w_n}, where w_i = p_a(d(s_i)), network account a can be the same or different from one w_i to another.

Multi-stage pipeline products

Network products are essentially pipeline products, i.e., products that use Pipeline Factory service catalog (Amazon Service Catalog) product to generate pipelines and execute to deploy network resources based on network definition profile in Amazon AppConfig. Different pipelines are distinguished by “stages”, where the one with empty name is the default stage. In a multi-stage pipeline deployment process, the default stage must first be deployed before other stages can be deployed.

Different networks have different definitions, so “variables” is introduced in Pipeline Factory to specify different network definitions. The content of the variables is a set of key-value pairs in JSON format. The default stage can be left unspecified, where the network definition named network-vpc is read. The value of the profile key for the non-default stage is the name of the network definition profile; for example, the profile name defined by the {"profile": "network-prod"} variable is network-prod. For instance, you need to add the profile to the cloud-foundations application in the Infrastructure Account, with the content as the network definition for this stage.

The following are the input boxes newly added for the Pipeline Factory service catalog product. The first one is the stage and the second one is the variables. For the default stage, leave both boxes blank. For non-default stages, it is recommended that the profile name has a certain correlation with the stage name to facilitate operation and maintenance. For example, if the profile is called network-prod, then the stage is called prod.

Below, we will further explain the detailed steps for building multiple networks in VPC-sharing and TGW-sharing models respectively.

VPC-sharing multiple networks

VPC-sharing network connectivity creates and manages resources such as TGWs and all VPCs in the Network Account, and shares the VPC subnets from the Network Account to the member accounts through Amazon RAM. One of the prerequisites for this model is that every account is within an Amazon Organizations organization. VPC-sharing network is deployed through different pipeline products in the main region and governing regions. The main region is through network/vpc, and the governing regions are through network/vpc/regional. For the same network, the network structures for all regions are defined in the same profile. For different networks, the network structures for the same region are defined in different profiles. Pay attention to the distinctions.

Figure 3. Example of a multi-regional network deployment in VPC-sharing mode

The figure above shows two building examples of VPC-sharing model in multiple regions. The general steps are to first build the default stage and then build the other stage, which in the diagram is the test stage. The steps for building the default stage are as follows:

Define the default stage network structure in the Infrastructure Account cloud-foundations application and save it to the network-vpc profile. The profile name is fixed;
Launch the Pipeline Factory service catalog product in the Infrastructure Account. The path is network/vpc, select the single-account mode, fill in network account 1. Leave the stage, variables, and regions blank. At this point, it is deployed in the main region and generates a pipeline;
Approve the execution of this pipeline and deploy network resources at the default stage to the main region;
Launch the Pipeline Factory service catalog product again in the Infrastructure Account. The path is network/vpc/regional, select the single-account mode, fill in network account 1, leave the stage and variables blank, fill in all the governing regions to be deployed. One pipeline is generated for one governing region;
Approve the execution of the above pipelines in sequence, and deploy network resources at the default stage to each governing region;

The steps for building the test stage are as follows:

Define additional stage network structure in the Infrastructure Account cloud-foundations application and save them to the network-test profile. The profile name is customizable; it is recommended to name as network-stage;
Launch the Pipeline Factory service catalog product in the Infrastructure Account. The path is network/vpc, select the single-account mode, and fill in network account 2. The stage is test, the variables is {"profile": "network-test"}, and leave the region blank. At this point, it is deployed in the main region and a pipeline is generated, whose name includes the stage name. You can also enter network account 1 here, which shares the same network account with the default stage;
Approve the execution of this pipeline and deploy network resources for the test stage to the main region;
Launch the Pipeline Factory service catalog product again in the Infrastructure Account. The path is network/vpc/regional, select the single-account mode, and enter network account 2. The stage is test and the variable is {"profile": "network-test"}. In the region, fill in all the governing regions to be deployed. One pipeline is generated for one governing region, whose name includes the stage name. Enter the network account, which must be the same as step 7;
Approve the execution of the above pipelines in sequence, and deploy network resources at the test stage to each governing region;

You can follow the steps above to build more VPC-sharing networks.

TGW-sharing multiple networks

TGW-sharing network creates and manages resources such as TGWs and functional VPCs in the Network Account. It uses Amazon RAM to share TGW to member accounts, and then directly creates VPCs and attaches them to the shared TGW in member accounts. This model doesn’t require each account to be in the same AWS Organizations organization. Unlike VPC-sharing, TGW-sharing uses the same pipeline product to complete deployment in the main region and governing regions, i.e., network/tgw/pipeline. Another difference is that TGW-sharing pipeline product is second-order, i.e., they need to execute the pipeline to generate a second pipeline based on the network definition, and then execute the latter to finally deploy network resources. The network definition is almost the same as VPC-sharing, where different regions of the same network are defined in the same profile. The main difference is that a VPC can only be specified for at most one member account.

Figure 4. Example of a multi-regional network deployment in TGW-sharing model

The figure above shows two building examples of a multi-regional TGW-sharing architecture. The general steps are also to first build the default stage and then build the other stages. In the diagram, this is the test stage. The steps for building the default stage are as follows:

Define the default stage network structure in the Infrastructure Account cloud-foundations application and save it to the network-vpc profile. The profile name is fixed;
Launch the Pipeline Factory service catalog product in the Infrastructure Account. The path is network/tgw/pipeline, select the single-account mode, fill in network account 1, leave the stage and variables blank, fill in all regions to be deployed, including the main region. At this point, it is deployed in all regions, and one pipeline is generated for one region;
Approve the execution of first-order and second-order pipelines in the main region in sequence, and deploy network resources in the default stage to the main region;
Approve the execution of first-order and second-order pipelines in other regions in sequence, and deploy network resources at the default stage to each governing region;

The steps for building test stage are as follows:

Define additional stage network structure in the Infrastructure Account cloud-foundations application and save it to the network-test profile. The profile name is customizable; it is recommended to name as network-stage;
Launch the Pipeline Factory service catalog product in the Infrastructure Account. The path is network/tgw/pipeline, select the single-account mode, enter network account 2, the stage is test, the variables is {"profile": "network-test"}, and fill in all the regions to be deployed, including the main region. At this point, it is deployed in all regions. One pipeline is generated for one region, whose name includes the stage name. You can also enter network account 1 here, which shares the same network account with the default stage;
Approve the execution of first-order and second- order pipelines in the main region in sequence, and deploy network resources for the test stage to the main region;
Approve the execution of first- order and second- order pipelines in other regions in sequence, and deploy network resources at test stage to each governing region;

You can follow the steps above to build more TGW-sharing networks.

Build multiple networks in hybrid models

You can simultaneously build multiple networks in both VPC-sharing and TGW-sharing models in multiple regions. At this point, it is recommended not to use the default network definition profile name, but to use a different default profile name to avoid conflicts. Since the default stage must be deployed first, when the two models are deployed at the same time, two networks in the default stage are deployed before networks in the other stages can be deployed. The general steps are as follows:

Define network structures for each model in the Infrastructure Account cloud-foundations application and save them in each profile, such as network-vpc-main, network-vpc-prod, network-tgw-main, network-tgw-prod, etc.;
Deploy VPC-sharing at the default stage, variables are {"profile": "network-vpc-main"};
Deploy VPC-sharing at other stages, variables are {"profile": "network-vpc-prod"} etc.;
Deploy TGW-sharing at the default stage, variables are {"profile": "network-tgw-main"};
Deploy TGW-sharing at other stages, variables are {"profile": "network-tgw-prod"} etc.;

You can build other networks by following the steps above.

Conclusion

This article mainly introduces some important new improvements of Cloud Foundations on supporting construction requirements of complex network structures in the form of multiple networks. It explains specific architectures and discusses detailed steps for building multiple networks with respect to common network-sharing models. Hereinafter, we hope that our work can better facilitate you with real and complex network construction processes. As always, we welcome your trial feedback and all kinds of valuable opinions and suggestions. Cloud Foundations is committed to provide automated construction tools of high-quality.

选择您的 Cookie 首选项

亚马逊AWS官方博客