DEV Community: Akhil Anil

How to Set Up Microsoft Entra ID SSO for AWS DevOps Agent

Akhil Anil — Sun, 23 Aug 2026 09:55:11 +0000

In my previous post I set up AWS DevOps Agent across a couple of AWS accounts — Agent Space, IAM roles, the lot. The bit I left out was login.

We already use Microsoft Entra ID for everything else, so putting the DevOps Agent web app behind the same SSO was the obvious next step. It took about twenty minutes. Here's the whole thing, start to finish.

What you're actually setting up

It's OIDC, not SAML. AWS DevOps Agent runs an authorization code flow with PKCE against Entra, and you give it four values: issuer, client ID, client secret, and a redirect URI that AWS generates for you.

Two things stay separate, and it's worth being clear about which is which:

Microsoft Entra ID  →  decides WHO can open the web app
AWS IAM roles       →  decide WHAT the agent can read in your accounts

Setting up SSO changes the front door. It doesn't change anything about what the agent can reach.

Before you start

An Agent Space that already exists — the IdP config lives on it
Permission to create an App Registration and a client secret in Entra
Admin access to the AWS DevOps Agent console
The Region your Agent Space is in. I lost five minutes staring at an empty list because I was in the wrong one.

You don't need IAM Identity Center. This replaces it.

Step 1 — Register an app in Entra

Entra admin center → Entra ID → App registrations → New registration

Three things on the form:

Name — I used AWS DevOps Agent. It shows up on the consent screen, so pick something people will recognise.
Supported account types — Accounts in this organizational directory only. Single tenant.
Redirect URI — leave it blank.

That last one feels wrong, but AWS won't give you the redirect URI until the IdP is connected, so you have to come back for it in Step 4.

Hit Register, then grab two values off the Overview page: Application (client) ID and Directory (tenant) ID.

Step 2 — Create a client secret

Certificates & secrets → Client secrets → New client secret

Add a description, pick an expiry, hit Add.

Now the part that trips people up: the table shows a Value and a Secret ID. AWS wants the Value. Copy it now — it's masked the moment you leave the page and there's no way to get it back.

On expiry, Entra caps you at 24 months and recommends under 12. I went with the maximum, which I'd now do differently — AWS has a Rotate client secret button that doesn't disconnect anything, so rotation is cheap. Whatever you pick, put the date in a calendar. When the secret expires, nobody can log in, and there's no warning anywhere in the AWS console.

Step 3 — Connect it in AWS

DevOps Agent console → Agent Spaces → your space → Access tab → User access → External identity provider

Four fields:

Field	What goes in it
Identity Provider	Microsoft Entra
Issuer URL	`https://login.microsoftonline.com/<TENANT_ID>/v2.0`
Client ID	Application (client) ID from Step 1
Client Secret	the secret Value from Step 2

The issuer has to be the tenant-specific v2.0 URL. Not common, not without the /v2.0, no trailing slash.

There's also a role option below — auto-create, use existing, or from a template. Auto-create is fine here; this role is just for the web app and isn't the one reaching into your other accounts.

Hit Connect. AWS immediately shows you two URLs:

Callback URL:  https://<AGENT_SPACE_ID>.aidevops.global.app.aws/authorizer/idp/callback
Login URL:     https://<AGENT_SPACE_ID>.aidevops.global.app.aws/authorizer/idp/login

Copy the callback URL.

Step 4 — Paste the redirect URI back into Entra

App Registration → Authentication → Add a platform → Web

Paste the callback URL. Platform type Web, not SPA — the token exchange happens server-side with the client secret.

Paste it, don't retype it. Entra matches the redirect URI exactly, the path is case-sensitive, and there's no trailing slash. Get it wrong and you'll get AADSTS50011 at login, which at least tells you what's broken.

Step 5 — Restrict who can log in

Easy to skip, and worth thirty seconds.

Enterprise applications → your app → Properties → Assignment required? → Yes

Then Users and groups → Add user/group and assign a group.

Assigning people without flipping that toggle does nothing — it defaults to No, and any account in your tenant can sign in. Since opening the web app is the access control for a shared Agent Space, this is the setting that matters.

Step 6 — Test it

Open the Login URL in a private window. Use private browsing — with an existing Microsoft session it all happens too fast to tell whether it actually worked.

This is the AWS-hosted hand-off page, and the one your team will actually meet day to day once a session has lapsed. Log in with SSO starts the flow:

From a clean session the Login URL skips straight past it:

Login URL
   ↓  straight to Microsoft, no AWS login page
Microsoft sign-in + your usual MFA
   ↓  consent prompt (first time only)
