Save on your AWS bill with this one simple trick

With only a few clicks of the mouse, I saved 16% on my company’s AWS bill. Pretty sweet, eh?

This article will show you why that matters, and how I did it.

FusionAuth Cloud lets you outsource operating your authentication service

But first, let me set the scene. FusionAuth is downloadable software and running it is as simple as:

curl -o docker-compose.yml https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/master/docker/fusionauth/docker-compose.yml curl -o .env https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/master/docker/fusionauth/.env docker-compose up

If you have Docker installed, that’s all you have to do to get a FusionAuth instance up and running.

After that, you need to integrate it with your application, typically using a standard OIDC library such as Passport or Spring security. You need to theme it to make it look like your application.

But that’s it.

With these steps, you get a full featured auth server, available on your laptop, for you to build against.

What about production?

docker-compose up is great for development.

But auth is the front door to your application, and should be highly available in production. Some of the considerations when running a FusionAuth production deployment include:

• securing the application and servers

• backups and restores

• upgrades and rollbacks

• responding to DDOS attacks

• monitoring

FusionAuth Cloud, where the FusionAuth team operates FusionAuth, lets customers let us run FusionAuth for their authentication needs. It takes these tasks off your plate and puts them on that of the FusionAuth team.

Now, there are many customers with the team, compliance needs, and desire to run FusionAuth themselves; we’re happy to support them in doing so with documentation and customer support.

But many users want to offload operational burdens and security concerns. In this aspect, FusionAuth Cloud is similar to a typical software as a service (SaaS) provider.

What’s so special about auth?

But.

An authentication service is not like any old SaaS application. Depending on your integration, it is embedded in your application. This is why Okta consistently has negative churn on the order of 20%. Once you’re committed to an auth provider, it’s a biggish project to shift to another one.

Worse, when your auth system breaks, your users don’t have access to your application. That’s bad.

Because of these two attributes, with an auth provider you have requirements above and beyond those of a typical SaaS tool. FusionAuth Cloud offers the following:

• It explicitly lets developers control the upgrade process; no required upgrades. You and your engineering team pick the version of software your application integrates with. You also choose how and when to upgrade. You can thoroughly test your integration when a new version comes out, rather than testing in prod or having new features foisted on you.

• Each customer is running on physically isolated single-tenant systems. Each FusionAuth Cloud deployment runs on separate virtual hardware, using Amazon’s best of breed managed services where appropriate.

Isolation in multi-tenant SaaS

Let’s talk about isolation. When you offer a multi-tenant solution, with different customers using your application, there are multiple approaches to isolating their data and available functionality.

• Logical isolation is implemented using a tenant_id field on tables (or using proprietary database functionality such as row level security). When a request comes in, the tenant is identified and only that tenant’s data is examined by the application. This is the cheapest and easiest multi-tenant solution to run. You have one set of servers and one primary datastore in production. However, if there are any flaws in the code, everyone’s data may be accessible. You can scale this system, but you can’t scale any individual customer’s application.

• Container level isolation relies on containers and other software constructs such as Kubernetes namespaces. With this option, you have one set of servers underlying the containers in a cluster, though you can also outsource running it to a public cloud provider. Each customer gets their own set of containers running the code, as well as a separate database schema or server. This is more expensive, but provides a higher level of isolation.

• Server isolation is when you stand up separate virtual or physical machines. The application runs on each system. You can configure network layer protections such as firewalls, which increases the level of isolation. There’s also a lower chance of a noisy neighbor causing customers issues; the servers are separate. However, the operational cost is higher too.

FusionAuth Cloud uses virtual machines and a shared-nothing architecture. Your data is isolated not within a database using foreign keys, but on physically separate machines.

FusionAuth Cloud and EC2

This architecture leads to a lot of VMs, as you might imagine. As FusionAuth Cloud grows, the FusionAuth team is responsible for more and more virtual machines.

Which brings us back to the beginning. During a hackfest, I took a look at reserved instances because I was interested in the cost savings opportunities. Most of FusionAuth’s AWS spend is with EC2 and RDS.

Many of our customers are on month to month plans, and the minimum AWS reserved instance length is one year (unless you are using the reserved instances marketplace, but I’m going to ignore that because it makes things complicated).

Our customers also choose one of 15+ AWS regions in which to deploy their FusionAuth servers. This allows them to pick the region that makes sense for their performance, compliance and data sovereignty needs, while still outsourcing operations to the FusionAuth team. Reserved instances are tied to an AWS region, making it an awkward choice.

