Optimizely Cloud Architecture
Why cloud architecture matters
Section titled “Why cloud architecture matters”Every second of downtime costs revenue and erodes user trust. Understanding how the Optimizely cloud platform is structured helps you make better decisions about performance tuning, disaster recovery, and capacity planning. You do not need to manage the infrastructure yourself, but knowing what sits beneath your application lets you troubleshoot effectively and design for scale.
Platform overview
Section titled “Platform overview”Optimizely Cloud is a managed hosting platform built on Microsoft Azure. It provides compute, storage, networking, and CDN services specifically tuned for content management workloads. Your application runs on dedicated resources within a multi-tenant infrastructure, with isolation between customers at the network and storage layers.
The platform handles:
- Compute provisioning — Web application instances that serve your site
- Database hosting — Managed SQL Server for content and commerce data
- Blob storage — Azure Blob Storage for media, files, and assets
- CDN — Edge caching and static asset delivery across global points of presence
- SSL/TLS — Automatic certificate management for custom domains
Regions and data residency
Section titled “Regions and data residency”Optimizely Cloud operates in multiple Azure regions. When your site is provisioned, you select a primary region where your compute and database resources run.
| Region | Location | Typical use |
|---|---|---|
| North America East | Virginia, US | US-based organizations |
| North America West | Washington, US | US west coast preference |
| Europe West | Netherlands | EU data residency requirements |
| Europe North | Ireland | UK and Nordic organizations |
| Asia Pacific | Singapore | APAC-focused sites |
| Australia East | Sydney | Australian data sovereignty |
Data residency: Your content database and blob storage remain in your selected region. CDN edge nodes cache content globally, but origin data stays in-region. This matters for GDPR, data sovereignty, and latency optimization.
Compute and scaling
Section titled “Compute and scaling”Each environment runs on one or more web application instances behind a load balancer. The platform automatically distributes requests across instances using round-robin with health checks.
Auto-scaling behavior
Section titled “Auto-scaling behavior”The platform monitors CPU utilization, memory pressure, and request queue depth. When thresholds are exceeded, additional instances spin up within minutes.
- Scale-out trigger — Sustained CPU above 70% or request queue exceeding configured depth
- Scale-in trigger — Sustained CPU below 30% with stable request rates
- Minimum instances — Production environments maintain at least two instances for availability
- Maximum instances — Configurable per subscription tier, typically 4 to 16
What you can configure vs. what is fixed
Section titled “What you can configure vs. what is fixed”Not all infrastructure settings are developer-configurable. The following table clarifies which parameters you control and which are determined by your subscription tier:
| Setting | Configurable? | Details |
|---|---|---|
| Minimum instance count | Fixed by tier | Production environments run at least 2 instances. Higher tiers may include more. |
| Maximum instance count | Fixed by tier | Typically 4 to 16, depending on your subscription level. Contact support to confirm your limit. |
| Auto-scaling thresholds | Not configurable | CPU, memory, and queue depth thresholds are managed by the platform. You cannot adjust the trigger percentages. |
| Database performance tier | Adjustable via support | Submit a support request to change the SQL performance tier. This is not self-service. |
| CDN cache TTL | Configurable | You control cache headers in your application code and CDN configuration. |
| SSL/TLS certificates | Automatic | Certificates are provisioned and renewed automatically for custom domains. |
| IP restrictions | Configurable | Set IP allowlists for management endpoints through the portal. |
Session affinity
Section titled “Session affinity”Optimizely Cloud uses ARR (Application Request Routing) affinity cookies by default. A user’s requests route to the same instance for session consistency. Stateless application design is still recommended because instances can restart during deployments or scaling events.
Storage architecture
Section titled “Storage architecture”SQL database
Section titled “SQL database”Each environment gets a dedicated Azure SQL database. Production databases run with geo-redundant backups and point-in-time restore capability covering the previous 35 days.
- Automated backups — Full backup weekly, differential daily, transaction log every 5-10 minutes
- Performance tier — Scaled to your subscription level, adjustable through support requests
- Read replicas — Available on higher tiers for reporting workloads without impacting production
Blob storage
Section titled “Blob storage”Media files, documents, and uploaded assets are stored in Azure Blob Storage with geo-redundant replication. The blob storage account is shared across environments within a project, with container-level isolation.
Network and security
Section titled “Network and security”Traffic flow
Section titled “Traffic flow”User → CDN Edge → Load Balancer → Web Instance(s) → SQL / Blob StorageAll traffic enters through the CDN layer. Requests for cached content are served from the nearest edge node. Cache misses route to the load balancer, which forwards to a healthy web instance. The application reads from SQL and Blob Storage as needed.
Security layers
Section titled “Security layers”- WAF (Web Application Firewall) — Protects against common web attacks (OWASP top 10)
- DDoS protection — Azure-level DDoS mitigation on all public endpoints
- Network isolation — Customer environments are isolated via virtual networks
- Encryption — TLS 1.2+ for data in transit, AES-256 for data at rest
- IP restrictions — Optional IP allowlisting for management endpoints
High availability
Section titled “High availability”Production environments are designed for high availability by default:
- Multiple instances — At least two compute instances in production
- Health checks — Load balancer removes unhealthy instances from rotation within 30 seconds
- Database failover — Automatic failover to a secondary replica if the primary becomes unavailable
- Blob redundancy — Geo-redundant storage replicates data to a paired Azure region
The platform targets 99.9% uptime for production environments. Scheduled maintenance windows are communicated in advance and typically involve zero-downtime deployments.
RPO and RTO
Section titled “RPO and RTO”Recovery Point Objective (RPO) and Recovery Time Objective (RTO) vary by subscription tier and region configuration. As a baseline, the automated backup schedule (transaction logs every 5-10 minutes, daily differentials, weekly full backups) provides a general RPO of under 10 minutes for database recovery. Specific RPO and RTO commitments for your subscription tier are available from Optimizely support — contact your account team or submit a support request referencing your project ID to obtain the numbers for your environment.
Related resources
Section titled “Related resources”1. A European client requires that all content data remain within EU borders for GDPR compliance, but they want fast page loads globally. How does the Optimizely Cloud architecture support this?
Selecting a European region ensures the content database and blob storage remain in that region for data residency. CDN edge nodes cache content globally for performance, but origin data stays in-region.
Selecting a European region ensures the content database and blob storage remain in that region for data residency. CDN edge nodes cache content globally for performance, but origin data stays in-region.
Review this topic →2. During a flash sale, a site experiences sustained CPU utilization of 85% across all instances. What does the Optimizely Cloud platform do automatically?
The platform auto-scales by spinning up additional instances when sustained CPU exceeds 70%. This happens automatically within minutes, no manual intervention required.
The platform auto-scales by spinning up additional instances when sustained CPU exceeds 70%. This happens automatically within minutes, no manual intervention required.
Review this topic →3. An architect wants to tune the auto-scaling trigger thresholds to be more aggressive (scale out at 50% CPU instead of 70%). Can they do this?
Auto-scaling thresholds (CPU, memory, queue depth) are managed by the platform and cannot be adjusted by customers. CDN cache TTL and IP restrictions are configurable, but scaling triggers are not.
Auto-scaling thresholds (CPU, memory, queue depth) are managed by the platform and cannot be adjusted by customers. CDN cache TTL and IP restrictions are configurable, but scaling triggers are not.
Review this topic →