AWS CloudFormation Reviews

Neutral

I have experience with AWS CloudFormation. I use it to automate the provisioning of the entire environment by spinning up the VPCs with the subnets and security groups, and I also use EC2 instances and databases. It is great for ensuring consistency across the development, staging, and production environments. With the help of AWS CloudFormation, I have managed the updates and rollbacks smoothly when there are changes in the infrastructure.

I often combine this with the AWS CDK to write the infrastructure as code in familiar programming languages, which speeds up development and improves maintainability. Sometimes, troubleshooting template errors or complex dependencies can take time, but once it's set up, it saves hours to minutes. Overall, it is very easy to manage the cloud infrastructure to avoid manual mistakes.

When considering AWS CloudFormation, I use it as an infrastructure as code service that lets us use AWS resources by using JSON, and we can easily automate the setup for the entire infrastructure such as servers, databases, networking, and more. It helps to manage complex environments by tracking resource dependencies, and it can easily update very safely. It mainly includes setting up the VPCs, EC2 instances, and the IAM roles. AWS CloudFormation is great for deployment automation, version control, and disaster recovery setups.

When it comes to the challenges with AWS CloudFormation, I faced a few challenges. One challenge is associated with large infrastructures; the template can become very long and hard to manage. Sometimes, the error messages during stack creation or update can be very hard to troubleshoot. Managing the correct order of resource creation and some updates can be tricky, especially with interdependent resources. If a stack update fails halfway and rolls back, it sometimes leaves the resources in an inconsistent state. AWS imposes a limit on stack size and the number of resources per stack, which can be quite constrained for large deployments. Despite all this, once we have experience, we can overcome these challenges very easily.

Stack creation or updates can be slower than expected, especially with large and complex resources, and certain resource types or dependencies can add to the wait time. Nevertheless, AWS offers a way to optimize performance by breaking large templates into nested stacks. It's very capable, but there is room for improvement in speed.

I actively use AWS CloudFormation.

When it comes to stability in AWS CloudFormation, I find it generally very stable and reliable for managing the infrastructure. It's a service that has been around for years, and it handles large complex deployments and updates with very good consistency. AWS continuously improves AWS CloudFormation by adding new features and supporting new services. Sometimes, there may be delays or timeouts during stack operations, especially for large and complex stacks, but these are very rare. The rollbacks help maintain stability if something goes wrong during updates. Overall, AWS CloudFormation provides a robust foundation for infrastructure automation.

AWS CloudFormation is easy to use with JSON and cloud infrastructure. It depends on the experience and the business requirements.

I rate AWS CloudFormation nine out of ten because it's very reliable and performs very well.

I recommend AWS CloudFormation to other people. I tell them they can easily automate and standardize their AWS infrastructure deployments while ensuring consistency across multiple environments such as development, testing, and production sites. They can also easily manage the infrastructure as code, which improves version control and collaboration. I suggest they invest some time in best practices such as modular templates and testing, considering the learning curve.

I primarily use AWS CloudFormation for deploying infrastructure efficiently. For instance, if I want to create load balancers with target groups and EC2 instances, I find CloudFormation simplifies the process of deployment and configuration, reducing the possibility of errors.

AWS CloudFormation lets me see all the infrastructure and its links clearly with code. I appreciate this ease in writing infrastructure with code, which provides an overview with text. It helps me visualize how AWS resources are linked and enhances my work efficiency.

AWS CloudFormation makes infrastructure deployment easy. I love how it facilitates many tasks and reduces errors. For example, I can see the entire infrastructure and its connections through code. I truly appreciate the simplicity of writing all the infrastructure as code and having an overview with text.

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.

I have been using AWS CloudFormation for something like a year.

I have not encountered any bugs or stability issues with AWS CloudFormation so far. It has been reliable and efficient in all my deployments.

Adjusting capacity and functionality is a fundamental use. However, I wish there was a simpler, more interactive visual representation post-deployment, allowing changes without reverting to code modification.

The support from AWS can take some time to respond, often taking about a day or two. While this might be acceptable for some, it can be lengthy depending on the urgency of the issue.

Positive

While I am familiar with Terraform, I find AWS CloudFormation to be more intuitive and easier to use. CloudFormation's documentation is concise, making it accessible compared to other tools for infrastructure as code.

The initial setup of AWS CloudFormation is very easy. I just need to click through the setup process, and then input the YAML file. It’s intuitive, without any significant problems.

I am not concerned about the pricing or setup costs for AWS CloudFormation, as my account is funded and I haven’t needed to pay attention to pricing details.

While I have used Terraform, I prefer AWS CloudFormation because it is easier to use and understand.

AWS CloudFormation is a very intuitive and easy product to use. I prefer it over Terraform due to its simplicity in understanding. I would recommend this product to others.

I'd rate the solution nine out of ten.

Our primary use case involves using numerous AWS services, including EC2, S3, RDS, Lambda, and all databases. We are focused on migrating our Oracle on-premises systems to AWS cloud to optimize costs. A

dditionally, we are leveraging automation infrastructure as code practices using AWS CloudFormation and Terraform, alongside implementing FinOps practices for cost optimization.

Using AWS CloudFormation has given us the ability to automate and optimize our infrastructure, reducing manual efforts and improving efficiency, particularly in cost optimization and management of our cloud resources.

The most valuable features of AWS CloudFormation include the import and export functionality, and pseudo parameters, which reduce our coding efforts by managing parameterization at the account level.

There is room for improvement in the optimization of AWS CloudFormation. Since it currently supports only YAML and JSON, the number of lines of code increases significantly.

