Cloud Compute Options

A virtual machine (VM) is a computer defined in software. It has virtual processors, memory, disks, a network connection and its own operating system. A hypervisor divides a physical server among VMs and keeps them isolated. A running cloud VM is also called an instance.

Choose the resources

The core services are Amazon EC2, Azure Virtual Machines and Google Compute Engine. Each rents you infrastructure; you manage the operating system and application. This is infrastructure as a service (IaaS).

Launching a VM involves several connected choices:

• Location: a region and, where offered, an availability zone.
• Image: a template containing the operating system and preinstalled software. AWS calls it an Amazon Machine Image (AMI); Azure and Google offer public and custom images.
• Size: the vCPUs, memory and related capacity. A vCPU is the processing unit assigned to the VM.
• Disk: persistent storage from which the operating system boots.
• Network: an interface in a subnet, plus traffic rules. A public IP address is optional.

AWS uses EBS volumes, VPC subnets and security groups. Azure uses managed disks, VNet subnets and network security groups. Google uses persistent disks, VPC subnets and firewall rules. The names differ, but the resources serve comparable roles.

Follow a launch decision

A team needs a Linux web server in Frankfurt. It selects the Europe (Frankfurt) Region, an Ubuntu AMI and m7g.large, with 2 vCPUs and 8 GiB of memory. It adds a 30 GiB EBS boot volume and connects the VM to a VPC subnet. Its security group allows HTTPS on port 443 from the internet and SSH on port 22 only from the office network. The image supplies the software starting point; the size supplies computing capacity; the traffic rules decide who can connect.

Track the lifecycle and the bill

A VM is created, runs, can be stopped and started, and is eventually deleted. Compute charges accrue while it is allocated for running, even if CPU use is near zero. Stopping normally ends compute charges, but retained disks and reserved public IP addresses can still cost money. On Azure, check for "Stopped (deallocated)": shutting down inside the guest operating system can leave the VM in "Stopped", with compute still billed.

Temporary local disks are different from persistent boot disks. AWS instance store, Azure temporary disks and Google Local SSD keep data on the physical host; stopping, moving or deallocating a VM can lose it. Put files that must survive in persistent storage. After deleting a VM, review retained billable resources. A security group alone has no standalone charge, while an undeleted disk can keep generating one.

Know who maintains it

The provider maintains the datacenter, physical hardware and hypervisor. You patch the guest operating system, update installed software, protect data and manage access and firewall settings. Renting a VM does not transfer guest patching to the provider.

A dedicated host reserves a physical server for your use, useful for licenses tied to physical cores. A bare-metal instance exposes hardware without a hypervisor layer. Azure Virtual Desktop and Amazon WorkSpaces instead stream cloud-hosted desktops to users' devices.

An instance family sets the balance of processing, memory, storage and accelerators. Its size sets how much of those resources you get. Choose the family from the workload's main need, then choose a size that meets all its requirements.

Recognize the main families

Fast local storage does not make data persistent. A workload that uses storage-optimized instances still needs a plan for data that must survive host loss.

Read the name

In m7g.large, m means general purpose, 7 is the generation, g indicates AWS Graviton and large is the size. The same family grows from 2 vCPUs and 8 GiB at large to 4 vCPUs and 16 GiB at xlarge, then 8 vCPUs and 32 GiB at 2xlarge.

In Azure's Standard_D4s_v5, D is the family, 4 is the vCPU count, s indicates premium SSD support and v5 is the version. Google's e2-standard-4 names the E2 series, standard memory ratio and 4 vCPUs. A vCPU is often a hardware thread; on Graviton it is a whole core. Do not treat every provider's vCPU as an identical physical core.

Work through a sizing choice

An internal reporting app needs 2 vCPUs and 6 GiB at peak. Compare these AWS sizes:

• c7g.large: 2 vCPUs and 4 GiB; memory is insufficient.
• m7g.large: 2 vCPUs and 8 GiB; both requirements fit, with 2 GiB spare.
• r7g.large: 2 vCPUs and 16 GiB; it supplies much more memory than this app needs.

The general-purpose size is the sensible starting point. Its memory per vCPU is $8÷2=4$ GiB. The compute-optimized and memory-optimized choices provide 2 and 8 GiB per vCPU, respectively. Google's E2 highcpu, standard and highmem 4-vCPU types similarly vary memory: 4 GB, 16 GB and 32 GB.

