type
status
date
slug
summary
tags
category
icon
password

411-AWS SAP AWS 「理論・実践・一問道場」Amazon Cognito

理論

1. Amazon Cognito

  • 概要: Amazon Cognitoは、AWSでのユーザー管理と認証を行うサービスです。主に、ユーザーがアプリケーションにアクセスする際の認証を管理するために使用されます。
  • MFA対応: Cognitoでは、ユーザーに対して多要素認証（MFA）を強制できます。これにより、セキュリティを強化し、ユーザーの認証をより安全に行うことができます。
  • ALB統合: CognitoのユーザープールをALBに統合することで、ALBを介してアプリケーションにアクセスするユーザーの認証を強制できます。これにより、アプリケーションに対するアクセス制御を効果的に実現できます。

2. Application Load Balancer (ALB)

  • 概要: ALBは、HTTP/HTTPSリクエストの負荷分散を行うAWSのサービスです。ALBは、リスナールールを使用してトラフィックをさまざまなターゲットにルーティングできます。
  • 認証機能: ALBには、Cognitoを統合して認証を強制する機能があります。リスナールールを設定し、Cognitoを通じてユーザー認証を行うことが可能です。

3. 多要素認証 (MFA)

  • 概要: MFAは、ユーザーの認証に追加のセキュリティ層を提供します。通常、ユーザー名とパスワードに加えて、物理的なデバイス（例: スマートフォンアプリ）から生成されるコードを使用します。
  • AWSでのMFA: AWSでは、MFAを有効にすることで、管理者アカウントやユーザーアカウントのセキュリティを強化できます。特に重要な操作（例: IAMポリシーの変更、AWSリソースの削除）にMFAを要求することが推奨されます。

4. AWS Identity and Access Management (IAM)

  • 概要: IAMは、AWSリソースへのアクセスを管理するサービスで、ポリシーに基づいてユーザーやグループにアクセス許可を設定します。
  • MFAとの統合: IAMユーザーは、MFAデバイスを設定して、AWSコンソールやAPIへのアクセスにMFAを強制することができます。

5. IAM Identity Center (AWS Single Sign-On)

  • 概要: AWS IAM Identity Centerは、企業のユーザーにシングルサインオン（SSO）機能を提供するサービスです。これにより、複数のAWSアカウントや外部アプリケーションに対して一元的にアクセス管理を行うことができます。
  • MFA対応: IAM Identity Centerは、MFAをサポートしており、企業のポリシーに基づいてMFAを必要とすることができます。ただし、ALBとの統合には慎重な設定が必要です。

結論

ユーザーアクセス制御とMFAの設定は、セキュリティ強化のために重要なステップです。AWSのCognitoやIAMを適切に使用し、ALBと組み合わせることで、インターネットからのアクセスに対してセキュアな認証を実現できます。特に、Cognitoを利用したMFAの強制は、インターネット上でのアプリケーションアクセスにおけるセキュリティのベストプラクティスです。

実践

略

一問道場

問題 #411
ある会社が、AWS上でサードパーティ製のウェブアプリケーションを展開しています。このアプリケーションはDockerイメージとしてパッケージ化されています。会社はそのDockerイメージをAmazon Elastic Container Service (Amazon ECS) のAWS Fargateサービスとして展開しています。アプリケーションへのトラフィックはApplication Load Balancer (ALB)によって転送されています。
会社は、特定のユーザーリストにのみインターネットからアプリケーションへのアクセスを許可する必要があります。会社はアプリケーションを変更できず、アイデンティティプロバイダーとの統合もできません。すべてのユーザーは、多要素認証(MFA)を通じて認証されなければなりません。
どのソリューションがこれらの要件を満たしますか？
A. Amazon Cognitoでユーザープールを作成します。プールをアプリケーションに対して設定します。必要なユーザーをプールに登録します。プールをMFAを必要とするように設定します。ALBでリスナールールを設定し、Amazon CognitoのホストされたUIを通じて認証を要求します。
B. ユーザーをAWS Identity and Access Management (IAM)で設定します。Fargateサービスにリソースポリシーを適用して、ユーザーがMFAを使用することを要求します。ALBでリスナールールを設定し、IAMを通じて認証を要求します。
C. ユーザーをAWS Identity and Access Management (IAM)で設定します。AWS IAM Identity Center (AWS Single Sign-On) を有効にします。ALBのリソース保護を設定し、MFAを使用することを要求するリソース保護ルールを作成します。
D. AWS Amplifyでユーザープールを作成します。プールをアプリケーションに対して設定します。必要なユーザーをプールに登録します。プールをMFAを必要とするように設定します。ALBでリスナールールを設定し、AmplifyのホストされたUIを通じて認証を要求します。

解説

この問題は、AWS上でホストされているアプリケーションに対して、特定のユーザーにのみアクセスを許可し、そのユーザーが多要素認証（MFA）を通じて認証されるようにする方法に関するものです。
それぞれの選択肢について解説します。

A. Amazon Cognitoでユーザープールを作成する

  • 説明: Amazon Cognitoは、ユーザー認証を管理するためのサービスです。ユーザープールを作成し、そのプールに必要なユーザーを登録し、MFAを必須とすることができます。ALBのリスナールールを設定することで、Amazon CognitoのホストされたUIを使用して認証を強制できます。
  • 適切な理由: このソリューションは要件を満たします。Cognitoを使えば、ユーザー管理やMFA認証を簡単に設定でき、ALBでのリスナールールを使ってその認証を強制できます。アプリケーションの変更なしに、ユーザー認証とMFAを実現できます。

B. IAMでユーザーを設定し、Fargateサービスにリソースポリシーを適用する

  • 説明: IAMを使用してユーザーを設定し、Fargateサービスに対してリソースポリシーを設定し、MFAを必須にする方法です。しかし、ALBでの認証にIAMを使って制限することは一般的には推奨されません。
  • 不適切な理由: IAMでMFAを強制することは可能ですが、ALBでIAMを使って直接ユーザー認証を行う方法は適切ではありません。ALBはIAM認証の直接的な仕組みをサポートしておらず、この方法では要件に合致しません。

C. IAM Identity Center (AWS Single Sign-On) を有効にする

  • 説明: IAM Identity Center（旧AWS SSO）を使って、ユーザーにシングルサインオンでアクセスを提供する方法です。リソース保護ルールを使用して、ALBでMFAを要求することができますが、IAM Identity CenterをALBに直接統合することは複雑で、一般的にはサポートされていません。
  • 不適切な理由: IAM Identity Centerはユーザー認証の管理に役立ちますが、ALBで直接MFAを要求するためには、他のサービス（Cognitoなど）の方が適切です。この方法は、要件を満たすために複雑な設定が必要になります。

D. AWS Amplifyでユーザープールを作成する

  • 説明: AWS Amplifyは主にフルスタックのアプリケーション開発をサポートするツールです。Amplifyでユーザープールを作成して、ユーザーを登録し、MFAを要求することができますが、Amplifyは主にフロントエンドのアプリケーションと統合されるものであり、ALBと直接連携させるのは通常の使用方法ではありません。
  • 不適切な理由: AWS Amplifyは主にフロントエンドアプリケーションに焦点を当てたサービスであり、ALBのリスナールールとの統合に関しては、Cognitoの方が適しているため、このソリューションは過剰であり、要件を満たすためには不適切です。

結論

最適な選択肢は A です。
Amazon Cognitoを使用してユーザープールを作成し、MFAを強制し、ALBでその認証を要求する方法が、要件に完全に適合します。
 
 

412-AWS SAP AWS 「理論・実践・一問道場」CAPABILITY_NAMED_IAM

 

理論

カスタムIAMロールは、AWSリソースにアクセスするために作成されるユーザーやサービスの権限を定義したものです。特定の操作を許可するために、信頼ポリシー（どのサービスがロールを引き受けるか）とアクセス許可ポリシー（どのアクションを実行できるか）を設定できます。
これにより、ユーザーやサービスに対して柔軟で細かいアクセス権限の管理が可能となり、セキュリティを強化できます。
 
CAPABILITY_NAMED_IAMは、AWS CloudFormationで使用される特別な許可です。この許可が必要なのは、CloudFormationがテンプレート内でカスタムIAMロールやIAMポリシーなどのリソースを作成または変更する場合だからです。

なぜCAPABILITY_NAMED_IAMが必要か？

AWS CloudFormationはリソースの作成・管理を自動化するためのツールですが、IAMロールやポリシーは非常にセンシティブでセキュリティ上重要なリソースです。そのため、AWSはCloudFormationがこれらのリソースを作成したり、カスタム名で変更したりする場合に、明示的に許可を与えることを求めています。

具体的な理由は以下の通りです：

  1. カスタムIAMロールの作成・変更
      • AWS CloudFormationがテンプレート内でカスタム名を持つIAMロールを作成しようとする場合、このリソースは他のリソースと異なり、権限の付与やアクセス管理に大きな影響を与えます。誤って適切な権限を設定しないと、アカウントのセキュリティに深刻な影響を与える可能性があります。
  1. リソースの安全な管理
      • IAMロールの作成や変更は、AWSアカウントのアクセス管理に直接影響を与えます。これにより、CloudFormationが安全にこれらのリソースを管理できるよう、明示的にユーザーが同意する必要があります。CAPABILITY_NAMED_IAMは、これらのリソースに対する操作を許可するための保護機能です。
  1. セキュリティとガバナンスの管理
      • IAMリソースは、AWSリソースやデータに対するアクセスを制御するため、最も厳密に管理されるべきリソースの一つです。AWSは、CloudFormationテンプレートでカスタム名のIAMリソースが変更される場合、ユーザーがその影響を認識し、許可を与えることを求めることで、セキュリティリスクを低減します。

