Get started with CloudFront - Part 2: Distribution Invalidations
Van Hoang Kha
Posted on March 1, 2023
Table of Content
1. Test Distribution Invalidations
When using Amazon CloudFront to distribute resources to the website, some resources will be stored in CloudFront's cache to speed up access for users. However, when you make changes to a cached resource but cannot change the URL to point to the new version, you need to perform Invalidations to discard the old version and reload the session. new version from the original server.
Access the Invalidations tab on the CloudFront Console interface.
- Create an Invalidation for the index.html resource.
You can specify / in Object paths because we have set index.html as default root object.
Invalidations in progress
Create successful Invalidations
After a few seconds, retry the site using the browser developer tool, you will see that it is no longer cached by CloudFront and reload a new version from the origin server.
Note: Invalidations may take a few minutes to complete, and during that time, users may be able to access an older version of the resource. Therefore, you need to consider and perform Invalidations at the right time to ensure the latest resources are delivered to users.
The data shows that when you perform Invalidations, if a resource is already cached in CloudFront, it will be removed from the cache and a new version will be downloaded from the origin server when the user requests access. access that resource. This helps ensure that users receive the latest version of the resource without having to clear the browser cache or wait for the CloudFront cache to expire.
Using Invalidations in Amazon CloudFront also saves costs and increases the performance of your website. When a resource is stored in CloudFront's cache, downloading it from the origin server consumes a lot of your time and system resources. When you use Invalidations to remove old versions, CloudFront will no longer have to reload these old versions, saving resources and reducing your website's operating costs.
In short, Invalidations is an important tool that helps ensure that users receive the latest version of the resource and helps speed up the website. It also saves resources and lowers your website's operating costs.
2. Custom Error Page
When testing a random URL with your CloudFront domain, you will get a 403 Forbidden response from S3 behind CloudFront because the file doesn't exist. By default, CloudFront temporarily stores this response for 10 seconds.
Create the error.html file on your computer using a text editor with the HTML content below and upload it to your S3 bucket as you did before for the index.html file.
- Open a text editor on your computer
- If you use Windows, you can use Notepad or Notepad++ to edit text
- If you use MacOS, you can use TextEdit or other text editors to edit text
- Create error.html file with HTML content below:
<html lang="en">
<body>
<h1>CloudFront Lab</h1>
<strong>Ops, this is a nice error page!</strong>
</body>
</html>
Save the error.html file with UTF-8 format and give the file an arbitrary name (eg error.html)
Log in to AWS Console and select the S3 . service
Select the S3 bucket where you want to upload the error.html . file
Select "Upload" to upload the error.html file from your computer to the S3 bucket
Wait for the upload to complete
To check if the error.html file has been uploaded successfully, select it on the S3 bucket and preview its contents.
Instructions for configuring a custom error page in CloudFront
To configure a custom error page in CloudFront, you can do the following:
Sign in to the CloudFront dashboard
- Select the CloudFront Distribution for which you want to configure the custom error page
- Select the "Error Pages" tab
- Find and select the "Error Pages" tab
- Create custom error page
- Click "Create custom error response" button
You can configure a custom error page with the following settings.
- HTTP error code > 403 Forbidden
- Error caching minimum TTL: 60
- Customize error response: Yes
- Response page path: /error.html
- HTTP Response code: 200 OK
-
Select Create custom error response
- With these settings, when your site encounters an HTTP error > 403 Forbidden, it will display a custom error page previously configured and cache it for at least 60 seconds. Customers visiting your website will receive a custom error response with the path /error.html and the HTTP response code 200 OK.
Create a successful custom error response.
Test your custom error page by requesting a random page from CloudFront. It may take a few minutes for the update to deliver and propagate to the Edge locations. Make sure you use a different random value than in the previous test, or else you will get the same cached version as when you tested in the last 5 minutes.
-
To check custom error page, follow these steps:
- Open a web browser and visit a random page from CloudFront.
- Wait a few minutes for CloudFront to update and spread the distribution.
- Enter a random value different from the previous test.
- Get HTTP > 403 Forbidden error messages from CloudFront.
- Check if custom error page is displayed or not. If the custom error page is displayed, the configuration is successful.
If you're still getting the default CloudFront error message, double check your custom error page configuration and make sure you've saved the changes. You should also check that your values match the required settings.
Create a new custom error page to display when CloudFront cannot connect to the source. Use the following settings:
- HTTP error code > 504 Gateway Timeout
- Error caching minimum TTL: 5
- Customize error response: Yes
- Response page path: /error.html
- HTTP Response code: 200 OK
- Select Create custom error response
Finish creating 2 Error pages.
Change Inbound rule of Security group
- Access to EC2 Console.
- At the EC2 Console interface, select Security Groups in the left panel.
- Select Security Group containing Inbound rule to access EC2 instance running Nodejs API.
Edit Inbound rule for HTTP from 0.0.0.0/0 to MyIP
- Select the Save Rules button to save the changes made.
Edit Security group successfully.
Open a web browser and enter the CloudFront URL of the index.html page in the address bar.
- Press Enter to access the website.
- Check if the website is working properly or not.
- You will see the interface as shown
3. Create Origin Group
In this section, you will configure an Origin Group to provide rerouting in the event of a problem. You can associate an Origin Group with a caching behavior so that requests are routed from the primary source to the secondary source for high availability.
Go to the S3 dashboard, create a new S3 bucket in a different area
- Give the S3 bucket a unique name, remember that the S3 bucket name is globally unique, so add a personalization suffix, for example:
cloudfrontlab-s3bucket-secondary-<YourNameHere>
Select Create bucket
Create a secondary-index.html file on your computer with the HTML content below:
<html lang="en">
<body>
<h1>CloudFront Lab</h1>
<strong>Hi, this is a page from my secondary Origin! We now support Origin group and failover!</strong>
</body>
</html>
- Open a web browser and log in to the S3 console.
- Select the name of the S3 bucket that you want to upload the file to.
- Click the "Upload" button in the upper right corner of the web page.
- Select the secondary-index.html file from your computer by clicking the "Add files" button or dragging and dropping the file into the upload area.
- Click the "Upload" button to upload your secondary-index.html file to S3.
Upload successful.
Go to your AWS account and select the CloudFront service.
- Find and select the CloudFront Distribution for which you want to configure the origin group.
- Create a new origin by selecting the "Create Origin" option
Choose your origin domain name and select the new S3 bucket containing the secondary-index.html file.
Set up access to the S3 bucket by selecting "Yes, use OAI" and selecting "Select" to select the OAI you created earlier.
- Update the bucket policy by selecting "Yes, update the bucket policy".
- Select Create origin
Create origin successfully. Click the Create Origin Group button to create a new Origin Group.
Make origin group configuration. Select the source from the drop-down list and click the Add button to add the source to the Origin Group.
- Use cloudfrontlab-s3bucket-* as primary origin
- And cloudfrontlab-s3bucket-secondary- as secondary origin
- For failover criteria, select 403 Forbidden and 404 Not Found.
- Click the Create origin group button to finish adding the source to the Origin Group.
Once done, you have successfully added the source to Origin Group on CloudFront. When the primary source fails, CloudFront automatically redirects to the second source to ensure service continuity.
Edit default behavior on CloudFront to use new Origin Group
- Select the Behaviors tab
- Select Default(*) and click the Edit button to edit the default behavior of the distribution.
Select the Origin Group created in the previous step.
- Click the Save changes button to save the changes.
- Once done, CloudFront will use the new Origin Group as the source when accessing the distribution. You can test failover functionality by trying to visit the website and temporarily disconnecting from the network to check if CloudFront redirects to the second source.
Once the distribution status is changed to Deployed, you can request the secondary-index.html site from CloudFront. If CloudFront is working correctly, you should see the second S3 origin serving your request.
- Open a web browser and access the URL of the CloudFront distribution.
- Change the URL from /index.html to /secondary-index.html to request the site from the second S3 origin.
- Check if the web page has been uploaded from the second S3 origin. If the web page is properly uploaded and displayed, it is an indication that CloudFront is working correctly and redirects to the second S3 origin when necessary.
- Note: If the site is not uploaded or displayed incorrectly, double check your settings to make sure it is properly configured and working as expected.
The following sections
Get started with CloudFront - Part 1: CloudFront Distribution
Get started with CloudFront - Part 2: Distribution Invalidations
Get started with CloudFront - Part 3: Response Headers and Cache Behavior
Posted on March 1, 2023
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related