Six ways to deploy Cloudflare, one diagram each
Common deployment topologies, from a standard front door for an AWS origin to multi-region load balancing, private access, API security, and log delivery into Splunk and Microsoft Sentinel. One line and one diagram per pattern.
Standard app to an AWS ALB origin
Cloudflare sits in front of a single AWS origin, handling DNS, TLS, DDoS, WAF and caching at the edge, with the origin locked down so clients cannot bypass Cloudflare and reach the ALB directly.
Multi-region with Cloudflare Load Balancing
Cloudflare steers traffic across health-checked application pools in two AWS regions and fails over automatically, provided the health monitors reflect real ability to serve rather than a non-critical dependency.
Private admin via Tunnel and Access
An admin application with no public ingress is reached through an outbound-only cloudflared tunnel, with Cloudflare Access enforcing identity, group, MFA and device posture before any connection is allowed.
API security deployment
Edge controls (DDoS, WAF, rate limiting, bot signals and API Shield with mTLS, JWT and schema validation) protect an AWS API origin, while the application still enforces authorisation, because a valid JWT proves the token, not the user’s right to the object.
Cloudflare to Splunk
Cloudflare datasets stream by direct Logpush into Splunk HEC as JSON, landing in an index that feeds dashboards, correlation and detections.
Cloudflare to Microsoft Sentinel
Cloudflare Logpush writes to an Azure Blob container that the Cloudflare connector ingests into Sentinel, where the logs drive analytics rules, workbooks, hunting and automation playbooks.
