从S3快照创建Elasticache集群失败，请求排查原因

1. 未配置ElastiCache访问S3的专属IAM服务角色 #

ElastiCache从S3恢复快照时，必须通过绑定了S3权限的IAM服务角色完成授权，仅配置S3桶策略无法让服务直接获取访问权限。

修正步骤： #

• 创建信任ElastiCache服务的IAM角色：

resource "aws_iam_role" "elasticache_s3_access" {
  name = "elasticache-s3-access-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "elasticache.amazonaws.com"
        }
      }
    ]
  })
}

• 给该角色附加S3访问权限：

resource "aws_iam_role_policy" "elasticache_s3_permissions" {
  name = "elasticache-s3-permissions"
  role = aws_iam_role.elasticache_s3_access.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "s3:GetObject",
          "s3:ListBucket"
        ]
        Effect = "Allow"
        Resource = [
          module.bucket.arn,
          "${module.bucket.arn}/*"
        ]
      }
    ]
  })
}

• 创建ElastiCache集群（或执行快照恢复）时，通过replication_group资源的s3_role_arn参数指定上述角色的ARN。

2. S3桶策略的Principal配置不准确 #

你当前使用的CanonicalUser ID可能并非ElastiCache所属账户的有效身份：

• 若ElastiCache与S3在同一账户，建议直接用ElastiCache服务角色ARN作为Principal，而非根账户Canonical ID；
• 若为跨账户场景，需确认CanonicalUser ID是ElastiCache所在账户的根用户Canonical ID，或改用账户ARN（arn:aws:iam::目标账户ID:root）作为Principal。

跨账户场景修正后的桶策略Principal示例：

data "aws_iam_policy_document" "allow_access_from_another_account" {
  statement {
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::123456789012:root"] # 替换为ElastiCache所在账户ID
    }

    actions = [
      "s3:GetObject",
      "s3:GetBucketAcl",
      "s3:ListBucket"
    ]

    resources = [
      module.bucket.arn,
      "${module.bucket.arn}/*",
    ]
  }
}

3. S3对象（dump.rdb）的ACL未授权 #

即使桶策略允许访问，若dump.rdb对象的ACL未给对应主体授予读取权限，仍会失败：

• 检查对象ACL，确保已给ElastiCache服务角色或目标账户配置读取权限；
• 若快照为跨账户上传，需确认对象所有权已转移给S3桶所有者（你已开启BucketOwnerPreferred，需确保上传时遵循该规则）。

内容的提问来源于stack exchange，提问作者blackstorm