Using Amazon Q for AI-Assisted Debugging in Amazon EKS

Using Amazon Q for AI-Assisted Debugging in Amazon EKS

Practical insights for Kubernetes engineers

The first step: Use Amazon Q capabilities in EKS environment - Part 1:
Fix issue with AWS IAM permissions and configure EKS environment.

---

TL;DR

• Amazon Q enables AI-assisted debugging directly in the AWS Console for EKS
• It accelerates root-cause analysis but does not replace kubectl or observability tools
• Correct IAM and EKS access configuration is critical: most Amazon Q “issues” are access-related
• Best used as a diagnostic accelerator, not an automated fix engine

---

𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 Amazon 𝗘𝗞𝗦 environments is rarely straightforward. Even experienced Kubernetes engineers often need to 𝗰𝗼𝗿𝗿𝗲𝗹𝗮𝘁𝗲 𝗶𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗮𝗰𝗿𝗼𝘀𝘀 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗹𝗮𝘆𝗲𝗿𝘀: pod logs, node health, IAM permissions, control plane behavior, networking, AWS-managed integrations, etc.

AWS introduced 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 some time ago.

𝗔𝗺𝗮𝘇𝗼𝗻 𝗤, an 𝗔𝗜 𝗮𝘀𝘀𝗶𝘀𝘁𝗮𝗻𝘁 embedded into the AWS 𝗖𝗼𝗻𝘀𝗼𝗹𝗲, which brings a new operational model to 𝗘𝗞𝗦 𝘁𝗿𝗼𝘂𝗯𝗹𝗲𝘀𝗵𝗼𝗼𝘁𝗶𝗻𝗴: a 𝗰𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲, 𝗔𝗜-𝗮𝘀𝘀𝗶𝘀𝘁𝗲𝗱 𝗿𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 directly where engineers already work.

This article 𝗲𝘅𝗽𝗹𝗮𝗶𝗻𝘀 what Amazon 𝗤 adds to 𝗘𝗞𝗦 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴, where it fits into real-world workflows, and why 𝗮𝗰𝗰𝗲𝘀𝘀 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 - not AI - is the real 𝗸𝗲𝘆 to success.

---

Why EKS Debugging Is Still Challenging

Although EKS abstracts much of the Kubernetes control plane, 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 remains 𝗰𝗼𝗺𝗽𝗹𝗲𝘅:
• Pod failures often involve IAM, networking, or node capacity

• Cluster events and logs are spread across services

• Kubernetes RBAC and AWS IAM must both align

• Engineers switch constantly between tools and consoles

𝗧𝗿𝗮𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 workflows rely heavily on kubectl, CloudWatch 𝗟𝗼𝗴𝘀, 𝗺𝗲𝘁𝗿𝗶𝗰𝘀 dashboards, and 𝗱𝗲𝗲𝗽 platform 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲. This is 𝗲𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲, 𝗯𝘂𝘁 𝘀𝗹𝗼𝘄 and cognitively expensive.

---

What Amazon Q Brings to the EKS Console

𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 is an AI-powered assistant 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗲𝗱 into the AWS 𝗖𝗼𝗻𝘀𝗼𝗹𝗲 UI.

When used with EKS, 𝗶𝘁 𝗰𝗮𝗻:
• Inspect cluster state and related AWS resources

• Explain error conditions in natural language

• Correlate Kubernetes symptoms with AWS infrastructure

• Suggest likely causes and remediation paths

• Generate Kubernetes YAML examples

Unlike external AI tools, Amazon 𝗤 𝗼𝗽𝗲𝗿𝗮𝘁𝗲𝘀 𝘄𝗶𝘁𝗵𝗶𝗻 𝗔𝗪𝗦 𝗰𝗼𝗻𝘁𝗲𝘅𝘁, meaning its 𝗮𝗻𝘀𝘄𝗲𝗿𝘀 are 𝘁𝗶𝗲𝗱 to what it can 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘀𝗲𝗲 in your account and cluster.

𝗡𝗼 𝗖𝗟𝗜 installation is required. The interaction happens directly 𝗶𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗰𝗼𝗻𝘀𝗼𝗹𝗲.

