# Networking in AWS Control Tower
<a name="networking"></a>

AWS Control Tower provides basic support for networking through VPCs.

If the default configuration or capabilities of the AWS Control Tower VPC do not meet your needs, you can use other AWS services to configure your VPC. For more information about how to work with VPCs and AWS Control Tower, see [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf).

AWS Control Tower supports IPv4 and IPv6 protocols, through dual-stack IP addresses. For more information, see [AWS Control Catalog endpoints and quotas](https://docs.aws.amazon.com//general/latest/gr/controlcatalog.html) and [AWS Control Tower endpoints and quotas](https://docs.aws.amazon.com//general/latest/gr/controltower.html).

**Related topics**
+ For information about how AWS Control Tower works when you enroll accounts that have existing VPCs, see [Enroll existing accounts with VPCs](enroll-account.md#enroll-existing-accounts-with-vpcs).
+ With Account Factory, you can provision accounts that include an AWS Control Tower VPC, or you can provision accounts without a VPC. For information about how to delete the AWS Control Tower VPC or configure AWS Control Tower accounts without a VPC, see [Walkthrough: Configure AWS Control Tower Without a VPC](configure-without-vpc.md).
+ For information about how to change account settings for VPCs, see the [ Account Factory documentation](https://docs.aws.amazon.com//controltower/latest/userguide/account-factory.html#configuring-account-factory-with-VPC-settings) on updating an account.
+ For more information about working with networking and VPCs in AWS Control Tower, see the section about [Networking](https://docs.aws.amazon.com//controltower/latest/userguide/related-information.html#networking) on the *Related information* page of this *User Guide*.

## VPCs and AWS Regions in AWS Control Tower
<a name="vpcs-and-regions"></a>

As a standard part of account creation, AWS creates an AWS-default VPC in every Region, even the Regions you are not governing with AWS Control Tower. This default VPC is not the same as a VPC that AWS Control Tower creates for a provisioned account, but the AWS default VPC in a non-governed Region may be accessible to IAM users.

Adminstrators can enable the Region deny control, so that your end-users do not have permission to connect to a VPC in *a Region that's supported by AWS Control Tower* but outside your governed Regions. To configure the Region deny control, go to the **Landing zone settings** page and select **Modify settings**.

The Region deny control blocks API calls to most services in non-governed AWS Regions. For more information, see [Deny access to AWS based on the requested AWS Region.](https://docs.aws.amazon.com//controltower/latest/userguide/primary-region-deny-policy.html).

**Note**  
The Region deny control may not prevent IAM users from connecting to an AWS default VPC in a Region where AWS Control Tower is not supported.

Optionally, you can remove the AWS default VPCs in non-governed Regions. To list the default VPC in a Region you can use a CLI command similar to this example:

```
aws ec2 --region us-west-1 describe-vpcs --filter Name=isDefault,Values=true
```

# Overview of AWS Control Tower and VPCs
<a name="vpc-concepts"></a>

Here are some essential facts about AWS Control Tower VPCs:
+ The VPC created by AWS Control Tower when you provision an account in Account Factory is not the same as the AWS default VPC.
+ When AWS Control Tower sets up a new account in a supported AWS Region, AWS Control Tower automatically deletes the default AWS VPC, and it sets up a new VPC configured by AWS Control Tower.
+ Each AWS Control Tower account is allowed one VPC that's created by AWS Control Tower. An account can have additional AWS VPCs within the account limit.
+ Every AWS Control Tower VPC has three Availability Zones in all Regions except for the US West (N. California) Region,`us-west-1`, and two Availability Zones in `us-west-1`. By default, each Availability Zone is assigned one public subnet and two private subnets. Therefore, in Regions except US West (N. California) each AWS Control Tower VPC contains nine subnets by default, divided across three Availability Zones. In US West (N. California), six subnets are divided across two Availability Zones.
+ Each of the subnets in your AWS Control Tower VPC is assigned a unique range, of equal size.
+ The number of subnets in a VPC is configurable. For more information about how to change your VPC subnet configuration, see [the Account Factory topic](https://docs.aws.amazon.com//controltower/latest/userguide/account-factory.html).
+ Because the IP addresses do not overlap, the six or nine subnets within your AWS Control Tower VPC can communicate with each other in an unrestricted manner.

When working with VPCs, AWS Control Tower makes no distinction at the Region level. Every subnet is allocated from the exact CIDR range that you specify. The VPC subnets can exist in any Region.

**Notes**

**Manage VPC costs**  
If you set the Account Factory VPC configuration so that public subnets are enabled when provisioning a new account, Account Factory configures VPC to create a NAT Gateway. You will be billed for your usage by Amazon VPC.

**VPC and control settings**  
If you provision Account Factory accounts with VPC internet access settings enabled, that Account Factory setting overrides the control [Disallow internet access for an Amazon VPC instance managed by a customer](https://docs.aws.amazon.com//controltower/latest/controlreference/data-residency-controls.html#disallow-vpc-internet-access). To avoid enabling internet access for newly provisioned accounts, you must change the setting in Account Factory. For more information, see [Walkthrough: Configure AWS Control Tower Without a VPC](https://docs.aws.amazon.com//controltower/latest/userguide/configure-without-vpc.html).

# CIDR and Peering for VPC and AWS Control Tower
<a name="vpc-ct-cidr"></a>

This section is intended primarily for network administrators. Your company’s network administrator usually is the person who selects the overall CIDR range for your AWS Control Tower organization. The network administrator then allocates subnets from within that range for specific purposes.

When you choose a CIDR range for your VPC, AWS Control Tower validates the IP address ranges according to the RFC 1918 specification. Account Factory allows a CIDR block of up to `/16` in the ranges of: 
+ `10.0.0.0/8`
+ `172.16.0.0/12`
+ `192.168.0.0/16`
+ `100.64.0.0/10` (only if your internet provider allows usage of this range)

The `/16` delimiter allows up to 65,536 distinct IP addresses.

You can assign any valid IP addresses from the following ranges:
+ `10.0.x.x to 10.255.x.x`
+ `172.16.x.x – 172.31.x.x`
+ `192.168.0.0 – 192.168.255.255` (no IPs outside of `192.168` range)

If the range you specify is outside of these, AWS Control Tower provides an error message.

The default CIDR range is `172.31.0.0/16`.

When AWS Control Tower creates a VPC using the CIDR range you select, it assigns the identical CIDR range to *every VPC* for every account you create within the organizational unit (OU). Due to the default overlap of IP addresses, this implementation does not initially permit peering among any of your AWS Control Tower VPCs in the OU.

**Subnets**

Within each VPC, AWS Control Tower divides your specified CIDR range evenly into nine subnets (except in US West (N. California), where it is six subnets). None of the subnets within a VPC overlap. Therefore, they all can communicate with each other, within the VPC.

In summary, by default, subnet communication within the VPC is unrestricted. The best practice for controlling communication among your VPC subnets, if needed, is to set up access control lists with rules that define the permitted traffic flow. Use security groups for control of traffic among specific instances. For more information about setting up security groups and firewalls in AWS Control Tower, see [Walkthrough: Set Up Security Groups in AWS Control Tower With AWS Firewall Manager](https://docs.aws.amazon.com//controltower/latest/userguide/firewall-setup-walkthrough.html).

**Peering**

AWS Control Tower does not restrict VPC-to-VPC peering for communication across multiple VPCs. However, by default, all AWS Control Tower VPCs have the same default CIDR range. To support peering, you can modify the CIDR range in the settings of Account Factory so that the IP addresses do not overlap.

If you change the CIDR range in the settings of Account Factory, all new accounts that are subsequently created by AWS Control Tower (using Account Factory) are assigned the new CIDR range. The old accounts are not updated. For example, you can create an account, then change the CIDR range and create a new account, and the VPCs allocated to those two accounts can be peered. Peering is possible because their IP address ranges are not identical.

# Access AWS Control Tower using an interface endpoint (AWS PrivateLink)
<a name="networking-privatelink"></a>

You can use AWS PrivateLink to create a private connection between your VPC and AWS Control Tower. You can access AWS Control Tower as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don't need public IP addresses to access AWS Control Tower.

You establish this private connection by creating an *interface endpoint*, powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for AWS Control Tower.

For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the *AWS PrivateLink Guide*.

## Considerations for AWS Control Tower
<a name="privatelink-vpc-endpoint-considerations"></a>

Before you set up an interface endpoint for AWS Control Tower, review [Considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the *AWS PrivateLink Guide*.

AWS Control Tower supports making calls to all of its API actions through the interface endpoint.

## Create an interface endpoint for AWS Control Tower
<a name="privatelink-vpc-endpoint-create"></a>

You can create an interface endpoint for AWS Control Tower using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.

Create an interface endpoint for AWS Control Tower using the following service names:

```
com.amazonaws.region.controltower
com.amazonaws.region.controltower-fips
```

If you enable private DNS for the interface endpoint, you can make API requests to AWS Control Tower using its default Regional DNS name. For example, `controltower.us-east-1.amazonaws.com`.

## Create an endpoint policy for your interface endpoint
<a name="privatelink-vpc-endpoint-policy"></a>

An endpoint policy is an IAM resource that you can attach to an interface endpoint. The default endpoint policy allows full access to AWS Control Tower through the interface endpoint. To control the access allowed to AWS Control Tower from your VPC, attach a custom endpoint policy to the interface endpoint.

An endpoint policy specifies the following information:
+ The principals that can perform actions (AWS accounts, IAM users, and IAM roles).
+ The actions that can be performed.
+ The resources on which the actions can be performed.

For more information, see [Control access to services using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *AWS PrivateLink Guide*.

**Example: VPC endpoint policy for AWS Control Tower actions**  
The following is an example of a custom endpoint policy. When you attach this policy to your interface endpoint, it grants access to the listed AWS Control Tower actions for all principals on all resources.

```
{
   "Statement": [
      {
         "Principal": "*",
         "Effect": "Allow",
         "Action": [
            "controltower:ListEnabledControls",
            "controltower:ListLandingZones"
         ],
         "Resource":"*"
      }
   ]
}
```

**Note**  
For a complete list of AWS Control Tower API operations, see the [AWS Control Tower API Reference](https://docs.aws.amazon.com//controltower/latest/APIReference/Welcome.html).