Ways To Reduce AWS Costs

by Mike Ricotta - March 18, 2020

If you’re reading this article, chances are that you’re pretty happy with your current setup but you wish you could find ways to reduce AWS costs for your hosting needs.  We’ll assume that you’re not all that interested in migrating to a different hosting provider.  Frankly, you’ll probably spend more short-run money migrating and resolving any post-migration issues than you if you had simply left things alone.  What we’ll do here is target the 2 main costs: Infrastructure and Labor, and then touch on some of the ways you can cost-cut in those areas with AWS.  Then we’ll identify the pros and cons of these changes and how it affects you in the short run versus the long run.

Infrastructure

In this context, the raw infrastructure means the virtual space itself (server).  These costs would include your monthly hosting fees (ie. rented/leased cloud hosting), licenses, and any ancillaries (ie. SSL, Domains, Email hosting, etc).

As indicated above, we’re of the assumption that you’re not looking to make any infrastructure changes. So we’ll stick with that and stay within the realm of how to reduce AWS costs.

With hosting on AWS, you’re probably dealing with a handful of specialized services like Lambda, S3, SES, RDS, and varying types of EC2.  Although each of these is billed differently, you’ll find that AWS offers different methods of payment.  Their billing insights tool is a great way to identify these.  Oddly, they require you to enable it for tracking this information instead of simply tracking it on day one. This won’t cause any issues with our below solutions.

Quick Tip! SSL certificates do not need to be expensive.  If you have one up for renewal, stop what you’re doing and look into Letsencrypt.org. Boom! Savings right off the bat with a FREE SSL.  Sure, you’ll have to install it but it’s free, so quit complaining.

Labor

Your hosting needs to be supported in some fashion.  At some point along the road, you’ve had someone to do something with your hosting. At minimal, set up FTP accounts or accessed a management GUI like Plesk or CPanel.  Even if you’re operating on serverless hosting (ie. Laravel Vapor), a container (ie. Docker), or Managed Hosting (ie. WordPressVIP), there are always labor costs involved. It can simply be your time and energy.  Your AWS labor costs are likely to be hourly contractors, employees, AWS Support, or managed services (a monthly rate paid to a contractor who maintains your servers).

One great example of low-cost managed hosting that we see very often are people who are renting shared hosting space.  The rental costs are almost non-existent and the servers they sit on are managed by the provider, so that’s a solid win-win, right?  Very Very WRONG!  In all of these cases, if you’re not dealing with a dedicated environment, your application layer is subject to the changes from the underlying OS.  We like to refer to this as “passive managed services”.

When your provider pushes across upgrades, it directly impacts your application layer and most often without warning.  You’re not paying a premium for their services, either, so they won’t be able to resolve your issue.  Without question, the economy-hosting clients we’ve encountered will end up spending more money reacting to their providers’ decisions than the minimal cost differences for a dedicated environment (usually as low as $10/mo difference).

On the flip side, if you’re dealing with a more professional level of managed services, you’re probably paying a premium for maintenance.  This could work financially to your benefit if there’s an emergency that requires resolution or if you need to manage your maintenance windows to support your marketing team’s high-traffic goals.  Nonetheless, there are costs involved and oftentimes alternative solutions to consider with regard to how to reduce AWS costs.

Here’s a great reference for comparing labor/support between top cloud providers:
Compare Cloud Support Options

And make sure you check out our AWS Managed Services.

How to Reduce AWS Costs: Reducing Infrastructure Costs

Reserved Pricing

When you sign up for AWS services, they are almost always set up as on-demand resources but AWS likes to know that they can at least cover their costs. They often provide better pricing for long-term commitments. If that works for you, that could reduce AWS costs.

Reserved instances are a way for AWS to get a guarantee from you that you will host with them for “X” amount of time and in turn, you pay a massive discount.  Setting up a reserved instance is no more than a billing setting; it doesn’t require any changes to your technology.

In addition to AWS’s EC2 reserved instance pricing, even AWS’s customers can re-sell their reserved instances. This means you’re able to shop from a large number of competitive pricing options possibly saving you up to 75%.  Oftentimes these are your most competitive prices, so keep an eye out. The “Reserved Instances” program also applies to other services, like RDS.  Here’s an example of MySQL RDS Reserved pricing.  The opportunities don’t stop at “Reserved Instances”, though.

