feat(gcp-to-aws): add EKS Auto Mode guidance for GKE migrations

[hasrazz]

Problem

For GCP → AWS migrations, the gcp-to-aws skill defaulted GKE workloads to ECS Fargate whenever the user didn't explicitly express a Kubernetes preference, and it did not offer EKS Auto Mode as a target at all. This is out of step with current AWS guidance, which positions EKS Auto Mode as the recommended low-operational-overhead way to run Kubernetes (the closest equivalent to GKE Autopilot). GKE Autopilot clusters in particular had no matching AWS landing zone, and the Autopilot signal — although captured in live discovery — never reached the Clarify/Design phases.

Solution

• Discovery: detect GKE Autopilot on both paths (Terraform enable_autopilot, live autopilot.enabled) and normalize a canonical config.autopilot_enabled key into the inventory schema so Clarify/Design can read it.
• Clarify (Q8): default GKE sources to EKS Auto Mode; standard EKS managed node groups and ECS Fargate become explicit opt-outs; the Autopilot flag is surfaced as context (Autopilot → Auto Mode is the 1:1 match).
• Multi-cloud (Q5): routes to standard EKS (Auto Mode is excluded — its node management is AWS-specific and defeats portability).
• Threading: the new eks-auto / eks-standard / ecs-fargate enum flows through the compute rubric (compute.md), fast-path, index, Terraform generation (Auto Mode cluster vs managed node groups), pricing formulas (Auto Mode management fee + control-plane fee), preferences schema, billing path, and workshop sheet.
• Cross-plugin parity: the same changes are mirrored into the advisor/ copy of gcp-to-aws so the cross-plugin drift check stays green.

Type of Change

• New plugin/power/tool
• Bug fix
• Enhancement to existing content
• Documentation update
• Guardrail/CI update

Team Folder

• advisor/
• migrate/
• solution-architecture/
• Other: ___

Note: the change lives in migrate/plugins/migration-to-aws/skills/gcp-to-aws/ and is mirrored into advisor/plugins/aws-startup-advisor/skills/gcp-to-aws/, which the repo's cross-plugin-drift check requires to stay in sync.

Checklist

• I have read the CONTRIBUTING.md guidelines
• My changes do not include hardcoded secrets, credentials, or internal-only content
• I have run mise run build locally and it passes
• I have updated documentation if needed
• My changes are scoped to my team's folder only

Verification: mise run build passes locally (exit 0) — lint, fmt:check, and the security suite (bandit, semgrep, gitleaks, checkov 184/0, grype clean) all pass; cross-plugin-drift, fixtures, frontmatter, and tests are OK; the working tree is not mutated by the build. Changes are documentation/prompt Markdown only. (Pre-existing, unrelated pricing:staleness warnings on the heroku-to-aws caches are warn-only and untouched by this PR.)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[herosjourney]

Summary

