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

type

status

date

slug

summary

451-AWS SAP AWS 「理論・実践・一問道場」セカンダリーパス

理論

AWS環境における冗長性、可用性、セキュリティを確保するためのネットワーク接続の設計に関連する汎用的な知識は、クラウドインフラの可用性と耐障害性を高めるための基盤となります。以下にその主要なコンセプトを簡潔に説明します。

1. AWS Direct Connect

AWS Direct Connectは、オンプレミスのデータセンターとAWS間の専用ネットワーク接続を提供します。この接続はインターネットを使用しないため、高い帯域幅と低遅延が提供され、データ転送が安定しています。しかし、単一接続の障害が発生すると、全体の接続が影響を受けるため、冗長性の確保が重要です。

冗長性の確保: 複数のDirect Connect接続を使用することで、接続の冗長性を高めることができます。しかし、追加の専用線やインフラコストが発生するため、コストが高くなります。

2. AWS Site-to-Site VPN

Site-to-Site VPNは、インターネットを介してオンプレミスネットワークとAWS間を接続するためのセキュアな通信トンネルを作成するサービスです。VPN接続は、インターネットを利用するため、Direct Connect接続のバックアップとして利用されることが多いです。VPNは比較的コストが低く、柔軟に設定できるため、セカンダリーパスとして非常に有用です。

静的VPN vs 動的VPN: 静的VPNは設定がシンプルで運用が容易ですが、動的VPNはより柔軟で高い可用性を提供するため、用途に応じて使い分けることができます。

静的VPNは、接続先が固定されており、変更のないシンプルなネットワークに最適です。例えば、単一のオフィスと外部サービスとの接続で使用されます。

動的VPNは、拠点数が多く、頻繁にルート変更や冗長性の確保が必要な場合に適しており、大規模な企業ネットワークでの使用が一般的です。

3. 冗長性と可用性の設計

冗長性を確保するためには、複数の接続経路を利用することが基本です。AWS環境では、以下の方法で冗長性を強化できます。

複数のDirect Connect接続: 異なる物理的経路を使用して冗長性を持たせる。

VPNバックアップ: Direct Connectが利用できない場合に備え、VPN接続をバックアップとして設定します。

複数のAWSリージョンやアベイラビリティゾーン(AZ): 複数のリージョンやAZを利用することで、単一の障害点を排除します。

4. セキュリティ

AWSのネットワーク接続においては、データの安全性を確保するために暗号化が必要です。特に、インターネット経由の通信であるVPN接続や、Direct Connect経由で送受信されるデータに対しては、MACsec（Media Access Control Security）やIPsec（Internet Protocol Security）による暗号化が推奨されます。

5. コスト管理

冗長性や可用性を高めるための接続は重要ですが、コスト効果を考慮した設計が求められます。特に、VPN接続は比較的低コストで冗長性を確保できるため、コスト効率が良い選択肢となります。一方で、Direct Connect接続は高い帯域幅や低遅延が求められる場面においては非常に有用ですが、コストが高くなる点を理解しておく必要があります。

まとめ

AWSのネットワーク接続における冗長性、可用性、セキュリティを確保するためには、複数の接続経路やバックアップ接続を利用することが重要です。コスト効率を最適化するためには、VPNやDirect Connectを適切に組み合わせることが求められます。

実践

略

一問道場

会社は製造アプリケーションのためにAWS環境を設計しています。このアプリケーションは顧客に好評で、ユーザー数が増加しています。現在、会社はAWS環境とオンプレミスのデータセンターを1GbpsのAWS Direct Connect接続でつないでおり、BGPを設定しています。

会社は、既存のネットワーク接続ソリューションを更新し、可用性、耐障害性、セキュリティを高める必要があります。どのソリューションが最もコスト効率良く、要件を満たすでしょうか？

A. データ転送中のセキュリティを強化し、Direct Connect接続の冗長性を提供するために、動的なプライベートIP AWS Site-to-Site VPNをセカンダリーパスとして追加します。また、MACsecを設定してDirect Connect接続内のトラフィックを暗号化します。

B. 会社のオンプレミスデータセンターとAWS間に別のDirect Connect接続を追加し、転送速度を向上させ、冗長性を確保します。MACsecを設定してDirect Connect接続内のトラフィックを暗号化します。

C. 複数のプライベートVIFを設定し、オンプレミスデータセンターとAWS間でデータをロードバランスして冗長性を提供します。

D. データ転送中のセキュリティを強化し、Direct Connect接続の冗長性を提供するために、静的なAWS Site-to-Site VPNをセカンダリーパスとして追加します。

解説

この問題における最もコスト効率の良い解決策は、D. 静的なAWS Site-to-Site VPNをセカンダリーパスとして追加し、Direct Connect接続の冗長性を提供するです。

理由:

コスト効果: Site-to-Site VPNは、Direct Connectに比べて導入・運用コストが低いため、冗長性を追加する際に非常にコスト効率が良いです。静的VPNは手間も少なく、追加の高価な専用回線を使わずに済みます。

冗長性と可用性: AWS Direct Connectは信頼性が高いですが、単一の接続が切断されるリスクがあるため、セカンダリーパスとしてAWS Site-to-Site VPNを追加することで、冗長性を確保できます。VPN接続はインターネット経由で構成できるため、Direct Connectの回線がダウンした場合にバックアップとして機能します。

セキュリティ: VPNは、インターネット経由でのデータ転送にセキュリティを提供します。VPN接続を使用することで、Direct Connect接続の障害時にもセキュアにデータを転送できます。

他の選択肢について:

A: 動的プライベートIP AWS Site-to-Site VPNとMACsecの組み合わせは、冗長性を提供しますが、MACsecはDirect Connectの中で暗号化を行うため、VPNを導入するだけではなく追加の暗号化機能が求められ、設定やコストが増大します。

B: 追加のDirect Connect接続を作成することで冗長性を確保できますが、これにはかなりのコストがかかります。特に転送速度が大きく増加する場合や、規模の拡大が求められない限り、必要以上にコストがかかります。

C: 複数のプライベートVIFを使用してデータをロードバランスすることは冗長性を提供する可能性がありますが、複数のVIFの設定や管理が複雑になり、コストが増す可能性があります。

このように、最もコスト効率が良く、要求された冗長性を実現できるのはDの静的AWS Site-to-Site VPNです。

452-AWS SAP AWS 「理論・実践・一問道場」S3+DynamoDB

理論

1. Amazon S3（Simple Storage Service）

用途: 主に大容量ファイルやオブジェクトのストレージに使用されます。動画や画像、バックアップデータなどのファイルストレージに最適です。

特徴:

高スケーラビリティと耐久性（99.999999999%の耐久性）
効率的なデータ転送と迅速なスケーリング
S3バケットに保存されたデータは、高速でアクセス可能
容量無制限

ビデオファイル保存におけるメリット:

大きなファイル（最大数GB）を効率的に保存

動画データの保存や配信において、非常にスケーラブル

高度なアクセス制御が可能（例: IAMポリシーによるアクセス制御）

2. Amazon DynamoDB

用途: 完全マネージド型のNoSQLデータベースサービスで、特に低遅延とスケーラビリティが求められるアプリケーションに適しています。キー・バリュー型データの保存やメタデータ管理に適しています。

特徴:

高速なデータアクセス
自動スケーリング機能
複数リージョンにまたがるグローバルなデータストレージ

