# Network connectivity
Workloads often exist in multiple locations or environments, both publicly accessible and private. Managing networks in AWS might require connecting many AWS-hosted VPCs from many accounts to specific enterprise networks, and to the internet. Your network strategy must allow for the interoperability of workloads while also aligning to your security architecture. The careful planning and management of your network design forms the foundation of how you provide isolation and resource boundaries within your workload. We think of network connectivity in three different groupings: connectivity between your on-premises network and your AWS environment, connectivity to and from the internet, and connectivity across your AWS environments—primarily between VPCs.
Where connectivity between VPCs is required, the M&G Guide recommends a hub and spoke model for your network design to connect to your existing environment. Intra-application connectivity requires multiple account network patterns that can be reusable for scale. Account types can include sandbox accounts that might require a separate network than the network used for your workload accounts. Regulatory requirements might require you to separate production data into distinct accounts and keep it separate from research and development activities in your sandbox accounts. To reinforce your data governance, you might restrict access using distinct network boundaries, along with specific controls. These boundaries could include controlling traffic with security groups and NACLs, implementation of firewalls, and implementing limited route configurations. Beyond data governance, your workload accounts might need further network refinement for regulated and non-regulated workloads.
Have a mechanism to enforce the use of non-overlapping private subnets when provisioning new accounts and VPCs in your multi-account framework. This automation should also encompass the definition of which network controls and patterns are implemented as you provision (and update) your AWS accounts and workloads. This automation would include definitions of which Regions are included and excluded from your network, as well as which mechanisms of access are allowed in your environments. Using AWS Control Tower, you can select a guardrail to detect if SSH or RDP is enabled for internet connections within your network, while specifically defining which Regions are allowed for the account and related VPC to operate. SSH and RDP traffic can also be restricted through security groups and NACLs.
Define and catalog your VPC in an infrastructure as code template such as AWS CloudFormation. Doing so will allow you to automate its provisioning as well as help with the necessary distributions of future version updates. AWS Control Tower provides a default VPC, or you can use the [Scalable VPC Architecture](https://aws.amazon.com/quickstart/architecture/vpc/) from AWS Quick Starts as a building block for your own deployments. This template is also available within your console in the [Service Catalog Getting Started Library](https://console.aws.amazon.com/servicecatalog/home?portfolios%3FactiveTab=gslAdminPortfolios®ion=us-east-1#getting-started-library).
# Interoperable functions
The eight management and governance functions, supported by AWS services and AWS Partner solutions, work together and interoperate to reduce complexity. Outputs from functions are used to inform or integrate with other functions.
For network connectivity this includes:
+ A specifically defined set of **Identity and permissions** to make changes to the networks.
+ Provisioning each network with the appropriate **Controls** defined within the infrastructure as code template.
+ Embedded integration with **Security management** including playbooks and runbooks.
+ Integrated change, provisioning, and remediation capabilities for your networking capabilities for your **Service management** framework. This would include defining support escalation paths and dependencies, runbooks, and playbooks for each network as well.
+ Complete **Monitoring and observability** with specific network logging, and identification of any necessary changes to the network design based on the behavior captured.
+ Networking components should be included in the total cost of application management calculations for your business cases within **Cloud Financial Management**.
+ Purchased third-party solutions or custom-built networking solutions **Sourced and distributed** across environments
# Implementation priorities
Network connectivity is typically implemented in the early phases of a cloud journey. As you evolve your network strategy, the following items should be prioritized.
## Plan your IP address space (IP address management – IPAM)
Similar to private networks, VPCs typically use private or RFC 1918 IPv4 space. However, you can also use publicly routable non-RFC 1918 CIDR blocks for your VPC. Carefully plan the IP address space that you will be allocating to your VPCs, particularly if you are using an IPv4 range. The best practice for IPv4 planning is to first allocate a non-overlapping and contiguous address block. Subdividing address space into subnets based on attributes like environment or AWS Region helps you to create separate network boundaries more easily. You might also consider other CIDR grouping approaches based on regulatory requirements or the sensitivity of their workloads. This approach can simplify routing, security policies and the ability to query logs.
In the following example, VPCs have been assigned a contiguous IP space aligned by VPC environment to simplify application of security groups and NACLs.
**Example VPC CIDR ranges**
| | Dev VPCs | Test VPCs | QA VPCs | Prod VPCs |
| --- | --- | --- | --- | --- |
| AWS Region 1 | 10.0.0.0/16 | 10.64.0.0/16 | 10.128.0.0/16 | 10.192.0.0/16 |
| AWS Region 2 | 10.1.0.0/16 | 10.65.0.0/16 | 10.129.0.0/16 | 10.193.0.0/16 |
+ 10.0.0.0/15 represents all Dev VPCs
+ 10.64.0.0/15 represents all Test VPCs
+ 10.128.0.0/15 represents all QA VPCs
+ 10.192.0.0/15 represents all Prod VPCs
In the next example, VPCs have been assigned contiguous IP space aligned by AWS Region to simplify routing.
**Example VPC CIDR ranges**
| | Dev VPCs | Test VPCs | QA VPCs | Prod VPCs |
| --- | --- | --- | --- | --- |
| AWS Region 1 | 10.0.0.0/16 | 10.1.0.0/16 | 10.2.0.0/16 | 10.3.0.0/16 |
| AWS Region 2 | 10.4.0.0/16 | 10.5.0.0/16 | 10.6.0.0/16 | 10.7.0.0/16 |
+ 10.0.0.0/14 represents all VPCs in AWS Region 1
+ 10.4.0.0/14 represents all VPCs in AWS Region 2
If insufficient IP space is a concern, consider [VPC sharing](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/) to simplify IPv4 address allocation, and preserve scarce IP addresses. This approach gives you the ability to centralize control of network maintenance while still granting builders the ability to self-provision VPC based resources. AWS PrivateLink can also help alleviate IP exhaustion and overlap by enabling the creation of services in your VPCs that can be consumed through a PrivateLink endpoint with traffic flowing across Amazon’s private network. Service consumers don’t have to worry about overlapping IP addresses, arrange for VPC peering, or use a Transit Gateway. If exhaustion of IP space is still a concern, you can evaluate alternative solutions that rely on [Private NAT and TGW](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) to allow for communication between VPCs with overlapping CIDR ranges.
The IPv6 address space is much larger than the IPv4 address space, so it’s not currently at risk of exhaustion. However, if you plan to [bring your own IPv6 space into AWS](https://docs.aws.amazon.com/vpc/latest/userguide/get-started-ipv6.html), it’s still a good practice to structure it in a similar fashion to IPv4.
Continually review and refine your network isolation boundaries and perform impact analysis for any proposed network changes. VPC design would be incomplete without a scalable subnet design. As with other management and governance functions, consider the operational complexity when designing or refining the allocation of subnets and be mindful of allocating too many subnet tiers. Because individual subnets cannot span multiple Availability Zones (AZs), deploy workloads to multiple subnets across multiple AZs to allow for workload resiliency using capabilities like Auto Scaling groups, load balancers, and services that span AZs. Your subnet design will likely include a combination of public and private subnets. Public subnets are associated with a route table that has a route to an Internet Gateway, while private subnets do not have a route to an Internet Gateway and are typically associated with a NAT Gateway if they require internet access.
## Design network connectivity
We think of network connectivity in three different areas:
+ Connectivity between your on-premises network and your AWS environments
+ Connectivity to and from the internet
+ Connectivity across your AWS environments.
For on-premises connectivity, customers typically start with a VPN. They add additional VPNs or convert to Direct Connect and add resilience and bandwidth as time, maturity, and requirements progress. It is also common for customers to configure VPN over a Direct Connect connection to achieve consistent levels of throughput and encryption algorithms that protect data in transit. AWS Direct Connect also offers IEEE 802.1AE MAC Security Standard (MACsec) encryption for 10Gbps and 100Gbps Dedicated Connections at select locations to secure your high-speed, private connectivity to the cloud.
Decide whether to configure internet traffic in a centralized or distributed manner, depending on your enterprise needs. You might choose to centralize inbound or outbound internet traffic with a hub and spoke model using AWS Transit Gateway or an AWS Partner solution, or distribute internet traffic flows via appropriate VPCs in their environment. Establish internet connectivity by implementing internet gateways, public subnets as well as NAT gateways. Review the whitepaper on [building scalable multi-VPC architectures](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf?did=wp_card&trk=wp_card) to help you decide which pattern best fits your requirements.
For connectivity across your AWS environments, connect VPCs both within and across AWS Regions using a transit gateway hub and spoke model. [The Serverless Transit Network Orchestrator solution](https://aws.amazon.com/solutions/implementations/serverless-transit-network-orchestrator) automates the process of setting up and managing transit networks in distributed AWS environments. It creates a web interface to help control, audit, and approve (transit) network changes. This includes establishing peering connections between transit gateways to extend connectivity and build global networks spanning multiple AWS Regions.
## Define your VPC endpoint and DNS strategy
To establish private connectivity from your VPC to supported AWS services, use [VPC Interface endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html). An interface endpoint is an elastic network interface with a private IP address from the IP address range of your VPC subnets. Interface endpoints can be deployed across multiple AZs for resiliency. Interface endpoints serve as an entry point for traffic destined to a supported AWS service. In addition, add [endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) to control access from the endpoint to the specified service. Amazon Virtual Private Cloud documentation includes an updated [list of services](https://docs.aws.amazon.com/vpc/latest/privatelink/integrated-services-vpce-list.html) that support VPC Interface endpoints.
When deploying your VPC endpoints, consider two approaches. One approach is to centralize multiple endpoints in a single VPC reachable from other VPCs using AWS Transit Gateway. This approach allows you to lower the overall endpoint cost but also means that access policies and endpoint capacity would be shared between multiple VPCs. A second approach is to use interface endpoints for relevant services in each VPC. Access is localized and security policies and performance are scoped and consumed by a single VPC. It is important to consider that costs and operational complexity will rise with each additional VPC deployed.
Gateway VPC endpoints are available for Amazon S3 and Amazon DynamoDB and are recommended when accessing these services from within a VPC. Gateway VPC endpoints offer a more cost-effective alternative than the equivalent interface endpoints. For example, Gateway VPC endpoints don’t have an associated data transfer or per-hour fee. Access to Gateway VPC endpoints is not directly accessible from your on-premises network and will require a proxy farm infrastructure to enable network connectivity.
A well-planned DNS strategy can help avoid complications as your AWS environments grow. If you maintain on-premises DNS capabilities, we recommend you design [hybrid DNS architectures](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/set-up-integrated-dns-resolution-for-hybrid-networks-in-amazon-route-53.html) that use on-premises DNS infrastructure along with [Route 53](https://aws.amazon.com/route53/) for any AWS based DNS requirements. Integrate DNS resolution with on-premises DNS environments using Route 53 Resolver Endpoints and [Forwarding rules](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html). Use private hosted zones to hold information about how you want Amazon Route 53 to respond to DNS queries for a domain and its subdomains within one or more VPCs that you create with the Amazon VPC service. Establish distributed management of your [private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs.html) by using Route 53 to associate your hosted zone to VPCs across your AWS accounts and Regions.
## Establish network security
Securing your AWS network must align to your overall security strategy and follow the recommendations in the [Well-Architected security pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). Understanding the risks that you’re mitigating will help you apply appropriate network security controls for specific traffic flows. For instance, the [Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html) recommends a centralized network account that isolates inbound, outbound, and inspection VPCs. Network security should be designed to protect connectivity between your on-premises network and your AWS environment, to and from the internet, and across your AWS environments.
[AWS Shield](https://aws.amazon.com/shield/) is a managed Distributed Denial of Service (DDoS) protection service that safeguards internet facing applications running on AWS and is offered in two tiers: standard and advanced. The standard plan, available to all AWS customers, is included for all tenants and defends against the most common, frequently occurring network and transport-layer DDoS attacks that target sites and applications. AWS Shield Advanced includes features such as additional capacity for large DDoS events, native integration with AWS WAF controls, historical reporting, assistance from the AWS DDoS Response Team, and some cost protection for charges incurred during an attack.
Configure [Amazon VPC Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) to allow specific inbound and outbound traffic. In addition to security groups, you can also configure [stateless network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) (NACLs) that operate at the subnet boundary. Configure security groups with more granular rules to govern access to specific applications or services. Use NACLs when security requirements require traffic be governed for an entire subnet.
Implement web application firewalls to help protect external facing web applications and APIs against common bugs and bots. These solutions can help block malicious application attacks like SQL injection, cross-site scripting (XSS), and others. These may include common threats such as OWASP Top 10 security risks, Content Management Systems specific threats, or emerging Common Vulnerabilities and Exposures (CVE). AWS Solutions also provides templates and patterns in [AWS WAF Security Automations](https://aws.amazon.com/solutions/implementations/aws-waf-security-automations), and centralized [AWS WAF and VPC Security Group Management](https://aws.amazon.com/solutions/implementations/aws-centralized-waf-and-vpc-security-group-management/) to assist you in the deployment of AWS WAF controls in an automated manner.
Select [deployment models supported by AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) that meet your specific use case. For each deployment model, you can have AWS Network Firewall chained together with other services (service chaining). For example, you can [chain AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) and NAT gateway. Extend your security architecture as you scale to enable [Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) to block DNS queries made for known malicious domains and to allow queries for trusted domains. Adopt centralized management through AWS Firewall Manager to streamline operations across your multi-account framework. Save time by automating the process of provisioning a centralized AWS Network Firewall to inspect traffic between your Amazon VPCs with [AWS Network Firewall Deployment Automations for AWS Transit Gateway](https://aws.amazon.com/solutions/implementations/aws-network-firewall-deployment-automations-for-aws-transit-gateway/).
Consolidating AWS Partner virtual appliances with Gateway Load Balancer can reduce operational overhead and cost. Implement and consolidate AWS Partner security solutions such as intrusion detection and prevention, next-generation firewalls, and web application firewalls.
## Establish network monitoring
Although network constructs are unique, you should pair network monitoring with the full breadth of your observability implementation, including specifying network metrics captured in [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/). For visibility into traffic patterns of your VPC, use [Amazon VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html). VPC Flow Logs provide metadata (IP addresses, ports, number of bytes transferred, etc.) about the networking flows (to and from interfaces) in your VPC. Collect VPC Flow Logs in a centralized S3 bucket for use with other log aggregation and analytics functions. When you need to perform content inspection, threat monitoring or troubleshooting, you can copy network traffic to specific monitoring appliances. For example, to capture the full packets, not just the metadata, use Amazon [VPC Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) to replicate all traffic, or specific flows from an elastic network interface, to the destination of your choice.
Automate the monitoring of your AWS networks and identify where network access to your environments may be misconfigured by implementing tools like [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) and [Amazon Inspector Network Reachability](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_network-reachability.html) from the [AWS Provable Security initiative](https://aws.amazon.com/security/provable-security/). These tools let you implement detailed network security checks without having to install scanners and send packets. This will reduce complexity by providing automated monitoring and create a more efficient review process, especially across VPC peering connections and VPNs.
# AWS network connectivity management tools
The following AWS services can be used to help you follow the guidance provided by the M&G Guide:
[Amazon VPC](https://aws.amazon.com/quickstart/architecture/vpc/) is a service that lets you launch AWS resources in a logically isolated virtual network that you define. This can be done within one account, or within a multi-account strategy. You have complete control over this virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 addresses for most resources in your virtual private cloud, helping to ensure secure and easy access to resources and applications.
[Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) (IPAM) is a VPC feature that makes it easier for you to plan, track, and monitor IP addresses for your AWS workloads. You can use the automated workflows in IPAM to more efficiently manage IP addresses.
For cloud-to-cloud connectivity, cloud-to-enterprise, and cloud-to-internet, we recommend using [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) as a shared service in your multi-account strategy. Transit Gateway uses a hub and spoke pattern to simplify your network and provide a central point for network traffic inspection. Connections of AWS accounts to a transit gateway can be deployed automatically by Control Tower Customizations and AWS Partners.
[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/index.html) establishes a dedicated network connection between your on-premises network and AWS. With this connection in place, you can create virtual interfaces directly to the AWS Cloud, bypassing your internet service provider. This can provide a more consistent network experience.
[AWS Virtual Private Network](https://aws.amazon.com/vpn/) solutions establish secure connections between your on-premises networks, remote offices, client devices, and the AWS global network. Site-to-Site VPN is comprised of two services: [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/) and [AWS Client VPN](https://aws.amazon.com/vpn/client-vpn/). Each service provides a highly-available, managed, and elastic cloud VPN solution to protect your network traffic. AWS Site-to-Site VPN creates encrypted tunnels between your network and your Amazon Virtual Private Clouds or AWS Transit Gateways. For managing remote access, AWS Client VPN connects your users to AWS or on-premises resources using a VPN software client.
[AWS Transit Gateway Network Manager](https://aws.amazon.com/transit-gateway/network-manager/) reduces the operational complexity of managing a global network across AWS and on-premises. With Network Manager, you can set up a global view of your private network simply by registering your Transit Gateways and on-premises resources. Your global network can then be visualized and monitored via a centralized operational dashboard.
To provide preventive security for internet-to-cloud connectivity, we recommend implementation of [AWS Network Firewall](https://aws.amazon.com/network-firewall/). Network Firewall gives you granular visibility and control of your network traffic, enabling outbound domain filtering, and intrusion prevention through event driven logging, and the service automatically scales with network traffic to provide high availability protections without the need to set up or maintain the underlying infrastructure.
By deploying Network Firewall along with Transit Gateway, you can centrally inspect hundreds or thousands of VPCs and accounts and centrally configure and manage your network firewall, firewall policies, and rule groups.
[AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) is a security management service that helps you to simplify management of firewall rules across your accounts, easily deploy managed rules across accounts, meet compliance obligations of your existing and new application firewalls, and centrally deploy protections for your VPCs.
AWS automated reasoning provides tools that detect entire classes of misconfigurations, including both a VPC and network configuration tool. [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) is a configuration analysis tool that enables you to perform connectivity testing between a source resource and a destination resource in your VPCs. When the destination is reachable, Reachability Analyzer produces hop-by-hop details of the virtual network path between the source and the destination. When the destination is not reachable, Reachability Analyzer identifies the blocking component. For example, paths can be blocked by configuration issues in a security group, network ACL, route table, or load balancer.
[Amazon Inspector Network Reachability](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_network-reachability.html) provides rules to analyze your network configurations to find security vulnerabilities of your EC2 instances. The findings that [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) generates also provide guidance about restricting access that might not be secure. The Network Reachability rules package uses the latest technology from the [AWS Provable Security initiative](https://aws.amazon.com/security/provable-security/). The findings generated by these rules show whether your ports are reachable from the internet through an internet gateway (including instances behind Application Load Balancers or Classic Load Balancers), a [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) connection, or a VPN through a virtual gateway. These findings also highlight network configurations that allow for potentially unwanted access, such as mismanaged security groups, ACLs, and internet gateways. These rules help automate the monitoring of your AWS networks and identify where network access to your EC2 instances might be misconfigured. By including this package in your assessment run, you can implement detailed network security checks without having to install scanners and send packets, which are complex and expensive to maintain, especially across VPC peering connections and VPNs.
If you would like support implementing this guidance, or assisting you with building the foundational elements prescribed by the M&G Guide, we recommend you review the offerings provided by [AWS Professional Services](https://aws.amazon.com/professional-services/) or the AWS Partners in the [Built on Control Tower program](https://aws.amazon.com/controltower/partners/).
If you are seeking help to operate your workloads in AWS following this guidance, [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) can augment your operational capabilities as a short-term accelerator or a long-term solution, letting you focus on transforming your applications and businesses in the cloud.
# Integrated network connectivity partners
The M&G Guide recommends you consider the following questions when choosing an AWS Partner solution for network and connectivity:
+ Does it support features you are considering using from Amazon VPC and Amazon EC2 instances?
+ Does it integrate with AWS services such as AWS Firewall Manager, AWS Security Hub CSPM, AWS Transit Gateway, Amazon GuardDuty, Gateway Load Balancer, AWS WAF, and AWS Network Firewall?
+ Does it support automatic scaling?
+ Can it be provisioned from an infrastructure as code template that is distributed from a central catalog?
+ Does it integrate with an observability solution? For instance, does it allow log aggregation across multiple instances, such as multiple firewalls and multiple routers?
## Network orchestration
To set up and maintain cloud environments effectively, enterprises need network management solutions that scale in a multi-account environment to configure, manage, and coordinate AWS resources automatically. The following integrated network connectivity AWS Partners have provided solutions that align with the M&G Guide, and are available for entitlement in AWS Marketplace: Network orchestration solutions
## Gateway Load Balancer partners
[Aviatrix – Cloud Network Platform](https://aws.amazon.com/marketplace/solutions/control-tower/network-orchestration/#Aviatrix) uses Gateway Load Balancer to scale and manage appliances that support GENEVE encapsulation. Gateway Load Balancer provides a high-performance connection to virtual appliances, reduces the need for source network address translation (SNAT), and allows you to add or remove appliances for scaling or in response to health checks without impacting existing sessions. The Aviatrix Controller automates attachment of Gateway Load Balancer, its associated Gateway Load Balancer endpoint, and all connected appliances to an Aviatrix Transit/FireNet Gateway.
[Cisco Systems – Cloud Application Centric Infrastructure (Cisco Cloud ACI)](https://aws.amazon.com/marketplace/solutions/control-tower/network-orchestration/#Cisco) drives networking automation in on-premises and AWS environments and allows you to have a consistent security posture and uniform operational processes across your hybrid cloud infrastructure.
[Palo Alto Networks – VM-Series](https://partners.amazonaws.com/partners/001E0000013FeQXIA0/Palo Alto Networks) scales your traffic across multiple VM-Series firewalls using native AWS networking constructs to achieve higher throughputs – without the need for encrypted tunnels for east-west and outbound traffic inspection. VM-Series also reduces the number of firewalls needed to protect your AWS environments and consolidate your overall network security posture with centralized security management.
## AWS Transit Gateway partners, including SD-WAN solutions
[Aviatrix](https://aws.amazon.com/marketplace/solutions/control-tower/network-orchestration/#Aviatrix) – With Aviatrix Secure Networking Platform AMI or Aviatrix software as a service (SaaS) listings, both available in AWS Marketplace, you can orchestrate the Transit Gateway in minutes without delving into the configuration detail required in each VPC and route table.
[Cisco](https://aws.amazon.com/marketplace/solutions/control-tower/network-orchestration/#Cisco) – Cisco SD-WAN offers automated connectivity provisioning to the most optimal AWS entry point for your data center, branch, and hub locations.
[Palo Alto Networks – Prisma SD-WAN](https://partners.amazonaws.com/partners/001E0000013FeQXIA0/Palo Alto Networks) (formerly CloudGenix SD-WAN) is a cloud-delivered service that implements application-defined, autonomous SD-WAN to help you secure and connect your branch offices, data centers, and large campus sites without increasing cost and complexity.