Amazon VPC

(1)

Amazon VPC

AWS Cloud WAN

(2)

Amazon VPC: AWS Cloud WAN

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is AWS Cloud WAN?

AWS Cloud WAN is a managed wide-area networking (WAN) service that you can use to build, manage, and monitor a unified global network that connects resources running across your cloud and on-premises environments. It provides a central dashboard from which you can connect on-premises branch offices, data centers, and Amazon Virtual Private Clouds (VPCs) across the AWS global network. You can use simple network policies to centrally configure and automate network management and security tasks, and get a complete view of your global network.

There are a number of ways you can work with AWS Cloud WAN to create and maintain your core network, policies, segments, and attachments:

• AWS Management console

The AWS Management console provides a web interface for you to create your global and core networks, policy versions, segments, and attachments. For more information on using the console to create and maintain your global and core networks, see Getting started (p. 4).

• AWS Command Line Interface (AWS CLI)

Provides command-line support for a broad set of AWS services using the command line. For more information see the Amazon EC2 command line reference, which includes AWS Transit Gateway and Amazon VPC and the AWS Network Manager API reference.

• AWS SDKs

Provides language-speciﬁc API operations and takes care of a number of connection details, such as calculating signatures, handling request retries, and handling errors. For more information, see the AWS Network Manager API reference.

• Query API

Provides low-level API actions using HTTPS requests. Using the Query API is the most direct way to access Amazon VPC, but it requires that your application handle low-level details such as generating the hash to sign the request, and handling errors. For more information, see the Amazon EC2 API Reference.

AWS Cloud WAN concepts

The following are the key concepts for AWS Cloud WAN:

• Global network

A single, private network that acts as the high-level container for your network objects. A global network can contain both AWS Transit Gateways and other AWS Cloud WAN core networks. These can be seen in the AWS Network Manager console.

• Core network

The part of your global network managed by AWS. This includes Regional connection points and attachments, such as VPNs, VPCs, and Transit Gateway Connects. Your core network operates in the Regions that are deﬁned in your core network policy document.

• Core network policy

A core network policy document is a single document applied to your core network that captures your intent and deploys it for you. The core network policy is a declarative language that deﬁnes segments,

(6)

Concepts

AWS Region routing, and how attachments should map to segments. With a core network policy, you can describe your intent for access control and traffic routing, and AWS Cloud WAN handles the configuration details. Some examples of advanced architectures that you can create with policy include creating a segment for shared services (for example, service directories or authentication services), providing internet access through a firewall for a segment, automatically assigning VPCs to segments based on tags, and defining which AWS Regions a segment is available in.

Over time you might ﬁnd that you want to make adjustments or additions to your core network policy.

With a policy, you can make any changes or additions to your core network and apply those changes through an updated JSON policy. You can do this using either the visual editor on the console, or through an included JSON editor. You can maintain multiple versions of a policy, although only one policy can be in eﬀect. At any time, you can update your core network to use a new policy or revert to a previous version.

• Attachments

Attachments are any connections or resources that you want to add to your core network. Supported attachments include VPCs, VPNs, Transit Gateway route table attachments, and Connect attachments.

• Core Network Edge

The Regional connection point managed by AWS in each Region, as deﬁned in the core network policy.

Every attachment connects to a Core Network Edge. Under the hood, this is an AWS Transit Gateway, and it inherits many of the same properties.

In your core network policy document, you deﬁne the AWS Region where you want connectivity.

At any time, you can add or remove AWS Regions using the policy document. For each AWS Region that you define in the policy document, AWS Cloud WAN then creates a Core Network Edge router in the specified Region. All Core Network Edges in your core network create full-mesh peering with each other to form a highly resilient network. Traffic across the AWS global network uses redundant connections and multiple paths.

• Network segments

Segments are dedicated routing domains, which means that by default, only attachments within the same segment can communicate. You can deﬁne segment actions that share routes across segments in the core network policy. In a traditional network, a segment is similar to a globally consistent Virtual Routing and Forwarding (VRF) table, or a Layer 3 IP VPN over an MPLS network.

AWS Cloud WAN supports built-in segmentation, which means that you can more easily manage network isolation across your AWS and on-premises locations. Using network segments, you can divide your global network into separate isolated networks. For example, you might want to isolate traﬃc between diﬀerent parts of your business, such as between retail sites or IT networks.

You can create a segment and define whether resources that ask for access require approval. You can also define explicit route filters to be applied before those routes can be attached to a segment.

Each attachment connects to one segment. Each segment will create a dedicated routing domain.

You can create multiple network segments within your global network. Resources connected to the same segment can only communicate within the segment. Optionally, resources in the same segment can be isolated from each other, with access only to shared services. With segments, AWS maintains a consistent conﬁguration across AWS Regions for you, instead of you needing to synchronize conﬁguration across every device in your network.

• Segment actions and attachment policies

Segment actions deﬁne how routing works between segments. After you create a segment, you can choose to map attachments to the segments either by explicitly mapping a resource to a segment (for example, "VpcId: "vpc-2f09a348) or by creating and using attachment policies. Instead of manually associating a segment to each attachment, attachments are tagged. Those tags are then associated with the applicable segment. When attachments are mapped to segments, you can choose how routes are shared between segments. For example, you might want to share access to a VPN

(7)

Concepts

across multiple segments, or allow access between two types of branch offices. You can also choose to configure centralized internet routing for a segment, or route traffic between segments through a firewall.

• Core network owner and Attachment owner

When creating a core network within a global network, the user that creates the core network automatically becomes the owner of the core network. A core network owner has full control and visibility over all parts of the AWS Cloud WAN network. The core network owner can then share a core network across accounts or across an organization using AWS Resource Access Manager. For more information, see the section called “Share a core network” (p. 39). The account to which the core network is shared becomes an attachment owner. An attachment owner has permission only to create connections, attachments, or tags, but no permission for any core network tasks. A core network owner can also be an attachment owner.

