3 ms·
We did the opposite because there was so much obfuscation about what exactly CDK was doing behind the curtains with respect to "small" things like IAM. We neede
by theideaofcoffee 4y ago
We did the opposite because there was so much obfuscation about what exactly CDK was doing behind the curtains with respect to "small" things like IAM. We needed to know exactly which role was created or modified, etc, and we just couldn't get that with the basic interfaces that CDK provided. Writing those roles, users, groups, policies, attachments out explicitly into their own resource statements made things so much more clear, especially with respect to the relationships to other resources, and less risky
- bsjaux628 4y agoYou can be pretty granular in CDK, just skip the L3 constructs and build everything using the L2 one or if you hate yourself go for the L1 which is manipulating the Cloudformarion template withing CDK
- digianarchist 4y agoWhy not both? https://github.com/hashicorp/terraform-cdk https://github.com/hashicorp/terraform-cdk
- indrora 4y agoYou can, but it takes a little bit of wringing your hands. You can inspect the entire construct tree that is created (minus anything created by Custom Resources, which are opaque to the CDK) via the Aspects visitor pattern. It allows you to audit the entire tree of resources. The Annotations framework allows you to add flags (notes, warnings, and errors) to any object in the construct hierarchy.