AWS Systems Manager

AWS Systems Manager simplifies resource management, ensures compliance, and automates routine tasks, making it easier to manage our whole application infrastructure efficiently and securely.

Use cases

Here are some use cases of the AWS Systems Manager service:

• Secrets management integration: We can securely store and manage sensitive data like passwords and API keys using Systems Manager’s Parameter Store service.

• Get operational insights data: We can gain insights into the operational health of our AWS resources and take proactive actions to maintain performance and availability.

• Hybrid cloud management: We can manage both AWS cloud resources and on-premises servers.

• Automated patch management: We can automate the patching process of servers for both Windows and Linux. AWS Systems Manager helps to define patch baselines, schedule patching windows, and ensure compliance with organizational patch standards.

• Automatically resolve application issues: AWS Systems Manager can be configured to automatically respond to certain application issues.

• Remediate security events: We can use AWS Systems Manager for the purpose of security and compliance management. In the event of a security incident, the AWS Systems Manager service can help in quick remediation. This could involve applying patches, updating security groups, or isolating affected instances.

Systems Manager services

AWS Systems Manager is an expansive service that offers a plethora of sub-services for the purpose of managing our cloud systems. We can divide the AWS Systems Manager services into four distinct categories, as seen in the diagram below:

Here’s a brief description of each of the AWS Systems Manager services:

• Operations management: These services are focused on allowing us to oversee and optimize the day-to-day operations of AWS resources. These services are primarily used for monitoring, incident management, and collecting operational data.

  • SSM OpsCenter: The SSM OpsCenter service offers a centralized management interface that allows us to view, investigate, and resolve operational issues of our AWS resources. These operational issues are collected as OpsItems, which include relevant data like resource ID, name, and issue details.

  • SSM Explorer: The SSM Explorer service is essentially a dashboard that provides a consolidated view of the operational data collected from our AWS services. As we can aggregate operational data for a better analysis, we can gain crucial insights into the operations across AWS accounts and regions.

  • SSM Incident Manager: The SSM Incident Manager service allows us to define, prepare for, and manage incidents affecting our AWS-hosted applications. It helps in response planning, incident tracking, and post-incident analysis.

• Application management: These services are focused on managing and deploying applications, including their configurations, dependencies, and performance.

  • SSM Application Manager: The SSM Application Manager service offers a centralized management interface for our applications that helps understand application dependencies, resources, and performance.

  • SSM AppConfig: The SSM AppConfig service allows us to manage and deploy application configurations and feature flags independently of the application code, enabling safer, faster deployment and updates.

  • SSM Parameter Store: The SSM Parameter Store service allows us to securely manage configuration data, such as passwords, database strings, and license codes. It provides a centralized store to manage our application configuration and secrets. We can version track our configuration and secret changes.

• Change management: These services are focused on managing and automating changes to our AWS cloud environment, allowing us to execute changes in a controlled and compliant manner.

  • SSM Automation: The SSM Automation service allows us to automate common and repetitive IT operations and maintenance tasks, reducing manual efforts and the possibility of human error. We can integrate it with AWS Config to automatically perform remediation actions when AWS Config triggers it.

  • SSM Change Manager: The SSM Change Manager service makes updating deployed workflows and approvals for our managed instances easier. This ensures changes are made safely and efficiently, in compliance with our organization’s policies.

  • SSM Maintenance Windows: The SSM Maintenance Windows service allows us to define specific time frames to run administrative and maintenance tasks across a fleet of instances. This allows us to minimize the impact on the business operations themselves.

• Node management: These services are focused on managing and maintaining individual server and instance nodes.

  • SSM Fleet Manager: The SSM Fleet Manager service offers an AWS Management Console dashboard that allows us to easily manage servers without needing to remotely log into each one, improving server operations in the process.

  • SSM Session Manager: The SSM Session Manager service provides secure and auditable instance management without opening inbound ports or maintaining bastion hosts, enabling us to access our instances securely.

  • SSM Patch Manager: The SSM Patch Manager service automates the process of patching managed instances with security and other updates, keeping our instances up-to-date and secure.

How SSM Parameter Store works

Now that we’ve explored the Systems Manager as a whole and briefly went over all the services it encompasses, let’s now explore how the most important of these services, the SSM Parameter Store, works.

The SSM Parameter Store service is a hierarchical storage to manage credentials, configurations, and sensitive information in the form of parameters. These parameters can later be used in an application. Here’s how the SSM Parameter Store service works:

• We create and set up parameters on the SSM Parameter Store, with values either as unencrypted plaintext or KMS-encrypted ciphertext.

• We use SSM Parameter Store to fetch the credentials stored in parameters for an application from services like CloudFormation and EC2 instead of storing the credentials directly in the application code or CloudFormation template.

• We reference these parameters using the unique name assigned to them.

• When a request to receive a parameter is made to the Parameter Store service, it checks if the requesting resource’s role has the necessary IAM permissions in the attached policy to access the parameter value.

• We can set up different hierarchies of the parameters we’re storing, making it easier to separate and limit access of different departments and teams to only the relevant credentials.

• To further customize the parameters in the SSM Parameter Store, we can set up parameter policies in its advanced settings. These policies allow us to set up an expiration date, after which certain actions will occur based on the policy type. Parameter policies are of the following types:

  • Expiration: This policy will have the parameter deleted after the expiration date.

  • ExpirationNotification: This policy will have an EventBridge expiration notification sent a little before the expiration date before the parameter deletion.

  • NoChangeNotification: This policy will have an EventBridge notification to update the parameter if it has not been updated for a specific period.

Example: Storing access credentials as cyphertext

Here’s an example illustration of an SSM Parameter Store that stores access credentials as cyphertext for an RDS database. The EC2 instance retrieves these access credentials from the SSM Parameter Store to access the database. The SSM Parameter Store verifies if the EC2 instance can access the SSM Parameter Store using the Instance Profile (IAM Role).

This lesson taught us about the AWS Systems Manager service and how it helps us manage the system operations of our AWS resources and applications. We also learned about SSM Parameter Store, SSM Session Manager, and other Systems Manager services.