Your AWS bill climbed again this month, even though traffic stayed flat and nobody shipped anything substantial. That gap between the infrastructure you think you are running and the infrastructure you are actually paying for is where nearly all cloud waste accumulates, and closing it rarely requires the kind of rewrite that most cost-cutting conversations end up circling around.Most advice on this topic stops at turning on Cost Explorer and tagging your resources, which is reasonable enough as a starting point and does very little once you have done it. What follows instead is five specific changes with published before-and-after numbers behind them, along with the reasoning you need to work out which of the five actually apply to your environment.Why does an AWS bill grow when nothing changed?Costs drift upward because defaults accumulate quietly. Every service you launch arrives with a default runtime, a default instance size and a default processor architecture, none of which were chosen with your particular workload in mind, and because nothing visibly breaks, nobody ever goes back to revisit them. Layer eighteen months of that on top of ordinary staff turnover and you end up with an account containing workloads that nobody currently employed can fully explain.A London-based foreign exchange company found itself in precisely that position. Successive departures had left its AWS environment undocumented, the monthly bills were rising without any obvious cause, and a single IAM access key had been sitting active for 1,198 days before anyone noticed it. The Estonian AWS partner Perfsys, brought in to review the setup, later published what the audit turned up. None of it was exotic. It is simply what a three-year-old AWS account tends to look like when no one has been made responsible for governing it.1. Audit before you optimize anythingThe temptation when a bill spikes is to start deleting things, which usually costs more than it saves because the resources that look expendable and the resources that are genuinely wasteful overlap far less than you would expect. Finding out where the money actually goes has to come first.The structured version of this exercise is an AWS Well-Architected Framework Review, which works through a defined question set across five pillars, one of which is cost optimization. In the London review, 24 of the 57 questions were covered, with supporting data pulled from the AWS Well-Architected Tool, Amazon Inspector and Trusted Advisor. That combination surfaced more than twenty critical vulnerabilities including remote code execution flaws in Windows and Chromium, deprecated Lambda runtimes still serving production traffic on Node.js 14 and Python 3.8, unencrypted RDS backups, and functions configured with 900-second timeouts that nobody had ever justified. On the cost side, AWS Compute Optimizer identified an estimated 41% monthly saving available on the company's ECS Fargate workloads.The review also qualified the company for $5,000 in AWS credits, which is worth knowing if you are weighing up whether an assessment is worth paying for. AWS partners can frequently unlock funding attached to this kind of work, so the exercise sometimes carries a negative net cost.One caveat on Compute Optimizer specifically: give it at least fourteen days of CloudWatch metrics before you act on anything it tells you, because rightsizing decisions made from a three-day sample tend to produce recommendations you will be reversing within a month.2. Check which processor your Lambda functions are running onIf your Lambda functions are still executing on x86_64, there is a straightforward percentage available to you, since AWS benchmarks put arm64 on Graviton2 at up to 19% better performance and 20% lower cost for an identical workload. The reason so many functions never move is that x86_64 is the default, so the architecture gets selected by omission instead of by any deliberate engineering decision.Tibica, a serverless application marketplace, went through this migration in 2023 after arriving at the problem from the latency side. Their event-driven architecture was scaling correctly and the cost was predictable, but response times felt sluggish, and because their product runs dozens of workflow steps in sequence, each small delay compounded into something users could feel. An assessment found that almost every function was still on x86_64, and the migration that followed took three weeks of updating function configurations and validating behavior across the affected API Gateway integrations.MetricBeforeAfterChangeAverage Lambda response time2.7s2.2s-17%Full user workflow duration53.8s41.9s-22%Lambda compute costbaselineoptimizedapprox -20%No application logic was rewritten and no infrastructure was rebuilt, which is what makes this worth doing early in any cost programme. The saving also recurs indefinitely, applying again every month in a way that one-off cleanups like deleting old snapshots never will.Before you switch, confirm that your runtime and any native dependencies ship arm64 builds, and run your full test suite against the new architecture instead of assuming parity. Interpreted workloads generally move without incident, while anything compiled deserves a closer look.3. Ask whether Lambda belongs in the request path at allThis is the fix teams almost never consider, and in the case below it produced the largest single reduction of the five.Tibica returned with a second and more interesting problem, in which cold starts were adding close to two seconds of delay to multiple workflow steps. Every request was routed through API Gateway to Lambda, with a custom Lambda authorizer layered on top for access control, and tracing those workflows with AWS X-Ray revealed that the majority of requests were simple GET operations carrying no processing logic whatsoever. Those requests were paying for a function invocation whose only real job was relaying a database read.The resolution was to take Lambda out of that path entirely by having API Gateway query DynamoDB directly through Velocity Template Language, which removes the cold start at source because no function is ever initialized. The same pattern was then extended to straightforward PUT and POST operations.MetricBeforeAfterChangeGET request latency1.74s0.61s-65%Write operation latency2.69s1.99s-26%Average workflow duration42.8s20.4s-52%Lambda compute costbaselineoptimized-50%Half the Lambda compute cost on those workflows disappeared, and while DynamoDB request charges rose slightly, the net reduction still came to 50%.The boundary here deserves stating honestly, because direct integration only suits stateless operations that map cleanly onto a single database action, and anything involving conditional logic or data transformation belongs in a function. VTL is also genuinely unpleasant to write and debug, so what you are trading is developer ergonomics for latency and cost, which is a reasonable trade on high-volume read paths and a poor one almost everywhere else. Identifying which requests qualify requires trace data, which is why the audit has to come first.4. Question any fixed monthly fee attached to variable demandFlat vendor pricing punishes seasonal businesses by charging peak rates through the quiet months regardless of whether anyone is using the product, and the effect is easy to miss because the line item never changes.Infoplay, which manages more than a hundred digital screens across ferries in Sweden, was running a third-party content management system on exactly that model in an industry that swings hard between holiday demand and off-peak silence. The serverless replacement took three months to build on Lambda, API Gateway, S3 and DynamoDB, with MediaConvert handling format conversion and Cognito managing access, after which monthly operating costs fell 80% off-season and 60% at peak with no loss of functionality. The billing model simply started tracking real usage.Identity is the other place this pattern shows up reliably. When my-vpa, a Cologne-based virtual assistant company, needed single sign-on across five internal systems, both Auth0 and Okta would have solved the problem while charging per user in perpetuity. They deployed Keycloak on AWS instead, running on EKS across two availability zones with RDS behind it, and a custom user federation provider allowed Keycloak to read their existing MySQL user base directly so that no user had to re-register. Implementation took roughly five weeks and operating cost settled near $60 per month against hundreds for a managed alternative, a reduction of more than 90% that has now held for five years through 10x user growth and upgrades spanning Keycloak v3.1 to v23.The trade-off is real and self-hosting moves the maintenance burden squarely onto your team, since five years of version upgrades represents five years of work that somebody has to own. Per-user pricing remains the simpler choice right up until the point where you succeed, at which stage it quietly becomes a tax on growth.5. Make cost review a monthly habitCost work fails when it happens once, because you clean up, the bill drops, and two years later the drift has put you back where you started with nobody having watched it happen.A workable monthly pass takes about half an hour and covers six things: any service whose spend moved more than 15% month over month in Cost Explorer, the current Compute Optimizer recommendations for over-provisioned resources, unattached EBS volumes alongside idle load balancers and stale snapshots, CloudWatch log retention settings where indefinite retention on chatty Lambda functions becomes expensive without ever announcing itself, whether any newly deployed functions landed on x86_64 by default, and S3 lifecycle rules that should be moving cold data into cheaper storage classes instead of leaving it in Standard indefinitely.Working out which of these applies to youThe five fixes work as a diagnostic set, and none of them needs to be applied in order. Graviton is relevant to almost anyone running Lambda at scale. Direct DynamoDB integration only matters if your traces show a meaningful volume of logic-free requests. Replacing fixed-fee tooling becomes urgent when demand is seasonal or your user count is climbing faster than your revenue per user. The audit applies universally, because without it every other decision on this list is being made on intuition.If you would rather bring in outside help for the assessment stage, AWS cost optimization consulting for startups and SMBs from Perfsys is one route worth considering, given that they hold AWS Select Tier Services Partner status along with Service Delivery Designations for Lambda, DynamoDB and API Gateway, and the case studies referenced throughout this article are published on their site with the full technical detail behind each number.Whichever way you approach it, the cheapest question available to you right now is what a single week of traced production traffic would reveal about your own environment. Most teams already have that data sitting in CloudWatch and have never once opened it.This article was published under HackerNoon's Business Blogging program.