This article is based on reporting originally published by TechTarget (techtarget.com) in 2019.
Background: Why CloudFormation Users Were Frustrated
AWS CloudFormation is one of the most widely used infrastructure-as-code (IaC) tools in the cloud ecosystem, allowing engineers to define and provision AWS infrastructure through declarative templates. However, for years, a persistent complaint from the CloudFormation community was that AWS’s own IaC tool lagged behind the pace of new AWS service releases — meaning engineers could not manage newly launched services through CloudFormation on day one of general availability.
In response to sustained user pressure, AWS released a public roadmap for CloudFormation in mid-2019, hosted on GitHub. The move was intended to give teams greater visibility into which CloudFormation resource types were being worked on and roughly when they might become available.
AWS evangelist Jeff Barr acknowledged the gap directly in a blog post at the time: “While our goal of providing 100% coverage remains, the reality is that it will take us some time to get there.” He attributed the lag to AWS prioritising scalability of the CloudFormation service itself over complete service coverage.
What the CloudFormation Public Roadmap Contains
The CloudFormation roadmap, modelled after a similar roadmap AWS had released for containers earlier that year, organises planned work into four status categories:
- Shipped: The CloudFormation resource type is complete and available for production use across all AWS public regions.
- Coming Soon: Work is well underway; expect availability within a few months.
- We’re Working On It: Active development is in progress, but on a longer timeline than “Coming Soon.”
- Researching: AWS has not yet determined how to implement the feature and is in an exploratory phase.
Importantly, the roadmap is scoped specifically to coverage updates for existing CloudFormation resource types and resource types with no existing CloudFormation support. It does not include information about AWS services that have not yet been publicly released.
AWS also made clear in its FAQ that specific release dates would not be provided on the roadmap, citing security and stability as primary priorities that could affect timelines.
Community Reaction: Cautious Optimism
Reaction from experienced AWS practitioners was generally positive but measured. Ryan Marsh, a DevOps and serverless coach at TheStack.io in Houston, offered qualified praise:
“This is exactly what we’ve been asking for, in lieu of same-day GA of course. Furthermore, we need to see more of this type of leadership with AWS’s various open source endeavors, many of which still feel controlled by the company — not the community — and yet have no public roadmap.”
Scott Piper, an AWS security consultant at Summit Route in Salt Lake City, took a more sceptical view of how much practical impact the roadmap would have:
“I think the increased transparency is good, although I wonder how many people actually monitor or care about it. I think most people have maybe one feature they want to have happen and so this gives them a better way of tracking the progress of that feature.”
Piper also raised a practical concern about the GitHub thumbs-up mechanism AWS uses to gauge user interest in features: “GitHub suffers from bots like every other social platform, and probably more so.” He suggested that for most customers, feature prioritisation at AWS still ultimately correlates with AWS spend — large enterprise customers with significant annual contracts having more direct influence over AWS engineering priorities than community votes.
CloudFormation vs. Terraform: The Coverage Gap Problem
The frustration driving the roadmap request was not merely academic. Several organisations reported that CloudFormation’s coverage lag had pushed them toward Terraform, the open-source IaC tool developed by HashiCorp. Because Terraform’s AWS provider is maintained by both HashiCorp and the community, it often gains support for new AWS services faster than CloudFormation itself does.
This is a notable irony: AWS’s own IaC tooling has at times provided less coverage of AWS services than a third-party tool. The public roadmap was partly AWS’s acknowledgement of this tension and an attempt to rebuild trust with teams who had already switched or were considering switching.
The CDK Factor: Has AWS Shifted Focus?
One context point worth understanding is that 2019 was also the year AWS launched the AWS Cloud Development Kit (CDK). CDK is an IaC framework that allows developers to define cloud infrastructure using familiar general-purpose programming languages — TypeScript, Python, Java, and others — rather than the JSON or YAML templates that CloudFormation requires.
CDK compiles down to CloudFormation templates under the hood, so it inherits CloudFormation’s coverage limitations. However, its developer experience is significantly different and was well received. Amazon CTO Werner Vogels, in an interview with TechTarget at the time, indicated that AWS had been directing more engineering attention toward CDK based on developer demand:
“I think overall, we’re on a good path — the right path. But I love the fact that there is a long list of requests for CloudFormation. It means that customers are passionate about it and want us to do more.”
For DevOps teams evaluating their IaC strategy, this raises a practical question: if AWS’s own engineering investment was increasingly going into CDK rather than raw CloudFormation template coverage, how quickly would the coverage gap actually close?
Key Takeaways for DevOps Engineers
- The roadmap provides visibility, not velocity guarantees. AWS explicitly declined to commit to specific release dates. Teams should treat the roadmap as a planning input, not a delivery contract.
- Scope is limited to existing services. If you are waiting for a brand-new, unreleased AWS service to get CloudFormation support, the roadmap will not tell you anything until that service is publicly available.
- Community input has limits. GitHub reactions do factor into prioritisation, but large enterprise spend is a more direct lever. Small teams should not assume a popular GitHub issue will move quickly.
- CDK is an alternative worth evaluating. If template verbosity is a pain point in addition to coverage, CDK’s programming-language-native approach addresses a different set of frustrations than raw CloudFormation.
- Terraform remains a valid option for coverage-sensitive workflows. For teams where day-one support of new AWS services is a hard requirement, Terraform’s provider ecosystem may still be a better fit.
Summary
The release of the AWS CloudFormation public roadmap in 2019 was a meaningful transparency improvement, responding directly to years of user criticism about feature lag. Hosted on GitHub and organised into four clear status categories, it gave CloudFormation users a structured way to track resource type coverage progress and provide feedback. However, the roadmap came with important caveats: no release dates, limited scope, and no explicit commitment to accelerated delivery. For DevOps teams building on AWS, it remains one useful signal among several when making IaC tooling decisions.