Rowan Udell: 10 Years of IAM, Writing a Practical IAM Guide, and Serverless Trends

About Rowan

Rowan is the Cloud Practice Director at Versent. He likes Javascript, Python, and Golang. He writes about Serverless, DevOps, software development, CI/CD, and AWS.

You can find him online on Twitter and his website.

Transcript

Adam: Hey, everyone. Welcome to AWSFM, a live audio show with guests from around the AWS community. I'm your host, Adam Elmore, and today I am joined by Rowan Udell. Hi, Rowan.

Rowan: Hello.

Adam: Thank you, Rowan, for a very short notice show. You actually agreed to do this show, the morning of the show, for you in Australia, which is definitely the latest we've booked a show. I had to throw it up on the website super fast last night, and just been preparing this morning feverishly. We had to work through some audio stuff, whole bunch of stuff, but you made it; we're here, we're on the show. We did it.

Rowan: Indeed. Look, it's nice when something can come together so quickly.

Adam: Yeah, exactly. It doesn't always work that way. I guess I want to start with your story, your background getting into technology and specifically getting into the cloud.

Rowan: Yeah, sure. I joined a consultancy six or seven years ago now. I was leading a team of developers and was just ready for a change from the managerial side of things, and was hearing lots of stuff about the cloud, was gaining more traction. I had used it for myself a few years earlier, but it was still in the early uncertain days of cloud, at least here in Australia. I took a chance and I've been doing it since, so it's worked out pretty well.

Adam: You're writing it, I'm calling it the IAM book. I don't know if that's the official title, but you're writing a book on IAM. Could you talk about that project?

Rowan: Sure. It's called the AWS IAM guide. I'd like to call it the IAM book. It's how I refer to it, but there are some other ones out there. There's obviously the AWS IAM user guide as well. It's pretty hefty and definitely deserves a title of book. I thought that I'd been using AWS for a fair few years, pretty exclusively. I had this awakening, this epiphany where I was like, "I use IAM every time." It's basically the only required AWS service, but I'd never actually devoted time to learning it and mastering it. I looked around and I actually saw Alex's book, who you've already had on the podcast, Alex DeBrie's book on DynamoDB had just come out, and I was like, "Man, I just want that but for IAM. It wasn't there, so I thought, "Well, maybe I should write it." It's taking a while but it's still progressing. It's still progressing. I think if I can get it out within a year of coming up with the idea, I'll be happy. I think I've got about a month and a half until then.

Adam: Oh, okay. Pressure's on.

Rowan: Yeah. It was re:Invent last year, that I came up with the idea and bought the domain name and all those classic new project things. Then I decided to move into state in the middle of a pandemic, and so it was slow going for a while there, but it's definitely not forgotten.

Adam: I want to dive in kind of deep on IAM, because it is sort of a forgotten ... It's not a forgotten service, but it is ... I think in learning AWS, you just, for me at least, my journey, you just learn what you need to get by. You're really learning about the other services and then you just kind of ... You get obligated into learning enough IAM. It looks like putting a lot of wild cards in and doing things just to get it to work. Could you talk about some of the common mistakes or misconceptions about IAM?

Rowan: For sure. Your experience is probably the most typical one. That was my experience for the first five or six years of using AWS exclusively, every day at my day job. You can get by doing that. All of the blog posts and the quick starts, they all focus on getting something working. You can get things working, especially if you turn on god mode and just do star, star. It's probably not secure and you have had to wrangle some of those issues that you develop a bit more appreciation of doing it right. Then you go down a rabbit hole of getting IAM to an optimal configuration. It doesn't happen by accident, unfortunately. We're not there yet.

Adam: Yeah. There's no pit of success with IAM, least privilege. I guess you were part of the 10 year celebration, which was fairly recently. IAM had a 10 year celebration. Your blog post least privilege was part of that celebration. Could you talk about, maybe for anyone on the call ... I'm guessing we have a pretty technical group here, but anybody listening to the podcast that doesn't understand least privilege, could you start there? Just explain what that concept is.