A core network owner can:

• Create, update, restore, delete, or share a Cloud WAN network.

• Create, update, download, run, delete, or restore core network policy versions.

• Create, update, or delete core network attachments.

• Accept or reject core network attachments.

• Create, update, or remove attachment tags.

• Visualize network topology and policy change sets.

• Track network events, routes, and performance.

• Create sites, links, devices, and other transit gateway associations.

An attachment owner can:

• Create, update, or delete VPC attachments.

• Add, update, or remove attachment tags.

(8)

Prerequisites

Getting started with AWS Cloud WAN

To get started with AWS Cloud WAN, you ﬁrst create your global network. Your global network contains all of your network resources, such as core networks, sites, devices, and attachments. During the creation process, you can choose to create your core network and core network policy simultaneously. Or you can choose to create the core network, and then create a policy at a later time. Creating a core network and policy creates the structure of your core network and implements it. Until you ﬁnish creating your core network and core network policy, you won't be able to do anything in your global network. After the structure is implemented, you can then add attachments, devices, or sites, and you can register existing transit gateways.

Prerequisites

There are no prerequisites for setting up AWS Cloud WAN. However, some features are not available to you unless you set them up in advance. These features are described in the following table:

Prerequisite Description

Events and metrics Before viewing events on the Events dashboard, you must complete a one-time setup that registers your events with CloudWatch Logs Insights. Until you register your events, you'll be unable to view any of your events on the dashboard. See the section called “Onboard CloudWatch Logs Insights” (p. 83) for the steps to register your events.

Transit gateways A transit gateway must ﬁrst be created on

the Amazon Virtual Private Cloud console at console.aws.amazon.com/vpc/home.

Transit gateways that you have created in Amazon VPC can then be registered in AWS Cloud WAN to be part of your AWS Cloud WAN global network.

Steps to create your global and core network

The following high-level steps provide links to the required and optional procedures for setting up the structure of your AWS Cloud WAN global and core network.

Step 1: the section called “Create a global network” (p. 5).

Step 2: the section called “Create a core network and core network policy” (p. 6).

Step 3: the section called “Create an attachment” (p. 7).

Step 4: (Optional) the section called “Create a core network policy version” (p. 16).

(9)

Create a global network

Step 5: (Optional) the section called “Register a transit gateway” (p. 11).

Step 6: (Optional) the section called “Add a device” (p. 12).

Step 7: (Optional) the section called “Create a site” (p. 12).

After getting your AWS Cloud WAN network set up, you can work with and modify any aspect of the network. Steps for working with your global and core network can be found in Work with AWS Cloud WAN (p. 14). For example, you can:

• Add new segments and implement an updated policy version.

• Add, edit, or remove attachments, devices, and sites.

• Add new resource tags to further help identify your network resources.

• View logical and topological trees of your global and core networks.

You can also view visualizations of your global and core networks as topological trees and logical diagrams, and you can monitor and track events. See Visualize and monitor global and core networks (p. 53) for the ways you can visualize and monitor your global and core networks.

Create a global network

The ﬁrst step in setting up AWS Cloud WAN is to create a global network. A global network is a single, private network that acts as the high-level container for your network objects. A Global Network can contain both an AWS Transit Gateway and other Cloud WAN core networks. These will appear in the AWS Network Manager console. When you create a global network, you can create a core network at the same time. You can also choose to create a core network later on.

You can either create a global network using the AWS console or through the command line or API.

Before you can set up your core network, you must ﬁrst set up your global network.

To create a global network using the AWS console

1. Open the AWS Network Manager console at https://console.aws.amazon.com/vpc/

home#networkmanager/.

2. Choose Get started.

3. Choose Create global network.

4. Enter a Name and Description for your global network.

5. (Optional) In Additional settings, add Key and Value tags that further help identify an Network Manager resource. To add multiple tags, choose Add tag for each tag that you want to add.

6. (Optional) Do one of the following:

• Keep the Add core network in your global network check box selected, and then choose Next to set up your core network and policies. For detailed instructions, see the section called “Create a core network while creating a global network” (p. 6).

• Set up your core network later on.

1. Clear the Add core network in your global network check box, and then choose Next to review your global network details.

2. Choose Edit for any detail that you want to change, and then choose Create global network.

The Global networks page appears with a conﬁrmation box that your global network was created successfully. Later, when you're ready to add your core network, see the section called

“Create a core network after creating a global network” (p. 7).

(10)

Create a core network and core network policy

To create a global network using the command line or API

• create-global-network

Next step: the section called “Create a core network and core network policy” (p. 6).

Create a core network and core network policy

After you've created your global network, you can create a core network within your global network.

When you create your core network, you also create the core network policy that deploys your network structure as it sets up the permissions. When the core network has been created, you can then create attachments within the network, and set up transit gateways and devices. At any time, you can also modify your policy and deploy a new version to better suit your business needs. For steps to create a new version of a policy, see the section called “Create a core network policy version” (p. 16).

Note

You can only have one core network for each of your global networks.

Create a core network while creating a global network

To create a core network while creating a global network

Prerequisite: the section called “Create a global network” (p. 5).

1. Create the core network. See the section called “Create a global network” (p. 5).

2. Under Core network general settings, enter a Name and Description to identify the core network.

3. (Optional) Choose Additional settings to add one or more Key and Value tags to help identify this network resource.

4. (Optional) Under Core network policy settings, set the beginning and ending ASN range (Autonomous System Number). Format the range as xxxxx - xxxxx.

Note

ASN is the Border Gateway Protocol (BGP) for the new core network. Valid ranges are 64512 – 65334 and 4200000000 – 4294967294.

