How I Used Codex to Cut My AWS Costs
A practical story about using Codex to assess AWS spend, tune S3 lifecycle policies, absorb a transition spike, and reduce recurring cloud costs safely.
Today I received my monthly AWS bill, opened it, and smiled.
That is not my usual emotional response to cloud billing.
The number was not zero. It was still a real bill, for real storage, holding real data I care about. But it was small enough to feel different. A few months ago the same account was costing roughly four times as much, and I had mostly accepted that as the price of keeping some personal infrastructure alive.
Then I tried an experiment.
I asked Codex to look at my AWS account the way it would look at a codebase: assume there is some history, some drift, a few decisions that made sense at the time, and probably a bit of waste hiding in plain sight.
A Very Ordinary Cost Problem
The account was boring in the way personal infrastructure often is: a handful of useful things accumulated over time, with just enough friction that I had not inspected them properly in a while. There was no forgotten Kubernetes cluster, oversized database, or fleet of EC2 instances burning money after a half-finished experiment.
The cost was almost entirely S3.
That made sense. I use S3 for backups, archives, historical files, and safety copies. It is a good fit for that job, but parts of its configuration had not aged with the data.
Some files were still being treated like warm data.
In practice, they were cold. Important, but cold. I wanted them to remain recoverable, but I did not need all of them sitting in a storage class designed for frequent access.
This is exactly the kind of maintenance work that is easy to postpone. The bill was not catastrophic. The account was not broken. There was no incident forcing me to care. It was just a small recurring inefficiency, quietly billing me every month.
Starting Read-Only
The first prompt was intentionally cautious:
Look at how I am using AWS.
Tell me whether there is waste.
Propose an action plan.
Do not change anything without confirmation.I did not give Codex write access at the beginning.
I created read-only access so it could inspect the account: Cost Explorer, budgets, S3 buckets, lifecycle policies, versioning, and the parts of the configuration that mattered for cost. I wanted it to build a picture before touching anything.
The useful output was a diagnosis rather than a bold recommendation to delete data. The spend was concentrated in S3. Some lifecycle rules already existed, but they were not doing enough. Current objects in backup buckets could move through colder classes more deliberately. Old multipart uploads could be cleaned up automatically. The monthly budget was also set below the actual baseline, so the alert was not distinguishing normal spend from abnormal spend.
That was already valuable.
Before Codex changed anything, it had made the account easier to reason about.
Turning the Assessment Into a Plan
The goal was to reduce cost without making recovery worse.
Cold storage is cheaper for a reason. Retrieval time, retrieval cost, minimum storage duration, and application behavior all matter. A backup that is technically cheap but painful to restore is not automatically a better backup.
So we split the problem by usage pattern.
For long-lived backup data, the lifecycle shape became more intentional: keep new objects in S3 Standard for a while, transition older data to Standard-IA, and move genuinely historical data toward Glacier Instant Retrieval where that still preserved the recovery experience I wanted. For buckets with versioning, non-current versions needed their own rules. For incomplete multipart uploads, the right answer was simply to stop letting old upload parts sit around forever.
There were also places where being too aggressive would have been a mistake.
One bucket was connected to application-level historical access. Moving that data all the way to Deep Archive would have looked attractive in a spreadsheet, but it would have made the actual restore workflow worse. Codex caught the tradeoff because the plan described operational behavior alongside price per GB.
Only after reviewing the plan did I temporarily expand the access key permissions.
Codex temporarily got enough permission to apply the lifecycle changes, verify the resulting configuration, and update the operational notes in my infrastructure repository. It never received permanent broad access or a vague mandate to improve the account however it wanted.
The work stayed bounded.
The Bill Went Up
Then the first bill after the change looked worse.
That was the part I did not enjoy.
I had done the responsible thing. I had reviewed costs, reduced waste, applied lifecycle rules, and documented the result. Then AWS reported a month that was about 20% higher than the previous baseline.
For a moment, the obvious emotional interpretation was: great, I optimized the bill upward.
The actual explanation was less dramatic. Moving many S3 objects between storage classes can itself create transition charges. In my case, the late-month spike was largely explained by lifecycle transition operations. The account was paying the cost of moving from the old storage posture to the new one.
That is an awkward but important detail.
Cloud cost optimization may not produce an immediate downward line on the next invoice. The month in which you fix the system can contain the old run rate, the new configuration, and the one-time cost of getting from one to the other.
If I had stopped the experiment there, I would have drawn exactly the wrong conclusion.
Waiting for the Next Cycle
The next month made the picture much clearer.
Before the intervention, the account had been sitting around 17 to 18 USD per month. The month with the transition spike went above 24 USD. Once that one-time movement had passed, the following month closed at about 6.24 USD.
The S3 portion told the same story more sharply: roughly 20 USD during the spike month, then about 4.66 USD the month after.
These are small numbers. This is not a grand enterprise FinOps story with an executive dashboard and a six-figure saving.
That is exactly why I like the example.
For a personal AWS account, I would probably never have scheduled a formal optimization project. The savings were meaningful over time, but not urgent enough to push the work to the top of the list. Codex changed the economics of attention. It made a small piece of operational hygiene cheap enough, cognitively, that I actually did it.
That is the same pattern I described in AI Agents Are Making Me a Better Programmer: the agent is not only writing or changing things. It is helping me make the work explicit enough to evaluate.
What Made It Work
The valuable part was the operating loop, not Codex knowing the names of AWS services.
It inspected first. It separated observed facts from interpretation. It proposed a plan before acting. It waited for permission. It made the changes. It verified them. It left documentation behind.
That is the same standard I would want from a human operator touching my infrastructure.
The difference is that, for this kind of small maintenance job, I would not usually involve another human operator. I would either do it myself on a quiet evening, or more realistically, keep postponing it because the system was working well enough.
Codex lowered the threshold for starting while responsibility stayed with me.
The Rule I Would Keep
I would not describe this as “I gave an AI agent the keys to AWS.”
That framing misses the part that made the experiment feel reasonable.
The access was progressive:
- read-only first;
- plan review before execution;
- temporary write permissions;
- verification after the change;
- removal or reduction of operational access afterward.
The scope was also explicit. Codex had to optimize the existing usage pattern without deleting data casually, redesigning the account, or destroying the usefulness of the backups.
That distinction matters.
Reducing cloud cost is easy if you are willing to break the system. The useful work is reducing cost while keeping the system honest.
An Understandable Bill
Codex did not discover a secret AWS trick. It helped me inspect the real cost driver, match lifecycle rules to usage, account for transition costs, wait for the next billing cycle, and document the change.
The small recurring expense is now a configuration I can explain, revisit, and improve instead of a vague cloud tax.
References
Share