AWS DevOps Agent, logged in

AWS never asks for a username or password of its own — credentials only ever get typed on Microsoft’s side. If anything other than Microsoft prompts you for one, something is wrong.

When it doesn't work

AADSTS50011 — redirect URI mismatch. Compare the two character by character, including case.
Login works, app then errors — same thing. Recheck the redirect URI.
"IdP configuration error" — no refresh token came back. Add offline_access as a delegated Microsoft Graph permission on the app registration.
Fails before Microsoft even loads — issuer URL is wrong. And note you can't edit it: AWS only lets you change the client secret after connecting, everything else means disconnect and reconnect. Disconnecting also wipes chat and artifact history, so get it right the first time.
Worked yesterday, dead today — check the client secret expiry.
Nothing works and the secret looks right — make sure you pasted the Value and not the Secret ID. They sit next to each other and look identical.
Blocked by policy — check the Enterprise Application's Sign-in logs before touching anything in AWS. Conditional Access failures show up there with a real error code.

One more: don't add a groups claim under Token configuration. AWS doesn't use group membership and it causes authentication failures.

Bonus — a nicer URL

The web app lives at https://<AGENT_SPACE_ID>.aidevops.global.app.aws. Nobody is remembering that, and it looks like phishing when you paste it in Slack. So we put a small Nginx pod in front of it and gave the team devops-agent.<YOUR_DOMAIN> instead. Convenience only — the real boundary is still Entra.

server {
    listen 80;
    server_name devops-agent.<YOUR_DOMAIN>;

    location / {
        # variable + resolver, so Nginx re-resolves DNS at runtime instead of
        # caching the CloudFront IPs forever at startup
        resolver 8.8.8.8 valid=30s ipv6=off;
        set $upstream "<AGENT_SPACE_ID>.aidevops.global.app.aws";

        # upstream needs both SNI and Host set to its own name
        proxy_pass https://$upstream/authorizer/idp/login;
        proxy_ssl_server_name on;
        proxy_set_header Host $upstream;
    }
}

Note it points at the login path, not /. This is a front door, not a proxy for the whole app.

The one thing to know: don’t add your custom domain as a redirect URI in Entra. AWS builds the redirect_uri from the Agent Space ID, so the login always comes back to the AWS hostname whichever door you walked in through. Your domain never appears in the OAuth flow at all.

A plain return 302 to the login URL does the same job in one line, if you would rather skip the proxy. You land on the AWS URL either way.

The whole thing

        devops-agent.<YOUR_DOMAIN>
                    │
                    ▼
              Nginx (EKS)
                    │
                    ▼
        AWS DevOps Agent Agent Space
           │                    │
           ▼                    ▼
    Microsoft Entra ID      IAM roles
      (who logs in)      (what it can read)
                              │
                        ┌─────┴─────┐
                        ▼           ▼
                       Dev         Prod

That's it. Entra handles the login, IAM handles the access, and the team just bookmarks one short URL.

If you want the IAM and multi-account half — trust policies, Terraform, connecting secondary accounts — that's all in the previous post.

How to Set Up AWS DevOps Agent: Agent Space, IAM, and Multi-Account Access

Akhil Anil — Sun, 16 Aug 2026 09:29:51 +0000

I set up AWS DevOps Agent a while back across our AWS Organizations environment — a central account running the Agent Space, with development and production connected to it — and did the IAM side in Terraform rather than clicking through the console.

This is the walkthrough I wanted when I started: what the moving parts actually are, the order to do them in, and the four or five places where the documented happy path doesn't match what happens.

If you just want the official steps, the AWS user guide is good and I'll link the relevant pages as I go. What follows is that path plus the friction.

What AWS DevOps Agent is, briefly

It went generally available at the end of March 2026. Two halves: release management (still preview — code review, release readiness, autonomous testing) and production operations, which is the part I actually use.

Production operations does four things: investigates incidents when an alert arrives, produces mitigation plans, surfaces preventative recommendations from patterns across your incident history, and answers on-demand SRE questions conversationally.

The useful mental model isn't "AI in the AWS console." It's a read-only correlation layer over infrastructure you already have instrumented. During an incident I normally open CloudWatch, RDS metrics, EC2, the EKS console, load balancer health, Logs Insights, and deployment history — and only then start thinking. The agent collapses the collecting part. It doesn't generate telemetry, and if your observability is thin it just gets you to an incomplete picture faster.

Three concepts you need before any of the setup makes sense:

Agent Space — the container and the access boundary. It defines which AWS accounts, which integrations, and which users the agent can reach. Investigation history and chat history are isolated per Agent Space. Agent Spaces are regional.

