Wzorce serverless dla agentów AI

Wzorce serverless dla agentów AI to przepisy, dzięki którym Claude Code, Codex i Cursor piszą dla AWS Lambda, Cloudflare Workers i Vercel kod, który przetrwa produkcję: handlery idempotentne przy ponownym dostarczeniu zdarzeń, bindingi Workera zgodne z wrangler.toml i poprawki cold startów przed provisioned concurrency. Każdy przepis kończy się testem albo bramką, a nie ręcznym czytaniem kodu.

Ta strona jest dla backend developerów, którzy już wdrażają funkcje, a teraz większość z nich pisze za nich agent. Sytuacja, którą rozwiązuje: Lambda przetwarzająca obrazy odpala się dwa razy na ten sam upload do S3, CloudWatch to ściana nieustrukturyzowanych console.log, a poranny skok p99 ktoś „naprawił” provisioned concurrency na każdej funkcji, co podwoiło rachunek. Serverless usuwa serwery, a nie problemy systemów rozproszonych. Ponowienia, idempotencja, cold starty i limity platform to nadal twój kod, a agent pisze tylko ścieżkę bez błędów, dopóki nie poprosisz o więcej.

Przepisy zakładają projekt w TypeScripcie z Vitestem; jeśli nie masz jeszcze tego zestawu narzędzi, przygotuj go najpierw według przepisów na Node.js albo wybierz inny stos w recepturach backendowych.

Co zyskujesz dzięki tym przepisom serverless

• Prompt, który tworzy idempotentny handler S3 → Lambda, oraz poprawny kształt handlera do porównania z wynikiem.
• Prompt testowy, który dowodzi, że handler przetrwa podwójne dostarczenie i awarię w trakcie pracy, więc weryfikujesz zachowanie zamiast czytać diff.
• Prompt na API gateway w Cloudflare Workers z pasującym wrangler.toml i dwie komendy, które przed wdrożeniem łapią rozjazd bindingów i puchnięcie bundla.
• Konfigurację serwera MCP Cloudflare i skilli Cloudflare dla każdego narzędzia, z kosztem kontekstu serwera MCP.
• Prompt do triage cold startów, który mówi, kiedy provisioned concurrency jest warte swojej ceny.
• Tryby awarii, które docierają na produkcję (podwójne dostarczenia z SQS, rekurencyjne wyzwalacze S3, limity CPU w Workers, zablokowane rekordy idempotencji), i sposób wyjścia z każdego.

Jak postawić usługę serverless z agentem?

Daj agentowi jedną konkretną usługę, region, runtime i źródła zdarzeń. Wszystkie trzy narzędzia sterują tymi samymi CLI frameworków (Serverless Framework, AWS SAM, Wrangler), więc wybieraj narzędzie według tego, gdzie toczy się praca, a nie według możliwości. Poniższy prompt używa Serverless Framework v4 (serverless 4.43.0 w npm, sprawdzone 2026-09-26) i Node.js 22.

Claude Code

Uruchom w pustym repozytorium w terminalu. Przy pierwszym uruchomieniu podaj --permission-mode manual, żeby samodzielnie zatwierdzać każdą edycję (od v2.1.283, na obu kanałach wydań w stanie na 2026-10-12, sesje interaktywne startują w trybie auto). Przejdź na --permission-mode acceptEdits, jak poniżej, gdy już ufasz planowi.

claude --permission-mode acceptEdits "Set up a Serverless Framework v4 service in TypeScript for AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image Lambda that only fires for the uploads/ prefix, and a DynamoDB table 'media' (PK id) plus a 'dedupe' table with TTL on 'ttl'. esbuild bundling, Node.js 22 runtime, dev and prod stages. Add a vitest setup and an npm 'test' script. Do not deploy."

Użyj claude -p z tym samym promptem, gdy szkielet ma być powtarzalny w skrypcie.

Codex

Trzymaj zapisy w obrębie workspace i pozwól Codexowi zapytać przed czymkolwiek szerszym:

codex --sandbox workspace-write -a on-request "Set up a Serverless Framework v4 service in TypeScript for AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image Lambda that only fires for the uploads/ prefix, a DynamoDB table 'media' (PK id) and a 'dedupe' table with TTL on 'ttl'. esbuild, Node.js 22, dev and prod stages, vitest with an npm 'test' script. Do not deploy."

