Skip to content

CloudFront Advanced

Links: 101 AWS SAA Index

CloudFront Signed URL/Cookies

  • Use Case: Give access to premium shared content to people all over the world.
  • Signed URL gives access to only one file. One URL per file.
    • If you want to share only one file then prefer Signed URL over Signed Cookies.
  • Signed Cookies give access to multiple files. One signed cookie for many files.

  • For signed cookies you don’t have to change URL.

  • When we create a URL or cookie we need to specify the following:

    • URL expiration
    • IP ranges to access the data from
    • Trusted signers (which AWS accounts can create signed URLs)

  • You create an application which generate the CloudFront signed URL using the SDK and then return it to the user. Now the user can access the content.

If your bucket is not public then CloudFront Signed URL is the only way to distribute cached premium content.
  • S3 pre signed URLs have a limited lifetime, CloudFront Signed URLs can be valid for years.

Pricing (Edge Locations)

  • CloudFront pricing varies depending on the data out per edge location. Pricing is different for different edge locations.
  • We can reduce the edge locations for price reduction.
  • There are different price classes for price reduction. By default its All.
    • All : Includes all regions and offers best performance.
    • 200 : most regions, but excludes the most expensive regions
    • 100 : only the least expensive region.

Routing to different origins

  • In CloudFront we can define multiple origins. We can route to different origins depending on the content type.
    • attachments/Pasted image 20220424115007.jpg
  • When adding additional Cache Behaviours, the default Cache Behaviour is always the last to be processed and is always /*.
  • Sign in page example
    • attachments/Pasted image 20230301092340.jpg

CloudFront Origin Failover

  • You can also set up CloudFront with automatic origin failover for scenarios that require high availability.
  • An origin group may contain two origins: a primary and a secondary.
    • If the primary origin is unavailable or returns specific HTTP response status codes that indicate a failure, CloudFront automatically switches to the secondary origin.
  • CloudFront fails over to the secondary origin only when the HTTP method of the viewer request is GET, HEAD, or OPTIONS.
    • CloudFront DOES NOT failover when the viewer sends a different HTTP method (for example POST, PUT, and so on).
To set up origin failover, you must have a distribution with at least two origins.
A website uses a CloudFront web distribution to serve their static contents to their millions of users around the globe. There are occasions when their users are getting HTTP 504 errors. How would you solve it?

Set up an origin failover by creating an origin group with two origins. Specify one as the primary origin and the other as the second origin which CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.

  • In case of S3 you can do a CRR of the primary origin bucket and make it the secondary origin.
    • attachments/Pasted image 20220424115209.jpg

Field Level Encryption

  • Protect sensitive user information like PII (Personally Identifiable Information).
  • Custom application logic on the web server to decrypt the logic
  • Adds an additional layer of security along with HTTPS.
  • Sensitive information encrypted at the edge close to user.
  • Usage:
    • Specify set of fields in POST requests that you want to be encrypted (up to 10 fields)
    • Specify the public key to encrypt them
    • attachments/Pasted image 20220424115442.jpg

Last updated: 2023-03-01