SAP-C02 练习题 — SAP-C02：解决方案架构师 - 专业级

需求如下：

1.本地系统（On-premises systems） 必须解析 `cloud.example.com`。

2.所有 VPC 必须解析 `cloud.example.com`。

3.高性能 是必需的（最低延迟和复杂度）。

选项 A 满足这些需求的原因：

1.将私有托管区域与所有 VPC 关联 → 确保 VPC 资源可通过 Route 53 原生解析 `cloud.example.com`。

2.在共享服务 VPC 中创建 Route 53 入站解析器（inbound resolver） → 为本地查询提供集中式 DNS 解析端点。

3.使用 AWS 传输网关（Transit Gateway）实现连接 → 确保 VPC 与本地系统之间的低延迟通信。

4.将本地 DNS 查询转发到入站解析器 → 使本地系统能高效解析 `cloud.example.com`。

为什么其他选项不正确？

-选项 B：使用基于 EC2 的条件转发器，与完全托管的 Route 53 解析器相比，会引入不必要的管理开销（扩展、补丁）。

-选项 C：仅将私有托管区域与共享服务 VPC 关联，这意味着其他 VPC 无法原生解析 `cloud.example.com`（需要出站解析器，增加复杂度）。

-选项 D：与选项 C 类似，但使用入站解析器，同时仍将托管区域限制在一个 VPC 中，导致其他 VPC 无法解析。

性能关键考量

-Route 53 私有托管区域 直接关联时，可在 VPC 内提供最快的 DNS 解析。

-Route 53 解析器（入站） 完全托管且针对混合 DNS 优化，优于手动 EC2 解决方案。

-传输网关 确保 VPC 与本地系统之间的高速连接。

结论

选项 A 是最高效、可扩展且高性能的解决方案，利用原生 AWS 服务（Route 53 私有托管区域 + 入站解析器），不引入不必要的复杂度。

基于所提供的信息，为公司的REST API实现多区域故障转移能力的最佳方案应为：

C. 在另一个区域部署新的API Gateway API和Lambda函数。将Route 53 DNS记录更改为故障转移记录。启用目标健康监控。将DynamoDB表转换为全局表。

该方法通过以下方式提供完整的灾难恢复解决方案：

- 在第二个区域部署整个API基础设施（API Gateway和Lambda函数）

- 使用带有健康监控的Route 53故障转移记录，在需要时自动重定向流量

- 将DynamoDB表转换为全局表，确保跨区域的数据一致性

选项A不完整，因为它仅在新区域部署新的Lambda函数，并更新现有API Gateway以使用边缘优化端点。这无法提供真正的区域故障转移能力，因为API Gateway本身在单一区域中仍会成为单点故障。

正确方案（C）通过Route 53健康检查和用于数据复制的全局表，在跨区域环境中创建了具有自动故障转移能力的完全冗余架构。

参考来源

- 《为Amazon API Gateway实现多区域故障转移》| AWS计算博客（https://aws.amazon.com/cn/blogs/compute/implementing-multi-region-failover-for-amazon-api-gateway/）

- 部署参考架构，模拟无服务器主动/被动工作负载与应用数据的异步复制，并实现从主AWS区域到辅助区域的故障转移 - 多区域应用架构解决方案（https://docs.aws.amazon.com/solutions/latest/multi-region-application-architecture/welcome.html）

- 基于成本效益的RTO、RPO需求：AWS Backup与全局表/数据库的对比 | AWS re:Post（https://repost.aws/questions/QUWf0GuonKSvW8U2N4o8huHw/aws-backup-vs-global-table-database-for-cost-effective-rto-rpo-requirements）

- 为API Gateway API配置DNS故障转移的自定义健康检查 - Amazon API Gateway（https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html）

- 社区文章 | 跨边界扩展：构建多区域架构同时保持数据本地化（https://community.aws/content/2dhVhtsciD5gVBlCKUlHoszrDzU/scale-beyond-borders）