Right-sizing means measuring real use and adjusting the choice. Inspect memory, disk and network use alongside CPU before downsizing. AWS Compute Optimizer, Azure Advisor and Google's machine type recommendations can help. Resizing an existing VM requires a stop or restart, so plan for interruption to a single-server app.

Distinguish bursts from interruption

Burstable AWS T, Azure B and shared-core Google E2 types suit quiet workloads with short peaks. AWS T and Azure B earn CPU credits below a baseline and spend them above it. When credits run out, Azure B and AWS T standard mode return to baseline; current AWS T types default to unlimited mode and can charge for surplus CPU.

Spot VMs use spare capacity that the provider can reclaim at short notice. They fit restartable batch work with saved progress. A single production database is a poor match. Google's older preemptible VMs also have a 24-hour maximum lifetime; that limit is not the defining rule for modern Spot VMs.

A service faces two different problems: more work arriving, and equipment failing. Scaling changes capacity. High availability keeps the service usable when parts fail. A design can solve one problem while leaving the other unresolved.

Change size or change count

Vertical scaling changes one machine's size: for example, 2 vCPUs and 8 GiB become 8 vCPUs and 32 GiB. Scaling up adds resources; scaling down removes them. It is a direct way to give an existing application more capacity, but the machine must usually restart, the largest size is finite, and the machine remains one failure point.

Horizontal scaling changes the number of copies. Three web servers can become nine, then return to three. Scaling out adds instances; scaling in removes them. A load balancer shares web requests, while background workers can take jobs from a shared queue. The application must support multiple copies doing useful work together. A shared database can still limit throughput or fail even when many web servers remain healthy.

Scalability is the ability to handle more work by adding resources. Elasticity is automatic, timely growth and shrinkage as demand changes. A shop that automatically changes from 4 servers at night to 20 during a sale is elastic. A fixed fleet with spare capacity may be highly available without being elastic.

Make copies replaceable

A stateless application instance keeps no unique data needed by a later request. Store carts, sessions and uploaded files in a shared database, cache or storage service. Then a request can reach any instance, and scaling in can remove one without losing its users' carts.

For example, a cart held only in one web server's memory disappears when that server is terminated. Keeping the user on that server with a sticky session does not protect the cart from server failure. Moving the cart into shared storage changes what can safely be removed.

Keep enough capacity after a zone fails

Availability zones are separate locations within a region with independent power, cooling and networking. Spreading instances across zones protects against a whole zone failing. Several instances in one zone still share that zone's risk.

Suppose an application must retain the capacity of 4 instances after losing any one of 3 zones. The two surviving zones must each supply 2 instances:

Run 2 instances in each zone, for 6 total. Losing any zone leaves 4. This is spare capacity for failure, not an increase in the workload's normal requirement. A load balancer directs requests to the survivors; any shared data service also needs suitable availability.

Recognize Azure availability sets

An availability set spreads VMs within one datacenter across hardware fault domains and maintenance update domains. A fault domain shares hardware such as power and network switches. Sets support up to 3 fault domains; update domains default to 5 and can reach 20. They reduce rack and planned-restart risks. Zones address the larger risk of an entire datacenter location becoming unavailable.

Auto scaling adds and removes instances as demand changes. Amazon EC2 Auto Scaling uses Auto Scaling groups, Azure uses Virtual Machine Scale Sets with autoscale rules, and Google uses managed instance groups with an autoscaler.

Start from a repeatable template

A new instance needs the same image, size, network settings and startup instructions as its peers. AWS uses a launch template, Azure a scale set VM model and Google an instance template. A change made by hand inside one running VM will disappear when that VM is replaced unless it is included in the repeatable setup.

The group has three capacity settings:

• Minimum: the floor the group maintains.
• Desired: the count it currently aims to run.
• Maximum: the ceiling it must not exceed.

With minimum 2, desired 4 and maximum 10, the group aims for 4 instances. Policies can move desired capacity between 2 and 10. The maximum is permission to grow; setting it to 10 does not itself run or bill 10 VMs. It caps instance count, not every charge in the application.

Choose what drives a change

Target tracking tries to keep a metric near a target, such as average CPU use of 50%. Step or rule-based scaling changes capacity when a threshold is crossed, such as adding 2 instances after CPU stays above 70% for 5 minutes. Scheduled scaling sets capacity at known times. Predictive scaling forecasts demand from past patterns and prepares capacity ahead of it.

A daily rush at 08:00 favors preparing instances before 08:00. Waiting for a high-CPU alarm means the rush has already arrived while the extra VMs are still starting.

Work out target-tracking capacity