Rowan: For sure. This is an idea that's definitely not unique to AWS. It's pretty prevalent in the identity and access management space, because obviously that's what IAM stands for. It's all around having the right level of access for the job at hand. There's a lot of nuance in that. Where you as an individual might have multiple levels of access, but if you're just going in to check on something and just have a look at something, and you're not intending to change something, then you probably shouldn't log in with the permission to actually be able to change something, even if you as an entity have that level of access. It's about making sure that when you go to do something, whether it's automated, or heaven's forbid a manual process, you're properly prepared with the right level of access and no more than that. That means that if anything goes wrong, your blast radius is limited. The worst thing that can happen is the thing that you intended to happen, as opposed to as we were saying before, running around with admin privileges where if you get something wrong, it can go wrong pretty badly.

Adam: You mentioned automation. I wanted to talk about IAM ... and I say, "I-AM." I-A-M.

Rowan: You made me realize I haven't actually addressed that in the book. Is it I-AM? Is it I-A-M? Is it ... I don't even know. I'll make something up.

Adam: Okay, great. I did read somebody. I can't remember who it was; it was somebody I respected said something about it being I-A-M, not I-AM.

Rowan: That's my go-to.

Adam: Okay, great. IAM is shaped a lot, at least from a developer's perspective, by the tooling you're using. For me, one of my favorite parts of going form cloud formation to the CDK, is a lot of the utilities that the CDK provides, granting privileges on resources as opposed to having to define them, which can get verbose in cloud formation. I don't know if you're familiar with the CDK or if you have opinions on infrastructure as code and its role in security in IAM on AWS.

Rowan: Definitely, definitely on the infrastructure as code bandwagon, when it comes to everything AWS for that matter, it is a challenge. It's not something, like I said, that happens by accident. You have to still unfortunately work for it. The tooling is getting a lot better in this space. There's actually been some big changes over the last few months really, both in the community but also from AWS themselves. The CDK, I haven't used myself yet, but I'm an old school cloud formation user. The CDK is great because it definitely takes people a lot further out of the box. It's ultimately a good thing.

Rowan: It gives them some sensible defaults and avoids some of the bigger pitfalls, from what I understand of the various constructs involved. There's always pros and cons to every way, and unfortunately the only real solution right now is still a composite approach. You still do need to wrangle a few different sources of information, potentially different tooling, so that you can really, really get to that least privilege nirvana. These things will continue to get better, like I said. They've already improved a lot recently. I think ultimately the CDK, while it definitely has a better set of defaults than just the existing default, which is user admin so that you can do whatever you want, because no one ever comes back after they get it working, to-

Adam: I never have.

Rowan: come back and tighten it. Then once you start doing that, you start getting other areas. Even it's like some of the features that are just being released from AWS, the more verbose errors to say, "Hey, this failed because of this particular type of policy." That didn't exist six months ago. Like I said, it's definitely getting better there. Again, it's also something that you have to do. This is your responsibility on AWS as part of the shared responsibility model. AWS gives you these secure tools, but it's up to you to use them and take advantage of them.

Adam: Are there other tools? This is a question I've had personally, as I build stuff out on AWS. I often feel like there's probably someone making, whether it's third party or it's actually Amazon, tools that just make it easier to accomplish good security practice. Are there anything like ... I don't know. I'm thinking CLI tools that'll ... I think there are tools to inspect your cloud formation and warn you if there are security problems with that. Is that from an IAM perspective, or are there anything, any tools out there you use or you're aware of?

Rowan: Yeah, there's a few. Like I said, there's been a few announcements recently. The one that jumps to mind is probably Ian McKay's iamlive tool, which basically sits on your, runs a proxy locally to listen to your requests to AWS, and then generates your policy based on the actions that you're actually sending to AWS. It uses this nifty feature that-

