[Enhancement]: Option to skip iops validation for unknown ebs volume types

[willgorman]

Description

The provider currently prevents iops from being set on volume types other than io1, io2, and gp3: https://github.com/hashicorp/terraform-provider-aws/blob/08b11917a71c8453d53c1caa1f6c260f4f6bdf3f/internal/service/ec2/ebs_volume.go#L349-L367

This presents a problem when using the provider with alternate backends that support the AWS EBS APIs but offer additional volume types, some of which do allow specifying provisioned iops. The purpose for this issue is to see if there is support for opening a PR that makes it possible to allow iops to be provided for other volume types. The implementation for this PR could be one of the following:

• Allow iops to be provided for any volume type that is not one of the official AWS volume types
• Support a flag/option/environment variable that allows a user to provide a list of volume types that support iops
• Support a flag/option/environment variable that disables the volume type check

This would also be beneficial if AWS adds another new volume type in the future that supports provisioned iops. Currently the provider would have to be updated to allow iops to be used with the new volume type but with this change it would be possible to use the new volume type without upgrading the provider version.

Affected Resource(s) and/or Data Source(s)

• aws_ebs_volume

Potential Terraform Configuration

resource "aws_ebs_volume" "a-volume" {
  availability_zone = "us-east-1a"
  size              = 50
  type              = "definitely-not-an-aws-volume-type"
  iops              = 5000
}

References

No response

Would you like to implement a fix?

Yes

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[justinretzolk]

Hey @willgorman 👋 Thank you for taking the time to raise this! While we try not to break compatibility with AWS-compatible services like you're describing, it's not something we actively test against or try to optimize for. The current behavior was introduced in order to provide a better experience with the native API, however, I can see your point re:AWS adding new volume types, so I'd like to leave this open so that someone from the team or community can give further input.

Given that this would (currently) only affect AWS-compatible services and not AWS itself, I'd be remiss if I didn't give you a heads up that it may take longer to be prioritized.

[willgorman]

@justinretzolk Thanks, that's definitely fair that it would be a lower priority. I'd be willing to work on this and open a PR but I just wanted to open this issue first to gauge how receptive the project would be. The impression that I get is that it would likely be acceptable as long as it doesn't impact the experience with the native API. In that case I think that the first proposed option ("Allow iops to be provided for any volume type that is not one of the official AWS volume types") would be the approach I'd take for this.

[willgorman]

As I was looking into this further I realized that there are other types of resources that have validation related to volume types. Although aws_ebs_volume doesn't currently reject unknown volume types, all of those other types of resources do consider unknown types to be invalid. There's perhaps a larger enhancement that could be made to allow unknown volume types to be used with any resource but offhand I'm not sure of a good way to do that without removing the validation that is necessary for users of the native API.

Resource	Validates Volume Type?	Validates IOPS?
aws_ebs_volume	No	Yes
aws_instance	Yes	Yes
aws_ami	Yes	No
aws_launch_template	Yes	No
aws_spot_fleet_request	Yes	No

I think there's still some value in the original scope of this issue for just aws_ebs_volume resources so I'd still like to go ahead with this (if accepted).