Search
AWS Blogs
In today’s multi-cloud landscape, organizations face significant challenges in network configuration and resource management. Traditional tools often need deep, tool-specific knowledge, which leads to increased deployment times and configuration errors.
The AWS Cloud Control API addresses these common cloud management challenges by providing a unified, language-agnostic interface for resource management. It offers immediate access to the latest AWS features and a standardized Create-Read-Update-Delete-List (CRUD-L) interface across services. These improvements simplify cloud resource deployments and management. Streamlining the interaction with AWS services allows for Cloud Control API to enable organizations to focus on their architectural design and business logic, rather than grappling with the complexities of various management tools and service-specific APIs. This leads to faster implementation, reduced errors, and more streamlined operations in multi-cloud environments.
This post demonstrates how the Cloud Control API refines networking resource development. We showcase inspection example setup using AWS Transit Gateway and AWS Network Firewall spanning multiple AWS Accounts and AWS Regions, highlighting best practices for deploying and managing these resources with the declarative approach of Cloud Control API. The concepts and building blocks discussed in this blog can be extended to other networking resources such as AWS Cloud WAN or Amazon VPC Lattice.
In this example scenario (Figure 1), we have a workload operating across two AWS Regions (us-east-1 and us-west-2). An internal application in the shared services account connects to this workload through Transit Gateway, which we use for cross-Region connectivity. All communication between the workload and the internal application undergoes inspection by Network Firewall. The blog provides technical deep dive about centralized deployment with AWS Network Firewall and AWS Transit Gateway.
Figure 1: Cloud Control API streamlining development and deployment of real-world network scenario
The following table (Table 1) summarizes the building blocks for our real-world scenario and how AWS Cloud Control API feature simplifies its development and deployment.
Table 1 : Building blocks for our real-world scenario with Cloud Control API
For this multi-Region workload, Transit Gateway acts as a network transit hub, connecting VPCs in us-east-1 and us-west-2, and the shared services account. The following table summarizes how Cloud Control API helps you simplify the implementation of this centralized connectivity architecture, by enabling the provisioning of Transit Gateway and its attachments through a single API call. This is shown in Figure 1 as label 1. Table 2 also provides a comparison with other available automation options, such as AWS CloudFormation, CDK and Terraform.
Table 2: A comparison for centralized connectivity with AWS Cloud Control API and other automation options, such as AWS CloudFormation, CDK and Terraform
To secure the multi-Region workload and its communication with the internal application, we route all traffic through Network Firewall. This is shown in Figure 1 as label 2. Cloud Control API offers several advantages in implementing this traffic inspection, as show in the following Table 3.
Table 3: A comparison for traffic inspection with AWS Cloud Control API and other automation options, such as AWS CloudFormation, CDK and Terraform
Our scenario involves multiple accounts: the workload accounts in different AWS Regions and the shared services account. Implementing this multi-account setup is crucial for workload isolation and security. This is shown in Figure 1 as label 3. The following Table 3 shows how Cloud Control API facilitates this setup.
Table 4: A comparison for multi-account setup with AWS Cloud Control API and other automation options, such as AWS CloudFormation, CDK and Terraform
To accommodate for workload growth and changes, we need to keep route tables and firewall rules updated across AWS Regions and accounts. This is shown in Figure 1 as label 4. Cloud Control API streamlines these dynamic updates, as show in the following Table 5.
Table 5: A comparison for dynamic updates with AWS Cloud Control API and other automation options, such as AWS CloudFormation, CDK and Terraform
To minimize manual interventions and make sure of consistency across our multi-Region, multi-account setup, we integrate our network resource management into CI/CD pipelines. This is shown in Figure 1 as label 5. Cloud Control API offers several advantages for this automation, as shown in Table 6.
Table 6: A comparison for automation with AWS Cloud Control API and other automation options, such as AWS CloudFormation, CDK and Terraform
The rest of blog provides details on how to deploy real-world scenario discussed using Cloud Control API. The solution has few prerequisites listed below.
The following prerequisites are needed to deploy the solution:
3. Install Git locally, referring to the steps outlined in this link.
To deploy the solution across accounts in your organization using CodePipeline and Cloud Control API, follow these steps:
2. IAM Roles
3. CodeBuild project
4. Amazon S3 artifact storage bucket
5. Set up CodePipeline in the Network Deployment Account
6. Set up the DynamoDB table in the Network Deployment Account
7. Update the Configuration Files and invoke the CI/CD Pipeline
The comparative analysis in this post demonstrates that AWS Cloud Control API addresses many challenges faced by traditional IaC tools such as AWS CloudFormation, AWS CDK, and Terraform. Its consistent Create, Read, Update, Delete, and List (CRUD-L) interface, real-time resource awareness, and streamlined cross-account management capabilities benefit enterprises with complex, multi-account network setups.
Organizations face challenges in scaling and securing their cloud networks. Cloud Control API provides a unified, declarative interface for resource management, streamlining the process of setting up and maintaining network architectures across multiple accounts and AWS Regions. It enables dynamic resource updates, seamless integration with CI/CD pipelines, and instant access to new AWS features without tool-specific updates.
Shiva Vaidyanathan is a Principal Cloud Architect at AWS. He provides technical guidance, design and lead implementation projects to customers ensuring their success on AWS. He works towards making cloud networking simpler for everyone leveraging cutting edge Generative AI technologies. Prior to joining AWS, he has worked on several NSF funded research initiatives on performing secure computing in public cloud infrastructures. He holds a MS in Computer Science from Rutgers University and a MS in Electrical Engineering from New York University.
Omkar Nyalpelly specializes in network architecture and automation, focusing on AWS Landing Zones. With deep expertise in AWS and a strong background in DevOps methodologies across the SDLC, he leads critical implementation and migration projects. His expertise ensures secure, scalable, and efficient cloud operations. At AWS Professional Services, he builds customer-centric solutions, leveraging Generative AI to enhance cloud infrastructure automation. Outside of work, he enjoys playing cricket, baseball, and photography. Omkar holds an MS in Networking and Telecommunications from Southern Methodist University