Unexpected AWS Charges You Should Be Monitoring Closely

This article covers some unexpected AWS charges that can pile up quickly. To avoid being surprised by your AWS bill, pay close attention to these costs.

Cloud adoption has many benefits, the most notable of which being the wide range of options and price models available. Your cloud charge, on the other hand, can get confusing. If you don’t keep track of it and review it on a daily basis, the expenses can easily escalate out of control. Fast scalability, pay-as-you-go pricing, and a vast array of options and updates can make things very complicated.

Every company should actively monitor its cloud costs, which can drive up the overall cloud bill. However, if you handle them properly, this can be avoided. Here are some AWS charges you should keep an eye on.

AWS Free Tier Usage

AWS Free Tier offers a limited number of AWS services to use for free, up to a defined monthly consumption cap. It’s divided into three pricing models: a 12-month Free Tier, an always free offer, and brief trials. You can use this model to test out the services, but also to build and maintain a basic web application. But for some time now, there is a growing problem between developers using the AWS Free Tier. They report having problems with unexpected costs and are not able to define what exactly is causing these costs. To avoid any charges like these, there are a couple of things you can do:

1. First, understand what services are covered by the free tier. Then, make sure that your planned project falls under the free tier offering. You’ll be charged on-demand instance rates for any additional usage.

2. Create usage alerts in AWS Budgets to be able to react on time. Make it a practice with any starting project to set up a monthly fixed limit in your AWS Budgets account.

3. Monitor your AWS charges frequently in the Billing and Cost Management console.

4. Delete resources after you’re done using them.

5. ake sure the free tier period has not expired. Any resources allocated to your account after that period are chargeable.

EC2 Instances

1. Idle Instances

Charges like computation, memory and local storage are all billed by AWS as instance hours, which is how much you spend to run an EC2 instance for each hour of the day. Unused or underutilized EC2 instances are one of the most common causes of high AWS bills since you need to pay for services you aren’t using.

Right-sizing, shutting off pre-production instances outside of business hours and having better prices through spot instances and reservations are all well-known tactics for controlling these costs. Be sure to end all instances as soon as you’re through with them. Keep in mind that this extends to each region separately, so you must check the conditions for the region you have chosen.

2. Unhealthy Instances

Also, keep an eye on your EC2 usage data for low CPU, bandwidth, or I/O consumption, since these are warning flags that may signify an unhealthy instance. A way to deal with this is auto-scaling – horizontal scaling that enables you to create collections of EC2 instances dedicated to handling the load of your application. According to the parameters you define, auto-scaling automatically adjusts the number of instances that will be running.

The added benefit here is that auto-scaling can determine the health status of an instance, terminate an unhealthy instance and replace it with a new one. With this you keep wasted infrastructure to a minimum.

3. Unused EBS Storage

EBS, or elastic block storage, has become an essential component of Amazon’s EC2 system, which is typically used as volumes attached to individual EC2 instances. It’s necessary to note that while an EBS volume, which serves as the instance’s core volume, is added to particular instances, they are paid independently. Unlike EC2 examples, an EBS volume does not need to be running to ramp up your AWS bill.

The EBS storage itself (GB-months), snapshots (also in GB-months), and finally provisioned IOPS are the three major categories on which you will be billed (IOPS-months). To save resources in this area, make sure you don’t have any unattached EBS volumes and that you select the right kind of EBS volume.

You can set up a policy to automatically delete all EBS volumes attached, as part of the termination process. You can also identify existing unattached volumes in the AWS Console. These volumes will be available, which means they are not attached to an EC2 instance. Also, check any volume activity over a previous period, If the volume hasn’t been used in weeks and it doesn’t belong to a production environment, that’s a good sign it can be deleted.

4. Orphan Snapshots

Additionally to deleting your EBS storage, you need to take care of your backups. Your snapshots will stay saved on Amazon Simple Storage Service (S3), and you will continue to pay monthly for them, even if the attached EBS volumes are immediately removed along with the instance. Delete these orphaned snapshots to save the same amount of money as removing the original EBS volume. Make sure to get rid of them unless you’re sure that you’ll use them again to generate potential EBS volumes.