データ型: 数値、文字列、リスト、マップなどの柔軟なデータ型をサポート

メタデータの管理におけるメリット:

ビデオファイルのメタデータ（例: ファイル名、サイズ、アップロード日時など）の管理

動画ファイル自体はS3に保存し、その参照（S3のオブジェクトキー）をDynamoDBで管理するのが理想的な使い方

3. AWS Database Migration Service (DMS) と AWS Schema Conversion Tool (SCT)

DMS: データベースの移行ツール。オンプレミスや他のクラウド環境からAWSへのデータベース移行をサポートします。例えば、MySQLからAmazon AuroraやDynamoDBへの移行など。

SCT: データベーススキーマの変換ツール。異なるデータベース間でスキーマの互換性を確保するために使用します。

移行における役割:

既存のデータベース（例えばMySQL）をAWSの適切なサービス（DynamoDBやAuroraなど）に移行する際に、DMSとSCTを利用してデータ移行とスキーマ変換を行う。

4. Base64エンコーディング

用途: バイナリデータをASCII文字列に変換する方法。主に、バイナリデータ（例えば画像や動画）をテキストベースのデータ形式で扱う必要がある場合に使用します。

デメリット: Base64でエンコードしたデータは、元のサイズの約1.33倍に膨らむため、大きなファイル（例えばビデオ）を直接保存する際には非効率です。

ビデオデータ保存における問題点:

ビデオファイルをBase64エンコードで保存すると、サイズが大きくなり、ストレージと転送コストが増加します。また、パフォーマンスにも悪影響を及ぼす可能性があります。

5. アーキテクチャの選定

データベースとファイルストレージの分離:

ビデオデータのような大容量データは、データベースに直接保存せず、S3のようなオブジェクトストレージを使用することが一般的です。
データベースは、ビデオデータのメタデータ（ファイル名、サイズ、アップロード日時など）を管理するために使用し、実際のビデオファイルはS3に保存します。このアーキテクチャは、スケーラビリティと効率を高めるために推奨されます。

結論

S3は、大容量ファイルやオブジェクトの保存に非常に適しており、動画ファイルなどの大きなデータを効率よく管理するために理想的な選択肢です。

DynamoDBは、ビデオファイルのメタデータを管理するために使用され、S3のオブジェクトキーと組み合わせることで、高度なスケーラビリティを実現します。

Base64エンコードは、大きなファイルをデータベースに直接保存するためには非効率であり、ファイル自体はS3に保存する方法が推奨されます。

実践

略

一問道場

ある企業がアプリケーションを近代化し、AWSに移行する必要があります。アプリケーションは、ユーザープロファイルデータをオンプレミスのMySQLデータベースの1つのテーブルにテキスト形式で保存しています。

近代化後、ユーザーは最大4GBのサイズのビデオファイルをアプリケーションにアップロードできるようになります。他のユーザーはアプリケーションからそのビデオファイルをダウンロードできるようにします。企業は、アプリケーションのパフォーマンスに影響を与えない、急速にスケーリング可能なビデオストレージソリューションが必要です。

どのソリューションがこの要件を満たすでしょうか？

A. AWSデータベース移行サービス（AWS DMS）を使用して、データベースをAmazon Aurora PostgreSQLに移行します。ビデオをデータベース内のTEXTカラムにbase64エンコードされた文字列として保存します。

B. AWSデータベース移行サービス（AWS DMS）を使用して、データベースをAmazon DynamoDBに移行し、AWSスキーマ変換ツール（AWS SCT）を使用します。ビデオをAmazon S3のオブジェクトとして保存し、S3キーを対応するDynamoDBアイテムに保存します。

C. AWSデータベース移行サービス（AWS DMS）を使用して、データベースをAmazon Keyspaces（Apache Cassandra）に移行し、AWSスキーマ変換ツール（AWS SCT）を使用します。ビデオをAmazon S3のオブジェクトとして保存し、S3オブジェクト識別子を対応するAmazon Keyspacesのエントリに保存します。

D. AWSデータベース移行サービス（AWS DMS）を使用して、データベースをAmazon DynamoDBに移行し、AWSスキーマ変換ツール（AWS SCT）を使用します。ビデオを対応するDynamoDBアイテムにbase64エンコードされた文字列として保存します。

解説

この問題は、アプリケーションをAWSに移行し、特にビデオファイルのストレージに関する要件を満たすソリューションを求めています。ビデオファイルのサイズ（最大4GB）が大きいため、適切なストレージの選択が重要です。また、アプリケーションのパフォーマンスに影響を与えないことが求められています。各選択肢を解説します。

選択肢 A:

「AWS DMSを使用して、データベースをAmazon Aurora PostgreSQLに移行します。ビデオをデータベース内のTEXTカラムにbase64エンコードされた文字列として保存します。」

問題点: ビデオをデータベース内のテキストカラムにbase64エンコードして保存する方法は、ビデオのサイズ（最大4GB）に対して不適切です。base64エンコードすると、データのサイズが約1.33倍になります。このため、データベースのストレージコストが高くなり、パフォーマンスにも悪影響を及ぼす可能性があります。また、ビデオファイルのアップロードやダウンロードの速度も遅くなり、アプリケーションのパフォーマンスに影響を与えるでしょう。

結論: この方法は、ビデオのストレージには適していません。

選択肢 B:

「AWS DMSを使用して、データベースをAmazon DynamoDBに移行し、AWS SCTを使用します。ビデオをAmazon S3のオブジェクトとして保存し、S3キーを対応するDynamoDBアイテムに保存します。」

適切な選択肢: DynamoDBは、キー・バリュー型データベースであり、ビデオデータのメタデータ（例えば、ビデオのS3オブジェクトキー）を保存するのに適しています。一方、実際のビデオファイル自体は、Amazon S3に保存できます。Amazon S3は大規模なファイルストレージを効率的に処理でき、スケーラビリティに優れています。DynamoDBは、ビデオのメタデータを管理するために利用し、S3は実際のビデオファイルの格納に使用するというアーキテクチャが適切です。

結論: このソリューションは、要件を満たし、スケーラブルで効率的な方法です。

選択肢 C:

「AWS DMSを使用して、データベースをAmazon Keyspaces（Apache Cassandra）に移行し、AWS SCTを使用します。ビデオをAmazon S3のオブジェクトとして保存し、S3オブジェクト識別子を対応するAmazon Keyspacesのエントリに保存します。」

適切だが過剰な選択肢: Amazon Keyspaces（Apache Cassandra）は、スケーラブルなNoSQLデータベースサービスですが、DynamoDBよりも管理や運用の手間がかかることが多いです。Keyspacesもビデオのメタデータを保存するには適していますが、DynamoDBと比較すると、運用の複雑さが増すため、特にシンプルで効果的なソリューションを求めている場合には過剰です。

結論: Keyspacesは適切ですが、DynamoDBよりもシンプルでないため、最適な選択肢ではありません。

選択肢 D:

「AWS DMSを使用して、データベースをAmazon DynamoDBに移行し、AWS SCTを使用します。ビデオを対応するDynamoDBアイテムにbase64エンコードされた文字列として保存します。」

問題点: DynamoDBにビデオファイルをbase64エンコードして保存する方法は、選択肢Aと同様に不適切です。ビデオのデータ量が大きいため、データベースにbase64エンコードされたビデオを保存すると、ストレージの効率が悪化し、パフォーマンスが低下します。また、DynamoDBは大きなバイナリデータの保存には最適ではないため、S3に保存する方が適しています。

