Mastering Reusable Infrastructure: Patterns, Governance, and Security in IaC

This study guide focuses on Domain 2 of the AWS Certified DevOps Engineer Professional exam, specifically addressing the implementation of standardized infrastructure patterns, governance, and security through reusable Infrastructure-as-Code (IaC) templates.

Learning Objectives

By the end of this module, you should be able to:

• Design reusable infrastructure patterns using AWS CloudFormation Modules and AWS CDK Constructs.
• Enforce governance and compliance by centralizing approved templates in AWS Service Catalog.
• Integrate security standards (e.g., encryption-at-rest, IAM least privilege) directly into IaC components.
• Scale deployments across multiple accounts and regions using StackSets and Service Catalog Portfolios.

Key Terms & Glossary

• Infrastructure-as-Code (IaC): The process of managing and provisioning computer data centers through machine-readable definition files (YAML/JSON) rather than physical hardware configuration or interactive configuration tools.
• AWS CDK Construct: The basic building block of AWS CDK apps; a construct represents a "cloud component" and encapsulates everything AWS CloudFormation needs to create that component.
• CloudFormation Module: A way to package resource configurations for inclusion across stack templates, acting like a reusable "snippet" or macro.
• Service Catalog Portfolio: A collection of Products (CloudFormation templates) together with configuration information and constraints for governing access.
• Constraint: A rule applied to a Service Catalog product that limits how it can be deployed (e.g., Launch Constraints that specify an IAM role for provisioning).

The "Big Idea"

[!IMPORTANT] The core goal of this domain is creating the "Golden Path." Instead of allowing developers to create resources from scratch (which risks security drift), DevOps engineers provide a library of pre-approved, "secure-by-default" components. This balances developer speed with organizational governance.

Formula / Concept Box

Hierarchical Outline

1. Core Reusability Tools
   • CloudFormation Modules: Encapsulate multiple resources into one block. Example: My::S3::SecureBucket which always includes encryption and public access blocks.
   • AWS CDK (Cloud Development Kit): High-level object-oriented abstraction. Uses Constructs to define patterns (e.g., a "Website" construct that creates an S3 bucket, CloudFront, and Route 53).
2. Governance through Service Catalog
   • Products & Portfolios: Packaging IaC for end-users.
   • Launch Constraints: Allows users to provision resources without needing direct IAM permissions to the underlying services.
   • Template Constraints: Limits parameters (e.g., allowing only t3.micro instance types).
3. Scaling Security Standards
   • AWS Config Rules: Monitoring compliance of the provisioned IaC.
   • StackSets: Deploying security baselines (like IAM roles or GuardDuty) across all accounts in an AWS Organization.

Visual Anchors

Service Catalog Provisioning Workflow

CDK Construct Hierarchy

Definition-Example Pairs

• Pattern Encapsulation: Creating a single reusable unit that contains best practices.
  • Example: A CloudFormation Module named Company::Network::VPC that automatically sets up Private Subnets, NAT Gateways, and Flow Logs without the user needing to define them manually.
• Launch Constraint: An AWS Service Catalog feature that assumes a specific role to provision resources.
  • Example: A developer has no permission to create an RDS database. However, through Service Catalog, they can "Order" a database because Service Catalog uses a pre-defined Launch Role to perform the action on their behalf.

Worked Examples

Problem: Enforcing S3 Bucket Encryption across 50 AWS Accounts

Step 1: Define the Reusable Pattern Create a CloudFormation Module (Organization::S3::EncryptedBucket) that explicitly sets BucketEncryption properties.

Step 2: Distribute via StackSets Use AWS CloudFormation StackSets to deploy an IAM Policy to all accounts that denies any s3:CreateBucket action unless the bucket is created via the approved Module or includes the encryption parameters.

Step 3: Centralize in Service Catalog Add the template to a Service Catalog Portfolio. Share this Portfolio with the AWS Organization. Developers now provision buckets via the "Self-Service" portal, ensuring every bucket is compliant from the start.

Checkpoint Questions

1. What is the main difference between a CloudFormation Module and a CloudFormation StackSet?
2. How does AWS Service Catalog help enforce security standards for users who do not have extensive AWS knowledge?
3. Why would a DevOps team choose AWS CDK over standard CloudFormation for complex infrastructure patterns?
4. Which Service Catalog constraint would you use to ensure a user only deploys a resource into a specific VPC?

Muddy Points & Cross-Refs

• CloudFormation Modules vs. Nested Stacks: Modules are physical code injections into a template at runtime (easier for small snippets). Nested Stacks are separate stacks referenced by a parent (better for hitting the 500-resource limit per stack).
• CDK L1 vs L2 vs L3: L1 are raw CFN resources. L2 include "sane defaults." L3 (Patterns) are multiple resources combined (e.g., ApplicationLoadBalancedFargateService).
• Cross-Ref: See "Domain 6: Security and Compliance" for how AWS Config monitors these resources after deployment to ensure no "Configuration Drift" occurs.

Comparison Tables

Choosing the Right Governance Tool