Compare VM, container, managed-container and serverless execution models, then learn images, bootstrap, instance families, lifecycle and health-driven autoscaling.
Treat instances as cattle where possible: configuration should come from images, bootstrap automation and external state rather than manual login changes.
Machine images capture a tested base. User data/cloud-init can perform lightweight instance-specific setup. Long, fragile bootstrap scripts increase launch time and failure risk.
Scaling policies need metrics or schedules, minimum/maximum capacity and health replacement rules. Scaling does not fix a memory leak or broken dependency by itself.
Cloud providers group virtual machines into families optimized for different CPU, memory, storage, acceleration or general-purpose profiles. Select from workload measurements rather than a familiar instance name.
Instances also move through lifecycle states such as pending, running, stopping/stopped and terminated. Automation must distinguish a reversible stop from termination and account for ephemeral state.
VMs provide operating-system control. Containers package application dependencies while sharing a host kernel. Managed container platforms can reduce node/control-plane work. Serverless functions or managed application runtimes trade infrastructure control for event-driven or application-focused operation.
The architecture question is which operational responsibilities you need to control. Use Docker Fundamentals for image/container depth and Kubernetes Fundamentals for orchestration depth; this module focuses on choosing the cloud execution model.
#!/bin/sh
set -eu
echo "APP_ENV=production" > /etc/academy-app.env
# Fetch application from an approved immutable artifact source here.Need guest-OS/kernel control → VM
Need portable packaged service → container
Need orchestrated long-running containers → managed Kubernetes/container platform
Need short event-driven execution → serverless function
Need application deployment with minimal infrastructure operation → managed application/PaaSGoal: Simulate a simple CPU-based desired-capacity calculation locally.
cat > /tmp/scale.py <<'PY'
def desired(current,cpu,min_n=2,max_n=6):
if cpu > 70: return min(max_n,current+1)
if cpu < 30: return max(min_n,current-1)
return current
for cpu in (20,45,85,95): print(cpu, desired(3,cpu))
PYpython3 /tmp/scale.pypython3 - <<'PY'
exec(open('/tmp/scale.py').read().split('for cpu')[0])
assert desired(6,95)==6
assert desired(2,10)==2
print('bounds respected')
PYpython3 - <<'PY'
workloads={'legacy_kernel_module':'vm','http_microservice':'container','image_resize_event':'serverless','kubernetes_platform_team':'managed_kubernetes'}
for k,v in workloads.items(): print(k,'->',v)
assert workloads['legacy_kernel_module']=='vm' and workloads['image_resize_event']=='serverless'
PYProduction scaling often combines load-balancer health, queue depth, latency or application metrics rather than a single CPU threshold.
Inspect existing instance types and lifecycle state without launching or changing instances.
aws ec2 describe-instance-types --max-results 5 --query 'InstanceTypes[].{Type:InstanceType,VCPU:VCpuInfo.DefaultVCpus,MemoryMiB:MemoryInfo.SizeInMiB}' --output tableaws ec2 describe-instances --query 'Reservations[].Instances[].{Id:InstanceId,Type:InstanceType,State:State.Name}' --output tableOpen each answer only after you have tried to answer the question yourself.
Adding or removing instances/capacity units rather than making one instance larger.
They make the base runtime repeatable and easier to replace consistently.
To define availability floors and cost/safety ceilings for the autoscaler.
A serverless/event-driven function model, because the workload is short-lived and triggered by events; verify runtime limits and cost before implementation.
Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.
Attempt the core lab and knowledge checks before marking the module complete.