AWS Cookbook: Recipes for Success on AWS

If you are working with AWS on a daily basis or are looking into it then the AWS Cookbook by John Culkin and Mike Zazon should definitely be on your radar. Explore some of the recipes that can ease and improve your work in a discussion with Kesha Williams, senior manager at Slalom. Some of the recipes discussed look at security, networking, storage, serverless, and containers. 

---

Intro

Kesha Williams: Welcome to "GOTO Book Club." My name is Kesha Williams. I'm serving as your host today. I've been in tech for 26 years. I currently serve as a senior manager at Slalom in their AWS Cloud Residency program. I'm also an AWS Machine Learning Hero and an Alexa Champion. I am so excited to be here today with Mike Zazon and John Culkin, the authors of this amazing book, "AWS Cookbook: Recipes for Success on AWS." I'd love to start by having the two of you introduce yourselves.

John Culkin: Awesome.

Mike Zazon: John Culkin, if you want to go first.

John Culkin: Thanks so much. John Culkin, right now I'm a partner solutions architect at AWS. I've been in IT for almost 20 years. And I've always really been focused on using technology to solve problems. Prior to AWS, I was working at Cloudreach with Mike Zazon as well. And we were lucky enough to lead teams that were helping organizations navigate cloud migrations, optimizations, and modernization. So, that's part of where we got the experience to help us write this book.

Mike Zazon: So, I'm Mike Z Zazon. I am a senior cloud architect at AWS in the professional services unit. We focus on helping customers modernize their businesses by refactoring and migrating applications and lots of infrastructure work as well.

Why a cookbook for AWS?

Kesha Williams: Awesome. I love this book because I design workloads on AWS on an almost daily basis. This book has now become my go-to, no pun intended, reference. And the one thing that I love about this book is that it not only contains recipes for success but it contains recipes with pictures and code. I can say, in real life, I hate real cookbooks that give you the recipe but they don't show you the picture of what the cake is supposed to look like. And so I appreciated that about this book. Can you start by just telling us, maybe, Mike, why did you decide to write the book?

Mike Zazon: So, John and I, while we were working at Cloudreach, we worked with a lot of customers directly. Those customers had development teams that we would sit with. They would ask us questions all the time when we were working with them in their office. And we saw common questions come up and lots of patterns that development teams would take. When we talked about writing this book, we thought, "What if we could take those questions that we got so many times and just present them in a nice short format for people to be able to read through and consume?" And these are all based on our practical experience in helping people in AWS. So, it came together as part of the Cookbook series as an excellent fit, since they're kind of bite-sized, you can get through a recipe pretty quickly, but have a lot of value afterward.

Kesha Williams: Anything you wanna add there, John?

John Culkin: I think Mike summarized a lot of it. When I think of the cloud, I get excited about all the capabilities that are now possible. And I love the format of the book where it's problem, solution, steps, because we have all this new capability, that can lead to innovation, that can lead to agility, that can lead to global scale. But let's get down to the steps that are gonna solve problems with it and make our world better. So, I like the format of the Cookbook series that O'Reilly had. So that's what kind of motivated me to do this.

Security recipes in AWS

Kesha Williams: I would agree with that. I find that when I use this book, I have a specific problem that I'm trying to solve. I look at the table of contents, I do a quick scan and I find the recipe that helps me solve that problem. And like you said, they're small sizes. I'm able to quickly read it, understand it, and figure out what my next steps are. 

I've gone through this book and picked out my favorite recipes. We'll talk about some of those recipes today. So, the first chapter in this book is dedicated to security. I like that security is the first chapter because security is so important. I would say, John, did you intentionally pick security as the first chapter? And if so, why?

John Culkin: You're right. I think you're kind of getting the hint that we laid down. We made a conscious choice to choose security as a first chapter because it does spread across all these other recipes and all these other areas. And just because the cloud brings all these capabilities, we wanted to set a solid foundation of security, with policies, roles attached to principles, and providing recipes such as 1.4, which will allow you to use a policy simulator to see what the intended effects of your policy would be before it goes into effect. So, to give you that confidence that what you're creating or cooking is going to be secure.

Connecting to EC2 instances using AWS Systems Manager Session Manager

