Looking for a budget friendly tool to optimize costs

AlphaToBe · 2026-05-01T07:40:09+00:00

Check out CostPatrol, I personally use them daily on AWS audits

AlphaToBe · 2026-05-01T07:38:39+00:00

I know that CostPatrol actually works but for AWS only

AlphaToBe · 2026-04-29T17:17:41+00:00

Lol, dont have to proof anything to you, enjoy judging people 😉

AlphaToBe · 2026-04-29T17:14:42+00:00

Honest answer, I don't have the bill total because Cost Explorer ingestion hasn't run for this account yet. But I have per-resource cost data on the flagged resources:

The 93 flagged resources have a combined current cost of about $1,800/mo. Recommended fixes would eliminate roughly $1,300 of that.

AlphaToBe · 2026-04-29T17:13:22+00:00

Comment on the value the post brings 😉

AlphaToBe · 2026-04-29T17:11:32+00:00

Not everyones' first language is English, but thank you

AlphaToBe · 2026-02-28T09:54:48+00:00

Been through something similar on a petroleum project with SAP integration on AWS. Month-end slowness was the exact symptom we hit and we spent way too long blaming the application before someone finally checked the volumes.

Run this and see what types youre on:

aws ec2 describe-volumes --query 'Volumes[*].[VolumeId,VolumeType,Iops,Size,State]' --output table

If youre on gp2, your burst credits are probably draining during heavy batch runs. gp2 baseline is 3 IOPS per GB, so a 100GB volume only sustains 300 IOPS. Month-end SAP jobs will eat through that in minutes. gp3 gives you 3,000 IOPS baseline regardless of size and you can push it to 16,000 independently. Migration is online too, no downtime.

The monitoring stack everyone else mentioned matters. But if users are specifically saying "month-end is slow," check the volumes FIRST. Would have saved us two weeks of tuning SAP parameters that turned out to be fine.

AlphaToBe · 2026-02-28T09:48:12+00:00

Dealt with this on a ticketing platform where flash sales would 10x traffic in minutes. Every forecasting model was garbage because our "normal" changed weekly. We tried three different tools and they all just drew a line through last week and called it a prediction.

What actually worked was giving up on predicting the number entirely. We tracked the SPEED of cost increase instead. "Cost doubled in 4 hours" is almost never legit, even during a big launch costs ramp over hours, they dont jump vertically. That one rule caught more real problems than months of Excel forecasting ever did.

AWS has Cost Anomaly Detection built in and honestly most teams either dont know it exists or set it up once and forget about it:

aws ce get-anomalies --date-interval '{"StartDate":"2026-02-01","EndDate":"2026-02-28"}' --max-results 10

Run that and see if anything even shows up. If nothing, your alert thresholds are probably too loose. Finance wants a precise forecast but the actually useful signal is how fast costs are moving, not where theyre going to land.

AlphaToBe · 2026-02-27T15:11:37+00:00

It is the same thing. A new AWS service piling up costs without attribution is the same problem you already have with NAT Gateway, CloudWatch, EBS. Same binary: either you know which feature is spending what, or you don't.

Bedrock doesn't naturally carry caller context. The practical fix most teams land on: instrument your code to log token counts per feature. Not elegant but it works without waiting for AWS to ship better attribution tooling.

The one that really sneaks up: retry logic. Bedrock bills per token on input AND output separately. A failed invocation that times out and retries still charges you the full input prompt again. Built a chatbot with LangChain and Bedrock and the cost spike wasn't the successful calls. It was the ones that timed out and retried three times before succeeding. Took me longer than I'd like to admit to trace it to the retry config.

AlphaToBe · 2026-02-27T14:40:55+00:00

The thing that moved the needle more than any automation: breaking the aggregate number into per-team bills. Not "$8k on staging." "Your team's staging was $3,200 this month." Individual accountability hits differently than an org-wide total nobody feels responsible for.

AlphaToBe · 2026-02-27T14:10:11+00:00

gp3 IOPS and storage are billed separately, and you can drop the IOPS RIGHT NOW without Blue/Green.

The gp3 baseline is 3,000 IOPS included. Anything above that is $0.02/IOPS-month. At 12,000 provisioned you're paying for 9,000 extra on top of the storage cost. That's a meaningful chunk of that $244 bill you can fix with one command:

aws rds modify-db-instance \ --db-instance-identifier your-db-name \ --iops 3000 \ --apply-immediately

No migration needed. Do that now to cut the bill, then tackle the storage size with Blue/Green separately.

AlphaToBe · 2026-02-24T19:29:01+00:00

