v2.3.0 SQS Least Privilege

Upgrade when time permits.

I have removed sqs:GetQueueAttributes from the error queue policy, in case users consider queue attributes sensitive. Thank you to @fbuchmeier-abi !

Use the new ErrorQueueAdditionalPolicyStatements parameter for desired cross-account access. Customization possibilities...

The ReadMe now references the Cloud Efficiency Hub, a database of community-contributed cost inefficiency reports. Check out this useful resource and add your own contributions...

v2.2.0 Terraform + CloudFormation!

All users should upgrade. ref=v2.2.0 changes/adds a qualifier for variables specific to the //terraform-multi module. The new names of the affected variables are: stay_stopped_rds_stackset_name_suffix and stay_stopped_rds_stackset_params .

The v2.0.0 release added Terraform modules for installation in one region or many and one AWS account or many. Minimum versions are Terraform v1.10 and Terraform AWS provider v6 .

The identifier of the EventBridge rule target no longer varies. In a CloudFormation StackSet, this prevents exceeding the 64-character limit.

General Step Function information has been removed. See Step Functions Are for Kids or the "Comparison" section of the old ReadMe.

Why Terraform?

I have added Terraform wrappers to my main open-source projects in hopes of reaching additional users.

My projects remain CloudFormation-first. CloudFormation offers the right balance for startups, small companies, and individuals.