Nowszym mechanizmem są profile uprawnień (-c default_permissions=":workspace", beta); --sandbox nadal działa w codex-cli 0.157.1. Nie łącz obu.

Aby uruchomić to samo zadanie w Codex Cloud i przejrzeć gałąź, wyślij je przez codex cloud exec --env ENV_ID "<ten sam prompt>" (--env jest wymagane w codex-cli 0.157.1; listę środowisk pokazuje codex cloud).

Cursor

Wklej ten sam prompt do agenta Cursora w otwartym repozytorium i przed akceptacją przejrzyj proponowany diff plik po pliku. Przy większym szkielecie najpierw poproś o plan w Plan Mode, a potem pozwól agentowi go wykonać.

Notatka

Do tej pracy zostań przy domyślnym modelu narzędzia i najpierw podnieś poziom effort, zanim zmienisz model. Aktualne modele domyślne i ceny są w przeglądzie modeli AI.

Jak zrobić idempotentny handler AWS Lambda?

S3, SQS i EventBridge dostarczają zdarzenia co najmniej raz. Handler ze skutkami ubocznymi (zapisy, e-maile, obciążenia kart) musi zająć stabilny klucz, zanim cokolwiek zrobi, pominąć pracę, gdy klucz jest już zajęty, i zwolnić go, gdy praca się nie uda, żeby ponowienie mogło się wykonać. Wygenerowane handlery często robią dobrze dwie pierwsze rzeczy i pomijają trzecią: zapisują rekord deduplikacji, padają w sharp, a każde ponowienie jest odtąd pomijane jako „duplikat”. Obiekt nigdy nie zostaje przetworzony.

Prompt do skopiowania: idempotentny procesor obrazów S3 → Lambda

Write an AWS Lambda handler in TypeScript (Node.js 22) for an S3 ObjectCreated trigger on the uploads/ prefix. It resizes the image to 256, 512 and 1024px WebP with sharp and writes them under derived/ in a SEPARATE destination bucket (never the source bucket, to avoid a recursive trigger).

Idempotency: URL-decode the object key (S3 encodes spaces as '+'). Before any side effect, claim pk = <bucket>/<key>#<eTag> with a DynamoDB PutItem using ConditionExpression 'attribute_not_exists(pk)' and a 'ttl' attribute 7 days out. If the condition fails, log status 'duplicate-skipped' and continue. If the resize or write fails, DELETE the claim, log status 'failed', and rethrow so the event reaches the on-failure destination.

Logging: exactly one JSON line per record with requestId, bucket, key, pk, status and durationMs.

Then give me the serverless.yml function block: memorySize 1024, timeout 30, the s3 event with the uploads/ prefix rule, an SQS on-failure destination, and IAM limited to GetObject on the source, PutObject on derived/ in the destination, and PutItem/DeleteItem on the dedupe table.

Porównaj wynik z tym wzorcem handlera. Liczy się kolejność operacji, nie styl:

// handler.ts: claim, work, release on failure
import type { S3Event } from 'aws-lambda';
import { DynamoDBClient, PutItemCommand, DeleteItemCommand } from '@aws-sdk/client-dynamodb';
import { resizeAndWrite } from './resize';

const ddb = new DynamoDBClient({});
const TABLE = process.env.DEDUPE_TABLE!;

export const handler = async (event: S3Event) => {
  for (const rec of event.Records) {
    const start = Date.now();
    const bucket = rec.s3.bucket.name;
    const key = decodeURIComponent(rec.s3.object.key.replace(/\+/g, ' '));
    const pk = `${bucket}/${key}#${rec.s3.object.eTag}`;
    const log = { requestId: rec.responseElements['x-amz-request-id'], bucket, key, pk };

    try {
      await ddb.send(new PutItemCommand({
        TableName: TABLE,
        Item: { pk: { S: pk }, ttl: { N: String(Math.floor(start / 1000) + 7 * 86400) } },
        ConditionExpression: 'attribute_not_exists(pk)',
      }));
    } catch (err) {
      if ((err as Error).name !== 'ConditionalCheckFailedException') throw err;
      console.log(JSON.stringify({ ...log, status: 'duplicate-skipped' }));
      continue;
    }

    try {
      await resizeAndWrite(bucket, key);
      console.log(JSON.stringify({ ...log, status: 'ok', durationMs: Date.now() - start }));
    } catch (err) {
      await ddb.send(new DeleteItemCommand({ TableName: TABLE, Key: { pk: { S: pk } } }));
      console.error(JSON.stringify({ ...log, status: 'failed', error: (err as Error).message }));
      throw err;
    }
  }
};

