Difficulty: Easy
Description
We detected VPC Flow Logs in your account that deliver to CloudWatch Logs. Vended-log delivery to S3 costs about half as much per GB as delivery to CloudWatch Logs (and S3 storage is cheaper still), so switching the destination reduces the ingestion cost with no loss of data. Each row is a CloudWatch log group; the flow logs writing to it are listed under Flow Logs, and because the cost is billed per log group, a group fed by several flow logs only stops incurring it once every one of them is switched — so migrate them all. For each flow log, create the S3-destined flow log alongside the existing one, validate it, then delete the CloudWatch Logs flow log. Before switching, confirm nothing reads the CloudWatch log group directly — subscription filters, metric filters, or Logs Insights queries would need to be re-pointed at S3 (Athena, S3 Select, or a Lambda processor). We surface only the delivery saving; the additional S3 storage saving is upside we do not quantify.
Selection Criteria
The VPC Flow Log delivers to CloudWatch Logs (
LogDestinationType = cloud-watch-logs).The flow log is active and actively delivering data (non-zero vended-log ingestion in the CUR).
Expected Saving
Around 50% of the CloudWatch Logs vended-log delivery cost in the first pricing tier ($0.50/GB to CloudWatch Logs vs $0.25/GB to S3), blended across tiers against the log group's monthly volume. The gap narrows in higher tiers (≈40% past 10 TB/mo, ≈25% past 30 TB/mo) and reaches 0 above 50 TB/mo, so the saving is computed per log group from the real, distributor-stripped CUR delivery cost and the tiered list-price ratio — never a flat percentage.
Example (delivery only): a VPC emitting 100 GB/month stays in the first tier, so delivery drops from 100 × $0.50 = $50/mo to 100 × $0.25 = $25/mo — about $25/mo (~$300/yr) saved, before any S3 storage or lifecycle upside.
Note:
We credit only the ingestion/delivery saving. S3 storage is cheaper too ($0.023 vs $0.03/GB-month, and far smaller after gzip compression), but the S3-side volume and lifecycle can't be derived from our data, so storage is left as unquantified upside rather than baked into the number.
Operational Impact
✅ No downtime — the S3-destined flow log can be created in parallel with the existing one and validated before the CloudWatch Logs flow log is deleted; both run simultaneously, so no records are lost. Recovery is trivial: re-creating the CloudWatch-destined flow log restores the previous behaviour.
⏳ Realized only after full migration — a log group fed by several flow logs keeps incurring cost (and the recommendation stays open) until every feeding flow log has switched; migrating some of them shrinks the projected saving but credits realized savings only once the whole group is migrated.
⚠️ Check downstream consumers first — subscription filters, metric filters, or Logs Insights queries reading the CloudWatch log group must be re-pointed at S3 (Athena, S3 Select, or a Lambda processor). We cannot detect these automatically, so validate manually before cutting over.
⚠️ Format defaults to plain text — S3-destined flow logs are plain text by default; consider Parquet for extra storage and Athena-scan savings (Parquet conversion adds ~$0.012/GB but typically pays for itself).
⚠️ Retention & compliance — ensure S3 lifecycle, encryption (SSE-S3 or SSE-KMS), and bucket policies meet the same retention and security requirements previously enforced by the CloudWatch log group.
⚠️ Real-time use cases — CloudWatch Logs ingests in near real time; if alerts or dashboards depend on that latency, confirm an S3-based pipeline (Athena, EventBridge on S3 events) meets the SLO before cutting over.