CloudFront Signed URLs, Signed Cookies, OAI, and OAC

Purpose of This Lesson

This lesson explains how CloudFront controls access to content and how to prevent users from bypassing CloudFront to access an Amazon S3 origin directly. It focuses on choosing between signed URLs and signed cookies for viewer access, and between the legacy Origin Access Identity (OAI) and the recommended Origin Access Control (OAC) for CloudFront-to-S3 access.

Key Concepts

Signed URLs

A CloudFront signed URL is a URL containing authorization information that controls whether a client may access a particular object. The policy can specify:

• When access begins
• When access expires
• Which IP address or IP range may use the URL

A common workflow is:

1. A client authenticates with a serverless application.
2. The application generates or returns a signed URL.
3. The client uses the signed URL to request the protected object through CloudFront.

Signed URLs are best suited to individual files and clients that do not support cookies.

Signed Cookies

Signed cookies provide a similar access-control mechanism without changing the URLs. They are useful when:

• The URLs should remain unchanged
• The user needs access to multiple restricted files

The key distinction is that signed URLs are intended for individual files, while signed cookies can support access to multiple restricted files.

Origin Access Identity (OAI)

An Origin Access Identity is a special CloudFront identity that can be granted permission to retrieve objects from an Amazon S3 bucket. The bucket policy allows the OAI to get objects and blocks direct access by other users.

With this arrangement:

• Users request content through CloudFront.
• CloudFront uses the OAI to retrieve the object from S3.
• Direct requests to the bucket are denied by the bucket policy.

OAI is considered a legacy feature and has been replaced by Origin Access Control. However, OAI may still appear in operational environments, documentation, or assessment scenarios.

Origin Access Control (OAC)

Origin Access Control is the recommended replacement for OAI and supports additional use cases. The S3 bucket policy allows the CloudFront service principal to access objects, typically with a condition tying the request to the relevant CloudFront distribution or OAC source ARN.

The lecture identifies OAC as the recommended choice when:

• CloudFront must connect to Amazon S3 buckets in all regions
• S3 server-side encryption uses AWS KMS keys
• CloudFront needs dynamic S3 requests such as PUT and DELETE

OAC requires an S3 bucket policy that grants access to the CloudFront service principal.

CloudFront Viewer Access and S3 Origin Access

These controls protect different sides of the request path:

• Signed URLs and signed cookies control whether a viewer is authorized to request protected CloudFront content.
• OAI and OAC control whether CloudFront is authorized to retrieve content from an S3 origin.

Using CloudFront as the required access path allows the distribution’s features and security controls to be applied consistently. The S3 bucket policy should prevent unauthorized direct access rather than relying only on users choosing to use the CloudFront URL.

A simplified request flow is:

Client -> CloudFront distribution -> authorized S3 origin access -> object

For signed URLs, an application may authenticate the client before issuing the URL:

Client -> authentication application -> signed URL -> CloudFront object request

Exam- or Assessment-Relevant Takeaways

• Choose a signed URL for access to an individual file, especially when the client does not support cookies.
• Choose signed cookies when URLs must remain unchanged or when one client needs access to multiple restricted files.
• Recognize OAI as legacy and OAC as its replacement.
• Use OAC for the stated modern requirements: all-region S3 access, S3 server-side encryption with AWS KMS keys, or dynamic PUT and DELETE requests to S3.
• OAI and OAC protect the origin from direct access; they are not substitutes for viewer authorization with signed URLs or cookies.
• An OAI-based bucket policy grants the OAI permission to retrieve objects.
• An OAC-based bucket policy grants the CloudFront service principal access and can use a source ARN condition to restrict the request.
• If a scenario says users must access S3 content only through CloudFront, look for an origin access feature and a restrictive S3 bucket policy.

Tool / Feature Decision Guide