Kesha Williams: I would agree with that. John, security is a part of everything. It just weaves itself into a lot of the other recipes in the book as well. So, the first recipe that I'm going to talk about is, "Connecting to EC2 instances using AWS Systems Manager Session Manager." Now, I have never used this to connect to EC2. I typically use SSH. So, maybe, Mike, can you tell us, like, what are the benefits of using session manager instead of SSH?

Mike Zazon: So, there are several benefits to this. And this is one of my favorite features. It's one of the first things I teach people when I engage with them how to use because you essentially minimize any open ports on a machine from the network standpoint. And the benefits to that are, reducing the tax surface, you don't have to worry about port scanning and distribution of SSH keys or login credentials. So, when you start a session, you ask the AWS control plane to give you access, and this access is logged and audited. It's controlled through IAM. So, you're asking for that, you can control granularly who can access what, but not having the SSH ports open, is a massive benefit. And also something that John and I do quite a bit in this book is have readers deploy isolated subnets with the AWS CDK, to set up a foundation to expand on recipes. We use session manager quite a bit throughout the book. And when we do that, we deploy VPC endpoints inside of our VPCs, so that we don't even have to have an internet gateway attached to our VPCs. You could still access your machines and get a fast terminal within. And that's a pretty powerful thing. Sometimes you need an internet gateway to do something to serve something. But if you have a private workload that's completely isolated, it's all inside your VPC, it's a very high-security posture to take. So, that's why we like that service.

Recommended talk: Building a Smart Security Camera with Raspberry Pi Zero, Java and AWS • Mark West • GOTO 2018

Encrypting EBS volumes using KMS keys

Kesha Williams: It sounds awesome and more secure. I think I need to check that out. I noticed in the book that there are hands-on challenges. I think that's cool. Because you give recipes and then you give an opportunity to just try it out and be hands-on. So that's another great point of this book. The next recipe for security is, "Encrypting EBS volumes using KMS keys." So, just, in general, encrypting data at rest in your AWS account is a common safety measure. You can encrypt things in S3, DynamoDB, RDS, and more. So, the question that I have for you, and maybe John, you can take this one. Talk to me about the strategy of layering KMS on top of other security strategies, and then just the variety of data encryption strategies offered by KMS.

John Culkin: That's a great question and observation too, about how security needs to be layered. So, if you think about, maybe a web application where users are uploading files or some type of content to a web server, that network traffic needs to be encrypted. And that's one layer or one piece of security. But also, when that data is received by the application in-stored on an EBS volume, you want that to be encrypted. So, we felt that it was great to show customers all these capabilities that KMS gives them. I was really happy to learn...we learned a lot writing this book about some of the commands you can write to set default encryption keys for your EBS volumes very easily. So, we were really happy to see that. And hopefully, we did a good job of showing the readers what's capable with AWS.

Kesha Williams: Definitely. And something you mentioned about you all learned a lot when writing this book. I find that whenever I try to learn something, I try to learn it as if I'm going to teach it to somebody because it just really helps things sink in and it just helps me grasp all of the concepts. So, I'm sure you all learned a lot.

John Culkin: Absolutely, we learned a ton writing this book. And I think it was Einstein who said, "If you can't explain something simply, then you don't understand it." So, we kind of took that mindset to break down these complex at times, cloud topics into, hopefully, a simple way for everybody to digest and consume. I think just having the chance to sit down and think about what recipes and what example we wanted to convey, really helped us even further our cloud knowledge.

Networking in AWS

Kesha Williams: Definitely. That's what I loved about the book. Everything is so simple and easy to follow and understand. So, definitely a great job there. So, now let's move over to Chapter 2, which is all about networking. In the book, you mentioned that networking serves as the foundation and the backbone for all of the big services that you all covered in the book. I would agree, like, that without reliable and secure connectivity, what can we do? Not a lot. Now, in this chapter, I picked one recipe, and that recipe is, "Controlling network access to S3 from your VPC using VPC endpoints." I know earlier we heard the concept of a VPC endpoint. On AWS, there are several VPC endpoint strategies, so there are the gateway endpoint and the interface endpoint. So, my question is, well, both do the same thing, but what are the major differences between the two? And maybe, Mike, you can take that one.

Controlling network access to S3 from your VPC using VPC endpoints

