Increase visibility and governance on cloud with Amazon Web Services Cloud Operations services – Part 1

by Elias Bedmar, Fred Hoskyns, and Ravindra Kori | on

Keywords: Amazon Web Services Systems Manager , Best Practices , Customer Solutions , Management & Governance , Management Tools , Technical How-to , Amazon Quicksight , Amazon Web Services Backup .

Many customers are migrating to Amazon Web Services to leverage cost reduction, boost staff productivity, improve operational resilience, and increase business agility. As they adopt Amazon Web Services, they will leverage multi-account architectures to meet business, governance, security and operational requirements. Operation teams (some of which may be used to on premises) can use this opportunity to improve visibility and governance across their entire estate on Amazon Web Services.

This two part post provides foundational tooling that will help you centralize and automate operations, and improve governance and visibility through Amazon Web Services Cloud Operations services . The patterns described in this blog apply at the Amazon Web Services Organizations organization or Organizational Unit (OU) level and across regions. This makes the solutions scalable and extensible to new member Amazon Web Services accounts. The focus will be on virtual server management tasks, but the patterns can be expanded to other operational tasks. The diagram below illustrates the architecture:

Architecture diagram foundational governance services

Architecture diagram for foundational cross-account governance using Amazon Web Services Organizations, Amazon Web Services Systems Manager, and Amazon Web Services Config.

Prerequisites

  • You have a multi-account architecture in place managed with Amazon Web Services Organizations.
  • Amazon Web Services Organizations trusted access is enabled for Amazon Web Services Config, Amazon Web Services Systems Manager and Amazon Web Services Backup .
  • You are familiar with the use of Amazon Web Services Systems Manager to manage Amazon Elastic Cloud Compute (Amazon EC2) instances and the Amazon Web Services Systems Manager Agent (SSM Agent) .

Solution overview

Centralized Governance and Configuration Management
The following steps are the foundations for your operations and governance at scale, and underpin centralized tooling and automation tasks.

1 – Set up Amazon Web Services Config across all accounts and regions using Amazon Web Services Systems Manager

Amazon Web Services Config allows you to keep track of your Amazon Web Services resources (and any changes to their configuration) at a detailed level. This enables many operations use cases such as resource administration, audit and compliance, configuration management and security analysis. We recommend you enable Amazon Web Services Config recording in all your accounts and regions by following these steps . We recommend you select the entire organization or OU as the target, and all relevant regions to be recorded. The configuration schedule can be set to ‘daily’, so any new accounts or regions added to the organization will be detected and included in the tooling. For the use cases in this post, we only selected EC2 instances and SSM resources to be recorded.

Amazon Web Services Systems Manager Quick Setup – Config Recording configuration deployment across entire organization

2 – Set up an Amazon Web Services Config aggregator at the organization level

An Amazon Web Services Config aggregator is a centralized view of your Amazon Web Services Config information across multiple accounts and regions. You should set this up at the organization level to aggregate the configuration and compliance data from all accounts being recorded by Amazon Web Services Config (which you configured in step 1). This will enable two key operational tools:

a.Centralized resource list: A centralized inventory of all resources across multiple accounts regions, including their configuration data, with search and filtering functions. You can access this inventory in the Aggregated resources page .

Amazon Web Services Config Aggregator showing all EC2 instances across an organization

b.Advanced queries: Amazon Web Services Config Advanced Queries is a feature to query resource information and configuration states. It is a very powerful tool for operations teams, as you can instantly get real-time key information from your entire multi-account multi-region Amazon Web Services estate in a centralized way. It leverages structured query language (SQL) syntax and allows exporting data to CSV. Example queries include: list all running/stopped EC2 instances, list all EC2s with AMI id-12345, list all EBS volumes that are not in use, and list all unencrypted EBS volumes. You can access the advanced queries tool by navigating to Advanced Queries in the Amazon Web Services Config console . Ensure you select the aggregator set up on step 2 as the ‘Query scope’ for your queries. This set-up will be useful for ad-hoc queries but the query syntax will have some limitations due to being a subset of SQL.

AWS Config Advanced Queries - example query run against organization-level aggregator ("Describe all EC2 instances currently running")

Amazon Web Services Config Advanced Queries – example query run against organization-level aggregator (“Describe all EC2 instances currently running”)

3 – Set up Amazon Web Services Config rules across accounts and regions

