Dedicated Cloud Gateways production readiness guide

Action:

• Verify that the data planes are deployed correctly. Check the data plane registration and logs.
• Verify that the data planes are being reported as in-sync with the control plane configuration. Look for configuration drift or synchronization errors.
• Verify the number of data planes deployed meets the your organization’s minimum redundancy and scale requirements. Compare these numbers with initial sizing discussions.

Action:

• Verify that all Services intended for production traffic have accurate configuration, including upstream URLs, health checks, and load balancing algorithms.
• Verify that production plugins are configured correctly, including authentication, rate limiting, and logging plugins. Make sure plugins are scoped correctly.
• Verify that production Routes correctly map to Services and the Route host, path, and methods are accurate. Test all production Routes.
• Verify the TLS/SSL configuration is configured correctly for all production Routes and Services. Ensure the correct certificates are used.

Action:

• Verify the transit gateway attachment, route table configurations, and CIDR ranges on your network side. Ensure routes exist for the Dedicated Cloud Gateway CIDR.
• Verify if the connectivity is working as expected by sending a test request from Dedicated Cloud Gateway to an internal upstream endpoint. Perform and end-to-end ping/HTTP test.
• Verify that the transit gateway firewall and network ACLs aren’t blocking traffic.

Action:

• Since VPC Peering is non-transitive, confirm that all necessary VPCs are peered or reachable via other means.
• Verify that you’ve shared the correct resource configuration (for example, VPC endpoint service name) with Konnect.
• Verify that you’ve updated all the child configurations for the endpoints you’ll be routing traffic to. Check all services that use resource endpoints.
• Verify if the connectivity is working as expected by sending a request to the respective upstream resource.

Action:

• Verify that the private hosted zone is shared with the Dedicated Cloud Gateway VPC correctly.
• Verify if the DNS is resolvable from the Dedicated Cloud Gateway network by sending a request to the upstream using its private hostname. Perform nslookup or a connection test.

Action:

• Verify if the outbound DNS resolver configuration is updated correctly in the Dedicated Cloud Gateway’s VPC settings. Ensure that your provided DNS resolvers are targeted.
• Verify if the domain is mapped to the correct DNS resolvers for resolution. Check conditional forwarding rules.
• Verify if the DNS is resolvable from the Dedicated Cloud Gateway network by sending a request to the upstream using its private hostname. Perform nslookup or a connection test.

Action:

• Verify the VNet peering status is connected in both Azure and Konnect.
• Verify that your Azure network security group and route table configuration on your network side allows traffic to and from the Dedicated Cloud Gateway CIDR. Check for blocked ports or IP ranges.
• Verify the connectivity is working as expected by sending a request to the upstream. Perform an end-to-end HTTP test to an internal service.
• Verify the private DNS configuration (for example, private DNS zones linked to VNet) to ensure private DNS is resolvable from your Dedicated Cloud Gateway. Test that the internal Azure hostnames resolve.

Action:

• Verify that your peering connection status and route table configuration are configured correctly in Google Virtual Private Cloud. Ensure routes are exported and imported correctly.
• Verify if the connectivity is working as expected by sending a request to an internal upstream endpoint. Perform an end-to-end HTTP test.
• Verify that your firewall rules are configured to allow necessary traffic between the peered networks.

Action:

• Cloud DNS peering zones are directional (for example, Dedicated Cloud Gateway to your organization’s VPC) and must be configured accordingly. Confirm correct directionality.
• Verify that the Cloud DNS peering zone is active and configured correctly in the your VPC to allow Dedicated Cloud Gateway to resolve your private domains.
• Verify if the DNS is resolvable from the Konnect network by sending a request to the upstream using its private hostname. Perform a DNS lookup with dig or a connection test.

Action: Limit what Konnect can access

Explanation: To ensure that Dedicated Cloud Gateway can only reach authorized workloads, do the following:

• Route scoping: Only propagate necessary subnets to Dedicated Cloud Gateway, omit others to enforce east-west boundaries.
• Restrictive security groups and NACLs: Even if routes exist, security groups and NACLs should deny undesired traffic by source CIDR or port.
• Endpoint scope: Restrict service exposure to load balancers (for example, ALBs), blocking direct access to EC2s or backend databases.

Action: Rapidly isolate traffic from Dedicated Cloud Gateway in the unlikely event of a compromise or misconfiguration.

Explanation: In the unlikely event of a compromise or misconfiguration, you can rapidly isolate traffic from Dedicated Cloud Gateway:

• Transit gateway or VPC peering detachment: Remove or disable the transit gateway or VPC peering attachment for Dedicated Cloud Gateway VPCs in Konnect by navigating to API Gateways > Networks and select “Delete” from the more options menu.
• Route table null routing: Black hole routes by pointing them at a non-existent target to prevent traffic flow from known Dedicated Cloud Gateway CIDRs.
• Security group updates: Revoke ingress rules for Dedicated Cloud Gateway source ranges.
• IAM policy revocation: If you’re using cross-account IAM roles, revoke permissions to limit potential control plane misuse.
• DNS firewall enforcement: Block Dedicated Cloud Gateway from resolving internal FQDNs using Route 53 DNS firewall if necessary.

You retain full administrative control over your transit gateway and can apply the following safeguards:

• Separate route tables per attachment: Maintain isolation between Dedicated Cloud Gateway and internal services.
• Transit gateway resource policies: Limit which principals can modify routes or propagate attachments.
• Monitoring and logging: Enable VPC Flow Logs and AWS CloudTrail on transit gateway attachments to audit usage and detect anomalies.

Each customer-dedicated AWS account and VPC provisioned by Kong follows strict security and operational controls:

• IAM zero trust: Kong applies least-privilege IAM policies across all infrastructure components.
• Intrusion detection agents: All VMs include runtime protection and IDS/IPS agents.
• Audit logging: AWS CloudTrail is enabled for all API activity.
• Patching compliance: Instances are regularly updated to meet Kong’s security baselines and CSP-recommended hardening benchmarks.

You can optionally choose to expose upstream services only via load balancers (for example, ALB). This can be enforced by the following:

• Security group and NACL rules: Only permit ALB IP ranges, block access to internal subnets.
• Transit gateway scoping: Only route ALB subnets through transit gateway.
• FQDN and TLS enforcement: Use host-based routing and TLS hostname validation to prevent direct IP-based access.