5. Choose the Edge locations. These are the Regions where your edges are located. You can have more than one edge location, but you must choose at least one. You can select multiple edge locations from the dropdown list.

6. Enter a Name to identify the segment. The name can include up to 100 alphanumeric characters.

Blank spaces and hyphens are not allowed. For example, if this core network is going to be used for development work, you can name the segment development.

7. Choose Next to review the global network details. Choose Edit to make any changes.

8. Choose Create global network.

Your global network is created. The core network policy starts creating and deploying your core network.

Important

A core network is not deployed instantaneously after creation. It can sometimes take several minutes or longer to complete, depending on the number of edge locations. While the core network is being created, you can't create any attachments within your core network or create policy versions. To view the status of the deployment, in the navigation

(11)

Create a core network after creating a global network

pane, choose Policy versions. While the policy is being implemented, the Change set state is Executing. After the policy is implemented, the Alias is LIVE, and the Change set state changes to Execution succeeded.

9. After your policy is LIVE and the core network has been created, you can begin to add attachments to your core network. See the section called “Create an attachment” (p. 7).

Create a core network after creating a global network

To create a core network after creating a global network

1. Access the AWS Network Manager console at https://console.aws.amazon.com/vpc/

3. Choose the global link that doesn't have a core network assigned to it.

4. The Core network displays a message that the core network is not yet enabled. This indicates that there is no core network associated with the global network.

5. Choose Create core network.

6. On the Create core network page, enter an optional Name and Description for the core network.

The name can include up to 100 alphanumeric characters.

7. (Optional) Under Additional settings, add one or more Key and Value tags to help identify this core network.

8. Choose the Edge locations. These are the Regions where your edges are located. You can have more than one edge location, but you must choose at least one. You can select multiple edge locations from the dropdown list.

9. Enter a Segment name and Segment description to identify the segment. The name can include up to 100 alphanumeric characters. Blank spaces and hyphens are not allowed. For example, if this core network is going to be used for development work, you can name the segment development.

10. Choose Create core network.

11. Your global network is created, and the core network policy starts creating and deploying your core network.

Important

A core network is not deployed instantaneously after creation. It can sometimes take several minutes or longer to complete, depending on the number of edge locations. While the core network is being created, you can't create any attachments within your core network or create policy versions. To view the status of the deployment, in the navigation pane, choose Policy versions. While the policy is being implemented, the Change set state is Executing. After the policy is implemented, the Alias is LIVE, and the Change set state changes to Execution succeeded.

12. After your policy is LIVE and the core network has been created, you can begin to add attachments to your core network. See the section called “Create an attachment” (p. 7).

Next step: the section called “Create an attachment” (p. 7).

Create an attachment

When you attach a VPC to a core network edge, you must specify one subnet from each Availability Zone to be used by the core network edge to route traﬃc. Specifying one subnet from an Availability Zone enables traﬃc to reach resources in every subnet in that Availability Zone. Limits mentioned on the Transit Gateway attachment to VPC page of the Transit Gateway User Guide applies also to core

(12)

Add a core network attachment using the command line or API

network VPC attachments. You can only add attachments after your core network is deployed and the core network policy is in place.

You can work with core network attachments using the Amazon VPC Console or the command line or API.

Attachment states can be one of the following. Attachment states appear on the Attachments page of the AWS Cloud WAN console.

• Creating — Creation of an attachment is in process.

• Deleting — Deletion of an attachment is in process.

• Pending network update — Waiting for the connection of attachments to the core network.

• Pending tag acceptance — Waiting for the core network owner to review the tag change for an attachment.

• Pending attachment acceptance — Waiting for the core network owner to accept or reject an attachment.

• Rejected — The core network owner rejected the attachment.

• Available — The attachment is fully functional.

The following are the supported core network attachment types. The links take you to instructions for adding that attachment type by using the AWS Cloud WAN console:

• Connect (p. 8)

• Connect peer (p. 9)

• VPC (p. 10)

• VPN (p. 11)

Add a core network attachment using the command line or API

You can create a Connect, VPC, or VPN attachment using the command line or API.

To add a core network attachment using the command line or API

• Create a Connect attachment: create-connect-attachment

• Create a Connect peer attachment: get-connect-attachment

• Create a VPC attachment: create-vpc-attachment

• Create a VPN attachment: create-vpn-attachment

Next step: (Optional) the section called “Create a core network policy version” (p. 16).

Add a Connect attachment

You can create a transit gateway Connect attachment to establish a connection between a core network edge and third-party virtual appliances (such as SD-WAN appliances) running in Amazon VPC. A Connect attachment supports the Generic Routing Encapsulation (GRE) tunnel protocol for high performance, and the Border Gateway Protocol (BGP) for dynamic routing. After you create a Connect attachment, you can create one or more GRE tunnels (also referred to as Transit Gateway Connect peers) on the Connect attachment to connect the core network edge and the third-party appliance. You establish two BGP sessions over the GRE tunnel to exchange routing information. The two BGP sessions are for redundancy.

(13)

Add a Connect peer

A Connect attachment uses an existing VPC attachment as the underlying transport mechanism. This is referred to as the transport attachment.

The Core Network Edge identifies matched GRE packets from the third-party appliance as traffic from the Connect attachment. It treats any other packets, including GRE packets with incorrect source or destination information, as traffic from the transport attachment.

Note

A Connect attachment must be created in the same AWS account that owns the core network.

To add a Connect attachment

3. On the Global networks page, choose the global network link that for the core network you want to add an attachment to.

4. In the navigation pane, choose Attachments.

5. Choose Create attachment.

6. Enter a Name identifying the attachment.

7. From the Edge location drop-down list, choose the location where the attachment is located.

8. Choose Connect.

9. From the Connect attachment section, choose the Transport Attachment ID that will be used for the Connect attachment.

