The Agent Toolkit for AWS is an open-source project created by AWS designed to make AI coding assistants more effective when working alongside AWS services. The toolkit now includes a newly launched MCP server, giving coding agents direct access to AWS-focused context, workflows, safety guidelines, and specialized tools needed to construct, launch, troubleshoot, and manage cloud-based systems—without depending on the AI’s built-in knowledge, which can quickly become outdated.
Rather than expecting a coding agent to guess or recall information from its training data, the toolkit delivers carefully selected, task-oriented guidance through organized components: skills, plugins, rules, and MCP server settings.
Skills function as concentrated instruction sets that walk the agent through particular AWS tasks, such as creating an S3 Tables lakehouse table, releasing a serverless application, resolving Lambda timeout issues, linking AWS Glue to a database, or adding memory capabilities to an AgentCore agent.
Plugins bundle related skills under shared categories. For instance, aws-core encompasses everyday AWS development tasks, aws-agents handles Bedrock AgentCore workflows, and aws-data-analytics manages S3 Tables, Glue, Athena, data discovery, and vector storage.
Rules files define how the agent behaves with AWS by default. They encourage the agent to favor infrastructure-as-code approaches, consult AWS documentation when uncertain, and leverage AWS MCP tools whenever possible.
The AWS MCP Server integration equips agents with real-time access to AWS documentation, AWS APIs, sandboxed script execution, and auditing through AWS-native mechanisms.
The end goal is more dependable and resilient cloud systems.
Why This Matters
Today’s coding agents are capable of generating believable AWS CLI commands, Terraform, CDK, Lambda handlers, Glue jobs, and IAM policies. Much of the time, this output works right away—but there’s a fundamental challenge that affects every AI coding agent: outdated training data.
AI models learn from data available up to a certain point in time, and by the time a model launches, that information is typically months old. For instance, GPT 5.5—released in late April 2026—was trained on data only through December 1, 2025. During that gap, AWS launches new services and updates existing APIs, documentation, and features.
Cloud development is packed with subtle nuances that can quietly cause serious failures. For example, when creating an analytics table in Amazon S3 Tables, a generic AI might write an Athena DDL statement with a LOCATION clause, since that’s a standard pattern for external tables. However, this is incorrect for S3 Tables, as the service itself handles storage management. The proper approach is to write clean SQL and reference the S3 Tables catalog through Athena’s query execution context.
The Agent Toolkit for AWS prevents these errors. Its built-in skills direct the agent to:
Inspect existing resources before creating new ones
Use the appropriate AWS APIs
Skip patterns that AWS doesn’t support
Cross-check assumptions using up-to-date AWS documentation
Generate least-privilege IAM policies
Run validation steps after making changes
Follow the correct diagnostic process when issues arise
This is especially critical in AWS environments, where the real challenge isn’t just writing code—it’s writing code that aligns with the correct AWS service, permissions model, and runtime environment.
Installing the Agent Toolkit in Your Coding Agent
The toolkit is compatible with most popular coding agents, including Claude Code, Cursor, Kiro, and VS Code. You can find example setup instructions for each platform in the AWS Toolkit repository, which I’ll reference at the end of this article.
My personal go-to coding assistant at the moment is Codex, so I’ll use it for the walkthrough below. Set up Codex first if you’d like to follow along.
To add the Toolkit to Codex, run this command in your terminal:
You should see output similar to the following, depending on what you’ve installed previously:
AI Agents on AWS
AWS Core
AWS Data Analytics
Browser
Documents
Presentations
Spreadsheets
That confirms the necessary AWS plugins are ready for your agent. If anything goes wrong, just ask your coding agent to help you troubleshoot.
Using the Toolkit with Your Coding Agent
This part is simple—just describe your goal to Codex in plain English.
Here’s what I asked it to build:
Create an Iceberg orders table using Amazon S3 Tables
Ingest order data from a JDBC source with AWS Glue
Validate and query the Iceberg table with Athena
This might appear straightforward, but it quickly becomes complex. Since I didn’t already have a JDBC data source, I also asked Codex to create an RDS database and populate it with test data. That single requirement triggers several downstream tasks: the RDS table had to sit inside a private network, so Codex needed to set up a VPC, security groups, IAM permissions, and more.
This is something AWS developers know well—what seems like a basic request usually involves intricate configuration around security, authentication, and permissions.
As you’ll see, the AWS Toolkit handles all of that complexity on our behalf.
Note: The Agent Toolkit for AWS operates within your coding-agent environment. When it needs to inspect, create, or modify AWS resources, it relies on the AWS credentials already configured in that environment. For local development, this typically means AWS CLI credentials, SSO, or environment variables—make sure one of these is set up before getting started.
To begin, I opened my Codex app and entered the following prompt:
Create an Iceberg orders table using Amazon S3 Tables, ingest order data
from a JDBC source with AWS Glue, and validate the table with Athena.
The first thing to do is set up a private JDBC source for the above
From there, Codex used the Toolkit’s skills and MCP server to automatically provision the RDS instance, configure networking and security, build the Glue connection and job, set up the S3 Tables catalog, and run validation queries via Athena—handling the entire workflow without me needing to manually specify each step.
The toolkit’s guidance prevented common missteps, such as using a LOCATION clause in Athena DDL or applying overly permissive IAM policies, that a generic AI agent would likely have made.
If you’d like to try this yourself, the Agent Toolkit for AWS and its full documentation are available on GitHub.
Final Thoughts
AI coding agents are transforming how developers work, but their usefulness is limited when cloud knowledge becomes outdated or incomplete. The Agent Toolkit for AWS bridges that gap by delivering curated, up-to-date guidance directly into your coding assistant’s workflow.
By combining structured rules, focused skills, smart plugins, and live integration with AWS services through the MCP Server, the toolkit turns a general-purpose coding agent into one that understands AWS deeply—helping you build more secure, reliable, and production-ready cloud systems without the guesswork.
Whether you’re deploying serverless applications or setting up complex data pipelines, the Agent Toolkit for AWS is worth adding to your toolkit.
with all
required VPC, networking and security infrastructure. Populate the JDBC source
with sample data,then everything else
From there, the agent simply got to work. Below are a few examples of what it produced. I’ve trimmed the full list since it was quite extensive.
Worked for 32m 49s
I'll leverage the AWS Data Analytics skills to handle the JDBC source, S3 Tables/Iceberg
table setup, data ingestion, and Athena validation. First, I'm examining the
current workspace structure so the implementation aligns with what's already in place.
The workspace already contains an aws-data-lake directory, so I'm
reviewing it before deciding whether to build on it or set up a separate
deployment package. I also need to confirm that local AWS tools and credentials
are properly configured before provisioning any actual AWS resources.
...
...
...
Files implemented:
orders-private-jdbc-source.yaml: VPC, private Aurora PostgreSQL source,
NAT/S3 endpoint, security groups, Glue connection/job, IAM roles, seed data
custom resource.
glue_orders_jdbc_to_s3tables.py: Glue 5.1 JDBC-to-S3-Tables ingestion script.
deploy-orders-end-to-end.ps1: deploys stack, uploads Glue script, grants
Lake Formation permissions, runs Glue, validates Athena.
README.md: updated runbook and validation results.
Validation completed:
CloudFormation stack: orders-private-jdbc-source
Glue job: orders-lake-jdbc-to-s3tables-orders
Successful Glue run: jr_a5c6e33544a452a107429f0f7613d5522d8f145062fbb40ad77507529a26263c
Target table: s3tablescatalog/mytablebucket.retail.orders
Athena row count: 6
Athena date range: 2026-04-01 to 2026-05-03
Athena sample rows returned ord-1001 through ord-1005
...
...
The entire process was remarkably thorough and wrapped up in just over half an hour.
But did it actually work?
Yes — and here’s the evidence.
CloudFormation
CloudFormation is the AWS service used to automate the provisioning of all resources needed for a given system. It serves as a definitive record of everything that was actually deployed. We can use the AWS CLI to inspect what CloudFormation accomplished.
We can also retrieve a complete inventory of every service and resource that CloudFormation provisioned on our behalf. I’ve included the command below, but note that I’ve reformatted the output for readability.
I won’t walk through every single service that was created, but here are the most important ones along with verification.
VPC and networking
A VPC is essentially your own isolated network within the AWS ecosystem. Built around it are components like CIDR address blocks, routing tables, subnets, and security groups — all of which govern which resources can communicate within the VPC. Let’s see what was provisioned.
aws ec2 describe-vpcs --region us-east-2 --query "Vpcs[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[VpcId,CidrBlock]" --output table
-------------------------------------------
| DescribeVpcsThe provided content is a mix of AWS infrastructure details, CloudFormation stack outputs, and a narrative describing the setup of a data pipeline involving VPC, subnets, security groups, IAM roles, RDS, Lambda, S3 Iceberg tables, and Athena. Below is a rephrased version that improves readability while preserving the original meaning and structure. HTML tags, code blocks, and images remain unchanged.
---
| VPC ID | CIDR Block |
|------------------------|------------------|
| vpc-0165f765ce1af50c0 | 10.40.0.0/16 |
bash
aws ec2 describe-subnets --region us-east-2 --query "Subnets[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[SubnetId,VpcId,CidrBlock,AvailabilityZone,MapPublicIpOnLaunch]" --output table
**Output:**
-----------------------------------------------------------------------------------------------
| DescribeSubnets |
+---------------------------+-------------------------+----------------+-------------+--------+
| subnet-0a9e1bbeeb1e7f53d | vpc-0165f765ce1af50c0 | 10.40.11.0/24 | us-east-2b | False |
| subnet-07dc3d0e99f09cdc4 | vpc-0165f765ce1af50c0 | 10.40.0.0/24 | us-east-2a | True |
| subnet-0c640ae5d30fe00e9 | vpc-0165f765ce1af50c0 | 10.40.10.0/24 | us-east-2a | False |
+---------------------------+-------------------------+----------------+-------------+--------+
bash
aws ec2 describe-security-groups --region us-east-2 --query "SecurityGroups[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[GroupId,GroupName,VpcId]" --output table
**Output:**
--------------------------------------------------------------------------------------------------------------------
| DescribeSecurityGroups |
+----------------------+-----------------------------------------------------------------+-------------------------+
| sg-0c56c3639a47dcbdb| orders-private-jdbc-source-DatabaseSecurityGroup-ZS9C0AJXzASB | vpc-0165f765ce1af50c0 |
| sg-0f1c55c20ebbf7acf| orders-private-jdbc-source-GlueSecurityGroup-XvKHWvTsRuap | vpc-0165f765ce1af50c0 |
+----------------------+-----------------------------------------------------------------+-------------------------+
---
### IAM Roles
Identity and Access Management (IAM) plays a vital role in AWS security by defining which users and services can access specific resources.
bash
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --query "StackResourceSummaries[?ResourceType=='AWS::IAM::Role' || ResourceType=='AWS::IAM::Policy'].[LogicalResourceId,ResourceType,PhysicalResourceId,ResourceStatus]" --output table
**Output:**
----------------------------------------------------------------------------------------------------------------------------------------
| ListStackResources |
+---------------------------+-----------------+--------------------------------------------------------------------+-------------------+
| GlueJobRole | AWS::IAM::Role | orders-private-jdbc-source-GlueJobRole-7cOVpk9zf1nf | UPDATE_COMPLETE |
| LakeFormationS3TablesRole| AWS::IAM::Role | orders-private-jdbc-sourc-LakeFormationS3TablesRole-4NKeHFJ0VwBh | CREATE_COMPLETE |
| SeedOrdersFunctionRole | AWS::IAM::Role | orders-private-jdbc-source-SeedOrdersFunctionRole-LPniYBvOU4jt | CREATE_COMPLETE |
+---------------------------+-----------------+--------------------------------------------------------------------+-------------------+
These roles enable key operations: creating an S3 table, loading sample data into an RDS database via a Lambda function, and syncing that data to the S3 table using an AWS Glue job.
---
### RDS Database
An RDS database served as the initial data source for our Iceberg table on S3. Once provisioned, it was populated with test data using a Lambda function.
---
### The Lambda Function
A Lambda function was responsible for seeding the RDS database with placeholder data, which would later be propagated to the S3 Iceberg table. While the actual code isn’t shown here, it consisted of approximately 70 lines of Python.
bash
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --query "StackResourceSummaries[?ResourceType=='AWS::Lambda::Function'].[LogicalResourceId,PhysicalResourceId,ResourceStatus]" --output table
**Output:**
---------------------------------------------------------------------------------------------------------
| ListStackResources |
+--------------------+--------------------------------------------------------------+-------------------+
| SeedOrdersFunction| orders-private-jdbc-source-SeedOrdersFunction-aDuplePymvWQ | CREATE_COMPLETE |
+--------------------+--------------------------------------------------------------+-------------------+
---
### An Iceberg Table on S3
Our primary objective was to generate an Iceberg-formatted table on S3 for storing, managing, and analyzing data. The screenshot below displays the table’s contents, which are an exact replica of the source data in the RDS database.
---
### Athena
Having data in an S3 Iceberg table is only useful if you can query, update, or delete it—and that’s precisely what AWS Athena enables. Initially, however, I encountered a problem: the new S3 table didn’t appear in the Athena console, so I couldn’t run queries against it. After some troubleshooting with Codex, the root cause was identified:
> The key issue is now clear: although database and table-level permissions were configured, catalog-level Lake Formation permissions were missing. According to AWS’s Athena S3 Tables documentation, the Athena principal must also have permissions on the S3 Tables catalog itself. I’ll grant full access (`ALL`) on `xxxxxxxxxxxx:s3tablescatalog/mytablebucket` to the root user and verify the fix.
Once this permission was applied, everything worked as expected.
bash
aws athena list-data-catalogs --region us-east-2 --output table
**Output:**
---------------------------------------------------------
| ListDataCatalogs |
+-------------------------------------------------------+
|| DataCatalogsSummary ||
|+-------------------------+-------------------+-------+|
|| CatalogName | Status | Type ||
|+-------------------------+-------------------+-------+|
|| AwsDataCatalog | CREATE_COMPLETE | GLUE ||
|| mytablebucket_s3tables | CREATE_COMPLETE | GLUE ||
|+-------------------------+-------------------+-------+|
Afterward, I successfully queried the table directly in the Athena console.
Glue & Spark
Glue is a data integration service from AWS designed with two core functions in mind. First, it acts as a central catalog, tracking data across various sources so services like Athena can discover and query them. Second, it leverages processing engines like Spark or Pandas to extract data from places such as RDS databases and then transform or load (ETL) it into other AWS services, including S3.
Codex created the code for a Glue Spark job to extract data from the RDS database and write it to Iceberg. I have almost a hundred lines of code to show, but for brevity, here is a small section:
import sys
from datetime import datetime, timezone
import boto3
from awsglue.context import GlueContext
from awsglue.job import Job
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from pyspark.sql.functions import col, lit, to_date
args = getResolvedOptions(
sys.argv,
[
"JOB_NAME",
"connection_name",
"source_table",
"target_table",
"watermark_bucket",
"watermark_key",
],
)
sc = SparkContext()
...
...
...
row_count = changed_df.count()
print(f"Found {row_count} changed rows")
if row_count > 0:
orders_df = changed_df.select(
col("order_id").cast("string").alias("order_id"),
col("customer_id").cast("string").alias("customer_id"),
to_date(col("order_date")).alias("order_date"),
col("status").cast("string").alias("status"),
col("amount").cast("double").alias("amount"),
col("updated_at").cast("timestamp").alias("updated_at"),
lit(datetime.now(timezone.utc)).cast("timestamp").alias("load_timestamp"),
)
orders_df.writeTo(args["target_table"]).append()
new_watermark = changed_df.agg({"updated_at": "max"}).collect()[0][0]
s3.put_object(
Bucket=args["watermark_bucket"],
Key=args["watermark_key"],
Body=str(new_watermark),
)
print(f"Updated watermark to {new_watermark}")
else:
print("No new rows to ingest")
job.commit()
Other important factors to keep in mind with the AWS toolkit
1/ Restricting the agent's access to certain AWS services.
By default, the AWS MCP Server in the toolkit uses your active IAM permissions to interact with AWS services. If you need to limit its access, you have a couple of strategies available.
a) Every request that flows through the AWS MCP Server automatically includes two global context keys:
aws:ViaAWSMCPService – This evaluates to true for any traffic routed through an AWS-managed MCP server.
aws:CalledViaAWSMCP – This identifies the specific AWS-managed MCP server, such as aws-mcp.amazonaws.com.
You can add these keys to your IAM policies to approve or block specific requests. Let's say you want to block the MCP server from deleting anything in S3. A policy like the following would prevent this:
b) An alternative approach is to set up a specific IAM role for the toolkit. Define restricted permissions for this role, then create a custom AWS CLI profile for it using aws configure. Run your coding agent with the AWS_PROFILE environment variable set to this new profile.
2/ Observability
Keeping an eye on the AWS Agent Toolkit relies heavily on the AWS MCP Server, since it acts as the central hub for tool calls and AWS operations within the managed component. This means the two go-to AWS services for monitoring are CloudWatch and CloudTrail.
The AWS MCP Server sends metrics to CloudWatch under the AWS-MCP namespace. You can monitor:
Invocation: how many times a tool was triggered
Success: successful tool calls
UserError: client-side errors, often related to IAM denies or incorrect inputs
SystemError: backend failures
Throttle: throttled request events
CloudTrail logs all AWS API calls in your account, recording the full context of each Event:
Who made the API call
The specific API action
When the event occurred
The request source IP
The IAM principal used
Whether the action succeeded or failed
Final thoughts
Whether you are a data engineer, data architect, or DevOps specialist, the AWS Toolkit can streamline your workflows significantly. Through its extensions and tools, it gives you access to the full AWS ecosystem, including over 15,000 API calls.
When paired with a coding agent, the toolkit enables you to:
Build AWS infrastructure, write code, and deploy applications while letting the agent select the most appropriate services and adhere to AWS best practices.
Access the latest AWS documentation, API specifications, and service details directly within your workflow.
Rely on proven, documented AWS patterns for complex tasks like IAM policies, data pipelines, or serverless architecture instead of relying on guesswork.
Investigate failed deployments, errors, or unexpected costs by pulling logs, metrics, stack status details, and troubleshooting guides.
Monitor agent behavior, enforce access controls via IAM, and establish guardrails like read-only access or blocking specific actions.
Integrate seamlessly with various MCP-compatible coding agents like Claude Code, Cursor, Codex, Kiro, Windsurf, and others.
That said, as my own experience with the Athena setup demonstrated, while the Toolkit is a massive time-saver, it is not foolproof. Just like any agent-driven output, always review your work before deploying to production.
For further details on the Agent Toolkit for AWS, visit the official GitHub repo.
