Understanding OAI and OAC in AWS CloudFront: Concepts, Configuration, and Best Practices

Amazon CloudFront is a highly secure and scalable content delivery network (CDN) that improves the distribution of content to users with low latency and high transfer speeds. CloudFront offers two key features to enhance security when serving content from Amazon S3 buckets: Origin Access Identity (OAI) and Origin Access Control (OAC). In this blog, we’ll explore these features, their purpose, and how to configure them using Terraform. We’ll also discuss their advantages and disadvantages to help you decide which is suitable for your use case.

Target Audience

This blog is intended for cloud architects, DevOps engineers, and developers who are familiar with AWS and want to improve their understanding of secure content delivery using CloudFront and S3.

What is OAI in AWS CloudFront?

What is OAI?

Origin Access Identity (OAI) is a special CloudFront user identity that ensures CloudFront can fetch objects securely from an S3 bucket without exposing them to the public.

What is OAC?

Origin Access Control (OAC) is an advanced feature providing fine-grained control over access permissions between CloudFront and S3. It builds on the benefits of OAI while offering additional flexibility and management improvements.

Terraform Configuration Examples

Configuring OAI in Terraform

Here’s how you can configure an OAI to secure your S3 bucket:

1. Define the S3 Bucket

resource "aws_s3_bucket" "example" {

  bucket = "example-bucket"

}


Here, we define an Amazon S3 bucket using Terraform. The bucket is named example-bucket. This will be the origin for our CloudFront distribution.

you can check AWS Services For your solutions.

2. Create an OAI

resource "aws_cloudfront_origin_access_identity" "example" {

  comment = "Access identity for CloudFront"

}

  This block creates an Origin Access Identity (OAI) for CloudFront. The OAI acts as a virtual user that CloudFront uses to securely access the S3 bucket.

  • Why OAI? Without an OAI, your S3 bucket would need to allow public access for CloudFront to fetch objects. By using an OAI, you can block public access to your bucket while allowing CloudFront to serve content.

3. Attach a Bucket Policy to Allow OAI Access

resource "aws_s3_bucket_policy" "example" {

  bucket = aws_s3_bucket.example.id




  policy = jsonencode({

    Version = "2012-10-17",

    Statement = [

      {

        Effect    = "Allow",

        Principal = {

          AWS = aws_cloudfront_origin_access_identity.example.iam_arn

        }

        Action    = "s3:GetObject"

        Resource  = "${aws_s3_bucket.example.arn}/*"

      }

    ]

  })

}

  This step is critical for securing the S3 bucket.

  • Bucket Policy: The policy grants the OAI permission to read objects (s3:GetObject) from the bucket.
  • Principal: Specifies the OAI as the entity allowed to access the bucket.
  • Resource: Applies the permission to all objects (*) within the S3 bucket.

4. Configure CloudFront Distribution

resource "aws_cloudfront_distribution" "example" {

  origin {

    domain_name = aws_s3_bucket.example.bucket_domain_name

    origin_id   = "S3-example"




    s3_origin_config {

      origin_access_identity = aws_cloudfront_origin_access_identity.example.cloudfront_access_identity_path

    }

  }




  enabled             = true

  default_cache_behavior {

    ...

  }

}

  This block sets up the CloudFront distribution.

  • Domain Name: Specifies the S3 bucket’s domain name as the origin for the CloudFront distribution.
  • Origin Access Identity: Links the OAI to the CloudFront distribution, ensuring only CloudFront can fetch content from the bucket.

How Does It Work?

  • Content Security: With this setup, your S3 bucket content is not publicly accessible. Only the CloudFront distribution with the configured OAI can access it.
  • User Access: Users access content via CloudFront, and CloudFront fetches the data from the S3 bucket using the OAI.
  • Performance: CloudFront caches the content in edge locations, reducing load on the S3 bucket and improving response times for end users.

[ Also Read: Types of Cloud Computing ]

Configuring OAC in Terraform:- 1. Define the S3 Bucket

resource "aws_s3_bucket" "example" {

  bucket = "example-bucket"

}

This block defines an Amazon S3 bucket where your content will be stored. The bucket is named example-bucket. It will act as the origin for your CloudFront distribution.

2. Create an OAC (Origin Access Control)

resource "aws_cloudfront_origin_access_control" "example" {

  name        = "example-oac"

  description = "Access control for CloudFront"

  origin_access_control_origin_type = "s3"

  signing_behavior                  = "always"

  signing_protocol                  = "sigv4"

}

This step creates an Origin Access Control (OAC).

  • What is OAC? OAC is an advanced method to securely manage permissions between CloudFront and the S3 bucket. Unlike OAI, it provides more flexibility and supports AWS SigV4 (Signature Version 4) for signing requests.
  • Attributes Explained:
  • name: A user-defined name for the OAC.
  • origin_access_control_origin_type: Specifies that the origin is an S3 bucket.
  • signing_behavior: Indicates when CloudFront should sign requests. always ensures all requests are signed.
  • signing_protocol: Specifies the signing protocol (sigv4), which is more secure and modern compared to older signing methods.

