UPDATE 2023-05-02: The repository I created for this is archived, but others are free to fork and maintain a version if they’d like. I haven’t used CloudFormation for a long time now, and this repository was for the most part automatically able to just run by itself up until recently. It may still be able to continue running automatically if spun-up, as-is, with tokens that had the proper permissions to open PRs and automatically merge them. The Python code is rather gnarly, as it was one of those things that went from a script I just wrote to help make insight more convenient for feedback to people at AWS, along with auto-generative code and detailed help documentation for modules meant to assist with CloudFormation template creation. With that being said, it may be difficult to extend due to how it was created.

NOTE: Would you like to take a look at a human-readable changelog of AWS CloudFormation resource offerings? Take a look here: aws-cfn-resource-specs/CHANGELOG.md. The origins around that repo are detailed in another blog post, AWS CloudFormation Resource Specification Auditor.

The Quick Summary

It is a result of updates AWS does to their AWS CloudFormation Resource Specification files. The repository audits AWS CloudFormation schema daily to see:

  • What AWS services are supported by CloudFormation
  • What services are supported in what regions in CloudFormation
  • What resources have since been renamed or removed after their initial release; the changelogs currently reference a type as removed only, as it is difficult to know when a removal was actually a renaming
  • What documentation links are broken within the CFN Resource Spec files provided by AWS
  • What resources, if any, are mentioned in other specification files outside of us-east-1. Certain tools have been dependent on the us-east-1 spec file as the master source file, though my tooling has discovered errors where certain supported resources were not included (when they were supported)

Both machine-readable and human-readable changelogs are generated after a new specification version is released by the AWS CloudFormation team.

More Detailed: Release History of AWS CloudFormation

When it comes to a centralized changelog of what AWS services are supported by AWS CloudFormation, and in what regions, the official documentation is lacking.

Right now, one can take a look at the AWS CloudFormation User Guide Release History page for a description of new and updated resources. That, and keep an eye out for updates dropped in AWS blog posts.

What’s missing from that release history?

  • Information about what regions are supporting each new resource
  • What regions newly support existing resources
  • What resources have since been renamed or removed
  • The version number of an associated CloudFormation resource specification

Example Release

The official release history shows the following, in regard to the last chunk of December 2019:

Duplicate: A column that includes whether this resource already was added to the release history, and is somehow reappearing again as a new resource. This seems to be a bug, making it a little confusing.

ResourceType New or Updated? Date Duplicate Problem
AWS::CodeBuild::ReportGroup New 12/12/2019 12/20/2019
AWS::WAFv2::WebACLAssociation New 12/19/2019 Doesn’t exist anywhere in documentation, and doesn’t exist in v10.2.0 resource spec
AWS::EC2::GatewayRouteTableAssociation New 12/19/2019 12/19/2019
AWS::MSK::Cluster Updated 12/20/2019
AWS::SSM::Document Updated 12/20/2019
AWS::RDS::DBInstance Updated 12/19/2019 12/20/2019

Example Release: Missing Information

Some column information:

  • Added Region Count: How many new regions is this now available in?
  • Release History? Is this documented in the AWS Release History?
  • Blog?: Is there a blog article referencing this? If so, link provided.
  • Details:: Misc. such as a link to the list of regions it is available in
Name Type New? Added Region Count Release History? Blog? Details
AWS::CodeBuild::ReportGroup Resource Yes 20 Yes Yes Regions Added
AWS::EC2::GatewayRouteTableAssociation Resource Yes 14 Yes Yes Regions Added
AWS::DLM::LifecyclePolicy.CrossRegionCopyRetainRule Property Yes 13 No No Docs page says “Currently not supported by CloudFormation.”
AWS::DLM::LifecyclePolicy.CrossRegionCopyRule Property Yes 13 No No Docs page says “Currently not supported by CloudFormation.”

A changelog file, such as this generated MarkDown file for v10.x specifications, can be automated to try and include much of this information.

Blog links would take a lot of time and experimenting to try and look for and include in something auto-generated, so I wouldn’t try it. Unless AWS does something interesting in the future where related blog posts are referenced by AWS CFN user guide docs or vice-versa? If so, that would provide a simplified path for including blog links in changelogs.

Current Issues with The Repository

My changelog is currently missing when new property options are appearing such as MaxAllocatedStorage being added to AWS::RDS::DBInstance. Once this is supported, the GitHub repo will be a great launching point for looking into what’s new.

There are some other problems at the moment, which I’ve opened issues for:

  • Need to split the monolithic workflow into separate workflows, in order to prevent run steps breaking due to AWS rate-limiting documentation scraping (Issue #28)
  • I want to create a docker container for testing GitHub Action run steps, otherwise I am stuck iterating against live GitHub Actions to ensure I’m not breaking a workflow. This slows down development until this is done (Issue #9)
  • Use the GitHub Releases API to automatically (Issue #16):
    • Label the latest release as Latest release
    • Duplicate the changelog Markdown into the newest GitHub Release
    • As long as the above two are not automated, this has to be manually done.
  • And others…

Extra Thoughts

I think it would be a great idea to create some automation around a Twitter account, and potentially an email newsletter, that sends out notifications of new releases.

At the moment, it would simply be a matter of adding one extra run step to GitHub Actions for each of those.

If problems are discovered, or if you have feature requests, raise issues in the repo! Otherwise, feel free to enter the discussion on dev.to or reach out to ScriptAutomate on Twitter.

NOTE: To get an in-depth look at the history of this project, take a look at the following previous blog posts: