Представляем Agent Toolkit для Amazon Web Services.
Это как иметь в своем распоряжении личного эксперта по архитектуре решений AWS и инженера по обработке данных.
Делиться

Что такое Agent Toolkit для WS?
Agent Toolkit for AWS — это проект с открытым исходным кодом, разработанный AWS, который помогает агентам ИИ-программистов более надежно работать с AWS. Благодаря недавнему добавлению сервера MCP в состав Toolkit, агенты-программисты, использующие Toolkit, теперь могут получить доступ к контексту, рабочим процессам, механизмам защиты и инструментам, специфичным для AWS, необходимым для создания, развертывания, отладки и эксплуатации облачных систем, не полагаясь исключительно на общие знания о моделях, которые часто устарели.
Вместо того чтобы просить программиста импровизировать по памяти, Toolkit предоставляет ему тщательно подобранные, специфичные для задачи инструкции. Они упакованы в виде навыков, плагинов, правил и конфигурации сервера MCP.
Навыки представляют собой специализированные пакеты инструкций. Они помогают агенту выполнять конкретные задачи AWS, такие как создание таблицы S3 Tables в Lakehouse, развертывание бессерверного приложения, отладка ошибок таймаута Lambda, подключение AWS Glue к базе данных или добавление памяти к агенту AgentCore.
Плагины объединяют связанные навыки в единую группу. Например, aws-core охватывает общую разработку на AWS, aws-agents — рабочие процессы Bedrock AgentCore, а aws-data-analytics — таблицы S3, Glue, Athena, поиск данных и векторное хранилище.
Файлы правил задают поведение агента по умолчанию в AWS. Они могут указывать агенту отдавать предпочтение инфраструктуре как коду, проверять документацию AWS в случае сомнений и использовать инструменты AWS MCP, если они доступны.
Интеграция с AWS MCP Server предоставляет агентам доступ к актуальной документации AWS, API AWS, выполнению скриптов в изолированной среде и аудиту с помощью встроенных средств управления AWS.
В результате должны получиться более совершенные системы с большей устойчивостью.
Почему это важно
Современные программисты могут писать правдоподобные команды AWS CLI, Terraform, CDK, обработчики Lambda, задания Glue или политики IAM. Часто они оказываются корректными и пригодными для использования сразу, но существует потенциальная проблема, с которой сталкиваются ВСЕ программисты: ограничение по уровню знаний.
При обучении агенты получают доступ к самой актуальной на тот момент информации, но к моменту выпуска моделей эта информация, как правило, устаревает на много месяцев. Например, последняя модель OpenAI на момент написания статьи — GPT 5.5. Она была выпущена в конце апреля 2026 года, но данные, необходимые для завершения обучения, датируются 1 декабря 2025 года. За это время внедряются новые сервисы, обновляются существующие системы, вызовы API, документация и т.д.
Разработка облачных решений полна деталей, которые могут показаться незначительными, но способны нарушить работу реальных систем. Например, при создании аналитической таблицы с использованием Amazon S3 Tables, стандартный агент может сгенерировать оператор DDL Athena с предложением LOCATION, поскольку такой шаблон распространен для внешних таблиц. Но с S3 Tables это неправильно: сервис управляет хранилищем таблиц. Правильный подход заключается в том, чтобы поддерживать чистоту SQL-запроса и передавать каталог S3 Tables через контекст выполнения запроса Athena.
Agent Toolkit для AWS помогает избежать подобных ошибок. Его функции направляют агента на следующие задачи:
- Перед созданием новых ресурсов проверьте, что уже существует.
- Используйте правильные API AWS.
- Избегайте шаблонов, которые не поддерживаются AWS.
- Проверьте предположения, сравнив их с текущей документацией AWS.
- Внедрить более жесткие политики управления идентификацией и доступом (IAM).
- После внесения изменений выполните проверки.
- При возникновении неполадок следуйте правильному алгоритму устранения неполадок.
Это наиболее важно в работе с AWS, где самая сложная часть — не написание кода. Сложность заключается в написании кода, который соответствует конкретному сервису AWS, модели разрешений и операционной среде.
Установка Agent Toolkit в ваш агент кодирования
Набор инструментов для агентов доступен для большинства современных агентов программирования, таких как Claude Code, Cursor, Kiro и VS Code. Примеры инструкций по установке для каждого агента находятся в репозитории AWS Toolkit, ссылку на который я приведу в конце статьи.
Сейчас мой любимый агент для программирования — Codex, поэтому в примере я буду использовать именно его. Если хотите следовать инструкциям, сначала установите его.
Для установки инструментария для Codex введите в окне терминала следующее:
$ codex plugin marketplace add aws/agent-toolkit-for-aws
Далее откройте приложение Codex и введите следующее.
/plugins
В зависимости от того, какие программы у вас были установлены ранее, вы должны увидеть что-то подобное.
AI Agents on AWS AWS Core AWS Data Analytics Browser Documents Presentations Spreadsheets
Это означает, что все необходимые плагины для AWS доступны вашему агенту. Помните, если у вас возникнут какие-либо проблемы, просто попросите вашего агента по программированию их исправить.
Использование инструментария с вашим агентом кодирования
Это самая простая часть, поскольку вам нужно буквально на английском языке объяснить Кодексу, чего вы хотите добиться.
В качестве примера я хотел:
- Создайте таблицу заказов Iceberg, используя Amazon S3 Tables.
- Загрузка данных о заказах из источника JDBC с помощью AWS Glue.
- Проверьте и выполните запрос к таблице iceberg с помощью Athena.
На первый взгляд, это может показаться довольно простым запросом, но если разобраться, всё гораздо сложнее, чем кажется. Во-первых, у меня нет существующего источника данных JDBC, поэтому мне пришлось сначала попросить Codex создать базу данных RDS и заполнить её фиктивными данными. Это само по себе порождает множество других требований, поскольку моя таблица в базе данных RDS является частной, мне также потребовались VPC, группы безопасности, разрешения IAM и т.д.
Вы поняли суть, и это хорошо известная проблема для любого, кто активно использует AWS и читает это. Даже довольно простая система AWS обычно требует сложной настройки, поскольку необходимо учитывать безопасность, авторизацию и права доступа.
Но, как вы увидите, AWS Toolkit берет на себя всю сложную работу.
Примечание: Agent Toolkit for AWS работает внутри вашей среды coding-agent. Для проверки, создания или изменения ресурсов AWS он использует учетные данные AWS, настроенные в этой среде. Для локальной разработки это обычно означает учетные данные AWS CLI, SSO или переменные среды , поэтому убедитесь, что один из этих методов настроен перед началом работы.
Для начала я запустил приложение Codex и ввел следующее:
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 with all required VPC, networking and security infrastructure. Populate the JDBC source with sample data,then everything else
После этого агент просто… продолжает свою работу. Вот некоторые из результатов, которые он мне выдал. Я не буду включать их все, так как список получился довольно длинным.
Worked for 32m 49s I'll use the AWS Data Analytics skills for the JDBC source, S3 Tables/Iceberg table creation, ingestion, and Athena validation. I'm first checking the workspace shape so the implementation matches what's already here. The existing workspace already has an aws-data-lake directory, so I'm inspecting it before deciding whether to extend it or create a separate deployment package. I also need to verify local AWS tooling and credentials before any real AWS resources can be created. ... ... ... Implemented files: 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 ... ...
Весь процесс был очень подробным и занял чуть более 30 минут от начала до конца.
Но сработало ли это?
Да, и вот доказательство.
Формирование облаков
Это сервис, который AWS использует для автоматизации создания всех ресурсов, необходимых для построения конкретной системы. Он является единым источником достоверной информации о том, что было фактически сделано. Мы можем использовать AWS CLI, чтобы проверить, что сделал CloudFormation.
aws cloudformation describe-stacks --stack-name orders-private-jdbc-source --region us-east-2 --query "Stacks[0].StackStatus" --output text # Output UPDATE_COMPLETE
Мы также можем получить полный список всех сервисов и ресурсов, которые CloudFormation создал для нас. Ниже приведена команда для этого, но обратите внимание, что я отформатировал ее вывод для большей читаемости.
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --output table # Modified Output +------------------------------------------------------+-------------------------------+-----------------+ | Service Deployed | ResourceType | ResourceStatus | +------------------------------------------------------+-------------------------------+-----------------+ | S3 bucket (artifact/scripts bucket) | AWS::S3::Bucket | CREATE_COMPLETE | | Security group rule (ingress) | AWS::EC2::SecurityGroupIngress | CREATE_COMPLETE | | Secrets Manager secret (DB credentials) | AWS::SecretsManager::Secret | CREATE_COMPLETE | | Security group (database SG) | AWS::EC2::SecurityGroup | CREATE_COMPLETE | | RDS DB subnet group (Aurora subnets) | AWS::RDS::DBSubnetGroup | CREATE_COMPLETE | | IAM role (Glue job execution role) | AWS::IAM::Role | UPDATE_COMPLETE | | Security group (Glue/Spark SG) | AWS::EC2::SecurityGroup | CREATE_COMPLETE | | Security group rule (egress) | AWS::EC2::SecurityGroupEgress | CREATE_COMPLETE | | Security group rule (ingress) | AWS::EC2::SecurityGroupIngress | CREATE_COMPLETE | | Security group rule (egress) | AWS::EC2::SecurityGroupEgress | CREATE_COMPLETE | | Internet Gateway (VPC IGW) | AWS::EC2::InternetGateway | CREATE_COMPLETE | | IAM role (Lake Formation / S3 Tables access role) | AWS::IAM::Role | CREATE_COMPLETE | | Elastic IP (for NAT Gateway) | AWS::EC2::EIP | CREATE_COMPLETE | | NAT Gateway | AWS::EC2::NatGateway | CREATE_COMPLETE | | Aurora DB cluster (PostgreSQL) | AWS::RDS::DBCluster | CREATE_COMPLETE | | Aurora DB instance (writer/instance) | AWS::RDS::DBInstance | CREATE_COMPLETE | | Glue job (JDBC -> S3 Tables ingestion) | AWS::Glue::Job | CREATE_COMPLETE | | Glue JDBC connection (to Aurora/Postgres) | AWS::Glue::Connection | CREATE_COMPLETE | | Route (private default route, typically to NAT) | AWS::EC2::Route | CREATE_COMPLETE | | Route table (private) | AWS::EC2::RouteTable | CREATE_COMPLETE | | Subnet (private subnet 1) | AWS::EC2::Subnet | CREATE_COMPLETE | | Route table association (private subnet 1) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE | | Subnet (private subnet 2) | AWS::EC2::Subnet | CREATE_COMPLETE | | Route table association (private subnet 2) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE | | Route (public default route, typically to IGW) | AWS::EC2::Route | CREATE_COMPLETE | | Route table (public) | AWS::EC2::RouteTable | CREATE_COMPLETE | | Subnet (public subnet 1) | AWS::EC2::Subnet | CREATE_COMPLETE | | Route table association (public subnet 1) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE | | VPC endpoint (S3 Gateway Endpoint) | AWS::EC2::VPCEndpoint | CREATE_COMPLETE | | Custom resource (seed orders data step) | Custom::SeedOrdersData | CREATE_COMPLETE | | Lambda function (seeds sample orders into DB) | AWS::Lambda::Function | CREATE_COMPLETE | | IAM role (Lambda execution role for seeding) | AWS::IAM::Role | CREATE_COMPLETE | | VPC | AWS::EC2::VPC | CREATE_COMPLETE | | VPC gateway attachment (attach IGW to VPC) | AWS::EC2::VPCGatewayAttachment | CREATE_COMPLETE | +------------------------------------------------------+-------------------------------+-----------------+
Я не буду перечислять ВСЕ созданные сервисы, но вот список наиболее важных из них с возможностью верификации.
VPC и сети
VPC — это как собственная мини-сеть в экосистеме AWS. Вокруг неё строятся такие сервисы, как CIDR-адреса, таблицы маршрутизации, подсети и группы безопасности, которые контролируют доступ ресурсов к VPC. Давайте посмотрим, что было создано.
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 ------------------------------------------- | DescribeVpcs | +------------------------+----------------+ | vpc-0165f765ce1af50c0 | 10.40.0.0/16 | +------------------------+----------------+ 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 ----------------------------------------------------------------------------------------------- | 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 | +---------------------------+-------------------------+----------------+-------------+--------+ 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 -------------------------------------------------------------------------------------------------------------------- | DescribeSecurityGroups | +----------------------+-----------------------------------------------------------------+-------------------------+ | sg-0c56c3639a47dcbdb| orders-private-jdbc-source-DatabaseSecurityGroup-ZS9C0AJXzASB | vpc-0165f765ce1af50c0 | | sg-0f1c55c20ebbf7acf| orders-private-jdbc-source-GlueSecurityGroup-XvKHWvTsRuap | vpc-0165f765ce1af50c0 | +----------------------+-----------------------------------------------------------------+-------------------------+
Роли IAM
Управление идентификацией и доступом (IAM) — важнейшая часть безопасности AWS. Оно контролирует, кто и что имеет доступ к каким сервисам в AWS.
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 | +---------------------------+-----------------+--------------------------------------------------------------------+-------------------+
Мы видим, что были созданы соответствующие роли, позволяющие нам создать таблицу S3, заполнить нашу базу данных RDS данными с помощью функции Lambda и заполнить нашу таблицу S3 из базы данных RDS с помощью задания Glue.
База данных RDS
Этот файл был создан в качестве исходного источника данных для нашей таблицы «айсберг» на S3. После создания таблица базы данных была заполнена фиктивными данными с помощью функции Lambda.

Лямбда-функция
Это использовалось для «заполнения» базы данных RDS фиктивными данными для последующего распространения в таблицу S3. Я не буду показывать код, но сама функция состояла примерно из 70 строк кода на Python.
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 | +--------------------+--------------------------------------------------------------+-------------------+
Таблица «Айсберг» на S3
Наша конечная цель заключалась в создании таблицы типа «айсберг» на S3, которую мы могли бы использовать для хранения, обработки и анализа данных. На скриншоте ниже показаны данные таблицы, которые в точности повторяют исходные данные в базе данных RDS.

Афина
Бесполезно иметь таблицу S3 с данными, если мы не можем запрашивать, обновлять или удалять эти данные. Именно это и позволяет делать сервис Athena от AWS. К сожалению, при первоначальной попытке использования Athena я столкнулся с проблемой. Когда я проверил консоль Athena, я не увидел новую таблицу S3 в списке баз данных и таблиц, поэтому не мог выполнить запрос к ней. Однако после непродолжительного общения с Codex в итоге было найдено следующее:
The key mismatch is now clear: database/table permissions are present, but catalog-level Lake Formation permissions are empty. AWS's Athena S3 Tables docs say the Athena principal also needs permissions on the S3 Tables catalog itself. I'm going to grant ALL on xxxxxxxxxxxx:s3tablescatalog/mytablebucket to the root user, then verify it.
После этого доступ стал нормальным.
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 || |+-------------------------+-------------------+-------+|
И я смог выполнить запрос к таблице в консоли Athena.

