Skip to main content

Protect Workload Resources

Stax Workloads supports the use of AWS Stack Policies to give you more control and protection over your Stax Workload CloudFormation resources.

By applying a set of rules to your Workload Manifest, you can prevent the following actions being performed when automated updates are applied to your CloudFormation stacks:

  • Deletion

  • Modification

  • Replacement

This feature can be used to prevent accidental deletion of code, stop the change of values that require the resource to be replaced, and prevent updates that cause interruption to service. To protect Workloads from accidental deletion in the Stax Console or API, see Protecting Stax Workloads.

tip

This feature doesn't affect manual changes, only changes to CloudFormation templates.

Before You Begin​

  • Ensure you are an Admin in your Stax tenancy

  • Ensure you have a Workload Manifest (see Create a Manifest)

Protect Workload Resources​

To add protection rules you must add some additional configuration to your manifest YAML file. This takes the form of the ProtectedResources key within a Resources list item. The ProtectedResources key accepts up to four child keys:

  • Modify

  • Replace

  • Delete

  • All (Modify, Replace, and Delete)

Each key above, if present, contains a list of one or more CloudFormation Resource Logical IDs. You can also use the special identifier "Stack" to apply the given rule to all resources within the CloudFormation stack.

Example​

There are four distinct approaches to protecting resources within a Stax Workloads manifest. You can, of course, combine these approaches within your manifest to apply different protections to some or all resources within a Stack.

Don't Protect Any Resources​

This manifest file has no protection of resources in place. This is the default approach.

Resources:
  - MyCloudFormationStack:
      Type: AWS::Cloudformation
      TemplateURL: s3://example-artifactbucket/cloudformation/stack.yml

Protect Some Resources Against All Actions​

This manifest file protects some resources against All actions. The specified resources cannot be modified, replaced, or deleted.

Resources:
  - MyCloudFormationStack:
      Type: AWS::Cloudformation
      TemplateURL: s3://example-artifactbucket/cloudformation/stack.yml
      ProtectedResources:
        All:
          - MyS3Bucket
          - MySnsTopic

Protect Some Resources Against Different Actions​

This manifest file protects different resources in the stack from having different actions taken upon them by CloudFormation changes. The MyS3Bucket resource in the CloudFormation template cannot be modified, replaced, or deleted. The EC2 instance cannot be replaced or modified, and the SNS topic can be modified or replaced, but not deleted.

Resources:
  - MyCloudFormationStack:
      Type: AWS::Cloudformation
      TemplateURL: s3://example-artifactbucket/cloudformation/stack.yml
      ProtectedResources:
        All:
          - MyS3Bucket
        Modify:
          - MyEc2Instance
        Replace:
          - MyEc2Instance
        Delete:
          - MySnsTopic

Protect All Resources Against All Actions​

This manfiest file uses the special Stack identifier to protect all resources deployed by the stack against modify, replace, and delete actions.

Resources:
  - MyCloudFormationStack:
      Type: AWS::Cloudformation
      TemplateURL: s3://example-artifactbucket/cloudformation/stack.yml
      ProtectedResources:
        All:
          - Stack

Changing a Protected Resource​

If a protected resource needs to be modified, you must first upload a new version of the manifest file to the Workloads Catalog that removes its protected status.

For example, to remove protection from resources in the Protect All Resources Against All Actions example above, you could upload a new version of the manifest file:

Resources:
  - MyCloudFormationStack:
      Type: AWS::Cloudformation
      TemplateURL: s3://example-artifactbucket/cloudformation/stack.yml

This removes the protections from the resources and allows a new version of the manifest file and/or CloudFormation template to make changes to resources that were previously protected.

You should consider re-enabling the protection status of your resources once the change has been made. You can do this by uploading a new manifest version to the Workloads Catalog with protection enabled, or even by re-applying the protection at the same time as making your CloudFormation changes.