AWS costs can shift under you

How is it costing more when it hasn't been touched?

AWS have a decent and largely deserved reputation for not raising prices. In fact, they say:

As of September 20, 2023, AWS has reduced prices 134 times since 2006

However, even if you run an unchanging workload your costs may still increase! It is not necessarily that prices go up in the strictest sense but rather it is something else changing over time that affects your costs.

It is rare that you do not get warned about these changes. However, it is possible, in some cases quite easy, to miss the warnings. And in some cases it is just something you need to be aware of: costs will increase over time...

Here are a select few examples where this can happen.

Surprise! Introducing a new product tier...

Extended support.

Services with an extended support tier

"I am altering the deal. Pray I don't alter it any further."

Darth Vader https://knowyourmeme.com/memes/i-am-altering-the-deal

Maybe a tad unfair, there is some benefit there. Saving us from ourselves maybe, but at a price.

EKS:

https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html
- Note that you may want to leave it enabled just in case but plan to upgrade in a managed manner. Upgrades are normally fine if you are fairly well sync'ed up within the compaibility window with nodes, addons, etc. - see that chaps blogs maybe.
https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html
Cost is 6x (for control plane). May not be a huge deal if huge clusters that drown out the control plane cost. But is have dev/test/stage/nonprod/prod...
- Managed nodes could remove one barrier to upgrading?
- Note that it started in preview, then costs kicked in: https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing/, https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-support-kubernetes-versions-preview/
- https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html
  - Was there initially no opt-out? https://medium.com/@talkimhi/aws-extended-eks-support-a-costly-band-aid-for-kubernetes-clusters-120b8d537abe and https://www.chkk.io/blog/amazon-eks-extended-support
    - It would be lovely to have a full timeline with a "happens before" feature, or service summary, maybe even full liearizability checker. Linerizability checker might be good for tooling of "was anyone affecvted by this bug" by looking for indicators against deployments/conditions.
      - https://hidekazu-konishi.com/entry/aws_history_and_timeline.html
      - Could imagine a delorean in sky roads that can travel alongs to see what came when
"This release cycle is pretty fast by the time scales of many corporation’s application development lifecycles,": https://cloudsoft.io/blog/cloudsoft-spotlight-eks-extended-support
https://www.vantage.sh/blog/eks-extended-support

Now, you get warnings as you are transitioning in soon I think, but if go straight there... https://medium.com/@krishnafattepurkar/how-i-accidentally-chose-an-extended-support-kubernetes-version-on-eks-and-paid-extra-because-i-6bbad34d2d4d https://www.infracost.io/finops-policies/amazon-eks-upgrade-version-to-avoid-extended-support-costs/

RDS:

https://www.vantage.sh/blog/amazon-rds-extended-support
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support-overview.html
This was definitley a "take action or suffer": https://aws.amazon.com/blogs/aws/your-mysql-5-7-and-postgresql-11-databases-will-be-automatically-enrolled-into-amazon-rds-extended-support/
https://repost.aws/questions/QUeJxMYVGuSd6veUeoWC3flg/why-do-i-still-see-rds-extended-support-enabled-after-upgrading-mysql-version
https://aws.amazon.com/blogs/database/introducing-amazon-rds-extended-support-for-mysql-databases-on-amazon-aurora-and-amazon-rds/
https://aws.amazon.com/blogs/aws-cloud-financial-management/estimating-the-charges-for-amazon-rds-extended-support/
- This gives a billing code to look out for. I should make some categorisation Rego.
Note that there is a snapshot restore behaviour, so need to look out for old sanpshots you may wish to restore too. Do you have any raw access to those snapshots? If not then you may be in a sticky situation if there are upgrade issues?

I shoudl write a blog looking at how many patches you actually get for this, and what the severities are. In general too, for EKS, for RedHat EUS etc. Refs may include:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.CVE_list.html
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support-versions.html
https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extendedsupport.html
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support.html
For EKS releases: https://repost.aws/questions/QUK8MBphGoQWepOoKh2qIf7w/implications-of-automatic-eks-platform-version-update