Amazon Web Services Config rules evaluate the configuration settings of your Amazon Web Services resources periodically against operational and security best practices. Amazon Web Services Config conformance packs are a collection of rules. You should set up conformance pack at the organization level so all new member accounts are automatically included in the evaluation scope. At present, 2 methods are available to deploy a conformance pack at the organization level:

Method Amazon Web Services Service used Technical considerations Implementation
Console

Amazon Web Services Systems Manager

(Quick Setup feature)

-Custom conformance packs are supported (through YAML templates stored in S3).

-Multi-region deployment is supported

Follow these steps to Deploy Amazon Web Services Conformance Packs (Amazon Web Services Systems Manager Quick Setup) .
Amazon Web Services CLI or API Amazon Web Services Config

-Custom conformance packs are supported (through YAML templates stored in S3).

-Multi-region deployment not available (API call is region-specific).

See put-organization-conformance-pack or PutOrganizationConformancePack API.

Note that the API call to deploy rules and conformance packs across accounts is region specific. At the organization level, you need to change the context of your API call to a different region if you want to deploy rules in other regions.

Centralized compliance reporting and remediation: Compliance status against all rules for resources across accounts and regions will be available centrally in the aggregator dashboard (set up in step 2). You can also define remediation actions (manual or automated) for non-compliant rules and conformance packs (out of the scope of this blog). This blog post will focus on just one rule within a custom compliance package (enforcing SSM agent, described in Step 4), but you can increase the number of rules you apply as your Amazon Web Services adoption increases. You can also leverage Amazon Web Services Config Conformance Pack sample templates provided by Amazon Web Services that include operational best practices for standards such as CIS, PCI, CISA, FedRAMP, and HIPAA, as well as workload-specific security requirements such as Amazon Relational Database Service (Amazon RDS) , Amazon Web Services Lambda or various container services.

4 – Enforcing the use of the SSM Agent on all EC2 instances
The SSM Agent is the ‘heartbeat’ of Amazon EC2 instance management and operations at scale. It provides periodic, detailed OS-level information about the instances, and provides the telemetry for many useful node management activities at scale through automation. We highly recommend you follow a managed node approach on Amazon Web Services to maximize control and visibility (i.e. all EC2 instances to be configured with SSM Agent ). You can enforce this across your organization (as explained in step 3) through the Amazon Web Services Config managed rule ec2-instance-managed-by-systems-manager . You can deploy this rule as a standalone rule or within a custom conformance pack. A rule remediation action for non-compliant instances can be added to install or configure the agent. You can view all non-compliant accounts and instances in the Aggregated Rules page .

Centralized view of non-compliant AWS Config rules showing accounts with EC2 instances not managed by SSM Agent cross-region.

Centralized view of non-compliant Amazon Web Services Config rules showing accounts with EC2 instances not managed by SSM Agent cross-region.

Detailed list of individual EC2 instances not managed by SSM Agent.Detailed list of individual EC2 instances not managed by SSM Agent.

Conclusion

In this blog post, we showed you how to prepare your multi-account multi-region Amazon Web Services Organizations for centralized management and visibility at scale using Amazon Web Services Cloud Operations services . We covered the automated enforcement of Amazon Web Services Config recording and Amazon Web Services Config rules and conformance packs for all existing and new accounts, the creation of an Amazon Web Services Config aggregator for a centralized view of resource inventory and configuration conformance, as well as the enforcement of SSM Agent for proper management of all EC2 instances. We encourage you to adopt these foundational patterns to quickly improve visibility and centralize governance of your cloud resources.

In Part 2 of this series, we build on these steps and show how to centrally manage, visualize and report on operational tasks such as patching, mandatory software compliance and backups.

About the authors

Elias Bedmar is a Customer Solutions Manager at Amazon Web Services. He is a technical and business program manager helping customers be successful on Amazon Web Services. He supports large migration and modernization programs, cloud maturity initiatives and adoption of new services. Elias has experience in migration delivery, DevOps engineering and cloud

Ravindra Kori is a Solutions Architect at Amazon Web Services. He has worked with multiple segments of customers from Enterprise, SMB and Startup, where he helped our customers architect their solutions and migrate to Amazon Web Services. He specializes in Cloud Operations and Serverless in Amazon Web Services.

Fred Hoskyns is a Senior Solutions Architect at Amazon Web Services who specializes in helping companies of all sizes translate their business requirements into technical solutions, having spent half a decade in sales roles at Amazon.com and Amazon Web Services. He is passionate about enabling customers to use Amazon Web Services builder tools and Serverless technology to delight their end users.