• No extra software to install
• Comprehensive support (infrastructure-as-code and AWS resources) available as part of the existing AWS Support plan
• A bias toward simplicity and use of AWS idioms
• Easy distribution: new users can download a single template file and create a stack in the AWS Console (with a quick-create button if I were willing to pay other people's S3 charges!)
• Easy installation at scale, across multiple regions and AWS accounts, via CloudFormation StackSets

The single-account //terraform module nevertheless demonstrates a Terraform benefit: data sources allow early verification that a dependency exists.

Keep in mind the need to:

• dedicate a system to running Terraform,
• secure it (unfortunately, Terraform runs with full AWS administrative privileges in the vast majority of installations),
• set up a Terraform backend to store state, and
• update modules, the Terraform AWS provider, and Terraform itself, in lock-step.

The balance between simplicity and complexity is up to you.

My recommendation is to use CloudFormation for AWS resources, placing the priority on the many and close interrelationships between those resources. Use whatever infrastructure-as-code system you like for other kinds of resources, noting that there are fewer and weaker interrelationships between pure AWS resources and others. AWS Systems Manager (SSM) Parameter Store works well for those kinds of external dependencies. I like Alternative Ways to Share Data Between Configurations, which, incidentally, is from HashiCorp's own documentation.

v2.1.0 Terraform + CloudFormation!

All users should upgrade. v2.1.0 adjusts the file path structure, with no other changes. In Terraform, change to ref=v2.1.0 .

The v2.0.0 release added Terraform modules for installation in one region or many and one AWS account or many. Minimum versions are Terraform v1.10 and Terraform AWS provider v6 .

The identifier of the EventBridge rule target no longer varies. In a CloudFormation StackSet, this prevents exceeding the 64-character limit.

General Step Function information has been removed. See Step Functions Are for Kids or the "Comparison" section of the old ReadMe.

Why Terraform?

I have added Terraform wrappers to my main open-source projects in hopes of reaching additional users.

My projects remain CloudFormation-first. CloudFormation offers the right balance for startups, small companies, and individuals.

• No extra software to install
• Comprehensive support (infrastructure-as-code and AWS resources) available as part of the existing AWS Support plan
• A bias toward simplicity and use of AWS idioms
• Easy distribution: new users can download a single template file and create a stack in the AWS Console (with a quick-create button if I were willing to pay other people's S3 charges!)
• Easy installation at scale, across multiple regions and AWS accounts, via CloudFormation StackSets

The single-account //terraform module nevertheless demonstrates a Terraform benefit: data sources allow early verification that a dependency exists.

Keep in mind the need to:

• dedicate a system to running Terraform,
• secure it (unfortunately, Terraform runs with full AWS administrative privileges in the vast majority of installations),
• set up a Terraform backend to store state, and
• update modules, the Terraform AWS provider, and Terraform itself, in lock-step.

The balance between simplicity and complexity is up to you.

My recommendation is to use CloudFormation for AWS resources, placing the priority on the many and close interrelationships between those resources. Use whatever infrastructure-as-code system you like for other kinds of resources, noting that there are fewer and weaker interrelationships between pure AWS resources and others. AWS Systems Manager (SSM) Parameter Store works well for those kinds of external dependencies. I like Alternative Ways to Share Data Between Configurations, which, incidentally, is from HashiCorp's own documentation.

v2.0.0 Terraform + CloudFormation!

All users should upgrade.

This release adds Terraform modules for installation in one region or many and one AWS account or many. Minimum versions are Terraform v1.10 and Terraform AWS provider v6 .

The identifier of the EventBridge rule target no longer varies. In a CloudFormation StackSet, this prevents exceeding the 64-character limit.

General Step Function information has been removed. See Step Functions Are for Kids or the "Comparison" section of the old ReadMe.

Why Terraform?

I have added Terraform wrappers to my main open-source projects in hopes of reaching additional users.

My projects remain CloudFormation-first. CloudFormation offers the right balance for startups, small companies, and individuals.

• No extra software to install
• Comprehensive support (infrastructure-as-code and AWS resources) available as part of the existing AWS Support plan
• A bias toward simplicity and use of AWS idioms
• Easy distribution: new users can download a single template file and create a stack in the AWS Console (with a quick-create button if I were willing to pay other people's S3 charges!)
• Easy installation at scale, across multiple regions and AWS accounts, via CloudFormation StackSets

The single-account //terraform module nevertheless demonstrates a Terraform benefit: data sources allow early verification that a dependency exists.

Keep in mind the need to:

• dedicate a system to running Terraform,
• secure it (unfortunately, Terraform runs with full AWS administrative privileges in the vast majority of installations),
• set up a Terraform backend to store state, and
• update modules, the Terraform AWS provider, and Terraform itself, in lock-step.

The balance between simplicity and complexity is up to you.

My recommendation is to use CloudFormation for AWS resources, placing the priority on the many and close interrelationships between those resources. Use whatever infrastructure-as-code system you like for other kinds of resources, noting that there are fewer and weaker interrelationships between pure AWS resources and others. AWS Systems Manager (SSM) Parameter Store works well for those kinds of external dependencies. I like Alternative Ways to Share Data Between Configurations, which, incidentally, is from HashiCorp's own documentation.

ABAC for function role

Upgrade when time permits.

1. Step-Stay Stopped is no longer experimental!

2. One event rule covers both RDS and Aurora.

3. If you tag an RDS database instance or an Aurora database cluster with StayStopped-Exclude (see ExcludeTagKey in CloudFormation), the Step Function role cannot stop the database — even if the role is misused. For secure attribute-based access control you would have to prevent people and systems from adding, changing and deleting ABAC tags.

   Tags remain completely unnecessary. RDS-EVENT-0154 and RDS-EVENT-0153 are generated for databases that have been stopped for 7 days, not for continuously running databases.

   The new code serves mainly as an example of how to condition IAM policies on resource tags, how to evaluate tags in EventBridge rules, and how to construct policies and event patterns in CloudFormation when tag keys are parameterized.

Semantic strengthening

Upgrade when time permits.

Externally, this release prefixes the CloudWatch log group name with /aws/vendedlogs/states/ and eliminates the random suffix. The prefix is a Step Functions best practice.

Updating your CloudWatch stack will delete the old log. If you need to keep the old log, change Enable to false without replacing the template of your original StepStayStoppedRdsAurora CloudFormation stack. Then, create a StepStayStoppedRdsAurora2 stack from the current template.

Internally, this release improves the representation of an unknown database status, reducing reliance on JSONata's undefined concept and preventing potential future bugs. If you are curious about the pitfalls of undefined, null and three-valued logics, see the description of pull/6.

One less step

Upgrade when time permits.

This release features a simpler Step Function, with one less step.

The Step Function retries after additional unknown RDS and Aurora errors.

I'll be ready to remove the "experimental" label soon!

Wait before 1st stop attempt

Upgrade as soon as possible.

• This release enters the 9-minute wait state before the first attempt to stop a database. In rare cases, RDS sends the forced start event before the database's status has changed from stopped to starting.

  I discovered this scenario during my second weekly end-to-end test of the Step Function solution. It had not occurred in weekly testing of the original Lambda + SQS solution, and is less likely there because of the long-polling delay and the general increase in latency from sending events to SQS first.

• Some state names are shorter.

• Automatically-generated state machine diagrams are horizontal because the vertical ones have become unintelligible.

Security improvements

Upgrade as soon as possible.

Yet another release! I said the Step Function solution was experimental, right?

Assigning a name to the Step Function makes it possible to prevent the use of the function's IAM role with other functions. Doing this internally¹ reduces work for AWS administrators or security teams.

The Step Function will be deleted and re-created, so past runs will be deleted.

---

If you need to retain old data, change Enable to false without replacing the template of your original StepStayStoppedRdsAurora CloudFormation stack. Then, create a StepStayStoppedRdsAurora2 stack from the current template.

Internally, a policy for KMS encryption of Step Function payloads receives an accurate name, and some unusual features of this KMS integration are documented in the CloudFormation template.

¹ If only a Lambda function role could be restricted to a single function, too! lambda:SourceFunctionArn conditions can't go in resource-based policies, such as the trust policy of an IAM role. aws:SourceArn isn't suitable, either. StackOverflow proposes aws:userid on every policy statement, but that's impractical, not to mention opaque.

Cautious bug fix

Upgrade as soon as possible.

This release fixes a subtle bug introduced in v1.1.0. Had the Aurora StopDBCluster or RDS DescribeDBInstances API stopped working while the Step Function was running, stale database status data would have been logged, causing confusion.