Four identical instances average 80% CPU, and the target is 50%. For a simplified constant-load estimate, first total the work in instance-percentage units:

Divide by the target per instance:

Round up to 7 instances because 6 would leave the average above target. With 7, the estimate is $320÷7\approx 45.7\mathrm{\%}$. If the group's maximum is 6, it stops there and averages about 53.3%.

Separate readiness from failure recovery

A VM needs time to boot, run its startup tasks and pass health checks. Warm-up prevents a new instance's incomplete measurements from distorting a scaling decision. A cooldown limits rapid back-and-forth changes.

Scaling groups can also replace failed VMs to restore desired capacity. Application-level checks and repair actions need configuration: a VM can be running while its web application is broken. On Azure a repair action can restart, reimage or replace; Google calls recovery autohealing. A load balancer can detect a broken app, but the scaling group must be configured to use that information for repair.

Scaling in removes instances. Keep logs centrally and lasting data outside their local files so removing a healthy copy does not remove unique information.

A load balancer gives clients one entry address and forwards incoming traffic to healthy servers. AWS calls the server pool a target group; Azure uses a backend pool; Google uses a backend service. Clients do not need a new address whenever the pool changes.

Route traffic and detect failures

A health check repeatedly tests a target, for example by requesting /health every 10 seconds. After enough failed checks, the target is marked unhealthy and receives no new traffic until it passes again. Detection takes time because the checks run at intervals.

Routing and repair are different jobs. The load balancer stops sending new requests to a failed target. A scaling group or operator repairs or replaces that server. Adding a load balancer alone adds no application processing capacity.

Round robin takes healthy targets in turn. Least connections or least outstanding requests favors the target with less work in progress. Hash-based routing maps connection details, including addresses and ports, to a target. One connection stays together, but a new connection from the same user can land elsewhere.

Session affinity, also called sticky sessions, keeps a user's requests on one server. It can support an application with local sessions, but makes traffic less even and leaves sessions exposed to that server's failure. Shared session storage lets other healthy servers continue the user's work.

Calculate the effect of losing a server

Three healthy servers share 900 requests per minute evenly. Each handles:

One server fails its health checks. The same work now goes to two:

If each can handle only 400 requests per minute, healthy routing still leaves an overload. The pool needs spare capacity or more instances. Auto scaling changes capacity; load balancing distributes it.

Pick the layer that fits the routing

A layer 7 service can also terminate TLS, decrypting HTTPS at the entry point, and can work with a web application firewall. A layer 4 service does not inspect an HTTP path to choose its backend. Check which transport protocols a particular product supports.

AWS Elastic Load Balancing offers Application Load Balancers at layer 7, Network Load Balancers at layer 4 and Gateway Load Balancers for network appliances, within a region. Azure Load Balancer is layer 4; Application Gateway is regional layer 7; Front Door provides a global layer 7 entry point. Google Cloud Load Balancing offers Application and Network Load Balancers in regional and global forms.

Join routing to scaling

With the integration configured, new group instances register as targets and receive traffic once healthy. During removal, connection draining allows active requests to finish before a target disappears. A multi-zone deployment routes to healthy zones during an outage, provided the survivors have enough capacity. Even two servers benefit from this shared entry point and health-based routing.

A container runs an application and its dependencies as an isolated process on a host. Packaging its libraries and runtime makes the tested software repeatable in production.

Image, registry and running copy

An image is the read-only template; a registry stores and distributes images; a container is a running copy. Amazon ECR, Azure Container Registry and Google Artifact Registry provide registries. The Open Container Initiative defines standard image formats; Docker helped popularize their use.

For example, a team packages its Python orders API as orders-api:1.4, tests it, pushes it to a registry and starts 3 production containers from that image. Environment settings and access to external services still need configuration.

Share a kernel instead of booting a guest OS

Each VM carries a full guest operating system behind a hypervisor. Containers share the host's kernel, the operating-system core that manages resources and processes. They have less software to carry and start: images are often tens or hundreds of megabytes, and startup takes seconds or less. VM images are commonly gigabytes and boot in minutes. A host can therefore run more containers than full VMs.

Sharing also affects isolation. A host-kernel flaw can affect several containers, while separate guest kernels give VMs a stronger boundary. Linux containers need a Linux kernel; Windows containers need Windows. The image must also match the processor architecture, such as x86 or Arm. Containers often run on cloud VMs.

Replace software and preserve data

Update a container by building a corrected image and replacing old copies. A hand patch disappears on replacement and leaves other replicas unchanged.

