<a id="enable-transit-gateway-cloud"></a>

<a id="aws-transit-gateway"></a>

# Use AWS Transit Gateway on Confluent Cloud

You can use [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) to simplify the
peering architecture. The Transit Gateway acts as a highly scalable cloud
router. Rather than peering VPCs directly to each other, you only have to set up
a Transit Gateway attachment between the Transit Gateway and your VPC once, and
you can access all the networks connected to the Transit Gateway.

With Transit Gateways, your data is encrypted and never travels over the
internet.

<a id="aws-transit-gateway-requirements"></a>

## Requirements and considerations

To use AWS Transit Gateway with Confluent Cloud, you need the followings:

<a id="create-ccloud-network-for-aws-tgw"></a>
* A [Confluent Cloud network](ccloud-network/aws.md#create-ccloud-network-aws) of type
  `Transit Gateway` or `VPC Peering` on AWS.

  After you create a Confluent Cloud network for your AWS Transit Gateway hub, you
  can:
  - [Add an AWS Transit Gateway attachment to a Confluent Cloud network](#add-aws-transit-gateway-attachment)
  - [Migrate from AWS VPC Peering to AWS Transit Gateway](#migrate-from-vpc-peering-to-transit-gateway)

    Existing Confluent Cloud clusters using secure public endpoints or AWS
    PrivateLink cannot be converted to use AWS Transit Gateway.
* All AWS availability zones, except `use1-az3` in the `us-east-1` region,
  are supported.
* [Cluster links between two AWS Transit Gateway clusters](../multi-cloud/cluster-linking/private-networking.md#cluster-linking-aws-tgw) are supported in the following CIDR blocks:
  - [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918):
    `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`
  - [RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598): `100.64.0.0/10`
* AWS RAM shares are restricted to a single Confluent Cloud organization.

  To use a Transit Gateway across two Confluent Cloud organizations, you need to create
  a new RAM share for the same Transit Gateway and use it for the second
  organization.
* To connect AWS VPCs with a Confluent Cloud network set up with an AWS Transit Gateway, add a
  Transit Gateway attachments for the VPCs as described in [Create a transit
  gateway attachments to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment).
* To connect with on-premise networks with a Confluent Cloud network set up with an AWS transit
  gateway, add Direct Connect gateway attachments as described in [Transit
  gateway attachments to a Direct Connect gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-dcg-attachments.html).
* Access to Confluent Cloud serverless products

  Connections established for use with Dedicated Kafka clusters may also
  be used to connect to some serverless products. For service-specific
  information, see:
  * [Flink](../flink/concepts/flink-private-networking.md#flink-sql-private-networking)
  * [Schema Registry](../sr/fundamentals/sr-private-link.md#sr-ccloud-private-link)

## Add an AWS Transit Gateway connection

To create an AWS Transit Gateway:

1. In AWS, use an existing Transit Gateway, or
   [create a Transit Gateway](#add-aws-transit-gateway).
2. In Confluent Cloud, [add a Transit Gateway attachment](#add-aws-transit-gateway-attachment).
3. In AWS, [accept the Transit Gateway attachment](#aws-transit-gateway-accept-connection).

   This step can be automated by selecting the **Auto accept shared
   attachments** option when you create the Transit Gateway in the first step.
4. In AWS, [update the route table](#update-aws-transit-gateway-route-table).

   AWS automatically adds the new Transit Gateway attachment to the default
   Transit Gateway route table.

<a id="add-aws-transit-gateway"></a>

### Add an AWS Transit Gateway in AWS

1. In Confluent Cloud Console, in the **Network management** tab for your environment,
   click the [Transit Gateway network resource](#create-ccloud-network-for-aws-tgw) to retrieve the **Confluent Cloud AWS
   Account ID** of the network resource you want to use.
2. In [the Amazon VPC console](https://console.aws.amazon.com/vpc/),
   add an AWS Transit Gateway for your AWS account. For details, see
   [Create a Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/create-tgw.html).
   * Select the **Auto accept shared attachments** option.
3. In [AWS Resource Access Manager (RAM) Console](https://console.aws.amazon.com/ram/home), create a resource share for your
   Confluent Cloud network.

   For details, see [Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)
   and [Share a Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-sharing)
   in the AWS documentation.

   Use the **Confluent Cloud AWS Account ID** you retrieved in the first
   step as the principal of the resource share in the **Principals** step.

   In Confluent Cloud, it is not possible to share the same RAM resources between
   Organizations, due to security concerns.

   To use a Transit Gateway across two Confluent Cloud organizations, you need to
   create a new RAM share for the same Transit Gateway and use it for the second
   organization.
4. Save the Amazon Resource Name (ARN) of the resource share.

   You need to provide the name when you create a Transit Gateway attachment.

<a id="add-aws-transit-gateway-attachment"></a>

### Add an AWS Transit Gateway attachment in Confluent Cloud

Add a Transit Gateway attachment in Confluent Cloud.

### Confluent Cloud Console

1. In the [Confluent Cloud Console](https://confluent.cloud/login),
   select your environment, and click **Network management**.
2. In the **Network management** tab, select the AWS Transit Gateway
   network resource that you want to add a Transit Gateway attachment to,
   and click the **Connections** tab.
3. Click **+ Transit Gateway**. The Add Transit Gateway Attachment page
   appears.
4. Specify the following information, and click **Add**.
   * **Name**: Enter a name for your attachment.
   * **AWS RAM Share ARN**: Use the ARN you saved in the last step of
     [creating a resource share in AWS](#add-aws-transit-gateway).
   * **AWS Transit Gateway ID**: The identifier (ID) of the AWS Transit
     Gateway that you are connecting to the Confluent Cloud network.
   * **AWS VPC CIDR**: A comma-separated list of destination CIDRs that
     you want to route to from the Confluent Cloud network when you attach Confluent Cloud
     to your Transit Gateway.

     This field needs to contain all CIDR blocks in your network (cloud
     VPC, on-prem) that needs return routes from the Confluent Cloud network via
     the Transit Gateway attachment.

     The RFC 1918 and RFC 6598 private address ranges are supported as described in
     [Confluent Cloud network CIDR blocks and block size for peering and Transit Gateway](ccloud-network/aws.md#cidr-block-size).

     Public IP address ranges are not allowed.

     The routes should not be identical and not completely within the
     Confluent Cloud network CIDRs. For example, with the Confluent Cloud network CIDR
     of `10.0.0.0/16`,  `10.0.0.0/8` is a valid Transit Gateway route,
     but `10.0.0.0/24` is not a valid route.
5. Your Transit Gateway Attachment will transition to `READY` in the
   Confluent Cloud Console.

   You may need to check if **Auto accept shared attachments** is
   configured on your Transit Gateway on AWS.

### Confluent REST API

Here is an example REST request:

**REST request**

```text
POST https://api.confluent.cloud/networking/v1/transit-gateway-attachments
```

**REST authentication**

See [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication).

**REST request body**

In the request specification, include values for cloud, region, environment, connection
type, and, optionally, add the display name, CIDR, and zones for the Confluent Cloud network.
Update the attributes below with the correct values.

See  [CIDR blocks requirements](ccloud-network/aws.md#cidr-block-size) for detail
requirements.

```json
{
   "spec":{
      "display_name":"prod-tgw-use1",
      "cloud":{
         "kind":"AwsTransitGatewayAttachment",
         "ram_share_arn":"arn:aws:ram:us-west-3:000000000000:resource-share/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
         "transit_gateway_id":"tgw-xxxxxxxxxxxxxxxxx",
         "routes":[
            "100.64.0.0/10",
            "10.0.0.0/8",
            "192.168.0.0/16",
            "172.16.0.0/12"
         ]
      },
      "environment":{
         "id":"env-abc123",
         "environment":"string"
      },
      "network":{
         "id":"n-00000",
         "environment":"string"
      }
   }
}
```

The `routes` are the IP address ranges routed back to your VPC Transit
Gateway from Confluent Cloud when you attach Confluent Cloud to your Transit Gateway.
This field needs to contain all CIDR blocks in your network (cloud VPC,
on-prem) that need return routes from the Confluent Cloud network via the
Transit Gateway attachment.

The RFC 1918 and RFC 6598 private address ranges are supported as described in
[Confluent Cloud network CIDR blocks and block size for peering and Transit Gateway](ccloud-network/aws.md#cidr-block-size), and public IP ranges are not allowed for
`routes`.

The `routes` should not be identical and not completely within the
Confluent Cloud network CIDRs. For example, with the Confluent Cloud network CIDR of
`10.0.0.0/16`,  `10.0.0.0/8` is a valid Transit Gateway route, but
`10.0.0.0/24` is not a valid Transit Gateway route.

### Confluent CLI

Use the [confluent network transit-gateway-attachment create](https://docs.confluent.io/confluent-cli/current/command-reference/overview.html)
Confluent CLI command to create an AWS Transit Gateway attachment:

```bash
confluent network transit-gateway-attachment create <attachment-name> <flags>
```

The following are the command-specific flags:

* `--network`: Required. Confluent Cloud network ID.
* `--aws-ram-share-arn`: Required. AWS Resource Name (ARN) for the
  AWS Resource Access Manager (RAM) Share of the AWS Transit
  Gateway that you want Confluent Cloud to be attached to.
* `--aws-transit-gateway`: Required. The ID of the AWS Transit
  Gateway that you want Confluent Cloud to be attached to.
* `--routes`: Required. A comma-separated list of destination CIDRs that
  you want to route to from the Confluent Cloud network when you attach Confluent Cloud
  to your Transit Gateway.

  This needs to contain all CIDR blocks in your
  network (cloud VPC, on-prem) that need return routes from the Confluent Cloud
  network via the Transit Gateway attachment.

You can specify optional CLI flags described in the [Confluent CLI command
reference](https://docs.confluent.io/confluent-cli/current/command-reference/overview.html),
such as `--environment`.

The following is an example Confluent CLI command to create a transit
gateway attachment:

```bash
confluent network transit-gateway-attachment create my-tgw-attachment \
  --network n-123456 \
  --aws-ram-share-arn arn:aws:ram:us-west-2:123456789012:resource-share/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx \
  --aws-transit-gateway tgw-xxxxxxxxxxxxxxxxx \
  --routes 10.0.0.0/16,100.64.0.0/10
```

### Terraform

Use the [confluent_transit_gateway_attachment](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_transit_gateway_attachment)
Confluent Terraform Provider resource to create a Transit Gateway
attachment.

See Terraform configuration examples for creating an AWS Transit Gateway
connection using Terraform:

* [Transit Gateway with ACLS](https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/dedicated-transit-gateway-attachment-aws-kafka-acls)
* [Transit Gateway with RBAC](https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/dedicated-transit-gateway-attachment-aws-kafka-rbac)

<br/>

If your Transit Gateway attachment fails, delete the attachment and
create a new one.

Attachment failures can occur for the following reasons:

- The attachment is not shared with the correct AWS principal for the Confluent Cloud
  network.

  Even if the auto-accept all attachment option is turned on, you still need to
  add the Confluent Cloud AWS Account ID to the AWS resource share you
  create in [Add an AWS Transit Gateway in AWS](#add-aws-transit-gateway).
- The Transit Gateway was not added to the AWS resource share.
- The AWS resource share ARN is not correct.

If you delete the Transit Gateway attachment, you must also delete the transit
gateway route table entry for the Confluent Cloud network.

<a id="aws-transit-gateway-accept-connection"></a>

### Accept the Transit Gateway attachment in AWS

This step can be automated by selecting the **Auto accept shared attachments**
option when you create the Transit Gateway in the [first step](#add-aws-transit-gateway).

When the connection status is “Pending” in the  Confluent Cloud Console,
go to the  [Amazon VPC Console](https://console.aws.amazon.com/vpc/) and
accept  the peering request.

1. In the [Amazon VPC Console](https://console.aws.amazon.com/vpc/), click
   **Transit gateway attachments** in the navigation pane.
2. Select the pending Transit Gateway attachment (the status is **Pending**).
3. Click **Actions**, and click **Accept request**.
4. When prompted for confirmation, choose **Accept request**.

   Save the Transit Gateway attachment id. The value is prefixed with
   `tgw-attach-`. You need to input this value in the [next step](#update-aws-transit-gateway-route-table) when you add the attachment to the
   route table.

When the connection request is accepted, the connection status becomes “Ready”
in the Confluent Cloud Console.

<a id="update-aws-transit-gateway-route-table"></a>

### Add the Transit Gateway route to the AWS Transit Gateway route table

AWS automatically adds the new Transit Gateway attachment to the default
Transit Gateway route table, and these steps might not be necessary for your
AWS account.

In AWS, add the Confluent Cloud CIDR to the route table with the target of your AWS
Transit Gateway.

For the routing to become effective, the route table must be associated with
subnet(s).

1. Go to the [Amazon VPC Console](https://console.aws.amazon.com/vpc/), and click
   **Transit gateway route tables** under **Transit gateways** navigation
   section.
2. Click the Transit Gateway route table for your VPC.
3. Click **Create static route**, and specify the following.

   Add routes for all three /27 CIDR blocks to all your VPC route tables,
   not just the zone-aligned routes.
   * **CIDR**: Specify the Confluent Cloud network VPC CIDR block.

     You can find the Confluent Cloud network VPC CIDR block in the **Network Overview** of your
     Confluent Cloud network, in the **Confluent Cloud CIDR** field.
   * **Type**: Select **Active**.
   * **Choose attachment**:

     Select the Transit Gateway attachment ID that corresponds to the transit
     gateway attachment you created in
     [Add an AWS Transit Gateway attachment in Confluent Cloud](#add-aws-transit-gateway-attachment). You can find the corresponding
     attachment ID in the **Transit gateway attachments** page.
4. Click **Create static route**.

For details, see [Update AWS Transit Gateway route table](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html).

<a id="migrate-from-vpc-peering-to-transit-gateway"></a>

## Migrate from AWS VPC peering connections to AWS Transit Gateway attachments

You can migrate a Confluent Cloud network from AWS VPC peering to AWS Transit
Gateway attachments.

#### WARNING
When you migrate from VPC peering to a Transit Gateway, you cannot add the
exact same CIDR route on the Transit Gateway as the CIDR that is used in your
VPC peering connection.

To migrate from a Confluent Cloud network that uses AWS VPC Peering to a network
using  an AWS **Transit Gateway** hub, perform the following steps:

1. Establish a maintenance window.

   Maintaining concurrent Transit Gateway attachments and VPC peering
   connections  might result in a degraded experience due to asymmetric routing
   with MTU mismatches  between the two connectivity types. Confluent recommends
   establishing a planned “maintenance window” during which both connection
   types exist to avoid packet  losses for your critical workloads. While
   concurrent connections exist, traffic  will be charged at [AWS transit
   gateway rates](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html#mtu-quotas).
2. File a Confluent Support ticket.

   Because of the potential for degraded experience, migrations between VPC
   peering  connections and Transit Gateway attachments on the same network
   require filing a  Confluent Support ticket.

   Sign in to the Confluent Support Portal at [https://support.confluent.io/hc/](https://support.confluent.io/hc/),
   click **SUBMIT A REQUEST**, and then click **AWS Transit Gateway Provisioning**.
   - Request to migrate your Confluent Cloud VPC Peering network (with existing VPC
     peering connections) to an AWS Transit Gateway network.
   - Include your Confluent Cloud network name and network ID (available from the Confluent Cloud Console).
3. After Confluent Support temporarily enables concurrent connection types (for both VPC
   peering connections and Transit Gateway attachments), you will be informed that
   you can proceed with your migration, and you can continue to the next step.
4. For each existing VPC peering connection, perform the following steps:
   1. In AWS, [create a Transit Gateway](#add-aws-transit-gateway).
   2. In Confluent Cloud, [add a Transit Gateway attachment](#add-aws-transit-gateway-attachment).
   3. In the [Amazon VPC console](https://console.aws.amazon.com/vpc/),
      update the AWS VPC route table.

      Edit the target of the associated routes to direct traffic to the transit
      gateway instead of the peering connection.
   4. In the Confluent Cloud Console, delete the existing VPC peering connection.
   5. In the [AWS VPC console](https://console.aws.amazon.com/vpc/home),
      verify that the AWS peering resource are deleted.

   #### WARNING
   If your VPC resources are not deleted, asymmetric routing and packet
   losses occur, resulting in a degraded experience.
5. [Validate connectivity](testing.md#testing-connectivity) over the newly
   provisioned resources.
6. After you complete the migration and validation steps, inform Confluent
   Support so that they can disable VPC peering connections and close the
   ticket.

<a id="dns-resolution-aws-tgw"></a>

## DNS resolution

Confluent Cloud hosts and manages the DNS records for endpoints which use AWS Transit Gateway connectivity. In order for your Kafka clients to resolve these DNS names, they must be able to resolve records from public DNS servers.

Confluent does not provide a supported private DNS solution for the clusters that use AWS Transit Gateway connectivity.

To resolve private hostnames for outbound connections from Confluent Cloud, such as
fully managed connectors that need to access data in your VPC, see
[Configure DNS forwarding on AWS](aws-dns-forwarding.md#dns-forwarding-aws).

## Next steps

- [(Legacy) Cluster Linking between AWS Transit Gateway attached Confluent Cloud clusters](../multi-cloud/cluster-linking/private-networking.md#cluster-linking-aws-tgw)
- Try [Confluent Cloud on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-g5ujul6iovvcy?trk=14575e70-1766-4f20-8083-0c2757a1ec75&sc_channel=el)
  with $1000 of free usage for 30 days, and pay as you go. No credit card is
  required.