Mike Zazon: Perfect. VPC endpoints are one of my favorite concepts and features within the VPC service. So, in terms of interface endpoint, you can have a network interface within your VPC and funnel access to AWS services through that network interface. And so what that means is when you have a service inside of your VPC that needs to talk to another service, like S3, DynamoDB, or Lambda, potentially, you can either go out through an internet gateway and call a public AWS API. Or you can install VPC endpoints within your VPC, and hit them privately. This again, allows you to not have an internet gateway attached to your VPCs if you don't need it and have all access private, which is nice. And the difference between the interface and gateway endpoints. Gateway endpoints are at the route table level, and interface endpoints end up being a network interface within your VPC. So, they have a private IP address in your address phase that you hit. AWS handles some of the DNS magic, we'll just call it, for now, to make that work from your application. But in the end, you take a private route over the AWS backbone to talk to the service through your VPC. So, very, very powerful concept. It's very secure and just a wonderful way to have some flexibility and security with your network traffic in your VPC.

Recommended talk: Thinking Asynchronously • Eric Johnson • GOTO 2020

Storage in the AWS

Kesha Williams: Right. That's what I like about it is just the security, because we're not on the public internet. So, if you all out there have questions and you want to learn more, check out that recipe in the "AWS Cookbook." Now, let's talk about Chapter 3, which is the storage chapter. There are several storage options on AWS. I would have to say that S3 is my favorite because I use it the most. What I love is a lot of the other services on AWS, are nicely integrated with S3. I picked two recipes from the storage chapter. And the first one is, "Replicating S3 buckets to meet recovery point objectives." Most developers, at some point, will need to have some type of replication on S3 for their applications. In the book, you mentioned the same-region replication and cross-region replication. This recipe discusses one-way replication, but there are several use cases for same-region replication. And can you just tell us more about some of the popular use cases for that?

Replicating S3 buckets to meet recovery point objectives

John Culkin: I'm glad you like storage so much that you picked two recipes from that chapter. So, it shows how much you like storage. And we love storage too. 

Kesha Williams: Or how much I don't like networking.

John Culkin: That could be it as well, but they're all great, right? And I think you had a good question about, what could we do with the replication of buckets. And there are a lot of great use cases. It could be for protecting against the corruption of data when users... And we love users, but sometimes they do the wrong thing. So, they could upload a corrupt file, or your application could have an error. So that could be a chance to create a need to replicate the data, to have something to recover from in case of corruption. Also, it could be data sovereignty issues, where you want to protect your data and ensure that it's replicated to another region that you define in AWS. We've just seen a lot of great usages, and I think it's one of the great things about the book, where we know there's going to be more use cases out there that we didn't think about. And we wanted to give readers the tools to create these outcomes, which help solve their problems for their organizations.

Recommended talk: Why Your Private Cloud is Probably a Bad Idea • Sam Newman • GOTO 2019

Observing S3 storage and access metrics using a storage lens

Kesha Williams: I agree. As I mentioned, this book has become my go-to guide because I'm building on AWS every day. So, it's starting to serve that purpose for me. The next recipe I have is, "Observing S3 storage and access metrics using storage lens." I was excited when I was reading this recipe about storage lenses because it's a service that I haven't had an opportunity to explore yet. So, just at a high level, can you tell everyone out there, what is storage lens? And talk to me about the free versus advanced metrics available. Mike?

Mike Zazon: I can take that one. Storage lens provides an observability layer on top of S3 that so many people have wanted for a long time. And like you, I'm glad this is here. You get a great insight into the metrics of how much you're storing in S3. Because if you think about it, in the past, when you had just been putting objects on S3, the only way people would have that observability is to look at their bill later or make a bunch of queries to some APIs and... And with storage lens, you get observability that is actionable. You can see things like the tiers of storage you're using. So, if you're an S3 standard or infrequently accessed, or maybe you've got things in the archive. You've got space usage, which is nice. These metrics can be rolled up. 

Something we talk about later in the book is AWS organizations in Chapter 9, which we might get to today. But being able to see all of your S3 usages across your org or just at your account level is nice. It helps you have just better control over what you're using S3 for, whether it's for application usage or maybe you have data lake usage, it's just a nice layer there. And as far as the free metrics and advanced metrics, the free metrics give you enough to make some just decisions on how to manage your data. But the advanced metrics give you so much more capability in terms of maybe scheduling some life cycle to different types of storage, and in the end, maybe driving some cost savings for yourself and your usage.