---

Example Queries You Can Ask

"Why is this pod in CrashLoopBackOff?"
"Explain why my node group isn't scaling up."
"Generate a Deployment YAML for NGINX with a LoadBalancer Service."
"Check if my cluster is using deprecated APIs before upgrading to 1.33."
"How do I restrict traffic between namespaces with a NetworkPolicy?"

---

Console-Aware vs Cluster-Aware Amazon Q

It’s 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 that not all Amazon Q experiences are identical.

Today, 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 may 𝗲𝗻𝗰𝗼𝘂𝗻𝘁𝗲𝗿 the following:
• 𝗚𝗹𝗼𝗯𝗮𝗹 𝗖𝗼𝗻𝘀𝗼𝗹𝗲 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤: a general-purpose AWS assistant (broadly available)
• 𝗖𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲 𝗘𝗞𝗦-𝗻𝗮𝘁𝗶𝘃𝗲 𝗤: embedded directly in EKS resource views (pods, nodes, add-ons)

The 𝗴𝗹𝗼𝗯𝗮𝗹 𝗮𝘀𝘀𝗶𝘀𝘁𝗮𝗻𝘁 works across services and regions.
The 𝗘𝗞𝗦-𝗻𝗮𝘁𝗶𝘃𝗲 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 appears contextually on cluster pages and 𝗰𝗮𝗻 𝗶𝗻𝘀𝗽𝗲𝗰𝘁 workloads more 𝗱𝗲𝗲𝗽𝗹𝘆.
Both rely on the same fundamental principle: 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝘀 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗯𝘆 𝗮𝗰𝗰𝗲𝘀𝘀 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻𝘀.

---

Why Access Configuration Matters More Than the AI

A 𝗰𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝗶𝗼𝗻 is that Amazon 𝗤 “𝙙𝙤𝙚𝙨𝙣’𝙩 𝙬𝙤𝙧𝙠” when it 𝗿𝗲𝘁𝘂𝗿𝗻𝘀 partial or 𝘃𝗮𝗴𝘂𝗲 𝗮𝗻𝘀𝘄𝗲𝗿𝘀.
𝗜𝗻 𝗿𝗲𝗮𝗹𝗶𝘁𝘆, Amazon 𝗤 𝗰𝗮𝗻 𝗼𝗻𝗹𝘆 𝗮𝗻𝗮𝗹𝘆𝘇𝗲 what the 𝗰𝗼𝗻𝘀𝗼𝗹𝗲 𝗶𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗶𝘀 𝗮𝗹𝗹𝗼𝘄𝗲𝗱 to access.
For 𝗘𝗞𝗦, this 𝗶𝗻𝘃𝗼𝗹𝘃𝗲𝘀:
• 𝗜𝗔𝗠 permissions (e.g., eks:AccessKubernetesApi)
• EKS 𝗮𝗰𝗰𝗲𝘀𝘀 𝗺𝗼𝗱𝗲 (Access Entries preferred; legacy 𝙖𝙬𝙨-𝙖𝙪𝙩𝙝 𝗱𝗲𝗽𝗿𝗲𝗰𝗮𝘁𝗲𝗱)
• Kubernetes 𝗥𝗕𝗔𝗖 mappings via Access Policies

Modern 𝗘𝗞𝗦 clusters (especially 1.30+) rely on 𝙀𝙆𝙎 𝘾𝙡𝙪𝙨𝙩𝙚𝙧 𝘼𝙘𝙘𝙚𝙨𝙨 𝙈𝙖𝙣𝙖𝙜𝙚𝙢𝙚𝙣𝙩, where access is controlled through 𝗔𝗰𝗰𝗲𝘀𝘀 𝗘𝗻𝘁𝗿𝗶𝗲𝘀 and 𝗔𝗰𝗰𝗲𝘀𝘀 𝗣𝗼𝗹𝗶𝗰𝗶𝗲𝘀, 𝗻𝗼𝘁 the 𝙖𝙬𝙨-𝙖𝙪𝙩𝙝 𝗖𝗼𝗻𝗳𝗶𝗴𝗠𝗮𝗽.

