The cloud bill for the month arrives 40 percent higher than expected. Finance asks why. The IT team opens the platform's activity log and finds dozens of changes: a database tier increased, two new virtual machines, a storage account moved to a premium plan, a backup policy extended. Each entry shows who made the change and when. None of them says which business service it was for, whether it was meant to be permanent, or what it was expected to cost. Reconstructing the story takes three people most of a week.
This is a common gap. Infrastructure changes are recorded technically, if at all, but not in business terms. When a cost spike, an outage or an audit question arrives, nobody can quickly connect a change to the reason it was made.
The problem in plain language
Every infrastructure change has a business reason: a new branch opening, a slow report, a customer complaint, a vendor requirement. That reason usually lives in someone's head, a chat message or an email thread. The change itself is made in a console or a script, and the only lasting trace is a technical log entry. Typical signs include:
- changes made directly in the cloud console with no ticket or note;
- change tickets that describe the technical action but not the service affected;
- no record of whether a change was temporary, such as extra capacity for a month-end run;
- cost increases that finance cannot match to any decision;
- incident reviews that start with the question “what changed?” and take hours to answer.
What the buyer is actually trying to solve
People search for why the cloud bill went up, how to track infrastructure changes, how to link changes to cost, or what a lightweight change process for a small IT team looks like. Finance managers want to know who approved a spend increase. IT managers want to know which change broke a service. Both are asking the same question: when something changed, what was it for, and who agreed? The underlying need is a short, consistent record that ties each change to a business service, a purpose and an expected effect.
Evidence and system mechanism
Platforms record the what and the who, not the why
Microsoft's documentation on the Azure activity log explains that the platform records management operations such as creating a virtual machine or changing an access policy, along with who initiated them. Entries are kept for 90 days by default and then deleted unless they are exported elsewhere. The log is valuable, but it contains no field for the business service, the reason or the expected cost. After three months, even the technical trail is gone unless someone planned for it.
A change record should be the first place to look
AWS's whitepaper on change enablement in the cloud argues that change management, like finance, exists to manage business risk, and that an effective record of change should be one of the first troubleshooting references when an incident occurs. It favours frequent, small and reversible changes, and notes that peer review within a team can manage risk as well as a central approval board. The point is not more bureaucracy; it is a record that people can actually use.
Impact should be analysed and shared
The AWS Well-Architected best practice on planning for unsuccessful changes asks teams to analyse the level of impact of changes, keep a documented rollback plan, and make data about changes visible to other workload owners so failures can be diagnosed quickly. It lists manual, untracked infrastructure updates as a common anti-pattern because they cannot easily be traced or reversed.
Problem owner and why-now trigger
The IT manager or infrastructure lead owns the change process. The business owners of affected services, such as the finance system owner or the e-commerce manager, should confirm the purpose and accept the impact. Budget accountability usually sits with the chief information officer, chief financial officer or chief operating officer.
The most common trigger is a cost spike that nobody can explain. Others include an outage traced to an unrecorded change, an external audit asking for evidence of change control, a new managed service provider who needs to understand the environment, or a key engineer leaving with the history in their head.
Economic consequence
- Unexplained spend. Temporary capacity becomes permanent because nobody recorded that it was temporary. The wider pattern is described in cloud costs rising without explanation.
- Slower incident recovery. Teams spend the first hours of an outage working out what changed, rather than fixing it.
- Repeated investigation. The same change is reconstructed by finance, IT and auditors separately.
- Risky clean-ups. Without a recorded purpose, nobody dares to reverse a change, so waste accumulates.
- Weak audit evidence. Approval and purpose cannot be shown after the fact.
Root cause
- Change is treated as a technical act. The record captures the configuration, not the decision.
- No link from infrastructure to services. Teams do not know which business services depend on which resources, a gap explored in when nobody knows which services depend on which systems.
- Console access is easier than the process. When recording takes longer than the change, recording is skipped.
- Heavy processes get bypassed. Long forms and weekly approval boards encourage people to work around them.
- Logs are not retained. Default retention expires before anyone needs the history.
Practical intervention
- Define a minimum change record. Five fields are usually enough: business service affected, reason, expected cost or capacity effect, temporary or permanent (with an end date), and rollback step.
- Classify changes. Routine, low-risk changes can be pre-approved as standard changes; others need a peer review; urgent changes are recorded after the fact within a set time.
- Put the record where the work happens. A ticket linked to the deployment, a pull request description, or a tag on the resource, rather than a separate spreadsheet.
- Map resources to services. Use tags or a simple service catalogue so each change can be tied to a business service automatically.
- Retain platform logs. Export activity logs to longer-term storage so the technical trail outlives the default window.
- Review monthly with finance. Compare cost movements with the change records; any unexplained increase becomes an action.
Configuration discipline more broadly is covered in why uncontrolled configuration changes create operational risk, and resource ownership in infrastructure resources without a clear business owner.
Trade-offs
Any record adds friction. Keep it short, pre-approve routine changes, and allow emergency changes to be recorded afterwards. A process that people bypass is worse than a light one they follow.
An illustrative example
Illustrative: a Durban logistics business with about 90 staff saw its cloud bill rise sharply over two months. Investigation showed that capacity added for a peak-season tracking load had never been reduced, and two test servers had been left running. The team introduced a five-field change note in its ticketing tool, tagged resources by service, and began a monthly half-hour review with the finance manager. Later cost increases could be explained in minutes rather than days.
Diagnostic questions
- For last month's largest cost increase, can you name the change, the service and the person who agreed it?
- How long are your platform activity logs kept?
- Do your change records say which business service is affected?
- Is temporary capacity recorded with an end date?
- How long did your last incident take to answer “what changed?”
What good looks like
Every infrastructure change carries a brief business record: the service, the reason, the expected effect, whether it is temporary and how to reverse it. Records sit beside the technical change, not in a separate system. Platform logs are retained long enough to support audits and investigations. Finance and IT review cost movements against changes monthly, and incident reviews begin with a list of recent changes rather than a search for one.
Where Mellorca fits
Mellorca's digital infrastructure work can design a lightweight change record, tagging and log retention that fit a small team. Mellorca's managed digital operations service can run the monthly change and cost review and keep records consistent over time.
Method note
Guidance is drawn from current cloud provider documentation; other platforms offer similar logs with different retention defaults. The example is illustrative rather than a client case. The right level of change control depends on the criticality of each service and any regulatory requirements that apply.
Sources and further reading
- Change Enablement in the Cloud - Change Enablement in the Cloud (last verified 10 October 2026)
- OPS06-BP01 Plan for unsuccessful changes - Operational Excellence Pillar (last verified 10 October 2026)
- Activity Log in Azure Monitor - Azure Monitor (last verified 10 October 2026)
Related Mellorca reading
- Why manual changes keep bypassing your infrastructure-as-code
- Why servers get upsized when nobody trusts the utilisation data
- When capacity planning only happens after something has gone down