Timeout wciąż może zabić funkcję między zajęciem klucza a jego zwolnieniem, a wtedy rekord blokuje każde ponowienie. Jeśli nie chcesz ręcznie pisać dzierżawy z terminem wygaśnięcia, poproś agenta o @aws-lambda-powertools/idempotency (2.35.0 w npm, sprawdzone 2026-09-26): biblioteka zapisuje rekord „w toku” z własnym terminem wygaśnięcia i rekord ukończenia z wynikiem, więc obsługuje także ten przypadek.

Jak udowodnić, że handler przetrwa podwójne dostarczenie?

Nie czytaj handlera linijka po linijce. Zapisz cztery zachowania, które mają znaczenie, i spraw, żeby test padał, gdy którekolwiek się zepsuje. Powiedz agentowi, że testy są specyfikacją, więc czerwony test prowadzi do poprawki handlera, a nie do zmiany asercji. Dlaczego to polecenie jest ważne, wyjaśnia strona chroń wyrocznię testową.

Prompt do skopiowania: testy podwójnego dostarczenia i awarii

Write a vitest suite for src/handler.ts using aws-sdk-client-mock (mock DynamoDBClient) and vi.mock('./resize'). Build S3Event fixtures by hand. Cover exactly these behaviours:
1. The same S3 event delivered twice: resizeAndWrite is called once, and the second invocation logs status 'duplicate-skipped'.
2. resizeAndWrite throws: the handler sends DeleteItemCommand for the same pk and rethrows.
3. A key 'uploads/my+photo.jpg' reaches resizeAndWrite as 'uploads/my photo.jpg'.
4. A DynamoDB error other than ConditionalCheckFailedException is rethrown without calling resizeAndWrite.
Do not modify src/handler.ts to make a test pass. If a test fails, stop and tell me which behaviour the handler gets wrong.

Potem uruchom bramki. Każda z nich zapala się na czerwono przy konkretnym błędzie i właśnie dlatego możesz ufać wynikowi bez przeglądania każdej linijki:

Bramka	Komenda (terminal lub CI)	Czerwona, gdy
Testy zachowania	npx vitest run	Duplikat zostaje przetworzony dwa razy, klucz nie zostaje zwolniony po nieudanym skalowaniu obrazu albo klucz obiektu nie jest zdekodowany
Typy	npx tsc --noEmit	Handler czyta pole, którego nie ma w typie zdarzenia
Paczka	npx serverless package --stage dev	serverless.yml się nie parsuje albo ścieżka handlera jest błędna
Bindingi Workera	npx wrangler types, potem npx tsc --noEmit	Kod Workera czyta binding, którego nie deklaruje wrangler.toml
Bundle Workera	npx wrangler deploy --dry-run --outdir dist	Wypisany Total Upload przekracza budżet rozmiaru, z którym porównuje go krok CI (np. błąd powyżej 1 MiB); sam dry run nigdy nie pada z powodu rozmiaru i nic nie jest wysyłane
Sygnał z produkcji	CloudWatch Logs Insights: stats count(*) by status	Po wydaniu zmienia się liczba duplicate-skipped albo failed

Testy i bramki należą do ciebie. Zmiany w politykach IAM, miejscach docelowych na błędy (on-failure destination) i konfiguracji etapów trafiają do przeglądu przez człowieka, bo błędne uprawnienie IAM przejdzie wszystkie powyższe testy. Wdrożenia uruchamia CI, a nie sesja agenta. Jak dołączyć wyniki bramek do pull requesta, pokazuje strona o pakiecie dowodów.

Aby agent sam uruchomił bramki i poprawił to, co padnie:

Claude Code

claude -p "Run npx vitest run and npx tsc --noEmit. If anything fails, fix src/, never tests/, and rerun until both pass. Print which behaviour was wrong and what you changed." \
  --permission-mode acceptEdits \
  --allowedTools "Bash(npx vitest *)" "Bash(npx tsc *)" \
  --disallowedTools "Edit(tests/**)" "Write(tests/**)"

Codex