Underutilizing Reserved Instances

Often AWS customers pay as they go and never think about buying reserved instances (RIs), which are pre-booked services and capabilities for one or three years. Your hourly rate is heavily reduced since you are agreeing to pay for all of the hours during your contract.

When you use all of the time you’ve purchased, RIs will save the company a lot of money. Calculating your use so long in advance can be daunting, and reserved instances can be a money trap if your needs are smaller than you expected. Try offering instances you don’t use on the AWS Marketplace if you’ve already purchased them.

AWS Data Transfers

There are different charges associated with moving data into and out of EC2, and these expenses can be largely based on the workloads. The amount you’ll be paying is determined by the amount of data being transmitted and where it’s going, and charges differ by region.

Transferring data from the Internet into any AWS region is free. Data transfer out to the Internet from an AWS region is billed per region-specific rates. You can find the pricing rates per region here.

Moving data between services within the same region is normally less costly than moving data between services outside the region, and some regions have higher costs. Data transfers between regions are the most costly in the AWS pricing models. They are calculated by source region-specific rates. You can find the prices here. This is why it’s important to choose wisely the regions where your data needs to transfer between and plan your data flow.

Data transfers within an AWS region are between services or resources in the region. If the services or resources are located in different availability zones, transfers incur costs. Only if you use a private IP address, then these transfers are free.

If you want a deep dive into this subject, here is a great article to help you better understand AWS data transfer charges.

Underutilized Elastic IP (EIP) Addresses

EIPs is a static IPv4 address for dynamic cloud computing. They allow users to quickly remap an address to another instance in their account to hide an instance malfunction. Each AWS instance comes with one free Elastic IP address (EIP), but EIPs connected with stopped instances or unattached network interfaces will be paid hourly. Users are also billed with any EIPs that aren’t connected with an active instance.

Also, all AWS accounts have 5 EIPs per region, because they are a limited resource.

You should keep an eye on your account for EIPs that are no longer in use, much like instances, orphan snapshots, and EBS amounts. Each additional static IP address is charged at a small hourly rate. You can verify how many EIPs are in use in the AWS console.

Unused Elastic Load Balancers

ELBs, which are widely used in front of web servers, distribute received application traffic dynamically. Moreover, they scale resources to satisfy traffic demands and are configured to keep the number of EC2 instances operating to a minimum. You’ll be typically charged for each ELB on a monthly basis, regardless of whether you use it or not, as well as per GB transferred.

An ELB is considered as “unused” when there is no EC2 target instance registered or when the target instance is not healthy. You can find unused Application Load Balancers (ALBs) and Network Load Balancers (NLBs) and delete them. You should also uninstall all ELBs connected with an EC2 instance before you can terminate it.

Conclusion

These aren’t the only AWS charges that could be causing your headaches. Unused services initiated in AWS OpsWorks, unhealthy instances, and charges for unnecessary API calls are all possible sources that may be pumping up the AWS bill.

As companies adopt the cloud more intensively, the hidden and unexpected charges can surprise and overwhelm them. This is probably the price to pay for AWS’s rapid rollout of services and the flexibility to easily enable you to spin up these services.

Some of the most common surprising costs that companies report are the following:

Stale resources
Infrastructure scaling and increased provisioning
Data transfer and storage request and retrieval
Performance activities
Support

However, the benefits you get are priceless. In order to prevent enormous AWS bills and take the most of what you’re paying, you should take control of your costs. Finding a tool that can monitor your bills and alert you if something’s odd is the easiest way to achieve this.

We ZippyOPS, Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, and Security

Services offered by us: https://www.zippyops.com/services

Our Products: https://www.zippyops.com/products

Our Solutions: https://www.zippyops.com/solutions

For Demo, videos check out YouTube Playlist: https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro

Relevant Blogs:

How To Trigger AWS Lambda by SMS

Decoding Disaster Recovery Scenarios in AWS

Removing the Bastion Host and Improving the Security in AWS

A Guide to AWS Instance Scheduler