Editor’s note: While AWS is a preferred choice for hosting your Magento store, it can prove expensive at times, especially when these vital things are ignored. If you are in the same boat as well and not happy with high costs, check out this post. It lists 10 easy ways to keep it under control. Another way to deal with Magento issues is to take expert services. We are known for the best Magento development services in the market. Don’t believe it yet? contact us and experience for yourself.
If you’re not careful, AWS can become a really expensive hosting option for your Magento store.
There are many little things that add to your bill and make you pay a lot more money than you have to.
The good news is that there are ways to reduce your Magento hosting costs with AWS without compromising performance.
So here’s how to do that.
1. Understand the demand and match it
In order to minimize the cost of your AWS you need to understand the resource utilization patterns.
In other words, you need to understand in which time periods there is more or less resource utilization.
For example, at looking at your traffic, you might realize that 80% of your traffic happens between 9 am to 12 pm.
So since these are your busiest hours, it’s normal to have more resources available to handle it.
However, there are times when there is little to no usage. For example this could be during the night or on the weekends.
And a great way to minimize your costs here is to turn off instances when this happens.
Saving costs in non-production workload environments would require scheduling the downtime of your EC2 servers in times of low demand.
Your services running in the AWS environment also need to be bootstrapped so that they start and stop automatically in line with initiation and termination of your EC2 servers respectively.
You can schedule your start and shut down by using instance tags to group resources.
This makes it easier to apply policy-based actions to control shutdown of entire instance groups when they’re idle.
2. Right sizing
Right sizing is the process of modifying or considering to modify your existing AWS cloud infrastructure to balance and meet the demand of your business.
With right sizing you can identify underutilized resources and you then make a decision on how to use them most effectively. You can either vertically adjust these resources allotted to an instant or release them.
The two things that you can right size most effectively are instance size and volume types.
For example: if an instant is being underutilized, you can switch down to a size or two.
Another things you can right size are the disk storage type and performance.
And there are two main reasons why your compute instances can be underutilized –
- Either a workload is no longer resource-intensive as it was befor
- The compute instance has accidentally or purposely been provisioned more than required.
It is important that you have continuous monitoring and automated alerts in place to flag underutilized resources.
Tools like Centilytics can give you real-time performance data to help you understand what and how you should right size in your cloud.
3. Use Reserved Instances
Using Reserved Instances is one of the best ways to reduce your Magento hosting costs.
They work very similar to coupons or long-term commitment to AWS. Â When you use them you pay a low, one-time fee in advance with a good discount on the hourly charge for your running instances.
To reduce your usage costs, AWS pricing framework automatically applies the rates for Reserved Instances.
Your best option here is to buy Reserved Instances for a time period of 1 year or 3 years. This can help you save up to 70% of your costs compared to what you’re going to pay when you use on-demand instances.
There are three different payment options available – all upfront, partially upfront, or no upfront.
What’s really good about Reserved Instances is that they provide you with loads of flexibility in terms of repurposing, reselling, and payment options.
But this comes with its challenges as well. If you purchase an instance and you don’t use it or keep it turn off for a long time, you’re still paying for it.
4. Orphaned Snapshots
Snapshots are a point-in-time backup copy of an EBS volume, stored in Amazon S3.
These snapshots are not only used as recovery points in case of any data loss or disaster but, can also be used as the starting point of new Amazon EBS volumes.
The very snapshot can be utilized to instantiate as many volumes as required. You can make copies of these snapshots across various AWS regions for geographical expansion, disaster recovery and data center migrations.
When an EC2 instance terminates, EBS root device volumes are automatically erased by default.
However, any additional EBS volumes that you attach at launch, or any EBS volumes that you attach to an existing instance persist even after the instance terminates.
This means that your EBS snapshots remain on S3 and keep on racking up monthly charges if not monitored regularly. Individual Snapshots do not account for much spikes in your bills as multiple snapshots combinedly do.
Sometime customers might make the mistake to automatically create snapshots on a regular basis, thereby neglecting to schedule the deletion of aged, unwanted snapshots.
That’s why you should make it a habit to clean up Snapshots that have no attached volumes to it. Of course, unless they are required for creating new EBS volumes in future.
5. Cleanup Unnecessary EBS Volumes
Unnecessary EBS Volumes could account for more than 50% of your AWS costs if you’re not careful.
They keep piling up in your AWS account, adding thousands of dollars in cost, no matter if they are being utilized or not.
Every time a new instance is launched, an EBS volume usually comes appended to it.
However, launching an instance via the AWS Console gives you the option in the settings to delete the attached EBS volume upon the decommissioning of the instance.
If that setting is not enabled, the volume remains in your account even after its associated instance gets terminated.
In general, all EBS volumes, that are not root volumes, should be erased. Organizing and deleting orphaned or unattached EBS volumes on a regular basis will help you keep your ASW costs low.
6. Cut Down Your Data Transfer Costs
Data transfer costs can contribute for up to 30% of your AWS costs and it is certainly something that you can optimize.
These charges appear when you’re transferring data across AWS cloud services in & out, to and from an AWS service.
Charges appear also when you’re transferring data in and out one service to another.
Pulling data across different regions could be really expensive. That’s why it’s a smart move to narrow down the number of Regions that your data flows across.
Try architecting or re-architecting your frameworks in a way so that the data transfer across various AWS regions or availability zones, is minimum.
Re-hosted applications that are not configured or aligned with AWS features needs are more prone to incur high data transfer costs.
They should be re-architected to ensure that data transfers are completed through the cheapest route possible.
Some AWS services cost much more to send and receive data as compared to others.
So in order to minimize costs, you need to analyze which services incur higher costs for transferring data to and from within the selected Region.
After that you need to re-design in a manner that your data transfers do not happen along costly routes.
7. Optimize Storage Costs
AWS offers three types of services for your object storage.
The most well-known option is S3 that guarantees you to provide with 99.999999999% redundancy and durability across all your availability zones within a region.
In case, if you have some static data objects that are noncritical or reproducible, and you are willing to compromise on reduced redundancy, you can go for S3 Reduced Redundancy Storage (RRS).
It costs around 15-20% less than that of S3 and offers lower levels of redundancy than Amazon S3’s standard storage. So in other words – 99.99% durability.
A third option is Glacier that offers services for archiving your objects, something like magnetic tape backups in traditional data centers.
The good news are that Glacier is much cheaper than the other two options – about one cent i.e. $0.01 per gigabyte every month and up to 80% cheaper than S3.
The reason why you might not want to get this storage option is that the retrieval time of the object is around four to five hours.
8. Discard Assets that are more of Liabilities
A lot of times infrastructure components that are not being used up to their potential or not being used for any purpose at all.
However, they are still running in the cloud environment causing a huge spike in your monthly AWS costs.
We call these assets obsolete resources or more of a liability.
These might include:
- outdated EC2 instances
- an idle Relational Database Service (RDS) instance
- idle Elastic Load Balancers (ELB)
These resources were once utilized for a specific purpose but haven’t been in use since then, nor were they terminated.
This could also happen because of some failure during their launch process or script errors failing to release those instances.
So as long as these assets or resources are utilized and they keep running, AWS will charge you for them.
So to save on your ASW costs they must be detached, assessed, and immediately discarded.
9. Auto Scaling
Every Magento store has busy periods when where there is a heavy load on their application but the number of services is far lower than what is required to handle it.
A great way to deal with this without spending unnecessary money for your AWS is to use auto scaling groups.
With their help you can acquire extra capacity so you can handle the heavy traffic.
Auto Scaling basically allows you to always have the necessary number of Amazon EC2 instances to handle the load of your application.
You do that by creating a collection of EC2 instances that you call an Auto Scaling Group. You decide how many instances to have in each group.
Then you setup these Auto Scaling groups to automatically launch or terminate unnecessary instances based on the current demand of your application.
10. Elastic IP Addresses
You get one free Elastic IP address (EIP) with each running instance on AWS.
With its help, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account.
However, EIPs are a limited resource to rely upon and they can also add a lot to your AWS costs.
Here’s how this happens.
An unattached Elastic IP address remains allocated to your AWS account until explicitly released.
In order to ensure effective consumption of addresses, Amazon imposes a small hourly charge on EIPs dissociated with a running instance, or EIPs associated with a halted instance or an unattached network interface.
The bad news are that you’re not charged for one Elastic IP address associated with the running instance. Instead, Amazon applies charges for any additional Elastic IP addresses attached to the instance.
So to decrease your AWS costs, you need to release EIPs the very moment instances are halted or terminated. Especially, when you don’t have plans to restart them or attach it to an instance.
In conclusion
The first step to reducing your Magento hosting cost with AWS is to understand how your resources are being utilized.
You need to understand in which hours and days there is more or less utilization. And then you need to turn off your instances when there is little to no usage.
It is very important that you right size your infrastructure, identify underutilized resources and learn how to use them more effectively.
One of the best ways to decrease your cost is to use Reserved Instances instead of on-demand instances. You just need to make sure you use them properly.
Also, don’t forget to delete orphaned snapshots and unnecessary EBS Volumes as they might add a lot to your AWS cost.
The same thing you should do with assets that are more of Liabilities.
The last but not least, don’t forget to cut down your data transfer and your storage costs. And be careful with using Elastic IP addresses.