How we reduced our annual server costs by 80% — from $1M to $200k — by moving away from AWS
An interview with Zsolt Varga, the tech lead and general manager at Prerender
This week we interviewed Zsot Varga, the lead engineer and manager at Prerender.io. He shares how Prerender saved $800k by removing their reliance on AWS and building in-house infrastructure to handle traffic and cached data.
“The goal was to reduce costs while maintaining the same speed of rendering and quality of service. Migrations like this need to be carefully planned and executed, as incorrect configuration or poor execution, would cause downtime for customer web pages and social media clicks and make their search rankings suffer and potentially increase our churn rate.”
=> Be interviewed in Level Up Coding ➡️ Fill out this form
=> Looking for an amazing job? ➡️ Visit the Level Up hiring platform
Can you describe Prerender and the most interesting technical problem you’re solving
Prerender, in simple terms, caches and prerenders your JavaScript pages so search engines can have a pure HTML file to crawl and index, and all it needs is to have the proper middleware installed on the site, avoiding users the pain of costly and long JavaScript workarounds.
However, all this data and processes need to happen on a server and, of course, we used AWS for it. A few years of growth later, we’re handling over 70,000 pages per minute, storing around 560 million pages, and paying well over $1,000,000 per year.
Or at least we would be paying that much if we stayed with AWS. Instead, we were able to cut costs by 80% in a little over three months with some out-of-the-box thinking and a clear plan. Here’s how you could too.
Planning a Migration: Our Step-by-Step Guide
Up until recently, Prerender stored the pages it caches and renders for its clients using servers and services hosted on Amazon Web Services (AWS) — being AWS one of the largest cloud providers, offering virtual servers and managed services.
Prerender had hitherto used AWS to store the pages it cached until they were ready to be picked up by Google, Facebook, or any other bot/spider looking for content to be indexed. This provided much of Prerender’s functionality — delivering static HTML to Google and other search engines, and dynamic, interactive JavaScript to human users.
The problem? Storing multiple terabytes of prerendered web page contents in this way on a 3rd party server is hugely expensive. Storing the cached pages in this way was costing Prerender astronomical amounts of money in maintenance and hosting fees alone.
But there was another catch that not many start-ups take into account and there’s not too much of a conversation around it: traffic cost.
Getting data into AWS is technically free, but what good is static data for most software? When moving the data around it became a huge cost for Prerender and we started to notice the bottleneck that was holding us back.
The solution? Migrate the cached pages and traffic onto Prerender’s own internal servers and cut our reliance on AWS as quickly as possible.
When we did a cost projection we estimated that we could reduce our hosting fees by 40%, and decided a server migration would save both Prerender and our client’s money.
The goal was to reduce costs while maintaining the same speed of rendering and quality of service. Migrations like this need to be carefully planned and executed, as incorrect configuration or poor execution, would cause downtime for customer web pages and social media clicks and make their search rankings suffer and potentially increase our churn rate.
To mitigate the potential consequences, we planned a three-phase process by which we could easily revert back to the previous step if anything went wrong. If for whatever reason the new servers didn’t work, we could easily roll back our changes without any downtime or service degradation noticeable to customers.
The caveat with continual and systematic testing is that it takes place over weeks and months.
Moving Prerender Away From AWS: a Weekly Overview
Phase 1 — Testing (4 to 6 Weeks)
Phase 1 mostly involved setting up the bare metal servers and testing the migration on a small and more manageable setting before scaling. This phase required minimal software adaptation, which we decided to run on KVM virtualization on Linux.
In early May, the first
