@themainkun@brankopetric00 EC2-Other is a catch-all. it's usually EBS volumes/snapshots, NAT Gateway data processing, inter-AZ transfer, or the newer public IPv4 hourly fee. in Cost Explorer set service to EC2 and group by usage type, that'll break out which line is actually driving it.
@Subbu2860@Im_IrushiK@yashmp2004 That one gets people because DeleteOnTermination defaults to false on non-root volumes. Check for snapshots with no source volume too. Filtering Cost Explorer to Amazon Elastic Block Store confirms what's still charging.
Every new CloudWatch log group defaults to "Never expire."
So most accounts are one forgotten incident away from a permanent storage line.
What retention default would you actually set for a small AWS account?
- different per environment (short dev, longer prod)
- same everywhere
I'd check IncomingBytes per log group to find which function is producing the volume.
Fix pattern:
drop the debug log level back down
set retention by environment on the group
keep longer retention only where audit or incident response needs it
A healthy Lambda can still create a log bill.
Scenario:
Traffic doubles.
Debug logging stays on.
The function works fine.
CloudWatch DataProcessing-Bytes starts climbing.
What would you check first?
Answer + fix below.
For a while it was reactive: a spike would tip us off, then we'd run scripts across each env to catch anything in "available" state plus snapshots whose source volume was already gone, and clean from there. Works, but the charges already landed by then, and snapshots are the sneaky half since they're incremental and an AMI can pin one in place. That gap is why we're building continuous scanning into Cloud Cost Clinic, so the leftovers get caught as they accumulate instead of after the bill spikes.
AWS shipped the FinOps Agent, and it's genuinely useful: it watches Cost Anomaly Detection, traces a spike through CloudTrail, and names who caused it.
The catch for small teams: it's reactive, and it assumes you already turned that cost stack on.
What it does and doesn't: https://t.co/Z5XJ6NqgS6
Common AWS cost mistake:
Turning on debug logging during an incident and never turning it off.
The incident ends. The logs keep flowing. New log groups default to "Never expire," so the storage line only ever goes up.
Safer check:
sort log groups by stored bytes, then by incoming bytes. The first list shows old retention decisions. The second shows the noisy producers still adding to it.
@Aniruddhaaaj7 cross-AZ shows up specifically as DataTransfer-Regional-Bytes in Cost Explorer when you group by usage type, so it's easy to size once you know the name to look for. the usual hidden drivers are chatty services split across AZs and load balancers with cross-zone enabled.
the gateway endpoints for S3/DynamoDB are underrated since they're free. one thing worth doing before re-architecting: pull NATGateway-Bytes in Cost Explorer to check how much is data processing vs the flat hourly charge. sometimes the hourly baseline is the bigger line and endpoints won't touch that part
free tier catching people out is so common. honestly the thing that saves you isn't more credits, it's a $1 budget alert set on day one so a forgotten resource can't quietly run all month. for actual credits, AWS Activate or the GitHub Student pack are the legit routes if you qualify
@fromcodetocloud yeah they expire on a fixed date, not after 6 months of usage. whatever's left on that date just disappears, no rollover. you can see the exact expiry and remaining balance under Billing > Credits in the console, and it's usually in the original credit email too.
@okey_amy That kind of runaway needs guardrails before the agent can create anything expensive. I’d pair tight IAM with low AWS Budget thresholds and Cost Anomaly Detection so the first signal is an alert.
@braddwyer That log spam find is painful, but it’s a great signal. After Cost Explorer shows the logs line, I’d check the top log groups by IncomingBytes and trace those back to code.
@emil_priver That $100/day log jump is exactly the kind of thing worth catching on the daily curve. Cost Explorer by service + usage type shows the spike first; then CloudWatch IncomingBytes by log group usually points at the noisy service.
CloudWatch Logs bills you twice: once to ingest, then every month to store.
The useful split in Cost Explorer:
DataProcessing-Bytes = ingestion (today's noise)
TimedStorage-ByteHrs = storage (every "Never expire" decision you ever made)
Quick review:
- log groups with no retention set
- biggest stored bytes
- highest IncomingBytes this week
- which of those are dev/staging
@chaulfield Forgotten compute is one of the cleanest surprise-bill patterns. I’d check the daily cost curve plus EC2 usage types first, then set a low forecasted budget alert so a runaway instance shows up while it’s still small.
@brankopetric00 The useful split is `NatGateway-Bytes` vs `DataTransfer-Regional-Bytes`. Those two usually explain whether the pain is NAT processing, cross-AZ traffic, or both.
EBS snapshots bill on stored changed blocks, so the cost creeps as chains grow.
Before deleting one, four checks:
1. AMI reference? Deregister-before-delete order matters.
2. AWS Backup or DLM policy managing it?
3. Restore expectation - is this someone's rollback path?
4. Approved next action written down?
Age tells you where to look. The references tell you what is safe.