Private Cloud on AWS
Private Cloud on AWSのデプロイメントオプションは、Amazon Web Servicesで実行されるAuth0アイデンティティプラットフォーム専用のマネージドインスタンスで、分離、高性能、個別の開発インスタンス、様々なアドオンなどを備えています。
運用上の違い
Private Cloud on AWSの各デプロイメントオプションを比較できるよう下の表にまとめました。
機能 | パブリッククラウド | Private Cloud Basic on AWS * | Private Cloud Performance on AWS * |
---|---|---|---|
テナンシー | マルチ | シングル | シングル |
1秒あたりの要求数(100 RPS単位) | 100 RPS(1x) | 100 RPS(1x) | 500* RPS(5x) 1,500* RPS (15x) 3,000* RPS (30x) 3,000* RPS (30xバースト) 6,000* RPS (60x) 6,000* RPS (60xバースト) 10,000* RPS (100x) |
サービスレベル契約(SLA) | 99.99% | 99.99% | 99.99% |
データレジデンシー | パブリッククラウド領域のみ | あり | あり |
開発環境 | なし | なし | 1 |
*RPSの処理能力は一般的な目安です。実際の性能は、顧客のプライベートクラウド環境内で処理されるトランザクションの種類と量によって異なる可能性があります。処理能力のベンチマークに使用されたテストトランザクションは、顧客のそれぞれに特有のトランザクションパターンや作業負荷とは合致しない可能性があります。たとえば、以下の処理能力はリソース所有者のパスワードフローを使用する場合には該当します。
Private Cloud on AWSインスタンスのサービスレベル契約(SLA)は99.99%を誇ります。
データレジデンシー
アプリケーションで膨大な要求毎秒(RPS)が必要な場合は、AWSのプライベートクラウドの利用を検討します。標準のレート制限の詳細については、「レート制限ポリシー」を参照してください。Private Cloud on AWSのデプロイメントでは、Private Basicのレート制限は100 RPSで、Private Performanceのレート制限は500 RPS、1,500 RPS、3,000 RPS、および6,000 RPSに拡張されます。
最大可用性
Private Cloud on AWS Performanceのデプロイメントには、開発テスト用の完全に分離され個別に更新されたインスタンスが含まれています。また、運用前環境をさらに追加して、ビジネス要件を満たすことができます。
高需要アプリ
RPS(1秒間に処理可能な要求数)やSLAの保証は、非運用環境には適用されません。
その他の開発環境
Private Cloud on AWSは、以下のリージョンで完全に導入することができます。
Oktaは、組織が予測するトラフィックに基づいて、また購入したRPSプランに応じて、レート制限を設けています。組織内でトラフィックが想定よりも多い場合、この計画外のトラフィック増加はエンドユーザーに影響を与える可能性があります。プライベートクラウドは、トランザクションレートが一定の範囲で増加しても(10分間で100 RPSから1000 RPSに増加するなど)、サービスに一切影響を及ぼさずに対応できるよう設計されています。しかし、トラフィックが急激に増加すると(数秒足らずで100 RPSから1000 RPSに増加するなど)、新たに生じた負荷の調整を行う間、サービスが不安定な状態になり、遅延が増加する可能性があります。
制限事項
データセンターの場所
Private Cloud on AWSを選択したら、オンボーディングとデプロイメントのプロセスが始まり、環境を構成します。
オーストラリア
バーレーン
ブラジル
カナダ
フランス
ドイツ
香港
インド
インドネシア
アイルランド
イタリア
日本語
シンガポール
南アフリカ
韓国
スウェーデン
英国
米国
米国
バーストトラフィック
契約締結後、オンボーディング要件に関する主要な情報をご提出いただき、当社で情報を確認いたします。
オンボーディング
オンボーディング要件を確認し終えたら、プロジェクト開始のためのミーティングを設けて実装プロセスを開始します。このミーティングは契約締結後5日以内に開催するよう強くお勧めします。
お客様のオンボーディング要件
オンボーディングフォームを確認次第、お客様の環境のプロビジョニングを開始いたします。
プロジェクト開始のミーティング
このプロセスを終了したら、環境移管の準備は完了で、Private Cloud on AWSデプロイメントを使用することができます。
実装
アクション、カスタムウェブフック、カスタムデータベースアクションスクリプトなど、一部のAuth0プラットフォームのカスタマイズ機能を使って、Auth0プラットフォームから独自のサービスへのアウトバウンド接続が可能です。Private Cloud on AWSでは、データをインターネットに公開することなく、プライベートクラウドのデプロイメントと独自のサービス間のネットワーク接続を確立することができます。
安全なアウトバウンドネットワークにはAWS PrivateLinkを使用します。まず、AWSアカウントでエンドポイントサービスを確立して、PrivateLinkを通じてサービスを共有します。基盤となるサービスは、AWSネイティブのサービスでも、データセンターで実行されるサービスでも構いません。サービスはプライベートクラウドのデプロイメントと同じAWSリージョン内のVPCに存在する必要があります。
安全なアウトバウンドネットワーク
次に、エンドポイントサービスを利用できるように、プライベートクラウドのデプロイメントが構成されます。Auth0にエンドポイントサービス情報をご提供いただいたら、当社がサービスをデプロイメントと統合し、カスタマイズコードからサービスにアクセスする方法をご提供します。
PrivateLinkでエンドポイントサービスを設定する方法の詳細については、AWSにお問い合わせください。Auth0とのサービスオンボーディングを調整するには、サポートセンターにリクエストを提出してください。
Private Cloud on AWSデプロイメントは、毎週自動更新されます。必要に応じて、週の特定の日時に設定することができます。
このポリシーは、リクエストの提出者であるPrivate Cloud on AWSご利用者に対して、Auth0が負荷テストを実施するために必要な要件をまとめたものです。負荷テストは、サポートセンターから申請してください。[Issue(問題)]フィールドで、[Private Cloud Support Incident(プライベートクラウドのサポートインシデント)]を選択します。
更新
専用の負荷テスト環境を購入された場合は、実行できる負荷テストの頻度に制限はありません。負荷テストが手順に沿って進められていると仮定した場合、標準の環境は年2台に制限されます。
テストを行う
負荷テスト
承認を申請するには、以下の条件を満たさなければなりません。
インフラストラクチャーへの変更が要求された場合、特定の要件に基づいてコストが決定されます。
ペネトレーションテスト
負荷は低い値から始め、ピークに達するまで徐々に上げていきます。環境で対処できる以上の負荷をかける必要がある場合は、環境サイズを上げる必要があります。
プライベートクラウド環境は契約の追加条項によって拡張することができます。この購入に関するご相談は、担当のアカウントエグゼクティブまたはTAMまでお問い合わせください。
遅くとも希望の実施日の2週間前までに申請すること。綿密な審査や内容の調整が必要になるため、1か月以上前に申請することをお勧めします。
テストを実施する前に、書面で承認を受けること。
公開されている運用レート制限内に収めること。
サブスクリプション | 負荷テスト容量 | ランプアップ |
---|---|---|
プライベートクラウドパフォーマンス500 RPS(5x) | 325 RPS | 100 RPS/分 |
プライベートクラウドパフォーマンス1500 RPS(15x) | 975 RPS | 100 RPS/分 |
テスト容量に関する考慮事項
プライベートクラウドでの負荷テストの詳細については、「環境要求の制限(プライベートクラウドのみ)」を参照してください。
高負荷が予想される期間は、イベント発生14日前に必ずアカウントチームに通知する必要があります。この通知により、シナリオを適切にテストする機会を確保し(可能な場合)、イベントに即したサポートを発生後に行うことができます。
セキュリティテストを実施するには、前もってAuth0サポートセンターにお知らせください。遅くともテスト開始予定日の1週間(7日)前にAuth0に通知する必要があります。
自社のインフラストラクチャ内で限定的にテストを実施する(つまり、Auth0サービスはテストされない)場合は、Auth0への通知は不要です。
必要とされる情報については、「ペネトレーションテストポリシー」を参照してください。
高負荷通知
このポリシーは、Geoフェイルオーバーのアドオンを備えた、AWSまたはAzure Customer Identity Cloud(Auth0)プラットフォーム上にあるプライベートクラウドのご利用者に対して、Oktaがフェイルオーバーテストを実施するために必要な要件をまとめたものです。フェイルオーバーテストは、サポートセンターから申請してください。[Issue(問題)]フィールドで、[Private Cloud Support Incident(プライベートクラウドのサポートインシデント)]を選択します。
フェイルオーバーテスト
承認を申請するには、以下の条件を満たさなければなりません。
Oktaは、要求されたテストを実施する担当者のスケジュールに応じて、フェイルオーバーとフォールバックの代替期間を提案する権利を留保します。また、フェイルオーバーまたはフォールバックの手続きの一環として発生するサービス中断は、SLA条項の対象外となります。
Auth0が管理する証明書(*.auth0app.comの形式)は、Auth0が取得および適用する責任を負います。Auth0はプロセスをエンドツーエンドで管理し、お客様に必要な対応を求めます。
フェイルオーバーテスト
カスタムドメイン用にAuth0が発行した証明書の更新は、Auth0によって管理されます。
プライベートクラウド環境は契約の追加条項によって拡張することができます。この購入に関するご相談は、担当のアカウントエグゼクティブまたはTAMまでお問い合わせください。
遅くとも希望のテスト日時(UTC)の2週間前までに申請すること。綿密な審査や内容の調整が必要になるため、1か月以上前に申請することをお勧めします。
フェイルオーバーテストの実施回数が暦年で2回以内であること。
テストを実施する前に、書面で承認を受けること。
フェイルオーバーとプライマリリージョンへのフォールバックの両方の期間(UTC)を指定すること。その際、両方の期間で最大15分間のダウンタイムが発生することを理解しておいてください。
Oktaとすべてのテストロジスティクスを調整する窓口となる連絡先が指定されていること。
Auth0ではログを提供しており、Dashboardまたはログストリーミングエンドポイントからアクセスできます。
証明書の更新プロセス
ご質問やご不明な点がございましたら、Auth0サポートチームまでお問い合わせください。リクエストに迅速に対応できるよう、サポートチケットにできるだけ詳しい情報をご記入ください。
カスタムドメイン用にAuth0が発行した証明書の更新は、Auth0によって管理されます。
カスタムドメインについて、顧客が管理する証明書(*.<CustomerName>.comの形式)は、顧客が責任を持って更新を行います。
レポートとモニタリング
Auth0ではログを提供しており、Dashboardまたはログストリーミングエンドポイントからアクセスできます。
サポート
ご質問やご不明な点については、Auth0サポートチームまでお問い合わせください。リクエストに素早く対応できるように、サポートチケットにはできるだけ詳しい情報をご記入ください。