Tel: +44 (0)1786 430076 email: firstname.lastname@example.org
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.
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
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
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
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
Fraser: Yeah, yeah
a databaser server, web application
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
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
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
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
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
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