Configuration Management & Desired State Automation

Automating application configuration ensures that infrastructure remains consistent, secure, and compliant throughout its lifecycle. This guide focuses on AWS Systems Manager (SSM) State Manager and AWS OpsWorks as primary tools for maintaining a "Desired State."

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between SSM State Manager and SSM Run Command for configuration tasks.
• Design and implement SSM Associations to maintain fleet-wide consistency.
• Explain the architectural components of AWS OpsWorks (Stacks, Layers, Instances).
• Evaluate the use of Chef recipes and Ansible playbooks within AWS automation services.
• Configure automated remediation for configuration drift.

Key Terms & Glossary

• SSM Document: A JSON or YAML file that defines the actions Systems Manager performs on managed instances.
• Association: A State Manager configuration that assigns an SSM Document to specific targets (instances or tags) on a defined schedule.
• Configuration Drift: When the actual state of a server (e.g., installed packages, file permissions) deviates from its intended configuration.
• Idempotency: The property where an operation can be run multiple times without changing the result beyond the initial application (crucial for desired state tools).
• Managed Instance: Any EC2 instance or on-premises server configured for Systems Manager (prefixed with i- or mi-).

The "Big Idea"

The transition from Imperative (manual scripts/commands) to Declarative (desired state) management is the core of DevOps maturity. Instead of asking "How do I install this?", you define "What should be installed?" and let the automation engine (State Manager or OpsWorks) handle the "How" and the "Keep it that way" aspects. This eliminates the "snowflake server" problem where individual instances become unique and difficult to replicate.

Formula / Concept Box

Hierarchical Outline

• I. AWS Systems Manager State Manager
  • A. SSM Documents: Defines the state (e.g., AWS-ApplyAnsiblePlaybooks).
  • B. Targets: Using Tags, Resource Groups, or Manual IDs to define where the state applies.
  • C. Schedule: Cron or Rate expressions (e.g., run every 30 minutes).
  • D. Compliance: Integration with SSM Compliance to report which instances failed to reach the desired state.
• II. AWS OpsWorks
  • A. Stacks: The highest-level container (e.g., "Production App").
  • B. Layers: Component groupings (e.g., Load Balancer, Web Server, Database).
  • C. Lifecycle Events: Setup, Configure, Deploy, Undeploy, Shutdown.
  • D. Chef/Puppet: Uses domain-specific languages (DSL) for granular configuration.

Visual Anchors

State Manager Execution Flow

OpsWorks Architectural Hierarchy

Definition-Example Pairs

• State Manager Association: A binding of a configuration document to a set of targets.
  • Example: Creating an association that runs the AWS-InstallApplication document on all instances tagged Role: WebServer every Sunday at 02:00.
• Lifecycle Event: A hook in OpsWorks that triggers specific code execution during an instance's life.
  • Example: Using the "Configure" event to update the load balancer configuration automatically whenever a new web server instance enters the stack.
• SSM Inventory: A feature that collects metadata about managed instances.
  • Example: Automatically gathering the list of all installed Python packages across 500 instances to check for version vulnerabilities.

Worked Examples

Scenario: Enforcing Security Agent Compliance

Goal: Ensure the "TrendMicro" agent is installed and running on all EC2 instances in the Production VPC, even if a user manually uninstalls it.

1. Create SSM Document: Write a document (or use an existing one) that checks for the service and installs it if missing.
2. Define Targets: Select instances based on the tag Environment: Production.
3. Create Association:
   • Document: Custom-InstallSecurityAgent
   • Schedule: rate(12 hours)
   • Remediation: If the script fails, it reports a non-compliant status in the SSM Console.
4. Verification: Check the SSM Compliance dashboard. Any instance where the agent was uninstalled will show as "Non-compliant" until the next 12-hour cycle runs and fixes it.

Checkpoint Questions

1. What is the main difference between using Run Command and State Manager for installing a patch?
2. In OpsWorks, which lifecycle event is triggered on all instances in a stack when a single instance is started or stopped?
3. How does SSM State Manager handle instances that are powered off during a scheduled association execution?
4. Can State Manager be used for on-premises servers? If so, what is required?

▶Click to see answers

1. Run Command is a one-time execution. State Manager is persistent and will re-apply the patch or configuration on a schedule to prevent drift.
2. The Configure event is sent to all instances to allow them to adjust to the new stack membership.
3. State Manager will apply the association as soon as the instance is powered back on and the SSM Agent checks in (if the schedule was missed).
4. Yes, via SSM Hybrid Activations. You must install the SSM Agent on the on-premises server and register it with AWS.

Muddy Points & Cross-Refs

• State Manager vs. AWS Config: This is a common point of confusion. AWS Config is for auditing and recording resource changes (What happened?). State Manager is for active enforcement of internal OS/software settings (Make it look like this!).
• Chef Versions in OpsWorks: Note that OpsWorks Stacks has specific supported Chef versions. For modern Chef/Puppet, AWS OpsWorks for Chef Automate or Puppet Enterprise (managed versions) are preferred over "Stacks."
• Ansible Integration: While SSM is native, you can run Ansible playbooks via State Manager using the AWS-ApplyAnsiblePlaybooks document.

Comparison Tables