10. (Optional) In the Tags section, add Key and Value tags to further help identify this resource. You can add multiple tags by choosing Add tag, or remove any tag by choosing Remove tag.

Add a Connect peer

You can create a Connect peer (GRE tunnel) for an existing Connect attachment. When you create the Connect peer, you must specify the GRE outer IP address on the appliance side of the Connect peer.

To add a Connect peer attachment

8. Choose Create Connect peer.

9. Enter a Name to identify the Connect peer.

10. (Optional) For the Core network GRE address, enter the GRE outer IP address for the core network edge. By default, the ﬁrst available address from the Inside CIDR block is used.

11. For the Peer GRE address, enter the GRE outer IP address for the Core Network Edge. By default, the ﬁrst available address from the Inside CIDR block is used.

12. For BGP Inside CIDR blocks IPv4, enter the range of inside IPv4 addresses used for BGP peering. Use a /29 CIDR block from the 169.254.0.0/16 range.

(14)

Add a VPC attachment

13. (Optional) For BGP Inside CIDR blocks IPv6, enter the range of inside IPv6 addresses used for BGP peering. Use a /125 CIDR block from the fd00::/8 range.

14. For Peer ASN, specify the Border Gateway Protocol (BGP) Autonomous System Number (ASN) for the appliance. You can use an existing ASN that's assigned to your network. If you do not have one, you can use a private ASN in the 64512–65534 range.

The default is the same ASN as the core network edge. If you configure the Peer ASN to be different than the core network edge ASN (eBGP), you must configure ebgp-multihop with a time-to-live (TTL) value of 2.

15. (Optional) In the Tags section, add Key and Value pairs to further help identify this resource. You can add multiple tags by choosing Add tag, or remove any tag by choosing Remove tag.

While the attachment is being created, the State on the Attachments page displays Creating. This might take several minutes or longer, depending on the number of edge locations on your core network. During this time you can't make any changes to the attachment. Once the attachment is created, the State changes to Available, indicating that the attachment has been created.

Add a VPC attachment

When you attach a VPC to a core network edge, you must specify one subnet from each Availability Zone to be used by the core network edge to route traﬃc. Specifying one subnet from an Availability Zone enables traﬃc to reach resources in every subnet in that Availability Zone. For more information about limits to core network VPC attachments, see Transit Gateway attachment to VPC in the Transit Gateway User Guide.

To add a VPC attachment

8. Choose VPC.

9. In the VPC attachment section, choose IPv6 support if the attachment supports IPv6.

10. From the VPC IP dropdown list, choose the VPC ID to attach to the core network.

11. After choosing the VPC ID, you're prompted to choose the Availability Zone and Subnet Id in which to create the core network VPC attachment. The Availability Zones that are listed are those edge locations that you chose when you created your core network. You must choose at least one Availability Zone and subnet ID.

(15)

Add a Site-to-Site VPN attachment

To attach a Site-to-Site VPN connection to your core network edge, you must ﬁrst create a Site-to-Site VPN connection with Target Gateway Type set to Not Associated. See Creating an AWS Cloud WAN Site- to-Site VPN attachment in the AWS Site-to-Site VPN User Guide.

Note

• Your Site-to-Site VPN must be attached to a core network before you can start conﬁguring a customer gateway. AWS doesn't provision these endpoints until the Site-to-Site VPN is attached to the core network.

• A Site-to-Site VPN attachment must be created in the same AWS account that owns the core network.

To add a Site-to-Site VPN attachment

8. Choose VPN.

9. From the VPN attachment section, choose the VPN ID to be used for the VPN attachment.

Register a transit gateway

Prerequisite: A transit gateway must ﬁrst be created on the Amazon Virtual Private Cloud console at console.aws.amazon.com/vpc/home.

Transit gateways that you've created in Amazon VPC can be registered in AWS Cloud WAN to be part of your AWS Cloud WAN global network.

To register a transit gateway in AWS Cloud WAN

3. On the Global networks page, choose the global network ID.

4. Choose Transit gateways.

(16)

Create a site

5. For Select Transit Gateway, choose the transit gateway that you want to register.

6. Choose Register Transit Gateway.

Next step: (Optional) the section called “Create a site” (p. 12).

Create a site

A site represents the physical location of your network, using location information. Sites are used in dashboard visualizations.

To create a site

4. In the navigation pane, choose Sites.

5. Choose Create site.

6. For Name and Description, enter a name and description for the site.

7. For Address, enter the physical address of the site, for example, New York, NY 10004.

8. For Latitude, enter the latitude coordinates for the site (for example, 40.7128).

9. For Longitude, enter the longitude coordinates for the site (for example, -74.0060).

10. (Optional) Under Additional settings, add one or more Key and Value tags to help identify this site.

11. Choose Create site.

Next step: (Optional) the section called “Add a device” (p. 12).

Add a device

Devices represent a physical or virtual appliance.

When you've created a device, you have options for further reﬁning it. For more information on working with devices in AWS Cloud WAN, see Working with devices (p. 47).

To add a device

4. In the navigation pane, choose Devices.

5. Choose Create Device.

6. For Name and Description, enter a name and description for the device.

7. For Model, enter the device model number.

8. For Serial number, enter the serial number for the device.

9. For Type, enter the device type.

10. For Vendor, enter the name of the vendor, for example, Cisco.

(17)

Add a device

11. For Location type, specify whether the device is located in a remote location (On-premises, Data center/ Other Cloud Provider) or in the AWS Cloud.

If you choose AWS Cloud, specify the location of the device within AWS:

• For the Zone, specify the name of an Availability Zone,Local Zone, Wavelength Zone, or an Outpost.

• For the Subnet, specify the Amazon Resource Name (ARN) of the subnet (for example, arn:aws:ec2:useast-1:111111111111:subnet/subnet-abcd1234).

12. For Address, enter the physical location of the site (for example New York, NY 10004).

