loading...

AWS – Detecting resource drift from templates with drift detection

It is best practice to manage your AWS environment using CloudFormation for all new resources, and for all subsequent changes to these resources. If you sidestep CloudFormation, and make a manual change to a resource, then the template and the actual resource have drifted. Drift can cause all manner of problems when you go to make changes to the CloudFormation stack in the future.

In this recipe, you will learn about a new feature of CloudFormation—drift detection.

How to do it…

Follow these steps in order to create a DynamoDB table, and then observe the drift after you have used the console to make a manual configuration change to the table:

  1. Paste the following code into a file on your filesystem. Give it a .yaml extension:
AWSTemplateFormatVersion: "2010-09-09"
Resources: 
  SimpleDynamoDBTable: 
    Type: AWS::DynamoDB::Table
    Properties: 
      AttributeDefinitions: 
        - 
          AttributeName: "Id"
          AttributeType: "S"
      KeySchema: 
        - 
          AttributeName: "Id"
          KeyType: "HASH"
      BillingMode: PAY_PER_REQUEST
Outputs:
  TableName:
    Description: Drift Detection Example Table
    Value: !Ref SimpleDynamoDBTable
  1. Go to the CloudFormation console, and click Create stack.
  2. Select  Upload a template to Amazon S3, and choose the file that you just created. Click  Next, and give the stack a name. 
  3. Click  Next, and then  Next on the following screen.
  4. Click  Create.
  5. Once the stack has completed, go to the Outputs tab, and note the name of the table.
  6. Go to the DynamoDb dashboard, and view the tables.
  7. Select the table that you just created:

A DynamoDB table
  1. Now, you are going to introduce drift to your stack, by making a change to the table configuration. Select the Indexes tab.
  2. Create a new index on an attribute called Name:

Create a DynamoDB index via the console
  1. Once the status on the new Global Secondary Index (GSI) is active, go back to the CloudFormation dashboard, and select the stack.
  2. Select Detect drift from the Actions drop-down menu:

Detect drift
  1. You should be able to refresh the page, and see that the stack’s Drift status has changed to DRIFTED
  2. Select View drifts results from the Actions menu in order to see a report that describes the detected drift:

A drifted stack
  1. To demonstrate why the drift is a problem, try to change the billing mode, by updating the stack with the following code, which attempts to add the same index to the table:
AWSTemplateFormatVersion: "2010-09-09"
Resources: 
 SimpleDynamoDBTable: 
 Type: AWS::DynamoDB::Table
 Properties: 
 AttributeDefinitions: 
 - 
 AttributeName: "Id"
 AttributeType: "S"
 - AttributeName: "Name"
 AttributeType: "S"
 KeySchema: 
 - 
 AttributeName: "Id"
 KeyType: "HASH"
 BillingMode: PAY_PER_REQUEST
 GlobalSecondaryIndexes: 
 - 
 IndexName: "Name-index"
 KeySchema: 
 - 
 AttributeName: "Name"
 KeyType: "HASH"
 Projection: 
 ProjectionType: "ALL"
Outputs:
 TableName:
 Description: Drift Detection Example Table
 Value: !Ref SimpleDynamoDBTable
  1. Choose Actions Update Stack.
  2. Select Replace the current template, and upload the new file.
  3. Click Next until you reach the final confirmation screen, and then click Update Stack.
  4. After a few moments, the stack will fail:

A failed stack update
  1. Drift detection will not fix the problem for you. It only points out that there is a problem, and it’s up to you to fix it.
  2. Go back to the DynamoDB console, and delete the index.
  1. Go back to the CloudFormation dashboard, and repeat steps 16-18.
  2. This time, the stack update will succeed, since the table properties match what CloudFormation expects, based on the prior version of the template.

How it works…

CloudFormation does not maintain a two-way connection with underlying resources. When it comes down to it, CloudFormation only concerns itself with the template as it is written. If you make a change to a resource outside of CloudFormation, your next stack update could go badly, since CloudFormation might attempt to re-create a resource that is already there.

The drift detection feature was added in order to make it easier to spot the differences between your template and the actual resources. At this time, there is strictly a visual tool to help you to identify the resources that need to be manually altered back, in order to match the template. Once there is no drift, then you can safely apply the changes in the template in order to reproduce what someone did manually.

But wait. I’m sure that you are wondering, What if I detect drift in a resource that is not easy to roll back, such as a database? Well, that’s why you should try really, really hard never to introduce drift in the first place. CloudFormation may someday support the notion of resource adoption, but for the time being, your only recourse is to roll back, and get things to the way that CloudFormation expects them to be.

There’s more…

There are a few more things to keep in mind regarding drift detection:

  • Unsupported resources and properties
  • Using the CLI

Unsupported resources and properties

Keep in mind that drift detection does not currently support all resources, and, for the resources it does support, not all properties can be successfully identified. If you get in the habit of making all changes via CloudFormation templates, then hopefully you won’t need this feature at all. But, if you do need it, it’s worth taking some time to read up on its limitations.

Using the CLI

Drift detection can, of course, be viewed from the CLI:

Drift detection with the CLI

Use the detect-stack-drift and describe-stack-drift-detection-status commands in order to view the drift status of a stack.

See also

  • Chapter 6, Managing AWS Databases, for more on DynamoDB
  • Chapter 4, AWS Compute, for more on EC2

Comments are closed.

loading...