AWS Wishlist and Chrismahanukwanzakah Part 1

Transcript
Corey: This episode is sponsored in part by our friends at Linode. You might be familiar with Linode; they’ve been around for almost 20 years. They offer Cloud in a way that makes sense rather than a way that is actively ridiculous by trying to throw everything at a wall and see what sticks. Their pricing winds up being a lot more transparent—not to mention lower—their performance kicks the crap out of most other things in this space, and—my personal favorite—whenever you call them for support, you’ll get a human who’s empowered to fix whatever it is that’s giving you trouble. Visit linode.com/screaminginthecloud to learn more, and get $100 in credit to kick the tires. That’s linode.com/screaminginthecloud.

Pete: Hello and welcome to AWS Morning Brief. I am Pete Cheslock. I'm joined yet again with Jesse DeRose. We are also excited to re-invite recurring guest for number two, Amy Negrette. Say hello, Amy.

Amy: Hello.

Pete: So, we are here. This is Christmas. Or should I say Christmahanukwanza. 

Jesse: So, close. That works. 

Pete: So, close. But it's the Christmahanukwanza episode—Hanu—hanukwanza—

Jesse: Christmashanukwanzika. 

Pete: And if you thought Hanukkah was spelled a bunch of different ways, Christmahanukwanza is spelled a lot of different ways. And we are here to talk about the #amazonwishlist, which is honestly one of my favorite hashtags to follow on Twitter—#awswishlist. It is pretty popular, it's heavily used.

Jesse: It was actually so heavily used that they made a specific @awswishlist account, basically, specifically to follow a lot of these hashtags, and to re-highlight a lot of these hashtags, especially when some of the wishes are actually fulfilled. 

Pete: Yeah, I think it's a great thing, and if I was an Amazon product manager, I would love this too because just talk about making my job a lot easier, I guess. 

Jesse: One thing that I do want to call out, I was looking through a number of the tweets going around for the hashtag#awswishlist, and I noticed that there was some of the responses from AWS folks, which one I'd love to say thank you, AWS for actually taking this seriously and actually responding to folks in conversation on Twitter for these wishlist items. There was one that I found where the person directed the original poster to an AWS support page, which was basically AWS’s, like, ‘Contact Us’ page. And the Contact Us page basically said, “Hey, if you have some questions, here's what you should do. I have some questions that could help improve an AWS product or service, how can I send feedback to AWS?” And all the answers were, “Click the feedback button on the page that you're on, either in the AWS console or the AWS documentation, or contact AWS support directly.” So, close—

Pete: Did you just tell me to go F myself there, Jesse? [laugh].

Jesse: [laugh]. I didn't maybe say it in so many words, but I think I did.

Amy: I absolutely love it when a support page says, “Maybe you should just do it yourself.” And I'm like, “Well if I did, I probably wouldn't have been here in the first place.”

Pete: Exactly. So, what we decided to do, what we thought would be kind of fun, is to troll through the Twitter #awswishlist hashtag and take a look at what people were saying, especially because it's a lot busier around the pre to current re:Invent time. And so independently each of us put together a list of things that—I mean, at least I could speak for myself—I thought were interesting, or things that I thought would be cool to have. And yeah, we're just going to talk about them and see from there. So, we'll include a link to each of these tweets in the [00:04:18 show notes] so you can check them out, and also so you can see the conversation on them. 

What was also cool, I just want to call out is that some of these that we saw on there, at least that I saw have been resolved by re:Invent time. One was AWS CloudShell that was announced recently at re:Invent, someone was saying I want is this AWS CloudShell thing because other vendors have this: Azure has this, Google has this. So, here's a scenario where Amazon was catching up. So, I thought that was pretty cool to see. So, I'm going to kick it off because, whatever, I'm here, and I got my list in front of me. 

So, this is actually related to the CloudShell one, which I thought was interesting. So, there was some conversation online about CloudShell, and this is maybe potentially allowing people to remove the need of having a bastion host, which, how cool is that you don't have to run those anymore? 

Jesse: Oh, yeah. 

Pete: And so there was a question around, “Well, does my identity get a home directory?” Which sounds like the answer was “Yes.” But the question mark there had to do when using AWS SSO because it has to do with the IAM principle, it's what comes back from the sts get-caller-identity. So, if you are using one of the different Federation technologies, your actual identity could be different for each one. And so that's a wishlist item that I could definitely be on board with because if you're dealing with IAM roles or Federation, and your home directory is never the same, that can be kind of annoying. 

