Tel: +44 (0)1786 430076 email: info@objectiveassociates.co.uk

The Objective Podcast & Blog

 

Discussing Amazon's AWS, including costs and "how to" best advice. We also talk about related technologies. The Objective Podcast is available on iTunes.

How to manage Amazon’s AWS costs (Podcast)

If you are looking at the costs in moving to AWS or are concerned about AWS costs running away with you, then this is where to start.



 

How to manage Amazon's AWS Costs (Comment)

It's difficult to explain just how impressive the AWS environment is when it comes to managing your costs. In this short, 15 minute, podcast we give you a few highlights and a few pointers as to where you should begin looking at the AWS cost benefits and where you can trim back expense.

Should you opt for RDS or EC2 instances? Well, that depends:

RDS is a fully resilient database set up with mirroring and the like all looked after for you; all you need to do is administer the database.

Whereas, EC2 simply provides you with various server instance types - you choose the server instance based on how much power and storage you need for the database you're setting up.

If you're responsible for the finance function then you'll want to be sure that AWS Costs don't run away with your wallet. That's where AWS really scores. The Cost Explorer allows you to see what you are spending, it'll even suggest when you should be looking at a different model to save money. For instance you could change from an "on demand" instance, to a "reserved" instance - and save a bit of cash by committing to a contract term.

Something else that the Finance Director will like in addition to Cost Explorer is Lambda. This is a way to run code in short bursts when you need to handle peak demands. That saves you having to commit to servers sitting quiet, waiting for such an eventuality. Instead Lambda runs code remotely for you when you need it to - and you only get charged for those bursts of activity.

Have a listen to the podcast, it's a good way to begin thinking through how you could be managing your server and your AWS costs. And of course, now that we've met... we're here to help: 01786 430076.

 

How to manage Amazon's AWS Costs (Transcript)

Alex: Hello and welcome to the Objective Associates podcast. Today we'll be talking about AWS costs, that's Amazon Web Services, a complicated area and one which I'm delighted to say we have someone who knows a lot about it.

Fraser Ingram joins me. Fraser is the CTO at Objective Associates, and of course I should introduce myself. My name is Alex Ogilvie and I'm Managing Director at Objective Associates.

So Fraser, I guess the first thing to talk about is really the big choices when you've moved to AWS, for whatever reasons, lets maybe cover that in a different episode as to why you would move to AWS; but I guess the first thing you look at is probably well, I guess the database types that you could potentially use, how does that work, how do you make that choice?

Fraser: Yeah sure, you've got a few options when you're looking at the database. You can either do it the way you'd probably normally have it in a data center, you've got virtual machines hosting databases or physical machines hosting database servers, be that Microsoft SQL Server MySql or many other database technologies. So you can still do that on AWS and how you do that is by setting up EC2 instances. You set them up choose the instance size that you'd want so effectively choosing the amount of memory you've got, the number of CPU cores that you've got available to you and and or the other choice; so that's EC2 you would choose those instances; or the other way to do it is look at using the RDS service from Amazon. The RDS service is effectively a cloud-based database that you've, you generate the database, you manage the database, but you don't manage the servers that go along with that. There's advantages to using RDS and obviously what's happening there is Amazon are managing the database servers if you like. They're dealing with the mirroring, they're dealing with resilience aspects of that. If you are doing that in EC2 you're having to put that together yourself so maybe setting up mirroring, transactional log shipping and all that kind of stuff that you'd normally do when you are setting up database servers on a traditional data center.

Alex: So when it comes to costs on that then strikes me if Amazon in the RDS database environment are doing a lot of that mirroring stuff on your behalf then that must be a more expensive option for you.

Fraser: Yeah I mean you're paying for Amazon to to set up the resilience for you so you are paying Amazon to do that for you, as opposed to an EC2 set up where you're doing that yourself. So in an EC2 scenario you may need, well if it's Microsoft technology that you're using you would need 3 databases in that case you'd need your primary, your mirror and a witness server. Whereas in RDS that's all done for you all you've got is a database to connect to and use the database.

Alex: And if you're not using mirroring or if you choose not to have mirroring for whatever reason. It sounds then that EC2 would be a very sensible way to go and presumably it's still pretty resilient it's not going to fall over on your anything.

Fraser: Yeah, yeah you can set up and use an EC2 database so and, that would,that would, be the same as setting up a single database server as you would do in a datacenter, or if you've got a database server in your office.

Alex: Alright so so there's a two choices you do RDS or you do EC2 which is... elastic computing?

Fraser: Yeah,Elastic Cloud Computing.

Alex: Elastic Cloud Computing thanks Fraser. Okay so there's the two choices - regardless of that choice you're gonna have to store the data someplace so so what's the options there?

Fraser: Yeah, I mean when you set up an EC2 instance you get a little bit of storage for, effectively for, your operating system. For some instances you also get effectively some temporary storage that's local to that that machine.

