AWS Configuration Management & Automation

This guide covers the strategic selection and implementation of AWS services to automate infrastructure and application configuration, specifically tailored for the Solutions Architect - Professional (SAP-C02) exam.

Learning Objectives

After studying this guide, you will be able to:

• Differentiate between AWS Systems Manager, AWS OpsWorks, and AWS Config for automation tasks.
• Design a remediation strategy for non-compliant AWS resources.
• Select the appropriate flavor of AWS OpsWorks based on existing CM tools (Chef vs. Puppet).
• Implement Infrastructure as Code (IaC) and Configuration as Code patterns to ensure operational excellence.

Key Terms & Glossary

• Configuration Item (CI): A record of a resource's configuration at a specific point in time, tracked by AWS Config.
• CMDB (Configuration Management Database): A repository that acts as a single source of truth for an organization's IT assets; AWS Config serves this role in AWS.
• Runbook: A predefined set of procedures (often in YAML/JSON) executed by AWS Systems Manager Automation to perform routine tasks.
• Recipe / Module: Code components used by Chef (Recipes) or Puppet (Modules) to define the desired state of a server.
• Drift: When the actual state of a resource deviates from its defined "intended" state (e.g., a manual change to a security group).

The "Big Idea"

In a cloud-native environment, manual configuration is a risk to both security and scalability. The "Big Idea" here is the shift from manual administration to Automated State Management. By using AWS Config to monitor compliance and AWS Systems Manager or OpsWorks to enforce state, you create a self-healing architecture that minimizes human error and ensures that every environment—from Dev to Prod—is identical and secure.

Formula / Concept Box

Hierarchical Outline

1. AWS Config: The Compliance Auditor
   • Managed Rules: Predefined AWS best practices (e.g., s3-bucket-public-read-prohibited).
   • Custom Rules: Built using AWS Lambda or CloudFormation Guard (DSL).
   • Remediation: Triggering SSM Automation Runbooks to fix non-compliant resources.
2. AWS Systems Manager (SSM): The Swiss Army Knife
   • Automation: Low-code workflow execution for common tasks.
   • State Manager: Maintains consistent OS configurations (antivirus, firewall rules).
   • Patch Manager: Automates the lifecycle of OS security updates.
3. AWS OpsWorks: The Managed CM Server
   • OpsWorks for Chef Automate: Managed Chef server with premium features.
   • OpsWorks for Puppet Enterprise: Managed Puppet environment.
   • OpsWorks Stacks (Legacy): Layer-based modeling using Chef Solo recipes.

Visual Anchors

Choosing a Configuration Tool

Automatic Remediation Flow

\begin{tikzpicture}[node distance=2cm, every node/.style={draw, fill=blue!10, text width=2.5cm, align=center, rounded corners}] \node (config) {AWS Config detects non-compliance}; \node (event) [right of=config, xshift=2cm] {Trigger Remediation (SSM Runbook)}; \node (action) [right of=event, xshift=2cm] {Resource Reconfigured to Compliant State};

\end{tikzpicture}

Definition-Example Pairs

• Managed Automation Runbook: A pre-built script by AWS to resolve common issues.
  • Example: Using AWS-TerminateEC2Instance automatically if an instance is found running an unapproved AMI.
• Infrastructure as Code (IaC): Defining infrastructure using configuration files.
  • Example: A CloudFormation template that defines a VPC, three subnets, and an RDS instance with encryption enabled.
• CloudFormation Guard: A policy-as-code tool used to validate templates before deployment.
  • Example: A rule that prevents any CloudFormation template from being deployed if it defines an S3 bucket with PublicRead access.

Worked Examples

Example 1: Remediating S3 Public Access

Scenario: A developer accidentally makes an S3 bucket public.

1. Detection: AWS Config rule s3-bucket-public-read-prohibited marks the resource as Non-compliant.
2. Association: The rule is linked to the AWS-DisableS3BucketPublicReadWrite automation runbook.
3. Execution: AWS Config passes the bucket name to the runbook.
4. Result: The runbook executes the PutPublicAccessBlock API call, and the bucket is secured within seconds.

Example 2: Migrating On-Premises Configuration to AWS

Scenario: An enterprise uses Puppet Enterprise on-premises and wants to maintain their existing modules while moving to AWS.

1. Solution: Use AWS OpsWorks for Puppet Enterprise.
2. Implementation: Use the provided Starter Kit to upload existing Puppet modules.
3. Benefit: AWS manages the Puppet Master server (patching/backups), while the team continues using familiar tools.

Checkpoint Questions

1. Which service should you use to track the historical configuration changes of an EC2 instance's security group?
2. What is the primary difference between OpsWorks for Chef Automate and OpsWorks Stacks?
3. How can you validate a Terraform or Kubernetes configuration file against corporate compliance standards before deployment?
4. Which SSM feature is best suited for ensuring that a specific version of antivirus software is installed on all instances?

[!NOTE] Answers: 1. AWS Config; 2. Chef Automate provides a fully-fledged managed Chef server, while Stacks is a legacy solution using Chef Solo; 3. AWS CloudFormation Guard; 4. SSM State Manager.

Muddy Points & Cross-Refs

• SSM vs. Config: This is often confusing. Remember: AWS Config is for checking/auditing (Is it compliant?), while SSM is for doing/acting (Apply this patch/run this script).
• OpsWorks Stacks Support: Note that OpsWorks Stacks is considered legacy and does not support the very latest OS releases. For modern workloads, prefer Chef Automate or Puppet Enterprise flavors.
• Cross-Ref: For more on security-specific triggers, see the AWS Security Hub documentation regarding "Custom Actions" and Amazon EventBridge integration.

Comparison Tables