目的

CAPABILITY_NAMED_IAMの目的は、CloudFormationがカスタムIAMリソースを安全に作成・変更できるようにするためです。この権限を与えることで、CloudFormationは以下のことが可能になります：
  • カスタムIAMロールやポリシーを作成する
  • IAMリソースの名前を変更する
  • テンプレートに記載されたIAMリソースを展開する
ユーザーはこの権限を付与することで、CloudFormationがIAMリソースを操作する際のセキュリティ上のリスクを理解し、承認する必要があるため、意図しない権限変更が行われるのを防ぐことができます。

結論

CAPABILITY_NAMED_IAMは、CloudFormationがカスタム名のIAMリソースを作成・変更する際に、ユーザーの明示的な承認を求めるために使用されます。この権限を指定することで、IAMロールやポリシーが安全に管理され、リソースが適切に展開されることが保証されます。

実践

略

一問道場

問題 #412
ソリューションアーキテクトは、以前使用されていなかったAWSリージョンに新しいセキュリティツールを展開する準備をしています。ソリューションアーキテクトは、AWS CloudFormationスタックセットを使用してツールを展開します。スタックセットのテンプレートにはカスタム名を持つIAMロールが含まれています。スタックセットの作成時に、スタックインスタンスが正常に作成されませんでした。
スタックを正常に展開するためにソリューションアーキテクトは何をすべきですか？
A. 関連するすべてのアカウントで新しいリージョンを有効にし、スタックセットの作成時にCAPABILITY_NAMED_IAM機能を指定します。
B. サービスクォータコンソールを使用して、新しいリージョンの各アカウントにおけるCloudFormationスタックの数のクォータ増加をリクエストし、スタックセットの作成時にCAPABILITY_IAM機能を指定します。
C. スタックセットの作成時にCAPABILITY_NAMED_IAM機能とSELF_MANAGED権限モデルを指定します。
D. スタックセットの作成時に管理者ロールARNとCAPABILITY_IAM機能を指定します。

解説

この問題におけるポイントは、CloudFormationスタックセットの展開時に必要な許可設定とIAMロールのカスタム名に関連しています。
AWS CloudFormationスタックセットを使う場合、スタックを作成するリージョンで特定のリソースを操作する権限が必要です。スタックセットの作成に失敗した原因は、IAMロールに関連する設定や許可不足が考えられます。

解説：

選択肢A:
「関連するすべてのアカウントで新しいリージョンを有効にし、スタックセットの作成時にCAPABILITY_NAMED_IAM機能を指定します。」
  • 正解です。AWS CloudFormationでは、スタックセットにカスタムIAMロール名が含まれている場合、CAPABILITY_NAMED_IAMという権限を指定する必要があります。この指定を行わないと、IAMリソースの作成時にエラーが発生します。また、新しいリージョンにリソースを作成するには、そのリージョンが有効化されている必要があります。
選択肢B:
「サービスクォータコンソールを使用して、新しいリージョンの各アカウントにおけるCloudFormationスタックの数のクォータ増加をリクエストし、スタックセットの作成時にCAPABILITY_IAM機能を指定します。」
  • これは、スタック数の制限に関するもので、今回の問題の解決には直接関係ありません。CAPABILITY_IAMは必要ですが、クォータ増加は問題の原因ではないため、解決には不要です。
選択肢C:
「スタックセットの作成時にCAPABILITY_NAMED_IAM機能とSELF_MANAGED権限モデルを指定します。」
  • SELF_MANAGED権限モデルは、スタックセットの管理者と実行者が異なる場合に使用されます。しかし、今回は特にその設定が必要な状況ではありません。SELF_MANAGEDはオプションであり、問題の解決には必須ではないため、これでは解決できません。
選択肢D:
「スタックセットの作成時に管理者ロールARNとCAPABILITY_IAM機能を指定します。」
  • CAPABILITY_IAMは必要ですが、カスタムIAMロール名がある場合は、CAPABILITY_NAMED_IAMが必要です。管理者ロールARNを指定することは有用ですが、問題の本質はIAMロール名に関する設定にあります。

結論：

スタックセットの作成時に、IAMロールのカスタム名を使用している場合は、CAPABILITY_NAMED_IAMを指定することが必要です。また、スタックセットをデプロイするリージョンが有効であることも確認する必要があります。そのため、選択肢Aが最も適切です。
 
 

413-AWS SAP AWS 「理論・実践・一問道場」APIとエンドポイント

 

理論

  • API は、サービスが提供する機能や操作の集合です。例えば、データベースにクエリを実行したり、ユーザー情報を取得したりするためのメソッドを定義しています。
  • エンドポイント は、そのAPIが提供する機能にアクセスするための「入口」です。通常、エンドポイントはURL（またはURI）として表され、リクエストを送信する先となります。
以下は、APIとエンドポイントの違いを示す比較表です：
項目
API
エンドポイント
定義
アプリケーション間でデータを交換するためのインターフェース。リクエストやレスポンスのフォーマット、メソッド（GET、POSTなど）を定義。
APIにアクセスするための「入口」や「インターフェース」。通常、URLやURIで表される。
役割
異なるアプリケーションが通信するためのルールやプロトコルを提供する。
APIにリクエストを送るための特定のURL。APIが提供する機能にアクセスするための接点。
例
REST API, SOAP API, GraphQL APIなど。
https://api.example.com/v1/resourceなどのURL。
使用方法
APIを利用するためのリクエストやレスポンスの形式を決める。
リクエストを送信するために使用する具体的なURLやURI。
関係性
エンドポイントはAPIの一部であり、APIが提供する機能にアクセスするためにエンドポイントを利用する。
APIは複数のエンドポイントを提供することが多い。エンドポイントはAPIの具体的な利用方法を示す。
例えば、Amazon Aurora Data APIの場合、APIはデータベースにクエリを実行するための機能を提供しますが、そのAPIにアクセスするためにはエンドポイント（例えば、https://data-api.cluster-name.region.rds.amazonaws.com）を通じてリクエストを送る必要があります。

実践

略

一問道場

ある会社には、アプリケーションで使用されるAmazon Aurora PostgreSQL DBクラスターがあります。このDBクラスターには、1つの小さいプライマリインスタンスと3つの大きいレプリカインスタンスが含まれています。アプリケーションはAWS Lambda関数で実行されており、データベースのレプリカインスタンスに多くの短期間の接続を行い、読み取り専用操作を実行しています。
高トラフィックの期間中、アプリケーションは信頼性が低下し、データベースは接続が多すぎると報告します。高トラフィックの期間の頻度は予測できません。
どのソリューションがアプリケーションの信頼性を向上させるでしょうか？
A. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。
B. DBクラスターのパラメータグループでmax_connections設定を増加させます。すべてのインスタンスを再起動します。Lambda関数を更新して、DBクラスターのエンドポイントに接続します。
C. DBクラスターでインスタンスのスケーリングを構成し、DatabaseConnectionsメトリックがmax_connections設定に近づいたときにスケーリングが発生するようにします。Lambda関数を更新して、Auroraリーダーエンドポイントに接続します。
D. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシのAurora Data APIの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。

解説

この問題では、AWS Lambda関数がAmazon Aurora PostgreSQLデータベースクラスターに対して多くの短期間の接続を行うため、接続数が多すぎて信頼性が低下しているというシナリオです。特に、高トラフィック時に接続数が制限を超えてしまい、アプリケーションの動作が不安定になる問題が発生しています。

各選択肢の解説

A. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。

  • 解説: RDS Proxyは、データベース接続の管理を効率化するサービスです。特にLambdaなどのアプリケーションが頻繁に接続・切断を行う場合、接続プールを活用して効率的にリソースを管理します。RDS Proxyを使用することで、Lambda関数が直接データベースに接続する回数を減らし、接続の制限を避けることができます。これにより、アプリケーションの信頼性が向上します。
  • 最適解: 高トラフィックの期間中でも接続数の管理が効率化され、接続の過負荷問題を解消できます。

B. DBクラスターのパラメータグループでmax_connections設定を増加させます。すべてのインスタンスを再起動します。Lambda関数を更新して、DBクラスターのエンドポイントに接続します。

  • 解説: max_connectionsの設定を増加させることで、接続数の制限を緩和できますが、この方法はスケーラビリティの根本的な解決にはなりません。特に、Lambda関数が短期間に多くの接続を開いて閉じることが原因である場合、接続数を増やすだけでは、接続管理の負荷が軽減されるわけではありません。
  • 不適切: 根本的な解決にはなりませんし、接続数の増加はコストを引き上げる可能性もあります。

C. DBクラスターでインスタンスのスケーリングを構成し、DatabaseConnectionsメトリックがmax_connections設定に近づいたときにスケーリングが発生するようにします。Lambda関数を更新して、Auroraリーダーエンドポイントに接続します。

  • 解説: インスタンススケーリングを使用しても、接続数を超えた場合にリーダーエンドポイントに接続して読み取り専用の操作を行うことは一時的な解決策になります。しかし、根本的な問題は接続の管理です。スケーリングがトラフィックの急激な変動に追いつかないこともあります。
  • 部分的解決: スケーリングの設定によりトラフィック負荷に対応することはできますが、接続プールを使用した効率的な接続管理には及びません。

D. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシのAurora Data APIの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。

  • 解説: Aurora Data APIはAurora Serverlessに関連しているもので、通常のAuroraインスタンスには適用されません。したがって、このオプションはAurora PostgreSQLには適用できません。
  • 不適切: Aurora Data APIはAurora Serverless向けであり、通常のAuroraインスタンスには使用できません。

結論

最適解はAです。RDS Proxyを利用することで、接続管理を効率化し、Lambda関数が短期間で大量の接続を行う問題を解決できます。
 
 

414-AWS SAP AWS 「理論・実践・一問道場」 AWS IoT Coreでは、自動登録機能、プロビジョニングテンプレート

 

理論

プロビジョニングテンプレートは、AWS IoT Coreでデバイスが自動的に登録されるかどうかを制御する設定です。allow-auto-registrationパラメータを使って、自動登録を有効（true）または無効（false）にできます。
  • 有効化（true）: デバイスが接続すると自動的に登録され、データ送信が可能に。
  • 無効化（false）: デバイスは自動登録されず、手動での検証と承認が必要。
このテンプレートは、デバイス接続時の登録と検証プロセスを管理します。

IoTデバイスのセキュアなAWS接続とプロビジョニングのベストプラクティス

IoT (Internet of Things) は、さまざまなデバイスがインターネットを通じてデータを交換する技術です。小売業におけるIoTセンサーの活用や、AWS（Amazon Web Services）との統合においては、セキュリティと認証が重要な要素となります。特に、センサーがインストールされるまでデータ送信を制限し、インストール後にのみAWSへのデータ送信を許可するという要件に対して、適切なプロビジョニング方法と認証管理を行うことが求められます。
以下では、AWSでのIoTデバイスのセキュアなプロビジョニングに関する汎用的な知識とベストプラクティスを解説します。

1. IoTデバイスの認証とセキュリティ

IoTデバイスがAWSに接続する際、認証とセキュリティは最も重要な考慮点です。AWSでは、デバイス認証にX.509証明書を使用することが一般的です。この証明書は、デバイスがAWS IoT Coreに接続する際に一意の識別子として機能し、セキュアな通信を確保します。

主要な認証方法:

  • X.509証明書: デバイスごとに発行され、一意の識別子（シリアル番号など）を含む証明書です。
  • 事前プロビジョニング: デバイスがインストールされる前に、証明書が発行され、AWS IoT Coreのデバイス登録が行われます。
デバイスがネットワークに接続する前に正しい認証が行われるようにすることが重要です。

2. AWS IoT Coreによるデバイス管理

AWS IoT Coreは、クラウドでデバイスの接続、管理、セキュリティを簡素化するサービスです。デバイスの登録からデータ送信まで、さまざまな機能を提供しています。

IoT Coreのプロビジョニングフロー:

  • デバイス証明書の発行: 各デバイスに一意の証明書を発行し、デバイスが認証されるようにします。
  • プロビジョニングテンプレート: デバイスの構成を定義するテンプレートを作成し、デバイスのプロビジョニング時に適用します。これにより、デバイスごとに異なる設定を適切に適用できます。

3. 事前プロビジョニングとデバイスのインストール管理

要件として「センサーがインストールされるまでAWSにデータを送信できないようにする」ことが挙げられています。この要件を満たすためには、以下の方法が有効です。

方法1: Lambda関数を用いた事前プロビジョニング

  • 事前プロビジョニングフックとしてLambda関数を使用することができます。これにより、デバイスがインストールされる前にAWS IoT Coreにデータ送信を制限するロジックを組み込むことができます。
  • Lambda関数は、デバイスのシリアル番号を検証し、インストール前に不正なデバイスからのデータ送信を防ぎます。

方法2: Step Functionsを使用したワークフロー管理

  • 複雑なデバイス管理のフローをAWS Step Functionsを使用して定義できます。これにより、複数のプロセスを順序立てて実行し、デバイスがインストールされるタイミングでのみAWS IoT Coreに登録が行われるようにできます。

4. 自動登録と管理

AWS IoT Coreでは、自動登録機能を使って新しいデバイスの登録プロセスを自動化できます。この方法では、センサーがインストールされると、デバイスの証明書を自動的に有効化し、AWS IoT Coreに登録します。
  • allow-auto-registrationパラメータ: この設定を使用することで、デバイスがインストールされるまで自動的に登録を無効化し、インストール後にのみデータ送信が許可されます。

5. ベストプラクティス

AWSでIoTデバイスを安全かつ効率的に管理するためのベストプラクティスには以下が含まれます：
  • セキュアな証明書の管理: 証明書は暗号化して保存し、管理する必要があります。証明書のローテーションや失効管理も重要です。
  • デバイス認証とアクセス管理: IAMポリシーを活用して、デバイスがアクセスできるリソースを制限します。
  • 監視とロギング: AWS CloudWatchやAWS IoT Device Defenderを使用して、デバイスのアクティビティやセキュリティインシデントを監視します。

まとめ

IoTデバイスのセキュアな接続と管理には、AWS IoT Coreと適切な認証機構を利用することが重要です。センサーがインストールされる前にデータ送信を制限するためには、Lambda関数や自動登録機能を利用し、プロビジョニングフローを適切に設定することが求められます。これにより、センサーがインストールされた後にのみデータ送信が許可され、セキュアな環境でのIoTシステム運用が実現できます。

実践

略

一問道場

問題 #414
小売業の会社が、世界中のすべての店舗にIoTセンサーを取り付けています。各センサーの製造中に、会社のプライベート証明書認証局（CA）が一意のシリアル番号を含むX.509証明書を発行します。会社はその後、各証明書をそれぞれのセンサーに展開します。
ソリューションアーキテクトは、センサーがインストールされた後にAWSにデータを送信できるようにする必要があります。センサーはインストールされるまで、AWSにデータを送信できないようにする必要があります。
どのソリューションがこれらの要件を満たしますか？
A. シリアル番号を検証できるAWS Lambda関数を作成します。AWS IoT Coreプロビジョニングテンプレートを作成します。パラメータセクションにSerialNumberパラメータを含めます。Lambda関数を事前プロビジョニングフックとして追加します。製造中に、RegisterThing API操作を呼び出し、テンプレートとパラメータを指定します。
B. シリアル番号を検証できるAWS Step Functionsステートマシンを作成します。AWS IoT Coreプロビジョニングテンプレートを作成します。パラメータセクションにSerialNumberパラメータを含めます。パラメータを検証するためにStep Functionsステートマシンを指定します。インストール時にStartThingRegistrationTask API操作を呼び出します。
C. シリアル番号を検証できるAWS Lambda関数を作成します。AWS IoT Coreプロビジョニングテンプレートを作成します。パラメータセクションにSerialNumberパラメータを含めます。Lambda関数を事前プロビジョニングフックとして追加します。CAをAWS IoT Coreに登録し、プロビジョニングテンプレートを指定してallow-auto-registrationパラメータを設定します。
D. AWS IoT Coreプロビジョニングテンプレートを作成します。パラメータセクションにSerialNumberパラメータを含めます。テンプレート内でパラメータ検証を含めます。CAを使用して各デバイスに対してクレーム証明書と秘密鍵を発行します。AWS IoT Coreサービスに、プロビジョニング中にAWS IoT Thingを更新する権限を付与します。

解説

この問題では、IoTセンサーがインストールされる前にAWSへのデータ送信を制限し、インストール後にデータ送信を許可するための適切なソリューションを選ぶことが求められています。それぞれの選択肢を詳しく解説します。

オプションA: Lambda関数とプロビジョニングテンプレート

  • 内容: シリアル番号を検証できるLambda関数を作成し、AWS IoT CoreプロビジョニングテンプレートにSerialNumberパラメータを追加します。Lambda関数を事前プロビジョニングフックとして使用し、製造中にRegisterThing APIを呼び出します。
  • 評価:
    • Lambda関数を使ってシリアル番号を検証することは適切です。
    • RegisterThing APIは、デバイスの登録を行うために使われますが、インストールされる前にデータ送信を制限することには適していません。製造中にデバイスを登録することは、インストール前にデータ送信を制限する要件に合致しません。
    • 不適切な選択肢: 登録段階でインストール後のデータ送信の制御には不十分です。

オプションB: Step Functionsとプロビジョニングテンプレート

  • 内容: Step Functionsステートマシンでシリアル番号を検証し、AWS IoT Coreプロビジョニングテンプレートを使ってSerialNumberパラメータを含めます。インストール時にStartThingRegistrationTask APIを呼び出します。
  • 評価:
    • Step Functionsを使うことで、複雑な処理や条件に基づくフローを実現できますが、この方法ではインストール前にデータ送信を制限する機能が不足しています。
    • StartThingRegistrationTaskは、デバイス登録プロセスを開始しますが、インストール前にデータ送信を制限する要件には合いません。
    • 不適切な選択肢: こちらもインストール前のデータ送信制限に対して十分ではありません。

オプションC: Lambda関数とプロビジョニングテンプレート + CA登録

  • 内容: シリアル番号を検証するLambda関数を使い、AWS IoT Coreプロビジョニングテンプレートを作成。SerialNumberパラメータを含め、Lambda関数を事前プロビジョニングフックとして追加します。CAをAWS IoT Coreに登録し、allow-auto-registrationパラメータを設定します。
  • 評価:
    • Lambda関数でシリアル番号を検証する方法は正しいアプローチです。
    • allow-auto-registrationの設定により、センサーがインストールされるタイミングでのみAWS IoT Coreに自動登録されるようにできます。これにより、インストール前にデータ送信を制限することが可能になります。
    • 適切な選択肢: これが最も要件に合致しています。

