はじめに
「AWSのテナントって、AWSアカウントやユーザーとは何が違うの？」
「マルチテナントにすると、別の顧客のデータが見えてしまうことはないの？」と疑問に感じていませんか。
複数の企業やユーザーが利用するSaaSをAWS上で構築しようとすると、テナントという言葉が出てきても、どこまでを1つの単位として分ければよいのか判断しにくいことがあります。
この記事では、AWSにおけるテナントの意味から、複数のテナントでシステムを利用するマルチテナントの仕組み、顧客ごとにデータやアクセス権限を分けるテナント分離の考え方まで、順を追って説明していきます。
AWSにおけるテナントとは？
AWSでSaaSを構築するときのテナントとは、サービスを利用する企業や組織などを区別して管理するための単位です。
まずテナントとAWSアカウントの違いを整理したうえで、各テナントをどのように識別して管理するのかを順番に確認していきましょう。
テナントはSaaSで利用者を分ける単位
テナントは、SaaSを利用する企業や組織ごとに利用者を分けるための単位です。
たとえば企業Aと企業Bが同じSaaSを利用する場合、それぞれを別のテナントとして区別します。
テナントごとに識別子を割り当てることで、同じSaaS上でもどの企業の利用者なのかを判別できます。
AWSアカウントとテナントは同じではない
AWSアカウントはAWSのリソースや料金を管理する単位で、SaaSの利用企業を分けるテナントとは役割が異なります。
1つのAWSアカウントで複数のテナントを管理することもあれば、テナントごとにAWSアカウントを分けることもあります。
そのため、「1つのAWSアカウント＝1テナント」と考えず、それぞれを別の単位として理解しておきましょう。
テナントごとにAWSアカウントを分けるべきか迷う場合は、複数アカウントをどのように管理するのかも確認しておくと判断しやすくなります。
▶AWSの複数アカウント管理とは？分けるメリットと管理方法を解説
AWSでテナントを識別して管理する考え方
AWSで複数のテナントを扱う場合は、テナントごとに一意のテナントIDを設定して識別します。
ユーザーがSaaSへログインした際にテナントIDを特定し、リクエストや保存するデータと紐づけることで、どのテナントの処理やデータなのかを区別して管理できます。
AWSでマルチテナントを構成する方法
AWSでマルチテナントを構成するときは、テナントごとにリソースを分ける方法と、複数のテナントで同じリソースを共有する方法があります。
ここでは、リソースの分離と共有の違いから、認証・認可とテナント識別の考え方まで順番に確認します。
テナントごとにリソースを分離する
テナントごとにリソースを分離する場合は、それぞれ専用のデータベースやストレージなどを用意します。
テナントAとテナントBで使用するリソースを分けることで、他のテナントへアクセスしない構成にしやすくなります。
どのリソースを使用するかはテナントごとに対応付けて管理します。
複数テナントでリソースを共有する
複数テナントでリソースを共有する場合は、1つのデータベースやストレージなどを複数のテナントで使用します。
保存するデータにテナントIDを持たせ、データを取得するときもテナントIDを条件に含めることで、ログイン中のテナントに対応するデータだけを処理します。
認証・認可とテナント識別を分けて考える
認証では「誰がログインしたか」、認可では「何を操作できるか」を確認し、テナント識別では「どのテナントに属しているか」を判定します。
それぞれを分けて考えることで、利用者の確認から操作できる範囲、アクセス対象となるテナントまで整理しやすくなります。
AWSのマルチテナント構成モデル
AWSでマルチテナント環境を構築するときは、テナントごとに環境を分けるか、複数テナントで同じ環境を共有するかによって構成モデルが変わります。
それぞれリソースの分け方が異なるため、3つのモデルがどのような構成になるのかを順番に確認していきましょう。
サイロモデルはテナントごとに環境を分離する
サイロモデルでは、テナントごとにデータベースやストレージなどのリソースを分けて配置します。
それぞれに専用のリソースを割り当てるため、他のテナントと共有せず、テナント単位で環境を分離して管理できます。
プールモデルは複数テナントで環境を共有する
プールモデルでは、複数のテナントが同じデータベースやストレージなどのリソースを共有します。
保存するデータにテナントIDを持たせ、データを取得するときもテナントIDを条件に含めることで、対象となるテナントのデータを区別して処理します。
ブリッジモデルは分離と共有を組み合わせる
ブリッジモデルでは、一部のリソースをテナントごとに分離し、それ以外は複数のテナントで共有します。
たとえばデータベースはテナントごとに分け、アプリケーションの実行環境は共有するなど、必要に応じてサイロモデルとプールモデルを組み合わせられます。
AWSでテナントを分離するときのポイント
AWSで複数のテナントを同じシステム上で扱う場合は、別のテナントのデータや機能へアクセスできないように分離する必要があります。
ログやメトリクスから各テナントの利用状況を区別できるようにし、データ分離・権限制御・監視の3つを順番に確認していきましょう。
サイロモデルはテナントごとに環境を分離する
サイロモデルでは、テナントごとにデータベースやストレージなどのリソースを分けて配置します。
それぞれに専用のリソースを割り当てるため、他のテナントと共有せず、テナント単位で環境を分離して管理できます。
プールモデルは複数テナントで環境を共有する
プールモデルでは、複数のテナントが同じデータベースやストレージなどのリソースを共有します。
保存するデータにテナントIDを持たせ、データを取得するときもテナントIDを条件に含めることで、対象となるテナントのデータを区別して処理します。
ブリッジモデルは分離と共有を組み合わせる
ブリッジモデルでは、一部のリソースをテナントごとに分離し、それ以外は複数のテナントで共有します。
たとえばデータベースはテナントごとに分け、アプリケーションの実行環境は共有するなど、必要に応じてサイロモデルとプールモデルを組み合わせられます。
AWSのテナント設計で押さえるポイント
AWSのテナント設計では、すべてのリソースをテナントごとに分けるのではなく、セキュリティ要件や運用方法に合わせて分離する範囲を決めます。
セキュリティ要件を確認したうえで共有できる範囲を決め、必要に応じて分離と共有を組み合わせる考え方を順番に確認していきましょう。
セキュリティ要件に応じて分離範囲を決める
テナントごとのセキュリティ要件を確認し、データベースやストレージなどをどこまで分離するか決めます。
ほかのテナントからのアクセスを避ける必要があるリソースは専用にするなど、必要な範囲にテナント間の境界を設けましょう。
テナントごとのアクセス範囲をどのように制限すればよいか迷う場合は、AWSの権限管理の仕組みもあわせて確認しておきましょう。
▶AWS IAMとは？ユーザー・ロール・ポリシーの違いと権限設定を解説
コストと運用効率を考えて共有範囲を決める
テナントごとにリソースを用意すると、管理対象が増えるため、料金や運用の負担も大きくなります。
複数のテナントで共通利用できるリソースは、セキュリティなどの要件を確認したうえで共有すると、コストや管理の負担を抑えやすくなります。
要件に応じて分離と共有を組み合わせる
すべてのリソースを分離または共有のどちらかに統一する必要はありません。
専用にする必要があるリソースは分離し、共通利用できるものは共有することで、それぞれの要件に合わせた構成にできます。
まとめ
AWSのテナント設計では、SaaSを利用する企業や組織を適切に区別し、ほかのテナントのデータやリソースへアクセスできないように管理することが大切です。
構成にはサイロ・プール・ブリッジなどがあり、セキュリティ要件やコスト、運用のしやすさに合わせて選びます。
特にリソースを共有する場合は、テナントIDを使ったデータ分離やアクセス制御、ログ・メトリクスによる監視まで考えておく必要があります。
すべてを分離することにこだわらず、専用にする部分と共有できる部分を整理しながら、自社のサービスに合った構成を検討してみてください。
