AWS認定資格 攻略②|典型アーキテクチャパターン・DR戦略・ハイブリッド接続完全ガイド
AWS認定資格対策の第2回です。合否を分ける典型シナリオ・アーキテクチャパターン、災害復旧(DR)戦略、ハイブリッドクラウド接続、データ移行戦略を扱います。
典型シナリオ&アーキテクチャパターン
パターンA:高可用性と耐障害性(ステートレスWebアプリ)
Route 53 → CloudFront(エッジキャッシュ&DDoS対策) → ALB → Multi-AZのEC2/ECS Auto Scaling → Aurora/RDS(Multi-AZ、自動フェイルオーバー) + ElastiCache(セッション管理&DB負荷軽減)
パターンB:スパイク負荷を吸収する非同期処理(疎結合化)
フロントエンド(API Gateway/EC2) → SQSキュー(スパイク負荷を吸収) → バックエンドEC2(Auto Scaling)/Lambda → DynamoDB/S3
ポイント:バックエンドのAuto Scalingポリシーは「CPU使用率」ではなく、SQSのキューの深さ(ApproximateNumberOfMessagesVisible)を指標にする。
パターンC:オンプレミスとAWSのハイブリッド接続
- コスト最優先/導入スピード:AWS Site-to-Site VPN(IPsec、インターネット経由、暗号化あり)
- 広帯域/安定した専用線:AWS Direct Connect(DX)(インターネットを経由しない専用回線)
- 多数のVPCとオンプレミスの相互接続:AWS Transit Gateway(ハブ&スポーク型でネットワークを簡素化)
災害復旧(DR)戦略の完全比較
DR戦略は「RTO(目標復旧時間)」「RPO(目標復旧時点)」「コスト」のトレードオフです。
| 戦略 | 仕組み・構成 | RTO/RPO | コスト | 選択基準 |
|---|---|---|---|---|
| ①バックアップ&リストア | データを別リージョンへ定期バックアップ。発災後にゼロからインフラ構築。 | 数時間〜数日 | 最安 | コスト最優先、数時間のダウンタイム許容 |
| ②パイロットライト | コアDBのみ別リージョンで常時稼働&同期。発災時にWeb/APをプロビジョニング。 | 10分〜数時間 | 低〜中 | DBは常時同期、通常時のインフラ費用は最小限 |
| ③ウォームスタンバイ | 本番環境の最小縮小版を別リージョンで常に稼働。発災時にAuto Scalingで拡大。 | 数分 | 中〜高 | 数分以内の迅速なフェイルオーバー、フル待機コストは回避 |
| ④マルチサイト(Active-Active) | 複数リージョンで本番規模を常時フル稼働。Route 53でリアルタイム分散。 | ほぼゼロ | 最高 | 一切の停止を許容しないミッションクリティカル |
ハイブリッドクラウド&高度なネットワーク設計
| 要件 | 最適なサービス・構成 |
|---|---|
| 数十〜数百のVPCとオンプレミスを相互接続 | AWS Transit Gateway(ハブ&スポーク構成) |
| VPC間を1対1でセキュアに接続 | VPC Peering(推移的ルーティング不可) |
| パブリックIPなしでEC2へセキュアにSSH/RDP接続 | AWS Systems Manager Session Manager(踏み台不要、ポート開放不要) |
| アウトバウンドトラフィックを集中管理・検査 | Transit Gateway+検査用VPC(AWS Network Firewall) |
| オンプレミス環境でAWSインフラをそのまま動かす | AWS Outposts(超低レイテンシー) |
Direct Connect(DX)とVPNの組み合わせ:①DX+バックアップVPN(平時はDX、障害時にVPNへ自動切替) / ②DX+VPN(専用線をさらにエンドツーエンドで暗号化、金融・医療等の高セキュリティ要件)
データ移行&ストレージ統合戦略
データ移行の判断フロー:10TB未満はインターネット/Direct Connect経由(AWS DataSync)。10TB以上でネットワーク帯域がボトルネックなら、数十〜数百TBはAWS Snowball Edge(物理配送)、数PB以上はAWS Snowmobile。
- AWS DataSync:オンプレミスのNFS/SMBストレージとS3/EFS/FSx間で大容量データを高速・自動で並列転送・同期。
- AWS DMS:稼働中DBのダウンタイムを最小限に抑えて移行。同種移行(MySQL→Aurora MySQL)はDMS単体。異種移行(Oracle→Aurora PostgreSQL)はAWS SCTでスキーマ変換後にDMSでデータ移行。
- AWS Storage Gatewayの3タイプ:ファイルゲートウェイ(S3を透過的に利用)/ボリュームゲートウェイ(保管型・キャッシュ型)/テープゲートウェイ(物理テープをGlacierで置き換え)
高度なセキュリティ・IAM・ガバナンス設計
IAMポリシーの評価論理:明示的な拒否(Deny)があれば拒否 → なければ明示的な許可(Allow)があれば許可 → どちらもなければデフォルト拒否(Implicit Deny)。ポリシーのどこかに1箇所でもDenyがあれば、他のすべてのAllowは上書きされアクセスは拒否されます。
- IAMロールの引き受け(sts:AssumeRole):アカウントAのユーザーがアカウントBのリソースを操作する際、長期的なアクセスキーではなく一時的なセキュリティ認証情報を発行。
- リソースベースポリシー:S3バケットポリシーやKMSキーポリシーはリソース側に直接付与でき、クロスアカウントアクセス時にロール引き受けなしで直接アクセスを許可できる。
- AWS Control Tower:ベストプラクティスに基づいたマルチアカウント環境(Landing Zone)を数クリックで自動セットアップ。
次回は「ひっかけ問題対策・本番模擬演習」編で、典型的な罠の見抜き方と本番レベルのケーススタディ5問を扱います。
コメント
コメントを投稿