Data governance with annotations in Amazon S3

AWS Architecture Blog

AWS Architecture Blog2026年10月26日

Data governance with annotations in Amazon S3

6.9内容质量

TL;DR · AI 摘要

Data governance with annotations in Amazon S3 AWS Architecture Blog Data governance with annotations in Amazon S3 If you...

核心要点

主题聚焦：Data governance with annotations in Amazon S3
来源：AWS Architecture Blog，建议结合原文判断细节。
AI 分析暂不可用，本条为保底评分与摘要。

#AI#编程#后端#安全#产品

打开原文

在 Amazon S3 中使用注解进行数据治理 | AWS 架构博客

在 Amazon S3 中使用注解进行数据治理

如果您在 Amazon Simple Storage Service (Amazon S3) 中执行数据治理，最关键的信息很可能并不存储在 S3 中。设想一下对象的分类方式、适用的保留策略、数据可能存储的位置，以及是否包含个人可识别信息（PII）。通常您会将这些信息保存在单独的数据库中，与所描述的对象分属不同的系统。

Amazon S3 注解功能填补了这一空白。您无需重写对象即可将治理信息直接附加到 S3 对象上。单个对象版本最多可携带 1,000 个注解。每个注解是 1 字节到 1 MB 之间的 UTF-8 数据负载，采用 JSON、XML、YAML 或纯文本等格式。这为完整治理记录提供了充足空间，而不仅仅是几个键值对。

注解功能为您提供了传统元数据存储难以实现的五大特性：

随数据移动的上下文 – S3 将注解与对象版本一起存储，而非单独系统。当您复制或复制对象时，S3 会一并移动注解，因此分类或驻留标签会伴随灾难恢复副本。

可原地修改的上下文 – 更新注解不会重写对象或改变其 ETag，因此可以在验证上下文时修正记录的分类，或将生成的标签从建议状态升级为已审核状态。

无需读取数据即可获取治理信息 – 仅具有注解只读访问权限的消费者可通过注解 API 按对象回答"哪些对象包含 PII 且保留策略已过期"等问题，或通过 S3 元数据注解表跨整个存储桶进行查询。

任何存储类别中均可读取的上下文 – 即使对象存档在冷存储类别中，其注解仍可直接读取。您可以在不先恢复对象的情况下，通过 Amazon S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 读取对象的治理信息。无论父对象的存储类别如何，注解的计费均按 S3 标准费率计算。

可扩展的 SQL 查询 – 作为 Apache Iceberg 表的 S3 元数据注解表，可通过 Amazon Athena 或任何 Iceberg 兼容引擎对大量对象进行上下文查询。

本文将完整演示这一模式，然后介绍决定设计方案正确性的几个 S3 行为特性。每个行为特性均包含文档规则和实际示例：注解负载、AWS 身份和访问管理 (IAM) 策略声明，或 AWS 命令行界面 (AWS CLI) 调用。

先决条件

要跟随本文并调整示例，您需要以下内容：

启用版本控制的 S3 存储桶的 AWS 账户。

具有配置存储桶策略和注解操作权限的 AWS 身份和访问管理 (IAM) 主体。

已安装并配置的 AWS CLI。

假定您熟悉 S3 注解概念、对象版本控制和基于 IAM 身份的策略。

治理记录

考虑一个受管存储桶，其中每个对象都是业务记录，如合同、政策文件或客户记录。您构建一个增强处理管道，该管道读取每个新对象并记录治理注解。该注解捕获分类信息、适用的保留策略、司法管辖区和数据驻留信息、PII清单以及简要说明。注解不仅限于治理场景。相同机制可附加其他对象上下文信息，例如简要内容摘要或处理日期。在此模式中，注解在上传完成后通过注解API操作写入。相同流程通过架构部分所示的独立路径，为管道创建之前的对象执行回填操作。

PutObjectAnnotation调用会在指定对象版本上写入一个唯一命名的注解，且一个对象版本最多可保存1000个注解。如何将治理记录分布在这些注解中是设计选择。使用细粒度注解时，您可以单独更新上下文的某一方面而无需重写其余内容，将意外覆盖限制在单个字段，并在启用后查询S3元数据注解表中的更细粒度单元。单个注解保存完整记录可使每次写入和读取都通过单个操作完成，并保持记录内部一致性。无需协调多个名称之间的部分状态。本文使用名为governance-context的单个注解，因为此处的记录作为整体创建和使用。