codex exec --sandbox workspace-write "Run npx vitest run and npx tsc --noEmit. If anything fails, fix src/, never tests/, and rerun until both pass. Print which behaviour was wrong and what you changed."

Cursor

Wklej to samo polecenie do agenta. Żeby uruchamiać je przy każdym pull requeście, użyj automatyzacji Cloud Agents z wyzwalaczem Source control, a powstały pull request niech przejrzy Bugbot, jak opisuje strona CI/CD w Cursorze.

Sam prompt tylko prosi agenta, żeby nie ruszał tests/. W Claude Code --disallowedTools zamienia to w regułę, której sesja nie złamie. W Codexie i Cursorze wymuś to poza agentem: wpisem w CODEOWNERS, który wymaga przeglądu tests/ przez człowieka, albo sprawdzeniem w CI, które pada, gdy gałąź agenta zmienia pliki w tests/.

Jak zbudować API gateway w Cloudflare Workers ze zgodnymi bindingami?

Workers domyślnie nie mają runtime’u Node.js, mają budżet czasu CPU na żądanie i bindingi zamiast klientów SDK. Poproś o Workera i jego konfigurację w jednym prompcie, żeby nazwy bindingów w kodzie i w wrangler.toml pochodziły z tej samej odpowiedzi.

Prompt do skopiowania: API gateway w Cloudflare Workers

