CloudWatch

CloudWatch

 Amazon CloudWatch monitors your Amazon Web

Services (AWS) resources and the applications you
run on AWS in real-time
 You can use CloudWatch to collect and track metrics,
which are the variables you want to measure for your
resources and applications
 CloudWatch alarms send notifications or
automatically make changes to the resources you are
monitoring based on rules that you define
 CloudWatch

 For example, you can monitor the CPU usage and

disk reads and writes of your Amazon Elastic
Compute Cloud (Amazon EC2) instances and then
use this data to determine whether you should
launch additional instances to handle increased load
 You can also use this data to stop under-used
instances to save money.
 In addition to monitoring the built-in metrics that
come with AWS, you can monitor your own custom
metrics
 CloudWatch Architecture

 Amazon CloudWatch is basically a metrics repository

 AWS product—such as Amazon EC2—puts metrics
into the repository
 You retrieve statistics based on those metrics
 If you put your own custom metrics into the
repository, you can retrieve those statistics as well.
CloudWatch Architecture
 CloudWatch

 You can use metrics to calculate statistics and

present the data graphically in the CloudWatch
console
 You can configure alarm actions to stop, start, or
terminate an Amazon EC2 instance when certain
criteria are met
 In addition, you can create alarms that initiate Auto
Scaling and Amazon Simple Notification Service
(Amazon SNS) actions on your behalf
 CloudWatch Concepts

 Metrics
 Namespaces
 Dimensions
 Time Stamps
 Units
 CloudWatch Concepts

 Statistics
 Periods
 Aggregation
 Alarms
 Regions
 Metrics

 Metrics represents a time-ordered set of data points

 These data points can be either your custom metrics
or metrics from other services in AWS
 You or AWS products publish metric data points into
CloudWatch and you retrieve statistics about those
data points as an ordered set of time-series data.
 Metrics exist only in the region in which they are
created
 Metrics

 The data points themselves can come from any

application or business activity from which you
collect data, not just Amazon Web Services products
and applications.
 For example, a metric might be the CPU usage of a
particular Amazon EC2 instance or the temperature
in a refrigeration facility
 You can use the PutMetricData API action (or the
put-metric-data command) to create a custom metric
and publish data points for it
 Metrics

 CloudWatch stores your metric data for two weeks.

 You can publish metric data from multiple sources,
such as incoming network traffic from dozens of
different Amazon EC2 instances, or requested page
views from several different web applications.
 You can request statistics on metric data points that
occur within a specified time window.
 Namespaces

 CloudWatch namespaces are containers for metrics.

 Metrics in different namespaces are isolated from each
other, so that metrics from different applications are not
mistakenly aggregated into the same statistics
 Namespace names are strings you define when you create
a metric. The names must be valid XML characters,
typically containing the alphanumeric characters "0-9A-
Za-z" plus "."(period), "-" (hyphen), "_" (underscore), "/"
(slash), "#" (hash), and ":" (colon). AWS namespaces all
follow the convention AWS/<service>, such as
AWS/EC2 and AWS/ELB.
 Dimension

 A dimension is a name/value pair that helps you to

uniquely identify a metric.
 Every metric has specific characteristics that
describe it, and you can think of dimensions as
categories for those characteristics.
 Dimensions help you design a structure for your
statistics plan.
 Because dimensions are part of the unique identifier
for a metric, whenever you add a unique name/value
pair to one of your metrics, you are creating a new
metric.
 Timestamps

 Each metric data point must be marked with a time

stamp. The time stamp can be up to two weeks in the
past and up to two hours into the future.
 If you do not provide a time stamp, CloudWatch
creates a time stamp for you based on the time the
data element was received
 Units

 Units represent your statistic's unit of measure. For example,

the units for the Amazon EC2 NetworkIn metric are Bytes
because NetworkIn tracks the number of bytes that an
instance receives on all network interfaces.
 Supported units:
 Seconds
 Bytes
 Bits
 Percent
 Count
 Bytes/Second (bytes per second)
 Bits/Second (bits per second)
 Count/Second (counts per second)
 None (default when no unit is specified)
 Statistics

 Statistics are metric data aggregations over specified

periods of time.
 CloudWatch provides statistics based on the metric
data points provided by your custom data or
provided by other services in AWS to CloudWatch.
 Aggregations are made using the namespace, metric
name, dimensions, and the data point unit of
measure, within the time period you specify
Statistics
 Periods

 A period is the length of time associated with a

specific Amazon CloudWatch statistic.
 Each statistic represents an aggregation of the
metrics data collected for a specified period of time.
 Although periods are expressed in seconds, the
minimum granularity for a period is one minute.
 Accordingly, you specify period values as multiples of
60
 Aggregation

 Amazon CloudWatch aggregates statistics according

to the period length that you specify in calls to
GetMetricStatistics.
 You can publish as many data points as you want
with the same or similar time stamps. CloudWatch
aggregates them by period length when you get
statistics about those data points with
GetMetricStatistics.
 Aggregated statistics are only available when using
detailed monitoring. In addition, Amazon
CloudWatch does not aggregate data across Regions.
 Alarm

 Alarms can automatically initiate actions on your

behalf, based on parameters you specify.
 An alarm watches a single metric over a specified
time period, and performs one or more actions based
on the value of the metric relative to a given
threshold over a number of time periods.
 The action is a notification sent to an Amazon Simple
Notification Service (Amazon SNS) topic or Auto
Scaling policy.
 Alarm

 Alarms invoke actions for sustained state changes

only. CloudWatch alarms will not invoke actions
simply because they are in a particular state, the
state must have changed and been maintained for a
specified number of periods.
 Alarm actions must reside in the same region as the
alarm. For example, any Amazon SNS message, Auto
Scaling policy, etc. invoked by an alarm must exist in
the same region as the alarm and the resource being
monitored
 Accessing CloudWatch

 Amazon CloudWatch can be accessed via API,

command-line interface, AWS SDKs, and the AWS
Management Console
Identity and Access Management (IAM)
 IAM

 AWS Identity and Access Management is a web

service that enables Amazon Web Services (AWS)
customers to manage users and user permissions in
AWS.
 The service is targeted at organizations with multiple
users or systems that use AWS products such as
Amazon EC2, Amazon RDS, and the AWS
Management Console.
 With IAM, you can centrally manage users, security
credentials such as access keys, and permissions that
control which AWS resources users can access.
 IAM Users

 An IAM user is an entity that you create in AWS that

provides a way to interact with AWS.
 A primary use for IAM users is to give people you
work with identities that they can use to sign in to
the AWS Management Console and to make requests
to AWS services.
 Newly created IAM users have no password and no
access key (access key ID and secret access key).
 IAM Users

 If the user needs to administer your AWS resources

using the AWS Management Console, you can create
a password for the user.
 If the user needs to interact with AWS
programmatically (using the command line interface
(CLI), the AWS SDK, or service-specific APIs), you
can create an access key for that user.
 The credentials you create for users are what they
use to uniquely identify themselves to AWS.
 Multi Factor Authentication (MFA)

 MFA adds extra security by requiring users to enter a

unique authentication code from their
authentication device when accessing AWS websites
or services
 For MFA to work, you must assign an MFA device
(hardware or virtual) to the IAM user account
 IAM Groups

 A group is a collection of IAM users.

 Groups let you specify permissions for a collection of
users, which can make it easier to manage the
permissions for those users.
 For example, you could have a group called Admins
and give that group the types of permissions that
administrators typically need.
 Any user in that group automatically has the
permissions that are assigned to the group.
 IAM Groups

 If a new user joins your organization and should

have administrator privileges, you can assign the
appropriate permissions by adding the user to that
group.
 Similarly, if a person changes jobs in your
organization, instead of editing that user's
permissions, you can remove him or her from the old
group and add him or her to the new group
 Groups: Characteristics

 A group can contain many users, and a user can

belong to multiple groups.
 Groups can't be nested; they can contain only users,
not other groups.
 There's no default group that automatically includes
all users in the AWS account. If you want to have a
group like that, you need to create it and assign each
new user to it.
 There's a limit to the number of groups you can have,
and a limit to how many groups a user can be in
IAM Groups
 IAM Roles

 A role is essentially a set of permissions that grant

access to actions and resources in AWS.
 These permissions are attached to the role, not to an
IAM user or group.
 Roles can be used by an IAM user in the same AWS
account as the role or a different account
 IAM Policy

 You define the permissions for a role in an IAM

policy, which is a JSON document written in the IAM
Policy Language
 Principal
 Principal is an entity in AWS which can perform action and
access resources. A principal can be an AWS account (the
"root" user), an IAM user, group, or role. You can use a policy
to grant permissions to a principal by attaching the policy to
the principal, or by referencing the principal in a policy that is
attached to a resource. If you reference an AWS account, it
generally means any principal defined in that account
 IAM Permission

 Permissions let you specify who has access to AWS

resources, and what actions they can perform on
those resources.
 Every IAM user starts with no permissions. In other
words, by default, users can do nothing, not even
view their own access keys.
 To give a user permission to do something, you can
add the permission to the user (that is, attach a
policy to the user) or add the user to a group that has
the desired permission
 Active Directory Authentication

 You can use AD authentication in IAM with Active

Directory, ADFS and SAML 2.0
 ADFS: Actve Directory Federation Service
 Provide users with single sign-on access to systems and
applications located across organizational boundaries
 SAML: Security Assertion Markup Language
 an XML-based, open-standard data format for exchanging
authentication and authorization data between parties, in
particular, between an identity provider and a service provider
 IAM Lab

HTTPS://RUN.QWIKLABS.COM
INTRODUCTION TO AWS IDENTITY AND
ACCESS MANAGEMENT
Route53
 Route53

 Route 53 is a highly available and scalable cloud

Domain Name System (DNS) web service
 It provides secure and reliable routing to your
infrastructure that uses Amazon Web Services
(AWS) products, such as Amazon Elastic Compute
Cloud (Amazon EC2), Elastic Load Balancing, or
Amazon Simple Storage Service (Amazon S3).
 You can also use Amazon Route 53 to route users to
your infrastructure outside of AWS
 Route53

 Amazon Route 53 is an authoritative DNS service,

meaning it translates friendly domains names like
www.example.com into IP addresses like 192.0.2.1.
 Amazon Route 53 responds to DNS queries using a
global network of authoritative DNS servers, which
reduces latency
 You can manage your DNS records through the
Amazon Route 53 console or the Amazon Route 53
API
 Hosted Zone

 A hosted zone is a collection of resource record sets

hosted by Amazon Route 53.
 Like a traditional DNS zone file, a hosted zone
represents a collection of resource record sets that
are managed together under a single domain name.
 Each hosted zone has its own metadata and
configuration information
 Route53: Supported Records

 A Format - Address record

 AAAA Format – IPv6 Address record
 CNAME Format – Canonical Name Record
 MX Format - Mail exchange record
 NS Format - Name server record
 PTR Format - Pointer record
 SOA Format - Start of authority record
 SPF Format – Sender Protection Framework record
 SRV Format - Service locator
 TXT Format - Text record
 Route53: DNS

 You can use Amazon Route 53 as the DNS service for

any registered domain name.
 You can create new domains that use Amazon
Route 53 as the DNS service, and you can migrate
DNS service for existing domains or subdomains to
Amazon Route 53.
 You can register new domains with Route53
 Migrating Existing Domain

 Create a Amazon Route 53 hosted zone for your

domain
 Get the current DNS configuration from your current
DNS service provider.
 Add resource record sets to your Amazon Route 53
hosted zone.
 Confirm that your changes have propagated to all
Amazon Route 53 DNS servers.
 Update your registrar's name server records.
 Wait for your changes to take effect
 Transferring Domain from other Registrars

 You must have registered the domain with the current

registrar at least 60 days ago.
 If the registration for a domain name expired and had to be
restored, it must have been restored at least 60 days ago.
 You must have transferred registration for the domain to the
current registrar at least 60 days ago.
 The domain cannot have any of the following domain name
status codes:
 pendingDelete
 pendingTransfer
 redemptionPeriod
 clientTransferProhibited
 Health Checks

 Amazon Route 53 lets you configure DNS failover in

active-active, active-passive, and mixed configurations to
improve the availability of your application.
 When you have more than one resource performing the
same function—for example, more than one HTTP server
or mail server—you can configure Amazon Route 53 to
check the health of your resources and respond to DNS
queries using only the healthy resources.
 For example, suppose your website, example.com, is
hosted on 10 servers, two each in five data centers
around the world. You can configure Amazon Route 53 to
check the health of those servers and to respond to DNS
queries for example.com using only the servers that are
currently healthy
 DNS Failover

 Active-active failover: Use this failover configuration when

