CDN, WAF আর DDoS সুরক্ষা — certificate আর edge-এর কাজ

১ · Edge কী — আপনার server-এর সামনের প্রথম দরজা

একটি কাল্পনিক অনলাইন বাজার অ্যাপ ধরুন। নাম দিই “বাজারঘর”। Server আছে একটি region-এ, আর ক্রেতা সারা দেশে। ঈদের আগে রাত ১২টায় ছাড় শুরু হবে। আগের অভিজ্ঞতা বলে তিনটি ঝামেলা হয়। পাতা ধীর হয়। Server একই ব্যানার ছবি লাখবার পাঠাতে গিয়ে হাঁপিয়ে ওঠে। আর কিছু script লগইন পাতায় অনবরত অনুরোধ পাঠায়।

তিনটি সমস্যার সমাধান এক জায়গায় বসে। সেই জায়গার নাম edge. এটি ব্যবহারকারীর কাছাকাছি provider-এর ছোট ঘাঁটি। পর্ব ৫-এ (Cloud-এর ভৌগোলিক কাঠামো) এর পরিচয় পেয়েছেন। এই পর্বে দেখবেন, সেখানে আসলে কী কী কাজ হয়, আর সেই কাজ কে সাজায়।

CDN-এর তত্ত্ব এই সাইটে আগেই আছে। কেন CDN, Zipf জনপ্রিয়তা আর push বনাম pull পাবেন System Design-এর CDN আর edge পর্বে। HTTP caching-এর নিয়ম, ETag আর 304 পাবেন Computer Networks-এর Web caching আর CDN পর্বে। এখানে আমরা অপারেশনের দিক দেখব: কীভাবে সাজাবেন, চালাবেন, রক্ষা করবেন আর বিল মেলাবেন।

ছবিতে ক্রমটি খেয়াল করুন। TLS প্রথমে শেষ হয়, তাই WAF অনুরোধের ভেতরটা পড়তে পারে। অনেক CDN-এ WAF cache-এর আগে বসে, তবে ক্রম provider-ভেদে আলাদা হতে পারে। তাই আপনার provider-এর docs মিলিয়ে নিন।

২ · CDN সাজানো — distribution, origin, behaviour আর cache key

CDN চালু করা মানে চারটি প্রশ্নের উত্তর দেওয়া। কোন নামে আসবে? আসল জিনিস কোথায়? কোন পথের সাথে কেমন আচরণ হবে? আর দুটি অনুরোধ “একই” কখন?

Cache key-ই সবচেয়ে বেশি ভুল হয়। Key-তে বেশি জিনিস রাখলে একই ফাইলের অনেক কপি জমে, hit কমে। কম জিনিস রাখলে এক জনের উত্তর আরেকজন পেতে পারে। এই দ্বিতীয়টি নিরাপত্তার ভুল। নিয়মটি এক লাইনে: উত্তর যা দিয়ে বদলায়, key-তে শুধু তাই থাকবে।

নিচে Terraform-এ বাজারঘরের সেটআপের মূল অংশ দেখুন। AWS-এর উদাহরণ, তবে ধারণা তিন provider-এই এক। Terraform পরে শিখবেন (পর্ব ৫২), এখন শুধু গঠন পড়ুন।

