I use both VPS providers (for my own little experiments), and deploy to AWS at scale. There are two major reasons I can think of that, from the perspective of "I just want a monthly VPS", that AWS's pricing feels so opaque. At the end, I'll also answer your actual question of what the dang thing costs.

1. Short Instance Lifetimes

An idiomatic system running on AWS (with autoscaling, load-balancing, and CloudFormation managing AMI changes to enable immutable infrastructure) has average instance lifetime (much) lower than one month.

In my current operation, most instances live a few days at most, many far fewer (some are literally just "background processes" instantiated as whole machines, and terminate themselves when their job is done. When instances are charged by the hour, this costs far less than it would seem!)

AWS isn't a VPS provider, really. You don't use it to run your snowflakes (http://martinfowler.com/bliki/SnowflakeServer.html). It's for building systems, living bodies made out of cells that are created and die without affecting the body as a whole.

A pretty valid comparison is that AWS encourages you to use VMs in about the same way that Erlang encourages you to use processes.

You might also consider that hosts like Heroku consume AWS and then provide something with monthly fees. When AWS calls itself Infrastructure-as-a-Service, it means it; it's not for end-user developers, because end-user developers don't need control over infrastructure. AWS is for ops-teams who need to declaratively instantiate an entire virtual data center.

If you want to play at being an ops-team (and I'm not knocking that desire; it's fun and educational) you can use AWS for your tiny web-app. But it's the wrong fit, precisely because you won't need most of what AWS is trying to give you, or have answers to the compromises it wants to know your position on, because those compromises only matter at scale.

AWS also has ...

2. A Heterogeneous Substrate

AWS has both old hardware and new hardware laying around, and both older and newer data centers, and their regions (collections of interlinked data centers) are either over- or under-capacity. The prices are played with to incentivize you to use whatever currently costs AWS the least to give you.

The us-east-1 region, for example, is more expensive to launch instances in, mostly because it's pretty hard to find more places to put new DCs in the area it's in, so they want to prevent everyone from crowding into it (especially given that it's the oldest region and the default.)

AWS spot instances are another example; if you're willing to take whatever people are using the least of on AWS whenever it becomes available, you can boot up an instance for even cheaper than its nominal price, because you're running it using machines that would otherwise be (pretty much guaranteed to be) idle.

One interesting thing AWS does, is make newer instance types only compatible with newer parts of their computational substrate. AWS never truly deprecates anything: non-VPC instances, 32-bit instances, PV instances, and instances with ephemeral public IPs, are still all there for systems that were designed way back then with those in mind and are expected to stay working. (This is also why us-east-1 is still the default, by the way. Old orchestration scripts assume they'll continue to get us-east-1 if they leave the region off. You don't want your new instances suddenly sneaking off half-way across the country from your old ones...)

But AWS isn't gonna bring up any new hardware to run the legacy stuff if they can help it. There are only so many e.g. 32-bit boxes in the AWS DCs, and AWS isn't going to allocate more, since one legacy customer moves away from 32-bit instances at about the same rate that some other legacy customer scales up to need more 32-bit instances. So 32-bit instance types (which are all legacy instance types, now) all stay the same price.

The new instance-types, meanwhile—like t2.micro or this m4 series—can afford to be cheaper, since they're restricted to only launch on the modern parts of the substrate. This means both that they will get cheaper over time (because AWS will continue to grow the modern part of the substrate), and also that they start out cheaper, because the modern designs are more efficient for AWS to run in terms of computational/network overhead, power consumption, cooling, cost of replacement parts, etc.

---

Anyway, to answer your question, I didn't bother with the docs; I used the AWS calculator (http://calculator.s3.amazonaws.com/index.html). (Side note: it's "AWS calculator", not "EC2 calculator", for a reason. It's very likely some cost other than compute will swamp your compute costs. Bandwidth, for example, or S3 storage, or RDS Postgres instances with provisioned IOPS.)

Anyway, in the us-west-2 region (a new-ish region with modern DCs), a t2.micro instance (the newest tiny instance type) run on-demand (no prepaid reservation) costs $9.52/mo. The cheapest you can get is a t2.micro run with a 3-year upfront reservation: it's $4.20/mo, or $151.00 total to get a VM that will sit around for three years.

But if you just want to try AWS, all of this is irrelevant: you get a year of hobbyist-grade resources (including e.g. one year of t2.micro instance-hours) for free (http://aws.amazon.com/free/) when you sign up.