Although it’s a bit confusing, AWS attempts to offer pricing options that are more suitable for the technical needs of your infrastructure.  Here’s one example of a way to change your pricing for RDS based on vCPU allocation.

Saving Plans & Spot Requests

Considered a subset of reserved pricing, you’ll find similar savings percentages in something called “Savings Plans”, which can be found on your control panel’s left sidebar.  Savings Plans are a flexible pricing model that offers low prices on EC2, Fargate and Lambda usage, in exchange for a 1 or 3-year commitment.  This will resemble Reserved Instances.

Another alternative for non-production environments is Spot Requests.  Spot Requests follow the same business model as travel websites like Hotels.com, Expedia, Kayak, etc.

You get below-market pricing to use part-time available EC2 instances during non-peak activity when they happen to be turned off.  Basically, John has a server he keeps turned on 20 hours a day or maybe has a second one turned off for an hour for maintenance and those 5 total hours make those 2 instances’ resources available to the network for strictly that 5-hour window.  If you have the flexibility of having your application run whenever is financially convenient, this is a solution for you.  This is only suitable for staging environments.

Can’t find what you’re looking for?

If you have a service that you cannot seem to find a billing alternative for (ie. reserved instances), you can always reach out to AWS’s support staff.  Billing coverage is included in your free-tier support level, so they’ll be able to investigate solutions for you.

Short Run

If you’re currently financially strapped, you won’t be able to pay a lump sum up-front for reserved instances, which is an obvious draw-back.  That said, just because you want a reserved instance does not mean you have to pay it all up front.  The beauty of the reserved instance marketplace is that it offers several different pricing plans.  You could, for example, split your payments quarterly or bi-annually.  Some of them even offer $0 up-front pricing.  Definitely look for these because they could help you both in the short run AND long run.

Long Run

Buying a reserved instance is a long term commitment. Reconsider this option if you expect your server may be turned off or scaled up. You could be stuck with a pre-paid instance you don’t need.  If your server needs a different instance type, you can change it but your pre-paid commitment is tied to the original type.  That said, there’s a solution to this.  With Amazon’s marketplace, you can re-sell your reserved instances so you can hope to recoup some of your money by effectively transferring that reservation to a new customer.

Resource Limitation

It’s entirely possible that you need less than what you’re using at AWS and AWS does offer ways to handle this. If that’s the case, look into that as a means to reduce AWS costs.

Pick an efficient instance type

The majority of you are probably working with EC2 instances.  This is AWS’s cloud server offering which has all sorts of different “types”. These are configured to target optimal performance for different purposes (ie. general compute, memory-optimized, processor-optimized, graphics optimized, etc).  They all have different pricing and although their configurations impact performance, they don’t change the underlying kernel and language packages.  Think of it as a way to dynamically reallocate memory and processing power to your machine without actually changing anything that would require changes to your website’s code.

Take a look at AWS’s offerings and see if there’s perhaps a lower-priced option that could service your needs.  Testing this out is super affordable and easy to do.  Simply select your server, turn it off, open the actions menu, change the instance type to the one you want, then turn it back on.  We always recommend testing thoroughly for whatever unit testing you typically perform (stress tests, smoke tests, regression tests). You’ll be paying for each hour you have this new instance type, so it’s a low-cost test.  If it doesn’t work, you can always change it back.

Set growth limitations

For services like RDS and general bandwidth usage, you can set restrictions on your on-demand pricing. This limits over-billing.  As an example, when setting up an RDS’s storage you can set it to disable storage auto-scaling. This sets a cap on your storage (although this is probably not a good idea) or set a storage threshold limit (better idea), to keep things from growing out of control.  Similarly, your storage capacity for things like S3, snapshots, and volumes benefit from static limiters.  We’ll cover storage more thoroughly later in this document.

Review billing insights

To get a really good grasp of your utilization and prevent things from growing out of control, take advantage of AWS’s billing insights tools. For example; You can set up alerts in your billing insights dashboard which will notify you when you exceed certain thresholds.  It will take a full billing cycle to track valuable statistics, so the short-run benefit is limited but you’ll be thanking yourself in month 2.

Short Run

If you’ve already paid for long-term pricing, trying out different configurations is mostly a waste of money.  Definitely do this before committing to long-term contracts. !s described earlier in this article., try re-selling your reserved instance if you’ve made that mistake. The other downside is that you have to turn your server off to change the type but we’re talking around 1 minute of downtime.  If you were paying On-Demand pricing, though, the short-run benefits are immediately realized.

