The Quick Summary
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
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-1spec 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.
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
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::WAFv2::WebACLAssociation||New||12/19/2019||Doesn’t exist anywhere in documentation, and doesn’t exist in
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::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…
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.
NOTE: To get an in-depth look at the history of this project, take a look at the following previous blog posts:
This article can also be viewed on dev.to