00-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

001-ハイブリッドDNSソリューション

理論

1. Amazon Route 53 の基本知識

Route 53 は、AWS が提供するDNSサービスで、パブリックおよびプライベートなドメイン名解決をサポートします。

Private Hosted Zone

VPC 内のリソースに対するドメイン名解決を提供します。
特定の VPC に関連付けることで、その VPC 内でのみ利用可能になります。
インターネットからはアクセスできず、プライベート環境での使用を目的としています。
例：

Private Hosted Zone を cloud.example.com というドメインで作成。
db.cloud.example.com という名前を VPC 内の EC2 インスタンスのプライベートIP（例：10.0.0.12）に関連付けます。

Inbound Resolver と Outbound Resolver

Inbound Resolver：オンプレミスから AWS 内部の DNS サービス（Private Hosted Zoneなど）にクエリを送るために使用します。
Outbound Resolver：VPC 内部から外部（オンプレミスやインターネット）の DNS サービスにクエリを送るために使用します。
使用例：

Inbound Resolver はオンプレミスのシステムが AWS 内のプライベートリソースにアクセスするために必要です。
Outbound Resolver は AWS リソースがオンプレミスのリソースやインターネット上のドメインを解決する際に使用します。

2. AWS ネットワーキングの基本知識

AWS のネットワーク構成やハイブリッドクラウドでの接続方法について理解しておく必要があります。

VPC（Virtual Private Cloud）

AWS 内で定義される仮想ネットワークで、独立したネットワーク空間を提供します。
リソース（例：EC2やRDS）は VPC 内でプライベートIPを使用して通信します。

Transit Gateway

複数の VPC やオンプレミスネットワークを接続するための中央ハブとなるサービスです。
高性能かつ低レイテンシーでネットワーク間通信を可能にします。
ルーティングテーブルを使用してトラフィックの管理を行います。
使用例：

VPC-A、VPC-B、オンプレミスネットワークを Transit Gateway 経由で接続し、DNS サービスを共有可能にします。

Direct Connect

オンプレミスのデータセンターと AWS を専用線で接続するサービスです。
高帯域幅かつ低レイテンシーで通信可能です。

3. DNS の基本知識

DNS の仕組みやハイブリッドクラウドにおける応用を理解する必要があります。

DNS 解決の種類

正引き（Forward Resolution）：ドメイン名 → IPアドレス（例：cloud.example.com → 10.0.0.12）。
逆引き（Reverse Resolution）：IPアドレス → ドメイン名（例：10.0.0.12 → db.cloud.example.com）。

条件付きフォワーディング（Conditional Forwarding）

オンプレミスの DNS サーバーに特定のドメイン（例：cloud.example.com）のクエリを特定の DNS サーバー（例：Route 53 Inbound Resolver）に転送するルールを設定します。

4. アーキテクチャ設計のベストプラクティス

ハイブリッドDNSソリューションの要件を満たすため、最適なアーキテクチャを選ぶための知識。

要件分析：

オンプレミスシステムが AWS 内部のドメインを解決できること（Inbound Resolver が必要）。
VPC 全体で DNS 解決を共有できること（Private Hosted Zone の正しい関連付け）。
高性能で管理が簡単なアーキテクチャを選択すること。

効率的なソリューションの特徴：

Private Hosted Zone は全ての必要な VPC に関連付けられるべき。
Inbound Resolver を使用してオンプレミスネットワークからアクセス可能にする。
Transit Gateway を使用して、複数の VPC 間およびオンプレミスネットワークとの通信を簡素化する。

必要な知識の要約

Route 53：Private Hosted Zone の用途、Inbound Resolver の役割。

AWS ネットワーク：VPC、Transit Gateway、Direct Connect の役割と接続方法。

DNS：正引き、条件付きフォワーディングの概念と設定方法。

アーキテクチャ設計の原則：パフォーマンスが高く、管理しやすい構成を選択するスキル。

これらを理解していると、効率的に最適解を選べるようになります。

実践

以下は、Amazon Route 53 Private Hosted Zone の基本的なハンズオン演習の設計です。このハンズオンは、Route 53 Private Hosted Zone の作成、設定、検証を通じて、DNS解決の仕組みを理解し、オンプレミス環境との統合を体験することを目的としています。

目標

Route 53 Private Hosted Zone を作成し、VPC に関連付ける。

EC2 インスタンスに対するプライベートドメイン名を設定し、DNS 解決を検証する。

条件付きフォワーディングを設定し、オンプレミスシステムからアクセス可能にする。

ハンズオンの前提条件

AWS アカウントを持っている。

AWS マネジメントコンソールにアクセス可能。

基本的な VPC や EC2 インスタンスの知識がある。

オンプレミスの代替として使用できるクライアント環境（例：ローカルPC、または別のVPCからアクセス可能なEC2インスタンス）を準備。

演習の構成

ステップ 1: 基本設定

VPC の作成

AWS マネジメントコンソールで VPC を作成。

CIDR ブロック例：10.0.0.0/16

1つのパブリックサブネット（例：10.0.1.0/24）とプライベートサブネット（例：10.0.2.0/24）を作成。

EC2 インスタンスの起動

パブリックサブネットに 1 台の EC2 インスタンスを起動（Bastion ホストとして利用）。

プライベートサブネットに 1 台の EC2 インスタンスを起動（テスト用）。

各インスタンスに適切なセキュリティグループ（SSH, DNS）を設定。

ステップ 2: Private Hosted Zone の作成

Route 53 で Hosted Zone を作成

ドメイン名例：cloud.example.com

Hosted Zone のタイプ：Private Hosted Zone

VPC をこの Hosted Zone に関連付ける。

DNS レコードの作成

app.cloud.example.com をプライベートサブネット内の EC2 インスタンスのプライベートIP（例：10.0.2.10）に関連付ける。

Hosted Zone の確認

プライベートサブネットの EC2 インスタンスで dig app.cloud.example.com を実行し、正しいIPアドレスが返されることを確認。

以下は、条件付きフォワーディングの設定手順を分かりやすく整理したものです。

ステップ 4: Inbound Resolver

1: オンプレミス環境の設定

オンプレミス環境を準備

別の VPC またはローカルPCを「オンプレミスシステム」として使用します。

Route 53 Inbound Resolver の作成

VPC 内に Inbound Resolver Endpoint を作成し、DNS クエリを受け付けるエンドポイントを構成します。

2: EC2 上での DNS フォワーディング設定

DNS サービスのインストール（例: BIND）

EC2の送信元/送信先チェックを変更をオフ

Amazon Linux 2023 上に、BIND9 または Unbound をインストールして、DNS フォワーディングを行います。

DNS フォワーディングの設定

BIND を使用して、DNS リクエストを Route 53 Inbound Resolver のプライベート IP アドレスに転送する設定を行います。

設定ファイル /etc/named.conf を開き、options セクションに forwarders 設定を追加します。

以下のように forwarders 設定を追加します（<Inbound Resolver IP アドレス> は実際の IP アドレスに置き換えてください）：

BIND サービスの起動と再起動

設定後、BIND サービスを起動して設定を反映させます。

サービスの状態を確認するには、以下のコマンドを使用します：

3: ローカルクライアントの設定

ローカルクライアントに DNS 設定を適用

自宅のコンピューターで、EC2 インスタンスを DNS サーバーとして設定します。

DNS クエリの検証

nslookup または dig を使用して、DNS クエリが EC2 インスタンスを経由して Route 53 Inbound Resolver に転送されるかを確認します。

設定が正しく行われていれば、app.cloud.example.com の DNS クエリに対して正しい結果が返されます。

これで、条件付きフォワーディングの設定が完了します。

ステップ 4: 拡張オプション

1. 複数VPCの統合

Transit Gatewayの作成と接続

Transit Gatewayを作成し、各VPCをTransit Gatewayにアタッチ。

ルーティングの設定

外部VPCのパブリックサブネットのEC2から、共有サービスVPCのプライベートサブネットのEC2にSSHアクセスを実現するため、下記を設定
ルートテーブルの更新

VPC1とVPC2のそれぞれのルートテーブルに、対向VPCへのルートを追加し、Transit Gatewayをターゲットとする。

例:

VPC1のCIDR：10.0.0.0/16
VPC2のCIDR：10.1.0.0/16
Transit Gateway ID：tgw-xxxxxxxx

VPC1のルートテーブル:

Destination: 10.1.0.0/16
Target: tgw-xxxxxxxx

VPC2のルートテーブル:

Destination: 10.0.0.0/16
Target: tgw-xxxxxxxx

Private Hosted Zoneの共有

Private Hosted Zoneを使用して、二つのVPC間でDNSゾーンを共有。

2. Outbound Resolverの設定、テスト

Outbound Resolver Endpointの作成

AWS内からインターネット上のドメインを解決するために、Outbound Resolver Endpointを共有サービスVPCのプライベートサブネットに作成。
外部VPCパブリックサブネットEC2から、SSHで、共有サービスVPCのプライベートサブネットEC2にログイン

ｗｗｗ.example.comで、インタネットDNS解決したかをテスト

4. ログとモニタリング

クエリログの有効化

Route 53のクエリログをCloudWatch Logsに記録し、クエリの動作をモニタリング。

まとめ

このガイドを通じて学べる内容：

Route 53 Private Hosted Zone の設定と動作確認。

Inbound Resolver の設定によるAWSとオンプレミスのDNS統合。

Outbound Resolver の設定。

Transit Gateway 経由での複数VPC間の接続およびDNSゾーンの共有。

ルートテーブルの設定 によるVPC間通信の実現。

これにより、Route 53を活用したハイブリッドDNSソリューションの設計と構築スキルを習得できます。

一門道場

AWS ハイブリッドDNSソリューション設計に関する問題

目的はオンプレミスのシステムとAWSのVPC間で cloud.example.com ドメインを解決可能にすること。

前提条件

Private Hosted Zone を使用して、VPC内リソースのための cloud.example.com ドメインを設定する。

オンプレミスのシステムが cloud.example.com を解決・接続できる必要がある。

すべてのVPCが cloud.example.com を解決可能である必要がある。

AWS Direct Connect を介してオンプレミスとAWS Transit Gatewayが接続されている。

選択肢

Private Hosted Zone をすべてのVPCに関連付ける。
共有サービスVPCに Route 53 Inbound Resolver を作成する。
すべてのVPCを Transit Gateway に接続し、オンプレミスのDNSサーバーで転送ルールを設定して Inbound Resolver に向ける。

Private Hosted Zone をすべてのVPCに関連付ける。
共有サービスVPCに Amazon EC2 Conditional Forwarder をデプロイする。
すべてのVPCを Transit Gateway に接続し、オンプレミスのDNSサーバーで転送ルールを設定して Conditional Forwarder に向ける。

Private Hosted Zone を共有サービスVPCに関連付ける。
共有サービスVPCに Route 53 Outbound Resolver を作成する。
すべてのVPCを Transit Gateway に接続し、オンプレミスのDNSサーバーで転送ルールを設定して Outbound Resolver に向ける。

Private Hosted Zone を共有サービスVPCに関連付ける。
共有サービスVPCに Route 53 Inbound Resolver を作成する。
共有サービスVPCを Transit Gateway に接続し、オンプレミスのDNSサーバーで転送ルールを設定して Inbound Resolver に向ける。

選択肢の解説

Option A: 最適解

設計意図:

Private Hosted Zone をすべてのVPCに関連付けることで、全VPCが cloud.example.com のDNSレコードを解決可能。

Route 53 Inbound Resolver を使用して、オンプレミスのDNSサーバーからのクエリをPrivate Hosted Zoneへ転送。

Transit Gateway を利用し、すべてのVPCとオンプレミスのネットワーク間の通信を一元化。

オンプレミスのDNSサーバーに、cloud.example.com を Inbound Resolver に転送するルールを設定。

メリット:

高パフォーマンス: Inbound Resolver は、専用設計されており、スケーラブルかつ効率的にクエリを処理可能。

管理の簡素化: Transit Gatewayを使うことで、すべてのVPCとオンプレミス間の接続を一元的に管理。

コスト効率: 他の選択肢と比較して、専用のEC2インスタンスを必要とせず運用負荷が低い。

想定される利用フロー:

オンプレミス → DNSクエリ → Inbound Resolver (共有サービスVPC) → Private Hosted Zone。

VPC内のリソース → Private Hosted Zone → クエリ解決。

Option B: Conditional Forwarder 使用

設計意図:

Private Hosted Zone をすべてのVPCに関連付け。

共有サービスVPC内に Amazon EC2 Conditional Forwarder を展開。

オンプレミスのDNSサーバーに cloud.example.com を Conditional Forwarder に転送するルールを設定。

メリット:

ある程度のパフォーマンスを確保可能。

AWS内に直接 Conditional Forwarder を設置できるため、オンプレミスからAWSリソースへのクエリは可能。

デメリット:

Conditional ForwarderはEC2インスタンス上で稼働するため、スケーラビリティや耐障害性がRoute 53 Resolverに劣る。

運用負荷: EC2インスタンスの管理が必要。

コスト: EC2インスタンスにかかる追加費用。

Option C: Outbound Resolver 使用

設計意図:

Private Hosted Zone を共有サービスVPCに関連付け。

共有サービスVPC内に Route 53 Outbound Resolver を作成。

オンプレミスのDNSサーバーに、cloud.example.com を Outbound Resolver に転送するルールを設定。

メリット:

VPC内リソースから外部DNSサーバー（オンプレミスなど）へのリクエストは可能。

デメリット:

Outbound Resolver は外部へのクエリ転送が目的であり、オンプレミスからAWSのPrivate Hosted Zoneへのクエリ解決には適さない。

要件を満たさない設計であるため、選択肢として不適。

Option D: Inbound Resolver + 共有サービスVPC接続

設計意図:

Private Hosted Zone を共有サービスVPCに関連付け。

共有サービスVPC内に Route 53 Inbound Resolver を作成。

共有サービスVPCのみを Transit Gateway に接続し、オンプレミスDNSサーバーに Inbound Resolver への転送ルールを設定。

メリット:

Option Aと似た構成であり、要件の大部分を満たす。

デメリット:

Private Hosted Zoneを共有サービスVPCに限定するため、他のVPCが cloud.example.com を直接解決できない。

各VPCから共有サービスVPCへのDNSクエリの中継が必要となり、パフォーマンスが低下する可能性がある。

結論: なぜOption Aが最適なのか

設計の完全性:

全VPCが直接 Private Hosted Zone を解決可能。

オンプレミスからのリクエストも Inbound Resolver により効率的に処理。

パフォーマンス:

Inbound Resolver は高いスケーラビリティを持ち、EC2ベースのConditional Forwarderに比べてDNSクエリの処理が迅速。

