PAYATHON 2026

BDA 使用 S3 Access Point 为何出现访问拒绝？

技术老齐

结论

这条 AccessDeniedException 既不能直接证明 BDA 不支持 S3 Access Point alias，也不能证明 BDA 无法定位文件。通过 Access Point 单独读取成功，只能说明那次 S3 请求的身份、网络路径和读取权限有效；BDA 调用所需的完整访问链路仍待验证，尤其是输出写入权限。

S3 官方文档说明，在受支持的数据访问操作中，Access Point alias 可以代替 bucket 名。服务接口接收 s3Uri，并不代表它一定支持 alias。所查阅的 BDA 调用文档没有明确承诺该接口支持 Access Point alias，因此目前无法判断它必然支持或完全不支持。S3 Access Point alias 文档

建议先修正调用参数，再在授权范围内用真实 bucket URI 建立基线，之后分别替换输入和输出 URI，排查问题出在哪一侧。

先修正代码中的调用问题

示例片段有几个独立问题：

  • invoke_data_automation_async() 接收关键字参数，不能直接传入一个位置字典。已有请求字典时，应使用 bda.invoke_data_automation_async(**request)。
  • 定义的是 s3_uri，调用时使用的却是 s3_input_uri。
  • 定义的是 DATA_AUTOMATION_PROJECT_ARN，调用时使用的却是 project_arn。
  • 按当前 Boto3 文档，dataAutomationProfileArn 是必填参数，示例没有传入。
  • 项目 ARN、profile ARN 和函数缩进需要补全。

这些问题通常会在本地解释或 SDK 参数检查阶段暴露，不能用来解释服务端已经返回的 AccessDeniedException。实际调用既然收到了该错误，执行的代码应与展示片段有所不同，排查时需要以实际执行版本为准。Boto3 调用参数说明

下面是用于排查的调用骨架。先在 Lambda 环境变量中设置真实有效的 DATA_AUTOMATION_PROJECT_ARN 和 DATA_AUTOMATION_PROFILE_ARN，并确认项目具有可用的 LIVE 配置：

import os
import boto3

AWS_REGION = os.environ["AWS_REGION"]

bda = boto3.client(
    "bedrock-data-automation-runtime",
    region_name=AWS_REGION,
)
sts = boto3.client("sts", region_name=AWS_REGION)


def lambda_handler(event, context):
    print({"callerArn": sts.get_caller_identity()["Arn"]})

    response = bda.invoke_data_automation_async(
        inputConfiguration={
            "s3Uri": "s3://data-bucket/bda-input/file.pdf"
        },
        outputConfiguration={
            "s3Uri": "s3://data-bucket/bda-out/"
        },
        dataAutomationConfiguration={
            "dataAutomationProjectArn": os.environ[
                "DATA_AUTOMATION_PROJECT_ARN"
            ],
            "stage": "LIVE",
        },
        dataAutomationProfileArn=os.environ[
            "DATA_AUTOMATION_PROFILE_ARN"
        ],
    )

    return {"invocationArn": response["invocationArn"]}

示例使用真实 bucket URI 做对照，但仅替换 URI 不一定能成功。如果 bucket policy 强制所有访问都经过 Access Point，直接访问 bucket 也会被拒绝，需要先为测试准备符合现有授权要求的访问路径。

核对实际身份和输入、输出权限

先查看代码打印的 callerArn，确认 Lambda 实际使用的角色。给某个角色配置权限，并不代表 Lambda 已经使用该角色。

信任策略决定谁可以承担角色；权限策略决定承担角色后可以执行哪些操作。向信任关系添加 bedrock、sagemaker 或 s3，不会自动让它们在这次调用中使用 bda-role。该调用也没有通过请求参数指定 roleArn。

接下来分别检查以下访问：

检查位置需要核对的权限或条件
输入对象 bda-input/file.pdfs3:GetObject，以及调用链路所需的 bucket 列举权限
输出前缀 bda-out/s3:PutObject，不能用输入读取成功代替验证
BDA 调用对实际项目和 profile 的调用授权
使用 SSE-KMS 的对象或输出 bucket相应 KMS 权限与 key policy
Access Point 和 bucket两侧策略、显式 Deny、网络条件是否允许该请求

AWS 的 S3 访问配置文档列出了读取所需的 s3:GetObject、s3:ListBucket，以及写入所需的 s3:PutObject；使用 KMS 时还需按读写用途核对密钥权限。Bedrock 的 S3 访问配置说明

现有 Access Point policy 中的 s3:* 不能单独保证访问成功。还要核对底层 bucket policy，以及适用的组织策略、权限边界和 VPC endpoint policy。如果 Access Point 仅允许某个 VPC 内的请求，Lambda 内直接读取成功，也不能证明服务后续访问满足相同的网络条件。S3 Access Point 权限和网络控制说明

分别验证输入和输出 alias

真实 bucket URI 的调用能够完成处理后，保持角色、文件、项目和其他配置不变，依次进行以下对照：

输入 URI输出 URI目的
真实 bucket真实 bucket验证基础调用和处理流程
Access Point alias真实 bucket检查输入 alias 路径
真实 bucketAccess Point alias检查输出 alias 路径
Access Point aliasAccess Point alias验证最终组合

输入 alias URI 保持为：

s3://my-data-bucket-ap-wdfeg-s3alias/bda-input/file.pdf

输出 alias URI 保持为：

s3://my-data-bucket-ap-wdfeg-s3alias/bda-out/

如果仅替换输入后失败，重点检查输入访问；如果仅替换输出后失败，重点检查输出写入。即使真实 bucket 路径成功而 alias 路径失败，也只能先将范围缩小到 Access Point 路径，仍需区分策略、网络限制和服务兼容性。

异步调用返回 invocationArn 后，还应通过 get_data_automation_status() 查看最终处理结果，不能只凭提交成功就判断读写链路全部正常。BDA API 工作流程

仍然失败时如何继续定位

保留完整异常、AWS request ID、Region、实际调用角色以及各组对照结果。如果已启用相关 S3 CloudTrail 数据事件，检查被拒绝请求对应的操作、资源和身份；没有记录时，也不能直接推断 BDA 未访问 S3。

如果基础调用正常，Access Point 下的直接读写也已使用同一 Lambda 身份验证通过，但 BDA 仍只在 alias 路径失败，可以携带这些证据向 AWS Support 确认该接口在目标 Region 对 alias 的支持范围。

在兼容性尚未确认期间，可使用已验证可用的真实 bucket URI，前提是该访问方式符合 bucket policy 和现有授权要求。如果必须保留 Access Point 作为数据入口，也可以评估通过已授权的流程把文件复制到专用处理 bucket，再交给 BDA；这需要另行配置复制、处理和清理权限。

备注：内容仅供参考。