Pin AWS SDK code generation to the versions in go.mod

[gustavodiaz7722]

Problem

build/scripts/generate-aws-interfaces.sh ran go get for each AWS service
before invoking ifacemaker. go get resolves to the module's latest
release and rewrites go.mod. Because go generate ./pkg/awsapi/... is part of
generate-always, this ran on every build.

So the pinned versions in go.mod were ignored during code generation, builds
were not reproducible, and an upstream AWS release could change generated code
or break tests with no corresponding commit in this repository.

This is currently breaking CI on every pull request

AWS published service/eks v1.91.0, which adds KubeApiServerConfig,
KubeControllerManagerConfig and KubeSchedulerConfig to ekstypes.Cluster.
go.mod pins v1.88.0, but builds resolved v1.91.0:

go: upgraded github.com/aws/aws-sdk-go-v2/service/eks v1.88.0 => v1.91.0

The four pkg/printers golden-file specs serialize an EKS Cluster, and the
golden files (last updated 2026-06-22) do not contain those fields, so they now
fail on every PR. Evidence that this is repo-wide rather than PR-specific:

• Add release notes for v0.230.0 #8787 changes only docs/release_notes/0.230.0.md and fails with the same
  four failures. A markdown file cannot break Go unit tests.
• The same branch on Bump github.com/aws/amazon-ec2-instance-selector/v3 from 3.1.2 to 3.1.3 #8733 passed on 2026-08-10 and failed on 2026-08-11 with
  no change to its contents. Only main moved, and no merged commit touched
  pkg/printers or the EKS SDK pin.

eks was not the only module affected. The same build also upgraded
ssm 1.68.6 -> 1.73.5, iam 1.58.1 -> 1.58.2, and elasticloadbalancingv2
1.58.5 -> 1.58.6.

Fix

Use go mod download instead of go get. It fetches the version already
selected in go.mod without modifying it, so generation happens against the
pinned SDK.

All eleven services in pkg/awsapi/generate/generate.go (ec2, autoscaling,
cloudwatchlogs, cloudformation, cloudtrail, elasticloadbalancing,
elasticloadbalancingv2, ssm, iam, eks, outposts) are direct
requirements in go.mod, so each resolves to its pinned version.

Upgrading an SDK becomes an explicit, reviewable commit, which is what
Dependabot already handles.

Why this approach over regenerating the golden files

Regenerating the golden files against v1.91.0 would turn CI green today, but it
leaves builds non-reproducible and CI would break again the next time AWS adds a
field to Cluster. Pinning addresses the cause; the existing golden files are
already correct for the pinned v1.88.0.

Testing

Verified bash -n on the script. The meaningful check is this PR's own CI: if
the four pkg/printers failures clear, generation is running against v1.88.0 as
intended.

Reviewers should also confirm whether the committed pkg/awsapi/*.go shims
drift, since they were last generated against an unpinned (newer) SDK. If
ifacemaker output differs for the pinned versions, that diff should be
committed separately so it is reviewed on its own.

[github-actions]

Hello gustavodiaz7722 👋 Thank you for opening a Pull Request in eksctl project. The team will review the Pull Request and aim to respond within 1-10 business days. Meanwhile, please read about the Contribution and Code of Conduct guidelines here. You can find out more information about eksctl on our website