Jesse: I cannot tell you how many times I have downloaded a file or put a file somewhere on a bastion host, gone away to a different project, come back to it, or SSH’ed into the same bastion host and wondered why it wasn't there anymore, only to realize that I was on a different bastion host in a different environment, or that the data had been purged every so often for security or cleaning purposes. I would absolutely love clean roles and just really, really well defined boundaries on this. Coming from somebody who uses different AWS accounts on a regular basis for the different clients that we work with, I would just love to see this really kind of clean structure of AWS, IAM usage, and user management and security.

Pete: And, Jesse, we saw similar issues, I believe, when we were playing around with QuickSight, and Federation, and IAM so—

Jesse: Oh, yes.

Pete: Hopefully that gets a little bit fixed up. But anyway, I thought that was a pretty interesting one. Amy, what did you find in your discovery of the Amazon wishlist hashtag?

Amy: I did find one for X-Ray support in API Gateway HTTP API. Again, one of the worst, longest names of any service, and EventBridge, which surprisingly, one that this hasn't happened yet, but two, [00:07:12 unintelligible] for me is kind of a double-edged sword where it's one of those services that everyone needs, but also the UI for it—like all Amazon monitoring—leaves more to be desired if you are a human being with eyes. But also it’s a weirdly priced service that seems to be more expensive as a native service than the competitors that are third party services.

Jesse: One of the things that I'm always fascinated by with AWS is the model of buying—or I should say acquiring new companies to compete or building the same thing internally to compete. And this is going to be an interesting one because I feel like if there are other competitors out there that are doing the same thing for a cheaper price, it's going to be difficult for AWS to continue to sell this X-Ray service at its current structure. But I'll also say that I think that it's so built into a lot of existing AWS native solutions that I feel like that's where they have the advantage. But again, every step of the way, AWS just has this opportunity to make things better, especially when you want to talk about the pillars of excellence. I think that this is a great one to focus on to say, these services do not work as well, the user experience is not as clean as it could be.

Pete: Well, there's always room for improvement. So, what did you find, Jesse? What was one of your favorite wishlist items you found?

Jesse: I'm gonna go big here. I think my number one that I had—and to clarify, these are not in a particular order, but I found this one first, so I was thinking about this one first as I started thinking about wishlist items. My biggest one is I would love to see a simplified reservation options across AWS services. So, for example, like, right now, AWS provides savings plans, which support EC2, Fargate Lambda, and Fargate for EKS. And I'll give them that, like, some of those services didn't have other reservation options in the past before this. 

But then you've also got reserved instances for EC2, RDS ElasticCache, ElasticSearch, Redshift. Then DynamoDB, reservations are reserved capacity. Elemental MediaConvert has reserved queues. And there's all sorts of different places where all of these reservations can be managed. I would love to see all of these manageable in a single place, ideally the billing console, and then maybe also built out across—or accessible across the different services where these resources and reservations live. 

But just one easy way that all of these things are consolidated in the same umbrella term so that ultimately when we're talking about reservations, we can talk about it broadly across all AWS resources, or all AWS services, not just the ones that are covered by a certain type of reservation.

Corey: This episode is sponsored in part by ChaosSearch. Now their name isn’t in all caps, so they’re definitely worth talking to. What is ChaosSearch? A scalable log analysis service that lets you add new workloads in minutes, not days or weeks. Click. Boom. Done. ChaosSearch is for you if you’re trying to get a handle on processing multiple terabytes, or more, of log and event data per day, at a disruptive price. One more thing, for those of you that have been down this path of disappointment before, ChaosSearch is a fully managed solution that isn’t playing marketing games when they say “fully managed.” The data lives within your S3 buckets, and that’s really all you have to care about. No managing of servers, but also no data movement. Check them out at chaossearch.io and tell them Corey sent you. Watch for the wince when you say my name. That’s chaossearch.io.

Pete: Yeah, I mean, reservations exist. I think your point, Elemental MediaConvert, probably most people have never heard of that service. And now you're like, “Wait, there's a reservation option for that?” So, hopefully, what I would love to see as part of that, my wishlist item would be, bring it into Amazon Organizations at that level, and give me that really high-level view over everything. That would be [kiss], you know, a Chef kiss, right?

Jesse: [laugh]. I love that idea. 