Adam: That's exactly what I'm looking for.

Rowan: Yeah.

Adam: It's recording the activity in your account?

Rowan: Yeah.

Adam: You turn it on ... Okay.

Rowan: Yeah. That's probably one of the best now, but that's still just in dev. You're not going to run that in production. AWS recently added a bit more support for their policy generation tool in IAM itself. Until a couple of months ago, it only supported a very limited number of services. They've added a whole lot more. I think it may be up to 50 or 60. Unfortunately, that's not the, whatever they're up to now, 200 plus services. It definitely does the main one, so that's another big step forward. It actually looks at your cloud trail log and then generates a policy based on that. There are going to be some gaps there, just because not everything is actually in cloud trail. Again, it's a lot better than it was six to 12 months ago.

Adam: I'm so glad I asked this. The IM live, I will look that up after the call. I get to remove another item from my Trello board. I've mentioned it on a previous episode. I've put ideas of things I want to exist. I had considered building that exact thing, basically turn it on and the CLI record your account activity, and then spit out the actions or whatever that you need to put in your policy.

Rowan: That's it. That's exactly what Ian's done.

Adam: Good to know it exists. I don't need to build it. The show is just helping me cut out things for me ... I thought it was taking all my time; it's actually giving me time back. It's fantastic. One of the questions I had for you is: in teaching IAM, are there common struggles you see? I know for me, one of the things I struggled with early on in my learning around security on AWS, is the difference in resource based policies and identity based policies. Are there common things that you run into, that are difficult to teach or that are hangups for students, when learning IAM?

Rowan: Good question. The ones that have really stood out to me is probably what you've touched on there. The different types of policies and how they interact with each other; there's policies, and policies, and policies, and policies. If we want to get specific, there's SCPs at the organization in the account level. There's obviously resource policies. When you're talking about S3 sometimes they're called bucket policies because that's the resource. It's not always using the same name. There's identity policies, but you can have identity policies on things that aren't necessarily identities, like groups. There are permissions boundaries and there are session policies. All of these interact with each other in the context of the request that you're sending. Once you break it down, ultimately IAM is a very simple service because it has to be, because it's a global service and handles millions and millions of requests, as they shared in their 10 year anniversary post. Even simple things when combined together, become complicated.

Adam: Absolutely. When I think of the resource based policies and all of the complexity ... KMS is a good example for me. I feel like I'll never understand KMS IAM. I hope there's something in your book that brings that, makes sense to me, explains it like I'm five. It's not a concept I feel I can grasp.

Rowan: KMS is an interesting one. I wasn't sure how much to cover it, just because it is unique. It has to be because of its job and just how important it is to security. The problem with KMS is if you get it wrong, you find out how many other services depend upon KMS for doing all of their encryption, but you find out the hard way because everything is behind another service.

Adam: Before we move on outside of IAM world, I wanted to just ask: I feel like there's things that I don't know I don't know about IAM. Are there any other tidbits, as you've written the book, things that are worth sharing, I guess?

Rowan: That's another good question.

Adam: It's a very open-ended question. I'm just looking for anything I don't ... I don't want to leave something cool out.

Rowan: It's just been a really interesting process writing this book. Obviously, it's taken me a fair while. I thought I knew AWS pretty well. That's why I decided to take on the project. I've just been surprised by how much I'm still learning today. After using AWS exclusively for the last six or seven years, after writing ... I wrote another book about AWS before this one, and now I'm writing this one. I'm still learning stuff. I'm still finding these tidbits hidden away in different parts of the various user guides. A lot of people give the AWS documentation a bit of flack, but I really like it. The only negative I have to say about it, is that sometimes you'll read the thing that's really important, but you won't appreciate that it's important until you go away and actually get burnt by something, and you come back in like, "Ah, it was right there in the box," but it was line number five out of 10. You can't say the docs are wrong. They're right; they're just not always having the right emphasis, I guess is how I'd describe it.