オプションD: プロビジョニングテンプレートとCAの使用

  • 内容: プロビジョニングテンプレートにSerialNumberパラメータを含め、テンプレート内でパラメータ検証を行います。CAを使って証明書を発行し、AWS IoT Coreにデバイスを登録します。
  • 評価:
    • この選択肢では、証明書発行や登録が行われますが、インストール前にデータ送信を制限するメカニズムが不足しています。
    • 具体的に、インストールされる前にデータ送信を制限するためのフックや設定が不足しており、要件に完全には適合しません。
    • 不適切な選択肢: インストール前のデータ送信制限には不十分です。

結論:

オプションCが最適な選択肢です。Lambda関数を用いてシリアル番号を検証し、インストール前にデータ送信を制限するためにallow-auto-registrationパラメータを活用する方法が、要件を最も効果的に満たします。
  • センサーがインストールされる前:
    • allow-auto-registrationが無効化（false）の場合、デバイスは自動的にAWS IoT Coreに登録されません。この設定が無効の場合、センサーがインストールされても、デバイスは自動的に登録されず、手動で登録する必要があります。
  • センサーがインストールされる後:
    • allow-auto-registrationが有効化（true）の場合、インストールされたデバイスが、事前に設定された証明書を使用してAWS IoT Coreに接続すると、自動的に登録が行われます。この場合、証明書やシリアル番号が正当なものであれば、デバイスは自動的にAWS IoT Coreに登録され、その後AWSにデータを送信できるようになります。
 
 

415-AWS SAP AWS 「理論・実践・一問道場」AWS CodeDeploy

 

理論

Jenkinsは、ソフトウェア開発のプロセスを自動化するためのオープンソースツールです。主に以下の機能を提供します：
  1. 自動ビルド: コード変更をトリガーに自動でビルドを実行。
  1. 自動テスト: ビルド後に自動でテストを実行。
  1. 継続的インテグレーション（CI）: コードを早期に統合してバグを発見。
  1. 継続的デリバリー（CD）: 成功したビルドを自動でデプロイ。
また、多数のプラグインを使って様々なツールと統合でき、効率的な開発とデリバリーを支援します。

GitHubとAWS CodePipeline

AWSとGitHubは、ソフトウェア開発の自動化を効率化するために強力な統合を提供しています。以下に、GitHubとAWS CodePipeline、AWS CodeDeployを使用するための重要なコンセプトを説明します。

1. GitHubとAWS CodePipelineの統合

AWS CodePipelineは、コードのビルド、テスト、デプロイのプロセスを自動化するための完全マネージド型のサービスです。GitHubはコードのバージョン管理を行うために非常に人気のあるプラットフォームで、AWSと統合することができます。
  • GitHub Webhooks: GitHubリポジトリの変更（コミット、プルリクエストなど）をAWS CodePipelineに通知するためには、GitHubのWebhook機能を使用します。Webhookは、特定のイベントが発生した際に指定されたURLに通知を送る仕組みです。GitHubからのWebhook通知は、AWS CodePipelineのパイプラインをトリガーするために使用されます。
  • GitHub Integration in CodePipeline: AWS CodePipelineでは、ソースプロバイダーとしてGitHubを直接利用できます。これにより、GitHubでコードが更新されるたびに、パイプラインが自動的に起動し、ビルド、テスト、デプロイのプロセスが実行されます。

2. AWS CodeDeployによるデプロイメント戦略

AWS CodeDeployは、アプリケーションを自動的にデプロイし、更新するためのサービスです。CodeDeployでは、異なるデプロイメント戦略を選択することができ、ダウンタイムなしで変更を適用することが可能です。
  • 青/緑デプロイメント（Blue/Green Deployment）:
    • 青/緑デプロイメントは、ダウンタイムを最小限に抑え、トラフィックを新しい環境（緑）に切り替える前に、現在の環境（青）を稼働させたままテストを行う手法です。もし新しい環境に問題が発生した場合、トラフィックをすぐに元の環境（青）に戻すことができるため、迅速なロールバックが可能です。
    • この戦略は、リスクの低減とユーザーへの影響を最小限にするため、非常に重要です。
  • インプレースデプロイメント:
    • インプレースデプロイメントは、既存の環境に対して直接変更を加える方法です。この方法では、全てのインスタンスに対して同時に変更が適用されるため、ダウンタイムが発生する可能性が高く、ロールバックが難しい場合があります。
    • 大規模なアプリケーションにおいては、インプレースデプロイメントが失敗した場合の影響が大きいため、青/緑デプロイメントが推奨されます。

3. AWS CodeBuildによるビルドとテストの自動化

AWS CodeBuildは、ソースコードをビルドし、テストを自動化するサービスです。GitHubリポジトリからソースコードを取り込み、JenkinsなどのCIツールと連携することができます。
  • JenkinsとAWS CodeBuildの統合: Jenkinsは、コードのビルド、テスト、デプロイを自動化するために非常に人気のあるツールです。AWS CodeBuildはJenkinsと連携し、ビルドジョブをAWSクラウドで実行できます。これにより、リソースのスケーリングが自動的に行われ、柔軟で効率的なビルドプロセスが可能になります。

4. SNS通知でのアラート設定

  • Amazon SNS（Simple Notification Service）: Amazon SNSは、メッセージングサービスであり、異常事態の発生時に開発者に通知を送るために使用できます。ビルドが失敗した場合や、デプロイが正常に完了したかどうかを通知するためにSNSを利用します。SNSは、Eメール、SMS、アプリケーションなど複数のチャネルを介して通知を配信することができます。

5. CI/CDの自動化による効果

  • DevOpsとCI/CDのプラクティス:
    • *CI（継続的インテグレーション）とCD（継続的デリバリー）**は、ソフトウェア開発のプロセスを自動化するための重要なプラクティスです。CodePipelineとCodeBuildを使用することで、コードの変更が即座にビルドおよびテストされ、エラーが早期に発見されます。
    • ダウンタイムなしでのデプロイは、ユーザー体験を損なうことなく、常に最新のコードを稼働させるために不可欠です。青/緑デプロイメントを活用することで、トラフィックが新しいバージョンにシームレスに切り替わります。

結論

GitHub、AWS CodePipeline、AWS CodeDeploy、AWS CodeBuildなどのツールを組み合わせることで、コードの管理からビルド、テスト、デプロイまでの一連のプロセスを効率的に自動化できます。これにより、ダウンタイムのないデプロイや迅速なロールバックが可能となり、ユーザーへの影響を最小限に抑えつつ、高品質なソフトウェアの提供が可能となります。

実践

 
略

一問道場

質問 #415
あるスタートアップ企業が、最近大規模なeコマースウェブサイトをAWSに移行しました。その結果、ウェブサイトの売上は70%増加しました。ソフトウェアエンジニアは、コードを管理するためにプライベートなGitHubリポジトリを使用しています。DevOpsチームは、ビルドと単体テストにJenkinsを使用しています。エンジニアは、ビルドに失敗した場合の通知を受け取り、デプロイメント中のダウンタイムをゼロにする必要があります。また、エンジニアは本番環境への変更がシームレスに行われ、重大な問題が発生した場合にロールバックできるようにする必要があります。ソフトウェアエンジニアは、AWS CodePipelineを使用してビルドおよびデプロイメントのプロセスを管理することに決めました。
どのソリューションがこれらの要件を満たしますか？
A. GitHubのWebSocketを使用してCodePipelineパイプラインをトリガーします。AWS CodeBuildのJenkinsプラグインを使用して単体テストを実施します。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、インプレースの全体展開構成でデプロイします。
B. GitHubのWebhookを使用してCodePipelineパイプラインをトリガーします。AWS CodeBuildのJenkinsプラグインを使用して単体テストを実施します。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、青/緑のデプロイメントでデプロイします。
C. GitHubのWebSocketを使用してCodePipelineパイプラインをトリガーします。AWS X-Rayを使用して単体テストと静的コード解析を行います。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、青/緑のデプロイメントでデプロイします。
D. GitHubのWebhookを使用してCodePipelineパイプラインをトリガーします。AWS X-Rayを使用して単体テストと静的コード解析を行います。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、インプレースの全体展開構成でデプロイします。

解説

この問題では、スタートアップ企業がAWSに移行したeコマースサイトでのビルドおよびデプロイメントのプロセスを効率化するための最適なソリューションを選択する必要があります。要件としては、次の点が挙げられています：
  1. GitHubでのコード管理
  1. Jenkinsによるビルドとテスト
  1. ビルドに失敗した場合の通知
  1. ダウンタイムのないデプロイメント
  1. 変更のロールバック機能
これらを満たすために必要な要素は以下の通りです。

各選択肢の分析

A. GitHubのWebSocketを使用してCodePipelineパイプラインをトリガーします。AWS CodeBuildのJenkinsプラグインを使用して単体テストを実施します。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、インプレースの全体展開構成でデプロイします。
  • WebSocket: GitHubのWebSocketは、GitHubでのイベントを監視するために使用される技術ではなく、一般的にはWebhookが使用されます。従って、この選択肢は不適切です。
  • インプレース全体展開: インプレース展開は、全てのインスタンスに同時に変更を加える方法です。この方法ではダウンタイムが発生する可能性があるため、要件を満たしません。
B. GitHubのWebhookを使用してCodePipelineパイプラインをトリガーします。AWS CodeBuildのJenkinsプラグインを使用して単体テストを実施します。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、青/緑のデプロイメントでデプロイします。
  • Webhook: GitHubのWebhookは、リポジトリでのコード変更をトリガーにAWS CodePipelineを起動するための一般的な方法です。これは正しいアプローチです。
  • 青/緑デプロイメント: 青/緑デプロイメントは、二つの異なる環境（青環境と緑環境）を使用してデプロイを行い、問題があった場合には以前の環境に戻すことができます。これにより、ダウンタイムを最小限に抑え、変更のロールバックも簡単に行えます。これが要件を満たすデプロイ方法です。