13. For Latitude, enter the latitude coordinates for the site (for example, 40.7128).

14. For Longitude, enter the longitude coordinates for the site (for example, -74.0060).

(18)

Global and core networks

Work with AWS Cloud WAN

With your global and core networks in place, you can modify and change diﬀerent aspects of your global network and core networks.

Topics

• Global and core networks (p. 14)

• Create a core network policy version (p. 16)

• Core network policies (p. 21)

• Attachments (p. 36)

• Share a core network (p. 39)

• Attachments on a shared core network (p. 41)

• Tag core resources (p. 42)

• Sites and links (p. 44)

• Devices (p. 47)

Global and core networks

A core network owner can maintain all aspects of global and core networks, including viewing, deleting, and updating networks.

Global networks

View, edit, or delete any of your current global networks.

Topics

• View and edit global network information (p. 14)

• Delete a global network (p. 15)

View and edit global network information

To view details about a global network

4. Choose the Details tab.

5. On the Details page you can edit the following:

• (Optional) To edit the description of your global network, in the Details section, choose Edit.

In the Description ﬁeld, enter a new description for your global network, and then choose Edit global network.

• (Optional) To edit, add, or delete tags, in the Tags section, choose Edit tags.

• To edit any current tag, change the Key or Value text as needed.

• To add additional Key and Value tags, choose Add tag for each tag that you want to add.

• To remove any existing tag, choose Remove tag.

(19)

Core networks

Delete global networks.

Delete a global network

When you delete a global network, the deletion cannot be undone. Before you delete a global network, you must ﬁrst delete any core networks that are associated with it. For more information on deleting core networks, see the section called “Delete a core network” (p. 15).

To delete a global network

5. On the Details page, choose Delete, and then conﬁrm that you are deleting the global network.

Core networks

View, edit, or delete core networks.

Topics

• View or edit core network information (p. 15)

• Delete a core network (p. 15)

View or edit core network information

To view or edit details about a core network

4. In the navigation pane, choose Core network.

6. On the Details page, you can edit the following:

• (Optional) To edit the description of your core network, in the Details section, choose Edit. In the Description ﬁeld, enter a new description for your core network, and then choose Edit core network.

• (Optional) To edit, add, or delete tags, in the Tags section, choose Edit tags.

• To edit any current tag, change the Key or Value text as needed.

• To add additional Key and Value tags, choose Add tag for each tag you want to add.

• To remove any existing tag, choose Remove tag.

Delete a core network

When you delete a core network, the deletion cannot be undone. After you have deleted all core networks that are associated with a global network, you can then delete a global network. For more information on deleting global networks, see the section called “Delete a global network” (p. 15).

(20)

Create a core network policy version

To delete a core network

4. In the navigation pane, choose Core network.

6. On the Details page, choose Delete, and then conﬁrm that you are deleting the core network.

Create a core network policy version

You can create a core network policy version at any time from the console, using visual editor mode or JSON mode. When you create a policy version, you can conﬁgure settings that determine how your network works. When you create a new policy version, a change set of the proposed core network changes is added. You can then review the changes and implement the new core network and core network policy when you're ready.

When you create a new policy version, the policy version ID increments from the previous LIVE version.

For example, if the current policy version ID is 1, and you create a new version of that policy, the new version is numbered 2. The latest version is displayed on the Policy versions screen with a LATEST status, indicating that the new policy is ready to implement.

Change set states can be any of the following:

• Ready to execute — A policy version change set and a new policy version have been created. This policy version was veriﬁed with no issues and is in a state where it can be implemented as the new LIVE policy. You can have multiple policy versions in this state, but you can only have one LIVE policy.

When implemented, the policy change set state changes to Execution succeeded. For the steps to implement a policy change set state, see the section called “Implement a policy version” (p. 22).

• Execution succeeded — A policy version change set state was implemented as the new LIVE policy.

• Out of date — If you have multiple policy version change sets, any policy version that's older than the current LIVE policy is set to out-of-date, indicating that it's older than the LIVE policy. You can restore an out-of-date policy. For instructions, see the section called “Restore an out-of-date policy version” (p. 22).

• Pending generation — A policy version was created and is waiting to be generated. When the version has been generated, the change set state changes to Ready to execute.

You can create a core network policy version using either the AWS Cloud WAN console or by creating a JSON ﬁle.

• the section called “Create a policy version using the AWS Cloud WAN console” (p. 16)

• the section called “Create a policy version using the JSON editor” (p. 21)

Create a policy version using the AWS Cloud WAN console

Use the AWS Cloud WAN console to create a core network policy version following these tasks:

1.Conﬁgure the network settings. (p. 17)

(21)

Network conﬁguration

2.Create network policy segments within your core network. (p. 18) 3.Create segment sharing and segment route actions. (p. 18) 4.Create policy attachments. (p. 19)

Network conﬁguration

You can use the Network configuration page to configure the Border Gateway Protocol (BGP) Autonomous System Number (ASN) for your core network. The valid ranges are 64512 - 65534 and 4200000000 - 4294967294. You can also configure the Inside CIDR blocks that are used for BGP peering on Connect peers. For more information on Transit Gateway Connect attachment and Connect peers, see the Transit Gateway Connect documentation. Using the network configuration, you can also configure the edge locations where you want the Core Network Edges to be available. At any time, you can add or remove edge locations through the network configuration.

To conﬁgure the network settings

3. On the Global networks page, choose the global network ID that for the core network you want to create a policy version for, and then choose Core network.

4. In the navigation pane, choose Policy versions.

5. Choose Create policy version.

6. In Choose policy view mode, choose Visual editor.

7. The Network conﬁguration displays general settings for the policy.

8. In General settings, choose Edit.

1. The Version can't be changed for a policy version.

2. Choose VPN ECMP support if the core network should forward traﬃc over multiple-cost routes using VPN.

