はじめに
目的
本ドキュメントは、AWSにおける「テナンシー」の基本概念と、その選択がシステムに与える影響を分かりやすく説明します。初めて触れる方でも理解できるよう、実例を交えて解説します。
対象読者
クラウド設計に関わる技術者、運用担当者、または導入を検討する管理者を想定しています。専門用語は必要最小限に留め、図や経験則を思い浮かべられる説明を行います。
テナンシーとは（簡単に）
テナンシーは、EC2インスタンスが「他のお客様と同じ物理サーバ上で動くか」または「専用の物理サーバ上で動くか」を決める設定です。共有ハードウェアはコストが低く、専有ハードウェアは物理的な分離によりセキュリティやコンプライアンス上の要件を満たしやすくなります。具体例として、一般的なウェブサーバは共有で問題ないことが多く、金融データなど厳しい規制がある場合は専有を選ぶことがあります。
本書の構成（第2章以降の予告）
第2章で各テナンシーの種類とVPCレベルでの設定方法、コストと運用面の影響を詳しく説明します。第3章で選択時のチェックポイントをまとめます。
AWS テナンシーの詳細解説
テナンシーとは何か
テナンシーは、EC2インスタンスがどのハードウェアで動くかを決める設定です。共有の物理サーバーで他の利用者と一緒に動かすか、自分だけが使うハードウェアで動かすかを選びます。例として、開発環境は共有、本番の重要システムは専有という使い分けが考えられます。
テナンシーの種類と特徴
- 共有（Default）: コストが最も低く、ほとんどの用途に向きます。例: テストや低負荷のサービス。セキュリティや性能の完全な独立は保証されません。
- 専有（Dedicated）: 同じ物理サーバーを他のAWSアカウントと共有しません。金融や医療など規制が厳しい場合に有効です。コストは上がります。
- Dedicated Host（専有ホスト）: 物理サーバー単位で丸ごと専有できます。ライセンス形態（古いOSや商用ソフト）を合わせたい時に便利です。
VPCレベルでのテナンシー設定
VPCを作るときにデフォルトか専有かを選べます。VPCで専有を選ぶと、そのVPC内の全EC2に適用されます。個別に変えたい場合はインスタンス単位で注意が必要です。
テナンシー選択の考慮事項
主に考える点はセキュリティ、コスト、ライセンス、性能です。規制やソフトウェアのライセンス条件で専有が必須になることが多いので、要件を先に確認してください。小規模サービスは共有でコストを抑えることが多いです。
テナンシーの変更方法
起動中のインスタンスは直接切り替えられません。インスタンスを停止してから、AWS CLIのmodify-instance-placementコマンドなどで変更します。運用計画に停止の影響を入れてスケジュールしてください。
VPC構築時の位置づけ
テナンシーはネットワーク設計と密接に関係します。性能や拡張性、運用コストに影響を与えるため、VPC設計の初期段階で方針を決めておくと後の手戻りを減らせます。
まとめ
以下では、本記事で扱ったテナンシーの要点と実務での判断基準をやさしくまとめます。
要点
- テナンシーはリソースの配置戦略を決める設定です。共有（Shared）はコスト効率が高く、小規模サイトや開発環境に向きます。専有（Dedicated）やDedicated Hostは分離と制御を重視する本番環境やコンプライアンス要件のあるシステムに適します。
判断のポイント
- コスト重視なら共有を優先します。例：社内向けのテスト環境。
- セキュリティやライセンス制約があるなら専有やDedicated Hostを検討します。例：金融系アプリやオンプレ移行時のライセンス管理。
- 性能の予測性が必要なら専有を選ぶと良いです。
実務的な注意
- まず要件（セキュリティ・性能・費用）を明確にします。リスクとコストを比較し、段階的に移行するのが安全です。リザーブドインスタンスやSavings Plansでコスト最適化も検討してください。
最後に、用途に応じて柔軟に選ぶことが最も重要です。必要があれば具体的なケースをお聞きして、より詳しい提案をいたします。