結論: ビデオをDynamoDBに保存するのは非効率的であり、最適な方法ではありません。

結論:

選択肢Bが最も適切です。DynamoDBを使用してメタデータを管理し、実際のビデオデータはAmazon S3に保存するアーキテクチャは、スケーラブルで効率的です。

453-AWS SAP AWS 「理論・実践・一問道場」AWS Backup

理論

AWS Backupのデフォルトバックアッププランには、バックアップの頻度に関して明確な定義がありますが、RPO（復旧時点目標）はバックアップの頻度に依存します。

デフォルトバックアッププランは通常、1日1回のバックアップを行います。このため、RPOは最大で24時間となります。つまり、バックアップが1日に1回実行される場合、最長で24時間前のバックアップに基づいて復元が行われることになります。

したがって、デフォルトプランのRPOは 最大24時間 となります。このため、RPOを100分以内に設定したい場合、カスタムバックアッププランでバックアップの頻度を調整する必要があります。

Amazon EFSのバックアップと復旧のポイント

Amazon EFS (Elastic File System):

スケーラブルで高可用性を持つファイルストレージ。

他のAWSサービス（EC2、Lambdaなど）からアクセス可能。

バックアップの設定:

AWS Backup: EFSのバックアップを簡単に自動化できる。

デフォルトバックアッププランでのスケジュール設定が可能（例: 1時間ごと、日次など）。

KMS（AWS Key Management Service）:

EFSのデータは暗号化可能。KMSキーを使用して暗号化。

バックアップがKMSで暗号化されている場合、バックアップの作成に適切な権限が必要。

RPO（復旧時点目標）:

RPOは、失われたデータをどれだけ迅速に復元できるかを示す指標。

バックアップの頻度を高めることで、RPOを短縮できる。

バックアップの頻度:

頻繁なバックアップ: より短いRPOを実現するためにバックアップ頻度を調整する。

例えば、30分ごとのバックアップはRPO 100分以内を満たす。

復旧手順:

バックアップを使用した復元で、削除されたデータを迅速に回復できる。

連続バックアップやクロスリージョンレプリケーションは、データ損失を防ぐための追加的な対策。

最適なバックアップ戦略:

バックアップ頻度の設定: RPO要件に応じてバックアップ頻度を設定することが最も重要。バックアップスケジュールが短いほど、迅速な復旧が可能になる。

実践

略

一問道場

ある会社は、Amazon Elastic File System (Amazon EFS) ファイルシステムでドキュメントを保存および管理しています。このファイルシステムは、AWS Key Management Service (AWS KMS) キーで暗号化されています。ファイルシステムは、独自のソフトウェアを実行するAmazon EC2インスタンスにマウントされています。会社はファイルシステムの自動バックアップを有効にしており、バックアップはAWS Backupのデフォルトバックアッププランを使用しています。

ソリューションアーキテクトは、削除されたドキュメントをRPO（復旧時点目標）100分以内で回復できることを確認する必要があります。

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

A. 新しいIAMロールを作成し、新しいバックアッププランを作成します。新しいIAMロールを使用してバックアップを作成し、KMSキーのポリシーを更新して、新しいIAMロールがキーを使用できるようにします。ファイルシステムのバックアップのために1時間ごとのバックアップスケジュールを実装します。

B. 新しいバックアッププランを作成し、KMSキーのポリシーを更新して、AWSServiceRoleForBackup IAMロールがキーを使用できるようにします。カスタムのcron式を実装して、ファイルシステムのバックアップを30分ごとに実行します。

C. 新しいIAMロールを作成し、既存のバックアッププランを更新します。KMSキーのポリシーを更新して、新しいIAMロールがキーを使用できるようにします。ポイントインタイム回復のために連続バックアップを有効にします。

D. 既存のバックアッププランを使用し、KMSキーのポリシーを更新して、AWSServiceRoleForBackup IAMロールがキーを使用できるようにします。ファイルシステムのクロスリージョンレプリケーションを有効にします。

解説

選択肢 A の内容は、1時間ごとのバックアップスケジュールを設定することです。問題の要件では RPO（復旧時点目標）100分以内 の回復が求められています。これを満たすためには、バックアップの頻度が 1時間以内 である必要があります。

Aの評価:

バックアップ頻度: 1時間ごとのバックアップ。これは100分以内に回復できることを意味します。例えば、ファイルが削除されたとしても、次のバックアップが1時間以内に行われるので、最大でも59分のデータ損失が発生することになります。これにより、RPO 100分以内という要件を満たしています。

他の選択肢との比較:

Bの選択肢では、30分ごとのバックアップを設定しますが、AWS Backupのデフォルトバックアッププランを使用している前提です。これは、手動で設定を変更する必要があり、指定された要件には過剰な設定となる可能性があり、特に「カスタムのcron式」を実装するのが必要という点で余計な手間がかかるかもしれません。

CとDでは、連続バックアップやクロスリージョンレプリケーションに焦点を当てていますが、これらはデータのバックアップやリカバリーの手段として有効であっても、RPOの要件を満たすためには必ずしも最適ではないため、この選択肢は条件を過剰に満たすことになります。

結論:

Aの選択肢は最もシンプルで効率的にRPO 100分以内を満たす方法であり、過剰な設定や不必要な手間を省いて要件を満たすため、正解です。

454-AWS SAP AWS 「理論・実践・一問道場」STS MFA

理論

1. MFA（マルチファクター認証）

MFAは、ユーザーがアクセスする際に追加の認証手段を要求するセキュリティ機能です。通常のパスワードに加え、物理的なデバイスやアプリを使って認証します。

AWSでは、IAMユーザーや管理者アカウントにMFAを設定することで、不正アクセスを防止できます。

2. 一時的な認証情報（AWS STS）

*AWS Security Token Service (STS)**を利用すると、一時的で期限付きの認証情報を発行できます。

一時的認証情報は、通常のアクセスキーとは異なり、短期間で有効期限が切れるため、リスクを減らすことができます。

STSを利用することで、長期間有効なアクセスキーを使う必要がなくなり、セキュリティが向上します。

3. IAMポリシーでのMFA要求

IAMポリシーを使って、MFAが必要な操作を定義することができます。例えば、S3へのアクセスや特定の管理操作に対してMFAを必須とするポリシーを設定することができます。

これにより、万が一アクセスキーが漏洩しても、MFAがないと操作が実行できないため、セキュリティが強化されます。

4. アクセスキーの管理

AWSでは、アクセスキーを使ってCLIやSDKを通じてアクセスしますが、これを長期間使用することはセキュリティリスクを高めます。

最適なセキュリティ実践として、一時的な認証情報を使用したアクセスや、アクセスキーの定期的なローテーションが推奨されます。

結論：

MFAと一時的な認証情報（AWS STS）を組み合わせることで、AWS環境でのセキュリティを強化し、アクセスキーの管理に伴うリスクを軽減できます。

実践

略

一問道場

質問 #454

ソリューションアーキテクトは、クラウドエンジニアチームがAWS CLIを使用してAmazon S3バケットにオブジェクトをアップロードするためのセキュアな方法を提供する必要があります。