3. Choose Edit general settings.

9. In the ASN ranges section, do the following:

1. Choose Create.

2. For ASN range, enter the ASN range for the policy version. For example, enter 64512-65334.

3. Choose Create ASN range.

10. In the Inside CIDR blocks section, do the following:

1. Choose Create.

2. For CIDR, enter the CIDR block that you want to use for BGP peering on Connect peers.

3. Choose Create inside CIDR block.

11. In the Edge locations section, do the following:

1. Choose Create.

2. From the Location dropdown list, choose the Region where you want the Core Network Edge router to be created. You can choose only one Region.

3. For ASN, enter the ASN number for the Region.

4. For Inside CIDR block, enter the CIDR block that you want to use for BGP peering on Connect peers. You can enter multiple CIDR blocks by choosing Add for each block that you want to add.

Choose Remove for any block that you don't want.

(22)

Segments

Note

You can't leave any blank destination CIDR blocks. Choose Remove to delete any empty blocks.

5. Choose Create edge locations.

12. Next, add your Segments. For detailed instructions, see the section called “Segments” (p. 18).

Segments

You can use a network segment to divide your global network into separate isolated networks. On the segments page, you create a segment, and then define the attachment communication mapping. Each segment creates a dedicated routing domain. You can create multiple network segments within your global network. Resources that are connected to the same segment can only communicate within the segment. Optionally, you can also set resources in the same segment to be isolated from each other, with access only to shared services. With segments, AWS maintains a consistent configuration across AWS Regions for you, meaning that you don't need to synchronize configuration across every device in your network.

To conﬁgure a segment

6. Choose Segments.

7. In the Segments section, Choose Create.

8. Enter the Segment name and Segment description to identify the segment.

9. From the Edge locations dropdown list, choose one or more segments to create.

10. Choose Require acceptance if you require approval for attachments to be mapped to this segment.

11. Choose Isolated attachments if you need this segment isolated. Attachments in isolated segments can't communicate with other segments, and attachments in other segments can't communicate with the isolated segment.

12. For Segment ﬁlter, choose if you want to Allow all shared routes from other segments, Allow selected routes, or Deny selected routes.

13. Choose Create policy.

Segment actions

Segment actions allow you to optionally share your segments or create routes.

Segment sharing

Create a shared segment.

To create a shared segment

(23)

Attachment policies

6. Choose Segment actions.

7. (Optional) In the Sharing section, choose Create, and then do the following:

1. From the Segment dropdown list, choose the core network segment that you want to share.

2. For the Segment ﬁlter, choose whether you want to allow all shared routes from other segments, to allow only selected routes, or to deny selected routes. The default is Allow all.

3. Choose Create sharing.

Segment routes

Create a segment route for a policy version.

To create a segment route

6. (Optional) In the Routes section, choose Create, and then do the following:

1. From the Segment dropdown list, choose the core network segment that you want to share.

2. For Destination CIDR Block, enter a static route. You can enter multiple CIDR blocks by choosing Add for each block that you want to add. Choose Remove for any blocks that you don't want.

Note

You can't leave any blank destination CIDR blocks. Choose Remove to delete any empty blocks.

3. Choose Blackhole if you want to "black hole" the route. If you make this choice, you can't add any attachments to the route.

4. From the Attachments list, choose any attachments that you want to include in this route.

5. Choose Create segment route.

7. (Optional) Add Attachment policies. For more information, see the section called “Attachment policies” (p. 19).

8. Choose Create route.

Attachment policies

Attachment policies control how your attachments map to your segments.

To create an attachment policy

(24)

Attachment policies

6. (Optional) Choose Attachment policies.

7. Choose Create.

8. For the Rule number, enter the rule number to apply to this attachment. Rule numbers determine the order in which rules are run.

9. Enter an optional Description to identify the attachment policy.

10. In the Action section, choose how you want to associate the attachment to the segment. Choose one of the following:

• Segment name — associates the attachment by the segment name. After choosing this option, the segment to attach to from the Attach to segment dropdown list.

• Attachment tag value — associates the attachment by the tag's value in a key-value pair. Enter the tag value in the Attachment tag value ﬁeld.

11. Choose one of the following:

• Inherit segments acceptance value if the attachment inherits the acceptance setting from a segment when a segment was created. This can't be changed.

• Requires attachment acceptance if you require approval for attachments to be mapped to this segment.

• If no acceptance option is chosen, attachments are automatically mapped to the segment.

12. (Optional) For Condition logic, further reﬁne how the attachment is associated with the segment:

• Choose OR — if you want to associate the attachment with the segment by either the Segment name/Attachment tag value, or by the chosen conditions.

• Choose AND — if you want to associate the attachment with the segment by either the Segment name/Attachment tag value and by the chosen conditions.

If no acceptance option is chosen, attachments are automatically mapped to the segment.

13. In Conditions, set the condition logic by doing the following:

1. From the Type dropdown list, choose one of the following condition types:

• Resource Id — Set an OR or AND condition that uses a Resource ID.

• Attachment type — Set an OR or AND condition that matches a speciﬁc attachment type.

• Account — Set an OR or AND condition that matches an account.

• Tag name — Set an OR or AND condition that matches a speciﬁc tag name.

• Tag value — Set an OR or AND condition that matches a speciﬁc tag value.

2. From the Operator dropdown list, choose the operator. The operator determines the relationship of the Type.

• Equals — Filters results that match the passed Condition value.

• Not equals — Filters results that do not match the passed Condition value. This option is not used for Attachment type.

• Begins with — Filters results that start with the passed Condition value. This option is not used for Attachment type.

• Contains — Filters results that match a substring within a string. This option is not used for Attachment type.

• Any — Filters results that match any ﬁeld. This option is not used for Attachment type.

(25)