But that is temporary storage and it will get deleted when the machine goes down and back up. So really what you need to do is set up some EBS storage and there's a number of choices in the EBS storage that you've got. You can use traditional hard disk drives or you can use SSDs and those number options within both of those as to how fast you want them to go.

Alex: Okay,so the costs associated without storage then I guess whether it's SSDs or any other kind of conventional storage. How are they charging for that, how does that work?

Fraser: You're really charged... so if you if you're looking at traditional hard disks... you're really charged per Gig. So effectively your charged, you know, if you want a hundred gigs worth of storage you're gonna get charged for a hundred Gigs worth of storage. For SSDs you've got another option though, you get charged per Gig, but you can also look at the IOPS that you need available so if you need really fast storage then you can bump the IOPS up and get charged more for that hundred Gig.

Alex: Alright so - IOPs; explain to me, if not the listener,what is an IOP then?

Fraser: IOPs really the... if you think of it as the rate in which you want to read and write data from that drive. You know, so the the more IOPS you've got, the faster you can read write data from the drive.

Alex: Alright so this is really, it's a notion of processing capability in the end isn't it? Because if you can't get the stuff in and out the system, then you're not gonna be able to process, so your system is going to slow down I guess.

Fraser: Yeah, yeah... so I mean if you're doing, if you've got you know, maybe a database for heavy read and write operations then... then looking at the, you know, being able speed up the IOPs on that would be fantastic.

Alex: So - there's a couple of price models that are associated when you're actually choosing your AWS setup. Do you want to run through those for us and explain the kind of pros and cons of each.

Fraser: Yeah, so on your EC2 instances. So effectively your normal server set up as you would see it. And you would normally have had it in your Data Center. A virtual server effectively, you've a couple of ways to pay for it, or a few ways to pay for that. You can pay for it on demand. So you can pay for it... if you want it up 24/7, then you pay for 24 hours worth of access of that every day of the week.

Okay so that's your normal; Okay I've got this server up and running and I'm always having it up and running. So you pay for it, you would you set up an on-demand instance in that case. To bring the cost down on that, if you can commit to running that for a period of a year or three years, there's ways to bring down the cost on that up to about twenty percent. So you buy a reserved instance in that case as opposed to an on demand instance.

Alex: Alright so you can imagine the situation where, if you're moving to the cloud, or you've got a new service or a new system you're installing, then you could potentially say: right I'm going to set up an on-demand type model and then figure out over the space of a couple of months or a couple of weeks even, I guess, how how much that's going to cost you and whether it's worthwhile going to a reserve model where you you may be committing on the longer term but you're getting a discount on the overall price.

Fraser: Yeah, absolutely,absolutely.

Alex: And is it easy to switch between those two business models?

Fraser: Yeah, I mean if you've got an on-demand instance running and you've got it up and running,then all you do is buy the reserved instance, you don't have to shut it down,your existing instance back down,you don't have to do anything like that. You just say: Okay I'm now buying a reserved instance of that same size and your costs for your on demand instance will effectively fall back down to the reserved price.

Alex: So that really helps to take the risk out of building a system on AWS. Because you can effectively suck it and see, before you commit to any long-term costs.

Fraser: Yeah, absolutely if you think that - you know - you need a pretty small server to start off with or a pretty chunky server to start off with, then then you spin that up, get it running, and see what it does. You know... you know, you see if you're using the full CPU power. See if, you see, how it's going, or do you need a bigger instance than that or do you need a smaller instance than that. And you tune it at that point and then once you've got it all settled then you can look at buying the reserved instance. And settling the costs on that. There's actually options as well within the reserved instance to convert it to different instance types as well.

Alex: Alright, so you can increase it's processing capability or the storage around it.

Fraser: Yeah, yeah, effectively if you've got a reserved instance of say a medium instance size then you can, you can look at changing that to maybe a 2XL. And there's ways to do that within AWS: there are certain parameters around about what you can change to what,but it can be done.

Alex: And you can go up and down? You're not locked in if you go up they way?

Fraser: You can go up, you can go up.

Alex: Right.You can go up. Alright - buyer beware perhaps. If you are then in an environment where you want to go up, or you want to move to a reserved instance,how do you know when to do it, how are you monitoring the behavior of the instance that you've got, or instances you've got, and deciding when that time is appropriate? How can you see what's going on?

Fraser: Well there's a couple of ways to do it okay? So if you look, the really simple way, is... okay... are your servers performing okay, and are you happy with the way the utilization that you've got on those instances - okay?

The very simple way is going into Cost Explorer within your AWS dashboard and if you've had it running for over a week you'll start getting recommendations from Amazon as to which instances would go onto reserved instances well, and how much money it would save you.

Alex: Should we believe that?

