g6e.2xlarge InsufficientInstanceCapacity in eu-central-1 – alternatives?

The InsufficientInstanceCapacity error occurs when AWS doesn't have enough available On-Demand capacity to fulfill your request at that moment. Here are some strategies to address your situation:

Immediate Solutions:

1. Wait a few minutes and resubmit your request, as capacity can shift frequently
2. Try launching without specifying a specific Availability Zone, allowing AWS to place the instance where capacity is available
3. Submit requests with a reduced number of instances if you're launching multiple

Alternative Instance Types: Given your requirement for ~48 GB GPU VRAM with the L40S GPU, the G6e family is specifically designed for this. However, if capacity issues persist, consider these alternatives:

• G5 instances: Feature NVIDIA A10G Tensor Core GPUs with 24 GB per GPU. While individual GPU memory is lower, you could use a multi-GPU configuration
• P4 instances: Another recommended alternative that may have better availability

Regarding Your Specific Questions: The capacity issue could be specific to the g6e.2xlarge size or broader to the instance family in that region. Different instance sizes within the same family can have varying availability, so trying the g6e.xlarge might yield different results, though both use the same L40S GPU.

Capacity Reservations: For on-demand start/stop workloads, Capacity Reservations can guarantee capacity when you need it, but you'll be billed for the reserved capacity whether you use it or not. This may not be cost-effective for intermittent workloads unless capacity availability is critical to your operations.

Best Practices:

• Try multiple Availability Zones within eu-central-1
• Consider testing alternative regions if your workload allows
• Monitor capacity patterns at different times of day
• Have a backup instance type strategy ready
  Sources
  Troubleshooting - Amazon SageMaker AI
  Troubleshoot Amazon EC2 instance launch issues - Amazon Elastic Compute Cloud

G6e capacity in Europe is genuinely constrained right now, here is what helps.

On your specific questions: The g6e.2xlarge shortage is not isolated to that size. G6e instances across eu-central-1 are in high demand due to the L40S GPU. Smaller sizes like g6e.xlarge are marginally more available but not reliably so.

For AZ availability, eu-central-1b tends to have slightly better G6e capacity than eu-central-1a and eu-central-1c, but this changes frequently. Always specify the AZ explicitly in your launch configuration and rotate through all three if one fails.

eu-west-1 (Ireland) generally has better G6e availability than eu-central-1 at the moment and is worth trying if latency to Frankfurt is not a hard requirement.

On Capacity Reservations: For on-demand start/stop workloads, an On-Demand Capacity Reservation makes sense only if you are willing to pay for the instance whether it is running or not. If your pipeline runs infrequently, the cost may outweigh the benefit. A better middle ground is joining an EC2 Capacity Reservation group, this gives you priority access without a full time commitment.

Practical alternatives if capacity remains unavailable: p3.8xlarge — 4x V100 GPUs, 64 GB VRAM combined, widely available in eu-central-1 g5.12xlarge — 4x A10G GPUs, 96 GB VRAM combined, more available than G6e in Europe Consider splitting inference across two g6e.xlarge instances if your pipeline supports it

Reference: EC2 On-Demand Capacity Reservations: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html EC2 instance types for GPU workloads: https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html

Similar has happened to me - not these instance types, and not this region, but it was still very large instances not starting on-demand.

When you want to start a g6e.2xlarge instance, the EC2 service needs to find 1 x L40S GPU and 48 GB of GPU memory, as well as 8 x VCPUs and 64GB of memory. All of these in, if not the same server, then certainly the same chassis or rack. If it can't find all of these resources at the same time, the instance can't be started.

It can also happen that as instance types get older and less-popular, the quantity gets reduced in favour of newer instance types that are in greater demand.

When it happened to me, the fix was the use EC2 Fleet. You come up with a list of instance types, ranked in order of preference, and EC2 Fleet goes through these until it finds an instance type that it can start. So g6e.2xlarge might be your first preference, and g7e.2xlarge your second preference, and so on. The further you go through the list the less appropriate the instances will be (too expensive, or lower specced) but it's a trade off you make for ensuring that your workload can run.

Which AZ in eu-central-1 tends to have better g6e capacity?

Each AZ will have the same. It's not a secret (although also not widely known) but the physical location of each AZ in each region isn't the same for each account.

Suppose there are three Data Centres in Frankfurt, called DC#1, DC#2 and DC#3. Your account might have eu-central-1a in DC#1, eu-central-1b in DC#2 and eu-central-1c in DC#3.

My account might have eu-central-1a in DC#2, eu-central-1b in DC#3 and eu-central-1c in DC#1.

Somebody else might have might have eu-central-1a in DC#3, eu-central-1b in DC#1 and eu-central-1c in DC#2.

If it was the same for everybody then, human nature being what it is, most people would build everything in eu-central-1a, and fewer things in eu-central-1b, and fewer still in eu-central-1c.

By varying it around like this, AWS ensures that all AZs (and thus all data centres) run at similar capacity.

Does a Capacity Reservation make sense for on-demand start/stop?

With capacity reservation you are basically paying for an always-on instance 24x7. It will be in-scope of Compute Savings Plans or Reserved Instances (if you have these) it will still be much more expensive than starting only when needed.