There is less support for on-premise environments. We get support from third-party vendors from AWS Partner Network in the CloudFormation registry, but not much for on-premise. People chose Terraform because it is useful when we work across different environments like AWS, Azure, and on-premise servers. AWS CloudFormation doesn’t work in such situations.

Provisioning a large environment or a large number of services takes a bit more time than with Terraform. 

The solution needs to provide a large set of documentation so you don't have to improvise at detailed levels. Documentation is available, but it lags behind what is provided by Terraform. 

The code we write in AWS CloudFormation is pretty big compared to Terraform. We need to have more modules in the solution. A library should also be there where we can save code lines. A dashboard feature would be good for designers. 

One area where AWS CloudFormation could improve is by offering more flexibility in creating custom templates. Currently, you can use default templates, but having easier ways to design your own templates, whether in JSON or YAML format, would be a helpful enhancement for users.

A few areas need improvement, like enhancing error handling and integrating with other AWS services.

They could improve the product's capability to handle circular dependencies more effectively. Currently, we encounter errors when deploying interdependent resources.

Including certain examples of templates would be advantageous.

AWS CloudFormation allows you to use the code templates written in JSON and YAML, but not directly in Python. Adding this feature would be beneficial. You may use Python alongside CloudFormation for enhanced automation and management capabilities.

Creating the inline policies is not great, and they need to maintain it on a higher level. They create a discrepancy between multiple templates when we do the numbering of those stacks using AWS CloudFormation templates. When we created those stacks in my old organization, a bulk of stacks were automatically wrongly numbered. The filtering of those stacks was painful on the AWS CloudFormation site. I prefer Terraform to manage that.

The product should be made cloud-agnostic, allowing users to deploy the same environment with minimal tweaks across different cloud platforms, similar to Terraform. Additionally, it would be beneficial to have the ability to manage templates outside of the AWS environment. 

The conditions that can be added in AWS CloudFormation are not as powerful as any programming language.

I'd like to see a better GUI than we currently have which is basically a script you write. If they were to add graphical components that would enable animation of the installation procedure it would be icing on the cake. We'd be able to preview the installation and visually see what's happening, whether or not anything is missing, and whether you can run parts of the installation in parallel.

There could be better error handling. It would be a good way to improve the solution.

The speed of the replication process could improve. It can take some time to replicate that could use a speed increase.

In a new release, they should add multiple optimization release features.

What could be improved in AWS CloudFormation is its user interface, in terms of graphical design, I prefer WYSIWYG.

CloudFormation has languages like YAML. If it were applicable, I would like to work with other languages like Python.

If you are a developer or a more technical person, it's very difficult to learn the complete syntax or because CloudFormation includes a new way to write infrastructure code. There is a technology called CDK and it provides a unique way to handle the infrastructure of every Cloud technology. 

CloudFormation should include compatibility with the programming languages or latest technologies. 

The cost of licensing could be reduced. 

The one bit of a drawback is that CloudFormation is, only, available in AWS.

When I have to work on other clouds or somebody has a configuration to be done on-prem Data Center, there's no way for me to use it.

It is what it is, AWS does not apparently intend to make this available all over.

The three big players in this area are Ansible, Terraform, and CloudFormation — except CloudFormation can only be used on AWS !

I would like to see less verbosity and better isolation.

One area that may be improved would be using variables as parameters in templates. This would make it a lot more flexible.

I don't know how soon that's going to happen because I'm trying to think from a developer's point of view - the guys that actually have to write and support all these features that I dream about.

Frankly, to evolve it but also maintain compatibility with what's in place now, may be a serious challenge.

The solution must enable more hands-on designing of the templates. We take the backend services and design the templates. The design must be drag and drop.

This tool is not intuitive and there are others that are easier to understand. It is very powerful but it can be developed to make it much easier to use. The learning curve is pretty steep. Unless you have been working with it for a long time, looking at a CloudFormation template is a tough job. The aim should be usability for a person with a non-coding background.

There is a lot of syntax and components that require you to look at the documentation, whereas with the inclusion of a few drop-down menus and choices, it would be much easier to work with.

You can have CloudFormation create a template based on your existing infrastructure, but not all of the services are included. For example, if you manually set up an environment and you have put in all of the scaling information then you can extract the entire infrastructure and get back a template. CloudFormation is then capable of recreating the environment but it might not have the scaling included automatically.

CloudFormation is not particularly good at handling cross-account dynamic references. If you try to refer to an object that CloudFormation has created in a separate AWS account, it tends to fall apart. That's because it is a byproduct of the multi-tenant configuration. This is the most glaring shortcoming in my perspective because you can't dynamically reference objects in other accounts that CloudFormation has created, but it is not a shortcoming that you can't overcome. This is the only pain point that I've come across that didn't have a workaround natively. Sometimes the confirmation is slow, and it could be faster.

The downside to CloudFormation when you're fully embracing it is that the AWS services do not get released immediately fully CloudFormation enabled. If you need to use the latest AWS service that just got announced or reinvented, you're not going to be able to continue with CloudFormation for the first X number of months. This is because they develop the products separately, and then they hand it to the CloudFormation team, which later on develops a CloudFormation integration. So, if you need to be on the newest thing AWS has, CloudFormation is often going to be a constraint that prevents you from doing that.

The customization is weak. Whether it is good or not depends on the customer's use case.

The solution needs to offer better support to other cloud vendors.

The solution requires Kubernetes support including container ops and staging support.