Ever felt like managing your AWS infrastructure is a bit like playing a never-ending game of whack-a-mole? Monitoring instances, fetching metrics, combining data – it’s often a manual dance between consoles, CLI commands, and scripts. But what if your cloud infrastructure could tell you what’s going on, and even proactively handle tasks, all through a simple conversation?
Enter AWS Bedrock Agents. These aren’t just fancy chatbots; they’re intelligent assistants designed to understand your intent, reason through tasks, and trigger real actions using AWS Lambda functions. Think of them as the orchestrators of your automated cloud operations.
In this article, I’ll walk you through how I built a “Supervisor Agent” using AWS Bedrock. This agent intelligently orchestrates multiple AWS Lambdas to achieve a common goal: listing EC2 instances, fetching their CPU metrics from CloudWatch, and then combining those results into one coherent answer – all without the agent ever touching AWS APIs directly. By the end, you’ll not only grasp how Bedrock Agents work, but also learn a powerful, scalable pattern for multi-step automation: the Supervisor function.
Demystifying AWS Bedrock Agents: Your Infrastructure’s New Brain
Before we dive into the code, let’s get a clear picture of what an AWS Bedrock Agent truly is. Imagine an AI persona, defined by a simple prompt, that can listen to your requests. When you ask it a question like, “How much CPU are my EC2 instances using?”, it doesn’t just return a canned response. Instead, it processes your query, understands the intent, and decides which tools it needs to use.
These “tools” are called Action Groups. Each action group is essentially a gateway to one or more AWS Lambda functions. The agent doesn’t directly interact with AWS services like EC2 or CloudWatch. Instead, it delegates the actual work to these pre-configured Lambda functions. This separation of concerns is incredibly powerful, offering enhanced security and a clear audit trail.
For example, if you ask an agent about product stock, it might trigger a “database” action group, which in turn calls a Lambda to query your DynamoDB table. Similarly, an “AWS Resources” action group could call a Lambda to list ECS tasks or even manage Kubernetes clusters via EKS – the possibilities are truly endless, extending even to third-party APIs for things like weather data or flight availability.
The magic happens in the agent’s instructions (its “prompt”). This is where you teach the agent which action group to invoke for specific types of requests, what parameters to expect, and even how to chain actions together. It’s like writing a high-level playbook for your AI assistant.
Building Blocks: Setting Up Our EC2 and CloudWatch Action Groups
Our journey begins by creating individual action groups for EC2 and CloudWatch. These will serve as the foundational “skills” our agent can tap into.
The EC2 Listing Lambda
First, we configure a Bedrock Agent and provide it with an initial set of instructions. Our primary goal for the first action group is to list EC2 instances. We define an action group named ec2 and specify a function called list_instances within it. The agent’s prompt guides it: “For EC2: Call ec2_listinstances.”
When the agent decides to use this action group, it invokes an associated AWS Lambda function. This Lambda, which Bedrock automatically creates with an `EC2` prefix, contains the logic to interact with the AWS EC2 service. Specifically, it uses the boto3 client to call describe_instances() and then formats the output into a list of instance IDs, states, types, and IP addresses. Crucially, the Lambda’s IAM role needs permissions like ec2:DescribeInstances to perform this operation.
The response from this Lambda isn’t just plain text; it adheres to a specific Bedrock agent format, ensuring the agent can correctly parse and utilize the information. After defining the Lambda code and granting permissions, we test it. A simple query like “list my ec2 instances” should yield a JSON-like output listing your instances.
Fetching Metrics with CloudWatch
Next, we add another action group, this time for CloudWatch. We’ll call it cloudwatch, and its function will be getMetrics. This function needs parameters, specifically instance_ids, so it knows which instances to fetch metrics for. We update our agent’s prompt to reflect this new capability and guide its behavior: “For EC2 + CPU: Call ec2__describeInstances, Extract instanceIds, Call cloudwatch__getMetrics, Combine results.”
The CloudWatch Lambda function is responsible for fetching CPU utilization data. It receives `instance_ids` (which might come as a stringified list from the agent, requiring careful parsing) and then uses boto3 to call cloudwatch.get_metric_statistics() for each instance. It retrieves the average CPU utilization over the last hour. Similar to the EC2 Lambda, this function also requires appropriate IAM permissions, such as cloudwatch:GetMetricStatistics, to access the metric data.
At this stage, our agent can technically handle both tasks separately, or even chain them if prompted explicitly. However, the agent’s instructions can become verbose, and the agent itself has to figure out the exact steps. This is where our Supervisor function comes in.
The Supervisor Pattern: Orchestrating Complexity with a Single Agent Call
While our agent can call EC2 and CloudWatch functions independently, or even chain them with detailed instructions, this approach can quickly become unwieldy for more complex workflows. Imagine a scenario with three, four, or even five interconnected steps. That’s where the Supervisor pattern shines.
Instead of making the Bedrock Agent responsible for orchestrating multiple specific Lambda calls and merging their results, we introduce a single “Supervisor” Lambda function. The agent’s only job then becomes to call this Supervisor, which in turn handles all the intricate, multi-step logic behind the scenes. It’s a cleaner, more scalable, and ultimately more maintainable way to build sophisticated automation.
We create a new action group, let’s call it supervisor, with a single function: analyzeInfrastructure. Crucially, we update our agent’s instructions to completely bypass direct calls to the ec2 and cloudwatch action groups. Now, the agent’s prompt becomes simpler, guiding it to use the supervisor: “Goal: Help analyze AWS infrastructure. Action Groups: supervisor: analyzeInfrastructure.”
Inside the Supervisor Lambda
The Supervisor Lambda is the brains of our multi-step operation. When the Bedrock Agent invokes analyzeInfrastructure, this Supervisor function kicks into gear:
- Invokes EC2 Lambda: It first makes an internal, programmatic call to our existing EC2 Lambda function (e.g.,
ec2-your-id) using theboto3.client("lambda").invokemethod. This fetches the list of EC2 instances. - Extracts Instance IDs: Upon receiving the response from the EC2 Lambda, the Supervisor parses it to extract all the relevant instance IDs. This involves carefully navigating the Bedrock-specific JSON response structure, perhaps using a combination of JSON parsing and regular expressions or Python’s
ast.literal_evalfor robust string-to-list conversion. - Invokes CloudWatch Lambda: With the instance IDs in hand, the Supervisor then internally invokes our CloudWatch Lambda function (e.g.,
cloudwatch-your-id), passing those instance IDs as parameters. This retrieves the CPU utilization metrics. - Merges and Returns: Finally, the Supervisor combines the textual outputs from both the EC2 and CloudWatch Lambdas into a single, comprehensive response. This consolidated message is then formatted back into the Bedrock-specific response structure and returned to the agent.
This entire process, from listing instances to fetching metrics and merging results, is encapsulated within a single call to the Supervisor. For this to work, the Supervisor Lambda’s IAM role needs lambda:InvokeFunction permissions for both the EC2 and CloudWatch Lambdas. Without this, it won’t be able to trigger them.
One small but important detail I learned during this setup was handling Lambda timeouts. My initial tests of the Supervisor function failed, showing a cryptic “3000.00ms” hint in the logs. This pointed directly to the default Lambda timeout. Increasing the Supervisor Lambda’s timeout to 10 seconds (or more, depending on your needs) resolved the issue, allowing sufficient time for the two nested Lambda invocations to complete.
This Supervisor pattern offers immense flexibility. You can continue extending its functionality by adding more internal Lambda calls for tasks like AWS billing analysis, identifying the most expensive resources, or even integrating with external APIs to fetch contextual data. Your Bedrock Agent remains focused on understanding your intent, while the Supervisor orchestrates the complex dance of your cloud automation.
Conclusion
Building an AWS Bedrock Supervisor Agent fundamentally changes how we approach cloud automation. We’ve moved beyond simple, single-action scripts to intelligent, conversational interfaces that can reason, plan, and execute multi-step workflows. By leveraging the Supervisor pattern, we’ve created a clean, modular, and scalable architecture where the Bedrock Agent acts as the intelligent front-end, and a dedicated Lambda handles the intricate orchestration of various backend tasks.
This approach not only simplifies the agent’s instructions but also makes your automation more robust and easier to maintain. As your cloud infrastructure grows in complexity, a well-designed Supervisor Agent can become an invaluable asset, transforming reactive troubleshooting into proactive, intelligent operations. The future of cloud management is conversational, and with Bedrock Agents, that future is already here.
