Try Demo

Talk to Adoption Engineer

Whitepaper

​
1. Corbado Deployment Options

When deploying the Corbado Connect solution, you have two primary hosting models to choose from - our public cloud (Shared AWS Instance) or a private cloud (Dedicated AWS Instance). Each model offers different levels of customization, security and availability, depending on your organization’s requirements. Within the private cloud model, there are multiple high-availability configurations to handle different disaster scenarios.

​
2. Public Cloud (Shared AWS Instance)

For organizations aiming for simplicity and speed, Corbado offers a public cloud instance hosted on shared AWS infrastructure. This is a cost-effective, fully managed environment where Corbado handles all maintenance, security updates, and scaling.
  • Quick Setup: Ideal for businesses that want a frictionless path to go live.
  • Cost Efficiency: Shared infrastructure lowers operational costs.
  • Scalability: Automatically adapts to user demand, ensuring smooth performance.
If your focus is on rapid deployment without extensive customization or regulatory constraints, the public cloud instance is an excellent fit.

​
3. Private Cloud (Dedicated AWS Instance)

For organizations requiring tighter controls or more advanced compliance measures, Corbado can be deployed in a private cloud (dedicated AWS instance). This deployment model provides full control over data residency, customized security policies, and network configuration. The dedicated AWS instance is fully managed by Corbado. We provide break-glass user access for emergency situations, ensuring you retain ultimate control when needed. Within a private cloud setup, you can choose from three levels of high availability and disaster recovery:

​
3.1 Multi-AZ Single-Region (Standard)

  • Description: Runs in multiple Availability Zones (AZ) within a single AWS region.
  • Infrastructure:
    • Application workload runs in 3 of 3 AZs.
    • Database workload runs in 2 of 3 AZs (MySQL RDS Multi-AZ).
  • Resiliency:
    • Automatically handles the failure of a single AZ (with near-zero data loss).
    • If two out of three AZs fail, service may degrade until AWS stabilizes in the remaining AZ.
    • Complete regional failure requires manual failover or data restore (4–8 hours RTO, up to 24 hours RPO).

​
3.2 Multi-AZ + Cross-Region Replica

  • Description: Extends Multi-AZ by adding near real-time data replication to a secondary AWS region.
  • Infrastructure:
    • Primary environment identical to Multi-AZ Single-Region.
    • Replicated data in another AWS region (< 1 minute RPO).
  • Resiliency:
    • If two AZs fail or the entire primary region is impacted, you have a current copy of data in another region.
    • Failover is still manual, but downtime is shorter (1-4 hours RTO, < 1 minute RPO).

​
3.3 Geo Failover-Ready

  • Description: Maintains a secondary region with both replicated data and a partially deployed (cold) application environment.
  • Infrastructure:
    • Near real-time data replication to secondary region (< 1 minute RPO).
    • Secondary environment can be activated quickly with minimal manual intervention (push button).
  • Resiliency:
    • Ideal for organizations that demand the highest availability.
    • In the event of a complete regional outage, recovery can occur within 15-30 minutes (RTO), with < 1 minute RPO.

​
4. Fallback Mechanism for Passkeys

Corbado’s system architecture ensures that any disruption to the passkey component automatically falls back to traditional login methods (e.g., existing login methods). This means:
  • Minimal Impact: Only passkey functionality is affected if a component fails.
  • Continuous Checkout: Payment or other workflows continue without interruption.
  • Seamless Recovery: Once the passkey service is restored, users can go right back to biometric authentication.

​
5. Comparing RTO & RPO Across Deployment Configurations

The following table provides a high-level comparison of Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for different failure scenarios across the dedicated AWS configurations.
Failure EventMulti-AZ Single-RegionCross-Region ReplicaGeo Failover
Single AZ FailureRTO: 1-5 min RPO: ~0 minNo need to fail overNo need to fail over
Two AZ FailureRTO: 15-30 min RPO: ~0 min Until AWS stabilizesRTO: 1-4 h RPO: < 1 min Manual failover if requiredRTO: 15-30 min RPO: < 1 min Push-button failover
Primary Region FailureRTO: 4-8 h RPO: up to 24 h Manual failoverRTO: 1-4 h RPO: < 1 min Manual failoverRTO: 15-30 min RPO: < 1 min Push-button failover

​
6. Next Steps

  1. Evaluate Your Requirements: Determine whether a shared or dedicated environment best meets your security, compliance, and performance needs.
  2. Choose a High-Availability Tier (if you select the dedicated AWS option): Decide which resiliency model (Multi-AZ Single-Region, Multi-AZ + Cross-Region Replica, or Geo Failover-Ready) aligns with your risk tolerance and recovery objectives.