Save money by hosting archived sites on AWS S3

Recently, one of our clients came to us looking to archive an older website that was no longer being updated. The site still needed to be accessible to the public for reference purposes. Taking it offline was not an option due to its historical value. 

Running the site on a traditional hosting environment meant paying for a full web server, application runtime, monitoring, and associated maintenance — all of which were unnecessary for a site that no longer required server-side processing.

If you have a legacy site that doesn’t require dynamic content, migrating it to AWS S3 and CloudFront can be a highly cost-effective solution, all while ensuring it remains accessible, secure, and efficient.

The process for archiving this site and establishing its new hosting infrastructure was straightforward. We needed to first create a static version of the front facing site and then remove interactive features no longer supported to optimize it for archiving. We then set up the AWS S3 service for static hosting, and finished the process by setting up CloudFront to establish a custom domain and greater security than what AWS S3 natively provides. 

Step one: Capturing the website with HTTrack

While the site was still live, we used HTTrack to create a complete static copy of its public-facing pages.

HTTrack is very easy to use — in most cases, you can simply install it, enter the website URL, and leave all settings at their defaults. The tool will automatically:

• Download all linked pages, images, and assets
• Preserve the folder structure
• Adjust links so they work in the offline copy

This made it ideal for our project, as it required minimal configuration but still delivered a full, working archive of the site.

Step 2: Post-processing and cleanup

The raw archive included unnecessary scripts and external dependencies that either wouldn’t function or were no longer needed. We reviewed the files and made the following changes:

Removed third-party monitoring scripts

• Deleted New Relic JavaScript libraries and integration code from all pages
• Removed Hotjar tracking code

Optimized image references

• Removed hard-coded domain prefixes from image src attributes so images load from the S3 bucket
• Manually downloaded responsive images that HTTrack did not capture

Updated site functionality

• Removed the action attribute from the search form so it refreshes the page instead of attempting a server-side search

Why we removed the action attribute from forms

On the original site, forms like the search form were connected to server-side scripts that processed user input and returned dynamic results.

Once the site is hosted as a static website on AWS S3, there is no backend to handle form submissions. If a form retains its original action attribute, pressing submit would:

• Attempt to send a request to the old server endpoint (which may no longer exist)
• Result in an error, broken redirect, or “page not found.”

By removing the action attribute, the form no longer attempts to send data. In most browsers, this causes the page to simply refresh when submitted. This approach avoids user confusion and ensures the static site behaves predictably without broken functionality.

This cleanup ensured the archived site is fully self-contained and does not rely on unavailable third-party services.

Step three: Preparing AWS S3 for Static Website Hosting

AWS S3 is designed for scalable file storage, but it also offers a Static Website Hosting feature. This makes it possible to serve HTML, CSS, JavaScript, and image files directly from S3 without running a web server.

Key benefits for the client:

• Cost efficiency – storage and bandwidth charges are significantly lower than EC2 or traditional hosting
• High durability and availability – S3 provides 99.999999999% durability and high uptime
• No server management – no OS updates, web server configuration, or patching required

While S3 can serve static files directly, it has some limitations. It does not provide:

• SSL certificate management
• Native HTTPS for static website endpoints
• Edge caching for global performance

For this, we will need to use a CloudFront distribution in conjunction with AWS S3 for an enhanced solution.

Step four: Setting up CloudFront for custom domain and HTTPS

In our setup, we are using Amazon CloudFront as the content delivery layer instead of merely relying on S3’s static website hosting feature. CloudFront provides better performance, security and flexibility by caching content at edge locations and enabling features like HTTPS, custom domains, and access control. We used the following configuration: 

• Origin: The S3 bucket's domain (e.g. www.example.com.s3.<Region>.amazonaws.com)
• SSL Certificate: Provisioned via AWS Certificate Manager for the client’s domain
• Custom Domain: Set up CNAME records in the Client’s DNS configuration
• Price class: Use only North America and Europe

This setup ensures the site is served over HTTPS, loads quickly in North America and Europe, and uses the client’s branded domain. 

As your final step, don't forget to test the archived website with the CloudFront URL. 

The Outcome

By moving the archived site to AWS S3 with CloudFront, the client achieved:

• A significant reduction in hosting costs compared to previous infrastructure
• A fully static, self-contained, and secure site (files are private).
• Elimination of unnecessary third-party scripts and dependencies.
• Improved target region (North America and Europe) load times through CDN distribution.

This approach provided a future-proof, low-maintenance way to preserve the website without ongoing server or application maintenance.