Experiment #3 — AWS EC2 + Cloudflare Tunnel + Cloudflare Security

1. Objective of the Experiment

This experiment explores an alternative architecture where Cloudflare replaces CloudFront and AWS WAF entirely, acting as:

• reverse proxy,
• CDN layer,
• security layer (WAF, bot filtering),
• ZTNA provider (Cloudflare Access),
• and optionally the DNS authority.

The goal was to evaluate whether Cloudflare could simplify the stack, reduce costs, and improve the security of a WordPress site — while keeping the EC2 instance completely invisible to the public internet through Cloudflare Tunnel.

2. Context and Technical Constraints

Architectural Motivation

After finding the AWS-native setup heavy and costly, I wanted to test a radically different approach:

• Hide EC2 behind a Cloudflare Tunnel,
• Let Cloudflare handle TLS, caching, WAF, ZTNA,
• Eliminate origin exposure entirely,
• Remove the cost of AWS WAF and reduce CloudFront complexity,
• Use Cloudflare’s generous free plan to bring overall cost down.

Security Requirements

• EC2 must be completely non-public (no public IP reachable).
• Admin access to /wp-login.php and /wp-admin must be restricted.
• Bot attacks and brute-force attempts must be eliminated.
• No origin bypass must be possible.

Functional Requirements

• Same performance (or better) than CloudFront.
• Seamless WordPress operation.
• No breaking of dynamic features or admin interface.
• Ability to use AWS Lambda@Edge for dynamic image resizing.

Cost Requirements

• Keep Cloudflare usage within the free plan (Access + Tunnel + CDN).
• Avoid additional AWS charges for traffic or WAF.
• Keep infrastructure lean (just EC2 + EBS).

Maintenance Requirements

• Minimal admin involvement.
• No complicated multi-service AWS configuration.
• Ideally simpler than the CloudFront/WAF setup.

Architecture Overview — EC2 Hidden Behind Cloudflare Tunnel

flowchart TD
  User["User / Browser"] --> CFEdge["Cloudflare Edge\nCDN + WAF + Cache"]
  CFEdge --> CFAcc["Cloudflare Access\nZTNA / IdP Login"]
  CFAcc --> Tunnel["Cloudflare Tunnel\nOrigin Connector"]
  Tunnel --> EC2["EC2 Instance\nWordPress + PHP + Web Server"]
  EC2 --> EBS["EBS Volume\nWordPress Files"]

  DNS["Cloudflare DNS\nZone & Records"] -.-> CFEdge

  Admin["Admin / Ops"] --> CFAcc
  Admin --> Tunnel

  %% Styles
  classDef edge fill:#eef2ff,stroke:#0f766e,stroke-width:1px,color:#111;
  classDef origin fill:#ecfeff,stroke:#0369a1,stroke-width:1px,color:#111;
  classDef dns fill:#fef9c3,stroke:#d97706,stroke-width:1px,color:#111;
  classDef mgmt fill:#fee2e2,stroke:#b91c1c,stroke-width:1px,color:#111;

  class CFEdge,CFAcc,Tunnel edge;
  class EC2,EBS origin;
  class DNS dns;
  class Admin mgmt;

Figure A — WordPress origin fully hidden behind Cloudflare Tunnel, with DNS, CDN, WAF and ZTNA handled at Cloudflare edge.

3. Architecture Tested

3.1. Components in This Setup

• Cloudflare Tunnel

  • Originless architecture.
  • EC2 is never exposed to the public internet.

• Cloudflare CDN

  • Edge caching similar to CloudFront.

• Cloudflare Access (ZTNA)

  • Used to protect WordPress admin endpoints.

• Cloudflare DNS

  • Required for optimal integration (though this introduced issues).

• EC2 instance

  • WordPress + PHP + Nginx/Apache.
  • No public traffic.

3.2. Infrastructure Security (AWS Architecture)

• EC2 has no public ingress at all.
• Security Groups restricted only to Cloudflare Tunnel connector.
• SSM access for administration (no SSH).
• TLS fully offloaded to Cloudflare.
• No need for CloudFront, AWS WAF, ACM, or ELB.

This significantly reduced AWS-side complexity and attack surface.

3.3. Application Security (WordPress Layer)

Cloudflare provided multiple layers of protection:

1. Cloudflare Access (ZTNA)

• Added authentication before reaching WordPress admin.
• Very strong protection: email-based, identity-based, or OAuth-based.
• Prevented brute-force attacks entirely.

