New for AWS CloudFormation – Quickly Retry Stack Operations from the Point of Failure

One of many nice benefits of cloud computing is that you’ve entry to programmable infrastructure. This lets you handle your infrastructure as code and apply the identical practices of utility code growth to infrastructure provisioning.

AWS CloudFormation offers you a simple approach to mannequin a set of associated AWS and third-party assets, provision them shortly and persistently, and handle them all through their lifecycles. A CloudFormation template describes your required assets and their dependencies so you possibly can launch and configure them collectively as a stack. You should use a template to create, replace, and delete a complete stack as a single unit as a substitute of managing assets individually.

Once you create or replace a stack, your motion may fail for various causes. For instance, there could be errors within the template, within the parameters of the template, or points outdoors the template, reminiscent of AWS Identification and Entry Administration (IAM) permission errors. When such an error happens, CloudFormation rolls again the stack to the earlier steady situation. For a stack creation, which means deleting all assets created as much as the purpose of the error. For a stack replace, it means restoring the earlier configuration.

This rollback to the earlier state is nice for manufacturing environments, however doesn’t make it straightforward to know the explanation for the error. Relying on the complexity of your template and the variety of assets concerned, you may spend a number of time ready for all of the assets to roll again earlier than you possibly can replace the template with the suitable configuration and retry the operation.

At the moment, I’m completely satisfied to share that now CloudFormation lets you disable the automated rollback, hold the assets efficiently created or up to date earlier than the error happens, and retry stack operations from the purpose of failure. On this means, you possibly can shortly iterate to repair and remediate errors and drastically cut back the time required to check a CloudFormation template in a growth atmosphere. You may apply this new functionality while you create a stack, while you replace a stack, and while you execute a change set. Let’s see how this works in observe.

Shortly Iterate to Repair and Remediate a CloudFormation Stack
For one among my purposes, I must arrange an Amazon Easy Storage Service (Amazon S3) bucket, an Amazon Easy Queue Service (SQS) queue, and an Amazon DynamoDB desk that’s streaming item-level modifications to an Amazon Kinesis knowledge stream. For this setup, I write down the primary model of the CloudFormation template.

AWSTemplateFormatVersion: "2010-09-09"
Description: A pattern template to repair & remediate
Parameters:
  ShardCountParameter:
    Sort: Quantity
    Description: The variety of shards for the Kinesis stream
Assets:
  MyBucket:
    Sort: AWS::S3::Bucket
  MyQueue:
    Sort: AWS::SQS::Queue
  MyStream:
    Sort: AWS::Kinesis::Stream
    Properties:
      ShardCount: !Ref ShardCountParameter
  MyTable:
    Sort: AWS::DynamoDB::Desk
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: "ArtistId"
          AttributeType: "S"
        - AttributeName: "Live performance"
          AttributeType: "S"
        - AttributeName: "TicketSales"
          AttributeType: "S"
      KeySchema:
        - AttributeName: "ArtistId"
          KeyType: "HASH"
        - AttributeName: "Live performance"
          KeyType: "RANGE"
      KinesisStreamSpecification:
        StreamArn: !GetAtt MyStream.Arn
Outputs:
  BucketName:
    Worth: !Ref MyBucket
    Description: The identify of my S3 bucket
  QueueName:
    Worth: !GetAtt MyQueue.QueueName
    Description: The identify of my SQS queue
  StreamName:
    Worth: !Ref MyStream
    Description: The identify of my Kinesis stream
  TableName:
    Worth: !Ref MyTable
    Description: The identify of my DynamoDB desk

Now, I wish to create a stack from this template. On the CloudFormation console, I select Create stack. Then, I add the template file and select Subsequent.

I enter a reputation for the stack. Then, I fill the stack parameters. My template file has one parameter (ShardCountParameter) used to configure the variety of shards for the Kinesis knowledge stream. I do know that the variety of shards must be better or equal to at least one, however by mistake, I enter zero and select Subsequent.