you want all of your resources to be available the majority of
the time. When a resource becomes unavailable, Amazon
Route 53 can detect that it's unhealthy and stop including it
when responding to queries.
 Active-passive failover: Use this failover configuration
when you want a primary group of resources to be available
the majority of the time and you want a secondary group of
resources to be on standby in case all of the primary resources
become unavailable. When responding to queries, Amazon
Route 53 includes only the healthy primary resources. If all of
the primary resources are unhealthy, Amazon Route 53 begins
to include only the healthy secondary resources in response to
DNS queries.
 Routing Policy

 Simple Routing Policy

 Use a simple routing policy when you have a single resource that
performs a given function for your domain, for example, one web
server that serves content for the example.com website. In this case,
Amazon Route 53 responds to DNS queries based only on the values
in the resource record set, for example, the IP address in an A record.
 Weighted Routing Policy
 Use the weighted routing policy when you have multiple resources
that perform the same function (for example, web servers that serve
the same website) and you want Amazon Route 53 to route traffic to
those resources in proportions that you specify (for example, 40% to
one server and 60% to the other)
 Latency Routing Policy

 Latency Routing Policy

 Use the latency routing policy when you have resources in
multiple Amazon EC2 data centers that perform the same
function and you want Amazon Route 53 to respond to DNS
queries with the resources that provide the best latency. For
example, you might have web servers for example.com in the
Amazon EC2 data centers in Ireland and in Tokyo. When a
user browses to example.com, Amazon Route 53 chooses to
respond to the DNS query based on which data center gives
your user the lowest latency
 Failover Routing Policy

 Failover Routing Policy (Public Hosted Zones

Only)
 Use the failover routing policy when you want to configure
active-passive failover, in which one resource takes all traffic
when it's available and the other resource takes all traffic when
the first resource isn't available. Note that you can't create
failover resource record sets for private hosted zones
 Geolocation Routing Policy

 Geolocation Routing Policy

 Use the geolocation routing policy when you want Amazon
Route 53 to respond to DNS queries based on the location of
your users
 You can specify geographic locations by continent, by country,
or by state in the United States
 Geolocation works by mapping IP addresses to locations
CloudFront
 CloudFront

 CloudFront is a web service that speeds up distribution of

your static and dynamic web content, for example, .html, .css,
.php, and image files, to end users. CloudFront delivers your
content through a worldwide network of data centers called
edge locations.
 When a user requests content that you're serving with
CloudFront, the user is routed to the edge location that
provides the lowest latency (time delay), so content is
delivered with the best possible performance.
 If the content is already in the edge location with the lowest
latency, CloudFront delivers it immediately. If the content is
not currently in that edge location, CloudFront retrieves it
from an Amazon S3 bucket or an HTTP server (for example, a
web server) that you have identified as the source for the
definitive version of your content
 How to configure CloudFront

1. You configure your origin servers, from which

CloudFront gets your files for distribution from
CloudFront edge locations all over the world.
2. An origin server stores the original, definitive version of
your objects. If you're serving content over HTTP, your
origin server is either an Amazon S3 bucket or an HTTP
server, such as a web server. Your HTTP server can be
running on an Amazon Elastic Compute Cloud (Amazon
EC2) instance or on a server that you manage; these
servers are also known as custom origins.
If you're distributing media files on demand using the Adobe Media
Server RTMP protocol, your origin server is always an Amazon S3
bucket.
 How to configure CloudFront

3. You upload your files to your origin servers. Your files, also
known as objects, typically include web pages, images, and
media files, but can be anything that can be served over
HTTP or a supported version of Adobe RTMP, the protocol
used by Adobe Flash Media Server.
If you're using an Amazon S3 bucket as an origin server, you can make the
objects in your bucket publicly readable, so anyone who knows the CloudFront
URLs for your objects can access them.
4. You create a CloudFront distribution, which tells
CloudFront which origin servers to get your files from when
users request the files through your web site or application.
At the same time, you specify details such as whether you
want CloudFront to log all requests and whether you want
the distribution to be enabled as soon as it's created.
 How to configure CloudFront

5. CloudFront sends your distribution's configuration (but not your

