This is a quick follow up to my prior post about strictly using Python instead of the CLI with AWS Cloud Development Kit.
In the real world, I probably want to create something more elaborate than just an S3 bucket. I want to create RDS instances, and EC2 instances, and Lambda functions, etc, etc, etc. And if I’m working on my side hustle, it’s probably okay if I just build things as I go, figuring out configuration improvements over time.
But what if I work in a team or company environment, and need a set of consistently configured resources?
In my mind, that is where the big promise of CDK really lies.
Dynamic Stacks with Consistent Configurations
Let’s consider the basic stack I originally created, but with a modification.
from aws_cdk import ( aws_s3 as s3, core ) class HelloCdkStack(core.Stack, ResourceOrder): def __init__(self, scope: core.Construct, id: str, **kwargs) -> None: super().__init__(scope, id, **kwargs) for key, value in ResourceOrder.get('tags', {}).items(): self.tags.set_tag(key, value, apply_to_launched_instances=True) for s3_bucket in ResourceOrder.get('s3_bucket', []): self.make_bucket(s3_bucket) ... potential other requestable resources ... def make_bucket(self, bucket_config): standard_bucket_policy = [{...}] policies = policy_resolution_logic(standard_bucket_policy, bucket_config.get('bucket_policy', [{}]) bucket = s3.Bucket(self, id=bucket_config.get('bucket_name'), bucket_name=bucket_config.get('bucket_name'), versioned=True, encryption=s3.BucketEncryption.KMS_MANAGED, block_public_access=s3.BlockPublicAccess(restrict_public_buckets=True), ) for policy in policies: policy['effect'] = iam.Effect(policy.get('effect')) statement = iam.PolicyStatement(**policy) bucket.add_to_resource_policy(statement)
The general idea here should be fairly clear – a ResourceOrder
object is passed into our standard stack class. The object is inspected for supported resources, and configured in a uniform way – encryption, versioning, and public accessibility for example – with some allowable differences.
The user is able to submit a custom name and some additional attributes to the bucket’s resource policy while still enforcing a standard set of bucket policies.
I’m also able to apply stack-level attributes, such as tags.
Monitoring and identifying configuration drift
One final thought while I’m on the subject – after doing all the hard work of enforcing an important set of standards on my AWS resource configuration design thanks to my dynamic and end-to-end automated deployment process, I probably want to be sure everything stays the way I meant it to.
Thankfully, AWS Config allows me to cheat using the cloudformation-stack-drift-detection-check
managed rule to quietly keep an eye on everything for me. And if I have a lot of accounts I need to check, I can actually use CDK to both activate the Config Aggregator and setup the managed rule in all of those accounts for me. From there, I can trigger a CloudWatch Rule and make that rule do something to alert me.
Leave a Reply