EKS部署的Kubernetes服务前是否需用AWS API Gateway？及架构咨询

一、是否有必要在EKS微服务前端部署API Gateway #

答案是有必要，但需结合业务规模和阶段判断：

• 补充后端能力短板：你的Spring Boot服务虽然用Spring Security实现了自定义认证授权，但API Gateway能提供一些后端难快速落地的能力：比如多环境（开发/测试/生产）的阶段部署、基于请求量/并发的精细化限流、请求/响应的日志聚合与监控，还有一键集成AWS其他服务（比如Lambda、S3）的能力，这些能大幅降低后端的非业务代码复杂度。
• 统一入口与流量管控：作为所有外部请求的唯一入口，API Gateway可以帮你统一处理跨域、请求转换、SSL终止，避免每个微服务都重复配置这些通用逻辑；同时能根据业务需求做流量拆分、灰度发布，比直接暴露EKS Ingress更灵活。
• 例外场景：如果只是小型内部服务、流量极低且短期内无扩展计划，直接用EKS的ALB Ingress暴露服务也能满足需求，但从长期可维护性和扩展性来看，API Gateway是更优选择。

二、AWS中搭建此类服务的标准基础设施方案 #

推荐的架构链路为：外部请求 → AWS API Gateway → EKS Ingress Controller → Spring Boot微服务，各组件职责及配置要点如下：

1. AWS API Gateway
   • 优先选择HTTP API（更轻量、成本更低，适配大部分微服务场景），复杂场景可考虑REST API
   • 认证授权策略：
     • 模式一（推荐）：API Gateway前置身份校验（比如集成AWS Cognito），通过后将用户身份信息（如JWT Token）透传给后端，由Spring Security负责细粒度的权限校验（接口级、资源级授权）
     • 模式二：API Gateway仅做流量转发，完全由后端Spring Security处理认证授权，适合已有成熟自定义认证体系且不想迁移的场景
   • 基础配置：开启限流规则避免后端过载，将访问日志同步到CloudWatch Logs，创建开发/测试/生产阶段对应EKS的不同命名空间服务
2. EKS集群与Ingress Controller
   • 使用ALB Ingress Controller（AWS原生集成，自动创建Application Load Balancer）或NGINX Ingress Controller（自定义规则更灵活），负责将API Gateway的请求转发到对应Spring Boot Pod
   • 为微服务配置Kubernetes Service和Ingress规则，确保API Gateway能通过ALB域名访问到后端服务
3. 配套基础设施
   • 监控：用CloudWatch监控API Gateway的请求量、错误率、延迟，同时通过Prometheus+Grafana监控EKS集群和微服务的运行状态
   • 日志：将EKS Pod日志和API Gateway日志统一收集到CloudWatch Logs，便于问题排查
   • CI/CD：用AWS CodePipeline+CodeBuild实现代码提交→镜像构建→EKS部署的自动化流程，配合Argo CD做持续部署

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