Pete: So, you came in with this big huge—you're just scaring all these Amazon engineers, with oh, my God, how terrible as that is, I'm going to come in with one that I saw, which I feel this one really strong, I think it's still probably a massive engineering undertaking, which is stripping the trailing whitespace from any text that you copy and paste into the different console search [laugh] boxes and stuff. Amazon has done this miraculous job of putting a little ‘copy to clipboard’ button next to some things, but it's not in all the things so sometimes you copy, and then it gets two tabs’ worth of information and maybe a special character. So, if you can't fix that part of it, maybe just fix—just strip it when I pasted it. I don't know, just ignore it—in some place, just ignore that. So, again, that's probably a bigger engineering effort than yours, Jesse. [laugh].

Jesse: Yeah, I cannot tell you how excited I was to see the copy to clipboard button in a bunch of different places on the console, and how much headache that has relieved me from, so I would love to see more of that with making it easier to copy and paste, ARNs and Instance IDs and other things across the console. 

Pete: Amy, I am sure you've been burned just like the rest of us with that one but other than stripping the whitespace from the copying and pasting, what do you think would be a great Amazon wishlist item?

Amy: Speaking of copying and pasting, I saw one—this is less about actually having to do it, and more of knowing why AWS won't let you do it. When you try to delete anything on AWS, they give you a text box with different words in it. Not CAPTCHA level different words, but it's always some format of ‘delete me,’ ‘remove me,’ ‘delete this resource,’ sometimes it's the actual resource ID. And one of the requests was to standardize them because if you're trying to maintain this a lot, and you are trying to keep your resources down, if you don't have an automated way of doing it, you are slowly losing your willpower delete after delete, trying to remember what all of these words are. And then you end up glossing over it anyway, instead of what it was obviously trying to do, which was give you a little speed bump, so you don't delete stuff on accident. 

There has to be a better way of doing that. I don't know what it is yet, but it is infuriating to go to one resource deleted and then go to its neighbor resource, or something it's attached to and try to delete that, only to have the phrase be different enough to give you a headache.

Pete: It's like an infomercial: “There has to be a better way.”

Jesse: [laugh]. I will add to that, that when I have to manually delete resources from the AWS console, it drives me crazy when it's maybe like an EC2 instance that has multiple EBS volumes attached, and it'll say, “Hey, if you delete this instance, we're automatically going to delete all of these EBS volumes as well.” And then it lists out the Volume IDs, but I'm not gonna be able to remember what these things are based on Volume IDs like I need the volume name, or maybe some tags or some kind of descriptive information that will help me better confirm like, “Oh, yeah, I don't need those volumes. That's fine.” Rather than just a bunch of Volume IDs that at that point, YOLO. Let's delete them. Who cares? I mean, it was easier when the Volume IDs and the Instance IDs were—what—eight characters before they got expanded.

Amy: 5000 characters.

Pete: Yeah. You know, I could remember those, like, “Oh yeah, Instance ID, like, I-A7D? I know that one. That's my friend. That's my NFS server. I need that server.” Right? I could always remember those. 

Jesse: I'm going to go for another really big one here. I'm going to call out—okay, actually you know what? That's a lie. It's not a big one; it’s probably a sprawling one, but I wouldn't say it's super-technically difficult. I would love a very clear, easy to understand document describing which AWS usage is taggable, and which AWS usage is not taggable. 

When I'm talking about taggable, I'm talking specifically about user-defined cost allocation tags. This is something that I will say from experience has driven me crazy because I have built a number of lists based on what is and is not taggable and created Cost Explorer reports off of this information, but I would just love one single definitive AWS document to rule them all—I mean, who wouldn’t—talking about how you can easily manage your cost attribution and your unit economics based on which AWS resources and which usage types are taggable and which ones aren’t.

Pete: Yeah, I mean, that's a really great point because, as we know—because we deal with this every day—to capture resources that are not taggable, the only way to do that is to have segmented accounts, which could be a massive engineering effort; it could maybe overcomplicate your network architecture. And so, I dream for that world; that's the future I want. 

Well, that was a pretty amazing part one of the #awswishlist items because there are Twelve Days of Christmas, there's going to be at least two days of #awswishlist items. So, stay tuned for part two next week, where we will invite Amy back again, to go through the rest of our wishlist items, and because it will be the new year—goodbye 2020 and welcome 2021—we'll maybe share some of our hope for the future. So, we'll hope to see you next time for that.

If you enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review and give it a five-star rating on your podcast platform of choice and tell us what is your #awswishlist. Thank you.

Announcer: This has been a HumblePod production. Stay humble.