Comparing azure ARM and AWS cloudformation

The idea behind these tools, is that you can define the service(s) that you want to be deployed, and just change the parameters when you want to deploy the same set of services in a different environment. This way of working allows you to make less mistakes as you don’t have to configure the service(s) themselves every time you need to set them up.

As CloudFormation and ARM are both made for their own cloud environments, there are some differences between them. Both are great to use, and it could come in handy to know the differences between them when working in another cloud than you’re used to. So let’s find out the differences!

ARM templates can only be written in JSON while CloudFormation supports both JSON and YAML.
As these languages are notation languages, it’s possible to separate your deployment in multiple files. This can be used to create an infrastructure template that contains the service(s) you want to setup and create one or more parameter files which contain the environment specific configuration parameters for the services.

By doing this, your infrastructure setup is less prone to errors as only the parameters are changed between environments. The setup of the services themselves remain the same.

I think CloudFormation is the big winner in this department as it is available in both JSON and YAML. The readability of comments in YAML is far greater than that of JSON comments. The ability to provide (easily readable) comments in the configuration files themselves can be very useful whenever another person has to go through the files to make changes or to understand how everything works.

The deployment can be monitored in both CloudFormation and ARM. When the deployment or configuration of a service fails, an error will show up in both the console and the CLI. Every creation or change of a service is logged to the cloud-specific logging service.

In my experience, most of the time the errors that are displayed will be useful. Both provisioning tools sometimes display a generic error that contains no useful information for debugging purposes. CloudFormation has been more reliable in giving debugging information than ARM in my case.

When deploying with ARM, all changes are logged inside the Azure Monitoring Log Analytics. In AWS the changes are logged to the CloudTrail service. In both cases it’s possible to go back in time and see who changed what in a specific service or environment.

CloudFormation keeps history of every change of state, this enables us to be able to do a rollback to any previous version. ARM is not fully stateful, but still gives us the ability to rollback to the last working version.

In ARM, modularity is achieved by providing nested templates. In CloudFormation, this is done by providing nested stacks and cross-stack references. These are very similar and generally can achieve the same thing. The downside to using nested templates/stacks is that the templates have to be stored in a Storage Account (Azure) or S3 (AWS) service. This increases the complexity of the setup, especially when you want to incorporate versioning.

There are plugins available for both CloudFormation and ARM. In my experience, the ARM plugins were a bit better as they have templates available for most of the services that can be deployed. CloudFormation was a bit lacking in this feature. (In YAML)

Both ARM and CloudFormation have the ability to validate the syntax of the given template(s) whenever you want to. The syntax validation is as easy as using the CLI to run the validation command. The deployment itself is validated on-the-fly during the deployment phase, so you won’t know if something’s wrong until you try and deploy it.

Most of the features are the same for both of the provisioning tools. The biggest differences are the available languages to write the templates in, and the state management that’s available. My personal preference goes to CloudFormation as it’s easier to read templates written in YAML.