The same applies to runtime files in the writable layer. An invoice generated there must be saved to a persistent volume or storage service before replacement. The image registry preserves application packages, not documents created by running containers.

Separate services when that helps

A monolith deploys as one unit. Microservices split an app into network-connected services that deploy and scale separately. A store can add payment-service containers without adding catalog-service copies.

An orchestrator places containers across hosts, restarts failed copies, scales them, rolls out versions and connects services. Kubernetes does this, as do simpler managed container services. Containers do not require Kubernetes.

Kubernetes deploys and manages containers across a group of machines called a cluster. It is open source, originated at Google and is maintained within the Cloud Native Computing Foundation. The same platform can run across clouds and private datacenters.

Understand the cluster's parts

The control plane stores configuration, schedules work and coordinates the cluster. Worker nodes, usually VMs, provide the processing and memory that containers consume.

A pod is the smallest unit Kubernetes schedules. It contains one or more containers that share a network address and stay together on one node. A pod is not a separate VM. Several pods can share the same worker node if their resource needs fit.

You declare a desired state: for example, 3 replicas of orders-api:1.4. Kubernetes works to keep 3 pods running. When a pod fails, it creates a replacement; after a node fails, replacement pods can run on surviving nodes with available capacity. A Kubernetes Service provides a stable name and address for reaching pods even as their individual addresses change.

Scale pods and machines separately

A horizontal pod autoscaler (HPA) changes pod count using metrics such as CPU demand. A cluster autoscaler changes node capacity when pods cannot fit or nodes become unnecessary. Adding pods without room to run them creates pending work, not more processing capacity.

Suppose each pod requests 0.5 vCPU and each node has 2 vCPUs available for pods. Ignore other resource limits for this example. One node can hold:

If the HPA raises the desired count to 10 pods, two nodes hold only 8. The requirement is:

Round up to 3 nodes. The third node supplies room for the last 2 pods. Use capacity available for pods, because the node's operating system and Kubernetes components also need resources. In real scheduling, memory and placement rules matter alongside CPU.

Divide management responsibilities

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) run managed control planes. The provider maintains that control plane, including its availability and updates. You manage images, application settings, access and workload resource requests. In many modes, you also manage worker-node choices and updates. Cluster fees can be separate from node charges.

GKE Standard leaves node choices with you and bills for the node VMs. GKE Autopilot provisions and manages nodes, generally charging for requested pod resources. EKS can run eligible pods on AWS Fargate so you do not manage the node VMs. These modes reduce operational work while limiting some host choices.

Decide whether the complexity helps

Kubernetes fits many independently deployed services and teams that need a common platform across providers. Its tools and workload definitions improve portability, though attached cloud databases, identity systems and networking can still require changes.

For one simple web app, a hosting platform or serverless container service can take less work. Managed Kubernetes does not fix a bug in your image or choose the right memory request for you. If an app repeatedly runs out of memory, the team must diagnose the app and its settings even when the control plane is fully managed.

Serverless container services run your images on provider-managed hosts. You still select resources, maintain the image and configure the app. Scaling and billing depend on the service.

Separate orchestration from compute

Amazon ECS orchestrates containers as tasks. An ECS service maintains a desired task count, optionally behind a load balancer. Tasks run on EC2 hosts you manage or on Fargate compute.

Fargate also supports eligible EKS pods. You choose task or pod vCPUs and memory and pay while those resources run; you do not select, patch or scale the underlying EC2 hosts. ECS service autoscaling uses policies you configure. Fargate supplies compute, not the application's desired task count. ECS on EC2 retains more host and instance-family control, with more management work.

Compare Azure and Google services

Azure Container Instances (ACI) starts one container or a small group without a cluster and bills per second. It suits tests and simple finite tasks, but has no built-in autoscaling.

Azure Container Apps hides its underlying Kubernetes platform. Configured rules scale containerized apps on HTTP traffic or events, including down to zero for suitable workloads.

Google Cloud Run offers services for incoming requests and jobs that run to completion. Services can grow from zero and shrink again. Request-based compute billing covers request processing plus startup and shutdown. With no minimum instances and no running instances, idle compute costs nothing; databases and stored images can still incur charges. Cloud Run also hosts Cloud Run functions, which start from function code instead of a customer-supplied app image.

Trade idle savings for startup delay

An internal booking API is busy 08:00–18:00 on weekdays: 10 hours on 5 days, or 50 of the week's 168 hours. Occasional night requests also arrive. Cloud Run or Container Apps can run several copies at peak and reach zero between requests during quiet periods.

