A Cloudflare platform mentális modellje

1.1Két világkép: régió vs. edge

Az AWS-en az alkalmazásod egy helyen él: kiválasztasz egy régiót (mondjuk eu-central-1), ott futnak az EC2-instance-ok a Beanstalk mögött, ott van az Aurora, és a világ többi részét a CloudFront CDN-nel „hozod közelebb". A skálázás azt jelenti, hogy több és nagyobb gépet kérsz ugyanoda.

A Cloudflare-en ez a kérdés fel sem merül. A kódod egyszerre fut a hálózat több száz városának mindegyikében — deploykor nem választasz régiót, mert nincs mit választani. A felhasználó kérése a hozzá legközelebbi adatközpontba (PoP — point of presence) érkezik, és jellemzően ott is szolgálják ki. A CDN nem egy külön termék az alkalmazásod előtt, hanem maga a platform, amiben az alkalmazásod fut.

1.2Mi az a Worker — és miért nem „kis Lambda"?

A Cloudflare compute-egysége a Worker: egy JavaScript/TypeScript (vagy Python, Rust) modul, ami HTTP-kérésekre, üzenetekre, cron-eseményekre reagál. A döntő különbség a futtatási modellben van: a Worker nem konténerben és nem Node-processzben fut, hanem V8 isolate-ben — ugyanabban a könnyűsúlyú homokozóban, amit a Chrome egy-egy böngészőfülhöz használ.

Egy gépen több ezer isolate él egymás mellett egyetlen processzben. Egy új isolate elindítása ezredmásodpercek kérdése — ezért nincs a Lambdánál megszokott cold start probléma, és ezért lehet a kódod egyszerre „mindenhol". Az ára ennek az, hogy a runtime nem Node.js: a webes standard API-kat kapod (fetch, Request/Response, URL, Web Crypto, streams), plusz egy egyre teljesebb Node-kompatibilitási réteget (nodejs_compat).

1.3Bindings: az IAM + SDK + connection string helyett

AWS-en egy szolgáltatás használata így néz ki: IAM role/policy → SDK-kliens példányosítása → régió és credentialök → hálózati hívás. A Cloudflare-en ehelyett binding-okat deklarálsz a konfigurációban: a Worker env objektumán egyszerűen megjelenik a kapcsolt erőforrás, natív JavaScript API-val, hitelesítés és endpoint-konfiguráció nélkül.

// IAM policy + credentials szükséges
import { S3Client, PutObjectCommand }
  from "@aws-sdk/client-s3";

const s3 = new S3Client({ region: "eu-central-1" });
await s3.send(new PutObjectCommand({
  Bucket: "my-bucket",
  Key: "avatar.png",
  Body: data,
}));

// nincs SDK, nincs credential, nincs régió —
// a binding a konfigban van deklarálva

export default {
  async fetch(request, env) {
    await env.MY_BUCKET.put("avatar.png",
      request.body);
    return new Response("OK");
  },
};

A jogosultság magából a bindingból következik: ha a Worker konfigjában ott a bucket, használhatja; ha nincs, nem is látja. Ez az IAM-nél durvább szemcséjű, de radikálisan egyszerűbb modell — a 9. modulban nézzük meg, mit jelent ez biztonsági szemmel.

1.4Szolgáltatás-térkép: mi minek a megfelelője

1.5Az első Worker — 5 perc alatt

A platform CLI-je a Wrangler (a terraform + eb + sam szerepét tölti be egyszerre, de egyetlen eszközként). Projektet a create-cloudflare generátorral érdemes indítani:

# új projekt interaktív varázslóval
npm create cloudflare@latest -- my-first-worker

# lokális fejlesztői szerver (http://localhost:8787)
npx wrangler dev

# deploy a Cloudflare hálózatra — ennyi, nincs több lépés
npx wrangler deploy

A projekt szíve két fájl. A konfiguráció (wrangler.jsonc) — ez tölti be azt a szerepet, amit AWS-en a Beanstalk-konfig, a CloudFormation-sablon és az IAM-policyk együtt:

{
  "name": "my-first-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-08-02",   // a runtime viselkedésének „verziója"
  "compatibility_flags": ["nodejs_compat"], // Node API-k engedélyezése

  // bindings — így „kapja meg" a Worker a szolgáltatásokat:
  "r2_buckets": [{ "binding": "MY_BUCKET", "bucket_name": "uploads" }],
  "vars": { "APP_ENV": "production" }
}

És maga a Worker — egy modul, ami exportál egy fetch handlert (gondolj rá úgy, mint az Express app helyére, csak webstandard Request/Response objektumokkal):

export default {
  async fetch(request, env, ctx): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === "/api/hello") {
      return Response.json({
        message: "Hello from the edge!",
        servedFrom: request.cf?.colo,  // pl. "BUD" — a budapesti PoP
        env: env.APP_ENV,
      });
    }
    return new Response("Not found", { status: 404 });
  },
};

A wrangler deploy után a Worker azonnal él egy *.workers.dev címen (később saját domaint kötsz rá). Nincs AMI, nincs instance-típus, nincs security group, nincs ALB target group — és nincs várakozás: a deploy másodpercek alatt globális.

1.6Mit nem kell többé csinálnod?

• Kapacitástervezés és autoscaling — nincs instance-méret, nincs scaling policy, nincs „mi lesz Black Friday-kor".
• Load balancer és target group — a hálózat maga a load balancer.
• CDN-konfiguráció külön rétegként — nincs CloudFront distribution, invalidation, origin config; a cache a platform része.
• OS- és runtime-patchelés — nincs AMI-frissítés, nincs Node-verzió upgrade az instance-okon.
• Fizetés üresjáratért — nulla forgalom = (közel) nulla számla; nincs éjszaka is pörgő EC2.

Cserébe új kérdéseket kell megtanulnod feltenni: belefér-e a CPU-limitbe? edge-kompatibilis-e ez az npm-csomag? hova kerül az állapot, ha nincs processz-memória? — pontosan ezekről szól a következő modul.

1.7Ellenőrizd magad