AWS CloudFront Study Note
Restriction the Geographic Distribution of Your Content
Use geo restriction also known as geoblocking to prevent users in specific geographic locations to access your content. You have two options.
- Use geo restriction feature to restrict access to entire web distribution and restrict at country level.
- Use third-party geolocation service to restrict access to subset of files associated with a distribution at finer granularity.
Use geo restriction for whitelist or blacklist.
If you need to create separate C.F web distributions if you want to apply different restrictions to your content.
Search C.F access log entries of sc-status value 403 for requests rejected by C.F. However, you cannot know the location of the user being rejected by C.F from access log cause user did not have permission to access the file. If you use third-party service such as Digital Element or MaxMind, you can identify the location of request based on IP address in c-ip column in the access log.
Third-Party Geolocation Service
Use third-party geolocation service to restrict only certain files of your distribution or if distribution not bounded to country level.
You can restrict not only on country level but also based on city, zip, postal code or even latitude and longitude.
When using third-party geolocation service, use signed URLs to specify an expiration date and time. In addition, use S3 bucket as origin so that can use OAI to prevent direct S3 bucket access.
Send source IP of request to third-party service to evaluate geolocation. Based on your logic, deny request by returning 403 or custom error message. Allow by generate a signed URL for the C.F content to the user.
Use Web service variable to get source IP address if not user ELB.
Use X-Forwarded-For http header to get the source IP address if using ELB.
Using Field-Level Encryption to Help Protect Sensitive Data
Use HTTPS to enforce secure end-to-end connections to origin servers. Field-level encryption adds an additional layer of security along with HTTPS that protect specific data throughout system processing so that only application can see it.
To use field-level encryption, you configure your C.F distribution to specify the set of fields in POST requests that you want to be encrypted and the public key to encrypt them.
Components that need access to the sensitive data for business reasons, such as a payment processing system needing access to a credit number, can use the appropriate private key to decrypt and access the data.
In order to use field-level encryption, your origin must support chunked encoding.
CloudFront field-level encryption uses asymmetric encryption, also known as public-key encryption. You provide a public key to CloudFront, and all sensitive data that you specify is encrypted automatically. The key you provide to CloudFront cannot be used to decrypt the encrypted values; only your private key can do that.
Signed URLs, Cookies, OAI
Signed Urls and signed Cookies provides the same functionality which allow you to control who can access your content.
Use signed URLs
- For RTMP. Signed cookies don’t support RTMP.
- Restrict access to individual file.
- Users are using client that doesn’t support cookies such as custom HTTP client.
Use signed Cookies
- Provide access to multiple restricted files.
- You don’t want to change your current URLs.
You cannot use signed URLs or cookies if your URL contain any of the following query string parameters
For signed URL and cookie, you use policy(CANNED or CUSTOM) statement in JSON format to specify the restriction on the URL such as how long the URL is valid. For cookie, it does not have №5, the rest are the same for both URL and cookie.
- Reuse policy statement for multiple files by using wildcard characters in Resource objets
Canned: NO, Custom: Yes
- Specify date and time user can BEGIN to access your content
Canned: No, Custom: Yes(Optional)
- Specify date and time user can NO LONGER to access your content
Canned: Yes, Custom: Yes(Optional)
- Specify source IP or range of users who can access your content
Canned: No, Custom: Yes(Optional)
- Include based64-encoded version of policy which results in a longer URL
Canned: No, Custom: Yes
For signed URL
- Your application determines whether a user should have access to your content and to create signed URLs to access the file.
- User request file using signed URLs
- Your application verifies if user is entitled to access the file: signed in, paid or met some requirement for access.
- Your application creates and returns signed URL to user.
For signed cookies
- Your application determines whether a user should have access to your content and if so, to send three Set-Cookie headers to the viewer. Each Set-Cookie can only contain only one name-value pair and signed cookie requires three name-value paris.
- User signs in to your website and either pays for the content or meets some requirement to be verified or entitled.
- Your application returns Set-Cookie headers in response and viewer stores the name-value pairs.
- User requests restricted file. User’s browser adds name-value from step above to the request in Cookie header. This is signed cookie.
Preventing Misuse of Signed Cookies
- Exclude the
Max-Agecookie attributes, so that the
Set-Cookieheader creates a session cookie. Session cookies are automatically deleted when the user closes the browser, which reduces the possibility of someone getting unauthorized access to your content.
- Include the
Secureattribute, so that the cookie is encrypted when a viewer includes it in a request.
- When possible, use a custom policy and include the IP address of the viewer.
- In the
CloudFront-Expiresattribute, specify the shortest reasonable expiration time based on how long you want users to have access to your content.
To use signed URLs or signed cookies, you need at least one AWS account that has an active C.F key pair. Such account is known as a trusted signer.
As soon as you add trusted signer(self or other AWS Account) to your distribution, C.F starts to require users using signed URLs or cookies to access your file.
To add trusted signer,
- Edit distribution
- Edit Behaviors
- Click Yes for Restrict Viewer Access (Using Signed URLs or Signed Cookies)
- Select Self or Specify Account for Trusted Signers
When you create signed URLs or cookies, you use the private key from trusted signer’s key pair to sign portion of the URL or cookie. When someone requests a restricted file, C.F compares the signed portion of the URL or cookie with the signed portion to verify the URL or cookie hasn’t been tampered. C.F also verifies that the URL or cookie is valid such as the expiration date and time hasn’t passed.
When you create a CloudFront signed URL or signed cookie, you include the key pair ID of the trusted signer’s key pair in the URL.
Web distributions use signed URLs or cookies whereas RTMP distributions use signed URLs only.
Use origin access identity (OAI), an user for C.F, allowing C.F to access S3 bucket as origin.
Increase Proportion of Requests Served from C.F Edge Caches(Cache Hit Ratio)
You can improve performance by increasing proportion of your viewer requests that are served from C.F edge caches instead of going to your origin for content to improve the cache hit ratio of your distribution.
Specifying How Long C.F Caches Your Objects
To increase cache hit ratio, configure your origin to add a Cache-Control max-age directive to your objects and specify the logest practical value for maz-age. The shorter the cache duration, the more frequent C.F forwards request to your origin to determine whether the object has changed.