Adam: Yeah. That makes sense. I did think of another IAM question for you that's practical for me. Every time I create an IAM user, I feel guilty, because I know better and I see the people I respect on Twitter tell me I should never do that. What are some of the alternatives there, and explaining it like I'm five? For me as a freelancer, I work for maybe a small business, and they don't really understand AWS. What are my options here, I guess, to set them up so that they're not just handing me an IAM user?

Rowan: In that scenario, there's no doubt that the IM user is well trodden path. Probably, I'd lean towards potentially if you had your own AWS account and that was yours and yours alone, you could deploy a role into their account with a-

Adam: I've got a few.

Rowan: A trusted ... I bet ... a trust relationship back to your account. You're almost mimicking an SSO. You're still using IAM as your identity store, which is maybe not ideal. If you deployed a role into their account that trusted yours, so that you could assume that role, then there'd be no long lived credentials you'd need to worry about. It's always in their control. If they ever decided to lock you out, they can delete that role and it's all nice and tidy. That really would be the ideal way to do it, I think. Once you get beyond that-

Adam: I put you on the spot here, with a very specific use case, for sure.

Rowan: Yeah, no. I should be able to answer it. Once you get beyond that, you've really got to start looking at identity providers and having SSO set up, and potentially opening a whole lot more can of worms. The role is how AWS accesses your account. You have service linked roles for services like auto scaling. You trust the service and you say, "Yes, this service can come into my account and they can do things according to these parameters." That's kind of what you're doing for your customers.

Adam: That actually helped me a ton and I can't wait to re-listen to this podcast and pick that up again. I think that was maybe the missing piece for me. I didn't think of it from that perspective, just how the services are interacting in my account. It's the same concept. I want to talk a little about non-IAM things. You're a principal solutions architect at Stax. Could you first, I guess, explain what is Stax?

Rowan: Stax is a ... If I had to sum it up in just a few words, we're kind of going with a cloud management platform, but exclusively for AWS. We basically help customers just with running a business on AWS. You think about obviously there's a whole lot of different services that customers come to AWS to use, but they all need to worry about things like access management and cost management. Having the elastic cloud is fantastic, but you want to be on top of what you're spending. Then obviously there's security is something that's common to all customers on AWS. These are the things that we help our customers deal with. We also help them take a multi-account approach. We help them not create IAM users everywhere, and just live all of those best practices that AWS is getting better and better at sharing and giving their customers a bit more direction. We want to go that extra step and really make it easier for customers to do those things.

Adam: What does your role specifically look like there?

Rowan: I spend most of my time talking to new customers and prospective customers. I do a lot of the technical pre-sales. I'm having lots of conversations about things like talking today, like what is the best way to use AWS. In my previous role, I was an AWS consultant or a consultant for an AWS partner. I've spent a lot of time just helping customers just get the most out of the AWS cloud.

Adam: You've written a few books. The IAM book, you've coauthored more traditional books. I would say traditional in the sense that, like traditional publishers, I believe.

Rowan: Yeah.

Adam: The IAM, is it self-published?

Rowan: Yeah. That one I'm doing on my own. It's been an interesting experience.

Adam: One of the questions I had, which I think you already answered at the beginning is the Alex DeBrie and the DynamoDB being an inspiration for that. Could you talk a little bit more about that?

Rowan: Yeah. Again, when Alex came out with his book, I'd already been using DynamoDB pretty extensively for a few years. I'd been doing a lot of work in the serverless space, and so obviously DynamoDB is a good fit there. I was doing single table design. I was pretty comfortable with that kind of thing. Then I read Alex's book and it was just a whole nother level of depth. That was something that was really inspiring to see. Again, the bare bones of the service is all there in the user guide, but it's not necessarily presented in the most practical way. I felt like the same opportunity was there for IAM. Anyone who's written a book, I said after the first book that I'd never write another book again. Enough time past and I'd forgot about that, and then I was like, "No, no. I can do this. I've done this before. How hard could it be?" I thought I-