有效负载如下所示。

code

{
  "schema_version": "1.0",
  "classification": "confidential",
  "retention": {
    "policy": "contracts-7y",
    "effective_date": "2026-06-01",
    "expires_on": "2033-06-01",
    "status": "active"
  },
  "jurisdiction": "EU",
  "data_residency": "eu-west-1",
  "pii": {
    "present": true,
    "categories": ["name", "email", "national_id"]
  },
  "rationale": "Signed customer contract containing personal data of EU data subjects; classified confidential under the 7-year contracts retention policy.",
  "generated_by": "enrichment-process",
  "generated_at": "2026-06-29T10:15:00Z",
  "review_required": true
}

当记录被审核或重新分类时，增强处理流程通过PutObjectAnnotation原地更新注解。分类变更无需重写对象或更改其ETag。这种原地更新本身会被复制，因此源对象的后续重新分类可保持跨区域副本的上下文最新，无需重新复制对象。只要复制角色携带本文后续描述的注解复制权限，此机制即可正常工作。

早于管道创建的对象需要相同的上下文信息。回填流程通过相同的PutObjectAnnotation调用批量为现有对象版本添加注解，因此写入路径可处理新到达的对象，而回填路径可将现有对象集提升至相同标准。这两种路径均体现在后续架构图中。

在读取方面，拥有只读注解访问权限的消费者可通过列出并检索注解上下文来回答治理问题。无需读取对象本身，也无需维护独立的治理数据库。

在大规模场景中，您通过启用一个S3元数据注解表来激活功能，该表通过存储桶元数据配置指定一个IAM角色，S3使用该角色来读取您的注解。S3随后会在Amazon S3 Tables（Amazon S3的一项功能，由Apache Iceberg支持）中创建并维护一张表，您可以通过SQL查询该表。该角色信任metadata.s3.amazonaws.com服务主体。这使相同的问题可以通过一个Athena语句在大量对象中进行查询。S3异步填充该表，初始数据回填可能需要几分钟到几小时，具体时间取决于存储桶中对象和注解的数量。查询结果反映的是最近一次表刷新时的注解状态，通常在约一小时后完成刷新，因此应将其视为最终一致性而非实时性。

code

SELECT object_key, object_version_id
FROM "s3tablescatalog/aws-s3"."b_amzn_s3_demo_governance"."annotation"
WHERE name = 'governance-context'
AND json_extract_scalar(text_value, '$.pii.present') = 'true'
AND json_extract_scalar(text_value, '$.retention.status') = 'expired';

该模式的参考架构

该模式位于以S3为中心的事件驱动系统中，如图1所示。它包含四条路径：写入路径用于丰富新对象，维护路径用于保持上下文最新，回填路径用于注解现有对象，读取路径则仅从注解上下文中为消费者提供服务。

图1：用于编写、维护、回填和读取S3注解治理上下文的事件驱动架构。

图1中的编号步骤追踪了这四条路径：

生产者通过PutObject操作将对象上传到受管理的S3存储桶中。

S3向Amazon EventBridge发出对象创建事件。当您通过Amazon EventBridge进行路由而非直接从S3调用AWS Lambda时，可以基于事件属性（如前缀或对象大小）进行过滤。您还可以将相同事件路由到多个目标而无需更改存储桶配置。如果不需要这种路由功能，直接通知或Amazon Simple Queue Service（Amazon SQS）队列是更简单的选择。

Amazon EventBridge调用富化Lambda函数。

该函数调用Amazon Bedrock富化代理对对象进行分类并提取保留期、司法管辖区和PII上下文。代理将结构化上下文返回给函数（虚线返回箭头）。在写入任何内容之前，请确保函数验证输出是否能解析为JSON并符合您的模式。模型通常会将JSON包裹在Markdown代码围栏中，但注解负载必须是原始结构化文档。

函数通过PutObjectAnnotation操作将上下文写入对象。该写入操作会发出s3:ObjectAnnotation:Put事件通知，下游消费者可以订阅该通知，这符合事件驱动设计。

按计划，Amazon EventBridge Scheduler会重新调用富化函数以重新评估并就地更新注解。

为了注解早于管道创建的对象，S3批量操作会调用回填Lambda函数。