Good direction overall — defaulting GKE migrations to EKS Auto Mode is the right call technically (it's the correct GKE Autopilot analog, and it's AWS's own recommended low-ops path), and the change is threaded consistently through Clarify, Design, Estimate, Generate, pricing, and schema. The advisor/ mirror is verified byte-identical to the migrate/ source apart from path prefixes, so the drift-check claim in the PR body holds up.

One real bug should block merge. Two other items are worth addressing but not blocking.

---

Blocking

graviton.md / generate-artifacts-infra.md — arm64 guidance for EKS Auto Mode is incomplete and would silently fail

Both files say to select arm64 for Auto Mode by setting kubernetes.io/arch: arm64 on "the NodePool / aws_eks_node_class." I checked this against AWS's docs: the built-in general-purpose NodePool — the one that actually schedules application workloads — is amd64-only. Only the built-in system NodePool (tainted CriticalAddonsOnly, for cluster components) supports both architectures. (Enable or Disable Built-in NodePools)

Getting arm64 app workloads on Auto Mode requires a custom NodePool + NodeClass (Karpenter CRDs applied via kubectl/Helm) — it's not a flag you can flip on the default pool, and it's not something the aws_eks_cluster Terraform resource can express. As written, an agent following this instruction will either fail or silently produce an amd64 cluster while reporting Graviton was applied.

Suggested fix: either (a) note that Auto Mode + Graviton requires generating an additional custom NodePool/NodeClass manifest (not just Terraform) and do that, or (b) flag to the user that Graviton isn't cleanly supported for Auto Mode via this skill's generated output yet, rather than asserting it works.

---

Non-blocking

compute.md — no regional-availability check for Auto Mode

Elsewhere in this codebase (design-ai.md, Bedrock model selection), newer AWS capabilities go through the awsknowledge MCP regional-availability check before being recommended. This PR recommends Auto Mode unconditionally on GKE detection with no equivalent gate. Auto Mode is broadly available today, but it's inconsistent with the caution pattern this repo already established for exactly this kind of rollout. Suggest adding the same MCP check, or explicitly noting why it's not needed here.

clarify-compute.md Q8 — question wording states the recommendation before presenting the choice

The new Q8 opens with "You're on GKE today, so by default we keep you on Kubernetes with EKS Auto Mode... How would you like to proceed?" before listing options A/B/C. That's a change from the old Q8, which explicitly instructed framing the question neutrally ("frame it practically so the user gives an honest answer rather than aspirational"). Leading with the recommended answer nudges "I don't know" responses toward passive confirmation rather than an actual decision.

To be clear, I think the default itself is a good change — Q8 only fires when GKE is already in inventory, meaning the customer already chose Kubernetes deliberately; defaulting undecided users to stay on that abstraction (via the lowest-ops AWS variant) respects an existing investment better than the old Fargate default, which silently dropped it. I'd just ask to restructure the prompt so options are presented before the recommendation is stated, keeping the same default.

Confirmed not an issue: I traced Q8's answer through Design and Generate independently, and all three answers (Auto Mode / standard EKS / Fargate) produce distinct, correct Terraform output — this isn't a case of the preference being captured but not honored downstream. The eliminator logic also correctly overrides preference when a technical blocker exists (node-level customization needs, or the Q5 multi-cloud portability override), which is the right precedence — user preference should win among viable options, not over hard constraints.

---

What's correctly implemented (verified against AWS docs)

• IMDSv2 enforcement claim for Auto Mode nodes (hop limit 1, non-configurable) — accurate, no launch template needed.
• Two distinct IAM roles (cluster role vs. node role, separate managed-policy sets) — matches AWS's documented setup exactly.
• Terraform block shape (compute_config { enabled, node_pools, node_role_arn }, kubernetes_network_config { elastic_load_balancing { enabled } }, storage_config { block_storage { enabled } }) — matches real working Auto Mode Terraform.
• Excluding Auto Mode from the Q5 multi-cloud path — correct; Auto Mode's node management genuinely is AWS-specific and would undercut the portability goal.
• Savings Plan caveat (applies to underlying EC2 instances, not the Auto Mode management fee or control-plane fee) — directionally correct per AWS's cost docs.

[hasrazz]

Blocking

graviton.md / generate-artifacts-infra.md — arm64 guidance for EKS Auto Mode is incomplete and would silently fail

Both files say to select arm64 for Auto Mode by setting kubernetes.io/arch: arm64 on "the NodePool / aws_eks_node_class." I checked this against AWS's docs: the built-in general-purpose NodePool — the one that actually schedules application workloads — is amd64-only. Only the built-in system NodePool (tainted CriticalAddonsOnly, for cluster components) supports both architectures. (Enable or Disable Built-in NodePools)

Getting arm64 app workloads on Auto Mode requires a custom NodePool + NodeClass (Karpenter CRDs applied via kubectl/Helm) — it's not a flag you can flip on the default pool, and it's not something the aws_eks_cluster Terraform resource can express. As written, an agent following this instruction will either fail or silently produce an amd64 cluster while reporting Graviton was applied.

Suggested fix: either (a) note that Auto Mode + Graviton requires generating an additional custom NodePool/NodeClass manifest (not just Terraform) and do that, or (b) flag to the user that Graviton isn't cleanly supported for Auto Mode via this skill's generated output yet, rather than asserting it works.

Yes - This is correct. We need separate manifests for graviton in EKS Auto mode as of now. I have added detailed guidance in newer commit. dec4d29

Non-blocking

compute.md — no regional-availability check for Auto Mode

Elsewhere in this codebase (design-ai.md, Bedrock model selection), newer AWS capabilities go through the awsknowledge MCP regional-availability check before being recommended. This PR recommends Auto Mode unconditionally on GKE detection with no equivalent gate. Auto Mode is broadly available today, but it's inconsistent with the caution pattern this repo already established for exactly this kind of rollout. Suggest adding the same MCP check, or explicitly noting why it's not needed here.

Nice, did not know about that, added this suggestion as well. 4aac819

clarify-compute.md Q8 — question wording states the recommendation before presenting the choice

The new Q8 opens with "You're on GKE today, so by default we keep you on Kubernetes with EKS Auto Mode... How would you like to proceed?" before listing options A/B/C. That's a change from the old Q8, which explicitly instructed framing the question neutrally ("frame it practically so the user gives an honest answer rather than aspirational"). Leading with the recommended answer nudges "I don't know" responses toward passive confirmation rather than an actual decision.

Restructured that in new commit. 8c4f94d

I will expand on ECS guidance in a different PR

[herosjourney]

All three findings addressed — approving

Re-verified each fix directly against the diff, not just the commit message.

Blocking - arm64/NodePool bug (dec4d29): fixed correctly. graviton.md and generate-artifacts-infra.md now correctly state Graviton on Auto Mode is not a Terraform flag - the built-in general-purpose NodePool is amd64-only and immutable, and getting arm64 workloads running requires a custom Karpenter NodePool + EC2NodeClass applied as a Kubernetes manifest post-provision. The fix also adds the right safety net: if the run can't emit/apply that manifest, it falls back to amd64 and explicitly flags Graviton as not applied, rather than claiming arm64 succeeded. This closes the exact failure mode I flagged.

Non-blocking - Q8 wording (8c4f94d): fixed, and improved beyond what I asked. Options A/B/C are now presented before the recommendation, with the default noted last as "if you're unsure, we default to A" rather than opening the question. The default itself is correctly unchanged (still eks-auto), which was the right call to preserve. Also caught and removed a dead option ("D) N/A - we don't use Kubernetes") that couldn't fire since Q8 only triggers when GKE is already present - good catch I'd missed.

Non-blocking - regional availability gate (4aac819): fixed correctly. Adds an awsknowledge MCP get_regional_availability check before finalizing eks-auto, reusing the same pattern this repo already applies to Bedrock/AgentCore. Falls back to eks-standard in the same region (not a different region) on unavailability, with both a rationale note and a warnings[] entry, plus a sane degraded path if the MCP call itself fails.

Verified independently:

• All touched files remain byte-identical between advisor/ and migrate/ mirrors.
• mise run build exits 0, drift:check reports 259 identical / 25 allowlisted (baseline, no new suppressions).

No remaining concerns. Approving.

[leon1418]

[🤖 AI review 🤖]

Update (September 14, 2026): the CLEAN conclusion below is superseded by my follow-up review at head ed268632, which requests changes. The original App Engine billing nit is fixed. The current review identifies two P1 issues (final target enforcement and the Auto Mode NodeClass API) and one P2 issue (the fallback architecture value). I incorrectly accepted the EC2NodeClass guidance in this earlier review. The original review below is retained as historical context.

---

[🤖 AI review 🤖]

Reviewed head 17c7e804 — 32 files, +422/−256 (all prose/Markdown, no code).

This PR adds EKS Auto Mode as the default GKE migration target, displacing the previous Fargate default. The change is well-designed: GKE usage signals Kubernetes adoption, so staying on managed Kubernetes (Auto Mode as the GKE Autopilot equivalent) is the right default; users who want node control or want off K8s opt in explicitly via Q8. The three-way enum (eks-auto / eks-standard / ecs-fargate) threads cleanly through Clarify → Design → Estimate → Generate → Workshop, with correct multi-cloud exclusion (Auto Mode is AWS-specific, Q5 routes to standard EKS). herosjourney's blocking finding (arm64/NodePool) and both non-blocking items are all verified fixed at the current head.

1 Nit (non-blocking): design-billing.md table row for google_app_engine_application says "EKS Auto Mode under compute: \"eks\"" while the override paragraph in the same file — and every other location — correctly says "EKS standard node groups" for multi-cloud. An agent parsing the table first would pick the wrong target. Inline comment posted.

What's correctly implemented (verified in the diff):

• Autopilot detection normalized into config.autopilot_enabled on both IaC and live paths, with canonical schema keys documented in schema-discover-iac.md.
• Q8 restructured: options presented before recommendation, dead option D removed (Q8 only fires when GKE present), default changed from Fargate to Auto Mode with clear rationale.
• Auto Mode eliminator (node-level customization) falls back to eks-standard, not Fargate — preserves Kubernetes.
• Regional availability gate via awsknowledge MCP get_regional_availability before finalizing eks-auto, matching the existing Bedrock/AgentCore pattern.
• Graviton/arm64 on Auto Mode correctly documented as requiring custom Karpenter NodePool+EC2NodeClass manifest (not a Terraform flag), with amd64 fallback if manifest cannot be emitted.
• EKS Auto Mode pricing formula correctly separates control plane fee, EC2 instance rate, and Auto Mode management surcharge, with amd64-by-default note.
• Savings Plan guidance updated to clarify management fee and control plane are not SP-eligible.
• Q5 multi-cloud consistently routes to eks-standard across all 16 files (compute, clarify-global, fast-path, index, billing, estimate, generate, workshop, schema-preferences).
• Cross-plugin parity: all 16 advisor/migrate pairs verified byte-identical after path normalization. No new drift allowlist entries.

CI: No checks reported on this branch.
Merge status: MERGEABLE, 1 approval (herosjourney at current head), review requested from startups-advisor + startups-migrate teams.
Verdict: CLEAN. The Nit is a copy/paste remnant that does not block — the authoritative override paragraph in the same file has the correct text, and an agent that reads past the table will get the right answer. But fixing it removes the ambiguity.

[hasrazz]

1 Nit (non-blocking): design-billing.md table row for google_app_engine_application says "EKS Auto Mode under compute: \"eks\"" while the override paragraph in the same file — and every other location — correctly says "EKS standard node groups" for multi-cloud. An agent parsing the table first would pick the wrong target. Inline comment posted.

updated this in e27ef1c

[hasrazz]

@leon1418, @herosjourney; All changes have been pushed and branch is updated with main.

[leon1418]

[🤖 AI review 🤖]

Reviewed exact head bbbe52eb576753a5d53dfef5d6fe1285d42bb8e9. All three findings from my previous Request changes review are resolved, and I found no remaining substantive concerns in the reviewed change. Approving this revision.

• Final enforcement and Generate preserve each resource's resolved Kubernetes target, including the explicit Fargate opt-out and the technical fallback from Auto Mode to a Standard EKS Cluster.
• The arm64 NodePool uses the Auto Mode default NodeClass with the correct API reference, while retaining workload scheduling and runbook instructions.
• The fallback artifact uses the canonical x86_64 value.

I followed up in the original discussions. Validation on this head: all 18 changed mirror pairs are byte-identical; cross-plugin drift passes (275 identical, 25 allowlisted); all 149 existing tests pass; formatting, Markdown lint, and git diff --check pass. Static contract checks for all three fixes pass in both copies and detect the previous defects at ed268632. I also rechecked the current official AWS NodePool/NodeClass documentation.

These are local checks and a review of the prompt contracts. No end-to-end LLM migration replay or EKS deployment was run. GitHub currently reports no checks/status results for this head, although build is required; the branch is behind main and other review discussions remain unresolved. Those merge gates still need to be satisfied.

[leon1418]

[🤖 AI review 🤖]

Re-reviewed exact head ea2d67e952da27dfd84aff22368d5509b30b1dc6 against base b30cb39be02d2eae78cb8c482f4018435d4dc988, including the changes since my actually inspected head bbbe52eb. No remaining substantive findings; approving this revision.

The new commits merge upstream changes. The PR's added/deleted content is unchanged relative to its updated base. I checked the affected integration rather than relying on the previous approval's commit metadata: the resolved Fargate/Standard EKS targets still survive final enforcement and generation, the arm64 pool still uses the Auto Mode NodeClass API, and the fallback artifact remains x86_64. I also checked the merged Terraform policy consumer and the allowlisted advisor-only closing instructions. The EKS pricing section is preserved.

Local validation on this head:

• All 18 changed mirror pairs are byte-identical; drift passes (281 identical, 27 allowlisted).
• All 151 Node tests and 57 policy tests in each plugin copy pass.
• An EKS-shaped static policy probe passes, a wildcard-policy negative case fails, and fixing that policy replaces the canonical failed verdict with a passing one while preserving Terraform and intermediate phase state.
• The three original source-contract regression checks pass in both copies and detect the previous defects. Formatting, Markdown lint, and git diff --check pass.

These are local/static checks, not an LLM migration replay or EKS deployment. All ten review threads are resolved. GitHub still reports no check/status result for this head, so the required build gate remains outstanding.

[ayn-builds]

Three blocking items. The first one is the substantive one; the other two are stale references left behind by the Q8 rewrite.

All three apply to both copies of the skill (migrate/plugins/migration-to-aws/... and advisor/plugins/aws-startup-advisor/...) at the same line numbers, since the 18 files this PR touches are identical pairs. The inline comments are anchored on the migrate/ copy only; each fix needs to land in the advisor/ mirror too.

---

3. references/phases/clarify/clarify.md:548 - trigger keys on an answer this PR deleted

(Posting this one here rather than inline because the line is outside the diff hunks.)

The Answer Combination Triggers table still has:

| Kubernetes-averse | Q5 = No + Q8 = Frustrated | ECS Fargate strongly recommended |

Frustrated was removed from Q8 in this PR, so this row can never fire. The equivalent is now Q8 = 3 (kubernetes: "ecs-fargate").

While in this table: line 546 ("Must stay portable ... EKS only, no ECS Fargate; App Engine also routes to EKS") should say Standard EKS Cluster. You updated exactly this wording in clarify-global.md but this copy was missed, and leaving it ambiguous here is what the rest of the PR works hard to disambiguate.

[leon1418]

[🤖 AI review 🤖]

Reassessed exact head ea2d67e952da27dfd84aff22368d5509b30b1dc6 after review 5250617626. Request changes for the China-region Auto Mode selection defect. My previous no-findings recommendation missed this restriction.

[P1] Regional selection: the current EKS FAQ explicitly excludes China Regions, whereas compute.md:53 asserts support there and removes the gate. The live availability catalog still reports support, but that conflicting response is insufficient to override the FAQ. A China-region override flows through the GKE default into Auto Mode generation; the billing-only mapping has the same unsupported default. I added evidence and the required fallback scope in the existing regional discussion, without opening a duplicate finding.

Non-blocking consistency corrections: I also verified the stale Q8 letter references at compute.md:48,177,185, the removed Q8 = Frustrated trigger at clarify.md:548, and the ambiguous portable-target wording at line 547. Use the current constraint values (eks-standard / ecs-fargate) or options 2/3, and name Standard EKS Cluster explicitly. The current interpretation/rubric still maps option 3 to Fargate and multi-cloud to standard EKS, so I did not reproduce an additional target-selection failure from these stale labels.

The prior per-resource enforcement, NodeClass API, and x86_64 fixes remain intact. Both plugin copies have the same new issues. Validation for this reassessment was a direct primary-documentation check and source/consumer trace, with 18 matching mirror pairs, a passing drift check, and a passing git diff --check. No implementation changes, deployment, new test infrastructure, or end-to-end model replay were performed.

[herosjourney]

Looked back through the full review history here (27 reviews, 12 threads, 31 commits) to understand why this keeps finding new things each round. Sharing what I found in case it's useful for closing this out.

This isn't a resolution loop. 10 of 12 review threads closed cleanly on the first fix — author fixes, reviewer verifies, done. The two open threads from today are genuinely new findings, not regressions of anything already fixed.

The recurring pattern is consistency drift, not contradictory review demands. This PR threads a new enum value (eks-auto) through every layer of the pipeline — discovery, Clarify, Design, pricing, Terraform generation, schema — mirrored across two plugin trees (migrate/ + advisor/). That's 36 files for one conceptual change. Almost every finding across all 12 threads (both resolved and open) is the same shape: a value renamed or introduced in one place that wasn't propagated everywhere it's referenced —

• the assembled preferences.json example that didn't match the renamed default
• the multi-cloud exclusion applied in 5 places but missing from a 6th
• today's stale "Q8 B/C" lettering in 3 spots after Q8 was renumbered elsewhere in this same PR

One real structural issue did cause a fix to ripple (thread on fast-path.md → Generate): the Kubernetes-target decision was computed independently in two places — Design's fast-path table and Generate's own re-derivation — so patching one didn't patch the other. That's now fixed and verified (bbbe52e).

Today's regional-availability finding is a fact-check reversal, not new code breaking something: the China-exclusion claim was live-verified via the awsknowledge MCP in an earlier round and the reviewer vouched for it (c083479); today's finding shows the MCP's isAvailableIn response conflicts with AWS's own published EKS FAQ, which explicitly excludes China. Worth noting for future regional-availability checks in this repo — the MCP catalog and the service FAQ apparently disagree here, so it's not a reliable single source for exclusions.

Suggestion to close this out in one more round instead of another partial one: rather than patching only the exact lines each review flags, do one deliberate sweep across both migrate/ and advisor/ trees for every reference to the renamed/new identifiers before the next push — specifically the remaining Q8 letter references (:48, :177, :185 per the open thread) and the China exclusion (needs to land on both the IaC and billing paths, per the open thread). That would likely catch what the next review round would otherwise find piecemeal.

[leon1418]

[🤖 AI review 🤖]

Update (September 23, 2026): the bootstrap-setting item is now a non-blocking suggestion, not a condition for merging this PR. This PR changes generation guidance, and we have not reproduced a failing generated Terraform artifact or deployment for that omission. Explicitly documenting the provider setting remains a useful improvement.

This edit changes only that item's disposition. The September 22 review text below is retained as historical context.

---

[🤖 AI review 🤖]

Reviewed exact head 25c60e9cf694f02dc4c4e0e82359da04fa67cac6 against base ec681ba5d49b039dbf1ef9d87d3304205b824f3d using OCR delegation, one fresh independent general reviewer, a parent repository review, and candidate verification. Request changes: one remaining P1 and two verified P2 findings.

• P1 — regional selection remains unresolved: Auto Mode still defaults into China Regions despite the current EKS FAQ exclusion. Follow-up is in the existing regional thread.
• P2 — Auto Mode creation: the generation instructions omit bootstrap_self_managed_addons = false, exposing the allowed provider's incompatible default.
• P2 — ARM64 estimate/generation alignment: pricing requires the custom NodePool to be applied before the Generate phase that emits it, while later output retains and claims alignment with the earlier Balanced estimate.

The latest Q8 option references, removed-sentiment trigger, and Standard EKS wording are verified fixed in both copies; I replied in the original discussion. The earlier resolved-target, NodeClass API and x86_64 fixes remain intact. The two new findings are inline and apply to both mirrors.

Validation: all 36 authored Markdown files were covered even though OCR excluded their extension; all 18 mirror pairs match. The parent ran 151 registered Node tests, formatting, Markdown lint, drift and git diff --check successfully. Provider defaults and phase contracts were checked against original source, with the new provider evidence independently refetched after candidate review. The required hybrid evidence gate passed.

These are source/provider-contract and local-check results. No end-to-end model migration or EKS deployment was run. GitHub CI and merge readiness remain separate requirements.