Cloud Planning
Cloud hosting and compute selection
Choose cloud compute by comparing application constraints, operating responsibility, demand, total cost and region fit.
Match cloud compute to the application's requirements, the control it needs and the work your team can operate. A virtual machine may suit software that needs guest operating system access. Managed application hosting may suit an application that fits a platform's runtime and deployment rules. Check the proposed configuration before drawing conclusions about performance, recovery or total cost.
Start with the application’s constraints
Record the runtime, operating system dependencies, background processes, local file use, external connections and demand pattern. Separate genuine requirements from habits inherited from the current server. If hosting instances can be replaced, application data needs a deliberately chosen place to persist.
Assign an owner for runtime updates, operating system patching where applicable, deployment, access, monitoring and incident response. The division of work varies by service; managed hosting does not remove responsibility for the application and its data.
Shortlist the hosting model
| Model | Consider it when | Check before selecting it |
|---|---|---|
| Virtual machines | The application needs guest operating system control or software a managed platform cannot run | Patching, images, scaling, health checks, disks and operator capacity |
| Managed application hosting | The application fits the supported runtime or container contract | Runtime restrictions, request limits, background work, persistent data and plan billing |
| A task or worker service | Work runs on a schedule or continues outside a user request | Trigger, execution limits, retries and worker capacity |
These are starting points, not interchangeable product categories. Check the exact service, plan and region: limits and billing units differ even within one provider.
For a concrete IaaS example, AWS says customers using Amazon EC2 manage the guest operating system, including updates and security patches, installed application software and utilities, and the instance security group firewall. Use the chosen service's responsibility model to confirm which of these tasks your team must perform; service choice and integration affect the division of work.
Cloud Hosting Models: Key Considerations
- Virtual Machines (IaaS)Best for apps needing OS control or custom software; requires patching, scaling, and security management by customer.
- Managed Application Hosting (PaaS)Ideal for apps fitting runtime or container contracts; reduces OS and infrastructure management but limits customization.
- Task or Worker ServiceSuitable for scheduled or long-running background tasks; supports retries and execution limits.
Pros and Cons of Managed Application Hosting (PaaS)
- ProsReduced infrastructure management, faster deployment, built-in scaling, automatic updates.
- ConsLimited OS access, runtime restrictions, potential vendor lock-in, less control over underlying resources.
Choose by execution shape
Some platforms offer distinct ways to run code. For example, Google Cloud Run services handle HTTP requests at a stable endpoint, while jobs run tasks manually or on a schedule until completion. Worker pools handle always-on background work, such as processing messages, and instances support long-lived workloads that need a single runtime environment.
Design for the demand pattern
Estimate quiet, normal and busy periods separately. A request-driven service with long idle periods may suit a platform that can scale down, if startup delay and execution rules are acceptable. Scaling the application tier also increases demand on its database and other dependencies. Set and monitor appropriate scaling limits.
Label new-workload traffic figures as assumptions. For an existing application, collect request volume, concurrency, memory use, CPU use and response times over a representative period. Use those observations for an initial configuration, then check an important user action at normal and busy load.
For example, Cloud Run services automatically adjust instance counts to incoming requests, events or CPU use, and by default scale to zero when a revision receives no traffic. A minimum-instances setting can keep capacity idle or warm. If the service uses CPU while it is not processing requests, Google advises setting minimum instances to one.
Key Cloud Compute Metrics to Monitor
- Request Volume
- Measure over a representative period for baseline planning.
- Concurrency
- Track peak concurrent users to size capacity appropriately.
- Memory Use
- Monitor per-request or per-instance usage to avoid over-provisioning.
- CPU Use
- Critical for scaling decisions and cost control.
- Response Time
- Test under normal and busy load to ensure SLA compliance.
Compare the whole operating arrangement
List running capacity, persistent storage, data transfer, load balancing, logs, support and any capacity kept ready during quiet periods. Include the work needed to maintain the chosen model. A running VM, an allocated application plan and a request-billed service have different billing units.
Choose a region after checking user and dependency locations, availability of the exact configuration and applicable data handling requirements. If Australian privacy obligations apply, review where personal information and its copies are held and who can access them. An Australian region name alone does not settle overseas handling questions.
Verify who operates each control
Cloud service models change the division of operational work. Microsoft describes IaaS as leaving the customer to manage virtual machines, operating systems and applications; with PaaS, the customer deploys applications without managing VMs or operating systems. Its examples include Azure Virtual Machines for IaaS and Azure App Service and Azure Functions for PaaS.
Check the platform contract
A container-based platform may accept code packaged as a container image; Cloud Run also offers source-based deployment for supported languages and frameworks. Check whether the application can meet the platform's request-handling and runtime requirements, and whether its work is request-driven, scheduled or continuously running. Those details help distinguish an application service from a job or worker model.
Keep data and identities in the decision
The provider's infrastructure responsibilities do not transfer ownership of application data or identities. Microsoft identifies customer data, configurations and settings, and identities and users as customer responsibilities across its cloud deployment types. Include the work to protect these, and to configure, operate and monitor the controls your selected service leaves in your hands.
Record a decision you can revisit
For each viable design, record required features, operational owners, region, workload assumptions, cost components and unanswered questions. Reject an option that cannot meet a required feature or operating responsibility. Compare remaining options using the same application action and demand scenario.
Update the decision record when the application or its demand changes.
In this guide
- Virtual machines versus managed application hostingCompare VMs and managed application hosting by OS control, application compatibility, scaling and operating responsibility.
- Comparing compute pricing units with realistic workloadsBuild a fair cloud compute estimate using workload scenarios, billing units, storage and data transfer.
- Choosing a region from latency and operational requirementsShortlist a cloud region using user latency, dependent services, service availability, data handling and operating capacity.
