diff --git a/app/_how-tos/dedicated-cloud-gateways/aws-resource-endpoints.md b/app/_how-tos/dedicated-cloud-gateways/aws-resource-endpoints.md index 3c8140925ab..809b0444b00 100644 --- a/app/_how-tos/dedicated-cloud-gateways/aws-resource-endpoints.md +++ b/app/_how-tos/dedicated-cloud-gateways/aws-resource-endpoints.md @@ -40,6 +40,11 @@ prereqs: * A [resource gateway](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-resource-gateway.html) * A [resource configuration group](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-resource-configuration.html) + {:.warning} + > **Important:** Your resource gateway's subnet must be in an Availability Zone (AZ) that overlaps with your Dedicated Cloud Gateway network's AZs. + > If there's no AZ overlap, {{site.konnect_short_name}} can't establish the connection, and the resource endpoint config shows as `missing`, with no other indication of the cause. + > Check which [AZs your Dedicated Cloud Gateway network supports](/konnect-platform/geos/#dedicated-cloud-gateways) before you create your resource gateway, and place it in a subnet within an overlapping AZ. + Copy and save the resource configuration ID and resource definition domain name for each resource configuration. {{site.konnect_short_name}} will use these to create a mapping of upstream domain names and resource configuration IDs. Export your AWS resource configuration domain name: @@ -71,6 +76,7 @@ faqs: - q: Which Availability Zones (AZs) does AWS resource endpoints support for Dedicated Cloud Gateway? a: | Dedicated Cloud Gateways supports [specific Availability Zones (AZs)](/konnect-platform/geos/#dedicated-cloud-gateways) in the supported AWS regions. + Your resource gateway must be in a subnet within an AZ that overlaps with your Dedicated Cloud Gateway network's AZs, or the connection can't be established. next_steps: - text: Dedicated Cloud Gateways production readiness checklist url: /dedicated-cloud-gateways/production-readiness/ @@ -158,28 +164,26 @@ curl -i -X GET "$RESOURCE_DOMAIN_NAME" ## Configure VPC security group inbound rules -When using AWS Resource Endpoints with Dedicated Cloud Gateways, traffic flows through AWS VPC Lattice before reaching your backend resources. -VPC Lattice terminates the connection from your Dedicated Cloud Gateway and opens a new connection to your backend services. -Because of this, the source IP of this new connection is an AWS-managed Lattice IP, not the original Dedicated Cloud Gateway IP. +When using AWS Resource Endpoints with Dedicated Cloud Gateways, your resource gateway is the point of inbound traffic into your VPC for the resource you shared. +Traffic from your Dedicated Cloud Gateway arrives at your backend resources sourced from the resource gateway's own elastic network interface (ENI), using a normal IP address from the subnet you assigned to the resource gateway when you created it. -To allow this traffic, you must configure the inbound security group rules for whatever resource is acting as your backend target (for example, EC2 instances, Application Load Balancers, Network Load Balancers, or target Elastic Network Interfaces). +To allow this traffic, create a dedicated security group for your resource gateway, then reference that security group (not an IP range or prefix list) as the allowed source on your backend target's security group (for example, EC2 instances, Application Load Balancers, Network Load Balancers, or target Elastic Network Interfaces). 1. In AWS, navigate to your VPC console. -1. From the VPC sidebar, click **Managed prefix lists**. -1. Search for the region where your backend resources (NLB/target group) are deployed (for example: `com.amazonaws..vpc-lattice`). -1. Copy the prefix list ID. +1. From the VPC sidebar, click **Security groups**. +1. Create a new security group (for example, `sg-resource-gateway`) and attach it only to your resource gateway. 1. Navigate to the security group for your backend target resource. -1. Create a new security group or edit the inbound rules of an existing security group. -1. In the **Source** field, enter the prefix list IDs, for example `pl-123456...`. -1. Repeat steps 1-7 for all regions where your backend resources are deployed. +1. Add an inbound rule for the relevant port (for example, TCP/443). +1. In the **Source** field, select the dedicated resource gateway security group you created. +1. Repeat steps 3-6 for each backend resource that receives traffic through the resource gateway. ## Troubleshooting timeouts If requests time out and your NLB shows no incoming traffic: -* Verify the security group attached to your backend allows the Lattice prefix list. -* Confirm the correct region-specific prefix list is used in your security group inbound rules. +* Verify the security group attached to your backend allows inbound traffic from the resource gateway's dedicated security group. +* Confirm your resource gateway's subnet has an Availability Zone (AZ) that overlaps with your Dedicated Cloud Gateway network's AZs. This is a common, hard-to-diagnose failure mode: without AZ overlap, the resource endpoint config can show as `missing` in {{site.konnect_short_name}}, even though nothing else is misconfigured. * Validate the Resource Endpoint connection is in the `READY` state in {{site.konnect_short_name}}. * Confirm the Gateway Service upstream host matches the Resource Endpoint domain name. * Check NLB target group health. -* Confirm backend subnet network access control lists (NACLs) allow inbound and outbound to the Lattice prefix. Security groups are stateful; a restrictive NACL silently drops the return path. +* Confirm backend subnet network access control lists (NACLs) allow inbound and outbound traffic from the resource gateway's subnet. Security groups are stateful; a restrictive NACL silently drops the return path. * Confirm the NLB listener protocol and port matches the resource configuration's accepted listener.