Databases in AWS

Kesha Williams: Definitely. I believe that anyone out there using S3 will find these metrics through a storage lens very helpful. So, check it out. Now, we're going to move to Chapter 4, and Chapter 4 is all about databases. There are a ton of database services on AWS. We have relational databases, graph databases, NoSQL databases, document databases, memory data stores, and the list goes on. There's a lot of flexibility when it comes to databases. There are even managed services that will help you manage your databases. So, the first recipe that I have is, "Migrating databases to Amazon RDS using DMS." And this recipe caught my eye because right now I'm in the middle of a project migrating an on-prem Db2 database to Amazon RDS, Postgres. And so when I saw this recipe, I just had to read it. And in the recipe, talks about using DMS. So, John Culkin, can you talk to us about how the mappings work in DMS using that Schema Conversion Tool?

Migrating databases to Amazon RDS using DMS

John Culkin: Absolutely. And excited to hear that you're working with Db2, that's gotta be a great experience.

Kesha Williams: I know.

John Culkin: The DMS tool is very powerful because you hear about the cloud, and you get excited about the capabilities, but how do you move there? So, having a tool like DMS and the Schema Conversion Tool enables you to accelerate your usage of the cloud, and hopefully, turn this data into information, which solves problems. And as you mentioned, the databases in AWS are purpose-built, for solving problems most efficiently and effectively. I love the DMS and Schema Conversion Tool because it makes it easier for developers to not have to be a DBA with years of expertise, to be able to change a database and then convert it to a format, which is, we'll call more cloud-friendly, to then take advantage of all this availability, security, reliability, sustainability features that the cloud has available. So, it was really exciting for us to just hopefully give these readers the capability now to go out and to make these things happen with these tools.

Recommended talk: WServerless Chatbots with Amazon Lex& AWS Lambda • Chris Munns • GOTO 2017

AWS and Serverless

Kesha Williams: Right. Definitely. DMS, as my claim to fame, is being a Java developer, definitely not a DBA. And the DMS service and that Schema Conversion Tool, as you mentioned, I don't have to be a DBA to do that piece of the work. It's been helpful on the project that I'm on now. Now, we're going to move on to Chapter 5, that's dedicated to serverless. And I remember when I first heard the term serverless, many years ago, I was like, "Server, what?" That's not even possible. I think serverless has been one of the more popular buzzwords in the IT industry. All that to say, there are a ton of serverless services on AWS. The first recipe is, "Configuring an application load balancer to invoke a Lambda function." Now, the load balancer is very flexible in that it can have many different targets, like Lambda functions, containers, and EC2 instances. I mentioned before that the book has hands-on challenges, which I think is cool. One challenge associated with this recipe recommended putting an Amazon API gateway in front of the Lambda function. And so my question for you, Mike, is what additional capabilities do you get by going through the API gateway instead of directly to the Lambda from the load balancer?

Configuring an application load balancer to invoke a Lambda function

Mike Zazon: That's a great question. And the most frequent pattern that we see people use when they're developing, potentially microservices and APIs using Lambda functions are using Lambda with API gateway. Some of the great features of API gateway is being able to have promotion within an environment. You can have all of your environments and your API laid out, and then promote that up through, and then have lots of control over the HTTP methods that you accept for those functions and handing them downstream. API gateway also has some great integration with the network load balancer. So, if you had to hand off to a compute service, maybe something running on EC2, you could have API gateway use a private connection into a network load balancer, and have your EC2 instance respond. So, maybe a portion of your API is running on your legacy server, but you're slowly migrating your application into microservices and able to break those into Lambdas. 

During your migration, you could have half running on EC2 and half running in your Lambda, and then take you time and move your entire API over to serverless in a microservices way, but tons of great capabilities there. It's a nice pattern. Offering it as a challenge is something we thought would be interesting. A really simple use case with the application load balancer is one thing. But once you take and accept that challenge, you'll see so many capabilities layer with the API gateway.

Recommended talk: What Does THIS Button Do? Serverless and IoT • Eric Johnson • GOTO 2019

Packaging Lambda code in a container image

Kesha Williams: I agree that when I think about past projects that I've been on, we use that pattern to put API gateway in front of a Lambda function. So, that's great that that pattern is in this book to help people learn it. Let's take one more recipe from the serverless chapter, and this one is "Packaging Lambda code in a container image." I think it's so cool that serverless code can be packaged in containers. And I know this feature is fairly new. So, my question is, maybe, John, you can tell us why this functionality was added, and the different run times that are supported.

