AWS CloudFormation Reviews

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. 

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.

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

We use AWS CloudFormation to build resources. 

AWS CloudFormation has automated the resource-building process, thereby removing the scope of human errors. We can tag the resources which help the billing process. 

I like the tool's updation capability for versions. The solution is good for scalability as well. 

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. 

I have been working with the product since 2016. 

I rate the tool's stability a ten out of ten. 

I rate AWS CloudFormation's scalability a ten out of ten. 

The solution is a service by AWS and does not involve deployment. We have installed the tool over the cloud. 

The solution's cost is normal, neither cheap nor expensive. 

I rate the solution a nine out of ten. You need to leverage AWS CloudFormation as much as possible to automate workflows.

We are currently using AWS CloudFormation to build the infrastructure stack for customers.

AWS CloudFormation enables a copy of infrastructure to be set up AWS, saving time in our daily routine.

The ability to quickly run up CloudFormation in AWS and the template validation function are the most valuable features.

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 have been using AWS CloudFormation ever since the last time we spoke.

Stability is rated ten out of ten. It is very stable.

Scalability is rated eight out of ten, indicating it is pretty scalable.

Technical support from Amazon is rated seven out of ten. The response time and quality of support could be improved.

Neutral

The initial setup requires a certain level of basic knowledge to leverage it. The basic setup can be done in-house.

CloudFormation itself is not priced. The service will enable you to spin up infrastructure, which gets priced as part of the AWS license.

Azure is a main competitor on the market, particularly dedicated to the Azure Stack.

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