How to track configuration changes to CloudFormation stacks using AWS Config

Recently, AWS Config announced support for AWS CloudFormation stacks. You can now start tracking the current and historical configuration of your CloudFormation stacks, and get notified via Amazon SNS when your stack configuration changes. You can also use a managed AWS Config rule to check whether your CloudFormation stacks are sending event notifications to an SNS topic.

Tracking configuration changes to a CloudFormation stack is valuable from a governance perspective. It tells you how and when a stack got modified. Use this information to troubleshoot operational issues and outages, and maintain audit compliance.

In this post, I describe two possible use cases, tracking stack changes and evaluating compliance, and walk you through each scenario.

AWS services

AWS Config enables you to assess, audit, and evaluate the configurations of your AWS resources. It continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. With AWS Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines.

CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion. CloudFormation standardizes the manner in which resources get deployed into your environments and simplifies the management of cloud resources. You can create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You can deploy and update a template and its associated collection of resources (called a stack) by using the AWS Management Console, AWS CLI, or APIs.

Example: Track stack configuration changes

When you create a stack, all update actions are allowed on all resources. By default, anyone with stack update permissions can update all of the resources in the stack.

With a stack policy, you can prevent stack resources from being unintentionally updated or deleted during a stack update. A stack policy is a JSON document that defines the update actions that can be performed on designated resources. Use a stack policy only as a fail-safe mechanism to prevent accidental updates to specific stack resources.

Consider a scenario where Bob, a cloud administrator, provisions a stack that creates a secure VPC for a public-facing application that includes subnets, NAT gateways, route tables, and custom network ACL rules. The security of this stack and its underlying resources is critical since it contains the essential building blocks for creating applications and any changes to this VPC, subnets, route tables etc. could potentially impact all applications hosted within that VPC. Hence, in order to prevent changes to this stack, Bob applies a “deny all” stack policy that disallows updates to all resources in the stack.

Adam, an application developer with stack update permissions attempts to modify the stack. He realizes that the stack cannot be updated due to the “deny all” stack policy, so he attaches a new stack policy (“allow all”) that allows updates to all resources in the stack.

You can capture these changes via AWS Config and use them to alert Bob, the cloud administrator. Download the CloudFormation template VPC-Production for this example. This template configures a secure VPC for a public-facing application that includes subnets, NAT gateways, route tables, and custom network ACL rules. The example uses the AWS Management Console, but you can use the AWS CLI or SDKs as well.

In the CloudFormation console, you can see what resources were configured when the stack was launched.

The following stack policy was attached at launch time. This policy denies updates to all resources in this stack.

{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}

Now, Adam, the application developer with stack update permissions, wants to modify the management subnet IP address range “pManagement CIDR”. After realizing that the stack has a “deny all” stack policy, he updates the stack policy via CLI as shown below:

This policy basically allows all updates to stack resources:

{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}

He then updates the stack to change the management subnet IP address range.

Check how AWS Config tracked these modifications. First, log in to the AWS Config console. Choose Resources. For Resources, choose CloudFormation: Stack. To see the list of all CloudFormation stacks being recorded in Config, choose Look up.

In this example, open the CloudFormation stack named myProdVPC to view its Config timeline. The following screenshot shows the timeline and configuration details.

At the top, you see a timeline of all changes that have occurred to the stack after creation.

You can see the configuration of the stack under Configuration Details. This includes the Amazon resource name (ARN), resource ID, rollback settings, and creation time.

In this scenario, there were 8 changes on July 10th. You can drill down further to see what those changes were. The stack policy was modified to allow updates to all resources, and then an EC2 network ACL entry was modified. Specifically, the “pManagement CIDR” block was modified from 10.100.10.0/24 to 10.100.96.0/21.

AWS Config also sends an SNS notification each time a configuration change is detected, so that you can be alerted of changes to your CloudFormation stacks.

In addition to reviewing these configuration changes, you can also see the entire list of resources within the stack. View Relationships for resource types supported in AWS Config, and view Unsupported Resources for resource types not currently supported in AWS Config.

You can also view the configuration history of resources currently supported in AWS Config, if you choose to investigate further.

Example: AWS Config rules

In addition to tracking the configuration of your CloudFormation stacks, you can use AWS Config rules to check your stacks against best practice rules and internal policies.

For example, use the prebuilt rules called cloudformation-stack-notification-check to verify whether your CloudFormation stacks are sending event notifications to an SNS topic at all times. The following example shows compliant and noncompliant configuration states.

cloudformation-stack-notification-check

The CloudFormation stack that you created earlier is showing as noncompliant with this rule, as it does not have any SNS topic configured.

After adding a notification topic to the stack in the CloudFormation console, you can see that the compliance status changes to the compliant state.

Summary

With support for CloudFormation stacks in AWS Config, you can now continuously track configuration changes to all stacks, including stack policies and parameter changes. You can use AWS Config rules to verify configuration best practices and compliance with internal policies.

About the Authors

Sid Gupta is a Sr. Product Manager for AWS Config. AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Sid enjoys working with customers and help them implement cloud security best practices. In his spare time, he enjoys hiking, reading and spending time with his kids.

Shashi Prabhakar is a Solutions Architect at AWS. He loves working with customers to help design, architect and build variety of workloads. Shashi always gets excited to learn new Technologies and Businesses while working with customers. When not learning, he likes to run, play tennis, travel, spend time with wife and enjoy life.