Whether it is called an image, an AMI (on AWS), or a VM template, it is the same idea: a snapshot of a ready-to-work machine. The contents of that image largely determine how fast and how consistent your CI is.
What is in the image?
A runner image bakes in the operating system, common language runtimes and SDKs, build tools, and the runner agent itself. When a runner launches, it boots this image and is immediately ready to pick up a job - no lengthy provisioning of the base toolchain per run.
AMI specifically?
On AWS, the image is an AMI (Amazon Machine Image) - the disk template an EC2 instance launches from. A self-hosted or managed runner fleet typically builds a custom AMI with exactly the tools its jobs need, so each instance comes up pre-loaded rather than installing everything at boot.
The trade-offs?
A richer image boots ready for more jobs but is larger and must be rebuilt and re-published whenever the baked tools change. A leaner image is smaller and easier to maintain but forces jobs to install more at runtime. The balance is including what most jobs need while leaving rare, heavy tools to per-job install or caching.
