Serverless Exits Still Leave Fingerprints: Reading cloud_service on IP99

Serverless and cloud-function platforms share egress. Your webhook, cron, or Lambda-style worker can look identical on the wire to someone else's — same ASN, same hosting NAT. Blanket-blocking every IDC address hits honest automation and still misses most proxy supply. On IP99 by ThreatHunter, cloud_service names something narrower: a cloud function / serverless egress observed as a risk tag — not "any hosting IP," not a commercial VPN static exit, and not a cloud-phone farm.

This walkthrough stays on free, no-key GET /v1/ip/{ip}. JSON samples below are documented product shapes from IP99 docs and prior verified captures — run the curls yourself for a live snapshot. We do not invent a sample IP that carries cloud_service; the official slug meaning and triage order are enough. Notes: IP99, API, detect proxy / VPN, proxy exits.

What cloud_service is (and what it is not)

IP99's free lookup returns a 0–100 risk.score for freshness and strength of verifiable risk evidence, not attacker probability. risk.level follows the score (0 → none, 1–29 → low, 30–69 → medium, 70–100 → high). Signals appear only when they hit. Always branch on evidence_state (active / stale / none) before the score: score 0 + none is a coverage gap, not a clean bill of health.

Tags that matter here:

slug	Meaning	Typical disposition
cloud_service	Cloud function / serverless egress (risk tag)	Shared egress — step-up / velocity; do not assume one human
cloud_phone	Cloud phone (handset / farm device in a datacenter)	Different pattern; do not conflate with serverless
proxy	Address currently used as a proxy exit	Step-up or block by business cost
vpn	Static commercial VPN exit	Product decision; often step-up, not refuse
dialup_pool	Dial-up / redial rotation pool	Supply-side rotation (often DYN/MOB)
hosting / mobile	Network attributes	Not risk verdicts alone
crawler	Search crawler egress	Benign; does not score

Official API / OpenAPI wording: cloud_service = a cloud function / serverless egress. It is a risk signal from observed evidence, not from "looks like AWS." Hosting alone never puts cloud_service in risk.signals.

Brief contrast with cloud_phone (earlier article): a cloud phone is a handset / farm device remoted for bulk signup; serverless egress is function/worker infrastructure sharing a cloud NAT. Same IDC neighborhood sometimes — different signal, different response. Do not reuse a cloud-phone ban for every Lambda customer.

False equivalents:

1. hosting on IDC ≠ cloud_service. Public DNS and ordinary VMs sit in hosting space every day with score 0.
2. proxy / vpn / dialup_pool ≠ serverless. Residential rotation, commercial VPN static exits, and dial-up pools are different supply classes.
3. crawler is benign and does not score — do not fold it into a serverless block.

Free /v1/ip does not return share_tier (Pulse only). On free tier, lean on evidence_state, score/level, signal type, usage_type, plus your own velocity / device checks.

Documented contrast: hosting attribute vs IDC proxy vs residential supply

curl https://ip99.com/v1/ip/8.8.8.8

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-09T10:22:26Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "country": "US",
    "region": "California",
    "city": "Mountain View",
    "tz": "America/Los_Angeles"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  }
}

hosting here is a network attribute on public DNS. evidence_state: none with score 0 means no verifiable proxy-class evidence on file — not "safe," and not cloud_service. "Block all IDC" would refuse this address for the wrong reason.

Now a Paris datacenter address with proxy evidence (contrast: proxy on IDC, not cloud_service):

curl https://ip99.com/v1/ip/178.20.30.146

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "178.20.30.146",
  "computed_at": "2026-10-09T10:23:02Z",
  "evidence_state": "active",
  "geo": {
    "continent": "EU",
    "country": "FR",
    "region": "Île-de-France",
    "city": "Paris",
    "tz": "Europe/Paris"
  },
  "network": { "asn": 46475, "usage_type": "IDC" },
  "risk": {
    "score": 99,
    "level": "high",
    "signals": ["hosting", "osint", "proxy"]
  }
}

Same IDC + hosting neighborhood many serverless exits share, but the matched slug here is proxy (plus osint), not cloud_service. Branch on the matched signal, not on "looks like a datacenter."

Most new proxy supply is not in that IDC slice. API docs demo for a residential proxy egress:

curl https://ip99.com/v1/ip/86.111.136.23

Documented product sample (API docs demo): score 86, level high, signals ["proxy"], usage_type DYN, ASN 15547, geo CH / Valais / Sitten. Re-curl for a live snapshot — scores decay with evidence age.

What the weekly capture mix says

Between 31 October – 6 November 2026 (UTC), IP99 captured 10,653,453 new proxy-class exit addresses (±0% WoW). By usage type: ~79% residential (8,410,793 / 78.9%), 12.4% mobile, 4.1% gateway/NAT, 3.7% datacenter (391,549). 58 upstream sources. Source: proxy-exits. Aggregates only; no address lists.

Most new proxy supply is not datacenter/serverless space. Blocking only IDC under-covers residential exits that dominate the feed, while over-punishing legitimate cloud workers that share those ranges without a cloud_service (or other risk) hit.

A practical branch (evidence_state first)

Official triage order: evidence_state → score/level → signal type → usage_type. Generic guidance (not a contract): score 0 → do not stamp "clean"; 1–29 → observe; 30–69 → captcha / throttle / second factor; 70–100 → block only when business cost allows. Score meaning: IP risk score.

1. Read evidence_state (active / stale / none).
2. Read risk.signals and network.usage_type.
3. If cloud_service is present and evidence_state is active:
     - Treat as shared cloud-function / serverless egress.
     - Do NOT assume a single human behind the IP.
     - Prefer step-up + velocity / device / session binding over refuse.
     - Do NOT hard-ban every customer whose traffic happens to leave via a public cloud NAT.
4. Else if hosting on IDC WITHOUT cloud_service / proxy / vpn / dialup_pool:
     - Network attribute only — do not invent a serverless verdict.
5. Else if cloud_phone (active):
     - Different playbook (device-farm pattern) — do not reuse as "Lambda ban."
6. Else if proxy / dialup_pool on DYN or MOB:
     - Residential / mobile proxy supply — different from serverless.
7. Never mark score 0 + evidence_state none as "trusted clean."
8. Re-query at decision time; do not cache a cloud_service verdict for days.

Anonymous quota is 500 lookups/day per client IP (60/min); a free logged-in key raises the daily cap to 5,000/day. Check remaining with GET https://ip99.com/v1/me or the X-Daily-* headers. OpenAPI: https://ip99.com/openapi.json. Pricing: https://ip99.com/en/pricing.

Do not treat IP99 scores as identical to other ThreatHunter datasets — this article only claims what free /v1/ip and the cited English product pages / OpenAPI document.

Try it

curl https://ip99.com/v1/ip
curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip/178.20.30.146
curl https://ip99.com/v1/ip/86.111.136.23
curl https://ip99.com/v1/me

IP99 is a ThreatHunter product. Use the free lookup to separate serverless / cloud-function egress (cloud_service) from ordinary hosting, commercial VPN exits, residential proxy supply, and cloud-phone farms — before a blanket IDC ban hits legitimate automation. Start at https://ip99.com; read detect proxy / VPN, proxy exits, and https://ip99.com/api.