If the 𝗰𝗼𝗻𝘀𝗼𝗹𝗲 𝗿𝗼𝗹𝗲 𝗹𝗮𝗰𝗸𝘀 proper EKS 𝗮𝗰𝗰𝗲𝘀𝘀:
• Amazon 𝗤 𝗰𝗮𝗻𝗻𝗼𝘁 𝗹𝗶𝘀𝘁 pods or nodes
• Cluster-level 𝗶𝗻𝘀𝗶𝗴𝗵𝘁𝘀 remain 𝘂𝗻𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲
• 𝗘𝗿𝗿𝗼𝗿𝘀 appear as “𝙖𝙪𝙩𝙝𝙤𝙧𝙞𝙯𝙖𝙩𝙞𝙤𝙣” or “𝙞𝙣𝙨𝙪𝙛𝙛𝙞𝙘𝙞𝙚𝙣𝙩 𝙖𝙘𝙘𝙚𝙨𝙨” messages
This is expected behavior, 𝗻𝗼𝘁 𝗮 𝗯𝘂𝗴.

---

A Common IAM Pitfall: When Amazon Q “Sees Nothing”

The user needs 𝗮𝗽𝗽𝗿𝗼𝗽𝗿𝗶𝗮𝘁𝗲 𝗜𝗔𝗠 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻𝘀 to interact with the cluster from the 𝗘𝗞𝗦 𝗰𝗼𝗻𝘀𝗼𝗹𝗲, which is typically achieved through 𝗘𝗞𝗦 𝗔𝗰𝗰𝗲𝘀𝘀 𝗘𝗻𝘁𝗿𝗶𝗲𝘀 using 𝗔𝗱𝗺𝗶𝗻𝗩𝗶𝗲𝘄 or 𝗖𝗹𝘂𝘀𝘁𝗲𝗿𝗔𝗱𝗺𝗶𝗻 policies.

𝗕𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁, 𝘆𝗼𝘂 𝗺𝗮𝘆 𝗻𝗼𝘁 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗜𝗔𝗠 𝗮𝗻𝗱 𝗘𝗞𝗦 𝘀𝗲𝘁𝘁𝗶𝗻𝗴𝘀 𝘁o use it, and when you issue a command, you may get the following error.

For example, 𝘄𝗵𝗲𝗻 you enter a 𝗰𝗼𝗺𝗺𝗮𝗻𝗱 in the 𝗰𝗵𝗮𝘁 interface, 𝘆𝗼𝘂 𝗺𝗶𝗴𝗵𝘁 𝗲𝗻𝗰𝗼𝘂𝗻𝘁𝗲𝗿 𝗮𝗻 𝗲𝗿𝗿𝗼𝗿 message like the following: “𝘐 𝘦𝘯𝘤𝘰𝘶𝘯𝘵𝘦𝘳𝘦𝘥 𝘢𝘯 𝘢𝘶𝘵𝘩𝘰𝘳𝘪𝘻𝘢𝘵𝘪𝘰𝘯 𝘦𝘳𝘳𝘰𝘳 𝘸𝘩𝘦𝘯 𝘵𝘳𝘺𝘪𝘯𝘨 𝘵𝘰 𝘢𝘤𝘤𝘦𝘴𝘴 𝘵𝘩𝘦 𝘤𝘭𝘶𝘴𝘵𝘦𝘳…”

𝗥𝗲𝗮𝘀𝗼𝗻:
The Amazon Q panel is visible and operational, but it cannot access Kubernetes objects within the cluster because 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 𝗹𝗮𝗰𝗸𝘀 the 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻𝘀 𝘁𝗼 𝗿𝗲𝗮𝗱 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝗶𝗻 your 𝗘𝗞𝗦 cluster.

---

---

In details - the full, detailed guide

