- The final pillar we need to explore
in this chapter is the cost optimization pillar.
Here, we're focused on getting the best cost optimization
that we can get out of our AWS deployment.
In other words, we want AWS to do what we need it to do,
but we don't want to pay for more than what we need.
So how we can look at our design
and make sure we're implementing it
in the least expensive, while properly performing,
properly reliable, and properly secure manner?
That's what cost optimization is all about.
Let's begin by looking at the cost
optimization pillar document.
So here we have the AWS cost optimization pillar.
It is AWS-cost-optimization-pillar.pdf.
We scroll down in it just like before,
and we'll see the table of contents
where we can go to the Design Principles section.
Now, notice that we have 35 pages in this document,
bringing us up to a grand total
of 180 pages across the four pillars.
So the first thing it suggests is
to adopt a consumption model.
What this means is that we want
to pay only for the computing resources we consume.
In other words, we want to have
the resources there when we need them,
but we don't want them there when we don't need them.
If you're a 24/7 shop, then maybe you need
your servers running 24/7.
But you might have some instances
that can be brought down every night at say,
8:00 or 9:00 p.m. and then brought back online
at say, 4:00 or 5:00 a.m.,
so they're ready for the next business day.
The point is if we don't need it,
it shouldn't be running at the time
that we don't need it.
So think about those things
that are there in the cloud for your customers
that you might need there 24/7
and then those things that are there
in the cloud for your employees
that you only need there during working hours.
If you're not a 24/7 shop,
and many office environments are a one-shift shop,
then you can get by with disabling several servers
during the evening hours and only bring them
back online when users need them.
So that can be a key cost optimization technique.
You also want to measure overall efficiency.
Measure the business output of the system
and the costs associated with delivering it.
So the benefit of this is that you can
actually monitor the systems you're using
and make sure you're getting business value out of them.
If you're not getting business value out of them,
you can stop using them.
This is one of the beautiful things about AWS.
You can test a system that to implement
in the old way of thinking,
by buying servers and racking and stacking them,
deploying licenses for applications and so forth,
you could spend $60,000 to $100,000,
or even millions of dollars on a solution.
In AWS, you can test it, make sure it gives you
the business value you want,
and then only continue using it
if it really gives you that value.
It may be a simple cost of $600
to $1,000 a month in AWS resources.
The next thing is to stop spending money
on data center operations.
So AWS takes care rack and stack.
In other words, it builds the physical servers
that you need to get the job done.
All you need to do is implement virtual instances on them.
So you don't have to spend money
on building out a data center
in order to test a new solution.
You also want to analyze and attribute expenditure.
So take a look at where your costs are coming from in AWS.
And make sure you understand the department
that's consuming it and so forth.
So that, again, you can justify it.
If there's a department that's consuming
30% of your AWS costs, but they're only providing 5%
of your business value,
you might want to reevaluate the use of that in AWS
or exactly what is being used,
so you can get the costs into balance.
Finally, use managed services
to reduce the cost of ownership.
If you run EC2 instances to do things,
the reality you have to understand
is that you actually have to manage
the operating systems and applications
running in that instance.
You need man hours to accomplish that.
When you do managed services, like using an RDS database,
instead of running a database in your own EC2 instance,
it doesn't require as many man hours
to manage that database service.
I want to share with you now
four pillars of cost optimization.
This information is available in a lot of detail
covering several pages in the cost optimization
pillars document available from AWS.
The first suggestion is to use cost-effective resources.
Cost-effective resources are not always
what you think they might be.
Sometimes it's actually less expensive
to run a more powerful instance that costs more per hour.
And the reason for that is that it gets the job done faster.
So it takes far less time,
and it can actually be less expensive
than paying for a cheaper server
that takes much more time.
So always use cost-effective resources.
Also, match supply with demand.
So you don't want to have scaled out to 15 servers
during a window of time when demand
only asks for three servers.
But you also don't want only three servers
during a period of time when demand asks for 15 servers.
So make sure you're using auto-scaling
to have the right number of servers
that you need at any given time.
Also, be aware of your expenditures.
So expenditure awareness comes through
using the billing management features of AWS,
where you can actually track billing
and even get billing alerts,
so you can know when you've crossed
a certain threshold in your expenditures.
Finally, you must be optimizing over time.
You need to make sure that you're continually looking
at ways that you can do things,
getting the performance you need,
getting the reliability you need,
getting the security you need,
but with the least costs possible.
And that's really what cost optimization is all about.
It's key as an architect to understand
that over time as you implement more and more AWS solutions,
you're going to learn more and more
about how to get the job done
with as little expenses as possible.
But it does take some time and experience to get there.
If you'll remember the tips
we've talked about in this episode,
you'll be a long toward that experiential goal
that you have down the road
of understanding cost optimization in AWS.
(lively music)