AWS Managed MCP Servers
Give agents access to Amazon S3, Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), and Amazon Bedrock through managed MCP servers. On an environment hosted on Amazon Web Services (AWS), AI Gateway can assume an AWS Identity and Access Management (IAM) role that you create, so you store no AWS credentials.
After reading this page, you will be able to:
-
Set up an IAM role that AI Gateway can assume with no stored AWS credentials
-
Configure an AWS managed MCP server to authenticate with that role
-
Troubleshoot a server whose role AI Gateway can’t assume
Prerequisites
To set up a server that stores no AWS credentials, you need:
-
An Agentic Data Plane environment hosted on AWS. See Create an Agentic Data Plane Environment.
-
Permission to create IAM roles and role policies in the AWS account that you deployed the environment into. See the AWS guide to creating a role with a custom trust policy.
-
The AWS Command Line Interface (AWS CLI), signed in to that account.
-
The AWS resource for the server to use: an S3 bucket, an SNS topic, an SQS queue, or an Amazon Bedrock embedding model.
What these MCP servers do
Each type works with one AWS resource that you name in its configuration, and its tools act on that resource:
| Type | Resource | Tools |
|---|---|---|
AWS S3 |
One S3 bucket and an optional key prefix that the server adds to keys in that bucket |
|
AWS SNS |
One SNS topic |
|
AWS SQS |
One SQS queue |
|
AWS Bedrock |
One Amazon Bedrock embedding model |
|
The AWS Redshift type authenticates to AWS in the same way, and it has its own setup guide. See AWS Redshift Managed MCP Server.
Choose an authentication method
Each type’s Auth section sets the AWS region and how the server authenticates to AWS. It offers three methods:
| Method | How it works | What Agentic Data Plane stores |
|---|---|---|
|
AI Gateway uses its own AWS role to assume an IAM role that you create. It works only on an environment hosted on AWS. |
No credentials. The configuration holds the Amazon Resource Name (ARN) of your role. |
|
AI Gateway uses an IAM user’s access keys to assume an IAM role that you name. |
The IAM user’s access key ID, secret access key, and an optional session token, in Secrets store. |
|
AI Gateway signs every request with an IAM user’s access keys. |
The IAM user’s access key ID, secret access key, and an optional session token, in Secrets store. |
On an environment hosted on AWS, use Gateway Assume Role when your security policy rules out long-lived credentials. An environment hosted on another cloud has no AWS identity for AI Gateway to use, so choose Assume Role or Static Credentials there.
For Static Credentials, store the IAM user’s access key ID and secret access key in Agentic Data Plane’s Secrets store with the AI Gateway scope, using UPPER_SNAKE_CASE names such as AWS_ACCESS_KEY_ID. Then select them in Access Key ID Secret Ref and Secret Access Key Secret Ref. The Assume Role method takes the same secrets under Source Credentials, plus the Role Arn of the role to assume, and an optional External ID and Session Name.
Gather the values the trust policy needs
A role’s trust policy decides who can assume the role. AI Gateway calls AWS Security Token Service (AWS STS) with its own role, and it sends an external ID made of your environment ID and the server’s name. With Gateway Assume Role, AI Gateway sets this external ID for each server, and you can’t change it in the server’s configuration. Other MCP servers send their own external IDs, so a trust policy that requires one server’s external ID doesn’t admit the others.
Collect these values before you create the role:
| Value | Where it comes from |
|---|---|
Environment ID |
The |
AWS account ID |
The AWS account that you deployed the environment into. With the AWS CLI signed in to that account, run |
Server name |
The name for the MCP server. Choose it now. The external ID contains it, and you can’t rename a server after you create it. |
AI Gateway’s role ARN |
Built from the AWS account ID and the environment ID: |
External ID |
Built from the environment ID and the server name: |
For example, take the environment d0example1cluster234 in the AWS account 123456789012, and a server named orders-queue. AI Gateway’s role ARN is arn:aws:iam::123456789012:role/aigw-d0example1cluster234, and the external ID is d0example1cluster234/orders-queue.
Grant the permissions the tools need
Write a permissions policy that grants the actions your server’s tools need, and save it as permissions-policy.json. The role’s permissions policy decides what the server can do in AWS, so grant only the actions for the tools your agents use, on the resource that the server works with:
| Type | Tool | IAM actions | Resource |
|---|---|---|---|
AWS S3 |
|
|
The bucket, for example |
AWS S3 |
|
|
The objects, for example |
AWS S3 |
|
|
The objects |
AWS S3 |
|
|
The objects |
AWS S3 |
|
|
The source object and the objects in the server’s bucket |
AWS S3 |
|
|
The objects |
AWS SNS |
|
|
The topic, for example |
AWS SQS |
|
|
The queue, for example |
AWS Bedrock |
|
|
The model, for example |
For example, this permissions policy lets a server send messages to one queue:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:orders"
}
]
}
For AWS S3, keep these points in mind:
-
If you set a
Prefixon the server, you can limit the object resources to it, for examplearn:aws:s3:::example-reports/data/uploads/*. -
The
copy_objecttool can read its source object from another bucket. The role’s permissions policy decides which source objects it can read. -
A URL from
generate_presigned_urluses the role’s permissions and stops working when the session that signed it expires, even if the tool reports a laterexpires_attime. By default, the tool sets a URL to expire after one hour (3600 seconds), but a session lasts only 900 seconds unless you setDuration Seconds. -
Without
s3:ListBucket, S3 answers a request for a missing object with an access-denied error instead of a not-found error.
If a customer managed key from AWS Key Management Service (AWS KMS) encrypts the bucket, topic, or queue, also grant the role these permissions on the key:
-
S3 bucket:
kms:GenerateDataKeyto write objects, andkms:Decryptto read them -
SNS topic:
kms:GenerateDataKey*andkms:Decrypt -
SQS queue:
kms:GenerateDataKeyandkms:Decrypt
The key’s policy must let IAM policies grant these permissions. The default key policy already does this in the key’s own account. If the key is in another AWS account, its key policy must also allow the role or the role’s account.
Create the IAM role
Create the role with the AWS CLI. The role must be under the /redpanda-adp/ path, and the AWS Management Console can’t set a role’s path.
This configuration refers to a third-party product. Specific UI elements may not be up to date. For current syntax, see the AWS documentation for aws iam create-role and aws iam put-role-policy.
|
-
Save this trust policy as
trust-policy.json, with your values in place of the placeholders:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<aws-account-id>:role/aigw-<environment-id>" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "<environment-id>/<server-name>" } } } ] }The principal is AI Gateway’s role, not your whole account. To learn why, see Limits.
-
Create the role under the
/redpanda-adp/path:aws iam create-role \ --role-name <role-name> \ --path /redpanda-adp/ \ --assume-role-policy-document file://trust-policy.jsonReplace
<role-name>with a name for the role, for exampleorders-queue-sender. The role’s ARN isarn:aws:iam::<aws-account-id>:role/redpanda-adp/<role-name>. You enter it when you create the server. -
Add the permissions policy that you saved as
permissions-policy.jsonto the role as an inline policy:aws iam put-role-policy \ --role-name <role-name> \ --policy-name <policy-name> \ --policy-document file://permissions-policy.jsonReplace
<policy-name>with a name for the policy, for exampleorders-queue-send.
Create the server
Create the server in the Agentic Data Plane UI:
-
Open MCP servers in the sidebar.
-
Click Add MCP server.
-
Click the card for the type: AWS S3, AWS SNS, AWS SQS, or AWS Bedrock.
-
Replace the suggested
Namewith the server name from the external ID, and optionally add aDescription. -
Fill in the type’s own fields:
Type Field Value AWS S3
Bucket, and optionallyPrefixThe bucket’s name, for example
example-reports, and a key prefix such asdata/uploads/AWS SNS
Topic ArnThe topic’s ARN, for example
arn:aws:sns:us-east-1:123456789012:ordersAWS SQS
URLThe queue’s URL, for example
https://sqs.us-east-1.amazonaws.com/123456789012/ordersAWS Bedrock
ModelThe embedding model’s ID, for example
amazon.titan-embed-text-v2:0 -
If the form shows an
AWSsection for AWS SNS, AWS SQS, or AWS Bedrock, leave it empty. It’s a deprecated copy ofAuth. -
In the
Authsection:-
Set
Regionto the AWS region of the resource, for exampleus-east-1. -
Leave
Endpointempty. -
In the
Authselector, chooseGateway Assume Role. -
Set
Role Arnto the ARN of the role you created, for examplearn:aws:iam::123456789012:role/redpanda-adp/orders-queue-sender. -
Optional: Set
Duration Seconds, the length of each AWS session. Keep0for the default of 900 seconds, or choose a value from 900 to 3600.
-
-
Click Create server.
The create form turns Enable code mode on by default for AWS Bedrock and leaves it off for the other AWS types. The rpk ai mcp-server create command has no code-mode flag. To add code mode from the CLI, create a Code MCP server named <server-name>-code with --code.mcp-servers <server-name>. See Code Mode.
Create the server with rpk ai
Run rpk ai mcp-server create with the type’s --managed.config payload. This example creates the orders-queue server for AWS SQS:
rpk ai mcp-server create orders-queue --enabled --managed.config '{
"@type": "type.googleapis.com/redpanda.mcps.aws_sqs.v1.AWSSQSMCPConfig",
"url": "https://sqs.us-east-1.amazonaws.com/123456789012/orders",
"auth": {
"region": "us-east-1",
"gateway_assume_role": {
"role_arn": "arn:aws:iam::123456789012:role/redpanda-adp/orders-queue-sender",
"duration_seconds": 900
}
}
}'
The auth block is the same for every AWS type. For the other types, change @type and the type’s own fields:
@type |
Type’s own fields |
|---|---|
|
|
|
|
|
|
Verify the connection
Creating the server succeeds even if AI Gateway can’t assume the role, so check the connection before an agent uses the server:
-
Open the server’s Inspector tab.
-
Confirm that the tool list loads. If AI Gateway can’t assume the role, the tab shows the error instead. See Troubleshooting.
-
Optional: To check the permissions policy too, run one of the server’s tools from the Inspector tab, such as
list_objectsfor AWS S3 orembedfor AWS Bedrock. See Run a tool. A tool that the policy doesn’t allow fails with an AWS authorization error.
Limits
Keep these limits in mind when you use Gateway Assume Role:
-
Server name reuse. The external ID combines the environment ID and the server name. If you delete a server and create another with the same name, the new server sends the same external ID and can assume the same role.
-
Other AI Gateway features. A trust policy that names AI Gateway’s role admits every AI Gateway feature that assumes IAM roles, not only MCP servers. Grant permission to create and modify large language model (LLM) providers (
dataplane_adp_llmprovider_createanddataplane_adp_llmprovider_update) and guardrails (dataplane_adp_guardrail_createanddataplane_adp_guardrail_update) only to users you trust with every role whose trust policy names AI Gateway’s role. See LLM provider permissions and Guardrail permissions. -
Role account. AI Gateway can assume a role in the AWS account that you deployed the environment into when the role’s trust policy names AI Gateway’s role ARN, as in the example on this page. For a role in another AWS account, or a role whose trust policy names a whole account as the principal, AI Gateway’s own role also needs permission to assume it. AI Gateway’s role doesn’t have that permission by default.
-
Resources in other accounts. To reach an S3 bucket, SNS topic, or SQS queue in another account, keep the role in the environment’s account, not the resource’s. Then allow the role in both the resource’s own policy and the role’s permissions policy.
-
Role path. AI Gateway accepts only roles under
/redpanda-adp/. It checks the role ARN when you save the server and again before it calls AWS STS. -
Session length. A session lasts from 900 to 3600 seconds. AI Gateway gets each session by using its own role to assume yours, and AWS limits a session obtained that way to one hour. AI Gateway requests a new session when the current one expires.
-
Audit trail. The role session name is
mcp-<server-name>, truncated to 64 characters. AWS CloudTrail logs show it in the ARN of the identity that made each call.
Troubleshooting
Common symptoms and fixes:
| Symptom | What to check |
|---|---|
Saving the server fails with |
The role isn’t under the |
Saving the server fails with |
Set |
The Inspector tab shows an error containing |
AWS refused to let AI Gateway assume the role. The message shows the role ARN and the external ID that AI Gateway sent. Check that the trust policy’s principal is AI Gateway’s role ARN, and that its |
The Inspector tab shows |
Your environment isn’t hosted on AWS. Use |
The Inspector tab shows an error ending in |
The call to AWS STS failed with an error other than access denied, or AI Gateway couldn’t refresh its own AWS credentials. If the message includes the error AWS returned, fix what it names. Otherwise, open the Inspector tab again after a few minutes. If the error persists, contact Redpanda Support. |
Running |
Your |
A tool call fails with an AWS authorization error, such as |
The role’s permissions policy doesn’t allow the action that the tool needs. The resource’s own policy or its KMS key policy can also deny it. See Grant the permissions the tools need. |