各クラウドエンジニアはIAMユーザー、IAMアクセスキー、仮想マルチファクター認証（MFA）デバイスを持っています。クラウドエンジニア用のIAMユーザーは「S3-access」という名前のグループに属しています。クラウドエンジニアはAmazon S3でアクションを実行するためにMFAを使用しなければなりません。

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

A. S3バケットにポリシーをアタッチして、IAMユーザーがS3バケットでアクションを実行する際にMFAコードの入力を促します。IAMアクセスキーを使用してAWS CLIからAmazon S3を呼び出します。

B. S3-accessグループの信頼ポリシーを更新して、グループを引き受ける際にMFAの使用を要求します。IAMアクセスキーを使用してAWS CLIからAmazon S3を呼び出します。

C. S3-accessグループにポリシーをアタッチして、MFAが存在しない場合はすべてのS3アクションを拒否します。IAMアクセスキーを使用してAWS CLIからAmazon S3を呼び出します。

D. S3-accessグループにポリシーをアタッチして、MFAが存在しない場合はすべてのS3アクションを拒否します。AWS Security Token Service（AWS STS）から一時的な認証情報を要求します。一時的な認証情報をAmazon S3が参照するプロファイルにアタッチし、ユーザーがAmazon S3でアクションを実行する際に使用します。

解説

この問題では、クラウドエンジニアがMFAを使ってAWS CLIでS3にオブジェクトをアップロードする方法を選ぶ必要があります。

選択肢A、B、Cは、アクセスキーを使い続けるため、アクセスキーの管理が必要であり、要件に合いません。

選択肢Dは、一時的な認証情報（STS）を使用し、MFAを強制するポリシーを設定することで、アクセスキーの管理を避けつつセキュリティを強化します。

したがって、選択肢Dが正解です。

455-AWS SAP AWS 「理論・実践・一問道場」Windows Web Application Migration + Beanstalk

理論

.NET は、Windows、Linux、macOS で Web サイト、サービス、コンソールアプリケーションを実行するためのクロスプラットフォームの実装です。GitHub で .NET はオープンソースです。.NET は以前 .NET Core と呼ばれていました。

AWS Elastic Beanstalk は、既存のアプリケーションをAWSクラウドに移行するのに適したサービスです。特に、コードの大幅な変更が不要で、インフラの管理を最小限に抑えたい場合に便利です。

Elastic Beanstalkが移行に適している理由：

アプリケーションコードを変更しなくても移行可能

.NET Framework など、Windowsベースのレガシーアプリケーションをそのまま移行できます。コードの修正なしで、AWS上で動作させることができます。

インフラの管理が不要

Elastic Beanstalkは、アプリケーションをデプロイするために必要なインフラ（EC2インスタンスやロードバランサー、データベース接続など）を自動的に構築し、管理してくれます。開発者はインフラ管理を気にせず、アプリケーションの開発に集中できます。

自動スケーリング

トラフィックの変動に応じて、Elastic Beanstalkはインスタンスを自動で増減させることができます。これにより、アプリケーションのパフォーマンスを保ちながら、高可用性を維持できます。

多くのプラットフォームをサポート

Elastic Beanstalkは、.NETやJava、Python、Node.jsなど、さまざまな開発環境をサポートしており、レガシーアプリケーションの移行に適しています。

モニタリングとログ管理の統合

AWS CloudWatchとの統合により、アプリケーションのパフォーマンスや状態をリアルタイムで監視でき、問題が発生した際にはすぐに対応できます。

移行に適したケース：

Webアプリケーションの移行

.NETで構築されたASP.NETなどのWebアプリケーションは、そのままElastic Beanstalkで動作させることができます。

インフラ管理を最小限にしたい場合

インフラの構成や管理に手間をかけたくない場合、Elastic Beanstalkは非常に便利です。AWSがその管理を自動で行ってくれます。

早急に移行したい場合

インフラ管理に時間をかけず、アプリケーションコードの移行だけで済ませたい場合にも最適です。

まとめ：

Elastic Beanstalkは、既存のアプリケーションを大きな変更なしにAWSに移行したい場合に最適な選択肢です。インフラの管理を自動化し、スケーリングやモニタリング機能も提供しているため、移行後も運用がスムーズになります。

クラウド移行の基本的なアプローチ

企業がオンプレミスのレガシーアプリケーションをクラウドに移行する際、以下のアプローチがよく用いられます。

1. リフトアンドシフト (Lift and Shift)

説明: 既存のアプリケーションやデータを変更せずにそのままクラウドに移行する方法。コード変更なしで迅速に移行できるため、時間を短縮できます。

ツール例: AWS Elastic Beanstalk、AWS EC2

適用ケース: コード変更を避け、迅速に移行したい場合に有効。

2. リファクタリング (Refactoring)

説明: アプリケーションをクラウドに適した形に変更・最適化する方法。コードの一部を変更することで、パフォーマンスやスケーラビリティを向上させることができます。

ツール例: AWS Toolkit for .NET、コンテナ化（ECS、EKS）

適用ケース: 長期的なコスト削減やスケーラビリティの向上が求められる場合。

3. コンテナ化

説明: アプリケーションをコンテナとしてパッケージ化し、柔軟に管理できる環境で実行する方法。クラウド環境において高いスケーラビリティや可搬性を持ちます。

ツール例: Amazon ECS、Amazon EKS

適用ケース: マイクロサービスアーキテクチャを採用している場合や、高いスケーラビリティが求められる場合。

4. プラットフォーム管理 (Platform as a Service, PaaS)

説明: インフラ管理を最小限に抑え、アプリケーションの開発やデプロイに集中できる環境を提供する方法。これにより、開発者はインフラの管理から解放され、コードのみに集中できます。

ツール例: AWS Elastic Beanstalk、Google App Engine、Azure App Service

適用ケース: インフラ管理を回避し、アプリケーションの運用に集中したい場合。

5. インフラ管理の抽象化

説明: クラウドサービスを使用してインフラ管理の手間を軽減する方法。自動化されたスケーリング、モニタリング、管理機能を活用し、効率的に運用できます。

ツール例: AWS Fargate（ECS、EKS用）、Elastic Beanstalk

適用ケース: インフラの管理にかかるコストや労力を削減したい場合。

まとめ

リフトアンドシフトは、迅速な移行を重視し、コード変更なしで移行するため、インフラ管理の手間を減らす目的に最適です。

リファクタリングやコンテナ化は、長期的にスケーラビリティやパフォーマンスの向上を目指す場合に適していますが、コード変更が必要です。

Elastic BeanstalkやFargateを利用することで、インフラ管理を最小化し、アプリケーションの運用に集中できます。

これらのアプローチを選ぶ際は、移行の目的（迅速性、スケーラビリティ、コスト削減）やインフラ管理の可否に応じて最適なツールを選定することが重要です。

実践

略

一問道場

質問 #455

ある企業が、オンプレミスのレガシーアプリケーション60個をAWSに移行する必要があります。これらのアプリケーションは.NET Frameworkをベースにしており、Windows上で実行されています。

企業は、移行時間を最小限に抑え、アプリケーションコードの変更を必要としないソリューションを求めています。また、インフラの管理は避けたいと考えています。

どのソリューションがこれらの要件を満たすでしょうか？

A. アプリケーションをリファクタリングし、AWS Toolkit for .NET Refactoringを使用してコンテナ化します。コンテナ化したアプリケーションをAmazon Elastic Container Service (Amazon ECS)のFargateローンチタイプでホストします。

