Fortunately, there is a straightforward work-around for impacted customers. We learned long ago that we should never hard-code any configuration in AWS. Everything can be overriden, including the volume worker instance type. Customers can set the instance type in Studio to avoid the issue. 

The simplest fix would probably be to just go back to m3.medium as the default instance type. However, it remains the case that T2 is more cost-efficient, and it works provided that dedicated tenancy is not used. Since dedicated tenancy is something of an edge case (only used by customers with particular security or compliance requirements), it might make sense to have a dual-configuration system so that we can use M3 instances in dedicated cases, but still use T2 in regular cases. This also reduces the risk of the change, because we make it specifically different for the dedicated tenancy case.

Under Connections Options Add the following :
UseExplicitVpcForVolumeWorkerBootstrap=true,VolumeWorkerInstanceType=m3.medium 

Note: Nitro-based instance type can not be used for volume worker and please refer to AWS for list of Nitro-based instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances

Problem Cause

In Elektra (7.12) we changed the default instance type that we use for volume workers on AWS. We had previously been using m3.medium, but we switched it to t2.small. We did this because we had to switch all of our Linux AMIs from paravirtual to HVM so that they would work in some newly-introduced regions. Adopting a T2 instance type was a less-expensive alternative relative to M3.

However, it has since transpired that T2 instances cannot be use as dedicated instances. (And volume workers need to be dedicated if the MCS catalog is dedicated). Therefore, the volume worker launch process fails when dedicated tenancy is chosen.