AWS · Claude

Connect AWS to Claude. For your whole team.

Two AWS services carry the answers people ask a chat for: DynamoDB holds the records, CloudWatch Logs holds what happened to them. An access key pasted into an MCP config reaches both with whatever its IAM policy allows, for whoever holds the config file. Loopthink holds one read-only key for the tables and log groups you tick, gives every Claude user in your team their own login, and lets Support read an order or a stack trace without the customer's e-mail address coming with it.

Free for 2 servers, no card · Paid plans from €39 · EU-hosted

The problem

AWS in a chat client, today.

AWS can restrict this, and doing so is work that has to be redone per table, per log group and per person. DynamoDB's fine-grained access control ties an item to a partition key value through a federated user id, which a static MCP key does not have, and it explicitly leaves Scan out because a scan returns every item regardless. Its attribute conditions are evaluated on what the request asked for, so a read without a projection expression returns every attribute anyway. CloudWatch Logs masks properly, but it masks at ingestion for everyone on the log group, and the one permission that reverses it, logs:Unmask, is granted per IAM identity. One key in an MCP config is one IAM identity for the whole team. The trail says the key ran a scan. It does not say who asked.

Who may do what

One matrix for AWS. Roles across, tools down.

ToolDevelopersSupportManagement
List tables and log groups Developers may use List tables and log groupsSupport may use List tables and log groupsManagement may use List tables and log groups
Get item by key Developers may use Get item by keySupport may use Get item by keyManagement may not use Get item by key
Query by key condition Developers may use Query by key conditionSupport may use Query by key conditionManagement may use Query by key condition
Scan a page of rows Developers may use Scan a page of rowsSupport may not use Scan a page of rowsManagement may use Scan a page of rows
Search log events Developers may use Search log eventsSupport may use Search log eventsManagement may not use Search log events
Logs Insights query Developers may use Logs Insights querySupport may not use Logs Insights queryManagement may use Logs Insights query
List log streams Developers may use List log streamsSupport may not use List log streamsManagement may not use List log streams
Write actions off by defaultDevelopers may not use Write actionsSupport may not use Write actionsManagement may not use Write actions

Masked for every role: e-mail, phone and delivery address attributes in every item, payment and token attributes, whatever they are called, e-mail addresses, IPs and bearer tokens inside log lines, including ones written before you set the rule, attributes that appeared after discovery, until somebody classifies them.

You set this once. Every Claude user in your team gets exactly this.

What you get

Four checks between Claude and AWS.

  1. 01

    Identify

    OIDC/SSO against your own IdP, including Microsoft Entra. The call runs as the person who made it, never as a shared service account.

  2. 02

    Authorize

    Per-role, per-tool, read or write. Anything not explicitly granted never shows up in the tool list in the first place.

  3. 03

    Mask

    Field-level masking and pseudonymization applied on your side, before the result travels. The model never sees the raw field. Composio, AnythingMCP and both provider tunnels have no field-level masking at all.

  4. 04

    Log

    Who asked, which tool, which records, which fields were masked. One audit trail across every AI client, exportable for review.

What you connect

Two services, one key.

An AWS account holds two kinds of answer: the records, in DynamoDB, and what happened to them, in CloudWatch Logs. Loopthink reaches both from the same read-only key and publishes them as separate tools, so Claude can follow an order from the table into the log without anybody switching windows.

The records

Amazon DynamoDB

You tick the tables that may be reached. Loopthink reads each one's key schema once, so the tools it publishes name the actual partition and sort key instead of asking the model to guess.

Tools per table

  • List tables the enabled ones only, with what each holds, so the model finds the right table before it reads anything.
  • Get item by key one row, by its primary key.
  • Query by key condition rows under one key, filtered, capped at 200 per call and paged from there.
  • Scan a page of rows for the questions that have no key, with the same cap and the same paging.

Read-only, by construction. No write tool exists for DynamoDB in Loopthink. Not switched off, not present. The IAM policy you paste has no write action in it either, so both layers say the same thing.

The DynamoDB MCP server AWS publishes now does data modelling; item operations moved to the AWS API MCP server, which states it is not built for more than one user.

Where the IAM policy stops for DynamoDB →
What happened to them

