Instance Type

An instance type is a named machine shape published by a cloud provider, and the name fixes the vCPU count, the memory size, the storage attached to the machine, and the network capability of every instance launched under it. Choosing one is how you decide what a GitHub Actions job runs on when the runner is a cloud virtual machine.

The vCPU count is the attribute most people read and the only one many people read. Two instance types can carry the same vCPU count and still finish the same workflow at different times, because storage and network are part of the shape as well.

Definition

An instance type is the unit a cloud provider sells compute in. Each entry in the catalog has a name, and the name resolves to a fixed allocation of four resources.

1. vCPU count. The number of virtual processors the guest sees, usually one hardware thread of a host core each. The count sets the ceiling on how much work runs in parallel, which is what a test runner reads when it decides how many workers to fork. The vCPU entry covers how the mapping to physical hardware works.
2. Memory. A fixed amount of RAM, generally held at a constant ratio to the vCPU count inside a family. On AWS the general purpose m family pairs 4 GiB of memory with each vCPU, the compute optimized c family pairs 2 GiB, and the memory optimized r family pairs 8 GiB.
3. Storage. Two different things travel under this word. Network attached block volumes (Amazon EBS, Google Persistent Disk, Azure Managed Disks) are configured separately from the instance type and can be resized or retyped without changing it. Instance store devices, also called local SSD or ephemeral disk, are physically attached to the host and exist only on instance types whose names say so.
4. Network capability. A bandwidth ceiling that scales with size inside a family. Smaller sizes in a family are commonly published as a burst figure, so a small shape reaches its headline number for a limited window rather than continuously.

Reading the name

Every major provider encodes the shape into the string, and the encoding is documented.

The AWS options field is where storage hides. AWS documents d as instance store volumes and i as Intel processors, so the difference between m6i and m6id is one letter that adds a physical NVMe device to the machine (EC2 instance type naming conventions, checked on 2026-08-13). Google Cloud spells the same idea out with an lssd suffix (Local SSD disks, checked on 2026-08-13), and Azure uses the additive feature letter d (Azure VM naming conventions, checked on 2026-08-13).

Sizes inside a family step through large, xlarge, 2xlarge, 4xlarge and upward, with vCPU and memory roughly doubling at each step. Google Cloud puts the vCPU count in the name directly, which removes the guesswork.

What the name leaves out

An instance type fixes the hardware shape and nothing above it. The operating system image, the preinstalled toolchain, the size and type of the boot volume, and the software configuration are all separate choices, so two machines of the same instance type can behave differently on the same workflow. Availability is separate again: a given instance type exists in some regions and availability zones and is absent from others, and account quotas are counted per vCPU per family per region rather than per machine.

Example

A team runs GitHub Actions jobs on self-hosted Linux runners in AWS and registers two fleets, one on m6i.2xlarge and one on m6id.2xlarge. Both shapes carry 8 vCPU and 32 GiB of memory. Only the second has a local NVMe device.

Each fleet advertises a label naming its instance type, and runs-on routes a job to a runner that carries every label listed (Choosing the runner for a job and Using labels with self-hosted runners, checked on 2026-08-13).

name: build
on:
  push:
    branches: [main]

jobs:
  unit-tests:
    runs-on: [self-hosted, linux, x64, m6i-2xlarge]
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  image:
    runs-on: [self-hosted, linux, x64, m6id-2xlarge]
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - run: docker build -t app:${{ github.sha }} .

Same vCPU count, different storage

Sources: AWS general purpose instance specifications and Amazon EBS General Purpose SSD volumes, both checked on 2026-08-13.

The storage row is what moves the wall clock on a build. Checking out a large repository, running npm ci, and extracting Docker layers all write tens of thousands of small files, and that pattern draws on IOPS rather than on processor time. On the EBS backed shape those writes spend the volume's baseline budget of 3,000 IOPS and 125 MiB/s, and raising the budget is a separate volume configuration with its own cost. On the instance store shape the same writes land on a device attached to the host, and the volume budget stops being the limit.

The tradeoff runs the other way for durability. Instance store contents are tied to the life of the instance and disappear when it stops or terminates, so anything that has to survive the run goes to an artifact upload, a cache upload, or a registry push. A machine also has to format and mount the device before a job benefits from it, because an image that never touches the device leaves the work directory on the boot volume and pays the same IOPS budget as the shape without local storage. The d suffix costs more per hour than the plain shape, which is the reason to point the storage heavy jobs at it and leave the rest where they are.

Related Terms

• What one vCPU maps to on the host machine: how a vCPU count relates to physical cores and threads, and what that means for build parallelism.
• Local SSD storage attached to an instance: the instance store device that a d or lssd suffix adds, and how its lifecycle differs from a block volume.
• Choosing instance types for runners in your own AWS account: where instance type selection appears when GitHub Actions runners launch inside your own account.
• AWS configuration for a runner stack: the AWS prerequisites, including the region quotas to check for the instance types you pick.
• Local SSD handling on Linux runner images: how instance store devices are detected, formatted, and mounted for the work directory.
• EC2 instance type naming conventions: the upstream table of series letters, generation numbers, and option letters.
• WarpBuild pricing: per minute rates by runner type.