Adam: It's like having kids.

Rowan: Yeah, exactly. I thought I'd get it done in three months and here I am nearly a year later and it's not done yet, unfortunately. It's getting there. It's not-

Adam: It's been a challenging year. It's been a couple of years.

Rowan: That's what I tell myself.

Adam: I wonder if we're going to see more of these, the book for a given service. I think that's great. I know the Cognito book's in the works. There's 200 services so there's a huge opportunity here for people to stake out area of expertise.

Rowan: Definitely. I guess the reality is everyone learns differently. Some people are going to prefer more video based or audio based. AWS continues to put out blogs around things like EC2, which has been around for a long time, more than 10 years. I think it's just the nature of learning, is that the same of similar information presented in a different format is still going to be valuable to different people. My take is, what I'm planning for with the book is to be very, very practical. I actually got halfway through writing it, and it just felt like the IAM user guide but written by Rowan rather than someone from AWS. I didn't throw it out but I put that to the side and said, "No, no. I'm going to do something more practical."

Rowan: Now I've gone for a more scenario based approach, which now that I think about it, that's what Alex does in his book. He's got a lot of different scenarios there. My one's going to be a little bit more focused on a variety of different services, but just trying to illustrate the practices of IAM, AWS IAM as I've seen it in the real world, and a lot of the different challenges. The first scenario I wrote was how to share an S3 bucket, because there's just this really good tweet by Corey Quinn where he just makes fun of ... So many people mis-configure their S3 buckets. There's a lot of nuance in it, and obviously people just get frustrated and just open it up to the world, and bad things happen.

Adam: Very bad things happen. I think we've all seen those headlines. You mentioned AWS are still writing blog posts about EC2. That leads me to my next topic, which is serverless. You're plugged into the serverless space. I wonder if you have thoughts. There's a lot happening right now, I feel like. I've had some of the guests talking about some of these things between serverless inc and serverless cloud. You've got SAM accelerate. Yesterday, I had Dax on, talking about serverless stack and some of the cool stuff they're doing. Do you have thoughts on all these new fun shiny things we get to play with in serverless land?

Rowan: First of all, I haven't played with many of them. At the moment, SAM is probably my go-to because I do still prefer CloudFormation. I used to be big on the serverless framework before things like SAM existed. Ultimately, I think it's all a positive thing, that where serverless still has plenty of space to mature and to improve is in the developer support. People on the call that know this better than I do. It's all about making serverless as accessible. I'm excited to think that there are developers who are starting now, getting started now, that won't ever have to configure a server, and yet they won't have to give up on any functionality. They'll just have to do things differently. It is a challenge, because there obviously is fragmentation. The fact that there's multiple cloud vendors in this space is also going to contribute to that.

Rowan: You obviously have the platform specific tools. I'm deep in AWS so I don't need to worry about those other ones, but then you have providers like serverless and Terraform and things like that, that come on and try and unify. It's like the XKCD comic where it's a new standard. It's a new thing. Now you have even more. That's not necessarily a pro, but I feel like we have to go through that phase in order to come out the other side. Ultimately, choice is generally going to be a positive thing in this space.

Adam: Absolutely. I love the idea of what new developers could be coming into with the serverless maturity that we're seeing. I've tweeted about it and I think I've spoken about it on the pod, but I think ... I just called it the pod. I swore I would never call it the pod; the podcast, the radio show, whatever this thing is. Just the idea that someone coming into serverless; if that's their first foray into the cloud, there's so many things they don't have to learn that maybe people five years ago getting into the cloud had to understand.