Amazon CloudWatch Logs

You tick the log groups. Everything else in the account stays invisible, and inside the ones you picked, masking runs at read time, so it covers the months written before anyone thought about it.

Tools per log group

  • List log groups the enabled ones, with what each one carries.
  • Search log events a filter pattern over a window, the last hour by default, up to 200 events per call.
  • Logs Insights query counts, stats and grouped results, with the log group supplied by the tool so a query cannot reach past its scope.
  • List log streams newest activity first, to see which instance or invocation wrote recently.

Read-only, by construction. Only the describe, filter and query APIs are implemented, so nothing here can delete a log group or write an event, whatever the connection is set to.

The CloudWatch MCP server AWS publishes says it can only be run locally on the same host as your LLM client, with that machine's AWS profile.

Who may read the log line? →

Both sit behind the same permission matrix above, and behind the same masking. A support colleague can read an order and the log line that mentions it, with the customer's e-mail address removed from both on the way out, and every one of those calls is logged under that person's name.

Use cases

What people actually ask Claude about AWS.

  • Support

    “What is the status of order 4711, and does the checkout log show an error for it?”

  • Developers

    “Which errors did /aws/lambda/checkout throw in the last hour, and on which instances?”

  • Management

    “How many orders landed yesterday by country, and how often did checkout fail?”

Each question runs as the person who asked it, with that person's role. A Support colleague asking the Developers question gets the tools their own role allows, not an error, not more.

Compare

Four ways to put AWS into Claude.

Native AWS connectorBuild it yourselfEnterprise gateways1Loopthink
Per-user identityOne personal login, all its rightsOnly if you build itYesYes, every call runs as the person who asked
Tool-level rolesNoYour codeYesYes, write off by default
Field maskingNoYour codeNot documentedYes, before the model sees the data
Published priceIncluded in your AWS planYour engineers' timeContact salesFree, paid from €39
EU companyNoWhatever you areMostly USYes, Germany

Native AWS connector: AWS publishes its own MCP servers. The CloudWatch one says it can only be run locally on the same host as your LLM client; the DynamoDB one now does data modelling, and data operations moved to the AWS API MCP server, which states it is not designed for multi-tenant environments. All of them run with the credentials on the machine that starts them: one identity for everybody, no roles, and no record of which person asked.

1 MintMCP, MCP Manager, Pomerium

Coming from one of them? Composio alternative · MintMCP alternative · MCP Manager alternative · AnythingMCP alternative

FAQ

Before you connect.

Does every team member need their own AWS account?
No. Loopthink holds one key or token for AWS. Your people sign in to Loopthink with their own identity, and every call to AWS is logged under their name. Seats in AWS stay where they are today.
Who has to add the connector in Claude?
One person with the right to add connectors in your Claude workspace, once. After that every team member enables it for themselves. Nobody pastes a key, nobody edits a config file.
Where does the AWS key live?
In Loopthink, encrypted, in the EU. It never reaches Claude and never reaches the people using the connector. Rotate it in AWS whenever you like and paste the new one once.
Can somebody write to AWS from the chat?
Not unless you switch it on. Write actions are a separate row in the permission matrix and are off for every role by default. If a role needs one write tool, you grant that one tool to that one role.
What does the model see?
The result of the tool call, after masking. Fields you mark as personal, such as emails, names or card details, are masked before the answer travels to Claude. The model gets the numbers, not the people.
Is there an audit trail?
Yes. Who asked, which tool, which parameters, which fields were masked, when. One log across every client your team uses, exportable for review.
What does it cost?
Free for one person and two MCP servers, forever, no card. Starter is €39 per month and adds roles, an identity of their own for every colleague, field masking and a 30-day audit. Team is €99 and adds your own APIs and SQL databases, your own domain and your own identity provider. Prices are on the pricing page, no call needed.
We already run our own MCP server for AWS. Does it still work?
Yes. Point it at Loopthink and it inherits the same login, roles, masking and audit. Nothing on the server has to change.

AWS in Claude, with rules.

One key in Loopthink, one login per person, one matrix that decides who may do what.

Free for 2 servers, no card · Paid plans from €39 · EU-hosted