To create, modify, or delete assets within the stack, I exploit an IAM position. On this means, I’ve a transparent boundary for the permissions that CloudFormation can use for stack operations. Additionally, I can use the identical position to automate the deployment of the stack later in a standardized and reproducible atmosphere.

In Permissions, I choose the IAM position to make use of for the stack operations.

Now it’s time to make use of the brand new function! Within the Stack failure choices, I choose Protect efficiently provisioned assets to maintain, in case of errors, the assets which have already been created. Failed assets are all the time rolled again to the final identified steady state.

I go away all different choices at their defaults and select Subsequent. Then, I evaluate my configurations and select Create stack.

The creation of the stack is in progress for a couple of seconds, after which it fails due to an error. Within the Occasions tab, I take a look at the timeline of the occasions. The beginning of the creation of the stack is on the backside. The latest occasion is on the high. Properties validation for the stream useful resource failed as a result of the variety of shards (ShardCount) is beneath the minimal. Because of this, the stack is now within the CREATE_FAILED standing.

As a result of I selected to protect the provisioned assets, all assets created earlier than the error are nonetheless there. Within the Assets tab, the S3 bucket and the SQS queue are within the CREATE_COMPLETE standing, whereas the Kinesis knowledge stream is within the CREATE_FAILED standing. The creation of the DynamoDB desk will depend on the Kinesis knowledge stream to be out there as a result of the desk makes use of the information stream in one among its properties (KinesisStreamSpecification). As a consequence of that, the desk creation has not began but, and the desk isn’t within the checklist.

The rollback is now paused, and I’ve a couple of new choices:

Retry – To retry the stack operation with none change. This selection is beneficial if a useful resource did not provision as a result of a difficulty outdoors the template. I can repair the problem after which retry from the purpose of failure.

Replace – To replace the template or the parameters earlier than retrying the stack creation. The stack replace begins from the place the final operation was interrupted by an error.

Rollback – To roll again to the final identified steady state. That is much like default CloudFormation habits.

Fixing Points within the Parameters
I shortly notice the error I made whereas getting into the parameter for the variety of shards, so I select Replace.

I don’t want to alter the template to repair this error. In Parameters, I repair the earlier error and enter the right amount for the variety of shards: one shard.

I go away all different choices at their present values and select Subsequent.

In Change set preview, I see that the replace will attempt to modify the Kinesis stream (at the moment within the CREATE_FAILED standing) and add the DynamoDB desk. I evaluate the opposite configurations and select Replace stack.

Now the replace is in progress. Did I resolve all the problems? Not but. After a while, the replace fails.

Fixing Points Exterior the Template
The Kinesis stream has been created, however the IAM position assumed by CloudFormation doesn’t have permissions to create the DynamoDB desk.

Within the IAM console, I add extra permissions to the position utilized by the stack operations to have the ability to create the DynamoDB desk.

Again to the CloudFormation console, I select the Retry choice. With the brand new permissions, the creation of the DynamoDB desk begins, however after a while, there may be one other error.

Fixing Points within the Template
This time there may be an error in my template the place I outline the DynamoDB desk. Within the AttributeDefinitions part, there may be an attribute (TicketSales) that’s not used within the schema.

With DynamoDB, attributes outlined within the template must be used both for the first key or for an index. I replace the template and take away the TicketSales attribute definition.

As a result of I’m enhancing the template, I take the chance to additionally add MinValue and MaxValue properties to the variety of shards parameter (ShardCountParameter). On this means, CloudFormation can test that the worth is within the appropriate vary earlier than beginning the deployment, and I can keep away from additional errors.

I choose the Replace choice. I select to replace the present template, and I add the brand new template file. I verify the present values for the parameters. Then, I go away all different choices to their present values and select Replace stack.

