第2章：クラウドインフラの共通概念とアーキテクチャ

この章で学ぶこと

リージョンとアベイラビリティゾーンの設計思想と可用性戦略を理解する

仮想ネットワークの基礎概念と効果的な設計手法を習得する

多層防御によるネットワークセキュリティの実装方法を学ぶ

IAMを中心とした包括的なアクセス制御戦略を身につける

リソース管理とタグ付けによるガバナンスの確立方法を理解する

第1章でクラウドコンピューティングの基礎を学びました。この章では、実際のクラウドインフラ設計・構築に必要な共通概念を深く理解し、アーキテクチャレベルでの設計判断ができるようになります。これらの概念は、後続の章で学ぶ具体的な実装技術の基盤となります。

2.1 リージョンとアベイラビリティゾーンの戦略的理解

地理的分散の設計思想

クラウドインフラストラクチャの物理的な配置は、単なる技術的な実装詳細ではありません。それは、可用性、パフォーマンス、コンプライアンス、コストのバランスを最適化する戦略的な設計です。

リージョンという概念の誕生

リージョンは、地理的に離れた場所に設置された独立したクラウドインフラストラクチャの集合体です。なぜクラウドプロバイダーはこのような分散アーキテクチャを採用したのでしょうか。

第一に、レイテンシの最小化です。光の速度は有限であり、東京からシリコンバレーまでのラウンドトリップには理論的にも最低60ミリ秒かかります。ユーザー体験を重視するアプリケーションにとって、この遅延は無視できません。

第二に、データレジデンシー要件への対応です。多くの国や地域では、特定のデータを国外に持ち出すことを制限しています。リージョンの存在により、これらの規制要件を満たしながらクラウドの利点を享受できます。

第三に、大規模災害への備えです。地震、洪水、停電などの地域的な災害から、重要なシステムを保護するには、地理的な分散が不可欠です。

アベイラビリティゾーンの役割

リージョン内には、複数のアベイラビリティゾーン（AZ）が存在します。AZは、独立した電源、冷却、ネットワークを持つ1つ以上のデータセンターの集合です。

なぜAZが必要なのか

単一のデータセンターに依存することのリスクは明らかです。しかし、なぜリージョンをさらにAZに分割する必要があるのでしょうか。

AZは、高可用性と低レイテンシの両立を可能にします。同一リージョン内のAZ間は高速な専用ネットワークで接続されており、通常1-2ミリ秒程度の遅延でデータを同期できます。これにより、リアルタイムのレプリケーションやフェイルオーバーが実現可能です。

また、AZレベルの障害（例：特定のデータセンターの電源障害）から保護しながら、リージョンレベルの一貫性（同じ規制環境、ネットワーク的な近さ）を維持できます。

可用性の数学的理解

可用性は、システムが正常に稼働している時間の割合で表されます。単一のAZが99.9%の可用性を持つ場合、年間約8.76時間のダウンタイムが予想されます。

マルチAZ構成の効果

2つのAZにまたがってシステムを構築し、両方が同時に障害を起こす確率が独立である場合、理論的な可用性は：

` 可用性 = 1 - (1 - 0.999)² = 1 - 0.000001 = 0.999999 (99.9999%) `

これは年間約30秒のダウンタイムに相当します。

実際の考慮事項

ただし、この計算は理想的な状況を前提としています。実際には、以下の共通の障害要因が存在します：

ソフトウェアのバグ
設定ミス
依存関係の問題
人的操作ミス
広域ネットワークの問題

実践的な設計パターン

アクティブ-アクティブ vs アクティブ-パッシブ

アクティブ-アクティブ構成：

すべてのAZでトラフィックを処理
負荷分散と可用性の両方を実現
リソース効率が高い
適用例：ステートレスなウェブアプリケーション

アクティブ-パッシブ構成：

通常は1つのAZでトラフィックを処理
障害時に別のAZにフェイルオーバー
データの一貫性を保ちやすい
適用例：強い一貫性を要求するデータベース

データの同期とレプリケーション

同期レプリケーション：

メリット：強い一貫性、データロスなし
デメリット：書き込み性能への影響、レイテンシの増大
適用例：金融取引、在庫管理

非同期レプリケーション：

