我了解到您对 Amazon Aurora Serverless 的混合云架构有一些疑问。这是一个非常棘手的话题，很容易被视为固执己见（幸运的是社区保持开放）。因此，如果我必须设计这种设置，我会尝试尽可能多地参考公共材料并尝试解释我的想法。
作为免责声明，我不是 AWS 官员。然而，在过去的三年里，我一直在创业行业构建和运营云应用程序......巧合的是，我有几分钟的时间，所以这是我的想法：
1. 问题陈述
Aurora Serverless 可通过 VPC 接口端点 [1] 访问：
每个 Aurora Serverless 数据库集群需要两个 AWS PrivateLink 终端节点。如果您达到 VPC 中 AWS PrivateLink 终端节点的限制，则无法在该 VPC 中创建更多 Aurora Serverless 集群。
根据文档 [1]，正如您已经正确指出的那样，这些端点是私有构造：
您不能为 Aurora Serverless 数据库集群提供公共 IP 地址。您只能从基于 Amazon VPC 服务的虚拟私有云 (VPC) 中访问 Aurora Serverless 数据库集群。
2.问题范围
您的问题涉及最佳实践 (Q1)、成本方面 (也是 Q1) 以及与云中其他数据库选项 (Q2) 的功能差异，例如通过 Internet 进行的公共访问和自动缩放。
在将数据库工作负载迁移到公共云时，这些都是有效的问题。但与此同时，它们只是应该考虑的问题的一个子集。
据我了解，我们在这里应该清楚地强调三个挑战：您正在 (CI) 开始迁移到云，(CII) 您即将将现有工作负载修改为混合工作负载，以及 (CIII) 您正在执行数据库迁移。这三个通常都是独立的大话题，不应该过早地决定它们。但是，如果您的工作量如您所描述的“轻”，那么将它们一起完成的风险可能是可以接受的。这不是我能够在下面讨论的事情。
因此，当我看到上述挑战 (C1) - (C3) 时，让我们关注一个非常基本的问题：
3. 混合工作负载是否可接受？(C2)
我认为您应该问自己的主要问题是本地工作负载是否可以转换为混合工作负载。因此，您应该考虑将数据库远离客户端对延迟和可靠性的影响。此外，您应该评估新的数据库引擎是否符合您的性能预期（例如，扩展速度足以应付窥视流量）[3]，以及数据库兼容性和限制是否可以接受 [4]。
通常，连接到云（可能通过外部网络运营商）的连接不如本地的一堆电缆可靠。也许您的工作负载甚至那么小，以至于数据库及其客户端运行在同一管理程序/机器上。在这种情况下，绝对应该仔细考虑将事物分开（通过 3rd 方网络连接）。
事实上，要使工作负载可靠和/或高度可用，不仅 Aurora 必须满足这些标准（它确实如此），而且您的网络连接也必须满足。
当你问自己正确的问题时，你会自动开始描述你的工作量。AWS 发布了一系列公共指南来帮助您完成此过程。
有Well- Architected Framework [10] 和Well-Architected Tool [11] - 后者是应用框架的“自动化”方式。例如，可靠性支柱[9] 包含 AWS 专家的一些想法和专业知识，以真正质疑您的混合方法。
此外，AWS 发布了所谓的Lenses [13]，以从良好架构的角度讨论特定的工作负载类型。正如您要求的最佳实践（Q1），我想指出，目前没有针对您描述的工作负载类型的详细指南/镜头。
但是，文档 [12] 中有一个名为“Performing a Proof of Concept with Amazon Aurora”的 Aurora 指南。（更多信息请参见“Aurora POC 指南”部分）
我过去从事过大量使用数据库层的应用程序，因此如果不进行重大重构就无法进行这样的更改……
这使我想到了第二点：迁移策略。
4. 什么是可接受的迁移策略？(C1)
由于这是一个数据库迁移，您应该问自己两个主要问题：(a) 您想要迁移到什么程度（称为迁移的 6R，一个独立于数据库的一般概念）和 (b) 如何迁移将数据库部分提升到云端（尤其是数据）。我不想在这里详细介绍，因为它高度依赖于您的工作负载特征。
AWS 已发布详细指南，可帮助您做出这些决定。[15]
它提到了一些有用的工具，例如DMS和SCT，它们可以帮助您正确转换模式（如果需要）并将数据从源数据库集群移动到目标数据库集群（可选地在“在线”/“实时”无需停机的迁移方式）。
我想再次强调，您必须做出一个重大决定：重新构建平台与重新构建应用程序（即数据库客户端）充分利用 Aurora 功能，可能需要重新架构（这可能最终会将整个工作负载转移到云中）。
如果您决定对应用程序进行部分重构，您也可以使用所谓的Data API。Aurora Serverless [7][8]的数据 API可以直接通过公共互联网发送查询。如果 (i) 您有能力重构应用程序代码的某些部分并且 (ii) 您的应用程序的特征适合 Data API，那么它可能适合您。Data API 有一种全新的数据库连接管理方法，因此非常适合一些无服务器用例。但是，这可能不适用于一些具有长期保持/大量使用连接的传统数据库工作负载。您还应该注意 Data API 的数据库引擎兼容性（“Data API 的可用性”[12]）。
5. 决策
我认为从技术上讲，访问 Aurora Serverless 应该没有问题。您基本上有四种连接选项：(a) 直接通过 Internet，(b) 通过 AWS 托管（站点到站点）VPN 连接，(c) 通过基于 EC2 实例的 VPN 连接和 (d) 通过 Direct Connect (缩写 DX）。
- 仅当您重新构建应用程序以使用数据 API AFAIK 时，选项 (a) 才可能。
- 选项 (d) 应得到支持，但按固定成本计算是最昂贵的。应该支持它，因为 AWS 接口终端节点（Aurora Serverless 的入口点）可通过 DX 访问。
- 根据 SO 专家的说法，选项 (c) 应得到支持。[19]
- 选项（b）在开始时肯定不支持 - 但据我了解，现在可能是。这是因为自 2018 年 9 月以来，AWS PrivateLink（支持 AWS 接口终端节点的技术）支持通过 AWS 托管 VPN 进行本地连接。 [17]
此外，您可能必须将 DNS 查询从本地转发到云中才能正确解析 VPC 接口终端节点。[18]
您应该描述您的工作负载，指定关于安全性、可靠性、性能的最低要求（请参阅架构完善的框架），最后寻找实现它的最具成本效益的方法。在 B2B 模式中，我不会为了降低成本而牺牲这三者（请参阅以下部分中的我的观点）。
你基本上有两个选择来决定：
- 自己完成工作（希望使用本文中引用的材料会更容易一些）
- 向 AWS 或外部公司寻求 AWS 解决方案架构师的帮助
这纯粹是在 (1) 弄清楚这一切并使其发挥作用所需的时间、(2) 成本（即实施解决方案的运营成本和咨询成本）、(3) 涉及的财务风险之间的权衡。迁移过程中出现问题。
正如您在“将所有内容移入云端”的问题中所说的那样，我猜您正处于云之旅的开始阶段。AWS 官方文件针对处于这种情况的公司规定了以下内容：
如果您的企业是 AWS 的新手，请考虑使用托管服务提供商（例如 AWS Managed Services）来构建和管理该平台。[14]
有创业行业的背景，我知道这对于小公司来说无论如何都不是一个选择——但我只想提一下这个选择是存在的。
6. 结论/我的意见（！）
将数据库暴露在互联网上是最好避免的做法。这不仅是我自己的观点，还有其他人的观点。[19]
我会尝试（至少！）使用 AWS 托管 VPN 方法，并在本地和云之间建立冗余VPN 连接。
为什么我说“最低限度”？
因为一个合适的解决方案可能是将整个工作负载转移到云中。但是，如果这不可能，我会尝试降低建立混合工作负载所涉及的风险。从安全角度来看，托管 VPN 连接可能是小型工作负载降低风险的最具成本效益的方式。
根据我的经验：
在过去三年中，我运行了一个完全构建在 AWS 云中的 SaaS 应用程序。从那时起，我们的网络运营商多次中断。我永远不会足够信任他们来建立某种混合架构。不适用于我们提供的工作负载类型（B2B 领域的 SaaS Webapp）和我们拥有 ATM 的互联网合同/连接。绝不。但是，情况对您来说可能完全不同 - 特别是如果您已经从数据中心/办公室托管服务，并且长时间没有可靠性问题。
如果你读到这里，你可能会问自己，为什么有人会想写这样一篇文章。好吧，我正在准备 AWS Certified Database Specialty [20]，这是一个进行认真研究、做一些笔记并收集一些资源/参考资料的好机会。我想支持各种 AWS 认证路径 [16] 以及围绕它的学习平台生态系统。AWS 发布了很多非常有用的资料。
希望你也能在这篇文章中为自己找到一些有趣的东西。
A. Aurora POC 指南
该指南提到，在将数据库迁移到 Aurora 时，应考虑：
重写客户端应用程序代码的某些部分——尤其是正确使用 DNS 端点 [5][6] 和连接池 [5]
如果从相当复杂（专有）的源数据库引擎（“移植您的 SQL 代码”[12]）迁移，则进行模式转换
（可选）合并一些 Aurora 特定的更改以使迁移更有效（适用于 Rearchitect 类型的迁移）[2]：
- 要充分利用 Aurora 功能进行分布式并行执行，您可能需要更改连接逻辑。您的目标是避免将所有读取请求发送到主实例。只读的 Aurora 副本正待命，拥有所有相同的数据，准备好处理 SELECT 语句。对您的应用程序逻辑进行编码，以便为每种操作使用适当的端点。请遵循以下一般准则：
- 避免对所有数据库会话使用单个硬编码连接字符串。
- 如果可行，请将诸如 DDL 和 DML 语句之类的写入操作包含在客户端应用程序代码中的函数中。这样，您可以使不同类型的操作使用特定的连接。
- 为查询操作创建单独的函数。Aurora 将读取器端点的每个新连接分配给不同的 Aurora 副本，以平衡读取密集型应用程序的负载。
- 对于涉及查询集的操作，请在完成每组相关查询时关闭并重新打开与读取器端点的连接。如果该功能在您的软件堆栈中可用，请使用连接池。将查询定向到不同的连接有助于 Aurora 在集群中的数据库实例之间分配读取工作负载。
参考
[1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.limitations
[2] https://docs.aws.amazon.com/AmazonRDS/latest /AuroraUserGuide/aurora-poc.html#Aurora.PoC.Connections
[3] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-poc.html#Aurora.PoC.Measurement
[4] https ://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.limitations
[5] https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql -database-administrator-handbook.pdf
[6] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Connecting.html
[7]https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html
[8] https://www.youtube.com/watch?v=I0uHo4xAIxg#t=12m30s
[9] https: //d1.awsstatic.com/whitepapers/architecture/AWS-Reliability-Pillar.pdf
[10] https://aws.amazon.com/architecture/well-architected/
[11] https://aws.amazon.com /de/well-architected-tool/
[12] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-poc.html
[13] https://aws.amazon.com/blogs/架构/well-architected-lens-focus-on-specific-workload-types/
[14] https://d1.awsstatic.com/whitepapers/Migration/aws-migration-whitepaper.pdf
[15]https://docs.aws.amazon.com/prescriptive-guidance/latest/database-migration-strategy/database-migration-strategy.pdf
[16] https://aws.amazon.com/training/learning-paths/
[17] https://aws.amazon.com/about-aws/whats-new/2018/09/aws-privatelink-now-supports-access-over-aws-vpn/
[18] https://docs。 aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html
[19] https://stackoverflow.com/a/52842424/10473469
[20] https://aws.amazon.com/ de/certification/certified-database-specialty/