Adam: You could come in and have no background as an engineer, and I feel like it's so many fewer concepts. Not that serverless is easy, but I think it is a different set of things you have to learn. I think everyone has to learn those things. Even if you have a more traditional engineering background, you're having to learn a lot of these new serverless concepts. I think it's a nice thing that it's sort of a different experience from what we're used to. It opens up doors for people who don't have that background. They don't have a Linux background, or they don't have ... Like I've said, you don't have to even know Sequel in serverless land. You can just do the Dynamo thing.

Rowan: Definitely. I think I often use the phrase, "cloud native." If you're developing a service application, you've got to be a lot more aware of the provider involved, that ultimately that's a lot further up the stack than worrying about the IP table's configuration on your Linux server and things like that. It does mean you have to learn things like identity. You can't ignore those, or you ignore them at your peril. Ultimately, I think that's going to be a better outcome, because you can use that cloud knowledge elsewhere as well, in your application development and managing things.

Rowan: I think anything that gets people out of the weeds and closer to the business end of the development process is going to be a positive in the long run. I certainly don't miss configuring servers and firewalls and switches and all this other kind of stuff has gone away with the cloud, and especially with serverless. It's all in the past for me. I hope, anyway.

Adam: Same. We got a few more things to do here, so you can't go yet Rowan. I know it's getting late in Australia.

Adam: One thing I want to do is go through a list of rapid fire questions. This was an idea that a former guest sent me, and I love it. Basically, just quick hits, things that are curiosities of mine, if you'll humor me. First, do you have a favorite tech blog?

Rowan: Tech blog, ooh. Are we talking about AWS tech or-

Adam: Anything. It's okay if you don't have one. I sort of just consume whatever I see.

Rowan: No, no. I definitely do. Probably dev.to.

Adam: Oh yeah. It's sort of a community of blogs. What about people who've inspired you? If you have people in the AWS space, that's great, or more broadly just in technology. Role models you've had as you've worked through your career in tech.

Rowan: Another good one. If I think about who I'm following on Twitter and stuff, there's definitely ... I'm really enjoying what Corey Quinn's done. He's made being snarky at AWS into a full-time career and a business. I think that's pretty admirable. He says a lot of things that I think but don't necessarily have the guts to say. It probably doesn't help that I work for an AWS partner as well, so there's that. Other than that, I think we said Wardley was on at the moment. He's somebody I follow and pay close attention to when he starts talking about the various things.

Adam: Same.

Rowan: There's a lot of others in the various fields.

Adam: Those are great.

Rowan: Everyone's got their specialties. I think we're just spoiled for choice these days.

Adam: Absolutely.

Rowan: That it's so easy to share the various knowledge. I probably get most of it through following people on Twitter, which obviously limits everything to a couple of hundred characters, but it keeps things interesting.

Adam: Do you have any favorite emerging trends in tech?

Rowan: I've been really intrigued in the 3D printing space. That's something that I have not yet made purchases for, but I have friends that have done it and are getting into it. That one definitely has my interest, and I check in every so often to see what's going on there. It's just a bit mind-blowing, just what you can achieve in your house now, with some of these printers that are relatively affordable. I won't go so far to say cheap, but for what they can do it's pretty cool.

Adam: I had a startup six or seven years ago, and we were part of a Disney accelerator. In that accelerator, one of the other companies in the cohort was a 3D printing for prosthetics. They were printing prosthetic arms and hands for kids, that were just way more affordable. It was a really cool company, and I need to check in and see how they're doing. It just blew my mind that that's possible, that those kind of things could be opened up, and just the whole manufacturing side made more efficient, cheaper.

Rowan: Exactly, just that idea of customization, especially in that particular scenario, is just cool.

Adam: Yeah. They were doing Marvel character hands and stuff. They were collaborating with Disney. It was really cool. Do you have a favorite AWS service, aside from IAM?

Rowan: I used to say Lambda a lot, but that's pretty easy. This was always one of my favorite interview questions to ask people during the hiring process, favorite and least favorite AWS service.

Adam: Least favorite; that's good too.