C. GitHubのWebSocketを使用してCodePipelineパイプラインをトリガーします。AWS X-Rayを使用して単体テストと静的コード解析を行います。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、青/緑のデプロイメントでデプロイします。
  • WebSocket: GitHubのWebSocketは誤りで、Webhookが正しい方法です。
  • AWS X-Ray: AWS X-Rayはアプリケーションのパフォーマンス解析ツールですが、単体テストや静的コード解析には適していません。このため、この選択肢も適切ではありません。
D. GitHubのWebhookを使用してCodePipelineパイプラインをトリガーします。AWS X-Rayを使用して単体テストと静的コード解析を行います。ビルドに失敗した場合はAmazon SNSトピックにアラートを送信します。AWS CodeDeployを使用して、インプレースの全体展開構成でデプロイします。
  • Webhook: 正しいアプローチです。
  • AWS X-Ray: 前述の通り、X-Rayは単体テストや静的コード解析には適していません。
  • インプレース全体展開: ダウンタイムが発生するため、要件に合致しません。

正しい選択肢は B

理由:
  • WebhookはGitHubのリポジトリから変更をトリガーするために最適な方法です。
  • 青/緑デプロイメントは、ダウンタイムを最小限に抑え、変更後に問題があれば簡単にロールバックできるため、この要件に完全に合致します。
 
 

416-AWS SAP AWS 「理論・実践・一問道場」RCU/WCU

 

理論

1. マルチテナント環境

  • マルチテナントとは、1つのシステムやアプリケーションインスタンスが複数の顧客（テナント）によって共有される設計モデルです。SaaS（Software as a Service）などで一般的に使われます。
  • 各テナントは独立したデータを持ちながらも、同一のインフラを共有します。このため、リソースやコストの分配方法が重要です。

2. リソース消費の追跡とコスト配分

  • リソース消費の追跡: 各テナントが使用したリソース（ストレージ、コンピューティング、APIリクエストなど）を追跡することは、コスト管理に欠かせません。これを実現する方法として、リソースごとのメトリクス（例: RCU/WCU）やタグ付け、ログの記録が使われます。
  • コスト配分タグ: AWSでは、リソースごとにコスト配分タグを設定することで、サービスの使用に基づくコストを細かく分けて追跡することができます。これにより、特定のテナントや部門ごとのコスト分析が可能になります。

3. AWSのコスト管理ツール

  • AWS Cost and Usage Report (CUR): AWSアカウント内で使用されているすべてのサービスとリソースの使用状況やコストを詳細に把握できるレポートです。これを使用することで、テナントごとのコストを分けることが可能になります。
  • AWS Lambda: イベント駆動型のコンピューティングサービスで、APIリクエストなどに応じて動的にコードを実行できます。Lambdaを使ってリソース消費の追跡を実装し、他のサービスとの連携を簡素化できます。
  • Amazon CloudWatch: サーバーレスアーキテクチャの監視とログ管理のためのサービスで、リソース使用状況やメトリクスの監視に役立ちます。CloudWatchを活用して、リソース使用量（例: RCU/WCU）を詳細に記録し、リアルタイムで監視できます。
  • AWS Cost Explorer: コスト分析と予測のためのツールで、AWSリソースの使用状況に基づいて、どのサービスやリソースが最もコストを発生させているかを視覚的に表示します。

4. 自動化の重要性

  • コスト管理とリソース追跡のプロセスを自動化することが、運用コストの削減やエラー防止に繋がります。例えば、Amazon EventBridgeを使用して定期的にLambda関数を実行し、コスト計算を自動化する方法があります。
  • サーバーレスアーキテクチャ（Lambdaなど）は、従来のインフラ管理を軽減し、リソース消費の計測やコスト計算を効率化する手段となります。

5. コスト計算のアプローチ

  • テナントごとのリソース消費を追跡する際、キャパシティユニット（RCU/WCU）やデータトランザクション、ストレージ使用量を基にコストを分配します。
  • 複雑な計算を実現するためには、適切なツールを使用して、リソースごとの詳細な分析を行う必要があります。
このような知識を基に、SaaS企業でのコスト管理を最適化し、テナントごとのコストを正確に追跡することができます。

実践

略

一問道場

質問 #416
ソフトウェア・アズ・ア・サービス（SaaS）企業がマルチテナント環境を開発しました。同社は、ストレージ層としてテナントが共有するAmazon DynamoDBテーブルを使用しています。また、アプリケーションサービスにはAWS Lambda関数を使用しています。
同社は、各テナントのリソース消費量に基づいた階層型サブスクリプションモデルを提供したいと考えています。各テナントは、Lambda関数への各リクエストの一部として送信される一意のテナントIDによって識別されます。同社はAWSアカウントでAWSコストと使用状況レポート（AWS CUR）を作成しました。また、DynamoDBのコストを各テナントのリソース消費量に応じて割り当てたいと考えています。
どのソリューションが最小の運用コストで、各テナントごとのDynamoDBコストを詳細に把握できるようにしますか？
選択肢
A. DynamoDBの各テーブルに「tenant ID」という名前の新しいタグを関連付けます。このタグをAWS課金とコスト管理コンソールでコスト配分タグとして有効化します。テナントIDをAmazon CloudWatch Logsに記録するように新しいLambda関数コードをデプロイします。AWS CURを使用して、各テナントIDのDynamoDB消費コストを分離します。
B. Lambda関数を設定して、DynamoDBから各トランザクションで消費されたRCU（読み取りキャパシティユニット）とWCU（書き込みキャパシティユニット）およびテナントIDをAmazon CloudWatch Logsに記録します。記録されたキャパシティユニットとAWS Cost Explorer APIの全体のDynamoDBコストを使用してテナントコストを計算する別のLambda関数をデプロイします。Amazon EventBridgeルールを作成し、この計算用Lambda関数を定期的に起動します。
C. DynamoDBアイテムを個々のテナントと関連付ける新しいパーティションキーを作成します。各トランザクションの一部として新しい列を入力するLambda関数をデプロイします。また、Amazon Athenaを使用してDynamoDBからテナントアイテム数を計算し、AWS CURの全体的なDynamoDBコストを使用してテナントコストを計算する別のLambda関数をデプロイします。Amazon EventBridgeルールを作成し、この計算用Lambda関数を定期的に起動します。
D. Lambda関数をデプロイして、テナントID、各レスポンスのサイズ、およびトランザクション呼び出しの期間をカスタムメトリクスとしてAmazon CloudWatch Logsに記録します。CloudWatch Logs Insightsを使用して、各テナントのカスタムメトリクスをクエリします。AWS Pricing Calculatorを使用してDynamoDB全体のコストを取得し、テナントコストを計算します。

解説

選択肢Bが適切な理由について詳しく説明します。

理由:

選択肢Bでは、DynamoDBから消費されたRCU/WCU（読み取りキャパシティユニット/書き込みキャパシティユニット）とテナントIDをCloudWatch Logsに記録し、それをもとに別のLambda関数でテナントごとのコストを計算するというアプローチです。この方法は、以下の点で優れています：
  1. リソース消費の正確な追跡: DynamoDBのキャパシティユニット（RCU/WCU）の消費をCloudWatchに記録することで、リソース消費量に基づく正確なコスト計算が可能になります。これにより、テナントごとのリソース使用量を詳細に把握できます。
  1. 自動化: 計算を自動化するために、Amazon EventBridgeルールを使って定期的にLambda関数を実行する設定が可能です。これにより、手動で計算を行う必要がなく、運用の手間が大幅に削減されます。
  1. AWS Cost Explorerとの統合: AWS Cost Explorer APIを使用して、DynamoDB全体のコストを取得し、それを基にテナントごとのコストを計算します。このように、コストデータを統合的に使用することで、全体的なコスト管理と分析が効率化されます。

他の選択肢との比較:

  • 選択肢Aも有効ですが、タグ付けとAWS CURの使用だけでは、テナントごとの詳細なリソース消費を反映することはできません。リソース消費に基づく詳細な計算が難しく、テナント別のコスト分析には不十分な場合があります。
  • 選択肢Cや選択肢Dは、AthenaやCloudWatch Logs Insightsなどを使用するため、計算やデータ処理の手間が増える可能性があり、運用コストが高くなる可能性があります。
したがって、選択肢Bは、最小の運用コストで、かつテナントごとのDynamoDBコストを詳細に把握する最適な方法と言えます。
 
 

417-AWS SAP AWS 「理論・実践・一問道場」S3漏洩

 

理論

S3バケットのデータ保護に関する重要な概念

1. S3バージョニング
  • S3バージョニングは、バケット内のオブジェクトのすべてのバージョンを保存し、誤ってデータを上書きしたり削除したりしても復元できるようにする機能です。
  • バージョニングを有効にすることで、過去のデータにアクセスでき、データ損失を防止します。
2. S3オブジェクトロック
  • S3オブジェクトロックは、オブジェクトに対して変更や削除をできなくする仕組みです。これを使用することで、データが意図しないタイミングで変更や削除されるリスクを軽減できます。
  • Retention period（保持期間）を設定することで、一定期間オブジェクトを保護し、その期間内に削除されないようにします。
