AWS CloudFormation Reviews

We use AWS CloudFormation to automate our deployment processes within the AWS environment. It makes the process easier to manage.

With CloudFormation, there is no need to use complicated coding. Instead, you define your infrastructure using a straightforward format called YAML, which resembles plain English rather than intricate code. Additionally, it offers extensive support and documentation, making it even easier to understand.

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

We have been using AWS CloudFormation for two years.

The initial setup of CloudFormation was very straightforward, to the point where even individuals with no coding background can easily understand the process. The deployment time depends on the amount of resources. It might require only a minute to complete if you have ten resources. However, if you have 100 resources, it could take two hours.

In a recent project, we had to deploy over 500 resources on AWS. Without CloudFormation, this would have been a time-consuming process, likely taking several days to complete manually through the console. Additionally, if we needed to remove the deployment, it would have required a considerable amount of time and a team of ten people. However, by using this platform, we were able to streamline the entire process. It allowed us to deploy everything with just one click. 

The change set feature provides efficient management of updates. Suppose you've deployed 500 resources but only need to modify 100, you can leverage the change set functionality to identify and apply these modifications. It automatically detects the necessary changes, creates a distinct change set, and deploys only the required updates.

I rate it a nine out of ten.

The product uses a simple JSON file format, so it's easy for a beginner to start. But you can use Terraform once you get good hands-on experience and know the infrastructure and resources well.

Using JSON templates in AWS CloudFormation has improved my infrastructure management because it's simple. We can have these templates in multiple setup repositories, which makes it easy for us to collaborate at a specific level.

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.

I haven't encountered any stability issues. 

From my experience with Amazon's customer support, it's good. We usually don't need to connect directly with the Amazon support team. We have specific customer relationship managers as well as a dedicated team that we pay for. We have a support plan in place.

We have both a support plan and a partner development manager who manages the AWS partnerships between our organization and AWS. So we don't have any big issues with support. The partnership manager helps maintain our relationship with AWS.

The tool's pricing depends on the page model. 

I rate the overall solution a nine out of ten and would recommend it to others. 

It allows us to use infrastructure as code. We write code to deploy resources on AWS. While we primarily use Terraform for deploying AWS resources, there are situations where we use CloudFormation stacks. It depends on the client's preference.

We have deployment pipelines set up to manage resources across multiple environments and accounts. When we want to deploy or modify something, we specify the target account ID and details within the deployment configuration. Changes to our code repository trigger the pipeline, which then executes actions on those specific accounts.

When it comes to automating things, the pipeline needs preparation for deployment. AWS calls this CodePipeline. In my last project, we used CodePipeline, though for CI/CD, we used Jenkins rather than AWS solutions. AWS CodePipeline is similar to Jenkins or GitHub Actions. 

Whenever you make changes to your CloudFormation source code, it will trigger the pipeline in CodePipeline. Our pipeline has steps for source control, build, test, and finally, deployment. This AWS DevOps functionality is the most valuable feature for automating things.

I appreciate the flexibility of infrastructure as code. With CloudFormation, we can define ground rules, control usage limits, and scale our infrastructure up or down programmatically. Having this level of control through code on infra is a major benefit. That's the beauty of CloudFormation.  

If you work with multiple cloud providers, it's better to go with Terraform. CloudFormation stacks cannot be used for multiple vendors. For example, you cannot create resources for Azure or Google Cloud Platform (GCP) using a CloudFormation stack.

I have been using it for the past two and a half years. 

I would rate the stability a ten out of ten. I haven't faced any issues with the stability yet. 

I would rate the scalability an eight out of ten. 

The reason for the eight is that we cannot directly integrate Control Tower with CloudFormation. For different services, AWS offers specific resources for scalability. For example, with EC2, we use Auto Scaling Groups to scale instances based on traffic or usage.

Within a CloudFormation stack, we can set up and create an Auto Scaling Group. So indirectly, CloudFormation facilitates the scaling of other resources, even though the stack itself isn't inherently scalable.

In my organization, there are probably around 800 to 1000 users working with AWS in general.

We are a service provider. We work with AWS as a service provider. Our clients include Toyota, BMW Canada, and BMW Germany. I recently worked with Vira Mobility in the US, and now I'm working in the banking sector. We provide CloudFormation to manage our clients' cloud infrastructure.

Customer service and support are available. If we raise tickets for issues on AWS, they will contact us as soon as possible. I think it's good. 

And, if we face any issues, they will resolve them quite well. The communication is also good.

Positive

For Toyota, we used Terraform. For BMW, we also used Terraform. For some FinOps purposes, we use CloudFormation stacks to have resources under control. 

