我将首先从您的帖子中解决一些问题。从您的标题看来，您在使用 RDS 中的数据库的 EC2 服务器上有应用程序代码。我将假设您的 EC2 实例使用 EBS 进行存储。
但应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。
从技术上讲，EC2 实例将无法访问 RDS 中的底层数据存储。即使您在 KMS 中使用相同的主密钥，也会使用不同的数据密钥来加密 EC2 实例 EBS 卷和 RDS 卷。现在，当然，RDS 实例有一个标准数据连接，允许使用适当的凭据进行访问，但这与说我可以“grep”或更改底层数据库文件/内容不同。这只是您用来对其进行查询并返回响应的任何数据库所允许的标准连接。当 RDS 将数据保存到非易失性内存时，底层存储将被加密。
所以这不是意味着密钥也驻留在 AWS 服务器中。
当然，是的。为了让 PaaS（平台即服务）处理加密的底层数据，它需要访问加密密钥来读取数据。
使用 AWS 就像一切一样，是有风险的。您（可能还有您的组织）需要就您愿意承担的风险级别做出明智的决定，并权衡您使用它的目的（以及您所暴露数据的敏感性级别）。
在加密方面，AWS 拥有许多不同级别的控制权，客户可以行使这些控制权。我通常会在下面从松到紧列出它们。当然，你控制得越多，你的责任（危险）就越大。
A) AWS 提供的最简单且通常默认的方法是使用亚马逊托管密钥。这些是看起来像 aws/ebs 或 aws/rds 的那些。在这种情况下，您使用的是 Amazon 创建并完全管理的密钥。但是，由于主密钥是共享的，因此没有对特定密钥的使用进行审计。 （当然，在服务发布到 CloudTrail 的范围内，对使用它的资源的访问仍然使用 CloudTrail 进行审核）。对于 KMS，使用信封加密。这意味着尽管“主”密钥可能相同，但主密钥只是加密另一个唯一的加密密钥。例如，使用相同主密钥创建的两个不同 EBS 卷将具有与数据关联的不同基础加密密钥。
B) 接下来，您可以迁移到 CMK。这是您进入 KMS 并专门创建一个主密钥（客户主密钥）供您使用的地方。每个主密钥每月收费，尽管它可以加密其下的无数底层密钥。如果您使用亚马逊创建的材料创建它，这意味着 AWS 将创建密钥（包括底层加密密钥）。它永远不会让你看到底层的加密密钥，这对你来说可能是一个加号或减号。如果您愿意，可以将其配置为每年自动轮换密钥材料。 CMK 专门用于您和您的账户。默认情况下，它只允许 IAM 策略控制对您账户的密钥的访问。它可以是一种有效的纵深防御防御。例如，如果有人错误地提供了允许公开访问数据的 S3 存储桶策略，默认情况下，KMS 将只允许授权给 CMK 的授权用户访问密钥，并有效地拒绝公开访问存储桶中的数据用户。这当然假设数据首先被加密。最后，使用该 CMK 的每个操作都将使用 CloudTrail 进行审计。这使您可以检查加密密钥的使用方式和位置。以下是 KMS 安全常见问题解答的摘录：
AWS KMS 的设计使得包括 AWS 员工在内的任何人都无法从该服务中检索您的明文 CMK。 AWS KMS 使用已根据 FIPS 140-2 验证或正在验证的硬件安全模块 (HSM) 来保护您的密钥的机密性和完整性。无论您是使用 AWS KMS 还是 AWS CloudHSM 创建密钥，还是将密钥材料导入 CMK，您的密钥都存储在这些 HSM 中。您的明文 CMK 永远不会离开 HSM，永远不会写入磁盘，并且只会在 HSM 的易失性内存中用于执行您请求的加密操作所需的时间。对服务主机上的软件和 AWS KMS HSM 固件的更新由多方访问控制控制，该控制由 Amazon 内部的一个独立小组和 NIST 认证的实验室按照 FIPS 140-2 进行审计和审查。
C) 接下来，您可以使用 CMK，但决定不信任 Amazon 创建加密密钥材料。您在一个有点复杂但必要的过程中安全地传输密钥材料，以确保密钥材料的完整性和机密性。创建 CMK 时，您会创建一个密钥的“外壳”，以准备导入密钥材料。在您这样做之前，密钥不能以任何有理形式使用。
通常，这与 Amazon 生成的 CMK 具有相同的优点/缺点。但是，有两个值得注意的例外情况：1) 恢复 - 即使 CMK 在整个选定区域的 AWS 上进行了冗余备份，但在发生长时间电源事件（或其他一些灾难）并且 AWS 无法访问您的关键材料时提供，它没有办法恢复密钥材料。您将需要再次提供密钥材料才能加载到 CMK。有一种安全的方法可以做到这一点，但现在您必须小心控制和保护您身边的密钥材料。您安全地执行此操作的能力可能对基础数据的安全性影响最大。 2) 由于 AWS 假设您正在控制密钥材料，因此它将允许您立即清除 CMK。在B）中，由于CMK可以控制数十、数百、数千甚至无数的数据元素，如果一个错误，破坏密钥是一场灾难。为了防止这种情况，AWS 永远不会让您立即删除密钥。相反，它将安排删除密钥并立即暂停使用该密钥。在任何情况下，删除都不能超过 7 天。但是，如果您希望能够使用客户提供的内容立即清除 AWS 的密钥 CMK 背后的加密货币是可行的方法。
D) 如果您想进一步控制 AWS 中加密密钥的管理方式，您可以使用 CloudHSM。这实际上是您自己在 AWS 中的专用密钥服务器。然而，你在这里失去了重要的东西。尽管您有很多控制权，但该服务很昂贵，而且许多（几乎所有）PaaS 产品不能与 CloudHSM 一起使用（例如：RDS，尽管我认为 Oracle RDS 可以工作）。我应该注意到，这项服务在 KMS 产品中相对较早，特别是在他们对创建的 KMS 密钥做出其他保证（如 FIPS 认证）之前。因此，它没有与其他服务很好地集成，并且在 AWS 产品中看起来像是一个红头发的继子。我得到的印象是这是一个小众应用程序，它并没有受到 AWS 的喜爱。这是一个“单独行动”的产品。
E) 您可以使用客户端加密，而不是使用服务器端加密（AWS 可以访问存储在某处的底层加密密钥）。更少的 AWS 服务支持这一点（我知道的唯一一个是 S3）。这与 C) 类似，您需要为所有加密密钥提供安全性，并在需要访问底层数据时提供它们。
F) 完全脱离网格会在它进入 AWS 之前对其进行加密。当然，这会阻止您使用 AWS 中的数据，例如在 EC2 实例或 RDS 实例中，因为 AWS 无法解码或使用数据。
归根结底，您需要决定什么值得冒险，什么不值得。您的组织在为您考虑在 AWS 上使用的服务与在本地使用的服务创建安全配置方面的表现如何？这样做的成本与 AWS 控制/妥协的可能性有何不同？这些问题的答案将最终决定 AWS 是否适合您。