Rowan: Yeah. You get some interesting stories out of that one. If I can't pick IAM, which is definitely my favorite at the moment, I've got a soft spot for S3. It just does some amazing things and it's just there in the background. When S3 has issues, not that it's very often, thankfully, and it's never with the durability of your data, but sometimes the availability, you appreciate just how many things depend upon S3.

Adam: What about any non-tech related hobbies?

Rowan: I'm a bit of a chess tragic. I've got a bookshelf full of chess books here. I'm going through a really rough patch right now, so I don't want to talk about it too much, but I love chess.

Adam: I've asked a lot of guests this. Do you have any hot takes, just inflammatory stuff that's good for social media fodder?

Rowan: I just retweeted something before this. I'm definitely in the camp of don't mock the AWS cloud. In fact, I'd take it further. It's something I learned from programming. Don't mock what you don't own. I see lots of developers out there, and I've got to admit I did this myself, especially in the serverless space, where you go, "Okay, I want to test this. It takes too long to push my code." That's why we're seeing things like SAM accelerate come out. "I'm just going to run everything locally. I'm going to spin up a local stack or DynamoDB local."

Rowan: I've tried it and it just ... you end up with a whole lot of other problems that you didn't have before. For me, the best result, and obviously this is partly just my personal preference, is to really only mock things that are mine. If you find yourself mocking a third party library directly, that's a bid of a code smell. If you want to wrap that up in something and then mock that, great. This is something that's worked really well for me, that I see a lot of people learning the hard way. Don't mock what you don't own.

Adam: That's interesting. I think all of my guests so far share the opinion that we should test in the cloud; we shouldn't try to test stuff locally so much, or just the local stack approach, not running local emulators and stuff. I do have Brian LeRoux coming on. I know he's on the other side. I need him to come on the show and bring balance to this debate, because so far it's been very one-sided. It's do it in the cloud.

Rowan: I'm looking forward to it. I definitely would love to hear his take on that. He's obviously got a lot of knowledge in that space. I tried it myself and I failed, so I stayed away from that point onwards. It's working out pretty well for me.

Adam: I've gotten used to the delay. I now, all these services coming out with ways to eliminate that delay, which is fantastic, but I've gotten so used to it now that it doesn't even ... I don't feel like I'm missing anything from my developer experience, pushing changes up to my cloud, dev stack or whatever, and then testing that way. It's just a bonus that people are removing that and now making it easier with SAM accelerate. Or CDK has the hotswap stuff, which is just pushing the Lambda code. That stuff's great. I want to play a game. Before I do, I have to say before the call we talked, and it ... you're working on something that ... I don't know if I ... Should I not share this, because-

Rowan: No, no. You should share. Maybe then it'll happen for sure.

Adam: Is it okay? Okay. It's something I have to share because it's something I had planned on building, another one of my Trello cards. I think I even have a name and a domain that I had thought of, because that's what I do. I start with logos. You're building a game where you see the AWS service icons and you have to guess multiple choice, I'm guessing. You have to choose which service that icon is. I love it so much. I'd planned on making it at some point. Now I can just help you, if you need help with leader boards or whatever. I've thought about all the features.

Rowan: My original version was multi-player. I toned it back to be just browser based. It's been two or three versions and I've made the mistake of not releasing it. I do need to. I think I've got the [inaudible 00:35:53]. I probably need to just flick it over to public. The interface needs some work, but the logic is there. [inaudible 00:36:01] the pictures in your background there, which I thought were very cool. I can't remember ... Unfortunately since I started it, there's been multiple ... I think there's been two iterations of AWS architecture icons. Unfortunately, the process of labeling each of the icons is still a human led process, maybe [crosstalk 00:36:24] [inaudible 00:36:24] for that can be AWS service [inaudible 00:36:30] AWS icons-

Adam: A Rekognition model that just sees it and spits out the name. Yeah, that would be great. I'd love to help, if I can help on the front end. I can Tailwind with the best of them. I can sling some Tailwind.

