CloudTrail Lake Availability Change: Should You Move to CloudWatch Before May 31, 2026?

AWS added CloudTrail Lake to its March 31, 2026 service availability update and said CloudTrail Lake will stop accepting new customers on May 31, 2026. Existing customers can continue to use it, but the message is not subtle: if you are not already on CloudTrail Lake, AWS wants you looking at CloudWatch for similar capabilities.

That makes this a two-part decision. Existing CloudTrail Lake customers need to decide whether to stay or migrate. New customers need to decide whether there is any reason to start with the old path before the window closes.

What changed and who is affected

AWS documentation also says CloudTrail Lake will only receive critical bug fixes and security updates. That is the important line. Existing use is supported, but expansion energy is clearly elsewhere.

Should new customers rush to enable it before May 31?

Probably not.

There is a narrow case where you might: you already know CloudTrail Lake’s query and retention model is exactly what you need, and you want to preserve the option while you evaluate migration later. For most teams, that is not the right move. Starting a fresh architecture on a service that is closing to new customers is usually the wrong default unless there is a very strong operational reason.

For everyone else, the better question is not “how do I get into CloudTrail Lake before the door closes?” It is “how close can CloudWatch get me to the same outcome, and what am I giving up?”

CloudTrail Lake vs CloudWatch

This is the real comparison now.

CloudTrail Lake was purpose-built for audit and investigation workflows. That is why teams liked it. But CloudWatch has widened into a broader data and analytics plane for operational, security, and compliance use cases. Once AWS started offering simplified import of historical CloudTrail Lake data into CloudWatch in late 2025, the direction became easier to read.

If your team already spends a lot of time in AWS CloudWatch, the migration path may be less disruptive than it first appears.

When staying on CloudTrail Lake still makes sense

I would not push every existing customer to migrate immediately.

Stay on CloudTrail Lake for now if:

• your existing queries and event data stores already match the workflows you need
• the team is comfortable with the current retention and investigation model
• there is no current pressure to unify audit data with broader operational analytics

In that case, the right move is probably to keep running, document the lifecycle change clearly, and schedule a deliberate evaluation rather than an emotional migration.

When moving to CloudWatch makes sense

Move sooner if:

• you are designing a new centralized security or observability stack
• you want audit, operational, and compliance data in one broader analytics surface
• your team already uses CloudWatch Logs, metrics, alarms, and dashboards heavily
• you want to avoid doubling down on a platform that AWS is no longer opening to new customers

This is especially true if you are already building flows around AWS Security Hub and CloudWatch findings. In that architecture, CloudWatch becomes more valuable the more security and operational telemetry you consolidate there.

A practical migration path

You do not need to rebuild everything at once.

1. Inventory the CloudTrail Lake workloads you actually use

This sounds basic, but many teams discover the same thing here: only a handful of saved queries and event stores drive most of the value.

List:

• event data stores
• query patterns
• retention expectations
• dashboards or analyst workflows that depend on them

2. Separate audit requirements from convenience habits

Some teams keep CloudTrail Lake because it feels familiar, not because it is uniquely required. Others genuinely need the audit-lake semantics. Figure out which one you are before planning the move.

3. Test CloudWatch with the real queries, not a toy example

If the query surface, cost model, or operational ergonomics feel worse in practice, that should show up in testing, not in production.

4. Import historical data only where it matters

AWS launched simplified import from CloudTrail Lake into CloudWatch in December 2025. That makes transition easier, but it does not mean every byte deserves migration. Move the data with real retention or investigation value first.

The trap to avoid

The trap is treating this like an emergency shutdown. It is not. Existing customers still have time. But the opposite trap is worse: doing nothing because the old service still works.

Lifecycle changes matter most when they hit architecture planning, not when they break a running endpoint. If you are building a new audit analytics path today, build toward the service AWS is still widening, not the one it is narrowing.

My recommendation

If you are already on CloudTrail Lake and it is working, keep it stable while you evaluate CloudWatch with your real workloads. If you are a new customer or building a new central logging and investigation platform in 2026, I would not start with CloudTrail Lake this late in the cycle.

For baseline service behavior, keep AWS CloudTrail Deep Dive nearby. For the destination platform, read AWS CloudWatch Deep Dive. The right answer here is less about brand loyalty to a feature and more about choosing the platform AWS is clearly still evolving.