メリット：高い書き込み性能、低レイテンシ
デメリット：障害時のデータロスリスク
適用例：ログ処理、分析データ

2.2 仮想ネットワークの設計原理

仮想ネットワークの必要性

パブリッククラウドは、本質的に共有環境です。しかし、企業のワークロードには、分離とセキュリティが不可欠です。仮想ネットワーク（AWS: VPC、Azure: VNet、GCP: VPC）は、この要求に応える基本的な構成要素です。

論理的な分離の実現

仮想ネットワークは、クラウド内に論理的に分離されたネットワーク空間を作成します。これは、物理的なVLANに似ていますが、ソフトウェアで定義されるため、より柔軟で動的です。

各仮想ネットワークは独自のIPアドレス空間を持ち、他のネットワークとは完全に分離されます。これにより、オンプレミスのプライベートネットワークと同様の分離レベルを実現できます。

IPアドレス設計の戦略的重要性

仮想ネットワークの設計は、IPアドレス計画から始まります。CIDR（Classless Inter-Domain Routing）表記を使用して、ネットワークのアドレス範囲を定義します。

慎重な計画が必要な理由

変更の困難性：一度作成した仮想ネットワークのCIDRブロックは、多くの場合変更できません。

将来の拡張性：組織の成長、新しいサービスの導入、他の環境との統合を考慮する必要があります。

オンプレミスとの統合：既存のネットワークとの重複を避ける必要があります。

実践的なIPアドレス設計

推奨アドレス範囲：

10.0.0.0/8：大規模組織（1,677万アドレス）
172.16.0.0/12：中規模組織（104万アドレス）
192.168.0.0/16：小規模組織（6.5万アドレス）

階層的な設計例： ` 本番環境： 10.0.0.0/16 開発環境： 10.1.0.0/16 テスト環境： 10.2.0.0/16 `

サブネット設計の原則

仮想ネットワーク内は、さらにサブネットに分割されます。サブネットは通常、AZに関連付けられ、リソースの配置単位となります。

効果的なサブネット分割

パブリックサブネット：

インターネットゲートウェイへの直接ルートを持つ
用途：ロードバランサー、NAT Gateway、Bastion Host
セキュリティ：最小限のリソースのみ配置

プライベートサブネット：

インターネットへの直接アクセスを持たない
用途：アプリケーションサーバー、内部サービス
セキュリティ：より厳格なアクセス制御

データベースサブネット：

最も厳格なアクセス制御を適用
用途：データベース、機密データ処理
分離：アプリケーション層からのアクセスのみ許可

実践的なサブネット設計例

` VPC: 10.0.0.0/16

AZ-A: ├── Public Subnet: 10.0.1.0/24 ├── Private Subnet: 10.0.11.0/24 └── Database Subnet: 10.0.21.0/24

AZ-B: ├── Public Subnet: 10.0.2.0/24 ├── Private Subnet: 10.0.12.0/24 └── Database Subnet: 10.0.22.0/24 `

ルーティングとゲートウェイ

仮想ネットワーク内外の通信は、ルートテーブルによって制御されます。各サブネットは、トラフィックの送信先を決定するルートテーブルに関連付けられます。

主要なゲートウェイ

インターネットゲートウェイ：

パブリックサブネットのリソースとインターネット間の通信
水平スケーラブルで高可用性
送信・受信の両方向に対応

NATゲートウェイ/NATインスタンス：

プライベートサブネットからのアウトバウンド通信
インバウンド接続は受け付けない
セキュリティを維持しながら外部通信を実現

VPNゲートウェイ：

オンプレミスとの安全な接続
IPsecトンネルによる暗号化
冗長化による高可用性

2.3 多層防御によるネットワークセキュリティ

多層防御の実装戦略

クラウドのネットワークセキュリティは、複数の層で実装されます。各層は異なる特性を持ち、組み合わせることで堅牢な防御を実現します。

セキュリティグループ：インスタンスレベルの防御

セキュリティグループは、仮想ファイアウォールとして機能し、インスタンスレベルでトラフィックを制御します。

重要な特徴：