運用効率:

EC2管理が不要で、Route 53サービス内でクエリが完結する。

Transit Gatewayにより、オンプレミスとすべてのVPC間の接続が一元化。

コスト:

EC2インスタンスを利用しないため、Option Bよりコスト効率が良い。

このため、Option AがこのハイブリッドDNSソリューションで最もパフォーマンスが高く、運用負荷の少ない解決策となります。

002-高可用性API設計

理論

ハンズオン前の前提知識整理

AWSを利用してAPIの高可用性と災害復旧（DR）を実現するためには、いくつかのサービスや概念を理解しておく必要があります。本記事では、その基礎知識を整理します。

高可用性イメージ図

1. フェイルオーバーとは

フェイルオーバーとは、システム障害が発生した際に別のリソースに切り替えるプロセスです。AWSでは、複数のリージョン（地理的エリア）を活用してフェイルオーバー構成を構築します。

これにより、災害や障害時にもサービスを継続的に提供できます。

2. Amazon API Gateway

概要

Amazon API Gatewayは、RESTやWebSocket APIをホストするためのマネージドサービスです。サーバーを管理する必要がなく、バックエンドをLambda関数やDynamoDBなどに接続できます。

フェイルオーバーでの活用

複数リージョンにデプロイ：API Gatewayを各リージョンに展開することで、障害時の切り替えを容易にします。

エンドポイントの種類：

リージョン API （エンドポイント）：特定のリージョンに固定されたエンドポイント。
エッジ最適化 API （エンドポイント）：グローバル配信に適したエンドポイント。
プライベート API：プライベート API には VPC からのみアクセスできます。

3. AWS Lambda

概要

AWS Lambdaは、イベント駆動型でコードを実行するサーバーレスコンピューティングサービスです。

応用例

ライフサイクル

フェイルオーバーでの活用

各リージョンで同じLambda関数をデプロイし、API Gatewayから呼び出します。

バックエンドロジックを柔軟に構築可能。

4. Amazon DynamoDB

概要

DynamoDBは、NoSQL型のフルマネージドデータベースサービスです。

LSIとGSIの違い：

LSI（ローカルセカンダリインデックス）

Partition Key は元のテーブルと同じ。

Sort Key のみをカスタマイズ可能。

クエリ時は必ず元の Partition Key を指定する必要がある。

パーティション内のデータに対する補助的な検索に使用される。

GSI（グローバルセカンダリインデックス）

Partition Key と Sort Key の両方を元のテーブルと独立して設定可能。

クエリ時に独自の Partition Key で検索可能。

テーブル全体のデータに対する広範囲な検索に適している。

例え：

LSI は「ファイルキャビネットの中の引き出し（Partition Key）」内で「異なる仕切り（Sort Key）」を使って整理するイメージ。

GSI は「キャビネットとは別の場所に、自由に整理された新しいキャビネット」を設置するようなもの。

グローバルテーブル

DynamoDBのグローバルテーブルを利用すると、データを複数のリージョン間で自動的に同期できます。

高可用性を実現するために必要な設定。

5. Amazon Route 53

概要

Route 53は、DNS（ドメイン名システム）のマネージドサービスで、トラフィックのルーティングを制御します。

重要な設定

フェイルオーバーレコード：

プライマリとセカンダリのエンドポイントを定義し、プライマリが障害を検出した際にセカンダリへ切り替え。

ターゲットヘルスモニタリング：

エンドポイントの稼働状況を監視し、障害検出をサポート。

6. 高可用性API構築の基本ステップ

複数リージョンへのデプロイ

API GatewayとLambda関数を各リージョンにデプロイする。

DynamoDBのグローバルテーブル化

データの一貫性と可用性を確保するために設定。

Route 53でフェイルオーバー設定

フェイルオーバーレコードを利用して、障害発生時の自動切り替えを構築。

監視とテスト

障害時の切り替えが正常に動作するか、定期的にテストを実施。

まとめ

AWSのAPI Gateway、Lambda、DynamoDB、Route 53を組み合わせることで、フェイルオーバー対応の高可用性APIを設計できます。これらのサービスの特性を理解し、正しく設定することで、災害時にも信頼性の高いシステムを維持することが可能です。

次に、この知識を使って実際の構築に挑戦してみましょう！

実践

AWS サーバーレスアーキテクチャで高可用性APIを構築する

このハンズオンでは、AWSのサーバーレス技術を活用し、フェイルオーバー機能を持つ高可用性のAPIを構築します。具体的には、API Gateway、AWS Lambda、DynamoDB、およびRoute 53を使用して、2つのリージョンに跨る冗長化されたシステムを作成します。サーバーレスアーキテクチャの特性とその中核を成すAWSサービスの概要を学びながら、実際に手を動かしてその理解を深めることができます。

目標

API Gateway を使用して、サーバーレスREST APIを作成し、2つのAWSリージョンで冗長化。

AWS Lambda を使用して、APIのバックエンドロジックを実装。

Amazon DynamoDB のグローバルテーブルを使って、データの高可用性を確保。

Amazon Route 53 を利用し、DNSフェイルオーバー機能を実装。

使用するAWSサービス

AWS Lambda: サーバーレスコンピューティングサービス。バックエンドロジックをLambda関数で処理します。

Amazon API Gateway: REST APIを作成・管理するサービス。リクエストをLambda関数に転送します。

Amazon DynamoDB: NoSQLデータベース。データを格納し、グローバルテーブルでデータの冗長化を実現します。

Amazon Route 53: DNSサービス。フェイルオーバー機能を使用して、異常が発生した際に他のリージョンへ切り替えます。

ステップ 1: API GatewayでのREST API作成

基本的な使い方をおさらいください

手順概要

API Gateway操作画面でREST APIを作成

新規に下記のREST APIを作成する。

バックエンドはまだ用意されていないため、モック設定を使用。

マッピングテンプレートを設定

マッピングテンプレートに以下のコードを設定してモックレスポンスを返すようにする：

マッピングテンプレートとは、API Gatewayでリクエストやレスポンスのデータ形式を変換するための設定です。APIとクライアント（フロントエンド）やバックエンド間のデータのやり取りをカスタマイズするために使います。

APIをデプロイ

APIをステージにデプロイする（例: devステージ）。

デプロイしたエンドポイントにアクセス

ブラウザやPostmanなどのツールでAPIエンドポイントにリクエストを送信してレスポンスを確認。

これでモックAPIの基本的な構築と動作確認が完了します。

ステップ 2: Lambda関数の作成

基本的な使い方をおさらいください

手順概要

このスクリプトは、AWS Lambda関数をハンズオン形式で学習する際の説明動画の内容をもとにしていますね。以下に、話されている内容を整理しつつ、要点をまとめます：

実際の操作手順:

Lambdaサービスの選択

サービス検索バーで「Lambda」と入力して選択。

新しい関数の作成

一から作成するオプションを選択。

関数名（例: translater-function）を設定。

ランタイムはPython 3.9を選択。

IAMロールは自動生成を選択。

メモリやタイムアウトの設定変更

メモリを256MBに変更。

タイムアウトを5秒に設定。

保存ボタンを忘れずにクリック。

ログ設定の追加

ソースコードにloggingライブラリをインポート。

ロガーを設定し、イベント内容をログに出力。

保存してからテストを実行。

テストの実行と確認

サンプルイベントを作成。

実行結果を確認し、ログにイベントの中身が正しく出力されていることを確認。

ステップ 3: DynamoDBの設定

手順概要

1. DynamoDBテーブルの作成

テーブル名: TranslaterLogs

プライマリキー:

パーティションキー: Timestamp（ユニークな値として指定。例: APIが呼び出された時刻）。
Sort Keyは使用しない。

キャパシティ設定:

リード/ライトキャパシティを「1」に指定（オンデマンドは使用しない）。
セカンダリインデックスは設定しない。

2. データの手動追加

テーブル作成後、「項目の作成」ボタンをクリック。

データ項目: API呼び出し時の以下の情報を保存:

呼び出し時間

日本語の入力テキスト（Input Text）

翻訳結果の英語テキスト（Output Text）

以下の情報を入力:

Timestamp: 例: 202412051720

input_text: 例: ★こんにちは

output_text: 例: ★Hello

「保存」をクリックするとデータが追加される。

3. 注意点

Timestampはプライマリキーとしてユニークである必要がある。

環境によってテーブル作成に少し時間がかかる場合がある。

次回はLambdaを使ってDynamoDBにデータを挿入する処理を解説します。

ステップ 4: API GatewayとLambdaとDynamoDB 統合

1. 目的

Web API が呼び出された際に、その履歴情報を DynamoDB テーブルに保存するように Lambda Function を修正します。

2. 事前準備

既に作成した Lambda Function に対して修正を加え、DynamoDB テーブルにデータを追加する設定を行います。

3. 手順

Lambda Function の修正:

DynamoDB へのデータ追加には、AWS SDK を利用します。
DynamoDB テーブルを操作するために、PutItem メソッドを使用します。
PutItem では、API 呼び出し履歴として以下の情報をテーブルに保存します:

入力テキスト (inputText): API 呼び出し時の入力データ
出力テキスト (outputText): API 呼び出し結果
タイムスタンプ: 呼び出し時刻

以下のコードを Lambda Function に追加します：

修正したらdeployをしてください

4. IAM ロール設定

Lambda 関数に DynamoDB へのアクセス権限を付与します。DynamoDBFullAccess TranslateFullAccess ポリシーを IAM ロールに追加します。

ALambdaとDynamoDB の統合テスト

Lambda Function を修正後、テストイベント実行し、DynamoDB テーブルにアイテムが追加されているかを確認します。

テストイベント例

API Gatewayと統合

API GatewayのメソッドをMockからLambda 統合に変更する

統合テスト

URLでAPIにアクセス、翻訳の返答とDynamoDBにログが記録されたかを確認する

この手順で、Web API が呼び出されるたびにその履歴を DynamoDB に保存することができます。

拡張オプション

ステップ 5: 両リージョンでの高可用性構築

Aリージョンで作成済みの API Gateway、Lambda、DynamoDB を Bリージョンに同じ構成で作成します。

1. API Gateway、Lambda、DynamoDB の複製

Aリージョンで設定済みのリソースを、Bリージョンにもデプロイします。

API Gateway: 同じエンドポイント構成で作成。
Lambda: 同じコードと設定をデプロイ。
DynamoDB: 必要に応じてグローバルテーブルを利用し、データの同期を自動化。

2. Route 53でフェイルオーバー設定を構築

Route 53コンソールで新しいホストゾーンを作成します（例: weather.example.com）。

DNSレコードを設定：

プライマリレコード: Aリージョンの API Gateway エンドポイントを設定。
セカンダリレコード: Bリージョンの API Gateway エンドポイントを設定。

3. ヘルスチェックの有効化

ヘルスチェックを設定して、各 API Gateway エンドポイントの稼働状況を監視。

プライマリリージョンのエンドポイントがダウンした場合、自動的にセカンダリリージョンのエンドポイントにリクエストを切り替えます。

これにより、両リージョンでの高可用性が確保され、システムの冗長性と耐障害性が向上します。

ステップ 5: テスト

Postmanやcurlを使って、weather.example.com にリクエストを送信します。

リージョン 1が正常な場合、そのエンドポイントから応答が返ります。

リージョン 1を意図的に停止し、Route 53がフェイルオーバーして、リージョン 2から応答が返ることを確認します。

ハンズオンの成果

高可用性を持つサーバーレスREST APIの構築。

リージョン間のフェイルオーバー機能を実装。

DynamoDBグローバルテーブルによるデータの冗長化。

参照元：

こちらのリンクで確認できます。

一門道場

ある会社がRESTベースのAPIを通じて複数の顧客に天気データを提供しています。このAPIはAmazon API Gatewayでホストされており、各API操作ごとに異なるAWS Lambda関数と統合されています。会社はDNSにAmazon Route 53を使用しており、

というリソースレコードを作成しています。また、このAPIのデータはAmazon DynamoDBテーブルに保存されています。

会社は、このAPIを別のAWSリージョンにフェイルオーバーする能力を持たせる必要があります。

以下のどのソリューションがこの要件を満たしますか？

選択肢

A.

新しいリージョンにLambda関数をデプロイ。

API Gatewayをエッジ最適化エンドポイントに更新し、両リージョンのLambda関数をターゲットとして設定。

DynamoDBをグローバルテーブル化。

B.

新しいリージョンにAPI GatewayとLambda関数をデプロイ。

Route 53のDNSレコードをマルチバリューアンサーに変更し、両API Gatewayをアンサーに追加。マルチバリューアンサー (Multi-Value Answer) とは、AWS Route 53 のルーティングポリシーの一つで、DNS クエリに対して複数の値 (IP アドレスやエンドポイント) を返す仕組みを指します。

ターゲットヘルスモニタリングを有効化。

DynamoDBをグローバルテーブル化。

C.

新しいリージョンにAPI GatewayとLambda関数をデプロイ。

Route 53のDNSレコードをフェイルオーバーレコードに変更。

ターゲットヘルスモニタリングを有効化。

DynamoDBをグローバルテーブル化。

D.

新しいリージョンにAPI Gatewayをデプロイ。

Lambda関数をグローバル関数に変更。

Route 53のDNSレコードをマルチバリューアンサーに変更し、両API Gatewayをアンサーに追加。

ターゲットヘルスモニタリングを有効化。

DynamoDBをグローバルテーブル化。

解説：正解はC

1. 新しいリージョンにAPI GatewayとLambda関数をデプロイ

API GatewayとLambda関数を新しいリージョンに複製して冗長構成を確立。

高可用性を実現する基盤を構築。

2. Route 53のDNSレコードをフェイルオーバーレコードに変更

フェイルオーバーレコードを利用することで、プライマリリージョンに障害が発生した場合、自動的にセカンダリリージョンへトラフィックを切り替え可能。

3. ターゲットヘルスモニタリングを有効化

Route 53がプライマリリージョンのAPI Gatewayの状態を監視。

障害検知時に迅速な切り替えを実現。

4. DynamoDBをグローバルテーブル化

複数リージョンでのデータ同期を自動化し、一貫性を確保。

プライマリリージョンで書き込まれたデータがセカンダリリージョンでも即座に反映。

他の選択肢が不適切な理由

A. エッジ最適化エンドポイントを利用

問題点：フェイルオーバーを保証する仕組みがない。

B. マルチバリューアンサーを使用

問題点：フェイルオーバーではなく負荷分散向け。障害発生時に特定のリージョンを無効化できない。

D. Lambda関数をグローバル関数に変更

問題点：Lambdaに「グローバル関数」という設定は存在しない。

