What Should a Cloud Application Stack Provider Actually Manage?

What is cloud application stack management?

Cloud application stack management is the ongoing operation, security, change, observation and recovery of the customer-controlled layers that make a cloud application work. It is broader than creating cloud resources and narrower than an assumption that one supplier owns everything in production.

The boundary depends on the services you use. With virtual machines, your side usually retains more responsibility for operating systems and runtimes. A managed database or serverless platform transfers some lower-level work to the cloud provider, but your application code, configuration, identities, data choices, monitoring and recovery decisions still need owners. A mixed stack can have a different boundary for every service.

Which cloud application layers need a named owner?

Not every engagement needs the provider to operate all ten layers. The important point is that no layer is left between teams. If your internal engineer owns data migrations while the provider owns deployments, the release process should say exactly where the hand-off occurs and who stops or reverses a failed change.

How should responsibility change with the hosting model?

Cloud platforms use a shared-responsibility model. The platform operates parts of the underlying cloud; the customer and any contracted operator retain responsibility for the workload-specific layers. Moving from infrastructure as a service to a more managed platform changes that division, but it does not remove the customer's side of it.

• Infrastructure as a service: define guest operating-system patching, runtime support, application deployment, data configuration and customer-controlled network rules.
• Platform or serverless services: the platform covers more of the host and runtime, while your side still needs owners for code, configuration, identities, data, telemetry and recovery choices.
• Managed Kubernetes: specify control-plane, worker-node, add-on, policy, workload, upgrade, telemetry and backup ownership separately.
• Software as a service: the vendor operates the product, but your organisation still controls users, access decisions, data use and tenant configuration.
• Mixed stacks: assess every service on its own boundary instead of applying one label to the entire system.

This is why a provider's technology list is not enough. Two teams can both advertise AWS, Azure or Google Cloud while offering materially different operational coverage. The useful comparison is the work and evidence inside the boundary, not the logos outside it.

What evidence should a provider supply before you sign?

Ask for representative, redacted evidence rather than confidential access to another customer's environment. The goal is to see whether the operating process produces verifiable records, not to collect screenshots that disclose somebody else's systems.

1. A responsibility matrix covering routine work, approvals, incidents and handover
2. An example architecture and data-flow diagram with a resource inventory
3. A redacted access model and privileged-access review
4. A controlled configuration or infrastructure-as-code sample with change history
5. A monitoring view, alert catalogue and escalation path
6. Defined recovery objectives with a dated restore or recovery-test result
7. A release record showing tests, artefact identity, deployment result and rollback route
8. An incident runbook and a redacted example of tracked corrective work
9. A workload-attributed cost view with budget or anomaly alerts
10. An exit pack covering repositories, diagrams, runbooks, access transfer and supplier-access removal

Scale the evidence to the risk. A small internal prototype does not need the control pack of a regulated production system, but it still needs an owner for access, changes, data and recovery. The provider should be able to explain what is deliberately omitted and why.

Which questions expose an unclear managed-cloud offer?

• Show us the ownership boundary for every layer, including what stays with our team and the cloud platform.
• Which production actions can you take directly, and which require our approval?
• What operating evidence will we receive, and how often?
• Who owns alerts outside our normal working hours?
• When was the recovery process last exercised, and what did the exercise cover?
• How are emergency changes recorded, reviewed and reversed?
• How will we see cost by workload and be warned of unusual spend?
• What do we receive, and which supplier access is removed, when the engagement ends?

The answers should become part of the scope. A polished sales explanation does not resolve an ownership gap during an incident. A named role, a decision path and an artefact do.

What can a US$1,000 starting engagement cover?

At ApexStack, an engagement can start at US$1,000 when the first outcome is tightly constrained. For a cloud application stack, that might be an architecture and ownership review, a deployment audit, a recovery-readiness assessment or one focused pipeline or observability improvement. It is not a blanket price for operating or rebuilding a complete production estate.

A useful first phase should end with something your team can inspect: a responsibility map, prioritised risk register, tested change, working dashboard or recovery finding. Wider implementation is scoped only after the application, hosting model, access boundary and operational risks are understood.