AWS MCP 서버: AI 에이전트로 AWS 다루기

AWS 콘솔에 들어가서 메뉴를 뒤져가며 EC2 인스턴스를 띄우거나 S3 버킷 정책을 만져본 경험이 있으실 텐데요. CLI에 익숙하더라도 200개가 넘는 서비스의 API를 다 외울 수는 없어서 결국 문서를 뒤지면서 작업하게 되죠.

이런 작업을 AI에게 자연어로 시킬 수 있다면 어떨까요? AWS가 2026년 5월 6일 AWS MCP 서버를 정식 출시하면서 그게 가능해졌습니다. “us-west-2 리전에 t3.micro 인스턴스 하나 띄워줘” 같은 요청을 클로드 코드나 Cursor에서 그대로 처리할 수 있어요.

이번 글에서는 AWS MCP 서버가 무엇이고 어떻게 설정해서 활용할 수 있는지 살펴볼게요.

AWS MCP 서버란?

AWS MCP 서버는 AWS가 직접 운영하는 관리형 원격 MCP 서버입니다. AI 에이전트가 IAM 자격 증명을 통해 AWS 서비스 전체에 안전하게 접근할 수 있게 해줘요. Agent Toolkit for AWS의 핵심 구성 요소로 자리 잡고 있습니다.

기존에도 AWS CLI나 SDK로 AWS를 프로그래밍할 수 있었지만 명령어 문법을 외우거나 매번 문서를 찾아봐야 했죠. AWS MCP 서버는 이 모든 API를 AI가 바로 호출할 수 있는 도구(Tool)로 감싸서, 자연어 요청만으로 EC2, S3, Lambda, DynamoDB 같은 서비스를 다룰 수 있게 해줍니다.

특히 흥미로운 점은 도구의 개수가 단 4개로 고정되어 있다는 거예요. 보통 MCP 서버는 서비스별로 수십 개의 도구를 노출하다 보니 AI의 컨텍스트 윈도우를 빠르게 잡아먹는데요. AWS MCP 서버는 범용 도구 4개만으로 15,000개가 넘는 모든 AWS API 작업을 커버합니다.

제공되는 4가지 도구

가장 핵심이 되는 도구는 call_aws입니다. AWS API 작업이라면 무엇이든 실행할 수 있어요. EC2 인스턴스 생성, S3 객체 업로드, Lambda 함수 호출, IAM 정책 수정까지 전부 이 하나로 처리됩니다. 내부적으로 사용자의 IAM 자격 증명으로 SigV4 서명을 만들어 호출하므로 별도의 인증 처리가 필요 없어요.

search_documentation과 read_documentation 두 도구는 AWS 공식 문서를 실시간으로 조회합니다. LLM의 학습 데이터는 보통 몇 달 전에 멈춰 있는데요. 그래서 최신 서비스나 신규 기능에 대해서는 잘못된 답을 내놓기 쉽거든요. 이 두 도구가 있으면 에이전트가 작업하기 전에 최신 문서를 먼저 확인할 수 있습니다. 게다가 이 두 도구는 인증 없이도 사용 가능해요.

마지막으로 run_script는 Python 스크립트를 샌드박스 환경에서 실행합니다. 여러 단계의 작업이나 복잡한 로직이 필요할 때 유용한데요. 예를 들어 “모든 리전에서 태그가 없는 EC2 인스턴스를 찾아서 목록으로 정리해줘” 같은 요청은 단일 API 호출로는 어렵지만 스크립트로는 깔끔하게 처리됩니다. 보안을 위해 샌드박스는 로컬 파일 시스템이나 네트워크에는 접근할 수 없고, IAM 권한은 사용자의 권한을 상속받아요.

인증과 권한 모델

AWS MCP 서버는 사용자의 IAM 자격 증명을 그대로 활용합니다. 별도의 토큰을 발급받거나 추가 권한을 설정할 필요가 없어요. 평소 aws configure로 설정해둔 자격 증명이 그대로 동작합니다.

다만 MCP는 OAuth 2.1 기반 인증을 사용하고 AWS는 SigV4를 쓰기 때문에 이 둘을 연결해줄 브리지가 필요한데요. AWS는 이를 위해 MCP Proxy for AWS라는 오픈소스 프록시를 제공합니다. 로컬에서 실행되면서 MCP 요청을 SigV4 서명이 들어간 AWS API 호출로 변환해줘요.

