The Enterprise Agent course on AWS, services only
The Enterprise Agent course on AWS, services only
The Enterprise Agent course on AWS, services only
iam-veeramalla/awesome-enterprise-agent-guide is a 10-day course plan by Abhishek Veeramalla, created on 15–16 September 2026. It takes one agent, a Kubernetes Incident Investigator, from prototype to production on Google's Gemini Enterprise Agent Platform.The plan is good: each day adds one production capability, and each capability is motivated by a question the prototype could not answer:
- Can we trust its answers?
- Where will it run?
- Can it remember?
- Who is it?
- What may it access?
- Can we see what it did?
- What does it cost?
- Who owns it?
The repository is an outline so far. The README describes all ten days. Each
Day-NN/README.md is nine bytes long: a heading and nothing else. So this page reads the plan, not code. It maps each day to the AWS-managed service that does the same job, with the API names read from the AgentCore and EKS models. It also points out the one place where the AWS version of the design should differ from the course's.Neighbouring pages:
- Bedrock AgentCore on AWS covers the platform service by service.
- Strands Agents on AWS covers the open-source SDK.
- Kubernetes troubleshooting on EKS is the investigation procedure the agent should follow.
The ten days, mapped
| day | the course (Google) | AWS-managed equivalent | API names, from the models |
|---|---|---|---|
| 1 — why prototypes fail | the eight production questions | the same questions; this page answers each with a service | — |
| 2 — first agent | Agent Development Kit (ADK) | Strands Agents (open-source SDK) with a Bedrock model; ADK itself also runs on AgentCore Runtime | bedrock-runtime Converse |
| 3 — tools to investigate | custom Kubernetes tools | the EKS MCP server (AWS Labs), or a handful of read-only tools of your own | — |
| 4 — evaluation | an evaluation set of incidents with known answers | AgentCore Evaluations: datasets, evaluators, batch and online evaluation | CreateDataset, CreateEvaluator, StartBatchEvaluation, CreateOnlineEvaluationConfig |
| 5 — managed runtime | Agent Runtime | AgentCore Runtime | CreateAgentRuntime, InvokeAgentRuntime |
| 6 — long-term memory | Memory Bank | AgentCore Memory | CreateMemory with episodicMemoryStrategy, semanticMemoryStrategy, summaryMemoryStrategy |
| 7 — its own identity | SPIFFE | the Runtime's IAM execution role, mapped to Kubernetes by an EKS access entry | CreateAccessEntry, AssociateAccessPolicy |
| 8 — control what it can do | Agent Gateway | AgentCore Gateway with a policy engine (Cedar), and the EKS access policy | CreateGateway (policyEngineConfiguration), CreatePolicyEngine, CreatePolicy |
| 9 — monitor, govern, cost | tracing, alerts, governance | AgentCore observability into CloudWatch, application inference profiles for cost by tag, online evaluation for drift | CreateInferenceProfile (APPLICATION) |
| 10 — the whole system | the complete architecture | the table above, as one stack | — |
Every row has an AWS service. The design choices that differ are in Days 3, 7 and 8.
Day 3 and Day 8: where read-only actually comes from
The course's Day 8 list is exact:
- Allowed: read workloads, events, logs and deployment information.
- Forbidden: deleting pods, restarting applications, changing configuration, reading Secrets.
It enforces that list in the gateway, "outside the agent's own code". On AWS the list has three places it could live. Only one of them is strong enough to rely on alone.
1. The tool (Day 3) cannot express it. AWS's own EKS MCP server is the obvious toolset. It is read-only by default:
--allow-write is off. But its README is explicit about the second flag. --allow-sensitive-data-access "enables access to sensitive data such as logs, events, and Kubernetes Secrets", and it is required by get_pod_logs, get_k8s_events and get_cloudwatch_logs. An incident investigator needs logs and events, so it needs the flag, and the flag also opens Secrets. Every one-click install configuration in that README enables both --allow-write and --allow-sensitive-data-access. The tool's flags cannot draw the course's line.2. The gateway (Day 8) can, and should. AgentCore Gateway takes a
policyEngineConfiguration with a mode of LOG_ONLY or ENFORCE. Policies are written in Cedar (definition.cedar.statement), each with its own enforcementMode of ACTIVE or LOG_ONLY. That is the course's "enforce policy outside the agent's own code", and the deny is a Gateway decision the agent can explain to a human.3. The EKS access policy is the one that holds if everything else is wrong.
AmazonEKSViewPolicy, from the EKS user guide's access-policy reference, grants get, list and watch on:- deployments, replica sets, stateful sets, daemon sets, jobs and cron jobs;
- pods,
pods/logandpods/status; - events, services and config maps.
Secrets are not in it. AWS publishes them as a separate policy,
AmazonEKSSecretReaderPolicy. Bind the investigator's IAM role to AmazonEKSViewPolicy through an access entry, scoped to the application namespaces if you like (AccessScopeType is cluster or namespace). Then the Kubernetes API server itself refuses a restart, a delete or a Secret read, whatever the tool flags say and however the gateway policy is written.So the AWS design puts the line in two places:
- the access policy, which no tool flag or prompt can widen;
- the Gateway policy, in
ENFORCEmode, for the denials the agent should see and explain.
Start the Gateway in
LOG_ONLY while the evaluation set runs, read what it would have denied, then switch.The course's Day 5 grants "broad read access for speed" and tightens it on Day 8. On EKS the narrow option is a managed policy you attach in one call, so there is no speed to gain from starting broad.
One caution the access policy does not cover:
AmazonEKSViewPolicy includes config maps. Teams that keep credentials in config maps rather than Secrets will find the agent can read them. That is a reason to move them, not a reason to widen the agent's role.Day 7: identity without SPIFFE
The course gives the agent a SPIFFE ID, so cluster audit logs show which agent made each request instead of a shared service account. On AWS the same result needs no SPIFFE infrastructure:
- AgentCore Runtime runs the agent with an IAM execution role.
- An access entry maps that role to Kubernetes permissions.
- Calls reach the cluster as that IAM principal, and the EKS audit log records the role.
Give each agent its own role, and the audit log answers "which agent did this" directly.
AgentCore Identity's workload identity (
CreateWorkloadIdentity) solves a different problem. It holds the agent's identity for outbound calls to third-party APIs, through OAuth and API-key credential providers. Use it if the investigator also opens a ticket in Jira or posts to Slack. It is not how the agent authenticates to EKS.If the agent runs inside the cluster instead of on AgentCore Runtime, use EKS Pod Identity: same IAM role per agent, same access entry, same audit trail.
Day 4 and Day 9: evaluation is a service now
The course's evaluation has two halves: did the agent find the right root cause, and did it investigate sensibly. AgentCore Evaluations has evaluator levels for exactly that split.
EvaluatorLevel is TOOL_CALL, TRACE or SESSION, and an evaluator can be llmAsAJudge, codeBased or derived:| the course's measure | evaluator level | type |
|---|---|---|
| found the correct root cause | SESSION | code-based against the known answer, where the answer is a label such as OOMKilled or missing ConfigMap |
| investigated in a sensible order — checked recent changes before concluding | TRACE | LLM-as-a-judge, or code-based on the tool-call sequence |
| each tool call was appropriate | TOOL_CALL | code-based: no denied calls, no repeated identical calls |
The incident set is a dataset (
CreateDataset, AddDatasetExamples), run with StartBatchEvaluation on every change. That is Day 4's "repeatable test every time the agent changes", in CI.Day 9's "turn production failures into new evaluation cases" is online evaluation (
CreateOnlineEvaluationConfig), which scores live sessions by rule. Copying a low-scoring session into the dataset closes the loop.Day 6: which memory strategy
The course stores incident summaries — symptoms, root cause, fix — and searches them when a new incident starts. Its caution is the right one: memory should support investigation, not replace verification. AgentCore Memory's
CreateMemory takes several strategy types:semanticMemoryStrategysummaryMemoryStrategyuserPreferenceMemoryStrategycustomMemoryStrategyepisodicMemoryStrategy
Episodic is the one shaped like an incident: what happened, in order, and how it ended. Semantic suits stable facts, such as "the payments service talks to RDS through a proxy". Use both. Then add the course's own test case — similar symptoms, different cause — to the evaluation dataset, so a memory that starts steering the agent wrong fails a build.
Day 9: cost, by agent and by investigation
The course tracks model tokens, tool calls and usage per investigation, and alerts on expensive ones. On AWS:
- Per agent: an application inference profile (
CreateInferenceProfile, typeAPPLICATION, with tags) per agent makes Bedrock spend separable by cost-allocation tag. - Per investigation: AgentCore observability writes spans to CloudWatch, so tokens and tool calls per session can be queried and alarmed on.
- Rate limits: Gateway rate limits (
CreateGatewayRateLimit) cap how many tool calls one agent can make, which bounds the cost of an investigation that loops.
What the course gets right, and what to add on AWS
Right:
- one agent carried through every stage;
- each capability motivated by a question the prototype could not answer;
- evaluation before deployment;
- memory that does not replace verification;
- the agent telling a human what to do when it is denied.
All of it transfers to AWS unchanged.
Add on AWS:
- Put the read-only line in the EKS access policy, not only in the gateway.
- Give each agent its own IAM role, which is Day 7 without new infrastructure.
- Start the Gateway policy in
LOG_ONLYwhile the evaluation set runs. - Treat the EKS MCP server's sensitive-data flag as unable to protect Secrets by itself.
Not yet possible to judge: the course content. Every day's folder is a placeholder. This page compares architectures, not lessons.
Verified, and not
Read in the repository (cloned 7 October 2026,
30eec99): the README's ten-day plan, and the nine-byte placeholder README in each Day-NN folder.From the AWS API models (botocore 1.43.107):
bedrock-agentcore-control:CreateDataset,AddDatasetExamples,CreateEvaluator(levelofTOOL_CALL,TRACE,SESSION;evaluatorConfigofllmAsAJudge,codeBased,derived) andCreateOnlineEvaluationConfig;CreateMemoryand its five strategy types;CreateGatewaywithpolicyEngineConfiguration.modeofLOG_ONLYorENFORCE;CreatePolicyEngine, andCreatePolicywithdefinition.cedarandenforcementModeofACTIVEorLOG_ONLY;CreateGatewayRateLimitandCreateWorkloadIdentity.
bedrock-agentcore:InvokeAgentRuntime,StartBatchEvaluation,Evaluate,RetrieveMemoryRecords.eks: the access-scope types;bedrock:CreateInferenceProfile.
From documentation, read 7 October 2026:
- EKS access-policy permissions reference:
AmazonEKSViewPolicy's resources, includingpods/log, events and config maps, and no Secrets;AmazonEKSSecretReaderPolicygranting Secrets separately. - The
awslabs/mcpEKS MCP server README: the--allow-writedefault, the--allow-sensitive-data-accessdescription, the tools that require it, and the install configurations that enable both flags.
From documentation, not checked against an API:
- that the EKS audit log records the IAM principal for an access-entry caller;
- that AgentCore observability writes spans to CloudWatch;
- that ADK runs on AgentCore Runtime.
Not run. No agent, gateway, policy or cluster was created.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article