Write a Cloudflare Worker in TypeScript (ES modules) that acts as an API gateway: proxy GET /v1/* to the origin in the ORIGIN var with fetch, check a bearer token against the TOKENS KV namespace, rate-limit each token to 100 requests per minute with a Durable Object class RateLimiter, and cache successful GETs in the Cache API for 60 seconds. Return JSON errors { error, requestId } with correct status codes. Keep synchronous CPU work small: move heavy CPU work out of the request into a Queue consumer or a Durable Object, and use ctx.waitUntil only for non-blocking I/O such as logging and analytics. Then give me wrangler.toml with the KV binding, the Durable Object binding and its migration, and the ORIGIN var, and add a test with @cloudflare/vitest-pool-workers that asserts 401 without a token and 429 on the 101st request.

# wrangler.toml: binding names must match the Worker's Env type
name = "api-gateway"
main = "src/index.ts"
compatibility_date = "2026-09-01"

[vars]
ORIGIN = "https://origin.internal.example.com"

[[kv_namespaces]]
binding = "TOKENS"
id = "KV_NAMESPACE_ID"

[[durable_objects.bindings]]
name = "RATE_LIMITER"
class_name = "RateLimiter"

[[migrations]]
tag = "v1"
new_sqlite_classes = ["RateLimiter"]

Zastąp KV_NAMESPACE_ID identyfikatorem, który wypisze npx wrangler kv namespace create TOKENS. Potem uruchom npx wrangler types: komenda generuje typ Env z tego pliku, więc Worker czytający env.TOKEN zamiast env.TOKENS padnie na tsc, a nie w runtime.

Jak dać agentowi dostęp do żywego stanu Cloudflare?

Wygenerowany kod to połowa pracy. Druga połowa to stan, na którym działa: literówka w identyfikatorze namespace, nieaktualna wartość w KV, trasa rzucająca błędy na produkcji. Cloudflare daje dwa sposoby, żeby pokazać to agentowi, i każdy rozwiązuje inny problem.

• Serwer MCP Cloudflare czyta i zmienia twoje żywe konto. Zalecany serwer Code Mode pod https://mcp.cloudflare.com/mcp udostępnia trzy narzędzia (search, execute, docs) nad całym API Cloudflare. Cloudflare szacuje koszt jego schematów na około 1000 tokenów wobec około 244 000 dla natywnych schematów narzędzi tego samego API (Cloudflare, README cloudflare/mcp, odczyt 2026-09-26). Wyniki są domyślnie przycinane do około 6000 tokenów. Serwery domenowe, takie jak https://observability.mcp.cloudflare.com/mcp, obejmują po jednym obszarze.
• Skille Cloudflare (cloudflare/skills, 14 skilli dla Workers, Wranglera, Durable Objects i innych) uczą agenta konwencji platformy. Wersja w postaci pluginu zawiera ten sam serwer MCP Code Mode.

Serwer MCP wymaga wpisu z adresem URL w każdym narzędziu. Uwierzytelnienie to OAuth przy pierwszym użyciu albo token API Cloudflare wysyłany jako bearer token.

Claude Code

claude mcp add --transport http cloudflare https://mcp.cloudflare.com/mcp
# or the plugin, which brings the skills and the MCP server together:
# /plugin marketplace add cloudflare/skills
# /plugin install cloudflare@cloudflare

Bez --transport http Claude Code 2.1.283 i tak zapisze adres URL jako komendę stdio. Wypisze ostrzeżenie, ale wpis trafi do konfiguracji i padnie przy łączeniu.

Codex

codex mcp add cloudflare --url https://mcp.cloudflare.com/mcp
# or the plugin:
codex plugin marketplace add cloudflare/skills
codex plugin add cloudflare@cloudflare

Cursor

Dodaj serwer do .cursor/mcp.json:

{ "mcpServers": { "cloudflare": { "url": "https://mcp.cloudflare.com/mcp" } } }

Same skille zainstalujesz dla Cursora i innych agentów przez npx skills add https://github.com/cloudflare/skills.

Przed MCP znalezienie nieaktualnego tokena oznaczało kopiowanie identyfikatorów namespace między kartami dashboardu. Z MCP jeden prompt odpowiada na podstawie żywego konta:

Prompt do skopiowania: odczyt żywego stanu Workera

Using the Cloudflare MCP server: list the bindings of the api-gateway Worker, confirm the TOKENS KV namespace id matches the one in wrangler.toml, and show the last hour of errors for api-gateway grouped by route. Read only: do not change any resource.

Wybierz skill, gdy agent ma tylko znać komendy i konwencje wrangler. Wybierz serwer MCP, gdy musi czytać albo zmieniać żywy stan, i nie dawaj uprawnień do zapisu w sesjach, które ich nie potrzebują. Odpowiednikiem dla AWS jest zestaw pluginów samego AWS (aws/agent-toolkit-for-aws, z pluginem aws-core do pracy z serverless i CDK). W Claude Code zainstalujesz go przez /plugin install aws-core@claude-plugins-official. W Codexie uruchom codex plugin marketplace add aws/agent-toolkit-for-aws, a potem zainstaluj aws-core z /plugins. Pełna lista serwerów i szczegóły OAuth są na stronie MCP Cloudflare.

Więcej promptów serverless: cold starty, kolejki i Vercel

Prompt do skopiowania: triage cold startów przed provisioned concurrency

My Lambda image-processor (Node.js 22, 1024 MB, in a VPC) has a p99 of 4 s in the morning and about 300 ms the rest of the day. Write a CloudWatch Logs Insights query that splits REPORT lines into Init Duration and Duration and shows how many invocations were cold. Then rank the likely causes: bundle size, SDK clients created at module scope, VPC networking, unused dependencies. Propose the cheapest fixes first (esbuild tree-shaking, dropping unused packages, lazy imports, removing the VPC if it is only there for DynamoDB). Recommend provisioned concurrency, with a concrete number, only if those fixes cannot bring p99 under 1 s, and say how to measure the result.

Prompt do skopiowania: konsument SQS z częściowymi błędami batcha

Write an SQS to Lambda consumer in TypeScript for order events with batchSize 10 and functionResponseType ReportBatchItemFailures, so one poison message does not fail the whole batch. Validate each message with a zod schema. Make the handler idempotent on orderId with a DynamoDB conditional write that is released on failure. Give me the serverless.yml for the queue and a DLQ with maxReceiveCount 3, a replay.ts script that moves DLQ messages back to the main queue, and vitest tests for: one invalid message in a batch of ten, and the same orderId delivered twice.

Prompt do skopiowania: Vercel Function z routingiem A/B według geolokalizacji

Write a Vercel Function that assigns a stable A/B variant: read the visitor country with geolocation(request) from @vercel/functions; bucket visitors whose country is in the comma-separated AB_COUNTRIES environment variable into the experiment, with the variant derived from a hash of a 'variant' cookie (set one if it is missing), and send everyone else to variant A; then stream the chosen origin's HTML through unchanged. Set the cookie on the first visit only. Use Web standard Request, Response and streams so the code has no Node.js-only APIs. Add tests that the same cookie always yields the same variant and that a visitor from a country outside AB_COUNTRIES always gets variant A.

Co się psuje, gdy kod serverless od agenta trafia na produkcję?

Podwójne przetwarzanie przy ponowieniach

Częsty błąd w serverless, a kod pisany tylko pod ścieżkę bez błędów rzadko go obsługuje. Objaw: dwa e-maile, dwa obciążenia albo nadpisane miniatury. Wyjście: znajdź stabilny klucz (eTag z S3, messageId z SQS, własny orderId) i daj agentowi prompt: „This handler is not idempotent. Add a DynamoDB conditional-write claim on KEY before any side effect, release it on failure, and add a test that delivers the same event twice.”

Rekord idempotencji, który nigdy nie znika

Objaw: obiekt nigdy nie zostaje przetworzony, a każde ponowienie loguje duplicate-skipped. Przyczyna: klucz został zajęty, a potem funkcja przekroczyła timeout albo padła, zanim zdążyła go zwolnić. Wyjście: usuń zablokowany rekord, a potem zastąp zwykłe zajęcie klucza dzierżawą, która wygasa (status „w toku” plus termin krótszy niż okno ponowień), albo przejdź na @aws-lambda-powertools/idempotency.

Rekurencyjny wyzwalacz S3

Objaw: liczba wywołań i rachunek rosną w ciągu minut. Przyczyna: funkcja zapisuje wynik do bucketu, który ją wyzwala. Wyjście: ustaw reserved concurrency funkcji na 0, żeby ją zatrzymać, a potem zapisuj wynik do osobnego bucketu albo ogranicz wyzwalacz do prefiksu wejściowego, np. uploads/. Dodawaj to ograniczenie do każdego promptu z S3. Wykrywanie pętli rekurencyjnych w Lambdzie, domyślnie włączone, obejmuje pętle przez Amazon S3 i zatrzymuje funkcję po około 16 wywołaniach w tym samym łańcuchu, ale tylko wtedy, gdy funkcja używa obsługiwanej wersji AWS SDK (dokumentacja AWS Lambda o wykrywaniu pętli rekurencyjnych, sprawdzone 2026-09-26). Traktuj je jako zabezpieczenie awaryjne, a nie rozwiązanie: pętli zapobiega osobny bucket albo prefiks.

Limity CPU w Cloudflare Workers, a nie limity czasu zegarowego

Workers ograniczają czas CPU na żądanie, a nie czas oczekiwania na fetch: 10 ms w planie Free, a w planie Paid domyślnie 30 sekund, z możliwością podniesienia do 5 minut przez limits.cpu_ms (strona limitów Cloudflare Workers, sprawdzone 2026-09-26). Worker, który parsuje duży JSON albo liczy hashe w pętli, pada z Error 1102, choć na twoim laptopie działa szybko. Wyjście: daj agentowi prompt: „Profile the synchronous CPU work in the request path, move heavy CPU work out of the request into a Queue consumer or a Durable Object, and use ctx.waitUntil only for non-blocking I/O such as logging”.

Gorące partycje w DynamoDB

Klucz partycji o małej kardynalności (np. status#PENDING) kieruje cały ruch do jednej partycji i pod obciążeniem dostajesz ProvisionedThroughputExceededException, choć średnie wykorzystanie wygląda na niskie. Wyjście: zamiast podnosić przepustowość, daj agentowi prompt: „Check the partition-key cardinality and propose a write-sharding suffix or a GSI”.

Provisioned concurrency z odruchu

Włączenie go na każdej funkcji to sposób na podwojenie rachunku. Opłaca się tylko na wrażliwej na opóźnienia ścieżce synchronicznej z przewidywalnym ruchem. Asynchroniczne handlery, takie jak powyższe konsumenty S3 i SQS, rzadko go potrzebują. Najpierw uruchom prompt do triage cold startów i mierz Init Duration przed każdą poprawką i po niej.

Dokąd dalej w temacie serverless

Wzorce tworzenia API Klucze idempotencji, paginacja i OpenAPI dla tras za Workerem-bramką.

Wzorce NoSQL Projekt kluczy i wzorce dostępu w DynamoDB dla tabel używanych przez te handlery.

Infrastruktura jako kod Przenieś te stosy do Terraform albo Pulumi z wdrożeniami wieloetapowymi.

Monitoring i obserwowalność Zamień ustrukturyzowane logi w alerty i dashboardy.

MCP Cloudflare Code Mode, serwery domenowe, OAuth i konfiguracja dla każdego narzędzia.

Najlepsze skille backendowe i platformowe Porównanie skilli Cloudflare, AWS i baz danych.