Jak hostovat AI agenty na AWS: Lambda, Fargate, nebo AgentCore?
AI agent na notebooku funguje. Odpovídá, používá nástroje a zvládá první reálné úkoly. Jakmile ho ale zpřístupníš uživatelům, objeví se nové otázky:
- Co když jeden běh trvá několik minut?
- Kde bezpečně uložit přístupové klíče?
- Jak zachovat historii konverzace po restartu?
- Jak zabránit nekonečné smyčce a nečekanému účtu?
V tomto článku porovnáme tři rozumné cesty, jak hostovat AI agenta na AWS: AWS Lambda, Amazon ECS s AWS Fargate a Amazon Bedrock AgentCore Runtime. Potom si projdeme praktickou architekturu na Fargate — od Docker image až po bezpečnost, monitoring a dlouhé úlohy.
Rychlé doporučení: Lambda se hodí pro krátké a nepravidelné úlohy. Fargate nabízí největší kontrolu nad vlastním runtime. AgentCore je zajímavý tam, kde chceš spravovaný provoz navržený přímo pro agenty.
Proč se AI agent nenasazuje jako obyčejné API
Zvenku může agent vypadat jako běžná webová služba: přijme požadavek a vrátí odpověď. Uvnitř ale často provede několik kroků — zavolá model, použije nástroj, vyhodnotí výsledek a pokračuje dál.
To mění požadavky na infrastrukturu:
- Běh může trvat sekundy i minuty. Je nutné hlídat timeouty webového serveru, API brány i load balanceru.
- Odpověď se často streamuje. Uživatel nemá čekat na prázdné obrazovce, zatímco agent dokončuje celý běh.
- Stav nesmí zůstat jen v paměti procesu. Konverzaci, průběh úlohy a výsledek je potřeba uložit mimo kontejner nebo funkci.
- Nástroje mají reálná oprávnění. Agent může číst databázi, posílat e-maily nebo měnit data. Každý nástroj proto potřebuje omezené oprávnění a jasné hranice.
- Cena není jen za server. Platíš také za tokeny, externí API, síťový provoz, logy a služby, které běží nepřetržitě.
Nejdřív si proto ujasni jednu věc: bude agent odpovídat synchronně, nebo bude pracovat asynchronně na pozadí?
Synchronní běh dává smysl pro chat a kratší úlohy, při kterých klient drží spojení a průběžně přijímá odpověď. U delší práce je spolehlivější vrátit uživateli ID úlohy, požadavek vložit do fronty a výsledek doručit později.
Tři cesty, jak hostovat AI agenta na AWS
1. AWS Lambda: pro krátké a nárazové úlohy
Lambda spustí kód jen tehdy, když přijde požadavek. Nemusíš spravovat server a při malém nebo nepravidelném provozu neplatíš za nečinnou výpočetní kapacitu.
Hodí se například pro:
- klasifikaci nebo extrakci dat;
- jednoduchého agenta s několika předvídatelnými kroky;
- webhooky a asynchronní zpracování zpráv ze SQS;
- prototyp s nepravidelným provozem.
Počítej ale s tvrdým limitem: jedna Lambda funkce může běžet nejvýše 15 minut. API Gateway REST API dnes umí streamovat odpověď z Lambdy, ale streaming je nutné výslovně nakonfigurovat a také má časové a síťové limity. Pro agenta, který může pracovat desítky minut, je vhodnější fronta nebo jiný runtime.
Cold start není důvod Lambdu automaticky zavrhnout. Je ale dobré ho změřit se skutečným balíčkem závislostí a v regionu, kde bude aplikace běžet.
2. Amazon ECS + AWS Fargate: pro vlastní runtime a plnou kontrolu
Na ECS Fargate spustíš agenta jako Docker kontejner, aniž bys spravoval virtuální servery. Sám si zvolíš framework, model, webový server i způsob streamingu.
Fargate se hodí, když potřebuješ:
- FastAPI, WebSocket nebo Server-Sent Events;
- vlastní agentní smyčku či více procesů;
- dlouhodobě běžící API nebo worker;
- přesnou kontrolu nad CPU, pamětí, sítí a nasazením.
Za flexibilitu platíš větším množstvím infrastruktury. Vedle samotného kontejneru řešíš síť, load balancer, škálování, logy a nasazování nových verzí.
A co AWS App Runner? Kontejner nasadí jednodušeji než ECS, ale HTTP požadavek má celkový limit 120 sekund. Pro krátké API může být příjemnou volbou, pro dlouhé streamy a několikaminutové běhy agenta je tento limit zásadní.
3. Amazon Bedrock AgentCore Runtime: spravovaný runtime pro agenty
Amazon Bedrock AgentCore Runtime je serverless prostředí navržené přímo pro provoz agentů a jejich nástrojů. Není vázané na jediný framework ani na modely z Bedrocku — podporuje například LangGraph, CrewAI, Strands Agents i vlastní řešení a model může běžet také mimo Amazon Bedrock.
Mezi hlavní výhody patří:
- izolace uživatelských relací v samostatných microVM;
- synchronní i asynchronní běhy;
- podpora běhů až do osmi hodin;
- spravované škálování a menší množství vlastní infrastruktury.
AgentCore dává smysl, když chceš zachovat vlastní agentní kód, ale nechceš stavět celý provozní základ na ECS. Před rozhodnutím ověř dostupnost služby, podporované regiony, způsob autentizace a cenový model pro svůj scénář.
Pozor na starší návody: Amazon Bedrock Agents se nyní označuje jako Bedrock Agents Classic a není otevřený novým zákazníkům. Pro nové projekty AWS doporučuje pro podobné scénáře prozkoumat AgentCore.
Praktická architektura agenta na ECS Fargate
Teď si projdeme univerzální variantu: agent napsaný v Pythonu vystavuje API přes FastAPI, běží v ECS Fargate a volá model přes Amazon Bedrock nebo externí API.
Základní tok vypadá takto:
Uživatel → HTTPS / Application Load Balancer → ECS Fargate → LLM a nástroje
├── DynamoDB (stav)
├── Secrets Manager (tajné klíče)
└── CloudWatch (logy a metriky)Pro delší úlohy přidej asynchronní větev:
API → SQS → Fargate worker → DynamoDB (stav a výsledek)Klient po odeslání dostane job_id a stav kontroluje přes API, WebSocket nebo notifikaci. Výpadek jednoho HTTP spojení tak nezruší celou práci.
Krok 1: Připrav aplikaci na provoz v kontejneru
Vedle endpointu pro agenta přidej jednoduchý health check. Neměl by volat LLM ani vzdálenou databázi — load balancer potřebuje rychle ověřit, že proces přijímá požadavky.
from fastapi import FastAPI
app = FastAPI()
@app.get("/health")
def health() -> dict[str, str]:
return {"status": "ok"}Základní Dockerfile může vypadat takto:
FROM python:3.12-slim
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt \
&& useradd --create-home appuser
COPY --chown=appuser:appuser . .
USER appuser
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]V produkci používej zamčené verze závislostí a image označuj neměnným tagem, například hashem commitu. Tag latest komplikuje dohledání toho, která verze skutečně běží.
Krok 2: Nahraj image do Amazon ECR
Amazon ECR je privátní registr Docker images v AWS:
AWS_REGION=eu-central-1
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REPOSITORY_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/muj-agent
aws ecr create-repository --repository-name muj-agent
aws ecr get-login-password --region $AWS_REGION \
| docker login --username AWS --password-stdin \
$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
docker build -t muj-agent .
docker tag muj-agent:latest $REPOSITORY_URI:1.0.0
docker push $REPOSITORY_URI:1.0.0Příkazy předpokládají nakonfigurované AWS CLI a oprávnění k ECR. V týmu je lepší build a push automatizovat v CI/CD než je provádět z notebooku.
Krok 3: Vytvoř task definition a ECS service
Task definition popisuje image, CPU, paměť, porty, logování a oprávnění. ECS service udržuje požadovaný počet instancí, nahrazuje spadlé tasky a provádí deployment nové verze.
Nezaměň dvě odlišné IAM role:
- Task execution role používá ECS například pro stažení image z ECR a odesílání logů.
- Task role dostane samotná aplikace, když přistupuje k DynamoDB, Bedrocku nebo jiné službě AWS.
Začni s malou kapacitou, ale CPU a paměť ověř zátěžovým testem. Doporučení typu „1 GB stačí každému agentovi“ neexistuje — záleží na knihovnách, souběhu požadavků i práci s dokumenty.
Krok 4: Ulož tajné hodnoty do Secrets Manageru
Klíče k externím LLM API nepatří do kódu, repozitáře ani Docker image. Ulož je do AWS Secrets Manageru a v task definition použij odkaz:
{
"secrets": [
{
"name": "OPENAI_API_KEY",
"valueFrom": "arn:aws:secretsmanager:eu-central-1:123456789012:secret:muj-agent/openai"
}
]
}Pokud agent volá Amazon Bedrock, obvykle žádný dlouhodobý API klíč nepotřebuje. Přístup mu dej přes task role s minimálním nutným IAM oprávněním.
Pozor také na rotaci: tajná hodnota vložená do environment proměnné se v běžícím tasku sama neobnoví. Po změně secretu je potřeba task nahradit, případně načítat hodnotu za běhu přes SDK.
Krok 5: Nastav síť, HTTPS a timeouty
Ve standardní produkční architektuře je veřejný pouze Application Load Balancer a Fargate tasky běží v privátních subnetech. HTTPS certifikát může spravovat AWS Certificate Manager.
Výchozí idle timeout Application Load Balanceru je 60 sekund. Pokud má agent delší pauzy mezi částmi streamu, uprav timeout load balanceru i aplikačního serveru a posílej data průběžně. Samotné zvýšení timeoutu ale není náhradou za asynchronní zpracování dlouhých úloh.
Privátní task, který volá veřejné LLM API, potřebuje odchozí přístup přes NAT. NAT Gateway má hodinové i datové poplatky a u malého projektu může stát víc než samotný kontejner. Pro služby AWS používej tam, kde to dává smysl, VPC endpoints a před nasazením si síť zahrň do cenového odhadu.
Krok 6: Ulož stav mimo kontejner
Fargate task je nahraditelný. Po restartu se nesmí ztratit historie konverzace ani informace o rozpracované úloze.
Pro běžný začátek se hodí:
- DynamoDB pro relace, zprávy, stav úloh a klíče proti duplicitnímu zpracování;
- ElastiCache for Redis pro velmi rychlou dočasnou cache nebo koordinaci;
- S3 pro větší dokumenty a výstupy.
V DynamoDB neukládej celou stále rostoucí konverzaci do jediné položky. Jednotlivé zprávy můžeš ukládat pod partition key session_id a řadit pomocí sort key. Pro dočasná data nastav TTL.
Krok 7: Přidej škálování a bezpečný deployment
ECS service může škálovat podle CPU, paměti nebo vlastních metrik. U workerů nad SQS je užitečnější metrika založená na počtu čekajících zpráv na jeden task.
Při nasazování ověř:
- že health check nové verze projde před odpojením staré;
- že rozpracovaný požadavek dostane čas na dokončení;
- že se při chybě nasazení automaticky vrátí předchozí verze;
- že zprávy, které opakovaně selžou, skončí v oddělené frontě pro ruční kontrolu (dead-letter queue).
Produkční checklist: co hlídat od prvního dne
Bezpečnost a oprávnění
- Autentizuj uživatele a omez počet požadavků.
- Každému nástroji dej jen nezbytná oprávnění.
- Destruktivní operace, například smazání dat nebo odeslání platby, potvrď člověkem.
- Počítej s prompt injection: text od uživatele ani obsah dokumentu není důvěryhodný pokyn.
- Citlivý kód nebo shell spouštěj pouze v izolovaném sandboxu s omezenou sítí a časem.
Spolehlivost
- Nastav maximální počet kroků, dobu běhu a rozpočet tokenů.
- Opakuj jen chyby, u kterých má další pokus smysl. Interval mezi pokusy postupně prodlužuj a přidej malou náhodnou odchylku (exponential backoff with jitter).
- Zápisové nástroje navrhni idempotentně, aby retry nevytvořil dvě objednávky nebo dva e-maily.
- U dlouhých úloh používej SQS, stav úlohy a dead-letter queue.
- Umožni běh zrušit a bezpečně ukončit.
Observabilita
Pro každý běh ukládej trace ID, použitou verzi promptu a modelu, dobu jednotlivých kroků, tokeny, volání nástrojů a chyby. Sleduj také úspěšnost, latenci, délku fronty a cenu na jednu dokončenou úlohu.
Do logů neposílej tajné klíče, osobní údaje ani interní „řetězec myšlenek“ modelu. Pro ladění stačí strukturovaný záznam vstupů a výstupů nástrojů, rozhodnutí na úrovni kroků a technických metrik. CloudWatch můžeš doplnit specializovaným tracingem, například Langfuse nebo LangSmith.
Náklady
Nelze obecně říct, že tokeny budou vždy nejdražší položkou. U Fargate platíš za rezervované CPU a paměť tasku; vlastní cenu mají také ALB, veřejné IPv4 adresy, NAT Gateway, přenos dat, CloudWatch a Secrets Manager. U vytíženého agenta mohou dominovat modely, u malého interního nástroje naopak fixní síťová infrastruktura.
Před spuštěním:
- udělej odhad v AWS Pricing Calculatoru;
- nastav AWS Budgets a upozornění;
- měř tokeny a cenu pro každý typ úlohy;
- omez počet kroků a velikost kontextu;
- pravidelně kontroluj náklady podle služby a tagu.
Jakou variantu tedy zvolit?
Zvol Lambda, pokud běh bezpečně skončí do 15 minut, provoz je nepravidelný a nepotřebuješ plnou kontrolu nad dlouhým spojením.
Zvol ECS Fargate, pokud chceš vlastní kontejner, dlouhé streamy, API i workery a nevadí ti spravovat síť, deployment a škálování.
Zvol Bedrock AgentCore Runtime, pokud chceš runtime určený přímo pro agenty, potřebuješ izolované uživatelské relace nebo dlouhé běhy a preferuješ spravovanou platformu před vlastní kontejnerovou architekturou.
U delšího procesu nezávisle na platformě odděl přijetí požadavku od jeho zpracování pomocí fronty. Je to spolehlivější než držet jedno HTTP spojení otevřené desítky minut.
Závěr: nezačínej službou, ale požadavky
Správná architektura nevychází z toho, která služba je právě populární. Začni délkou běhu, požadavkem na streaming, citlivostí nástrojů, očekávaným provozem a tím, kolik infrastruktury chceš spravovat.
Pro krátký prototyp může být nejlepší Lambda. Pro vlastní produkční API a workery dává smysl ECS Fargate. Pokud chceš provozní prostředí navržené přímo pro agenty, prověř AgentCore Runtime.
Ať zvolíš cokoli, od prvního dne ukládej stav mimo proces, omez agentní smyčku, používej minimální oprávnění a měř cenu každého běhu. Právě tyto základy rozhodují, jestli se z povedeného prototypu stane spolehlivá služba.
Chceš AI agenty nejen stavět, ale také dostat do produkce?
V kurzu Programátor AI Agentů si projdeš
návrh agentní smyčky, práci s nástroji, pamětí i bezpečností — a naučíš se z prototypu vytvořit řešení,
které dokážeš spolehlivě provozovat. Prakticky, na reálných úlohách a s podporou lektora.
Zdroje a další čtení