結論

選択肢Cが最適：

フェイルオーバー構成をAWSベストプラクティスに基づいて実現。

高可用性、データ一貫性、自動切り替えを確保でき、要件を満たします。

003-OrganizationsとSCP

理論

AWS OrganizationsとSCPの基礎知識

AWS Organizationsを利用すると、複数のAWSアカウントを1つの組織内で効率的に管理できます。特に、サービス制御ポリシー（Service Control Policy, SCP）を用いて、アカウントや組織単位（OU）のアクセス権を制限または許可することが可能です。SCPはAWSアカウント内で実行可能な最大権限を制限するものです。

1. AWS Organizationsの基本構造

AWS Organizationsには以下の要素があります：

ルート（Root）

組織全体のトップレベル。すべてのアカウントとOUがこのルートに属します。

OU（Organizational Unit）

アカウントをグループ化するための単位。OUに適用したSCPは、グループ内のすべてのアカウントに適用されます。

アカウント

実際にAWSリソースを使用するエンティティ。個々のアカウントにもポリシーが適用されます。

2. サービス制御ポリシー（SCP）

SCPはAWS Organizationsにおけるアクセス管理の重要なツールです。

特徴

許可リスト方式（Allow List SCP）

特定のサービスや操作を「許可」するポリシー。

デフォルトではすべてが拒否され、明示的に許可された操作のみ実行可能。

拒否リスト方式（Deny List SCP）

すべての操作がデフォルトで許可されており、特定のサービスや操作を「拒否」するポリシー。

限定的な制御が必要な場合に利用される。

適用範囲

SCPはアカウント単位ではなくOU単位で適用される。

IAMポリシーの制約を越えてアクセスを制限可能。

SCPで拒否された操作は、アカウントレベルのポリシーで許可されていても実行できない。

3. AWS ConfigとSCPの関係

AWS Configはリソースの構成監視やコンプライアンス管理を行うサービスです。AWS Configルールを使用すると、AWS環境が企業ポリシーに準拠しているかどうかを監視できます。

SCPでAWS Configのアクションが拒否されている場合、ルールの作成や更新が制限されます。

AWS Configを利用するには、関連するアクション（例: config:PutConfigRule）がSCPで許可されている必要があります。

4. ポイント

SCPの仕組み

SCPはIAMポリシーよりも優先される。

SCPで拒否された操作は、IAMポリシーやユーザー権限で上書きできない。

OUの役割

アカウントを一時的に別のOUに移動して独自のSCPを適用することで、特定のタスクを完了させられる。

AWS Configの動作

AWS Configのルールを更新するためには特定の権限が必要。

これらの権限がSCPで拒否されている場合、権限を一時的に許可する方法を検討する必要がある。

組織のポリシー管理のベストプラクティス

長期的な管理コストを抑えるため、SCPを頻繁に変更するのではなく、構造を工夫して一時的な変更を柔軟に行う。

まとめ

AWS OrganizationsとSCPの仕組みを理解し、問題の解決策を選ぶ際には以下を考慮する必要があります：

現在のポリシーをできるだけ変更せず、一時的に必要な権限を提供する。

長期的な管理負荷を増やさない。

AWS Configの要件を満たしながら、既存のセキュリティ基準を維持する。

実践

ハンズオン：費用かかる為、今後作成する予定

一問道場

問題AWS Organizationsでのアクセス制御とSCP（Service Control Policies）。

背景:

企業は「Production」という1つのOUで複数のAWSアカウントを管理している。

組織のルートに拒否リストベースのSCPを適用しており、特定サービスへのアクセスを制限している。

新規ビジネスユニットのアカウントを追加した際、そのアカウントではAWS Configルールを更新できない問題が発生した。

選択肢

A

SCPからAWS Configへのアクセス制限を削除。

AWS Service Catalogを利用して標準のAWS Configルールを全アカウントに展開。

B

新規一時OU「Onboarding」を作成し、新しいアカウントを移動。

Onboarding OUにAWS Configの操作を許可するSCPを適用。

AWS Configの調整完了後、そのアカウントをProduction OUに戻す。

選択肢C

拒否リストベースのSCPを許可リストベースに変更。

一時的にAWS Config操作を許可するSCPを新規アカウントに適用。

選択肢D

新規OU「Onboarding」を作成し、新しいアカウントを移動。

Onboarding OUにAWS Config操作を許可するSCPを適用。

現在のSCPをProduction OUに移動し、その後アカウントをProduction OUに戻す。

解説

正解: 選択肢B

新規一時OU「Onboarding」を活用することで、柔軟に問題解決が可能。

長期的な管理負担を増やさず、現行ポリシー構造を維持できる。

他の選択肢よりも実施が簡単で現実的。

他の選択肢の問題点

選択肢A: 管理が複雑化し、長期的なコストが高くなる。

選択肢C: SCP全体の変更はリスクが大きい。

選択肢D: SCPの移動など手順が多く、非効率。

ポイント

SCPの設定変更において、運用効率と長期的なポリシー維持を両立させるアプローチが求められる。選択肢Bは、一時的な調整と既存ポリシーの保全を両立する解決策として最適です。

004-スケーラブルなアプリケーションとデータベースのアーキテクチャ設計

理論

1. Amazon Aurora PostgreSQL

Auroraは、Amazonが提供するフルマネージド型のリレーショナルデータベースサービスで、PostgreSQL互換のデータベースエンジンも提供しています。

Aurora Auto Scalingは、リードレプリカの数を自動的に調整する機能です。これにより、アプリケーションの読み取りトラフィックに合わせてリソースをスケーリングできます。

2. EC2 Auto Scaling

EC2 Auto Scalingは、アプリケーションの需要に応じてEC2インスタンスの数を自動的に調整する機能です。これにより、トラフィックが増加した際にインスタンスを追加し、トラフィックが減少した際にインスタンスを削除できます。

3. Elastic Load Balancing (ELB)

Elastic Load Balancingは、AWSの負荷分散サービスで、アプリケーションのトラフィックを複数のバックエンドインスタンスに分散させ、可用性とスケーラビリティを向上させます。

Application Load Balancer (ALB)は、HTTP/HTTPSトラフィックに最適化された負荷分散機能で、アプリケーション層（第7層）でのルーティングを行います。ルーティングのアルゴリズムとしては、ラウンドロビンがよく使われます。

ラウンドロビンとは

例:

例えば、3台のサーバーA、B、Cがあった場合、リクエストが到着するたびに順番に次のサーバーに振り分けられます。

最初のリクエスト → サーバーA

次のリクエスト → サーバーB

次のリクエスト → サーバーC

次のリクエスト → サーバーA

…という具合に繰り返し

Network Load Balancer (NLB)は、TCP/UDPトラフィックに最適化された負荷分散機能で、第4層（トランスポート層）で動作します。最小待機リクエストなどのルーティングアルゴリズムを使用することができます。

最小待機リクエストとは

最小待機リクエスト（Least Outstanding Requests）は、負荷分散アルゴリズムの一種で、リクエストを処理中の待機中のリクエスト数が最も少ないサーバーに振り分ける方式です。このアルゴリズムは、サーバーの負荷を動的に判断し、最も空いているサーバーにリクエストを割り当てるため、効率的にリソースを使用することができます。

4. Sticky Sessions（セッション維持）

Sticky Sessions（またはセッションアフィニティ）は、同じクライアントからのリクエストを常に同じEC2インスタンスにルーティングする機能です。これにより、セッション情報が保存されている特定のインスタンスと継続的にやりとりすることができます。

5. スケーラビリティと一貫性の確保

アプリケーションやデータベースがスケールする場合、ユーザーに一貫した体験を提供するために、セッション管理（Sticky Sessions）や適切な負荷分散の設定が重要です。

Auroraのリードレプリカを使用して、読み取り専用のトラフィックを分散させることで、書き込みトラフィックが集中してもパフォーマンスを保つことができます。

6. オートスケーリングの対象

Aurora Auto Scalingは、Auroraレプリカのスケーリングに関係し、Aurora書き込みインスタンスに対するスケーリングではない点に注意が必要です。書き込みインスタンス（Writer）は通常、1つのインスタンスに固定されていますが、読み取りトラフィックの増加に応じてレプリカを増やすことができます。

7. 2層のWebベース

通常、Webアプリケーションが2層（レイヤー）で構成されていることを指します。一般的に、この場合、2つの主な層は以下の通りです。

プレゼンテーション層（クライアント層）: ユーザーがインタラクトする部分です。通常、ブラウザやモバイルアプリがこの層に該当します。この層は、ユーザーインターフェース（UI）を提供し、ユーザーからの入力を受け取り、それをサーバーに送信します。

データ層（バックエンド層）: アプリケーションのビジネスロジックやデータの管理が行われる部分です。この層は、通常、サーバー上で動作しており、データベースとの通信や処理を行います。Webアプリケーションの場合、データベース（例: PostgreSQLやMySQL）とサーバーサイドのロジック（例: アプリケーションサーバー）で構成されます。

この「2層アーキテクチャ」のメリットは、プレゼンテーション層とデータ層が分離されているため、開発や管理が容易であることです。例えば、UIの変更がバックエンドに影響を与えないなど、システムの保守性が高まります。

重要な要点

Aurora Auto Scalingを使用してAuroraレプリカをスケーリングし、読み取りトラフィックを分散させる。

Application Load Balancer (ALB) を使用し、ラウンドロビンでトラフィックを均等に分配。

Sticky Sessionsを使用して、一貫したユーザー体験を提供。

実践

今後作成する予定

一門道場

シナリオ: 企業が、2層のWebベースのアプリケーションとデータベースをAWSに移行しています。現在のセットアップでは、状態を保持するアプリケーションが1台のサーバーで実行され、そのアプリケーションは別のサーバーで稼働しているPostgreSQLデータベースに接続しています。ユーザー数が大幅に増加することが予想されており、企業はAmazon Aurora PostgreSQL、Amazon EC2 Auto Scaling、およびElastic Load Balancingを利用してアプリケーションとデータベースをAWSに移行する計画です。

目標: アプリケーションとデータベースの両方の層がスケールする中で、一貫したユーザー体験を提供するソリューションを選択すること。

選択肢:

AuroraのAuto Scaling（Auroraレプリカ用）を有効化

Network Load Balancer (NLB) を使用し、最小待機リクエストのルーティングアルゴリズムとステッキーセッションを有効化

AuroraのAuto Scaling（Aurora書き込み用）を有効化

Application Load Balancer (ALB) を使用し、ラウンドロビンルーティングアルゴリズムとステッキーセッションを有効化

AuroraのAuto Scaling（Auroraレプリカ用）を有効化

Application Load Balancer (ALB) を使用し、ラウンドロビンルーティングアルゴリズムとステッキーセッションを有効化

AuroraのAuto Scaling（Aurora書き込み用）を有効化

Network Load Balancer (NLB) を使用し、最小待機リクエストのルーティングアルゴリズムとステッキーセッションを有効化

解説

1. アーキテクチャの構成

このアプリケーションは、オンプレミスからAWSに移行される2層のWebベースのアーキテクチャです。具体的には、以下の構成が予定されています：

アプリケーション層：状態を保持するアプリケーションが1台のEC2インスタンスで動作しています。

データベース層：PostgreSQLデータベースが別のサーバーで稼働していますが、AWSのAurora PostgreSQLに移行されます。

2. アプリケーションのスケーリング

アプリケーション層は、ユーザー数が増加するにつれてスケールアウト（水平スケーリング）する必要があります。これを実現するために、EC2 Auto Scalingを使用します。また、負荷分散のためには**Elastic Load Balancing (ELB)**を使用し、アプリケーションのトラフィックを複数のインスタンスに分散します。

3. データベースのスケーリング

データベース層では、Amazon Aurora PostgreSQLを使用します。Auroraはリードレプリカを使用して読み取り処理を分散し、Aurora Auto Scalingを有効にすることで、レプリカ数を自動で調整できます。

A. AuroraリプリカのAuto Scalingを有効にする、Network Load Balancerを使用

Network Load Balancer (NLB) は高いトラフィックを処理するために設計されていますが、リクエストの最小待機時間（least outstanding requests）でトラフィックを分散します。NLBは通常、TCP/UDPトラフィックに最適ですが、状態保持型のWebアプリケーションで「Sticky Sessions」を使用する場合、Application Load Balancer (ALB) がより適しています。

この選択肢は、状態保持型のアプリケーションとトラフィック管理には不適切です。

B. AuroraライターのAuto Scalingを有効にする、Application Load Balancerを使用

AuroraのライターインスタンスにAuto Scalingを有効にすると、書き込み操作の負荷を分散できますが、ライターのスケーリングは通常、特定の書き込み操作を分散するために使用されます。このシナリオでは、読み取り専用の操作が主であり、リーダーのスケーリングが必要です。

ALBはWebアプリケーションのロードバランシングに適しており、状態保持（Sticky Sessions）を活用する場合にも最適です。

C. AuroraリプリカのAuto Scalingを有効にする、Application Load Balancerを使用

Auroraリプリカを使用することで、読み取り専用のリクエストを複数のインスタンスに分散できます。また、ALBはHTTP/HTTPSトラフィックの処理に優れており、状態保持型のセッション管理（Sticky Sessions）もサポートしています。この選択肢は、Webアプリケーションのスケーラビリティと一貫したユーザー体験を提供するために最適です。

D. AuroraライターのAuto Scalingを有効にする、Network Load Balancerを使用

AuroraライターのAuto Scalingを使用する場面では、書き込み操作にフォーカスする必要があり、このシナリオではリードレプリカのスケーリングが重要です。さらに、NLBは状態保持型アプリケーションには適していません。

5. 最適解

最も適した選択肢はCです。Auroraリプリカを使用し、ALBでトラフィックを管理することが、アプリケーション層とデータベース層をスケーラブルに保ち、ユーザー体験の一貫性を確保します。

005-古いデバイス対応とHTTPヘッダー

理論

AWSを活用した古いデバイス向けHTTPヘッダー処理

企業がAWSを利用して、古いデバイスが処理できないHTTPヘッダーを削除するシステムを構築するための前提知識を以下にまとめます。

1. HTTPおよびHTTPヘッダーの基礎知識

HTTPプロトコル

クライアントとサーバーが通信するためのプロトコル

リクエストとレスポンスで構成

HTTPヘッダーとは？

リクエストやレスポンスのメタデータを含む情報

例: コンテンツのタイプ（Content-Type）、キャッシュの制御（Cache-Control）

古いデバイスへの対応

最新のHTTP仕様やセキュリティヘッダーをサポートしていない

問題となるヘッダーを削除する必要あり

2. User-Agentヘッダーを活用したデバイス識別

