- In this section, we're gonna look
at the five different categories
of features within SSM, the simple Systems Manager service.
And then we're gonna look at an example
within each of those categories.
And let's start with SSM operations management.
So the features that fall under this category
are the Incident Manager, the SSM Explorer,
OpsCenter which allows you to create
tickets called OpsItems, CloudWatch dashboards,
Trusted Advisor dashboards,
and the Personal Health Dashboard.
And each of these can be used
for slightly different purposes,
but all towards the same goal
of managing operations within the service.
And so let's take a look at the SSM Explorer as an example.
The Explorer shows up as a dashboard,
where you can create and move widgets around
as they make sense for specific dashboards.
And you can see here
that we have a number of different widgets,
like EC2 instances that are managed by us Systems Manager,
we have those same instances organized by AMI,
we have open OpsItems, and then we have items over time.
And so there's different ways of utilizing these dashboards,
including the ability to utilize filters
so you can make your widgets more specific
or more applicable.
There are direct links to service and resource pages,
so that you can pull up all of the other properties
of those resources.
And it also has multiple region and multi account support,
so that you don't need to have a large number of dashboards
that you then have to maintain access to.
Our second category is application management.
And this one only has a small number of features.
We have the Application Manager, AppConfig,
and Parameter Store.
And let's use Parameter Store as our example.
Parameter Store is an offering
that allows you to store arbitrary structured
or unstructured text and make it available
to other resources in AWS.
It is version controlled.
It also supports resource-based policies
for least privilege.
And you can enable encryption to protect your data at rest.
And you can even enforce encryption of data
in transit as well.
And one thing is kind of interesting
about SSM Parameter Store is that you can create
a public parameter that is available for anonymous access
that you could even use for an application to query
to determine whether or not an update
is available for that application.
Our next category is SSM change management.
And this also has kind of a small number of features.
We have the Change Manager, we've got SSM Automation,
we have the Change Calendar,
and we have Maintenance Windows.
And so these are clearly going to be used
in conjunction with other features of SSM,
like Patch Manager that we're gonna talk about
in just a minute.
In terms of Maintenance Windows,
you can define a schedule for tasks
that might be considered to be disruptive.
And then you can issue these tasks using
SSM Run command that we're gonna talk about
in just a moment, SSM Automation workflows,
Lambda functions so you can go completely outside of SSM
or you can trigger an entire step functions
workflow as well.
Our next category is the big one.
This is the one that has a lot of different features,
Node Management.
This is designed around individual OS based resources.
And so the features we have available here
are Fleet Manager, Compliance,
Inventory, Hybrid Activations.
So when we have on-prem resources
that have been connected into Systems Manager,
we have the Session Manager that allows you to connect
to OS based resources without requiring SSH.
We have SSM Run command, State Manager,
Patch Manager, and Distributor.
And each of these fits a slightly different gap
in the management of OS based resources.
But they all have something in common.
All of these require the Systems Manager agent
to be installed on the resource
that you're attempting to manage.
And so an example, within this category is Patch Manager.
And Patch Manager is going to operate
using a specific set of prerequisites.
Now first, you create a patch baseline.
And you can associate this
with one or more operating systems.
And then you create a number of rules
that will determine what types of patches get approved,
and on what schedule.
From there, you create what we call a Patch Group.
And this is simply the value of a Patch Group tag
that is assigned with one or more EC2 instances
or on-prem resources.
And then you actually tag your resources
with a tag named Patch Group with a capital P and capital G.
And then if the value matches
a patch group in Patch Manager,
then you can perform regular tasks
that will run that patch baseline
either to determine what patches are necessary.
Or actually install patches,
which with an optional reboot afterwards.
Now our final category is shared resources.
And for this one, we have SSM documents
that we can use with operations,
automation, and with steps and parameters.
SSM documents is kind of a unique category
that takes up the entirety of this shared resources section.
So let's dig a little bit deeper into SSM documents.
And there are different document types.
The first of these is called a command document.
And this can be used with a number of other features
of systems manager, like Run command,
State Manager or for Maintenance Windows.
We have automation runbooks,
which can be run using the Automation feature,
State Manager or Maintenance Windows.
We have packaged documents which is used for distributor
and that's exactly what it sounds like
the ability to install and maintain individual packages.
We have session documents,
which helped to define and configure the ability to utilize
Session Manager to gain an interactive shell session
with an instance.
We have policy documents,
which are used for State Manager
to help determine if individual resources
are in compliance with that policy.
And we have CloudFormation templates,
which can be applied directly using CloudFormation
with SSM documents.
And finally, we have a document type called
post-incident analysis templates.
And this is used specifically
with the incident manager feature
to help with those root cause analysis and post-mortems.