Requirement	Preferred feature	Reason
Restrict access to one file	Signed URL	Authorization is attached to the URL for the specific object request.
Client cannot support cookies	Signed URL	The client can use the authorization embedded in the URL.
Keep URLs unchanged	Signed cookies	Authorization is delivered through cookies instead of modifying URLs.
Restrict access to multiple files	Signed cookies	One cookie-based authorization mechanism can support multiple restricted objects.
Existing legacy CloudFront-to-S3 access setup	OAI may be encountered	OAI is still referenced and may exist, but it is legacy.
Modern CloudFront-to-S3 origin access	OAC	OAC replaces OAI and supports additional use cases.
S3 with AWS KMS server-side encryption	OAC	This is one of the lecture’s stated OAC use cases.
Dynamic S3 PUT or DELETE requests	OAC	OAC supports the stated dynamic request scenario.
Prevent direct S3 access	OAI or OAC plus a bucket policy	The policy grants CloudFront-origin access and denies unauthorized direct access.

Common Traps / Misconceptions

• Confusing signed URLs with origin access controls: Signed URLs authorize viewers; OAI and OAC authorize CloudFront to access the origin.
• Assuming signed URLs are the best choice for many files: The lecture distinguishes signed URLs for individual files from signed cookies for multiple restricted files.
• Treating OAI and OAC as equally current: OAI is legacy. OAC is the replacement and should be preferred for supported modern designs.
• Forgetting the bucket policy: Creating an OAI or OAC alone is not enough. The S3 bucket policy must grant the appropriate identity or CloudFront service principal access.
• Allowing direct bucket access accidentally: If the policy does not restrict access appropriately, users may bypass CloudFront and lose the intended distribution-level controls.
• Using signed cookies merely because content is private: The decision depends on URL stability, client cookie support, and whether access covers one file or multiple files.
• Confusing viewer IP restrictions with origin restrictions: An IP condition in a signed URL limits who can use that URL; it does not replace the S3 bucket policy that controls origin access.

Real-World Engineer / Analyst Notes

• Treat viewer authorization and origin authorization as separate design decisions. A private-content architecture may need both a signed URL or cookie and OAC.
• When reviewing an existing environment, identify whether the distribution uses OAI or OAC before changing the S3 bucket policy. OAI configurations may still be active even though OAC is the modern choice.
• Check the complete request path during troubleshooting: client authentication, signed URL or cookie validity, CloudFront distribution behavior, origin authorization, and S3 bucket policy.
• For signed URLs, verify the start time, expiration time, and any IP restriction when diagnosing an access failure.
• For OAC-related issues, inspect whether the bucket policy references the CloudFront service principal and contains the expected source ARN condition.
• Restricting direct S3 access ensures requests use CloudFront, where the distribution’s security and delivery features can be applied.

Quick Reference Summary

• Signed URL: Individual file, client without cookie support, optional time and IP restrictions.
• Signed cookie: Multiple restricted files or unchanged URLs.
• OAI: Legacy CloudFront identity for S3 origin access.
• OAC: Recommended OAI replacement; supports all-region S3 access, AWS KMS encryption scenarios, and dynamic S3 PUT/DELETE requests.
• S3 bucket policy: Required to authorize the selected origin access mechanism and block unauthorized direct access.
• Separation of concerns: Signed URLs/cookies secure viewer access; OAI/OAC secure CloudFront-to-S3 access.

Flashcards

Q: A mobile client authenticates with an application and needs temporary access to one protected object. Which CloudFront feature is the best fit?

A: Use a signed URL. It can encode the access period and optionally restrict use by IP address, and it works for clients that do not support cookies.

Q: When should signed cookies be preferred over signed URLs?

A: Prefer signed cookies when URLs must remain unchanged or when the client needs access to multiple restricted files.

Q: What is the key scope difference between a signed URL and a signed cookie in this lesson?

A: A signed URL is intended for an individual file, while signed cookies are useful for access to multiple restricted files without changing their URLs.

Q: A client cannot store or use cookies but must download a protected file through CloudFront. What should you choose?

A: Choose a signed URL because the authorization travels in the URL rather than through cookies.

Q: What controls the authorization period in a signed URL?

A: The signed URL can specify a beginning time and an expiration time. It may also restrict use to specified IP addresses or ranges.

Q: What problem does an OAI or OAC solve in a CloudFront-to-S3 design?

A: It allows CloudFront to retrieve objects from S3 while the bucket policy blocks unauthorized direct access to the bucket.

