حالت Express در AWS زمان استقرار عامل‌های هوش مصنوعی را نصف کرد

تصور کنید یک پشته API بدون سرور، امروز دو برابر سریع‌تر از دیروز مستقر شود. در یک آزمایش واقعی که در ۳ ژوئیه ۲۰۲۶ انجام شد، حالت Express در CloudFormation زمان استقرار را ۵۰٪ کاهش داد. طبق اعلام AWS در ۳۰ ژوئن ۲۰۲۶، این ویژگی جدید کنترل را بلافاصله پس از اعمال پیکربندی به کاربر بازمی‌گرداند و دیگر منتظر تثبیت کامل تک‌تک منابع نمی‌ماند.

این تغییر برای توسعه‌دهندگانی که عامل (Agent) — شبیه دستیاری است که می‌تواند ابزارهای نرم‌افزاری را برای رسیدن به هدف اجرا کند — می‌سازند، حیاتی است. این بهبود در استقرار زیرساخت، در کنار پیشرفت‌های اخیر در هسته مدل‌ها، مانند زمانی که مدل‌های عامل AWS Bedrock به تنها ۲ فراخوانی API برای استقرار نیاز پیدا کردند، سرعت توسعه را به شدت افزایش می‌دهد. برای توسعه‌دهندگان عامل‌های هوش مصنوعی، این تغییر مرحله «چرخان انتظار» (Spinner) در حلقه استقرار را حذف می‌کند. یک عامل معمولاً با استقرار یک قالب، خواندن خطا و سپس استقرار مجدد پیش می‌رود؛ بنابراین هر ثانیه انتظار برای تثبیت منابع، زمان تلف‌شده‌ای برای مدل و اپراتور است.

به نقل از مستندات رسمی AWS، شکاف عملکردی در حالت Express بسیار چشمگیر است؛ برای مثال، زمان استقرار یک صف SQS با صف نامه‌های مرده (DLQ) از ۶۴ ثانیه در حالت استاندارد به تنها ۱۰ ثانیه کاهش یافته است.

جزئیات setup آزمایش

برای سنجش این قابلیت، یک توسعه‌دهنده یک محیط تست (Harness) سفارشی با حدود ۱۵۰ خط کد پایتون ساخت که بدون استفاده از هیچ چارچوب خارجی برای عامل‌ها بود. اجزای اصلی این ساختار عبارت بودند از:

• مدل: مدل Claude Sonnet 4.6 که روی سرویس Amazon Bedrock (با شناسه us.anthropic.claude-sonnet-4-6) اجرا می‌شد.
• رابط: استفاده از Converse API که تنها از یک ابزار به نام deploy_stack(template_yaml) بهره می‌برد.
• منطقه: تمام منابع در منطقه ap-northeast-1 مستقر شدند.
• پیکربندی: این ابزار از DeploymentConfig با تنظیمات "Mode": "EXPRESS" و "DisableRollback": true استفاده می‌کرد.
• پایش: سیستم پایش، هر ثانیه وضعیت DescribeStacks را بررسی می‌کرد و دلایل شکست در DescribeStackEvents را استخراج می‌کرد تا در صورت بروز خطا، آن‌ها را به مدل بازگرداند.

شرح فنی ماموریت

عامل هوش مصنوعی با یک تسک ساده «سلام دنیا» روبرو نبود، بلکه مأموریت داشت یک API بدون سرور کوچک و با ساختاری سخت‌گیرانه با محدودیت‌های زیر بسازد:

• منطق اصلی: یک تابع Lambda با پایتون ۳.۱۳ که پشت یک API Gateway HTTP API قرار دارد و دارای نقطه اتصال GET /health است که پاسخ {"status": "ok"} را برمی‌گرداند.
• امنیت: تعریف یک نقش IAM اختصاصی که به طور صریح استفاده از سیاست مدیریت‌شده AWSLambdaBasicExecutionRole را ممنوع می‌کرد و نیازمند مجوزهای inline با اصل «حداقل دسترسی» (Least-privilege) بود که فقط برای گروه لاگ (Log Group) تابع مربوطه تعریف شده باشد.
• ثبت وقایع: ایجاد صریح یک AWS::Logs::LogGroup با دوره نگهداری ۷ روزه که باید پیش از تابع ساخته می‌شد.
• یکپارچه‌سازی: تنظیم صحیح یکپارچگی AWS_PROXY و یک استیج $default با قابلیت استقرار خودکار (Auto-deploy) و تعریف Lambda::Permission محدوده شده به منبع برای API Gateway.
• خروجی: پشته نهایی باید URL فراخوانی (Invoke URL) را به عنوان خروجی ارائه می‌داد.

این محدودیت IAM یک نقطه درد معروف برای توسعه‌دهندگان است. در حالی که ساده‌سازی دسترسی‌ها سرعت بخشیده، اما بحث امنیت کلیدهای API در محیط‌های ابری همچنان یک چالش جدی برای حفظ داده‌های حساس در عامل‌های AI است. مجوزهای CloudWatch Logs برای CreateLogStream به ARN گروه لاگ نیاز دارند، اما برای PutLogEvents در سطح استریم، به پسوند :log-stream:* نیاز است؛ نکته‌ای ظریف که اغلب توسط توسعه‌دهندگان نادیده گرفته می‌شود.

