AWS CloudFormation Reviews

We're using CloudFormation to deploy our Lambdas and infrastructure. We set up the configuration using the CloudFormation template.

Using AWS CloudFormation as our cloud service provider is helpful for us in deploying our applications and infrastructure.

AWS CloudFormation is very helpful for deploying resources across different regions, such as the US, EU, or Asia. With CloudFormation, we can utilize a single template to deploy resources across multiple areas, providing flexibility and ease of management.

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 product is stable.

I rate the solution’s stability a ten out of ten.

The solution’s scalability is good. 30-40 people are using this solution.

I rate the solution’s scalability a ten out of ten.

Technical support is fast.

Positive

We were using GitLab or SAP pipeline.

The initial setup is easy and takes 10-20 minutes to complete.

I rate the initial setup a nine out of ten, where one is difficult and ten is easy.

With AWS CloudFormation, whenever we encounter an issue, we don't need to update it manually in the console. We use templates and can quickly deploy them to other regions. By deploying without manual intervention in the console, CloudFormation helps to minimize human error and mistakes

Since numerous AWS services are available, if we ever find a particular feature missing, such as the CloudFormation service, we can explore alternative AWS services that offer that feature. Alternatively, if we don't see a feature available or need guidance, we can ask AWS support for advice on their solutions.

I advise you to look for available documentation. There's a lot of information on how to set up the configuration and the template.

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

We use CloudFormation for infrastructure management. Since we only have read access to the AWS console, we rely on CloudFormation for any changes, such as creating or managing instances, storage, or IAM activities. 

As a DevOps engineer, I work with databases, compute services (like EC2), the Beanstalk stack, and Lambda functions. CloudFormation is our primary way to manage all those resources.

There is a service called OpenSearch, previously known as Elasticsearch. It is used for search optimization. Whatever keywords we type in the search, related keywords automatically appear. This is facilitated by Elasticsearch, or in AWS terms, AWS OpenSearch. 

Previously, it had a public IP address, but we needed to change that to a more secure setup. So, instead of modifying the current public VPC, we decided to go with a totally new one, and we are currently planning to migrate from Elasticsearch to OpenSearch. 

Elasticsearch is open-source, which anyone can use, not just AWS cloud users. AWS OpenSearch is something AWS offers, which is like an extension of Elasticsearch. 

This is our plan for upgrading. So we created a VPC, which should be private, with the proper setup to enable communication between computing services across different accounts as well. We use different accounts to manage our applications. 

Even if one computing service is on one phone and another on a different phone, both should be able to communicate with each other. Also, we have many legacy applications available, which are very old and installed directly on an instance, not as a microservice. These applications, on-premise, need to communicate with cloud servers. We use VPNs for this. Everything requires some planning to make this happen. This is something we have knowledge in and what we do in our work. 

Even in DevOps work, deploying the application end-to-end without any manual intervention is key. Once a developer has pushed it to Bitbucket, which is the version control tool we use, if they click the build button in Jenkins, deployment should happen automatically and quickly, even in Jenkins AWS. 

We recently decided to move to GitHub Actions, considering different options available to migrate our CI/CD setup to another one due to the manual processes here which are causing performance issues. 

This migration IT is also happening, and this is something I have experience on. 

One feature I like is reusing the same code. For instance, we have different environments available, like a general development environment, SIT, UAT. Once we have created a setup by spending much time on that particular code, we can reuse the same by changing minor details. 

For example, if there is an application to be deployed in a development environment, I spend a lot of time to create a CloudFormation template with proper instance settings, and AWS JVM settings which need to be configured. 

I configure everything at one time, and I can reuse the same multiple times if I want to create environments, which can be USIP pre-production or production. Reusing the code multiple times simplifies our work significantly.

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.

We use it on a day-to-day basis in my company. I have been using it for four years.

I would rate the stability an eight out of ten. 

Every day, we face issues like a headache-related task. We don’t use the software as a service model for Bitbucket; we maintain it in our infrastructure. 