ステートフル：許可した接続の戻りトラフィックは自動的に許可
デフォルト拒否：明示的に許可したトラフィックのみ通過
許可ルールのみ：拒否ルールは設定できない
複数適用可能：1つのインスタンスに複数のセキュリティグループを適用
動的更新：変更が即座に反映される

ネットワークACL：サブネットレベルの防御

ネットワークACL（Access Control List）は、サブネット境界でトラフィックを制御します。

特徴：

ステートレス：インバウンドとアウトバウンドを個別に設定
順序処理：ルール番号順に評価
許可・拒否両方：明示的な拒否ルールが設定可能
サブネット単位：サブネット全体に適用

効果的な使い分け

セキュリティグループの適用場面：

アプリケーション固有のアクセス制御
動的な環境での柔軟なルール管理
開発・テスト環境での迅速な変更

ネットワークACLの適用場面：

より広範な制御が必要な場合
特定のIPアドレスやポートを明示的に拒否
サブネット全体に適用される共通のルール
コンプライアンス要件による明示的な拒否

実践的な設計パターン

最小権限の原則の実装

必要最小限のポートとプロトコルのみを許可し、送信元も可能な限り限定します。

例：3層アーキテクチャのセキュリティ設計

` Web層セキュリティグループ:

インバウンド: 0.0.0.0/0からHTTPS(443)
アウトバウンド: App層セキュリティグループに対してHTTP(8080)

App層セキュリティグループ:

インバウンド: Web層セキュリティグループからHTTP(8080)
アウトバウンド: DB層セキュリティグループに対してMySQL(3306)

DB層セキュリティグループ:

インバウンド: App層セキュリティグループからMySQL(3306)
アウトバウンド: なし `

動的なセキュリティグループ参照

IPアドレスではなく、セキュリティグループIDを参照することで、動的な環境でも一貫したセキュリティを維持できます。

利点：

インスタンスのIPアドレス変更に対応
Auto Scalingグループでの自動適用
管理の簡素化

高度なセキュリティ機能

WAF（Web Application Firewall）の統合

レイヤー7の攻撃から保護するため、多くのクラウドプロバイダーはマネージドWAFサービスを提供しています。

保護対象：

SQLインジェクション
クロスサイトスクリプティング（XSS）
HTTP Flood攻撃
ボット攻撃

実装パターン： ` インターネット → WAF → ロードバランサー → アプリケーション `

DDoS保護

基本的なDDoS保護は多くの場合無料で提供されますが、より高度な保護には追加サービスが必要です。

保護レベル：

Layer 3/4保護：ネットワーク層の攻撃を吸収
Layer 7保護：アプリケーション層の攻撃を検知・緩和
リアルタイム監視：攻撃の検知と自動的な対応

2.4 IAMを中心とした包括的なアクセス制御

IAMがクラウドセキュリティの中核である理由

クラウド環境では、従来の物理的なセキュリティ境界が存在しません。代わりに、アイデンティティが新しい境界となります。IAMは、この新しいセキュリティパラダイムの中心的な役割を果たします。

認証と認可の分離

IAMは、「誰であるか」（認証）と「何ができるか」（認可）を明確に分離します。この分離により、きめ細かなアクセス制御が可能になり、最小権限の原則を効果的に実装できます。

IAMの構成要素

ユーザー

個人を表すエンティティです。各ユーザーは一意の認証情報を持ち、コンソールアクセスやAPIアクセスが可能です。

特徴：

長期的な認証情報（パスワードやアクセスキー）
直接的なポリシー付与が可能
MFA（多要素認証）の設定が可能

管理上の注意点：

定期的なパスワード変更
不要になったユーザーの削除
アクセスキーの適切な管理

グループ

ユーザーの集合で、共通の権限を付与するために使用します。

設計原則：

組織構造や職務に基づく設計
権限の階層化
管理の簡素化

実践例： ` Developers グループ:

開発環境への読み書きアクセス
本番環境への読み取り専用アクセス

Administrators グループ:

全環境への完全アクセス
IAM管理権限

ReadOnly グループ:

全リソースへの読み取り専用アクセス `

ロール

一時的な権限のセットで、信頼関係に基づいて引き受けることができます。

特徴：

長期的な認証情報を持たない
一時的なセキュリティトークンを発行
クロスアカウントアクセスに対応

主要な用途：

