AWS Cloud WAN FAQs

By using network segmentation, you can divide your global network into separate, isolated networks. For example, a bank might create one segment for payment card transactions and another for general network traffic. By preventing communication between the networks, segmentation provides an additional layer of security and control.

Use the Cloud WAN core network policy to control network traffic across your network segments and AWS Regions. You can create the policy by using a declarative language, such as JSON. You can define your access control and traffic routing, and Cloud WAN handles the configuration details. Examples of what you can create with policies include the following:

• Creating a segment for shared services (for example, service directories, authentication services)
• Enabling or disabling internet access from a network segment
• Assigning Amazon VPCs to segments based on tags automatically
• Defining a subset of AWS Regions where a segment is available
• Steer traffic inter-segment or intra-segment traffic via network function group

The network policy has the following sections:

• Network configuration: Define the AWS Regions where you want connectivity. You can also add or remove Regions with the network policy. For each AWS Region that you define in the policy, Cloud WAN will create a core network edge router.
• Segments: You can name your segments and define whether attachments can communicate within the segment, whether resources asking for access require approval, and specify explicit route filters. Each attachment connects to one segment.
• Network Function Groups: You can name your network function groups and define whether resources asking for access require approval for this association. 
• Attachment rules: You can choose to map attachments to segments by explicitly mapping a resource (such as a vpc-id) to a segment, or by using the tags on the attachment.
• Segment actions: When you map attachments to segments, you can choose how routes are shared between segments. For example, you might want to share access to a VPN across multiple segments or allow access between two types of branch offices. You can also configure centralized internet routing for a segment or route traffic between segments through a firewall or via attachments associated with a network function group.

Yes. Cloud WAN works with existing networks. You can augment your existing WAN and incrementally move it to Cloud WAN. The following methods describe how you can use Cloud WAN alongside your existing WAN:

• Attach on-premises sites to Cloud WAN global networks – Continue to use your existing WAN, and connect your on-premises sites to Cloud WAN. You can choose to move incrementally, shifting parts of your network over to Cloud WAN by defining routing logic on your on-premises routers or gateways. You can also choose to make Cloud WAN your primary WAN and use your existing WAN as backup, or the other way around.
• Configure software-defined wide area network (SD-WAN) to use Cloud WAN as the underlying network transport – Your SD-WAN devices can use Cloud WAN alongside your existing connections to create an overlay network. You can define policies for SD-WAN devices to route traffic over Cloud WAN while keeping other traffic on your existing WAN. For example, you can keep voice traffic over your existing WAN connections and allow all other traffic to use Cloud WAN.

Both Transit Gateway and Cloud WAN allow centralized connectivity between VPCs and on-premises locations. Transit Gateway is a Regional network connectivity hub and is optimal if you operate in a few AWS Regions, want to manage your own peering and routing configuration, or prefer to use your own automation.

Cloud WAN is a managed wide area network (WAN) that unifies your data center, branch, and AWS networks. Although you can create your own global network by interconnecting multiple Transit Gateways across Regions, Cloud WAN provides built-in automation, segmentation, and configuration management features designed specifically for building and operating global networks. Cloud WAN has additional capabilities such as automated VPC attachments, integrated performance monitoring, and centralized configuration.

Yes. You can connect your Transit Gateway with a core network edge natively by using a peering connection. The Transit Gateway must be in the same AWS Region as the core network and have an Autonomous System Number (ASN) that doesn't fall within the range of ASN assigned to Cloud WAN. The Transit Gateway can be in the same AWS account or in a different AWS account as the core network edge.

Yes. Peering connections between Cloud WAN and Transit Gateway support dynamic routing with the automatic exchange of routes by using Border Gateway Protocol (BGP). You can use route table attachments on the peering connection to exchange routes selectively between a specific Transit Gateway route table and a Cloud WAN network segment for complete segmentation and network isolation. The ASN used on a Transit Gateway must be different from the ASN configured on the core network edge.

Currently we don’t support native Direct Connect attachments to Cloud WAN. You can integrate your Direct Connect network with Cloud WAN by using the Transit Gateway service. You can use Direct Connect attachments to interconnect your Direct Connect gateway with the Transit Gateway. You can then peer the Transit Gateway with Cloud WAN to route traffic back and forth between your Direct Connect network and the Cloud WAN network.

Depending on your use case, you might choose one, the other, or both. Cloud WAN can create and manage networks of VPCs across multiple Regions. By contrast, SiteLink connects AWS Direct Connect locations together, bypassing AWS Regions, to improve performance.

Service insertion lets you easily insert AWS and third-party networking and security services on Cloud WAN using the central policy document. Using this feature, you can easily steer VPC-to-VPC or VPC-to-on-premises traffic via network or security appliances by defining simple policy statements or alternatively using a few clicks in the UI.

Network Function Group is a global construct that you can add attachments to from any of the AWS regions belonging to the core network. For example, if your core network operates across three AWS regions (us-east-1, eu-west-1, ap-west-1) you can add Inspection/Firewall VPCs from any of those three regions in a single Network Function Group. You can then specify via Cloud WAN policy, segment or segment pairs for which traffic needs to be redirected to the network function group. Cloud WAN then automatically re-directs network traffic between the segments via the specified core network attachments for the respective network function group. 

Yes, you can steer traffic across VPCs or on-premises network associated with a single segment to the network function group attachment. This applies both for single and cross-region traffic scenarios. You need to enable isolate-attachments setting for the segment for same-segment service insertion.

Yes, service insertion feature can redirect both same-region and cross-region traffic via network function group associated core network attachments. 

By default, Cloud WAN will select an attachment in one out of the two regions (single-hop mode) from network function group for service insertion based on a default region priority list. That way cross-region traffic across two regions is redirected to a network function (e.g. inspection VPC) in one of the two regions and not doubly inspected. You can choose to inspect traffic in both regions by selecting dual-hop mode in Cloud WAN policy. You can also choose to override default region preferences using the with-edge-overrides clause in Cloud WAN policy. 

Segments are isolated routing domains that you can associate attachments with full control over routing within and across segments. E.g you can add or delete routes within a segment or share routes across segments. Network Function Group is a collection of attachments that point to specialized network or security functions. While Network Function Group have their own route tables, these routes are automatically propagated (with next hop redirections) based on your service insertion configuration in the policy doc. While you have visibility into these routes you cannot add, delete or share routes within a Network Function Group. 

For the workload segments (aka segments that need Service Insertion), all Cloud WAN attachment types (VPC, VPN, Connect, TGW peering Route-Table attachments) are supported. Similarly for Network Function Group (aka where network functions reside), all CWAN attachment types (VPC, VPN, Connect, TGW peering Route-Table attachments) are supported.

You can use segment action “send-via” to steer inter-segment or intra-segment traffic via network function group attachments (for example, in an east-west inspection use-case). You can use segment action “send-to” to steer traffic from a segment to a network function group attachment (for example an north south Internet ingress/egress use-case). 

There is no explicit quota limit for Network Function Group. However, a network function group uses one core network segment under the hood and hence the maximum segment and route limit quota needs to be considered for service insertion deployments.

Appliance mode is independent of Service insertion and is required if you want to ensure stateful inspection via your security infrastructure in the VPC. You need to enable Appliance mode on your inspection VPC attachments to ensure traffic in both directions for a particular network flow are steered to the same AZ and as a result to the same security appliance for purposes of stateful inspection. 

To get started with Cloud WAN, create a free AWS account and start building in the AWS Management Console.