B. Windows Web Application Migration Assistantを使用して、アプリケーションをAWS Elastic Beanstalkに移行します。Elastic Beanstalkを使用してアプリケーションをデプロイし、管理します。

C. Windows Web Application Migration Assistantを使用して、アプリケーションをAmazon EC2インスタンスに移行します。EC2インスタンスを使用してアプリケーションをデプロイし、管理します。

D. アプリケーションをリファクタリングし、AWS Toolkit for .NET Refactoringを使用してコンテナ化します。コンテナ化したアプリケーションをAmazon Elastic Kubernetes Service (Amazon EKS)のFargateローンチタイプでホストします。

解説

この問題では、レガシーアプリケーションの移行に関する要件が提示されています。要件は以下の通りです：

移行時間を最小限に抑える

アプリケーションコードの変更を必要としない

インフラの管理を避けたい

これを踏まえ、各選択肢を評価してみましょう。

A. アプリケーションをリファクタリングし、AWS Toolkit for .NET Refactoringを使用してコンテナ化します。コンテナ化したアプリケーションをAmazon Elastic Container Service (Amazon ECS)のFargateローンチタイプでホストします。

リファクタリングとコンテナ化はコード変更を必要とし、時間と労力がかかります。要件に「コード変更なし」とありますので、こちらは適していません。

B. Windows Web Application Migration Assistantを使用して、アプリケーションをAWS Elastic Beanstalkに移行します。Elastic Beanstalkを使用してアプリケーションをデプロイし、管理します。

Elastic Beanstalkは、アプリケーションのデプロイや管理を簡略化し、インフラ管理を抽象化します。このアプローチは、コードの変更なしで既存のアプリケーションを移行し、運用管理を簡素化するため、要件に合っています。

C. Windows Web Application Migration Assistantを使用して、アプリケーションをAmazon EC2インスタンスに移行します。EC2インスタンスを使用してアプリケーションをデプロイし、管理します。

EC2インスタンスを使用する場合、インフラの管理が必要となります。要件に「インフラ管理を避けたい」とありますので、この選択肢は不適切です。

D. アプリケーションをリファクタリングし、AWS Toolkit for .NET Refactoringを使用してコンテナ化します。コンテナ化したアプリケーションをAmazon Elastic Kubernetes Service (Amazon EKS)のFargateローンチタイプでホストします。

こちらもリファクタリングとコンテナ化が必要で、コード変更なしでの移行には不向きです。さらに、EKSはKubernetesの管理が必要であり、インフラ管理を避けたいという要件には適しません。

結論

最も適切な選択肢は B です。AWS Elastic Beanstalkを使用することで、アプリケーションコードの変更なしで移行し、インフラ管理を簡素化することができます。

456-AWS SAP AWS 「理論・実践・一問道場」AWS Batch と EC2スポットインスタンス

理論

大規模バッチ処理におけるコスト効率を最適化する方法

AWS Batch

大規模なバッチ処理ジョブに最適なマネージドサービス。

自動的にコンピューティングリソースをスケールし、処理の効率化を図ります。

スポットインスタンスを使用することでコストを大幅に削減可能。スポットインスタンスは、余剰のEC2リソースを利用し、通常のオンデマンドインスタンスより安価で提供されます。

EC2スポットインスタンス

スポットインスタンスはコストが最大90%削減できるため、時間に敏感でないジョブに最適。

SPOT_CAPACITY_OPTIMIZED戦略を利用すると、リソースの確保がより効率的に行え、計算リソースを安定的に確保できます。

AWS Lambda

サーバーレスでスケーラブルな処理を提供しますが、メモリと実行時間に制限があるため、15〜20GBのデータを扱う大規模なバッチ処理には不向き。

Amazon EKS (Elastic Kubernetes Service)

Kubernetesでの処理に特化したマネージドサービスですが、複雑なオーケストレーションが必要となり、シンプルなバッチ処理には過剰な場合があります。

まとめ

大規模なバッチ処理でコスト効率を最大化するには、AWS Batch と EC2スポットインスタンス を組み合わせて使用するのが最適です。ジョブが中断可能であれば、スポットインスタンスを活用することで、処理コストを大幅に削減できます。

実践

略

一問道場

質問 #456

ある企業が、Amazon S3バケットに保存されているデータで大規模なバッチ処理ジョブを実行する必要があります。ジョブはシミュレーションを行い、ジョブの結果は時間に敏感ではなく、中断に耐えることができます。

各ジョブは、S3バケットに保存されているデータを15〜20GB処理する必要があります。企業は、ジョブの出力を別のAmazon S3バケットに保存して、さらに分析を行います。

どのソリューションが最もコスト効率よくこれらの要件を満たすでしょうか？

A. サーバーレスデータパイプラインを作成します。オーケストレーションにはAWS Step Functionsを使用します。データ処理にはAWS Lambda関数（プロビジョニングされた容量を使用）を使います。

B. Amazon EC2スポットインスタンスを含むAWS Batchコンピューティング環境を作成します。SPOT_CAPACITY_OPTIMIZED割り当て戦略を指定します。

C. Amazon EC2オンデマンドインスタンスとスポットインスタンスを含むAWS Batchコンピューティング環境を作成します。スポットインスタンスにはSPOT_CAPACITY_OPTIMIZED割り当て戦略を指定します。

D. Amazon Elastic Kubernetes Service (Amazon EKS)を使用して処理ジョブを実行します。Amazon EC2オンデマンドインスタンスとスポットインスタンスの組み合わせを含む管理ノードグループを使用します。

解説

この問題は、大量のデータを処理するためのコスト効率の良いソリューションを選択することに関するものです。要件としては、シミュレーションを行うジョブで、時間に敏感ではなく、中断しても問題ないこと、15〜20GBのデータを処理し、結果を別のS3バケットに保存するというものです。これらの要件を満たし、最もコスト効率の良いソリューションを選ぶ必要があります。

各選択肢の評価:

A. サーバーレスデータパイプラインを使用 (AWS Lambda + AWS Step Functions)

不適切な選択肢: サーバーレスのAWS Lambdaは非常にスケーラブルで便利ですが、Lambdaには実行時間とメモリ制限があります。特に、1回のジョブで15〜20GBのデータを処理する場合、Lambdaのメモリ制限や最大実行時間（15分）が制約となる可能性があります。また、Lambdaのプロビジョニングされた容量を使用することでコストが増加するため、この方法は最適ではありません。

B. AWS BatchとEC2スポットインスタンス (SPOT_CAPACITY_OPTIMIZED)

適切な選択肢:AWS Batchは、大規模なバッチ処理に最適なサービスで、特にジョブが中断可能である場合に非常にコスト効率が良いです。EC2スポットインスタンスは、定常的なインスタンスよりもはるかに低コストで、AWSが余剰のコンピューティング能力を利用して提供するインスタンスです。スポットインスタンスのSPOT_CAPACITY_OPTIMIZED割り当て戦略を使うことで、リソースの確保がより効率的になります。ジョブが中断可能なため、スポットインスタンスは適しています。

C. AWS Batchとオンデマンドおよびスポットインスタンス (SPOT_CAPACITY_OPTIMIZED)

不適切な選択肢: この選択肢は、スポットインスタンスとオンデマンドインスタンスを組み合わせて使用します。オンデマンドインスタンスはスポットインスタンスよりも高価で、コスト効率を重視する場面では過剰です。ジョブが中断可能であるため、オンデマンドインスタンスを使用する必要はなく、スポットインスタンスのみを使用したほうがよりコスト効率が良いです。