Long Run

There’s really nothing bad about getting your server right and at a lower price. The long-run benefits are all there as long as you have addressed your short-run drawbacks above.

Optimizing Your Storage

Storage is super inexpensive, it shouldn’t be hurting you.  Snapshots cost less than volumes and EBS is already pretty inexpensive. If the cost of EBS and snapshots are high, you need to do some house cleaning.  Start by reducing your backup retention rate.  The easiest way to do this is with the LifeCycle Manager.

Enforce strict backup retention

If you have backups set up through Rules and Events, you’re probably staring at tons of snapshots that have been retained forever!  Remove those rules/events and replace them within LifeCycle Manager.  That will prevent this from becoming a growing problem.

Delete unused data

Now that you’ve set a cap on snapshots, it’s time to remove wasted money.  Consider deleting old snapshots and de-registering orphaned AMI’s.  Don’t worry, de-registering an AMI you’ve used on a production server will not cause that server to fail.

On the EBS volumes themselves, clean up whatever you aren’t using.  Log files and backups (ie. .log, .sql, .zip, .tar.gz) are probably clogging your server with orphaned junk.  If you don’t need it/want it, delete it.  We even go to the extent of creating scheduled tasks that clear our access logs every so often.

Once you have your data cleaned up, consider scaling down your EBS volumes. Alternatively, you could consolidate files on single EBS volumes and unmount the ones you don’t need.  EBS volumes can scale up in real-time, which is awesome but they cannot be scaled down in the same fashion.

Quick Tip! To scale up your EBS volumes, visit the EBS tab, select your volume, open the actions menu, and then change the allocated disk space.  It may take a few minutes (or even 30+) to optimize the disk, so be patient with the performance and do not shut down any attached instances during this process.

Scale down

If you want to scale down, you’ll have to create a new volume (which means re-mounting it) and you cannot build a smaller volume from a larger snapshot. This means file migrations.

The simplest solution is to create an empty volume of reduced size and attach and mount that volume.  Then migrate the root directory recursively from the old volume to the new one.  Alternatively, you could just consolidate all files onto one EBS volume (if you consider that safe practice; we typically don’t). Be sure to umount and detach your old volume(s) and delete any backup rules or lifecycle events that would otherwise continue to store copies of that unused volume.

Optimize storage types

Amazon S3 containers are also a great way to store frequent assets for fast load and at a reduced cost.  On the flip side, if you’re looking at deep storage, AWS also offers a way to reduce your storage by up to 85% with their elastic file system.

Other Considerations for How to Reduce AWS Costs

If you’re looking at your sidebar and see something called “Limits”, it’s not what you think it is.  This is a way to calculate vCPU limitations in order to request increases to your account’s limits (not decreases).

In a similar vein, “Capacity Reservations” is not a way to save money.  These are simply a way to reserve an increase in capacity within AWS’s network. Used when you know of a need for increased capacity.  This is strictly about performance, not savings, as you will be charged with On-Demand pricing.

Most importantly, shut off whatever you aren’t using.  More often than not we see people wasting money by leaving dormant on-demand instances on their accounts.

Many of the other miscellaneous services offer a free tier.  See if you can change your operations to fit within that free tier.  Staging servers don’t need the highest performance, for example.  Along those same lines, if you’re exceeding the free Simple Email Service (SES) threshold, you’re probably doing something wrong.  We’d suggest using Sendgrid over SES anyway (better spam score).

Short Run

This is pretty much all up-side.  Performance while scaling can be slow, which is a bummer, and transitioning assets to S3 probably requires development costs. This is an obvious drawback but that’s something you can control.

Long Run

This is definitely all up-side.  You’ll save tons in storage over time and if you’ve set automated restrictions on your backup retention, you’ll save in labor costs as well.

Reducing Labor Costs

The cost-effectiveness of labor is often hard to evaluate because in this case, you’re paying for both maintenance and emergency resolution.  As with any service where urgencies or emergencies are involved, a fast resolution is of the utmost importance. Only you are best suited to determine the financial loss realized by outages.

Contractors

If you are finding yourself reaching out to contractors upon the event of an emergency, you’re already far too late.  Hourly contractors have queues they need to fill to keep the lights on, so they are justifiably disinterested in dropping their paying customers to support your ad-hoc needs.

