Install & Compatibility
Where this runs
tested against v1.204.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.910 runs
installs and imports cleanly · install 0.0s · import 0.000s · 36.8MB
glibcpy 3.10–3.910 runs
installs and imports cleanly · install 5.0s · import 0.000s · 37MB
36MB installed
● package 36MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
LogGroup
✓ from aws_cdk import core
from aws_cdk import aws_logs as logs
class MyStack(core.Stack):
def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
super().__init__(scope, id, **kwargs)
log_group = logs.LogGroup(self, 'MyLogGroup')
✗ from aws_cdk.aws_logs import LogGroup
CDK v1 typically uses `import aws_cdk.aws_logs as logs` and accesses constructs as `logs.LogGroup`. Direct import `from aws_cdk.aws_logs import LogGroup` is less common for services in v1 and changed in v2.
RetentionDays
✓ from aws_cdk import aws_logs as logs
logs.RetentionDays.ONE_WEEK
✗ from aws_cdk.aws_logs.RetentionDays
RetentionDays is an enum within the `aws_logs` module, accessed via the module alias.
This quickstart demonstrates how to create a basic CloudWatch Log Group using `aws-cdk-aws-logs` with a 7-day retention policy. It also sets the removal policy to `DESTROY` for easier cleanup in development environments and outputs the log group name. Remember that `aws-cdk-aws-logs` is a CDK v1 package.
import os
from aws_cdk import core
from aws_cdk import aws_logs as logs
class MyLogStack(core.Stack):
def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
super().__init__(scope, id, **kwargs)
# Create a CloudWatch Log Group with a retention period of 7 days
log_group = logs.LogGroup(self, 'ApplicationLogGroup',
retention=logs.RetentionDays.ONE_WEEK,
removal_policy=core.RemovalPolicy.DESTROY
)
core.CfnOutput(self, "LogGroupName", value=log_group.log_group_name)
app = core.App()
MyLogStack(app, "CdkLogsQuickstartStack",
env=core.Environment(
account=os.environ.get('CDK_DEFAULT_ACCOUNT'),
region=os.environ.get('CDK_DEFAULT_REGION')
)
)
app.synth()
Debug
Known issues
breakingAWS CDK v1, including `aws-cdk-aws-logs`, reached End-of-Support on June 1, 2023. This package is no longer being updated or receiving security patches. All users should migrate to AWS CDK v2 to ensure continued support, security, and access to new features.fixMigrate your CDK applications to AWS CDK v2. For the `aws-logs` library, this means replacing `pip install aws-cdk-aws-logs` with `pip install aws-cdk-lib` and updating import statements from `import aws_cdk.aws_logs as logs` to `from aws_cdk import aws_logs`. Consult the official AWS CDK v2 migration guide for detailed steps.
affects: 1.x.x
gotchaThe import paths for CDK constructs changed significantly from v1 to v2. Code written for `aws-cdk-aws-logs` (v1) will not work directly with `aws-cdk-lib` (v2) without updating imports.fixIn AWS CDK v1, service constructs were in separate packages (e.g., `aws_cdk.aws_logs`). In v2, they are consolidated under `aws_cdk.aws_logs` within the `aws_cdk_lib` package. Update your imports from `import aws_cdk.aws_logs as logs` to `from aws_cdk import aws_logs`.
affects: 1.x.x (when migrating to v2)
gotchaCloudWatch Log Group names must be unique within an AWS Region for a given account. Attempting to deploy a CDK stack with a duplicate Log Group name will result in a CloudFormation deployment failure.fixEnsure that `log_group_name` property (if explicitly set) is unique, or allow CDK to generate a unique name by omitting it. If reusing log groups, import existing ones using `LogGroup.from_log_group_arn()` or `LogGroup.from_log_group_name()`.
affects: All versions
gotchaIncorrect or insufficient IAM permissions are a common cause of CloudFormation deployment failures when interacting with CloudWatch Logs, manifesting as 'You don't have permissions to perform this action' errors.fixReview the CloudFormation error messages to identify the missing permissions. Grant the necessary `logs:CreateLogGroup`, `logs:PutRetentionPolicy`, `logs:CreateLogStream`, `logs:PutLogEvents`, etc., permissions to the IAM role deploying the stack or to the resources interacting with the logs. Always apply the principle of least privilege.
affects: All versions
Errors
Common errors & fixes
jsii.errors.JavaScriptError: Error: There is already a LogGroup named...
A CloudWatch Log Group with the same name already exists in the AWS account and region where the stack is being deployed.
fixIf the log group is intended to be managed by this stack, ensure its name is unique. If you want to reference an existing log group, use `logs.LogGroup.from_log_group_name(self, 'ExistingLogGroup', 'MyExistingLogGroupName')` or `logs.LogGroup.from_log_group_arn(...)` instead of creating a new one. Alternatively, if the log group is implicitly created by a service, allow CDK to generate a unique name.
jsii.errors.JSIIError: No resource 'LogGroup' exists with id '...' in stack '...'.
This error can occur when trying to reference a LogGroup that hasn't been defined or imported correctly within the CDK stack, or if there's a typo in the construct ID.
fixVerify that the LogGroup construct has been instantiated with the correct ID or that `LogGroup.from_log_group_name()`/`from_log_group_arn()` is used to import an existing log group before attempting to reference it. Check for typos in construct IDs. Ensure the stack contains the LogGroup definition.
Error: Stack 'MyStack' failed to deploy: UPDATE_ROLLBACK_COMPLETE: ... The specified KMS key does not exist or is not accessible.
When encrypting a LogGroup with a KMS key, the specified `encryptionKey` ARN is either invalid, the key does not exist, or the CloudFormation service role (or the entity creating the log group) does not have sufficient permissions to use the key.
fixVerify the KMS key ARN is correct. Ensure the IAM role used by CloudFormation (or the resource deploying the log group) has `kms:Encrypt`, `kms:Decrypt`, `kms:ReEncrypt*`, `kms:GenerateDataKey*`, and `kms:DescribeKey` permissions on the specified KMS key. Ensure the KMS key is in the same region as the log group.
Upgrade
Version history
1.204.0latest on PyPI · released Jun 19, 2023
Audit
Dependencies
aws-cdk.corerequiredCore AWS CDK functionality for constructing applications and stacks.
constructsrequiredThe base class for all constructs in the AWS CDK.