2014-07-23 23:41:48 +02:00
---
layout: "aws"
page_title: "AWS: aws_instance"
sidebar_current: "docs-aws-resource-instance"
2014-10-22 05:21:56 +02:00
description: |-
Provides an EC2 instance resource. This allows instances to be created, updated, and deleted. Instances also support provisioning.
2014-07-23 23:41:48 +02:00
---
# aws\_instance
Provides an EC2 instance resource. This allows instances to be created, updated,
and deleted. Instances also support [provisioning ](/docs/provisioners/index.html ).
## Example Usage
2017-04-17 12:17:54 +02:00
```hcl
2016-07-09 12:09:10 +02:00
# Create a new instance of the latest Ubuntu 14.04 on an
2016-10-15 00:37:30 +02:00
# t2.micro node with an AWS Tag naming it "HelloWorld"
2015-12-21 17:00:34 +01:00
provider "aws" {
2017-02-18 23:48:50 +01:00
region = "us-west-2"
2015-12-21 17:00:34 +01:00
}
2016-07-09 12:09:10 +02:00
data "aws_ami" "ubuntu" {
most_recent = true
2017-02-18 23:48:50 +01:00
2016-07-09 12:09:10 +02:00
filter {
2017-02-18 23:48:50 +01:00
name = "name"
2016-10-02 23:54:16 +02:00
values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
2016-07-09 12:09:10 +02:00
}
2017-02-18 23:48:50 +01:00
2016-07-09 12:09:10 +02:00
filter {
2017-02-18 23:48:50 +01:00
name = "virtualization-type"
2016-10-02 23:54:16 +02:00
values = ["hvm"]
2016-07-09 12:09:10 +02:00
}
2017-02-18 23:48:50 +01:00
2016-07-09 12:09:10 +02:00
owners = ["099720109477"] # Canonical
}
2014-10-13 22:55:59 +02:00
resource "aws_instance" "web" {
2017-02-18 23:48:50 +01:00
ami = "${data.aws_ami.ubuntu.id}"
instance_type = "t2.micro"
tags {
Name = "HelloWorld"
}
2014-10-13 22:55:59 +02:00
}
```
2014-07-23 23:41:48 +02:00
## Argument Reference
The following arguments are supported:
* `ami` - (Required) The AMI to use for the instance.
* `availability_zone` - (Optional) The AZ to start the instance in.
2015-04-02 08:33:16 +02:00
* `placement_group` - (Optional) The Placement Group to start the instance in.
2015-11-26 11:21:06 +01:00
* `tenancy` - (Optional) The tenancy of the instance (if the instance is running in a VPC). An instance with a tenancy of dedicated runs on single-tenant hardware. The host tenancy is not supported for the import-instance command.
2014-09-08 01:03:48 +02:00
* `ebs_optimized` - (Optional) If true, the launched EC2 instance will be
EBS-optimized.
2015-05-15 21:18:05 +02:00
* `disable_api_termination` - (Optional) If true, enables [EC2 Instance
Termination Protection](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination)
2017-02-18 23:48:50 +01:00
* `instance_initiated_shutdown_behavior` - (Optional) Shutdown behavior for the
instance. Amazon defaults this to `stop` for EBS-backed instances and
`terminate` for instance-store instances. Cannot be set on instance-store
2016-01-14 21:55:39 +01:00
instances. See [Shutdown Behavior ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingInstanceInitiatedShutdownBehavior ) for more information.
2014-07-23 23:41:48 +02:00
* `instance_type` - (Required) The type of instance to start
* `key_name` - (Optional) The key name to use for the instance.
2015-06-25 18:07:11 +02:00
* `monitoring` - (Optional) If true, the launched EC2 instance will have detailed monitoring enabled. (Available since v0.6.0)
2016-10-03 16:45:34 +02:00
* `security_groups` - (Optional) A list of security group names to associate with.
2016-05-31 17:27:00 +02:00
If you are creating Instances in a VPC, use `vpc_security_group_ids` instead.
2015-03-07 07:09:13 +01:00
* `vpc_security_group_ids` - (Optional) A list of security group IDs to associate with.
2014-07-23 23:41:48 +02:00
* `subnet_id` - (Optional) The VPC Subnet ID to launch in.
2017-02-18 23:48:50 +01:00
* `associate_public_ip_address` - (Optional) Associate a public ip address with an instance in a VPC. Boolean value.
2014-09-01 10:06:39 +02:00
* `private_ip` - (Optional) Private IP address to associate with the
2014-08-22 02:17:50 +02:00
instance in a VPC.
2014-07-23 23:41:48 +02:00
* `source_dest_check` - (Optional) Controls if traffic is routed to the instance when
2014-09-16 13:40:16 +02:00
the destination address does not match the instance. Used for NAT or VPNs. Defaults true.
2014-07-23 23:41:48 +02:00
* `user_data` - (Optional) The user data to provide when launching the instance.
2014-09-23 20:06:30 +02:00
* `iam_instance_profile` - (Optional) The IAM Instance Profile to
2017-04-11 15:57:15 +02:00
launch the instance with. Specified as the name of the Instance Profile.
2017-03-01 17:16:59 +01:00
* `ipv6_address_count` - (Optional) A number of IPv6 addresses to associate with the primary network interface. Amazon EC2 chooses the IPv6 addresses from the range of your subnet.
* `ipv6_addresses` - (Optional) Specify one or more IPv6 addresses from the range of the subnet to associate with the primary network interface
2014-10-13 22:55:59 +02:00
* `tags` - (Optional) A mapping of tags to assign to the resource.
2017-04-26 00:12:38 +02:00
* `volume_tags` - (Optional) A mapping of tags to assign to the devices created by the instance at launch time.
providers/aws: add root_block_device to aws_instance
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype
Fixes #913
Refs #858
2015-02-18 18:45:30 +01:00
* `root_block_device` - (Optional) Customize details about the root block
2015-02-24 18:00:22 +01:00
device of the instance. See [Block Devices ](#block-devices ) below for details.
* `ebs_block_device` - (Optional) Additional EBS block devices to attach to the
instance. See [Block Devices ](#block-devices ) below for details.
* `ephemeral_block_device` - (Optional) Customize Ephemeral (also known as
"Instance Store") volumes on the instance. See [Block Devices ](#block-devices ) below for details.
2017-04-25 00:06:28 +02:00
* `network_interface` - (Optional) Customize network interfaces to be attached at instance boot time. See [Network Interfaces ](#network-interfaces ) below for more details.
2014-11-20 00:59:29 +01:00
2015-02-24 18:00:22 +01:00
## Block devices
Each of the `*_block_device` attributes controls a portion of the AWS
Instance's "Block Device Mapping". It's a good idea to familiarize yourself with [AWS's Block Device
2016-01-14 21:55:39 +01:00
Mapping docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html)
2015-02-24 18:00:22 +01:00
to understand the implications of using these attributes.
2014-07-23 23:41:48 +02:00
providers/aws: add root_block_device to aws_instance
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype
Fixes #913
Refs #858
2015-02-18 18:45:30 +01:00
The `root_block_device` mapping supports the following:
2015-02-24 18:00:22 +01:00
* `volume_type` - (Optional) The type of volume. Can be `"standard"` , `"gp2"` ,
or `"io1"` . (Default: `"standard"` ).
providers/aws: add root_block_device to aws_instance
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype
Fixes #913
Refs #858
2015-02-18 18:45:30 +01:00
* `volume_size` - (Optional) The size of the volume in gigabytes.
2015-02-24 18:00:22 +01:00
* `iops` - (Optional) The amount of provisioned
2016-01-14 21:55:39 +01:00
[IOPS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html ).
2017-03-07 13:44:39 +01:00
This is only valid for `volume_type` of `"io1"` , and must be specified if
using that type
2015-02-24 18:00:22 +01:00
* `delete_on_termination` - (Optional) Whether the volume should be destroyed
on instance termination (Default: `true` ).
Modifying any of the `root_block_device` settings requires resource
replacement.
Each `ebs_block_device` supports the following:
2014-11-20 00:59:29 +01:00
* `device_name` - The name of the device to mount.
* `snapshot_id` - (Optional) The Snapshot ID to mount.
2015-02-24 18:00:22 +01:00
* `volume_type` - (Optional) The type of volume. Can be `"standard"` , `"gp2"` ,
or `"io1"` . (Default: `"standard"` ).
2014-11-20 00:59:29 +01:00
* `volume_size` - (Optional) The size of the volume in gigabytes.
2015-02-24 18:00:22 +01:00
* `iops` - (Optional) The amount of provisioned
2016-01-14 21:55:39 +01:00
[IOPS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html ).
2015-02-24 18:00:22 +01:00
This must be set with a `volume_type` of `"io1"` .
* `delete_on_termination` - (Optional) Whether the volume should be destroyed
on instance termination (Default: `true` ).
* `encrypted` - (Optional) Enables [EBS
2016-01-14 21:55:39 +01:00
encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
2015-05-28 18:25:13 +02:00
on the volume (Default: `false` ). Cannot be used with `snapshot_id` .
2014-07-23 23:41:48 +02:00
2015-02-24 18:00:22 +01:00
Modifying any `ebs_block_device` currently requires resource replacement.
providers/aws: add root_block_device to aws_instance
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype
Fixes #913
Refs #858
2015-02-18 18:45:30 +01:00
2016-09-13 08:41:39 +02:00
~> **NOTE on EBS block devices:** If you use `ebs_block_device` on an `aws_instance` , Terraform will assume management over the full set of non-root EBS block devices for the instance, and treats additional block devices as drift. For this reason, `ebs_block_device` cannot be mixed with external `aws_ebs_volume` + `aws_volume_attachment` resources for a given instance.
2016-03-25 18:12:01 +01:00
2015-02-24 18:00:22 +01:00
Each `ephemeral_block_device` supports the following:
* `device_name` - The name of the block device to mount on the instance.
2016-12-08 11:03:51 +01:00
* `virtual_name` - (Optional) The [Instance Store Device
2016-01-14 21:55:39 +01:00
Name](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#InstanceStoreDeviceNames)
2016-12-08 11:03:51 +01:00
(e.g. `"ephemeral0"` ).
* `no_device` - (Optional) Suppresses the specified device included in the AMI's block device mapping.
2015-02-24 18:00:22 +01:00
Each AWS Instance type has a different set of Instance Store block devices
available for attachment. AWS [publishes a
2016-01-14 21:55:39 +01:00
list](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#StorageOnInstanceTypes)
2015-02-24 18:00:22 +01:00
of which ephemeral devices are available on each type. The devices are always
identified by the `virtual_name` in the format `"ephemeral{0..N}"` .
2015-04-08 00:05:00 +02:00
~> **NOTE:** Currently, changes to `*_block_device` configuration of _existing_
resources cannot be automatically detected by Terraform. After making updates
to block device configuration, resource recreation can be manually triggered by
using the [`taint` command ](/docs/commands/taint.html ).
providers/aws: add root_block_device to aws_instance
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix #859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytype
Fixes #913
Refs #858
2015-02-18 18:45:30 +01:00
2017-04-25 00:06:28 +02:00
## Network Interfaces
Each of the `network_interface` blocks attach a network interface to an EC2 Instance during boot time. However, because
the network interface is attached at boot-time, replacing/modifying the network interface **WILL** trigger a recreation
of the EC2 Instance. If you should need at any point to detach/modify/re-attach a network interface to the instance, use
the `aws_network_interface` or `aws_network_interface_attachment` resources instead.
The `network_interface` configuration block _does_ , however, allow users to supply their own network interface to be used
as the default network interface on an EC2 Instance, attached at `eth0` .
Each `network_interface` block supports the following:
* `device_index` - (Required) The integer index of the network interface attachment. Limited by instance type.
* `network_interface_id` - (Required) The ID of the network interface to attach.
* `delete_on_termination` - (Optional) Whether or not to delete the network interface on instance termination. Defaults to `false` .
### Example
```hcl
resource "aws_vpc" "my_vpc" {
cidr_block = "172.16.0.0/16"
tags {
Name = "tf-example"
}
}
resource "aws_subnet" "my_subnet" {
vpc_id = "${aws_vpc.my_vpc.id}"
cidr_block = "172.16.10.0/24"
availability_zone = "us-west-2a"
tags {
Name = "tf-example"
}
}
resource "aws_network_interface" "foo" {
subnet_id = "${aws_subnet.my_subnet.id}"
private_ips = ["172.16.10.100"]
tags {
Name = "primary_network_interface"
}
}
resource "aws_instance" "foo" {
ami = "ami-22b9a343" // us-west-2
instance_type = "t2.micro"
network_interface {
network_interface_id = "${aws_network_interface.foo.id}"
device_index = 0
}
}
```
2014-07-23 23:41:48 +02:00
## Attributes Reference
The following attributes are exported:
* `id` - The instance ID.
* `availability_zone` - The availability zone of the instance.
2015-04-02 08:33:16 +02:00
* `placement_group` - The placement group of the instance.
2014-07-23 23:41:48 +02:00
* `key_name` - The key name of the instance
2017-02-18 23:48:50 +01:00
* `public_dns` - The public DNS name assigned to the instance. For EC2-VPC, this
2015-11-24 17:10:12 +01:00
is only available if you've enabled DNS hostnames for your VPC
2016-03-11 02:27:10 +01:00
* `public_ip` - The public IP address assigned to the instance, if applicable. **NOTE** : If you are using an [`aws_eip` ](/docs/providers/aws/r/eip.html ) with your instance, you should refer to the EIP's address directly and not use `public_ip` , as this field will change after the EIP is attached.
2016-07-25 20:52:40 +02:00
* `network_interface_id` - The ID of the network interface that was created with the instance.
2017-04-25 00:06:28 +02:00
* `primary_network_interface_id` - The ID of the instance's primary network interface.
2017-02-18 23:48:50 +01:00
* `private_dns` - The private DNS name assigned to the instance. Can only be
used inside the Amazon EC2, and only available if you've enabled DNS hostnames
2015-11-24 17:10:12 +01:00
for your VPC
* `private_ip` - The private IP address assigned to the instance
2014-07-23 23:41:48 +02:00
* `security_groups` - The associated security groups.
2015-04-15 19:17:21 +02:00
* `vpc_security_group_ids` - The associated security groups in non-default VPC
2014-07-23 23:41:48 +02:00
* `subnet_id` - The VPC subnet ID.
2016-07-21 00:28:59 +02:00
## Import
2017-02-18 23:48:50 +01:00
Instances can be imported using the `id` , e.g.
2016-07-21 00:28:59 +02:00
```
$ terraform import aws_instance.web i-12345678
2016-09-13 08:41:39 +02:00
```