AWS：如何通过Route 53将TCP流量路由至私有子网EC2并寻求替代方案

针对你的需求（私有子网EC2无公网IP、TCP流量基于FQDN路由、单一公网入口、不用SNI），以下是具体的可行方案及服务分析：

一、Gateway Load Balancer (GLB) 适用性分析 #

GLB不适合你的场景：它工作在OSI三层（网络层），仅能基于源/目标IP、端口进行流量转发，无法识别TCP payload中的应用层FQDN信息，因此无法实现你需要的基于FQDN的路由逻辑。

二、可行方案 #

方案1：公有子网部署TCP反向代理集群 + NLB #

这是最直接且灵活的方案，适用于所有包含FQDN标识的TCP协议（如HTTP、SMTP、自定义TCP协议等）：

• 步骤1：部署代理实例：在VPC公有子网创建2台及以上的EC2实例（保证高可用），安装Nginx或HAProxy作为TCP反向代理。

  • 配置代理监听指定TCP端口，根据流量中的应用层FQDN标识（如HTTP的Host头、自定义协议中的特定字段）转发到对应的私有子网EC2。
  • 例如Nginx的TCP配置示例：

    stream {
        upstream ec2_1 {
            server 10.0.1.10:8080; # 私有子网EC2'1的IP和端口
        }
        upstream ec2_2 {
            server 10.0.1.11:8080; # 私有子网EC2'2的IP和端口
        }
        server {
            listen 8080;
            proxy_pass $upstream;
            # 根据Host头匹配转发（适用于HTTP类TCP流量）
            map $ssl_preread_server_name $upstream {
                ec2-1.test.com ec2_1;
                ec2-2.test.com ec2_2;
            }
            # 若为自定义TCP协议，可解析payload中的FQDN字段进行匹配
        }
    }
    

• 步骤2：配置NLB：创建公网NLB，将代理实例注册到NLB的目标组，NLB监听对应TCP端口。

• 步骤3：Route53配置：将ec2-1.test.com和ec2-2.test.com都指向NLB的公有DNS名称。

• 优点：支持几乎所有带FQDN标识的TCP协议，无需SNI，单一公网入口，高可用；

• 缺点：需要维护代理实例的运维成本，可通过容器化降低负担。

方案2：容器化TCP代理（ECS/EKS）+ NLB #

将TCP代理容器化部署到ECS或EKS，进一步简化运维：

• 基于Nginx/HAProxy制作自定义Docker镜像，配置好FQDN路由规则；

• 在ECS（Fargate或EC2模式）或EKS中部署代理服务，指定公有子网；

• 将容器服务注册到NLB的目标组，后续Route53配置同方案1。

• 优点：利用AWS容器服务的自动扩容、自愈能力，减少运维工作量；

• 缺点：需要具备基础的容器化知识。

三、其他排除的服务说明 #

• ALB：仅支持HTTP/HTTPS等七层协议，无法处理纯TCP流量（非HTTP类），不符合需求；
• CloudFront：仅支持HTTP/HTTPS、RTMP等特定协议，不支持通用TCP流量的FQDN路由；
• Transit Gateway：仅用于VPC间的网络层路由，无法识别应用层FQDN信息。

内容的提问来源于stack exchange，提问作者Greyer