type
status
date
slug
summary
tags
category
icon
password
371-AWS SAP AWS 「理論・実践・一問道場」OIDC プロバイダー
理論
1. AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)
- AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）は、AWS クラウドで Active Directory（AD）をホストできるサービスです。これにより、既存の Active Directory 環境をクラウドに移行し、Microsoft AD のドメインと同じように管理できます。
- 企業が既存の Active Directory をクラウドで使用している場合、ユーザー認証やアクセス管理をクラウド内で行えるため、オンプレミスの Active Directory 環境と統合して一貫した管理が可能です。
2. Application Load Balancer (ALB) の認証機能
- ALB は、HTTP および HTTPS ベースのアプリケーションのトラフィックを管理するロードバランサーです。ALB は、特に Web アプリケーションのトラフィックを処理し、リクエストのルーティングを効率的に行います。
- ALB には、認証機能が組み込まれており、OIDC (OpenID Connect) や Cognito などを使ってユーザー認証を行うことができます。これにより、ALB がアプリケーションの前段階でユーザー認証を担当し、セキュリティを強化できます。
3. OIDC（OpenID Connect）認証
- OIDC は、OAuth 2.0 の拡張で、ID プロバイダーと Web アプリケーション間でユーザー認証を行うためのプロトコルです。OIDC は、アプリケーションがユーザーの身元を確認するための標準的な方法を提供します。
- ALB では、OIDC プロバイダーを設定することができ、これにより Active Directory やその他の ID プロバイダーを使ってアプリケーションのユーザーを認証できます。
4. Cognito と AWS Directory Service の違い
- Amazon Cognito は、ユーザー管理や認証、認可をクラウドベースで提供するサービスです。Cognito は主にウェブアプリケーションやモバイルアプリケーション向けのユーザー認証に使われますが、AWS Directory Service はオンプレミスの Active Directory 環境のクラウド版であり、既存の企業ディレクトリとの統合に強みがあります。
- Cognito と AWS Directory Service は異なるユースケースに対応しており、ALB で使用する場合、それぞれに適した認証アクションを選択する必要があります。
5. IAM ロールと SAML 2.0
- IAM ロール は、AWS のリソースにアクセスするためのアクセス許可を定義するために使われます。SAML 2.0 は、シングルサインオン (SSO) のための標準的な認証フレームワークです。SAML は、特に外部 IdP（例：Active Directory）との連携をサポートし、AWS IAM で設定したロールを通じてアクセス管理を行います。
- ALB の認証機能では、OIDC や Cognito など、他の認証フレームワークと組み合わせて使用することが一般的ですが、IAM と SAML 2.0 の組み合わせは、AWS のリソースへのアクセスを管理するための別の手法です。
6. ALB の認証アクション
- ALB のリスナーで設定する認証アクションには、
authenticate-cognitoとauthenticate-oidcの2つがあります。authenticate-cognitoは Amazon Cognito と連携するために使用し、authenticate-oidcは OpenID Connect を利用した認証を行うために使用します。問題のシナリオでは、AWS Directory Service for Microsoft Active Directory を OIDC プロバイダーとして利用し、ALB のリスナールールにauthenticate-oidcを使用することが求められています。
まとめ：
- AWS Directory Service for Microsoft Active Directory を使用し、ALB の
authenticate-oidcアクションで認証を行うことで、Active Directory アカウントを持つすべてのユーザーがシームレスにアプリケーションにアクセスできるようになります。
- Cognito や IAM との統合は、AWS Directory Service の利用には適していません。
実践
略
一問道場
問題 #371
ある企業が、Amazon EC2 インスタンスでホストされているイントラネット Web アプリケーションを、アプリケーションロードバランサー (ALB) の背後に配置しています。現在、ユーザーは内部のユーザーデータベースを使用してアプリケーションに認証しています。
この企業は、既存の AWS Directory Service for Microsoft Active Directory ディレクトリを使用して、ユーザーをアプリケーションに認証させる必要があります。ディレクトリにアカウントを持つすべてのユーザーがアプリケーションにアクセスできるようにしなければなりません。
どのソリューションがこの要件を満たしますか？
A. ディレクトリに新しいアプリクライアントを作成します。ALB のリスナールールを作成し、リスナールールに authenticate-oidc アクションを指定します。リスナールールを適切な発行者、クライアント ID とシークレット、エンドポイントの詳細で構成します。新しいアプリクライアントを ALB が提供するコールバック URL で構成します。
B. Amazon Cognito ユーザープールを構成します。ユーザープールをディレクトリからのメタデータを持つフェデレート型アイデンティティプロバイダー (IdP) で構成します。アプリクライアントを作成します。アプリクライアントをユーザープールと関連付けます。ALB のリスナールールを作成し、authenticate-cognito アクションを指定します。リスナールールをユーザープールとアプリクライアントで構成します。
C. ディレクトリを新しい IAM アイデンティティプロバイダー (IdP) として追加します。SAML 2.0 フェデレーションのエンティティタイプを持つ新しい IAM ロールを作成します。ALB へのアクセスを許可するロールポリシーを構成します。新しいロールを IdP のデフォルト認証済みユーザーロールとして構成します。ALB のリスナールールを作成し、authenticate-oidc アクションを指定します。
D. AWS IAM Identity Center (AWS Single Sign-On) を有効にします。ディレクトリを SAML を使用した外部アイデンティティプロバイダー (IdP) として構成します。自動プロビジョニング方法を使用します。SAML 2.0 フェデレーションのエンティティタイプを持つ新しい IAM ロールを作成します。ALB へのアクセスを許可するロールポリシーを構成します。新しいロールをすべてのグループに添付します。ALB のリスナールールを作成し、authenticate-cognito アクションを指定します。
解説
この問題の解説は以下の通りです。
問題の要点
- 会社は現在、内部ユーザーデータベースを使用してアプリケーションへの認証を行っています。
- 会社は、AWS Directory Service for Microsoft Active Directory を使用してユーザー認証を行いたいと考えています。
- 要求として、すべてのユーザーがアプリケーションにアクセスできるようにし、既存のディレクトリを利用して認証を行うことです。
解答の考察
選択肢 A は正解です。
authenticate-oidcアクションを ALB のリスナーで使用し、AWS Directory Service for Microsoft Active Directory を OpenID Connect (OIDC) プロバイダーとして設定します。
- ALB では、OIDC プロバイダーを使って認証を行い、ユーザーが Active Directory のアカウントで認証されるようにします。
- これにより、ユーザーは既存のディレクトリアカウントを利用してアプリケーションにアクセスできます。
- OIDC は、AWS Directory Service for Microsoft Active Directory と直接統合できるため、最適な方法です。
- App client の設定で、ALB のコールバック URL を指定し、ALB からのリダイレクトを処理します。
選択肢 B は不正解です。
- Amazon Cognito は AWS の独立したユーザー管理サービスであり、AWS Directory Service for Microsoft Active Directory と統合することはできません。
- 質問では既存のディレクトリを使用するよう求められており、Cognito に移行する必要はありません。
選択肢 C は不正解です。
- IAM は SAML 2.0 の連携をサポートしますが、AWS Directory Service for Microsoft Active Directory と直接統合するための方法としては適していません。
- SAML 2.0 と IAM は、特にウェブアイデンティティ連携を利用する場合に使用されるものであり、Active Directory との統合には OIDC の方が適しています。
選択肢 D は不正解です。
- AWS IAM Identity Center (AWS SSO) は、シングルサインオン (SSO) を管理するサービスであり、通常複数の AWS アカウントに対するアクセスを管理するために使います。
- しかし、質問のシナリオでは、単一の社内アプリケーションのアクセス制御について話しており、AWS IAM Identity Center は必要ありません。
- また、
authenticate-cognitoアクションは、Cognito ユーザープールと連携するために使用され、外部 IdP（この場合は AWS Directory Service）とは互換性がありません。
結論
最も適切な解決策は 選択肢 A です。AWS Directory Service for Microsoft Active Directory を OIDC プロバイダーとして設定し、ALB のリスナーで
authenticate-oidc アクションを使用することによって、既存のディレクトリアカウントでの認証をシームレスに実現できます。他の選択肢は必要以上の手順や不適切なサービスの使用を含んでいるため、適していません。372-AWS SAP AWS 「理論・実践・一問道場」53→cloudfront→Health check
理論
1. Amazon Route 53とフェイルオーバー
Amazon Route 53は、クラウドベースのDNSサービスです。特に、フェイルオーバールーティングポリシーは、プライマリリージョンで障害が発生した場合にバックアップのDR（ディザスタリカバリ）リージョンにトラフィックを自動的にルーティングするために使用されます。
- ヘルスチェックを使って、バックエンドサービスの健康状態を監視し、正常でない場合にトラフィックをバックアップリージョンに送ることができます。
- TTL（Time to Live）: DNSキャッシュの有効期限を短く設定することで、フェイルオーバーが早く反映されますが、過度に短いTTLはDNSサーバーへの負荷が増加するため、適切な設定が必要です。
2. Amazon CloudFrontとオリジングループ
CloudFrontは、グローバルにコンテンツをキャッシュし、ユーザーに近い場所から提供するCDN（コンテンツデリバリーネットワーク）です。CloudFrontは、オリジン（バックエンドサーバ）からコンテンツを配信します。
- オリジングループを使用すると、CloudFrontは複数のオリジンを設定し、障害発生時に自動で別のオリジンに切り替えることができます。これにより、バックエンドの障害が発生しても、ユーザーへのサービスが途切れることなく提供されます。
- キャッシュビヘイビアは、CloudFrontがオリジンからコンテンツを取得する方法やキャッシュの設定を制御します。オリジンフェイルオーバーを設定することで、1つのオリジンが失敗した際に別のオリジンからコンテンツを取得することができます。
3. フェイルオーバーを最速で実現するための最適化
フェイルオーバーのスピードを向上させるためには、以下の点が重要です。
- CloudFrontオリジングループの利用: 複数のバックエンドサービスをオリジングループとして設定し、キャッシュビヘイビアでオリジンフェイルオーバーを活用することで、フェイルオーバー時間を最小化できます。
- Route 53 TTLの短縮: TTLの設定を短くすることで、DNSが迅速に新しいエンドポイントを反映し、ダウンタイムを減らせます。ただし、TTLを短くしすぎると、DNSのクエリ数が増加する可能性があるので、適切なバランスが必要です。
4. レイテンシールーティングとオリジンの選択
- レイテンシールーティングポリシーを使うことで、最も近いリージョンのバックエンドにトラフィックをルーティングすることができます。これにより、パフォーマンスが向上しますが、フェイルオーバーの速度には影響を与えません。
まとめ
この問題に関連する知識として、CloudFrontのオリジングループやRoute 53のフェイルオーバーポリシーを利用することで、高速なフェイルオーバーを実現できます。具体的には、オリジンフェイルオーバーやキャッシュビヘイビアの設定を活用することが、最適な結果をもたらします。
実践
一問道場
問題 #372
ある会社が多くの訪問者を持つウェブサイトを運営しています。この会社は、ウェブサイトのバックエンドサービスを主要な AWS リージョンと災害復旧（DR）リージョンにデプロイしています。
会社はウェブサイト用に単一の Amazon CloudFront ディストリビューションを使用しています。会社は、主要リージョンのバックエンドサービスに対してヘルスチェックを行い、フェイルオーバールーティングポリシーを使って Amazon Route 53 のレコードセットを作成します。
そのレコードセットは CloudFront のオリジンとして設定されています。会社は、DR リージョンのバックエンドサービスのエンドポイントを指す別のレコードセットを作成し、これをセカンダリのフェイルオーバーレコードとして設定します。
両方のレコードセットの TTL（キャッシュの生存時間）は 60 秒に設定されています。
現在、フェイルオーバーに 1 分以上かかっています。ソリューションアーキテクトは、最速のフェイルオーバーを実現するための解決策を設計する必要があります。
どのソリューションが最適でしょうか？
A. 追加の CloudFront ディストリビューションをデプロイし、新しい Route 53 フェイルオーバーレコードセットを作成して、両方の CloudFront ディストリビューションにヘルスチェックを設定する。
B. 既存の Route 53 レコードセットの TTL を 4 秒に設定し、各リージョンのバックエンドサービスに適用する。
C. バックエンドサービス用に新しいレコードセットを作成し、遅延ルーティングポリシーを使用して、CloudFront ディストリビューションのオリジンとして設定する。
D. CloudFront オリジングループを作成し、2 つのオリジン（各バックエンドサービスリージョン用）を含め、CloudFront ディストリビューションのキャッシュビヘイビアとしてオリジンフェイルオーバーを設定する。
解説
詳細な解説：
このシナリオでは、CloudFrontディストリビューションとRoute 53を使用して、フェイルオーバーを最適化する必要があります。最速のフェイルオーバーを実現するためには、CloudFrontのオリジングループを使用して、複数のバックエンドサービス間で自動的にフェイルオーバーする設定が重要です。
選択肢の解説：
- A: 新たにCloudFrontディストリビューションを作成して、Route 53のフェイルオーバーレコードセットを作成する方法です。これにより、冗長性は増しますが、既存のインフラに対する影響を大きくし、設定が複雑になります。既にCloudFrontが導入されているため、この方法は最適ではありません。
- B: Route 53のTTLを4秒に設定する方法です。TTLを短くすることでDNSの反映速度は速くなりますが、これだけではCloudFrontディストリビューションがバックエンドをどのように選択するかに関する改善はありません。TTLを短くすることでの影響は限られた範囲にとどまります。
- C: レイテンシールーティングポリシーを使用する方法です。この方法は、最適なバックエンドサービスを選択するのに役立ちますが、フェイルオーバーの速度には直接関与しません。フェイルオーバーが目的であるならば、CloudFront内でのオリジン選択の方が優れています。
- D: CloudFrontオリジングループを作成し、2つのバックエンドサービス（主要リージョンとDRリージョン）をオリジンとして設定して、CloudFrontのキャッシュビヘイビアとしてオリジンフェイルオーバーを使用する方法です。この方法が最速のフェイルオーバーを実現します。CloudFrontは自動的に障害が発生したオリジンから別のオリジンにリクエストを切り替えるため、フェイルオーバーが即時に行われます。
まとめ：
- Dが正解です。CloudFrontオリジングループとオリジンフェイルオーバーを利用することで、最速のフェイルオーバーを実現できます。この方法は、特にバックエンドサービスが複数のリージョンに分散している場合に有効です。
BやCも有効な手法ですが、フェイルオーバーのスピードを最速にするためには、Dの方法が最適です。
373-AWS SAP AWS 「理論・実践・一問道場」否定リスト戦略
理論
1. AWS OrganizationsとSCP（サービスコントロールポリシー）
- AWS Organizationsは複数のAWSアカウントを一元的に管理するサービスで、アカウントを組織単位（OU）で整理し、ポリシーを適用できます。
- *サービスコントロールポリシー（SCP）**は、AWS Organizations内でアクセス権限を制御するためのポリシーで、アカウントごとの許可や拒否を管理します。これにより、組織全体や特定のOUに対して特定のサービスや操作を制限できます。
- 例えば、「全てのサービスに対するアクセスを許可し、一部のサービスは拒否」といったポリシー設定が可能です。
2. IAM（Identity and Access Management）とアクセスアドバイザー
- *IAM（Identity and Access Management）**は、AWSリソースへのアクセスを管理するサービスです。IAMユーザー、グループ、ロール、ポリシーを使用して、リソースへのアクセス権限を制御できます。
- IAM アクセスアドバイザーは、IAMポリシーを基にユーザーやロールが使用したサービスを分析し、実際にアクセスされたリソースを確認するツールです。これを使って、不要なサービスへのアクセスを制限するためのポリシーを見直すことができます。
3. 組織単位（OU）
- *組織単位（OU）**は、AWS Organizations内でアカウントをグループ化するための方法です。OUごとに異なるポリシーを適用することができ、例えば本番環境と開発環境で異なる制限を設定することが可能です。
- 各OUに適用するSCPによって、サービスへのアクセスやリソースの管理に柔軟に対応できます。
4. アクセス制御戦略（許可リスト vs 否定リスト）
- 許可リスト（ホワイトリスト）戦略では、特定のサービスへのアクセスのみを許可し、それ以外はデフォルトで制限します。これにより、利用しないサービスに対して不必要なアクセスを防ぐことができます。
- 否定リスト（ブラックリスト）戦略では、アクセスを明示的に拒否したいサービスを定義し、それ以外は基本的に許可します。特定のサービスのみを制限するのに効果的です。
5. Trusted Advisor vs Access Advisor
- AWS Trusted Advisorは、AWSアカウントの設定やリソースに対する最適化、コスト削減、セキュリティのベストプラクティスを提案しますが、特定のサービスが「使用されているかどうか」を直接追跡するツールではありません。
- IAMアクセスアドバイザーは、ユーザーやロールが実際にどのAWSサービスを使用したかを追跡するため、アクセス制限をかける上で有用な情報源です。
結論
- AWS OrganizationsとSCPを利用して、複数のAWSアカウント間でアクセス制御を中央で管理することができます。IAMと組み合わせることで、さらに精緻なアクセス管理が可能です。
- アクセスアドバイザーを使って、実際に使用されているサービスを把握し、不要なサービスへのアクセスを制限するポリシー設定を行うことができます。
実践
略
一問道場
問題 #373
ある会社は複数の AWS アカウントを使用しており、複数の DevOps チームがこれらのアカウントで本番環境および非本番環境のワークロードを実行しています。
その会社は、DevOps チームが使用していないいくつかの AWS サービスへのアクセスを中央で制限したいと考えています。会社は AWS Organizations を使用し、すべての AWS アカウントを正常に組織に招待しました。現在使用中のサービスへのアクセスを許可し、いくつかの特定のサービスを拒否したいと考えています。また、複数のアカウントを単一のユニットとして管理したいと考えています。
ソリューションアーキテクトは、この要件を満たすためにどの組み合わせの手順を取るべきでしょうか？（3つ選択してください。）
A. 否定リスト戦略を使用する。
B. AWS IAM のアクセスアドバイザーを確認して、最近使用されたサービスを確認する。
C. AWS Trusted Advisor レポートを確認して、最近使用されたサービスを確認する。
D. デフォルトの FullAWSAccess SCP を削除する。
E. 組織単位（OU）を定義し、メンバーアカウントを OU に配置する。
F. デフォルトの DenyAWSAccess SCP を削除する。
解説
正解:
A. 否定リスト戦略を使用する。
- 否定リスト戦略では、許可したいサービスを「許可リスト」として設定せず、アクセスを明示的に拒否することで、DevOps チームが使わないサービスへのアクセスを制限します。この方法は、必要なサービスだけにアクセスを許可し、その他のサービスを制限するために有効です。
B. AWS IAM のアクセスアドバイザーを確認して、最近使用されたサービスを確認する。
- IAM アクセスアドバイザーを使用すると、各ユーザーやロールが最近使用した AWS サービスを確認できます。この情報を基に、使用されていないサービスを特定し、それらのサービスに対するアクセスを制限するための戦略を立てることができます。
E. 組織単位（OU）を定義し、メンバーアカウントを OU に配置する。
- AWS Organizations では、組織単位（OU）を使ってアカウントをグループ化できます。これにより、異なるアクセス制限ポリシーを組織単位ごとに設定することが可能です。例えば、本番環境と非本番環境を別々の OU に分け、それぞれに適切なポリシーを適用することができます。
解説:
- A: 否定リスト戦略を使用することで、使用しないサービスへのアクセスを制限し、必要なサービスのみを許可できます。
- B: IAM アクセスアドバイザーを利用して、現在使用されているサービスを確認し、不要なサービスを制限できます。
- E: 組織単位（OU）を使って、異なるポリシーを適用できるようにすることで、より細かい管理が可能になります。
不正解:
C. AWS Trusted Advisor レポートを確認して、最近使用されたサービスを確認する。
- Trusted Advisor は主にリソースの最適化やコスト削減を目的としたアドバイスを提供しますが、サービスの使用履歴に基づくアクセス制限のためには適していません。
D. デフォルトの FullAWSAccess SCP を削除する。
- デフォルトで適用されている
FullAWSAccessポリシーを削除するのは有効ですが、アクセス制限のためには、具体的にサービスを制限する SCP（サービスコントロールポリシー）を作成する必要があります。
F. デフォルトの DenyAWSAccess SCP を削除する。
DenyAWSAccessというポリシーは存在しません。正しいポリシー名や設定が必要です。
まとめ
最適な選択肢は「A」「B」「E」です。これらのステップを踏むことで、適切にアクセス制限を行い、DevOps チームが使用しないサービスを中央で制御できます。
374-AWS SAP AWS 「理論・実践・一問道場」高トラフィックイベント
理論
高トラフィックイベントにおけるAWSスケーリング戦略のポイント
高トラフィックが予想されるイベント（例: チケット販売）では、システムの可用性とスケーリングが重要です。以下は、関連する汎用的な知識をまとめたポイントです。
1. スケーリング戦略の選択
- スケジュールスケーリング:
- イベント日時が事前に分かっている場合に有効。
- 定時にリソースを増加させ、イベント後に縮小する。
- 使用例: Auto ScalingグループでのEC2インスタンスのスケールアウト。
- 予測スケーリング:
- 過去のデータをもとに需要を予測してスケールアウト。
- 不確定要素が多い場合に適用。ただし、販売イベントなど急激なトラフィック増加には不向き。
2. Amazon Auroraの選択理由
- スケーリングの柔軟性:
- Auroraはリードレプリカの作成が高速で、必要に応じてリソースを迅速に拡張可能。
- Multi-AZ構成により、高可用性を実現。
- コスト効率:
- AuroraはRDSよりもコスト効率が良い場合が多い。
- イベント後にリードレプリカを縮小することで運用コストを削減。
3. リードレプリカの活用
- リードレプリカは、読み取りトラフィックを分散させるために使用。
- 大規模イベントでは、事前に大きなリードレプリカを作成し、必要に応じてフェイルオーバー。
- イベント終了後はリードレプリカを縮小してコスト最適化。
4. イベントトリガーの自動化
- Amazon EventBridge:
- イベントスケジュールに基づいてAWSサービスをトリガー。
- Lambdaを利用して、スケーリングやフェイルオーバーの自動化を実現。
- AWS Step Functions:
- 複雑なワークフローを自動化し、複数のLambda関数を並列実行可能。
5. その他の考慮事項
- キャッシュ:
- Amazon CloudFrontやElastiCacheを利用して、データベースへの負荷を軽減。
- ヘルスチェック:
- ELBやRoute 53のヘルスチェックを使用して、異常検知とリソース切り替えを確実に行う。
まとめ
高トラフィックイベントには、スケジュールスケーリングとAurora Multi-AZ構成を組み合わせるのが効果的です。さらに、EventBridgeとLambdaを利用して、リソースの拡張・縮小を自動化することで、可用性とコスト効率を両立できます。
実践
略
一問道場
Question #374
あるライブイベント会社が、AWS上で運用するチケットアプリケーションのスケーリングソリューションを設計しています。このアプリケーションは、販売イベント中に利用率が非常に高くなります。各販売イベントは一度きりのイベントで、事前にスケジュールされています。このアプリケーションは、Auto Scalingグループ内のAmazon EC2インスタンスで実行されており、データベース層にはPostgreSQLを使用しています。
会社は、販売イベント中の最大限の可用性を確保するためのスケーリングソリューションを必要としています。
この要件を満たすソリューションはどれですか？
A. EC2インスタンスに予測スケーリングポリシーを使用する。データベースをAmazon Aurora PostgreSQL Serverless v2 Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前にデータベースを事前ウォームアップするために、並列AWS Lambda関数を実行するAWS Step Functionsステートマシンを作成する。Amazon EventBridgeルールを作成して、ステートマシンを呼び出す。
B. EC2インスタンスにスケジュールスケーリングポリシーを使用する。データベースをAmazon RDS for PostgreSQL Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前に、より大きなリードレプリカを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。そのリードレプリカにフェイルオーバーする。販売イベント後にリードレプリカをスケールダウンする別のEventBridgeルールを作成する。
C. EC2インスタンスに予測スケーリングポリシーを使用する。データベースをAmazon RDS for PostgreSQL Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前にデータベースを事前ウォームアップするために、並列AWS Lambda関数を実行するAWS Step Functionsステートマシンを作成する。Amazon EventBridgeルールを作成して、ステートマシンを呼び出す。
D. EC2インスタンスにスケジュールスケーリングポリシーを使用する。データベースをAmazon Aurora PostgreSQL Multi-AZ DBクラスターでホストする。販売イベント前に、より大きなAurora Replicaを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。そのAurora Replicaにフェイルオーバーする。販売イベント後にAurora Replicaをスケールダウンする別のEventBridgeルールを作成する。
解説
Dの内容
- EC2: スケジュールスケーリングで事前にスケールアウトを計画。
- データベース: Aurora PostgreSQL Multi-AZ DBクラスタを使用。
- EventBridge: Lambdaを活用して事前に大きなリードレプリカを作成し、販売イベント中にフェイルオーバー。イベント終了後にリードレプリカを縮小。
Dが正解となる理由
- スケジュールスケーリングの有効性
- 販売イベントは日時が事前に分かっているため、予測スケーリングよりもスケジュールスケーリングが適切。
- これにより、イベント開始前に必要なリソースを確保できる。
- Aurora PostgreSQLの強み
- AuroraはRDSよりもスケーリングが柔軟で、高可用性や自動バックアップなどの利点がある。
- Multi-AZ構成により、フェイルオーバー時にも高い可用性が確保される。
- 事前リードレプリカ作成とフェイルオーバー
- EventBridgeとLambdaを使用することで、リードレプリカの作成を自動化。
- フェイルオーバーによって、より大きなリードレプリカを主要インスタンスとして利用可能。
- イベント後にリードレプリカを縮小することでコスト最適化も実現。
- 予測スケーリングより確実
- 販売イベントはトラフィックのピークが急激であるため、事前スケールアウトが必要。
- 予測スケーリングは履歴データに依存するため、イベント特有の急激な増加に対応しきれない可能性がある。
他の選択肢と比較
- A: Aurora Serverless v2は非常に柔軟だが、予測スケーリングの適用がイベントには向かない。
- B: RDSはAuroraに比べてスケールアウトが遅く、販売イベントのような即応性が求められる場面には適さない。
- C: Aと同様に予測スケーリングがボトルネックとなる可能性がある。
結論
- Dが正解である理由:
- 販売イベントの特性（日時が事前に決まっている、トラフィック急増）がスケジュールスケーリングとAuroraの組み合わせに最適である。
- リードレプリカを事前に拡張し、フェイルオーバーする戦略は、イベント中の可用性を最大化しつつ、コスト最適化も可能にする。
375-AWS SAP AWS 「理論・実践・一問道場」仮想プライベートゲートウェイ
理論
AWS Elastic Disaster Recovery を活用した災害対策の基礎知識
AWS Elastic Disaster Recovery（AWS DRS）は、オンプレミスまたは他のクラウド環境で稼働しているアプリケーションをAWSにレプリケーションすることで、災害対策やバックアップソリューションを提供します。以下に、関連する重要な知識を簡潔にまとめます。
1. AWS DRS の主な特徴
- 継続的レプリケーション:
- ソースサーバーの変更をリアルタイムでAWSに転送。
- 最小のダウンタイムで障害復旧を実現。
- テスト機能:
- ディザスタリカバリ計画を実行する前に、安全にテスト環境を構築。
- 自動化:
- リカバリ後のサーバー設定やスケーリングを自動化。
2. プライベート接続の活用
災害対策において、セキュリティと信頼性を確保するため、以下の接続方法を利用します：
Direct Connect (DX)
- 特徴:
- AWSとオンプレミス間の専用の物理接続。
- トラフィックがパブリックインターネットを通過せず、セキュリティが向上。
- 高帯域幅で、大量のデータを効率的に転送可能。
- 適用シナリオ:
- 高いパフォーマンスと信頼性が求められる環境。
- レプリケーショントラフィックを確実に管理する必要がある場合。
Site-to-Site VPN
- 特徴:
- オンプレミスネットワークとAWS VPC間をVPNで接続。
- 低コストだが、帯域幅に制限がある。
- 適用シナリオ:
- トラフィック量が少ない場合やコスト優先の場合。
3. ネットワーク構成
プライベートサブネットと仮想プライベートゲートウェイ
- プライベートサブネット:
- インターネットに直接公開しないリソースを配置。
- セキュリティを確保しつつ、内部でのデータ処理を実施。
- 仮想プライベートゲートウェイ:
- Direct ConnectまたはVPNを通じて、オンプレミスとAWS間のプライベート接続を確立。
レプリケーションにプライベートIPアドレスを使用
- パブリックインターネットを回避することで、データ転送のセキュリティを強化。
4. スケーリングとリカバリ設定の自動化
- AWS DRSでは、ターゲットサーバーの自動スケーリングやリカバリプロセスを設定可能。
- データ転送と同時に、ターゲットサーバーの構成（OS、ストレージ、IPアドレスなど）をプライベート環境に最適化。
5. ポイントまとめ
- Direct Connect を利用して信頼性の高い接続を構築。
- プライベートサブネットとプライベートIPアドレスを使用してセキュリティを確保。
- レプリケーションとスケーリングを自動化することで効率的な災害対策を実現。
このような構成は、データのセキュリティを保ちながら、災害時の迅速な復旧を可能にします。
実践
略
一問道場
問題 #375
ある会社がオンプレミスでイントラネットアプリケーションを運用しています。この会社はアプリケーションのクラウドバックアップを設定したいと考えています。このソリューションにはAWS Elastic Disaster Recoveryを選択しました。
以下の要件があります：
- レプリケーショントラフィックがパブリックインターネットを通過しないこと。
- アプリケーションがインターネットからアクセス可能でないこと。
- このソリューションが利用可能なネットワーク帯域幅を全て消費しないこと。他のアプリケーションも帯域幅を必要とするためです。
これらの要件を満たす手順を選択してください。（3つ選択してください）
選択肢：
A. 少なくとも2つのプライベートサブネット、2つのNATゲートウェイ、仮想プライベートゲートウェイを持つVPCを作成します。
B. 少なくとも2つのパブリックサブネット、仮想プライベートゲートウェイ、インターネットゲートウェイを持つVPCを作成します。
C. オンプレミスネットワークとターゲットAWSネットワークの間にAWS Site-to-Site VPN接続を作成します。
D. オンプレミスネットワークとターゲットAWSネットワークの間にAWS Direct Connect接続とDirect Connectゲートウェイを作成します。
E. レプリケーションサーバーの設定中に、データレプリケーションにプライベートIPアドレスを使用するオプションを選択します。
F. ターゲットサーバーの起動設定中に、リカバリーインスタンスのプライベートIPアドレスがソースサーバーのプライベートIPアドレスと一致するようにするオプションを選択します。
解説
正解の組み合わせ：A, D, E（ADE）
解説
AWS Elastic Disaster Recoveryを使用して、オンプレミスアプリケーションのセキュアで効率的なクラウドバックアップを設定する要件を満たす手順を以下に説明します。
正解選択肢の詳細
A. 少なくとも2つのプライベートサブネット、2つのNATゲートウェイ、仮想プライベートゲートウェイを持つVPCを作成します。
- 理由: プライベートサブネットを使用することで、AWS内のリソースがインターネットから隔離されます。仮想プライベートゲートウェイを使うことで、オンプレミスとのプライベート接続（VPNやDirect Connect）を構成できます。
- 重要性: アプリケーションがインターネットに公開されない要件を満たします。
D. オンプレミスネットワークとターゲットAWSネットワークの間にAWS Direct Connect接続とDirect Connectゲートウェイを作成します。
- 理由: Direct Connectは、オンプレミスとAWS間の専用の物理接続を提供し、信頼性が高く、高帯域幅でレプリケーショントラフィックを処理できます。また、トラフィックがパブリックインターネットを通過しません。
- 重要性: 高い信頼性とセキュリティが求められるバックアップ要件に対応します。
E. レプリケーションサーバーの設定中に、データレプリケーションにプライベートIPアドレスを使用するオプションを選択します。
- 理由: レプリケーショントラフィックにプライベートIPアドレスを使用することで、インターネット経由のデータ転送を回避できます。
- 重要性: データのセキュアな転送を実現します。
不正解の選択肢
B. 少なくとも2つのパブリックサブネット、仮想プライベートゲートウェイ、インターネットゲートウェイを持つVPCを作成します。
- 理由: パブリックサブネットとインターネットゲートウェイを利用すると、リソースがインターネットに公開されるリスクがあります。これは、アプリケーションがインターネットにアクセスできないようにする要件を満たしません。
C. オンプレミスネットワークとターゲットAWSネットワークの間にAWS Site-to-Site VPN接続を作成します。
- 理由: Site-to-Site VPNは低コストですが、トラフィックが大量になる場合にパフォーマンスが制限されることがあります。この問題では、Direct Connectの使用が求められています。
F. ターゲットサーバーの起動設定中に、リカバリーインスタンスのプライベートIPアドレスがソースサーバーのプライベートIPアドレスと一致するようにするオプションを選択します。
- 理由: この設定は便利ですが、問題文で要求されている内容には直接関係しません。
AWS Elastic Disaster Recovery（AWS DRS）の設定で、ターゲットサーバー（リカバリーインスタンス）のネットワーク構成を行う際に、「リカバリーインスタンスのプライベートIPアドレスをソースサーバー（元のオンプレミスまたは他の環境のサーバー）のプライベートIPアドレスと一致させる」というオプションを選択することを指しています。
背景と目的
- プライベートIPアドレスの一致の意義:
- リカバリーインスタンスが、元のソースサーバーと同じプライベートIPアドレスを持つことで、アプリケーションやネットワーク構成に変更を加える必要がなくなります。
- 例えば、オンプレミスのサーバーが停止し、AWS上のリカバリーインスタンスに切り替えた場合でも、アプリケーションが従来通り機能することを保証できます。
- 主な利点:
- ネットワークの一貫性: ネットワーク設定や接続情報がそのまま維持される。
- 復旧プロセスの簡略化: 復旧時にIPアドレス変更に伴う追加作業を回避。
- 依存関係の維持: 他のシステムが特定のIPアドレスを期待している場合でも問題が発生しない。
使用例
例えば、オンプレミス環境で192.168.1.100というプライベートIPを持つサーバーをAWS上に復旧する際、そのリカバリーインスタンスに同じ192.168.1.100のIPアドレスを割り当てる設定を選択します。これにより、他のシステムがそのIPアドレスに依存している場合でも、何の変更も必要なく動作します。
要約
正しい組み合わせ（A, D, E）は、以下の要件を満たします：
- セキュリティ：インターネット経由のトラフィックを回避（A, E）。
- 高い信頼性：Direct Connectを使用した接続（D）。
- セグメント化されたネットワーク構成：プライベートサブネット（A）。
この構成により、バックアップの効率性、セキュリティ、およびアプリケーションの要件がすべて満たされます。
376-AWS SAP AWS 「理論・実践・一問道場」S3 ライフサイクルポリシー
理論
1. AWS Lambda とイベント駆動型アーキテクチャ
- AWS Lambdaは、サーバーレスでコードを実行できるサービスです。イベント駆動型のアーキテクチャでは、S3やEventBridgeなどのサービスからトリガーされるイベントに基づいて、Lambda関数が自動的に実行されます。
- 例えば、S3バケットに画像がアップロードされると、そのイベントがLambda関数を呼び出し、リサイズ処理を行い、結果をS3に保存します。
2. Amazon S3 とストレージクラス
- S3 Standardは、頻繁にアクセスされるデータに最適です。画像ファイルなど、アクセス頻度が高いデータの保存に適しています。
- *S3 Standard-IA（Infrequent Access）**は、アクセス頻度が低いデータに向いており、コストを節約するために使用されますが、アクセス頻度が高いデータには不向きです。
- S3 Glacierは、長期間アクセスされないデータを低コストで保存できるストレージクラスであり、アーカイブ用途に使われます。
3. AWS EventBridge と S3 イベント
- Amazon EventBridgeは、アプリケーション間でイベントを伝播させるためのサービスで、AWSサービス間やカスタムイベントソースを統合できます。S3バケットにアップロードされた画像のイベントをトリガーとして、必要な処理をLambdaで行う場合などに利用されます。
- EventBridgeを使うことで、スケーラブルで耐障害性の高いアーキテクチャを構築することができます。
4. AWS Step Functions
- AWS Step Functionsは、複数のAWSサービスを組み合わせて、複雑なワークフローを構築できるサービスです。複雑なエラーハンドリングや状態管理が必要な場合に使用されますが、単純な画像処理やリサイズのようなタスクには過剰かもしれません。
5. S3 ライフサイクルポリシー
- S3ライフサイクルポリシーは、S3内のオブジェクトに対して自動的に保存期間を管理するルールを設定できます。画像を6か月後に削除またはアーカイブするなど、ストレージコストを最適化するために利用されます。
6. コスト効率とスケーラビリティ
- スケーラビリティ: イベント駆動型のアーキテクチャ（Lambda + S3イベント）は、トラフィックの増加に対して自動的にスケールできるため、大規模な処理にも適しています。
- コスト効率: S3ライフサイクルポリシーを活用することで、必要に応じてストレージクラスを変更し、コストを最適化できます。また、AWS LambdaやEventBridgeは、使用した分だけ課金されるため、無駄なコストを削減できます。
まとめ:
AWS Lambda、EventBridge、S3ライフサイクルポリシーを組み合わせることで、スケーラブルでコスト効率の高い画像処理システムを構築することができます。また、S3のストレージクラスやライフサイクルポリシーを利用して、データの保存コストを最適化することが可能です。
実践
略
一問道場
質問 #376
画像ストレージサービスを提供する会社が、顧客向けのソリューションをAWSにデプロイしようとしています。このソリューションは数百万の個人顧客によって使用されます。ソリューションは、大量の大きな画像ファイルを受け取り、それらをリサイズし、Amazon S3バケットに最大6か月間保存します。
ソリューションは、需要の大きな変動に対応する必要があります。また、企業規模で信頼性があり、失敗が発生した場合には処理ジョブを再実行できる必要があります。
この要件を最もコスト効率よく満たすソリューションはどれですか？
A. ユーザーが画像を保存した際に発生するS3イベントを処理するためにAWS Step Functionsを使用します。画像をその場でリサイズし、元のファイルをS3バケット内に置き換えるAWS Lambda関数を実行します。すべての保存された画像を6か月後に期限切れにするS3ライフサイクルポリシーを作成します。
B. ユーザーが画像をアップロードした際に発生するS3イベントを処理するためにAmazon EventBridgeを使用します。画像をその場でリサイズし、元のファイルをS3バケット内に置き換えるAWS Lambda関数を実行します。すべての保存された画像を6か月後に期限切れにするS3ライフサイクルポリシーを作成します。
C. S3イベント通知を使用して、ユーザーが画像を保存した際にAWS Lambda関数を呼び出します。このLambda関数を使用して画像をその場でリサイズし、元のファイルをS3バケットに保存します。すべての保存された画像を6か月後にS3 Standard-Infrequent Access（S3 Standard-IA）に移行するS3ライフサイクルポリシーを作成します。
D. ユーザーが画像を保存した際に発生するS3イベントを処理するためにAmazon Simple Queue Service（Amazon SQS）を使用します。画像をリサイズし、リサイズされたファイルをS3 Standard-Infrequent Access（S3 Standard-IA）を使用するS3バケットに保存するAWS Lambda関数を実行します。すべての保存された画像を6か月後にS3 Glacier Deep Archiveに移行するS3ライフサイクルポリシーを作成します。
解説
このシナリオでの要件に最も適したソリューションは B です。以下の理由で選ばれます：
要件のポイント:
- 大量の画像ファイルの取り扱い:
- ソリューションは数百万の個人顧客によって使用され、スケーラビリティが必要です。
- 高い信頼性:
- 失敗が発生した場合に再実行可能でなければならず、信頼性が求められます。
- コスト効率:
- 画像を6か月後に期限切れにし、保存コストを削減するためにS3ライフサイクルポリシーを使用する必要があります。
解説:
- オプションA:
- AWS Step Functionsは非常に強力なサービスですが、画像処理のスケーリングや高い需要に対するコスト効率の点では過剰になる可能性があります。特に、Step Functionsは状態管理や複雑なワークフローを提供しますが、このシナリオでは画像処理の単純なワークフローにはオーバーエンジニアリングとなる可能性があります。
- オプションB:
- Amazon EventBridgeを使用することで、S3イベントを効率的にトリガーし、Lambda関数を呼び出すことができます。EventBridgeは、S3イベントをリアルタイムで処理でき、スケーラブルでコスト効率が良いです。また、S3ライフサイクルポリシーで画像を6か月後に期限切れにする設定も簡単に実行できます。この組み合わせは、高いスケーラビリティとコスト効率を提供し、必要な信頼性も確保できます。
- オプションC:
- S3 Standard-IAに移行するライフサイクルポリシーは、ストレージコストを削減するための方法ですが、特にリサイズ後の画像が頻繁にアクセスされる場合には不適切かもしれません。Standard-IAはアクセス頻度が低い場合に最適ですが、このケースでは頻繁なアクセスが予想されるため、標準的なS3ストレージクラス（S3 Standard）を使用する方がコスト効率が良い可能性があります。
- オプションD:
- SQSを使用してイベントを処理する方法は、非同期のジョブ処理には適していますが、スケーラビリティとコスト効率の面では、EventBridgeや直接Lambdaを使用した方がシンプルで効果的です。また、S3 Glacier Deep Archiveは長期間アクセスされないデータの保存に適しており、6か月後のデータをそれに移行するのは適切ではありません。頻繁にアクセスされる画像ファイルに対しては、より高頻度のアクセスが可能なストレージクラス（S3 Standard）を使用すべきです。
結論:
Bの選択肢は、スケーラビリティ、コスト効率、信頼性の面で最もバランスが取れており、このシナリオに最適です。
377-AWS SAP AWS 「理論・実践・一問道場」Compute Savings Plans
理論
AWSのコスト管理と最適化に関する重要な知識
AWS環境でのコスト管理は、規模が大きくなるにつれて重要になります。企業が効率的にコストを管理し、最適化するためには、以下のポイントを押さえておくことが重要です。
1. AWS Organizations と統合請求
- AWS Organizationsを使うと、複数のAWSアカウントを管理でき、統合請求を利用して、1つの請求書で複数アカウントのコストをまとめて確認できます。これにより、全体のコスト把握がしやすく、部門別のコスト割り当てや集計が可能になります。
2. タグ付け戦略
- タグはリソースを分類し、管理やコストの可視化に役立ちます。タグを使用することで、各部署やプロジェクトごとのリソースの追跡や請求を簡単に行えます。AWSのTag Editorを使って、タグを一括で管理できます。
- 重要なのは、タグ付け戦略を最初に定義しておくことです。部門名、プロジェクト名、環境（開発、テスト、本番）などのタグを使用することが一般的です。
3. AWS Budgets
- AWS Budgetsは、設定した予算に基づいてAWSのサービス使用状況を監視し、コストが予算を超える前にアラートを出すことができます。これを使うことで、予算オーバーを防ぎ、各部門やプロジェクトに対するコスト管理を強化できます。
4. Savings Plans
- Savings Plansは、長期間のリソース使用を事前に約束することで、コストを削減できるオプションです。Compute Savings Plansは、EC2、AWS Lambda、AWS Fargateなど、様々なコンピュータリソースに適用できます。一方、EC2 Instance Savings Plansは、特定のEC2インスタンスタイプに特化しています。
- Savings Plansは柔軟性を保ちながらコスト削減を実現できるため、利用するリソースが変動する場合にも有効です。
5. Service Control Policies (SCPs)
- *SCPs（サービス制御ポリシー）**は、AWS Organizations内でサービスやアクションに対するアクセス制限を設定するための機能です。これを利用することで、特定のアクションやリソースへのアクセスを制限し、コストの無駄遣いを防ぐことができます。ただし、タグの適用には直接関与しないため、タグ管理は他の手段で行う必要があります。
6. AWS Cost Explorer
- AWS Cost Explorerを使用すると、時間ごとのコストの推移をグラフ化し、どのサービスがコストを発生させているかを可視化できます。これにより、リソースの最適化のためにどこでコスト削減が可能かを特定できます。
7. AWS Trusted Advisor
- AWS Trusted Advisorは、AWSの最適化に関する推奨事項を提供するサービスです。コスト削減に関しても、未使用のリソースや過剰にプロビジョニングされたリソースを見つけて、無駄な支出を削減する手助けをしてくれます。
まとめ
AWS環境でのコスト管理と最適化は、タグ付け、統合請求、Savings Plans、そして予算管理ツールを活用することで効果的に行えます。適切な管理戦略を採用し、定期的にリソースの使用状況を見直すことが、長期的なコスト削減に繋がります。
実践
略
一問道場
質問 #377
ある企業がAWS Organizations内で、各部署ごとに別々のAWSアカウントを作成しています。アプリケーションチームは異なる部署から独立してソリューションを開発し、デプロイしています。
企業はコンピュータリソースのコストを削減し、各部署のコストを適切に管理したいと考えています。また、各部署の請求に対する可視性を向上させたいとも考えています。企業はコンピュータリソースの選択において運用の柔軟性を失いたくありません。
これらの要件を満たす解決策はどれですか？
A. 各部署に対してAWS Budgetsを使用し、Tag Editorを使用して適切なリソースにタグを適用します。EC2インスタンスのSavings Plansを購入します。
B. AWS Organizationsを設定して統合請求を使用します。部署を識別するタグ付け戦略を実装します。SCPを使用して適切なリソースにタグを適用します。EC2インスタンスのSavings Plansを購入します。
C. AWS Organizationsを設定して統合請求を使用します。部署を識別するタグ付け戦略を実装します。Tag Editorを使用して適切なリソースにタグを適用します。Compute Savings Plansを購入します。
D. 各部署に対してAWS Budgetsを使用し、SCPを使用して適切なリソースにタグを適用します。Compute Savings Plansを購入します。
解説
この質問は、AWSで部署ごとのコスト管理と可視化を行い、コンピュータリソースのコスト削減を達成するために最適な方法を選択するものです。各選択肢を詳しく見ていきます。
A. AWS Budgets + Tag Editor + EC2 Instance Savings Plans
- AWS Budgetsを使って各部署の予算を設定し、コストを管理します。Tag Editorでリソースにタグを適用することで、各部署ごとにリソースを識別できます。さらに、EC2インスタンスSavings Plansを購入して、EC2インスタンスのコストを削減します。
- 問題点: EC2インスタンスSavings Plansは、特定のEC2インスタンスの利用に最適化されていますが、他のタイプのリソースやコンピューティングリソースには適用できません。また、部署全体のコスト管理という観点から、選択肢としては少し限定的です。
B. AWS Organizations + SCPs + EC2 Instance Savings Plans
- AWS Organizationsの統合請求を使用して、複数のアカウントの請求を一元化します。**SCPs（サービス制御ポリシー）**を使用して、リソースにタグを適用し、部署ごとにリソースの管理を行います。さらに、EC2インスタンスSavings Plansを購入して、EC2インスタンスに特化したコスト削減を実現します。
- 問題点: SCPはポリシーの適用には有効ですが、リソースへのタグ付けには直接関与しません。タグの適用については、Tag Editorや別の方法を使うべきです。
C. AWS Organizations + Tagging Strategy + Tag Editor + Compute Savings Plans
- AWS Organizationsで統合請求を有効にし、部署ごとにタグ付け戦略を実施します。Tag Editorを使って、リソースにタグを適用し、部署ごとのコストを可視化します。そして、Compute Savings Plansを購入して、EC2だけでなく、AWSのさまざまなコンピュータリソースに適用できるコスト削減を実現します。
- 最適解: Compute Savings Plansは、EC2だけでなく、AWSのその他のコンピューティングリソース（Lambda、Fargateなど）にも適用でき、コスト削減の柔軟性が高いです。また、統合請求とタグ付け戦略を組み合わせることで、部署ごとの詳細なコスト分析と管理が可能になります。これにより、運用の柔軟性を維持しつつ、コスト管理を最適化できます。
D. AWS Budgets + SCPs + Compute Savings Plans
- AWS Budgetsで各部署の予算を管理し、SCPsでタグを適用します。さらに、Compute Savings Plansを購入してコスト削減を行います。
- 問題点: SCPsはタグ付けを直接行うものではなく、リソースにタグを適用するためには別の方法（例えばTag Editor）が必要です。また、AWS Budgetsを使用することで予算管理は可能ですが、コストの可視化には不十分な場合があります。
結論
最も適切な選択肢は C です。
- AWS Organizationsでの統合請求と、部署ごとにタグ付け戦略を組み合わせることで、コスト管理と可視化が強化されます。
- Compute Savings Plansは、さまざまなコンピュータリソースに適用できるため、柔軟性があり、コスト削減の効果が高いです。
378-AWS SAP AWS 「理論・実践・一問道場」プリサインドURL
理論
プリサインドURLを使用してオブジェクトをS3にアップロードする手順は以下の通りです：
- 署名付きURLの生成:
- AWS SDKまたはAWS CLIを使用して、
GetObjectまたはPutObject操作用の署名付きURLを生成します。 - 署名付きURLには、有効期限やアクセス権限が含まれます。
- URLの提供:
- 生成したプリサインドURLを、認証されたユーザーに提供します。このURLを通じて、ユーザーはS3にアクセスできます。
- ブラウザまたはアプリケーションでアップロード:
- ユーザーは提供されたURLを使い、ブラウザやアプリケーションからオブジェクトをアップロードします。URLにリクエストを送るだけで、認証や権限チェックを済ませることができます。
- S3での確認:
- アップロードされたオブジェクトは、指定されたS3バケットに保存されます。
プリサインドURLを使用することで、署名の管理やアクセス制御を簡単に行えます。
実践
略
一問道場
問題 #378
ある会社がウェブアプリケーションを運営しており、そのアプリケーションは安全に画像や動画をAmazon S3バケットにアップロードします。この会社は、認証されたユーザーのみがコンテンツを投稿できるようにする必要があります。アプリケーションは、ブラウザインターフェイスを通じてオブジェクトをアップロードするために使用されるプリサインドURLを生成します。ほとんどのユーザーは、100 MB以上のオブジェクトのアップロードが遅いと報告しています。
ソリューションアーキテクトは、認証されたユーザーのみがコンテンツを投稿できることを保証しながら、アップロードパフォーマンスを向上させるために何をすべきですか？
A. Amazon API Gatewayを設定し、エッジ最適化されたAPIエンドポイントを作成して、リソースとしてS3サービスプロキシを設定します。このリソースのPUTメソッドを設定して、S3のPutObject操作を公開します。API GatewayをCOGNITO_USER_POOLS認証を使用してセキュリティで保護します。ブラウザインターフェイスには、プリサインドURLの代わりにAPI Gatewayを使用してオブジェクトをアップロードさせます。
B. Amazon API Gatewayを設定し、リージョン別のAPIエンドポイントを作成して、リソースとしてS3サービスプロキシを設定します。このリソースのPUTメソッドを設定して、S3のPutObject操作を公開します。API GatewayをAWS Lambda認証でセキュリティで保護します。ブラウザインターフェイスには、プリサインドURLの代わりにAPI Gatewayを使用してオブジェクトをアップロードさせます。
C. S3バケットにS3転送加速エンドポイントを有効にします。このエンドポイントを使用してプリサインドURLを生成します。ブラウザインターフェイスには、このURLを使用してオブジェクトをS3マルチパートアップロードAPIでアップロードさせます。
D. Amazon CloudFrontディストリビューションを対象のS3バケットに設定します。CloudFrontキャッシュビヘイビアのPUTおよびPOSTメソッドを有効にします。CloudFrontオリジンをオリジンアクセスアイデンティティ（OAI）を使用するように更新します。OAIユーザーにS3バケットポリシーで3:PutObjectの権限を付与します。ブラウザインターフェイスには、CloudFrontディストリビューションを使用してオブジェクトをアップロードさせます。
解説
この問題に対する解説は、各選択肢がどのようにS3へのアップロードパフォーマンスを改善し、認証されたユーザーのみがコンテンツを投稿できるようにするかに焦点を当てています。
A. API Gateway + Cognito User Pools
- 説明: Amazon API Gatewayを使用し、エッジ最適化されたAPIエンドポイントでS3のPutObject操作を公開します。COGNITO_USER_POOLS認証を使用して、API Gatewayをセキュアにします。
- 問題点: API Gatewayのエッジ最適化は、主にグローバルなアクセスに最適化されていますが、アップロード速度向上には特に関与しません。また、大きなファイルのアップロードにはAPI Gatewayのオーバーヘッドが発生するため、パフォーマンスが低下する可能性があります。
- 結論: パフォーマンス向上を最優先にする場合、API Gatewayは最適ではありません。特に大きなファイルのアップロードにおいて、遅延が発生する可能性があります。
B. API Gateway + Lambda Authorizer
- 説明: API Gatewayを使用し、AWS Lambda認証を利用して認証を行います。この設定は、セキュリティには有効ですが、パフォーマンスには影響を与える可能性があります。
- 問題点: Lambda認証によるオーバーヘッドがあり、大きなファイルのアップロードに対するパフォーマンス向上には寄与しません。API Gatewayはマネージドサービスとして便利ですが、速度には制限があります。
- 結論: 同様に、パフォーマンスの問題を解決するためには、他の選択肢を検討するべきです。
C. S3 Transfer Acceleration + Multipart Upload
- 説明: S3転送加速を有効にすると、アップロードのパフォーマンスが改善される可能性があります。特に、大きなファイルや遠距離からのアップロード時に有効です。転送加速により、データが最寄りのエッジロケーションからS3バケットに転送され、帯域幅が最適化されます。マルチパートアップロードを使用すると、ファイルが複数の部分に分割され並行してアップロードされるため、全体のアップロード速度が向上します。
- 結論: この方法は、パフォーマンス改善に最も効果的です。特に、100 MB以上の大きなオブジェクトに対して顕著なパフォーマンス向上が期待できます。
D. CloudFront Distribution + OAI
- 説明: CloudFrontは、静的コンテンツの配信を最適化するためのCDN（コンテンツ配信ネットワーク）ですが、アップロードパフォーマンスを向上させるためには必ずしも効果的ではありません。CloudFrontのキャッシュを利用してS3バケットへのPUTおよびPOSTメソッドを処理することができますが、アップロードは通常、S3転送加速やマルチパートアップロードで行う方が効率的です。
- 問題点: CloudFrontはコンテンツ配信の最適化には優れていますが、大きなファイルのアップロードに対しては、転送加速やマルチパートアップロードの方がより適切です。
- 結論: CloudFrontを使用することでコンテンツ配信のパフォーマンスは向上しますが、アップロードのパフォーマンス向上には転送加速の方が効果的です。
結論
最も適切な選択肢は C です。S3転送加速を使用すると、アップロード速度が改善され、大きなオブジェクト（100 MB以上）のアップロードにおいて特にパフォーマンスが向上します。また、マルチパートアップロードを使用することで、大きなファイルを並行してアップロードし、処理時間を短縮できます。
379-AWS SAP AWS 「理論・実践・一問道場」AWS Organizations
理論
AWS Organizationsとコスト管理、セキュリティ管理のベストプラクティス
AWSでは、複数のAWSアカウントを効率的に管理するためにAWS Organizationsを使用することが推奨されます。以下は、AWS Organizationsを使用する際の重要なポイントとそのメリットです。
1. AWS Organizationsの利用
- AWS Organizationsを使用することで、複数のアカウントを一元的に管理できます。これにより、各事業部門やチームが独自のアカウントを持ちながら、組織全体でのコスト管理やポリシーの適用が簡単になります。
- アカウントは**組織単位（OU）**としてグループ化でき、各部門やワークロードに基づいてポリシーや請求を管理できます。
2. サービスコントロールポリシー（SCP）
- *サービスコントロールポリシー（SCP）**は、AWS Organizations内のアカウントに対する許可・拒否を制御します。SCPを使って、特定の操作（例：EC2インスタンスの起動、S3バケットへのアクセス）を制限することができます。
- これにより、セキュリティチームは最小権限の原則を遵守し、全アカウントにわたって一貫したポリシーを適用できます。
3. タグによるコスト配分と管理
- 各AWSリソースにはタグを設定し、コスト配分を行うことができます。タグは部門やプロジェクトに関連するリソースを識別するために利用され、AWS Cost Explorerを使ってコストの可視化やレポート作成が可能になります。
- タグ付けにより、AWSのリソース使用量やコストを部門単位で管理できるため、部門ごとのコスト管理が容易になります。
4. コンソリデーションによる支払い管理
- *統合請求（Consolidated Billing）**を活用すると、すべてのAWSアカウントを1つの請求アカウントに集約することができます。この機能を使用すると、親アカウント（支払者アカウント）で1つの請求書を受け取り、複数のアカウントで発生したコストを合算して管理できます。
- 複数のアカウントでの割引（例：利用量に応じた価格割引）を最大化するためにも役立ちます。
5. アカウントのプロビジョニングと管理
- AWS Organizationsを使うことで、新しいアカウントを自動的にプロビジョニングしたり、既存のアカウントを組織に招待したりすることができます。これにより、アカウントの作成と管理が効率化され、企業の成長に合わせてスムーズにアカウントを増やすことができます。
6. コスト管理と予算設定
- AWS Budgetsを利用することで、各部門ごとのコスト予算を設定し、予算超過を防ぐためのアラートを設定できます。これにより、コスト超過のリスクを早期に察知し、予算内での運用が可能となります。
7. IAM権限の集中管理
- AWS IAMを使用して、ユーザーやグループごとにアクセス権を設定し、権限を細かく制御できます。これにより、個々のアカウント内でのアクセス権限を管理する際に、セキュリティリスクを最小化できます。
結論
AWS Organizationsを使用することで、企業は複数のAWSアカウントを効率的に管理し、コスト管理とセキュリティ管理の一貫性を保ちながら運用できます。サービスコントロールポリシー（SCP）、統合請求、タグ付けによるコスト管理などの機能を活用することで、最小の労力で組織全体をスケーラブルかつセキュアに管理することが可能です。
実践
略
一問道場
問題 #379
大企業がそのITポートフォリオ全体をAWSに移行しています。各事業部門は、開発およびテスト環境をサポートする独立したAWSアカウントを持っています。まもなく、プロダクションワークロードをサポートする新しいアカウントが必要になります。
財務部門は、支払いのための集中管理方法を要求していますが、各グループの支出に対する可視性を維持して、コストを割り当てる必要があります。
セキュリティチームは、会社のすべてのアカウントでIAMの使用を制御するための集中管理メカニズムを要求しています。
最小の労力で会社のニーズを満たすために、次のオプションの組み合わせはどれですか？（2つ選択）
A. パラメータ化されたAWS CloudFormationテンプレートのコレクションを使用して、共通のIAM権限を定義し、各アカウントに展開します。新しいアカウントと既存のアカウントに、適切なスタックを起動させて最小特権モデルを強制します。
B. AWS Organizationsを使用して、選択した支払者アカウントから新しい組織を作成し、組織単位の階層を定義します。既存のアカウントを組織に招待し、Organizationsを使用して新しいアカウントを作成します。
C. 各事業部門に自分のAWSアカウントを使用させます。各AWSアカウントに適切なタグを付け、Cost Explorerを有効にして費用配分を管理します。
D. AWS Organizationsのすべての機能を有効にし、適切なサービスコントロールポリシーを確立して、サブアカウントのIAM権限をフィルタリングします。
E. 会社のすべてのAWSアカウントを単一のAWSアカウントに統合します。請求目的でタグを使用し、IAMのAccess Advisor機能を使用して最小特権モデルを強制します。
解説
この問題は、企業がAWSの複数のアカウントを管理し、コスト管理、セキュリティ、IAMの統制を効率的に行うための方法を選ぶことに関するものです。各選択肢について詳しく解説します。
正解となる選択肢：
B. AWS Organizationsを使用して、選択した支払者アカウントから新しい組織を作成し、組織単位の階層を定義します。既存のアカウントを組織に招待し、Organizationsを使用して新しいアカウントを作成します。
D. AWS Organizationsのすべての機能を有効にし、適切なサービスコントロールポリシーを確立して、サブアカウントのIAM権限をフィルタリングします。
選択肢の解説：
A. CloudFormationテンプレートでIAM権限を定義し、各アカウントでこれらのスタックを起動する方法：
- CloudFormationを使って共通のIAM権限を定義する方法も考えられますが、これは複数のアカウントにわたって権限を一貫して適用するには手間がかかります。また、新しいアカウントが追加されるたびに、適切なスタックを手動で起動する必要があり、管理が複雑になります。このため、最小の労力という点では最適ではありません。
B. AWS Organizationsを使用して組織を作成し、アカウントを管理する方法：
- AWS Organizationsを使用すると、企業全体での集中管理が容易になります。特に、各事業部門に独立したAWSアカウントを使用し、それらを一元的に管理できます。組織単位（OU）を使ってアカウントを階層化し、支払いとコストの管理を簡単にすることができます。この方法で新しいアカウントを追加したり、既存のアカウントを管理したりするのが効率的です。
C. 各事業部門に独立したAWSアカウントを使用し、タグを使ってコストを管理する方法：
- 各アカウントにタグを適用することでコスト配分は可能ですが、AWS Organizationsを使用した集中管理の方がよりスケーラブルで柔軟です。タグだけでは、IAMの統制や一貫したポリシー適用に限界があります。
D. AWS Organizationsのすべての機能を有効にし、サービスコントロールポリシー（SCP）を使ってIAM権限を管理する方法：
- *サービスコントロールポリシー（SCP）**を使用すると、組織全体でIAMの使用を中央集権的に管理できます。これにより、セキュリティチームは各アカウントで適切なIAM権限が使用されているかを確認し、最小権限の原則を実施することができます。
E. すべてのAWSアカウントを単一アカウントに統合し、タグを使って管理する方法：
- 複数のアカウントを単一のAWSアカウントに統合する方法は、スケーラビリティや管理の観点で問題があります。複数のアカウントを使うことによって、それぞれの部署の独立性やセキュリティを確保できるため、単一アカウントにまとめるのは適切ではありません。また、タグによる管理も十分ではなく、SCPを活用した管理の方が効果的です。
結論：
最も効率的で労力が少なく、セキュリティとコスト管理を簡単にする方法は、AWS Organizationsを使用してアカウントを管理し、SCPでIAM権限を制御する方法です。
380-AWS SAP AWS 「理論・実践・一問道場」
理論
1. メッセージングサービスの活用
- Amazon SQS (Simple Queue Service) は、非同期的なメッセージキューイングサービスで、システムの耐障害性を高めるために活用されます。処理が失敗した場合でも、メッセージをキューに保存し、後で処理できるため、データの損失を防ぐことができます。
- デッドレターキュー (DLQ) は、失敗したメッセージを保存する専用のキューです。失敗した処理を分析し、手動で再処理できるようにするための重要なツールです。
2. 冗長性とスケーラビリティ
- システムの冗長性を確保することで、障害が発生しても別のインスタンスやサービスが処理を引き継げるようになります。例えば、SQSを使うことでメッセージを一時的に保存し、複数の処理ユニット（Lambda関数など）で並行して処理することが可能です。
- スケーラビリティの確保も重要です。負荷が高くなるとサービスが過負荷になるため、自動スケーリングや並列処理を使ってシステムの負荷分散を行うことが求められます。
3. リトライと再試行ポリシー
- 処理が失敗した場合に備えて、リトライポリシーや再試行メカニズムを組み込むことが重要です。失敗したメッセージを一定回数リトライし、最終的に失敗した場合にはデッドレターキューに送る設計が一般的です。
4. イベント駆動型アーキテクチャ
- Amazon EventBridge や AWS Lambda は、イベント駆動型のシステムでのエラーハンドリングを効率化します。イベントが失敗した場合でも、他のシステムに影響を与えずに後続処理を行うための柔軟性を提供します。
5. モニタリングとアラート
- システムの監視が欠かせません。Amazon CloudWatch を使って、SQSのキューの長さやLambda関数の実行時間、失敗率を監視し、問題が発生する前に通知を受け取れるようにすることで、迅速に対処できます。
このようなアーキテクチャやサービスを活用することで、システムの耐障害性を強化し、予期しない障害に備えることができます。
実践
略
一問道場
ある企業が、数千の気象観測所からの気象データを分析するソリューションを持っています。気象観測所はデータをAmazon API Gateway REST API経由で送信し、そのAPIはAWS Lambda関数と統合されています。Lambda関数は、データの前処理のためにサードパーティサービスを呼び出します。しかし、サードパーティサービスが過負荷になり、前処理が失敗し、データが失われています。
ソリューションアーキテクトは、ソリューションのレジリエンシー（耐障害性）を改善する必要があります。ソリューションアーキテクトは、データが失われることなく、失敗が発生した場合に後でデータを処理できることを確保する必要があります。
この要件を満たすために、ソリューションアーキテクトは何をすべきですか？
A. Amazon Simple Queue Service (Amazon SQS) キューを作成し、そのキューをAPIのデッドレターキューとして設定します。
B. 2つのAmazon Simple Queue Service (Amazon SQS) キューを作成します。1つはプライマリキュー、もう1つはセカンダリキューです。セカンダリキューをプライマリキューのデッドレターキューとして設定します。APIを新しい統合に更新し、プライマリキューを使用します。Lambda関数をプライマリキューの呼び出しターゲットとして設定します。
C. 2つのAmazon EventBridge イベントバスを作成します。1つはプライマリイベントバス、もう1つはセカンダリイベントバスです。APIを新しい統合に更新し、プライマリイベントバスを使用します。プライマリイベントバスのすべてのイベントに反応するEventBridgeルールを設定し、そのルールのターゲットとしてLambda関数を指定します。Lambda関数の失敗先としてセカンダリイベントバスを設定します。
D. カスタムAmazon EventBridgeイベントバスを作成し、Lambda関数の失敗先としてそのイベントバスを設定します。
解説
B. 2つのAmazon Simple Queue Service (Amazon SQS) キューを作成します。1つはプライマリキュー、もう1つはセカンダリキューです。セカンダリキューをプライマリキューのデッドレターキューとして設定します。APIを新しい統合に更新し、プライマリキューを使用します。Lambda関数をプライマリキューの呼び出しターゲットとして設定します。
この選択肢の解説：
- プライマリキューとセカンダリキューを使うことで、リクエストが失敗した場合にセカンダリキューにデータを移し、後で処理を再試行できます。これにより、データの損失を防ぎ、後で再処理を行うレジリエンシーを強化できます。
- デッドレターキューとしてセカンダリキューを使用することによって、プライマリキューが正常に処理できなかったリクエストを後で処理するためのエラーハンドリングが行われます。この方法では、処理失敗時のメッセージを追跡し、再処理の際に手動で問題を修正できるため、確実にデータを失うことなく処理を行えます。
Bのメリット：
- 失敗したリクエストをセカンダリキューに保存し、後で再処理を行えるため、データ損失の防止が可能です。
- 複数のキューを使用することで、処理の優先度を分けることができます（プライマリとセカンダリの使い分け）。
- エラーハンドリングの柔軟性を持たせることができ、失敗したリクエストに対して手動で対応できる場面が増えます。
Aとの比較：
- Aの選択肢では、SQSをデッドレターキューとして使用する方法が提案されています。こちらも有効ですが、Bの方法では、より高い柔軟性を持って複数のキューを使用することで、失敗時にさらに多くの制御を持たせることができます。
結論：
Bは、データの損失を防ぎつつ、失敗したデータの処理を後で行うために適切なアーキテクチャです。特に、プライマリキューとセカンダリキューを使い分けることで、エラーハンドリングの手法を強化できるため、こちらのアプローチが最適であると言えます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/178d7ae8-88e2-8099-a33a-cf33f0ec4117
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
