How compute as a service works on AWS, the differences between instance types, Spot vs On-Demand, and an introduction to ECR as a private registry for container images
Article by Andrea Mengato – Full-stack Developer at AzzurroDigitale
An introductory guide to compute as a service on AWS: how Amazon EC2 works, how to choose between the main instance type families and when to use On-Demand, Spot, Reserved Instances or Savings Plans. It closes with an overview of Amazon ECR, the private registry for container images integrated with the AWS ecosystem.
If I had to name the service where it all started in the cloud, I would point without much hesitation to compute. Before managed databases, serverless or AI, there was a fairly simple idea that changed the rules of the game: being able to switch on a machine in a few seconds, use it for as long as needed, and switch it off without having to buy or physically manage it. On AWS this is called Amazon EC2, and it is probably the most “historic” service on the whole platform.
In this issue I try to put some order into a few concepts that are often taken for granted: what “compute as a service” really means, how to find your way among the various instance types, when it makes sense to use Spot Instances instead of On-Demand, and I close with a section on Amazon ECR, the private registry for container images, useful above all if you already work with Docker or Kubernetes.
Compute as a service, in practice
The basic idea is that AWS provides computing capacity (CPU, RAM, storage, network) without you having to own or manage the underlying hardware. Each EC2 instance runs virtualised on a hypervisor (today mainly the Nitro System), which isolates resources between different customers who may share the same physical host. The interesting part is not so much virtualisation itself, which existed before the cloud, but the fact that all this can be requested on demand: console, CLI, SDK or infrastructure as code, and in a few minutes you have a machine ready to use. You can scale both horizontally, by adding instances (for example with an Auto Scaling Group), and vertically, by moving to a larger instance. Billing follows the same principle: you pay based on usage time, instance type and the pricing model you choose, which we discuss shortly.
Keep in mind: AWS handles the security and maintenance of the physical infrastructure, while you remain responsible for what runs on top of it, namely the operating system, patching and network configuration. This is the classic shared responsibility model.
How to choose the right instance type
These are the main families you will deal with most often:
| Family | Optimised for | Example uses |
|---|---|---|
| General Purpose (t, m) | Balanced CPU/RAM/network | Web servers, microservices, development environments |
| Compute Optimized (c) | High CPU-to-RAM ratio | Batch processing, video encoding, HPC workloads |
| Memory Optimized (r, x, z) | Large amounts of RAM | In-memory databases, caches, real-time analytics |
| Storage Optimized (i, d, h) | High-performance local I/O | Data warehouses, NoSQL databases, distributed file systems |
| Accelerated Computing (p, g, inf, trn) | Dedicated GPUs/accelerators | Machine learning, rendering, training/inference |
Spot vs On-Demand: where the real savings are
If the choice of instance type affects costs, the choice of pricing model often has an even bigger impact.
On-Demand
- You pay as you go, with no commitment of any kind.
- Fixed, predictable price, but the highest of all the available options.
- It makes sense for unpredictable workloads, traffic peaks and test environments that are short-lived.
Spot Instances
- They use computing capacity that AWS has unused at a given moment, which is why the price can be up to 90% lower than On-Demand.
- The price fluctuates according to supply and demand for available capacity.
- The risk: AWS can reclaim the instance with just two minutes’ notice if that capacity is needed elsewhere for On-Demand workloads.
- They are only suitable for stateless, fault-tolerant or otherwise interruptible workloads: batch jobs, rendering, distributed data processing with Spark or EMR, CI/CD runners, non-critical ML training.
- Best practice: combine them with an Auto Scaling Group with a mixed instances policy, so the infrastructure automatically falls back to On-Demand when Spot capacity is not available, and build the application to withstand sudden interruptions (checkpoints, retries and the like).
For completeness, Reserved Instances and Savings Plans are also worth mentioning: they are one- or three-year commitments in exchange for significant discounts, up to 72%, and make sense for stable workloads that you already know will run for a long time, such as an always-on database.
In practice: On-Demand when you need flexibility, Spot when the workload tolerates interruptions and you want to save, Reserved or Savings Plans for everything that is predictable and long-term. In most real accounts these three models happily coexist.
Amazon ECR: where your container images live
With the spread of Docker and Kubernetes, compute is no longer just “virtual machines”: a growing share of workloads runs inside containers. Amazon ECR (Elastic Container Registry) is the service AWS provides to store, manage and distribute these images privately.
Compared with a generic registry such as Docker Hub, the added value lies mainly in its integration with the AWS ecosystem:
- IAM integration: access to repositories goes through IAM policies, so you do not have to manage separate credentials.
- Private and public repositories: private by default, but you can also publish to the ECR Public Gallery.
- Vulnerability scanning: automatic layer scanning, based on Amazon Inspector, looking for known CVEs.
- Lifecycle policies: automatic rules to delete old or untagged images, so storage costs stay under control.
- Direct integration: ECS, EKS, Lambda with container images and CodePipeline can pull directly from ECR without special configuration.
From there on, the image is ready to be used by an ECS task, an EKS pod or a container-based Lambda function, without having to move the image anywhere else.
All in all, compute on demand remains the piece on which the rest of the cloud rests, and knowing how to navigate instance types and pricing models really makes a difference to the final bill. With containers becoming ever more central, a service like ECR completes the picture by providing a secure way to distribute what runs on top of that compute.
Frequently Asked Questions (FAQ)
What is compute on demand?
It is the ability to use computing capacity (CPU, RAM, storage and network) as a service: you start a virtual machine in minutes, use it for as long as needed and pay based on usage, without buying or managing hardware. On AWS the service is called Amazon EC2.
What is the difference between Spot and On-Demand instances?
On-Demand instances have a fixed pay-as-you-go price with no commitment. Spot instances use AWS’s unused capacity and can cost up to 90% less, but AWS can reclaim them with two minutes’ notice: they are only suitable for interruptible workloads.
When do Reserved Instances and Savings Plans make sense?
For stable, long-term workloads such as an always-on database: in exchange for a one- or three-year commitment they offer discounts of up to 72% compared with On-Demand.
How do you choose an EC2 instance type?
Based on the workload: General Purpose for web servers and microservices, Compute Optimized for batch and encoding, Memory Optimized for in-memory databases and caches, Storage Optimized for intensive I/O and Accelerated Computing for machine learning and rendering.
What is Amazon ECR used for?
Amazon ECR (Elastic Container Registry) is AWS’s private registry for storing and distributing container images, integrated with IAM, with vulnerability scanning and direct use from ECS, EKS and Lambda.