Surprise! The cost of simply existing just indirectly increased...

This is a tricky one. It's not a new direct cost for a resource you use but rather a new, indirect, associated cost that is incurred.

I already feel like this is at risk of sounding quite tenuous, so let's make it concrete...

Step 1: you are keeping CloudTrail data, maybe a trail logging to S3, or perhaps in a CloudTrail Lake
Step 2: you are using resource type X, let's say S3 Tables
Step 3: your use of this resource creates CloudTrail events
Step 4: it costs a small amount to store these events
Step 5: AWS starts generating Cloudtrail events for S3 Tables maintenance operations
Step 6: it costs an extra small amount to store these new events
Step 7: your overall cost of using S3 Tables has increased, though the service list price is unchanged

Now, is this a huge cost increase? Probably not. It is possible that the CloudTrail costs are carried by a different team and you never have to think about it during your use of S3 Tables, but there are two ways of looking at it:

You pay more for the same use of S3 Tables today compared to yesterday
CloudTrail costs incrase over time as the service gains new event coverage

Whichever viewpoint is held by your organisation, you've done nothing but your costs have increased. To be fair, you have (arguably) gained some value.

And this pattern can play out in other, similar, often more expensive ways, such as AWS Config starts supporting additional resource types in the regions you use.

Step 1: you are using AWS Config
Step 2: you make use of resource type X
Step 3: your AWS Config costs are steady
Step 4: AWS adds resource type X to its "Supported Resource Types for AWS Config"
Step 3: your AWS Config costs increase

Note that with Config you might not be loggin all resources, so it might not be automatic. See the next section, keeping up!

Surprise! The cost of keeping up increased...

An AWS service starts becoming available over VPCe and you want to use it (a mindful choice)

Is there a Security Hub or GuardDuty angle. Cloudtrail fo sure. Conformance packs.

CloudTrail : https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-s3-generates-aws-cloudtrail-events/

IP addresses kind of fit into this, but directly.

EKS extended support.

Surprise! Introducing a new billing dimension...

Or tier like extended support. Think about the terminology.

Surprise! This resource is no longer free...

Charging for IPv4 addresses

This was a change that AWS introduced to, in their own words, "encourage you to be a bit more frugal with your use of public IPv4 addresses and to think about accelerating your adoption of IPv6 as a modernization and conservation measure".

The change came into effect on February 1st 2024, with a blog post stating:

We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not (there is already a charge for public IPv4 addresses you allocate in your account but don’t attach to an EC2 instance).

This was a cost increase for, I would say, pretty much all customers of AWS. Sometimes a small bump, sometimes a large one, depending on the size and shape of your cloud estate. I will note though the date of the announcment: 28th July 2023. A good 4 months or so.

Not a price increase per se...

Surprise! This service is no longer free...

Services leaving (public?) preview

Interconnect free during beta but says will remove them before GA: https://www.gadgets360.com/internet/news/amazon-aws-interconnect-preview-launch-multicloud-service-9735029
- https://docs.aws.amazon.com/interconnect/latest/userguide/what-is.html#:~:text=At%20the%20time%20AWS%20Interconnect%20becomes%20Generally%20Available%2C%20any%20%E2%80%9Cpreview%E2%80%9D%201Gbps%20connections%20will%20be%20removed%20from%20your%20account.
Security Hub action needed: https://docs.aws.amazon.com/securityhub/latest/userguide/public-preview-to-ga-migration.html
AWS DevOps agent not yet leaving preview: https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-public-preview-pricing-and-limits.html
- https://aws.amazon.com/blogs/aws/aws-devops-agent-helps-you-accelerate-incident-response-and-improve-system-reliability-preview/
- https://aws.amazon.com/about-aws/whats-new/2025/12/devops-agent-preview-frontier-agent-operational-excellence/