3. MFA Delete
  • MFA Delete（多要素認証削除）は、S3バケット内のオブジェクトを削除する際に、MFA（多要素認証）を要求するセキュリティ機能です。これにより、誤った削除や不正な削除を防ぐことができます。
4. S3ライフサイクルルール
  • S3ライフサイクルルールを使用すると、オブジェクトの保存期間を設定して自動的に削除したり、他のストレージクラスに移行したりすることができます。
  • 例えば、データを一定期間保存した後に削除するルールを作成することができます。
5. S3バケットのセキュリティ管理
  • AWS IAM（Identity and Access Management）を使用して、S3バケットへのアクセス権限をきめ細かく設定することができます。
  • 役割ベースのアクセス制御（RBAC）を使用して、特定のユーザーやロールにアクセスを制限し、必要最低限の権限を付与します。
6. AWS Configと監視
  • AWS Configは、リソースの設定や変更を追跡するサービスです。バージョニングやMFA削除が適用されていないバケットを自動的に修復するためのルールを設定できます。
  • Amazon GuardDutyは、AWSアカウントのセキュリティ監視サービスで、S3に対する不正アクセスのリスクを検出します。

最適なデータ保護戦略

  • データ保護には、単一の対策に依存するのではなく、複数のレイヤーで対策を講じることが重要です。バージョニングやオブジェクトロックを組み合わせ、削除や変更が意図しないタイミングで行われないようにします。
  • MFA削除や、バージョニングの組み合わせは、データを誤って削除するリスクを大幅に減らします。

実践的なポイント

  • S3バケットのセキュリティ強化: バケット作成時にS3バージョニングとオブジェクトロックを強制する設定を導入し、データの変更・削除を防ぐ。
  • アクセス制御: IAMポリシーを使用して、特定のユーザーだけがデータにアクセスできるようにする。特に、重要なデータには厳格なアクセス権限を設定します。
このようなセキュリティ対策を実装することで、S3バケット内のデータを安全に保護し、長期的なデータ保持ポリシーを確実に実行できます。

実践

略

一問道場

質問 #417
ある会社には、データを単一のAmazon S3バケットに保存するアプリケーションがあります。会社はすべてのデータを1年間保持する必要があります。会社のセキュリティチームは、攻撃者が漏洩した長期的な認証情報を通じてAWSアカウントにアクセスできる可能性があることを懸念しています。
どのソリューションが、S3バケット内の既存および今後のオブジェクトを保護することを保証しますか？
選択肢
A. 新しいAWSアカウントを作成し、セキュリティチームのみがロールを引き受けてアクセスできるようにします。新しいアカウントにS3バケットを作成します。S3バージョニングとS3オブジェクトロックを有効にし、1年間のデフォルト保持期間を設定します。既存のS3バケットから新しいS3バケットにレプリケーションを設定します。S3バッチレプリケーションジョブを作成して、すべての既存データをコピーします。
B. s3-bucket-versioning-enabled AWS Configマネージドルールを使用します。AWS Lambda関数を使用して、S3バージョニングとMFA削除を有効にする自動修復アクションを構成します。S3ライフサイクルルールを追加して、1年後にオブジェクトを削除します。
C. すべてのユーザーおよびロールからバケット作成を明示的に拒否し、AWSサービスカタログの起動制約ロールのみに許可します。S3バケットの作成のためにサービスカタログ製品を定義し、S3バージョニングとMFA削除を強制します。ユーザーがS3バケットを作成する必要がある場合、製品を起動できるように権限を付与します。
D. アカウントおよびAWSリージョンにAmazon GuardDutyを有効にし、S3保護機能を使用します。S3ライフサイクルルールを追加して、1年後にオブジェクトを削除します。

解説

この問題は、S3バケット内のデータを1年間保持し、セキュリティを強化する方法について尋ねています。セキュリティチームは、長期的な認証情報が漏洩した場合のリスクを懸念しています。
以下、選択肢ごとの正確な解説です。

選択肢 A

新しいAWSアカウントを作成し、S3バージョニングとS3オブジェクトロックを有効にして1年間の保持を設定する方法です。
  1. 新しいAWSアカウントを作成し、セキュリティチームのみがアクセス可能にします。
  1. 新しいアカウント内で、S3バージョニングとS3オブジェクトロックを有効にし、データが誤って削除されないように保護します。
  1. 1年間のデフォルト保持期間を設定し、既存のS3バケットから新しいS3バケットにレプリケーションを設定してデータをコピーします。
解説:
  • S3バージョニングは、オブジェクトのすべてのバージョンを保存する機能で、誤ってデータが上書きされたり削除されても復元可能です。
  • S3オブジェクトロックは、オブジェクトを変更・削除できないようにロックする機能で、特にセキュリティが重要なデータに対して有効です。
  • 新しいアカウントを作成することで、セキュリティチーム以外のアクセスを制限できます。
この方法は、データ保護の強度が高く、最も堅牢なソリューションです。

選択肢 B

AWS Configを使用して、バージョニングが有効でないS3バケットに対して自動的に修復を行う方法です。
  1. AWS Configでs3-bucket-versioning-enabledルールを有効にし、バージョニングが無効なバケットを監視します。
  1. AWS Lambda関数を使用して、バージョニングを有効にし、MFA削除（多要素認証を必要とする削除）を設定します。
  1. S3ライフサイクルルールを追加し、1年後にオブジェクトを削除します。
解説:
  • AWS Configを使用して、バージョニングが無効なS3バケットを自動的に修復できます。
  • MFA削除を設定することで、誤った削除を防止できますが、オブジェクトロックのような強力な保護は提供しません。
  • ライフサイクルルールは、1年後にオブジェクトを削除することができますが、削除を防ぐ仕組み（オブジェクトロック）を欠いています。
この方法は、バージョニングが無効な場合に修復を行う手段としては有効ですが、選択肢Aに比べると保護が弱く、追加の保護手段が必要です。

選択肢 C

AWSサービスカタログを使用して、バケット作成時にS3バージョニングとMFA削除を強制する方法です。
  1. バケット作成を制限し、AWSサービスカタログを通じてS3バケットを作成させます。
  1. サービスカタログで定義した製品を使い、S3バージョニングとMFA削除を強制します。
解説:
  • この方法では、バケット作成時の設定を強制することができますが、データ保護（オブジェクトロックなど）に関する仕組みは含まれていません。
  • MFA削除は、削除操作に対してセキュリティを強化しますが、オブジェクトの誤削除を防ぐためのオブジェクトロック機能は提供しません。
この方法は、S3バケットを作成するプロセスに制限をかけることはできますが、データ保護に関する強力な機能は不足しています。

選択肢 D

Amazon GuardDutyを有効にして、S3保護機能を使用する方法です。
  1. Amazon GuardDutyを有効にし、S3保護機能を使って不正アクセスを検出します。
  1. S3ライフサイクルルールを追加して、1年後にオブジェクトを削除します。
解説:
  • Amazon GuardDutyはセキュリティサービスで、S3への不正アクセスや攻撃を検出するのに役立ちますが、データ保持や削除防止には関与しません。
  • ライフサイクルルールを使用してオブジェクトを削除できますが、オブジェクトロックやバージョニングのような直接的なデータ保護機能は提供しません。
この方法は、セキュリティの監視には有効ですが、データ保護や保持に関する要件を満たすには不十分です。

結論

最も適切な選択肢はAです。この方法は、S3バージョニングとオブジェクトロックを使用してデータの変更や削除を防ぎ、1年間のデータ保持を保証します。また、新しいアカウントを作成してアクセス制限を強化するため、セキュリティ面でも最も堅牢なアプローチです。
 
 

418-AWS SAP AWS 「理論・実践・一問道場」JWT

 

理論

notion image

1. Amazon API Gateway と認証

  • API Gatewayでは、認証を強制するために、JWT（JSON Web Token）を使用する認証方式がよく利用されます。JWTは、ユーザーが認証されると、トークンを発行し、そのトークンをAPI Gatewayに渡すことで認証が完了します。
  • API Gatewayの認証方法：
    • JWT認証（カスタムオーソライザー）：外部のIDプロバイダー（OIDC、Cognitoなど）と連携し、トークンを検証します。
    • IAMポリシー：リクエストをIAM認証を通じて制御します。
    • Amazon Cognito：Cognitoユーザープールを使用して、アプリケーションのユーザー管理を行います。

2. Amazon Application Load Balancer（ALB）と認証

  • ALBは、ロードバランサーとしての機能を提供しますが、デフォルトでは認証を強制しません。ALBに認証を追加するためには、ALBをIDプロバイダー（例えば、Cognito、OIDC）と統合して認証を行う必要があります。
  • ALBの認証設定：
    • ALBは、AWS CognitoやOIDCと連携して認証を行うことができます。これにより、ALBが受け付けるリクエストに認証を要求し、未認証のリクエストをブロックできます。

3. Amazon CloudFrontと署名付きURL

  • CloudFrontはコンテンツ配信ネットワーク（CDN）として、リクエストに対する認証を行うために署名付きURLや署名付きクッキーを使用することができます。
  • 署名付きURLは、特定のリソースへのアクセスを制限するために使用され、期限付きでアクセスを許可することができますが、これ自体は認証ではなく、リクエストのアクセス許可を制御する手段です。

4. AWS WAFとセキュリティ

  • AWS WAF（Web Application Firewall）は、ウェブアプリケーションに対するリクエストをフィルタリングするために使用しますが、WAF自体には認証機能はありません。WAFは主に、IP制限やSQLインジェクション攻撃、クロスサイトスクリプティング（XSS）などからの防御に役立ちます。
  • WAFは、認証されていないリクエストをフィルタリングすることはできませんが、ALBやAPI Gatewayで認証を行った後、WAFで不正なリクエストをブロックすることは可能です。

