AWS CloudFormation Reviews

We use this solution for application hosting and utilize the caching mechanisms. 

The cost of licensing could be reduced. 

We have been using this solution for one year. 

This is a stable solution. 

This is a scalable solution. 

For the cost point of this solution, the customer service and support is quite good.

Positive

The initial setup is straightforward and took approximately four weeks. 

The implementation was completed by an external consultant. 

I would recommend the use of this solution. 

I would rate it an eight out of ten.

We use it for deploying all the Infrastructure: VPCs, EC2 instances, storage solutions, most managed services. Providing IAM configuration, providing group account configurations, role management within IAM.

CloudFormation is THE Infrastructure as Code (IaC) solution AWS recommends.

Almost everything should, according to AWS, be automated and managed using CloudFormation - whenever possible. 

Within our organization, mostly the DevOps engineers use AWS CloudFormation — around 42 of them.

I don't really care how my organisation is functioning; I care about the way that my client's organisation functions. That's what I'm after. We host workshops teaching people the DevOps transformation process, how to do infrastructure automation — almost everything. 

Of course we do the same internally, but our internal needs and use-cases don't, even, come close to our Clients'.

First off, It's fairly easy to work with, although a bit verbose. It is legible. You can understand what you're doing. The introduction of "nested stacks" allows a modular design and repeatable  structures. The nested stacks would be one of the more valuable features. I am waiting for them to become much better with parameters as this is not quite up there.

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.

I have been using AWS CloudFormation for just over one year.

It's definitely stable. If it's not a long-running service, and this one's not, it's very easy to verify that you've got it where you want it. 

Just run a deployment, then it's very easy to look at the configuration and see exactly what came out. The easiest verification is the intuitive visual check-out.

There are ways to test around in the sense that you're not forced to use CloudFormation to see that it's correct. You can literally, visually inspect the configurations with the console and other means not using CloudFormation. There's always a way to verify, and the fact that you have a verification method available is convenient.

If you want to deploy thousands of components - not only virtual machines, but, also, users, roles and services, in any of the AWS regions — it's not a problem.

Frankly, I never had a problem, with AWS CloudFormation, per se.

Something advertised that doesn't work and to require support, that actually has never happened.

I did use another solution, which is Ansible, but I didn't switch. I'm still using Ansible as a backup for those cases where CloudFormation does not cover. Also, outside AWS, where CloudFormation is not available.

CloudFormation is setup by AWS by default. It's easy and it doesn't require you to do anything.

When you create your infrastructure, there is no need for you to deploy anything like agents; everything is already in there.

It's very convenient in the sense that you don't need to worry about updating, upgrading, patching or monitoring for liabilities. AWS takes care of all of that.

There's probably a lot of people that are trying to work around it. Or, to avoid it. My advice would be: use it when Amazon says so because it's probably the most straightforward approach to your problem. Afterwards, then you can become creative, for it's worth putting in the effort.

On a scale from one to ten, I would give this solution a rating of seven.

That rating would, definitely, be higher if CloudFormation would be made available on other platforms, outside Amazon.

CloudFormation drives most of our AWS configuration. It is the configuration engine for our whole footprint. Literally, everything that we configure in AWS is configured in CloudFormation. We are using its latest version.

Its ability to treat infrastructure's code is valuable. It makes things automatable and reproducible.

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.

I have been using this solution for four years.

It is stable. Crashing is not really a concern. There are edge conditions that probably started off as bugs, but they're pretty well understood. There isn't an issue related to stability, reliability, or anything like that. 

It scales as well as AWS does. Scaling is not a consideration in CloudFormation. You scale the things that feed your templates. In the end, you let AWS itself handle the scaling. Therefore, CloudFormation itself is not under scaling considerations.

Our users of this solution are software engineers, DevOps engineers, and SecOps engineers.

Their tech support is very good at addressing failures. I would rate them an eight out of ten.

I have used other solutions but not in AWS. To solve this problem, CloudFormation is the only thing I've used in AWS.

It all depends on how much you're trying to do with it. The more you're trying to do with it, the more initial load you have to do. If you're just trying to retrieve a single object, you just write a confirmation template to load it up in there. There's nothing else to be done.

It is very quick and almost instant to bootstrap from nothing. I have a confirmation template that does it for me, but obviously, in AWS, doing a thing is not all you do. You do many things layered on top of each other. To get to something truly functional takes some time, but I would say it is pretty quick.

I would rate AWS CloudFormation an eight out of ten. It does what it is supposed to do, but there are certainly ways in which it could be extended, and there are certain ways using which it could be integrated earlier into their release cycle.

We primarily use the solution for creating automated blueprints for deploying machines, infrastructure as a service, and platform as a service.

The integration of the solution is very good.

The time to market is really good, I would say. You can quickly set up a blueprint and deploy it.

The initial setup is simple.

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.

I've been using the solution for about a year.

We've never had to contact technical support. So far, there haven't been any problems.

I also use vRealize and find that it is better compared to CloudFormation. It has better features.

The initial setup is very straightforward. It's not complex at all.

It only takes about 15-20 minutes to set up. After that, there's a bit of blueprinting that needs to happen, however, how long that takes really depends upon the person who's building it.

In terms of maintenance, our clients have three options: they could take a managed service from us, where our engineers will go and support the system, they can have some resident engineers in their own company, or, if there are technical problems, they can contact Amazon AWS to get support.

We are system integrators. We help our clients during implementation.

I don't know what the cost of the solution is.

We also use VMware's vRealize automation. vRealize has better orchestration workflows. We have prebuilt orchestration workflows available on vRealize and can build the blueprint and basically deploy in any public or private cloud vendor, so it's a cloud-agnostic product. This is something AWS lacks.

It also is created on YAML. It's an industry standard, which can, again, be compatible with multiple platforms.

We are a solution provider and system integrator with AWS. We are also a solution provider with VMware.

We don't personally use the solution. Instead, we deploy it for our customers. The companies we work with range from small companies to large enterprises. Our clients use the solution daily.

I'd advise other organizations to definitely have an understanding of the AWS portfolio, and the product portfolio. It's also important to first understand the manual structure because it's basically automating manual tasks. It depends upon how repetitive those tasks are, because sometimes building a blueprint might take a sufficient amount of time and if those are not very repeatable and it's done once in a week or more, then it doesn't make sense to use CloudFormation to automate that.

I'd rate the solution seven out of ten.