Key takeaways
- A DevOps AMC is a 12-month contract to monitor, maintain, secure and improve your pipelines, cloud and Kubernetes platform, not your laptops and printers.
- Compare AMCs on response times by severity, coverage hours and the monthly hour bank, not the headline price.
- Insist on root-cause analysis, patching, DR drills and a monthly report in writing. "Alert monitoring only" is not an AMC.
- An AMC works best on a platform the provider built or stabilised, so most start after a 3- to 6-month enablement.
What is a DevOps AMC?
An annual maintenance contract (AMC) is a familiar idea in India: you pay a fixed amount for a year and the provider keeps something running. Most AMCs on the market cover hardware, desktops, networks or packaged software. A DevOps AMC is different. It covers the systems that build, ship and run your software: CI/CD pipelines, cloud infrastructure, containers and Kubernetes, monitoring, backups and security controls.
The goal is simple: your developers keep shipping features while a specialist team keeps the platform secure, patched, observable and recoverable, with response times agreed in writing.
What a good DevOps AMC covers
- Monitoring and incident response: alerts are watched, incidents are triaged and fixed, and every major incident gets a written root-cause analysis.
- Patching and upgrades: operating systems, container images, Kubernetes versions and dependencies are updated on a planned schedule.
- Pipeline maintenance: CI/CD stays fast and reliable as code, tools and teams change.
- Security hygiene: vulnerability fixes, access reviews, secret rotation and hardened (CIS) baselines.
- Backups and disaster recovery: backups verified, restores tested and DR drills run with a report.
- Cost control: monthly review of cloud spend with right-sizing recommendations.
- Reporting: uptime, incidents, changes, cost and recommended improvements every month.
If a proposal lists only "24×7 monitoring", ask what happens after the alert fires. Monitoring without fixing is a notification service, not maintenance.
SLAs, severity levels and hour banks
Every DevOps AMC should define severity levels and the response you get for each. A typical structure looks like this:
| Severity | Example | What to agree |
|---|---|---|
| P1 · Critical | Production down, data at risk | Response within minutes to 1 hour, 24×7 on higher tiers, continuous work until restored |
| P2 · High | Major feature degraded, failing deployments | Response within a few hours during covered hours |
| P3 · Medium | Non-urgent fault, slow pipeline | Next business day |
| P4 · Request | New environment, access change, small improvement | Scheduled, drawn from the monthly hour bank |
Response time is when an engineer starts working; resolution depends on the problem. Be wary of contracts that promise fixed resolution times for every issue: nobody can honestly guarantee that.
Most AMCs include a monthly bank of hours for planned work such as upgrades and small changes. Agree in advance what happens to unused hours (expire or roll over) and the rate for work beyond the bank.
Coverage windows and tiers
Coverage hours drive cost more than anything else. Business-hours support (for example 8×5) suits internal or stable systems. Customer-facing platforms usually need extended hours, and payment or banking systems need 24×7 on-call for critical incidents.
Providers usually package this into tiers. At CItoCD we use Essential, Standard and Premium AMC tiers, each with agreed response times, an hour bank and a monthly report.
How DevOps AMCs are priced
- Fixed monthly fee by tier: the most common model; predictable for budgeting.
- Hour bank plus overage: a set number of hours per month, with extra hours at an agreed rate.
- Per environment or per cluster: useful when you run many similar environments.
- Annual prepayment: providers often discount for paying the year in advance.
For typical market price ranges in India, see our DevOps services cost guide.
Questions to ask before you sign
- Who exactly will work on our platform, and how do they learn it?
- What are the response times by severity, and during which hours?
- Is root-cause analysis included for major incidents?
- How often do you patch, and who approves production changes?
- When was the last DR drill, and will we receive the report?
- Is all infrastructure defined as code in our repositories?
- What happens to our access, data and documentation if we end the contract?
Red flags
- Shared admin accounts or the provider holding your only cloud root credentials.
- No Infrastructure as Code: changes made by hand in the console.
- No documentation or runbooks you can keep.
- "Unlimited support" with no defined response times.
- Long lock-in with no exit or handover clause.
Enablement first, then AMC
An AMC is only as good as the platform underneath it. If your current setup is manual or undocumented, a provider cannot promise meaningful SLAs on it. That is why most good AMCs start with a 3- to 6-month DevOps enablement: automate, secure and document the platform, train your team, then maintain it.
We start every engagement with a free 30-day pilot on one service, so you see the quality of the work before committing to enablement or an AMC.