CloudFront Signed URLs, Signed Cookies, OAI, and OAC – SAP-C02 Study Guide

Purpose of This Lesson

Amazon CloudFront can restrict access to private content in two complementary ways:

• Viewer authorization: Signed URLs and signed cookies control which clients may request content through CloudFront.
• Origin protection: Origin Access Control (OAC) prevents users from bypassing CloudFront and accessing an S3 origin directly.

These mechanisms solve different problems and are often used together. For example, an application can authenticate a user, issue a short-lived signed URL, and use OAC to ensure the requested S3 object is retrieved only through the CloudFront distribution.

Key Concepts

CloudFront signed URLs

A signed URL is a CloudFront URL containing a cryptographic signature and policy information. CloudFront validates the signature before serving the requested object.

A signed URL can include controls such as:

• An expiration date and time
• An optional start date and time
• An optional allowed client IP address or range
• The specific resource being requested

A common workflow is:

1. A client authenticates with an application or API.
2. The application authorizes access to a private object.
3. The application generates a signed CloudFront URL.
4. The client uses that URL to retrieve the object from CloudFront.
5. CloudFront validates the URL and serves the content if the policy is satisfied.

Signed URLs are generally appropriate when:

• Access is needed for an individual file or a small number of specific files.
• The client does not support cookies reliably.
• The application needs a URL that can be passed to another system or client.
• Access should expire after a defined period.

CloudFront signed URLs require a trusted signer configuration, such as a CloudFront key group containing a public key. The application that creates the URL must securely hold the corresponding private key or use a controlled signing service.

CloudFront signed cookies

Signed cookies use the same general authorization model but place the access policy in cookies rather than modifying the object URL.

They are usually a better choice when:

• A user needs access to multiple restricted files.
• Existing URLs should remain unchanged.
• The application is serving a private collection of content, such as a subscription area or web application assets.

A signed cookie can authorize access to a path or group of resources, whereas a signed URL is commonly used for a particular object.

Origin Access Identity

Origin Access Identity, or OAI, is the older CloudFront mechanism for restricting access to private S3 content. An S3 bucket policy grants access to the CloudFront OAI, and users are expected to retrieve objects through CloudFront rather than directly from S3.

With OAI:

• The S3 bucket is protected by a bucket policy.
• The policy identifies the OAI as the allowed principal.
• Direct requests to the S3 bucket are denied unless the caller meets the bucket policy.
• CloudFront can retrieve the object on behalf of the viewer.

OAI is a legacy feature. AWS recommends using OAC for new designs.

Origin Access Control

Origin Access Control, or OAC, is the current recommended method for securing an S3 origin behind CloudFront.

An OAC-based design typically includes:

• An OAC attached to the CloudFront S3 origin
• An S3 bucket policy that allows the cloudfront.amazonaws.com service principal
• A condition restricting access to the ARN of the intended CloudFront distribution
• No public S3 access requirement for normal viewer delivery

The bucket policy conceptually looks like this:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudfront.amazonaws.com"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXAMPLE123"
    }
  }
}

The exact policy may also require account-specific conditions or additional actions depending on the design. The important exam concept is that access is granted to the CloudFront service principal and constrained to the expected distribution.

OAC is preferred because it supports more modern use cases than OAI, including authenticated requests to S3 and SSE-KMS-encrypted objects. It can also support request methods beyond simple reads when the architecture requires them.

OAC and the correct S3 origin type

OAC and OAI are designed for an S3 bucket origin using the S3 API endpoint, not the S3 static website endpoint.

This distinction is important:

• S3 bucket origin: Supports OAC or OAI and private bucket access through CloudFront.
• S3 website endpoint: Behaves like a custom HTTP origin and does not support OAC/OAI in the same way.

If a design requires OAC, configure the CloudFront origin as the S3 bucket origin. Do not select the website endpoint. Website endpoints may be useful for S3 website hosting features, but they cannot provide the same private-origin integration.

Viewer access and origin access are separate controls

Signed URLs and signed cookies control whether a viewer may use CloudFront. OAC controls whether CloudFront may access the S3 origin.