5. AWS CloudTrailと監査

  • AWS CloudTrailは、AWSアカウント内で発生したAPIコールの監査ログを記録するサービスです。CloudTrailはリクエストの追跡や監査に便利ですが、リアルタイムで認証をブロックすることはできません。CloudTrailのログを使用して、後から問題を特定することは可能ですが、認証の強制にはAPI GatewayやALBでの認証機能が必要です。

まとめ

  • API GatewayとALBの認証を強制するには、API GatewayでJWTやCognitoを使った認証を設定し、ALBを適切なIDプロバイダーと統合して認証を行う必要があります。
  • CloudFrontの署名付きURLはアクセス制限には使えますが、認証そのものには使えません。
  • AWS WAFは、認証後の不正リクエストをブロックするのに有用ですが、認証を強制する機能はありません。
  • CloudTrailは監査ログの管理に有用ですが、認証のブロックには直接関与しません。
このように、AWSでは様々なセキュリティツールや機能を組み合わせて、認証やアクセス制御を行うことが求められます。

実践

略

一問道場

質問 #418
ある企業は、AWS上でのWebアプリケーションのセキュリティを強化する必要があります。アプリケーションは、2つのカスタムオリジンを使用してAmazon CloudFrontを利用しています。最初のカスタムオリジンはAmazon API Gateway HTTP APIへのリクエストをルーティングし、2番目のカスタムオリジンはトラフィックをアプリケーションロードバランサー(ALB)にルーティングします。アプリケーションは、ユーザー管理のためにOpenID Connect (OIDC)アイデンティティプロバイダー(IdP)と統合しています。セキュリティ監査では、JSON Web Token(JWT)認証がAPIへのアクセスを提供していることが確認されました。また、セキュリティ監査では、ALBが認証されていないユーザーからのリクエストを受け入れていることも判明しました。
ソリューションアーキテクトは、すべてのバックエンドサービスが認証されたユーザーにのみ応答するようにするためのソリューションを設計しなければなりません。
この要件を満たすソリューションはどれですか？
A. ALBをIdPと統合し、認証と認可を強制するようにALBを構成します。認証されたユーザーのみがバックエンドサービスにアクセスできるようにします。
B. CloudFrontの設定を変更して署名付きURLを使用します。バックエンドサービスへのアクセスを許可する寛容な署名ポリシーを実装します。
C. ALBレベルで認証されていないリクエストをフィルタリングするAWS WAFウェブACLを作成します。認証されたトラフィックのみがバックエンドサービスに到達するようにします。
D. AWS CloudTrailを有効にして、ALBに来るすべてのリクエストをログに記録します。AWS Lambda関数を作成してログを解析し、認証されていないユーザーからのリクエストをブロックします。

解説

問題の要点

  • 企業がAWS上でWebアプリケーションを運用しており、Amazon CloudFrontを使って2つのカスタムオリジンを設定しています。
      1. API Gateway HTTP API（カスタムオリジン1）
      1. Application Load Balancer (ALB)（カスタムオリジン2）
  • アプリケーションは、**OpenID Connect (OIDC)**を使ってユーザー認証を行っています。
  • セキュリティ監査の結果：
    • API GatewayはJWT認証を使って認証されたユーザーのみアクセスを許可している。
    • しかし、ALBは認証されていないユーザーからのリクエストも受け入れてしまっている。

問題文で求められていること

  • バックエンドサービス（API GatewayとALB）が、認証されたユーザーのみに応答するようにする必要がある。
  • ALBが認証されていないユーザーからのリクエストを受け入れないようにする必要があります。

各選択肢の解説

  1. A. ALBをIdPと統合し、認証と認可を強制するようにALBを構成
      • 正しい選択肢です。ALBはデフォルトでは認証を強制しませんが、IdPと統合して認証と認可を実施することが可能です。これにより、ALBは認証されたユーザーからのみリクエストを受け入れるようになります。この方法が最も適切で、要件を満たします。
  1. B. CloudFrontの設定を変更して署名付きURLを使用
      • 署名付きURLは、CloudFront経由でアクセスを制御するために使用できますが、この方法では認証の強制ができません。署名付きURLは、あくまでURLアクセスの有効期限を制御するもので、ユーザー認証を強制するものではないため、問題の要件を満たしません。
  1. C. AWS WAFウェブACLを使用してALBレベルで認証されていないリクエストをフィルタリング
      • 誤りです。AWS WAF（Web Application Firewall）は、リクエストをフィルタリングするために使いますが、WAF自体に「認証」の機能はありません。WAFは、特定のIPアドレスやパターンに基づいてリクエストをブロックできますが、認証に関する設定はAPI GatewayやALBで行うべきです。
  1. D. AWS CloudTrailを有効にして、ALBに来るリクエストをログに記録し、Lambdaで解析して認証されていないリクエストをブロック
      • CloudTrailはAPIコールのログを記録するツールですが、リクエストの実行時に認証をブロックするわけではありません。CloudTrailとLambdaで後から分析することはできますが、リアルタイムでリクエストを防ぐためには適切な認証機能がALBまたはAPI Gatewayに必要です。したがって、実際の問題には不十分な方法です。

結論

最も適切な解決策はAです。ALBに認証を統合することで、認証されたユーザーだけがバックエンドサービスにアクセスできるようになります。この方法が要件に最も合致します。
 
 

419-AWS SAP AWS 「理論・実践・一問道場」AWS Security Hub

 

理論

1. AWS Security Hub

  • 概要: AWS Security Hubは、AWS全体のセキュリティ状況を集中的に管理および監視するためのサービスです。複数アカウントやリージョンにわたってセキュリティ情報を集約し、可視化します。セキュリティのベストプラクティスや脆弱性の評価を行い、リスクを管理するための統一的なダッシュボードを提供します。
  • 特徴:
    • AWS Organizationsを使用して複数アカウントを一元的に管理できる。
    • セキュリティチェックリストやベストプラクティスの実行状況をリアルタイムで把握。
    • 他のAWSサービス（GuardDuty, Inspector, Macieなど）と統合してセキュリティの監視を行う。
    • セキュリティイベントをリアルタイムでアラートとして受け取ることができる。

2. AWS Config

  • 概要: AWS Configは、AWSリソースの設定を追跡、評価、監視するサービスです。コンフォーマンスパックを使用して、特定のセキュリティやコンプライアンス基準に対するリソースの遵守状態を確認できます。リソースの変更履歴や設定の違反を監視し、リスクを管理します。
  • 特徴:
    • リソースの設定と変更履歴を追跡。
    • コンフォーマンスパックを使用して特定のポリシーを適用。
    • セキュリティ監査やコンプライアンスチェックを行い、違反を検出して通知。

3. Amazon GuardDuty

  • 概要: Amazon GuardDutyは、脅威検出サービスで、AWS環境内で発生した悪意のある活動や不審な動きをリアルタイムで検出します。これにより、セキュリティチームはインシデント対応を迅速に行うことができます。
  • 特徴:
    • 機械学習を使用して異常なネットワークアクティビティやアカウントの異常な動作を検出。
    • 他のAWSサービス（CloudTrail、VPC Flow Logsなど）からのログを解析し、脅威を特定。
    • 自動化されたレスポンスをトリガーして迅速に対応。

4. AWS CloudTrail

  • 概要: AWS CloudTrailは、AWSアカウントでのAPIリクエストのログを記録するサービスです。セキュリティ監査や運用のトラブルシューティングに役立ちます。すべてのAPI呼び出しが記録され、異常なアクティビティの追跡が可能です。
  • 特徴:
    • リアルタイムでのAPIアクションの記録。
    • 不審な活動や誤った設定を発見するための監査機能。
    • 監査証跡の保存と分析が可能。

5. AWS Organizations

  • 概要: AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。セキュリティやコンプライアンスの管理を組織全体で統一的に行うことができます。ポリシーの管理やリソースの集中的な管理が可能です。
  • 特徴:
    • 組織内で一貫性のあるセキュリティ設定を適用。
    • アカウントの管理や権限設定を効率化。
    • 複数アカウントにわたるセキュリティリソースの統一的な適用が可能。

6. Amazon Inspector

  • 概要: Amazon Inspectorは、AWSのインフラおよびアプリケーションのセキュリティ評価サービスです。脆弱性をスキャンし、セキュリティのリスクを特定します。
  • 特徴:
    • インスタンスの脆弱性や設定ミスをスキャン。
    • 自動化されたセキュリティ評価と推奨される対策の提供。
これらのツールを組み合わせて、AWS環境のセキュリティを包括的に監視し、リスクを低減することが可能です。特にAWS Security Hubは、複数アカウントでのセキュリティ状態を一元的に管理するために非常に有効です。

実践

略

一問道場

質問 #419
ある企業が、複数アカウントのAWS環境を管理および統治するためにAWS Control Towerランディングゾーンを作成しました。セキュリティチームは、すべてのアカウントでAWSサービスを監視するために予防的制御と検出的制御を展開します。セキュリティチームは、すべてのアカウントのセキュリティ状態の集中管理を必要としています。
この要件を満たすソリューションはどれですか？
A. AWS Control Tower管理アカウントから、AWS CloudFormation StackSetsを使用してAWS Configコンフォーマンスパックをすべてのアカウントに展開する。
B. AWS OrganizationsでAmazon Detectiveを有効にし、1つのAWSアカウントをDetectiveの委任管理者として指定する。
C. AWS Control Tower管理アカウントから、AWS CloudFormationスタックセットをデプロイして、組織全体でAmazon Detectiveを有効にする自動デプロイメントオプションを使用する。
D. AWS OrganizationsでAWS Security Hubを有効にし、1つのAWSアカウントをSecurity Hubの委任管理者として指定する。