サービス間の権限委譲
他のAWSアカウントとの連携
一時的な権限昇格

ポリシー

JSON形式で記述される権限の定義です。

構成要素：

Effect：許可（Allow）または拒否（Deny）
Action：実行可能な操作
Resource：対象となるリソース
Condition：追加の制約条件

ポリシー例： json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::my-bucket/*", "Condition": { "StringEquals": { "s3:x-amz-server-side-encryption": "AES256" } } } ] }

実践的なIAM設計

階層的な権限モデル

組織の構造を反映した権限モデルを設計します：

組織レベル：

全体的なガバナンスとコンプライアンス
セキュリティポリシーの統一
監査とレポーティング

アカウントレベル：

環境（本番、開発、テスト）の分離
部門やプロジェクトの分離
請求の分離

リソースレベル：

個別のリソースへのアクセス制御
詳細な権限管理
条件付きアクセス

職務分離の実装

重要な操作には複数の承認を要求し、単一の個人が過度な権限を持つことを防ぎます。

実装例：

本番環境へのデプロイ権限とその承認権限の分離
セキュリティ設定の変更と承認の分離
監査ログへのアクセス権限の分離

条件付きアクセス

時間、場所、デバイスなどの条件に基づいてアクセスを制限します。

実装例： json { "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }, "DateGreaterThan": { "aws:CurrentTime": "2023-01-01T00:00:00Z" }, "Bool": { "aws:MultiFactorAuthPresent": "true" } } }

IAMのベストプラクティス

定期的な権限の見直し

アクセスレビュー：

四半期ごとの権限監査
使用されていない権限の削除
過剰な権限の特定と修正

自動化ツール：

AWS Access Analyzer
IAM Credential Report
第三者製の権限分析ツール

自動化の活用

Infrastructure as Code：

CloudFormation、Terraform等でIAM設定を管理
バージョン管理とレビュープロセス
環境間の一貫性確保

継続的な監視：

CloudTrailによる操作ログの記録
異常なアクセスパターンの検知
アラートとインシデント対応

2.5 リソース管理とガバナンスの確立

リソース管理の戦略的重要性

クラウドの柔軟性は諸刃の剣です。簡単にリソースを作成できる一方で、管理されていないリソースが急速に増加し、「リソースのスプロール」と呼ばれる状態に陥ります。

リソースのスプロールが引き起こす問題：

コストの増大：使用されていないリソースによる無駄な支出
セキュリティリスク：管理されていないリソースの脆弱性
運用の複雑化：把握できないリソースによる運用負荷
コンプライアンス違反：規制要件を満たさないリソースの存在

タグ付け戦略の体系的設計

タグは、リソースに付与するメタデータで、キーと値のペアで構成されます。効果的なタグ付け戦略は、組織のニーズを反映した体系的なアプローチが必要です。

必須タグの定義

すべてのリソースに付与すべき基本的なタグ：

Environment（環境）：

値：production, staging, development, testing
用途：環境別の管理とコスト分析

Owner（所有者）：

値：責任者のメールアドレスやチーム名
用途：連絡先の明確化とアカウンタビリティ

CostCenter（コストセンター）：

値：会計処理のための識別子
用途：部門別のコスト配分

Project（プロジェクト）：

値：関連するプロジェクトやアプリケーション名
用途：プロジェクト別のリソース管理

CreatedDate（作成日）：

値：リソースの作成日時
用途：リソースの年齢分析と清掃

用途別の拡張タグ

Compliance（コンプライアンス）：

値：PCI-DSS, GDPR, SOX等の規制要件
用途：コンプライアンス監査とレポート

Backup（バックアップ）：

値：daily, weekly, monthly, none
用途：自動バックアップポリシーの適用

Maintenance（メンテナンス）：

値：メンテナンスウィンドウの定義
用途：自動メンテナンスのスケジューリング

タグの戦略的活用

コスト配分とチャージバック

タグを使用して、部門やプロジェクトごとのコストを正確に追跡できます。

実装例： ` 月次コストレポート: ├── Marketing部門: $15,000 │ ├── WebサイトProject: $8,000 │ └── CampaignProject: $7,000 ├── Engineering部門: $25,000 │ ├── ProductionEnvironment: $18,000 │ └── DevelopmentEnvironment: $7,000 └── 未分類: $2,000 (要改善) `

自動化とオーケストレーション

タグを条件として、自動化スクリプトやポリシーを適用できます。

実装例： `bash

開発環境の自動停止

aws ec2 stop-instances –instance-ids $( aws ec2 describe-instances
–filters “Name=tag:Environment,Values=development”
–query ‘Reservations[].Instances[].InstanceId’
–output text ) `

きめ細かなアクセス制御

IAMポリシーでタグを条件として使用し、詳細なアクセス制御を実現できます。

ポリシー例： json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-west-2" }, "ForAllValues:StringEquals": { "aws:PrincipalTag:Department": "${aws:RequestedTag:Department}" } } } ] }

リソースのライフサイクル管理

プロビジョニング標準の確立

リソース作成時の標準化により、一貫したガバナンスを実現します。

標準化項目：

命名規則：リソース名の統一フォーマット
必須タグ：すべてのリソースに必要なタグ
セキュリティ設定：基本的なセキュリティ設定
監視設定：標準的な監視とアラート

Infrastructure as Codeによる強制： `yaml

CloudFormationテンプレート例

Resources: WebServer: Type: AWS::EC2::Instance Properties: ImageId: ami-0123456789abcdef0 InstanceType: t3.micro Tags: - Key: Name Value: !Sub “${ProjectName}-${Environment}-web” - Key: Environment Value: !Ref Environment - Key: Project Value: !Ref ProjectName - Key: Owner Value: !Ref Owner `

定期的な棚卸しと清掃

未使用のリソースを定期的に特定し、削除または最適化します。

清掃対象の特定：

長期間停止しているインスタンス
接続されていないEBSボリューム
使用されていないElastic IP
古いスナップショット

自動化スクリプト例： `python import boto3 from datetime import datetime, timedelta

def identify_unused_resources(): ec2 = boto3.client(‘ec2’)

# 1週間以上停止しているインスタンス
week_ago = datetime.now() - timedelta(days=7)

stopped_instances = ec2.describe_instances(
    Filters=[
        {'Name': 'instance-state-name', 'Values': ['stopped']},
        {'Name': 'launch-time', 'Values': [f'*{week_ago.strftime("%Y-%m-%d")}*']}
    ]
)

return stopped_instances `

組織的なガバナンス

クラウドセンターオブエクセレンス（CCoE）

多くの組織では、クラウドのベストプラクティスを推進する専門チームを設置しています。

CCoEの責任：

標準策定：タグ付け標準、命名規則、セキュリティ基準
ツール選定：ガバナンスツール、自動化ツール
教育・訓練：ベストプラクティスの普及
監視・監査：コンプライアンスの確保

継続的な改善

リソース管理は一度設定すれば終わりではありません。

改善サイクル：

現状分析：リソース使用状況の定期的な分析
問題特定：非効率性やリスクの発見
対策実施：プロセスやツールの改善
効果測定：改善の効果を測定
標準更新：学習した内容を標準に反映

まとめ：クラウドアーキテクチャの基盤

この章では、クラウドインフラの共通概念とアーキテクチャの基盤を学びました。

重要なポイント：

リージョン・AZによる可用性とパフォーマンスの最適化
仮想ネットワークによる論理的な分離とセキュリティ
多層防御によるネットワークセキュリティの実装
IAMを中心とした包括的なアクセス制御
タグ付けによるリソース管理とガバナンス

実装における成功要因：

設計段階での十分な計画と検討
セキュリティファーストの思想
自動化による一貫性の確保
継続的な監視と改善

運用上の考慮事項：

変更管理プロセスの確立
定期的な見直しと最適化
組織的なガバナンス体制の構築
教育・訓練による知識の普及

次章への展開：第3章では、これらの基盤概念を踏まえて、実際のコンピュートリソース（仮想マシン）の設計・構築・運用について詳しく学びます。

自己点検ポイント

リージョン・AZの選択基準と可用性戦略を説明できるか

効果的な仮想ネットワーク設計の原則を理解しているか

多層防御によるネットワークセキュリティを実装できるか

IAMによる包括的なアクセス制御を設計できるか

タグ付け戦略によるリソース管理を実践できるか