Last Week In AWS Podcast

Links

• Pete and Jesse Talk Account Managers

Transcript
Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.

Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.

Tim: And I’m Tim Banks.

Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today, we’re going to be talking about, really, a couple things; building your relationship with AWS, really. This stems from one of the questions that we got from a listener from a previous event. The question is, “How do the different companies that we’ve worked with work with AWS? Is the primary point of contact for AWS at a company usually the CTO, the VP of engineering, an architect, an ops person, a program manager, or somebody from finance, a [unintelligible 00:01:00] trainer? Who ultimately owns that relationship with AWS?”

And so we’re going to talk about that today. I think there’s a lot of really great content in this space. Pete and I, back in the day, recorded an episode talking about building your relationship with your account manager, and with your TAM, and with AWS in general. I’ll link that in the show notes. That’s a great precursor to this conversation. But I think there’s a lot of great opportunities to build your relationship and build rapport with AWS, as you work with AWS and as you put more things on the platform.

Amy: I think one of the things we always say right off the bat is that you should introduce yourself and make a good relationship with your account manager and your technical account manager, just because they’re the ones who, if you need help, they’re going to be the ones to help you.

Jesse: Yeah, I think one of the things that we should also take a step back and add is that if you are listening to this and you’re saying to yourself, “I don’t have an account manager,” that’s actually wrong; you do have an account manager. Anybody who’s running workloads on AWS has an account manager. Your account manager might not have reached out to you yet because usually speaking, account managers don’t reach out unless they see that you’re spending a certain amount of money. They usually don’t start a conversation with you unless you specifically are spending a certain amount of money, have reached a certain threshold, and then they want to start talking to you about opportunities to continue using AWS, opportunities to save money, invest in AWS. But you definitely have an account manager and you should definitely start building that rapport with them as soon as possible.

Amy: First question. How do you actually engage your account manager?

Tim: So, there’s a couple ways to do it. If you have reached a certain spend threshold where your account manager will reach out to you, it’s real simple: you just reply back to them. And it kind of depends. The question most people are going to have is, “Well, why do I need to reach out to my account manager? If I just have, like, a demo account, if I’m just using free tier stuff.”

You probably don’t ever need to reach out to your account manager, so what are the things, typical things that people need to reach out to their account manager for? Well, typically because they want to grow and want to see what kind of discounts are offered for growth, and I want to see what I can do. Now, you can open a support ticket, you can open a billing ticket, but what will end up happening is once you reach a spend threshold, your account manager will reach out to you because they want to talk to you about what programs they have, they want to see how they can help you grow your account, they want to see what things they can do for you because for them, that means you’re going to spend more money. Most account managers within a little bit of time of you opening your account and reaching a lower spend threshold, they’re going to send you an email and say, “Hey, this is my name, this is how you reach me,” et cetera, et cetera. And they’ll send you some emails with links to webinars or other events and things like that, and you can typically reply back to those and you’ll be able to get your account manager sometimes as well. But like I said, the easiest way to get a hold of your account manager or find out who it is, is to start increasing your spend on AWS.

Jesse: So, then if you’re a small company, maybe a startup or maybe just a student’s using AWS for the first time, likely that point of contact within a company is going to be you. From a startup perspective, maybe you are the lead engineer, maybe you are the VP of engineering, maybe you are the sole engineer in the company. We have seen most organizations that we talk to have a relationship with AWS, or build that relationship or own that relationship with AWS at a engineering management or senior leadership level. Engineering management seems to be the sweet spot because usually, senior leadership has a larger view of things on their plate than just AWS so they’re focused on larger business moves for the company, but the engineering manager normally has enough context and knowledge of all of the day-to-day specifics of how engineering teams are using AWS to really be involved in that conversation with your account manager, with your technical account manager, or with your solutions architect, or whatever set of folks you have from AWS’s side for an account team. And I think that’s another thing that we should point out as well, which is, you will always have an account manager; you won’t always have a technical account manager.

The technical account manager generally comes in once you have signed an enterprise discount program agreement. So, generally speaking, that is one of the perks that comes with an EDP, but obviously, there are other components to the EDP to be mindful of as well.

Tim: So, let me clarify that. You get a technical account manager when you sign up for enterprise support. You don’t have to have an EDPs to have enterprise support, but when you sign up for enterprise support, you automatically get a technical account manager.