3. Attach a Bucket Policy for OAC

resource "aws_s3_bucket_policy" "example" {

  bucket = aws_s3_bucket.example.id




  policy = jsonencode({

    Version = "2012-10-17",

    Statement = [

      {

        Effect    = "Allow",

        Principal = {

          Service = "cloudfront.amazonaws.com"

        }

        Action    = "s3:GetObject"

        Resource  = "${aws_s3_bucket.example.arn}/*"

        Condition = {

          StringEquals = {

            "AWS:SourceArn" = aws_cloudfront_distribution.example.arn

          }

        }

      }

    ]

  })

}

Here, a bucket policy is attached to allow the OAC-enabled CloudFront distribution to access the S3 bucket.

Key Components:

  • Principal: Specifies cloudfront.amazonaws.com as the service allowed to access the bucket.
  • Condition: Adds a condition to restrict access only to the specific CloudFront distribution (AWS: SourceArn).
  • Action: Grants permission for s3:GetObject, allowing CloudFront to fetch objects.

4. Configure CloudFront Distribution with OAC

  resource “aws_cloudfront_distribution” “example” { origin { domain_name = aws_s3_bucket.example.bucket_domain_name origin_id   = “S3-example”   origin_access_control_id = aws_cloudfront_origin_access_control.example.id }   enabled             = true default_cache_behavior { # Additional cache behavior settings here } }   This step configures the CloudFront distribution to use the OAC.

Key Attributes:

  • domain_name: Specifies the S3 bucket’s domain name as the origin.
  • origin_access_control_id: Links the previously created OAC to the CloudFront distribution.  

How Does It Work?

  • Secure Access: The OAC ensures that only the CloudFront distribution can fetch objects from the S3 bucket. Public access to the bucket is blocked.
  • SigV4 Signing: CloudFront uses AWS SigV4 to sign every request to the S3 bucket, enhancing security and ensuring the requests are valid.
  • Fine-Grained Control: The bucket policy ensures that only a specific CloudFront distribution can access the S3 bucket, providing precise control over permissions.

Why Use OAC?

  • Advanced Security: Uses modern SigV4 signing, which is more secure and recommended by AWS.
  • Flexibility: Provides more configuration options compared to OAI, allowing for advanced use cases.
  • Alignment with AWS Standards: OAC is the newer, future-proof solution for securing CloudFront origins.

When to Use OAC Over OAI?

Use OAC if:

  • You need modern signing protocols like SigV4.
  • You require fine-grained access control for your CloudFront distributions.
  • Your project needs alignment with the latest AWS features.
  • Stick with OAI if:
  • Your use case is simple and doesn’t require advanced access control.
  • You want a quicker and easier setup process.

[ Also Read: Cost Optimization in AWS ]

Advantages of OAI and OAC

Advantages of OAI

  1. Ease of Setup: Simpler to configure for basic use cases.
  2. Improved Security: Blocks public access to the S3 bucket.
  3. Cost Efficiency: No additional cost for using OAI.

Advantages of OAC

  1. Advanced Control: Offers enhanced fine-grained access control and supports modern configurations.
  2. Protocol Flexibility: Uses SigV4 protocol for robust signing.
  3. Future Proofing: Aligns with the latest AWS features and updates.

Disadvantages of OAI and OAC

Disadvantages of OAI

  1. Limited Functionality: Doesn’t support all features (e.g., enhanced origin control options).
  2. Management Overhead: May require custom policies for specific configurations.

Disadvantages of OAC

  1. Complexity: Configuration can be more involved compared to OAI.
  2. Newer Technology: This may have a learning curve for those accustomed to OAI.
  3. Potential Cost Implications: Advanced features could lead to additional costs in complex setups.

Conclusion

Both OAI and OAC are powerful tools to enhance the security of your CloudFront and S3 configurations. If you’re looking for simplicity and reliability, OAI might be sufficient. However, if you require fine-grained access control or are working on modern projects, OAC is the better option. By using Terraform, you can automate the configuration of these features, ensuring consistent and secure deployments. Choose the option that best aligns with your project requirements and AWS ecosystem practices. Which feature do you prefer for your project? Share your thoughts in the comments below! 

Author: Dev Kumar Gautam

I'm Dev Kumar Gautam, a DevOps Engineer at Opstree Solutions, where I specialize in cloud infrastructure, automation, and continuous integration/continuous deployment (CI/CD) pipelines. With hands-on experience in tools like AWS, Linux, Jenkins, Docker, Kubernetes, and Terraform, I focus on building scalable and secure systems that enhance software delivery processes.

Leave a Reply