解説

この問題は、複数のAWSアカウントにわたってセキュリティ状態を集中管理し、セキュリティ監視を行いたいという要件に対する解決策を選ぶものです。各選択肢について詳しく解説します。

選択肢 A

AWS Control Tower管理アカウントから、AWS CloudFormation StackSetsを使用してAWS Configコンフォーマンスパックをすべてのアカウントに展開する。
  • 解説: AWS Configはリソースの設定を追跡し、評価できるサービスです。コンフォーマンスパックを使って、AWSアカウントにセキュリティルールを適用し、監視することができます。
  • ただし、AWS Control Towerでは、AWS Configのコンフォーマンスパックを展開するために、通常、手動で設定やリソースを管理することが必要です。この方法では、セキュリティ状態の集中管理が効率的に行えない可能性があります。

選択肢 B

AWS OrganizationsでAmazon Detectiveを有効にし、1つのAWSアカウントをDetectiveの委任管理者として指定する。
  • 解説: Amazon Detectiveは、セキュリティインシデントを調査するために使用されるサービスで、イベントやアクティビティを可視化し、調査を支援します。しかし、Detectiveは、セキュリティ状態の全体的なモニタリングには適していません。主にインシデント対応のためのツールであり、セキュリティ状態の包括的な監視や評価を行うためのツールではないため、この選択肢は要件を完全に満たしていません。

選択肢 C

AWS Control Tower管理アカウントから、AWS CloudFormationスタックセットをデプロイして、組織全体でAmazon Detectiveを有効にする自動デプロイメントオプションを使用する。
  • 解説: この選択肢では、CloudFormation StackSetsを使用してAmazon Detectiveを自動的に全アカウントに展開することを提案しています。ですが、先述の通り、Detectiveはセキュリティ状態の監視には最適なツールではなく、セキュリティの集中管理には向いていません。従って、この解決策も要件に合致しません。

選択肢 D

AWS OrganizationsでAWS Security Hubを有効にし、1つのAWSアカウントをSecurity Hubの委任管理者として指定する。
  • 解説: AWS Security Hubは、AWSのセキュリティ状態を集中的に監視・管理するサービスです。Security Hubを利用すると、複数アカウントでのセキュリティインシデントを集中管理し、リスクを評価できます。また、Security HubはAWS Organizationsを通じて組織全体で有効にでき、セキュリティ状態を一元的に把握できます。このサービスはセキュリティ監視に最適で、他の選択肢よりも明確に要件を満たします。

結論

最適な解決策は 選択肢 D です。AWS Security Hubは、全アカウントのセキュリティ状態を集中監視できるため、セキュリティチームがAWS環境全体を効果的に管理するために最も適切なツールです。
 
 

420-AWS SAP AWS 「理論・実践・一問道場」AWS DataSyncエージェント

 

理論

1. AWS DataSync

AWS DataSyncは、オンプレミスのストレージからAWSクラウドストレージ（S3など）へのデータ転送を簡素化するサービスです。大量のデータを高速に転送でき、転送中の暗号化を自動で行います。さらに、転送の自動化も可能で、運用負担を減らします。
  • 主な利点:
    • 大量データの高速転送
    • 自動暗号化
    • 転送の自動化
    • 最適化されたネットワーク利用

2. AWS Snowball

AWS Snowballは、データ転送が非常に大きく、ネットワーク経由で転送するには非効率な場合に使用する物理デバイスです。デバイスを使用してデータを転送するため、大規模データ移行に適していますが、日常的な自動データ転送には向きません。

3. Amazon S3 Transfer Acceleration

S3 Transfer Accelerationは、ネットワークの帯域幅が限られている場合にS3へのデータ転送速度を向上させるための機能です。ただし、Transfer Accelerationは大規模な一括転送には最適でない場合があり、特に既存データと新規データの定期的な転送が必要な場合には、AWS DataSyncの方が適しています。

4. Site-to-Site VPNとS3 API

VPNを使用してデータをS3に転送する方法もありますが、帯域幅や速度の制約から、大量データの転送には不向きです。特に60TBのデータを転送する場合、AWS DataSyncなど、専用のデータ転送サービスを利用した方が効率的です。

結論

大量のデータを自動的に、かつ暗号化しながら転送するためには、AWS DataSyncが最適な選択です。

実践

略

一問道場

問題 #420
ヨーロッパとアジアにオフィスを持つ消費者向け電子機器を開発している会社があります。この会社は、ヨーロッパのオンプレミスに60 TBのソフトウェア画像を保管しています。会社は、これらの画像をap-northeast-1リージョンのAmazon S3バケットに転送したいと考えています。新しいソフトウェア画像は毎日作成され、転送中に暗号化される必要があります。会社は、すべての既存および新しいソフトウェア画像を自動的にAmazon S3に転送するためにカスタム開発を必要としない解決策を求めています。
転送プロセスの次のステップは何ですか？
A. AWS DataSyncエージェントを展開し、タスクを構成して画像をS3バケットに転送する。
B. Amazon Kinesis Data Firehoseを構成して、S3 Transfer Accelerationを使用して画像を転送する。
C. AWS Snowballデバイスを使用して、S3バケットをターゲットとして画像を転送する。
D. Site-to-Site VPN接続を介してS3 APIを使用し、マルチパートアップロードで画像を転送する。

解説

この問題では、ヨーロッパから日本のリージョン（ap-northeast-1）への60 TBのソフトウェア画像を転送する方法について尋ねられています。転送中に画像が暗号化される必要があり、カスタム開発を必要としない解決策を求めています。
各選択肢についての解説は以下の通りです：

A. AWS DataSyncエージェントを展開し、タスクを構成して画像をS3バケットに転送する。

最適解
AWS DataSyncは、大量のデータをオンプレミスからAWSのストレージサービス（Amazon S3など）に転送するためのサービスです。DataSyncは、転送中にデータを自動的に暗号化し、転送のスピードと効率性を向上させるために最適化されています。また、DataSyncは既存のデータと新しいデータの転送を自動化できるため、手動で開発する必要はありません。この選択肢は、指定された要件に合った最適な解決策です。

B. Amazon Kinesis Data Firehoseを構成して、S3 Transfer Accelerationを使用して画像を転送する。

不適切
Amazon Kinesis Data Firehoseは、ストリームデータを迅速にストレージに送るサービスですが、データの転送元が大きなデータセット（例えば60 TBのソフトウェア画像）である場合、一般的には適切ではありません。また、S3 Transfer Accelerationは転送速度を向上させるための機能であり、大量のデータの転送には最適な選択肢ではないため、この選択肢は不適切です。

C. AWS Snowballデバイスを使用して、S3バケットをターゲットとして画像を転送する。

可能だが最適ではない
AWS Snowballは、大規模なデータ移行に便利な物理デバイスです。Snowballを使って60 TBのデータを移行することは可能ですが、これはネットワーク経由の転送ではなく、物理的な転送となります。画像が毎日新たに作成されるため、毎日新しいデータをSnowballで転送する必要があり、手間がかかります。したがって、既存のデータの移行には適していますが、日々の自動転送には不向きです。

D. Site-to-Site VPN接続を介してS3 APIを使用し、マルチパートアップロードで画像を転送する。

不適切
Site-to-Site VPN接続は、AWSとオンプレミス間で安全な通信を提供しますが、VPN接続を使用して大量のデータ（60 TB）を転送するのは非常に非効率的です。VPN接続は帯域幅に限界があり、特に大量のデータを転送する際には、スピードや信頼性に問題が生じやすいため、この方法は適していません。また、S3 APIを使用しての手動転送は、管理が煩雑で、自動化するのも難しいです。

結論

AのAWS DataSyncが最適解です。DataSyncは、データ転送の効率性が高く、暗号化も自動で行い、カスタム開発なしで、既存および新しいデータを自動的にAmazon S3に転送する要件に合致しています。
 
 
Relate Posts
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
初心者向け！コンテナ化WordPressサイト構築ガイド（超詳細版）
Lazy loaded image
EFSを活用！AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
00-AWS SAP「理論・実践・10問道場」
Lazy loaded image
01-AWS SAP「理論・実践・10問道場」
Lazy loaded image
02-AWS SAP「理論・実践・10問道場」
Lazy loaded image
40-AWS SAP「理論・実践・10問道場」42-AWS SAP「理論・実践・10問道場」
Loading...
Catalog
0%
minami
minami
一个普通的干饭人🍚
Announcement

🎉 ブログへようこそ 🎉

notion image
名前:みなみ独立事務所
性別:男
国籍:China
完全独学だけで基本情報をはじめ31個の資格を仕事をしながら合格。 現在はIT会社の技術担当や、ブログの執筆や学習支援などを手掛けています。 独学で合格できる学習法、勉強法、試験対策を配信します！

📚 主な内容

💻 IT・システム開発
🏠 不動産 × 宅建士
🎓 MBA 学習記録

🔍 コンテンツの探し方

現在、サイトのデザインはシンプルなため、情報がやや探しにくいかもしれません。
気になるテーマを探す際は、タグ検索の利用をおすすめします。
Search | みなみの風物詩
自分らしく未来へ
Search | みなみの風物詩
https://www.minami.ac.cn/search
Search | みなみの風物詩
Catalog
0%