D. Amazon EKS (Elastic Kubernetes Service) + EC2オンデマンドおよびスポットインスタンス

不適切な選択肢: Amazon EKSはKubernetesを管理するサービスですが、バッチ処理のようなシンプルなジョブに対しては過剰な選択肢です。Kubernetesは複雑なオーケストレーションを提供しますが、その設定と管理には追加のコストと時間がかかります。また、スポットインスタンスとオンデマンドインスタンスを組み合わせて使用する点もコスト効率を損なう要因となります。

最適解:

B. AWS Batch と EC2スポットインスタンス (SPOT_CAPACITY_OPTIMIZED) が最もコスト効率が良い解決策です。AWS Batchはバッチ処理に最適化されており、EC2スポットインスタンスを使用することでコストを大幅に削減できます。また、ジョブが中断可能であるため、スポットインスタンスを使用するのが理想的です。SPOT_CAPACITY_OPTIMIZED戦略を使うことで、リソースの確保が効率的に行えます。

457-AWS SAP AWS 「理論・実践・一問道場」AWS DataSyncエージェントをHyper-V VM

理論

AWSによる画像データのアーカイブとコスト効率の最適化

AWS DataSync

オンプレミスからAWSへのデータ転送を効率的に管理できるサービス。

大量のデータを高スループットで移行でき、転送のスケジュールや帯域幅制限の設定も可能。

S3 Glacier Deep Archive

最もコスト効率の良い長期アーカイブ用ストレージ。

頻繁にアクセスされないデータ（例えば、バックアップやアーカイブ用データ）の保存に適しており、アクセスが必要な場合でも低コストで保存できます。

Storage Gateway

オンプレミスのストレージとAWSクラウドのストレージを接続し、クラウドバックアップやアーカイブを行うためのサービス。

Tape Gatewayはテープバックアップシステムを仮想化するため、主にバックアップ用途に適していますが、今回のシンプルなデータアーカイブには過剰な選択肢。

結論

大量の画像データを効率的かつコスト効果高くアーカイブするには、AWS DataSyncを使い、S3 Glacier Deep Archiveにデータを直接転送する方法が最も適しています。

ストレージと転送コストを最適化するためには、S3 Glacier Deep Archiveが最適な選択肢です。

実践

略

一問道場

質問 #457

ある企業が、オンプレミスで画像データを解析し保存するアプリケーションを運用しています。このアプリケーションは毎日数百万件の新しい画像ファイルを受信します。

ファイルのサイズは平均1MBです。ファイルは1GBのバッチで解析され、バッチの解析が完了すると、画像は1つのファイルに圧縮され、長期保存のためにオンプレミスのNFSサーバーにアーカイブされます。

企業はオンプレミスにMicrosoft Hyper-V環境を持ち、コンピューティングリソースは利用可能です。ただし、ストレージ容量が不足しており、画像をAWSにアーカイブしたいと考えています。企業は、リクエストから1週間以内にアーカイブされたデータを取得できる必要があります。

企業は、オンプレミスのデータセンターとAWS間に10GbpsのAWS Direct Connect接続を持っています。企業は帯域幅制限を設定し、非営業時間中にアーカイブ画像をAWSにコピーするスケジュールを設定する必要があります。

どのソリューションが最もコスト効率よくこれらの要件を満たすでしょうか？

A. 新しいGPUベースのAmazon EC2インスタンスにAWS DataSyncエージェントをデプロイし、DataSyncエージェントを構成してNFSオンプレミスサーバーからAmazon S3 Glacier Instant Retrievalにファイルのバッチをコピーします。コピーが完了したら、オンプレミスのストレージからデータを削除します。

B. オンプレミスのHyper-V VMにAWS DataSyncエージェントをデプロイし、DataSyncエージェントを構成してNFSオンプレミスサーバーからAmazon S3 Glacier Deep Archiveにファイルのバッチをコピーします。コピーが完了したら、オンプレミスのストレージからデータを削除します。

C. 新しい一般的なAmazon EC2インスタンスにAWS DataSyncエージェントをデプロイし、DataSyncエージェントを構成してNFSオンプレミスサーバーからAmazon S3 Standardにファイルのバッチをコピーします。コピーが完了したら、オンプレミスのストレージからデータを削除します。その後、S3ライフサイクルルールを作成し、オブジェクトを1日後にS3 Glacier Deep Archiveに移行します。

D. AWS Storage Gateway Tape GatewayをオンプレミスのHyper-V環境にデプロイし、Tape GatewayをAWSに接続します。自動テープ作成を使用し、Amazon S3 Glacier Deep Archiveプールを指定します。バッチ画像がコピーされた後にテープを排出します。

解説

この問題では、企業がAWSに画像データをアーカイブし、非業務時間に帯域幅制限を設定してコピーを行う最もコスト効率の良い方法を求めています。各選択肢について詳しく見ていきましょう。

A. GPUベースのEC2インスタンスを使用

GPUベースのEC2インスタンスは、画像解析などの高負荷処理には向いていますが、今回はデータのコピーという比較的シンプルな操作です。GPUは不要であり、この選択肢はオーバースペックです。

Amazon S3 Glacier Instant Retrievalは、低レイテンシでデータにアクセスできるストレージですが、コストが高いため、長期保存には適していません。今回の要件には過剰なストレージクラスです。

B. Hyper-V VMにDataSyncエージェントをデプロイ

AWS DataSyncエージェントを使用して、データをS3 Glacier Deep Archiveにコピーするのは適切です。S3 Glacier Deep Archiveは最もコスト効率が良いアーカイブ用ストレージです。アーカイブデータの長期保存に適しており、頻繁にアクセスしないデータに最適です。

この方法は、データの移行におけるコストを最小化し、帯域幅制限を設定するのにも柔軟です。

C. EC2インスタンスでDataSyncエージェントを使用

S3 Standardを使うと、データの長期保存にはコストが高くなるため、これは長期アーカイブには適していません。

S3 Glacier Deep Archiveに移行するためのライフサイクルルールを作成することは可能ですが、最初にS3 Standardに保存するのは非効率的でコストがかさむ可能性があります。

D. AWS Storage Gateway Tape Gatewayを使用

Tape Gatewayはテープバックアップの仮想化サービスで、主にバックアップやアーカイブの用途に使用されますが、現在の要件には過剰であり、シンプルなデータコピーのシナリオでは不必要です。テープ作成や管理が追加され、管理が複雑になります。

結論

最もコスト効率が良い選択肢は、B. AWS DataSyncエージェントをHyper-V VMにデプロイして、S3 Glacier Deep Archiveにコピーする方法です。この選択肢は、低コストのアーカイブストレージであるS3 Glacier Deep Archiveを使用し、オンプレミスのストレージを削除することでコスト削減が可能です。

458-AWS SAP AWS 「理論・実践・一問道場」Amazon CloudWatch

理論

1. CloudWatch Logs メトリックフィルター

目的: CloudWatch Logsに保存されているログデータから、特定のパターンを抽出してメトリックを作成する。

利点: アプリケーションのコード変更を最小限に抑え、既存のログを活用して運用データをメトリック化できます。

使用シーン: ログインやエラーイベントなど、アプリケーションで発生した重要なアクションをメトリックとして監視する場合。