Jesse: And, Tim, if you could share with everybody, what kind of things can you expect from a technical account manager?

Tim: So, a technical account manager, I mean, they will do—like, all TAMs everywhere pretty much can liaise with support to escalate tickets or investigate them and see what’s going on with them, try and, kind of, white-glove them into where they need to be. AWS TAM’s, they also have the same—or a lot of ...

Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/the-lessons-aws-infinidash 

Never miss an episode

• Join the Last Week in AWS newsletter
• Subscribe wherever you get your podcasts

Help the show

• Leave a review
• Share your feedback
• Subscribe wherever you get your podcasts

What's Corey up to?

• Follow Corey on Twitter (@quinnypig)
• See our recent work at the Duckbill Group
• Apply to work with Corey and the Duckbill Group to help lower your AWS bill

Links:

• https://www.duckbillgroup.com/blog/aws-cost-allocation-guide-tagging-best-practices/
• https://www.duckbillgroup.com/blog/aws-cost-allocation-guide-identifying-your-costs/

Transcript

Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com. 

Jesse: Hello, and welcome to the AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.

Tim: And I’m Tim Banks.

Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today, we’re actually going to talk about a very specific listener question that we didn’t get to last week, but really, we had so many thoughts on this topic that we wanted to break it out into its own episode. So, today we’re going to be talking about tagging, and the importance of tagging, and how tagging can be used. And when I say tagging, specifically we’re talking about user-defined cost allocation tags. The original question that I’ll read off was from [Aaron 00:00:58].

Aaron asks, “Is tagging over-recommended as a cost reporting mechanism? I recently took on managing my company’s AWS bill and when talking to AWS and reading third-party blog posts about cost management, a solid tagging strategy is often extolled this step zero for understanding AWS costs. Based on what I know about AWS so far, this approach seems like it may work for some aspects of cost management, but does not seem to be a sound strategy for more formal cost reporting, like budgeting or calculating total spend for a given product or cost center. To me, these activities require complete or near-complete accuracy the tags just don’t seem to be able to provide since there are some costs like data transfer that aren’t tagged, and the fact that the tags are not retroactive—” that’s a big one that I can say is super frustrating for me. “Is there something I’m missing here? Is there in fact, a way to use these tags to ensure that 100% of an AWS account’s costs are in fact attributed back to a specific cost center accurately? It seems drastically simpler to embrace a multi-account strategy where each account is simply billed to whatever cost center makes sense to the organization.” So, Amy and Tim, again, the main question here is, is tagging over-recommended as a cost reporting mechanism?

Tim: The simple answer is no, it is not over-recommended. And the question makes a lot of good points around some of the heartaches and some the problems that come with tagging, specifically about tags not being retroactive, but, if you’re going to make changes to reflect changes in the past, I mean, you know, I don’t really have a good answer for that, if we’re being honest. But if we’re talking about going forward, tracking costs from this point forward, tagging is going to be a much more concise solution than using multi-account strategy. That said, there are a lot of reasons you should use multi-account strategy and tagging together. Multi-account strategy and tagging strategies should definitely be an ‘and’ situation, not an ‘or’ situation. That’s like pizza or steak. No. It’s both pizza and steak.

And I feel like because there are a number of non-cost reasons to use multiple accounts, especially in AWS, the biggest concern of which are service limits, right? Service limits, as you know, are done by account by region, so, if I have a service limit of S3 buckets that I can create—and I think that the hard limit is, like, one thousand—once I need that one thousandth and one S3 bucket, I have to create another account. That account can still be production, it can still be for all the same things that I’ve used for anything else, but I had to add another account so I can spin up S3 buckets. So, how do I track those, what those buckets are for, what those costs are going to be? I’m going to track those with tags.

And I’m going to track those tags from the payer account, or from up in the organization. So, as you set up multiple accounts, you can have—even if they’re all production, they still need to be tagged. Even if they’re all dev, they still need to be tagged. If you’re using the account vending machine style stuff from Control Tower where you spin up a sandbox account, you run some stuff, and then you throw it away, tagging is going to be the best way to track those costs, not just the fact that this account is named a certain thing. Names are arbitrary; they don’t really reflect necessarily what they’re going to be for, accounts can come and go.