Клей и искра
Glue — это инструмент AWS для ETL-процессов, выполняющий две основные функции. Он может каталогизировать источники данных, делая их доступными для других сервисов AWS, таких как Athena. Glue также может использовать Spark или Pandas для чтения источников данных (например, баз данных RDS) и использовать любые найденные данные для создания и заполнения хранилищ данных в других сервисах, таких как таблицы и объекты S3.
aws glue get-connection --name orders-lake-orders-aurora-postgres --region us-east-2 --output json # Output { "Connection": { "Name": "orders-lake-orders-aurora-postgres", "Description": "Private Aurora PostgreSQL orders source for S3 Tables ingestion.", "ConnectionType": "JDBC", "ConnectionProperties": { "JDBC_ENFORCE_SSL": "false", "JDBC_CONNECTION_URL": "jdbc:postgresql://orders-private-jdbc-source-ordersdbcluster-wxxm5ygu3dig.cluster-chfygkamm03d.us-east-2.rds.amazonaws.com:5432/ordersdb", "SECRET_ID": "arn:aws:secretsmanager:us-east-2:XXXXXXXXXXXX:secret:DatabaseSecret-AYWd1SzbgdsG-3K7a0X" }, "PhysicalConnectionRequirements": { "SubnetId": "subnet-0c640ae5d30fe00e9", "SecurityGroupIdList": [ "sg-0f1c55c20ebbf7acf" ], "AvailabilityZone": "us-east-2a" }, "CreationTime": "2026-05-08T21:27:26.593000+01:00", "LastUpdatedTime": "2026-05-08T21:27:26.593000+01:00", "LastUpdatedBy": "user/administrator", "ConnectionSchemaVersion": 1 } }
Codex также сгенерировал код Spark в Glue для загрузки данных из базы данных RDS в Iceberg. Я не буду показывать весь код, так как он состоит почти из 100 строк, но вот его фрагмент.
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()
Другие моменты, которые следует учитывать при использовании инструментария AWS.
1/ Ограничение доступа агента к определенным сервисам AWS.
Сервер AWS MCP из набора инструментов использует ваши стандартные разрешения IAM для создания и доступа к сервисам AWS. Если вы хотите ограничить доступ к определенным сервисам AWS, у вас есть несколько вариантов.
а) К каждому запросу, выполняемому через сервер AWS MCP, автоматически добавляются два глобальных ключа контекста условий:
- aws:ViaAWSMCPService – Установите значение true для любого запроса, проходящего через управляемый AWS сервер MCP.
- aws:CalledViaAWSMCP – Содержит субъект службы конкретного управляемого AWS сервера MCP (например, aws-mcp.amazonaws.com).
Вы можете использовать эти ключи контекста в своих политиках IAM, чтобы разрешать или запрещать действия, инициируемые любым управляемым AWS сервером MCP. Например, предположим, вы хотите запретить серверу MCP удалять корзины или объекты S3. Вы можете использовать следующую политику:
{ "Effect": "Deny", "Action": ["s3:DeleteBucket", "s3:DeleteObject"], "Resource": "*", "Condition": { "StringEquals": { "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com" } } }
b) Другой вариант — создать отдельную роль для AWS Toolkit. Прикрепите к этой роли все необходимые политики ограничений, а затем создайте для неё именованный профиль AWS CLI с помощью команды aws configure .
Затем, перед запуском агента кодирования (например, Codex), установите переменную среды AWS_PROFILE на новое имя профиля, предназначенного только для Codex.
2/ Наблюдаемость
Мониторинг AWS Agent Toolkit в основном осуществляется через AWS MCP Server, поскольку это управляемый компонент, который принимает вызовы инструментов и выполняет действия AWS. Таким образом, для мониторинга используются те же две основные службы AWS, что и для большинства других служб AWS — CloudWatch и CloudTrail.
Сервер AWS MCP автоматически публикует метрики в CloudWatch. в пространстве имен AWS-MCP. Вы можете увидеть:
- Вызов: сколько раз был вызван инструмент.
- Успех: успешные вызовы инструментов
- UserError: ошибки на стороне клиента, часто связанные с отказом IAM в выполнении действий или некорректными параметрами.
- SystemError: server-side failures
- Ограничение скорости: запросы ограничены
CloudTrail записывает фактические вызовы API AWS, выполненные в вашей учетной записи. Проверить это можно здесь:
- Кто сделал звонок?
- Какой API был вызван?
- Когда это произошло
- Исходный IP-адрес
- предполагаемая роль или руководитель IAM
- Удалась ли эта акция или нет.
Заключение
Если вы инженер по обработке данных, архитектор данных или специалист по DevOps, использование AWS Toolkit станет для вас настоящим подспорьем. Благодаря предоставляемым плагинам и инструментам вы можете получить доступ ко всем сервисам AWS и более чем 15 000 вызовам API.
Короче говоря, при использовании с агентом кодирования инструментарий AWS может:
- Создавайте ресурсы AWS, пишите код и развертывайте приложения. Инструментарий помогает выбирать подходящие сервисы и следовать лучшим практикам AWS.
- Получите доступ к актуальной документации AWS, API и подробной информации об услугах.
- Для сложных задач, таких как политики IAM, конвейеры обработки данных или бессерверные приложения, агент следует проверенным и задокументированным рабочим процессам AWS, а не гадает на кофейной гуще.
- Ваш агент может помочь в расследовании неудачных развертываний, ошибок или скачков затрат, используя журналы AWS, метрики, состояние стека и рекомендации по устранению неполадок.
- Вы можете отслеживать активность агентов, контролировать доступ с помощью IAM и устанавливать ограничения, такие как доступ только для чтения или блокировка определенных действий AWS.
- Работайте со множеством различных агентов программирования, совместимых с MCP, включая Claude Code, Cursor, Codex, Kiro, Windsurf и др.
Однако, как показывает проблема, с которой я столкнулся при настройке Athena, этот инструментарий, хотя и значительно экономит время, не является безупречным, поэтому, как и в случае со всеми результатами работы агента, проверяйте свою работу, прежде чем запускать что-либо в производство.
Для получения более подробной информации о Agent Toolkit для AWS, ознакомьтесь с официальным репозиторием на GitHub.
https://github.com/aws/agent-toolkit-for-aws
Томас Рид. Все материалы от Томаса Рида.
Источник: towardsdatascience.com

Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.