What needs improvement with AWS CloudFormation?

The Infrastructure Composer is not fully complete, making it necessary to tweak the code manually after generating it, which could be improved. Additionally, there are services still not integrated into the Infrastructure Composer. It presents challenges for users unfamiliar with coding, posing as a barrier to fully utilizing CloudFormation.

Everything in AWS has room for improvement. I haven't come across any major issues to where I wasn't able to launch anything via CloudFormation.

The ability to convert it easily to other code which can be used for on-premises infrastructure would be a beneficial improvement. Also, improving the quality of support would be helpful.

I prefer Terraform over AWS CloudFormation because AWS CloudFormation is specific to just AWS. But if I want to use a multi-cloud or hybrid setup, then Terraform works better. It uses a simple language, HCL. So, if you learn HCL, you can manage your infrastructures across different cloud providers. You don't need to be specific to one cloud provider. I prefer Terraform over CloudFormation, so I would rather work with Terraform for deployments. It's easier and simpler to perform deployments with Terraform in my experience.

There are some limitations with JSON, as the code is written in JSON, which doesn't support commands, looping, or conditionals. This can make the code difficult to read and share across teams. Moreover, the tool only supports AWS. Another challenge is related to cost, which I feel could be reduced as it's a bit on the higher side. Additionally, the documentation could be improved, as there is room for enhancement.

When I used AWS CloudFormation, I wrote the CloudFormation file. It would help all users if AWS improved the auto-generation of the CloudFormation file.

Manual updates are sometimes deployed, leading to errors or disruptions when attempting to modify or tear them down. These issues can be stressful to address

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.

For improvement, it's crucial that AWS provides options in terms of computing services, DB related services, and machine learning solutions. If I'm not hands-on with a particular service, like machine learning applications, I struggle to write the CloudFormation code. To specify, applications like SageMaker are ones I'm not very familiar with, so it takes me some time to launch ML-related applications when required.

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.

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

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.

Including certain examples of templates would be advantageous.

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.

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.

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

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.

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.

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

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.

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.

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.

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

The cost of licensing could be reduced.

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 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 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.

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.