So, I don’t necessarily like the use of name. Plus, sometimes it’s hard to do that if you’re doing, like, [unintelligible 00:04:21] various countries and things like that, various languages. Different things can impart different meanings. Tags also still probably use language 
problems, but they are arbitrary values. You know you’re going to try and lump these all together; that’s all that matters.

So, I definitely think that, if we’re using tagging, tagging is going to let you be more concise with your costs, it’s going to let you apply costs across different accounts more readily, it’s going to let you apply costs across different cloud providers, especially if you use one of the CMP tools like CloudHealth, or Cloudcheckr, or something like that and you run production workloads from a single cost center across multiple clouds, you’re going to want to tag those in those tools, so, that way, you can keep a consistent track and more concise tracking of costs, versus just using account names. Account names after a while is going to just become unmanageable when it comes to tracking costs.

Amy: I totally agree. And one of the big things that I harp on, especially on this podcast, is that if you’re worried that it’s not going to be as explicit as other billing methods, you will still at least have that data. You will still know per resource—if it’s properly tagged—who it’s supposed to be charged to and who owns it. You would make that decision on an architectural level, you should also make it for your bill, just to make sure that if you ever need that information in the future, you can go get it. You’re not going to get it—since they don’t happen retroactively, then you may as well do it as early as possible.

Jesse: Yeah. It’s super frustrating that a lot of this information is not available retroactively. And while I understand the technical limitations to that, I can’t harp enough why starting to tag resources early is super, super critical to understanding that spend, and using that tagging setup, that tagging policy, to better understand your spend in a number of different ways. But ...

