AWS ECS Service Connect与Service Discovery对比及共存问题咨询
背景概述
AWS Cloud Map 可帮助为VPC设置命名空间，为各个服务分配该命名空间内的名称。名称的可发现方式分为三类：
- A) 仅通过API调用私有发现
- B) 在VPC内通过API调用或私有DNS发现
- C) 通过公网DNS和API调用发现
ECS与Cloud Map交互实现服务自动注册的功能，在AWS ECS中称为Service Discovery。
AWS ECS还有一项较新功能——Service Connect，它基于Cloud Map构建，会为ECS服务添加代理边车容器，自动创建服务网格。
我的配置与遇到的问题
我已通过CloudFormation成功配置ECS的Service Connect：
- 在
AWS::ECS::Cluster中，将ServiceConnectDefaults配置为目标Cloud Map命名空间（如example.internal） - 在
AWS::ECS::Service的ServiceConnectConfiguration中设置enabled: true，并补充服务/端口名称等细节（例如命名为my-service）
我了解到，同一VPC内使用Service Connect的其他服务可通过my-service.example.internal连接，边车代理无需DNS即可找到my-service实例（尚未测试，需澄清）。
但我还希望获得私有DNS访问权限，以便在Cloud9中直接执行curl my-service.example.internal/api/test，无需手动查找实例IP。我尝试定义AWS::ServiceDiscovery::PrivateDnsNamespace和同名AWS::ServiceDiscovery::Service（即my-service），并通过ServiceRegistries将其与ECS服务关联，但部署CloudFormation堆栈时出现错误：
Invalid request provided: CreateService error: Service already exists.
我推测，Service Connect内部已自动创建了AWS::ServiceDiscovery::Service，手动创建同名资源导致冲突。若不手动创建，ECS自动生成的资源不会为my-service提供DNS条目。
核心疑问
- AWS ECS是否只能二选一：使用Service Connect（无服务DNS条目，边车代理通过API查找服务），或使用Service Discovery（手动创建Cloud Map DNS条目，ECS自动注册）？还是我配置有误？
- 我猜测使用Service Discovery并获取DNS条目后，其他服务可通过Cloud Map找到私有DNS，实现类似Service Connect的功能且无需边车代理，但可能会失去Service Connect的部分监控能力？烦请确认该理解是否正确，并详细说明ECS中使用Service Connect与Service Discovery的实际差异及影响。
内容的提问来源于stack exchange，提问作者Garret Wilson