content) to all of its edge locations—collections of servers in
geographically dispersed data centers where CloudFront caches
copies of your objects.
As you develop your website or application, you use the domain name that
CloudFront provides for your URLs. For example, if CloudFront returns
d111111abcdef8.cloudfront.net as the domain name for your distribution, the URL for
logo.jpg in your Amazon S3 bucket (or in the root directory on an HTTP server) will be
http://d111111abcdef8.cloudfront.net/logo.jpg.
You can also configure your CloudFront distribution so you can use your own domain
name. In that case, the URL might be http://www.example.com/logo.jpg.
6. Optionally, you can configure your origin server to add headers to
the files; the headers indicate how long you want the files to stay
in the cache in CloudFront edge locations. By default, each object
stays in an edge location for 24 hours before it expires. The
minimum expiration time is 0 seconds; there isn't a maximum
expiration time limit
How CloudFront works
 Serving Private Content

 To securely serve this private content using

CloudFront, you can do the following:
 Require that your users access your private content by using
special CloudFront signed URLs or signed cookies.
 Require that your users access your Amazon S3 content using
CloudFront URLs, not Amazon S3 URLs. Requiring
CloudFront URLs isn't required, but Amazon recommend it to
prevent users from bypassing the restrictions that you specify
in signed URLs or signed cookies
 Serving Private Content

 You can restrict access to objects in

CloudFront edge caches – You can configure
CloudFront to require that users access your objects
using either signed URLs or signed cookies.
 You then develop your application either to create
and distribute signed URLs to authenticated users or
to send Set-Cookie headers that set signed cookies on
the viewers for authenticated users.
 Serving Private Content

 When you create signed URLs or signed cookies to control

access to your objects, you can specify the following
restrictions:
 An ending date and time, after which the URL is no longer
valid.
 (Optional) The date and time that the URL becomes valid.
 (Optional) The IP address or range of addresses of the
computers that can be used to access your content.
 One part of a signed URL or a signed cookie is hashed and
signed using the private key from a public/private key pair.
When someone uses a signed URL or signed cookie to access
an object, CloudFront compares the signed and unsigned
portions of the URL or cookie. If they don't match,
CloudFront doesn't serve the object
 Serving Private Content: S3

 You can restrict access to objects in your

Amazon S3 bucket – You can optionally secure
the content in your Amazon S3 bucket so users can
access it through CloudFront but cannot access it
directly by using Amazon S3 URLs.
 This prevents anyone from bypassing CloudFront
and using the Amazon S3 URL to get content that
you want to restrict access to. This step isn't required
to use signed URLs, but we recommend it.
 Serving Private Content: S3

 To require that users access your content through

CloudFront URLs, you perform the following tasks:
 Create a special CloudFront user called an origin
access identity.
 Give the origin access identity permission to read the
objects in your bucket.
 Remove permission for anyone else to use Amazon
S3 URLs to read the objects
Serving Private Content
 Using an HTTP Server for Private Content

 You can use signed URLs or signed cookies for any

CloudFront distribution, regardless of whether the origin
is an Amazon S3 bucket or an HTTP server.
 However, for CloudFront to get your objects from an
HTTP server, the objects must remain publicly
accessible.
 When the objects are publicly accessible, anyone who has
the URL for an object on your HTTP server can access
the object without logging in or paying for your content.
 If you use signed URLs or signed cookies and your origin
is an HTTP server, do not give the URLs for the objects
on your HTTP server to your customers or to others
outside your organization
 Choosing Between Signed URLs and Signed
Cookies

 Use signed URLs in the following cases:

 You want to use an RTMP distribution. Signed cookies aren't
supported for RTMP distributions.
 You want to restrict access to individual files, for example, an
installation download for your application.
 Your users are using a client (for example, a custom HTTP
client) that doesn't support cookies.
 Use signed cookies in the following cases:
 You want to provide access to multiple restricted files, for
example, all of the files for a video in HLS format or all of the
files in the subscribers' area of a website.
 You don't want to change your current URLs
 Limitations

 If you are not currently using signed URLs and if

your URLs contain any of the following query string
parameters, you cannot use either signed URLs or
signed cookies:
 Expires
 Policy
 Signature
 Key-Pair-Id
 CloudFront assumes that URLs that contain any of
those query string parameters are signed URLs and
therefore won't look at signed cookies
 CloudFront Lab

HTTPS://RUN.QUICKLABS.COM
INTRODUCTION TO AMAZON CLOUDFRONT