Take a minute to review the progression of governance and compliance when
working with your resources in the AWS Cloud.
As the owner of the coffee shop, I want to watch what's going on
throughout the day to make sure that things are running smoothly.
In the coffee shop, I can see that people are getting their coffees,
and things look generally fine. But I can't just sit there and watch
things all day long. As the owner, I am a pretty important person.
And, I would like to eventually leave and then get a report about
how things went.
For example, I might want to know how many coffees were sold any
given day. How long was the average wait time for someone when
ordering a coffee? Did we run out of any inventory for anything
today? Even better yet, I'd love to be automatically alerted if the
wait times become too long.
Every business, including this coffee shop, can use metrics to
measure how well systems and processes are running. This idea of
observing systems, collecting metrics, evaluating those metrics over
time, and then using them to make decisions or take actions is what
we call monitoring.
It's important to set up monitoring in the cloud. AWS services can
dynamically scale up and down. So, you'll want to keep a close
watch on your AWS resources to ensure that your systems are
running as expected.
For example, if an EC2 instance is being over-utilized, a scaling
event can be triggered to automatically launch another EC2
instance using EC2 Auto Scaling. Or if an application starts sending
error responses at an unusually high rate, notifications can be sent
to the employees to troubleshoot the issue.
AWS monitoring tools help you measure how your systems are
performing, alert you when things aren't right, and even help you
debug and troubleshoot issues as they come along.
Monitoring is performed using real-time monitoring tools, log collection and analysis,
and dashboards. In the following lessons, you will identify several different
monitoring tools and what they do.
In both our coffee shop and the AWS Cloud, there are so many
systems to monitor. Wouldn't it be nice to have one centralized
place to go? Yep. That's where Amazon CloudWatch comes in.
CloudWatch makes it possible for you to monitor your infrastructure
and the applications you run on AWS. It accomplishes this through
monitoring and tracking of metrics.
Metrics are variables that are tied to your resources. For example,
the number of espressos made by an espresso machine or the CPU
utilization of an Amazon EC2 instance. For espresso machines, they
need to be cleaned after every 1000 espressos. So, we go into
CloudWatch and create a custom metric called Espresso Count. This
tells us what the espresso count is at any given time. But after it
reaches 1000, how do we let our employees know they need to
clean the machine?
Well, with another CloudWatch feature called CloudWatch alarms.
We create an alarm and then set the threshold for a metric. After
the threshold is reached, the alarm is triggered and we can add a
corresponding action.
With our Espresso Count metric, we set the threshold to 1000 and
set the action to let the manager know the machine needs to be
cleaned. Even better, because CloudWatch alarms are integrated
with Amazon SNS, we can set up the action to send a text message
to the manager directly.
We can create all sorts of custom alarms for metrics from all
different types of AWS resources. But I can see you asking, “Rudy,
where do I see all these metrics?” I got you, boo. You can use the
CloudWatch dashboard feature. A dashboard, or screen, lists out all
the metrics in near real time.
In our case, we create a CloudWatch dashboard that shows us all
our espresso machines and their espresso counts. No need to click
the refresh button on your browser either. These dashboards auto
refresh so you can see up-to-date information with ease. But where
does all the data on the dashboard get stored? And what if we want
to review what happened in the coffee shop, say last week, or
search for an issue on a specific machine, or even analyze data
further?
That's where CloudWatch logs can help. This feature centralizes log
management and analysis by collecting, storing, and monitoring log
files from AWS resources. You can view, search, and filter logs,
depending on what you need. In fact, it’s very useful for filtering
certain error codes or searching for why espresso machine two
started making decaf coffee last week! A little secret—it’s because I
put decaf beans into it. Mwahaha. Just kidding…or am I?
Let’s wrap up by touching on the benefits of CloudWatch. The first is
centralized access to all your metrics from all your different sources.
That means all your AWS resources and your on-premises servers.
No more siloed monitoring. Use a single pane of glass for system-
wide visibility. Reduce mean time to resolution or MTTR. Improve
total cost of ownership, or TCO, and much more.
In application terms, this means freeing up important resources like
developers to focus on adding business value like coding the next
great app. Lastly, you can drive insights to optimize applications and
operational resources. For example, aggregating usage across an
entire fleet of EC2 instances to derive operational and utilization
insights.
Metrics
CloudWatch collects metrics from all your AWS resources,
applications, and services that run on AWS and on-premises servers.
Alarms
With CloudWatch alarms, you can define thresholds on CloudWatch
metrics and send notifications or automatically make changes to the
resources.
Dashboards
Dashboards are customizable home pages in the CloudWatch
console that you can use to monitor your resources in a single view.
Logs
CloudWatch Logs centralize the logs from all of the systems,
applications, and AWS services that you use.
Being able to audit transactions of IT events is a critical ability. In a
physical datacenter there are so many places where a human can,
even by accident, make changes without any record of that change
getting saved.
In the AWS Cloud, that problem goes away because every action in
AWS is an API call. They can be centrally logged and audited with
AWS CloudTrail. This service is straightforward. It logs every request
made to AWS. It doesn't matter if it's to launch an Amazon Elastic
Compute Cloud, or Amazon EC2 instance, or add a row to an
Amazon DynamoDB table, or change a user's permissions.
Every request gets logged in CloudTrail. It records exactly who
made the request, what operator, and when the API call was sent.
Where were they? What was their IP address? And what was the
response? Did something change? And what is the new state? Or
was the request denied?
This is great for us, and this makes an auditor's job much easier
which in turn makes our job easier! CloudTrail is an audit log of the
AWS API calls, so it is a history of configurations and changes in a
deployment. CloudTrail even comes with features to validate log file
integrity to show evidence of tampering.
Furthermore, if we are concerned an actor with root level
permissions could still tamper with the CloudTrail logs, we can ship
the logs to another AWS account which by design has different
permissions to further protect the log integrity.
For every industry, there are specific standards that need to be
upheld, and you could be audited or inspected to ensure that you
have met those standards. You rely on documentation, records, and
inspections to pass audits and compliance checks as they come
along.
Depending on what types of solutions you host on AWS, you will
need to ensure that you are up to compliance for whatever
standards and regulations your business is specifically held to. If you
run software that deals with consumer data in the European Union,
you would need to make sure that you're in compliance with general
data protection regulation or GDPR. Or if you run healthcare
applications in the US, you will need to design your architectures to
meet Health Insurance Portability and Accountability Act of 1996, or
HIPAA, compliance requirements.
Whatever your compliance need is, you'll need some tools to be
able to collect documents and records. You will also need to inspect
your AWS environment to check if you meet the compliance
regulations that you're under.
The first thing to note is that AWS has already built out data center
infrastructure and networking using industry best practices. As an
AWS customer, you inherit all the best practices of AWS policies,
architecture, and operational processes. AWS complies with a long
list of assurance programs that you can find online. This means that
segments of your compliance have already been completed, and
you can focus on meeting compliance within your own architectures
that you build on top of AWS.
The next thing to know in regard to compliance and AWS is that the
AWS Region you choose to operate out of might help you meet
compliance regulations. If you can only legally store data in the
country that the data is from, you can choose a Region that makes
sense for you, and AWS will not automatically replicate data across
Regions.
You should also be very aware of the fact that you own your data in
AWS. As shown in the AWS Shared Responsibility Model, you have
complete control over the data that you store in AWS. You can
employ multiple different encryption mechanisms to keep your data
safe, and that varies from service to service. You can either use the
features that already exist in many services or build it yourself on
top of AWS. For a lot of services though, enabling data protection is
a configuration setting on the resource.
AWS offers multiple whitepapers and documents that you can
download and use for compliance reports. One place you can access
these documents is through a service called AWS Artifact. With AWS
Artifact, you can gain access to compliance reports done by third
parties who have validated a wide range of compliance standards.
Check out the AWS Compliance Center. It will show you compliance-
enabling services in one place. And you can also use resources like
the AWS Risk and Security whitepaper which contains a lot of
awesome information that you can learn from.
When it comes to compliance, the good news is that the underlying
infrastructure "of" the cloud is secure.
AWS Compliance
The AWS Compliance portal(opens in a new tab) contains resources to help you learn
more about AWS compliance. You can read customer compliance stories to discover
how companies in regulated industries have solved various compliance, governance,
and audit challenges.
You can also access compliance whitepapers and documentation on topics such as
the following:
AWS answers to key compliance questions
An overview of AWS risk and compliance
An auditing security checklist
For essentials and best practices, guides, and workbooks, including training,
visit Additional compliance resources(opens in a new tab).
You might be wondering how you know if the resources and
architectures you create are in compliance with your own company
standards.
Your organization will likely have rules you want your architectures
to adhere to including specific configuration guidelines for different
AWS resources. You're going to want a way to assess and audit the
resources you create on AWS to ensure that they meet these rules.
That's where AWS Config comes in.
AWS Config is a service that monitors and records AWS resource
configurations and evaluates them against the configurations you
want to implement. It helps you assess, audit, and evaluate your
resources so your solutions can be in compliance with internal
policies and regulations.
Config continuously tracks changes to your AWS resources. You can
create rules that define your compliance standards, and then Config
will automatically evaluate if your resources meet those standards.
You can receive notifications when Config identifies any
noncompliant resources, and you can even set up automated
remediation actions to get your resources back into compliance.
You can also generate reports showing which resources are
compliant and which ones are not. After all, compliance isn't
something you do once and you're done. It's an ongoing thing. With
Config, you can monitor your configurations to ensure that they
don't change over time.
Sounds like you'd be all set, right? Well, not so fast. If you’re in an
industry that requires high levels of compliance, it's not enough to
be compliant. You must be able to provide evidence that you meet
the standards and regulations.
So, for example, a healthcare company might need to provide
evidence that patient data is kept private and secure. Or, a financial
firm might need to provide evidence to regulators that it’s handling
money safely and correctly. That's where you can use AWS Audit
Manager, a fully managed service that automates evidence
collection to reduce the manual effort of several cross-functional
teams that audit activities often require.
You can assess if your policies, procedures, and activities, also
called controls, are operating effectively. And it helps you manage
stakeholder reviews of your controls as well as provides information
for building audit-ready reports with less manual effort.
As you can see, Audit Manager has pre-built frameworks that cover
a range of compliance standards and maps your AWS resources to
the requirements for industry standards and regulations.
You might be wondering how you know if the resources and
architectures you create are in compliance with your own company
standards.
Your organization will likely have rules you want your architectures
to adhere to including specific configuration guidelines for different
AWS resources. You're going to want a way to assess and audit the
resources you create on AWS to ensure that they meet these rules.
That's where AWS Config comes in.
AWS Config is a service that monitors and records AWS resource
configurations and evaluates them against the configurations you
want to implement. It helps you assess, audit, and evaluate your
resources so your solutions can be in compliance with internal
policies and regulations.
Config continuously tracks changes to your AWS resources. You can
create rules that define your compliance standards, and then Config
will automatically evaluate if your resources meet those standards.
You can receive notifications when Config identifies any
noncompliant resources, and you can even set up automated
remediation actions to get your resources back into compliance.
You can also generate reports showing which resources are
compliant and which ones are not. After all, compliance isn't
something you do once and you're done. It's an ongoing thing. With
Config, you can monitor your configurations to ensure that they
don't change over time.
Sounds like you'd be all set, right? Well, not so fast. If you’re in an
industry that requires high levels of compliance, it's not enough to
be compliant. You must be able to provide evidence that you meet
the standards and regulations.
So, for example, a healthcare company might need to provide
evidence that patient data is kept private and secure. Or, a financial
firm might need to provide evidence to regulators that it’s handling
money safely and correctly. That's where you can use AWS Audit
Manager, a fully managed service that automates evidence
collection to reduce the manual effort of several cross-functional
teams that audit activities often require.
You can assess if your policies, procedures, and activities, also
called controls, are operating effectively. And it helps you manage
stakeholder reviews of your controls as well as provides information
for building audit-ready reports with less manual effort.
As you can see, Audit Manager has pre-built frameworks that cover
a range of compliance standards and maps your AWS resources to
the requirements for industry standards and regulations.
Most companies will want you to follow specific configuration guidelines for your
different AWS resources. This means that you will want a way to assess and audit the
resources that you create on AWS to help ensure that they meet those rules. That's
where AWS Config can help.
With your first foray into the AWS Cloud, you will most likely start
with a single AWS account. This is great if you are experimenting
with AWS and moving test workloads. However, as your company’s
AWS footprint matures, you will start to create more and more
separate AWS Accounts.
These accounts will all have specialized purposes like production
and non-production, or an account just for your developers, and
another just for your infrastructure team. These accounts could also
limit access to certain AWS Services and have other customizations
that are not shared across all accounts.
Moreover, you need a way to manage your accounts since doing it
manually is not ideal. This is where AWS Organizations can help.
Organizations is an account management service that allows for the
consolidation and central management of multiple AWS accounts
within an organization. It allows you to manage billing, access,
compliance, and security as well as share resources across
accounts.
You designate a main, or parent account, and all other accounts are
secondary, or children, to that main account. Billing is consolidated
into the primary account. So, all the bills for the children accounts
roll up to the parent account. Then, discounts are applied at the top
level.
Another feature is hierarchical account groupings to meet security,
compliance, or budgetary needs. For example, you can group all the
accounts into organizational units or OUs. So, if you have accounts
that must access only the services that meet certain regulatory
requirements, you can put those accounts into one, single OU.
Or if, say, you have accounts that fall under the developer OU, you
can group them accordingly. As an admin of the primary account of
an organization, you even have control over the AWS services and
API actions that each account can access.
You can even use service control policies, or SCPs, to specify the
maximum permissions for member accounts in the organization. In
essence, with SCPs you can control which services, resources, and
individual API actions, the users and roles in each member account
can access.
So, consider using Organizations, sooner rather than later, so you
don’t end up with ghost AWS accounts. After all, nobody wants
ghosts running around. That’s spooky.
AWS Organizations
AWS Organizations is used to consolidate and manage multiple AWS
accounts within a central location. When you create an organization,
it automatically creates a root, which is the parent container for all
the accounts in your organization.
Management account
The management account is the central AWS account that creates
and manages the organization. It's responsible for overall control
and governance.
Organizational unit (OU)
An organizational unit (OU) is a logical grouping of accounts in an
AWS Organization. OUs can contain member accounts or nested
OUs.
Service control policies (SCP)
An SCP is a policy that lets you place restrictions on the AWS
services, resources, and individual API actions that users and roles
in each account can access. SCPs can be applied to either OUs or
individual member accounts.
Member account not in an OU
If you have a member account that has unique requirements that do
not overlap with those of an organizational unit, you can add them
to the organization. They do not have to be placed under an OU.
This account can still take advantage of benefits such as
consolidated billing.
In designing your organization, you should consider the
business, security, and regulatory needs of each department.
You use this information to decide which departments group
together in OUs.
To learn more about centrally managing your environment as
you scale your AWS resources, refer to the AWS Organizations
User Guide.
Imagine you're the mayor of a rapidly growing city: Cloud Town. As
your city expands, you need a way to oversee all the new buildings,
roads, and services while making sure everything follows the city's
rules. You want to empower your builders to act autonomously, but
you need to ensure governance.
Governance is the framework that makes it so all the work of
building and operating your deployment is efficient and supports the
overall goals. In Cloud Town, we might want a zoning code limiting
the height of buildings because we know we're building an airport
later.
You might want to enforce that all resources are tagged with the
department that creates them for simple cost tracking. How can you
do this if every AWS account's root user can in theory do whatever
they want?
With multiple accounts, that's where AWS Control Tower can help.
It’s like a high-tech control center for your cloud city, helping you
govern, manage, and organize your AWS environment as it grows.
AWS Control Tower is especially helpful because the more people
you have building in the cloud, the more complex and time-
consuming set up and governance can be.
You need everyone creating new accounts and spinning up AWS
resources to follow the rules. You can provision new AWS accounts,
and you have peace of mind knowing your accounts conform to your
company-wide policies. It helps you standardize initial account setup
according to best practices.
Let's look at how it works. First, Control Tower makes it possible for
you to automate setup using established blueprints for configuring
your AWS environment with federated access management and
account provisioning workflows.
Next is applying guardrails. These are like the safety barriers on a
highway. They help prevent accidents by automatically enforcing
rules and best practices across your AWS environment.
You can apply security and compliance policies using established
guardrails to prevent resources from being deployed that don’t
conform to policies. Plus, you can detect and remediate
noncompliant accounts and resources as your team provisions
them.
Finally, you can monitor compliance. Control Tower provides a visual
summary of your AWS environment through a dashboard that you
can use to observe your accounts, guardrails, and compliance status
all in one place.
With Control Tower, you can save time and have greater control
over your AWS environment so you can govern your workloads more
efficiently while making sure they also conform to your company-
wide policies.
So, whether you’re starting out on your journey to AWS, building a
new AWS environment, or launching a new cloud initiative, Control
Tower will help you with governance and best practices built-in to
make sure you’re successful.
Dashboard
The AWS Control Tower dashboard provides continuous oversight to
see provisioned accounts across your enterprise. AWS Control Tower
also has controls for policy enforcement and can help detect
noncompliant resources.
Account Factory
The AWS Control Tower Account Factory is a configurable account
template that standardizes the provisioning of new accounts.
Controls
Controls, sometimes called guardrails, are high-level rules that
provide governance for your overall AWS environment.
Landing zone
A landing zone is a well-architected multi-account environment
that's based on security and compliance best practices. It's the
enterprise-wide container that holds all of the organizational units
(OUs), accounts, users, and resources you want to regulate for
compliance.
When running a business, you might need some advisors who can
come in from the outside and say, “Hey, this process should be
streamlined.” Or, “Hey, I have some good tips on how to save
money on your overhead.” Or even, “Hey, I noticed I was able to
waltz right in, go behind the cash register, and open the drawer
without anyone noticing.”
Not good!
The point I'm trying to make is, sometimes it's nice to have
someone who knows the industry best practices, and knows what to
look for, come in, and tell you what you need to change to run more
efficiently, be more secure, or to lower costs.
AWS has an automated advisor called AWS Trusted Advisor. This is a
service that you can use in your AWS account that will evaluate your
resources against five categories of checks.
The checks look for areas of improvement related to cost
optimization, performance, security, fault tolerance, and service
limits. Trusted Advisor runs through a series of checks for each
category in your account in real time, based on AWS best practices.
It compiles categorized items for you to look into, and you can view
them directly in the AWS Management Console.
Some checks are included in your AWS account, and others are
available, depending on the level of your support plan. For example,
if you don't have multi-factor authentication turned on for your root
user, it's going to let you know. It also lets you know if you have
underutilized EC2 instances that might be able to be turned off to
lower costs. Another example, is if you have EBS volumes that
haven't been backed up in a while. To get a better idea, let's look at
AWS Trusted Advisor in my own account.
Here I am in the Trusted Advisor dashboard and I'm going to choose
Cost Optimization first to view what it has found. You can see that
we have red here, which means action recommended, orange,
which means investigation recommended, and green, which means
that there were no problems detected.
Lucky for me, I don't have any critical items for Cost Optimization.
However, I can go through and read more about each check that
Trusted Advisor ran. For example, there is a check that looks to see
if there are any RDS instances that are idle in this account. And here
is another example of a check that evaluates ELB utilization. And
then here is another one that checks for EBS utilization. If I had
resources in this account that got flagged with these checks, I could
decide to scale these resources down to save on cost. Or, if they
aren't being used at all, I could decide to delete them.
Now, let's move on to Performance. There are no action
recommended or investigation recommended items, but we can
review some of the checks that Trusted Advisor performed. Scrolling
down, I can type in EBS, and there is this one here that checks for
EBS volumes whose performance might have been affected by the
throughput capability of the EC2 instance that it's attached to.
Next up, let’s check out Security. In this demo account, you can see
there are two alerts that are at the action recommended level.
There are some security groups allowing public access to EC2
instances, which is putting those resources at risk, and this should
be resolved.
Now let's move on to Fault tolerance. For this, there were a few
things that are found to be insufficient. First, Trusted Advisor is
telling me that there are EBS volumes without snapshots in this
account. Remember, a snapshot is a backup. So, without backups, if
I had an EBS volume fail, I would lose that data.
Another alert we have here is that my EC2 AZ balance is at the
action recommended level. This means that my EC2 workload is not
properly launched across AZs. So, if one AZ or instance has trouble,
my application might have a disruption. Deploying across AZs would
be the answer to this one.
And then lastly, we have one for Amazon S3 Bucket Logging. And
this is checking to see if logging is enabled properly for my S3
buckets, which I have some buckets in this account that do not have
proper logging.
Finally, let's go ahead and move onto Service limits. Service limits
tell you when you are approaching or hitting any AWS service limits.
A lot of these are soft limits, meaning they are restrictions that can
be lifted to some degree. It's good to know when you are
approaching one of those limits, and when it's time to use the
Service Quota console, which you can use to request a change to
these limits. There is nothing to report for this specific account on
that front.
Overall, you can see how Trusted Advisor can help point you in the
right direction. You can set up email alerts that go out to billing,
operations, and security contacts, as checks are run in your
account. Make sure you have Trusted Advisor turned on so that you,
too, can start taking action to optimize your AWS account.