The " Free Tier " in AWS gives you some stuff for free for a certain time period. For example, you get 5GB of S3 storage for the first 12 months. If you go over 5Gb, you pay for what's above that. After 12 months, you pay for all of it. For EC2 instances, the "free tier" gives you "750 hours per month" of t2.micro (or t3.micro) instance for the first 12 months after creating the account. There are just under 750 hours in a month, so you can run one t2.micro instance free for a year. If you run two t2.micro instances, the daily cost explorer will show that they are both free for the first 15 days, and after that you pay for them for the rest of the month. You could also run 750 of them for one hour once a month for free. Or anything in between. Do also spend time reading up on the costs of AWS resources. The virtual disk on an EC2 instance is called an EBS volume . It has a separate lifecycle, and a separate billing line, and its own free tier allocation. You will also pay for data out of AWS (first GB out per month is free - and doesn't expire after 12 months) and everything after that is billed at $0.09 per GB out to the internet. Do make time to read the docs so you don't get nasty surprises. Also switch on Billing Alarms , and set yourself a reminder to visit the Cost Explorer every day. For further best practice advice, try this for bedtime reading . Good luck

A good explainer for what's happening is at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html > In Unlimited mode, if the instance bursts above baseline CPU utilization, then the instance first uses the accrued credits to burst. If there are no accrued credits remaining, then the instance spends surplus credits to burst. When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. **If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a flat additional rate per vCPU-hour.** The bit in bold is highlighted by me, and this is what is happening to you. There's a worked example here https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/unlimited-mode-examples.html#t3_unlimited_example Take a look at the CPU usage stats in the Monitoring tab of the EC2 section of AWS Console, what's the CPU usage looking like in there? You mention that your workload isn't CPU intensive, but bear in mind that the t3.micro (the only T3 instance type that's in-scope of free tier, so it has to be this that you're running) has only 1GB of memory and two cores, and that everything else (not just your webscraper) has to run inside that. Usually that is close to negligible, but suppose your workload is consuming a lot of memory - as free memory becomes scarce (and there's only 1GB of it to start with) eventually the kernel swapper will come into play and start to consume more and more CPU as it looks for scraps of memory that it can free up. Not saying this is happening in your case, but these are the kind of things that may not be immediately apparent, but will still contribute to CPU utilisation. Anyway, this is getting away from the main point about why this item is appearing on your bill. If you still feel you have been wrongly charged then raise a billing support case with AWS https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-get-answers.html#billing-support

If you are just running a Drupal website, you will need an EC2 instance with EBS storage and an Elastic IP address (all EC2 instances have SSH access). The EC2 instance (t1.micro) will be free (for 1 year, if you are a new customer)

You get 10GB of EBS storage - the default Amazon Linux AMI has an 8GB root volume. I would recommend shrinking this down to about 4 GB and attaching a second 6GB volume to your instance (at least personally, I like to keep my data separate from the root volume). One area where you might incur costs are for I/O. Amazon's Linux AMI is quite efficient, but depending on your drupal setup and traffic, it would not be unexpected to exceed the 1M I/Os you get per month.

Ideally, you will use EBS snapshots for your backups, however, that is very dependent on the amount of data you have. This is one of the reasons I like to split the root volume from my data. It is very easy to exceed 1GB of snapshot storage, and it can be quite difficult to estimate your necessary snapshot space (the first snapshot will be around 50% of your used space (depending on how compressible your data is). Each subsequent snapshot will take much less, since it is a differential backup, but looks at changed blocks as opposed to changed files. Alternatively, you can take more traditional backups (tar.gz) and upload them to S3 (remember though, that generating those backups result in I/Os).

Your final cost will come from bandwidth - 15GB per month is included in the free tier. Determine your current bandwidth usage to see whether or not you will go over.

At any time you can view your current account activity on Amazon's site, so you can monitor if you are getting close to the threshold values. Unfortunately, there is no way of setting caps on resource usage on AWS - whatever you use you have to pay for.

I would recommend setting up an EC2 instance, but keeping your existing host operational to begin with. You can switch your DNS to point to your AWS Elastic IP and try it out, keeping an eye on your Account Activity. If you find that everything is well within an acceptable range, you can do away with your existing host, otherwise, it is a simple matter of reverting your DNS and rsyncing any changes to go back to your old host (remember to delete your snapshots, EBS volumes, and stop your instances otherwise you will continue to incur costs). AWS also provides 'reports' with hourly activity broken down by resource usage - they are a bit hard to read, but you should be able to make sense of them. They can help you to determine when and what might be causing your usage to to be higher than normal.

Just to recap: you should be able to predict bandwidth usage in advance - which means that I/O will be the main factor that is hard to predict (and snapshot usage if you opt to go that root).