Using only OAC does not automatically make content selectively available to individual viewers. If the distribution is public, anyone who can request an object through CloudFront may receive it unless another viewer authorization mechanism is applied.

Using only signed URLs does not necessarily prevent direct access to the S3 bucket. The bucket must also be private and protected with an appropriate bucket policy.

Exam-Relevant Takeaways

• Use signed URLs for individual files, expiring links, or clients that do not support cookies.
• Use signed cookies when users need access to multiple restricted files without changing URLs.
• Use OAC to protect an S3 origin from direct access and force content delivery through CloudFront.
• OAI is legacy; choose OAC for new architectures unless a question explicitly requires an existing OAI configuration.
• OAC policies use the CloudFront service principal, commonly constrained with AWS:SourceArn to a specific distribution.
• OAC and OAI apply to S3 bucket origins, not arbitrary origins such as an EC2 web server or an Application Load Balancer.
• Do not confuse an S3 bucket origin with an S3 website endpoint. OAC requires the bucket origin/API endpoint.
• Signed URLs and signed cookies require a trusted signing configuration and secure private-key management.
• A private S3 bucket alone does not provide viewer-level, time-limited authorization through CloudFront; combine bucket protection with signed URLs or cookies when needed.

Architecture Decision Guide

Requirement	Recommended mechanism	Reason
Grant temporary access to one object	CloudFront signed URL	Precise, shareable, time-limited access
Grant access to many files while retaining normal URLs	CloudFront signed cookies	Policy is carried in cookies rather than every URL
Prevent direct access to an S3 bucket	CloudFront OAC	Bucket policy allows CloudFront rather than public users
Configure a new private S3 origin	OAC	Current recommended origin-protection mechanism
Maintain an older deployment already using OAI	OAI, or migrate to OAC	OAI is legacy but may remain during migration
Protect an EC2 or load balancer origin from direct access	Use origin-specific controls, not OAI/OAC	OAI/OAC are for S3 origins
Use S3 website-hosting behavior with CloudFront	S3 website endpoint as a custom origin	OAC cannot secure the website endpoint as an S3 bucket origin
Serve SSE-KMS-encrypted S3 objects through CloudFront	OAC plus suitable KMS and bucket policies	OAC supports the modern authenticated S3 access pattern

Common Exam Traps

• Choosing OAI for a new design: OAI is deprecated/legacy. OAC is the preferred answer for new S3 origin protection.
• Assuming OAC works with an S3 website endpoint: It does not provide the same integration there. Use an S3 bucket origin for OAC.
• Treating signed URLs as origin protection: A signed URL authorizes a viewer request to CloudFront; it does not replace an S3 bucket policy.
• Using signed URLs for a large set of files: Signed cookies are usually more appropriate when many resources must be accessed without changing URLs.
• Assuming OAC applies to any origin: OAC is an S3 origin-access feature, not a generic control for EC2, ALB, or arbitrary HTTP origins.
• Making the S3 bucket public: A public bucket defeats the goal of forcing access through CloudFront. Block public access unless a deliberate exception is required.
• Ignoring key security: The private key used to sign URLs or cookies must not be embedded in a client application or exposed to end users.
• Confusing CloudFront authorization with application authentication: A signed URL proves that a trusted signer authorized a request under the URL policy; it does not replace the application’s login and authorization system.

Real-World Engineer Notes

• Keep signed URL and cookie lifetimes as short as practical. Longer expiration increases the impact of a leaked URL or cookie.
• Avoid relying on client IP restrictions for mobile users unless necessary. Mobile networks, proxies, and carrier NAT can cause the apparent source IP to change.
• Store signing keys in a controlled secrets or key-management workflow. Limit who can generate signatures and monitor signing activity.
• Use CloudFront cache policies and origin request policies independently from access controls. A private object can still be cached by CloudFront after an authorized request, provided the distribution is configured correctly.
• When migrating from OAI to OAC, update the CloudFront origin configuration and bucket policy carefully. Validate access through CloudFront and confirm that direct S3 access remains blocked.
• If using SSE-KMS, verify both the S3 bucket policy and the KMS key policy. S3 authorization alone may not be sufficient for CloudFront to retrieve encrypted objects.
• Restrict the S3 bucket policy to the intended distribution where possible. This reduces the chance that another CloudFront distribution in the account or organization can access the bucket unintentionally.