User-Agentヘッダーとは？

HTTPリクエストに含まれる情報で、クライアントの種類やバージョンを示す

例: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..."

User-Agentヘッダーによるデバイス識別

特定のデバイス（例: 古いテレビ）を識別し、不要なHTTPヘッダーを削除する

Lambda関数やAPI Gatewayのレスポンスマッピングテンプレートを使用

3. AWSのサーバーレスサービスの理解

AWS Lambda

イベント駆動型のサーバーレスコンピューティングサービス

コードを実行し、迅速なレスポンスが可能

AWS Lambdaの役割

特定のリクエストに対してデータを処理し、レスポンスヘッダーを動的に変更

古いデバイス向けに不要なヘッダーを削除する処理をサーバーレスで行う

Amazon CloudFront

グローバルに分散したCDN（コンテンツ配信ネットワーク）サービス

エッジロケーションで必要な処理を行い、低遅延でコンテンツを配信

4. レスポンスヘッダーの処理方法

Lambda@Edge

CloudFrontと統合し、エッジロケーションでLambda関数を実行できるサービス

リアルタイムにレスポンスヘッダーを変更し不要なヘッダーを削除

1. Viewer Request (エンドユーザーからのリクエスト)

エンドユーザー（お客様）は、自分のPCやスマートフォンからコンテンツ（例: Webページ、画像、動画）をリクエストします。

このリクエストはCloudFrontのエッジサーバーに送信されます。

2. Origin Request (オリジンサーバーへのリクエスト)

リクエストされたコンテンツがCloudFrontのキャッシュにない場合、CloudFrontはオリジンサーバー（例: Webサーバー、S3バケット）にコンテンツを取りに行きます。

3. Origin Response (オリジンサーバーからのレスポンス)

オリジンサーバーはリクエストされたコンテンツをCloudFrontに返します。

4. Viewer Response (エンドユーザーへのレスポンス)

CloudFrontはオリジンサーバーから取得したコンテンツをキャッシュに保存し、エンドユーザーに配信します。

以後、同じコンテンツのリクエストがあった場合は、CloudFrontはキャッシュからコンテンツを返すことで、迅速なレスポンスを提供します。

5. CloudFront Cache

CloudFrontはグローバルに分散したCDN（コンテンツ配信ネットワーク）で、エッジロケーションにキャッシュを保持しています。

エンドユーザーのリクエストがエッジロケーションに到達すると、CloudFrontはそのリクエストがキャッシュ内に既にあるかどうかを確認します。

このプロセスにより、CloudFrontは低遅延でコンテンツを提供し、オリジンサーバーへの負荷を軽減します。また、CloudFrontのキャッシュ機能を利用することで、高速で効率的なコンテンツ配信が実現できます。

レスポンスマッピングテンプレート

API Gatewayを使ってレスポンスをカスタマイズ

User-Agentに基づき、古いデバイス向けにヘッダーを削除

5. API Gatewayの利用

API Gatewayとは？

REST APIやHTTP APIの管理、リクエストのルーティング、レスポンスのカスタマイズを行うサービス

REST APIとHTTP APIの違い

REST API: より多機能で、認証、キャッシュ、詳細なモニタリング機能を提供

HTTP API: よりシンプルで軽量なAPI管理が可能で、低コストで運用

まとめ

この問題を解決するためには、以下の技術的な知識が重要です：

HTTPおよびHTTPヘッダー：レスポンスにおけるヘッダーの役割と古いデバイスへの対応方法

User-Agentヘッダー：デバイスの識別に役立つヘッダーの利用方法

AWS Lambda：サーバーレスコンピューティングで、リクエストに応じた処理を動的に実行する方法

Amazon CloudFrontおよびLambda@Edge：エッジでレスポンスヘッダーを変更する技術

API Gateway：リクエスト・レスポンスの管理とカスタマイズ方法

これらの技術を駆使することで、AWS上でスケーラブルで効率的なシステムを構築し、古いデバイス向けに適切なレスポンスを提供することができます。

実践

以下は、Lambda@Edge関数の作成と設定に関する部分を簡潔に整理した記事です。

源サーバコンテンツを作成

Amazon S3 に index.html ファイルを作成してアップロードする

1. `index.html` ファイルの作成

まず、テキストエディタを開き、以下の HTML コードをコピーして、新しい index.html ファイルを作成します。

この内容を index.html として保存し、わかりやすい場所に保存します。

2. `index.html` ファイルの確認

アップロードが完了したら、Amazon S3 が提供するオブジェクト URL を使用して、index.html ファイルにアクセスできます。初回はアクセスが拒否されることがありますが、これはファイルが公開設定されていないためです。

これで、Amazon S3 に index.html ファイルを作成し、アップロードする手順が完了です。

CloudFront 分配の作成

1. CloudFront 分配の作成

AWS コンソールの CloudFront に移動し、「CloudFront 分配の作成」をクリック。

S3 バケットをソースとして設定し、CloudFront にアクセス権限を付与。

ソースドメイン: 作成した S3 バケットを選択。

アクセス S3 バケット: 「はい、OACを使用して、CloudFront のみにアクセスを制限」を選択。

2. ソースアクセスアイデンティティの設定

「新規 OAC を作成」をクリックし、ダイアログで「作成」を選択。

バケットポリシー: 「はい、バケットポリシーを更新」を選択。

3. デフォルトキャッシュ設定

プロトコルポリシー: HTTP を HTTPS にリダイレクト。

キャッシュとソースリクエスト:

キャッシュポリシー: 「CachingOptimized」（S3 ソース向けの推奨設定）。

4. ドメイン設定

代替ドメイン名（CNAME）: 必要に応じて設定。

デフォルトルートオブジェクト: 「index.html」を設定（オプション）。

5. 分配の作成

「分配の作成」ボタンをクリックして、CloudFront 分配を作成。作成には通常 5～10 分かかります。

Lambda@Edge関数の作成

1. Lambda@Edge関数の作成

AWSコンソールにログインし、ap-northeast-1東京リージョンを確認。

Lambdaコンソールに移動し、関数の作成をクリック。

関数の設定：

「一から作成」を選択。

関数の作成を選択。

関数名を LambdaEdgeImmersionDayLabFunction に設定。

ランタイムは Node.js 18.x を選択。

ロールの設定：

新しいロールを作成を選択。

ロール名を lambda_edge_execution_role に設定。

ポリシーテンプレートとして Basic Lambda@Edge permissions (for CloudFront trigger) を選択。

関数の作成をクリック。

2. Lambda関数のテスト設定

テストタブを選択し、新しいテストイベントの作成をクリック。

イベント名を TestEvent として設定し、以下のJSONを入力。

3. Lambda関数のコード設定

上記のテストイベントデータを使用して、Lambda関数を作成し、レスポンスを返すように設定します。

関数を保存：上記コードをLambda関数に入力し、保存。

デプロイ：Deployボタンをクリックしてデプロイ。

テスト実行：Testボタンをクリックしてテストを実行。

4. Lambda@Edge関数をCloudFrontにデプロイ

Lambdaコンソールで設定：

Add triggerボタンをクリックし、CloudFrontを選択。

Deploy to Lambda@Edgeをクリック。

トリガーの設定：

ディストリビューションを選択。

キャッシュビヘイビアを/serverlessに設定。

CloudFrontイベントを Origin request に設定。

「I acknowledge that...」を選択して、Deployをクリック。

デプロイ完了：

数分後にデプロイが完了。

Lambdaインターフェースで確認:

Replicas タブからレプリカを確認。

CloudFrontディストリビューションのテスト：

ブラウザでサーバーレスパスを使用してアクセスし、テスト。

これで、Lambda@Edge関数の作成と、CloudFrontディストリビューションにデプロイする方法が完了です。

一問道場

企業の現在の状況

オンプレミスのメタデータ収集サービスを使用しています。

TVやインターネットラジオなどの消費者デバイスがこのサービスにアクセスしています。

古いデバイスは特定のHTTPヘッダーをサポートしておらず、これらのヘッダーがレスポンスに含まれているとエラーが発生します。

オンプレミスのロードバランサーを使用して、古いデバイス（User-Agentヘッダーで特定）に送信されるレスポンスからサポートされていないヘッダーを削除しています。

企業の計画

このサービスをAWSに移行し、サーバーレス技術を採用。

古いデバイスのサポート機能を維持。

アプリケーションを既にAWS Lambda関数に移行。

解決策の選択肢

選択肢 A

Amazon CloudFrontディストリビューションをメタデータサービスのために作成。

Application Load Balancer（ALB）を作成。

CloudFrontディストリビューションを設定して、ALBにリクエストを転送。

ALBを設定して、各リクエストタイプに対して正しいLambda関数を呼び出します。

CloudFront関数を作成し、User-Agentヘッダーの値に基づいて問題のあるヘッダーを削除。

選択肢 B

Amazon API Gateway REST APIをメタデータサービスのために作成。

API Gatewayを設定して、各リクエストタイプに対して正しいLambda関数を呼び出します。

デフォルトのゲートウェイレスポンスを修正して、User-Agentヘッダーの値に基づいて問題のあるヘッダーを削除。

選択肢 C

Amazon API Gateway HTTP APIをメタデータサービスのために作成。

API Gatewayを設定して、各リクエストタイプに対して正しいLambda関数を呼び出します。

レスポンスマッピングテンプレートを作成して、User-Agentヘッダーの値に基づいて問題のあるヘッダーを削除。

HTTP APIにレスポンスデータマッピングを関連付け。

選択肢 D

Amazon CloudFrontディストリビューションをメタデータサービスのために作成。

Application Load Balancer（ALB）を作成。

CloudFrontディストリビューションを設定して、ALBにリクエストを転送。

ALBを設定して、各リクエストタイプに対して正しいLambda関数を呼び出します。

Lambda@Edge関数を作成し、User-Agentヘッダーの値に基づいて問題のあるヘッダーを削除。

問題の要点：

企業はAWSに移行したい。

古いデバイス（テレビやインターネットラジオなど）が特定のHTTPヘッダーに対応しておらず、エラーを引き起こす。

古いデバイスのために、HTTPレスポンスの中からそのヘッダーを削除したい。

要求されている解決策：

AWSに移行しつつ、古いデバイスのサポートを続ける。

古いデバイスの識別は、User-Agentヘッダーを使って行う。

サーバーレス技術（Lambdaなど）を使いたい。

システム全体の流れ

リクエスト送信：

古いデバイスを含むエンドユーザーがCloudFrontにリクエストを送信。

リクエスト処理：

CloudFrontがリクエストを受け取り、キャッシュを確認。

キャッシュにヒットしない場合、ALBにリクエストを転送。

リクエスト転送：

ALBがリクエストを受け取り、適切なAWS Lambda関数にルーティング。

メタデータ処理：

Lambda関数がメタデータサービスからデータを収集し、レスポンスを生成。

CloudFrontレスポンス：

生成されたレスポンスがALB経由でCloudFrontに戻る。

レスポンス修正：

CloudFrontでLambda@Edgeがレスポンスから古いデバイスがサポートしないHTTPヘッダーを削除。

レスポンス返送：

修正されたレスポンスがエンドユーザーに返送。

このフローにより、古いデバイスがサポートしていないHTTPヘッダーを削除して、エラーを防ぎます。

各選択肢の解説：

選択肢A（CloudFront + ALB + CloudFront関数）

CloudFront：コンテンツ配信ネットワーク（CDN）を使って、ユーザーへのレスポンスを高速化します。

ALB（Application Load Balancer）：リクエストをLambda関数に転送する役割。

CloudFront関数：CloudFrontでリクエストを処理し、特定のヘッダー（例えばUser-Agent）に基づいて不要なヘッダーを削除します。

問題点：

CloudFront関数は処理が軽いものに向いていますが、複雑な処理やヘッダー操作には限界があります。

選択肢B（API Gateway REST API + Lambda）

API Gateway：リクエストをLambdaに転送するサービス。REST APIとしてリクエストを受け付けます。

Lambdaで処理し、レスポンスから問題のヘッダーを削除。

問題点：

API Gatewayは主にリクエストのルーティングに使われ、レスポンスの処理はやや手間がかかります。

古いデバイス向けには、もっと効率的にヘッダー処理をする方法が必要です。

選択肢C（API Gateway HTTP API + Lambda）

API Gateway HTTP API：軽量なHTTP APIを使って、リクエストをLambdaに転送します。

レスポンスのマッピングテンプレートで、User-Agentに基づいて不要なヘッダーを削除。

問題点：

こちらもAPI Gatewayを使っていますが、エッジで直接ヘッダーを処理するわけではないので、パフォーマンスがやや劣ります。

選択肢D（CloudFront + ALB + Lambda@Edge）

Lambda@Edge：CloudFrontのエッジロケーションで直接コードを実行できるサービス。

ALB：リクエストをLambda関数に転送。

CloudFront：リクエストを最初に受け取る。エッジで処理を行い、遅延を最小限に。

この選択肢が最適な理由：

Lambda@EdgeはCloudFrontのエッジロケーションで動作するため、ユーザーに最も近い場所で処理を行い、非常に低い遅延でヘッダーを削除できます。

ヘッダーの削除は、User-Agentヘッダーを使って行いますが、Lambda@Edgeではより柔軟で複雑なロジックが実行可能です。

古いデバイス向けに、レスポンスの修正をエッジで効率的に行えるため、最適です。

結論：

選択肢Dが最適です。

Lambda@Edgeを使うことで、エッジロケーションでリクエストとレスポンスを処理し、低遅延で効率よく古いデバイスへのサポートを維持できます。

006-AWSアカウント間のS3バケットアクセス設定

理論

AWSアカウント間でS3バケットへのアクセスを許可するには、以下のポイントを理解することが重要です。

IAMポリシーとバケットポリシー:

IAMポリシーは、ユーザーやグループに対して特定のアクションを許可または拒否しますが、S3バケットへのアクセスを制御するためには、S3バケットポリシーを設定する必要があります。

S3バケットポリシーでは、どのアカウントやIAMユーザーがどのリソースにアクセスできるかを詳細に定義します。特にクロスアカウントアクセスの場合、Principalフィールドを使用して、他のAWSアカウントのユーザーにアクセス権を付与します。

状況によりますが、両方が適切に設定されている必要があるケースが多いです。クロスアカウントアクセスやパブリックアクセスのシナリオでは、S3バケットポリシーの設定が特に重要です。

クロスアカウントアクセス:

クロスアカウントアクセスとは、1つのAWSアカウントに保存されたリソースに、別のAWSアカウントのIAMユーザーがアクセスできるようにする設定です。このためには、適切なバケットポリシーで、指定したIAMユーザーに対してリソース（S3バケット）のアクセス権を付与します。

