如何将本地应用程序连接到 AWS Aurora Serverless
How to connect an on-premises application to AWS Aurora Serverless
我们有一堆本地应用程序，每个应用程序 运行 都有自己的本地 MySQL 服务器。我们的工作量很轻，偶尔会有 activity 的爆发（一种 B2B 业务模型，在每月的某些特定时间使用我们的应用程序更有利可图，因此我们在那些日子里看到了使用高峰）。我们认为通过将所有数据库移动到一个数据库来简化基础架构是个好主意 server/cluster，经过一番讨论后我们决定购买托管解决方案比尝试建立和维护我们自己的解决方案更好 MySQL 集群（我们中 none 是 DBA）。
我们进行了大量研究，最终选择 Amazon Aurora Serverless 作为其自动扩展功能的可靠候选者，因此与我们检查的替代方案相比（可能）成本更低（AWS MySQL RDS 和 DigitalOcean 管理 MySQL)，由于我们通常很轻的工作负载偶尔会爆发 activity。
但是，据我所知，不可能简单地从我们的本地应用程序连接到 AWS Aurora Serverless（例如 ），所以我的问题是：
- 解决此问题的最佳实践、现代方法是什么 - 我们是否应该使用站点到站点 VPN 将本地主机连接到云？这最终会让我们付出更多的代价吗？
- Aurora Serverless 真的是最好的解决方案吗，还是我们应该回退到 Amazon RDS 或 DigitalOcean 的托管 MySQL 集群，这两者都允许分配 public IP，但都不会自动缩放（意味着我们需要根据我们的峰值使用量购买一层，并且可能会浪费很多钱，因为它在一个月的大部分时间里几乎闲置）？
我们想要实现的是一个简单的、即发即弃的 MySQL 集群设置，由其他人管理，最好是自动缩放，并且不会花费地球或最终变得更多比当前的本地解决方案更难管理。
我们并不厌恶云，但我们也不想突然开始将一切全部迁移到云中，只是为了简化数据库基础架构。
我们不管理自己的防火墙 - 因此设置站点到站点 VPN 可能会很棘手，并且涉及与第三方（我们的网络提供商）的协调。理想情况下，如果可能的话，我也想避免这种麻烦。
你是对的，你不能从 AWS 外部直接连接 到 Aurora Serverless (AS)。原因是AS不能是public。来自 docs:
You can't give an Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC) based on the Amazon VPC service.
AS 还有 many other limitations 你应该知道的，其中一些是：没有副本，也没有 IAM 身份验证。
Q1 连接到 AS
有几个选项用于连接到 SA，或其他无法从 Internet 访问的服务（例如 RDS 代理、ElasticSearch 域）。
Bastion/jump主机
最便宜、最 ad-hoc 主要用于测试和开发的选项是使用 bastion/jump 主机。使用此选项，您将设置到堡垒的 ssh 隧道，而堡垒又会将您连接到 AS。
但是，这显然不适合可靠访问，但我觉得至少应该在答案中提及。
AWS Site-to-Site VPN
正如您已经提到的，AWS Site-to-Site VPN 是另一种选择。这显然是启用从 on-prem 访问 VPC 的更好方法。
但问题是成本，因为 your charged每小时 0.05 美元和每次数据传输。
每小时的价格并没有那么多。 1 个月约为 3.6 美元/月：
24 hours x 30 days x [=10=].05 = .6
数据传输更难估计，因为它取决于您的实际需求。例如，如果您估计每月将从 AS 中获取 100GB 的数据（入站流量免费），您将每月支付约 8.91 美元（前 1GB 免费）：
99GB * [=11=].09 = .91
假设上述情况，您将支付大约 12.51 美元/月。此 不包括 AS 价格本身。
但是，由于提到的防火墙设置问题，这可能在设置和管理方面比较麻烦，但却是有益的。
直接连接
AWS Direct Connect 最贵，但最可靠和私密。只是想提一下，因为这可能 不适合 您的 use-case.
Q2 AS 的适用性
AS的use-case之一是Infrequently used applications:
You have an application that is only used for a few minutes several times per day or week, such as a low-volume blog site. With Aurora Serverless, you pay for only the database resources that you consume on a per-second basis.
您还需要考虑 AS 冷启动，这可能会出现问题，例如 here or here。
从你的问题中不清楚AS的使用模式到底是什么，或者冷启动是否会有问题。但基于无法 public 访问 AS 的问题，由于防火墙设置 VPN 的困难，我会 倾向于使用常规的 Aurora MySQL 或 RDS（不能真正评论 DigitalOcean）。
原因是您可以 public 访问它，它的设置速度非常快，价格已知，没有冷启动问题，而且它是托管服务。此外，它支持 autoscaling for storage，因此您无需担心。
此外，您可以从 小型数据库实例 （t3.small 或更小）开始，然后在需要时 up-size，或将只读副本添加到 off-load 读取密集型工作负载。
示例成本为：
以上内容不包括任何只读副本、Multi-AZ 设置或 RDS 或 Aurora 提供的其他额外功能。您可以使用 calculator.aws 根据您的个人需要进行自己的估算。对于 RDS，您可以使用 t3.small 更小的实例，例如t2.micro.
同时，通常不建议通过 Internet 公开您的生产级数据库。因此，您最终还是要么将其保密，要么使用 VPN 通过互联网私下访问它。但是通过正确设置 安全组 和 网络 ACL，您可以限制其 public 访问单个工作站或您工作场所的 IP 范围。如果 VPN 不是真正的选择，这将降低数据库拥有 public IP 的风险。
P.S.
我建议独立验证所提供的价格和详细信息，因为可能会出错。
我了解到您对 Amazon Aurora Serverless 的混合云架构有一些疑问。
这是一个非常棘手的话题，可能很容易被视为自以为是（幸运的是，社区对此持开放态度）。
所以，我尝试尽可能多地参考 public material 并尝试解释我的想法，如果我必须设计这种设置。
声明一下，本人不是AWS官方。
然而，过去三年我一直在创业行业构建和运营云应用程序......巧合的是我有几分钟的时间，所以这是我的想法：
1。问题陈述
Aurora Serverless 可通过 VPC 接口端点访问[1]:
Each Aurora Serverless DB cluster requires two AWS PrivateLink endpoints. If you reach the limit for AWS PrivateLink endpoints within your VPC, you can't create any more Aurora Serverless clusters in that VPC.
根据文档 [1]，正如您已经正确指出的那样，这些端点是私有结构：
You can't give an Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC) based on the Amazon VPC service.
2。问题范围
您的问题涉及 best-practices（Q1）、成本方面（也是 Q1）以及与云中其他数据库选项的功能差异（Q2），例如public 通过互联网访问和自动缩放。
将数据库工作负载迁移到 public 云时，这些都是有效的问题。但与此同时，它们只是应该考虑的问题的一个子集。
据我了解，我们在这里面临三个应明确强调的挑战：您正在 (CI) 启动 到云的迁移，(CI我) 您将要将现有工作负载修改为 混合工作负载 并且 (CIII) 您正在执行 数据库迁移 。
这三者通常本身就是一个大话题，不应该过早地决定它们。
但是，如果您的工作量正如您所描述的那样“轻”，那么将它们一起完成的风险可能是可以接受的。这不是我可以在下面讨论的内容。
因此，让我们关注一下在查看上述挑战 (C1) - (C3) 时出现在我脑海中的最基本问题：
3。混合工作负载是否可以接受？ (C2)
我认为您应该问自己的主要问题是 on-premise 工作负载是否可以转换为混合工作负载。
因此，关于 latency 和 reliability，您应该考虑将数据库放置在远离客户端的位置。
此外，您应该评估新的数据库引擎是否符合您的性能预期（例如，扩展速度足以满足窥视流量）[3] 以及数据库兼容性和限制是否可以接受 [4]。
通常，与云的连接（可能通过外部网络运营商）不如一堆电缆 on-premise 可靠。也许您的工作量甚至那么小，以至于数据库及其客户端 运行 在同一个 hypervisor/machine 上。
在那种情况下，将东西移到很远的地方（通过第 3 方网络连接），绝对应该慎重考虑。
事实是，要使工作负载可靠 and/or 高度可用，不仅 Aurora 必须满足这些标准（确实如此），您的网络连接也必须如此。
当您问自己正确的问题时，您会自动开始描述您的工作量。
AWS 发布了一系列 public 指南来帮助您完成此过程。
有 Well Architected Framework [10] 和 Well-Architected Tool [11] - 后者是“自动化”方式应用框架。
例如，可靠性支柱 [9] 包含 AWS 专家的一些想法和专业知识，以真正质疑您的混合方法。
此外，AWS 发布了所谓的 Lenses[13]，从 well-architected 的角度讨论特定的工作负载类型。
正如您要求的 best-practices (Q1)，我想指出，目前没有针对您描述的工作负载类型的详细 [=215=]。
但是，在文档 [12] 中有一个名为“使用 Amazon Aurora 执行概念验证”的 Aurora 指南。 （更多信息在下面的“Aurora POC 指南”部分）
我过去开发的应用程序大量使用数据库层，因此如果不进行重大重构就无法进行这样的更改...
这就引出了第二点：迁移策略.
4。可接受的迁移策略是什么？ (C1)
由于这是数据库迁移，您应该问自己两个主要问题：(a) 您希望迁移到什么程度（称为迁移的 6R - 一个独立于数据库的一般概念）和(b) 如何将数据库部分（尤其是数据）提升到云端。
我不想在这里详述，因为它在很大程度上取决于您的工作负载特征。
AWS 发布了一份详细指南，可帮助您做出这些决定。 [15]
它提到了一些有用的工具ch 作为 DMS 和 SCT 可帮助您正确转换模式（如有必要）并将数据从源数据库集群移动到目标数据库集群（可选择以“在线”/“实时”迁移方式进行，无需停机）。
我想再次强调，您必须做出一个重大决定：重新构建平台 与 重新构建 应用程序（即数据库客户端）
我想您只需进行少量更改即可使 Aurora Serverless 工作，但为了充分利用 Aurora 的功能，可能需要重新架构（最终可能会将整个工作负载移至云端）。
如果您决定对您的应用程序进行部分重构，您也可以使用所谓的 Data API。
Aurora Serverless [7][8] 的 Data API 使得直接通过 public 互联网发送查询成为可能。
如果 (i) 您有能力重构应用程序代码的某些部分，并且 (ii) 您的应用程序的特征符合数据 API，那么它可能适合您。
Data API 具有全新的数据库连接管理方法，因此非常适合某些无服务器用例。但是，这可能不适用于某些具有 long-hold / 大量使用连接的传统数据库工作负载。
您还应该注意 Data API 的数据库引擎兼容性（“数据的可用性 API” [12]）。
5。决策
我觉得技术上访问Aurora Serverless应该是没有问题的。
您基本上有四种连接选项：(a) 直接通过 Internet，(b) 通过 AWS 托管 (site-to-site) VPN 连接，(c) 通过基于 EC2 实例的 VPN 连接和 (d) 通过 Direct Connect（缩写 DX).
- 仅当您重新设计应用程序以使用数据 API AFAIK 时，选项 (a) 才有可能。
- 应该支持选项 (d)，但根据固定成本，它是最昂贵的。它应该得到支持，因为 AWS Interface Endpoints（进入 Aurora Serverless 的入口点）是通过 DX 访问的。
- 这里的专家认为应该支持选项 (c)。 [19]
- 一开始肯定不支持选项 (b) - 但据我了解，现在可以了。这是因为自 2018 年 9 月以来，AWS PrivateLink（支撑 AWS 接口端点的技术）支持来自 on-premises 通过 AWS 托管 VPN 的连接。[17]
此外，您可能必须将 DNS 查询从 on-premise 转发到云中，以便正确解析 VPC 接口端点。 [18]
您应该描述您的工作负载，指定关于安全性、可靠性、性能[=的最低要求183=]（参见Well-Architected框架）最后看最cost-effective的方法来完成它。
在 B2B 模式中，我不会为了降低成本而妥协这三者（请参阅我在下面部分的意见）。
你基本上有两个选择来决定：
- 自己完成工作（希望使用此 post 中引用的 material 会更容易一些）
- 向 AWS 或外部公司寻求 AWS 解决方案架构师的帮助
这纯粹是 (1) 弄清楚所有这些并使其正常运行所需的时间，(2) 成本（即实施解决方案的运营成本和咨询成本），(3)迁移过程中出现问题时涉及的财务风险。
正如您在“将一切都迁移到云中”这个问题中所述，我想您正处于云之旅的开端。
AWS 官方文件针对处于这种情况的公司说明如下：
If your business is new to AWS, consider a managed service provider, such as AWS Managed Services, to build out and manage the platform. [14]
我有创业行业的背景，我知道对于小公司来说这不是一个选择 - 但只是想提一下这个选择是存在的。
6。结论/我的意见(!)
最好避免将数据库暴露在互联网上。这不仅是我自己的意见，也是其他人的意见。 [19]
我会尝试（至少！）使用 AWS 托管 VPN 方法并在 on-premise 和云之间设置 冗余 VPN 连接.
为什么我说“最低限度”？
因为一个合适的解决方案可能是将整个工作负载转移到云端。
但是，如果这不可能，我会尝试降低建立混合工作负载所涉及的风险。
从安全角度来看，托管 VPN 连接可能是小型工作负载降低风险的最 cost-effective 方式。
根据我的经验：
在过去的三年里，我运行了一个完全构建在 AWS 云中的 SaaS 应用程序。
我们有服务器l 从那时起我们的网络运营商停运。我永远不会足够信任他们来建立某种混合架构。
不适用于我们提供的工作负载类型（B2B 领域的 SaaS Webapp）和互联网 contract/connectivity 我们有 ATM。绝不。
但是，情况对您来说可能完全不同 - 特别是如果您已经从您的 datacenter/office 托管服务很长时间而没有可靠性问题。
如果你读到这里，你可能会问自己为什么有人想要写这样一篇文章。
嗯，我正在准备 AWS Certified Database Specialty [20]，这是一个很好的机会来做一些认真的研究，做一些笔记并收集一些 sources/references。
我想认可各种 AWS 认证路径 [16] 和围绕它的学习平台生态系统。 AWS 发布了很多非常有用的资料。
希望您也能从中找到一些有趣的东西 post。
一个。 Aurora POC 指南
该指南提到，在将数据库迁移到 Aurora 时，应考虑：
重写客户端应用程序代码的某些部分 - 特别是正确使用 DNS 端点 [5][6] 和连接池 [5]
如果从相当复杂的（专有的）源数据库引擎（“移植您的 SQL 代码”[12]）迁移，则执行模式转换
（可选）合并一些 Aurora-specific 更改以使迁移更有效（适用于 Rearchitect 类型的迁移）[2]:
- To take full advantage of Aurora capabilities for distributed parallel execution, you might need to change the connection logic. Your objective is to avoid sending all read requests to the primary instance. The read-only Aurora Replicas are standing by, with all the same data, ready to handle SELECT statements. Code your application logic to use the appropriate endpoint for each kind of operation. Follow these general guidelines:
- Avoid using a single hard-coded connection string for all database sessions.
- If practical, enclose write operations such as DDL and DML statements in functions in your client application code. That way, you can make different kinds of operations use specific connections.
- Make separate functions for query operations. Aurora assigns each new connection to the reader endpoint to a different Aurora Replica to balance the load for read-intensive applications.
- For operations involving sets of queries, close and reopen the connection to the reader endpoint when each set of related queries is finished. Use connection pooling if that feature is available in your software stack. Directing queries to different connections helps Aurora to distribute the read workload among the DB instances in the cluster.
参考资料
[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/architecture/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]
[20]https://aws.amazon.com/de/certification/certified-database-specialty/
我们有一堆本地应用程序，每个应用程序 运行 都有自己的本地 MySQL 服务器。我们的工作量很轻，偶尔会有 activity 的爆发（一种 B2B 业务模型，在每月的某些特定时间使用我们的应用程序更有利可图，因此我们在那些日子里看到了使用高峰）。我们认为通过将所有数据库移动到一个数据库来简化基础架构是个好主意 server/cluster，经过一番讨论后我们决定购买托管解决方案比尝试建立和维护我们自己的解决方案更好 MySQL 集群（我们中 none 是 DBA）。
我们进行了大量研究，最终选择 Amazon Aurora Serverless 作为其自动扩展功能的可靠候选者，因此与我们检查的替代方案相比（可能）成本更低（AWS MySQL RDS 和 DigitalOcean 管理 MySQL)，由于我们通常很轻的工作负载偶尔会爆发 activity。
但是，据我所知，不可能简单地从我们的本地应用程序连接到 AWS Aurora Serverless（例如
- 解决此问题的最佳实践、现代方法是什么 - 我们是否应该使用站点到站点 VPN 将本地主机连接到云？这最终会让我们付出更多的代价吗？
- Aurora Serverless 真的是最好的解决方案吗，还是我们应该回退到 Amazon RDS 或 DigitalOcean 的托管 MySQL 集群，这两者都允许分配 public IP，但都不会自动缩放（意味着我们需要根据我们的峰值使用量购买一层，并且可能会浪费很多钱，因为它在一个月的大部分时间里几乎闲置）？
我们想要实现的是一个简单的、即发即弃的 MySQL 集群设置，由其他人管理，最好是自动缩放，并且不会花费地球或最终变得更多比当前的本地解决方案更难管理。
我们并不厌恶云，但我们也不想突然开始将一切全部迁移到云中，只是为了简化数据库基础架构。
我们不管理自己的防火墙 - 因此设置站点到站点 VPN 可能会很棘手，并且涉及与第三方（我们的网络提供商）的协调。理想情况下，如果可能的话，我也想避免这种麻烦。
你是对的，你不能从 AWS 外部直接连接 到 Aurora Serverless (AS)。原因是AS不能是public。来自 docs:
You can't give an Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC) based on the Amazon VPC service.
AS 还有 many other limitations 你应该知道的，其中一些是：没有副本，也没有 IAM 身份验证。
Q1 连接到 AS
有几个选项用于连接到 SA，或其他无法从 Internet 访问的服务（例如 RDS 代理、ElasticSearch 域）。
Bastion/jump主机
最便宜、最 ad-hoc 主要用于测试和开发的选项是使用 bastion/jump 主机。使用此选项，您将设置到堡垒的 ssh 隧道，而堡垒又会将您连接到 AS。
但是，这显然不适合可靠访问，但我觉得至少应该在答案中提及。
AWS Site-to-Site VPN
正如您已经提到的，AWS Site-to-Site VPN 是另一种选择。这显然是启用从 on-prem 访问 VPC 的更好方法。
但问题是成本，因为 your charged每小时 0.05 美元和每次数据传输。
每小时的价格并没有那么多。 1 个月约为 3.6 美元/月：
24 hours x 30 days x [=10=].05 = .6
数据传输更难估计，因为它取决于您的实际需求。例如，如果您估计每月将从 AS 中获取 100GB 的数据（入站流量免费），您将每月支付约 8.91 美元（前 1GB 免费）：
99GB * [=11=].09 = .91
假设上述情况，您将支付大约 12.51 美元/月。此 不包括 AS 价格本身。
但是，由于提到的防火墙设置问题，这可能在设置和管理方面比较麻烦，但却是有益的。
直接连接
AWS Direct Connect 最贵，但最可靠和私密。只是想提一下，因为这可能 不适合 您的 use-case.
Q2 AS 的适用性
AS的use-case之一是Infrequently used applications:
You have an application that is only used for a few minutes several times per day or week, such as a low-volume blog site. With Aurora Serverless, you pay for only the database resources that you consume on a per-second basis.
您还需要考虑 AS 冷启动，这可能会出现问题，例如 here or here。
从你的问题中不清楚AS的使用模式到底是什么，或者冷启动是否会有问题。但基于无法 public 访问 AS 的问题，由于防火墙设置 VPN 的困难，我会 倾向于使用常规的 Aurora MySQL 或 RDS（不能真正评论 DigitalOcean）。
原因是您可以 public 访问它，它的设置速度非常快，价格已知，没有冷启动问题，而且它是托管服务。此外，它支持 autoscaling for storage，因此您无需担心。
此外，您可以从 小型数据库实例 （t3.small 或更小）开始，然后在需要时 up-size，或将只读副本添加到 off-load 读取密集型工作负载。
示例成本为：
以上内容不包括任何只读副本、Multi-AZ 设置或 RDS 或 Aurora 提供的其他额外功能。您可以使用 calculator.aws 根据您的个人需要进行自己的估算。对于 RDS，您可以使用 t3.small 更小的实例，例如t2.micro.
同时，通常不建议通过 Internet 公开您的生产级数据库。因此，您最终还是要么将其保密，要么使用 VPN 通过互联网私下访问它。但是通过正确设置 安全组 和 网络 ACL，您可以限制其 public 访问单个工作站或您工作场所的 IP 范围。如果 VPN 不是真正的选择，这将降低数据库拥有 public IP 的风险。
P.S.
我建议独立验证所提供的价格和详细信息，因为可能会出错。
我了解到您对 Amazon Aurora Serverless 的混合云架构有一些疑问。 这是一个非常棘手的话题，可能很容易被视为自以为是（幸运的是，社区对此持开放态度）。 所以，我尝试尽可能多地参考 public material 并尝试解释我的想法，如果我必须设计这种设置。
声明一下，本人不是AWS官方。 然而，过去三年我一直在创业行业构建和运营云应用程序......巧合的是我有几分钟的时间，所以这是我的想法：
1。问题陈述
Aurora Serverless 可通过 VPC 接口端点访问[1]:
Each Aurora Serverless DB cluster requires two AWS PrivateLink endpoints. If you reach the limit for AWS PrivateLink endpoints within your VPC, you can't create any more Aurora Serverless clusters in that VPC.
根据文档 [1]，正如您已经正确指出的那样，这些端点是私有结构：
You can't give an Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC) based on the Amazon VPC service.
2。问题范围
您的问题涉及 best-practices（Q1）、成本方面（也是 Q1）以及与云中其他数据库选项的功能差异（Q2），例如public 通过互联网访问和自动缩放。
将数据库工作负载迁移到 public 云时，这些都是有效的问题。但与此同时，它们只是应该考虑的问题的一个子集。
据我了解，我们在这里面临三个应明确强调的挑战：您正在 (CI) 启动 到云的迁移，(CI我) 您将要将现有工作负载修改为 混合工作负载 并且 (CIII) 您正在执行 数据库迁移 。
这三者通常本身就是一个大话题，不应该过早地决定它们。
但是，如果您的工作量正如您所描述的那样“轻”，那么将它们一起完成的风险可能是可以接受的。这不是我可以在下面讨论的内容。
因此，让我们关注一下在查看上述挑战 (C1) - (C3) 时出现在我脑海中的最基本问题：
3。混合工作负载是否可以接受？ (C2)
我认为您应该问自己的主要问题是 on-premise 工作负载是否可以转换为混合工作负载。 因此，关于 latency 和 reliability，您应该考虑将数据库放置在远离客户端的位置。 此外，您应该评估新的数据库引擎是否符合您的性能预期（例如，扩展速度足以满足窥视流量）[3] 以及数据库兼容性和限制是否可以接受 [4]。
通常，与云的连接（可能通过外部网络运营商）不如一堆电缆 on-premise 可靠。也许您的工作量甚至那么小，以至于数据库及其客户端 运行 在同一个 hypervisor/machine 上。 在那种情况下，将东西移到很远的地方（通过第 3 方网络连接），绝对应该慎重考虑。
事实是，要使工作负载可靠 and/or 高度可用，不仅 Aurora 必须满足这些标准（确实如此），您的网络连接也必须如此。
当您问自己正确的问题时，您会自动开始描述您的工作量。
AWS 发布了一系列 public 指南来帮助您完成此过程。
有 Well Architected Framework [10] 和 Well-Architected Tool [11] - 后者是“自动化”方式应用框架。
例如，可靠性支柱 [9] 包含 AWS 专家的一些想法和专业知识，以真正质疑您的混合方法。
此外，AWS 发布了所谓的 Lenses[13]，从 well-architected 的角度讨论特定的工作负载类型。 正如您要求的 best-practices (Q1)，我想指出，目前没有针对您描述的工作负载类型的详细 [=215=]。
但是，在文档 [12] 中有一个名为“使用 Amazon Aurora 执行概念验证”的 Aurora 指南。 （更多信息在下面的“Aurora POC 指南”部分）
我过去开发的应用程序大量使用数据库层，因此如果不进行重大重构就无法进行这样的更改...
这就引出了第二点：迁移策略.
4。可接受的迁移策略是什么？ (C1)
由于这是数据库迁移，您应该问自己两个主要问题：(a) 您希望迁移到什么程度（称为迁移的 6R - 一个独立于数据库的一般概念）和(b) 如何将数据库部分（尤其是数据）提升到云端。 我不想在这里详述，因为它在很大程度上取决于您的工作负载特征。
AWS 发布了一份详细指南，可帮助您做出这些决定。 [15]
它提到了一些有用的工具ch 作为 DMS 和 SCT 可帮助您正确转换模式（如有必要）并将数据从源数据库集群移动到目标数据库集群（可选择以“在线”/“实时”迁移方式进行，无需停机）。
我想再次强调，您必须做出一个重大决定：重新构建平台 与 重新构建 应用程序（即数据库客户端） 我想您只需进行少量更改即可使 Aurora Serverless 工作，但为了充分利用 Aurora 的功能，可能需要重新架构（最终可能会将整个工作负载移至云端）。
如果您决定对您的应用程序进行部分重构，您也可以使用所谓的 Data API。 Aurora Serverless [7][8] 的 Data API 使得直接通过 public 互联网发送查询成为可能。 如果 (i) 您有能力重构应用程序代码的某些部分，并且 (ii) 您的应用程序的特征符合数据 API，那么它可能适合您。 Data API 具有全新的数据库连接管理方法，因此非常适合某些无服务器用例。但是，这可能不适用于某些具有 long-hold / 大量使用连接的传统数据库工作负载。 您还应该注意 Data API 的数据库引擎兼容性（“数据的可用性 API” [12]）。
5。决策
我觉得技术上访问Aurora Serverless应该是没有问题的。 您基本上有四种连接选项：(a) 直接通过 Internet，(b) 通过 AWS 托管 (site-to-site) VPN 连接，(c) 通过基于 EC2 实例的 VPN 连接和 (d) 通过 Direct Connect（缩写 DX).
- 仅当您重新设计应用程序以使用数据 API AFAIK 时，选项 (a) 才有可能。
- 应该支持选项 (d)，但根据固定成本，它是最昂贵的。它应该得到支持，因为 AWS Interface Endpoints（进入 Aurora Serverless 的入口点）是通过 DX 访问的。
- 这里的专家认为应该支持选项 (c)。 [19]
- 一开始肯定不支持选项 (b) - 但据我了解，现在可以了。这是因为自 2018 年 9 月以来，AWS PrivateLink（支撑 AWS 接口端点的技术）支持来自 on-premises 通过 AWS 托管 VPN 的连接。[17]
此外，您可能必须将 DNS 查询从 on-premise 转发到云中，以便正确解析 VPC 接口端点。 [18]
您应该描述您的工作负载，指定关于安全性、可靠性、性能[=的最低要求183=]（参见Well-Architected框架）最后看最cost-effective的方法来完成它。 在 B2B 模式中，我不会为了降低成本而妥协这三者（请参阅我在下面部分的意见）。
你基本上有两个选择来决定：
- 自己完成工作（希望使用此 post 中引用的 material 会更容易一些）
- 向 AWS 或外部公司寻求 AWS 解决方案架构师的帮助
这纯粹是 (1) 弄清楚所有这些并使其正常运行所需的时间，(2) 成本（即实施解决方案的运营成本和咨询成本），(3)迁移过程中出现问题时涉及的财务风险。
正如您在“将一切都迁移到云中”这个问题中所述，我想您正处于云之旅的开端。 AWS 官方文件针对处于这种情况的公司说明如下：
If your business is new to AWS, consider a managed service provider, such as AWS Managed Services, to build out and manage the platform. [14]
我有创业行业的背景，我知道对于小公司来说这不是一个选择 - 但只是想提一下这个选择是存在的。
6。结论/我的意见(!)
最好避免将数据库暴露在互联网上。这不仅是我自己的意见，也是其他人的意见。 [19]
我会尝试（至少！）使用 AWS 托管 VPN 方法并在 on-premise 和云之间设置 冗余 VPN 连接.
为什么我说“最低限度”？
因为一个合适的解决方案可能是将整个工作负载转移到云端。
但是，如果这不可能，我会尝试降低建立混合工作负载所涉及的风险。
从安全角度来看，托管 VPN 连接可能是小型工作负载降低风险的最 cost-effective 方式。
根据我的经验：
在过去的三年里，我运行了一个完全构建在 AWS 云中的 SaaS 应用程序。
我们有服务器l 从那时起我们的网络运营商停运。我永远不会足够信任他们来建立某种混合架构。
不适用于我们提供的工作负载类型（B2B 领域的 SaaS Webapp）和互联网 contract/connectivity 我们有 ATM。绝不。
但是，情况对您来说可能完全不同 - 特别是如果您已经从您的 datacenter/office 托管服务很长时间而没有可靠性问题。
如果你读到这里，你可能会问自己为什么有人想要写这样一篇文章。 嗯，我正在准备 AWS Certified Database Specialty [20]，这是一个很好的机会来做一些认真的研究，做一些笔记并收集一些 sources/references。 我想认可各种 AWS 认证路径 [16] 和围绕它的学习平台生态系统。 AWS 发布了很多非常有用的资料。
希望您也能从中找到一些有趣的东西 post。
一个。 Aurora POC 指南
该指南提到，在将数据库迁移到 Aurora 时，应考虑：
重写客户端应用程序代码的某些部分 - 特别是正确使用 DNS 端点 [5][6] 和连接池 [5]
如果从相当复杂的（专有的）源数据库引擎（“移植您的 SQL 代码”[12]）迁移，则执行模式转换
（可选）合并一些 Aurora-specific 更改以使迁移更有效（适用于 Rearchitect 类型的迁移）[2]:
- To take full advantage of Aurora capabilities for distributed parallel execution, you might need to change the connection logic. Your objective is to avoid sending all read requests to the primary instance. The read-only Aurora Replicas are standing by, with all the same data, ready to handle SELECT statements. Code your application logic to use the appropriate endpoint for each kind of operation. Follow these general guidelines:
- Avoid using a single hard-coded connection string for all database sessions.
- If practical, enclose write operations such as DDL and DML statements in functions in your client application code. That way, you can make different kinds of operations use specific connections.
- Make separate functions for query operations. Aurora assigns each new connection to the reader endpoint to a different Aurora Replica to balance the load for read-intensive applications.
- For operations involving sets of queries, close and reopen the connection to the reader endpoint when each set of related queries is finished. Use connection pooling if that feature is available in your software stack. Directing queries to different connections helps Aurora to distribute the read workload among the DB instances in the cluster.
参考资料
[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/architecture/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]
[20]https://aws.amazon.com/de/certification/certified-database-specialty/