[Yandex Cloud documentation](../../../index.md) > [Yandex Compute Cloud](../../index.md) > [Concepts](../index.md) > [Instance groups](index.md) > Instance template

# Instance template

When creating a group, you need to describe an _instance template_, which is the basic instance configuration used for deploying all instances in the group.

In CLI, the template description is provided together with the [policy](policies/index.md) description as a YAML file when creating or updating an instance group with the help of the `--file` parameter. This is a convenient method to provide values that consist of multiple strings. For more information, see [Creating a fixed-size instance group](../../operations/instance-groups/create-fixed-group.md).

You can set variable values for the instance template. For more information, see [Variables in an instance template](variables-in-the-template.md).

## Computing resources {#types}

When describing a template, you specify the computing resources to allocate to each instance, i.e., the number and guaranteed performance of processor cores (vCPUs) and the amount of RAM. You can choose the computing resources that are appropriate for the expected load. For more information, see [vCPU performance levels](../performance-levels.md).

You can also use configure the template to create [preemptible](../preemptible-vm.md) instances, which are cheaper than regular ones. Preemptible instances can only be autohealed if there is enough computing resources in the availability zone. If the resources are insufficient, Instance Groups will resume autohealing as soon as the resources become available; this, however, may take a longer time.

You can enable a [software-accelerated network](../software-accelerated-network.md) for group instances. This will transfer the processing of VM network traffic to additional compute cores.

## Disks and file storages {#disks}

Each instance must have at least one disk attached, which is a boot disk. Each boot disk is created automatically and attached to a single instance when creating an instance group. For more information, see [Disks](../disk.md).

You can also attach additional disks to each instance. You can create an additional disk along with an instance group. You can create an empty disk or restore it from a snapshot or an image. You can only attach or detach additional disks when creating or updating a group. You can [update secondary disks](deploy/secondary-disk.md) by updating [YAML specification](specification.md).

{% note alert %}

When you delete a VM, its disks are also deleted from the group. You can delete VMs during [scaling](scale.md) and [automatic recovery](autohealing.md).

{% endnote %}

In addition to disks, you can also attach [file storages](../filesystem.md) to instances within a group. File storages allow configuring an instance to handle [stateful workloads](stateful-workload.md) by saving the states of applications running on the instance to the storage independent of the instance group.

After attaching a file storage to a VM in the group, [mount](../../operations/filesystem/attach-to-vm.md) it on the VM's operating system. You can attach file storages using the [CLI](../../../cli/quickstart.md), [Terraform](../../../tutorials/infrastructure-management/terraform-quickstart.md), or [API](../../api-ref/index.md). For more information, see [Creating an instance group connected to a file storage](../../operations/instance-groups/create-with-filesystem.md).

## Network {#network}

When creating a group, you can:

* Set the network for the entire group.
* Set subnets for each instance in the group.

A [service account](../../../iam/concepts/users/service-accounts.md) used to perform operations in Instance Groups should have a [role](../../../vpc/security/index.md) for accessing network and subnets where the instance group is located. For more information, see [Access](access.md).

You can create a group without specifying any subnets for its instances if the availability zone selected for each instance contains exactly one subnet for the specified network.

{% note info %}