John Culkin: I'm glad you picked two serverless recipes as well. I was worried that I wouldn't get a chance to talk about serverless because I think it's awesome that it empowers developers. When you hear about the cloud and AWS, it's really about removing the undifferentiated heavy lifting is the buzz phrase, if you will, to allow developers who know how to write Python, who might be familiar with a Docker file, in this case. So, let's not make them learn something new, let's meet them where they are and provide them these new mechanisms to get their code into the cloud, have it be executed, and then provide great results for the users of their applications. I thought this was a great example of how AWS listens to customers and hears about what they want it to do with their code. They might have existing workflows that utilize Docker files. So rather than having to convert Docker files into another format, this is a great way to take your existing workflow, your existing Docker files, and then hand it off to Lambda to have that code executed in a serverless fashion, which is awesome.

Running containers on AWS

Kesha Williams: I would agree. That is awesome. I know, when that was announced, everyone was super excited and happy about it. 

I think that's a great lead-in to Chapter 6, which is dedicated to containers. And I've been in tech for 26 years. And I remember the world before containers. I also remember the world before CI/CD, and it wasn't a fun place to be. What I love about containers is that it just ensures consistency whenever you deploy your application to different environments. That is a big win. And when I look at running containers on AWS, there are several options. There's straight EC2, ECS, EKS, EKS plus Fargate, ECS Anywhere, EKS Anywhere. And so I love the flexibility. The first recipe that I called out, which is super important, it's "Scanning images for security vulnerabilities on push to Amazon ECR, which is the container registry." Can you talk to us about the common vulnerabilities and exposures database, what that is and how it integrates with ECR? Mike?

Scanning images for security vulnerabilities on push to Amazon ECR, which is the container registry

Mike Zazon: Definitely.

Kesha Williams: You can tell I'm switching each question. So, yeah, it's your turn.

Mike Zazon: Perfect. I can answer that. This feature gets me excited because it provides actionable very, very critical feedback about the security posture application. So, in many cases, in a Docker file, you'll be installing some packages and dependencies, things like maybe the Apache web server or maybe some Python libraries. When you do that, you're installing a specific version, in most cases. And these being open source packages, many times they're improved, security vulnerabilities are found and patched, but they're also reported and aggregated in a vulnerability database. They're assigned a risk score so that you can understand the risk level of that specific vulnerability that was found. So, if there was some sort of remote-code execution vulnerability, it's probably going to be something closer to a 10. And if there's something like some local file right capability, that was only to temporary space, and that was it. Maybe that's a little bit less, maybe like a five. So, of course, all security vulnerabilities, we should take seriously. But the ones that are 10s are very, very actionable immediately for every organization. With ECR scan on push, you can get feedback about these scores when you push your container image. Then with those results, you can decide whether or not to fix it before you deploy and run your application to something like ECS or EKS. And you mentioned CI/CD as part of a build process, a build push process. You could potentially fail a build if you found vulnerabilities higher than a certain score so that you knew right away, your developers knew right away not to take that image any further, let's fix those vulnerabilities, and then push and get it the build to pass. So, it brings in a lot of great CI/CD possibilities there too.

Kesha Williams: Right. That sounds like an awesome feature that everyone should take advantage of. I like the tieback to failing a build if it has high-security vulnerabilities. Handy feature. Okay. 

Recommended talk: Containers From Scratch • Liz Rice • GOTO 2018

Big data and AWS

Kesha Williams: Now we're going to move on to Chapter 7, which is dedicated to big data. I think the book mentions that data is the new gold. Data is the new gold. I think there's more data than gold though. And what excites me about big data, I'm a huge fan of machine learning and how it allows you to find new insights into your data. So, because I love machine learning, I love data. But before we go to machine learning, let's focus on data. And I found in the book several useful recipes. Today, we're going to talk about, "Automatically discovering metadata with AWS Glue crawlers." Now, I remember, in the past, having CSV files that I needed to parse and find metadata from, and I would have to write a script maybe in Python or Java. But because of a service called AWS Glue, I no longer need to do that, which is super exciting. So, my question for you, John, is how easy is it to configure a Glue crawler to scan source data? And can you also talk to us about the debugging process?