https://www.linkedin.com/posts/paulchinjr_aurora-dsql-is-leaving-preview-to-delete-activity-7329147668595707904-4Lrs/

https://www.google.com/search?q=OpenSearch+Serverless+convert+preview+to+ga&sca_esv=591f49c5cb9ac867&biw=1440&bih=779&aic=0&sxsrf=ANbL-n4YKjv8T1wO7NB9zfQ0wBExqQRZKg%3A1769091473290&ei=kTFyac66EZi3hbIPkbC0oA4&ved=0ahUKEwiOx9ymq5-SAxWYW0EAHREYDeQ4HhDh1QMIEQ&uact=5&oq=OpenSearch+Serverless+convert+preview+to+ga&gs_lp=Egxnd3Mtd2l6LXNlcnAiK09wZW5TZWFyY2ggU2VydmVybGVzcyBjb252ZXJ0IHByZXZpZXcgdG8gZ2EyBRAhGKABSI1EUOgCWNg-cAN4AZABAJgB1gSgAa8nqgEMNC4xMC41LjIuMS4yuAEDyAEA-AEBmAIaoALBJcICChAAGLADGNYEGEfCAgQQIxgnwgILEAAYgAQYkQIYigXCAgUQABiABMICChAAGIAEGBQYhwLCAgYQABgWGB7CAgcQIRigARgKwgIEECEYFcICCBAAGIAEGKIEwgIIEAAYogQYiQXCAgUQABjvBZgDAIgGAZAGCJIHDDQuMTMuNS4xLjIuMaAH5lqyBwwxLjEzLjUuMS4yLjG4B7YlwgcGNi4xNi40yAcpgAgA&sclient=gws-wiz-serp

EKS:

Note that it started in preview, then costs kicked in: https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing/, https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-support-kubernetes-versions-preview/
Again, AWS are note really in the busioness of surprises. Istead of an auto-upgrade, which most don;t want, you have a stay of execution. But now you have to pay a bit. They changed the tradeoff you make. It is your part of the deal to stay on top of these things, though I'm not sure exectly where this is stated.

OpenSearch serverless looks like it started in preview as paid: https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-is-now-generally-available/

Surprise! Your change was not forever: stopping an RDS instance

This one shouldn't be a surprise because the documentation on stopping an RDS instance mentions this behaviour and it is called out for acknowledgement if stopping an RDS instance using the AWS management console. The relevant, and first, sentence from the documentation is (with emphasis mine):

You can stop your DB instance intermittently for temporary testing or for a daily development activity, for a maximum of 7 consecutive days.

However, I've seen a lot of wasted cloud spend on RDS instances that had been stopped but automatically restarted. Whether it is from using tooling that does not give the warning in the managemnt console, or from "I'll definitely remember to come back to this within 7 days", the result is the same:

If you stop an RDS instance and walk away, 7 days later it will start automatically and you will incur the running costs of any RDS instances (along with the storage, which you pay for even when stopped too).

On-demand self-service and rapid elasticity are widely understood to be essential characteristics of cloud computing.

However, "on-demand self-service" is probably best thought of as the request being on-demand with the fulfilment time somewhere between instantaneous and it depends, with the option of never.

You can work in the cloud for a long time without really noticing or being affected by this behaviour, with many common resources being provisioned near-instantaneously.

This post is here to cover a selection of the times where your action is decoupled from AWS reaction but also where time otherwise is an important consideration.

Or things that depend on previous actions. Like CuR, such that you need to visit ahead of time, you can; tjust get the report for the first time on-demand. And it only updates on a period with perhaps no real guarantees IIRC.

TO THINK ABOUT: should this post only really touch on eventually consistency and do then check actions? Or just the less common ones.

"Understanding unexpected charges" is an AWS docs page (https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html), this is my take on things you are more likely to stumble upon as a more casual user. Things that you might stumble upon.

