SubnetAvailableWaiter treats InvalidSubnetID.NotFound as a hard failure after CreateSubnet succeeds

[atisap]

How to categorize this issue?
/area networking
/kind bug
/platform aws

What happened:
During shoot creation on AWS, gardener-extension-provider-aws calls CreateSubnet successfully (an ID is returned), but SubnetAvailableWaiter immediately polls DescribeSubnets with that ID and receives InvalidSubnetID.NotFound. The error is propagated as a hard failure and the Infrastructure CR moves to Failed state. No retry is attempted.

Error from Infrastructure CR status.lastErrors:

task "Waiting until shoot infrastructure has been reconciled" failed:
Error while waiting for Infrastructure <shoot-namespace>/<shoot-name> to become ready:
error during reconciliation: Error reconciling infrastructure: 1 error occurred:
  * failed to "ensure zones resources": 2 errors occurred:
  * failed to "ensure subnet us-east-1a-SubnetPublicUtility":
    subnet <subnet-id> did not become available:
    operation error EC2: DescribeSubnets, https response error StatusCode: 400,
    api error InvalidSubnetID.NotFound: The subnet ID '<subnet-id>' does not exist
  * failed to "ensure subnet us-east-1f-SubnetPublicUtility":
    subnet <subnet-id> did not become available:
    operation error EC2: DescribeSubnets, https response error StatusCode: 400,
    api error InvalidSubnetID.NotFound: The subnet ID '<subnet-id>' does not exist

The error is classified as ERR_CONFIGURATION_PROBLEM, which prevents any automatic retry. Once the Infrastructure CR is in Failed state, the consuming operator loops re-reading the cached status.lastErrors but does not trigger a new infrastructure reconciliation. Eventually the shoot creation operation times out and the shoot is deleted.

The subnets were confirmed to exist in AWS after the fact. The failure is caused by EC2 eventual consistency: CreateSubnet returns before the resource is visible via DescribeSubnets.

What you expected to happen:

SubnetAvailableWaiter should tolerate a brief propagation window after CreateSubnet. When InvalidSubnetID.NotFound is received immediately after a successful CreateSubnet call, it should be treated as a retryable transient error, not a hard configuration failure. The waiter should back off and retry for a short period before failing permanently.

How to reproduce it (as minimally and precisely as possible):

The race is timing-dependent and not consistently reproducible. It has been observed on fresh shoot creation in AWS us-east-1.

Anything else we need to know?:

This has been observed on multiple shoots over the past weeks, all in AWS us-east-1. In every case the shoot was deleted after the creation timeout and could not be recovered by manual reconciliation.

Earlier occurrences of the same error via the Terraform-based infraflow were resolved at the time by manually triggering a reconciliation retry. With the Go-based infraflow the shoot enters Failed state immediately and no automatic or manual retry path is available within the creation timeout window.

Environment:

• Cloud provider: AWS
• Region: us-east-1
• Infraflow: Go-based (not Terraform)
• gardener-extension-provider-aws: v1.68.3