回填函数通过PutObjectAnnotation操作写入上下文。

消费者向Bedrock消费者代理询问治理问题，代理返回基于证据的答案（虚线返回箭头）。

消费者代理通过ListObjectAnnotations和GetObjectAnnotation列出并检索相关注解。S3仅返回注解上下文，从不返回对象主体（虚线返回箭头）。

对于跨多个对象的查询，消费者代理会查询Athena。

Athena读取S3元数据注解表，该表由S3自动从对象注解中维护（虚线表示“维护”关系）。

第6步中的计划更新需要一个保护条件：对对象的ETag进行条件写入。通过--object-if-match CLI参数传递ETag，该参数对应x-amz-object-if-match请求头。

ETag是S3为对象版本内容返回的标识符。该函数在获取对象时读取它，并在写入时将其返回。如果在此期间对象被覆盖，ETag将不再匹配，注解写入会失败。这可以防止覆盖函数从未评估过的版本所属的上下文。

决定你设计的行为

管道实现是直接的。本节中的行为是团队最容易在治理设计上出错的地方。每个行为都会在文档中出现，而每个行为的治理影响只有在追溯时才会变得清晰。一个原则可以预测大部分情况：

注解是调用方创建的上下文，绑定到特定对象版本。S3存储并移动它，但不会解释或验证其含义。注解的生命周期遵循对象版本的生命周期。

由此产生两个后果。由于注解绑定到对象版本，版本管理行为决定了你的上下文是保留还是消失：删除标记、特定版本的删除和覆盖都会改变保留的内容。此外，由于S3不解释内容，代理写入的分类仅与生成它的过程一样可信。对于每个行为，请问注解绑定到什么，以及在该情况下对象版本的生命周期如何运作。

删除作用域限定在对象版本

常见的治理需求是根据请求删除数据主体的记录。由于注解绑定到特定对象版本，只有当该版本消失时注解才会消失。在非版本化存储桶中，删除对象并假设其上下文随之消失是正确的。

在版本化存储桶中，没有版本ID的DELETE请求会创建删除标记，但保留底层版本及其注解。对象不再出现在ListObjectsV2响应中，看起来已经消失，但仍然会通过ListObjectVersions返回，之前版本上记录的PII上下文依然存在。

要真正删除注解，请删除特定版本：

code

aws s3api delete-object \
  --bucket amzn-s3-demo-governance \
  --key contracts/acme-msa.pdf \
  --version-id <VERSION_ID>

如果希望按计划过期非当前版本，可以应用如下的S3生命周期配置。它会在非当前版本产生30天后永久删除这些版本。

code

{
  "Rules": [
    {
      "ID": "expire-noncurrent-governed-records",
      "Filter": { "Prefix": "contracts/" },
      "Status": "Enabled",
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
    }
  ]
}

生命周期规则按照时间计划过期版本，无法读取注解值。如果需要对象的分类或保留状态触发过期或删除，必须自行构建自动化流程读取注解并执行删除操作。如果需要的触发条件是事件而非数值（如合同关闭或审计完成），Object Lock 事件持有功能可原生处理此类场景，无需构建自动化流程。

在版本化存储桶中，不要依赖普通删除操作实现被遗忘权工作流程。需提前明确采用版本定向删除还是过期非当前版本，并在工具链中仅支持该路径，同时使用真实对象进行测试。失败模式是静默无响应。版本定向删除具有永久性，因此误删版本会导致只能从独立备份中恢复的数据丢失。

Object Lock 冻结注解

治理型存储桶常使用 S3 Object Lock，而注解被视为对象版本的修改操作，Object Lock 会阻止此类操作。当版本处于活跃的 Object Lock 保留期时，PutObjectAnnotation 和 DeleteObjectAnnotation 均会因 AccessDenied 被拒绝，并提示“对象受对象锁保留保护”，该限制在治理模式和合规模式下均适用。读取注解仍可正常进行，因此消费者不受影响。无法对已开始保留的版本添加或更新治理型注解。

这使注解顺序成为设计规则：应先对对象进行注解，再应用保留期。在锁定前写入的注解可被读取且保持不变，但会冻结至保留期结束。如果代理程序会随时间重新评估分类，需同步规划保留时长和数据富化频率。当保留期基于未来事件而非写入时间启动时，注解时无法预知冻结窗口的结束时间，因此应在锁定生效前写入完整的治理记录。