Create a policy version using the JSON editor

3. In the Condition values ﬁeld, enter the value that corresponds to the Type and Operator. This option is not used for Attachment type.

4. Choose Add to include additional conditions or choose Remove to delete any conditions.

14. Choose Create attachment policy.

Create a policy version using the JSON editor

You can create a core network policy version by using the AWS Cloud WAN JSON editor. In the JSON editor, you add the parameters of your core network and policies. For a description of the required and optional parameters in the JSON ﬁle, see the section called “Core network policy parameters” (p. 24).

Note

Familiarity with creating JSON ﬁles is required.

To create a policy version using a JSON editor

6. In Choose policy view mode, choose JSON.

7. In the JSON editor, create your new policy. For the required and optional parameters in your JSON policy, see the section called “Core network policy parameters” (p. 24).

A new policy version is generated.

Next step: Optional: the section called “Register a transit gateway” (p. 11).

Core network policies

You can update, delete, or restore an out-of-date AWS Cloud WAN policy. You can also download a policy as a JSON ﬁle, and then edit the JSON ﬁle to create a new policy version. For examples of JSON policies, see the section called “Core network policy examples” (p. 29).

When you make an update to a policy version, it creates a new change set for that new policy version.

When a change set has been created, you can then implement it as your new core network policy.

Topics

• Update a core network policy version (p. 22)

• Implement a policy version (p. 22)

• Restore an out-of-date policy version (p. 22)

• Delete a policy version (p. 23)

• Download a policy (p. 23)

• Core network policy parameters (p. 24)

• Core network policy examples (p. 29)

(26)

Update a core network policy version

Before deploying a new policy version, review the proposed change set.

To access a core network policy change set

4. In the navigation pane, choose Core network, and then choose Policy versions.

5. Under Policy version ID, choose the policy version that you want to edit, and then choose Edit.

6. Change any information on the Network conﬁguration, Segments, Segment actions, or Attachment policies tabs. For more information about creating policy versions, see the section called “Create a core network policy version” (p. 16).

7. Choose Create policy. This creates a new version of the policy. The policy version is incremented by 1 from the last version.

The Change set state of the new version is set to Pending generation on the Policy versions page, and the alias is set to LATEST, indicating that this is the most recent version of the policy. When a policy version has been generated, the Change set state changes to Ready to execute. You can then implement the new policy version as your LIVE policy. See the section called “Implement a policy version” (p. 22).

Implement a policy version

A policy version is never implemented automatically. After creating a version of a policy, you can implement the policy version as your new LIVE policy.

To implement a core policy version

5. Under Policy version ID, choose the policy version that you want to implement.

6. On the Policy version - ID page, review the details about the change set.

7. Choose View or apply change set. This creates a new version of the policy. The policy version is incremented by 1 from the last policy version.

8. On the Change set page, choose Apply change set.

9. The Change set state of the new policy is set to Executing, indicating that the chosen policy version is being implemented as the new LIVE policy. When ﬁnished, the change set state changes to Execution succeeded, and the Alias changes to LIVE. If any previous policies were in the Ready to execute change set state, those change to Out of date. This indicates that those policies are now considered older than the current LIVE policy.

Restore an out-of-date policy version

An out-of-date policy can be restored as a new version of a policy.

(27)

Delete a policy version

To restore an out-of-date policy version

5. Under Policy version ID, choose the out-of-date policy version that you want to restore and then choose Restore.

The Policy version ID is incremented by 1 from the last version listed on the Policy versions page, and the Change set state displays as Pending generation.

When generated, the change set state changes to Ready to execute, and the Alias changes to LATEST. If any previous policies were in the Ready to execute change set state, those change to Out of date. This indicates that those policies are now considered older than the LATEST.

Delete a policy version

Any policy except your current LIVE policy can be deleted.

To delete a core policy version

5. Under Policy version ID, choose the policy version that you want to delete and then choose Delete.

6. Conﬁrm that you want to delete the policy version, and then choose Delete again.

Deleted policy versions are removed from the Policy versions page.

.

Download a policy

Download any policy version or your current LIVE policy as a JSON ﬁle.

To download a core policy

5. Under Policy version ID, choose the policy version that you want to download and then choose Download.

The policy downloads to your system as a JSON ﬁle. You can make changes to this JSON ﬁle as needed.

(28)

Core network policy parameters

6. To submit a policy that was created outside of the AWS Cloud WAN, follow the preceding steps to go to the Policy versions page.

7. Choose Create policy version, and then choose JSON.

8. Copy the contents of your modiﬁed JSON ﬁle, and paste those contents into the AWS Cloud WAN JSON editor.

A policy version is generated.

Core network policy parameters

The following sections describe the parameters that you use to create a core network policy version using JSON. Your JSON ﬁle contains two sections that describe the policy network settings and

segments. You can then add two optional sections for deﬁning segment actions and attachment policies.

For example JSON policies, see the section called “Core network policy examples” (p. 29).

Topics

• core-network-conﬁguration (p. 24)

• segments (p. 25)

• segment-actions (p. 26)

• attachment-policies (p. 26)

core-network-configuration

The core network conﬁguration section deﬁnes the Regions where a core network should operate.

For AWS Regions that are defined in the policy, the core network creates a Core Network Edge where you can connect attachments. After it's created, each Core Network Edge is peered with every other defined Region and is configured with consistent segment and routing across all Regions. Regions cannot be removed until the associated attachments are deleted. core-network-configuration is required.

Parameters

The following parameters are used in core-network-configuration:

• asn-ranges — The Autonomous System Numbers (ASNs) to assign to Core Network Edges. By default, the core network automatically assigns an ASN for each Core Network Edge but you can optionally deﬁne the ASN in the edge-locations for each Region. The ASN uses an array of integer ranges only from 64512 to 65534 and 4200000000 to 4294967294. No other ASN ranges can be used.