Want to give your ears a break and read this as an article? You’re looking for this link[https://www.lastweekinaws.com/blog/I-Scored-81%-on-my-AWS-Certification-Exam,-Locking-in-my-re:Invent-Lounge-Pass

Never miss an episode

• Join the Last Week in AWS newsletter
• Subscribe wherever you get your podcasts

Help the show

• Leave a review
• Share your feedback
• Subscribe wherever you get your podcasts

What's Corey up to?

• Follow Corey on Twitter (@quinnypig)
• See our recent work at the Duckbill Group
• Apply to work with Corey and the Duckbill Group to help lower your AWS bill

Transcript

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.

Tim: I’m Tim Banks.

Jesse: This is the podcast within a podcast where we talk about all the ways that we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today on the show, we are going to be talking about AWS re:Invent. Now, I know that most of you know what re:Invent is, but I just would love to set the playing field level for everybody really quick. Amy, Tim, what is AWS re:Invent.

Tim: AWS re:Invent is AWS’s week-long corporate conference. It’s not really a user conference; it’s certainly not, like, a community conference, but it’s a week-long sales pitch in the desert. It’s like the worst version of a corporate Burning Man you could ever imagine because they even have a concert.

Jesse: It is in Las Vegas. Now, I personally have mixed feelings about going to Las Vegas in general, but this adds so much to the conference in general because it’s not just in a single conference venue that’s centrally located near the hotels. Is it is across the strip—

Amy: It’s the entire strip.

Jesse: It’s the entire strip. So—

Amy: They block every hotel and they buy every piece of ad space.

Jesse: Yes. There is no escaping AWS re:Invent for the entire week that you’re there. And sometimes that’s a good thing because you do want to be involved in what’s going on, but other times, it is a lot.

Tim: So, I’m trying to figure out which LP that ‘buy the entire Las Vegas trip’ covers because it’s certainly not be frugal.

Amy: No. [laugh].

Jesse: No, not at all. But we do have new information. We decided to do this episode specifically because new information was just released about re:Invent for this year. Amy, what is that information? What do we know?

Amy: They’ve decided, in having to go virtual last year, due to some kind of horrible global crisis, to return in person to the world’s most densely packed tourist spot, Las Vegas, and host this huge event from November 29th to December 3rd—that’s right after Thanksgiving—and just, what do they say? Return to normal. Return to normal.

Tim: That way everybody can get exposed to COVID before they go home for the holidays.

Jesse: [laugh].well, you at least get one holiday in, if you celebrate or recognize Thanksgiving, and then you get to bring everything back after that.

Amy: Yeah, people bring enough things back from Vegas. I’m not sure we’d have to find more reasons. [laugh].

Tim: [laugh].

Jesse: I know that there’s that great marketing tactic of, “What happens in Vegas stays in Vegas,” but—

Tim: That’s not what they say at the clinic.

Jesse: Nope. Mm-mm. Now, I will say, I know that almost every conference event was completely virtual last year due to the pandemic, and this year, a lot of conferences are still trying to straddle that line between what’s acceptable, can we do maybe smaller events in person, some kind of a hybrid online/in-person thing. I have mixed feelings on this. I appreciate that I can still attend AWS re:Invent from home this year digitally, I can still watch a lot of the main keynote events and a lot of the other information that is being shared, but I don’t know, it’s always hard because if you do a hybrid event, you’re automatically going to miss out on any of that in-person socializing and networking.

Tim: Well. So, I think it’s interesting. AWS re:Invent suffers from the same issue that pretty much all other conferences suffer from is that there’s not really value-add in the talks, at least for attending.

Jesse: Yeah.

Amy: If you’re going to be able to see those talks afterwards if the announcements are going to be publicized afterwards which, that is true in both cases, then what’s the point of spending the money, and the time, and the possible exposure to go watch them in person? So, then the other thing is, “Well, we want to go for some of the training seminars,” or some of these other things. Well, those are also offered online, often. Or, like, copies of them online. These are the same kinds of tutorials like that that you can have your TAM or SA run if you’re an AWS customer currently; that’s what they’re doing there.

The other thing is, too, those in-person sessions get filled up so quickly that there’s no guarantee [unintelligible 00:05:08] anyways. And that’s one of the complaints they’ve had about re:Invent in the past is that you can’t get into any of the sessions. And so, you couple all that along with most of the reason going being—if it’s not the talks and is not the sessions, it’s the hallway track. And then you got to kind of wonder, is the hallway track going to be valuable this year because if it’s hybrid, what percent of the people that you would normally 
talk to you are going to be there and what percentage aren’t? And so there’s a lot of calculus that’s got to go into it this year.

Jesse: I’ve always struggled with any vendor-sponsored event, all the talks feel either like a sales pitch, or they feel like a use case that just doesn’t fit for me. And that may just be where I’m at in my professional journey; there’s definitely reasons to go if you want to see some of these talks or see some of this information live, or be the first person to talk about it. Or even the people who are going to be the news sources for everybody else who want to be the first person to talk about, “Oh, we attended, and we saw these things and were live-tweeting the entire conference.” If that’s your shtick, I fully support that, but I always struggle going to any kind of vendor conference because I just feel like the value that I get from the talks, from training if I go to training, just doesn’t feel like enough for me, personally.

Amy: So, I’ve done some of the AWS-led training when Summit was in Chicago, a couple years ago, and I’ll be honest, you lose a lot in these large AWS-led trainings because these classes, it’s not going to be like the ones that you would sign up for even being hosted either by your company or by your local user group chapter where you will have at max 100 people. You have well over that. You have an entire conference room full of people, and they’re asking questions that are across the level of expertise for that topic. I went for one of the certification training seminars and straight-up 15 minutes was spent talking about what a region is. And given that’s page one of any training material, that was a waste of $300....

Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/the-cloud-genie 

Never miss an episode

• Join the Last Week in AWS newsletter
• Subscribe wherever you get your podcasts

Help the show

• Leave a review
• Share your feedback
• Subscribe wherever you get your podcasts

What's Corey up to?

• Follow Corey on Twitter (@quinnypig)
• See our recent work at the Duckbill Group
• Apply to work with Corey and the Duckbill Group to help lower your AWS bill

Transcript

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.

Tim: And I’m Tim Banks.

Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today is a very special episode for two reasons. First, we’re going to be talking about all the things that you want to talk about. That’s right, it’s time for another Q&A session. Get hyped.

Amy: And second as is Duckbill’s customary hazing ritual, we’re putting a new Duckbill Group Cloud Economist Tim Banks through the wringer to answer some of your pressing questions about cloud costs and AWS. And he has pretty much the best hobbies.

Tim: [laugh].

Jesse: Absolutely.

Tim: You know, I choke people for fun.

Jesse: [laugh]. I don’t even know where to begin with that. I—you know—

Amy: It’s the best LinkedIn bio, that’s [laugh] where you begin with that.

Tim: Yeah, I will change it right after this, I promise. But no, I think it’s funny, we were talking about Jiu-Jitsu as a hobby, but my other hobby is I like to cook a lot, and I’m an avid, avid chili purist. And we were in a meeting earlier and Amy mentioned something about a bowl of sweet chili. And, dear listeners, let me tell you, I was aghast.

Amy: It’s more of a sweet stewed meat than it is, like, some kind of, like, meat candy. It is not a meat candy. Filipinos make very sweet stews because we cannot handle chili, and honestly, we shouldn’t be able to handle anything that’s caramelized or has sugar in it, but we try to anyway. [laugh].

Tim: But this sounds interesting, but I don’t know that I would categorize it as chili, especially if it has beans in it.

Jesse: It has beans. We put beans in everything.

Tim: Oh, then it can’t be chili.

Jesse: Are you a purist that your chili cannot have beans in it?

Tim: Well, no. Chili doesn’t have beans in it.

Amy: Filipino food has beans in it. Our desserts have beans in it. [laugh].

Jesse: We are going to pivot, we’re going to hard pivot this episode to just talk about the basis of what a chili recipe consists of. Sorry, listeners, no cost discussions today.

Tim: Well, I mean, it’s a short list: a chili contains meat and it contains heat.

Jesse: [laugh].

Tim: That’s it. No tomatoes, no beans, no corn, or spaghetti, or whatever people put in it.

Amy: Okay, obviously the solution is that we do some kind of cook-off where Tim and Pete cook for everybody, and we pull in Pete as a special quote-unquote, outside consultant, and I just eat a lot of food, and I’m cool with that. [laugh].

Jesse: I agree to this.

Tim: Pete is afraid of me, so I’m pretty sure he’s going to pick my chili.

Jesse: [laugh].

Amy: I could see him doing that. But also, I just like eating food.

Tim: No, no, it’s great. We should definitely do a chili cook-off. But yeah, I am willing to entertain any questions about, you know, chili, and I’m willing to defend my stance with facts and the truth. So…

Amy: If you have some meat—or [sheet 00:03:19]—related questions, please get into our DMs on Twitter.

Jesse: [laugh]. All right. Well, thank you to everyone who submitted their listener questions. We’ve picked a few that we would like to talk about here today. I will kick us off with the first question.

This first question says, “Long-time listener first-time caller. As a solo developer, I’m really interested in using some of AWS’s services. Recently, I came across AWS’s Copilot, and it looks like a potentially great solution for deployment of a basic architecture for a SaaS-type product that I’m developing. I’m concerned that messing around with Copilot might lead to an accidental large bill that I can’t afford as a solo dev. So, I was wondering, do you have a particular [bizing 00:04:04] availability approach when dealing with a new AWS service, ideally, specific steps or places to start with tracking billing? And then specifically for Copilot, how could I set it up so it can trip off billing alarms if my setup goes over a certain threshold? Is there a way to keep track of cost from the beginning?”

Tim: AWS has some basic billing alerts in there. They are always going to be kind of reactive.

Jesse: Yes.

Amy: They can detect some trends, but as a solo developer, what you’re going to get is notification that the previous day’s spending was pretty high. And then you’ll be able to trend it out over that way. As far as asking if there’s a proactive way to predict what the cost of your particular architecture is going to be, the easy answer is going to be no. Not one that’s not going to be cost-prohibitive to purchase a sole developer.

Jesse: Yeah, I definitely recommend setting up those reactive billing alerts. They’re not going to solve all of your use cases here, but they’re definitely better than nothing. And the one that I definitely am thinking of that I would recommend turning on is the Cost Explorer Cost Anomaly Detector because that actually looks at your spend based on a specific service, a specific AWS cost category, a specific user-defined cost allocation tag. And it’ll tell you if there is a spike in spend. Now, if your spend is just continuing to grow steadily, Cost Anomaly Detector isn’t going to give you all the information you want.

It’s only going to look for those anomalous spikes where all of a sudden, you turned something on that you meant to turn off, and left it on. But it’s still something that’s going to start giving you some feedback and information over time that may help you keep an eye on your billing usage and your spend.

Amy: Another thing we highly recommend is to have a thorough tagging strategy, especially if you’re using a service to deploy resources. Because you want to make sure that all of your resources, you know what they do and you know who they get charged to. And Copilot does allow you to do resource tagging within it, and then from there should be able to convert them to cost allocation tags so you can see them in your console.

Jesse: Awesome. Well, our next question is from Rob. Rob asks, “How do I stay HIPAA compliant, but keep my savings down? Do I re...