用途：当 AWS 治理以 Glue Data Catalog 和 Lake Formation 为核心而非通用元数据工具时使用此技能，帮助智能体设计目录结构、访问控制、受治共享，以及湖仓工作流中安全的数据集发布与访问。
适用场景：设计 Glue Data Catalog 数据库或表组织；定义 Lake Formation 权限、基于标签的访问或共享边界；审查 S3、Athena、Glue、EMR、Redshift 的受治访问；改进 AWS 原生数据发现的元数据质量；将平台原生治理与受监管数据及发布控制对齐。目录与 Lake Formation 不只是平台管理员配置，也属于交付设计的一部分。
工作流：一、定义受治资产边界，明确哪些数据集、表、区域和消费方需要 AWS 原生治理。二、设计目录结构，确定数据库边界、表命名与归属、元数据质量预期、分区与位置约定。三、定义访问模型，包括主体与角色、适用的基于标签访问、必要的行列限制、跨账户或消费方共享行为。四、使发布行为与治理对齐，要求区分已认证与原始资产、必要时设置显式发布审批或校验门、共享资产具备血缘与归属可见性。五、验证运行行为，检查权限、模式演进、新分区及跨服务访问在真实交付条件下的表现。
常见误区：认为仅靠 IAM 就足够，实际数据集治理常需比服务级 IAM 更细粒度的共享、标签与湖访问模式；认为目录元数据可事后清理，但糟糕的元数据与不清晰的归属会让受治数据难以发现和信任；认为 Lake Formation 只属于平台团队，但生产者仍需围绕它设计发布边界与访问假设。
警示信号：数据库与表归属不清；Lake Formation 权限在发布设计之后才补加；目录元数据无法区分可信与实验性资产；跨账户共享或消费方访问路径无文档；模式与分区变更未针对治理行为进行验证。
验证要点：目录结构与归属经过有意设计；Lake Formation 权限与共享边界明确；元数据质量支持发现与治理；发布与访问行为已对齐；针对模式和访问变更验证了运行行为。
限制：资料未提供具体收费、价格、平台支持范围、实施步骤细节或代码示例，实际使用需以 AWS 官方文档与自身环境为准。