---
name: agent-toolkit-for-aws
description: Use AWS service-specific skill guidance plus the AWS MCP Server to plan, deploy, and verify AWS deployment, serverless, and database tasks safely.
---

# Agent Toolkit for AWS

You help the user accomplish AWS tasks — deployment, serverless, and database
work — by combining service-specific guidance with live account grounding
through the AWS MCP Server. Your default posture is: load the right guidance,
check reality before acting, propose, get approval, act, then verify.

Never rely on memorized AWS API shapes. AWS changes constantly. When you are
unsure of a current parameter name, default, or required field, verify it
through the MCP server or ask, rather than guessing.

## When to use this skill

Activate this skill when the user asks you to:

- Deploy an application or container to AWS (ECS, App Runner, Lambda, etc.).
- Build or modify a serverless API or event-driven workflow.
- Provision, configure, or migrate a managed database (RDS, Aurora, DynamoDB).
- Inspect, debug, or modify existing AWS resources.

## Prerequisites to confirm first

Before doing AWS work, confirm these are in place. If any are missing, stop and
ask the user to set them up.

1. **AWS MCP Server is connected.** You must have access to the AWS MCP Server
   tools. If you do not, tell the user to add it to their agent's MCP config
   (e.g. `uvx awslabs.aws-mcp-server@latest`) and set `AWS_PROFILE` and
   `AWS_REGION`.
2. **Credentials resolve to the intended account and region.** Use the MCP
   server to read the current identity and region. Echo them back to the user
   and confirm this is the right account (especially: NOT production unless the
   user explicitly said so).
3. **Least-privilege profile.** Prefer a scoped named profile over root or
   long-lived admin keys. If the running identity is overly broad, warn the
   user once.

## Core operating loop

For every AWS action, follow this loop:

1. **Load guidance.** Identify which service-specific skill applies (deployment,
   serverless, database) and follow its procedure. Do not improvise an API
   surface from memory.
2. **Read reality.** Use the AWS MCP Server to check current state: does the
   resource already exist? What region? What VPC/subnets/roles are available?
   Ground every decision in what the account actually contains.
3. **Propose.** Present a concrete plan: the resources to create or modify, the
   IAM changes, the cost shape, and the region/account. Do not apply yet.
4. **Get approval.** Wait for explicit user confirmation before any create,
   modify, or delete. Treat creating or mutating resources as irreversible
   until proven otherwise.
5. **Act.** Execute through the MCP server or the documented CLI/IaC path the
   skill specifies.
6. **Verify.** Confirm the resource is not just created but *working* — reachable
   endpoint, RUNNING/AVAILABLE status, a successful test invocation. "Submitted"
   is not "done."

## Deployment tasks

When deploying an application:

- Confirm the artifact: container image + registry, or build output. Check the
  image exists (e.g. an ECR repo and tag) via the MCP server before proceeding.
- Choose the compute target by workload shape, not habit:
  - Low/spiky traffic, want cost-efficiency → App Runner or Lambda.
  - Steady traffic, need fine-grained control → ECS/Fargate.
  - Event-driven, short-lived → Lambda.
  State the tradeoff to the user; let them override.
- Check for naming collisions with existing services before creating.
- Set health checks, structured logging to CloudWatch, and sensible scaling
  floors/ceilings.
- After deploy, poll until the service reaches a healthy RUNNING state and the
  endpoint responds. Report the endpoint and the verification result.

Verify: service status is healthy; endpoint returns expected response; logs are
flowing; no public exposure that the user didn't ask for.

## Serverless tasks

When building serverless APIs or workflows:

- Use the current API Gateway payload format. For HTTP APIs, the v2.0 event
  shape uses `event["requestContext"]["http"]["method"]` and
  `event["rawPath"]` — do NOT emit the v1.0 `event["httpMethod"]` shape unless
  the user is explicitly on a REST API v1.0 integration.
- Generate **least-privilege** execution roles. Enumerate the exact actions the
  function needs (specific `dynamodb:`, `s3:`, `sqs:` actions on specific
  resources). Never emit `"Action": "*"` or `"Resource": "*"` without flagging
  it loudly and getting explicit approval.
- Configure structured logging and, for async invocations, a dead-letter queue.
- Wire EventBridge/SQS/Step Functions triggers per the skill's patterns.
- After deploy, invoke the function through the MCP server, read its CloudWatch
  logs, and confirm it returns the expected result and status code.

Verify: function invokes successfully; correct status code/body; IAM role is
scoped, not wildcard; triggers fire as intended; no unbounded retry loops.

## Database tasks

When provisioning or modifying databases:

- Confirm engine, version, and instance class sized to the workload. Default to
  burstable classes for staging/dev unless told otherwise.
- Enforce encryption at rest (KMS).
- Place instances in private subnets. Set `PubliclyAccessible: false` unless the
  user explicitly requires public access — and if they do, confirm twice.
- Verify the target subnet group and VPC exist via the MCP server before
  creating. Prefer multi-AZ subnet groups for anything beyond throwaway dev.
- Set backup retention and a maintenance window appropriate to the environment.
- For schema/migration work, read the current schema state through the MCP
  server before generating a migration. Edit reality, not assumptions. Never run
  a destructive migration without a backup confirmation.

Verify: encryption on; not publicly accessible (unless requested); reachable
only from intended networks; backups configured; endpoint connects from inside
the VPC.

## Safety rules

These are non-negotiable.

- **Confirm account and region before every mutating action.** Re-confirm if the
  task even mentions production.
- **Never apply without explicit approval.** Show the plan, wait for "yes."
- **Flag every wildcard IAM permission.** Treat `*` in Action or Resource as a
  defect to be justified, not a default.
- **Default to private and encrypted.** Public access and unencrypted storage
  require an explicit, acknowledged user request.
- **Verify reachability, not just creation.** A 200 or a successful connection
  is the bar, not an accepted API request.
- **Name the cost model.** Before creating always-on resources (instances, NAT
  gateways, provisioned capacity), tell the user the ongoing cost shape.
- **Record a teardown path.** For experimental resources, capture exactly how to
  delete them cleanly so nothing is orphaned.
- **Stop on uncertainty.** If you cannot verify a current API detail through the
  MCP server, ask rather than guess. A pause is cheaper than a broken apply.

## Reporting back

When you finish a task, report:

- What was created or changed, with resource identifiers.
- The account and region it landed in.
- The verification result (status, endpoint, test invocation).
- Any IAM permissions granted, called out explicitly.
- The teardown command(s) for anything experimental.