Actions needed ahead of time

Quota increase - possible manual approval? The CUR thing below. Location of credits at month end plus other caveats

Surprise! Your billing dimensions are changing

Aurora Serverless v1 migrated to v2. And note you may drop into extended support at teh same time too! https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html

https://lumigo.io/aws-serverless-ecosystem/aws-aurora-serverless/ https://stackoverflow.com/questions/74381092/recently-updated-to-aurora-serverless-v2-from-v1-rds-bill-increased-3x-how-can

Surprise! Using less is going to cost you more.

The elasticity of the cloud is a core feature, with resources elastically provisioned and released as needed.

So surely using 2 EC2 instances for 5 minutes - that's 5 minutes including create, use, destroy - is more cost effective than using 1 instance for an hour? Surely this is the case, because we know how time works.

In general, absolutely this is the case, it's common sense. However, well, it depends, as each "partial instance-hour consumed will be billed per-second for Linux, Windows, Windows with SQL Enterprise, Windows with SQL Standard, and Windows with SQL Web Instances, and as a full hour for all other OS types."

So, away from the world of per-second billing (which became widespread in AWS in late 2017 those 2 lots of 5 minutes are in fact 2 lots of a "partial instance-hour consumed" and hence billed as 2 hours, or twice as much as having an instance running for the full hour.

RedHat Enterprise Linux (RHEL) used to be one of the usual suspects here, with per-hour billing, but that changed in April 2024 to per-second billing. Not entirely off the hook though, prices revised July, meaning that come July you may well get a price increase. Pricing of Marketplace offers is not controlled by AWS though (is this?).

Eample of disposable VMs, like for CI/CD runners. "Security" and architecture say use RHEL, but real security says destroy. Cost agrees.

SUSE

Note that the says "Pay less by using more" (https://aws.amazon.com/pricing/) talking about volume-based discounts.

Surprise! Deleting things costs money?!?!

Not usually!

AWS Config costs when you record a deletion. Even more when you delete rules.

Any logs of deletion? Small incidental cost, CloudTrail bucket etc.

hourly billing you waste money, but doesn't cost.

Surprise! Time travelling into the past

All this "take an action then wait for the effect"...

What do we want? Time travel! When do we want it? It's irrelevant!

CUR resource allocation tags. If you wish you'd had them in the past... enable then and you kinda did?!?!

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-allocation-backfill.html

On the negative side - restoring a Private CA. Get charged for the time it was "mostly dead" (Princess Bride): https://aws.amazon.com/private-ca/pricing/. That's awkward, is there a cost for that time or not, really? No charge if you do not restore it...

Services that are not "on demand"

Cost reports need visiting to enable.

You cannot access it on-demand for the first time. You can after.

Times when usually quick requests are slow

Lack of capacity. Do a variety of instance types.

Eventual consistency

Notes

Time-sensitive things in AWS. Things that are not there by default, things that align to month end, etc

ASG are autonomous. Karpenter. Agents/controllers.

Free trials Free tier (not now, or less so?) Beta periods then payment may be needed

Extended support in EKS

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar
- Default for new and exsiting cluster is opted-in to EXTENDED support

Hourly billing for certain EC2 images Anything not prorated? Anything? Not private CA but I thought it was at one point

Secutity Hub and Guard Duty not real time due to log time and processing time.

Quotas and things that need warming up

number of accounts
lead time on requests for quotas
lambda scaling. Chunks of elb and natgw? Another post, do some research.

Scratch

there are certain resources or other actions that do not have an immediate effect.

Expecting the results of your actions to be immediately effective is not always correct

Time sensitive vs time dependent. Am I firmly in one camp?

https://www.lastweekinaws.com/blog/sagemaker_is_responsible_for_my_surprise_bill/

End of free trial year (or $200 now?).

https://www.reddit.com/r/aws/comments/120ecpi/comment/jdk1q5k/

Exchange rate changes? More days in the month?