This time, the creation of the stack is profitable, and the standing is UPDATE_COMPLETE. I can see all assets within the Assets tab and their description (primarily based on the Outputs part of the template) within the Outputs tab.

Right here’s the ultimate model of the template:

AWSTemplateFormatVersion: "2010-09-09"
Description: A pattern template to repair & remediate
Parameters:
  ShardCountParameter:
    Sort: Quantity
    MinValue: 1
    MaxValue: 10
    Description: The variety of shards for the Kinesis stream
Assets:
  MyBucket:
    Sort: AWS::S3::Bucket
  MyQueue:
    Sort: AWS::SQS::Queue
  MyStream:
    Sort: AWS::Kinesis::Stream
    Properties:
      ShardCount: !Ref ShardCountParameter
  MyTable:
    Sort: AWS::DynamoDB::Desk
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: "ArtistId"
          AttributeType: "S"
        - AttributeName: "Live performance"
          AttributeType: "S"
      KeySchema:
        - AttributeName: "ArtistId"
          KeyType: "HASH"
        - AttributeName: "Live performance"
          KeyType: "RANGE"
      KinesisStreamSpecification:
        StreamArn: !GetAtt MyStream.Arn
Outputs:
  BucketName:
    Worth: !Ref MyBucket
    Description: The identify of my S3 bucket
  QueueName:
    Worth: !GetAtt MyQueue.QueueName
    Description: The identify of my SQS queue
  StreamName:
    Worth: !Ref MyStream
    Description: The identify of my Kinesis stream
  TableName:
    Worth: !Ref MyTable
    Description: The identify of my DynamoDB desk

This was a easy instance, however the brand new functionality to retry stack operations from the purpose of failure already saved me a number of time. It allowed me to repair and remediate points shortly, lowering the suggestions loop and rising the variety of iterations that I can do in the identical period of time. Along with utilizing this for debugging, it’s also nice for incremental interactive growth of templates. With extra subtle purposes, the time saved will likely be enormous!

Repair and Remediate a CloudFormation Stack Utilizing the AWS CLI
I can protect efficiently provisioned assets with the AWS Command Line Interface (CLI) by specifying the --disable-rollback choice once I create a stack, replace a stack, or execute a change set. For instance:

aws cloudformation create-stack --stack-name my-stack 
    --template-body file://my-template.yaml -–disable-rollback
aws cloudformation update-stack --stack-name my-stack 
    --template-body file://my-template.yaml --disable-rollback
aws cloudformation execute-change-set --stack-name my-stack --change-set-name my-change-set 
    --template-body file://my-template.yaml --disable-rollback

For an current stack, I can see if the DisableRollback property is enabled with the describe stack command:

aws cloudformation describe-stacks --stack-name my-stack

I can now replace stacks within the CREATE_FAILED or UPDATE_FAILED standing. To manually roll again a stack that’s within the CREATE_FAILED or UPDATE_FAILED standing, I can use the brand new rollback stack command:

aws cloudformation rollback-stack --stack-name my-stack

Availability and Pricing
The potential for AWS CloudFormation to retry stack operations from the purpose of failure is on the market at no extra cost within the following AWS Areas: US East (N. Virginia, Ohio), US West (Oregon, N. California), AWS GovCloud (US-East, US-West), Canada (Central), Europe (Frankfurt, Eire, London, Milan, Paris, Stockholm), Asia Pacific (Hong Kong, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Center East (Bahrain), Africa (Cape City), and South America (São Paulo).

Do you like to outline your cloud utility assets utilizing acquainted programming languages reminiscent of JavaScript, TypeScript, Python, Java, C#, and Go? Excellent news! The AWS Cloud Growth Equipment (AWS CDK) staff is planning so as to add help for the brand new capabilities described on this put up within the subsequent couple of weeks.

Spend much less time to repair and remediate your CloudFormation stacks with the brand new functionality to retry stack operations from the purpose of failure.

— Danilo