Private Cloud on AWS

Private Cloud on AWS

The Private Cloud on AWS deployment option is a dedicated, managed instance of the Auth0 identity platform running on Amazon Web Services. It provides isolation, higher performance, separate development instances, various add-ons, and more.

Operational differences

The table below compares each deployment option for Private Cloud on AWS.

Feature Public Cloud Private Cloud Basic on AWS Private Cloud Performance on AWS
Tenancy Multi Single Single
Requests per second (Multiples of 100 RPS) 100 RPS (1x) 100 RPS (1x) 500 RPS (5x)
1,500 RPS (15x)
3,000 RPS (30x)
6,000 RPS (60x)
Service level agreement (SLA) 99.99% 99.99% 99.99%
Data residency Public cloud regions only Yes Yes
Dev environment No No 1

Data residency and isolation

With Private Cloud on AWS, you choose the region where your data is stored. Auth0 can provide a list of available regions that use multiple availability zones for the deployment. All data can remain and be stored in the chosen region. This is crucial in instances where regulations prevent data from being stored or processed outside the origin region.


Backups are stored in the deployment region.

Data sovereignty

If you have data sovereignty requirements, Auth0 supports Public Cloud deployments in the following regions:

  • United States

  • Europe

  • Australia

  • Japan

  • United Kingdom

Otherwise, Private Cloud on AWS can be supported in other regions (except China). Furthermore, Auth0 can deploy backups in the same AWS region that hosts the Private Cloud.

Maximum availability

Private Cloud on AWS instances have a 99.99% service level agreement (SLA).

High demand apps

If your application requires a significantly high amount of requests per second (RPS), you may also wish to consider Private Cloud on AWS. See the rate limits policies for more information about the standard rate limits. For Private Cloud on AWS deployments, the limit is 100 RPS with an upgrade to 1,500 RPS.

Additional dev environments

Private Cloud on AWS Performance and Performance Plus deployments include a fully-isolated and independently-updated instance for development and testing. You can add additional pre-production environments to meet your business requirements.


Data residency

Private Cloud on AWS is fully deployable (meeting full data sovereignty requirements) in the following regions:

  • USA

  • Europe

  • Australia

  • Japan

  • Canada

  • United Kingdom

  • Ireland

  • Italy

  • Bahrain

  • Singapore

  • Brazil

  • South Africa

  • Australia

  • India

  • France

  • Germany

  • Sweden

  • South Korea


After choosing Private Cloud on AWS, an onboarding and deployment process will be followed to configure your environment(s).

Customer onboarding requirements

Upon contract signing, we will ask you to provide key information regarding your onboarding requirements, which we will then validate.

Kickoff meeting

Once we validate your onboarding requirements, we will host a kickoff meeting with you to begin the implementation process. We strongly recommend that this meeting occur no later than five (5) days after the contract signing.


Immediately after the onboarding form validation, we will begin provisioning your environment.

At the end of this process, you're ready for the environment handover and your Private Cloud on Azure deployment is ready for use.


Private Cloud on AWS deployments are updated every week automatically. You can set a specific day and time during the week, if required.


Load testing

This policy outlines the necessary requirements for Auth0 to perform load testing for Private Cloud on AWS customers who submit a request. You can file a load testing request via the Support Center. Under the Issue field, select Private Cloud Support Incident.

To be considered for approval, the request must:

  • Be filed at least two (2) weeks prior to the desired test date; in many cases, Auth0 encourages one (1) month of advance notice to ensure time for a thorough review and any required modifications.

  • Receive approval in writing before any testing is conducted.

  • Stay within our published production rate limits.

  • Include all information described in our Load Testing Policy.

If changes to infrastructure are requested, the cost will be determined based on your specific requirements.

Testing capacity considerations

If you perform a test that exceeds 500RPS in a High Availability environment or 1500RPS in a High Capacity environment, then the performance of the environment may be negatively affected, either with requests being slow or potentially the environment seizing. You should start with a low load and slowly increase until the environment has reached its peak. Should you require a load greater than what the environment can handle, then the environment size should be increased, if possible; you can work with your Technical Account Manager to discuss details.

High load notifications

For periods of anticipated high load, you must inform your account team no later than 14 days prior to the event. The notification provides the opportunity to adequately test scenarios (if possible) and aligns reactive support to the event.

Penetration testing

To conduct a security test, please notify us in advance via the Auth0 Support Center. Auth0 requires at least one week (seven days) notice prior to your test's planned start date.

If the test is isolated to your infrastructure (that is, there will be no testing of Auth0 services), you do not need to notify Auth0.

For the information that we require, see our Penetration Testing Policy.

Failover testing

This policy outlines the necessary requirements for Okta to perform failover testing for Private Cloud customers on either the AWS or Azure Customer Identity Cloud (Auth0) platform with the required Geo Failover add-on. You may file a failover testing request via the Support Center. Under the Issue field, select Private Cloud Support Incident.

To be considered for approval, the request must:

  • Be filed at least two (2) weeks prior to the desired test date and time (in UTC). In many cases, Okta encourages one (1) month of advance notice to ensure time for a thorough review and any required modifications.

  • Fall under the limit of (2) failover tests per calendar year.

  • Receive approval in writing before any testing is conducted.

  • Specify windows (in UTC)  for both the failover and the fallback to the primary region, with an understanding that both windows will result in downtime of up to 15 minutes.

  • Designated point-of-contact specified with whom Okta will coordinate all testing logistics

Please note that Okta reserves the right to suggest alternative windows for the failover and fallback to correspond to availability of Staff to perform the requested testing. Additionally, any service interruption that results as part of the failover or fallback procedures is exempt of any SLA provisions.

Certificate renewal process

Auth0-managed certificates (in the format * are the responsibility of Auth0 to both obtain and apply. Auth0 will manage the process end-to-end and will prompt you with any action required.

Renewal of Auth0-issued certificates for custom domains is managed by Auth0.

Renewal of customer-managed certificates for custom domains (in the format *.<CustomerName>.com) is the customer’s responsibility to manage and obtain.

Reporting and monitoring

Auth0 provides logs that are accessible via the Dashboard or the log streaming endpoint.


You can reach out to the Auth0 Support team with any questions or concerns you might have. To help expedite your request, please provide as much information as possible in the Support ticket you open.