نتایج و مشاهدات

بر اساس گزارش منتشر شده در dev.to، عامل در اولین تلاش موفق شد و تمام جزئیات امنیتی و ARNهای مربوط به جریان‌های لاگ را بدون آنکه ترفند آن به او گفته شود، به درستی پیاده کرد. مدل به طور کامل از !GetAtt LambdaLogGroup.Arn و !Sub '${LambdaLogGroup.Arn}:log-stream:*' استفاده کرد. پشته در ۲۵.۶ ثانیه به وضعیت 'CREATE_COMPLETE' رسید و API بلافاصله پاسخگو شد و درخواست‌های curl را پذیرفت.

برای جداسازی اثر سرعت، نویسنده یک بنچمارک را اجرا کرد که در آن یک قالب یکسان سه بار در هر دو حالت استاندارد و Express در یک اکانت و منطقه اجرا شد:

• حالت استاندارد: میانگین زمان استقرار ۵۱.۹۱ ثانیه (اجراهای مجزا: ۵۲.۰۳ ثانیه، ۵۱.۷۸ ثانیه، ۵۱.۹۳ ثانیه).
• حالت Express: میانگین زمان استقرار ۲۵.۴۴ ثانیه (اجراهای مجزا: ۲۵.۵۸ ثانیه، ۲۵.۲۴ ثانیه، ۲۵.۵۱ ثانیه).

این نتایج نشان‌دهنده یک افزایش سرعت ۲.۰۴ برابری ثابت است. اگرچه AWS ادعای بهبود ۴ برابری برای صف‌های SQS دارد، اما این بهره ۲ برابری برای APIهای بدون سرور، یک خط پایه واقعی و قابل تکرار با انحرافی کمتر از نیم ثانیه است.

چالش‌های پیاده‌سازی

یک مانع فنی حیاتی در طول آزمایش شناسایی شد که مربوط به پارامتر OnFailure است. در اولین تلاش توسعه‌دهنده، سیستم ۸ بار متوالی با خطای ValidationError: OnFailure cannot be specified with EXPRESS deployment mode مواجه شد.

به دلیل عادت، اسکریپت مقدار OnFailure="DO_NOTHING" را در کنار DeploymentConfig ارسال می‌کرد. با این حال، در حالت Express، رفتار بازگشت (Rollback) باید منحصراً از طریق DeploymentConfig.DisableRollback کنترل شود. ترکیب پارامتر قدیمی OnFailure با حالت Express باعث می‌شود استقرار مستقیماً رد شود.

جمع‌بندی نهایی

این تغییر نشان می‌دهد که سیگنال «پیکربندی اعمال شد» برای اکثر منابع بدون سرور، معیار قابل اعتمادی برای آماده‌باش است. برای عامل‌های هوش مصنوعی، این موضوع فرآیند استقرار را از یک زنجیره خطی و کند به یک حلقه بازخورد با فرکانس بالا تبدیل می‌کند. دادن یک مشخصات امنیتی سخت‌گیرانه به مدل — مانند ممنوعیت نقش‌های مدیریت‌شده — آزمونی دقیق‌تر برای مهارت در زیرساخت‌-به‌عنوان-کد (IaC) است و Claude Sonnet 4.6 این پیچیدگی‌ها را به راحتی مدیریت کرد.

از دیدگاه عملی، مؤثرترین حلقه‌های عامل آن‌هایی خواهند بود که دلایل واقعی شکست در StackEvents را به عنوان نتیجه ابزار به مدل بازمی‌گردانند. این کار یک حلقه تلاش مجدد کور را به یک حلقه اصلاح دقیق تبدیل می‌کند و به هوش مصنوعی اجازه می‌دهد خطاهای YAML را در لحظه تشخیص داده و حل کند. همان‌طور که عامل‌های AI از نوشتن کد به سمت مدیریت محیط‌های عملیاتی حرکت می‌کنند، گلوگاه از استدلال مدل به تأخیرهای ارائه‌دهنده ابری تغییر می‌کند.

شما می‌توانید پیاده‌سازی کامل این پروژه — شامل کمکی‌های استقرار و پایش، حلقه استفاده از ابزار در Bedrock و اسکریپت‌های بنچمارک — را در گیت‌هاب در آدرس yama3133/cfn-express-agent-demo با مجموعاً حدود ۲۵۰ خط کد بیابید.

گام بعدی شما

• اگر از CloudFormation استفاده می‌کنید، پارامتر OnFailure را حذف کرده و DeploymentConfig را روی EXPRESS تنظیم کنید.
• برای عامل‌های خود، خروجی‌های StackEvents را مستقیماً به عنوان نتیجه ابزار به مدل بازگردانید تا چرخه اصلاح خطا سریع‌تر شود.
• مستندات مربوط به DisableRollback را برای جلوگیری از خطاهای ValidationError بررسی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.