保留模式也改变了被遗忘权路径。在治理模式下，除非调用者持有 s3:BypassGovernanceRetention 权限并传递 --bypass-governance-retention 参数，否则对锁定版本的版本定向删除会被拒绝。因此该流程需要权限和审批步骤。在合规模式下，保留期结束前任何人都无法删除版本，包括根用户，因此在此前可能无法满足删除请求。

事件持有引入了第三种情况。处于事件持有下的版本在持有期间受保护。释放持有会启动保留期而非结束保护，因此释放操作会使删除请求更难实现。IAM 和存储桶策略的条件密钥可控制谁可以设置或释放持有，并可强制规定最小和最大持续时间，这正是审批关卡应处的位置。

Object Lock 和注解承担不同职责。Object Lock 通过事件持有实现保留（包括基于事件的保留），注解则记录适用的策略及原因，这是 Object Lock 不会存储的上下文信息。前者保护对象，后者解释决策。

分段复制会丢弃注解除非主动启用

治理型标签只有在数据移动时保持关联才有意义。对于 CopyObject 请求（对象最大 5 GiB），S3 默认会连同对象一起复制注解。

对于通过分段上传复制的较大对象，除非您主动选择，否则注释不会被复制。当AWS CLI和SDK通过传输管理器进行分段上传时，通常在8MB以上会使用此方式。默认行为容易被忽视，因为对象大小变化会改变行为，而非运行的命令。当对象大小超过分段上传阈值时，小对象复制操作会静默丢弃标签，不会报错或警告。通过分段上传主动选择后，SDK会在复制完成后写入注释，因此目标对象会短暂存在但缺少所有注释。

code

aws s3 cp \
  s3://amzn-s3-demo-governance/contracts/acme-msa.pdf \
  s3://amzn-s3-demo-governance-dr/contracts/acme-msa.pdf \
  --copy-props all

直接调用CopyObject时，x-amz-annotation-directive头提供显式控制。COPY会在目标对象上包含源注释，EXCLUDE则会排除它们。当您明确需要低敏感性复制时，请使用EXCLUDE。

建议将此设置作为默认值统一配置，而非每次调用时决定。在所有依赖注释的复制路径中标准化使用--copy-props主动选择。通过复制超过分段阈值的对象进行测试来确认，因为小对象测试可能通过但会隐藏问题。

注释删除和覆盖是不可逆操作

对象版本控制为您提供安全网，但注释没有此功能。即使在启用版本控制的存储桶中，注释也没有删除标记和版本历史记录，因此删除后将永久丢失。更新操作同样如此：向现有注释名称写入新内容会直接覆盖原有内容。这使得意外覆盖与删除一样具有破坏性。

应将注释删除视为需要审批的主动操作，而非常规清理。将s3:DeleteObjectAnnotation权限限制在专用管理角色，并设置审批流程。如果记录的上下文可能需要用于审计，请订阅s3:ObjectAnnotation:Put和s3:ObjectAnnotation:Delete事件通知，或使用S3元数据日志表，以保留注释变更的审计轨迹，确保删除注释不会抹去您唯一的治理决策副本。

SSE-C对象无法添加注释

S3使用与父对象相同的加密配置来加密注释。这包括使用Amazon S3托管密钥（SSE-S3）、AWS KMS密钥（SSE-KMS）和双层SSE-KMS（DSSE-KMS）的服务器端加密。设计时需要注意的一个例外是：使用客户提供的密钥进行的服务器端加密（SSE-C）对象无法添加注释。以下AWS CLI调用尝试为SSE-C对象添加注释并显示返回的错误。

code

aws s3api put-object-annotation \
  --bucket amzn-s3-demo-governance \
  --key contracts/acme-msa.pdf \
  --annotation-name governance-context \
  --annotation-payload governance-context.json \
  --sse-customer-algorithm AES256 \
  --sse-customer-key <BASE64_KEY> \
  --sse-customer-key-md5 <KEY_MD5>

An error occurred (InvalidRequest) when calling the PutObjectAnnotation operation:
Adding metadata to object with CUSTOMER_MANAGED encryption is not supported

