Download to read offline
Uploaded byTapio Rautonen
Deep dive into AWS CDK custom resources by Tapio Rautonen
The document discusses the differences between CloudFormation and the Cloud Development Kit (CDK), emphasizing the need for custom resources in managing complex infrastructure. It covers the anatomy and lifecycle of custom resources, including their interactions with CloudFormation and Lambda functions, as well as best practices for implementation. Additionally, it highlights the limitations of both CDK and CloudFormation and provides guidance on handling updates, security, and resource identification.
More Related Content
Similar to Deep dive into AWS CDK custom resources by Tapio Rautonen
Deep dive into AWS CDK custom resources by Tapio Rautonen
- 1. TAPIO RAUTONEN ▸ Idlis,CTO Amazon, Senior SDE Umbra, Tech Lead Gofore, Software Architect ▸ Solving business problems with the help of computers ▸ Experienced in large-scale systems
- 2. CUSTOM RESOURCES DEEP DIVEINTO CDK
- 3. THE GOOD, THEBAD AND THE UGLY ▸ CDK vs CloudFormation ▸ What custom resources are ▸ Why you (or CDK constructs) need them ▸ Things you should and should not know ▸ Best practices to follow
- 4.
- 5. CLOUDFORMATION ▸ Declarative approachto de fi ning infrastructure (YAML / JSON) ▸ Enables consistency and version control through reusable templates ▸ Limited logic control (conditions, mappings, outputs) ▸ Dif fi cult to manage large-scale infrastructure ▸ Awful to read and write
- 6. TEXT CLOUD DEVELOPMENT KIT(CDK) ▸ High-level constructs and abstractions to simplify resource de fi nitions ▸ Supports complex logic and control structures ▸ Leverages familiar programming languages (TypeScript, Python, Go, etc.) ▸ Developer friendly and better productivity ▸ Essentially a YAML generator
- 7.
- 8. ANATOMY OF ACUSTOM RESOURCE ▸ Custom resource provider (or through SNS) - provides the logic that handles CloudFormation requests - returns the result and status back to CloudFormation ▸ Lambda function (or Step Functions) - provisions the infrastructure and runs any custom logic - interacts with AWS or other external APIs ▸ Custom resource - makes an instance (a resource) of the provider and function
- 9.
- 10. CUSTOM RESOURCE LIFECYCLE ▸Resource lifecycle in the stack is determined by the logical id ▸ CloudFormation sends a request to the resource provider when a change in the custom resource occurs ▸ The request type can be either CREATE, UPDATE or DELETE ▸ The Lambda function must return an immutable physical resource id which is used by CloudFormation for resource tracking
- 11. CREATE EVENT ▸ CloudFormationinitiates a CREATE request when a new logical id is found in a stack ▸ The provider invokes the Lambda function which is expected to run the create logic and responds either SUCCESS or FAILURE back to CloudFormation ▸ The Lambda function must return an immutable physical id
- 12. UPDATE EVENT ▸ CloudFormationinitiates an UPDATE request when a custom resource changes with an existing logical id ▸ The provider invokes the Lambda function which is expected to run the update logic and responds either SUCCESS or FAILURE back to CloudFormation ▸ The Lambda function must return a new physical id for replacements and same physical id for in-place updates - CloudFormation initiates a DELETE request for the old physical id
- 13. DELETE EVENT ▸ CloudFormationinitiates a DELETE request when an existing logical id is deleted or after UPDATE results a new physical id ▸ The provider invokes the Lambda function which is expected to run the delete and clean up logic and responds either SUCCESS or FAILURE back to CloudFormation ▸ The Lambda function must return the same physical id
- 14. WHY YOU NEEDTHEM
- 15. CDK USES CUSTOMRESOURCES INTERNALLY ▸ CloudFormation does not support all use cases that are considered very useful to infrastructure maintainers ▸ Handful of internal constructs use custom resources to extend CloudFormation functionality - S3 auto delete objects - Route53 cross account zone delegation - DynamoDB multi-region replication - CDK cross region export reader ...
- 16. CROSS ACCOUNT /REGION OPERATIONS ▸ CloudFormation does not play nicely when provisioning needs to be done on different account or region of where the stack resides ▸ Generally AWS and CDK teams discourage these kinds of operations, but due to how AWS is built sometimes you need to cross the boundaries ▸ E.g. The infamous us-east-1 certi fi cates for CloudFront
- 17. TEXT EXTEND CDK ORCLOUDFORMATION ▸ CloudFormation does not support all AWS services that might still have APIs ▸ CDK does not support all services that CloudFormation supports ▸ CDK implementation might be missing a critical feature ▸ E.g. CloudFront Origin Access Control or Bedrock
- 18. AUTOMATE RESOURCES BEYONDAWS ▸ Interact with 3rd party services or APIs ▸ Provision non-AWS infrastructure ▸ E.g. issue licenses, certi fi cate validation for 3rd party DNS provider or provision external CDN like Cloud fl are
- 19. POST-DEPLOYMENT TASKS ▸ Whena resource is deployed it might need some con fi guration or initialization after the fact ▸ Execute external work fl ows after a successful or failed deployment ▸ E.g. database migration, asset deployment or trigger monitoring system
- 20. THINGS YOU SHOULDAND SHOULD NOT KNOW
- 21. TYPICAL CLIENT-SERVER REQUESTFLOW IN THE CLOUD ▸ CloudFormation communicates the changes to custom resource to update the stack state and outputs CloudFormation LambdaFunction S3 ResourceProvider ▸ Resource provider responds the status and payload through S3 signed URLs ▸ Don't bother to implement the provider from scratch
- 22. NOT ALL UPDATESARE EQUAL ▸ CloudFormation triggers an UPDATE event for changes on the custom resource, but what is considered a change? ▸ Stack update? ▸ Lambda function update? ▸ Custom resource properties update?
- 23. AT LEAST WEHAVE TYPES ▸ Custom resource properties can be used to customize the resource provisioning ▸ cdk.CustomResource is written in TypeScript and provides type guarantees for the con fi guration attributes ▸ CloudFormation stringi fi es any properties, no questions asked!
- 24. BEST PRACTICES TOFOLLOW
- 25. IDENTIFY YOUR RESOURCES ▸Custom resources can be given custom resource type to differentiate the types of custom resources in a stack - use a speci fi c type like Custom::DnsValidatedCerti fi cate ▸ Resources provisioned by the custom resource cannot be identi fi ed easily - can be easily mixed with manually created resources - use tags wisely and create a convention to identify the resources
- 26. TAKE SECURITY SERIOUSLY ▸Principle of least privilege access - ensure the lambda role has minimum permissions to perform its tasks ▸ Can expose a security loophole by lambda invokes - limit users who have permission to lambda invoke ▸ Secure secret management - don't hardcode secrets, use Secrets Manager or Parameter Store ▸ Validate all input properties
- 27. MAKE YOUR CUSTOMRESOURCES IDEMPOTENT ▸ React correctly to CloudFormation events - use same physical id for in-place updates and return new for replaces - clean up resources on delete ▸ If an error occurs, the lambda function might be retried - don't create duplicate resources on retried creates - don't try to delete already deleted resources ▸ The physical id given for delete depends on CloudFormation update status - old resource id on success, new resource on failure
- 28. SET CORRECT TIMEOUTEXPECTATIONS ▸ Misbehaving custom resource can stall the stack update for a long time ▸ Set the lambda function timeout according to expected provisioning time (max 15 minutes) ▸ Set the custom resource service timeout based on the lambda function timeout and expected provisioning time (max 1 hour) ▸ Implement long running provisioning tasks using Step Functions
- 29. WHAT WAS ACTUALLYGENERATED AND WAS IT NECESSARY? ▸ As said earlier: CDK is essentially a YAML generator ▸ Read and review the synthesized output ▸ Learn from the CDK internal custom resources ▸ Think twice or rather 10 times before using a custom resource