Cloud Execution Models and Responsibility

Consider a hypothetical migration from a self-operated database to a managed service whose contract covers host patching, automated backups, and failover. Four months later an audit finds a public endpoint with a weak password. The team gained useful infrastructure support, but endpoint configuration and credentials remained its responsibility. Those duties were missed in the migration plan.

Choosing a cloud execution model means deciding which work your team will keep. AWS and Microsoft describe different responsibility boundaries by service; use those boundaries to identify the controls and operating tasks that remain.

Execution models and the work you still operate

Microsoft distinguishes IaaS, where customers manage virtual machines, operating systems, and applications; PaaS, where they deploy applications without managing the underlying VMs or operating systems; and SaaS, where they use a ready-made application. Serverless functions provide a managed execution model in which the platform schedules code within service-specific limits.

Each model combines operating responsibilities with constraints. IaaS offers control over supported operating-system images, architectures, and licensing choices, with guest patching left to you. Ordinary serverless function environments provide temporary local storage, whose lifetime is unsuitable for authoritative state. Managed durable workflow state is a separate capability; it does not make a function’s local files durable. Choose against the workload’s execution, storage, and recovery requirements.

The boundary, line by line

The shared responsibility model describes this division. AWS assigns infrastructure protection to the provider and makes the customer’s duties depend on the selected service. Record the boundary for the particular service and configuration, rather than assuming one boundary applies across a provider.

Microsoft publishes the division as a matrix, and reading it row by row is more informative than any diagram.

Responsibility	On-premises	IaaS	PaaS	SaaS
Customer data	You	You	You	You
Configurations and settings	You	You	You	You
Identities and users	You	You	You	You
Applications	You	You	Shared	Shared
Network controls	You	You	Shared	Provider
Operating system	You	You	Provider	Provider
Physical hosts, network, datacenter	You	Provider	Provider	Provider

The customer-data, configuration, and identity rows remain customer responsibilities across the matrix. Microsoft also identifies customer duties for endpoint protection and access management. Translate these categories into concrete controls: classification and protection rules, encryption choices, account lifecycle, roles, multifactor authentication, and access policies. A managed component can implement a control without deciding the customer’s intended policy.

Which explains the opening story precisely. The managed database moved the operating-system row. It did not move the configuration row or the identity row, and those are where the incident happened.

For EC2, AWS assigns guest operating-system updates, customer-installed applications, and firewall configuration to the customer. The provider operates the infrastructure underneath those instances.

For services such as S3 and DynamoDB, AWS also operates the service platform and operating system. Customers still classify and protect their data, select encryption options, and configure appropriate access permissions.

A local virtual environment develops the same habit of managing dependencies explicitly, but its isolation boundary differs from a container’s. Python venv separates package installation paths while host operating-system, native-library, and file dependencies remain. Containers add an image and process/filesystem isolation, usually sharing the host kernel. Record the boundary needed for reproducibility and operation instead of treating the two mechanisms as interchangeable.

Patching illustrates why a duty can be divided across layers. AWS describes the split: “AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.” Record which party patches each layer of the selected service so that moving infrastructure does not leave an application dependency unmaintained. A duty can be shared rather than transferred, and assuming otherwise is the most common way an unpatched system survives a migration.

For each adopted service, write down which duties moved and which remain. Keep access reviews and configuration-drift checks on the operating plan. Assign lifecycle and rotation duties for customer-managed keys and credentials according to the service contract; where the provider automates rotation, verify its configuration and monitor the result.

State is what decides the model

Ask what the workload keeps between requests and the choice narrows quickly, because each model treats local state differently.

In the standard AWS Lambda execution lifecycle, the platform can freeze an environment after an invocation and reuse it later. Initialized objects and files in the temporary directory may survive that reuse, making connection pools or downloaded models useful caches. Other execution modes have their own lifecycle rules.

Reuse is not a persistence guarantee. Lambda can replace an environment for maintenance or scaling. Conversely, a reset after an invocation error can preserve its temporary files, so a later invocation must handle leftovers safely. Keep authoritative data and accepted work in storage with an explicit durability contract.

A stateless service keeps the correctness of later requests independent of a particular instance’s previous local state. Rebuildable caches and intentionally per-instance counters are valid. Global totals, global rate limits, and accepted pending work need shared or durable coordination appropriate to their guarantees. Instance replacement can still lose in-flight work or a response; persistence, acknowledgements, retries, and effect deduplication must address that separately.