2. カスタムメトリックの作成

目的: アプリケーションやシステムの動作を詳細に追跡するために、ユーザー定義のメトリックを作成する。

方法: AWS SDKやAWS Lambdaを使用してメトリックをカスタムで記録する方法がありますが、アプリケーションコードの変更やLambda関数の設定が必要です。

3. AWS Lambda の使用

目的: 自動化された処理を行うために、ログのストリームを消費して処理を行い、結果をメトリックとして記録する。

利点: スケーラブルで自動化された処理を実現できますが、設定に手間がかかる場合があります。

4. CloudWatchのディメンション

目的: メトリックをさらに細かく分類するために、ディメンションを設定して特定の属性（ユーザー名、クライアント名など）を追跡します。

使用例: ログインの成功数をユーザーやクライアント別に分類して、パフォーマンス指標として使用する。

これらの知識を活用することで、CloudWatch Logsを効果的に利用し、アプリケーションのパフォーマンスやユーザーアクションを監視することができます。

実践

略

一問道場

企業は、ユーザー別ライセンススキーマへの移行戦略の一環として、アプリケーションからの主要業績評価指標（KPI）を記録したいと考えています。アプリケーションは、WebベースのUIを持つマルチティアアプリケーションです。企業は、CloudWatchエージェントを使用してすべてのログファイルをAmazon CloudWatchに保存しています。アプリケーションへのログインはすべてログファイルに保存されています。

新しいライセンススキーマの一環として、企業は毎日、毎週、毎月ごとのユニークなユーザー数を把握する必要があります。

どのソリューションがアプリケーションへの変更を最小限に抑えた状態でこの情報を提供できますか？

A. Amazon CloudWatch Logsのメトリックフィルターを設定し、各成功したログインをメトリックとして保存します。ユーザー名とクライアント名をメトリックのディメンションとして設定します。

B. アプリケーションロジックを変更して、各成功したログインがAWS SDKを呼び出し、ユーザー名とクライアント名のディメンションを含むカスタムメトリックをインクリメントするようにします。

C. CloudWatchエージェントを設定して、ログから成功したログインメトリックを抽出します。さらに、CloudWatchエージェントを設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックとして成功したログインメトリックを保存します。

D. AWS Lambda関数を設定して、アプリケーションログのAmazon CloudWatch Logsストリームを消費します。さらに、Lambda関数を設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックをCloudWatchでインクリメントします。

解説

この問題では、アプリケーションのログイン情報を元にユニークなユーザー数を計測し、それをAmazon CloudWatchでメトリックとして記録する方法を求めています。最小限のアプリケーション変更でこの要件を満たす方法を選ぶ必要があります。

各選択肢の解説：

A. Amazon CloudWatch Logsのメトリックフィルターを設定し、各成功したログインをメトリックとして保存します。ユーザー名とクライアント名をメトリックのディメンションとして設定します。

メリット: この方法はアプリケーションの変更を最小限に抑えつつ、CloudWatch Logsを活用してメトリックを抽出できます。ログインに関する情報はすでにCloudWatchに保存されているため、ログの内容に基づいてメトリックフィルターを設定することで、ユーザーごとの成功ログイン回数を簡単に計測できます。

最適な選択肢: 変更はログに基づいたメトリック設定のみで、アプリケーションコードに対する変更はほとんど必要ありません。

B. アプリケーションロジックを変更して、各成功したログインがAWS SDKを呼び出し、ユーザー名とクライアント名のディメンションを含むカスタムメトリックをインクリメントするようにします。

デメリット: アプリケーションのロジックを変更してAWS SDKを呼び出す必要があり、これは大きな変更になります。特に既存のアプリケーションに対して、メトリックのインクリメントを直接アプリケーションコードに組み込むのは手間がかかり、エラーの可能性も増えます。

C. CloudWatchエージェントを設定して、ログから成功したログインメトリックを抽出します。さらに、CloudWatchエージェントを設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックとして成功したログインメトリックを保存します。

デメリット: CloudWatchエージェントを設定してメトリックを抽出するのは可能ですが、エージェントで直接ログからメトリックを抽出してカスタムメトリックを生成するのは少し複雑です。さらに、CloudWatchエージェントを設定するには多少の手間がかかります。

D. AWS Lambda関数を設定して、アプリケーションログのAmazon CloudWatch Logsストリームを消費します。さらに、Lambda関数を設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックをCloudWatchでインクリメントします。

デメリット: Lambda関数を設定することで処理を自動化できますが、これも設定や維持に一定のコストと手間がかかります。Lambda関数を利用する場合、ストリームからデータを処理してメトリックをインクリメントするため、特にスケーラビリティが求められる場合に適していますが、最小限の変更で対応する目的には少し過剰かもしれません。

結論：

最も効率的でアプリケーションの変更を最小限に抑えられる方法は A です。CloudWatch Logsのメトリックフィルターを使って、ログイン成功の情報を基にメトリックを生成することで、既存のログデータを有効活用し、最小限の設定変更で目的を達成できます。

459-AWS SAP AWS 「理論・実践・一問道場」GitHub Action（OIDC）

理論

1. AWS STS (Security Token Service)

STSは、短期間有効な認証情報を生成するサービスで、IAMユーザーやサービスがAWSリソースにアクセスするための一時的なセキュリティトークンを発行します。

sts:AssumeRoleを使ってIAMロールを引き受け、短期的な認証情報を得ることができます。

2. OIDC (OpenID Connect)

OIDCは、WebアプリケーションやCI/CDパイプラインにおいて、ユーザー認証のための標準的なプロトコルです。GitHubなどの外部サービスがAWSと連携する際に利用されます。

GitHub Actionsでは、OIDCを使って、IAMロールへのアクセスを一時的な認証情報を通じて安全に取得できます。

3. GitHub Actions と AWS の連携

GitHub Actionsは、CI/CDパイプラインを自動化するためのツールで、AWSリソースを操作するためには、認証情報が必要です。長期的なアクセスキーを使う方法はセキュリティ上のリスクがあるため、短期的なSTSトークンを使う方法が推奨されます。

4. セキュリティのベストプラクティス

長期的な秘密鍵やアクセスキーの使用を避け、一時的なSTSトークンを使用することで、セキュリティリスクを最小限に抑えます。

OIDCやSAMLなどの外部認証プロバイダーを使うことで、AWSのアクセスをよりセキュアに管理できます。

これらの知識を理解することで、GitHub ActionsのようなCI/CDパイプラインをAWSに統合し、セキュリティと運用の負担を軽減することが可能です。

実践

略

一問道場

問題 #459

ある企業は、GitHub Actionsを使用してCI/CDパイプラインを実行し、AWSリソースにアクセスしています。パイプラインは、AWSに認証するためにシークレットキーを使用するIAMユーザーを持っています。既存のIAMロールには、リソースをデプロイするために必要な権限を持つポリシーがアタッチされています。企業のセキュリティチームは、新しいポリシーにより、パイプラインでは長期間使用されるシークレットキーが使えなくなったという要件を導入しました。ソリューションアーキテクトは、シークレットキーを短期間で利用可能な別の方法に置き換える必要があります。

この要件を最も運用負担を軽減して満たす解決策はどれでしょうか？