A request after idle time may wait for a cold start. Keeping one minimum instance warm reduces delay within its capacity and adds ongoing cost. A burst beyond that capacity can still start extra instances cold.

Choose the host control you need

These services restrict host access and impose resource and duration limits. You cannot install host agents or change the host kernel. VMs or suitable Kubernetes nodes fit those needs. For standard containerized APIs, simpler services can avoid the work of operating Kubernetes; ACI is a direct option for a simple container group.

A serverless function is code that runs when a matching event arrives. The provider manages the servers and managed runtime. AWS Lambda, Azure Functions and Google Cloud Run functions offer this functions as a service (FaaS) model.

Connect a trigger to an invocation

A trigger starts one execution, called an invocation. Triggers include HTTP requests, uploaded files, queue messages, database changes and timers. A photo upload can trigger a function that creates a 200-pixel thumbnail and saves it in storage. With no uploads, an on-demand deployment can have no function compute running.

The provider scales execution as events arrive, within concurrency and service limits. Many simultaneous functions can open many database connections. The function layer may have room to scale even when the database does not. Limit concurrency to what connected systems can handle.

Functions are stateless across invocations. A later invocation may use a new environment, so it cannot depend on an earlier call's memory or temporary files. Store counters, sessions and lasting results in a database, cache or object storage. A warm environment may be reused, but that reuse is not a persistence contract.

Calculate consumption-style usage

Lambda's standard on-demand billing combines invocation count and GB-seconds (GB-s): allocated memory in GB multiplied by running seconds. For an illustrative calculation, assume each of 3,000,000 invocations runs for 0.2 seconds with 0.5 GB of memory. Ignore free allowances and all other services.

At assumed prices of $0.0000167 per GB-s and $0.20 per million requests, compute costs $5.01 and requests cost $0.60, totaling $5.61. These are assumed prices for learning the model. Cloud Run functions also meter CPU; Azure plans may charge for ready or allocated instances.

At 100,000,000 otherwise identical invocations, usage is 10,000,000 GB-s: $167 compute plus $20 requests at those assumed rates. A VM priced at an assumed $0.04 per hour costs $29.20 for 730 hours, but a fair comparison also checks whether it can process the same work and includes its operating effort. Spiky demand favors avoiding idle capacity; steady load can favor always-on compute.

Check execution limits and startup delay

Lambda default compute allows at most 15 minutes per invocation and up to 10,240 MB of memory. A 40-minute conversion cannot fit that invocation. A container job, VM or shorter steps can fit; timeout rules differ for other plans and compute modes.

A cold start occurs when a new execution environment must be prepared, after idle time or during scale-out. Reused warm environments start faster. Lambda provisioned concurrency, always-ready instances on Azure Premium or Flex Consumption, and Cloud Run minimum instances reduce startup delays at extra cost.

The provider maintains servers and the managed runtime. You still fix your code and included libraries, protect secrets, configure permissions and secure data. Serverless removes server administration, not application ownership.

An application hosting platform takes your code or container image and provides the infrastructure for running it. It is platform as a service (PaaS): deployment, health monitoring, server operation and scaling are provided through the platform, while you build the application.

Compare the main platforms

AWS Elastic Beanstalk creates ordinary AWS resources for your app, commonly EC2 instances in an Auto Scaling group behind an Elastic Load Balancer. It handles deployments and health monitoring. Beanstalk itself has no extra service fee; you pay for the resources it creates. Those resources remain visible in your account, and you can customize their configuration.

Azure App Service hosts web apps, APIs and mobile back ends from code or containers. An App Service plan sets the region, instance size and count. Apps in that plan share those instances. Dedicated tiers bill for the plan even when the apps are quiet. Features such as autoscale and deployment slots depend on the chosen tier.

Google App Engine has standard and flexible environments. Standard uses supported runtimes in a sandbox and can scale to zero with suitable automatic scaling. Flexible runs containers on Compute Engine VMs, permits more customization and keeps at least one instance running. Cloud Run is another route for hosting an app already packaged in a container.

Release a new version safely

A two-person store team uses an App Service tier with deployment slots. It runs 2 instances and deploys a new version into a staging slot, a separate place to test the release before customers use it. After testing, it swaps staging and production. The old version remains available in the other slot for a possible rollback.

During a sale, its configured autoscale rule raises the plan to 5 instances after average CPU remains above 70%, then returns to 2 as demand falls. The platform carries out the scaling, but the team still selects the plan, rules and limits. It never installs the host operating system or web server.

