ITIL provides guidelines and processes for managing changes by IT. These guidelines help companies to ensure when IT makes changes–and changes are inevitable—service reliability is not jeopardized and there is no negative impact on customers’ experience. But IT also needs to make changes fast, especially if you are on cloud. Cloud’s main draw is that you no longer have to wait days or months for resources. But wait, doesn’t this contradict the first expectation of reliability? Yes, it does, but with the help of proper processes and tools, IT can ensure readability and enable rapid changes in services.

Cloud makes rapid changes easy, and sources of change are ever increasing. Each department has its own workflow to launch resources. I am sure some departments in your organization launch resources using Terraform, some use AWS CloudFormation, and a few people don’t believe in this automation nonsense. They simply go rogue, launch resources directly from the console, and then forget to shut them down when with it. If this sounds like your company, congratulations you are on cloud!

So that begs the question, what constitutes change management in cloud?

Two key elements are imperative for effective change management in cloud.

Infrastructure delta

One of the most appealing benefits of cloud is that you can scale up and down based on your needs. Most companies heavily leverage auto scaling; new resources can be launched based on specified metrics. But this behavior makes change management difficult. If new resources are appearing and disappearing, how do we track what truly changed in the infrastructure? To gain a true picture, we need an infrastructure delta, which shows resource updates for a given time period for only the resources still running.

Define the ideal infrastructure

So, your organization is on cloud, and you are taking full advantage. Your developers don’t have to wait for resources, and cloud is helping your team be more productive. Now, you simply can’t stop everyone from launching new resources because you need to implement a new change management process, but you can define the infrastructure’s appearance. For example, every resource should have a tag, and each tag should contain Terraform. If anyone launches resources that violate this policy, IT will receive real-time alerts with the context. Context is extremely important. If you know who launched the resource, the resource name, which environment resource belongs to, and which policy it’s violating, then, IT can work with developers to resolve that issue.


We built nOps just to address these key elements. Our change management feature allows you to review all the newly introduced resources, be it changes or documents, and it’s valuable to know the original purpose of the AWS S3 bucket a year after that bucket was created.


nOps rules are our way of allowing Ops to define policies concerning the infrastructure’s appearance. These policies can be easily enabled across all accounts, and you receive real-time notifications with the complete context anytime there is a violation of a specific rule.


Sign up for a 15-day free trial, and stay on top of all of your cloud changes.