While we could have projected a baseline of region usage and VM lifetime and bought reserved instances based on that, this felt like a bigger project than was suitable for a hackfest.

However, after more research, I discovered AWS Compute Savings Plans. There is an EC2 version that “appl[ies] to EC2 instance usage regardless of instance family, size, AZ, Region, OS or tenancy”.

Perfect!

How much can you save?

FusionAuth Cloud adds new customers regularly, and churn happens, especially when someone tries our Starter Plan free trial and determines that FusionAuth isn’t the right fit.

I wanted to avoid automating the purchase of these plans, which felt like over-optimization. I began with a manual solution.

The Savings plan overview has a “Recommendations” tab. You can play with options and arrive at a savings amount. This helps you determine if you have enough spend to make buying a plan worth your time. To begin with, I chose “Compute Savings Plans”, a “1-year” term, and “No upfront” as the purchase commitment. You get a deeper discount for prepayment or a longer commitment.

Here’s a table of the discounts available to us at time of writing. Check out the Savings plans section yourself to see your discount options.

I could have saved more money, but going with a year term and no upfront cost gave the right mix of savings and flexibility. A 21% discount on EC2 usage we already know will be running 100% of the time?

Yes please.

Buying the Compute Savings plan

Here’s the screen where I purchased the plan.

With Compute Savings plans, you are buying hours of instances, but paying in dollars per hour. It’s a bit weird, but makes sense when viewed in the bigger picture. After all, it’s an AWS bill, so it can’t be too straightforward.

Here’s an example to make it a bit clearer.

Let’s say you have 20 X1E Extra Large EC2 instances. These bad boys each cost $0.6160 per hour. I don’t know what you’re doing with that much RAM, but whatever.

With this, you have $12.32/hour of spend (20*0.616). To save money, if you know you will run these servers for a year or so, use a Compute Savings plan and buy down a portion of the $12.32. You could buy $5 of that hourly spend for $3.95, for instance.

After you buy the plan, you will be billed for that $3.95 whether you run the instances or don’t. Your total hourly bill is now $11.27, a savings of $1.05 or 8.5% across your entire spend.

The bottom line is that AWS is thrilled when you commit to spending money with them, and is therefore willing to pay you to do it.

Setting up a system

Because of our growth, I wanted to avoid buying a savings plan as a one and done effort. I wanted a system that was lightweight, but would save us money as more customers came on board while preserving flexibility if we wanted to shift directions.

Instead of buying the amount recommended by AWS, I bought 50% of it. In the future, we’ll do it again: purchase half of the recommended Compute Savings plan every few months.

This will allow us to work towards having 100% of our usage covered by a savings plan. But we’ll never get there. Similar to Achilles and the tortoise from Zeno’s paradox (image credit to wikipedia).

After determining that system would work, I documented it so I wouldn’t forget. This also lets others do this task if need be. Then I attached it to a recurring event in my calendar and promptly forgot about it. Every quarter or so, I get a reminder, and log into the AWS console and buy more discounted compute hours.

This approach doesn’t maximize our savings, but it yields a useful amount (approximately 16% of our bill) and offers flexibility if our needs change. All at the cost of approximately 10 minutes every quarter.

I’ve spent more time on this blog post than I have buying Compute Savings Plans over the past year. I’ll be honest, it’s fun to save thousands or tens of thousands of dollars with a single click and essentially zero downside.

That’s the kind of clickops I can get behind.

Downsides of AWS Compute Savings plans

What about that downside? Well, if FusionAuth ever needed to leave AWS, we’d have to plan ahead a year or so or eat the cost of the committed spend. However, migrating off any cloud provider, especially when your system is the front door for millions of your customers’ customers, isn’t a task you undertake on a whim. That downside is acceptable.

We’re also not saving as much as we could. If we signed up for three years instead of one, we’d save more but lose flexibility. If we optimized, researched reserved instances (especially for RDS servers), and automated plan purchases, we could save even more. But we’ve made a conscious decision to focus on growth. Spending too much time optimizing cloud spend doesn’t align with that.

10 minutes a quarter, on the other hand, is pretty easy to find.

Summing up

If you are running significant numbers of EC2 instances, there’s very little risk in investigating and implementing cost savings plans.

Happy saving!