OAI vs OAC in CloudFront: Key Differences and When to Use Each

In AWS CloudFront, OAI (Origin Access Identity) is the older method to securely restrict S3 bucket access to CloudFront, while OAC (Origin Access Control) is the newer, more flexible and recommended approach that supports additional features like signing requests with AWS SigV4. OAC improves security and integration with modern AWS services compared to OAI.

Quick Comparison

This table summarizes the key differences between OAI and OAC in CloudFront.

Feature	OAI (Origin Access Identity)	OAC (Origin Access Control)
Release Era	Older, legacy method	Newer, modern method
Access Method	Uses special CloudFront user identity	Uses AWS SigV4 signed requests
Supported Origins	Only Amazon S3 buckets	Amazon S3 and custom origins
Security	Basic access restriction	Enhanced security with request signing
Setup Complexity	Simpler but limited	Slightly more complex but flexible
Recommended Usage	Legacy workloads	New deployments and best practice

Key Differences

OAI is a CloudFront feature that creates a special identity CloudFront uses to access an S3 bucket privately. You attach this identity to your bucket policy to block public access and allow only CloudFront. It works well but only supports S3 origins and does not sign requests.

OAC is a newer feature that uses AWS Signature Version 4 (SigV4) to sign requests from CloudFront to origins. This means it can securely access both S3 buckets and custom origins like HTTP servers. OAC offers better security by signing requests and supports more origin types, making it more flexible.

While OAI is simpler to set up, it is limited to S3 and lacks advanced security features. OAC requires configuring signing but is the recommended approach for new CloudFront distributions because it aligns with AWS's modern security standards and supports more use cases.

Code Comparison

Here is an example of how to configure CloudFront with an OAI to restrict access to an S3 bucket.

terraform

resource "aws_cloudfront_origin_access_identity" "example_oai" {
  comment = "Example OAI for CloudFront"
}

resource "aws_s3_bucket_policy" "example_policy" {
  bucket = aws_s3_bucket.example_bucket.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect = "Allow",
      Principal = {
        AWS = aws_cloudfront_origin_access_identity.example_oai.iam_arn
      },
      Action = "s3:GetObject",
      Resource = "${aws_s3_bucket.example_bucket.arn}/*"
    }]
  })
}

resource "aws_cloudfront_distribution" "example_distribution" {
  origin {
    domain_name = aws_s3_bucket.example_bucket.bucket_regional_domain_name
    origin_id   = "S3-example"

    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.example_oai.cloudfront_access_identity_path
    }
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    target_origin_id       = "S3-example"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

Output

CloudFront distribution created with OAI restricting S3 bucket access to CloudFront only.

OAC Equivalent

Here is how to configure CloudFront with an OAC to securely access an S3 bucket using signed requests.

terraform

resource "aws_cloudfront_origin_access_control" "example_oac" {
  name             = "example-oac"
  description      = "OAC for CloudFront to access S3 with SigV4"
  origin_type      = "s3"
  signing_behavior = "always"
  signing_protocol = "sigv4"
}

resource "aws_cloudfront_distribution" "example_distribution" {
  origin {
    domain_name = aws_s3_bucket.example_bucket.bucket_regional_domain_name
    origin_id   = "S3-example"

    origin_access_control_id = aws_cloudfront_origin_access_control.example_oac.id
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    target_origin_id       = "S3-example"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

Output

CloudFront distribution created with OAC signing requests to S3 bucket securely.

When to Use Which

Choose OAI if you have existing CloudFront distributions using it and only need simple S3 bucket access control without request signing. It is easier to set up but limited to S3 origins and basic security.

Choose OAC for all new CloudFront distributions. It provides stronger security by signing requests, supports both S3 and custom origins, and aligns with AWS's current best practices. It is the future-proof choice for secure content delivery.

Key Takeaways

OAC is the modern, recommended way to secure CloudFront access to origins using signed requests.

OAI is legacy, simpler but limited to S3 buckets without request signing.

OAC supports more origin types and better security with AWS SigV4.

Use OAI only for legacy workloads; prefer OAC for new deployments.

Configuring OAC requires more setup but offers stronger protection and flexibility.