Spring Boot微服务AWS部署选型及API Gateway搭配、资源分配疑问

• Spring Cloud Config：可直接适配AWS Systems Manager Parameter Store、AWS Secrets Manager，无需自行维护配置中心服务；如果需要保留Spring原生配置中心能力，也可将Config Server部署在EC2/ECS/EKS中
• Spring Cloud Service Discovery（Eureka/Nacos等）：适配AWS Cloud Map，也可直接使用ECS/EKS自带的服务发现能力，无需单独部署自研服务发现组件；若需保留Spring生态的服务发现逻辑，也可部署在AWS计算资源中
• Spring Cloud Gateway：可独立部署在EC2/ECS/EKS上，也可与AWS API Gateway搭配使用，两种方案均为行业常用方案
• Spring Cloud Vault：直接适配AWS Secrets Manager、AWS KMS，可直接用AWS托管密钥管理服务替代自研Vault，也可自行部署Vault服务到AWS计算资源中

你提到的两种部署方式都可行，根据你的业务需求选择即可：

仅部署Spring Boot API Gateway到EC2 #

适用场景：

• 已经基于Spring Cloud Gateway做了大量自定义开发，比如自定义鉴权、限流、日志埋点、与Spring生态其他组件深度联动
• 不需要AWS API Gateway的托管特性，团队有能力自行运维网关服务
  部署建议：
  至少部署2台EC2实例实现高可用，前面挂载AWS ALB做流量分发，避免单实例故障导致服务不可用。

Spring Boot API Gateway与AWS API Gateway搭配使用 #

适用场景：

• 需要AWS API Gateway的托管能力，比如WAF防护、DDoS防护、全球边缘加速、API生命周期管理、按调用量付费的弹性计费模式
• 希望公网入口由AWS托管，降低公网侧运维风险，内部微服务的路由、自定义业务逻辑仍由自研Spring Cloud Gateway处理
  部署架构：公网流量先接入AWS API Gateway，再转发到ALB，之后到你部署的Spring Cloud Gateway，最终转发到内部微服务。

针对Service Discovery、Config Service这类轻量组件，资源分配分两种情况：

• 若选择使用AWS托管服务替代自研组件：无需分配任何EC2实例，直接使用全托管服务，按需付费即可，省去运维成本
• 若必须保留Spring生态的自研组件：
  • 测试环境：可将多个轻量服务部署在同一台EC2实例上，通过不同端口区分，降低资源成本
  • 生产环境：建议为每个核心组件分配至少2台EC2实例做高可用，避免单实例故障影响所有微服务的配置拉取、服务注册发现能力；也可选择部署在ECS/EKS等容器服务中，共享底层EC2资源，提高资源利用率。

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