例として、arn:aws:iam::AccountB:user/User_DataProcessorのように、別アカウントのユーザーを指定してアクセスを許可します。

S3バケットポリシーの基本構文: S3バケットポリシーはJSON形式で記述され、通常は次のような構成をとります：

IAMユーザーの権限設定: IAMユーザー（User_DataProcessor）には、S3バケットにアクセスできる権限（s3:GetObjectやs3:ListBucketなど）を付与する必要があります。

バケットポリシーの検討点:

Actionには、アクセスを許可したい操作（s3:GetObjectやs3:ListBucket）を指定します。

Resourceには、アクセス対象となるS3リソース（バケット全体またはファイル単位）を指定します。

実践

AWSクロスアカウントS3アクセス設定のハンズオン

このハンズオンでは、2つの異なるAWSアカウント間でS3バケットへのアクセスを設定する方法を学びます。アカウントAのS3バケットに保存されたデータファイルに、アカウントBのIAMユーザーがアクセスできるようにします。

目的

アカウントAのS3バケットに、アカウントBのIAMユーザーがアクセスできるように設定する。

アカウントAでバケットポリシーを設定し、アカウントBのIAMユーザーにアクセス権限を付与する。

必要な準備

2つのAWSアカウント（アカウントAとアカウントB）

アカウントAのS3バケット（例：account-a-bucket）

アカウントBのIAMユーザー（例：User_DataProcessor）

ステップ1: アカウントAでS3バケットを作成

AWS Management Consoleにログイン（アカウントAで）。

S3サービスを選択し、バケットを作成します。

バケット名: account-a-bucket（一意の名前を使用）。

他の設定はデフォルトのままでOK。

ステップ2: アカウントBのIAMユーザーを作成

アカウントBにログインし、IAMコンソールに移動。

ユーザーを追加を選択し、User_DataProcessorという名前で新しいIAMユーザーを作成します。

アクセスの種類は「プログラムによるアクセス」と「AWS Management Consoleアクセス」を選択。

ユーザーにS3アクセス権限を付与します。

「ポリシーを直接アタッチ」し、AmazonS3ReadOnlyAccessを選択。

ステップ3: アカウントAでS3バケットポリシーを設定

アカウントAでS3バケットのポリシーを設定:

S3バケットの「権限」タブを開き、「バケットポリシー」を選択。
次のポリシーを入力して、アカウントBのUser_DataProcessorにアクセス権限を付与します。

ポリシーを保存。

ステップ4: アカウントBからS3バケットにアクセス

アカウントBのUser_DataProcessorとしてログインし、AWS CLIまたはS3コンソールを使用して、アカウントAのS3バケットにアクセスします。

例えば、AWS CLIで次のコマンドを実行してファイルを確認できます：

確認

アカウントBのユーザーは、アカウントAのS3バケットのオブジェクトを取得し、バケット内のオブジェクトをリストできることを確認します。

解説

このハンズオンでは、クロスアカウントアクセスを実現するために、S3バケットポリシーを利用しています。アカウントAのS3バケットに対して、アカウントBのIAMユーザーに権限を付与することで、アカウントBからS3バケットにアクセス可能になります。このプロセスでは、以下の要素を確認しました：

Principal: アカウントBのIAMユーザー（User_DataProcessor）に対してアクセス権限を与える。

Action: アクセス可能なアクション（s3:GetObjectとs3:ListBucket）を指定。

Resource: アクセス対象となるリソース（S3バケットとそのオブジェクト）。

一門道場

小売会社（Account A）が保存したデータファイルを、別の会社（ビジネスパートナー）に提供する必要があります。このファイルはAccount AのS3バケットに保存されており、ビジネスパートナーは自社のIAMユーザー（User_DataProcessor）に対して、Account AのS3バケット内のファイルへのアクセスを許可したいと考えています。この場合、必要な手順を選択する問題です。

A:「S3バケットでクロスオリジンリソースシェアリング（CORS）を有効にする」

解説:

CORSは、異なるドメイン間でリソースを共有するための設定ですが、これは主にブラウザベースのリクエストに関係するもので、IAMユーザーによるアクセス権の管理には直接関係しません。そのため、これは不正解です。

B:「Account AのS3バケットポリシーに次の内容を設定する」

解説:

