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.
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
There was no dramatic cloud horror story waiting for us.
No forgotten Kubernetes cluster. No oversized database. No fleet of EC2 instances burning money after a half-finished experiment. 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.
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. The problem was not that S3 was the wrong service. The problem was that the data had aged, while parts of the configuration had not aged with it.
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 not a bold recommendation to delete data.
It was a diagnosis. 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 plan was not “make everything as cheap as possible.”
That would have been the wrong goal.
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 was written in terms of operational behavior, not just price per GB.
Only after reviewing the plan did I temporarily expand the access key permissions.
Temporary is the important word.
Codex got enough permission to apply the lifecycle changes, verify the resulting configuration, and update the operational notes in my infrastructure repository. It did not get permanent broad access. It did not get 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 is not always visible as an immediate downward line on the next invoice. Sometimes the month in which you fix the system contains 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 not that Codex knew the names of AWS services.
The valuable part was the loop.
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.
Not the threshold for responsibility. That still belongs to me. The threshold for starting.
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 was not allowed to chase the cheapest possible bill by destroying the usefulness of the backups. It was not allowed to delete data casually. It was not asked to redesign the account. It was asked to optimize an existing usage pattern while preserving the reason that data was in S3 in the first place.
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.
The Lesson
The lower bill is the visible result, but it is not the main lesson.
The main lesson is that agents are good at this kind of neglected middle ground: work that is too small for a project, too useful to ignore forever, and too context-dependent to solve with a generic checklist.
In this case, Codex did not discover a secret AWS trick. It helped me do the ordinary things properly:
- read the bill by service;
- identify the real cost driver;
- inspect the relevant configuration;
- choose lifecycle rules that matched actual usage;
- account for transition costs;
- wait for the next billing cycle;
- document what changed and why.
The bill made me smile because the number was lower.
But the better feeling was seeing that a small recurring expense had become understandable. It was no longer a vague cloud tax. It was a configuration I could explain, revisit, and improve.
That is a more satisfying result than simply saying I saved money on AWS.
References
Share