We previously used our NFS as the backend instance to store all the Bitbucket storage. Now, we recently upgraded to EFS. 

Still, the performance is below the minimum expectation, which is that whatever the migration we are doing, it should be equal to the old server performance or better. But unfortunately, here, it’s poor compared to the old server performance. It takes 10 to 12 seconds to open a single page. So, we are still working on fixing the issue.

Many reasons we are able to find out why this is the case with AWS. One is related to the credits that AWS will provide. Here, so many people are using this bucket. So, the credit limit should be increased. That is one point. We have not found the proper reason, but still, in reality, we face different issues, and this is one of them that happened to them.

I would rate the scalability a nine out of ten. We use it every day. There are around 15 end users who use this solution to manage other users and teams, like the QA team and the dev team is there, by concluding all the users. So, in our database, around 50+ user software is managed by our team, which is asking people, and we only have access to CloudFormation. 

We have contacted the customer service and support team. We needed to move some items based on the technical deployment solution. This is something that we are unable to figure out while the deployment is ready. 

Everything is good on the cloud side and the configuration side. We have scenarios where we need to speak to Amazon’s support team.

Positive

The initial setup is very straightforward. It depends on the project's scope. Typically, a minimal setup can be scripted within five minutes if it involves basic resources. 

However, a more complex or fully customized setup can take longer. However, the process is much simpler compared to other infrastructure as code tools because no installation is required. I use the Visual Studio Code editor, which is sufficient to write our code, and the automation services handle the rest efficiently.

There's no cost for launching any template using CloudFormation. We only pay for the AWS resources we use. For example, if we launch an instance using CloudFormation, we pay only for the instance itself.

If you need to launch an instance for a one-time test, and won't be repeating that process, it might be simpler to do it manually. 

Writing the CloudFormation code and handling potential deployment issues could be more effort than it's worth for a single use. However, if it's a task you'll repeat, CloudFormation is a great choice.

Overall, I would rate the solution a nine out of ten. I would recommend using it. 

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.

It serves as an automation framework for deploying infrastructure by using templates.

The most beneficial aspect lies in its capability to handle input acquisition and assessment. This feature allows users to input information, essentially functioning as a vendor, where values can be inserted and interest can be derived from the system.

Including certain examples of templates would be advantageous.

I have been working with for four years.

It is very stable. I would rate it nine out of ten.

I would rate its scalability capabilities nine out of ten. Our team exclusively relies on CloudFormation templates, and it consists of five to six individuals.

The level of technical support provided by AWS is excellent. I would rate it ten out of ten.

Positive

While currently working with Azure, we utilize distinct solutions tailored to the platform. However, it's worth noting that when we were using AWS previously, CloudFormation stood out as the preferred and superior choice for configuration.

The initial setup was fairly easy and I would rate it nine out of ten.

We handled the deployment internally with a team of four or five members. While maintenance typically only needs one person, it is currently managed by multiple individuals.

The pricing is not notably high. I would rate it two out of ten.

Overall, I would rate it ten 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.

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.

I use it to automate the creation of infrastructure using AWS CloudFormation templates. In my project, I must create infrastructure for SaaS-based applications hosted in the AWS cloud. Whenever I onboard a new customer, I need to create the same architectural infrastructure for them, as it's a multitenant architecture, so a lot of the setup remains the same.

By using AWS CloudFormation, I can automate tasks like creating VPCs and load balancers instead of doing them manually each time. The features I like most include improved scalability, resource management, ease of deployment, template creation, and resource provisioning.

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.

I have been working with the product for three years. 

I haven't faced any stability issues with AWS CloudFormation, and I would rate its stability as nine out of ten.

As for scalability, I see improved scalability with no issues, and I would rate it an eight out of ten. In my organization, around 18 people are using AWS CloudFormation.

AWS support is fine and prompt. It is paid. 

The initial setup is quite easy, like filling out a form and submitting it, making the deployment straightforward.

I rate the overall product an eight 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.