권한 측면에서 중요한 점은 에이전트가 사용자의 권한을 상속받는다는 겁니다. 평소 IAM 정책에 신경을 써왔다면 그대로 적용된다고 보면 돼요. AI에게 너무 많은 권한을 주고 싶지 않다면 별도의 IAM 사용자나 역할을 만들어서 읽기 전용 권한만 부여하는 것을 추천합니다.

세분화된 제어를 위한 IAM 컨텍스트 키도 지원해요. 예를 들어 특정 시간대에만 쓰기 작업을 허용하거나, 특정 리소스 태그가 있는 자원에만 접근을 허용하는 식의 정책을 만들 수 있습니다.

클로드 코드에서 설정하기

클로드 코드에서 AWS MCP 서버를 설정해볼게요. 먼저 MCP Proxy for AWS를 실행할 uv가 필요합니다.

curl -LsSf https://astral.sh/uv/install.sh | sh

이미 설치되어 있다면 이 단계는 건너뛰어도 됩니다. 그다음 claude mcp add-json 명령어로 서버를 등록합니다.

claude mcp add-json aws-mcp --scope user '{
  "command": "uvx",
  "args": [
    "mcp-proxy-for-aws@latest",
    "https://aws-mcp.us-east-1.api.aws/mcp",
    "--metadata",
    "AWS_REGION=us-west-2"
  ]
}'

여기서 엔드포인트 URL의 us-east-1은 MCP 서버 자체가 호스팅되는 리전을 의미합니다. --metadata로 넘기는 AWS_REGION=us-west-2는 실제로 AWS API를 호출할 리전이에요. 두 값은 독립적이라 서울에서 작업하더라도 도쿄 리전의 리소스를 다룰 수 있습니다.

설정이 잘 되었는지 확인할게요.

claude mcp list

aws-mcp 항목이 보이면 성공입니다. 클로드 코드를 실행한 뒤 /mcp 명령어로도 연결 상태를 확인할 수 있어요.

자격 증명은 ~/.aws/credentials에 설정된 기본 프로필이 자동으로 사용됩니다. 특정 프로필을 쓰고 싶다면 AWS_PROFILE 환경 변수를 셸에 설정해두면 돼요.

Cursor와 다른 클라이언트

Cursor에서도 같은 방식으로 설정할 수 있습니다. Cursor Settings > MCP에서 추가하거나 .cursor/mcp.json 파일에 직접 등록하면 돼요.

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-west-2"
      ]
    }
  }
}

이외에 Kiro CLI, Kiro IDE, OpenAI Codex 같은 MCP 호환 도구에서도 동일한 명령어와 인자로 설정할 수 있습니다. MCP 표준을 따르는 도구라면 사실상 모두 동작한다고 보면 돼요.

AWS MCP 서버는 현재 미국 동부(버지니아)와 유럽(프랑크푸르트) 두 리전에 배포되어 있는데요. 엔드포인트 URL을 두 리전 중 가까운 쪽으로 바꾸면 응답 지연을 줄일 수 있습니다. 단, API 호출 자체는 모든 AWS 리전을 대상으로 가능하므로 작업 리전과는 무관해요.

실전 활용 예시

설정이 끝났으니 실제로 어떤 작업이 가능한지 살펴볼게요.

가장 기본은 리소스 조회입니다. “us-west-2 리전의 EC2 인스턴스를 전부 보여줘”라고 하면 call_aws로 DescribeInstances를 호출해서 결과를 정리해줍니다. “프로덕션 태그가 붙은 인스턴스 중에 t2.micro인 것만 골라줘”처럼 조건을 덧붙이면 알아서 필터링까지 해줘요.

리소스 생성도 자연어로 가능합니다. “Node.js 런타임으로 Lambda 함수를 하나 만들어줘. 이름은 hello-world이고, S3 버킷 my-bucket의 업로드 이벤트로 트리거되게”라고 하면 함수 생성과 트리거 설정을 한 번에 처리합니다. CloudFormation이나 CDK 없이도 인프라 작업이 되는 거죠. 본격적인 IaC 작업이 필요하다면 AWS CDK와 함께 사용하면 더 좋고요.

운영 작업도 강력해요. “어제 새벽에 RDS 인스턴스 my-db에서 발생한 에러 로그를 CloudWatch에서 찾아줘”라고 하면 CloudWatch Logs API를 호출해서 로그를 가져와 분석해줍니다. 장애 대응할 때 콘솔과 CLI를 오가며 정보를 모으는 시간을 크게 줄일 수 있어요.

