S3 Multipart Upload Lifecycle Auditor

The Incident (What Does the Error Mean?)

Raw error from AWS SDK or CLI:

An error occurred (AccessDenied) when calling the AbortMultipartUpload operation:
  User: arn:aws:iam::123456789012:role/app-upload-role
  is not authorized to perform: s3:AbortMultipartUpload
  on resource: arn:aws:s3:::my-data-bucket/uploads/large-file.tar.gz

S3 multipart upload is a three-phase protocol: Initiate → Upload Parts → Complete or Abort. Most IAM policies are written to authorize the happy path (Initiate + PutObject + CompleteMultipartUpload) and forget the abort leg. When the SDK, a lifecycle rule, or your application logic tries to call AbortMultipartUpload — either on failure or during cleanup — S3 returns a hard 403. The upload is now a zombie: the parts exist, are billed, and cannot be removed by your application.

The Attack Vector / Blast Radius

This is a dual-threat failure: operational and financial.

Operational impact: Any retry logic that calls AbortMultipartUpload before re-initiating will permanently fail. Depending on your SDK's retry behavior, you may see cascading AccessDenied exceptions that surface as application-level upload failures even when the underlying network and data are fine. In high-throughput pipelines (ETL, media ingestion, ML dataset uploads), this silently corrupts your upload queue.

Financial blast radius: Orphaned multipart parts are billed at standard S3 storage rates. AWS does not automatically purge them. A single 5 GB file upload that fails and retries 10 times without abort leaves 50 GB of invisible, unindexed part data. At scale — a data pipeline doing 500 failed uploads/day — this compounds to terabytes within weeks. This is a well-documented AWS cost anomaly that has burned engineering teams on bills exceeding $10K/month before detection.

Privilege escalation angle: If your bucket policy or IAM policy uses a wildcard action (s3:*) as a "fix," you've introduced a far worse problem. An over-permissioned role can now delete objects, modify bucket policies, or exfiltrate data. Do not fix a missing permission with a wildcard.

Prevention in CI/CD

1. Checkov static analysis — catches missing S3 multipart permissions in Terraform and CloudFormation before terraform apply:

checkov -d ./iam --check CKV_AWS_111,CKV_AWS_283

2. OPA/Conftest policy — enforce that any IAM policy granting s3:CreateMultipartUpload must also grant s3:AbortMultipartUpload:

package iam.s3.multipart

deny[msg] {
  action := input.Statement[_].Action[_]
  action == "s3:CreateMultipartUpload"
  not action_present(input.Statement, "s3:AbortMultipartUpload")
  msg := "IAM policy grants s3:CreateMultipartUpload without s3:AbortMultipartUpload. Orphaned parts risk."
}

action_present(statements, target) {
  statements[_].Action[_] == target
}

3. AWS Config Rule — use iam-policy-no-statements-with-admin-access as a baseline and write a custom Config rule to flag upload roles missing the abort action.

4. Lifecycle rule as code — never provision an S3 bucket that accepts multipart uploads without the abort_incomplete_multipart_upload lifecycle rule. Enforce this in your Terraform module's variables.tf with a validation block:

variable "enable_multipart_lifecycle" {
  type    = bool
  default = true
  validation {
    condition     = var.enable_multipart_lifecycle == true
    error_message = "Buckets accepting multipart uploads MUST have abort lifecycle rules enabled."
  }
}