Managed Cloud Services: A Complete Guide

What are managed cloud services?

Managed cloud services are ongoing operations of your cloud environment by an outside provider under a defined scope and service levels. The provider typically handles monitoring, incident response, patching, backups, security baselines and cost reporting, while your team keeps ownership of the applications, the data and the decisions about both.

The service is not a product you install. It is a contract, a set of runbooks and a team on call. Its value depends on how clearly the scope is written and how well the provider's people know your environment.

What does a managed cloud provider do day to day?

A managed cloud provider spends most of its time on routine work that prevents incidents, and a smaller share responding to the incidents that still happen. The routine is where the value builds.

• Monitoring and alerting: Metrics, logs and health checks with alerts routed to an on-call engineer, tuned so real problems are not buried.
• Patching: Operating system and middleware updates on a schedule, with emergency patches for critical vulnerabilities.
• Backup operations: Scheduled backups, retention rules, and regular checks that backups completed and can be restored.
• Access management: Joiner, mover and leaver changes, privileged access reviews and multifactor enforcement.
• Configuration baselines: Infrastructure as code, drift detection and fixes when someone changes a setting by hand.
• Cost reporting: Monthly spend by account and service, idle resources flagged, and reserved capacity recommendations.
• Change management: Planned changes reviewed, scheduled in agreed windows and recorded.

Which managed service tier fits your team?

Match the tier to the skills you have in house. Buying a full service when you have a strong platform team wastes money, and buying monitoring only when nobody can respond at night leaves a gap.

• Monitoring only: The provider watches and alerts, and your team fixes. Suits teams with engineers but no overnight coverage.
• Infrastructure management: The provider runs the operating systems, networks, databases and backups, and your team runs the applications.
• Full operations: The provider also handles deployments, application monitoring and first-line incident response for your software.
• Advisory add-ons: Architecture reviews, cost optimization projects and security assessments on top of any tier.

Most healthcare software companies start at infrastructure management. It removes the overnight burden of servers and databases while the product team keeps control of releases and application behavior.

Keep cloud operations in house when the platform is a core part of what you sell, when you already have a platform team large enough for a fair on-call rotation, or when your environment changes so fast that an outside team cannot keep pace.

A mixed model is common. The internal team owns architecture, releases and the platform roadmap, while the provider covers overnight monitoring, patching and backup checks. That split keeps the knowledge in house and stops your best engineers from burning out on night alerts.

How does responsibility split between the cloud vendor, the provider and you?

Responsibility splits three ways: the cloud vendor secures its platform, the managed provider operates what runs on it within the agreed scope, and you keep accountability for your data, your users and your applications. Write the split down item by item.

AWS describes its model as security of the cloud, which AWS handles, and security in the cloud, which the customer handles. For a service such as Amazon EC2, the customer is responsible for the guest operating system, including updates and security patches, along with application software and the firewall configuration AWS provides. A managed provider takes on part of the customer's side, but only the part the contract names.

• Cloud vendor: Physical data centers, hardware, the hypervisor and the managed service internals.
• Managed provider: Operating system patching, network rules, backups, monitoring and access baselines, as scoped.
• Your team: Application code, data classification, user access decisions, vendor contracts and the final say on risk.
• Shared and easy to miss: Encryption key policy, logging retention, incident communication to customers and breach decisions.

A responsibility matrix with one row per control and one named owner per row prevents the most common argument in managed services, which is each side assuming the other was watching.

What should a managed cloud SLA promise?

A managed cloud SLA should promise response and resolution times by severity, availability of the services the provider controls, and reporting you can check. Uptime of the cloud vendor itself is the vendor's promise, not the provider's.

• Severity definitions: What counts as critical, high, medium and low, written in terms of user impact.
• Response times: How quickly an engineer acknowledges and starts work at each severity, around the clock for critical issues.
• Escalation path: Named roles and a timeline for escalating when an incident is not improving.
• Recovery targets: Agreed recovery time and recovery point objectives for each system, tested rather than assumed.
• Reporting: Monthly incident, patching, backup and cost reports, with raw data available on request.
• Service credits: What you receive when targets are missed, though credits rarely cover the real cost of an outage.

How do you test backup and disaster recovery?

Test backup and disaster recovery by restoring real systems on a schedule and timing the result against your targets. A backup job that reports success proves only that a file was written.

For healthcare organizations this is a HIPAA requirement, not just good practice. The Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan and an emergency mode operation plan, with testing and criticality analysis listed as addressable specifications.

• Restore tests: Restore a database and a file store to a clean environment every quarter, and check the data is complete.
• Region failover: Rehearse moving a critical service to a second region at least once a year.
• Account loss: Keep backup copies in a separate account with separate credentials, so one compromised login cannot delete both.
• Runbooks: Step-by-step recovery instructions that someone other than the author has followed successfully.
• Results: A written record of each test, the time taken and the fixes raised.

How do managed services keep cloud cost in check?

Managed services keep cost in check through steady housekeeping rather than one-off cuts. Spend grows quietly through forgotten test environments, oversized instances and storage nobody deletes.

• Tagging: Every resource tagged with owner, environment and product, so spend can be traced.
• Rightsizing: Instance sizes reviewed against actual use each month.
• Scheduling: Non-production environments stopped outside working hours.
• Commitments: Reserved capacity or savings plans bought for steady workloads, with the provider's recommendation and your approval.
• Storage lifecycle: Old logs and snapshots moved to cheaper tiers or deleted under the retention policy.

Agree in advance which savings the provider may act on alone and which need your sign-off. Deleting an unused volume is housekeeping; buying a three-year commitment is a business decision that belongs to you.

What does HIPAA add to managed cloud services?

HIPAA adds business associate agreements at every layer that touches protected health information. HHS guidance states that a cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is itself a business associate, even when it stores only encrypted data and has no key.

That means a BAA with the cloud vendor and a separate BAA with the managed provider, whose engineers will have administrative access. HHS also notes that service level agreements should address matters such as availability, backup and data recovery, and the return of data when the relationship ends, so put those terms in the contract alongside the BAA.

• Access logging: Every action by the provider's engineers recorded and available to you.
• Least privilege: Provider access limited to the accounts and roles the scope requires.
• Incident notice: Timelines for telling you about security incidents, short enough for your own breach duties.
• Exit: Return of configurations, runbooks, credentials and documentation when the contract ends.

How do you onboard a managed cloud provider?

Onboard a managed cloud provider in phases over several weeks, with your team still on call until the provider has handled real alerts in your environment. A hand-over on a single day leaves gaps that only appear during the first incident.

• Discovery: The provider inventories accounts, workloads, data stores, alerts, backups and existing runbooks, and lists what is missing.
• Access setup: Named provider accounts with multifactor login and scoped roles, never shared credentials or a root user.
• Baseline fixes: Gaps found in discovery, such as untested backups or missing alerts, fixed and recorded before the SLA starts.
• Shadow on-call: The provider receives alerts alongside your team for two to four weeks and practices the runbooks.
• Handover: The SLA clock starts, the escalation path goes live, and the first monthly report sets the baseline.

Ask for the discovery findings in writing. They show how carefully the provider looked at your environment and give you an honest starting picture of risk.

How Agnotic can help

Agnotic Technologies runs AWS and Azure environments for healthcare software companies and providers: monitoring and on-call, patching, backups with tested restores, access reviews, cost reports and infrastructure as code, under a BAA and a written responsibility matrix.

Clients choose the tier that fits their team, and keep full access to their accounts, code and documentation, so they can bring operations in house or move providers without starting over.

Sources

• AWS: Shared responsibility model
• HHS: Guidance on HIPAA and cloud computing
• 45 CFR 164.308: Administrative safeguards