Automatically discovering metadata with AWS Glue crawlers

John Culkin: Awesome question. And I like how you tied it to machine learning, which is such an exciting topic as well. But you need to have data, clean data, and organized data to be able to train those awesome AI and ML models. So, a tool like Glue will help you get a point-and-click interface, right out of the box, very easy to use. When you present it with mountains of data, be it structured, semi-structured, or unstructured, you have to make sense of it and kind of wrangle it in if you will, and put your arms around it and enforce those rules and gather those initial insights. Similar, to what you're talking about with the CSV files, there's data inside those columns, but also there's metadata surrounding that. When was the last time it was modified? Who modified it? When was it uploaded? So, those types of tidbits help you make better decisions down the road when you're analyzing and trying to gather insights from that data.

Artificial Intelligence and Machine Learning with AWS

Kesha Williams: Yes, definitely a useful service, as are most of the services on AWS. I must admit. So, let's jump straight to Chapter 8 which is my favorite chapter, "AI and ML." I mentioned earlier that I am a machine learning hero. So, I believe this was my favorite chapter. I found so many of the recipes to be useful. It was very hard for me to pick one or two for us to talk about today. So, the first one that we're gonna talk about is, "Transcribing a podcast." There are a lot of us out here with podcasts, and I've appeared on many AWS-related podcasts. Like, what if you need to create this text transcript from your podcast? Of course, there's a service on AWS that will help you do that. So, Mike, my question is, can you talk to us about the process to create a transcript from an MP3-based audio file? And then which languages are supported?

Transcribing a podcast

Mike Zazon: So, we present this recipe in terms of trying to show the ease of using the AI services on AWS. We were excited that it is so easy for a developer or just a user on their command line to issue one AWS CLI command and get a response back with text from an audio file. Fantastic service. So, if you think about, maybe a podcasting platform building this into their service, as soon as their podcasters would upload their MP3-based podcast, the service could automatically generate transcriptions, which could then let all kinds of great stuff happen. You could have, different types of users from an accessibility standpoint, be able to consume your media, could then run searches on top and pick out, you could summarize portions, and then, bring those on top. It's amazing what you could do with that. But that first step, in that one-line command we give you to initiate that transcription, was such a powerful command. That's leveraging so much training behind-the-scenes on transcription. And as far as the number of languages supported, I'd have to look at the official documentation. I don't know off the top of my head. But that's a great question.

Recommended talk: Taking Machine Learning from Research to Production • Robert Crowe • GOTO 2019

Redacting PII from text using Comprehend

Kesha Williams: Check out that service. Literally, at the click of a button, you can take that audio file and have that text transcript that you can then upload on your website. So, super cool. The next recipe from the AI and machine learning chapter is, "Redacting PII from text using Comprehend." So many projects that I've worked on have like PII data, passport numbers, and Social Security numbers. And it's always a huge concern because that's information that we have to keep safe. So, my question for you, John, is let's say you have data stored in S3. How does Comprehend help with detecting PII, and how is that different from what Macie provides?

John Culkin: That's a great question. One of the benefits I think of using Comprehend to detect PII, is to not only detect but also redact PII to place it in a workflow. So, an example that we talk about is if you have maybe a workforce who needs to look over documents, and the documents may have things like passport numbers, as you mentioned, Comprehend can not only detect which documents have this sense of information but also then redact those fields so that the work, the data can still be processed downstream. It's a great way to add security to your workflow by removing those fields, but also by detecting those fields, because you may want to handle a document differently if you know that it has PII in it.

Account management in AWS

Kesha Williams: Yes, that's a useful service. And like I mentioned, almost all projects that I've worked on, have some level of PII information that needs to be protected. I enjoyed the AI and machine learning recipes in this book. Now, let's go to the next Chapter, which is related to account management. I picked one recipe and it's, "Modifying tags for many resources at one time with the Tag Editor." And what I've seen, on some of my past projects when we were just getting started with the cloud, tagging wasn't something that we considered. But as we matured, we needed to go back and tag resources that were already in production. And so my question for you, Mike, is how easy is it to modify tags once resources have been created? And are there any resources that can't be tagged after you create them?

Modifying tags for many resources at one time with the Tag Editor

