Error message not clear when the instance_type is not available on region

[kdefives]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Hello,

I tried to pop an AWS instance on AWS China (Beijing region) with an instance_type which is not available in this region, for instance : m5.4xlarge
When i do the terraform apply, i would like to suggest to improve the error message displayed. I know is it not urgent but i think it could be useful to debug and analyze what is the error.

Bellow the current error message :

Error: Error applying plan:
1 error(s) occurred:

• aws_instance.instance_1: 1 error(s) occurred:
• aws_instance.instance_1: Error launching source instance: Unsupported: The requested configuration is currently not supported. Please check the documentation for supported configurations.
  status code: 400, request id: d426d0e4-8810-4935-8370-010e3866b205

FEATURE REQUEST: What do you think to improve the error log message by something like this : "instance type not available on the current zone"?

New or Affected Resource(s)

• aws_instance

Potential Terraform Configuration

#Terraform v0.12.1
#+ provider.aws v2.7.0 

provider "aws" {
    access_key = ""
    secret_key = ""
    region     = "cn-north-1"
}

resource "aws_instance" "instance_1"{
    ami = "ami-XXXX" #Replace here by your own AMI
    instance_type = "m5.4xlarge" #This instance_type exists on Europe region but not in China (eg. cn-north-1)
    tags = {
        Name = "Hello World"
    }
    vpc_security_group_ids = ["sg-XXXX"] #Replace here by your securityGroupID
    subnet_id = "subnet-XXXX" #Replace here by your subnetID
}

Code example available here : https://github.com/kdefives/issue-aws_instance-error_message_not_clear_with_bad_instance_type

References

[bflad]

Hi @kdefives 👋 Thanks for writing this in! That error message is certainly vague.

This particular error messaging is coming from the EC2 API itself:

Unsupported: The requested configuration is currently not supported. Please check the documentation for supported configurations.
status code: 400, request id: d426d0e4-8810-4935-8370-010e3866b205

And unfortunately, the Terraform AWS Provider aws_instance resource does not get any additional insight into why this particular error message occurred as we are just passing it through. In this situation, the best we might be able to do within our code is catch and wrap this particular error message with some additional messaging, e.g.

aws_instance.instance_1: Error launching source instance: Unsupported: The requested configuration is currently not supported. Please check the documentation for supported configurations.
status code: 400, request id: d426d0e4-8810-4935-8370-010e3866b205

Some common items to check include:
 * Instance Type is supported in the AWS Region
 * ... additional item here...
 * ... additional item here ...

As you can imagine though, even this might not be particularly helpful for operators since it cannot provide too much insight either. We will not know whether it was an instance type to region mismatch or some other condition that the EC2 API decided to trigger this message. I am not sure that we would want to accept the maintenance burden of implementing this additional messaging should it potentially be incorrect (e.g. leading operators down the wrong troubleshooting paths), missing troubleshooting paths, or if future updates to the EC2 API error break our handling for catching this scenario.

Your best bet to getting this error messaging within the EC2 API improved is to reach out with a feature request in an AWS Support Case or your AWS account managers if you have any. 👍

Since this likely falls under a case where we will not want to do anything to increase the code complexity here, I'm going to proactively close this issue, but please do write back if you would like to further discuss this!

[bflad]

As a related followup point, I have been wondering if we might want to support a data source that allows verifying whether AWS Regions/Availability Zones do support a certain instance type or more in particular, which Availability Zones an instance can be launched in. With the recent launch of the usw2-az4 Availability Zone (us-west-2d in all accounts older than this year), there are a ton of instance types not supported in that particular AZ, including what I presume many operators would probably consider pretty common (e.g. t2.micro and m4.large).

Our particular pain point maintaining this project is surrounding the following integration testing setup (the aws_instance resource is not the only resource affected by this issue):

# This example is for illustrative purposes only in Terraform 0.12 syntax and omits other implementation details
resource "aws_vpc" "example" {}

# Without specifying availability_zone, the AZ is automatically selected (potentially us-west-2d)
resource "aws_subnet" "example" {
  vpc_id = aws_vpc.example.id
}

# Since the subnet availability zone was predetermined previously
# we cannot do anything to prevent the instance type error here.
resource "aws_instance" "example" {
  subnet_id = aws_subnet.example.id
}

Now theoretically in our acceptance testing could just depend on the default VPC and its subnets existing to remove subnet_id from problematic places to get rid of this particular error scenario, however we have acceptance testing that deletes those. Also some customer environments where the Terraform AWS Provider acceptance testing is run will also not have those. 😄

To partially alleviate this issue, a few releases ago we added blacklisting support to the aws_availability_zones data source (#8462), which allows us a fairly manual process for working around this situation:

# This example is for illustrative purposes only in Terraform 0.12 syntax and omits other implementation details
data "aws_availability_zones" "example" {
  blacklisted_zone_ids = ["usw2-az4"]
  state                = "available"
}

resource "aws_vpc" "example" {}

# Now we are ensuring that us-west-2d is not included :)
resource "aws_subnet" "example" {
  availability_zone = data.aws_availability_zones.example.names[0]
  vpc_id            = aws_vpc.example.id
}

resource "aws_instance" "example" {
  subnet_id = aws_subnet.example.id
}

But since its manual process, its slow to implement and likely to become incorrect over time as instance type support is updated.

The data source idea here would leverage EC2's dry run abilities and provide a list of supported availability zones or completely error if none are found.

# Rough design sketch with placeholder naming and usage which is tailored for our particular problem.
# This example is for illustrative purposes only in Terraform 0.12 syntax and omits other implementation details.

# This would error if instance type is not found in region
data "aws_ec2_instance_type" "example" {
  instance_type = "m4.large"
  # Optional arguments below:
  availability_zone = "..." # limit search to single AZ
}

resource "aws_vpc" "example" {}

# We are ensuring that us-west-2d is not included for now,
# but it will get automatically included when the instance type is added in the future :)
resource "aws_subnet" "example" {
  availability_zone = data.aws_ec2_instance_type.example.availability_zones[0]
  vpc_id            = aws_vpc.example.id
}

resource "aws_instance" "example" {
  subnet_id = aws_subnet.example.id
}

I'm not sure of its utility in the real world though so it may never be implemented, but figured I would throw this out there as a potential idea as well since it seemed related.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!