Q: Which origin access feature is legacy, and what replaced it?

A: Origin Access Identity (OAI) is legacy and was replaced by Origin Access Control (OAC).

Q: A distribution must use S3 server-side encryption with AWS KMS keys. Which origin access feature should be selected according to the lesson?

A: Use OAC. S3 server-side encryption with AWS KMS keys is one of the stated OAC use cases.

Q: A CloudFront distribution needs dynamic PUT and DELETE requests to Amazon S3. Which feature is the appropriate choice?

A: Use OAC because dynamic S3 requests such as PUT and DELETE are identified as OAC use cases.

Q: What principal does an OAC-based S3 bucket policy allow?

A: It allows the CloudFront service principal, typically with a condition such as a source ARN restriction tying access to the relevant CloudFront resource.

Q: What is the purpose of the S3 bucket policy in an OAI configuration?

A: It grants the OAI permission to retrieve objects and prevents other users from directly retrieving the protected content from the bucket.

Q: A user requests an S3 object directly instead of through CloudFront and receives an access failure. What configuration goal does this demonstrate?

A: The bucket policy is enforcing CloudFront-only access by allowing the configured OAI or OAC path rather than unauthorized direct bucket access.

Q: Do signed URLs replace OAC when protecting private S3 content?

A: No. Signed URLs authorize viewers, while OAC authorizes CloudFront to access the S3 origin. They address different sides of the request.

Q: What should you inspect first when a signed URL request fails unexpectedly?

A: Check whether the URL is within its permitted start and expiration times and whether the requesting IP matches any configured IP restriction.

Practice Questions

Question 1

A web application authenticates a user and grants access to one private PDF for the next 15 minutes. Some clients do not support cookies. Which solution best matches the requirement?

A. Signed cookies
B. Signed URL
C. OAI only
D. OAC only

Correct answer: B. Signed URL. The requirement is temporary access to an individual file, and the clients may not support cookies. OAI and OAC control CloudFront’s access to the origin, not the viewer’s authorization.

Question 2

A customer wants users to access several private files while keeping the existing file URLs unchanged. Which CloudFront viewer-access feature should be selected?

A. Signed URL for every file
B. Signed cookies
C. OAI
D. S3 bucket website access

Correct answer: B. Signed cookies. Signed cookies are suited to multiple restricted files and avoid changing the URLs.

Question 3

An organization is designing a new CloudFront-to-S3 integration. The S3 objects use server-side encryption with AWS KMS keys. Which origin access option is the recommended choice from the lesson?

A. OAI
B. OAC
C. Signed URL
D. Signed cookie

Correct answer: B. OAC. OAC is the recommended OAI replacement and is specifically identified for S3 server-side encryption with AWS KMS keys.

Question 4

Users should be able to retrieve content only through CloudFront. Direct requests to the S3 bucket must fail. Which configuration is required?

A. Make the S3 bucket public and add signed URLs to CloudFront
B. Configure OAI or OAC and a restrictive S3 bucket policy
C. Configure signed cookies without changing the S3 policy
D. Use an IP restriction in the signed URL as the only control

Correct answer: B. Configure OAI or OAC and a restrictive S3 bucket policy. The origin access mechanism authorizes CloudFront, while the bucket policy prevents unauthorized direct S3 access.

Question 5

A team finds an existing distribution that uses OAI and is planning a modernization. Which statement best reflects the lesson?

A. OAI is the current replacement for OAC
B. OAI and OAC are viewer authorization mechanisms
C. OAI is legacy; OAC is the replacement and supports additional use cases
D. OAI should always be removed before any CloudFront request can work

Correct answer: C. OAI is legacy; OAC is the replacement and supports additional use cases. OAI may still be encountered, but OAC is the recommended modern origin access feature.

WordPress Metadata

Suggested Slug:
cloudfront-signed-urls-oai-oac

Meta Description:
Study how CloudFront signed URLs, signed cookies, Origin Access Identity, and Origin Access Control restrict content access and when to choose each option.

Tags:
AWS CloudFront, signed URLs, signed cookies, Origin Access Identity, Origin Access Control, Amazon S3, bucket policies, AWS KMS, CloudOps Engineer