Mike Zazon: I agree with you. The importance of tagging is so massive, especially if you have had to go back and retag things and amend tags or change tags. Many times we see people that have a little more cloud maturity, they might be automatically tagging things through other mechanisms, like maybe they're using CloudFormation, or maybe Terraform, or something like CDK that the tags are automatically applied to the resources that they're creating. But if you're deploying things one by one, or if you're maybe a new user or manually building things, you might not be able to take advantage of that automation. So, Tag Editor lets you edit tags at scale for many resources. Maybe you've got an account that has all of your stuff in it and you just wanted to be able to apply a tag on everything that says it's yours because you're about to invite somebody else to start using your account, right? So you can start to tell the difference between which is, whose resources are what. This is a great way to do it. So you can select everything in your account that's tagable and apply your tag. Maybe it's a name tag or some sort of billing tag if you're gonna split billing with somebody, but you can do that in a batch sense with Tag Editor and maybe even edit that tag later if you need to. So it lets you search, query, and batch edit tags at scale.

Enabling CloudTrail logging for your AWS account

Kesha Williams: I think that's a very useful feature. Based on timing, it looks like we have time for one more recipe from this chapter. The next recipe that I'd like to talk about is, "Enabling CloudTrail logging for your AWS account." This feature is very important. I just relate everything to my past experiences. And I remember when there was a security incident and we were trying to track down, what was the flow that led up to this incident. And we went to CloudTrail and the default logging provided wasn't enough. So, from that experience, we learned to go in and manually create our CloudTrail. That was a big lesson that we learned. So, John, can you tell us some of the limitations of the default logging, and why manually creating a trail is important?

John Culkin: That's a great question. And you bring up a great example of working in an enterprise, trying to track down an issue that may have occurred, where there was some confusion about what happened, who did it, you know, when did it happen. That's where CloudTrail comes in and shines. And as you mentioned, a massive best practice, we really can't stress it enough to configure CloudTrail, to log to an S3 bucket with retention that you're comfortable with. So, obviously, the more you log, there'll be some more costs associated, but that's very important data. You're going to have that data around to interrogate, to prove what happened, who called the APIs. One of the things we love about AWS, of course, is that its API-driven. Then we wanna have a log of what those APIs were doing and who called them. So, as you mentioned, CloudTrail is a great way to get that data and focus on having it when you need it.

Short CLI commands that save time

Kesha Williams: Yes. So, a useful feature to help track down just the trail of who did what and when. That brings us to the, not last chapter because it's an appendix but it talks about fast fixes. So, just several short CLI commands that will help people save time. And I just want to call out quickly my top three. So, you have a CLI command for populating data in a DynamoDB table. That's such a huge time saver. Another fast fix is enabling encryption by default for new EBS volumes in a region. Then I think my favorite because I've needed to do this, create a pre-signed URL for an object in S3 that expires in a week. So, can you just, maybe, Mike, talk to us about why you decided to add the appendix of fast fixes?

Mike Zazon: Well, that's a great call-out there, especially this top three. I agree. John and I both found, especially working with so many different folks, so smart in terms of cloud and programming. We all keep our libraries of one-liners and things and snippets. And with the AWS CLI being so powerful, we tend to have a big amount of those. So we try to distill down to the useful ones that we use, maybe all the time, especially like populating a DynamoDB table very quickly, so you can just test, make sure things are working okay. That's just a nice thing to be able to pull quick and throw it in. Also, there are some commands in there that John and I used throughout the book, to maybe clean up some resources or just do some other quick actions. And we built these commands, and we wanted to share them because frankly, we know there are use cases for them. But we might not be covering everything. We thought this is a great starting point. And, you know, maybe, in the future, we'll release some new ones on our GitHub organization github.com/awscookbook, where we're putting some new content frequently there. So, these fast fixes, are good to have in your tool belt when you're working on the command line with AWS.

Kesha Williams: Definitely, they're very useful. Well, I think that brings our time together to a close. But I just have to say, I enjoyed reading this book. I would love to see this book on the best sellers list because it has become my go-to source. And anyone working on AWS will find this book useful. So, thank you so much, Mike Zazon and John Culkin for writing this book and for spending time with us today.

John Culkin: Thank you so much.

Mike Zazon: Thank you so much. I appreciate it.

Kesha Williams: Okay. I think that's a wrap.