I have been using AWS CloudFormation for over three years.

The stability of AWS CloudFormation is generally good. On a scale from one to ten, I would rate it an eight.

The scalability of AWS CloudFormation is crucial, especially in large-scale environments like multi-region setups. It allows us to deploy CloudFormation stacks across multiple AWS accounts and regions with a single template.

AWS provides fast customer service and support. They promptly respond to tickets and provide valuable guidance, receiving a rating of four point five out of five for their support.

The initial setup of AWS CloudFormation was straightforward, although applying complex security controls later added some complexity.

AWS CloudFormation does not charge for stack creation itself, only for the resources used, which is cost-effective.

I definitely recommend AWS CloudFormation as it does not require expert skills to build, and someone with intermediate knowledge can use it effectively.

I'd rate the solution 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. 

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.

I use AWS CloudFormation for deploying infrastructure on AWS. It is solely limited to AWS across multiple cloud platforms such as AWS, Azure, Google, and Oracle. I have used it to deploy various AWS services like Amazon S3, MongoDB, and others. To use it, I simply need to upload a template to an S3 bucket and then execute the deployment. CloudFormation is robust in its implementation, but if the decisions made during deployment are incorrect, it may result in deployment issues.

AWS CloudFormation is easy to use. The language it offers provides a choice between JSON and YAML, which are human-readable languages compared to other coding languages like Python or Java. One of the selling points of CloudFormation—it uses a familiar language, making it easy to read and troubleshoot.

If Amazon could extend CloudFormation to other cloud platforms, that would be good. Currently, it is only limited to AWS. The main reason some people avoid using CloudFormation is because it's restricted to a single cloud platform. In my previous role, we operated across multiple cloud environments including Azure and were preparing to integrate Google Cloud. Since our operations span multiple platforms, we needed a solution that could handle infrastructure as code for AWS, Azure, and Google Cloud. We opted to use Terraform, which supports multiple cloud providers, allowing us to manage our infrastructure seamlessly across AWS, Azure, and Google Cloud.

I have been using AWS CloudFormation for 3-4 years.

The product is stable.

The solution scales really well because when I'm deploying resources. Scalability depends on how the user sets it up. You don't have any issues with scalability. We are using AWS CloudFormation to address current issues. I created more resources, which took too much time. I was using three servers with CloudFormation and then scaled to ten servers. I set up my template, including the master server. But when it's time to scale, It can scale up automatically. I don't need to do anything.

Support depends on what type of subscription you have with AWS. If you have sufficient reach of AWS CloudFormation and encounter any issues, you can call for support. You can create a ticket, and they respond to your email within a few hours. If necessary, they'll schedule a call to provide further assistance. I've experienced good support from them.

Positive

I have used Terraform for CI/CD pipeline.

The initial setup is easy. Unlike Terraform, where I have to configure AWS credentials before using it, CloudFormation is seamlessly integrated into AWS. I can access it directly from my AWS portal, allowing me to quickly start writing configurations or setting up resources. Additionally, with IAM, I can easily manage permissions.

CloudFormation itself is free to use. You will be charged for the resources you deploy using CloudFormation.

The change set feature is a way to preview the changes that will be applied to AWS infrastructure before securing them. It's proposing the changes to the CloudFormation stack. The CloudFormation stack is essentially my template. It shows what resources would be added, modified, or deleted based on the template. I'll generate it by specifying the CloudFormation template to create the change set and providing the necessary parameters if needed.

If you are using AWS, CloudFormation is a way to go. If you're operating across multiple platforms such as AWS, Azure, and others, each cloud provider's native orchestration tool might be preferable. AWS offers its own solution. AWS CloudFormation seamlessly integrates with its services, making interactions smoother. Using CloudFormation in an AWS environment simplifies the orchestration process. However, if you're using a multi-cloud setup, managing resources across platforms might become complex.

Overall, I rate the solution a nine 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. 

AWS CloudFormation is an IaC tool. We use it for the creation or modification of the entire environment.

When we make changes in an infrastructure, we should ensure that we make the same changes in all environments. We must do careful observation. No matter how fast we do, there is no proper way of tracking. With AWS CloudFormation, any change is trackable. It is much more helpful.

Earlier, we used to face a lot of issues. Some things would work in dev but not in UAT. Some things would work in UAT but not in production. We must ensure that we make every change properly. Everything goes in the same flow along with the code.

Versioning makes our work easy. Everything has a version. If we use a specific version, we can use the features available for that particular version. It is really helpful. We can write it in JSON or YAML. It gives us a lot of flexibility. We can model and provision the third-party resources in the CloudFormation registry. We can also publish them to the AWS Partner Network.

We can also work with the SAM templates. It is the most important thing I use when I work with Lambda functions. I can build the serverless application faster with the SAM templates. It’s an open-source framework. We also have a template builder. It is a command line tool. We can generate the templates. We can perform drag-and-drop actions on the builder. We can also create codes automatically.

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.

I have been using the solution for eight years.

When a new version comes, there are slight changes. Overall, the stability is good. The tool is stable and reliable.

The setup is easy. The time taken for deployment depends on the infrastructure.

The product is free.

As developers, we create infrastructure once. After that, we only make changes. We use the solution during the start of our projects. For managing infrastructure across multiple AWS accounts, we create the CloudFormation templates and integrate the CI/CD process with them. When we started, there was no CloudFormation. We used to do everything manually. I recommend the solution if a person is using only the AWS environment. Otherwise, Terraform is a good option. Overall, I rate the tool a six 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.