Apply Security and Compliance Rules with CDK Aspects (2026)

CDK Aspects let you enforce security and compliance guardrails across your entire AWS CDK application without modifying individual constructs.

Let’s see this in action. Imagine you want to ensure all S3 buckets in your infrastructure are private, meaning no public read access.

from aws_cdk import (
    Stack,
    aws_s3 as s3,
    aws_iam as iam,
    Aspects,
    CfnTag
)
from constructs import Construct
from typing import Any

class MySecureBucketStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # This bucket will be checked by the aspect
        s3.Bucket(self, "MyPrivateBucket",
            removal_policy=s3.RemovalPolicy.DESTROY,
            auto_delete_objects=True
        )

class PublicAccessBlockAspect:
    def visit(self, node: Any):
        if isinstance(node, s3.CfnBucket):
            # Ensure PublicAccessBlockConfiguration is set correctly
            node.public_access_block_configuration = s3.CfnBucket.PublicAccessBlockConfigurationProperty(
                block_public_acls=True,
                ignore_public_acls=True,
                block_public_policy=True,
                restrict_public_buckets=True
            )

# In your app.py or main CDK file:
# from aws_cdk import App
# from my_secure_bucket_stack import MySecureBucketStack, PublicAccessBlockAspect
#
# app = App()
# stack = MySecureBucketStack(app, "MySecureBucketStack")
# Aspects.of(stack).add(PublicAccessBlockAspect())
# app.synth()

When you run cdk synth with the PublicAccessBlockAspect applied, the CDK will automatically inject the public_access_block_configuration into any AWS::S3::Bucket CloudFormation resources it generates. This ensures that even if you forget to configure it manually on a specific bucket, the guardrail is enforced.

The core problem Aspects solve is the "distributed configuration problem." In large, complex applications, maintaining consistent security policies and compliance rules across hundreds or thousands of individual AWS resources becomes a manual, error-prone nightmare. You might have a team of developers, each deploying their own stacks, and ensuring everyone adheres to a company-wide policy (like "no public S3 buckets") requires constant vigilance, code reviews, and often, custom Lambda-backed custom resources or manual checks. Aspects provide a declarative, programmatic way to inject these checks and configurations directly into the CDK synthesis process.

Here’s how it works internally. When you define an Aspect and add it to a construct (like a Stack or the App itself), the CDK traverses the construct tree during synthesis. For every node in the tree, it calls the visit method of your Aspect. Your visit method receives the node. If the node is of a type you’re interested in (e.g., s3.CfnBucket), you can then modify its properties or add new resources. The key is that Aspects operate on the CloudFormation template generated by the CDK, not on the CDK constructs directly during the cdk.out phase. This means you’re modifying the underlying AWS resources’ definitions before they are deployed.

The primary lever you control is the visit method’s logic. You can inspect the node being visited. If it’s a construct you care about, you can check its properties. For example, you could check if an s3.Bucket has public_read_access enabled and throw an error if it does. Or, as in the example, you can programmatically add or modify CloudFormation properties. You can also use Aspects to add tags, IAM policies, or even create entirely new resources that are conditionally attached to existing constructs. The scope parameter in the visit method is crucial; it represents the scope from which the aspect was applied, allowing you to conditionally apply rules based on the hierarchy of your constructs.

A subtle but powerful aspect of Aspects is their ability to modify constructs that are already defined. When node.public_access_block_configuration = ... is executed within the visit method, you’re not just reading properties; you’re directly setting them on the CfnBucket instance that the CDK is building. This means an Aspect can effectively "fix" a construct’s configuration to meet compliance requirements, even if the original construct definition didn’t explicitly set those properties. It’s a form of automated configuration enforcement.

The next logical step after enforcing basic security configurations is to manage cross-account access policies.