• inside-cidr-blocks — (Optional) The Classless Inter-Domain Routing (CIDR) block range used to create tunnels for AWS Transit Gateway Connect. The format is standard AWS CIDR range (for example, 10.0.1.0/24). You can optionally deﬁne the inside CIDR in the Core Network Edges section per Region. The minimum is a /24 for IPv4 or /64 for IPv6. You can provide multiple /24 subnets or a larger CIDR range. If you deﬁne a larger CIDR range, new Core Network Edges will be automatically assigned /24 and /64 subnets from the larger CIDR. an Inside CIDR block is required for attaching Connect attachments to a Core Network Edge.

• vpn-ecmp-support — (Optional) Indicates whether the core network forwards traﬃc over multiple equal-cost routes using VPN. The value can be either true or false. The default is true.

• edge-locations — An array of AWS Region locations where you're creating Core Network Edges.

The array is composed of the following parameters:

• location — An AWS Region code, such as us-east-1.

(29)

Core network policy parameters

• asn — (Optional) The ASN of the Core Network Edge in an AWS Region. By default, the ASN will be a single integer automatically assigned from asn-ranges.

• inside-cidr-blocks — (Optional) The local CIDR blocks for this Core Network Edge for AWS Transit Gateway Connect attachments. By default, this CIDR block will be one or more optional IPv4 and IPv6 CIDR preﬁxes auto-assigned from inside-cidr-blocks.

segments

The segments section defines the different segments in the network. Here you can provide descriptions, change defaults, and provide explicit Regional operational and route filters. The names defined for each segment are used in the segment-actions and attachment-policies section. Each segment is created, and operates, as a completely separated routing domain. By default, attachments can only communicate with other attachments in the same segment. segments is a required section.

Parameters

The following parameters are used in segments:

• segments — At least one segment must be deﬁned, composed of the following parameters:

• name — The name of the segment. The name is a string used in other parts of the policy document, as well as in the console for metrics and other reference points. Valid characters are a–z, and 0–9.

Note

There is no ARN or ID for a segment.

• description — (Optional) A user-deﬁned string describing the segment.

• edge-locations — (Optional) Allows you to deﬁne a more restrictive set of Regions for a

segment. The edge location must be a subset of the locations that are deﬁned for edge-locations in the core-network-conﬁguration. These locations use the AWS Region code. For example, you might want to use us-east-1 as an edge location.

• isolate-attachments — (Optional) This Boolean setting determines whether attachments on the same segment can communicate with each other. If set to true, the only routes available will be either shared routes through the share actions, which are attachments in other segments, or static routes. The default value is false. For example, you might have a segment dedicated to development that should never allow VPCs to talk to each other, even if they’re on the same segment. In this example, you would keep the default parameter of false.

• require-attachment-acceptance — (Optional) This Boolean setting determines whether attachment requests are automatically approved or require acceptance. The default is true, indicating that attachment requests require acceptance. For example, you might use this setting to allow a sandbox segment to allow any attachment request so that a core network or attachment administrator does not need to review and approve attachment requests. In this example, require- attachment-acceptance is set to false.

• deny-filter — (Optional) An array of segments that disallows routes from the segments listed in the array. It is applied only after routes have been shared in segment-actions. If a segment is listed in the deny-filter, attachments between the two segments will never have routes shared across them. For example, you might have a ﬁnancial payment segment that should never share routes with a development segment, regardless of how many other share statements are created.

Adding the payments segment to the deny-filter parameter prevents any shared routes from being created with other segments.

• allow-filter (optional) — An array of segments that explicitly allows only routes from the segments that are listed in the array. Use the allow-filter setting if a segment has a well-deﬁned group of other segments that connectivity should be restricted to. It is applied after routes have been shared in segment-actions. If a segment is listed in allow-filter, attachments between the two segments will have routes if they are also shared in the segment-actions area. For example, you might have a segment named video-producer that should only ever share routes with a video-distributor segment, no matter how many other share statements are created.

Amazon VPC

Amazon VPC

AWS Cloud WAN

Amazon VPC: AWS Cloud WAN

Table of Contents

What is AWS Cloud WAN?

AWS Cloud WAN concepts

Getting started with AWS Cloud WAN

Prerequisites

Steps to create your global and core network

Create a global network

To create a global network using the AWS console

To create a global network using the command line or API

Create a core network and core network policy

Note

Create a core network while creating a global network

To create a core network while creating a global network

Note

Important

Create a core network after creating a global network

To create a core network after creating a global network

Important

Create an attachment

Add a core network attachment using the command line or API

To add a core network attachment using the command line or API

Add a Connect attachment

Note

To add a Connect attachment

Add a Connect peer

To add a Connect peer attachment

Add a VPC attachment

To add a VPC attachment

Add a Site-to-Site VPN attachment

Note

To add a Site-to-Site VPN attachment

Register a transit gateway

To register a transit gateway in AWS Cloud WAN

Create a site

To create a site

Add a device

To add a device

Work with AWS Cloud WAN

Global and core networks

Global networks

View and edit global network information

To view details about a global network

Delete a global network

To delete a global network

Core networks

View or edit core network information

To view or edit details about a core network

Delete a core network

To delete a core network

Create a core network policy version

Create a policy version using the AWS Cloud WAN console

Network conﬁguration

To conﬁgure the network settings

Note

Segments

To conﬁgure a segment

Segment actions

Segment sharing

To create a shared segment

Segment routes

To create a segment route

Note

Attachment policies

To create an attachment policy

Create a policy version using the JSON editor

Note

To create a policy version using a JSON editor

Core network policies

Update a core network policy version

To access a core network policy change set

Implement a policy version

To implement a core policy version

Restore an out-of-date policy version

To restore an out-of-date policy version

Delete a policy version

To delete a core policy version