The AWS cloud computing model allows you to pay for services on-demand and to use as much or as little at any given time as you need. While resources are active under your account, you pay for the cost of allocating those resources and for any incidental usage associated with those resources, such as data transfer or allocated storage. To keep your costs as low as possible, you should release or terminate unused resources as soon as you are done with them.
Here's some more information you may find useful.
The AWS Free Usage Tier applies only to a limited set of AWS resources. For more information about what free tier covers, see the AWS Free Usage Tier details page. Here are a few tips for troubleshooting unexpected charges:
- Linux distribution – Make sure you used the standard distribution of Linux. SUSE Linux and Red Hat Linux, for example, are commercial distributions and aren't covered by the free tier.
SOLUTION: Terminate the instance and launch a new one using the Amazon Linux AMI.
- Instance size – Only t1.micro instance usage is covered by the free tier. Other instance sizes will accrue charges until you terminate them.
SOLUTION: Terminate your existing instance and launch a new t1.micro instance.
- EBS storage – Check the amount of storage you've provisioned in Amazon Elastic Block Store (Amazon EBS) volumes. If the total amount of provisioned storage in your volumes exceeds 30 GB, you will accrue charges for the additional storage.
SOLUTION: Delete unused Amazon EBS volumes.
Unexpected charges on your account can be the result of a simple misunderstanding, or an indication of a resource configuration issue. Here are some things to check:
- Idle instances – Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Relational Database Service (Amazon RDS) instances accrue hourly charges as soon as you launch the instance, and continue accruing until you explicitly terminate the instance. If you launch an instance and then sign out of your account without terminating the instance, it will continue running and accruing charges.
- Using more than one region – The AWS Management Console displays only one region at a time. If you accrue charges but aren't able to see any running instances under the EC2 tab in the console, you may want to review the other regions by selecting each of them from the drop-down menu in the upper left corner of the console page.
|Check your Amazon EC2 Resources|
|US East (Virginia)|
|US West (Oregon)|
|US West (N. California)|
|EU West (Ireland)|
|Asia Pacific (Singapore)|
|Asia Pacific (Tokyo)|
|Asia Pacific (Sydney)|
|South America (Sao Paulo)|
- Reserved Instances – If you purchased a Reserved Instance but are still being charged the on-demand rate for your running instances, there are a couple of things you may want to check:
- Inactive reservation – If your bank declined the purchase price for your Reserved Instance, your reservation wasn't activated. In this case, the original Reserved Instance was canceled, so you'll want to make a new purchase in order to receive the benefits of a Reserved Instance. You can check the status of your Reserved Instances from the AWS Management Console.
- Reservation doesn't match running instance – Reserved Instances need to match your running instances exactly in order to receive the lower usage rate. Some things to check are operating system, instance size, and Availability Zone. You can compare your reservations to your running instances in the AWS Management Console.
- Unexpected data transfer – High data transfer charges can be the result of a runaway process on your instance, increased traffic to your website, or a misconfiguration of your resource. Here are some things to check:
- Usage reports – Download your usage reports to determine which service generated the data transfer. We recommend you start by checking the reports for Amazon EC2 and Amazon Simple Storage Service (Amazon S3).
- Review your security settings – Sometimes a misconfiguration in your security settings can allow third-party access to your AWS resources.
For Amazon EC2: Check for open ports (0.0.0.0/0) or (*.*.*.*/0). Leaving ports open like this, especially admin ports such as port 22 or port 3389, leaves your instance vulnerable to compromise.
For Amazon S3: Check your ACLs for public read/write access on your buckets.
For more information about securing your AWS resources, see our whitepaper, AWS Security Best Practices.