Quick Reference Summary

• Signed URL: Temporary authorization for a specific CloudFront resource; useful for individual files and clients without cookie support.
• Signed cookie: Temporary authorization for multiple resources while preserving normal URLs.
• OAI: Legacy CloudFront identity used to access private S3 origins.
• OAC: Recommended modern control for private S3 origins; uses the CloudFront service principal and a bucket policy.
• S3 website endpoint: Not the correct origin type for OAC/OAI-based private bucket access.
• Defense in depth: Use OAC to protect the origin and signed URLs or cookies to control viewer access.

Flashcards

1. Q: What problem do CloudFront signed URLs solve?

A: They provide time- and policy-limited authorization to access specific CloudFront resources.

1. Q: When are signed cookies preferable to signed URLs?

A: When a user needs access to multiple restricted files and the URLs should remain unchanged.

1. Q: What is the recommended replacement for CloudFront OAI?

A: Origin Access Control, or OAC.

1. Q: What principal commonly appears in an OAC S3 bucket policy?

A: The CloudFront service principal, cloudfront.amazonaws.com.

1. Q: How can an OAC bucket policy restrict access to one distribution?

A: By using a condition such as AWS:SourceArn matching the distribution ARN.

1. Q: Does OAC protect an S3 website endpoint?

A: No. OAC is used with an S3 bucket origin, not the S3 website endpoint.

1. Q: Does a signed URL prevent direct access to S3?

A: No. Origin protection requires a private bucket and an appropriate bucket policy, typically with OAC.

1. Q: Can OAI be used for an Application Load Balancer origin?

A: No. OAI and OAC are intended for S3 origin access control.

1. Q: What should happen if a signed URL is past its expiration time?

A: CloudFront should reject the request according to the URL policy.

1. Q: What is the security risk of exposing a CloudFront signing private key?

A: An unauthorized party could generate valid signed URLs or cookies.

Practice Questions

Question 1

A company stores premium video files in Amazon S3. Customers authenticate to a web application and should receive access to individual videos for 15 minutes. The S3 bucket must not be publicly accessible. Which design best meets these requirements?

Correct answer: Use CloudFront signed URLs with an OAC-protected private S3 bucket.

Explanation: Signed URLs provide per-object, time-limited viewer authorization. OAC and the S3 bucket policy prevent users from bypassing CloudFront and reading the bucket directly.

Question 2

A web application provides authenticated users with access to hundreds of private images. The URLs are already embedded throughout the application and should not be changed. Which CloudFront feature is most appropriate for viewer authorization?

Correct answer: CloudFront signed cookies.

Explanation: Signed cookies can authorize access to multiple restricted objects while leaving the existing URLs unchanged. Generating and distributing a signed URL for every image would be less suitable.

Question 3

An architect is creating a new CloudFront distribution for a private S3 bucket. The proposed configuration uses an OAI and an S3 static website endpoint. Which change should be recommended?

Correct answer: Use an S3 bucket origin with OAC and update the bucket policy for the CloudFront service principal.

Explanation: OAC is the recommended modern mechanism, and it requires the S3 bucket origin rather than the S3 website endpoint. The website endpoint is treated as a custom HTTP origin and does not support the same private S3 integration.

Question 4

A CloudFront distribution uses OAC, but users can still retrieve objects directly with S3 URLs. Which action is most likely required?

Correct answer: Remove public access and update the S3 bucket policy so that object reads are allowed through the CloudFront service principal and restricted to the distribution.

Explanation: OAC does not automatically revoke public S3 permissions. Direct access remains possible if the bucket policy, object ACLs, or other permissions allow it. The origin must be private and explicitly trust CloudFront.

Question 5

A mobile application cannot reliably store or send cookies. It authenticates users through an API and then needs to grant access to one private file for a short period. Which option is most appropriate?

Correct answer: Have the authorized backend generate a short-lived CloudFront signed URL.

Explanation: Signed URLs are designed for individual resources and clients that do not support cookies well. The signing operation should occur in a trusted backend rather than in the mobile application.