# উদাহরণ: চালানোর জন্য নয়। আসল cloud-এ চালালে খরচ হতে পারে।
resource "aws_cloudfront_distribution" "shop" {
  enabled = true
  aliases = ["shop.example.com"]

  origin {                    # static files: private bucket
    origin_id                = "assets"
    domain_name              = "example-bucket.s3.ap-southeast-1.amazonaws.com"
    origin_access_control_id = aws_cloudfront_origin_access_control.assets.id
  }
  origin {                    # API: load balancer
    origin_id   = "api"
    domain_name = "origin.shop.example.com"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  ordered_cache_behavior {    # hashed files: cache for a long time
    path_pattern           = "/assets/*"
    target_origin_id       = "assets"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    cache_policy_id        = var.long_cache_policy_id
  }
  default_cache_behavior {    # everything else: do not cache
    target_origin_id         = "api"
    viewer_protocol_policy   = "redirect-to-https"
    allowed_methods          = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods           = ["GET", "HEAD"]
    cache_policy_id          = var.no_cache_policy_id
    origin_request_policy_id = var.forward_all_policy_id
  }

  restrictions {
    geo_restriction { restriction_type = "none" }
  }
  viewer_certificate {
    acm_certificate_arn      = var.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }
}

তিন provider-এর নাম

নাম আর ভাগ সময়ের সাথে বদলায়, তাই লেখার সময়ের ছবি হিসেবে নিন। Cloudflare, Akamai আর Fastly-র মতো স্বাধীন CDN-ও বহুল ব্যবহৃত, আর এগুলো যেকোনো cloud-এর origin-এর সামনে বসতে পারে।

প্রথম অনুরোধ বনাম দ্বিতীয় অনুরোধ

Edge-এ cache থাকলে উত্তরকে বলে hit, না থাকলে miss. নিচে একই CSS ফাইলের দুটি অনুরোধ দেখুন। সময়গুলো হিসাবের সুবিধার জন্য ধরে নেওয়া: ব্যবহারকারী থেকে edge ১৫ ms, edge থেকে shield ৬০ ms, shield থেকে origin ৪০ ms, origin-এর নিজের কাজ ২৫ ms (প্রতিটিই যাওয়া-আসা মিলিয়ে)।

আপনার সাইটে hit না miss, তা নিজেই দেখতে পারেন। Header-এর নাম CDN-ভেদে আলাদা।

# উদাহরণ: নিজের site-এ চালান। নিচের উত্তর নমুনা, CDN-ভেদে আলাদা হবে।
curl -sI https://shop.example.com/assets/app.3f9a1c.css

HTTP/2 200
content-type: text/css
cache-control: public, max-age=31536000, immutable
age: 12
x-cache: Hit from cloudfront

৩ · Hit ratio-র অঙ্ক — origin-এর ভার আর মাসের বিল

Cache hit ratio ৯০% শুনতে ভালো লাগে। কিন্তু origin-এর কাছে গুরুত্বপূর্ণ সংখ্যাটি হলো miss. কারণ origin-এর ভার miss-এর সমানুপাতিক:

ধরুন peak-এ সেকেন্ডে ১,০০০ অনুরোধ।

এজন্যই শেষের কয়েক পয়েন্টের দাম এত বেশি। ৫০% থেকে ৫৫% হলে ভার কমে ১০ ভাগের ১ ভাগ। ৯০% থেকে ৯৫% হলে কমে অর্ধেক।

মাসের বিল — একটি সিমুলেটর

নিচের কোডে সব দাম ধরে নেওয়া গোল সংখ্যা। আসল দাম region, আয়তন আর চুক্তিতে বদলায়, তাই provider-এর pricing পাতা দেখে PRICE বদলে আবার চালান। মাস ৩০ দিনের, গড়ে ১০০ req/s, peak ১,০০০ req/s, গড় উত্তর ১০০ KB. Origin-এ অন্তত ২টি server থাকবে, কারণ একটিতে নিরাপত্তা নেই (পর্ব ১৭-এর শিক্ষা)।

// A month of traffic through a CDN. All prices are ASSUMED round numbers.
const RPS_AVG = 100, RPS_PEAK = 1000;       // requests per second
const KB_PER_REQ = 100;                     // average response size
const SEC_MONTH = 30 * 24 * 3600, HOURS = 720;

const PRICE = {
  directEgressGB: 0.09,   // origin straight to users
  cdnEgressGB: 0.06,      // CDN to users
  cdnPerMillion: 1.00,    // CDN request fee
  fillGB: 0.02,           // origin to CDN (set 0 if your provider gives it free)
  serverHour: 0.10,       // one origin server
};
const SERVER_RPS = 250, MIN_SERVERS = 2;

const millions = RPS_AVG * SEC_MONTH / 1e6;
const totalGB = millions * 1e6 * KB_PER_REQ * 1000 / 1e9;
const servers = (peak) => Math.max(MIN_SERVERS, Math.ceil(peak / SERVER_RPS));
const usd = (x) => ('$' + x.toFixed(0)).padStart(7);

console.log(`month: ${millions.toFixed(1)} million requests, ${totalGB} GB`);
const directBill = totalGB * PRICE.directEgressGB + servers(RPS_PEAK) * PRICE.serverHour * HOURS;
console.log(`no CDN: ${servers(RPS_PEAK)} servers, bill ${usd(directBill).trim()}`);
console.log('hit%  originRPS(peak)  servers  originGB   CDN   fill  server   total');

for (const hit of [0, 0.5, 0.8, 0.9, 0.95, 0.99]) {
  const peak = RPS_PEAK * (1 - hit), fillGB = totalGB * (1 - hit), n = servers(peak);
  const cdn = totalGB * PRICE.cdnEgressGB + millions * PRICE.cdnPerMillion;
  const fill = fillGB * PRICE.fillGB, srv = n * PRICE.serverHour * HOURS;
  console.log(`${String(hit * 100).padStart(3)}%  ${peak.toFixed(0).padStart(15)}  ${String(n).padStart(7)}` +
    `  ${fillGB.toFixed(0).padStart(8)} ${usd(cdn)} ${usd(fill).slice(1)} ${usd(srv)} ${usd(cdn + fill + srv)}`);
}

month: 259.2 million requests, 25920 GB
no CDN: 4 servers, bill $2621
hit%  originRPS(peak)  servers  originGB   CDN   fill  server   total
  0%             1000        4     25920   $1814   $518    $288   $2621
 50%              500        2     12960   $1814   $259    $144   $2218
 90%              100        2      2592   $1814    $52    $144   $2010
 99%               10        2       259   $1814     $5    $144   $1964

Origin shield — miss-কেও এক জায়গায় জমানো

ধরুন ২০টি edge, ৫,০০০টি জনপ্রিয় ফাইল, আর প্রতিটির TTL ১ ঘণ্টা। প্রতিটি edge আলাদাভাবে ফাইল আনলে দিনে origin-এ যায় ৫,০০০ × ২০ × ২৪ = ২৪,০০,০০০ অনুরোধ। মাঝখানে একটি origin shield বসালে সব edge আগে সেখানে আসে। তখন origin-এ যায় ৫,০০০ × ২৪ = ১,২০,০০০ অনুরোধ, অর্থাৎ ২০ ভাগের ১ ভাগ।

Shield আরেকটি কাজ করে। একই ফাইলের অনেক miss একসাথে এলে সে একটিই origin-এ পাঠায়, বাকিরা অপেক্ষা করে। একে বলে request collapsing. পর্ব ২৩-এর cache stampede-এর ওষুধ এটিই।

AWS-এ এর নাম Origin Shield. অন্য CDN-এ tiered cache-এর মতো নামে একই ধারণা পাবেন। Shield-এর নিজের খরচ আছে, আর একটি বাড়তি hop যোগ হয়। ফাইল কম হলে বা ব্যবহারকারী এক অঞ্চলে হলে লাভ কম। Shield সেই region-এ রাখুন যেটি origin-এর সবচেয়ে কাছে।

৪ · Cache-Control আর versioned file — পুরোনো জিনিস ভোলানোর দুই পথ

Cache-এর সবচেয়ে কঠিন প্রশ্ন হলো, জিনিস বদলালে কী হবে? আগে দেখুন, origin কীভাবে নির্দেশ দেয়। Cache-Control header-এর পূর্ণ নিয়ম RFC 9111 (২০২২)-এ আছে। কাজের মানগুলো এই:

ফাইল বদলালে পুরোনো কপি সরানোর পথ দুটি।

প্রতি deploy-এ /* invalidation সবচেয়ে সহজ, আর সবচেয়ে বিপজ্জনক। সব edge একসাথে খালি হয়, অর্থাৎ cold cache. সেকেন্ডে ১,০০০ অনুরোধের সাইটে h ৯৫% থাকলে origin পেত ৫০টি। Purge-এর ঠিক পরে প্রায় ১,০০০টি পেতে পারে, অর্থাৎ ২০ গুণ। তার ওপর অনেক provider নির্দিষ্ট সংখ্যার বেশি invalidation-এ টাকা নেন।

নিচে নিরাপদ পথটি দেখুন। Build tool নতুন CSS বানিয়েছে: app.7d2e40.css. HTML সবসময় ঠিক করে কোন CSS চলবে, তাই HTML-এর আয়ু ছোট, আর CSS-এর আয়ু লম্বা। এখানে ধরে নিচ্ছি HTML-ও bucket থেকে আসে, নিজের একটি behaviour-এ ৬০ সেকেন্ডের TTL নিয়ে।

# উদাহরণ: চালানোর জন্য নয়। ক্রমটিই আসল কথা।
# 1) assets first. No --delete here: old files must stay.
aws s3 sync dist/assets s3://example-bucket/assets \
  --cache-control "public, max-age=31536000, immutable"

# 2) then the HTML
aws s3 cp dist/index.html s3://example-bucket/index.html \
  --cache-control "public, max-age=60"

# 3) purge one path, not /*
aws cloudfront create-invalidation \
  --distribution-id E123EXAMPLE --paths "/index.html"

৫ · Origin রক্ষা আর certificate — দরজা একটিই রাখা

CDN-এর সব নিয়ম তখনই কাজ করে, যখন সবাই CDN দিয়েই আসেন। Origin-এর ঠিকানা সরাসরি খোলা থাকলে যে কেউ WAF আর cache-কে পাশ কাটিয়ে যেতে পারে। বাড়ির সামনে দারোয়ান রেখে পেছনের দরজা খোলা রাখার মতো।

Bucket origin — public করবেন না

পর্ব ২১-এ (Object storage চালানো) দেখেছেন, bucket public রাখা সবচেয়ে পরিচিত দুর্ঘটনা। AWS-এ origin access control CDN-কে নিজের পরিচয়ে bucket পড়তে দেয়। Bucket policy বলে দেয়, শুধু এই একটি distribution পড়তে পারবে।

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowOneDistributionToRead",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123EXAMPLE"
      }
    }
  }]
}

Load balancer origin — তিনটি স্তর

1. ঠিকানায় সীমা: Security group-এ শুধু CDN-এর IP range-কে ঢুকতে দিন (পর্ব ২৭)। AWS-এ এর জন্য তৈরি একটি managed prefix list আছে।
2. গোপন header: ওপরের list-এ সব গ্রাহকের CDN আছে। অন্য কারও distribution-ও আপনার origin-এ আসতে পারে। তাই CDN অনুরোধে একটি গোপন header জোড়ে, আর LB-র rule সেটি না পেলে ফিরিয়ে দেয়। Header-এর মান secret manager-এ রাখুন আর পালা করে বদলান (পর্ব ৩৩)।
3. Private origin: সম্ভব হলে origin-কে public ঠিকানাই দেবেন না। CloudFront-এর VPC origin, Azure Front Door-এর Private Link-এর মতো ব্যবস্থা এজন্যই। সমর্থন আর দাম provider-ভেদে আলাদা।

# উদাহরণ: চালানোর জন্য নয়। id-গুলো নমুনা।
aws ec2 describe-managed-prefix-lists --filters \
  Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-0123456789abcdef0}]'

Certificate — দুই ভাগের TLS

CDN থাকলে TLS সংযোগ দুটি। একটি ব্যবহারকারী থেকে edge, আরেকটি edge থেকে origin. দুটিতেই TLS certificate লাগে। দ্বিতীয়টি বাদ দিলে, অর্থাৎ edge থেকে origin-এ সাধারণ HTTP পাঠালে, browser-এ তালা দেখালেও পথের অর্ধেক খোলা থাকে।

Managed certificate হলে নেওয়া, রাখা আর নবায়নের কাজ provider করে। পর্ব ১৪-তে certbot দিয়ে যা হাতে করেছিলেন, এখানে সেটি সেবা। Private key সাধারণত আপনার হাতে আসে না, তাই আপনার দিক থেকে ফাঁসের সুযোগও কমে। তিনটি বিষয়ে তবু নজর রাখুন:

• DNS validation-এর record রেখে দিন। নবায়নের সময় provider সেই record দেখেই মালিকানা যাচাই করে। কেউ “অদরকারি” ভেবে মুছলে নবায়ন আটকে যেতে পারে। পর্ব ১৪-এর dns-01 ধারণাই এখানে কাজ করে।
• Region-এর নিয়ম দেখুন। লেখার সময়ে CloudFront-এর জন্য ACM certificate us-east-1-এ নিতে হয়, app যেখানেই থাকুক। এমন নিয়ম provider-ভেদে আলাদা।
• Origin-এর নাম মিলতে হবে। Edge origin-এর certificate যাচাই করে। নাম না মিললে বা মেয়াদ ফুরালে ব্যবহারকারী 502-জাতীয় error দেখেন, অথচ edge-এর certificate ঠিকই থাকে।

Managed হলেও মেয়াদের alert রাখুন। Certificate-এর মেয়াদ কমার ধারা আগেই পর্ব ১৪-এ দেখেছেন। CA/Browser Forum-এর ২০২৫ সালের সিদ্ধান্তে সর্বোচ্চ মেয়াদ ধাপে ধাপে কমে ২০২৯ সালে ৪৭ দিনে নামার কথা। হাতে নবায়ন তখন আর চলবে না।

৬ · WAF — count আগে, block পরে

WAF মানে Web Application Firewall. Security group দেখে IP আর port. WAF অনুরোধের ভেতরটা পড়ে: path, header, query আর body-র প্রথম অংশ। মেট্রো স্টেশনের ব্যাগ স্ক্যানারের সাথে তুলনা করুন। গেটম্যান শুধু টিকিট দেখেন, স্ক্যানার ব্যাগের ভেতরটা দেখে। ফলে স্ক্যানার মাঝেমধ্যে নিরীহ জিনিসেও আপত্তি করে।

Rule-গুলো ক্রমে চলে। প্রতিটির একটি action থাকে: allow, block, count বা CAPTCHA-র মতো challenge. প্রধান ধরনগুলো এই:

নিচের JSON-এ AWS WAF-এর দুটি rule আছে। প্রথমটি managed rule set, যার ফল আপাতত শুধু গোনা হবে (Count). দ্বিতীয়টি ৫ মিনিটে একটি IP থেকে ২,০০০-এর বেশি অনুরোধ আটকাবে।

[
  {
    "Name": "managed-common",
    "Priority": 10,
    "Statement": {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesCommonRuleSet"
      }
    },
    "OverrideAction": { "Count": {} },
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "managed-common"
    }
  },
  {
    "Name": "per-ip-limit",
    "Priority": 20,
    "Statement": {
      "RateBasedStatement": {
        "Limit": 2000,
        "EvaluationWindowSec": 300,
        "AggregateKeyType": "IP"
      }
    },
    "Action": { "Block": {} },
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "per-ip-limit"
    }
  }
]

Count বনাম block — একটি ছোট evaluator

Count mode-এ rule মিললে শুধু log হয়, অনুরোধ এগিয়ে যায়। Block-এ অনুরোধ সেখানেই শেষ। নিচের খেলনা WAF একই পাঁচটি অনুরোধ তিনভাবে চালায়। Rule-টি ইচ্ছা করেই স্থূল: body-তে “select” আর তার পরে “from” থাকলেই সন্দেহ করে। আসল rule অনেক সূক্ষ্ম, তবে ভুলের ধরন একই। কোডের good ঘরটি জানায় অনুরোধটি আসলে ভালো কি না। আসল WAF তা জানে না, আমরা রেখেছি শুধু ভুল মাপার জন্য।

// A toy WAF. Rules run in priority order: count only notes a match, block stops.
const R = (id, path, ip, body, good) => ({ id, path, ip, body, good });
const requests = [
  R(1, '/api/search', '198.51.100.8', 'select from eid offers', true),
  R(2, '/api/search', '198.51.100.9', 'select shoes from dhaka', true),
  R(3, '/api/login', '203.0.113.50', 'select ... from ... probe', false),
  R(4, '/admin', '203.0.113.50', '', false),
  R(5, '/admin', '192.0.2.10', '', true),
];
const makeRules = (mode, narrow) => [
  { name: 'sql-words', mode, test: (r) => /select.*from/.test(r.body) && !(narrow && r.path === '/api/search') },
  { name: 'admin-office-only', mode, test: (r) => r.path === '/admin' && r.ip !== '192.0.2.10' },
];
function evaluate(req, rules) {
  const counted = [];
  for (const rule of rules) {
    if (!rule.test(req)) continue;
    if (rule.mode === 'block') return { action: 'BLOCK', by: rule.name, counted };
    counted.push(rule.name);                     // count: note it, keep going
  }
  return { action: 'ALLOW', by: '-', counted };
}
function run(title, rules) {
  console.log(`--- ${title}`);
  const tally = { badBlocked: 0, goodBlocked: 0, badPassed: 0 };
  for (const r of requests) {
    const d = evaluate(r, rules), note = d.counted.length ? ' count:' + d.counted.join(',') : '';
    console.log(`#${r.id} ${r.path.padEnd(11)} ${d.action.padEnd(5)} ${d.by}${note}`);
    if (d.action === 'BLOCK') tally[r.good ? 'goodBlocked' : 'badBlocked']++; else if (!r.good) tally.badPassed++;
  }
  console.log(JSON.stringify(tally));
}
run('A: count mode', makeRules('count', false));
run('B: block mode, rule as shipped', makeRules('block', false));
run('C: block mode, /api/search excluded', makeRules('block', true));

--- A: count mode
#1 /api/search ALLOW - count:sql-words
#3 /api/login  ALLOW - count:sql-words
{"badBlocked":0,"goodBlocked":0,"badPassed":2}
--- B: block mode, rule as shipped
#1 /api/search BLOCK sql-words
{"badBlocked":2,"goodBlocked":2,"badPassed":0}
--- C: block mode, /api/search excluded
#1 /api/search ALLOW -
{"badBlocked":2,"goodBlocked":0,"badPassed":0}

Rule ছাড়ার নিরাপদ পথ

ধরুন বাজারঘরে দিনে ১০,০০,০০০ অনুরোধ আসে। নতুন managed rule set বসাবেন। নিচের সংখ্যাগুলো উদাহরণ।

০.০২৪% ভুল খুব ছোট শোনায়। কিন্তু দিনে ২৪০ জন আসল ক্রেতা, আর ঈদের ভিড়ে সেটি কয়েক গুণ হতে পারে। তাঁরা error দেখে অভিযোগ করেন না, সাধারণত অন্য দোকানে চলে যান।

৭ · Edge-এ rate limit — token bucket আর bot

WAF-এর rule চেনে অনুরোধের চেহারা। Rate limit দেখে অনুরোধের পরিমাণ। বৈধ চেহারার অনুরোধও অতিরিক্ত হলে ক্ষতি করে।

দুটি সংখ্যা। Capacity ঠিক করে একবারে সর্বোচ্চ কত বড় ঝাঁক যাবে। Rate ঠিক করে দীর্ঘ সময়ের গড় গতি। T সেকেন্ডে সর্বোচ্চ capacity + rate × T সংখ্যক অনুরোধ যেতে পারে।

// A token bucket on a simulated clock: one tick = one second.
// capacity = the largest burst; rate = tokens added per second.
function tokenBucket(capacity, rate, arrivals) {
  let tokens = capacity, passed = 0, refused = 0;
  const rows = [];
  arrivals.forEach((want, sec) => {
    if (sec > 0) tokens = Math.min(capacity, tokens + rate);   // refill first
    const ok = Math.min(want, tokens);
    tokens -= ok;
    passed += ok;
    refused += want - ok;
    rows.push(`${String(sec).padStart(2)}  want ${String(want).padStart(3)}  ok ${String(ok).padStart(3)}` +
              `  429 ${String(want - ok).padStart(3)}  tokens left ${tokens}`);
  });
  return { rows, passed, refused };
}

function show(title, capacity, rate, arrivals) {
  const r = tokenBucket(capacity, rate, arrivals);
  console.log(`--- ${title} (capacity ${capacity}, rate ${rate}/s)`);
  r.rows.forEach((x) => console.log(x));
  const total = r.passed + r.refused;
  console.log(`passed ${r.passed}/${total} (${(100 * r.passed / total).toFixed(0)}%), refused ${r.refused}`);
}

// One shopper opens a page: a quick burst of 8 calls, then normal clicks.
show('one shopper', 10, 2, [8, 1, 0, 0, 1, 0]);
// A script calling the login endpoint without pause.
show('script', 10, 2, [20, 20, 20, 20, 20, 20]);
// 30 shoppers behind one shared public IP (CGNAT), 1 call each per second.
show('30 shoppers, one shared IP', 10, 2, [30, 30, 30, 30, 30, 30]);

--- one shopper (capacity 10, rate 2/s)
 0  want   8  ok   8  429   0  tokens left 2
 1  want   1  ok   1  429   0  tokens left 3
passed 10/10 (100%), refused 0
--- script (capacity 10, rate 2/s)
 1  want  20  ok   2  429  18  tokens left 0
passed 20/120 (17%), refused 100
--- 30 shoppers, one shared IP (capacity 10, rate 2/s)
passed 20/180 (11%), refused 160

শেষ সারিটি কাল্পনিক নয়। মোবাইল operator-রা প্রায়ই CGNAT ব্যবহার করেন, যেখানে বহু গ্রাহক একই public IP-র পেছনে থাকেন। বাংলাদেশের মোবাইল ইন্টারনেটেও এমন হওয়া স্বাভাবিক, যদিও ঠিক কত জন একটি IP ভাগ করেন তা operator-ভেদে আলাদা। তাই সীমা ঠিক করুন ভেবে:

• সম্ভব হলে key হিসেবে IP নয়, লগইন-করা user id বা API key নিন।
• Path ধরে আলাদা সীমা দিন। /api/login আর OTP পাঠানোর path কড়া, ছবির path শিথিল।
• Block-এর আগে count করুন। সীমার ঠিক নিচে কারা আছেন, log থেকে দেখুন।
• ঠিক উত্তর দিন। 429 Too Many Requests, সাথে Retry-After header (RFC 6585, ২০১২). ভালো client তাহলে অপেক্ষা করে আবার চেষ্টা করে।

Token bucket এখানে ধারণা বোঝানোর জন্য। Cloud-এর rate-based rule প্রায়ই নির্দিষ্ট সময়-জানালায় অনুরোধ গোনে, আর সিদ্ধান্ত নিতে কিছুটা দেরি হয়। AWS WAF-এ লেখার সময়ে জানালা ১ থেকে ১০ মিনিটের। তাই অল্প সময়ের ঝাঁক সেখানে অনেক সময় ধরা পড়ে না। API gateway আর Nginx-এর limit_req (leaky bucket) আরও সূক্ষ্মভাবে থামাতে পারে। পূর্ণ সুরক্ষায় edge আর app দুই জায়গাতেই সীমা রাখুন।

Bot — সব bot শত্রু নয়

Traffic-এর একটি বড় অংশ মানুষের নয়। Search engine-এর crawler আপনার দরকার। দাম-তুলনার bot নিয়ে মত ভিন্ন হতে পারে। চুরি যাওয়া password নিয়ে লগইন-চেষ্টা বা ছাড়ের পণ্য লুটে নেওয়া bot ক্ষতিকর। Bot management সেবাগুলো এদের আলাদা করতে চায়। ব্যবহার করে আচরণ, TLS-এর ধরন, JavaScript challenge আর পরিচিত bot-এর তালিকা। AWS WAF Bot Control, Azure-এর bot rule আর Cloud Armor-এর reCAPTCHA সংযোগ এর উদাহরণ।

দুটি সতর্কতা। robots.txt শুধু অনুরোধ, প্রহরী নয়। আর CAPTCHA প্রতিবন্ধী ব্যবহারকারী আর ধীর network-এ ভোগায়, তাই শুধু সন্দেহজনক অনুরোধে দিন। Bot ঠেকানোর সবচেয়ে কাজের সঙ্গী সেবাটি নিজে নয়, বরং ব্যবসার যুক্তি: এক অ্যাকাউন্টে কতগুলো ছাড়ের পণ্য, আর একটি নম্বরে কতগুলো OTP.

৮ · DDoS — তিন স্তর, আর কে কোনটি সামলায়

DDoS মানে Distributed Denial of Service: বহু উৎস থেকে একসাথে এত চাপ, যাতে আসল ব্যবহারকারী সেবা না পান। এখানে আমরা শুধু প্রতিরক্ষার দিক দেখব। মূল প্রশ্ন একটিই: চাপটি কোন জায়গা ভরে ফেলতে চায়?

লক্ষ করুন, ওপর থেকে নিচে নামলে দায় provider থেকে আপনার দিকে সরে। এটিই shared responsibility. L7-এর অনুরোধ দেখতে বৈধ, তাই আপনার অ্যাপের কোন path দামি, তা provider জানে না।

তিন provider-এ লেখার সময়ের ছবি মোটামুটি এই। AWS Shield Standard L3/L4 সুরক্ষা স্বয়ংক্রিয়ভাবে দেয়, আর Shield Advanced একটি paid স্তর, যাতে বাড়তি সাহায্য ও খরচ-সুরক্ষার সুবিধা আছে। Azure DDoS Protection-এর ভিত্তি-সুরক্ষার ওপরে paid স্তরে VNet-এর public IP-র জন্য বাড়তি নীতি আর মাপজোখ মেলে। L7-এর জন্য Azure WAF লাগে। Google Cloud Armor external Application LB-র সামনে L3/L4 সুরক্ষা দেয়, আর নিরাপত্তা নীতিতে L7-এর rule চলে। শর্ত আর দাম বদলায়, তাই docs মিলিয়ে নিন।

আক্রমণের সময় autoscaling — বিলের হিসাব

পর্ব ১৭-এ দেখেছেন, চাপ বাড়লে autoscaling server বাড়ায়। L7 চাপেও সে তাই করবে। সে তো ভালো-মন্দ চেনে না। ধরুন cache না হওয়া একটি search path-এ ৬ ঘণ্টা ধরে সেকেন্ডে ৫,০০০ অনুরোধ এলো। প্রতিটি server ১০০ req/s নেয়, স্বাভাবিক সময়ে ৪টি চলে, উত্তর ২০০ KB. ধরে নেওয়া দাম: server ঘণ্টায় $০.১০, egress GB-তে $০.০৮, WAF-এর পরীক্ষা ১০ লাখে $০.৫০।

দুটি শিক্ষা। প্রথমত, এখানে বিলের বড় অংশ server নয়, bandwidth. দ্বিতীয়ত, WAF-এর পরীক্ষার টাকা থেকেই যায়, কারণ আটকাতেও পড়তে হয়। এই ধরনের ক্ষতির একটি নাম আছে: economic denial of sustainability. সেবা বন্ধ হয় না, কিন্তু বিল সহ্যের বাইরে চলে যায়।

• Autoscaling-এর max রাখুন। এটি বিলের ছাদ, তবে ছাদে পৌঁছালে সেবা ধীর হবে। ব্যবসার সাথে কথা বলে সংখ্যাটি ঠিক করুন।
• Serverless-এ concurrency-র সীমা রাখুন। প্রতিটি call-এ টাকা, তাই সীমা না থাকলে খরচও সীমাহীন (পর্ব ৬৯)।
• Budget alert খরচ থামায় না। শুধু জানায়। তাই request rate আর egress-এর আলাদা alert রাখুন।
• আগেই অনুশীলন করুন। Runbook-এ লিখুন: কে সিদ্ধান্ত নেবেন, কোন rule আগে কড়া হবে, cached পাতা দেখানো যাবে কি না, provider-এর সাহায্য কীভাবে চাইবেন। আপনার সিস্টেমে চাপ পরীক্ষা করতে চাইলে provider-এর নিয়ম মানুন। অন্যের সিস্টেমে কখনোই নয়।

৯ · Edge function, log আর খরচ

Edge function — এবং তার সীমা

Edge function হলো edge-এ চলা ছোট প্রোগ্রাম। Edge computing-এর এটিই সবচেয়ে পরিচিত রূপ। Redirect, header বদলানো, cache key স্বাভাবিক করা, token-এর সহজ যাচাই আর A/B পরীক্ষার ভাগ এখানে ভালো মানায়। উদাহরণ: CloudFront Functions, Lambda@Edge, Cloudflare Workers, Fastly Compute. Azure Front Door-এ অনেক কাজ rule engine দিয়ে হয়।

// Example: not runnable here. Adds security headers on the way back to the viewer.
function handler(event) {
  var response = event.response;
  response.headers['strict-transport-security'] = { value: 'max-age=63072000; includeSubDomains' };
  response.headers['x-content-type-options'] = { value: 'nosniff' };
  return response;
}

Edge সব কাজের জায়গা নয়। সীমাগুলো জেনে নিন:

• সময় আর আকার ছোট। CPU সময়, memory আর কোডের আকারের কড়া সীমা থাকে। হালকা ধরনে network call-ও নিষেধ হতে পারে। সংখ্যাগুলো পণ্যভেদে আলাদা।
• ডেটা কাছে নেই। Database এক region-এ থাকলে edge থেকে প্রতিটি query দূরে যায়। তখন edge-এ কোড চালিয়ে উল্টো দেরি বাড়ে।
• Debug কঠিন। Log অনেক জায়গায় ছড়ানো। ভুল rollout সব edge-এ পৌঁছায়। তাই staging distribution আর ধীরে ছাড়া দরকার।
• প্রতি অনুরোধে টাকা। সব অনুরোধে function চালালে বিল আর latency দুটোই বাড়ে। শুধু দরকারি path-এ লাগান।

Log — কী হচ্ছে, তার একমাত্র সাক্ষী

CDN-এর access log বলে কোন edge, কোন path, hit না miss, কত byte. WAF log বলে কোন rule, কোন action. নিচের Bash block একটি নমুনা log থেকে দুই রকম hit ratio, origin-এ ফেরা path আর status-এর ভাগ বের করে। সব ডেটা block-এর ভেতরেই বানানো।

set -euo pipefail
log=$(mktemp)
# fields: time edge status result bytes path (sample data)
cat > "$log" <<'EOF'
10:00:01 EDGE-A 200 Hit 48000 /css/app.7d2e40.css
10:00:01 EDGE-A 200 Hit 900000 /img/banner.webp
10:00:02 EDGE-B 200 Miss 900000 /img/banner.webp
10:00:02 EDGE-A 200 Hit 48000 /css/app.7d2e40.css
10:00:03 EDGE-A 200 Miss 3000 /index.html?utm_source=fb
10:00:03 EDGE-A 200 Miss 3000 /index.html?utm_source=wa
10:00:04 EDGE-B 200 Hit 900000 /img/banner.webp
10:00:04 EDGE-A 200 Miss 3000 /index.html?utm_source=sms
10:00:05 EDGE-A 200 Hit 48000 /css/app.7d2e40.css
10:00:05 EDGE-B 502 Error 0 /api/cart
10:00:06 EDGE-A 403 Blocked 150 /api/login
10:00:06 EDGE-A 200 Hit 900000 /img/banner.webp
10:00:07 EDGE-B 200 Hit 48000 /css/app.7d2e40.css
10:00:07 EDGE-A 200 Hit 900000 /img/banner.webp
EOF

echo "== hit ratio by requests and by bytes"
awk '$4=="Hit"{h++; hb+=$5} {n++; b+=$5}
END {printf "requests %d, hit %d (%.0f%%)\n", n, h, 100*h/n
     printf "bytes hit %.0f%%\n", 100*hb/b}' "$log"

echo "== what goes back to the origin"
awk '$4=="Miss"{print $6}' "$log" | cut -d'?' -f1 | sort | uniq -c | sort -k1,1nr

echo "== status by result"
awk '{print $3, $4}' "$log" | sort | uniq -c | sort -k1,1nr

rm -f "$log"

== hit ratio by requests and by bytes
requests 14, hit 8 (57%)
bytes hit 81%
== what goes back to the origin
      3 /index.html
      1 /img/banner.webp
== status by result
      8 200 Hit
      4 200 Miss
      1 403 Blocked
      1 502 Error

Log-এ ব্যক্তিগত তথ্য থাকতে পারে: IP, URL-এর query, cookie. Authorization আর Cookie header WAF log থেকে বাদ দিন (redaction), মেয়াদ ঠিক করুন, আর অনুমতি সীমিত রাখুন। প্রতিদিন যে সংখ্যাগুলোয় চোখ রাখবেন: hit ratio, edge-এর 4xx আর 5xx, origin-এর latency, WAF-এর block, আর egress.

বিলের খাত

এক শর্ত সবসময় মনে রাখুন: কোনো egress-এর দাম নির্দিষ্ট নয়। ফ্রি-টিয়ার আর চুক্তি provider-ভেদে আলাদা। আপনার traffic দিয়ে হিসাব করুন। পর্ব ৭৩-এ FinOps-এ বিস্তারিত দেখবেন।

১০ · AI-এর যুগে edge config যাচাই

AI একটি distribution বা WAF rule কয়েক সেকেন্ডে লিখে দেয়। কিন্তু edge-এর ভুল সব ব্যবহারকারীর ওপর একসাথে পড়ে। আর ভুলটি প্রায়ই চুপচাপ থাকে: সাইট চলছে, শুধু অন্যের পাতা অন্যজন দেখছেন, বা origin খোলা পড়ে আছে।

AI-এর দেওয়া edge config হাতে পেলে — যাচাইয়ের চেকলিস্ট

• terraform plan পড়েছি, কোনো অপ্রত্যাশিত replace বা destroy নেই
• প্রতিটি argument official docs-এ মিলিয়েছি
• ডিফল্ট behaviour-এ cache বন্ধ, আর cookie-সহ কোনো পাতা cache হচ্ছে না
• দুটি আলাদা account দিয়ে দেখেছি, কেউ অন্যের তথ্য পাচ্ছে না
• সরাসরি origin-এ curl ব্যর্থ হয়, আর bucket public নয়
• সব WAF rule আগে count-এ ছিল, log পড়েছি, ফেরার পথ আছে
• Certificate-এর validation record আছে, আর মেয়াদের alert রাখা হয়েছে
• কোনো secret config-এ বা prompt-এ নেই
• Budget alert আর request rate-এর alert দুটোই আছে