-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(ec2): support throughput option in EBS volume #16213
Comments
Thanks for the feature request! We welcome community contributions! If you are able, we encourage you to contribute. If you decide to contribute, please start an engineering discussion in this issue to ensure there is a commonly understood design before submitting code. This will minimize the number of review cycles and get your code merged faster. |
@njlynch I would propose the following implementation. Do you have any comments? Add new property readonly throughput?: number; Add validation in
Add validation in
Add unit test cases and create integration tests that show Volume and LaunchTemplate with |
Hey, i just stumbled upon this issue while looking for a way of defining the throughput of GP3 volumes. Until this feature is merged, is there any workaround for defining it? |
You can do something like: interface ExtendedEbsDeviceOptions extends autoscaling.EbsDeviceOptions {
throughput: number;
}
const asg = new autoscaling.AutoScalingGroup(this, "example", {
blockDevices: [{
deviceName: "/dev/sda1",
volume: autoscaling.BlockDeviceVolume.ebs(1, {
...
volumeType: autoscaling.EbsDeviceVolumeType.GP3,
throughput: 125,
} as ExtendedEbsDeviceOptions),
}],
...
}) This extends the type to include There are other ways to get the throughput property rendered out with the resource but this is probably the easiest. If you need to do get the compatibility for an ec2 volume you would do something like: interface Ec2VolumeExtended extends ec2.VolumeProps {
throughput: number;
}
const volume = new ec2.Volume(this, "volume", {
volumeType: ec2.EbsDeviceVolumeType.GP3,
throughput: 125,
...
} as Ec2VolumeExtended) |
Adds support for the `throughput` property on GP3 volumes in both autoscaling and EC2 packages since their volume implementations are separate per the comment https://github.com/aws/aws-cdk/blob/master/packages/@aws-cdk/aws-autoscaling/lib/volume.ts#L1. Change includes unit test coverage, integration test coverage on the autoscaling changes, and validation of the inputq to throughput. I was on the fence about whether to include the validation for synth time checking since as far as I can tell validation is not performed consistently across the CDK at synth time. Happy to modify that behavior pending reviewer feedback. It was not obvious to me at first pass where similar integration test coverage that was added to the autoscaling package could be added to the EC2 package, so if the reviewer would like to see integration tests for GP3 volumes on in the EC2 package, would you mind providing a hint as to where that test might fit in the existing test paradigm? Happy to break this change into two PRs -- one for EC2 and one for autoscaling. closes: #16213 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
@csumpter I don't think the workaround works. This is my code:
The |
@aldredb You should be able to upgrade to the latest aws-cdk release which now includes support/types for the |
@csumpter Yep i used the 2.54.0 release. The |
You are correct that the In the meantime are you trying to create a EC2 instance in the example you gave? |
Yes. I'm trying to use this: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.Instance.html#blockdevices |
@aldredb I don't believe you can set a |
I also stumbled on this today for launch templates. Here's the workaround: const launchTemplate = new ec2.LaunchTemplate(this, 'LaunchTemplate', {
// omitting other required properties
blockDevices: [
{
deviceName: '/dev/xvda',
volume: ec2.BlockDeviceVolume.ebs(100, {
volumeType: ec2.EbsDeviceVolumeType.GP3,
}),
},
],
});
(launchTemplate.node.defaultChild as CfnResource).addPropertyOverride("LaunchTemplateData.BlockDeviceMappings.0.Ebs.Throughput", 200) I'm not sure why LaunchTemplate ebs supports throughput (doc), whereas instance ebs not (doc). edit) |
For EBS volumes with volume type GP3, the throughput in MiB/s can be configured. This is currently not supported in CDK.
Workaround: use escape hatches
Use Case
Set custom value for throughput, impacts performance and pricing.
Proposed Solution
The property is available in ebs volume and launchtemplate blockdevicemaping. It should be supported in both constructs.
Check if the property can be added to
EbsDeviceOptionsBase
or only to one of its subclasses (EbsDeviceOptions
andEbsDeviceSnapshotOptions
). Nothing specific is mentioned in the documentation.Display a warning if throughput is defined for a volume type that does not support specifying a throughput. Display an error if a throughput value is specified that is not supported.
Other
Originally mentioned as comment in issue #12020.
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: