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.
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.