Tel: +44 (0)1786 430076 email: info@objectiveassociates.co.uk
Discussing Amazon's AWS, including costs and "how to" best advice. We also talk about related technologies. The Objective Podcast is available on iTunes.
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.
Alex: Hello, and welcome to another edition of the Objective Associates podcast. In which we talk about technology and in particular, in this little series of podcasts, we've been talking a lot about Amazon Web Services. Very powerful web services they are. And with me Fraser Ingram. So say hello Fraser.
Fraser: Hello.
Alex: And I am Alex Ogilvie - we are both directors at Objective Associates. In this episode we're going to talk about how to choose your AWS instance type. So I guess - where do you start Fraser? What's the kind of first things that you have to consider?
Fraser: Yeah - the first thing you're looking at is the same as when you're provisioning any kind of server. How many cores do you need, and how much memory do you want on that, on that, server. On AWS you can go anything from a single core, single virtual CPU effectively - with half a gig of memory, up to... well some of the M5s type instances have got 96 virtual cores and hundreds of gigs worth of memory on them. So yeah, you need to gauge where do you want to be in that scale.
Alex: I mean there's a number of things in there, there's M fives and there's R's and there's I threes and things - what do these mean do they mean anything?
Fraser: They're optimized for different operations so your M type instances are your general purpose instance types - okay. Where as something like an R instance type is memory optimized. T... - T2 instances in particular - are a different breed altogether. They are pretty much like an M, except there's a credit based use on the CPU. So yeah, I mean theres loads of different instance types but they're all optimized slightly differently, either skewed toward CPU, skewed towards storage, skewed towards memory.
Alex: Alright so depending on the type of application you're running for your business you can get some some guidance from the Amazon branding. So like you say an M5 is general purpose, I think you said R was memory optimized.
Fraser: Yeah and I is storage optimized, meaning it's got some fast storage next to it, for quick access to storage.
Alex: Well I guess it's like going into a car showroom and they kinda steer you towards either a 3 series or a 5 series or... it's that type of thing. They take you to where they think you need - the performance. And then you said as well the T2 instances they're different in breed, because it's more the business model is different there rather than the technology.
Fraser: Yeah, yeah T2 instances are a bit more peculiar, so you start off with one virtual CPU and half a Gig of memory and on T2 instances I think you can go up to about eight virtual CPUs - something like that. The difference with these though is the way that you use the CPU and how you pay for that CPU usage. What you start with is a set of credits, 63 credits on the T2 instances. As you use the CPU above a threshold you start losing credits and as a you stop using the CPU you start gaining credits. And obviously the aim is never to reach zero credits and watch your credit usage to make sure that you're on an instance type where you're not overusing the CPU or under using the CPU. So you're looking for effectively a peaky application in that case, okay. So you're looking for something that peaks with its use of the CPU for a little while and then stops using it for a little bit.
Alex: I guess then that the thing, that a... someone whose provisioning, effectively, one of these instances, are going to look at what type of application it is. So if it's general purpose I mean I guess that's kind of like that a conventional CRM system for a business would be general purpose.
Fraser: Yeah, yeah a databaser server, web application server.
Alex: And I guess memory optimized. well something that's really kinda needing to do an awful lot of grunt, so maybe your processing video, something really heavy handed. That type of stuff I guess.
Fraser: Yeah, that type of stuff. Although whether you do that in an EC2 instance, or some of the other AWS technology... I guess is the question.
Alex: Aye, good point because there is a number of services that can support video processing. Once you've picked that that instance though, I guess the risk is that you've got it wrong.
Fraser: Yeah, I mean either you've got it wrong, or your use changes.What you really want to do is set up Cloud Watch to monitor your use of that server. So you can set up Cloud Watch within Amazon to send you alerts based on... okay where's your CPU usage. You know if you're above sixty / seventy percent you want to start getting alerts on that, to tell you that your CPU usage is high. Or even the opposite, you want to look at, okay, you start getting alerts for the CPU usage being low. Is the CPU usage 10 / 20 percent in which case you're underutilizing that instance. You could maybe save some money by changing that instance type.
Alex: Right so it lets you, at least, spot that you're maybe overspending, and then you can cut back, and provision something else. Can you do that automatically. I mean can you just change instance easily - or have you got to do something...
Fraser: No... I mean it's fairly simple process, you do it on the console within AWS. You can change your instance type, the one thing that you do have to do, is the machine has to be rebooted in order to change that instance type. But it's a fairly fast process in order to do that. You can also do it programmatically - if you've got a resilient system, where bringing that server down and back up isn't gonna cause you a problem operationally, then you could do that programmatically.
Alex: Alright so that opens up the notion that if you are starting to see your CPU usage go above your thresholds too often, through using Cloud Watch, you could potentially trigger something to programmatically... well I guess spin up another instance or use lambda functions, or do something to take care of that over utilisation.
Fraser: Yeah, so I mean if you imagine in Cloud Watch, if you set an alert to say: the CPU usage is high. You send that to Amazon's SNS, you pick off that alert from SNS and you do something with it. That could be an automated process that you do. In which case, you know, you maybe want to increase the instance size and do a couple other things, or maybe bring up an additional instance that also takes care of some of the workload.
Alex: But, yeah, I mean, I think that power of actually being able to detect when a server is under pressure, for whatever reason, and then programmatically do something about that, that's pretty...
Fraser: Yeah, it is pretty cool. I mean you don't have to do that; you could just get an email to tell you. Okay, you know, this server's under pressure, you might need to think about doing something about it.
Alex: Okay, so we've picked the instance type but we haven't really mentioned storage; other than, I guess, depending on whether it's an M or an R. What can you do there? How do you actually set up, or choose the storage that's appropriate for the environment you want?
Fraser: Yeah, so you've got your different types of storage. You've got instance storage, which effectively is locally attached to the machine - and that's volatile storage, so it's there for as long as the machine is running. But once the machine gets shut down and restarted, that would get blanked effectively. So that instance storage is typically very fast storage and would come on the storage optimized instance types. Or you get instances which are, which have EBS storage. Now EBS storage can either be SSDs or hard drives and within each of those there's different flavours depending on what level of performance you're looking for. So you've got something like - cold storage on a hard drive, so typically that would be, well it's slow storage, but typically used for something like backups or something that you don't really need access quickly or often. You've got throughput optimized hard drives which are faster hard drives, but is still a hard drive. And then on SSDs there's two flavors of SSDs that you can get. One's a general-purpose SSD where effectvely how fast that is, is determined by the size of the drive you've got. Or a provisioned IOPs SSD. And that lets you set how fast you want it to be, as opposed to based on the size.
Alex: Alright, so that really puts you in control then with SSD option with these provisioned IOPs. You can actually say - that's as much as I need and I guess if you need more - they charge you more on the IOP side.
Fraser: Yeah, so I mean if you've got a thousand IOPs it'll cost you, I dunno, 90 bucks a month, if you're using it full time. If you want to bump it to 2,000 IOPs, then double it. That's pretty much how it's gonna work on the IOPs. But again you get a lot faster storage, you don't have to be limited on the storage speed based on the size. You can work out how fast you need it to be. And then again on the Cloud Watch side of things, that's how you work out, is your storage fast enough. Quite a few metrics in Cloud Watch that tell you about what's happening on the drives. You've got things like you Queue lengths, you've got number of read operations, number of write operations, things like that. And Amazon have kind of given us a few calculations as to to work out, have you got fast enough storage. But the one that I typically look at is where's the queue length on that drive. And Amazon are basically saying if you're queue length is five or below on the drive, most of the time, then you have got fast enough IOPa, you've got enough IOPs on that drive. If you're running above that, then the queue length on the drive is getting long and your access to the storage, or access to the data that's on the drive is starting to slow down.
Alex: Goodness, I mean that's useful again. Because as you're basically bringing this recipe together for your own business systems, being able to use Cloud Watch to detect when your CPU is maybe being over utilized or when your queue length on your disk is starting to go up... really does put you in quite a powerful position, to manage your system and control costs.
Fraser: Yeah, I mean that's the the key thing here, is to make sure that what you've got provisioned is the right size for what your using. You know, don't over provision IOPs, because it will cost you an absolute fortune. So if you've got a queue length that's always zero then you've over-provisioned you're IOPs on there. So bring your IOPS down. If your CPU usage is typically 10% then bring down the instance size o,r choose a different instance type that's more suited to that application.
Alex: And as you said, you choose the instance type that's appropriate. If it's a small or less powerful server and all you have to worry about is the fact that it's going to go down and back up again to actually get going.
Fraser: Yep, yep,
Alex: So as long as you manage, that your good.
Fraser: Yeah, either a maintenance window, or hopefully, even better a resilient solution where it copes with the fact that a server goes down and backup.
Alex: Well look we've covered a fair bit there, on how you choose your instance type, but it sounds like you have to look at the various precooked server instances that Amazon provide. Whether that's an M type or an R and some of these are, well the R is memory optimized for instance. So it really depends on what your application is doing. Sounds like for the bulk of people out there the general purpose M4s and M5s is about right. And then after that it's your storage provision. Whether you're using local instances or whether you are using EBS. Lots of different options in there. And ultimately Cloud Watch sitting there telling you how much you are using that system and ultimately giving you the option to potentially programmatically change those instance types, which I think is pretty cool. Fraser, anything else to add before we wind up?
Fraser: I think probably the only, the last thing is, as Amazon bring out a new generation of instances, they're typically a little bit faster, and a little bit cheaper. So they knd of encourage you to move on to the next generation. So if you're sitting on M4 instances and they're bringing out M5s, you know, look to see what you can do and shift onto the M5s. It might not save you an awful lot of money, but it's the latest instance type. It'll be a little bit more powerful and a little bit cheaper for you.
Alex: Sounds fantastic. Okay folks, well that brings us to the end of another podcast from Objective Associates Hopefully talk to you soon, bye just now.
The Objective Podcast is available on iTunes
AWS resilience capabilities explained
How to manage Amazon’s AWS costs
How to get started on Amazon's AWS
How to choose your AWS instance type
5 tips on how to save money on AWS