DEV Community

Cover image for The Air-Gapped AI Detective: Automating L2 Support on AWS
Dhananjay Lakkawar
Dhananjay Lakkawar

Posted on

The Air-Gapped AI Detective: Automating L2 Support on AWS

There is a silent killer of engineering velocity in every B2B and SaaS startup: The L2 Support Request.
Every day, Customer Success (CS) or Account Managers ping your engineering team in Slack or Jira:

  • "Hey, Acme Corp says their data export didn't run today. Can you check?"
  • "Why was Tenant B charged twice this morning?"

Your $150k/year Senior Engineers have to stop coding, break their flow state, log into the VPN, write SQL queries against a read-replica, dig through CloudWatch logs, and translate the technical findings back to the CS team. It takes 30 minutes, but the context-switch ruins their entire afternoon. It burns 20% of your engineering team's week.
The Pivot: We need to stop treating engineers as database lookup tools.
Instead, we can build an autonomous AI agent with strict, mathematically proven read-only access to your logs and databases. Let the CS team ask the AI questions in plain English, and let the AI safely perform the forensic database and log investigations.
Here is how to build the "Air-Gapped" AI Support Detective using AWS Step Functions, Amazon Bedrock, and Amazon Athena—saving your engineering team hundreds of hours a month without risking your production environment.

The Pivot: Sandboxed AI Forensics
When you suggest letting an LLM write and execute SQL against a production database, every CTO will immediately (and correctly) say no.

  1. The AI might hallucinate a DROP TABLE or UPDATE statement.
  2. The AI might write an unoptimized 12-way JOIN that spikes CPU to 100% and crashes the live database.

We solve both problems at the infrastructure layer.
We use AWS IAM to mathematically guarantee the AI cannot mutate data, and we use Amazon Athena Federated Query to isolate the analytical compute from your live RDS database.
The 7-Service Architecture

Image12
How the Workflow Operates:

  1. The Slack/Jira Hook (API Gateway): Receives the plain-English question from the support rep ("Why did the nightly sync fail for the user 'john@acme.com' last night?").

  2. The Orchestrator (AWS Step Functions): Ensures the AI follows a strict "investigation runbook" instead of wandering aimlessly.

  3. The Ironclad Bouncer (AWS IAM): The Step Function executes under a strict ReadOnlyAccess IAM role. It is physically impossible for the system to execute an UPDATE, DELETE, or INSERT statement.

  4. The Translator (Amazon Bedrock): Step Functions sends the English question and your database schema to Claude 3.5 Sonnet. The LLM generates a SQL query to check the database state, and a CloudWatch Logs Insights query to find the error.

  5. The Safe Data Layer (Amazon Athena): Instead of running the SQL directly against your live RDS, Step Functions passes it to Amazon Athena. Athena uses "Federated Query" via AWS Lambda to read from your RDS Read-Replica. If the AI writes a terrible query, it might time out Athena, but your production RDS compute is protected.

  6. The Trace (CloudWatch Logs Insights): Step Functions simultaneously executes the Bedrock-generated log query to scan the last 24 hours of backend logs for that specific user_id.

  7. The Human Translation (Bedrock -> Slack): Step Functions takes the raw JSON SQL results (status: rate_limited) and the raw CloudWatch trace (Error 429), feeds it back to Bedrock, and says: "Explain this to a non-technical support rep."

The Final Slack Message:
"The sync failed because John's account hit the API rate limit of 10,000 requests/day at 11:42 PM. The database currently shows his account is locked until midnight. No engineering action needed; he just needs to upgrade his tier."

The CTO Perspective: Grounded Economics
When I map this out for engineering leaders, the reaction is absolute validation: "Wait... We can give CS a Slack bot that autonomously writes SQL, queries our read-replicas, and parses CloudWatch stack traces? And because it's sandboxed via IAM and Athena, it's mathematically impossible for it to break production?"
Yes. Now let's look at the unit economics.

The Human Cost: A Senior Engineer getting distracted by an L2 request takes ~30 minutes to regain their deep-work flow state. At a blended rate of $100/hour, that interruption costs the business roughly $50 in lost productivity, plus the frustration tax. If this happens 10 times a week, you are burning $26,000 a year on basic database lookups.

The AI Detective Cost:

  • Bedrock (Claude 3.5 Sonnet): Generating the queries and summarizing the answer uses roughly 4,000 tokens. Cost: ~$0.015.
  • Amazon Athena: Athena charges $5.00 per Terabyte scanned. Querying a specific user record in a read-replica scans megabytes. Cost: ~$0.001.
  • CloudWatch Insights: $0.005 per GB scanned. Cost: ~$0.005.
  • Step Functions & API Gateway: ~$0.001.
  • Total Cost per Investigation: Less than 3 cents.

You eliminate a $50 human interruption for 3 cents, and the Customer Success rep gets their answer in 45 seconds instead of waiting 4 hours for an engineer to finish their Sprint task.
Engineering Reality Check: Tradeoffs and Guardrails
This is one of the highest-ROI AI architectures you can build, but you must design around these AWS realities before deploying it:

  1. Asynchronous Execution (The Polling Loop)
    Amazon Athena and CloudWatch Logs Insights do not return data instantly. They are asynchronous APIs. You send a StartQueryExecution command, and they return a QueryId. Your Step Function must include a polling loop (using a Wait state and GetQueryExecution) to check if the query has finished before fetching the results.

  2. Tenant Isolation and PII Leaks
    If CS Rep A is only authorized to support "Client X", you cannot let the AI query "Client Y's" data. The Fix: You must pass the CS Rep's identity into the Step Function payload. Bedrock must be instructed (via Amazon Bedrock Guardrails) to append a mandatory WHERE tenant_id = 'X' to every generated SQL query. Furthermore, use AWS Macie or Bedrock Guardrails to automatically mask PII (like credit card numbers or Social Security Numbers) before the final Slack message is sent.

  3. Hallucinating Schema
    The AI cannot query a database if it doesn't know the table structure. You cannot fit a 500-table enterprise schema into a prompt. The Fix: Store your Data Dictionary (table names and column definitions) in an Amazon OpenSearch Serverless vector index, or simply use Amazon Bedrock Knowledge Bases. Have the Step Function execute a quick RAG lookup to retrieve the relevant table schemas before asking the LLM to write the SQL.

The Bottom Line
Your senior engineers were hired to build new features, scale infrastructure, and solve hard architectural problems. They were not hired to run SELECT * FROM users WHERE email = 'x' for the Customer Success team.
By leveraging AWS Step Functions as an orchestrator, IAM as a mathematical boundary, and Athena as a safe data sandbox, you can completely automate L2 support.
Give the CS team the answers they need instantly, and give your engineers their flow state back.

How much time does your engineering team spend on L2 support requests? Are you exploring AI for log and database forensics? Let's discuss your architecture in the comments below!

Top comments (0)