# Suboptimal log class configuration in CloudWatch Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-log-class-configuration-in-cloudwatch By default, CloudWatch Log Groups use the Standard log class, which has a higher per-GB ingestion price. By: Kyler Rupe Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Suboptimal Log Class Configuration in CloudWatch The short version By default, CloudWatch Log Groups use the Standard log class, which has a higher per-GB ingestion price. [Kyler Rupe](https://www.linkedin.com/in/kyler-rupe-8b802a190/) Cloud FinOps Engineer @ Koch AWS service [AWS CloudWatch](https://www.pointfive.co/efficiency-hub/cloud-services/aws-cloudwatch) Category [Other](https://www.pointfive.co/efficiency-hub/service-category/other) Reference CER-0224 Type Inefficient Configuration ## Explanation Why the waste happens and who it affects. AWS also offers an Infrequent Access (IA) log class designed for logs that are rarely queried - such as audit trails, debugging output, or compliance records. Many teams assume storage is the dominant cost driver in CloudWatch, but in high-volume environments, ingestion costs can account for the majority of spend. When logs that are infrequently accessed are ingested into the Standard class, it leads to unnecessary costs without impacting observability. The IA log class offers a lower per-GB ingestion price (storage and Logs Insights query charges are the same as Standard), making it a better fit for logs used primarily for post-incident review, compliance retention, or ad hoc forensic analysis. ## Billing model The pricing dimensions that drive this cost. CloudWatch Logs are billed based on: - Ingestion volume per GB - Storage per GB-month - Querying via Logs Insights (optional) By default, Log Groups are set to the Standard log class. However, AWS offers an Infrequent Access (IA) log class with a lower ingestion price per GB; storage and Logs Insights charges are the same in both classes. This class is ideal for logs accessed occasionally, such as security audits, application debugging, or forensic analysis. Because the log class must be set at creation, many environments default to Standard even when IA would be more cost-effective. ## How to detect 7 checks to find it in your estate. - Identify all log groups currently using the Standard log class - For each, assess whether logs are actively queried or primarily retained for infrequent access - Review ingestion volumes relative to query frequency to surface high-ingest, low-access patterns - Evaluate log retention periods - long-retained logs with low query activity are strong candidates - Analyze whether ingestion charges account for a significant portion of CloudWatch costs - Flag logs used for compliance, audit, or post-incident forensics that could be routed to Infrequent Access - Exclude log groups that rely on metric filters, subscription filters, Live Tail, anomaly detection, embedded metric format, or the GetLogEvents and FilterLogEvents APIs, none of which the Infrequent Access class supports ## How to fix 5 ways to remove the waste. - Create new log groups using the Infrequent Access class for applicable use cases - Update application and service configurations to route logs to the new log groups - Route logs at the source (agent, service, or application configuration) so that high-access logs go to Standard log groups and infrequently accessed logs go to IA log groups; IA log groups do not support subscription filters - Apply tagging or naming conventions to distinguish log groups by access frequency or retention intent - Periodically audit log group configurations and adjust routing based on evolving usage patterns ## Documentation Vendor references for pricing and configuration. - [Log classes docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch_Logs_Log_Classes.html) - [Amazon CloudWatch Pricing aws.amazon.com](https://aws.amazon.com/cloudwatch/pricing/) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - AWS CloudWatch CER-0090 ### [Excessive CloudWatch Log Volume from Persistently Enabled Debugging](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-cloudwatch-log-volume-from-persistently-enabled-debugging) Engineers often enable verbose logging (e.g., debug or trace-level) during development or troubleshooting, then forget to disable it after deployment. This results in elevated log ingestion rates - and therefore costs - even when the... Other - AWS CloudWatch CER-0382 ### [Unnecessary EC2 Detailed Monitoring](https://www.pointfive.co/efficiency-hub/inefficiencies/unnecessary-ec2-detailed-monitoring) EC2 basic monitoring publishes instance metrics to CloudWatch at 5-minute granularity at no charge. Detailed monitoring switches those metrics to 1-minute granularity, and each metric EC2 sends is then billed at the CloudWatch custom... Other - AWS CloudWatch CER-0233 ### [Overly Permissive VPC Flow Log Filters Sent to CloudWatch Logs](https://www.pointfive.co/efficiency-hub/inefficiencies/overly-permissive-vpc-flow-log-filters-sent-to-cloudwatch-logs) VPC Flow Logs configured with the ALL filter and delivered to CloudWatch Logs often result in unnecessarily high log ingestion volumes - especially in high-traffic environments. This setup is rarely required for day-to-day monitoring or... Other --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.