Topology — what the agent builds after you connect an account. It's a graph of your resources and their relationships, and it's what lets the agent reason about blast radius instead of just reading metrics.

IAM roles — how it reaches anything at all. The agent never uses your credentials. It assumes roles you create, using the service principal aidevops.amazonaws.com.

One structural thing that confused me for the first ten minutes: there are two consoles. Administrators configure Agent Spaces in the AWS Management Console. Operators run investigations in a separate web app, with its own IAM role and its own auth flow. So you're creating two roles before you've connected a second account.

Prerequisites

Before you start clicking:

A supported Region. Six of them: N. Virginia, Oregon, Frankfurt, Ireland, Sydney, Tokyo. The Agent Space stores its data in the Region where you create it, so pick with data residency in mind — this isn't easily changed later.

IAM permissions to create roles, in every account you plan to connect. The console's auto-create option needs this in the primary account; secondary accounts need it wherever you create the cross-account role.

iam:PassRole in the primary account — only needed if you're connecting secondary accounts, but get it in place early. More on why below, because this one produces a genuinely confusing error.

A decision about console vs. infrastructure-as-code. The console's auto-create path is the fastest way to a working Agent Space and it's what I'd use to evaluate the service. It's not what I'd want owning cross-account trust into production long-term. You can start with auto-create and move to IaC later; you can't easily reconstruct why a hand-clicked trust policy says what it says.

Awareness that this costs money. Pay-per-second, no commitment, billing started April 10, 2026. AWS Support customers get monthly credits scaled to their support tier. Worth checking what your tier includes before you turn it loose on a large estate.

Step 1 — Create the Agent Space

In the AWS DevOps Agent console, choose Create Agent Space. You give it a name, an optional description, and an optional response language (it defaults to matching the language of your input).

Then two sections that both create IAM roles, and this is the real decision point of the whole setup.

"Give this Agent Space AWS resource access" — the role the agent uses to investigate resources in the primary account. Three options: auto-create a role, assign an existing role, or build one from a policy template. Auto-create is the recommended default.

"Enable web app" — the operator role, for the separate web app where investigations actually happen. Same three options.
Then Create.

The moment the space exists, it starts scanning the account for resources and relationships. That takes a few minutes. Once it's done, Operator access appears on the Agent Space details page and opens the web app in a new tab.

What I'd do differently on a second run: use auto-create for the web app role and a pre-created role for resource access. The web app role is boring and account-local. The resource access role is the one that matters, the one you'll want to reason about later, and the one whose ARN you'll need again for anything you connect later.

Step 2 — Understand the IAM before you accept it

Auto-create is convenient and I'd still recommend it for a first look, but you should know what it's building, because the same three components appear in every account you ever connect.

The trust policy

