AWS EC2 Cost Saving Guide
1. Selecting across the same instance type
Fine-tune your EC2 instance selections based on CPU and Memory usage. Even if you had chosen the instance type carefully, note that the application and its usage pattern might change over time.
Select always new instance generation. You will get enhanced performance at a lower cost. Look at how instances differ across generations. Instance prices decline as the new generations come. Upgrading to M5 generation from M3 saves you 27.8% per hour.
Upgrading to the new generation also gives you a performance increase from C3 to C5 large the cost per ECU decreases by %43 and from M3 to M5d.large it decreases by 44%
Of course, upgrading to a new generation instance might require some additional work; however, it will save money in the long run.
Selecting across the same instance type
2. Instance Selection over Different Types:
Instance Selection over Different Types
Amazon EC2 offers a wide range of EC2 instance types and pricing options offer significant advantages if you select instances carefully.
To compare instances across types, you need to calculate per compute units like vCPU, ECU and Memory. The below table lists the most common low-mid-end instance types sorted by cost per vCPU.
The below table is sorted by Cost per Memory.
Considering both CPU and Memory options, interesting cost-saving opportunities arise. Here t3.large instances are cheaper than m5.large instances by 13.3%. Both have 2vCPUs and 8 GiB of memory. T3 might be the better selection considering the burstable option.
M4 large is priced as C4 large. Although the M4 has just less CPU performance than C4 (6.5 vs 8 vCPU), it has a signification memory advance (3.75 vs. 8 GiB) so if your applications do not very heavy on CPU, having M4 over C4 large more than double what you get from memory with the same price.
If your current application runs on Computation-optimized C types and you notice that you might need extra memory before increasing the size in the same class, always consider M types.
Here for example if your application runs on C4 large, before considering moving to C4 xlarge or C5 xlarge, consider M5 large where you will get 8 GiB memory at a lower price.
This is similar to even C5 large. You can consider moving to M5 Large. If you don’t require extra ECUs) you can select M5 large and then move to C5 xlarge.
3. Comparing Processors:
Amazon EC2 provides Intel, AMD EPYC and AWS Graviton types of processors where a selection of the processors directly affects the cost.
Below compares different processor types. In general, the cost for AMD processors is around 10% cheaper than Intel instances.
4. Generate Scheduling Plans:
Review your workload to find instances that can be scheduled. Especially development and test environments are of this kind.
You won’t need those resources always up&running. You can use AWS Instance Schedule which will only cost you $5 per month in AWS Lambda for each schedule, and $0.9 Cloudwatch schedule tracking will be added per schedule.
AWS Scheduler is based on schedule not a number of instances, so create as less as possible scheduler covering as many as your instances.
For on-demand requests, you can create scripts to make your environment up & down if needed.
5. Monitor data transfer costs:
One of the important pitfalls is underestimating the cost of data transfer on VPCs. VPC peering is a cost-effective method for transferring data across VPCs, if you won’t use VPC peering, then transfer happens via public IP, resulting in higher costs.
6. Regularly check CPU and Memory utilization:
Instances that run with CPU and memory utilization under 50% can be considered a candidate for resizing.
You can choose to deploy smaller and less expensive instances or totally terminate the instance by moving the workload to containers.
7. Check unallocated EBS or EIPs :
Terminating an instance does not always terminate EBS or EIPs. Ensure that EBS volumes are terminated and that “Delete on Termination” is selected during the creation of the instance.
In any means, a script that detects unallocated regularly and alerts teams will be very helpful.
8. Use EC2 Autoscaling and Fleet:
If your workload has variable loads, you can use EC2 Autoscaling & Fleet to save costs.
You can set the baseline capacity and scaling resources in terms of instances, vCPUs, or application-oriented units and also indicate how much of the capacity should be fulfilled by Spot Instances.
You should also select instance types that have reservations to use commitment discounts.
9. When you delete Ec2 Fleet, you need to stop or terminate the instances manually.
Be sure that if you delete the EC2 fleet, it only deletes the definition, not the actual EC2 instances. You need to stop or terminate them manually.
10. Set auto-scaling groups based on minimum resource capacity.
Be careful with setting up Auto Scaling groups. You should validate that the min resource capacity and desired capacity are not over-provisioned.
You should also define a scale-down policy for each scale-up policy. This can be based on CPU, Memory utilization.
11. Check the deleted instance if it belongs to Autoscaling group or not.
If a deleted instance belongs to an auto-scaling group, auto scaling group might spin up alternate instances to match the capacity. You need to change or delete group definitions before deleting the instance.
12. Be careful about 3rd party software licenses on auto scaling or EC2 fleet.
If you set up an autoscaling group or use software priced per CPU, you should check your workload before adding to the auto-scaling group.
See Also