However, in most cases, we use Terraform for infrastructure management and deployment. Currently, I'm onboarding to a new project where they use CloudFormation more heavily than Terraform.

So, I've mostly worked on Terraform. I use CloudFormation stacks purely for specific tasks that Terraform cannot offer.

The initial setup depends on how large your infrastructure is. If the infrastructure is small, it won't be too tough. But if the infrastructure is huge and we need to deploy across multiple accounts, like 20 to 30, then it's going to be quite difficult. 

Also, keep in mind that we can't use CloudFormation to create organization member accounts within AWS Control Tower. Aside from that, the initial setup is easier if you know what you're doing. For a beginner, it's kind of difficult. It might be better to start with Terraform as it's easier than CloudFormation.

So, the user does need some knowledge in order to do it.

AWS CloudFormation integrates with the existing CI/CD pipeline.

In CloudFormation, we configure our CodePipeline settings. Whenever you make changes to the source code, this triggers the pipeline. We can set this up in the AWS console. You can configure it to check your source code every 10 to 20 seconds. If there are changes, it will trigger the pipeline.

There's a particular team, the FinOps team, that handles the calculation of pricing. We do sometimes check the pricing for cost optimization purposes.

So, it's actually cheaper. In general, pricing within AWS is relatively affordable.

Overall, I would rate it a ten out of ten. It's quite similar to Terraform and easy to manage – especially if you know AWS well. The thing is, the CloudFormation stack is going to create the resources, so knowledge of AWS is important. Overall, it's actually good.

If you are using only a single cloud provider, you can go with CloudFormation. For those focused solely on AWS, it's a good option.

However, if you work with multiple cloud providers, it's better to go with Terraform. CloudFormation stacks cannot be used for multiple vendors. For example, you cannot create resources for Azure or Google Cloud Platform (GCP) using a CloudFormation stack.

AWS CloudFormation is infrastructure as Code specific to AWS. It allows companies invested in AWS to codify their infrastructure, enabling faster deployment, tracking drift, and gaining visibility into the environment through the templates. This facilitates easy deployment in different regions.

Since AWS CloudFormation integrates well with the AWS platform, it facilitates faster deployment. Building templates for AWS services within the solution is also straightforward, making the process easier.

I would say the versioning feature is particularly useful. Ensuring that we have the right version and being able to track changes made by enabling versioning is valuable. Additionally, the ability to roll back to a previous stack in case of a bad update is good. 

We primarily utilize AWS S3 buckets for large-scale deployments to store and maintain our templates. We keep a copy of the templates in a restricted bucket. We deploy these templates using AWS CloudFormation, which provides a console for quick deployment. During deployment, we can monitor the provisioning results and quickly make any necessary changes.

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. 

You need an enterprise agreement with AWS, meaning your company pays for the services. AWS delivers daily responses in the production environment, typically within five to ten minutes. However, in non-production environments, it might take up to 24 hours. Therefore, there could be delays in non-production environments, which may pause operations for a while.

Primarily, I use Terraform because I work across AWS, Azure, and Google Cloud platforms. Terraform is more portable across different cloud providers than AWS CloudFormation, which is specific to AWS.

The tool's deployment depends on the person's knowledge and experience, but overall, I find it pretty easy to set up. Additionally, AWS offers various templates for various services within its platform. It doesn't require many resources to deploy. It does require some maintenance in terms of adding and removing resources or adjusting the environment to meet current specifications. However, maintaining the software or the template backbone falls within AWS's purview.

The tool is free for the AWS environment. 

I recommend AWS CloudFormation to any company that is heavily invested in AWS. However, for companies operating across multiple clouds or adopting a hybrid on-premise and cloud solution, I would not recommend it. I rate the overall product a seven out of ten. 

I am using CloudFormation to automate the infrastructure of AWS.

CloudFormation has helped automate the infrastructure in AWS, making the process more efficient.

I like CloudFormation because the language is very simple, and it has a very good graphical interface for diagramming my infrastructure.

It's not that easy to use, but I can learn very fast.

I have been using CloudFormation for about two years.

I have not had any problems with the stability of CloudFormation.

If I need to use different clouds like GCP and Azure along with AWS, I prefer using Terraform.

I would recommend CloudFormation to others who use AWS solely. It is very useful for AWS-specific tasks.

I would rate it an eight out of ten.

Our company uses the solution to provision AWS services for customers. 

Whenever a new environment comes into the picture, we make use cases. We determine private and public user instances, how many VPCs to create, how many security groups we need, and how many knuckles. We prepare templates and provision the environment based on documentation from the client side.