⚠️Important
You 𝗰𝗮𝗻 𝗳𝗶𝗻𝗱 the detailed guide (what 𝘀𝘁𝗲𝗽𝘀 are 𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝘆 in relation to 𝗜𝗔𝗠 𝗮𝗻𝗱 𝗘𝗞𝗦, what to do if you 𝗱𝗼𝗻'𝘁 𝗵𝗮𝘃𝗲 an 𝙖𝙬𝙨-𝙖𝙪𝙩𝙝 𝗰𝗼𝗻𝗳𝗶𝗴𝗺𝗮𝗽) and the solution to the error: you will find the reference, the link, 𝗮𝘁 𝘁𝗵𝗲 𝗲𝗻𝗱 𝗼𝗳 𝘁𝗵𝗶𝘀 𝗽𝗼𝘀𝘁, in my 𝗠𝗲𝗱𝗶𝘂𝗺 article.

---

---

A brief explanation

One of the most common issues I’ve encountered is the assumption that 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆 𝗵𝗮𝘀 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀-𝗹𝗲𝘃𝗲𝗹 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 once you open the EKS console.
In practice, this is often 𝗻𝗼𝘁 𝘁𝗿𝘂𝗲.
Typical symptoms:
• Amazon Q responds with partial or generic answers
• Pod- or node-level questions fail silently
• Messages like “𝘪𝘯𝘴𝘶𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘢𝘤𝘤𝘦𝘴𝘴” or “𝘶𝘯𝘢𝘣𝘭𝘦 𝘵𝘰 𝘳𝘦𝘵𝘳𝘪𝘦𝘷𝘦 𝘤𝘭𝘶𝘴𝘵𝘦𝘳 𝘥𝘢𝘵𝘢”
• The cluster appears healthy in the console, but Q cannot explain issues
This usually indicates an 𝗜𝗔𝗠 𝗮𝗰𝗰𝗲𝘀𝘀 𝗴𝗮𝗽, not a problem with Amazon Q itself.

The most common underlying causes
The IAM role used in the AWS Console:
• Doesn't have the right EKS permissions (e.g. DescribeCluster)
• Is not 𝗮𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗲𝗱 𝘁𝗼 𝗮𝗰𝗰𝗲𝘀𝘀 𝘁𝗵𝗲 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗔𝗣𝗜

Modern EKS clusters rely on 𝗘𝗞𝗦 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗔𝗰𝗰𝗲𝘀𝘀 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁, where Kubernetes access is controlled via:
• 𝗔𝗰𝗰𝗲𝘀𝘀 𝗘𝗻𝘁𝗿𝗶𝗲𝘀
• 𝗔𝗰𝗰𝗲𝘀𝘀 𝗣𝗼𝗹𝗶𝗰𝗶𝗲𝘀
• IAM→ Kubernetes RBAC mapping
Legacy aws-auth-based assumptions no longer apply.

𝗧𝗵𝗲 𝗳𝗶𝘅 (𝗵𝗶𝗴𝗵 𝗹𝗲𝘃𝗲𝗹)
Ensure that the console role:
• Has eks:AccessKubernetesApi
• Is mapped via an 𝗔𝗰𝗰𝗲𝘀𝘀 𝗘𝗻𝘁𝗿𝘆 to the appropriate Kubernetes permissions
• Uses a read-level or admin-level Access Policy depending on use case

Once this is correctly configured, Amazon Q immediately gains the visibility required to:
• List pods and nodes
• Inspect workload state
• Provide accurate, context-aware explanations
This behavior is expected and intentional, 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 𝗻𝗲𝘃𝗲𝗿 𝗯𝘆𝗽𝗮𝘀𝘀𝗲𝘀 𝗜𝗔𝗠 𝗼𝗿 𝗥𝗕𝗔𝗖.

---

Where Amazon Q Fits in Real Operations

Amazon Q does 𝗻𝗼𝘁 replace:
• 𝙠𝙪𝙗𝙚𝙘𝙩𝙡
• GitOps pipelines (Argo CD/Flux)
• Full observability platforms
• Incident response processes

Instead, it acts as a 𝗱𝗶𝗮𝗴𝗻𝗼𝘀𝘁𝗶𝗰 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗼𝗿:
• 𝗙𝗮𝘀𝘁𝗲𝗿 understanding of failures
• 𝗥𝗲𝗱𝘂𝗰𝗲𝗱 time-to-hypothesis
• 𝗜𝗺𝗽𝗿𝗼𝘃𝗲𝗱 𝗼𝗻𝗯𝗼𝗮𝗿𝗱𝗶𝗻𝗴 for new engineers
• Consistent 𝗲𝘅𝗽𝗹𝗮𝗻𝗮𝘁𝗶𝗼𝗻𝘀 across teams
For 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 and 𝗦𝗥𝗘 teams , it becomes a first-stop 𝗿𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 𝘁𝗼𝗼𝗹 not the final authority.

---

When Amazon Q Is Most Useful

𝗥𝗲𝗰𝗼𝗺𝗺𝗲𝗻𝗱𝗲𝗱 𝘀𝗰𝗲𝗻𝗮𝗿𝗶𝗼𝘀:
• Multi-cluster EKS environments
• Teams onboarding engineers new to Kubernetes
• Incident triage and exploratory debugging
• Environments with well-defined IAM and RBAC

𝗟𝗲𝘀𝘀 𝗲𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝘀𝗰𝗲𝗻𝗮𝗿𝗶𝗼𝘀:
• Highly restricted clusters with minimal visibility
• Environments expecting “automatic fixes”
• Poorly structured access models

Amazon 𝗤 𝗶𝗺𝗽𝗿𝗼𝘃𝗲𝘀 on a good 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹; it 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗿𝗲𝗽𝗹𝗮𝗰𝗲 missing fundamental elements.

---

Key Takeaways

• 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 provides 𝗔𝗜-𝗮𝘀𝘀𝗶𝘀𝘁𝗲𝗱 𝗿𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 𝗶𝗻𝘁𝗼 𝗘𝗞𝗦 operations
• Its value depends entirely on 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗮𝗰𝗰𝗲𝘀𝘀 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻
• It 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗲𝘀 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 but does not replace engineering judgment
• Teams 𝘀𝗵𝗼𝘂𝗹𝗱 𝘁𝗿𝗲𝗮𝘁 it as a trusted(?) 𝗮𝘀𝘀𝗶𝘀𝘁𝗮𝗻𝘁, not an autonomous operator

Used properly, Amazon 𝗤 can significantly 𝗿𝗲𝗱𝘂𝗰𝗲 the 𝘁𝗶𝗺𝗲 and effort required to 𝗱𝗲𝗯𝘂𝗴 complex 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗶𝘀𝘀𝘂𝗲𝘀 in AWS environments.

---

Final Thoughts

𝗔𝗜-𝗮𝘀𝘀𝗶𝘀𝘁𝗲𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 are becoming a foundational capability in modern cloud platforms. 𝗔𝗺𝗮𝘇𝗼𝗻 𝗤 represents AWS’s first serious step toward native, 𝗰𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲 𝗔𝗜 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 for Kubernetes.

The 𝘁𝗲𝗮𝗺𝘀 𝘁𝗵𝗮𝘁 𝗯𝗲𝗻𝗲𝗳𝗶𝘁 most will be those who 𝗰𝗼𝗺𝗯𝗶𝗻𝗲:
• Clean EKS access design
• Strong IAM and RBAC practices
• Realistic expectations of AI assistance

That 𝗰𝗼𝗺𝗯𝗶𝗻𝗮𝘁𝗶𝗼𝗻 -not AI alone- is what unlocks 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗲𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆.

---

Note

This DEV.to post is a concise version of a longer, experience-based guide.

If you’re interested in deeper technical details, IAM configuration nuances, and real-world EKS lessons learned, you can read it among My medium stories

This article is the first part of a series where we explore AI-oriented debugging and operational workflows in Kubernetes and Amazon EKS environments.

---

About the Author

I’m Róbert Zsótér, Kubernetes & AWS architect.

If you’re into Kubernetes, EKS, Terraform, and cloud-native security, follow my latest posts here:

• LinkedIn: Róbert Zsótér
• Substack: CSHU

Let’s build secure, scalable clusters, together.

---

Note: Originally published on Medium Enhancing Amazon EKS Operations with AI capabilities of Amazon Q -Part 1

---