Fraser: If you're settled on your infrastructure then it's a really good way of looking at it, okay? But if you're looking at your instances and going actually, maybe I'm underutilising that instance, or maybe it's not quite coping with what I've got running on the instance. Then maybe you look at first upping or downsizing. Effectively what you really want to do is you want to make every instance the right size for what's running on it, okay? So we talk about right sizing the instances okay? So make sure that if you're, if you've got a two core instance then it's utilizing those two cores. If you've got a four core instance and you're not using the CPU very much then look at changing it, you know. Look at bringing it back down to a smaller instance size and utilising it fully.

Alex: So presumably all these... the CPU usage... that's getting reported to you in some digestible manner?

Fraser: Yeah, so within your AWS console, you get your, you get some really good stats when you look at instances, okay?

You also, you've got cloud watch as well,which cloud watch will let you set up alerts and monitors on CPU usage,it'll let you set up monitors on... you know... if you're looking at... T2 instances it'll let you set up credit watches, and things like that and I'm sure we'll talk about T2 instances in a second.

Alex: Nicely queued up I guess T2 instances, obviously they must be something of interest to the folks, so explain a wee bit about them then.

Fraser: So if you've got a... if you've got an instance running on AWS; say you've got an instance with thirty gig of memory, four cores. You've got it sitting running, but you were actually most of the time that instance is is low CPU usage... okay? So you know, I might need all the memory, but I'm not using the CPU all the... at full tilt. So there's ways to reduce that, and convert that instance from its current instance down to a T2 instance. What a T2 instance lets you do is, it's cheaper than the equivalent general-purpose instance for a start. So it's cheaper per hour than the general-purpose instance, but what happen is that as you're using the CPU, you either gain or lose credits on that CPU. So you start off with a set number of CPU credits, that's about sixty odd. And if you're underutilising the CPU use, the CPU, then you gain credits on that, if you're overusing the CPU based on a threshold, then you will start losing credits and the aim obviously is not to get to zero credits. If you get to zero credits the machine will start to get throttled.

Alex: Alright, I'm trying to digest that. I guess it sounds a bit like a leaky bucket where - somebody, somewhere is pouring water in at the top and there's water pouring out at the bottom. And the idea is to find some kind of equilibrium.

Fraser: Yes, okay.

Alex: Yes, right I'm sure that doesn't help anybody out there.

Fraser: And monitor it. Make sure you never hit zero credits. What we do in that case is we've got our T2 instances set up with Cloud Watch to monitor and make sure that we don't go below 50 credits on any of our instances.

Alex: Okay. We're almost out of time, but given that we're talking about how to maximize the usage of AWS and minimize your spend, the last thing that's probably worth a quick mention is Lambda. Because that strikes me as almost science fiction.

Fraser: Ah, Lamba is fantastic. I love it. It's absolutely brilliant. So what Lambda does it allows you to execute a bit of code for up to five minutes, okay? So you can basically say: here's a bit of code that I want to run; here's the data I wanna give it - and run this for five minutes and come back to me with the results. And then you are effectively paying for what you use, okay? You're not running a server; you're just, you're just firing it a data packet and getting it to run some code against it.

Alex: So basically Amazon's got a whole bunch of processing power and you chuck this code at the thing and it does it and as long as you do it within five minutes and tidy up at the backend so you complete your processing safely; you just chuck it when you need it?

Fraser: Yeah,yeah. It's fantastic.

Alex: So great for a real heavy peak load kind of moments when you really need to do something fast and you've not already pre contracted that processing power, I guess?

Fraser: Yeah, I mean it saves you running up an EC2 instance to go and... and... you know... run something for a couple hours, you just, you know, chop it down, run, run it on Lambda functions and get the results back.

Alex: And you get price information on this regularly so that you're not just spending the Finance Directors budget all the time?

Fraser: Yeah, yeah. So it's worth keeping an eye on your AWS console.So you've got Cost Explorer within AWS console and that tells you effectively what you're spending. Keeps you up-to-date so today I can see what we spent yesterday. And yeah.

Alex: Okay, right folks we've covered a lot of ground: I should thank Fraser, that's probably about 15 minutes that we've spent chatting about AWS costs and the general structure of how an AWS system should look. So, you know to recap there's RDS databases, there's EC2. RDS sounds like a fully managed type thing from Amazon,which is pretty expensive compared to EC2.You choose the instance that you want,you step up the ladder as you need to get more processing power, but with Cloud Watch you can monitor the usage. Sounds like IOPs are pretty important, you get the IOP count right then you can do as much processing as you want, get that wrong and your system will die on its feet by the sounds of it. And then there's this Lambda thing, which is throw some code at Amazon and it'll run it for you. So, yeah, pretty good. Is that a rough summary, Fraser, do you think?

Fraser: Yeah, that's pretty good,we'll take that.

Alex:A pretty rough one I guess. Alright, okay, well thanks again Fraser.

And listeners we're hoping to do a few of these over the next few weeks so please check in again.

Yeah this has been Alex and Fraser talking about AWS costs, thanks very much.

Fraser: Thank you.