India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud Infrastructure Management: Changes, Drift and Lifecycle in Code
Cloud infrastructure management is the routine operation of compute, network, storage and identity resources after they go live: fulfilling change requests, keeping deployed state aligned with code, tracking end-of-life components and maintaining DNS and certificates. NTSPL runs this as a managed service with request SLAs, every change made through Terraform or Bicep, for teams whose engineers should be building product instead.
Delivered on
In scope
Running Cloud Infrastructure After Go-Live
After migration, infrastructure work does not stop; it fragments. Developers raise 40 to 150 small requests a month: open a port, add a subnet, resize a disk, create a storage bucket, renew a certificate. Most are done by hand in the console because the Terraform repository is out of date, which makes the repository even more out of date. Within a year we typically find 15-30% of resources that exist in no code, security groups with 200 rules nobody can explain, and a list of operating systems and instance families nearing end of support that nobody is tracking.
NTSPL runs infrastructure as a service desk backed by code. Each request type has a form, an approval rule and an SLA; the change is made as a pull request against your repository, reviewed and applied by pipeline. A nightly drift scan compares deployed state with code and opens tickets for every difference. A lifecycle register tracks OS, runtime, Kubernetes and database versions against vendor support dates so upgrades are planned two quarters ahead.
When Infrastructure Requests Start Slowing Delivery
Signals you need Cloud Infrastructure Management
- Developers wait more than three working days for routine infrastructure requests
- A drift scan or audit finds over 15% of resources not represented in any IaC repository
- Security groups or NSGs carry hundreds of rules with no owner or ticket reference
- You have OS, database or Kubernetes versions within 12 months of end of support and no upgrade plan
- Your one infrastructure engineer is a single point of failure for every change
When to choose something else
- You are still designing the landing zone or migrating; that is a build engagement, and this service starts once the design is in place
- Your estate is fully serverless with infrastructure owned by product teams through their own pipelines; a governance review is more useful than a request desk
Infrastructure Work NTSPL Takes Off Your Team
Service request desk
A catalogue of 25-40 standard request types, such as firewall rules, new environments, disk resizes and DNS records, each with a form, approver and SLA.
Change by pull request
Every change is a pull request to your Terraform, Bicep or Pulumi repository with plan output attached, peer-reviewed and applied by pipeline.
Drift detection
Nightly plan runs across all workspaces report resources changed outside code, which are either imported or reverted within five days.
Lifecycle register
OS versions, database engines, Kubernetes versions, runtimes and instance families tracked against provider and vendor support dates.
Network and certificate hygiene
Quarterly firewall rule recertification with owners, DNS zone cleanup and certificate expiry tracking with 30-day renewal.
Request-to-Pipeline Change Flow with Drift Control
Catalogue-Driven Infrastructure Change and Drift Reconciliation
Requests enter through a catalogue form, become pull requests against the IaC repository and are applied by a pipeline after review. A nightly drift job and the lifecycle register feed new work back into the same queue.
Select any component
Catalogue-Driven Infrastructure Change and Drift Reconciliation: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
How Infrastructure Is Operated on Each Provider
AWS Config records configuration history, which lets us show exactly when a security group was changed outside Terraform and by which role.
Resource Graph queries give a full cross-subscription inventory in seconds, and deployment stacks can deny changes to resources they manage, which cuts drift at source.
Cloud Asset Inventory exports to BigQuery let us join resource lists with labels and owners to find orphans across every project in the organisation.
Choices on Code, Approval and Lifecycle
Import or rebuild unmanaged resources
Import resources into code when they hold state or are hard to recreate, such as databases, VPCs and DNS zones. Rebuild stateless resources such as autoscaling groups and load balancers from modules during a change window, because imported hand-built resources carry odd settings forward. Target zero unmanaged production resources within 90 days and track the count weekly.
Who can change the console
Remove standing write access for humans in production once the pipeline is reliable, typically after 30 days of pull-request operation. Keep a break-glass role that requires a ticket number, expires in 24 hours and raises an alert when used. Non-production can stay more open, but drift there is still reported so environments do not diverge.
Approval thresholds
Auto-approve changes that only add DNS records, tags or non-production resources under a cost limit such as ₹25,000 a month. Require the service owner for production sizing changes, and the security owner for anything internet-facing, IAM-related or touching encryption keys. Any plan that destroys a stateful resource needs two named approvers.
Lifecycle lead times
Start OS upgrades 9 months before end of support, database major versions 6-9 months ahead, and Kubernetes minor versions as soon as the next release is generally available on your provider. Treat paid extended support, such as Amazon RDS Extended Support or EKS extended support, as a short bridge with a dated exit, not a plan.
Taking Over an Existing Cloud Estate
Inventory and drift baseline
Pull full inventory, run a plan against every workspace and measure unmanaged and drifted resources.
Request catalogue design
Analyse six months of tickets to define standard request types, forms, approvers and SLAs.
Pipeline and module hardening
Set up remote state, plan-review pipelines and policy checks, and refactor copied code into modules.
Import and cleanup sprint
Import or rebuild unmanaged production resources and recertify firewall rules with owners.
What you receive
Fulfilment and Hygiene Targets
| KPI | Typical target |
|---|---|
| Standard request fulfilment | Within 1 working day for 90% of requests |
| Production resources managed in code | Above 98% |
| Drift items older than 5 days | Zero |
| Components past end of support | Zero, with exceptions approved and dated |
Infrastructure Operations Pitfalls
| Risk | How NTSPL prevents it |
|---|---|
| Importing resources into Terraform triggers an unintended replace on first apply | Import in plan-only mode, reconcile attributes until the plan shows no changes, and apply in a change window. |
| Pipeline outage blocks an urgent fix | Documented break-glass path with mandatory follow-up pull request within one working day. |
| Firewall cleanup breaks an undocumented integration | Use flow logs to confirm zero hits for 30 days before removing a rule, and remove in batches with a rollback plan. |
Managed cloud infrastructure vs hiring a DevOps engineer: which works better?
One DevOps engineer can run a small estate, but becomes the bottleneck and single point of failure as soon as requests exceed 30-40 a month or the estate spans two clouds. Leave, attrition or a production firefight stops all infrastructure work. A managed service gives you a team with defined SLAs, multi-cloud skills and continuity, at a cost often similar to one senior hire in Bengaluru or Pune. The better pattern for growing companies is both: keep a platform lead in-house who owns architecture and priorities, and let NTSPL carry the request queue, drift, lifecycle and hygiene work.
Key facts: Cloud Infrastructure Management
Cloud Infrastructure Management in Practice
2 Cloud Infrastructure Management scenarios, from Coworking and flexible workspace and Logistics aggregator, plus related platform case studies.
Coworking operator clears a 130-ticket backlog and brings 94% of Azure into code
Logistics aggregator ends AWS and Google Cloud drift and retires 38 end-of-life servers
Specialty chemicals group links 6 plants and HQ to AWS with dual-path hybrid network
Container terminal links TOS, gate automation and Azure over dual ExpressRoute
Cloud Infrastructure Management: Frequently Asked Questions
How is cloud infrastructure management priced?
We price on estate size and request volume. A typical estate of 100-250 resources with up to 80 requests a month starts around ₹1.8 lakh a month. The initial import and cleanup sprint is a fixed fee, usually four to six weeks of effort depending on how much is unmanaged.
Do we need Terraform already?
No. If you have none, we generate code for existing resources using provider export tools and Terraform import blocks, then clean it into reusable modules. If you prefer Bicep on Azure or CloudFormation on AWS, we use those instead; the request, review and drift operating model stays the same.
Can our developers still create resources?
Yes, in their sandbox and non-production accounts within policy limits on regions, sizes and spend. For production, they raise a catalogue request or submit a pull request themselves, which we review and apply. This keeps delivery speed while ending undocumented production changes.
How do you handle data residency for Indian workloads?
We enforce allowed-region policies through SCPs on AWS, Azure Policy and Organization Policy on Google Cloud, typically limiting production to Mumbai and Hyderabad, Central and South India, or Mumbai and Delhi. That supports DPDP Act 2023 obligations and sector rules such as RBI's payment data storage directive.
What happens with end-of-support Windows servers?
We flag them in the lifecycle register and plan in-place or rebuild upgrades. Windows Server 2012 and 2012 R2 Extended Security Updates ended on 13 October 2026, so any remaining instances are now unpatched and are treated as priority exceptions with isolation until upgraded.
Will you work alongside our existing MSP or vendor?
Yes. We often run infrastructure while another vendor supports the application. A RACI agreed at onboarding defines who owns which layer and who approves what, and shared tickets carry both teams' notes, so handoffs during an incident or a change window do not lose context.