如果你在SSE-C上构建受控存储桶并计划叠加基于注释的上下文，这种模式将无法正常工作。这与SSE-C的整体发展方向一致：2026年4月，S3默认禁用了新存储桶和部分现有存储桶的SSE-C功能。如果你正在使用或考虑使用SSE-C，应计划迁移到支持注释的SSE-S3、SSE-KMS或DSSE-KMS。

分离读取、写入和删除权限

受控上下文不应被所有能读取它的用户写入。S3为注释的读写操作暴露了不同的IAM操作，因此富化流程可以写入上下文，而消费者只能读取。以下基于身份的策略允许富化角色在受控存储桶上写入和读取注释。对于使用SSE-KMS的存储桶，注释使用对象的KMS密钥，因此富化和消费者角色也需要kms:Decrypt权限，富化角色还需要kms:GenerateDataKey权限。

code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnrichmentRoleMayWriteAnnotations",
      "Effect": "Allow",
      "Action": ["s3:PutObjectAnnotation", "s3:GetObjectAnnotation", "s3:GetObjectVersionAnnotation"],
      "Resource": "arn:aws:s3:::amzn-s3-demo-governance/*"
    }
  ]
}

消费者角色只能读取相同上下文。

code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ConsumerRoleReadsAnnotations",
      "Effect": "Allow",
      "Action": ["s3:GetObjectAnnotation", "s3:GetObjectVersionAnnotation","s3:ListObjectAnnotations"],
      "Resource": "arn:aws:s3:::amzn-s3-demo-governance/*"
    }
  ]
}

将破坏性操作分离。仅将s3:DeleteObjectAnnotation权限授予专用的管理角色，而不是富化或消费者角色，这样常规流程无法永久删除治理上下文。为了纵深防御，如以下语句所示，在富化和消费者角色策略中添加对s3:DeleteObjectAnnotation的显式拒绝。

code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAnnotationDeletion",
      "Effect": "Deny",
      "Action": "s3:DeleteObjectAnnotation",
      "Resource": "arn:aws:s3:::amzn-s3-demo-governance/*"
    }
  ]
}

显式拒绝会覆盖通过其他策略可能到达角色的任何允许，因此即使未来权限变更，这些角色也无法删除注释。拒绝仅覆盖删除操作。富化角色仍可通过PutObjectAnnotation覆盖治理上下文，因此依赖前面描述的审计追踪来检测意外更改。

复制有其独立的控制机制。为了将分类和驻留标签附加到跨区域复制，需在源对象上授予s3:GetObjectVersionAnnotationForReplication权限，在目标对象上授予s3:ReplicateObjectAnnotation权限。

code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSourceAnnotationsForReplication",
      "Effect": "Allow",
      "Action": "s3:GetObjectVersionAnnotationForReplication",
      "Resource": "arn:aws:s3:::amzn-s3-demo-governance/*"
    },
    {
      "Sid": "ReplicateAnnotationsToDestination",
      "Effect": "Allow",
      "Action": "s3:ReplicateObjectAnnotation",
      "Resource": "arn:aws:s3:::amzn-s3-demo-governance-dr/*"
    }
  ]
}

注解的复制过程独立于对象本身，并在对象复制完成后进行，因此应将复制的注解视为最终一致性。对象可能显示复制已完成的状态，而其注解仍在传输中。可以通过注解表中每个注解的 replication_status 列来验证注解复制状态。如果需要在保留源区域注解的同时复制对象，请在复制角色策略中拒绝 s3:ReplicateObjectAnnotation 权限。对象复制将继续进行，仅阻止注解复制。

生成的标签是建议，而非决定

当应用程序或代理生成分类时，心智模型的第二个后果会从脚注转变为控制因素。S3 会存储您写入的任何标签，而不会检查其是否正确。如果生成的 PII 标志或保留状态触发了自动过期或删除操作，错误的标签将导致错误的删除。

在创作上下文与执行操作之间保持验证边界。使用生成的注解进行信息告知和优先级排序，并在任何标签驱动不可逆生命周期操作前要求验证步骤。该步骤可以是自动化策略检查或人工审核。

先前有效载荷中的 review_required 字段编码了这一边界。该字段初始值为 true，仅在验证后设置为 false，因此下游自动化依赖的是已审核的标签而非原始预测。generated_by 和 generated_at 字段可为您提供审计追踪，用于追溯在后续决策被质疑时标签的生成过程。