If you’re dealing with a contractor with a ton of free time, you may want to ask yourself how good they are at supporting situations like yours.  Bottom line is that you won’t be able to get your problem solved quickly, you have no leverage, and you’re bleeding money.

MSPs

In a similar vein, managed services companies are offering low-priced solutions that require their engineering staff to learn your environment when convenient for them.  They’ll be better suited to support your needs in the long run and probably more cost-effective in the short-run but a resolution will still likely be more than a day.  Bottom line is that it doesn’t serve you well to forego labor altogether and it’s certainly best to set up your labor in advance.

Now that we know we need to set up labor in advance, we’ll drop hourly contractors from the conversation.  This is truly never cost-effective.  It’s far more cost-effective for a managed services contractor to maintain a server and keep it operational than it is to allow a server to crash and try to pay to fix it at premium hourly rates.

If you’re looking for a benchmark, take a look at our pricing, below:

Arcane Managed Cloud Service Pricing

Employees

Since you’re here to review ways to save money, we’ll drop employees from this conversation as well, since they’re more expensive than managed services.  Even full-time overseas contractors will cost you more than a managed services agreement unless you run a larger number of servers than the average person and require control over prioritization.

AWS Support Pricing

In terms of AWS support pricing tiers, AWS offers only 2 tiers which cost less than a full-time employee.  As you’ll see in their pricing, Enterprise costs a minimum of $15,000/mo, so that’s out of the question here.  If you’ve signed up for this, stop everything you’re doing and discontinue it.  You can get a managed services contractor at a fraction of that price.  So, that leaves us with their “Developer” and “Business” plans, both of which are truly useless.

The “Developer” plan is basically access to their knowledgebase.  Within 12-24 hours, you’ll get a response from an inexperienced support representative providing you guidance on things you already know, at a high level, and not tailored to your infrastructure.  This is a frankly terrible service and not worth a penny.  You’ll get better information, for free, on StackOverflow.

The “Business” plan is only helpful if you are strictly using AWS’s API for all of your service needs.  That’s because the only difference between the two plans is that “Business” offers API support and slightly faster response times.  It still doesn’t include any hands-on support, so for $100/mo, this is wasted money.  You can easily find a managed services contractor who offers hands-on support for $50-$100 per device at the same response time speed (or better).

MSP’s Are The Answer

Your only good solution is a managed services provider, which explains why there’s an industry built around it.  MSP’s typically offer different tiered pricing models based on the SLA.  Our model, for example, offers a “Standard” and “Premium“ option.  Our Developer/Knowledgebase option is essentially the same as AWS’s Developer option but less expensive and more tailored to your infrastructure.  If you’re a developer who is comfortable with basic server administration, this may be a solution for you.  For everyone else, though, you’re probably looking for a hands-on approach.

MSP’s will offer tiers similar to our “Standard” and “Premium”, which are just based on response time, and hours of availability.  If you want a faster response time and to be able to reach engineers in off-hours, you pay more for that support.  When reviewing MSP’s support levels, determine which is best suited for you.  In comparison to the alternatives (ie. full-time employees), if it costs more than $2,500/mo, you should bring full-time overseas contractors back into the conversation.

Our marketing team has put together some whitepapers on ways to evaluate your MSP’s to find the best option.  You can find these on our LinkedIn page.  I’d strongly advise taking a look at these before signing up for any long-term commitment.

Tying Up: How to Reduce AWS Costs

As you can see, there are plenty of ways to reduce AWS costs and the most effective measure starts with the labor and ends with the infrastructure and reserved pricing.

As we’ve seen, it doesn’t serve you well to forego labor altogether.  That said, you probably don’t need an enterprise-level service if you’re looking to cut costs and economy-level service is almost useless in many cases.  You won’t find that middle-tier solution within AWS’s support and you don’t want to be paying full-time employees if you’re reading this article, so a reasonably priced managed services contractor is the best solution, hands down.

Be sure that your servers’ storage and backups are capped and controlled before you commit to reserved pricing. Also, that your instances are using the most cost-effective configuration to benefit your application’s performance and pricing.  Once that’s verified, try out reservice instances, a savings plan, or spot reservations for non-production environments.

I hope this helps you tighten your expenses and reduce AWS costs even in the slightest bit.  If you have any questions about how to implement these solutions to reduce AWS costs, feel free to reach out to us at support@arcanestrategies.com.

You Might Also Like:

• Explore our AWS Managed Services plans.
• Read our comparison article on AWS vs Google Cloud vs Azure.