Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Managed cloud services: what to expect from a provider in 2026 What managed cloud services should cover in your AWS or Azure account: access, security, patching, backups, cost control, reporting and a clean exit.
A typical starting point: a company has an AWS or Azure account that a former developer set up. It runs the website, an API and a database. The bill has crept up, nobody is sure which resources are still needed, and the only admin login belongs to someone who left. They start looking for a managed cloud provider and find that every proposal uses the same words for very different amounts of work.
The direct answer: with managed cloud services, a provider runs the day-to-day operation of your cloud account while you keep ownership of it. Expect named, auditable access; a security baseline; scheduled patching; backups with tested restores; monitoring with agreed response times; active cost control; a change log; a monthly report; and a documented way to leave.
This article is about the cloud account itself. If your question is mainly about looking after individual Linux servers, our piece on what server management services include covers that layer in more detail.
Who owns the account, and how the provider gets in Settle this first, because everything else depends on it. The cloud account, the billing relationship and the root or global administrator credentials should belong to your organisation. Some providers resell cloud capacity through their own accounts. That can be convenient, but it makes leaving hard: your resources, logs and backups sit in someone else's account.
The provider should get in through access you can see and revoke. On AWS, that usually means users in IAM Identity Center or a cross-account role that their engineers assume. On Azure, it means guest or member accounts in Microsoft Entra ID with role assignments scoped to the right subscriptions, or Azure Lighthouse delegation. Shared passwords and long-lived access keys handed over by email are a warning sign.
A cross-account role on AWS is easy to inspect. The trust policy names exactly which outside account can assume it, and an external ID guards against the confused deputy problem when a third party manages several customers. Ask how the provider enforces MFA for its own engineers. A condition on aws:MultiFactorAuthPresent looks tidy, but that key is often absent when people sign in through IAM Identity Center or another identity provider, so it can block legitimate access without adding much.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "agreed-random-value" }
}
}
]
}Removing the provider then becomes one action: delete the role. You should also be able to see every action they take, which is why audit logging comes next.
The first month: an inventory and a baseline A good provider does not start by changing things. They start by finding out what you have. Expect a written inventory of every region in use, every resource and what it is for, every user and access key, and every public endpoint. Resources nobody can explain should be listed for a decision, not quietly deleted.
Alongside the inventory, they should put a minimum security baseline in place and tell you what they changed:
Multi-factor authentication on the root user or global administrators, with those credentials stored somewhere only your organisation controls. Named logins for every person, with no shared accounts and no unused access keys. Audit logging switched on and kept: an AWS CloudTrail trail delivered to a protected bucket, or the Azure Activity Log sent to a Log Analytics workspace or storage account. A threat detection service reviewed regularly, such as Amazon GuardDuty or Microsoft Defender for Cloud. No databases, admin ports or storage buckets exposed to the internet unless there is a written reason. Budgets and spend alerts, so a runaway resource is noticed within days rather than at month end. A quick test of how seriously a provider takes access is to ask what they would look at first. On AWS, the IAM credential report is a good answer. It lists every user, whether they have MFA, and when each password and access key was last used.
aws iam generate-credential-report
# repeat until State is COMPLETE, then download
aws iam get-credential-report --query Content --output text \
| base64 --decode > credential-report.csvThe routine work, month after month Once the baseline is in place, most of the value is in work that happens quietly and on schedule. A managed cloud service should cover at least the following, with the detail written into the agreement.
Operating system patching for virtual machines through AWS Systems Manager Patch Manager or Azure Update Manager, applied to staging first and inside an agreed maintenance window. Engine version tracking for managed services such as Amazon RDS, Azure Database for PostgreSQL, Kubernetes clusters and Lambda or Functions runtimes. These reach end of support on the provider's timetable, not yours. Backup policies through AWS Backup or Azure Backup, with copies in a separate account, region or vault, and a restore tested on a schedule. Monitoring and alerts in CloudWatch or Azure Monitor for health checks, disk, memory, error rates and certificate expiry, routed to people who will act. Small changes handled as tickets: DNS records, certificates, security group rules, new environments or an extra instance. Retirement notices read and acted on. Both clouds announce deprecations by email and in their health dashboards, and those emails often go to an inbox nobody watches. Version tracking deserves a specific mention because it now costs money when ignored. Amazon RDS charges for Extended Support when a MySQL or PostgreSQL major version passes its end of standard support. A provider should give you a list of upcoming end-of-support dates with a planned upgrade for each, well before the charges or the forced upgrades begin.
Cost control should be active, not a dashboard Many managed cloud offers mention cost optimisation. In practice that ranges from sending you a screenshot of Cost Explorer to actually changing things. Expect the provider to do the work and explain each change.
Tagging resources by environment, application and owner, so the bill can be read by someone outside engineering. Removing idle resources: unattached disks and volumes, old snapshots, unused public IPv4 addresses (AWS charges for these), idle load balancers and forgotten test environments. Right-sizing instances and databases using real utilisation data, not guesses. Scheduling non-production environments to stop outside working hours where that is practical. Recommending Savings Plans or reservations only once usage has been stable for a few months, because a one- or three-year commitment you stop using is money you cannot get back. Watching storage and data transfer, which are often the lines that grow without anyone noticing. Ask how the provider is paid. If their fee is a percentage of your cloud spend, they have little reason to reduce it. A fixed monthly fee for an agreed scope keeps the incentives straight.
Incidents, response times and what is out of scope Every provider will say they handle incidents. What matters is the detail. The agreement should state the hours of coverage, how quickly they respond to each severity, how you raise an urgent issue outside office hours if that is covered, and who decides when to escalate to AWS or Microsoft support. Coverage hours and response times vary a lot between providers and plans, so get them in writing rather than relying on a sales call.
After an incident, expect a short written review: what happened, how long it lasted, the cause, and what will stop it happening again. Without that, the same problem tends to come back.
Be equally clear about what is not included. Managed cloud usually means the platform, not your application code. Bugs in your software, new feature work, large migrations and redesigns are normally separate projects. A provider that is vague about this boundary will either disappoint you or send unexpected invoices.
Reporting, documentation and a clean exit You should not need to log in to the console to know how your cloud is doing. A monthly report should cover patches applied, incidents and their causes, restore test results, spend against budget, upcoming end-of-support dates and decisions the provider needs from you. Two pages is usually enough.
Documentation matters most on the day you leave. Ask for these to live in your own repositories and accounts: infrastructure as code where it exists, runbooks for common tasks and failures, an architecture diagram, the access list, and the backup and restore procedure. Ask the provider to describe their offboarding process before you sign. A confident answer is a good sign. Hesitation usually means the knowledge lives only in their engineers' heads.
Questions to ask before you sign Whose account will our resources and backups live in, and who holds the root or global administrator credentials? How will your engineers access our account, and how do we remove that access in one step? Which tasks are in the monthly fee, and which are billed separately? What are the coverage hours and response times for each severity, in writing? How often do you test restores, and will we see the results? How are you paid, and does that reward lowering our cloud bill? What do we receive if we end the contract, and how long does handover take? If you already have a provider, the same list works as a health check. Any question you cannot answer from your contract or last month's report is worth raising with them now, not during an outage.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789