将富化代理视为提议者，而非审批者。对于可逆或影响较小的操作，审批步骤可以是自动化规则检查。对于不可逆或影响较大的操作（如删除、保留期过期或跨境传输），无论模型的置信度如何，都必须要求明确的人工审批。

注解并非总适用的场景

注解适用于特定场景：与对象一同传输的较大、结构化且可变的上下文。S3 提供了其他将信息附加到对象的方式，这些方式并非互换。

对象标签仅限于10个小型键值对，但它们可以与 IAM 策略条件、S3 生命周期规则和成本分配集成。用户自定义元数据在上传时固定，无法更改而不复制对象。外部数据源可提供丰富的专用查询，但会增加系统操作复杂性，并将上下文与所描述的数据分离。

通过 S3 元数据实时库存表，标签和用户自定义元数据也可在大规模查询中使用，因此查询能力并非注解的独特之处。真正独特的是其更大、更丰富、可变的有效载荷。注解在以下三种情况下并非合适工具：

您的访问模式为关系型或需要大量连接操作。
您需要基于值本身进行策略条件或生命周期过滤。
您对同一对象有极高的写入频率。

另一个设计约束影响了注解的实现。由于注解是在对象创建后写入，因此在上传和富化之间存在一个短暂窗口，此时对象不携带治理上下文。如果您的控制机制无法容忍这一间隔，上下文可通过用户自定义元数据或预注册步骤随上传本身一同到达。下表总结了对比情况。

设计决策

S3 注解

对象标签

用户自定义元数据

外部数据源

每个对象版本最大值

1,000

10

上传时固定设置

不适用

最大尺寸

512字节名称 + 1 MB有效载荷

128字符键 + 256字符值

总计最多2 KB

实际上无限制

数据格式

任意UTF-8文本（JSON、XML、YAML、纯文本）

键值字符串

任意

写入后可修改

是

否（需要对象复制）

上传时设置

否（仅上传后）

IAM条件/生命周期过滤

无

大规模查询

S3元数据注释表

S3元数据实时清单表

丰富/关系型

生产指导

设计需要完成三个操作要点：

通过分离写入注释的富化角色与读取注释的消费者角色，实施最小权限原则，并显式控制注释复制。

遵循注释命名规则。名称长度为1-512字节，仅限字母、数字、下划线、句点和连字符，且不能以保留的aws或s3前缀开头。

对有效载荷模式进行版本控制，使消费者能够随其演进，并使用Base64对任何二进制内容进行编码，因为有效载荷必须是有效的UTF-8。

在比较成本时，需考虑每个组件：

注释有效载荷消耗的存储空间。

PutObjectAnnotation操作和读取操作的请求费用。

如果启用了S3元数据注释表，该表的存储和请求成本，以及通过Athena查询时的扫描费用。

有两个要点需要特别强调。无论父对象的存储类别如何，注释存储始终按S3标准费率计费，因此S3 Glacier Deep Archive对象上的注释仍需支付标准存储费用。当对象被复制或复制时，每个注释也会被复制并计为独立的PUT操作。因此，携带大量注释的对象在进行批量复制和复制时，请求成本与注释数量成正比。

将总成本与运行和查询独立元数据数据源的成本进行权衡，并与通过保留对象上下文避免的对象读取成本进行比较。请在S3定价页面（参见管理与洞察下的注释）以及S3元数据和Athena定价页面上确认当前定价。

结论

通过S3注释，您可以将治理上下文与所描述的数据保持一致：附加到对象上、原地可修改、在复制和复制过程中传递，并通过S3元数据注释表使用SQL进行查询。

正确实现这一点取决于少数行为：版本范围删除、对象锁定序列、跨多部分复制的注释保留、不可逆注释删除、SSE-C约束、IAM作用域以及生成标签周围的信任边界。心智模型认为注释是调用者创建的、绑定到对象版本的上下文，S3存储并移动这些注释但不进行解释。有了这个模型，您可以在构建之前对每个行为进行推理。

要开始使用，请将本文档中的治理注释模式适配到您自己的分类和保留模型，并应用此处描述的IAM分离和生命周期处理。每个有效载荷、策略语句和AWS CLI调用都是内联的，因此您可以直接复制到自己的环境中。

关于作者

'"` /think