A. AWS Identity and Access Management (IAM)でSAML 2.0アイデンティティプロバイダー(IdP)を作成し、適切な信頼ポリシーを設定した新しいIAMロールを作成します。そのロールに、sts:AssumeRole API呼び出しを許可し、既存のIAMポリシーをアタッチします。GitHubでSAML認証を使用するようにパイプラインを更新します。

B. AWS Identity and Access Management (IAM)でOpenID Connect (OIDC)アイデンティティプロバイダー(IdP)を作成し、GitHub OIDC IdPからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する信頼ポリシーを設定した新しいIAMロールを作成します。GitHubを更新して、そのロールをパイプラインで引き受けるようにします。

C. Amazon Cognitoアイデンティティプールを作成し、GitHubを認証プロバイダーとして設定します。その後、GitHub認証プロバイダーからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する信頼ポリシーを設定した新しいIAMロールを作成します。パイプラインをCognitoを使用するように設定します。

D. AWS Private Certificate Authorityで信頼アンカーを作成し、AWS IAM Roles Anywhereで使用するクライアント証明書を生成します。信頼ポリシーを設定した新しいIAMロールを作成し、sts:AssumeRole API呼び出しを許可します。パイプラインで資格情報ヘルパーツールを使用し、クライアント証明書の公開鍵を参照してIAMロールを引き受けるように設定します。

解説

この問題は、CI/CDパイプラインでAWSリソースにアクセスする際に使用されている長期的なIAMユーザーのシークレットキーを、短期間で利用可能な解決策に置き換える方法に関するものです。セキュリティチームの新しい方針に従い、長期間使われるシークレットキーの代わりに、短期的な認証情報を使いたいという要件があります。

各選択肢の解説

A. SAML 2.0 アイデンティティプロバイダーを使用する方法

SAMLは、組織内の認証情報をAWSに渡すための標準的なプロトコルです。これを利用するためには、GitHub ActionsがSAML認証をサポートしていなければならず、これを設定するには多少のカスタマイズが必要です。SAML 2.0は通常、企業内シングルサインオン(SSO)に使用されるため、GitHub Actionsのような外部サービスと組み合わせるのは少し手間がかかります。

B. OpenID Connect (OIDC) アイデンティティプロバイダーを使用する方法

OIDCは、GitHub ActionsとAWSを安全に接続するための非常に適した方法です。GitHub Actionsは、OIDCをサポートしており、AWS側でOIDCを使った一時的な認証を行うことができます。この方法は、最もシンプルかつ運用負担が少ない方法です。GitHub ActionsからのAPI呼び出しを許可するため、IAMロールで sts:AssumeRoleWithWebIdentity ポリシーを使う設定を行います。

C. Amazon Cognito を使う方法

Cognitoは、ユーザー認証を簡単に行えるサービスですが、GitHub ActionsのパイプラインでCognitoを認証プロバイダーとして使う方法は、セットアップが複雑になる可能性があり、直接的な利点が少ない場合もあります。OIDCを使った方法に比べると運用負担が大きくなるかもしれません。

D. AWS IAM Roles Anywhere を使用する方法

IAM Roles Anywhereは、証明書ベースの認証を使って、オンプレミスや外部システムからAWSリソースへのアクセスを管理するものです。この方法は、GitHub Actionsでの利用には過剰な設定が必要で、運用負担が大きくなる可能性があります。特に、証明書の管理や資格情報ヘルパーツールの使用など、追加の手間がかかります。

最適な解決策

最もシンプルで運用負担が少なく、GitHub ActionsとAWS間で短期的な認証を行うために最適な方法は、B. OIDCを使用する方法です。これにより、GitHub Actionsは直接AWSのIAMロールを引き受け、一時的な認証情報を得ることができます。これにより、シークレットキーを使用する必要がなく、セキュリティ要件も満たすことができます。

460-AWS SAP AWS 「理論・実践・一問道場」クローリング

理論

「クローリング」とは、インターネット上のウェブサイトやページを自動的に巡回して情報を収集するプロセスのことです。特に、検索エンジンのボットがウェブページをスキャンして、内容をインデックスに登録する際に行う作業が「ウェブクロール」と呼ばれます。

このプロセスでは、指定されたURLのリストを基に、ページを訪れてデータを取得し、必要な情報（例えば、テキストや画像）をダウンロードしたり、解析したりします。クローリングは、例えば検索エンジンがページの内容を理解し、結果をランキングに反映させるために必要不可欠です。

1. AWS Lambdaを利用したサーバーレスアーキテクチャ

AWS Lambdaは、サーバーを管理せずにコードを実行できるサーバーレスサービスです。

Lambdaは、トリガーに応じて自動的にスケールし、リクエストがないときは実行されません。この特性により、リソースの無駄を避けることができ、コストを最小化できます。

Lambdaの利用には、リクエストに基づいた課金がされるため、アイドル状態のコストが発生しません。

2. Amazon S3を用いた低コストなストレージ

Amazon S3は、非常にスケーラブルで耐久性が高いオブジェクトストレージサービスです。データを長期間保存する場合に最適で、クローリングデータのような大量のファイルを効率的に保存できます。

S3は、保存するデータ量に基づいてコストが発生するため、処理後の結果を保存するのに非常にコスト効率が良いです。

3. Amazon EC2インスタンスのコスト最適化

EC2インスタンスを使用する場合、インスタンスが常に稼働し続けるため、アイドル状態の時間が長いとコストが無駄になります。

必要に応じてスケールするサービス（LambdaやFargateなど）の導入により、コストを最適化することができます。

4. 非同期処理とバッチ処理

SQS（Simple Queue Service）を使用することで、非同期処理を実現し、リクエストがあるときにのみリソースを利用できます。LambdaやEC2インスタンスの利用を非同期にすることで、効率的にリソースを使用できます。

これらの知識を活用することで、ウェブクローリングのようなリソースを動的に管理するタスクのコストを最適化し、スケーラブルなシステムを構築できます。

実践

略

一問道場

ある企業が、機械学習アルゴリズムの訓練データを取得するために、ターゲットURLのリストに基づいてウェブクローリングプロセスを実行しています。複数のAmazon EC2 t2.microインスタンスが、Amazon Simple Queue Service (Amazon SQS)キューからターゲットURLを取得し、クローリングアルゴリズムの結果を.csvファイルとしてAmazon Elastic File System (Amazon EFS)ボリュームに書き込みます。EFSボリュームは、インスタンスのすべてのフリートでマウントされています。別のシステムが、URLをSQSキューに追加していますが、その頻度は低いです。インスタンスは、各URLを10秒以内にクローリングします。メトリクスによると、URLがSQSキューにないときに、一部のインスタンスがアイドル状態になっています。ソリューションアーキテクトは、コストを最適化するためにアーキテクチャを再設計する必要があります。

次の手順のうち、コストを最も効果的に最適化するために実施すべきものはどれですか？（2つ選んでください。）

A. ウェブクローリングプロセスにm5.8xlargeインスタンスを使用し、インスタンスの数を50%削減します。

B. ウェブクローリングプロセスをAWS Lambda関数に変換し、Lambda関数でSQSキューからURLを取得するように設定します。

C. ウェブクローリングプロセスで結果をAmazon Neptuneに保存するように変更します。

D. ウェブクローリングプロセスで結果をAmazon Aurora Serverless MySQLインスタンスに保存するように変更します。

E. ウェブクローリングプロセスで結果をAmazon S3に保存するように変更します。