In addition to subnets created by you, a cloud network can host automatically created subnets. For example, the [Cloud Functions](../../../functions/concepts/networking.md#user-network), [Serverless Containers](../../../serverless-containers/concepts/networking.md), and [API Gateway](../../../api-gateway/concepts/networking.md#user-network) service subnets, or [reserved addresses](../../../managed-kubernetes/concepts/network.md#network-resources) for Managed Service for Kubernetes cluster pods and services.

{% endnote %}

You can also configure a public IP address for each instance. This allows the instance to connect to other services over the internet. For more information, see [VM network interfaces](../network.md).

You can specify the [appropriate security groups](../../../vpc/concepts/security-groups.md) in a template or configure them individually for each instance in the group.

## Metadata {#metadata}

You can use a template to describe the metadata service parameters and the VM metadata for the instances in the group. For example, in the `user-data` key, you can describe the system users to be added or the [software installation scripts](../../operations/vm-create/create-with-cloud-init-scripts.md#examples) to be run when creating a new VM. Read more about the metadata supported by Compute Cloud in [VM metadata](../vm-metadata.md).

## Template description in a YAML file {#instance-template}

A template describes the configuration of the base instance. It is defined in the `instance_template` key in a YAML file.

Here is how a YAML file entry may look like:

```yaml
...
instance_template:
  platform_id: standard-v3
  resources_spec:
    memory: 2G
    cores: 2
    core_fraction: 20
  boot_disk_spec:
    mode: READ_WRITE
    disk_spec:
      image_id: jk9ib7ecsbrj********
      type_id: network-hdd
      size: 50G
      preserve_after_instance_delete: false
  secondary_disk_specs:
    - name: disk-2
      mode: READ_WRITE
      disk_spec:
        preserve_after_instance_delete: false
        type_id: network-hdd
        size: 21474836480
  filesystem_specs:
    - mode: READ_WRITE
      device_name: sample-fs
      filesystem_id: epdccsrlalon********
  network_interface_specs:
    - network_id: adv1rq7pmi05********
      subnet_ids:
        - u8zxv2v5f3rr********
      primary_v4_address_spec: {
        one_to_one_nat_spec: {
          ip_version: IPV4
        }
      }
      security_group_ids:
        - enps0ar5s3ti********
  network_settings:
    type: SOFTWARE_ACCELERATED
  placement_policy:
    placement_group_id: rmppvhrgm77g********
  service_account_id: ajegtlf2q28a********
  metadata_options:
    gce_http_endpoint: ENABLED
    aws_v1_http_endpoint: DISABLED
    gce_http_token: DISABLED
    aws_v1_http_token: DISABLED
  metadata:
    user-data: |-
      #cloud-config
      write_files:
        - path: /var/lib/cloud/scripts/per-boot/01-run-load-generator.sh
          permissions: '0555'
          content: |
            #!/bin/bash
            docker run -d --net=host -p 80:80 openresty/openresty:alpine
      users:
        - name: my-user
          groups: sudo
          shell: /bin/bash
          sudo: 'ALL=(ALL) NOPASSWD:ALL'
          ssh_authorized_keys:
            - ssh-ed25519 AAAAB3...
...
```

By default, the disk size is specified in bytes. You can specify a different unit of measurement using the applicable suffix.

| Suffix | Prefix and multiplier | Example |
| ----- | ----- | ----- |
| `k` | kilo- (2^10^) | `640k` = 640 × 2^10^ = `655360` |
| `m` | mega- (2^20^) | `48m` = 48 × 2^20^ = `50331648` |
| `g` | giga- (2^30^) | `10g` = 10 × 2^30^ = `10737418240` |
| `t` | tera- (2^40^) | `4t` = 4 × 2^40^ = `4398046511104` |
| `p` | peta- (2^50^) | `2p` = 2 × 2^50^ = `2251799813685248` |

Keys (the table lists keys that directly define the base instance configuration):

Key | Value
----- | -----
`platform_id` | ID of the instance's hardware platform.
`resources_spec.memory` | Amount of RAM available to the instance, specified in bytes. The maximum value is 274877906944 (275 GB).
`resources_spec.cores` | Number of cores available to the instance. The value depends on the [platform](../vm-platforms.md) type.
`resources_spec.core_fraction` | Basic [vCPU performance level](../performance-levels.md).
`boot_disk_spec` | Boot disk parameters.
`boot_disk_spec.disk_spec.mode` | Disk access mode.</br>– `READ_ONLY`: Read-only access.</br>– `READ_WRITE`: Read/write access.
`boot_disk_spec.disk_spec.image_id` | ID of the image to create the disk from.
`boot_disk_spec.disk_spec.type_id` | ID of the disk type. To get a list of available disk types, use the [diskTypes](../../api-ref/DiskType/list.md) request.
`boot_disk_spec.disk_spec.size` | Size of the disk, specified in bytes. Acceptable values are in the range from 4194304 (4 MB) to 4398046511104 (4 TB).
`boot_disk_spec.preserve_after_instance_delete` | Option to preserve the disk on instance deletion.</br>– `true`: Preserve the disk on instance deletion.</br>– `false`: Delete the disk together with the instance.
`secondary_disk_specs` | Secondary disks parameters. This is optional.
`secondary_disk_specs.name` | Secondary disk name. This is optional. In the same specification, names should be assigned either to all secondary disks or none of them. For more information, see [Updating secondary disks in an instance template](deploy/secondary-disk.md).
`secondary_disk_specs.mode` | Disk access mode.</br>– `READ_ONLY`: Read-only access.</br>– `READ_WRITE`: Read/write access.
`secondary_disk_specs.disk_spec.preserve_after_instance_delete` | Option to preserve the disk on instance deletion.</br>– `true`: Preserve the disk on instance deletion.</br>– `false`: Delete the disk together with the instance.
`secondary_disk_specs.disk_spec.type_id` | ID of the disk type. To get a list of available disk types, use the [diskTypes](../../api-ref/DiskType/list.md) request.
`secondary_disk_specs.disk_spec.size` | Size of the disk, specified in bytes. Acceptable values are in the range from 4194304 (4 MB) to 4398046511104 (4 TB).
`filesystem_specs` | File storage parameters. This is optional.
`filesystem_specs.mode` | File storage access mode: </br>– `READ_ONLY`: Read-only access.</br>– `READ_WRITE`: Read/write access (default).
`filesystem_specs.device_name` | Device name for attaching the file storage to the VM, e.g., `sample-fs`. After attaching a file storage to a VM in the group, [mount](../../operations/filesystem/attach-to-vm.md) it on the VM's operating system. For more information, see [Creating an instance group connected to a file storage](../../operations/instance-groups/create-with-filesystem.md).
`filesystem_specs.filesystem_id` | File storage ID.
`network_interface_specs.network_id` | Cloud network ID.
`network_interface_specs.subnet_ids` | IDs of cloud subnets.
`network_interface_specs.ip_version` | IP version for the public IP address.
`network_interface_specs.security_group_ids` | Security group IDs.
`network_settings.type` | Network acceleration type. This is optional.</br>– `SOFTWARE_ACCELERATED`: Software-accelerated network.</br>– `STANDARD`: Standard network (default parameter).
`metadata_options` | [Metadata service parameters](../vm-metadata.md#metadata-formats). This is optional.
`metadata_options.gce_http_endpoint` | Access metadata using the Google Compute Engine format. This is optional.</br>– `enabled`: Enabled.</br>– `disabled`: Disabled.
`metadata_options.gce_http_token` | Access Identity and Access Management credentials using the Google Compute Engine format. This is optional.</br>– `enabled`: Enabled.</br>– `disabled`: Disabled.
`metadata` | Metadata for a template instance. This is optional. For more information, see [VM metadata](../vm-metadata.md).
`metadata.user-data` | Additional settings for instance initialization. In the example, the settings are described for the `cloud-init` program.
`placement_policy` | [VM placement group](../placement-groups.md) parameters. This is optional.
`placement_policy.placement_group_id` | Placement group ID. VM instances will reside in data center server racks depending on the selected placement strategy:</br>– `spread` placement: Each instance is hosted on a separate server rack in one of the availability zones.</br>– `partition` placement: Even allocation of VM instances across group partitions where VM instances from different partitions reside in different server racks in one of the availability zones.
`service_account_id` | [Service account](../../../iam/concepts/users/service-accounts.md) attached to the VMs in the group that enables them to use cloud resources. This is optional. With a service account, you can flexibly configure access permissions for your resources.</br>For more granular access management, link different service accounts with different permissions to the instance group and individual instances within that group.

For information about the technical restrictions of Instance Groups, see [Quotas and limits in Compute Cloud](../limits.md).

## Use cases {#examples}

* [Running an autoscaling instance group](../../tutorials/vm-autoscale/index.md)
* [Scheduled instance group scaling](../../tutorials/vm-scale-scheduled/index.md)
* [Autoscaling an instance group to process messages in Yandex Message Queue](../../tutorials/autoscale-monitoring.md)

#### Useful links {#see-also}

* [VM metadata](../vm-metadata.md)
* [Creating a VM with a custom configuration script](../../operations/vm-create/create-with-cloud-init-scripts.md)