Transitioning from Data Center to Cloud: How Atlassian's Edge Security Stack Fills the Gap Left by Cloudflare
Mihai Perdum
Author
10 min readFebruary 13, 2026
Why This Matters for Every Data Center Migration
When your organization runs Jira, Confluence, and JSM on Data Center with Cloudflare sitting in front of your instances, you control everything — the WAF rules, the DDoS thresholds, the rate limiting policies, the geo-blocking, the TLS configuration. You built that stack, you tuned it, and you trust it. So when someone says "we're moving to Atlassian Cloud," the first question from your security team isn't about data residency or SSO. It's this: what happens to Cloudflare?
The answer is simultaneously reassuring and uncomfortable. Atlassian Cloud replaces Cloudflare with a fully managed AWS-native security stack — Amazon CloudFront for CDN, AWS WAF for application-layer firewalling, and AWS Shield Advanced for DDoS protection across L3/L4/L7. The stack is enterprise-grade, always-on, and tuned specifically for Atlassian's products. The uncomfortable part? You can't touch it. You can't add custom WAF rules, you can only restrict by country through an IP allowlist, and you can't place your own CDN or proxy in front of it.
This isn't a limitation born from laziness — it's an architectural decision that comes with real trade-offs. Understanding those trade-offs is what this post is about.
The AWS-Native Edge Stack: CloudFront, WAF, and Shield Advanced
Three layers you do not run and do not pay for separately, sitting in front of the tenant.
Amazon CloudFront: Your New CDN
Atlassian completed a strategic migration to AWS-native edge services around 2023, replacing what had previously been a patchwork of off-the-shelf products and internally developed solutions. This isn't speculation — it's confirmed in an AWS case study featuring Ben McAlary, Atlassian's Principal Network Engineer.
Amazon CloudFront now serves as the CDN and front door for all Atlassian Cloud products — Jira, Confluence, JSM, Bitbucket, Trello, and Loom. Static assets like JavaScript, CSS, images, and fonts are cached at CloudFront's global edge locations. Atlassian's own documentation states that they use CloudFront CDN to deliver webpage assets to browsers.
What makes this implementation interesting is how Atlassian uses CloudFront Functions for custom origin routing. Traffic gets directed to the correct data residency region without costly cross-region hops. The results are concrete: a 50% reduction in cross-region data transfer costs and a 20% improvement in page load times for users in distant geographies like Brazil and South Africa.
For enterprise firewall teams, one critical detail: Atlassian uses Anycast static IPs for CloudFront — three unique IP addresses identifying Jira and Confluence products. This matters because your network team needs stable, predictable IPs for allowlisting, and Atlassian delivers exactly that.
AWS WAF: The Application-Layer Firewall
AWS WAF sits on the CloudFront distributions, inspecting all HTTP/HTTPS traffic before it reaches origin infrastructure. Atlassian didn't just flip on the default AWS managed rules and call it a day — they built a custom rule set that was reviewed and improved by AWS, who provided eight specific recommendations for tuning.
The scale of what this WAF handles is significant. According to McAlary, every hour of every day, Atlassian sees hundreds of thousands of malicious or inauthentic requests blocked by AWS WAF. The protection covers the OWASP Top 10, rate-based rules, IP reputation blocking, and custom rules tuned for Atlassian-specific patterns. That last point matters — Atlassian had to account for scenarios like Jira tickets that contain JavaScript code snippets, which a generic WAF rule would flag as an XSS attempt.
Atlassian is also actively creating proofs of concept for AWS WAF Bot Control and the L7 Anti-DDoS Amazon Managed Rule. These aren't in production yet, but they signal the direction of the platform's edge security evolution.
AWS Shield Advanced: DDoS Across All Layers
AWS Shield Advanced provides DDoS mitigation across Layers 3, 4, and 7. This is the premium tier of AWS's DDoS service — not the free Shield Standard that every AWS customer gets by default.
What does this mean in practice? Protection against volumetric network floods like UDP reflection and TCP SYN floods at L3/L4, protocol-level attacks, and application-layer DDoS at L7. Atlassian gets 24/7 access to AWS's Shield Response Team, automatic application-layer mitigation via rate-based WAF rules, proactive engagement when Shield detects health-impacting events, and DDoS cost protection so that attack-driven traffic spikes don't generate surprise bills.
The system has been tested at scale. Attacks reaching hundreds of millions of requests have been mitigated by this stack. For context, that's the kind of volumetric attack that would require significant Cloudflare Enterprise features to handle on your own Data Center deployment.
The Capability Mapping: Cloudflare vs. Atlassian Cloud
Here's the direct mapping your technical team needs:
The pattern is clear: every Cloudflare capability has a functional equivalent, but almost none of them are customer-configurable. This is the fundamental trade-off of moving to a SaaS platform.
API Rate Limiting: Deeper Than You'd Expect
One area where Atlassian Cloud actually provides more sophisticated protection than most Cloudflare configurations is API rate limiting. Atlassian enforces rate limiting at both the edge layer via AWS WAF and the application layer, with a multi-dimensional system that goes well beyond simple request counting.
Three Independent Rate Limiting Mechanisms
Jira and Confluence Cloud enforce three rate limiting mechanisms simultaneously.
Points-based hourly quotas assign a cost to each API call based on complexity. A simple issue GET costs 2 points, while fetching 8 group members costs 17 points. Default quotas start at 65,000 points per hour in a global pool (Tier 1), with per-tenant pools available after Atlassian review that scale from 100,000 to 150,000+ points per hour depending on plan tier, capped at 500,000 points per hour. New points-based enforcement begins March 2, 2026, for Forge, Connect, and OAuth 2.0 apps — if your client has integrations, this date matters.
Per-second burst rate limits use a token bucket algorithm. Defaults are 100 requests per second for GET and POST, 50 requests per second for PUT and DELETE. Some endpoints have custom limits — JSM's customer endpoint is limited to just 5 RPS, while some Confluence endpoints allow up to 500 RPS.
Per-issue write limits cap operations at 20 per 2 seconds and 100 per 30 seconds, preventing runaway automation from hammering individual issues.
JSM's Assets REST API has its own distinct limits: 1,000 requests per minute per endpoint per instance, with a total cap of 10,000 requests per minute per instance.
Rate Limit Response Headers
When limits are hit, Atlassian provides actionable response headers: X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After, and a RateLimit-Reason header specifying exactly which limit was triggered — values like jira-quota-global-based, jira-burst-based, or jira-per-issue-on-write. When quotas are exhausted, all API requests are blocked until the hourly window resets. There is no partial throttling or graceful degradation — it's a hard cutoff.
For teams migrating from Data Center where Cloudflare handled rate limiting externally, this is actually more granular than what most organizations configure themselves. The trade-off is that you can't adjust these limits — they're Atlassian's limits, not yours.
SSL/TLS: Entirely Atlassian-Managed
Browser TLS terminates at the edge: on the wire, CloudFront takes the connection (the certificate is issued by Amazon and responses carry via: CloudFront), with Atlassian's own edge service behind it identifying itself as server: AtlassianEdge. Customers have zero configuration control over TLS settings.
The minimum supported version is TLS 1.2, with TLS 1.3 supported for several years. Atlassian has no plans to deprecate TLS 1.2. All remaining cipher suites use AEAD encryption (GCM or ChaCha20), SHA-256+ hashing, and ECDHE key exchange providing Perfect Forward Secrecy. The nine supported cipher suites break down as follows:
TLS 1.2 suites: Six ECDHE suites with RSA or ECDSA using AES-GCM or ChaCha20
CBC-mode ciphers, SHA-1, non-PFS suites, and DHE-RSA suites were all deprecated by mid-2024. Customers cannot bring their own certificates. For custom domains — now available for Jira, Confluence, and JSM — Atlassian provisions certificates via AWS Certificate Authority. No certificate pinning is implemented for browser access.
One important note for organizations using TLS inspection proxies: Atlassian explicitly acknowledges that TLS/HTTPS inspection proxies can be used with their services, but they recommend skipping TLS inspection on *.atl-paas.net domains for performance. TLS inspection proxies cause HTTP/2-to-HTTP/1.1 protocol downgrades, which Atlassian warns significantly degrade the performance of modern web applications.
Customer-Configurable Controls: What You Actually Get
This is the section your security team will scrutinize most carefully. The migration to Atlassian Cloud means accepting a fundamentally different security model — one where you rely on Atlassian's managed stack plus a focused set of admin controls rather than building and tuning your own.
IP Allowlisting: The Primary Network Control
IP allowlisting is the most significant customer-configurable network control in Atlassian Cloud. Available on Premium and Enterprise plans, it supports up to 500 IP addresses, CIDR blocks or countries per application. Atlassian started rolling out countries as a location type in February 2026, so where your org has it the same allowlist doubles as a country-level restriction. Configuration lives at admin.atlassian.com > Security > Device Security > IP allowlists. This restricts both web UI and REST API access at the site level — users outside allowed IPs receive explicit rejection messages.
There are important caveats. IP allowlisting does not cover admin.atlassian.com itself — organization-level settings remain accessible regardless of IP restrictions. Some metadata like issue and page titles may still be accessible through certain interfaces even with IP allowlisting enabled.
What You Cannot Configure
This list is what will generate the most questions from your client's security team:
Custom WAF rules — not available in any form
Custom HTTP security headers (CSP, X-Frame-Options, HSTS) — Atlassian-managed only
Geo-blocking — only by allowing countries in an IP allowlist, there's no rule to block a specific country
TLS version or cipher suite preferences — Atlassian chooses
CDN cache behavior — though Atlassian support can disable the CDN for Jira and Confluence on request (not for user management)
DDoS thresholds or response policies — Atlassian and AWS manage these entirely
Custom error pages — not available
Page rules or redirect logic — not available
If your client currently uses Cloudflare Page Rules, Workers, or custom WAF rulesets extensively, those capabilities have no equivalent in Atlassian Cloud. The security model shifts from "we configure everything" to "Atlassian configures the infrastructure, we configure identity and data governance."
Atlassian Guard: Identity and Data — Not Network Security
Atlassian Guard (Standard and Premium) fills the identity and data governance gap but provides zero network-level security features. This is important to understand because it's often positioned as the "security product" for Atlassian Cloud, and teams sometimes assume it covers the WAF/DDoS/CDN layer. It doesn't.
Guard Standard ($4/user/month, free with Enterprise plans) delivers enforced SAML SSO, SCIM provisioning, 2FA enforcement, session controls, API token management, and organization audit logs.
Guard Premium ($8/user/month, add-on) adds AI-driven anomalous activity detection, data classification, sensitive data scanning for credit cards, API tokens, and SSNs, SIEM integration via webhooks, and suggested remediation workflows.
Both tiers are valuable — but neither touches the WAF, DDoS, or CDN layer. Guard is about who accesses your data and what they do with it, not about how traffic reaches Atlassian's infrastructure.
Why You Can't Put Cloudflare in Front of Atlassian Cloud
This is the question that comes up in every Data Center migration planning session, and the answer is definitive: Atlassian does not support customers placing a reverse proxy, CDN, or WAF in front of Atlassian Cloud products. This isn't merely a policy decision — it's a technical constraint.
Atlassian Cloud runs on *.atlassian.net domains that customers do not control, making DNS-level proxying through Cloudflare impossible. You can't CNAME your way around this because the DNS records are Atlassian's, not yours. As an Atlassian expert noted in the community forums, for Atlassian services to function correctly behind a proxy, the systems running them need to know they are being proxied — and you cannot configure that on Cloud servers.
Custom domains — now available for Jira, Confluence, and JSM — might theoretically enable proxying. But Atlassian manages the SSL certificate for custom domains, monitors for certificate changes, and will suspend the custom domain if suspicious certificate activity is detected. Creating a wildcard certificate for the parent domain — which is exactly what a CDN proxy like Cloudflare would generate — triggers this detection.
There's also a practical argument: since Atlassian already uses CloudFront internally, layering another CDN would add latency without clear benefit. You'd be proxying through Cloudflare only to have traffic proxied again through CloudFront — double TLS termination, double edge processing, for no security gain.
For organizations using third-party security platforms like Zscaler or Netskope for outbound traffic inspection, Atlassian recommends excluding *.atlassian.com, *.atlassian.net, and *.atl-paas.net from proxying, or adding the platform's IP ranges to allowlists.
The Full AWS Infrastructure Stack
For the infrastructure team that wants the complete picture, Atlassian Cloud runs entirely on AWS with a multi-tenant microservices architecture orchestrated via an internal PaaS called Micros alongside Kubernetes.
The networking and security stack from edge to origin:
Data residency is available across 12 locations: US, EU, Australia, Canada, Germany, India, Japan, Singapore, South Korea, Switzerland, UK, and a Global default. An important nuance — data residency controls where data is stored at rest, but does not affect how content is served. CloudFront serves from global edge locations regardless of residency pinning. A user in Tokyo accessing an EU-pinned Confluence instance still gets their static assets from a nearby CloudFront edge, but the dynamic content and data at rest live in the EU.
Atlassian publishes comprehensive IP ranges at ip-ranges.atlassian.com, with dedicated egress IP ranges from Atlassian-registered netblocks (104.192.136.0/21 and 185.166.140.0/22) that no other AWS customer uses, plus per-region ranges that AWS has dedicated to Atlassian's own accounts. This is critical for teams that need to allowlist Atlassian's outbound connections — such as webhooks hitting your internal systems. Allowlisting them isn't the same as trusting them, though: Atlassian notes these outgoing ranges also carry untrusted, user-configurable traffic, for example from the Forge platform.
Compliance Certifications
The certifications cover the full stack, including the networking layer. The edge/CDN tier doesn't have its own certification — that coverage is inherited from AWS's own certifications for CloudFront, WAF, and Shield.
SOC 2 Type II — covers Jira Cloud, Confluence Cloud, and Bitbucket Cloud under Security, Availability, and Confidentiality trust criteria
ISO/IEC 27001:2022 — certifies the Atlassian Trust Management System (ATMS) including Jira, Confluence, and Bitbucket Cloud
ISO 27017 (cloud-specific security) and ISO 27018 (PII protection in cloud)
FedRAMP Moderate — achieved March 2025 for Jira, Confluence, and JSM on the purpose-built Atlassian Government Cloud, based on NIST SP 800-53 Rev. 5 controls
CSA STAR Level 1 — self-assessment (CAIQ v4.0) published
PCI DSS Level 2 — merchant compliance for payment processing
HIPAA — supported with a Business Associate Agreement on Standard plans and above
For organizations that need FedRAMP compliance, the Government Cloud is a separate offering with its own infrastructure and additional controls beyond standard Atlassian Cloud.
The Bottom Line: What to Tell Your Client
The migration from Data Center with Cloudflare to Atlassian Cloud represents a shift from customer-managed edge security to a vendor-managed model that is arguably more robust but significantly less configurable.
Atlassian's AWS-native stack of CloudFront + WAF + Shield Advanced covers every functional area that Cloudflare provides — CDN, DDoS, WAF, rate limiting, SSL/TLS, and DNS. The critical difference is that customers cannot tune any of it.
The Gaps to Plan For
Your client's technical team should be aware of these specific gaps where Cloudflare capabilities have no direct replacement:
Geo-blocking is allowlist-only — if the client currently uses Cloudflare to restrict access by country, the closest equivalent is adding those countries as locations in an IP allowlist. Atlassian began rolling this out in February 2026 and its changelog still marks it as rolling out, so confirm the client's org has it. It's Premium and Enterprise only, countries count toward the same 500-entry limit as IP addresses, and it only works by allowing countries, not by blocking them.
No custom WAF rules — any custom rules the client has built in Cloudflare are gone. Atlassian manages the WAF entirely.
No custom HTTP security headers — CSP, X-Frame-Options, and HSTS are Atlassian's to configure.
No third-party CDN/WAF layering — you cannot put Cloudflare (or anything else) in front of Atlassian Cloud. This is a technical constraint, not just a policy.
Limited IP allowlisting — 500 entries per application, Premium and Enterprise plans only, and it doesn't cover admin.atlassian.com.
What the Client Gains
It's not all loss of control. The managed model brings real benefits:
No operational overhead — Atlassian's security team handles WAF rule tuning, DDoS response, TLS certificate rotation, and CDN optimization. Your client's team doesn't need to staff for this.
Continuous improvement — Atlassian's WAF rules are updated based on real attack patterns across their entire customer base. When one customer gets targeted, the protections benefit everyone.
Scale — AWS Shield Advanced with 24/7 Shield Response Team access is expensive when you're buying it yourself. Bundled into Atlassian Cloud, it's included.
Proven at scale — attacks of hundreds of millions of requests have been successfully mitigated.
The Honest Assessment
If your client's primary use of Cloudflare is CDN caching, DDoS protection, basic WAF rules, and SSL termination — which describes most Data Center deployments — Atlassian Cloud's managed stack is a functional replacement that will likely perform better than what they've built themselves.
If your client relies heavily on Cloudflare's advanced features — custom WAF rulesets, Workers for edge compute, geo-blocking beyond a simple country allowlist, custom Page Rules, or specific bot management configurations — those capabilities have no equivalent. The client will need to accept that these controls move from their hands to Atlassian's, evaluate whether Atlassian's managed approach meets their compliance requirements, and supplement with Atlassian Guard for identity and data-level controls.
The question isn't whether Atlassian Cloud's edge security is good enough. It is — demonstrably so. The question is whether your client's security posture requires the configurability that Cloudflare provides, or whether the managed model meets their actual requirements.
Atlassian Cloud's edge security isn't something you configure — it's something you inherit. The stack is enterprise-grade, battle-tested, and continuously improving. The trade-off is control. For most organizations migrating from Data Center, that trade-off is worth making. For those that need granular edge configuration, understanding exactly what you're giving up — and what you're gaining — is the first step toward a migration plan that your security team can actually sign off on.