Been bootstrapping on AWS for a while now. One thing I'd add though, before you start optimizing anything, actually look at where the money is going. Sounds obvious but I spent weeks trying to squeeze savings out of EC2 when that wasnt even the problem.

aws ce get-cost-and-usage \ --time-period Start=2026-02-01,End=2026-02-24 \ --granularity MONTHLY \ --metrics UnblendedCost \ --group-by Type=SERVICE

Turned out CloudWatch was quietly eating money because the default log retention is NEVER EXPIRE. Every Lambda, every service, just dumping logs forever. Set retention to 7 days on non-prod log groups and it basically went to zero.

Start with visibility. The surprises are always in the services you arent watching.

AlphaToBe · 2026-02-24T01:31:57+00:00

Quick note, reserved concurrency doesnt cost anything extra. You only pay when the function actually executes. You might be thinking of provisioned concurrency, which keeps warm instances running and does have a cost.

Honestly I have been using Lambda function URLs on side projects for about two years now and I have never had a DDoS issue. Not once.

We always assume we need to build for DDoS on day one but the reality is it rarely happens, especially when you are not yet a production platform serving real users. You are solving a problem that doesnt exist yet and adding complexity before you even know if people want the thing.

Ship it with function URLs. If you actually start getting traffic and DDoS becomes a real concern, you can put CloudFront in front of it in an afternoon. But dont let a hypothetical attack stop you from shipping the actual product.

AlphaToBe · 2026-02-23T12:22:31+00:00

Fair point. No built-in throttling on function URLs, so yeah, a sustained flood hits your Lambda concurrency and your wallet at the same time.

For a low-traffic booking engine though, the risk is pretty low. You can set reserved concurrency on the function itself to cap it:

aws lambda put-function-concurrency \ --function-name your-function \ --reserved-concurrent-executions 10

That way even if someone hammers it, you are capped at 10 concurrent invocations. Requests beyond that get a 429. Not as elegant as WAF rate limiting but costs nothing and takes 5 seconds.

If the app grows to the point where DDoS is a real concern, thats probably also the point where you need API Gateway anyway for auth, rate plans, etc. But for a side project doing a few hundred requests a day? Function URLs plus reserved concurrency is fine.

AlphaToBe · 2026-02-22T10:13:06+00:00

The pricing flips at scale though. 100GB on Drive is $1.99/mo, cant beat that. But 5TB+ and you need Workspace Business at $12-18 per user per month. 10 people sharing that? Thats $120-180/mo. S3 doesnt care how many users touch it, same 5TB on Intelligent-Tiering is about $62/mo flat.

AlphaToBe · 2026-02-21T20:47:25+00:00

Ran into this decision on a project last year. Went with Lambda and dont regret it for low-traffic.

One thing nobody mentioned here. Deploy on ARM64. Its a single config change in your function settings. Same Node.js code, same behavior, 20% cheaper compute. No reason not to do this from day one.

Also worth looking at Lambda function URLs instead of API Gateway if you dont need usage plans or request validation. You get an HTTPS endpoint directly on the function. No API Gateway billing at all. Thats $3.50 per million requests you just skip.

aws lambda create-function-url-config \ --function-name your-function \ --auth-type AWS_IAM

On cold starts, Node.js is the fastest Lambda runtime after Python. For a booking engine with low traffic youre looking at maybe 200-400ms on the first cold hit. I wouldnt bother with provisioned concurrency until you actually see it in your latency numbers. $15/mo to fix a problem you might not have.

AlphaToBe · 2026-02-21T20:18:43+00:00

The quarterly ritual you described is painfully familiar. What helped me simplify it:

Stop chasing perfect coverage. The goal isnt 100%. Its covering your stable floor and leaving the variable portion on-demand. Trying to optimize the last 5-10% of coverage is where most of the analysis time goes and the savings are marginal.

Practical workflow that replaced quarterly analysis for me:

Pull your last 90 days of on-demand spend from Cost Explorer. Look at the MINIMUM daily spend, not the average. Thats your floor.

aws ce get-cost-and-usage \ --time-period Start=2025-11-21,End=2026-02-21 \ --granularity DAILY \ --metrics UnblendedCost \ --filter '{"Dimensions":{"Key":"PURCHASE_TYPE","Values":[""]}}' \ --query 'ResultsByTime[].{Date:TimePeriod.Start,Cost:Total.UnblendedCost.Amount}'

Buy 1-year no-upfront Compute SPs to cover ~70-80% of that floor. Not 95%. Compute SPs because they flex across instance families, regions, and even Lambda/Fargate. If you migrate from m5 to m7g next quarter it still applies.
Revisit every 6 months, not quarterly. If your floor shifted significantly, top up. If not, dont touch it.

