AWS Configuration Management: Choosing the Right Service

This guide explores the critical AWS services used to manage, track, and automate configuration across cloud environments. Mastering the selection of these services is essential for the AWS Certified DevOps Engineer - Professional exam.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between AWS Systems Manager (SSM), AWS Config, AWS AppConfig, and AWS OpsWorks.
• Determine the optimal service for patching, compliance monitoring, and application configuration deployment.
• Explain how to remediate non-compliant resources using automated workflows.
• Apply the correct service to maintain a "desired state" for EC2 fleets and on-premises servers.

Key Terms & Glossary

• Managed Instance: Any EC2 instance or on-premises server that has the SSM Agent installed and is authorized to communicate with AWS Systems Manager.
• Configuration Item (CI): A record of the configuration of a specific AWS resource at a point in time, managed by AWS Config.
• State Manager: A component of Systems Manager that automates the process of keeping managed instances in a defined state (e.g., ensuring a specific agent is always running).
• Feature Flag: A technique in AWS AppConfig that allows you to turn features on or off in an application without redeploying code.
• Remediation Action: An automated step (usually an SSM Document or Lambda function) triggered by AWS Config when a resource is found to be non-compliant.

The "Big Idea"

In a DevOps culture, infrastructure and applications are dynamic. Configuration Management is the "sanity check" for this dynamism. While Infrastructure as Code (IaC) like CloudFormation sets the initial stage, configuration management services ensure that once the stage is set, it doesn't "drift" into an insecure or broken state. It provides the mechanism to update software, patch vulnerabilities, and audit changes across thousands of resources simultaneously.

Formula / Concept Box

Hierarchical Outline

• I. AWS Systems Manager (SSM) - Operational Hub
  • Patch Manager: Automated OS patching based on "Patch Baselines."
  • State Manager: Maintains instances in a "desired state" (e.g., specific software versions).
  • Run Command: Execute scripts/commands across fleets without SSH/RDP keys.
  • Inventory: Collects metadata about software, drivers, and configurations on instances.
  • Session Manager: Secure, logged browser-based shell access.
• II. AWS Config - Compliance & Governance
  • Config Rules: Managed or custom rules to evaluate resource settings (e.g., "Is S3 public?").
  • Aggregators: Collect compliance data from multiple accounts and regions into one view.
  • Conformance Packs: Collections of rules and remediation actions for specific compliance standards (e.g., PCI-DSS).
• III. AWS AppConfig - Application Agility
  • Configuration Profiles: Store app settings in SSM Parameter Store, S3, or AppConfig itself.
  • Deployment Strategies: Control the rollout speed and rollback criteria for configuration changes.
• IV. AWS OpsWorks - Traditional Configuration
  • OpsWorks for Chef Automate: Fully managed Chef server.
  • OpsWorks for Puppet Enterprise: Fully managed Puppet server.

Visual Anchors

Service Selection Flow

AWS Config Lifecycle

Definition-Example Pairs

• Remediation Action: The process of fixing a non-compliant resource automatically.
  • Example: An AWS Config rule detects an unencrypted S3 bucket and automatically triggers an SSM Document to enable AES-256 encryption.
• Patch Baseline: A set of rules that define which patches are approved for installation on your instances.
  • Example: A baseline that automatically approves all "Security" patches for Ubuntu with a 7-day delay to allow for testing.
• Managed Node: Any machine configured for use with Systems Manager.
  • Example: An on-premises Raspberry Pi running the SSM Agent, appearing in the AWS Console alongside EC2 instances.

Worked Examples

Example 1: Rolling out a Feature Flag

Scenario: You want to enable a new "Beta Dashboard" for only 10% of your users.

1. Store: Create a configuration profile in AWS AppConfig.
2. Define: Set a JSON flag {"beta_dashboard": true}.
3. Deploy: Start a deployment with a "Linear" strategy (e.g., 10% growth every 5 minutes).
4. Monitor: CloudWatch Alarms watch for 5xx errors; if errors spike, AppConfig automatically rolls back to the false state.

Example 2: Inventory and Patching

Scenario: A new critical vulnerability (CVE) is released for Linux.

1. Identify: Use SSM Inventory to query the fleet and find all instances running the vulnerable kernel version.
2. Execute: Use SSM Run Command with the AWS-RunShellScript document to run a yum update on only those specific instances.
3. Verify: Check the Compliance dashboard in SSM to ensure the "Patch Compliance" status is now green.

Checkpoint Questions

1. Which service should you use if you need to maintain a history of how a Security Group's rules have changed over the last 6 months?
2. What is the primary difference between SSM State Manager and SSM Run Command?
3. You need to store sensitive database credentials and rotate them. Should you use AppConfig or Secrets Manager? (Hint: AppConfig is for configuration, Secrets Manager is for secrets).
4. Can AWS Systems Manager manage servers located in a private data center? If so, what is required?

Muddy Points & Cross-Refs

• Config vs. SSM State Manager: This is a common confusion. AWS Config is usually for AWS Resource settings (S3 buckets, IAM roles) and auditing. SSM State Manager is for Internal OS settings (Registry keys, specific files, installed software).
• OpsWorks vs. SSM: If you already have a heavy investment in Chef recipes or Puppet manifests, use OpsWorks. If you are starting fresh or prefer Python/YAML/Shell, use SSM.
• AppConfig vs. Parameter Store: AppConfig uses Parameter Store as a source, but AppConfig adds deployment logic (rollbacks, gradual rollouts) which Parameter Store lacks.

Comparison Tables