I got an answer from support. The issue was that the user credentials used for the operation when applying from the console expire after ~7 hours, but IAM service role accounts have a much longer timeout, so applying the update using the service role allowed the operation to completely wait for the optimization/conversion process.
As for the re-optimization of the volumes, the AWS::EC2::Volume documentation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html states that a cooldown period is enforced when changing Iops, Size, or VolumeType; my reading of it is that this refers to the optimization process. I saw that the optimization was triggered when changing Iops even after successfully updating the stack to the gp3 version, so I guess that's just the behavior of CloudFormation and/or EBS.
Is it redundant to have an EC2 instance and its EBS volumes in the same AWS Backup resource assignment?Accepted Answerasked 9 months ago
Type of disk attached to an instanceAccepted Answerasked 9 months ago
Restriction on number of EBS volumes per EC2 ?Accepted Answerasked 2 years ago
Every stack update tries to optimize gp3 volumeasked 2 years ago
How do you find the EBS Volume IDS for a Volume that was created and attached at EC2 Instance Launch Time ?asked 5 months ago
AWS MGN , EBS VolumesAccepted Answerasked a month ago
EBS gp3 volumes in Severely Degraded stateasked 5 months ago
We have 2 volumes can't detach and deleteasked 4 months ago
Unable to delete ebs volumesasked 5 months ago
Conditions to attach EBS volumesasked 5 months ago