Booking a public cloud is easy. Operating it securely, cost-efficiently and in line with your own requirements is not. That’s exactly where the managed public cloud comes in: external specialists take on planning, implementation and ongoing operation of the public cloud environment, instead of the company carrying it all alone.
The misconception that most often makes these projects expensive: that the cloud is a data centre somebody else operates. It’s a construction kit somebody else provides. What gets built from it, and whether that is secure, remains your responsibility.
Where the responsibility boundary runs
Every major provider works with a shared responsibility model. The provider is responsible for the security of the cloud: data centres, hardware, virtualisation, the services themselves. You are responsible for security in the cloud.
What that means concretely depends on the service model in use:
| Stays with you | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data and its classification | yes | yes | yes |
| Identities and permissions | yes | yes | yes |
| Application configuration | yes | yes | partly |
| Operating system and patches | yes | no | no |
| Network configuration | yes | partly | no |
The row that explains virtually every incident is the top one: data and permissions always stay with you. A publicly reachable storage bucket, an over-broad role, an access key in source code: those aren’t provider failures but configuration decisions.
A managed public cloud provider takes on parts of your side of that line. It does not move the line.
What a managed public cloud provider takes on
A Managed Public Cloud Provider (MPCP) typically covers several layers:
- Project preparation and planning: target picture, architecture, roadmap
- Migration support: moving existing workloads
- Infrastructure operations: monitoring, backups, security
- Platform services: DevOps, capacity planning
- Application operations: management at the application level
How far each of those actually extends is the real subject of negotiation, the questions that settle it are further down.
Why a managed approach at all?
The major cloud providers have millions of customers and correspondingly limited individual support. An MPCP fills exactly that gap: personal guidance, cost optimisation, ensuring security and compliance and, above all, the cloud expertise most companies simply lack in-house. Studies have shown consistently for years that a large share of companies rely wholly or partly on external experts for their cloud transformation.
There’s also a sober staffing reason: cloud architecture, automation and cloud security are three separate specialisations. Looking for them in one person rarely works; hiring three doesn’t pay off for most organisations.
The difference from a traditional MSP
MPCPs are considered “next-generation MSPs.” Traditional managed service providers often come from the on-premise world and don’t automatically bring genuine cloud-native capabilities: infrastructure as code, automation, cloud security models. The difference isn’t in the label but in lived cloud competence.
A practical test: how does this provider change infrastructure? If the answer is “through the console”, you’re running a data centre with a different invoice. If it’s “through versioned code with review”, you’re running a cloud. The difference shows at the latest when an environment has to be reproducibly rebuilt.
The landing zone decides the next several years
Before the first production workload moves, the foundation should exist: account structure, network segmentation, identity and permission model, logging, encryption, guardrails for permitted regions and services.
That foundation is commonly called a landing zone, and it’s the decision with the longest half-life in the entire project. A structure that grew on request can only be put in order later at considerable cost: at the latest when someone asks which team can actually reach which production data.
A good MPCP brings a pattern for this and justifies it. A poor one starts with the migration.
Cost control is an operational discipline
The most common source of disappointment after a cloud migration isn’t technology but the invoice.
The cause is nearly always the same: lift and shift. Virtual machines get copied into the cloud one to one, run there around the clock at the same sizing as before: except they’re now billed hourly instead of purchased once. Without resizing, without shutting down outside usage hours and without reserved capacity, the cloud is simply more expensive in that model.
What matters:
- Cost transparency by team and application, not just as one total
- Regular rightsizing rather than sizing by gut feel
- Shutting down non-production environments outside working hours
- Reserved capacity for anything that runs permanently anyway
Clarify in advance whether your MPCP owes cost optimisation as a service or earns a percentage of your cloud spend. The second model is common and legitimate, but it sets an incentive you should be aware of.
Which platform sits underneath is a separate decision. We compared the two large providers in AWS vs. Azure, and the European alternative in STACKIT.
What to look for when choosing
- Does the MPCP fit your workload types: enterprise applications or web workloads?
- Does it bring genuine hybrid-cloud experience where needed?
- Does it hold the relevant certifications and security competence?
- Does it build security in from the start or is it a bolt-on afterthought?
That last point is decisive: a managed public cloud without a well-considered security model merely shifts risk instead of reducing it.
Questions to settle before signing
Who owns the cloud account? Does the environment run under your own agreement with the hyperscaler, or the provider’s? In the second case, changing providers means changing not just partners but the entire environment.
Who holds administrative access, and how is it logged? The provider needs far-reaching rights. Traceability of who changed what and when isn’t a statement of distrust: it’s operational baseline.
What exactly is included in “operations”? Patching the operating systems? Backup and verified restore? Response to security events or only to availability incidents?
Who detects attacks? Availability monitoring is not security monitoring. If the MPCP has no detection mandate, you need a separate arrangement: how those differ is set out in SIEM, SOC, MDR.
What does exit look like? Are infrastructure definitions versioned and accessible to you? An environment only the provider can reproduce is a dependency regardless of contract term.
How Cloud Cape helps
We think cloud operations and security together: Cloud First, but never at the expense of protection. In our Consulting & Project Management engagements we guide selection, architecture and migration vendor-neutrally; ongoing protection can be validated continuously through our Continuous Threat Exposure Management.
Talk to us about Consulting & Project Management. We bring cloud operations and security into one pair of hands.