2. Cloudflare WAF + Bot Management

• Blocked malicious crawlers.
• Reduced attack noise dramatically.
• But: “Bot Fight Mode” and other aggressive filters often broke WordPress admin.

3. Cloudflare Tunnel isolation

• Only Cloudflare edge nodes can reach the origin.
• Removes the possibility of direct attacks on the EC2 IP.

3.4. High-Level Traffic Flow

1. Visitor reaches Cloudflare HTTPS endpoint.
2. Cloudflare applies:
   • DNS steering,
   • WAF rules,
   • Bot filtering,
   • ZTNA (if accessing admin).
3. Cloudflare Tunnel connects to the EC2 origin.
4. WordPress generates the response.

3.5. Technical Observations

1. Cloudflare Tunnel setup is not “plug and play”

Despite being marketed as simple:

• the configuration takes time,
• you must install + run the connector,
• you must handle authentication and routing,
• debugging can be painful if the tunnel drops.

And if the tunnel goes down, the site is completely offline.
There is no graceful fallback.

2. Migrating all DNS to Cloudflare is painful

This was a major operational drawback:

• Large and complex DNS zones (e.g. Microsoft 365 records) require careful migration.
• AWS services like:
  • ACM certificate validation,
  • S3 static websites,
  • CloudFront alternate domains
    become harder to manage when DNS is external.
• Cloudflare’s DNS UI is powerful but extremely crowded.

Cloudflare DNS migration is not trivial for multi-service environments.

3. No noticeable speed difference vs CloudFront

Contrary to expectations:

• performance was equivalent to CloudFront,
• sometimes slower due to Tunnel overhead simulation,
• dynamic requests saw no improvement.

4. WordPress compatibility issues

Especially:

• Cloudflare bot challenges breaking /wp-admin,
• forced security headers conflicting with WordPress login flow,
• caching accidentally applied to dynamic admin pages.

5. AWS Lambda functions (image resizing) became painfully slow

Dynamic image resizing via Lambda@Edge completely collapsed performance, even behind Cloudflare.

This architecture amplified AWS Lambda cold-start and routing latency.

6. Cloudflare UI changes constantly

The dashboard suffers from:

• frequent UI redesigns,
• features moved daily,
• unintuitive navigation,
• inconsistent configuration workflows.

Comparable to “the best of Microsoft 365” — in an ironic sense.

7. Cloudflare downtime = total downtime

Since Cloudflare Tunnel is the network,
there is no origin failover.

If Cloudflare has an outage, everything disappears instantly.

4. Results and Analysis

4.1. Pros

• EC2 fully hidden from the public internet.
• Excellent ZTNA via Cloudflare Access.
• Cloudflare costs = zero (free plan).
• Strong WAF and bot mitigation (when tuned).
• No AWS WAF fees and no CloudFront complexity.
• Simple origin architecture (just EC2 + EBS).

4.2. Cons

• Cloudflare Tunnel is a single point of failure.
• DNS migration is complex and risky for multi-service environments.
• Bot protection frequently breaks WordPress admin.
• No performance improvement over CloudFront.
• Dynamic image resizing via AWS Lambda becomes extremely slow.
• Cloudflare’s UI is chaotic, constantly changing, and unintuitive.
• Cloudflare outage = complete outage.
• Some WordPress plugins/themes still behave unpredictably behind a Tunnel.

4.3. Cost Analysis

• Cloudflare: free plan (Tunnel, Access, CDN, WAF).
• EC2: CHF 8–12
• EBS: CHF 1–3
• No AWS WAF: saves ~CHF 20–25/month
• CloudFront not used: saves extra CHF 1–15/month

Total: ~CHF 10–15 per month (depending on EC2 size)

This is by far the cheapest experiment so far.

5. Conclusion

The Cloudflare Tunnel architecture brings exceptional security (ZTNA, invisible origin, strong WAF) and the lowest cost of all experiments.

But it also introduces several major drawbacks:

• operational complexity,
• DNS migration headaches,
• compatibility issues with WordPress and AWS features,
• tunnel fragility,
• performance neutrality vs CloudFront,
• Cloudflare UI instability,
• and the risk of total outage if Cloudflare goes down.

For small sites, it can work — but it is not “set and forget.”
For environments using AWS services heavily, it becomes difficult to manage.

The next article will explore the more advanced (and more AWS-aligned) architecture: EC2 + ALB + CloudFront + WAF, and whether it offers a better balance between security, performance, and maintainability.