AWS CDK - Introduction and Beyond - Indy.Code() 2023
•Download as PPTX, PDF•
0 likes•14 views
The AWS CDK is a development framework that allows you to define your cloud application resources and infrastructure using programming languages instead of configuration files. By defining your resources as code you can benefit from your normal development tooling and more easily define you application. This talk provides an introduction to Infrastructure as Code, discusses key AWS CDK concepts and usage, provides tips for AWS CDK usage, and an overview of AWS CDK Best Practices.
More Related Content
Similar to AWS CDK - Introduction and Beyond - Indy.Code() 2023
Similar to AWS CDK - Introduction and Beyond - Indy.Code() 2023 (20)
Recently uploaded
Recently uploaded (20)
AWS CDK - Introduction and Beyond - Indy.Code() 2023
- 1. AWS CDK - Introduction & Beyond Jason Butz Solution Architect & Practice Lead @ DMI AWS Community Builder & AWS Certification SME dminc.com jasonbutz.info @jbutz@hachyderm.io
- 3. Infrastructure as Code • “A fundamental principle of DevOps is to treat infrastructure the same way developers treat code” – AWS • All infrastructure defined by code and stored in version control
- 4. Tools AWS • CloudFormation • Serverless Application Model (SAM) • Cloud Development Kit (CDK) Non-AWS • Puppet • Chef • Ansible • Terraform • Serverless Framework • Pulumi • ...
- 8. AWS Cloud Region Amazon CloudFront Website Bucket Logs Bucket Logs Bucket
- 9. Image Source: AWS CDK Documentation
- 11. Reference: Use generated resource names, not physical names CDK Tip: Don’t Name Resources
- 12. Constructs • L1: Low-level • L2: Intent-based • L3: Patterns
- 17. AWS Solutions Constructs • AWS created constructs for common patterns that follow best practices Reference: AWS Solutions Constructs
- 20. CDK - Beyond AWS has a detailed ”Best Practices” document for the CDK, it’s worth a read
- 21. Don't Put It All In the Constructor! Use constructs and methods to break up the code
- 22. One App – Multiple Stacks • More than nested stacks • Multiple regions, multiple accounts
- 24. Example: jasonbutz.info CDN Stack (us-east-1) CloudFront Distribution ACM Certificate Primary Stack (us-east-2) S3 Replication Amazon S3 Bucket Secondary Stack (us-west-2) Amazon S3 Bucket
- 25. Automated Testing • Focus on: • Important constructs • Critical infrastructure • Snapshotting
- 26. Review • Define cloud resources using constructs and OOP • Use AWS Solution Constructs to build common patterns • Decompose your stack with constructs • Use multiple stacks within the same CDK app • Use automated testing, when it makes sense
- 28. Thank You • AWS CDK v2 - What is the AWS CDK? • AWS CDK Workshop • AWS CDK v2 - Best Practices • AWS Solutions Constructs • Construct Hub • AWS CDKv2 - CDK Pipelines • CDK Pipelines for GitHub Workflows
Editor's Notes
- Introduce talk and self Solution Architect and Practice Lead at DMI AWS Community Builder since February Certification SME, focusing on the Dev Assoc exam All opinions are my own and do not necessarily reflect those of my employer, AWS, or anybody else This talk is largely based around what I have seen from newer CDK users and trying to move them towards better usage of the CDK Icon Source: Font Awesome (https://fontawesome.com/license/free)
- Let’s say I’ve got a lot of thoughts and opinions (CLICK) I want to write those all down (CLICK) And I of course don’t want to keep those to myself, I want them on the internet (CLICK) So I want a website, and I want to make and deploy it myself because using some service undermines my “dev cred” and also undermines the story I’m using in this talk I don’t want to configure and maintain everything by a bunch of clicking, I want automation. I want -> IaC
- IaC is key concept within DevOps Infra defined via config or code and stored in version control Automated deployments Hopefully repeatable builds Sources “A fundamental principle of DevOps is to treat infrastructure the same way developers treat code” - https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html
- Numerous IaC Tools AWS has several, all building on CloudFormation AWS’s IaC service, deploys code and handles rollback on errors Limited number of tools also mentioned here
- CloudFormation Template Very basic partial example of an API with single endpoint YAML or JSON
- AWS SAM Similar situation, an API with one endpoint YAML or JSON
- CDK Same situation, API with a single endpoint TypeScript, using objects, with IntelliSense, same linting tools AWS CDK supports TypeScript, JavaScript, Python, Java, C#/.NET, and Go
- This is my goal, a simple website on AWS for static assets CloudFront (CDN) returning resources from an S3 Bucket Two S3 Buckets for log files If you have a question about why the two buckets for logs, hang on to that Next: Let’s talk about some key concepts with the CDK before we get much further
- CDK Concept: Construct Construct = “Cloud Component,” one or more resources and configuration Single or Multiple resources, an SQS Queue, or an entire API Stacks contain one or more constructs and directly map to CloudFormation stacks Apps contain one or more stacks CDK App is transpiled to a CloudFormation Template then deployed using CloudFormation
- Example of using a Construct This case creating an encrypted S3 Bucket Construct = what we’re defining Scope = what contains this construct, must always be a construct, Stacks and Apps are special constructs ID = Identifier unique within the scope for the construct. Very similar concept to Logical ID if you know CloudFormation Props: Properties for the Construct. Here it's defining a name for our S3 bucket and turning on the encryption Best Practices for CFN apply, [NEXT SLIDE TIP]
- Best Practice / Tip – CFN/SAM/CDK Don’t name your resources unless you REALLY need to CFN generates a unique name for you Reference: https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html#best-practices-apps-names
- L1: Low-level, nearly identical to CloudFormation template resource Can be used as an escape hatch to provision resources not supported by the CDK L2: Intent-based, wraps one or more resources and includes configuration and permission aspects The majority of constructs you’ll end up using L3: Patterns The solution constructs as well as many other custom constructs Create your own as your apps grow Image Source: https://pixabay.com/vectors/building-blocks-tetris-3d-blocks-2026721/
- Talked about what the CDK is, but not how to deploy it Node.js CLI tool Bootstrap account and regions CLI tool can initialize and deploy your app CDK resources can live alongside the rest of your app
- Initialize an app in a directory and you’ll get a structure like this Bin directory has where you define your CDK App and how the Stacks are used Lib directory has your stack file and other constructs
- AWS created constructs for common patterns and built them using best practices Numerous common patterns, including connecting CloudFront to S3 (CDN to storage for static assets) Available in TypeScript/JavaScript, Java, and Python for sure. Maybe others
- This shows the Stack file with the comments removed and our solution construct added Deploying this, we get: CloudFront Distribution (CDN) S3 Bucket (Website Assets) S3 Buckets (Logs) No files in place yet for our website, but it works
- Construct handles uploading files from a directory, `public`, to our S3 bucket Creates a Lambda function and uses CloudFormation Custom Resources to put files into the S3 Bucket CloudFrontToS3 construct provides properties to the resources it creates After deployment we have a working website at this point, there is still a lot you can do to improve but it works!
- AWS has great CDK Best Practices document Much of what I outline is from or evolves out of AWS’s published best practices Some of what I am about to say will go directly against what I just showed, but that’s ok Always exceptions Always iterate improvement QR Code destination: https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html
- Don't put all the code in the constructor! Joke: This isn't the matrix. We don't want to try and comprehend that wall of text Use Custom Constructs. Use Methods. Break it up! Don't have a 2000-line-long constructor Avoid a 2000-line-long CDK stack class, so prefer the constructs Sometimes you can't avoid a lot of repetitive code, but if you can. Do Photo Source: https://unsplash.com/photos/iar-afB0QQw (Free to use under the Unsplash License)
- Only split stacks if you need AWS recommends focusing on deployment requirements, but you can keep them together in a single code repository Stateful and stateless resources – DB vs Lambda – Enable termination protection on stateful stack to prevent deletes Stack per environment (ex, next slide) Mutli-region deployments (ex, 2nd slide) Image Source: https://pixabay.com/vectors/cube-building-blocks-tetris-3d-2026724/
- Common example, stack per deployment environment Environment-specific configuration passed in when you define the stack Deploy script selects the stack(s) based on the environment TIP: The CDK CLI tool supports wildcards when specifying stacks! Code Snippet: const app = new App() new SampleStack(app, 'production', { env: { region: 'us-east-1', account: '999999999999' }, hostname: 'myapp.example.com', }) new SampleStack(app, 'staging', { env: { region: 'us-east-1', account: '000000000000' }, hostname: 'myapp-staging.internal.example.com', })
- Example of using L3 constructs and multiple stacks is my own website L3 Construct: “Redundant CDN” construct encapsulating all the setup for a distribution with an origin group Multiple stacks: 3 stacks to 3 different regions to setup the site Deploy secondary S3 bucket Deploy primary S3 bucket Deploy CDN and certifiance Also worth remembering you can use OOP when building everything Secondary stack is extended by the “primary stack” to add in replication, everything else is the same! Icons Source: https://aws.amazon.com/architecture/icons/
- Focus your CDK unit testing efforts on important constructs, critical infrastructure, and things you want to make sure a right If you're not careful, these unit tests can basically turn into a copy of your code, and that isn't want you need Like with any application, be careful that every change to code doesn't require a change to unit tests Skip less beneficial tests Don’t test that your custom Lambda construct defined a Lambda function. Test that it defined a Lambda with the special configuration your construct handles Snapshotting – Jest makes it easy, and it’s easy to overdo it If you use it too much, everyone will always run the tests so they update the snapshot Example of a good unit test: Situation: Custom CDK construct for Lambda to reuse a single IAM Role for most Lambdas in a stack, they all needed the same permissions Test: Define two Lambdas, ensure one IAM Role is created and both Lambdas are using that IAM Role Test: Define two Lambdas, one to use the IAM Role and one to use a different one, ensure the functions are using the correct IAM Role Overall, this is probably not an area to aim for 100% code coverage Image Source: https://pixabay.com/vectors/pyramids-blue-shape-egyptian-3d-23957/
- Thank you for attending QR Code: https://jbutz.dev/i38/resources