これはAccount A側でのS3バケットポリシー設定に関するものですが、指定された形式（arn:aws:s3:::AccountABucketName/*）は不完全です。arn:aws:s3:::AccountABucketNameと指定することで、バケット自体に対するアクセス権を付与することはできますが、ファイルにアクセスするためには適切なポリシーが必要です。この選択肢は誤りです。

C:「Account AのS3バケットにアクセスするために、Account BのIAMユーザー（User_DataProcessor）に対してアクセス権限を付与する」

解説:

これは正しい選択肢です。Account AのS3バケットポリシーで、Account BのIAMユーザー（User_DataProcessor）に対してアクセス権限を付与することで、指定されたIAMユーザーがS3バケットにアクセスできるようになります。正しいポリシー例は次のようになります。

これにより、User_DataProcessorは指定されたバケット内のファイルを読み取る権限を得ます。

D:「Account BのIAMユーザー（User_DataProcessor）の権限を設定する」

解説: IAMユーザーにアクセス権を付与することは、アクセス対象のリソース（この場合はAccount AのS3バケット）に対しても権限を設定する必要があります。しかし、この選択肢は他のAWSアカウントのリソースへのアクセスを設定するものではないため、不完全な解答です。

選択肢E:「Account BでUser_DataProcessorに対して、Principalを指定したポリシーを設定する」

解説: Principalを指定するのは、Account A側のS3バケットポリシーで行うべきであり、Account B側でPrincipalを設定することは誤りです。この選択肢も不正解です。

正解

選択肢C: Account AのS3バケットに、Account BのIAMユーザー（User_DataProcessor）に対してアクセス権限を付与する。

選択肢B: Account A側でS3バケットポリシーを設定し、ファイルの読み取りとバケットのリスト表示が可能なアクセス権限を付与します。

解説

この問題では、異なるAWSアカウント間でS3バケットへのアクセス権を設定する方法を問われています。正しく設定するためには、Account AのS3バケットポリシーで、Account BのIAMユーザーに対して適切な権限（s3:GetObjectやs3:ListBucket）を付与する必要があります。

007-マイクロサービスのコンテナ化とサーバーレスアーキテクチャ

理論

企業が従来型のウェブアプリケーションをマイクロサービスアーキテクチャにリファクタリングし、運用の複雑さを最小限に抑えながらコスト効率を最大化するためには、適切なインフラストラクチャ選択が必要です。

1. マイクロサービスアーキテクチャの基本概念

マイクロサービスとは

マイクロサービスアーキテクチャは、アプリケーションを小さな独立したサービスに分解する設計スタイルです。各サービスは特定の機能に焦点を当て、他のサービスと独立してデプロイ、スケーリング、更新が可能です。これにより、アプリケーション全体の柔軟性と拡張性が向上します。

コンテナ化の重要性

コンテナ技術は、アプリケーションとその依存関係を単一のパッケージとして扱い、どこでも一貫した動作を確保します。これにより、マイクロサービスアーキテクチャの各サービスをコンテナ化することが一般的になります。コンテナ化の利点は以下の通りです：

環境依存を排除して、どの環境でも動作が一貫する

短時間でのスケーリングが可能

サービスの独立性が保たれ、トラブルシューティングや更新が容易

2. サーバーレスアーキテクチャのメリットとデメリット

サーバーレスアーキテクチャとは

サーバーレスは、インフラストラクチャの管理を完全にクラウドプロバイダーに委託し、ユーザーはアプリケーションのコードやロジックに集中できるモデルです。サーバーレスの代表的なサービスは AWS Lambda です。サーバーレスの特徴としては以下が挙げられます：

コスト効率: 実行されたコードに対してのみ料金が発生

スケーラビリティ: トラフィックに応じて自動的にスケーリング

運用の簡素化: インフラ管理が不要

デメリット

長時間実行するタスクや状態管理が複雑な場合には制限がある

高度なカスタマイズや複雑なワークロードには不向き

AWS Lambda（サーバーレスコンピューティング）

使用シナリオ: 短時間で終わるトリガーベースのタスクやイベント駆動型のアプリケーション

利点: 完全なサーバーレス環境で、インフラの管理が不要。イベント駆動型でスケーリングが自動。

制限: 長時間実行されるタスクや複雑な状態管理が必要なマイクロサービスには不向き。

Amazon ECS (Elastic Container Service)

使用シナリオ: コンテナ化されたアプリケーションの管理。Fargateを使うことで、インフラ管理なしでコンテナを実行。

利点: コンテナのスケーリング、管理が簡単。Fargateを利用することで、サーバーレスのようにインフラ管理不要。

制限: コンテナに対して柔軟に設定が可能だが、EKSよりは機能が少ない。

Amazon EKS (Elastic Kubernetes Service)

使用シナリオ: 高度にカスタマイズ可能なKubernetesベースのオーケストレーションが必要な場合。

利点: 高い柔軟性とスケーラビリティ。大規模なマイクロサービスに適している。

制限: Kubernetesの管理が複雑で、運用には高度な知識が必要。

AWS Elastic Beanstalk

使用シナリオ: アプリケーションのデプロイとスケーリングを簡素化したい場合。

利点: インフラ管理を自動化し、簡単にアプリケーションをデプロイ可能。

制限: マイクロサービスアーキテクチャには柔軟性に欠ける場合があり、特にコンテナ管理には向かない。

実践

初心者向け！コンテナ化WordPressサイト構築ガイド（超詳細版）

一問道場

ある企業が、Amazon EC2インスタンスで従来型のウェブアプリケーションを実行しています。この企業はアプリケーションをコンテナで実行するマイクロサービスにリファクタリングする必要があります。アプリケーションの異なるバージョンは、本番環境とテスト環境という2つの異なる環境に存在しています。アプリケーションの負荷は変動しますが、最小負荷と最大負荷は既知です。ソリューションアーキテクトは、運用の複雑さを最小限に抑えたサーバーレスアーキテクチャで更新されたアプリケーションを設計する必要があります。

最もコスト効果の高い要件を満たすソリューションはどれですか？

選択肢:

コンテナイメージをAWS Lambdaに関数としてアップロードし、予想されるピーク負荷を処理できるようにLambda関数に同時実行制限を設定します。

さらに、Amazon API Gateway内で本番環境とテスト環境用の2つのLambdaインテグレーションを設定します。

コンテナイメージをAmazon Elastic Container Registry (Amazon ECR)にアップロードし、予想される負荷を処理するために2つのオートスケールのAmazon Elastic Container Service (Amazon ECS)クラスターをFargate起動タイプで設定します。

ECRのイメージからタスクをデプロイし、2つの異なるApplication Load Balancerを設定して、ECSクラスターへのトラフィックを誘導します。

コンテナイメージをAmazon Elastic Container Registry (Amazon ECR)にアップロードし、予想される負荷を処理するために2つのオートスケールのAmazon Elastic Kubernetes Service (Amazon EKS)クラスターをFargate起動タイプで設定します。

ECRのイメージからタスクをデプロイし、2つの異なるApplication Load Balancerを設定して、EKSクラスターへのトラフィックを誘導します。

コンテナイメージをAWS Elastic Beanstalkにアップロードし、Elastic Beanstalkで本番環境とテスト環境のために別々の環境とデプロイメントを作成します。

さらに、2つの異なるApplication Load Balancerを設定して、Elastic Beanstalkのデプロイメントへのトラフィックを誘導します。

これで、選択肢が整理され、問題がより読みやすくなりました。

解説

この問題は、企業が従来型のウェブアプリケーションをマイクロサービスにリファクタリングし、サーバーレスアーキテクチャで運用の複雑さを最小限に抑えながらコストを削減する方法を選択するものです。各選択肢には異なるアーキテクチャが提案されており、それぞれの利点と欠点を考慮する必要があります。

選択肢 A

AWS Lambdaを使用する方法

コンテナイメージをAWS Lambdaにアップロードし、API Gatewayを通じて本番環境とテスト環境を管理します。

Lambdaは完全にサーバーレスであり、インフラ管理の負担がなく、スケーラビリティが非常に高いですが、コンテナとして直接Lambdaにアップロードするのはあまり一般的な方法ではなく、特に複雑なマイクロサービスには適さない可能性があります。

複雑なマイクロサービスには、Lambdaの制限や実行時間の制限が影響することもあります。

適していない理由:

Lambdaは短期間のタスクに適していますが、複雑なアプリケーションや、長時間実行されるマイクロサービスには向いていない場合があります。特に、アプリケーションが複数の依存関係や長時間稼働するタスクを持つ場合には、より適切なサービス（ECSやEKS）が推奨されます。

選択肢 B

Amazon ECS（Elastic Container Service）を使用する方法

Amazon ECRにコンテナイメージを保存し、Fargateを使用してECSクラスターでコンテナを実行します。これにより、サーバーレスでのコンテナ管理が可能となり、負荷に応じたスケーリングが自動で行われます。

ECSはコンテナの管理とオーケストレーションを簡素化するサービスであり、特にマイクロサービスアーキテクチャに適しています。Fargateを使用することで、インフラの管理が不要となり、コスト効率も高くなります。

ECSクラスターを本番環境とテスト環境で分けることができ、スケーラビリティや管理が簡単に行えます。

適している理由:

ECSは、コンテナの管理に優れたサービスであり、Fargateを利用することでサーバーレスでの管理が可能となり、開発者はインフラの設定やスケーリングに悩む必要がなくなります。コスト効率も良いとされています。

選択肢 C

Amazon EKS（Elastic Kubernetes Service）を使用する方法

コンテナイメージをECRにアップロードし、EKSクラスターでFargateを使用してコンテナを実行します。Kubernetesは強力なオーケストレーションツールですが、その設定や管理には学習コストがかかります。

EKSはECSよりも強力で柔軟性が高く、特に大規模なマイクロサービスや複雑なワークロードに適しています。しかし、その管理の複雑さを軽減するためにFargateを使うことができます。

適していない理由:

EKSはKubernetesをベースにしており、Kubernetesの設定と管理は学習コストが高く、運用の複雑さを考慮すると、ECSの方がシンプルでコスト効果が高い場合があります。特に、運用の複雑さを最小限にしたい場合、ECSの方が適しているかもしれません。

選択肢 D

AWS Elastic Beanstalkを使用する方法

Elastic Beanstalkは、アプリケーションのデプロイとスケーリングを簡単に管理できるサービスであり、インフラの設定を自動化できます。しかし、Elastic Beanstalkはコンテナアプリケーションの管理に対しては若干制限があり、特にマイクロサービスアーキテクチャにはあまり最適ではない場合があります。

本番環境とテスト環境を分けてデプロイできますが、コンテナに関するより高度な制御が必要な場合には、Elastic Beanstalkは不向きです。

適していない理由:

Elastic Beanstalkは簡単に運用できる反面、コンテナベースのマイクロサービスを効率的に管理するための柔軟性や機能が制限されている場合があります。複雑なアーキテクチャには、ECSやEKSの方が適していると考えられます。

結論:

最もコスト効果が高いのは 選択肢 B です。

Amazon ECS は、コンテナアーキテクチャの管理に適しており、Fargateを使用することでサーバーレスでの運用が可能になります。スケーリングが簡単で、インフラ管理の負担を減らすことができるため、コスト効率が高い選択肢となります。また、ECRを利用して本番環境とテスト環境をそれぞれ管理する方法も、実用的かつコスト効率が良いです。

008-AWSを使用した多層Webアプリケーションの災害復旧（DR）設計

理論

AWSを用いた災害復旧設計に必要な前提知識

AWS（Amazon Web Services）は、柔軟で高可用性のあるインフラストラクチャを提供し、災害復旧（Disaster Recovery, DR）に役立つ多くのツールやサービスを提供しています。災害復旧の目的は、システム障害が発生した際に迅速にサービスを復旧させることです。このために、AWSではいくつかのアーキテクチャ的な選択肢を提供しており、企業は必要に応じて最適なソリューションを選択できます。本記事では、AWSを用いた災害復旧設計に関する前提知識を整理します。

1. Auto ScalingとElastic Load Balancing (ELB)

Auto Scaling:

AWS Auto Scalingは、アプリケーションのトラフィックの増減に応じて、インスタンス数を自動で調整します。これにより、システムの可用性とコスト効率が向上します。Auto Scalingグループは最小数と最大数のインスタンスを定義し、トラフィックに応じてインスタンスを追加・削除します。

Elastic Load Balancer (ELB):

ELBは、複数のAmazon EC2インスタンス間でトラフィックを分散するサービスです。Application Load Balancer（ALB）は、HTTPおよびHTTPSリクエストをトラフィックルールに基づいて適切なターゲット（インスタンス）にルーティングします。ALBは、負荷分散のために複数のリージョンやインスタンスをまたいで使用できます。

2. Amazon Route 53とDNSベースのフェイルオーバー

Amazon Route 53:

Route 53は、ドメインネームシステム（DNS）のサービスであり、インターネット上でのリソースの名前解決を行います。Route 53は、レイテンシーベースのルーティング、ヘルスチェック、フェイルオーバールーティングなどの機能を提供し、トラフィックの制御を行います。

DNSベースのフェイルオーバー:

Route 53を使って、プライマリリージョンで障害が発生した場合に、バックアップリージョンへトラフィックを自動的にルーティングすることができます。Route 53の「フェイルオーバーポリシー」は、ヘルスチェックの結果に基づいて、正常なインスタンスやリージョンにトラフィックを切り替えます。

3. Amazon RDS (Relational Database Service) と Multi-AZ

Amazon RDS (Relational Database Service):

Amazon RDSは、リレーショナルデータベースをフルマネージドで提供するサービスです。アプリケーションのデータストレージに使用され、スケーラブルで高可用性の構成が可能です。

RDS Multi-AZ:

Multi-AZデプロイメントでは、プライマリインスタンスと同期的に更新されるセカンダリインスタンス（障害発生時に切り替え用のインスタンス）が別のアベイラビリティゾーン（AZ）に配置されます。これにより、プライマリインスタンスがダウンしても、データベースは継続的に利用可能となります。

RDS Read Replica:

Read Replicaは、読み取り専用のDBインスタンスで、プライマリインスタンスからデータを非同期に複製します。バックアップリージョンに配置することで、災害時の迅速なデータ復旧が可能になります。Read Replicaを昇格させて、プライマリインスタンスとして使用することもできます。

4. AWS Lambdaとオートメーション

AWS Lambda:

AWS Lambdaは、サーバーレスコンピューティングサービスであり、コードを実行する際にインフラの管理を不要にします。特に災害復旧時には、特定のトリガーに応じて自動で実行されるスクリプトやプロセスを簡単に設定することができます。

Lambdaを用いた自動フェイルオーバー:

Lambda関数を使用して、特定のイベントが発生した場合（例: CloudWatchアラームのトリガー）に、バックアップリージョンのDBインスタンスを昇格させたり、Auto Scalingの設定を変更したりすることができます。これにより、復旧作業を自動化できます。

5. AWS Global Accelerator

AWS Global Accelerator: Global Acceleratorは、アプリケーションのパフォーマンスを向上させ、複数のリージョンに跨るエンドポイントにトラフィックを分散させるサービスです。これを使用すると、ユーザーが最も近いリージョンからアプリケーションにアクセスできるようになり、災害時には迅速に他のリージョンに切り替えることが可能になります。

6. Cross-Region Replication (クロスリージョン複製)

S3クロスリージョン複製: Amazon S3のクロスリージョン複製（CRR）は、オブジェクトストレージデータを複数のリージョンにリアルタイムで複製する機能です。これにより、データが物理的に異なるリージョンに存在するため、災害時にも迅速なデータ復旧が可能となります。

7. 障害発生時の手順と復旧時間 (RTO)

RTO（復旧目標時間）:

RTOは、システム障害後にサービスを復旧させるために必要な最大時間です。これを短縮するためには、複数のリージョンでリソースを冗長化し、自動的にフェイルオーバーする仕組みを整えることが重要です。

RPO（復旧時点目標）:

RPOは、障害発生時にどれだけのデータ損失を許容するかを示す指標です。データの冗長化や同期複製の設定により、RPOを最小限に抑えることが求められます。

結論

災害復旧の設計には、高可用性を持つアーキテクチャを構築し、障害発生時には迅速にサービスを復旧できるようにするための複数のAWSサービスを活用する必要があります。Route 53のフェイルオーバー、RDSのMulti-AZやRead Replica、Lambdaによるオートメーション、Global Acceleratorなどを組み合わせて、効果的な災害復旧戦略を実現することができます。

実践

AWS Lambdaを活用したAuto Scalingグループの自動調整

以下は、Lambda関数を使用してAuto Scalingグループの設定を変更するハンズオンの手順です。このハンズオンでは、ALB（アプリケーションロードバランサー）とAuto Scalingグループを作成し、Lambda関数をトリガーすることで、Auto Scalingグループの設定を変更するシナリオを実装します。

ALBとAuto Scalingグループを作成

Auto Scalingグループを作成するには、まずインスタンステンプレートを作成する必要があります。その後、Auto Scalingグループを作成して、スケーリングポリシーやターゲット設定を行います。以下にその手順を詳細に説明します。

1. EC2ダッシュボードに移動

AWS Management Consoleにログインし、EC2ダッシュボードに移動します。

左側のナビゲーションペインから「Auto Scaling Groups」を選択します。

2. Auto Scalingグループの作成

「Create Auto Scaling group」ボタンをクリックします。

3. インスタンステンプレートの作成

Auto Scalingグループに使用するインスタンステンプレートを作成します。このテンプレートは、Auto Scalingグループがインスタンスを起動する際に使用する設定を定義します。

左側のメニューから「Launch Templates」を選択し、「Create launch template」をクリックします。

Launch Template Name（例: my-auto-scaling-template）を入力します。

AMI (Amazon Machine Image)を選択します。例えば、Amazon Linux 2023など、アプリケーションに適したAMIを選びます。

インスタンスタイプ（例: t2.micro）を選択します。

その他の設定（ネットワーク、セキュリティグループ、IAMロールなど）を設定します。これらは、アプリケーションに必要なアクセス権やネットワークの設定を反映させるために重要です。

ユーザーデータ - オプション

4. Auto Scalingグループを作成

インスタンステンプレートが作成されたら、これを使用してAuto Scalingグループを作成します。

「Create Auto Scaling group」ボタンをクリックし、作成したインスタンステンプレートを選択します。

Auto Scalingグループ名を入力します（例: my-auto-scaling-group）。

ターゲットグループとして、ALB（Application Load Balancer）を選択します。ALBは、トラフィックをAuto Scalingグループ内のインスタンスに分散します。

新しいロードバランサーにアタッチすると設定します。新しいロードバランサーのスキームはInternet-facingに設定

新しいターゲットグループ名と設定します。

5. Auto Scalingポリシーの設定

Auto Scalingの設定を行います。これには、インスタンスの最小数、最大数、スケーリングのポリシーを含みます。

最小インスタンス数と最大インスタンス数を設定します。例えば、最小インスタンス数を0、最大インスタンス数を1に設定することができます。

スケーリングポリシーを設定します。これには、CPU使用率やネットワークトラフィックなどに基づいてインスタンス数をスケーリングするルールを作成します。

6. 必要なネットワーク設定を行う

Auto Scalingグループが使用するVPC（仮想プライベートクラウド）とサブネットを選択します。これにより、インスタンスが配置されるネットワーク環境が決定されます。

VPCとサブネットを選択します。通常は、ALBと同じVPC内のサブネットを選ぶことが一般的です。

必要に応じて、セキュリティグループやIAMロールを設定します。

7. Auto Scalingグループの作成

設定が完了したら、「Create Auto Scaling group」ボタンをクリックして、Auto Scalingグループの作成を完了します。

これで、Auto Scalingグループが作成され、インスタンステンプレートに基づいて自動的にインスタンスが起動されるようになります。また、ALBと連携してトラフィックを効率的に分散させることができます。

8. ALBのURLでアクセスしてみる

Lambda関数でAuto Scalingグループの設定を変更

ステップ1: Lambda関数を作成

AWS Lambdaコンソールに移動し、「Create function」をクリックします。

「Author from scratch」を選択し、関数の名前を入力します。

ランタイムとしてPython（またはNode.jsなど）を選択します。

必要なIAMロール（Auto ScalingグループにアクセスできるロールAutoScalingConsoleFullAccess）を設定します。

ステップ2: Lambda関数のコード作成

Lambda関数は、CloudWatchアラームやイベントによってトリガーされ、Auto Scalingグループの設定を変更します。以下は、Auto Scalingグループのインスタンス数を変更するための簡単なPythonコードの例です。

このコードでは、update_auto_scaling_group メソッドを使って、Auto Scalingグループの最小インスタンス数、最大インスタンス数、希望のインスタンス数を設定しています。

2. テストイベントの設定

Lambda関数を手動でテストすることができます。Lambdaコンソールで「Test」をクリックし、以下のようなテストイベントを設定します。

これにより、Lambda関数が正しく実行され、Auto Scalingグループの設定が変更されるかを確認できます。

4. 結果の確認

Lambda関数が正しく実行されると、Auto Scalingグループのインスタンス数が変更され、バックアップリージョンのリソースがスケールアップされます。また、ALBのトラフィックは新しい設定に基づいてバックアップリージョンへルーティングされます。

これで、Auto Scalingグループの設定をLambda関数を使って動的に変更するプロセスが完了します。

この手順を実行することで、AWS Lambdaを使って自動的にインフラの設定を変更する仕組みが構築できます。

一問道場

シナリオ:

ある企業が、AWS上で稼働する多層Webアプリケーションを運用しています。このアプリケーションは以下の構成を持っています:

Amazon EC2インスタンス: Application Load Balancer (ALB) の背後にあり、Auto Scaling Group (ASG) によって管理されている。

Amazon RDS Multi-AZ DBインスタンス: データを保存しており、バックアップリージョンにはRead Replicaがある。

Amazon Route 53: エンドユーザーにアプリケーションのエンドポイントを提供している。

現在、バックアップリージョンには以下の設定があります:

ALBとASG: 設定されているが、ASGの最小値と最大値は0になっている。

RDS Read Replica: バックアップリージョンに存在する。

要件:

RTO（復旧目標時間）を15分未満に短縮したい。

予算の制約があるため、アクティブ-アクティブ戦略は採用できない。

アプリケーションが自動的にバックアップリージョンにフェイルオーバーする仕組みを実現する必要がある。

選択肢:

Route 53レコードをレイテンシーベースのルーティングポリシーに変更し、2つのALB間でトラフィックを分散。

バックアップリージョンにAWS Lambda関数を作成：

リードレプリカを昇格。

Auto Scalingグループの値を変更。

CloudWatchアラームを設定：

HTTPCode_Target_5XX_Countメトリクスを監視。

プライマリリージョンのALBが障害を検知した際、Lambda関数を呼び出す。

バックアップリージョンにAWS Lambda関数を作成：

リードレプリカを昇格。

Auto Scalingグループの値を変更。

Route 53にヘルスチェックを設定：

Webアプリケーションを監視。

ヘルスチェックが不健康となった場合、SNS通知でLambda関数を呼び出す。

Route 53レコードをフェイルオーバーポリシーに設定：

障害発生時にバックアップリージョンのALBへトラフィックをルーティング。

バックアップリージョンのAuto Scalingグループの値をプライマリと同じに設定。

Route 53レコードをレイテンシーベースのルーティングポリシーに変更。

リードレプリカを削除し、代わりにスタンドアロンのRDS DBインスタンスを配置。

RDSインスタンス間でスナップショットとAmazon S3を使用したクロスリージョンレプリケーションを設定。

AWS Global Acceleratorのエンドポイントを作成し、2つのALBを同等の重み付けでターゲットに設定。

バックアップリージョンにAWS Lambda関数を作成：

リードレプリカを昇格。

Auto Scalingグループの値を変更。

CloudWatchアラームを設定：

HTTPCode_Target_5XX_Countメトリクスを監視。

プライマリリージョンのALBが障害を検知した際、Lambda関数を呼び出す。

問題の要点

目標：RTO（復旧時間目標）15分未満。

現状：プライマリとバックアップリージョンの構成があるが、バックアップリージョンは非稼働（Auto Scalingが0、リードレプリカのみ）。

制約：アクティブ-アクティブ構成不可（予算の制約）。

解答

各選択肢のポイント

A. レイテンシーベースのルーティング + CloudWatch

プライマリリージョンのALBでエラーを検知 → Lambda関数でバックアップを稼働。

問題：レイテンシーベースは常時トラフィック分散が発生し、コストが高い。

B. フェイルオーバーポリシー + ヘルスチェック

Route 53のヘルスチェック失敗でLambda関数がバックアップを稼働。

利点：コスト効率が高く、シンプルで自動化に優れる。

C. スタンドアロンDB + スナップショット

リードレプリカを削除し、独立したDBを配置。

問題：スナップショットでは同期遅延が発生し、データ整合性に課題。

D. Global Accelerator + CloudWatch

高速ルーティングで障害時の切り替えを実現。

問題：Global Acceleratorのコストが高い。

アクティブ-アクティブ構成 「AWS Global Acceleratorのエンドポイントを作成し、2つのALBを同等の重み付けでターゲットに設定」という設定は、アクティブ-アクティブ構成に該当し、トラフィックが両方のALBに均等に分散され、アプリケーションの可用性とパフォーマンスが向上します。

Global Accelerator と Route 53 の違い

特徴	Global Accelerator	Route 53
目的	パフォーマンス最適化（低レイテンシ、信頼性向上）	DNSベースのルーティング
プロトコル	TCP/UDP	DNS
切り替え速度	即時（数秒以内）	DNSキャッシュの影響で遅延あり
固定IPアドレス	提供される	提供されない
コスト	高め	比較的低コスト

Bが最適：コスト効率が良く、シンプルな構成でRTO 15分未満を達成可能。

💡

このケースにおいて、RDSの自動昇格とLambda関数での自動昇格との違いは？

主な違いのまとめ

特徴	RDSの自動昇格（Multi-AZ）	Lambda関数での自動昇格
対象	データベース層の障害 RDSのMulti-AZ構成（同一リージョン内）	アプリケーション層の障害 RDSのRead Replica（異なるリージョンにも対応可能）
昇格の速度	数分で自動的に昇格される	Lambda実行後、処理が完了するまで時間がかかる場合がある
運用の手間	AWSが自動で管理	Lambda関数の作成、管理、トリガー設定が必要
制限	同一リージョン内での復旧のみ	複数リージョン間のフェイルオーバーを柔軟に実現可能
柔軟性	自動化されており、設定変更なしで復旧できる	シナリオに応じて柔軟な設定が可能、ただし手動の操作が多い

結論

RDSの自動昇格（Multi-AZ）は、データベース層の障害、簡単で迅速な障害回復を提供し、特に単一リージョン内での復旧には理想的です。しかし、複数リージョンを跨る障害復旧には対応していません。

Lambda関数を利用した自動昇格は、アプリケーション層の障害のようなより柔軟なシナリオ対応が可能ですが、運用の手間や設定の複雑さが増します。複数リージョン間でのフェイルオーバーやRead Replicaの昇格に対応できる点で、Multi-AZの制限を超えることができます。

そのため、RDS Multi-AZの自動昇格を基本にし、必要に応じてLambdaを使って異なるリージョンへのフェイルオーバーやRead Replicaの昇格を行うのが理想的なアプローチと言えるでしょう。

009-ElasticCache

理論

構成図の勉強

この図は、可用性と冗長性を確保したAWSアーキテクチャを示しています。それぞれのコンポーネントがどのように配置され、どのように相互作用しているかについて詳しく説明します。

1. 全体の構成

このアーキテクチャは、複数のアベイラビリティゾーン (Availability Zones, AZ) にまたがって設計されています。

可用性を高めるために、重要なコンポーネントが冗長化されています。

2. アプリケーション層

Auto Scaling Group:

図の中央にあるオレンジ色の枠は、Auto Scaling Group を表しています。
複数の EC2 インスタンスが含まれ、Elastic Load Balancer (ELB) を通じてトラフィックを分散します。
Auto Scaling Group は動的にインスタンス数を調整し、障害時に新しいインスタンスを起動します。

Elastic Load Balancer (ELB):

トラフィックを複数の EC2 インスタンスに分散する役割を果たします。
これにより、単一インスタンスの障害に対応できます。

3. データベース層

Amazon RDS (Relational Database Service):

図の下部にある2つのデータベースアイコンは、RDS の Multi-AZ 構成を示しています。
プライマリインスタンス (左) と スタンバイインスタンス (右) が配置されています。
プライマリインスタンスが障害を起こした場合、自動的にスタンバイインスタンスにフェイルオーバーします。
データは同期的にレプリケーションされています。

4. キャッシュ層

ElastiCache for Redis:

図の右上にある「CACHE」というラベルのコンポーネントが ElastiCache を表します。
このクラスターは、レプリケーショングループを使用して Multi-AZ 構成が有効化されています。
Redis は高速なデータアクセスを提供し、障害発生時にはスタンバイノードが自動的に昇格します。

5. 可用性ゾーン (AZ)

図の全体は、2つのアベイラビリティゾーン (Availability Zone A と B) に分かれています。

各 AZ にコンポーネントを分散配置することで、ゾーン単位の障害に対応可能です。
例えば、AZ A に障害が発生しても、AZ B のコンポーネントが動作を継続します。

6. フローの概要

クライアントからのリクエストは ELB を通じて Auto Scaling Group 内の EC2 インスタンスに送信されます。

アプリケーションがデータベースにアクセスする際は、RDS (プライマリ) に接続します。

高速なデータ処理には ElastiCache (Redis) を使用します。

障害が発生した場合は、RDS と Redis のスタンバイインスタンスが自動的に引き継ぎます。

特徴と利点

高可用性: すべての主要コンポーネントが冗長化され、障害時の自動復旧が可能です。

スケーラビリティ: Auto Scaling により、トラフィックの変動に応じて EC2 インスタンスの数を動的に調整可能です。

低遅延: ElastiCache を活用し、データの読み取り速度を向上。

この設計は、可用性とパフォーマンスを最優先にしたベストプラクティスに基づく構成です。

疑問？

💡

ElastiCache for Redisはレプリケーショングループがあるのに、なぜかAmazon RDSはレプリケーショングループがないですか

解答

良い質問です！ElastiCache for Redis と Amazon RDS の設計が異なる理由は、それぞれが異なるユースケースと技術的要件に基づいているからです。以下で詳細に説明します。

レプリケーショングループは、リードレプリカの作成、管理、そして障害発生時のフェイルオーバーなどを制御します。

以下は、ElastiCache for RedisとAmazon RDSの簡潔な比較表です：

特徴	ElastiCache for Redis	Amazon RDS
主な役割	インメモリキャッシュ、セッション管理	リレーショナルデータベース
データ構造	キー・バリュー型	テーブル（リレーショナル）
高可用性	リードレプリカによるスケールアウト、フェイルオーバー	マルチAZデプロイによるフェイルオーバー
スケーラビリティ	読み取り負荷の分散（リードレプリカ）	リードレプリカで読み取り分散、書き込みはプライマリに依存
主な使用ケース	キャッシュ、セッション管理	トランザクション処理、データ整合性が必要なシステム
データ同期	非同期レプリケーション	同期レプリケーション（マルチAZの場合）
スケール方法	リードレプリカによるスケールアウト	リードレプリカまたは垂直スケーリング
高可用性の仕組み	レプリケーショングループ＋Multi-AZ	Multi-AZ 構成とリードレプリカ
フェイルオーバー	スタンバイノードが自動昇格	スタンバイインスタンスが自動昇格

なぜ違いがあるのか？

ElastiCache はキャッシュ用途に特化しており、データの永続性や整合性よりもパフォーマンスを重視しています。そのため、複数のノードに負荷を分散しやすい設計です。

RDS はデータベースとしての完全性や整合性が重要であり、特に書き込み操作で競合が起こらないようにする必要があります。そのため、複数プライマリノードの同時運用ではなく、スタンバイノードによるフェイルオーバーを採用しています。

この違いにより、それぞれのサービスは異なる設計でユースケースに最適化されているのです！

実践

VPC、EC2、IAMロールの作成

VPCの作成

プライベートサブネット2つ、パブリックサブネット2つを作成します。

EC2インスタンスの作成

インスタンスタイプ：t2.micro

OS：Amazon Linux 2023

セキュリティグループで自身のIPを許可

IAMロールのアタッチ

EC2インスタンスにRDSFullAccessとElastiCacheFullAccessロールをアタッチします。

ElastiCacheの設定

ElastiCacheの作成

Redis OSSを作成します。

マルチAZは無効化します。

サブネットグループを指定してRedisを配置します。

セキュリティグループの設定

EC2からElastiCacheへのアクセスを許可するため、EC2のセキュリティグループをElastiCacheのセキュリティグループのソースとして設定します。

ElastiCacheの選択肢比較

Valkeyキッシュ（ElastiCache for Redis）は高可用性とスケーラビリティに優れたキャッシュ。

Memcachedはシンプルなキャッシュシステムで、基本的なキャッシュ用途に適しています。

Redis OSSはオープンソース版で、より高機能ですが、運用がやや手間がかかります。

特徴	Valkeyキッシュ (Redis)	Memcached	Redis OSS
用途	高可用性、高スケーラビリティ	シンプルなキャッシュ	高機能なデータ構造
データ構造	リスト、セット、ハッシュ等	単純なキー-バリュー	高度なデータ構造
永続化	あり（スナップショット等）	なし	あり（バックアップ等）
スケーラビリティ	水平スケーリング	水平スケーリング	クラスター構成可能
可用性	高可用性（自動フェイルオーバー）	なし	高可用性
性能	高速	非常に高速	高速
運用の簡便さ	管理が簡単	簡単	自分で管理
主な使用ケース	キャッシュ、セッション管理	ページキャッシュ	キャッシュ、メッセージング

RDSの作成

MySQLを選択してRDSインスタンスを作成

必要なサブネットやセキュリティグループを設定。

EC2からRDSへの接続

EC2インスタンスからRDSインスタンスへの接続設定を行います。

RDSの作成

MySQLを選択。RDSインスタンスを作成し、必要なサブネットやセキュリティグループを設定。

EC2コンピューティングリソース接続オプションで、自動RDSサブネットを作成します。

RDS接続のため必要なツールのインストール

1.MySQLクライアントのインストール

2. RDSへの接続

例:

3. テストデータの投入

RDSに接続後、以下のコマンドでデータベースを作成し、テーブルにテストデータを挿入します。

Redis接続スクリプトを実行するための、Python環境の設定

Pythonのインストール

必要なパッケージのインストール

Pythonコードの準備と実行

環境変数設定

Pythonコードの実行

流れ：

Redisに接続。

環境変数からデータベース接続情報を取得。

fetch 関数でキャッシュに従業員情報があるか確認。

ない場合、データベースから情報を取得し、Redisにキャッシュとして保存。

キャッシュを使うことで、次回以降はデータベースアクセスなしで迅速にデータが取得可能。

要するに、Redisをキャッシュとして使い、データベースアクセスの回数を減らすことでパフォーマンスを向上させるアーキテクチャです。

以下の結果を確認、理解する

手順の終了と掃除

作成したインフラ（EC2、VPC、サブネットなど）の削除を行い、リソースをクリーンアップ。

アーキテクチャの目的

このハンズオンでは、Redisをキャッシュとして使用し、データベースアクセスを減らしてパフォーマンスを向上させる方法を実践的に学びます。データベースからのデータ取得時にキャッシュを利用することで、クエリの応答時間を短縮し、効率的なデータ処理を実現します。

一問道場

ある会社が重要なアプリケーションを次の構成で運用しています：

Amazon EC2 インスタンス：単一インスタンス上でアプリケーションをホストしています。

Amazon ElastiCache for Redis：単一ノードのクラスターを使用したインメモリデータストアを利用しています。

Amazon RDS for MariaDB：単一のデータベースインスタンスを使用しています。

このアプリケーションが正常に動作するには、各インフラコンポーネントが正常かつアクティブな状態である必要があります。

ソリューションアーキテクトは、このアプリケーションのアーキテクチャを改善し、可能な限り短いダウンタイムで自動復旧できるようにしたいと考えています。

次の選択肢の中から、要件を満たす3つのステップを選んでください（3つ選択）

Elastic Load Balancer を使用して、トラフィックを複数の EC2 インスタンスに分散させます。

また、これらの EC2 インスタンスを Auto Scaling グループに設定し、最小インスタンス数を2にします。

Elastic Load Balancer を使用して、トラフィックを複数の EC2 インスタンスに分散させます。

また、これらの EC2 インスタンスを「無制限モード」に設定します。

RDS DB インスタンスを変更して、同じアベイラビリティゾーン（AZ）にリードレプリカを作成します。

障害が発生した場合には、そのリードレプリカをプライマリインスタンスに昇格させます。

RDS DB インスタンスを変更して、2つのアベイラビリティゾーンにまたがる Multi-AZ 構成を有効にします。

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Auto Scaling グループを使用して最小インスタンス数を2に設定します。

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Multi-AZ 構成を有効にします。

補足

選択肢を検討し、適切な3つを選んでください。

解説

この問題では、アプリケーションのアーキテクチャを改善し、障害発生時に短いダウンタイムで自動復旧が可能な仕組みを構築する方法を検討します。それぞれの選択肢について詳しく解説します。

選択肢 A

Elastic Load Balancer を使用してトラフィックを複数の EC2 インスタンスに分散させる。また、これらの EC2 インスタンスを Auto Scaling グループに設定し、最小インスタンス数を2にする。

詳細解説：単一の EC2 インスタンスでは障害発生時にアプリケーションがダウンします。Elastic Load Balancer (ELB) を使えばトラフィックを複数の EC2 インスタンスに分散でき、Auto Scaling グループを設定して最小2インスタンスを維持すれば、1つのインスタンスが障害を起こしても残りのインスタンスで処理を続行できます。必須の選択肢です。

選択肢 B

Elastic Load Balancer を使用してトラフィックを複数の EC2 インスタンスに分散させる。また、これらの EC2 インスタンスを「無制限モード」に設定する。

詳細解説：無制限モードは EC2 インスタンスの CPU クレジットを超える利用を許可する設定です。これは突発的なトラフィック増加時に便利ですが、障害復旧には関係しません。この選択肢は不適切です。

選択肢 C

RDS DB インスタンスを変更して、同じアベイラビリティゾーン（AZ）にリードレプリカを作成する。障害が発生した場合には、そのリードレプリカをプライマリインスタンスに昇格させる。

詳細解説： RDS のリードレプリカは読み取り専用のデータベースとして機能し、プライマリインスタンス障害時に手動で昇格することは可能です。ただし、手動操作が必要であり自動復旧を保証しないため、この選択肢は不適切です。

選択肢 D

RDS DB インスタンスを変更して、2つのアベイラビリティゾーンにまたがる Multi-AZ 構成を有効にする。

詳細解説： Multi-AZ 構成を有効にすることで、プライマリインスタンスが障害を起こした場合に自動的にスタンバイインスタンスに切り替わります。これによりデータベースの高可用性が確保され、ダウンタイムが最小化されます。必須の選択肢です。

選択肢 E

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Auto Scaling グループを使用して最小インスタンス数を2に設定する。

詳細解説： ElastiCache は Auto Scaling グループをサポートしていません。この選択肢は技術的に実現不可能であり、不適切です。

選択肢 F

ElastiCache for Redis クラスターのレプリケーショングループを作成し、Multi-AZ 構成を有効にする。

詳細解説： ElastiCache のレプリケーショングループを作成し、Multi-AZ を有効にすることで、障害発生時にスタンバイノードが自動的に昇格されます。これによりデータ損失を防ぎ、可用性が向上します。必須の選択肢です。

正解の組み合わせ

A, D, F

A：アプリケーション層（EC2）の冗長性を確保。

D：データベース層（RDS）の自動復旧を実現。

F：キャッシュ層（ElastiCache）の冗長性と自動復旧を実現。

結論

この組み合わせにより、アプリケーション全体で短いダウンタイムでの自動復旧が可能になります。

010-CloudFrontにカスタムエラーページ

理論

AWSでのアプリケーション運用とALB (Application Load Balancer)

1. Application Load Balancer (ALB)

AWSのApplication Load Balancer(ALB)は、HTTPおよびHTTPSトラフィックを処理するためのマネージド型負荷分散サービスです。ALBは、リクエストをターゲットグループに分散させ、リクエストのルーティングを行います。ターゲットグループには、EC2インスタンス、コンテナ、IPアドレスなど、さまざまなリソースが含まれます。

502エラー (Bad Gateway): ALBがターゲット（EC2インスタンスやコンテナなど）から不正なレスポンスを受け取った場合に発生します。通常、ターゲットサーバーがリクエストを処理できない、またはエラーを返した場合に発生します。

ALBのエラーページ: ALBが502エラーを返すと、標準のエラーページ（AWSのデフォルトのエラーページ）が表示されます。これは、一般的なエラーメッセージしか提供せず、ユーザーに対して明確な解決策を示しません。

2. HTTPヘッダーの問題

ALBで502エラーが発生する原因の一つは、不正または不完全なHTTPヘッダーです。これらのヘッダーは、クライアント（ブラウザ）からサーバー（EC2インスタンスやアプリケーション）に送信される情報を含んでいます。例えば、アプリケーションの更新後にコードが変更され、不正なヘッダーを返すことが原因で502エラーが発生することがあります。

Malformed HTTP headers: HTTPヘッダーが不正な場合、ALBはターゲットからのレスポンスを処理できず、502エラーを返します。更新後に問題が発生するのは、新しいコードが不適切なヘッダーを送信することによって引き起こされます。

3. Amazon CloudFront

Amazon CloudFrontは、コンテンツ配信ネットワーク(CDN)サービスで、静的コンテンツや動的コンテンツを高速に配信するために使用されます。CloudFrontはALBの前に配置され、コンテンツをキャッシュして、ウェブサイトの応答速度を向上させることができます。

カスタムエラーページ設定: CloudFrontを使用する場合、特定のエラーページをカスタマイズすることができます。これにより、502エラーが発生した際にユーザーにカスタムメッセージを表示することが可能になります。

4. Amazon Route 53

Amazon Route 53は、AWSのDNSサービスであり、ドメイン名をIPアドレスに解決するために使用されます。また、ヘルスチェックを使用して、リソースが正常に動作しているかを監視することもできます。Route 53のヘルスチェックを利用すると、ALBのターゲットインスタンスが健康状態にない場合、トラフィックを他の健康なターゲットにリダイレクトすることができます。

5. カスタムエラーページの必要性

ALBの502エラーが発生した場合、標準のエラーページでは、ユーザーに何が起きているのかを詳しく説明できません。これに対して、カスタムエラーページを作成することにより、エラーが発生した理由や、次に取るべき行動（例えば、サポートへの連絡、サイトの再読み込み）を案内することができます。これにより、ユーザーエクスペリエンスを改善し、プロフェッショナルなブランドイメージを維持することができます。

カスタムエラーページの利点: ユーザーに対して適切なメッセージを提供し、エラー時にウェブサイトの他の部分へ誘導することができます。例えば、他の製品ページやサポートページへのリンクを表示することができます。

まとめ

ALBはAWS環境でのトラフィックの負荷分散に不可欠なサービスであり、502エラーが発生する場合、通常はターゲットインスタンスからの不正なレスポンスやアプリケーションの問題が原因です。このエラーに対してカスタムエラーページを設定することは、ユーザーに対してより良い体験を提供し、プロフェッショナルな印象を与えるために非常に重要です。また、Amazon CloudFrontやRoute 53といったAWSの他のサービスと連携することで、エラー時の応答を効率的に管理し、ユーザーへの影響を最小限に抑えることができます。

実践

このハンズオンでは、ALB（Application Load Balancer）、Amazon S3、CloudFront、Route 53などのAWSサービスを使用して、カスタムエラーページを設定する手順を学びます。

目的:

このハンズオンでは、502エラーが発生した場合に、ALBの標準エラーページの代わりにカスタムエラーページを表示する方法を学びます。具体的には、以下のステップを実行します：

ALBとEC2インスタンスのセットアップ

カスタムエラーページの作成とS3へのアップロード

CloudFrontを使用したカスタムエラーページの配信

ALBのエラー応答設定

今回の構成

以下、構成図になります。今回は、サーバーが停止した場合を想定し、その際のステータスコード504が発生した際に、AmazonS3から504エラー用のエラーページを返すよう設定します。

ステップ 1: ALBとEC2インスタンスのセットアップ

1.1 EC2インスタンスの作成

AWS Management ConsoleからEC2インスタンスを起動します。

必要なAMI（Amazon Linux 2023）を選択します。

セキュリティグループの設定で、HTTP（80）ポートを開放します。

ユーザーデータを追加

1.2 ALB（Application Load Balancer）の作成

EC2インスタンスの前にALBを配置します。

ALBのリスナーとしてHTTPを設定します。

ターゲットグループを作成し、EC2インスタンスをターゲットとして追加します。

1.3 ALBの動作確認

ALBのDNS名を使用して、EC2インスタンスが正常に表示されるかを確認します。

ステップ 2: カスタムエラーページの作成とS3へのアップロード

2.1 カスタムエラーページの作成

任意のエディタを使用して、502エラー時に表示するカスタムエラーページ（HTMLファイル）を作成します。

エラーページには、エラーの説明と、再試行の指示、サポートへのリンクなどを含めます。

2.2 S3バケットの作成

S3バケットを作成し、作成したカスタムエラーページをアップロードします。

バケットの公開設定を変更して、静的ウェブホスティングを有効にします。

2.3 S3のパブリックアクセス設定

アップロードしたカスタムエラーページがパブリックにアクセスできるよう、適切なアクセス許可を設定します。

ステップ 3: CloudFrontを使用したカスタムエラーページの配信

3.1 CloudFrontディストリビューションの作成

オリジンドメイン名 (Origin Domain Name) に、ALBのDNS名を指定（例: my-alb-123456789.us-west-2.elb.amazonaws.com）。

CloudFrontディストリビューションを作成

3.2 カスタマエラーPAGE設定

AmazonS3をAmazon CloudFrontのオリジンに追加

ビヘイビアとして、カスタムエラーページのリクエストがルーティングされる場所を指定します。今回設定するS3のパスパターンは/error.htmlです。

「エラーページ」タブをクリックし、「カスタムエラーレスポンスの作成」をクリックします。

「HTTPエラーコード」にカスタマイズしたいHTTPステータスコードを入力します。今回は「503」を選択します。

「エラーコードのTTL」にエラーページがキャッシュされる時間（秒）を入力します。

「カスタムエラーレスポンス」を「Yes」に設定します。

「応答ページパス」に、S3バケット内のカスタムエラーページへのパスを入力します。今回は「/error.html」とします。

「HTTPレスポンスコード」に、カスタムエラーページを返す際のHTTPステータスコードを入力します。

「作成」ボタンをクリックして設定を保存します。

ステップ 4: ALBのエラー応答設定

4.1 ALBのカスタムエラーページ設定

ALBの「エラー応答」設定を開き、「502エラー」時にCloudFrontのカスタムエラーページを表示するように設定します。

この設定を行うことで、502エラーが発生した際に、ALBが自動的にCloudFront経由でS3のカスタムエラーページを表示するようになります。

ステップ 5: 確認テスト

5.1 サーバー（EC2）を停止してみる

EC2インスタンスのアプリケーションを停止し、ALB経由でアクセスすると502エラーが発生します。

5.2 ALB-URLでアクセス、デフォルトのエラーペーが表示

5.3 CloudFrontのキャッシュを削除する

タブのキャッシュ削除で、/* を設定

5.4 CloudFront-URLでアクセス、カスタマのエラーペーが表示

カスタムエラーページが正常に表示されることを確認します。

まとめ

このハンズオンを通じて、AWSのALB、S3、CloudFront、Route 53を連携させ、502エラーが発生した場合にユーザーにカスタムエラーページを表示する方法を学びました。ALBやCloudFrontを活用することで、エラー時のユーザー体験を改善し、運用の効率化を図ることができます。

一問道場

ある小売業の企業が、AWS上でECサイトアプリケーションを運営しています。アプリケーションは、アプリケーションロードバランサー（ALB）の後ろにAmazon EC2インスタンスで動作しています。企業はAmazon RDS DBインスタンスをデータベースバックエンドとして使用しています。Amazon CloudFrontは、ALBを指す1つのオリジンで構成されており、静的コンテンツがキャッシュされています。Amazon Route 53は、すべてのパブリックゾーンをホストしています。

アプリケーションの更新後、ALBは時々502ステータスコード（Bad Gateway）エラーを返します。エラーの根本原因は、ALBに返された不正なHTTPヘッダーです。ウェブページは、ソリューションアーキテクトがウェブページをリロードした後に正常に表示されます。

企業が問題に取り組んでいる間、ソリューションアーキテクトは、標準のALBエラーページの代わりにカスタムエラーページを訪問者に提供する必要があります。

運用負荷が最も少ない方法でこの要件を満たす手順を選択してください（2つ選んでください）。

選択肢

A. Amazon S3バケットを作成し、S3バケットを静的ウェブページとしてホストするように設定し、カスタムエラーページをAmazon S3にアップロードする。

B. Amazon CloudWatchアラームを作成し、ALBの健康チェックレスポンスでTarget.FailedHealthChecksが0より大きい場合、AWS Lambda関数を呼び出す。そのLambda関数でALBの転送ルールを変更し、公開Webサーバーにポイントさせる。

C. 既存のAmazon Route 53レコードを修正し、ヘルスチェックを追加して、ヘルスチェックに失敗した場合にフォールバックターゲットを設定する。DNSレコードを変更して、公開Webページにポイントさせる。

D. Amazon CloudWatchアラームを作成し、ALBの健康チェックレスポンスでElb.InternalErrorが0より大きい場合、AWS Lambda関数を呼び出す。そのLambda関数でALBの転送ルールを変更し、公開Webサーバーにポイントさせる。

E. CloudFrontのカスタムエラーページを設定し、DNSレコードを変更して公開Webページにポイントさせる。

解説

この問題では、AWS上で運用されているECサイトアプリケーションにおいて、ALB（アプリケーションロードバランサー）が時々502エラー（Bad Gateway）を返します。このエラーの原因は、ALBに送られた不正なHTTPヘッダーです。エラーが発生した際、ソリューションアーキテクトがウェブページをリロードすると問題が解決します。現在、標準のALBエラーページではなく、カスタムエラーページを訪問者に表示する方法を求められています。

要件：カスタムエラーページを提供するため、最も運用負荷が少ない方法を選択します。

選択肢の日本語での整理

Amazon S3 バケットを作成し、S3 バケットを静的ウェブページとしてホスティングする設定を行い、カスタムエラーページを S3 にアップロードする。

→ この方法では、ALBがエラーを返す際に、S3でホスティングされたカスタムエラーページが表示されるため、運用負荷は低く、簡単に設定可能です。

Amazon CloudWatch アラームを作成し、ALB 健康チェックのレスポンスで Target.FailedHealthChecks の値が 0 より大きい場合に AWS Lambda 関数を起動する。そのLambda 関数を使って、ALBの転送ルールを変更し、パブリックにアクセス可能なウェブサーバーに指示を出す。

→ Lambda を使用するため、運用が複雑になり、過剰な対応となる可能性があります。

既存の Amazon Route 53 レコードを修正し、ヘルスチェックを追加して、ヘルスチェックに失敗した場合にフォールバックターゲットを設定する。DNS レコードを変更して、パブリックにアクセス可能なウェブページにポイントさせる。

→ Route 53 を使ったフォールバック設定は、エラー処理には適していますが、ALB エラーに対する直接的な対応策としては過剰であり、最適ではありません。

Amazon CloudWatch アラームを作成し、ALB 健康チェックのレスポンスで Elb.InternalError の値が 0 より大きい場合に AWS Lambda 関数を起動する。その Lambda 関数を使って、ALB の転送ルールを変更し、パブリックにアクセス可能なウェブサーバーに指示を出す。

→ Lambda 関数を使う方法は運用負荷が高く、ALBエラーへの対応としては過剰な対策となります。

CloudFront のカスタムエラーページを設定し、エラー発生時に表示されるカスタムエラーページを設定する。DNSレコードを変更して、パブリックにアクセス可能なウェブページに指示を出す。

→ CloudFront のカスタムエラーページを設定することで、ALBがエラーを返した場合にカスタムエラーページを表示でき、運用負荷も低くなります。

最小の運用負荷で目的を達成するための手順

A: S3にカスタムエラーページをアップロードし、静的ウェブサイトとしてホスティングする。

E: CloudFront のカスタムエラーページを設定する。

これらの手順を選ぶことで、ALB のエラー発生時にカスタムエラーページを表示し、最小限の運用負荷で問題を解決できます。

💡

なぜリロードした後に正常に表示されます

ALBのターゲットインスタンスの変動: アプリケーションが更新された直後、ALBが一部のEC2インスタンスに対して502エラーを返すことがあります。このエラーは、更新に伴って一時的に発生した問題（例えば、アプリケーションの不具合や依存関係の問題など）が原因です。しかし、ALBは複数のEC2インスタンスにリクエストを分散させるため、リロード時にはエラーを返すインスタンスではなく、正常に動作している別のインスタンスにリクエストが転送され、ページが正常に表示されることがあります。

💡

なぜ標準のALBエラーページの代わりにカスタムエラーページが必要？

プロフェッショナルなブランドイメージの維持: ALBの標準エラーページはAWSのデフォルトのものです。これが表示されると、ユーザーに対して問題が発生していることが示されますが、企業のブランドやプロフェッショナリズムが欠けている印象を与えることがあります。カスタムエラーページを設定することで、企業はエラーメッセージを自社のデザインに合わせ、ユーザーに対して統一されたブランド体験を提供することができます。