Introduction

CloudFormation stack events are not the same thing as a native CloudWatch Logs stream. If you are looking for a single built-in CloudWatch log group that contains every CloudFormation action, that is not how the service works. You usually inspect stack events in CloudFormation, and then look at CloudWatch Logs for the resources CloudFormation created or invoked.

What CloudFormation Gives You Directly

CloudFormation exposes stack events, resource statuses, and failure messages through the console and API.

From the CLI:

aws cloudformation describe-stack-events --stack-name my-stack

Those events show progress such as CREATE_IN_PROGRESS, CREATE_COMPLETE, or CREATE_FAILED. They are essential for debugging, but they are not stored as a CloudWatch Logs log stream by default.

Where the Real Logs Usually Live

When a stack fails, the detailed logs are often in the underlying service, not in CloudFormation itself.

Common examples:

• Lambda-backed custom resources write to CloudWatch Logs automatically
• EC2 bootstrapping with cfn-init writes logs on the instance, and you can ship them to CloudWatch
• ECS tasks, CodeBuild jobs, or Step Functions triggered by stack resources have their own logs
• API activity related to CloudFormation is recorded in CloudTrail, not CloudWatch Logs by default

So the real answer is usually: use CloudFormation events to find the failing resource, then inspect that resource's logs.

Lambda Custom Resource Example

If your stack uses a Lambda-backed custom resource, the Lambda function's log group is often the most important place to look.

aws logs tail /aws/lambda/my-custom-resource --follow

CloudFormation might show only that the custom resource failed. The Lambda log group usually contains the exception, timeout, or permission error that actually caused it.

EC2 and cfn-init Logs

For EC2-based stacks using helper scripts, the useful logs may be on the instance itself.

Typical Linux locations include:

/var/log/cfn-init.log
/var/log/cfn-init-cmd.log
/var/log/cloud-init.log

If you want those visible in CloudWatch Logs, install and configure the CloudWatch agent in the instance bootstrap.

If You Need Centralized Observability

CloudFormation does not automatically centralize all dependent resource logs for you. You have to wire that up intentionally.

A common pattern is:

1. inspect CloudFormation events for the failing logical resource
2. open the corresponding CloudWatch Logs group for that service
3. send instance logs to CloudWatch with the CloudWatch agent if EC2 is involved
4. use CloudTrail if you need API-level auditing of stack actions

That gives you a full picture, but it spans multiple AWS services.

CloudTrail Versus CloudWatch Logs

If your goal is to audit who changed a stack or which API calls were made, CloudTrail is the right source.

CloudTrail can be viewed directly or delivered onward for analysis, but it is different from runtime service logs.

So ask yourself which of these you need:

• stack progress and failures: CloudFormation events
• runtime function output: CloudWatch Logs for the resource
• API audit trail: CloudTrail

A Small Debugging Workflow

Here is a practical sequence when a stack fails:

aws cloudformation describe-stack-events --stack-name my-stack

Look for the first CREATE_FAILED or UPDATE_FAILED resource. Then inspect that service's own logs. For a Lambda custom resource:

aws logs tail /aws/lambda/my-custom-resource --since 30m

That usually gets you to the actual error much faster than staring at stack events alone.

Common Pitfalls

A common mistake is expecting CloudFormation itself to emit all stack events into a CloudWatch log group automatically. That built-in stream does not exist in the way many people expect.

Another mistake is stopping at the CloudFormation failure reason. The resource-level logs usually contain the real stack trace or permission error.

Developers also sometimes ignore CloudTrail when the question is really about auditing who triggered or changed a stack, not about runtime logs.

Summary

• CloudFormation stack events are available in CloudFormation, not as a default CloudWatch Logs stream.
• Use stack events to identify the failing resource first.
• Inspect CloudWatch Logs for Lambda custom resources and other AWS services involved.
• Use instance logs and the CloudWatch agent for EC2 bootstrap visibility.
• Use CloudTrail when you need API audit history rather than runtime logs.