AWS CloudFormation Reviews

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.

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.

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. 

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.

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.

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. 

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.