비용 분석에도 유용합니다. “이번 달 EC2 비용이 가장 많이 나오는 인스턴스 5개를 찾아줘”라고 하면 Cost Explorer API를 호출해서 결과를 보여주는데요. 이런 작업은 단일 API로 끝나지 않고 여러 단계가 필요한데, 이때 run_script 도구가 빛을 발합니다. AI가 Python 스크립트를 만들어서 샌드박스에서 실행하고 결과만 반환하는 식이에요.

최신 서비스에 대한 질문도 잘 처리해줍니다. 예를 들어 클로드 4.6 모델의 학습 데이터는 2025년 5월까지인데요. 그래서 2025년 12월에 출시된 Amazon S3 Vectors 같은 신규 기능은 잘 모릅니다. 하지만 AWS MCP 서버가 연결되어 있으면 에이전트가 search_documentation으로 최신 문서를 먼저 찾아본 뒤 정확한 답을 내놓아요.

엔터프라이즈 환경에서의 보안

회사 환경에서 AI 에이전트에게 AWS 권한을 주는 건 부담스러운 일이죠. 의도치 않은 작업으로 운영 환경이 망가질 수도 있고, 비용 폭탄을 맞을 수도 있으니까요. AWS MCP 서버는 이런 우려를 줄이기 위한 장치를 여러 개 제공합니다.

우선 모든 작업이 CloudTrail에 기록됩니다. 누가 언제 어떤 API를 호출했는지 감사할 수 있어요. 사용자가 직접 콘솔에서 작업한 것과 동일하게 추적되므로 기존 감사 체계를 그대로 활용할 수 있습니다.

또한 AWS-MCP 네임스페이스로 CloudWatch 메트릭이 자동으로 수집됩니다. 에이전트가 얼마나 많은 호출을 했는지, 어떤 도구를 주로 쓰는지 모니터링할 수 있어요. 비정상적인 사용 패턴을 알람으로 잡아내는 것도 가능합니다.

권한 분리도 중요한데요. 사람이 직접 쓰는 IAM 사용자와 에이전트용 IAM 사용자를 분리하는 것을 추천합니다. 에이전트용에는 최소 권한만 부여하고, 운영 환경에 영향을 줄 수 있는 작업(EC2 종료, RDS 삭제 등)은 명시적으로 거부 정책으로 막아두면 안심할 수 있어요.

읽기 전용으로만 쓰고 싶다면 IAM 정책에서 Action을 *:Describe*, *:Get*, *:List* 같은 패턴으로 제한하면 됩니다. 에이전트가 정보 조회만 가능하고 어떤 변경도 못 하게 막을 수 있죠.

가격과 가용성

AWS MCP 서버 자체는 무료입니다. 추가 요금이 부과되지 않아요. 다만 에이전트가 실제로 AWS 리소스를 생성하거나 데이터를 전송하면 해당 서비스의 일반 요금이 발생합니다. 예를 들어 EC2 인스턴스를 띄우면 EC2 요금이, S3에 데이터를 올리면 스토리지 요금이 부과되는 식이에요.

현재 미국 동부(버지니아)와 유럽(프랑크푸르트) 리전에서 사용할 수 있으며, API 호출 대상은 모든 AWS 리전이 가능합니다. 한국 사용자도 두 엔드포인트 중 원하는 쪽을 골라서 쓸 수 있어요.

마치며

AWS MCP 서버는 AI 에이전트에게 AWS 전체를 다룰 수 있는 표준화된 인터페이스를 제공합니다. 도구 4개로 모든 AWS API를 커버하면서도 IAM 기반의 권한 모델과 CloudTrail 감사 기능을 그대로 활용할 수 있다는 점이 특히 인상적이에요.

처음 써본다면 읽기 전용 IAM 사용자를 하나 만들어서 시작해보는 것을 추천합니다. “내 AWS 계정에서 현재 실행 중인 모든 EC2 인스턴스를 보여줘” 같은 간단한 조회부터 시도해보고, 익숙해지면 점차 작업 범위를 넓혀가면 돼요.

다른 MCP 서버도 함께 활용하고 싶다면 GitHub MCP 서버를 같이 연결해두면 좋습니다. 코드 변경과 인프라 작업을 하나의 워크플로우로 묶을 수 있거든요. MCP 레지스트리에서 다른 MCP 서버들도 둘러볼 수 있어요.

더 자세한 설정 옵션이나 IAM 정책 예시는 Agent Toolkit for AWS 공식 문서를 참고하세요.