Automations make it pretty easy to provision AWS, development, or deployment environments. The automations save on time and costs. 

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. 

I have been using the solution for more than three years. 

The stability on the higher side and similar to Active Directory. Stability is rated a nine out of ten. 

The solution is scalable so scalability is rated a seven out of ten. 

There are three environments or microservices for support.

The first is the sandbox which is like a playground where cloud engineers develop or deploy. The second is the UAT which is for clusters and other things. The third is the E2E environment for testing.

These levels provide good support and a high level of availability. Support is very good for cloud hardening and resource tagging.

In the non-pro environment, support is comparably less. It takes much more time to follow up or solve issues. On the weekends, you cannot get test study or dev team support because they are not working. 

We also use Terraform and either Ansible or Puppet from the automation perspective. 

The setup is pretty easy. We just make a template as per expectations. The solution is one of the easier ones to set up because it includes Guard with shift left testing, detective governance, compliance, and deployment safety. 

Guard is also there to install the solution and AWS Lambda functions. In the initial state, if you want to install the solution then you have to install Guard. Depending on your OS, you can install Guard in Windows, Linux, Unix, or macOS. After you install Guard, you provision the environment of the solution. 

Setup is rated an eight out of ten. 

We install the solution for customers. 

Initially, you download the binary and set the path on the OS. Then, you confirm the install the correct version of Guard. Next is the PA package manager with various levels of steps. Depending on documentation, you follow the steps and provision the environment by writing binary reports and the template. 

One team member can handle implementations. Sometimes, we work with a firewall or AWS support team for SSOs or two-factor authentications. Every organization has some level of security compliance so you just have to provision it. Sometimes, a port or firewall is not open so you have to take care of that. We handle requests for opening ports or firewalls and getting permissions for installs from the proper teams. 

The documentation is there to fire commands and install. Sometimes, glitches happen and we have to troubleshoot. For example, privileges are not there to set paths or binaries are not downloading properly. 

If there are no network latencies or other barriers, then the process is completed in 40 to 45 minutes and the solution is ready to use. 

The solution is an AWS-specific provider that can use JSON or YML. I use YML which makes the solution pretty easy to use and manage. 

Conversely, Terraform can span across multiple cloud services like GCP, Azure, AWS. It is open source and enables development of infrastructure as a code. It provides a common language that defines and provisions the infrastructure. The HCL configuration language is a very powerful tool because you can implement it in a JSON template. Command and repeat are infrastructure as a code. 

There are some size limitations with the solution. A developer cannot clear a template that is more than around 40 to 50 MB. On the other hand, Terraform uses a proprietary JSON-computable language with no limitations. 

The solution is managed by AWS services so it checks the infrastructure constantly to detect whether the provisions are maintained in state. A detailed response from their side only is received if anything changes or happens. Conversely, Terraform stores the state of infrastructure to provision machines visible or remote machines right in the JSON files. 

I like the solution for provisioning so I rate it an eight out of ten. 

AWS Cloud automation supports the creation of only AWS resources, and we use it to reduce the time needed to create resources. We create template files inside AWS CloudFormation to create multiple resources in AWS, such as EC2, S3, RDS, or Lambda functions. When we apply those files, the resources are created parallelly, reducing the time needed to create them.

AWS Cloud automation reduces the time needed to create AWS resources.

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.

I have been using AWS CloudFormation for one year. 

I have not faced any issues with the solution’s stability.

I rate the solution an eight out of ten for stability.

Around 10 to 15 users are using the solution in our organization.

The solution's technical support is faster and better than that of other cloud providers.

Positive

The solution's initial setup is neither easy nor difficult.

AWS CloudFormation's pricing is cheaper than that of other cloud providers.

I would recommend AWS CloudFormation to other users.

Overall, I rate the solution a seven out of ten.

It helps to automate the process of creating and managing AWS resources. It allows defining the infrastructure as code using templates, which describe the desired state of the infrastructure. This approach makes it easy to replicate environments, track changes, and perform repeatable deployments.

It enables fast and efficient deployment of AWS resources and configurations through code templates. It facilitates sharing and deploying infrastructure configurations across different environments and locations. It provides automated resource management, allowing for updates and rollbacks to be easily managed.

Its infrastructure as code approach is the most valuable.

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.

I have been using it for five years.

It offers good stability. I would rate it eight out of ten.

I would rate the scalability capabilities eight out of ten.

The initial setup was relatively straightforward.

We witnessed a return on investment.

It provides assurance and confidence in the deployment of the environment, due to its infrastructure as code mode. It allows easy tracking of the changes, reviewing configurations, and ensuring that it aligns with requirements and best practices. I would rate it nine out of ten.