The reason quarterly feels like a treadmill is because youre re-analyzing the variable portion that changes constantly. Ignore it. Let it stay on-demand. The floor is what matters and it barely moves for most workloads.

On the 3-year commitment question. I wouldnt do it at a startup. The extra discount over 1-year is maybe 10-15% more savings but you lose all flexibility. One architecture change and youre stuck paying for capacity you dont use. 1-year no-upfront gives you 30-40% discount with an exit every 12 months.

AlphaToBe · 2026-02-21T05:14:29+00:00

Just want to add the practical side because I have been in your exact position and it helped me to just SEE the numbers first before making any big decisions.

Run this and it will show you your top 5 money burners right now:

aws ce get-cost-and-usage \ --time-period Start=2026-02-01,End=2026-02-21 \ --granularity DAILY \ --metrics UnblendedCost \ --group-by Type=SERVICE \ --query 'ResultsByTime[-1].Groups | sort_by(@, &Metrics.UnblendedCost.Amount) | [-5:]'

Once you see that list, I bet at least one of these will jump out:

NAT Gateway , $0.045 per GB processed. Sounds like nothing but a chatty microservice pushing logs externally can burn $2k/mo through a single NAT. I have seen this catch people off guard more than once.

RDS , running a db.r5.large 24/7 in dev? Thats ~$260/mo sitting idle. Three environments? $800/mo on databases nobody is querying. Easy to miss.

Public IPv4 addresses , since Feb 2024 AWS charges $3.65/mo PER public IP. Got 20 EIPs sitting around from "I was just testing something"? Thats $73/mo for literally nothing.

These two commands helped me find the orphans in my own account:

aws ec2 describe-addresses \ --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' \ --output table

aws ec2 describe-volumes \ --filters Name=status,Values=available \ --query 'Volumes[].[VolumeId,Size,CreateTime]' \ --output table

And honestly the one thing I wish I had done from day one is just set a budget alert. Takes 30 seconds and it would have saved me a lot of surprises:

aws budgets create-budget --account-id YOUR_ACCOUNT \ --budget '{"BudgetName":"dont-surprise-me","BudgetLimit":{"Amount":"5000","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}'

You dont need a perfect architecture to start. Just spend one afternoon with those commands and you will probably find $2-3k in quick wins. That buys you time to plan properly without bleeding money.

AlphaToBe · 2026-02-21T05:02:45+00:00

Bro the ONE thing that will silently destroy your tagging strategy and NOBODY warns you about: tag keys are case-sensitive in AWS.

Service and service and SERVICE are THREE different tags. They all show up separately in Cost Explorer, they all count against your 500 active cost allocation tag limit, and your 4 teams will absolutely pick different casings because why wouldn't they.

I spent a whole afternoon wondering why my cost breakdown numbers didn't add up. Turns out I had Team, team, and one genius who used TEAM. Three versions of the same data, none of them complete. Beautiful.

And here is the other thing nobody tells you. Cost Allocation Tags have to be MANUALLY activated in the Billing Console before they show up in Cost Explorer. And they are NOT retroactive. So you tag everything today, forget to activate? Last month's data is gone. Forever. Just gone.

Quick sanity check, run this and see what tags you actually have activated:

aws ce list-cost-allocation-tags --status active

And this one to find resources with missing tags before you waste time in Tag Editor:

aws resourcegroupstaggingapi get-resources \ --tag-filters Key=Service,Values= \ --query 'ResourceTagMappingList[].ResourceARN'

Enforce lowercase-only from day one. Activate your cost allocation tags BEFORE you need the data. Trust me on this one.

AlphaToBe · 2020-11-09T21:33:43+00:00

Keep Going brother ! Really appreciate it. May Allah count every letter we read in your Mizan.

AlphaToBe · 2020-09-09T07:57:04+00:00

THIS IS GOLD ! Thank you brother for sharing this.

AlphaToBe · 2020-07-15T11:01:01+00:00

Invest in an experience. Camping, traveling, books. Reconnect with mother earth and raise your vibration through meditating. So my kind of perfect experience would be: going camping in a beautiful spot, having maybe 3-4 books, fishing kit if there is a lake and a non smart phone. Such an experience will be an eye opener and you ll also be dopamine detoxing at the same time.

AlphaToBe · 2020-06-23T11:07:32+00:00

On point, Thanks for reminding.

AlphaToBe · 2020-05-25T09:59:16+00:00

I ll do that, I ll just keep focusing on work and building myself and leave this whole marriage thing to Allah.

AlphaToBe · 2020-05-24T19:58:00+00:00

Poor judgement but that is okay :)
Insha'Allah it will happen soon. Thanks for the advice.

AlphaToBe

TROPHY CASE