Rowan: I think I've included tail wind but hadn't actually gotten around to it, to using it.

Adam: I want it to exist. I'm going to send you DMs every few months and make sure you're pushing forward.

Rowan: It's going to be another thing that I procrastinate with the book on.

Adam: Exactly. The book's more important. Focus on the book. We'll worry about the game later. We'll get it out there. The game we're going to play is a different game. For people who've listened to the show and you've heard us play it, or maybe the podcast. You've heard Ben Bridts was the first who played. AWS or Amazon is what I called it. That's a terrible name. Nobody's given me any better suggestions. I really need to workshop this. I need somebody to throw something at me. What we're going to play today with Rowan is, because he's writing the IAM book, it's going to be IAM actions, and real or fake. I'm going to name some actions that may or may not be real, and Rowan has to guess or know that they're real or fake. You're going to have a minute on the clock. It's how many can you get right. I don't know if I'll play this with anyone else. You may just by default, be number one on this one. Ben Kehoe. I could play this with Ben. He's an IAM guy.

Rowan: Yep. Ben would do well. Ben or if you get Ian on here, that'd be ... Ian McKay.

Adam: Oh yeah. I need to write that down. Ian needs to be on the show. Are you ready, Rowan?

Rowan: I'm ready.

Adam: App sync create data source?

Rowan: Yeah, it's real.

Adam: Elastic load balancing, set load balance for policies for backend server?

Rowan: False.

Adam: Cloud watch create alarm?

Rowan: That's real.

Adam: Cloud trail list private keys?

Rowan: That's not real.

Adam: You're right. I just hit the wrong button. IOT detach thing principle?

Rowan: Yeah, that's true.

Adam: That's a funny one. Athena get named query?

Rowan: I'm going to guess true, real.

Adam: Glue delete user defined function?

Rowan: Fake. Not real.

Adam: Config deliver config snapshot? Oh, the buzzer.

Rowan: That was real.

Adam: I think you got three or four. You were held back by the fact that it took me forever to read some of them and then I had to opine and make comments and snarky remarks.

Rowan: All good.

Adam: We'll get the official count after the show, but thought some of those were interesting in looking through the list.

Rowan: It's one of those things where all of the actions are defined by each of the service teams. Unfortunately, they're not entirely consistent with each other.

Adam: Right.

Rowan: It's just something that we all have to learn the hard way.

Adam: I love it. Rowan, it's been so good. It was such short notice. I appreciate you hopping on. We had just talked about getting you on the show, and then I sprung it on you the morning of, and you were great to come on and fill in a Friday.

Rowan: No worries. Thanks very much. Thanks for doing it, thanks for sharing. I've been really enjoying working my way through the back episodes.

Adam: Oh yeah. I'm putting them out pretty fast. It's hard to keep up. I want to say that for anyone listening to the podcast, I apologize if three times a week is too much. It's too much for me too, so maybe I should slow down. If it's too much for my listeners, that's probably a good sign. On the podcast, I guess a few things. Join the Discord. Rowan, I want to see you on the Discord. That'd be fantastic.

Rowan: I'm coming.

Adam: Okay, great.

Rowan: Cool.

Adam: That's my plug. Get in the Discord. The other thing is rate and review, because this is what people say on podcasts. If you listen to it on a podcast platform, go ahead and give me a review or just rate it. I think it helps with something. Some day I'll learn. I just got plugged into podcast Twitter, so that's a new thing. I just yesterday said, "Where do I find the podcast Twitter?," because I didn't have any idea, and I got a ton of responses. I guess they're very active and I'll learn all kinds of things about making a better podcast. One of my things is, I'm never going to call it a pod again. If I do, I need my listeners to call me out. [inaudible 00:40:55] never listen again. That's the deal, if I call it a pod. I'm done. Thank you so much, Rowan. It's been so good to have you and just to get to know you a little bit better.

Rowan: Cool. Thank you.