CloudWatch Logs Account-Level Retention: How It Works

AWS announced account-level retention policies for Amazon CloudWatch Logs on November 9, 2026. Platform teams can apply a retention period to all log groups in an account and Region or scope it by log group name prefix. A policy can cover only newly created groups or also reach existing groups. Matching policies take precedence over the log group’s own setting, so teams should verify effective retention before changing production.

Original editorial illustration.

Consider an ASP.NET Core API running on ECS alongside several scheduled Lambda jobs. Each workload can produce log groups, and several teams might manage them through different deployment templates. If retention is managed solely in those templates, the effective policy depends on every template and every manually created group. An account policy moves the baseline to one place while allowing longer retention for selected groups. It also changes who can shorten how long production evidence is kept. AWS announcement

What did CloudWatch Logs change?

CloudWatch Logs organizes events into log streams within log groups. Historically, a team set the age at which events expire on each log group with PutRetentionPolicy or a corresponding infrastructure setting. That still works for groups without a matching account policy. When a matching account policy applies, PutRetentionPolicy can still save a group-specific value, but it does not change the effective expiration while the account policy is active.

A NEW_ONLY policy governs groups created after the policy. A RETROACTIVE policy applies to matching existing groups too. If several eligible account policies match, the longest retention period applies. AWS treats NEVER_EXPIRE as longest. The longest rule compares account policies with each other, so it does not preserve a longer individual retention period in a group covered by a shorter account policy. PutAccountPolicy · PutRetentionPolicy

How CloudWatch applies retention.

What changes for deployment and operations?

Area	Individual log group settings	Account-level policies
Ownership	Workload template or log group operator	Platform policy administrator
Selection	A named log group	All groups or a prefix, evaluated in that Region
Existing groups	Change each group separately	Retroactive mode can affect a matching fleet
Future groups	Templates or automation must apply retention	New matching groups can inherit policy
Exceptions	Override each group	Add a longer matching account policy, or exclude the group from the baseline design
Compatibility	Useful for uncovered groups and individual needs	Up to 20 policies per account and Region
Cost and performance	Ingestion, storage and queries retain their service pricing	AWS adds no policy fee. Retention changes how long data remains and can affect storage cost

AWS announced availability across commercial Regions except Middle East (Bahrain) and Middle East (UAE). Account retention policies accept a defined list of periods from 30 through 3,653 days, as well as NEVER_EXPIRE. Values such as seven or fourteen days that are available in the group-level operation are not supported in the account-level policy. Read the list before migrating a template. Retention policy API

How do you roll out and verify a policy?

The example starts with a dedicated test prefix and new groups only. Use a current AWS CLI and a role authorized for logs:PutAccountPolicy to create the policy, and an inspection role with logs:DescribeLogGroups to verify it. Resource and account controls can further constrain who is allowed to manage policies. This command changes your AWS account configuration. The syntax was checked against the API and was not executed.

aws logs put-account-policy \
  --region us-east-1 \
  --policy-name aspnet-lab-new-90 \
  --policy-type RETENTION_POLICY \
  --policy-document '{"retentionInDays":90,"enforcementMode":"NEW_ONLY"}' \
  --selection-criteria 'LogGroupNamePrefix = "/aspnet/lab/"'

AWS documents a 24-hour delay before a created or updated retention policy takes effect. Create the comparison group before applying the policy, then create another matching lab group after activation. Compare it with a matching group that already existed. Inspect the account policy name and effective day count together.

aws logs describe-log-groups \
  --region us-east-1 \
  --log-group-name-prefix /aspnet/lab/ \
  --query 'logGroups[].{Group:logGroupName,Days:retentionInDays,Policy:retentionPolicyName}'

The expected newly created group shows 90 days and the applied policy name. The pre-existing group should retain its existing behavior unless another account policy covers it. If several policies are in play, inspect the group response instead of assuming the narrowest prefix wins. If your SDK model does not surface the new field, compare the console or current CLI output and update the client. DescribeLogGroups

Why start with new groups only?

A retroactive policy can shorten effective retention across many existing groups. Older events may become eligible for deletion. Use the documented dry-run option to review counts and samples of groups whose retention would change. Record which groups are under legal hold or have audit requirements, and export or preserve necessary evidence before changing expiration. An infrastructure rollback cannot bring back deleted events. Use one account and Region, an intentionally narrow prefix, a reviewed list of matches and representative test groups before widening the rule.

The workload’s logging code can stay the same. Keep the runtime identity focused on writing events and leave retention changes to a platform role. Align log group names with environment and workload boundaries so developers can tell whether a group is intended to inherit the policy. Redact sensitive application data at the source, since retention does not remove sensitive values from newly ingested logs. For related application-level practices, see structured logging and OpenTelemetry in ASP.NET Core.

How should teams handle exceptions and rollback?

Make an inventory before changing an account baseline. Record each group’s current effective period, any account policy already attached, its environment, the owner and the reason for its retention. Test long-lived audit groups as well as short-lived debug groups. The difficult case is often an overlap between two broad prefixes, where a longer rule increases storage or a shorter new baseline unexpectedly overrides a group that used to keep records for years.

Keep the prior policy definition under version control and document the operator who can restore it. If a group-specific setting remains saved beneath an account policy, it can matter again when the account policy no longer applies. Include those latent values in the inventory. Validate before removing a policy as carefully as before adding one. Change control should account for the 24-hour delay and verify outcomes using the service’s effective values.

Frequently asked questions

Will a one-year group setting beat a 90-day account policy?

No. An applicable account-level policy determines effective retention. To keep the group for a year under the centralized model, add a matching one-year account policy or keep the group outside the 90-day policy’s scope.

Does central retention change how an application sends logs?

No. Event ingestion stays separate. This changes the retention rules AWS applies to the log groups, so application teams should check where their groups are created and which prefixes they use.

Is it worth migrating every group?

Start with policy coverage that matches your existing standards. Keep group-level settings for workloads with requirements the account policy cannot express, particularly shorter periods that are only supported at group level.