The real spend comes from delivery, storage, and analysis, not the toggle itself
- VPC Flow Logs are billed as vended logs, so the main charge is for data delivery, not just for enabling the feature.
- CloudWatch Logs is the most convenient option for live troubleshooting, but it adds archival and query costs.
- S3 is usually the better long-term archive because storage is cheap, though delivery charges still apply.
- Firehose is a pipeline choice, not a discount choice; it adds ingestion and delivery charges of its own.
- The fastest way to reduce spend is to narrow scope, shorten retention, and tag the destination resource for chargeback.
How the billing model really works
I usually think about flow log spend in three layers. First is the vended-log delivery charge, which AWS applies based on how much data you publish and which destination you choose. Second is the destination itself, because CloudWatch Logs, S3, and Firehose each add their own storage or ingestion line items. Third is whatever you do with the data after it lands, such as search, transformation, or long-term retention. The important detail is that the log feature itself is not the whole story. Flow logs are collected outside the path of your network traffic, so they do not affect throughput or latency, which means the trade-off is mostly financial and operational rather than performance-related. For observability teams, that is useful: you can tune cost without worrying about breaking the network.| Cost layer | What it covers | Why it matters |
|---|---|---|
| Delivery | Bytes published by the flow log | This is the base charge and it applies regardless of destination. |
| Retention | Storing logs in CloudWatch or S3 | Keeping data longer always raises the bill, even if traffic volume stays flat. |
| Pipeline | Firehose ingestion and delivery | Useful when you need streaming delivery, but it adds another meter. |
| Analysis | Queries and downstream tools | Search-heavy workflows can cost more than the storage itself. |
One subtle point matters in 2026: AWS’s vended-log tiers reset at the start of every month, so a quiet month can look cheap and a bursty month can jump to a higher rate band quickly. Once you separate those layers, the destination choice becomes much easier to judge.
Why CloudWatch Logs is usually the expensive default
CloudWatch Logs is the most natural home for hot network telemetry because it gives you fast searching, dashboards, and alerting in one place. I still recommend it for incident response, but I would not treat it as a cheap archive. The convenience is real, and so is the cost.
In AWS’s published pricing example for vended logs, the first 10 TB is charged at $0.50 per GB, then the rate steps down to $0.25, $0.10, and $0.05 per GB as volume increases. There is also archive cost in the same model, shown at $0.03 per GB-month in the example. That means even moderate log volume adds up quickly: 1 TB of delivery alone is about $512 before you count retention or querying.
The bigger numbers make the same point more clearly. AWS’s own 72 TB example comes out to $13,414.40 in delivery charges plus $921.60 in archival, for a total of $14,336. That is not a niche edge case; it is what happens when a noisy environment is logged too broadly and kept hot for too long. I see this most often in security teams that leave everything searchable because it feels safer, then discover the bill is paying for convenience they rarely use.
CloudWatch is still the right answer when you need to investigate quickly or build near-real-time alerts. It is simply not the right place for every byte of history, especially if the logs are mostly there for occasional forensics. If the data is mostly for compliance or long-tail investigation, S3 changes the economics completely.
When S3 is the better archive
S3 is the option I reach for when the logs need to exist, but do not need to live in a hot search index. AWS still applies the vended-log delivery charge, so S3 is not a way to bypass the base cost. The difference is that storage is usually much cheaper than keeping the same data in a searchable logging service.
As a rough US-East benchmark, AWS lists S3 Standard from $0.023 per GB-month. That means 1 TB of retained flow logs would be about $23.55 for storage before request costs, lifecycle transitions, or any conversion step. For UK teams, the exact number will differ by region and currency, but the shape of the bill stays the same: delivery is the fixed part, storage is the cheap part, and lifecycle policy is where the savings compound.
There is one practical compromise to keep in mind. Flow log files arrive in S3 at 5-minute intervals, which is perfectly fine for audits, batch analysis, or Athena-based investigation, but not ideal if you want immediate searching during an active incident. That is why I often prefer a split model: short-lived hot retention in CloudWatch for the operational team, and S3 for the longer archive.
| Destination | Best for | Typical extra charges | My take |
|---|---|---|---|
| CloudWatch Logs | Live search, alarms, incident response | Delivery, archival, and query costs | Fastest path, but the priciest when kept hot |
| S3 | Long retention, audits, Athena analysis | Delivery, storage, and optional conversion | Best default archive for most teams |
| Firehose | Streaming into analytics or storage pipelines | Delivery plus Firehose ingestion and transforms | Good when you need movement, not just storage |
If the archive is the main goal, S3 usually wins on economics and simplicity. Firehose only makes sense when you need the stream to keep moving.
Where Firehose fits and why it can still increase the bill
Firehose is the destination people often pick when they want flexibility, but flexibility is not the same as savings. AWS says that when you publish flow logs to Firehose, standard ingestion and delivery charges apply, which means the vended-log delivery meter is still running and Firehose adds its own ingestion bill on top.
That makes Firehose useful for the right reasons and expensive for the wrong ones. It is a good fit when you need to transform, compress, enrich, or forward the data into another AWS service without building your own ingestion layer. It is a poor fit if the only goal is to avoid CloudWatch, because you do not eliminate the base cost, you just move it into a different pipeline.
As a practical benchmark, AWS’s US-East pricing shows Firehose ingestion at $0.029 per GB for the first 500 TB per month. That is not huge on its own, but it is another line item that compounds with the vended-log charge and any downstream storage or delivery costs. If you also transform the payload or send it to an external endpoint, the bill can climb further.
I tend to think of Firehose as a routing decision, not a cost-optimisation decision. Use it when you need a managed stream. Do not use it just because it sounds like a cheaper way to move logs around.
How to estimate and cut your spend before it runs away
The simplest estimate is this: monthly cost equals delivery charges plus destination storage or ingestion plus any analysis or transformation. That is enough to model most environments without building a spreadsheet that nobody keeps current. For a UK team, I would use the same structure but run the estimate in your actual AWS region rather than converting a US-East example into pounds by hand.
My rule of thumb is to reduce spend in this order: scope, destination, retention, then analysis. Scope is the biggest lever because AWS lets you create flow logs for a VPC, a subnet, or a network interface, so you do not have to log every path if you only care about one workload or one control point. If your investigation only needs a critical subnet, logging the whole VPC is often just paying for noise.
- Start with the smallest scope that still answers the question. Logging only the VPC, subnet, or network interface you actually need keeps unnecessary traffic out of the bill.
- Use CloudWatch only for hot data. Keep the active investigation window short, then move the long tail to S3.
- Apply lifecycle rules early. S3 lifecycle transitions can move older logs into cheaper storage classes before retention becomes expensive.
- Tag the destination resource. AWS supports cost allocation tags on the log group, S3 bucket, or delivery stream, which makes it much easier to see which app or team is producing the spend.
- Review volume after the first full month. Because tiers reset monthly, a design that looks fine in the first week can behave very differently once traffic spikes.
The biggest mistake I see is treating flow logs as a set-and-forget security control. In reality, they are an observability pipeline, and pipelines need operating rules: what gets logged, where it lands, how long it stays, and who pays for it. Once those are explicit, the bill becomes predictable instead of mysterious.
A practical setup for 2026
If I were designing this for a UK platform team in 2026, I would use a split architecture. CloudWatch Logs would hold only the short-lived, high-value slice that helps with live incident response. S3 would store the broader archive for audits, forensics, and batch analysis. Firehose would be added only when the logs need to be transformed or forwarded in motion.
That pattern keeps the hot path small and the cold path cheap, which is usually the right answer for observability budgets. It also fits the way most teams actually work: they need fast access during an outage, then cheap retention after the issue is closed. The cleanest rule is simple: pay CloudWatch for what needs to be searchable now, pay S3 for what needs to be kept, and treat Firehose as a pipeline decision rather than a saving.
If you review scope, retention, and tagging before the first bill arrives, flow logs stay useful without turning into a security tax. That is the version of VPC monitoring I would choose in practice.