Retain the right responsibilities

You maintain code, included libraries, settings, secrets, data and access in every platform. App Service and App Engine maintain their host operating system and managed runtime. Beanstalk permits more EC2 customization; AWS publishes platform updates, and you apply them or enable managed platform updates. Extra software you install also needs care.

A platform is different from SaaS. With PaaS, you deploy the app you build; with SaaS, you use someone else's finished application, such as an email suite. Platform-specific settings and service integrations can also make a later provider move harder.

Fit simpler hosting needs

Amazon Lightsail bundles a virtual private server, storage and data transfer for a predictable monthly package. It suits small websites but still involves VM responsibilities. A static site consists of files such as HTML, CSS, JavaScript and images. AWS Amplify Hosting, Azure Static Web Apps and Firebase Hosting can serve those files globally without a web server for you to maintain. An app requiring full host operating-system control belongs on VMs.

Compare compute models against the same workload. Check control, operating effort, startup, billing, limits and portability.

Who maintains what?

Data and access remain the customer's responsibility throughout. Elastic Beanstalk also requires choosing how platform updates are applied.

Compare traffic and usable capacity

A VM usually needs a minute or more to boot and pass checks; a container often starts in seconds; a warm function can begin work in milliseconds. A new environment can add cold-start delay. Warm capacity reduces that delay at an ongoing cost.

A directory quiet overnight can benefit from scale to zero; steady demand can favor allocated compute. Compare equivalent throughput, memory and concurrency before monthly totals: one cheap VM may not serve the same work as many simultaneous function invocations. Include operating effort too.

VMs and dedicated hosting plans bill for allocated time, busy or idle. Lambda standard on-demand billing combines requests and GB-seconds; other function plans use different meters. Zero instances removes idle compute charges only when no paid minimum remains. Storage and databases can still bill.

Check limits and movement between platforms

Long-lived processes fit VMs or suitable containers. One Lambda default-compute invocation is limited to 15 minutes, so an uninterrupted two-hour job needs another compatible execution option. Functions cannot depend on local state surviving calls; disposable containers and scaling-group VMs also need external lasting data.

Full guest OS control, kernel changes and specialized licensed software favor VMs. Many independently deployed services can justify Kubernetes. Standard web apps often fit hosting platforms; short event tasks fit functions.

Container images move between compatible hosts, and Kubernetes offers common deployment tools across clouds. Databases, identity and networking can still need changes. VM migration depends on provider formats and tools; functions and platforms tie more closely to provider settings and triggers. Different components can use different models.

First check the requirements that could rule an option out. Then compare traffic, cost and team skills.

Find the decisive constraint

1. Check guest operating-system access, special software, hardware and licensing.
2. For short event-triggered work, check function duration, state and concurrency.
3. For containerized apps, compare Kubernetes control with simpler managed services.
4. For standard web apps deployed as code, consider a hosting platform.
5. Check startup delay, traffic patterns, resource limits and total operating cost.

Match the business cases

A vendor supports an accounting app only on Windows Server, with a core-based license. VMs preserve that environment; use a dedicated host if physical-core licensing requires it. Multi-zone copies need a compatible app and data design. Moving largely unchanged is rehosting, or lift and shift, and retains guest maintenance.

Photo uploads rise from a few at night to thousands per minute. Short independent thumbnail tasks fit functions triggered by uploads. They scale with arrivals; check cold starts, duration limits and the capacity of downstream services.

A retailer has 30 microservices, 6 teams and a two-cloud platform requirement. Managed Kubernetes supplies common orchestration tools. A start-up with 3 services and no Kubernetes experience can use Cloud Run, Container Apps or ECS with Fargate, retaining image and app responsibilities without host work.

A museum's agency builds a ticketing website but has no operations staff. A hosting platform supplies deployment tools and scaling for opening days. App Service and App Engine maintain hosts; Beanstalk needs a platform-update choice, such as managed updates.

A two-hour nightly report fits a container job or VM with a suitable execution limit, not one Lambda default-compute invocation. Spot can reduce cost if the job saves progress and resumes after interruption.

Multi-day GPU training needs accelerated VMs or suitable Kubernetes GPU nodes. Persisted checkpoints make Spot practical by limiting lost progress.

Explain a staged choice

A company can rehost first to leave its datacenter quickly, then modernize selected components with containers, hosting platforms or functions. Rehosting alone keeps the old operating model.

For example: "Use Cloud Run because the API is already containerized, traffic stops at night and the team has no server administrator; allow for a cold start after idle time."