The role trusts the AWS DevOps Agent service principal directly:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "aidevops.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<PRIMARY_ACCOUNT_ID>"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:<REGION>:<PRIMARY_ACCOUNT_ID>:agentspace/*"
        }
      }
    }
  ]
}

Those two conditions are the entire security story. aws:SourceAccount and aws:SourceArn are confused deputy prevention — without them, the service principal is a wide-open door, because aidevops.amazonaws.com is the same principal in every AWS account on earth. The conditions are what say "only an Agent Space in my account may use this role."

The operator role's trust policy is nearly identical but needs sts:TagSession alongside sts:AssumeRole, because the web app scopes access using a session tag (aws:PrincipalTag/AgentSpaceId). If you're hand-building that one and it fails, missing TagSession is the reason.

The permissions

Attach the AWS-managed AIDevOpsAgentAccessPolicy for resource access — read-only permissions for discovery, configuration and metric reads, and log analysis. The operator role gets AIDevOpsOperatorAppAccessPolicy instead.

The bit everyone forgets

A small inline policy allowing iam:CreateServiceLinkedRole, scoped to the Resource Explorer service-linked role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCreateServiceLinkedRoles",
      "Effect": "Allow",
      "Action": ["iam:CreateServiceLinkedRole"],
      "Resource": [
        "arn:aws:iam::<ACCOUNT_ID>:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
      ]
    }
  ]
}

This is what lets the agent bootstrap Resource Explorer in the account. Skip it and the setup still succeeds — you just get a much thinner topology and no obvious error telling you why. It goes on every role, in every account, primary and secondary.

Why it matters: the agent discovers resources two ways — by walking CloudFormation stacks, and via Resource Explorer for everything else. If you're a Terraform shop, that second path is doing nearly all the work, because none of your infrastructure is in CloudFormation. Resource Explorer largely sets itself up once this policy is in place, and it indexes off tags, so inconsistent tagging gives you an inconsistent topology. Give it time before you panic: tagged resources show up within minutes, untagged ones can take up to two hours.

Step 3 — Connect the primary AWS account

If you used the console flow, this already happened — creating the Agent Space with a resource access role associates the primary account for you.

If you're doing it via CLI or IaC, it's an explicit association, and the thing to notice is accountType:

aws devops-agent associate-service \
  --agent-space-id <AGENT_SPACE_ID> \
  --service-id aws \
  --configuration '{
    "aws": {
      "assumableRoleArn": "arn:aws:iam::<PRIMARY_ACCOUNT_ID>:role/<AGENT_SPACE_ROLE>",
      "accountId": "<PRIMARY_ACCOUNT_ID>",
      "accountType": "monitor"
    }
  }' \
  --region <REGION>

monitor is the primary account that hosts the Agent Space. source is every additional account. You'll use source in step 5.

Step 4 — Verify the primary account works

Three checks, in increasing order of how much I trust them.

One — the association exists:

aws devops-agent list-associations \
  --agent-space-id <AGENT_SPACE_ID> \
  --region <REGION>

Two — the topology has something in it. Open the web app via Operator access, go to the Topology page, and switch to the System view, which shows account and Region boundaries. Then All Resources to see whether discovery actually found your estate. Empty here means Resource Explorer, tags, or patience — in that order.

Three — ask it something only a working connection can answer. Not "what can you do," but something specific to a real resource: "list the RDS instances in this account and their instance classes." If it answers with your actual inventory, the role works. This is the only check I fully trust, because the first two can pass while the agent still can't read anything useful.

Step 5 — Connect additional AWS accounts

This is where most real deployments end up, because applications rarely live in one account.

The trust model

The important thing to understand — and it's not obvious from the console flow — is that the agent does not assume a role in the primary account and then chain into the second account. The AWS DevOps Agent service principal assumes the role in the secondary account directly:

AWS DevOps Agent  (aidevops.amazonaws.com)
        │
        │ sts:AssumeRole
        ├──────────────► DevOpsAgentRole (Secondary Account A)
        │                     ├── AIDevOpsAgentAccessPolicy
        │                     └── inline: Resource Explorer SLR
        │
        └──────────────► DevOpsAgentRole (Secondary Account B)
                              ├── AIDevOpsAgentAccessPolicy
                              └── inline: Resource Explorer SLR

There's no role in the middle. What restricts it is the trust policy conditions — the same aws:SourceAccount and aws:SourceArn pair, pointing at the primary account and its Agent Space.

The console path

Agent Space → Capabilities tab → Cloud section → Secondary sources → Add. You name the role, and the console hands you a trust policy and an inline policy. You take both to the IAM console in the target account, create a custom-trust-policy role, paste the trust policy, attach AIDevOpsAgentAccessPolicy, name the role exactly what you told the console it would be called, create it, then add the inline policy. Back in the primary account, choose Next and confirm the status shows Active.

It works. It's also a lot of clipboard for something that grants cross-account read access to production.

The gotcha that will cost you twenty minutes

The principal adding a secondary account needs iam:PassRole in the primary account.

This fails with an HTTP 403 AccessDeniedException naming iam:PassRole — even if that principal already has full `aidevops:`*. And the fix has a trap in it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<PRIMARY_ACCOUNT_ID>:role/*",
      "Condition": {
        "StringEquals": { "iam:PassedToService": "aidevops.amazonaws.com" }
      }
    }
  ]
}

The Resource must be the role wildcard. A policy scoped to specific role ARNs does not satisfy the check — the check itself is performed against the wildcard. This is counterintuitive if you've been trained to scope everything, and it's the kind of thing you'll spend a while assuming you got the ARN wrong.

Also: the check re-runs every time you update a secondary account, not just when you add one. Already-connected accounts keep working until the next update, so this can surface weeks later.

My setup: one Agent Space, Dev and Prod

Here's how it looks in my environment:

        Organization / Management Account
                       │
             AWS DevOps Agent Agent Space
                       │
              ┌────────┴────────┐
              │                 │
        Development         Production
          Account             Account

One Agent Space in a central account, with dev and prod connected as secondary sources. Each target account has its own role — not a shared one — so permissions can diverge later, the two show up as distinct principals in CloudTrail, and revoking one environment means deleting one role.

Why one Agent Space instead of one per environment

I could have built two. AWS's documentation actually nudges you that way — it lists "environment isolation: separate production from non-production" as a reason to create multiple Agent Spaces.

I went with one because a lot of my real investigations don't respect the account boundary. "This started after last night's deploy" begins in dev and lands in prod. "Why is prod behaving differently under the same query pattern?" is inherently a comparison. Two Agent Spaces would put me back to being the integration layer between two tools that can't see each other — which is exactly the problem I was trying to reduce.

Secondary benefits: one place to look, one topology, integrations configured once instead of per environment, and adding the next account is three Terraform resources rather than a new setup project. Account separation is completely untouched — dev and prod are still separate AWS accounts with separate roles.

The trade you're making, stated plainly: operator access and investigation data are both scoped per Agent Space, not per connected account. Anyone who can open the web app can ask about every account in that space. There's no "dev-only operator" tier inside a space. Concurrency is shared too — the defaults are 3 concurrent investigations and 10 concurrent chat invocations per space, both adjustable.

For me that's fine, because web app access is restricted to the DevOps team and that team already holds production authority. Developers don't get an operator login. When the set of people allowed to investigate dev is identical to the set allowed to investigate prod, per-environment isolation is guarding a boundary that doesn't exist in the org chart.

So the decision rule isn't "always separate prod." It's "do the same humans investigate both?" If developers self-serve investigations in dev while a separate group owns prod, split the spaces — the isolation is doing real work there.

Why I did the IAM in Terraform

Cross-account trust into production, created by hand from a clipboard, with no diff and no review, is the kind of thing that's correct on day one and mysterious on day ninety.

The shape is one aliased provider per target account and three resources in each:

provider "aws" {
  alias  = "dev"
  region = "eu-central-1"
  assume_role { role_arn = "arn:aws:iam::<DEV_ACCOUNT_ID>:role/<DEPLOY_ROLE>" }
}

provider "aws" {
  alias  = "prod"
  region = "eu-central-1"
  assume_role { role_arn = "arn:aws:iam::<PROD_ACCOUNT_ID>:role/<DEPLOY_ROLE>" }
}

locals {
  agent_space_account = "<MANAGEMENT_ACCOUNT_ID>"
  agent_space_arn     = "arn:aws:aidevops:eu-central-1:<MANAGEMENT_ACCOUNT_ID>:agentspace/<AGENT_SPACE_ID>"
}

Alias every provider and leave no default. An unaliased default provider in a config that touches production IAM means any resource where someone forgets the provider argument silently lands wherever the default points.

Then, per account:

data "aws_caller_identity" "dev" { provider = aws.dev }

data "aws_iam_policy" "devops_agent_access_dev" {
  provider = aws.dev
  name     = "AIDevOpsAgentAccessPolicy"
}

resource "aws_iam_role" "devops_agent_dev" {
  provider = aws.dev
  name     = "DevOpsAgentRole-AgentSpace-dev"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "aidevops.amazonaws.com" }
      Action    = "sts:AssumeRole"
      Condition = {
        StringEquals = {
          "aws:SourceAccount" = local.agent_space_account
          "aws:SourceArn"     = local.agent_space_arn
        }
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "devops_agent_access_dev" {
  provider   = aws.dev
  role       = aws_iam_role.devops_agent_dev.name
  policy_arn = data.aws_iam_policy.devops_agent_access_dev.arn
}

resource "aws_iam_role_policy" "devops_agent_dev_slr" {
  provider = aws.dev
  name     = "AllowCreateResourceExplorerServiceLinkedRole"
  role     = aws_iam_role.devops_agent_dev.name

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid      = "AllowCreateServiceLinkedRoles"
      Effect   = "Allow"
      Action   = ["iam:CreateServiceLinkedRole"]
      Resource = [
        "arn:aws:iam::${data.aws_caller_identity.dev.account_id}:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
      ]
    }]
  })
}

Two details worth copying:

StringEquals on aws:SourceArn, not ArnLike with agentspace/*. The docs use the wildcard because on the primary role you have a chicken-and-egg problem — the space doesn't exist yet. For secondary accounts it already does, so pin the exact ARN. It costs nothing, and it means a second Agent Space created in that account tomorrow, by someone else, cannot reach production.

data.aws_caller_identity instead of a hardcoded account ID in the service-linked-role ARN. It has to resolve to the account the role lives in. Paste the number by hand and a future provider change gives you a policy pointing at the wrong account and an SLR failure with an unhelpful error.

The prod block is the same three resources against aws.prod. Right now that's literal duplication; the module refactor happens when the third account arrives. Two copies didn't justify the indirection.

What this buys: the trust relationship is reviewable in a pull request, drift is visible, and there's a git history explaining why production trusts one specific Agent Space ARN. The associations can be code too — there are awscc provider resources for the agent space and its associations.

Running a first real investigation

Once both accounts were connected, the test I used was a question I've genuinely asked during incidents: "Why did database connections drop around 14:30 yesterday?"

The manual version of that investigation:

CloudWatch alarm history
        ↓
RDS connection + CPU metrics for the window
        ↓
application logs in CloudWatch Logs Insights
        ↓
deployment history — did anything ship?
        ↓
security groups / subnets / NAT — did networking change?
        ↓
CloudTrail — did anyone change a config?

Six places, each requiring me to hold the previous answer in my head while navigating to the next. Roughly twenty minutes before I have a hypothesis.

The agent-assisted version is the same investigation with the fetching collapsed. I describe the symptom and the window; it pulls the metrics, checks the topology for what's connected to that database, looks at deployment data if a pipeline is connected, and returns a correlated picture with its reasoning trail.

What you get is a starting hypothesis and the evidence behind it — not a verdict. Sometimes it lands on the cause. Sometimes it surfaces a correlation that turns out to be coincidental, and I only catch that because I know the system. It has never removed the need for me to understand what a connection pool is.

Every reasoning step lands in an immutable agent journal, and API calls land in CloudTrail. That matters practically, not just for compliance: an answer you can't audit is an answer you can't act on at 3am.

Where it's earned the most in my day-to-day:

RDS — CPU spikes, connection swings, memory pressure, whether utilisation matches the instance class. The win isn't that it knows something I don't; it's that "pull these five metrics over this window and tell me what's unusual" is one sentence instead of five console navigations.

EKS — because Kubernetes incidents so often aren't Kubernetes incidents. A pod that can't reach a database has a problem living in RDS, a security group, a route table, or an IAM policy. Asking about the pod and the AWS-side dependency in one conversation removes a real context switch. One caveat if you're following along: EKS needs an extra step beyond the IAM role above — an access entry on the cluster for the agent's role — which I'll cover in a separate post.

Resource sizing, carefully. AWS documents preventative recommendations spanning observability, infrastructure optimisation, pipelines, and resilience. I use the agent as one input when asking whether something looks oversized — it assembles the utilisation picture fast. It is not a rightsizing engine, and I still cross-check against Compute Optimizer, Cost Explorer, and actual knowledge of the workload's traffic shape.

Things I learned, and things to watch

Nothing in my stack got turned off. Prometheus and Grafana still hold my dashboards. CloudWatch still holds the AWS-native signal. Alerting still fires, logs and traces are where they were, Terraform still owns the infrastructure, kubectl is still open in a terminal. The agent reads what already exists — it's a correlation layer over your observability, not a replacement for it. Getting that ordering backwards is the most reliable way to be disappointed.

Onboard dev first and live with it. Same reason you don't test a restore for the first time during an outage.

Decide who can open the web app before you connect production, not after. In a shared Agent Space this is the control, because operator access is per-space. I wired the operator app to our corporate identity provider through the external IdP flow — Microsoft Entra ID — so access follows the same directory groups and MFA policy as everything else, and offboarding someone removes their agent access with their email. IAM Identity Center is the other first-class option; raw IAM authentication links with their 10-minute sessions are the fallback. That setup has enough moving parts that it deserves its own post, which I'll write separately.

PII in logs is your problem. AWS states PII is not automatically filtered and recommends redaction. If your application logs contain customer data, the agent can read it during log analysis. For anyone in a regulated industry, that's a conversation to have before onboarding, not after.

Think about where the Agent Space lives. Mine sits in the central org account, which is convenient and which I'd revisit. AWS's own guidance leans toward a dedicated account as primary with application accounts attached as secondaries, and general Organizations practice keeps workloads out of the management account. Designing from scratch, I'd put it in a dedicated tooling account.

Removing a secondary account does not delete the IAM role. Cleanup is on you — or on Terraform, which is one more argument for managing it as code.

Check the quotas against your reality. 3 concurrent investigations and 10 concurrent chat invocations per Agent Space by default, both adjustable. 100 Agent Spaces per account per Region. Fine for most teams, worth a look if you're planning something large.

Worth it?

Setup is genuinely about an hour for a single account, and maybe a couple of hours for a multi-account setup done properly in Terraform with the IAM reviewed rather than clicked.

What I'd tell someone evaluating it: the value shows up in the first ten minutes of an investigation, and drops off sharply after that. The mechanical phase — open the consoles, pull the metrics, line up timestamps, check the deploys — compresses. The reasoning phase doesn't, and shouldn't.

I don't think AI agents reduce how much AWS, Kubernetes, networking, or database internals you need to know. If anything they raise it, because the new skill is judging whether the agent's reasoning holds up. A confident, wrong correlation is only dangerous to someone who can't tell.

But the evidence-gathering phase was always the least valuable part of the job, and it's the first part that's turned out to be automatable. That's a smaller claim than the marketing makes, and it's the one I'd actually stand behind.

AI Didn't Replace My DevOps Workflow. It Shortened the Path to a Hypothesis.

Akhil Anil — Sun, 09 Aug 2026 09:49:21 +0000

How an alert, ten browser tabs, and a Slack ping actually get resolved when AI is in the loop — and where I still don't trust it.

An alert fires.

I open Grafana. Then CloudWatch. Then the logs. Then kubectl describe on the pod that's misbehaving. Then GitHub, to see what merged. Then Argo CD, to see what actually rolled out.

Ten tabs in, trying to hold six timelines in my head at once, someone drops into the channel:

Do we know what happened yet?

That moment is the real job. Not the syntax. Not remembering the exact kubectl flag. The job is correlating scattered signals fast enough to form a hypothesis worth testing. That's the part where AI has changed how I work. It didn't take the troubleshooting away from me. I'm still doing all of it. It just shortened the gap between "something is wrong" and "this is probably where I should look."

I don't use AI as a replacement for understanding Kubernetes, AWS, Terraform, Linux, networking, databases, or CI/CD. I use it as another tool in the workflow, one that helps me get from a problem to a testable hypothesis faster.

My AI usage today broadly splits across three areas:

ChatGPT — communication, research, reasoning, and technical analysis
Claude and Claude Code — coding, Kubernetes, scripts, configurations, and troubleshooting
AWS DevOps Agent — AWS infrastructure investigation, resource analysis, troubleshooting, and optimization

Each tool has a slightly different role. The part that actually matters isn't having access to AI. It's knowing where it's useful, what context to give it, and when its output needs to be challenged. None of them makes a production decision for me.

One habit before I get into the tools: I'm careful about what I paste into any of them. Config with real hostnames, account IDs, or anything secret-shaped stays out.

ChatGPT: the part of DevOps nobody warns you about

People underestimate how much of this job is communication.

I'll finish a technical investigation and then have to explain it — to a developer, a manager, a vendor, or the wider team — without either dumping raw metrics on someone who doesn't need them or oversimplifying to the point of being wrong.

A recent example: I was looking at EKS control-plane logging. I'd already done the actual work — figured out that api, audit, and authenticator logs were adding up to roughly 20–25 GB of ingestion per cluster per month, that ingestion was the real cost driver rather than storage, and that the sensible levers were trimming which log types we actually needed and dropping retention from 90 days to 30.

That investigation was mine. What I didn't want to spend twenty minutes on was rewriting the summary three times until it read cleanly for a Slack thread.

So I hand ChatGPT the findings and let it tighten the explanation. It isn't helping with the investigation. It's helping with the communication overhead after the investigation.

The second way I use it is more interesting: as a second pair of eyes on my own reasoning.

Say I've got a c7i.2xlarge sitting mostly idle and I'm thinking of dropping it to c7i.xlarge. The weak version of the question is "should I downsize this?" — because it just tells me what I already decided.

The version I actually get value from is:

What am I missing before I make this change?

And it'll nudge me toward network throughput, EBS bandwidth, short-lived peaks that a 30-day average hides, workload patterns, rollback path. Half of those I'd check anyway. But every so often it names the one I would've skipped, and that's the whole point.

I stopped asking AI to make the call and started asking it to find the hole in mine.

Claude and Claude Code: reducing the search space

I use Claude for the code-shaped work — Kubernetes manifests, Bash and Python scripts, CI/CD config. That part's useful but not that interesting; generating a Deployment YAML was never the hard part.

Claude Code is where it gets useful, because a Kubernetes problem almost never lives in one file.

The behavior I'm chasing is usually smeared across Helm templates, values.yaml, values-prod.yaml, a ConfigMap, a Secret, a GitHub Actions workflow, and whatever Argo CD is actually syncing. Previously I'd grep my way through all of it by hand, holding the thread in my head the whole time.

Now I can ask, against the real repo:

Find where DATABASE_HOST is defined and explain how it reaches the production Deployment.

Or:

Compare dev and prod and show me anything that affects memory limits or scheduling.

Here's a concrete one. A pod keeps restarting. I run the usual:

kubectl describe pod <pod>
kubectl logs <pod>
kubectl logs <pod> --previous
kubectl get events

And I find:

Last State: OOMKilled
Exit Code: 137

I already know the direction — this is memory. What used to eat my time wasn't forming that hypothesis; it was the file-hopping to test it. Where's the current limit set? Is a prod override quietly bumping it down? Did a recent change touch the Helm values? Claude Code walks that trail with me instead of me opening eight files to reconstruct it.

It's also confidently wrong sometimes. Once it pointed me at a limit in values.yaml and told me that was the effective value in prod — except Argo CD was syncing that service from a different repo, so the file it was reading never applied. The answer looked right. It just didn't know about the source it couldn't see. That's exactly why the output is a lead, not a verdict: it reduces the search space, and then I confirm what actually applies.

AWS DevOps Agent: correlating telemetry I'd otherwise eyeball

This is the most infrastructure-facing part of how I work.

Worth being precise here, because it's a capable product and it's easy to undersell. AWS DevOps Agent can go a long way on its own: it investigates incidents autonomously, correlates telemetry with code and deployment data, and produces root-cause analysis and mitigation plans without me driving each step. I read those as a strong lead, not a verdict. The part I lean on most is the correlation, because that's where it saves me the tab-juggling. The root-cause call and anything that touches production, I still confirm and own myself.

AWS already collects an enormous amount of operational data. Finding the graphs was never the problem. The problem is figuring out what changed at the same time as the thing that's on fire.

RDS is the clearest example. A CPU spike shows up, and normally I'd be pulling up CPUUtilization, DatabaseConnections, FreeableMemory, read/write IOPS, latency, DiskQueueDepth, Performance Insights, and the RDS events feed — one tab at a time.

Say the picture looks like this:

10:00   CPU: 20%   Connections: 100
10:05   CPU: 85%   Connections: 450
10:10   CPU: 95%   Connections: 700

The useful observation isn't "CPU hit 95%." Anyone can read that off a graph. The useful observation is that CPU and connections climbed together, and that turns a symptom into a hypothesis. Maybe replicas scaled up. Maybe connection pooling fell over. Maybe a scheduled job kicked in, or queries got slower, or a retry loop started hammering the database.

Correlation isn't proof. I still have to confirm which of those it actually was — and this is where Performance Insights earns its place: top SQL by load told me the time was going into a single unindexed query, which ruled out the retry-loop and pooling theories fast. But having the correlation surfaced for me is the difference between starting an investigation and starting it fifteen minutes late.

The same correlation habit feeds straight into cost work. Picture a c7i.2xlarge running at ~5% average CPU, ~15% peak, memory under 15%. The lazy move is to downsize on CPU alone. Instead I want CPU, memory, network, EBS/disk, and the peak-workload periods considered together, because low CPU with high memory is a completely different story.

One catch that's easy to miss: halving the instance size also halves the network and EBS bandwidth ceilings, so that 15% peak has to be re-checked against the smaller instance's limits, not the current one's. When the signals genuinely agree that c7i.2xlarge → c7i.xlarge is safe, and I've validated it, AI has directly helped me cut spend while keeping real headroom. That's more honest than saying "AI helps with cost optimization." It helped me confidently run the workload smaller.

The thing all three have in common

Strip away the tools and here's what actually changed.

Before:

Alert → metrics → logs → docs → repo search → config comparison → hypothesis

Now:

Alert → collect evidence → AI helps correlate/search → hypothesis → validate → fix

The steps didn't disappear. The evidence still has to be collected, the hypothesis still has to be validated, the fix is still mine to ship. What compressed is the messy middle: the correlating, the searching, the file-hopping.

Where the human stays in the loop

I don't hand production to any of this.

If a right-sizing analysis says an instance can shrink, I don't just run terraform apply. If Claude generates a manifest, I read every line of it. If the AWS agent points at a root cause, I still go confirm the metrics say what it thinks they say.

My loop is boring on purpose:

AI suggestion → understand it → validate it → make the change → monitor → roll back if needed

The trap is easy to fall into: create Kubernetes Deployment, copy the YAML, ship it. But if you can't explain your own resources.requests, your probes, or your affinity rules, AI just made you faster at deploying things you don't understand. That's more dangerous, not less.

AI makes syntax, searching, and retrieval cheap. If the syntax is cheap now, the judgment about whether to run it is the part that's actually worth paying an engineer for.

What moved is how long I spend getting from "something is wrong" to "this is probably where I should look." That gap used to be most of the incident. Now it's a smaller part of it, and I'd rather spend my time on the part that actually needs an engineer.

One question for the DevOps, SRE, cloud, and platform folks: where has AI actually created more work for you than it saved — a wrong root cause you chased, a confident answer that was subtly off, a place you still don't trust it? (And if you've got a genuine win, I'll take that too.)