根据提供的信息，将有状态应用迁移至AWS并确保可扩展性和一致用户体验的最佳方案为：

C. 为Aurora副本启用Aurora自动扩缩容功能。使用启用轮询路由和粘性会话的应用负载均衡器（Application Load Balancer）。

该方案的优势在于：

-Aurora副本自动扩缩容：可使数据库层根据需求自动扩展读取容量，这在用户基数显著增长时至关重要。

-应用负载均衡器（ALB）：适用于基于Web的应用程序的HTTP/HTTPS流量，相比网络负载均衡器（Network Load Balancer）提供更高级的路由能力。

-粘性会话：对维护有状态应用的一致用户体验至关重要，可确保用户会话在整个周期内始终连接到同一EC2实例。

-轮询路由机制：通过ALB将传入流量均匀分配至自动扩缩容组中的健康EC2实例，实现高效的负载分发。

选项A不够合适，原因在于：

- 网络负载均衡器（NLB）工作于传输层（TCP/UDP），通常用于极端性能需求场景，而非标准Web应用。

- NLB原生不支持ALB那样的粘性会话功能，而这对有状态应用至关重要。

参考资料

- REL07-BP01《获取或扩展资源时使用自动化》- AWS架构完善框架（https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_adapt_to_changes_autoscale_adapt.html）

- 《AWS上ASP.NET Web Forms应用的高可用性与自动扩缩容》- AWS规范指南（https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-asp-net-web-forms/ha-scaling.html）

- 《超大规模扩展Aurora MySQL兼容版以应对突发流量增长》- AWS规范指南（https://docs.aws.amazon.com/prescriptive-guidance/latest/hyperscale-aurora-mysql/introduction.html）

- 《后端数据库重新平台化》- AWS规范指南（https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-replatforming-cots-applications/replatforming-backend-databases.html）

- 《云之旅：Joby Aviation的PLM迁移至AWS》- AWS行业博客（https://aws.amazon.com/cn/blogs/industries/navigating-the-cloud-joby-aviations-plm-migration-to-aws/）

1. 无服务器架构： 公司希望采用无服务器技术。
2. 向后兼容性： 必须支持不支持某些 HTTP 头的旧版消费设备。
3. 删除头部逻辑： 根据 User-Agent 标识，必须删除特定的 HTTP 头以确保兼容旧设备。

选项分析：

• A： 创建一个 Amazon CloudFront 分发 和一个 应用负载均衡器（ALB），可以高效地路由请求。CloudFront 可以使用 CloudFront 函数 根据 User-Agent 的值删除有问题的 HTTP 头。ALB 能够调用适当的 Lambda 函数来处理请求。此方案完全符合要求，并且需要的工作量最小。

• B： 使用 API Gateway REST API 并配置网关处理头部删除逻辑会引入不必要的复杂性。虽然可以实现，但需要创建额外的映射模板或修改响应，与 CloudFront 和 ALB 的简洁方案相比增加了操作负担。

• C： 使用 API Gateway HTTP API 删除头部需要管理响应映射模板，并将其与 HTTP API 关联。这与选项 B 类似，增加了复杂性和操作工作量。

• D： 在 CloudFront 分发中使用 Lambda@Edge 函数 是一种可行的替代方案，但会增加延迟，因为 Lambda@Edge 在边缘位置执行。与 CloudFront 函数相比，这可能影响性能，而后者原生集成，且更适合像头部删除这样轻量级的任务。

选择 A 的关键优势：

• 无缝头部删除： CloudFront 函数提供了一种轻量化的机制，能够基于 User-Agent 值删除头部。
• 高效路由： ALB 可以高效地将请求路由到正确的 Lambda 函数进行处理。
• 无服务器设计： 完全符合无服务器架构的要求，同时确保向后兼容性。

因此，选项 A 是正确答案。