Storage lifetime depends on the storage type and failure boundary. A Docker writable layer survives stopping and starting the same container but is removed when the container is deleted; tmpfs data is lost on stop or restart. Volumes have a lifecycle independent of the container, and bind mounts use host paths, but surviving host loss still requires suitable storage and recovery arrangements. A VM can use temporary instance storage or persistent disks, with different guarantees. Stateful containers and VMs both need a plan for reattachment, restoration, backups, and lost hosts.

Elasticity is a property of your design, not of the platform

Providers sell the ability to add and remove capacity. Whether your workload benefits depends on three things the platform cannot supply.

• Requests that any instance can serve. Session state pinned to one machine makes scaling out a routing problem instead of a capacity fix.
• Retries that are safe. Scaling events cause interruptions, so work has to be repeatable without double effect — plain idempotency, and the requirement people discover after a scale-in event has charged two customers.
• Start-up fast enough for the workload. Measure whether new capacity becomes ready within the response or completion deadline. For functions, cold start frequency and initialization duration depend on traffic, runtime, and configuration. Provisioned concurrency can reduce startup delays, but reserved capacity is billed even when it receives no requests. Compare the resulting latency and cost against the required service level.

Elasticity adds or removes capacity; workload isolation limits interference. Autoscaling alone guarantees neither isolation nor a response-time target. A shared pool can use reservations, admission control, scheduling, and resource limits to bound specified forms of contention. Verify which resources those controls protect and which dependencies remain shared, including storage and downstream services.

Choosing, and what each choice costs later

Choose	When	What you accept
Virtual machines	Supported licensed or legacy software, kernel-level requirements, or a migration requiring control of the guest environment	Guest operating-system maintenance, capacity charges, and an explicit storage and recovery design; VM local storage is not automatically durable
Containers	Many services with similar runtime needs; you want the same artifact in every environment and control over how it runs	A scheduling layer you have to place somewhere — either an orchestrator you operate, or a managed container service that runs one for you and constrains what you can configure
Serverless functions	Event-driven, spiky, or low-volume work that fits execution limits and can benefit from on-demand capacity scaling to zero	Temporary execution state, cold starts, service limits, and provider-specific deployment; pre-initialized capacity and surrounding services can still incur idle charges
Managed data and platform services	Almost always, for databases, queues, and storage — unless a requirement genuinely rules them out	Configuration, data, and identity stay yours, and so does the provider’s version schedule

Container packaging leaves a separate operating decision: who runs the scheduler and hosts? A managed container service can reduce control-plane and host duties while constraining networking, scaling, or node-level customization. Your team still maintains its application images and dependencies, configures access and credentials, deploys changes, observes behavior, manages quotas and scaling settings, and responds to incidents. The exact division is service-specific. Compare those remaining duties and constraints with the upgrades, capacity planning, and expertise required by an orchestrator you operate.

Two cost questions belong in the decision rather than after it. First, compare the whole cost: staff time, on-call burden, and the skills required are part of total cost of ownership, and a managed service that is more expensive per hour is frequently cheaper per year. Second, name what leaving would take. The further up the stack you go the more the provider’s shape is baked into your code, so portability deserves a stated position — and the honest form of that position is an estimated exit cost rather than a preference for open tools.

One structural note that recurs through cloud architecture: most managed services separate the part that decides from the part that does the work — the control plane and the data plane. It is worth knowing which is which for services you depend on, because they fail differently: a control-plane outage can leave running workloads healthy while preventing any change, and a team that has not distinguished them will read one as the other during an incident.

Where to start

For one workload you are placing or moving, four questions settle most of it, in this order.

• What state must survive which failures? Identify authoritative state, storage lifetime, recovery time, and whether an external managed store meets the need. Stateful containers, VMs, and durable workflow services require different recovery designs.
• What is its traffic shape? Compare on-demand execution with reserved or minimum capacity using the same workload, service-level target, and time horizon. Include pre-initialized capacity, storage, logs, networking, and staff effort. Steady demand makes reservations worth evaluating; spiky demand makes scale-to-zero worth evaluating. Neither pattern guarantees the cheaper total deployment.
• Which responsibility rows move, and which stay? Write the answer down. This is the step that prevents the audit finding.
• What would leaving cost? Not as an objection — as a number, so the decision is made with it rather than against it.

References

• AWS, Shared Responsibility Model
• Microsoft Learn, Shared responsibility in the cloud
• AWS Lambda Developer Guide, Understanding the Lambda execution environment lifecycle
• Docker Engine, Storage
• Amazon EC2, Instance store temporary block storage
• AWS Lambda pricing
• Python, venv — Creation of virtual environments