type
status
date
slug
summary
tags
category
icon
password

491-AWS SAP AWS 「理論・実践・一問道場」Lambda SnapStart

 

理論

AWS Lambda関数において、リクエストを処理するコード（ハンドラー）以外の部分で実行される処理を指します。具体的には、次のようなコードや処理が含まれます：

ハンドラーの外部

  • グローバルスコープのコード Lambda関数ファイルの最上部や、ハンドラー関数の外部で記述されたコードです。このコードは、関数が初めて初期化される際に一度だけ実行されます（コールドスタート時）。例としては、以下のような処理が該当します：
    • ライブラリやモジュールのインポート
    • 静的な変数やオブジェクトの定義
    • リソースの接続設定（例：データベース接続）
    • 重い初期化処理（例：大量の設定ファイル読み込みやクラスのインスタンス化）
上記の例では、INSTANCE_IDの生成がハンドラー外部で行われており、このコードはLambda関数の初期化フェーズで実行されます。

ハンドラーの内部

一方、ハンドラー内部とは、リクエストを受信した際に実行される関数の中身です。この部分のコードは、各リクエストごとに実行されます。

ポイント

「ハンドラーの外部」とは、リクエストが来るたびに実行される処理（ハンドラー）ではなく、Lambda関数の初期化時（コールドスタート）に一度だけ実行されるコードを指します。この部分を最適化することで、Lambda関数の初期化時間（レイテンシー）を短縮することが重要になります。
 
プリスナップショットフック（Pre-Snapshot Hook）とは、AWS LambdaのSnapStart機能を使用する際に、スナップショットを取得する前に実行されるコードのことです。このフックを使うことで、スナップショットに含めたい初期化処理を明示的に設定できます。

特徴

  • 実行タイミング: Lambda関数のスナップショットが作成される前に一度だけ実行されます。
  • 目的:
      1. 長時間変わらない初期化処理を行う（例: ライブラリのロード、定数の設定）。
      1. スナップショットに含めるべきリソースやデータを準備する。

注意点

  • スナップショット後に動的なデータが変わる場合（例: ユニークID生成）、それらはハンドラー内に移動する必要があります。

例

これにより、スナップショット取得時に効率的な初期化が可能になります。

AWS Lambdaのコールドスタートと最適化

AWS Lambdaを使用する際、特にレイテンシーが重要なアプリケーションにおいて、Lambda関数の初期化時間（コールドスタート）を短縮することは重要です。以下では、コールドスタートの概念、影響、最適化方法について簡潔に説明します。

コールドスタートとは？

  • 概要: Lambda関数は初めてリクエストを受けたときや、しばらく使われていなかった場合、新しい環境（コンテナ）を作成します。この初期化プロセスに時間がかかることをコールドスタートと呼びます。
  • 影響する要因:
      1. 使用するランタイム（例: JavaはPythonやNode.jsより遅い傾向）
      1. 初期化時の処理量（ライブラリのロード、設定の読み込みなど）
      1. メモリサイズ（メモリを増やすと起動時間が短縮される場合あり）

コールドスタートを最小化する方法

  1. Lambda SnapStart
      • 概要: 初期化済みのLambda関数のスナップショットを保存し、次回以降のリクエストで再利用します。
      • メリット: Javaランタイムで特に効果的。コールドスタートの影響を大幅に低減。
      • 注意点: すべての初期化コードを最適化し、SnapStartのプリスナップショットフックを活用する必要があります。
  1. プロビジョニング済み同時実行
      • 概要: Lambda関数を事前に起動しておく設定。リクエストごとに新しい環境を作成しないため、コールドスタートが発生しない。
      • メリット: 高速なレスポンスを保証。
      • デメリット: 必要な環境を維持するために追加コストが発生。
  1. グローバルスコープの最適化
      • 概要: 初期化処理（ライブラリのロード、設定ファイルの読み込みなど）をグローバルスコープに配置。
      • メリット: 初回実行後、同じ環境が再利用される（ウォームスタート）。
      • デメリット: コールドスタート時には依然として時間がかかる。
  1. ランタイムの選択
      • 軽量ランタイムの活用: Node.jsやPythonはJavaよりも起動が速いため、可能であればこれらを検討。
  1. メモリサイズの調整
      • 概要: Lambdaのメモリサイズを増やすことで、CPU割り当て量が増加し、初期化が速くなる場合があります。

ユニークな注意点（SnapStart利用時）

  • プリスナップショットフックの使用: SnapStartはLambda関数の初期化状態を保存しますが、スナップショットを取得する前に行う処理（データベース接続、キャッシュ生成など）を適切に整理する必要があります。
  • リクエストごとのユニーク処理の移動: ユニークIDの生成や動的データの初期化は、スナップショットには含めず、ハンドラー内に移動します。

コストとパフォーマンスのトレードオフ

  • プロビジョニング済み同時実行: コストが高いが、最速の応答を保証。
  • SnapStart: Javaランタイムで特に効果的。コスト効率が良い。
  • グローバルスコープ最適化: コストは最小だが、コールドスタートの影響が残る。

まとめ

  • SnapStartは、Javaランタイムを使用するLambda関数のコールドスタートを効果的に解決できる重要な機能。
  • アプリケーションの要件に応じて、SnapStart、プロビジョニング済み同時実行、ランタイムの選択を適切に組み合わせることで、コストとパフォーマンスのバランスを最適化できます。
 

実践

略

一問道場

企業は、レイテンシーに敏感なアプリケーションを開発しています。このアプリケーションには、できるだけ早く初期化する必要がある複数のAWS Lambda関数が含まれています。これらのLambda関数はJavaで記述されており、ライブラリのロード、クラスの初期化、ユニークIDの生成など、ハンドラーの外部で実行される初期化コードを含んでいます。
起動パフォーマンスの要件を、最もコスト効果の高い方法で満たすための解決策として、次の選択肢のうちどれが最適ですか？
A.
すべての初期化コードを各Lambda関数のハンドラーに移動し、各Lambda関数にLambda SnapStartを有効化します。そして、SnapStartを各Lambda関数の最新バージョン（LATESTバージョン）を参照するように設定します。
B.
各Lambda関数のバージョンを公開します。各Lambda関数に対応するエイリアスを作成し、そのエイリアスが対応するバージョンを指すように設定します。その後、エイリアスを指定してプロビジョニング済みの同時実行数の設定を行います。
C.
各Lambda関数のバージョンを公開します。その公開されたバージョンにプロビジョニング済みの同時実行数の設定を行い、さらにLambda SnapStartをその公開バージョンに対して有効化します。
D.
Lambda関数を更新してプリスナップショットフックを追加します。また、ユニークIDを生成するコードをハンドラー内に移動します。その後、各Lambda関数のバージョンを公開し、公開されたLambda関数のバージョンに対してLambda SnapStartを有効化します。

解説

問題の背景

  1. AWS Lambda関数とは？
      2. AWS Lambdaは、コードを実行するサーバーレスサービスです。特定のイベントが発生したときに、そのコード（関数）が実行されます。
  1. レイテンシーが問題になる理由
      2. レイテンシーとは、コードが実行されるまでの時間のことです。Lambda関数では特に「初めて実行されるとき（コールドスタート）」に遅延が発生することがあります。理由は、初期化時に以下のような処理が必要だからです：
      • 必要なライブラリやコードをロードする。
      • 初期設定（データベース接続、IDの生成など）を行う。
  1. Javaの特徴
      2. Javaは他の言語に比べて、クラスのロードや初期化に時間がかかりやすいです。そのため、Lambda関数でJavaを使う場合、初期化時間を短縮する工夫が必要です。
  1. 目標
      2. Lambda関数の初期化（コールドスタート）を速くしつつ、コストを最小限に抑える方法を考えることです。

選択肢の解説

A. 初期化コードをハンドラーに移動し、SnapStartを有効化
  • 意味: 初期化コードをリクエストごとに実行するように変更し、Lambda SnapStart（コールドスタートを高速化するAWSの機能）を使います。
  • メリット: SnapStartでコールドスタートが速くなります。
  • デメリット: 初期化コードがリクエストごとに実行されるため、リクエスト単位の処理が遅くなり、効率的ではありません。
B. プロビジョニング済みの同時実行数を設定し、エイリアスを使用
  • 意味: Lambda関数をあらかじめ「起動済み」にしておく設定をします（プロビジョニング済み同時実行数）。また、エイリアスを使って管理を簡単にします。
  • メリット: コールドスタートが発生しません。
  • デメリット: プロビジョニング済みの設定には追加コストがかかります。
C. SnapStartを有効化し、プロビジョニング済みの設定も使用
  • 意味: SnapStartを有効化してコールドスタートを速くしつつ、一部のリクエストに対してプロビジョニング済みの設定も行います。
  • メリット: SnapStartとプロビジョニング済み設定の組み合わせで、パフォーマンスが向上します。
  • デメリット: 余分なプロビジョニングを行うため、コストがかさむ可能性があります。
D. SnapStart用のフックを追加し、初期化コードをハンドラーに移動
  • 意味: SnapStartを効果的に使うため、初期化処理を最適化（フックの追加）し、一部の処理をハンドラー内に移動します。
  • メリット: SnapStartを活用して効率的な初期化が可能になります。
  • デメリット: 開発者がコードの変更を行う必要があります。

正解：D

  • 理由: SnapStartはLambda関数の初期化時間を短縮するための機能で、コールドスタートを最適化します。この機能を最大限活用するために、プリスナップショットフックを追加し、初期化処理を適切に管理することが重要です。また、ユニークIDの生成のようなリクエストごとに変わる処理はハンドラー内に移動することで、SnapStartの効率を損ねません。これにより、コストを抑えつつパフォーマンスを向上させることができます。

ポイント

  1. SnapStartを有効にすると、Lambda関数の初期化状態がスナップショットとして保存され、次回以降そのスナップショットを再利用できます。
  1. コストを抑えるために、プロビジョニング済みの設定を避け、SnapStartを活用するのが最適です。
  1. ユニークID生成のような処理を適切に配置することで、余分な初期化を防ぎます。
 
 

492-AWS SAP AWS 「理論・実践・一問道場」Systems Manager

 

理論

AWS Systems Manager（SSM）の管理対象インスタンスについて

AWS Systems Manager（SSM）は、AWSのリソース（特にEC2インスタンス）をリモートで管理・操作するためのサービスです。SSMを利用するためには、インスタンスが「管理対象インスタンス」として認識される必要があります。この認識に必要な要素を簡潔にまとめます。

管理対象インスタンスの要件

  1. SSMエージェントのインストールと実行
      • EC2インスタンスにはSSMエージェントがインストールされており、かつ実行されている必要があります。これがインスタンスとSSMサービス間の通信を担当します。
      • 多くのAmazon Machine Image（AMI）にはSSMエージェントがデフォルトで含まれていますが、手動でインストールすることもできます。
  1. IAMロールの設定
      • インスタンスには適切なIAMロールが割り当てられている必要があります。特に、AmazonSSMManagedInstanceCoreポリシーが含まれたロールが必要です。このロールはSSMがインスタンスと通信するための権限を付与します。
  1. ネットワークアクセス
      • インターネットアクセスがある場合、SSMはAWSのパブリックエンドポイントを使用して接続します。
      • インターネットアクセスがない場合、VPCエンドポイント（SSM用）が必要です。これにより、プライベートネットワーク内からもSSMを利用できます。
  1. SSMエージェントのトラブルシューティング
      • SSMエージェントがインストールされていない、または動作していない場合、インスタンスは管理対象インスタンスとして表示されません。
      • エージェントのログファイルを確認して、エラーや警告を確認することが重要です。

一般的な問題とその解決策

  • 問題: インスタンスが管理対象インスタンスとして表示されない。
    • 解決策:
        1. SSMエージェントのインストールと実行確認（ssm-agentが稼働しているかを確認）。
        1. IAMロールの確認（インスタンスにAmazonSSMManagedInstanceCoreポリシーを付与したロールが割り当てられているか確認）。
        1. ネットワーク接続の確認（インターネットまたはVPCエンドポイントの接続性を確認）。
  • 問題: SSMがインスタンスにアクセスできない。
    • 解決策:
        1. インスタンスのセキュリティグループとネットワークACLの設定を確認。
        1. VPCエンドポイントの設定を確認（インターネットにアクセスできない場合）。

まとめ

AWS Systems Managerの管理対象インスタンスには、エージェントのインストール、IAMロールの設定、ネットワークアクセスの構成が不可欠です。これらを適切に設定することで、リモート管理やオートメーションが可能となります。

実践

略

一問道場

質問 #492
あるソリューションアーキテクトが、AWS Import/ExportのAmazon EC2 VM Import機能を使用して、オンプレミス環境からVMをインポートしています。このソリューションアーキテクトは、AMIを作成し、そのAMIに基づいてAmazon EC2インスタンスをプロビジョニングしました。このEC2インスタンスは、VPC内のパブリックサブネットで稼働しており、パブリックIPアドレスが割り当てられています。
しかし、EC2インスタンスがAWS Systems Managerコンソールに管理対象インスタンスとして表示されません。
ソリューションアーキテクトがこの問題をトラブルシューティングするために実行すべき手順の組み合わせはどれですか？（2つ選択）
A. インスタンスにSystems Managerエージェントがインストールされ、実行中であることを確認する。
B. インスタンスにSystems Manager用の適切なIAMロールが割り当てられていることを確認する。
C. VPCにVPCエンドポイントが存在することを確認する。
D. AWS Application Discoveryエージェントが設定されていることを確認する。
E. Systems Manager用のサービスリンクロールが正しく構成されていることを確認する。

解説

この問題は、Amazon EC2インスタンスが**AWS Systems Manager（SSM）**コンソールに「管理対象インスタンス」として表示されない問題をトラブルシューティングする内容です。Systems Managerに管理されるために必要な設定が不足している可能性を考え、正しい手順を選ぶ必要があります。

Systems Managerに管理される条件

  1. SSMエージェントのインストールと実行
      2. EC2インスタンス上にSSM Agent（Systems Manager Agent）がインストールされ、正常に実行されている必要があります。これがなければ、インスタンスはSystems Managerから操作できません。
      → A. 正解
  1. IAMロールの適切な設定
      2. Systems Managerは、EC2インスタンスに関連付けられたIAMロールを介して動作します。このIAMロールには、以下のようなポリシーが必要です：
      • AmazonSSMManagedInstanceCore 適切なIAMロールが割り当てられていない場合、Systems Managerはインスタンスを管理できません。 → B. 正解
  1. ネットワークの接続性
      • インターネットアクセスがある場合、Systems ManagerはAWSパブリックエンドポイントを介して接続します。
      • インターネットアクセスがない場合、VPCエンドポイント（SSM用のプライベート接続）が必要です。 本問ではインスタンスにパブリックIPアドレスが割り当てられているため、VPCエンドポイントは不要です。 → C. 不正解
  1. Application Discovery Agentの設定
      2. AWS Application Discovery Serviceは、オンプレミスのアプリケーションをAWSに移行する際に使用するツールです。Systems Managerの動作には不要です。
      → D. 不正解
  1. サービスリンクロールの設定
      2. AWS Systems Managerは、自動的にサービスリンクロールを作成します。この設定を手動で確認する必要は通常ありません。
      → E. 不正解

解答

  • A. インスタンスにSystems Managerエージェントがインストールされ、実行中であることを確認する。
  • B. インスタンスにSystems Manager用の適切なIAMロールが割り当てられていることを確認する。

解説のポイント

  1. AWS Systems Managerの基本要件（SSMエージェントとIAMロール）を確認することが最優先です。
  1. 本問ではインスタンスがパブリックサブネットにあり、パブリックIPが割り当てられているため、ネットワーク周りの設定（C）は不要です。
  1. Application Discovery Agentやサービスリンクロール（D・E）はSystems Managerの要件ではないため無関係です。
 
 

493-AWS SAP AWS 「理論・実践・一問道場」AWS CodeBuild（ビルド、テスト、スキャン）

 

理論

CI/CDの実装における基本的な要素とツール

CI/CD（継続的インテグレーション / 継続的デリバリー）は、ソフトウェア開発の効率を高めるために使われるプロセスです。AWSを使ったCI/CDの一般的な実装方法について、主要なツールや手順を紹介します。

CI/CDの要素

  1. ソース管理
      • AWS CodeCommitは、Gitベースのリポジトリを提供し、ソースコードを管理します。開発者がソースコードを管理するためのベースとなります。
  1. ビルドとテスト
      • AWS CodeBuildは、アプリケーションのビルド、テスト、自動化されたセキュリティスキャンを実行するサービスです。コードの変更があった際に、ユニットテストやセキュリティテストを自動的に実行し、品質を保つために重要です。
  1. 通知とアラート
      • Amazon SNS（Simple Notification Service）は、ユニットテストの失敗やその他の重要なイベントに対する通知を開発者に送信するために使われます。Amazon EventBridgeを使用して、イベントに基づいて通知をトリガーすることができます。
  1. インフラの管理
      • AWS CloudFormationやAWS CDK（Cloud Development Kit）を使用して、インフラをコードとして管理し、動的に設定を変更することができます。これにより、環境ごとに異なる設定を簡単に管理でき、機能のオン/オフを実現できます。
  1. 承認とデプロイ
      • AWS CodePipelineは、CI/CDパイプラインを自動化するサービスです。パイプライン内で手動承認ステージを挿入し、リード開発者がデプロイを承認するまでアプリケーションのデプロイを保留にすることができます。

CI/CDのベストプラクティス

  1. 自動化されたテストとセキュリティスキャン
      • コードが変更されるたびに、ユニットテストやセキュリティスキャンを自動的に実行し、品質を維持することが重要です。これにより、エラーを早期に発見できます。
  1. 通知とアラートの設定
      • テストが失敗した場合や重要なイベントが発生した場合には、開発者に即座に通知が届くように設定しましょう。これにより、問題に迅速に対処できます。
  1. 柔軟な機能管理
      • アプリケーションの機能を動的にオン/オフできるようにすることで、異なる環境で異なる設定を使い分けたり、機能のリリースをコントロールしたりできます。
  1. 手動承認ステージ
      • デプロイメントの前に、リード開発者が手動で承認するプロセスを導入することで、品質を確保し、重要な変更が本番環境に反映される前に確認できます。

まとめ

AWSでCI/CDを実装する際には、CodeCommit、CodeBuild、CloudFormation/CDK、SNS、EventBridge、CodePipelineなどのツールを組み合わせることで、ソフトウェアの品質を高め、開発の効率を向上させることができます。また、テスト自動化、セキュリティスキャン、通知、機能のオン/オフ、手動承認などの要素を組み込むことで、より強力なデプロイメントパイプラインを構築できます。

実践

略

一問道場

質問 #493
ある企業は、すべてのアプリケーションのデプロイツールとしてAWS CloudFormationを使用しています。アプリケーションのすべてのバイナリとテンプレートは、バージョン管理が有効化されたAmazon S3バケット内で管理されています。開発者は、統合開発環境（IDE）をホストしているAmazon EC2インスタンスにアクセスできます。開発者は、アプリケーションのバイナリをAmazon S3からEC2インスタンスにダウンロードし、変更を加えた後、ローカルでユニットテストを実行した後、バイナリをS3バケットにアップロードします。開発者は、既存のデプロイメントメカニズムを改善し、AWS CodePipelineを使用してCI/CDを実装したいと考えています。
開発者には以下の要件があります：
  • ソース管理にAWS CodeCommitを使用する。
  • ユニットテストとセキュリティスキャンを自動化する。
  • ユニットテストが失敗した場合に開発者にアラートを送信する。
  • アプリケーションの機能をオン/オフし、CI/CDの一環としてデプロイを動的にカスタマイズする。
  • アプリケーションをデプロイする前に、リード開発者による承認を得る。
どのソリューションがこれらの要件を満たすでしょうか？
A. AWS CodeBuildを使用してユニットテストとセキュリティスキャンを実行します。ユニットテストが失敗した場合に、Amazon EventBridgeルールを使用してAmazon SNSアラートを開発者に送信します。さまざまなソリューション機能のためにAWS Cloud Development Kit（AWS CDK）構造を作成し、マニフェストファイルを使用してAWS CDKアプリケーション内で機能をオン/オフします。パイプラインに手動承認ステージを追加して、リード開発者がアプリケーションを承認できるようにします。
B. AWS Lambdaを使用してユニットテストとセキュリティスキャンを実行します。パイプラインの次のステージでLambdaを使用して、ユニットテストが失敗した場合に開発者にAmazon SNSアラートを送信します。さまざまなソリューション機能のためにAWS Amplifyプラグインを作成し、ユーザープロンプトを使用して機能をオン/オフします。パイプラインでAmazon SESを使用してリード開発者がアプリケーションを承認できるようにします。
C. Jenkinsを使用してユニットテストとセキュリティスキャンを実行します。パイプラインでAmazon EventBridgeルールを使用して、ユニットテストが失敗した場合にAmazon SESアラートを開発者に送信します。さまざまなソリューション機能のためにAWS CloudFormationネストスタックを使用し、パラメータを使用して機能をオン/オフします。パイプラインでAWS Lambdaを使用してリード開発者がアプリケーションを承認できるようにします。
D. AWS CodeDeployを使用してユニットテストとセキュリティスキャンを実行します。パイプラインでAmazon CloudWatchアラームを使用して、ユニットテストが失敗した場合にAmazon SNSアラートを開発者に送信します。さまざまなソリューション機能のためにDockerイメージを使用し、AWS CLIで機能をオン/オフします。パイプラインに手動承認ステージを追加して、リード開発者がアプリケーションを承認できるようにします。

解説

この問題では、開発者がAWS CodePipelineを使ってCI/CD（継続的インテグレーション/継続的デリバリー）を実装したいというシナリオです。要件として、ユニットテストとセキュリティスキャンの自動化、ユニットテストの失敗時にアラート、機能のオン/オフ、リード開発者による承認のステージなどが求められています。
以下、問題を解決するために考慮すべき要点と解説です。

1. ソース管理の使用

  • AWS CodeCommitは、ソースコードを管理するためのサービスです。この要件はすべての解決策に共通しているため、特に重要なポイントではありません。

2. ユニットテストとセキュリティスキャンの自動化

  • ユニットテストは、コードが正しく動作するかを検証するための自動化されたテストです。
  • セキュリティスキャンは、コードの脆弱性やセキュリティリスクをチェックするためのプロセスです。
これらは自動化するために、AWS CodeBuild（ビルド、テスト、スキャンの自動化）やAWS Lambda（小規模なスクリプトの実行）を使用できます。

3. ユニットテストの失敗時にアラートを送信

  • ユニットテストが失敗した場合、開発者に通知する仕組みが必要です。これには、Amazon SNS（Simple Notification Service）を使用します。SNSは、エラーが発生したときに開発者に通知する手段です。Amazon EventBridgeを使って、テスト失敗時にSNSでアラートを送信することができます。

4. アプリケーション機能のオン/オフ切り替え

  • CI/CDの一環として、機能をオンまたはオフにする必要があります。これには、アプリケーションの構成ファイルや、AWS CloudFormationやAWS CDK（Cloud Development Kit）を使って、動的に機能を設定できるようにすることが考えられます。
  • AWS CDKは、インフラをコードとして定義するためのツールで、機能をオン/オフにするための柔軟な方法を提供します。

5. リード開発者による承認

  • アプリケーションをデプロイする前に、リード開発者が手動で承認する仕組みが必要です。手動承認ステージをAWS CodePipelineに追加することで、リード開発者がデプロイを許可するまでパイプラインを一時停止できます。

解答選択肢の解説

  • A. 正解
    • AWS CodeBuildを使ってユニットテストとセキュリティスキャンを自動化。
    • Amazon EventBridgeを使って、テスト失敗時にSNSアラートを送信。
    • AWS CDKを使って機能をオン/オフ（マニフェストファイルで制御）。
    • 手動承認ステージを設定して、リード開発者による承認を実現。
  • B. 不正解
    • AWS Lambdaを使う方法もありますが、AWS Amplifyは主にフロントエンドアプリケーションに使われるツールで、CI/CDのバックエンドでの動的機能制御には適していません。
  • C. 不正解
    • Jenkinsは、AWSのネイティブツールではないため、AWS CodePipelineの代わりに使用するのは理想的ではありません。
    • AWS CloudFormationネストスタックは、機能のオン/オフに使えますが、AWS CDKの方がより柔軟で管理しやすいです。
  • D. 不正解
    • AWS CodeDeployは、アプリケーションのデプロイに使われますが、ユニットテストやセキュリティスキャンには適していません。
    • DockerイメージやAWS CLIでの機能制御も、AWS CDKほど動的ではなく、手間がかかります。

結論

  • Aが最も適切な解答です。AWS CodeBuildを使ってテストやスキャンを自動化し、AWS CDKで機能をオン/オフにする方法が最も効率的で、リード開発者による承認も簡単に実現できます。
 
 

494-AWS SAP AWS 「理論・実践・一問道場」iSCSI ボリュームゲートウェイ

 

理論

AWS Storage Gatewayの基本と活用方法

AWS Storage Gatewayは、オンプレミスの環境とAWSクラウドストレージをシームレスに統合するためのサービスです。これを使用することで、オンプレミスのアプリケーションがAWSクラウドのストレージリソースを利用できるようになります。以下に、AWS Storage Gatewayの主要なタイプとその利用方法について解説します。

AWS Storage Gatewayの主要なタイプ

  1. テープゲートウェイ (Tape Gateway)
      • 用途: クラウドバックアップ、アーカイブ、ディザスタリカバリのためのストレージ。
      • 特徴: 仮想テープライブラリ（VTL）を提供し、バックアップソフトウェアとの統合を簡単にします。
      • 制限: 低レイテンシーアクセスが求められるアプリケーションには適しません。
  1. ボリュームゲートウェイ (Volume Gateway)
      • 用途: オンプレミスアプリケーションとAWSクラウド間でストレージボリュームをマウント。
      • モード:
        • キャッシュモード: 頻繁にアクセスされるデータをオンプレミスのキャッシュに保持し、クラウドにはバックアップを取る。
        • ストレッチモード: オンプレミスのボリューム全体をクラウドに移行し、必要なデータのみをオンプレミスでキャッシュ。
      • 特徴: iSCSIインターフェイスを提供し、オンプレミスのアプリケーションがクラウドボリュームをマウントできます。
  1. ファイルゲートウェイ (File Gateway)
      • 用途: NFSやSMBプロトコルを使用して、オンプレミスとAWS S3間でファイルをアクセス。
      • 特徴: オンプレミスのサーバーやアプリケーションからS3バケットにファイルを直接アクセスできるようにします。
      • 制限: iSCSIボリュームとしてマウントすることはできません。
  1. クエリゲートウェイ (Volume Gateway + DataSync)
      • 用途: 大量のデータをAWS S3やAmazon EFSに高速に移行する。
      • 特徴: 複数のデータセンター間で大量のデータを効率よく移動できます。

バックアップと復元

  • AWS Backupと統合:
    • AWS Storage GatewayはAWS Backupと統合でき、オンプレミスのデータやボリュームのバックアップをクラウドに保存し、時点コピーを作成することが可能です。
    • これにより、データの損失を防ぎ、災害復旧（DR）シナリオにおける可用性を高めることができます。

使用シナリオ

  1. 低レイテンシーが必要な場合:
      • ボリュームゲートウェイ（キャッシュモード）を使用して、頻繁にアクセスされるデータをオンプレミスにキャッシュし、クラウドにバックアップを保管します。これにより、ローカルで高速アクセスを実現できます。
  1. バックアップとアーカイブ:
      • テープゲートウェイを使用して、オンプレミスのバックアップデータをクラウドに移行し、長期保管が可能になります。
  1. ファイルストレージのシンプルな統合:
      • ファイルゲートウェイを使用して、S3バケットをオンプレミスファイルシステムのように扱い、リモートのアクセスが可能なファイルストレージを提供します。

選択基準

  • iSCSIアクセス: ボリュームゲートウェイ（キャッシュモード）は、iSCSIデバイスとしてマウント可能で、低レイテンシーアクセスを提供します。
  • ファイルストレージ: ファイルゲートウェイは、NFSやSMBでのファイルアクセスをサポートしますが、iSCSIアクセスはサポートしません。
  • バックアップとアーカイブ: テープゲートウェイは、バックアップ用の仮想テープを提供し、AWS Backupと組み合わせることで効率的なバックアップ戦略を構築できます。

まとめ

AWS Storage Gatewayは、オンプレミスとAWSクラウドをシームレスに統合するための強力なツールです。低レイテンシーのiSCSIアクセスが必要な場合は、ボリュームゲートウェイ（キャッシュモード）を使用するのが最適です。AWS Backupと組み合わせることで、時点バックアップや災害復旧計画を簡単に実現できます。

実践

略

一問道場

質問 #494
あるグローバルなeコマース企業が、世界中に複数のデータセンターを持っています。保存されるデータの増加に伴い、企業はレガシーなオンプレミスのファイルアプリケーション用にスケーラブルなストレージソリューションを設定する必要があります。企業は、AWS Backupを使用してボリュームの時点コピーを作成できる必要があり、頻繁にアクセスされるデータに対して低レイテンシーでアクセスできることが求められています。また、企業はオンプレミスのアプリケーションサーバーから、インターネット小型コンピュータシステムインターフェイス（iSCSI）デバイスとしてマウントできるストレージボリュームも必要です。
どのソリューションがこれらの要件を満たしますか？
A. AWS Storage Gatewayのテープゲートウェイをプロビジョニングし、テープゲートウェイを設定してデータをAmazon S3バケットに保存します。AWS Backupをデプロイして、ボリュームの時点コピーを作成します。
B. Amazon FSx File GatewayとAmazon S3 File Gatewayをプロビジョニングし、AWS Backupをデプロイしてデータの時点コピーを作成します。
C. AWS Storage Gatewayのボリュームゲートウェイをキャッシュモードでプロビジョニングし、オンプレミスのStorage GatewayボリュームをAWS Backupでバックアップします。
D. AWS Storage Gatewayのファイルゲートウェイをキャッシュモードでプロビジョニングし、AWS Backupをデプロイしてボリュームの時点コピーを作成します。

解説

この問題は、企業がAWSで提供するストレージソリューションを使用して、オンプレミスのファイルアプリケーション用にスケーラブルで低レイテンシーのストレージを提供する方法を問うものです。特に、AWS Backupを使用してボリュームの時点コピーを作成する要件と、iSCSI経由でアクセスできるストレージボリュームのニーズに関するものです。
以下、各選択肢の詳細な解説を行います。

A. AWS Storage Gatewayテープゲートウェイを使用

  • テープゲートウェイは、クラウドストレージにバックアップデータを保存するためのストレージゲートウェイです。しかし、これは主にバックアップやアーカイブ目的に使われます。iSCSIアクセスを提供しません。
  • 要件との不一致: iSCSIデバイスとしてマウントする必要があるという要件に対して、テープゲートウェイは適切なソリューションではありません。テープゲートウェイは、低レイテンシーで頻繁にアクセスされるデータの要求にも応じません。

B. Amazon FSx File GatewayとAmazon S3 File Gateway

  • FSx File Gatewayは、Amazon FSx for Windows File Serverと連携するファイルゲートウェイですが、これもiSCSIデバイスとしてボリュームをマウントする要件には適していません。FSxは主にファイルストレージ用で、iSCSIをサポートするものではありません。
  • S3 File Gatewayは、S3バケットをファイルシステムのように利用できるゲートウェイですが、iSCSIデバイスとしてマウントする要件には対応していません。

C. AWS Storage Gatewayボリュームゲートウェイ（キャッシュモード）

  • ボリュームゲートウェイは、オンプレミスのアプリケーションサーバーからiSCSI経由でボリュームをマウントできるストレージソリューションを提供します。キャッシュモードでは、ローカルキャッシュにデータが保持され、頻繁にアクセスされるデータへの低レイテンシーアクセスが可能です。
  • AWS Backupの利用: ボリュームゲートウェイは、バックアップ機能と統合されており、AWS Backupを使用して時点コピーを作成することができます。
  • 要件との一致: iSCSI経由でアクセスでき、低レイテンシーアクセスを提供し、AWS Backupを使用したバックアップにも対応しており、要件を満たします。

D. AWS Storage Gatewayファイルゲートウェイ（キャッシュモード）

  • ファイルゲートウェイは、ファイルベースのストレージ（NFSやSMB）を提供するためのゲートウェイで、iSCSIアクセスを提供することはできません。したがって、iSCSIデバイスとしてマウントする要件には適していません。
  • 要件との不一致: ファイルゲートウェイは、iSCSIボリュームとしてマウントすることはできません。

結論

選択肢 C が最も適切です。AWS Storage Gatewayのボリュームゲートウェイ（キャッシュモード）を使用することで、iSCSI経由での低レイテンシーアクセスを提供し、AWS Backupでのバックアップ機能を活用することができます。このソリューションは、指定された要件を満たします。
 
 

495-AWS SAP AWS 「理論・実践・一問道場」KMS

 

理論

AWS Key Management Service (KMS) とマルチリージョンキー

AWS Key Management Service (KMS) は、AWSのクラウドサービスで暗号化を管理するためのサービスです。KMSを利用することで、データを暗号化および復号化するための鍵（キー）を作成、管理、および制御できます。AWS KMSは、クラウド全体でデータ保護を実現するための重要なサービスであり、多くのAWSサービスと統合され、データのセキュリティを確保します。

KMSマルチリージョンキー

AWS KMSでは、特にグローバルで一貫性のある暗号化を実現するために、マルチリージョンキーの機能を提供しています。この機能を使用することで、同じKMSキーを異なるリージョンで利用することができ、以下のような利点があります。
  1. データの一貫した暗号化と復号化:
      • 複数のリージョンにまたがってデータを保存する場合、同じキーを使用して暗号化および復号化することが可能です。これにより、データを複数のリージョンで管理してもセキュリティを一貫して維持できます。
  1. セキュリティと可用性の向上:
      • データを複数のリージョンに保存する場合、各リージョンでキーをレプリケートできるため、障害が発生しても他のリージョンでデータを復元することが可能です。
  1. 管理の簡素化:
      • マルチリージョンキーを利用すると、複数のリージョンで異なるキーを管理する必要がなく、一貫したセキュリティポリシーを適用できます。

KMSキーのレプリケーション

KMSのマルチリージョンキー機能を使用すると、以下の操作が可能です：
  • プライマリキー: メインとなるKMSキーを特定のリージョンに作成し、そのキーを基にレプリカキーを作成します。
  • レプリカキー: プライマリキーのコピーであり、異なるリージョンにレプリケートされたものです。これにより、同じキーを利用して複数のリージョンでデータの暗号化・復号化が行えます。

KMSの利用シナリオ

  1. クロスリージョンバックアップ:
      • 複数のリージョンにバックアップを保存し、そのバックアップデータを同じキーで復号化する必要がある場合に有効です。
  1. グローバルアプリケーションの暗号化:
      • 複数のリージョンに分散されたアプリケーションで、データを暗号化および復号化する必要がある場合、マルチリージョンキーを使用することで、全リージョンで一貫した暗号化を維持できます。
  1. 災害復旧:
      • データセンターの障害やリージョン障害時に、他のリージョンからデータを復元する場合、同じキーを利用してデータを復号化できます。

KMSキー管理のベストプラクティス

  • キーのローテーション: セキュリティの向上を図るため、定期的にキーをローテーションすることが推奨されます。AWS KMSは自動的にキーのローテーションをサポートしています。
  • IAMポリシーの利用: 誰がどのキーにアクセスできるかを制御するために、IAMポリシーを適切に設定することが重要です。
  • 監査とログの管理: AWS CloudTrailを使用して、KMSキーへのアクセスや使用状況を監査し、不正アクセスや操作を監視します。

まとめ

AWS KMSのマルチリージョンキー機能を使用することで、複数のリージョンにまたがるデータの暗号化および復号化を一貫して管理でき、データのセキュリティと可用性を確保できます。この機能を活用することで、グローバルなアプリケーションにおけるデータ管理の効率を高め、セキュリティリスクを軽減できます。

実践

略

一問道場

質問 #495
ある企業には、AWS Key Management Service (AWS KMS)を使用してデータを暗号化および復号化するアプリケーションがあります。アプリケーションはデータをAmazon S3バケットに格納します。企業のセキュリティポリシーでは、データをS3バケットに格納する前に暗号化する必要があります。また、アプリケーションはS3バケットからファイルを読み込む際にデータを復号化する必要があります。企業はS3バケットを他のリージョンに複製しています。ソリューションアーキテクトは、アプリケーションがリージョンをまたいでデータを暗号化および復号化できるようにするソリューションを設計しなければなりません。アプリケーションは、各リージョンでデータを復号化するために同じキーを使用しなければなりません。
どのソリューションがこれらの要件を満たしますか？
A. KMSマルチリージョンのプライマリキーを作成し、そのKMSマルチリージョンプライマリキーを使用して、アプリケーションが実行される各追加リージョンにKMSマルチリージョンレプリカキーを作成します。アプリケーションコードを更新して、各リージョンで特定のレプリカキーを使用します。
B. アプリケーションが実行される各追加リージョンに新しいカスタマー管理のKMSキーを作成します。アプリケーションコードを更新して、各リージョンで特定のKMSキーを使用します。
C. AWS Private Certificate Authorityを使用して、プライマリリージョンに新しい証明書機関（CA）を作成します。CAからアプリケーションのウェブサイトURLのための新しいプライベート証明書を発行します。AWSリソースアクセスマネージャー（AWS RAM）を使用して、追加リージョンとCAを共有します。アプリケーションコードを更新して、各リージョンで共有されたCA証明書を使用します。
D. AWS Systems Manager Parameter Storeを使用して、アプリケーションが実行される各追加リージョンにパラメータを作成します。プライマリリージョンのKMSキーからキー素材をエクスポートします。各リージョンのパラメータにキー素材を保存します。アプリケーションコードを更新して、各リージョンでパラメータからキー情報を使用します。

解説

この問題は、複数のリージョンにわたってデータを暗号化および復号化するために、アプリケーションがどのように同じ暗号化キーを使用するかを問うものです。特に、AWS Key Management Service (KMS)を使用してデータの暗号化を実現する場合に焦点を当てています。
以下は各選択肢の解説です。

A. KMSマルチリージョンのプライマリキーを作成し、そのKMSマルチリージョンプライマリキーを使用して、アプリケーションが実行される各追加リージョンにKMSマルチリージョンレプリカキーを作成します。アプリケーションコードを更新して、各リージョンで特定のレプリカキーを使用します。

  • 正解: これは最も適切なソリューションです。AWS KMSのマルチリージョンキー機能を使用すると、1つのプライマリキーを複数のリージョンにレプリケート（複製）できます。これにより、同じKMSキーを複数のリージョンで使用し、データの暗号化と復号化を実現できます。
    • 利点: データの暗号化と復号化に一貫したキーを使用でき、セキュリティポリシーに適合します。
    • 手順: プライマリキーを作成し、それを基に各リージョンでレプリカキーを作成することで、アプリケーションは異なるリージョンでも同じキーを使用できます。

B. アプリケーションが実行される各追加リージョンに新しいカスタマー管理のKMSキーを作成します。アプリケーションコードを更新して、各リージョンで特定のKMSキーを使用します。

  • 不適切: これは推奨されません。各リージョンに異なるKMSキーを作成する場合、異なるキーを使って暗号化/復号化を行うことになり、各リージョンでのデータアクセスの整合性を確保するのが難しくなります。また、データを同じキーで復号化するという要件を満たせません。

C. AWS Private Certificate Authorityを使用して、プライマリリージョンに新しい証明書機関（CA）を作成します。CAからアプリケーションのウェブサイトURLのための新しいプライベート証明書を発行します。AWSリソースアクセスマネージャー（AWS RAM）を使用して、追加リージョンとCAを共有します。アプリケーションコードを更新して、各リージョンで共有されたCA証明書を使用します。

  • 不適切: この選択肢は、証明書を管理する方法に関するものであり、KMSキーを使ったデータの暗号化/復号化とは関係ありません。証明書は、通常、TLS/SSL通信のセキュリティに使われ、データの暗号化とは異なります。

D. AWS Systems Manager Parameter Storeを使用して、アプリケーションが実行される各追加リージョンにパラメータを作成します。プライマリリージョンのKMSキーからキー素材をエクスポートします。各リージョンのパラメータにキー素材を保存します。アプリケーションコードを更新して、各リージョンでパラメータからキー情報を使用します。

  • 不適切: KMSのキー素材をエクスポートして保存することは、セキュリティの観点から推奨されません。キー素材の管理は非常に慎重に行う必要があり、誤って漏洩すると重大なリスクとなります。また、KMSのキーを複数リージョンで使用するためにこの方法を使うことは、管理が複雑であり、望ましいアプローチではありません。

まとめ

  • Aの選択肢が最適な解決策です。AWS KMSのマルチリージョンキー機能を使用することで、同じキーを複数のリージョンで利用し、データを暗号化および復号化することができます。これにより、企業のセキュリティポリシーに従った一貫したキー管理を実現できます。
 
 

496-AWS SAP AWS 「理論・実践・一問道場」ヘルスチェックの猶予期間

 

理論

1. Auto Scalingとヘルスチェック

  • Auto Scalingは、EC2インスタンスの数を自動的にスケーリングする機能です。インスタンスが正常に動作しているかどうかを判定するために、**ALB（Application Load Balancer）**を使用してヘルスチェックが行われます。
  • ALBは、EC2インスタンスに対して定期的にヘルスチェックを実行し、正常なインスタンスにトラフィックを送ります。もしインスタンスが不健康だと判断された場合、ALBはそのインスタンスを「サービスから外す」ことになります。

2. ヘルスチェックの失敗

  • ヘルスチェックの失敗は、EC2インスタンスが要求に応じて正常に応答できなかった場合に発生します。これには、インスタンスが適切に初期化されていない、リソースが不足している、あるいは必要なサービスがまだ起動していない場合などが含まれます。
  • ユーザーデータスクリプト（例: S3からのデータダウンロードなど）が完了していないと、ALBのヘルスチェックに失敗し、不健康として判定される可能性があります。

3. ヘルスチェックの猶予期間（Health Check Grace Period）

  • ヘルスチェック猶予期間は、Auto Scalingグループの設定で、インスタンスの起動後、最初のヘルスチェックが実行されるまでに待機する時間を指定できます。この設定を適切に調整することで、インスタンスが起動してから十分な時間を確保し、ALBが実行するヘルスチェックに合格するようにできます。
  • 初期化処理が完了する前にALBのヘルスチェックを行うと、不健康と見なされてインスタンスが終了されるため、ヘルスチェック猶予期間を増やすことで、インスタンスが完全に準備が整うまで待機することができます。

4. ユーザーデータスクリプトの最適化

  • ユーザーデータスクリプトで行う処理（S3からのダウンロードなど）が重い場合、その完了に時間がかかり、EC2インスタンスの起動が遅れます。スクリプトが完了する前にALBのヘルスチェックが行われると、失敗と判断される可能性があります。このため、ヘルスチェック猶予期間を増やすことが解決策となります。

まとめ

  • ALBヘルスチェックは、EC2インスタンスの健康状態を監視する重要な要素ですが、インスタンスの初期化に時間がかかる場合は、ヘルスチェック猶予期間を増やすことで、初期化処理が完了するまで十分な時間を確保できます。これにより、EC2インスタンスがALBのヘルスチェックに合格し、正常にサービスを提供することができます。

実践

略

一問道場

会社は、Amazon EC2インスタンスを複数使用するアプリケーションをホストしており、そのインスタンスはApplication Load Balancer（ALB）の背後でAuto Scalingグループに配置されています。EC2インスタンスが起動すると、インスタンスはユーザーデータスクリプトを実行して、アプリケーションに必要な重要なコンテンツをAmazon S3バケットからダウンロードします。
EC2インスタンスは正常に起動しますが、しばらくすると、次のエラーメッセージとともにインスタンスが終了します：「ELBシステムのヘルスチェックの失敗に応じてインスタンスがサービスから外れました。」その結果、EC2インスタンスはAuto Scalingイベントによって終了し、新しいインスタンスが起動されるという無限ループが発生しています。
最近の変更点は、会社がS3バケットに大量の重要なコンテンツを追加したことだけです。会社は本番環境でユーザーデータスクリプトを変更したくありません。
プロダクション環境が正常にデプロイできるように、ソリューションアーキテクトはどのように対応すべきでしょうか？
A. EC2インスタンスのサイズを増やす。
B. ALBのヘルスチェックタイムアウトを増やす。
C. ALBのヘルスチェックパスを変更する。
D. Auto Scalingグループのヘルスチェックの猶予期間を増やす。

解説

この問題は、AWS環境でEC2インスタンスがAuto Scalingグループ内で起動し、Application Load Balancer (ALB) を通じてトラフィックを受け取る設定に関連しています。問題の根本的な原因と解決策を以下のステップで解説します。

問題の背景

  • EC2インスタンス: アプリケーションは、EC2インスタンスが含まれるAuto Scalingグループ内でホストされており、インスタンスが起動する際にユーザーデータスクリプトを実行して、Amazon S3から重要なコンテンツをダウンロードします。
  • ALBによるヘルスチェック: ALBは、トラフィックを処理するためにEC2インスタンスのヘルスチェックを実施します。EC2インスタンスが「健康」と見なされるためには、指定されたヘルスチェックに成功する必要があります。
  • 無限ループの問題: EC2インスタンスは、最初は正常に起動しますが、ある一定の時間が経過した後に「ELBシステムのヘルスチェックの失敗」によってインスタンスがサービスから外れ、Auto Scalingグループによりインスタンスが再起動されるという無限ループが発生します。

問題の原因

  • EC2インスタンスが起動時に必要なコンテンツをS3からダウンロードしているため、インスタンスの起動と準備には時間がかかります。
  • ALBのヘルスチェックが実行されるタイミングで、インスタンスがまだ完全に準備できておらず、そのためALBの健康チェックに失敗してしまいます。
  • ヘルスチェックが失敗すると、ALBはそのインスタンスを「不健康」と見なし、インスタンスはAuto Scalingグループによって終了されます。終了されたインスタンスは再度起動されますが、再び同じ問題が発生します。このプロセスが繰り返されることにより、無限ループが発生します。

解決策

問題の解決策は、EC2インスタンスが初期化処理を完了するまでの時間を確保することです。このためには、ALBがヘルスチェックを実行する前に、インスタンスが必要な初期化を完了するための猶予期間を設定する必要があります。

選択肢 D: Auto Scalingグループのヘルスチェックの猶予期間を増やす

  • *ヘルスチェックの猶予期間（Health Check Grace Period）**は、Auto Scalingグループの設定で指定できるパラメータで、インスタンスが起動後に実際にトラフィックを受け取る前に、インスタンスが完全に準備できるまでの時間を待機する時間です。
  • ユーザーデータスクリプトでコンテンツのダウンロードなどが完了するためには一定の時間が必要です。この猶予期間を増やすことで、ALBの健康チェックが実行されるタイミングでインスタンスが「健康」と見なされるようになります。

他の選択肢について

  • A. EC2インスタンスのサイズを増やす:
    • インスタンスサイズを大きくしても、コンテンツのダウンロードが遅くなるわけではなく、根本的な問題は解決しません。
  • B. ALBのヘルスチェックタイムアウトを増やす:
    • ALBのヘルスチェックタイムアウトを増やすことは、インスタンスが最初のチェックに合格する時間を増やすために有効ですが、EC2インスタンスがALBのヘルスチェックに失敗するのは、タイムアウトよりもインスタンスの準備ができるまでの時間不足が主な原因です。このため、ヘルスチェックの猶予期間を増やす方が適切です。
  • C. ALBのヘルスチェックパスを変更する:
    • ヘルスチェックパスを変更しても、インスタンスが準備できる時間の不足に関する問題は解決しません。

結論

この問題を解決するためには、Auto Scalingグループのヘルスチェック猶予期間（Health Check Grace Period）を増やすことが最も効果的です。この設定を行うことで、EC2インスタンスは初期化を完了するまでの時間を確保でき、ALBの健康チェックに合格することができるようになります。
 
 

497-AWS SAP AWS 「理論・実践・一問道場」空間データ

 

理論

空間データとは？

空間データ（Spatial Data） とは、地理的位置や形状に関連するデータのことです。このデータは、地球上の物体や地点の位置や形状を表現するために使用されます。例えば、地図上で特定の場所を示す座標、道路、建物、河川などが空間データです。
空間データは主に2つのタイプに分けられます：
  1. ベクターデータ:
      • 地点、線、面などで表現されるデータ。
      • 例えば、都市の座標、道路の位置、国境線などがこれに該当します。
  1. ラスターデータ:
      • ピクセル（格子状）で表現されるデータ。衛星画像や空撮写真などが例です。
      • ピクセルごとに色や標高などの値が設定されているため、地形や土地利用の分析に利用されます。

空間データの利用例

  • 地図作成: 地理的な情報を基に地図を作成します。例えば、Google MapsやApple Mapsの地図が空間データを活用しています。
  • ナビゲーション: 車や歩行者向けの道案内システムで使用されます。GPSデータと空間データを組み合わせて、最適なルートを提供します。
  • 環境モニタリング: 自然環境の変化や都市開発の影響を追跡するために空間データが使われます。
  • 都市計画: 新しい建物や道路、緑地などの配置を決める際に空間データが活用されます。

空間データを扱うためのツールと技術

  • GIS（地理情報システム）: 空間データの収集、管理、解析、表示を行うシステム。ArcGISやQGISが代表的なGISツールです。
  • PostGIS（PostgreSQL）: 空間データを扱うためのPostgreSQLの拡張機能。空間データ型や空間関数を使用して、データベース内で空間データを効率的に管理できます。
  • RDS（Relational Database Service）: AWSのRDSサービスもPostGISをサポートし、クラウド上で空間データを管理することができます。

空間データとクラウドサービス

クラウド環境でも空間データを管理することが増えてきており、以下のようなサービスが役立ちます：
  • Amazon RDS for PostgreSQL: クラウド上で空間データを扱いたい場合、PostgreSQLのRDSサービスが便利です。PostGIS拡張機能を使って、空間データを簡単に管理できます。
  • Amazon Athena: S3に保存された空間データをSQLクエリで分析できます。Athenaを使うと、データをS3から直接クエリできます。
  • AWS Lambda: 空間データの処理や分析を自動化するために、Lambdaを使用してサーバーレスで作業を実行できます。

空間データの特徴

  • 座標系: 空間データは、通常「緯度」「経度」などの座標系を使って位置を特定します。異なる座標系を使うことがあるため、座標系の変換が必要な場合もあります。
  • ジオメトリ: 空間データには、点、線、面といったジオメトリが使われます。例えば、特定の場所を示す「点」、道路や川を示す「線」、都市の区域を示す「面」などがあります。

空間データのクエリと分析

  • 空間データを活用するためには、専用のクエリや関数を使用してデータを抽出、加工、解析します。例えば、PostGISでは、位置が指定された円範囲内にある地点を検索したり、2つの線が交差しているかどうかを調べることができます。

まとめ

空間データは、地理的な情報を扱うためのデータで、地図作成やナビゲーション、環境モニタリング、都市計画など多くの分野で使用されます。AWSを使った空間データの管理や分析には、RDS for PostgreSQLやPostGIS、Amazon Athenaなどのサービスが役立ちます。空間データの理解と適切なツールを使うことが、効果的なデータ管理と分析に繋がります。

実践

略

一問道場

ある企業がオンプレミスのOracleデータベースの一部をAWSに移行する必要があります。企業は、ビジネスコンプライアンスの理由で一部のデータベースはオンプレミスに残すことに決定しました。オンプレミスのデータベースには空間データが含まれており、メンテナンスのためにcronジョブを実行しています。企業は、AWSからオンプレミスのシステムに直接接続して、データを外部テーブルとしてクエリする必要があります。
この要件を満たすソリューションはどれですか？
A. 自動スケーリングを有効にしたAmazon DynamoDBグローバルテーブルを作成します。AWSスキーマ変換ツール（AWS SCT）とAWSデータベース移行サービス（AWS DMS）を使用して、オンプレミスからDynamoDBにデータを移動します。AWS Lambda関数を作成して、空間データをAmazon S3に移動します。データをAmazon Athenaを使用してクエリします。EventBridgeを使用してDynamoDBのメンテナンスジョブをスケジュールします。外部テーブルのサポートにはAmazon API Gatewayを使用します。
B. Amazon RDS for Microsoft SQL Server DBインスタンスを作成します。ネイティブレプリケーションを使用して、オンプレミスからDBインスタンスにデータを移動します。AWSスキーマ変換ツール（AWS SCT）を使用して、レプリケーション後にSQL Serverスキーマを必要に応じて変更します。空間データをAmazon Redshiftに移動します。システムメンテナンスのためにストアドプロシージャを使用します。AWS Glueクローラーを作成して、オンプレミスのOracleデータベースに接続し、外部テーブルサポートを提供します。
C. Amazon EC2インスタンスを起動して、Oracleデータベースをホストします。EC2インスタンスをAuto Scalingグループに配置します。AWSアプリケーション移行サービスを使用して、オンプレミスからEC2インスタンスにデータを移行し、リアルタイムの双方向変更データキャプチャ（CDC）同期を行います。Oracleのネイティブな空間データサポートを使用します。AWS Lambda関数を作成して、AWS Step Functionsワークフローの一部としてメンテナンスジョブを実行します。外部テーブルサポートのためにインターネットゲートウェイを作成します。
D. Amazon RDS for PostgreSQL DBインスタンスを作成します。AWSスキーマ変換ツール（AWS SCT）とAWSデータベース移行サービス（AWS DMS）を使用して、オンプレミスからDBインスタンスにデータを移動します。PostgreSQLのネイティブな空間データサポートを使用します。DBインスタンスでcronジョブを実行してメンテナンスを行います。外部テーブルサポートのために、AWS Direct Connectを使用してDBインスタンスをオンプレミス環境に接続します。

解説

このシナリオにおいて、要件を満たすソリューションは D の選択肢です。

理由:

  1. 外部テーブルのサポート: オンプレミスのOracleデータベースの一部をAWSに移行する必要があり、外部テーブルを使ってAWS上からオンプレミスデータベースにアクセスする要件があります。選択肢Dでは、PostgreSQL のネイティブな空間データサポートを利用して、外部テーブルをサポートします。これは、AWS RDS for PostgreSQLを利用し、必要に応じてオンプレミスデータベースとの接続を確立できます。
  1. 空間データ: 空間データを扱うために、PostgreSQLにはPostGISという拡張機能があり、空間データを効率的に処理できます。AWS RDS for PostgreSQLは、このPostGIS機能をサポートしており、空間データをAWS側でも適切に扱えます。
  1. メンテナンスのためのcronジョブ: PostgreSQLでは、RDSインスタンス上でcronジョブを使用して、必要なメンテナンスタスクをスケジュールすることができます。
  1. オンプレミス接続: 外部テーブルのサポートには、AWS Direct Connectを使用して、AWSとオンプレミスのデータベース間で低遅延かつ安全な接続を提供することができます。

他の選択肢の問題点:

  • A: DynamoDBはNoSQLデータベースであり、空間データのサポートが限られています。また、DynamoDBへの移行は、Oracleのリレーショナルな特性を活かすには不向きです。
  • B: RDS for SQL Serverを使用し、空間データをRedshiftに移動する案ですが、SQL Serverの空間データサポートはRedshiftの方が強力ではなく、オンプレミスのOracleデータベースとの互換性に問題が生じる可能性があります。
  • C: EC2にOracleデータベースをインストールする方法ですが、EC2インスタンスでOracleを管理するのは手間がかかります。また、双方向CDC同期の設定やインターネットゲートウェイの利用など、複雑さが増します。
したがって、D の選択肢が最も適切な解決策です。
 
 

498-AWS SAP AWS 「理論・実践・一問道場」カスタムリソース

 

理論

AWS CloudFormationとリソース削除

AWS CloudFormationは、インフラストラクチャをコードとして管理できるサービスで、リソースの作成、更新、削除を自動化します。CloudFormationスタックは、関連するAWSリソースを一度に管理するためのテンプレートに基づいています。

CloudFormationのリソース削除

CloudFormationスタックを削除すると、デフォルトで作成されたリソースも削除されます。ただし、削除の挙動はリソースによって異なり、いくつかのリソースは手動で削除する必要がある場合もあります。
  • DeletionPolicy属性: CloudFormationでは、DeletionPolicy属性を設定することで、リソース削除時の挙動を指定できます。
    • Delete: リソースが削除される。
    • Retain: リソースが削除されない。
    • Snapshot: リソースのスナップショットを作成し、その後削除する。

S3バケットの削除問題

S3バケットをCloudFormationで管理する際、バケット内にオブジェクトが残っていると、バケット削除に失敗することがあります。これを回避するためには、オブジェクトを削除する方法を事前に設定しておく必要があります。

解決方法

  • Lambda関数によるオブジェクト削除: S3バケット内のオブジェクトを削除するために、CloudFormationのカスタムリソースとしてLambda関数を使用することが有効です。Lambda関数を使うことで、オブジェクトの削除を自動化し、スタック削除時にオブジェクトが削除されるようにします。
  • DependsOn属性: CloudFormationのDependsOn属性を使用して、特定のリソースが削除される前にLambda関数を実行するように順序を指定できます。これにより、S3バケット内のオブジェクトが確実に削除されてからバケット自体が削除されます。

まとめ

CloudFormationを使用する場合、リソースの削除順序や削除方法を適切に管理することが重要です。Lambda関数やDependsOn属性を活用することで、スタック削除時の問題を防ぐことができます。

実践

略

一問道場

質問 #498
企業は、Amazon EC2およびAWS Lambda上でアプリケーションを実行しています。このアプリケーションは、Amazon S3に一時的なデータを保存します。S3のオブジェクトは24時間後に削除されます。
会社はAWS CloudFormationスタックを使って新しいバージョンのアプリケーションをデプロイします。スタックは必要なリソースを作成します。新しいバージョンの検証が完了すると、古いスタックを削除しますが、最近、古い開発スタックの削除に失敗しました。
ソリューションアーキテクトは、大きなアーキテクチャの変更なしでこの問題を解決する必要があります。
どのソリューションがこの要件を満たすでしょうか？
A. S3バケットからオブジェクトを削除するLambda関数を作成し、このLambda関数をCloudFormationスタックのカスタムリソースとして追加します。そして、DependsOn属性でS3バケットリソースを指定します。
B. CloudFormationスタックを変更して、S3バケットにDeletationPolicy属性を追加し、その値をDeleteに設定します。
C. CloudFormationスタックを更新して、S3バケットリソースにDeletionPolicy属性を追加し、その値をSnapshotに設定します。
D. CloudFormationテンプレートを更新して、一時ファイルを格納するためにAmazon Elastic File System（Amazon EFS）を作成し、Lambda関数をEFSファイルシステムと同じVPC内で実行するように設定します。

解説

この問題は、AWS CloudFormationスタックの削除に関する問題です。具体的には、CloudFormationスタックを削除しようとしたときに、S3バケットのオブジェクトが削除されなかったため、スタック削除が失敗しました。この問題を解決する方法を求めています。以下は、各選択肢に関する解説です。

選択肢 A: Lambda関数を使ったカスタムリソースの追加

  • 概要: S3バケットからオブジェクトを削除するためにLambda関数を作成し、このLambda関数をCloudFormationスタックのカスタムリソースとして追加します。DependsOn 属性を使って、Lambda関数の実行をS3バケットリソースの削除に依存させます。
  • 解説: この方法では、CloudFormationのカスタムリソースとしてLambda関数を使い、S3バケット内のオブジェクト削除を自動化できます。DependsOn 属性を使って、リソース削除の順序を制御することができます。この方法は、スタック削除時にオブジェクト削除を確実に実行するための良いアプローチです。

選択肢 B: DeletionPolicy属性をDeleteに設定

  • 概要: CloudFormationスタックで、S3バケットに対して DeletionPolicy 属性を設定し、その値を Delete に設定します。
  • 解説: DeletionPolicy 属性は、CloudFormationスタック削除時にリソースの削除方法を制御するためのものです。Delete を設定すると、CloudFormationはリソースを削除しますが、S3バケット内のオブジェクトは削除されません。この方法ではオブジェクト削除が行われないため、問題解決には不適切です。

選択肢 C: DeletionPolicy属性をSnapshotに設定

  • 概要: CloudFormationスタックで、S3バケットに対して DeletionPolicy 属性を設定し、その値を Snapshot に設定します。
  • 解説: Snapshot 設定は、リソースの削除前にスナップショットを作成する設定ですが、S3バケットに対しては意味を持ちません。スナップショットが取られるのは、主にEBSボリュームやRDSインスタンスなどです。このため、S3バケットに対して Snapshot を設定してもオブジェクト削除には影響を与えないため、問題解決には不適切です。

選択肢 D: Amazon EFSを使用する

  • 概要: 一時ファイルを格納するためにAmazon EFS（Elastic File System）を使用し、Lambda関数がEFSと同じVPC内で実行されるように設定します。
  • 解説: EFSは分散型のファイルストレージで、EC2インスタンスやLambda関数がアクセスできます。しかし、S3バケットのオブジェクト削除問題とは直接的な関係はなく、この方法では根本的な問題は解決できません。AWS LambdaをEFS内で実行しても、S3のオブジェクト削除問題を解決することにはなりません。

最適解: 選択肢 A

  • Lambda関数を使ってS3バケットのオブジェクト削除を行う方法が、CloudFormationのスタック削除時にオブジェクト削除を確実に行うための最適な方法です。カスタムリソースとしてLambda関数を設定し、DependsOn 属性で順序を制御することで、S3オブジェクト削除を適切に実行できます。

結論

選択肢 A がこの要件を最も適切に解決する方法です。
 
 

499-AWS SAP AWS 「理論・実践・一問道場」Amazon S3

 

理論

Amazon S3のコスト最適化

Amazon S3は、スケーラブルで高耐久性のあるオブジェクトストレージサービスですが、ストレージのコストを最適化するためには、以下のいくつかの戦略を適用することが重要です。

1. ストレージクラスの選択

S3には複数のストレージクラスがあり、アクセス頻度やデータ保持の目的に応じて最適なクラスを選択することができます。
  • S3 Standard: 頻繁にアクセスされるデータに適しており、最も高価です。
  • S3 Standard-IA (Infrequent Access): アクセス頻度が低いが、すぐにアクセスする必要があるデータに最適で、コストを削減できます。
  • S3 Glacier: 長期保存向けのアーカイブストレージで、コストが低いですが、データアクセスには時間がかかります。

2. ライフサイクルポリシー

S3のライフサイクル設定を利用して、データの保存期間に応じてストレージクラスを自動的に変更できます。
  • 例えば、アクセス頻度が低くなったデータをS3 Standard-IAに移行したり、一定期間後にS3 Glacierに移行する設定ができます。これにより、コストを最適化できます。

3. 未完了のマルチパートアップロードの削除

S3でマルチパートアップロードを使用すると、大きなファイルを複数のパートに分割してアップロードできますが、途中で失敗した場合や中断された場合、未完了のアップロードがストレージに残ることがあります。これらをライフサイクル設定で一定期間後に削除することで、不要なコストを削減できます。

4. データ転送の最適化

S3へのデータ転送にかかるコストも考慮する必要があります。
  • S3 Transfer Accelerationは、アップロード速度を向上させるサービスですが、追加料金がかかります。転送の効率化には役立つ一方、コスト削減には直接関係しません。

5. Requester Pays

Requester Paysモードを有効にすると、S3バケットにアクセスするユーザーがデータ転送費用を負担することになります。この設定は、データ転送コストの管理には有効ですが、ストレージコスト削減には効果がないため、注意が必要です。

まとめ

S3のコスト最適化には、ストレージクラスの選択、ライフサイクル設定、未完了アップロードの管理が重要です。アクセス頻度の低いデータは、S3 Standard-IAやS3 Glacierに移行することで、コストを大幅に削減できます。また、マルチパートアップロードの未完了データを削除することも、無駄なコストを減らすために重要です。

実践

略

一問道場

質問 #499
ある企業には、Amazon S3バケットにユーザーがアップロードした動画を保存するアプリケーションがあります。このS3バケットはS3 Standardストレージを使用しています。ユーザーは動画がアップロードされてから最初の180日間は頻繁にアクセスしますが、180日を過ぎるとアクセスはまれになります。ユーザーには名前付きユーザーと匿名ユーザーがいます。ほとんどの動画のサイズは100MBを超えており、ユーザーは動画をアップロードする際にインターネット接続が不安定なことが多く、アップロードに失敗することがあります。企業は動画のアップロードに対してマルチパートアップロードを使用しています。
ソリューションアーキテクトは、アプリケーションのS3コストを最適化する必要があります。
この要件を満たすために、どのアクションの組み合わせが適切でしょうか？（2つ選んでください）
A. S3バケットをRequester Paysバケットとして設定する。
B. S3 Transfer Accelerationを使用して、動画をS3バケットにアップロードする。
C. S3ライフサイクル設定を作成し、マルチパートアップロードが開始されてから7日後に未完了のアップロードを期限切れにする。
D. S3ライフサイクル設定を作成し、1日後にオブジェクトをS3 Glacier Instant Retrievalに移行する。
E. S3ライフサイクル設定を作成し、180日後にオブジェクトをS3 Standard-infrequent Access（S3 Standard-IA）に移行する。

解説

この問題では、企業がAmazon S3に保存されているユーザーアップロード動画のコストを最適化するための方法を尋ねています。以下は各選択肢の解説です。

A. S3バケットをRequester Paysバケットとして設定する

  • 解説: Requester Pays は、S3バケットにアクセスするユーザーがデータ転送コストを負担する設定です。つまり、S3バケットの所有者はリクエスト料金を支払う必要がなく、リクエスト元が料金を支払います。ただし、これは動画の保存やコストの最適化には直接関係なく、主にデータ転送にかかる料金の管理を行うためのオプションです。動画のストレージコストやアップロードの効率化には寄与しませんので、このオプションは最適化に役立たない可能性があります。

B. S3 Transfer Accelerationを使用して、動画をS3バケットにアップロードする

  • 解説: S3 Transfer Acceleration は、ユーザーが動画をS3にアップロードする際の速度を向上させるサービスです。特にインターネット接続が不安定な場合、アップロードが成功しやすくなる可能性があります。しかし、これはコスト削減には寄与しません。むしろ、通常のアップロードに比べて追加料金が発生するため、コスト最適化には不向きです。

C. S3ライフサイクル設定を作成し、マルチパートアップロードが開始されてから7日後に未完了のアップロードを期限切れにする

  • 解説: S3では、マルチパートアップロードを使用して大きなファイルを分割してアップロードしますが、もしアップロードが途中で失敗した場合、未完了のパートがS3バケットに残ることがあります。これらの未完了アップロードはコストを無駄にするため、ライフサイクル設定で期限切れにすることが有効です。未完了のマルチパートアップロードを自動的に削除することで、不要なストレージコストを削減できます。

D. S3ライフサイクル設定を作成し、1日後にオブジェクトをS3 Glacier Instant Retrievalに移行する

  • 解説: S3 Glacier Instant Retrieval は、アーカイブされたデータの迅速なアクセスを提供しますが、これは主にデータが長期間使用されない場合に有効です。動画の保存初期には頻繁にアクセスされるため、1日後にデータをS3 Glacier Instant Retrievalに移行するのは不適切です。1日後に移行するのは早すぎ、アクセス頻度の高いデータに対してコスト効率が悪くなります。

E. S3ライフサイクル設定を作成し、180日後にオブジェクトをS3 Standard-infrequent Access（S3 Standard-IA）に移行する

  • 解説: S3 Standard-IA は、アクセス頻度が低いデータの保存に最適化されたストレージクラスです。動画が180日を過ぎるとアクセス頻度が低くなるという要件に最適です。S3 Standard-IAにデータを移行することで、ストレージコストを大幅に削減できるため、最適化に寄与します。

最適解の組み合わせ

  • C と E が最適です。
    • C: 未完了のマルチパートアップロードを削除することで、不要なストレージコストを削減できます。
    • E: アクセス頻度が低くなる動画をS3 Standard-IAに移行することで、コストを最適化できます。

結論

最適な組み合わせは C と E です。
 
 

500-AWS SAP AWS 「理論・実践・一問道場」WAF

 

理論

1. Lambda関数のスケーリングとコールドスタート問題

  • プロビジョンドコンカレンシー: Lambda関数はサーバーレスでスケーラブルですが、トラフィックが急増すると「コールドスタート」が発生し、レイテンシが増加します。プロビジョンドコンカレンシーを使用すると、指定した数のインスタンスが常に保持され、コールドスタートを防げます。

2. データベースのスケーラビリティとコスト最適化

  • Amazon Aurora Serverless: サーバーレスアーキテクチャで、トラフィックの需要に応じて自動的にスケーリングし、アイドル状態時にコストを削減します。これにより、負荷が少ない時期でも効率的にコストを抑えつつ、ピーク時にはスケールアップできます。
  • RDS予約インスタンス: RDSインスタンスの長期的な利用が予測される場合、予約インスタンスを使うと割引が適用され、コスト削減できますが、サーバーレスアーキテクチャほどの柔軟性はありません。

3. セキュリティ対策

  • AWS WAF (Web Application Firewall): SQLインジェクションやクロスサイトスクリプティング（XSS）など、アプリケーション層の脅威に対する保護を提供します。WAFは、悪意のあるリクエストを検出し、ブロックすることができます。
  • AWS Shield Advanced: 主にDDoS攻撃に対する保護を提供します。これを使うことで、トラフィックの急増に伴うサービスの中断を防ぐことができますが、SQLインジェクションやXSS攻撃のようなWeb層の脅威にはWAFが必要です。

4. コンテンツ配信とキャッシュ

  • Amazon CloudFront: 静的コンテンツの配信を高速化し、グローバルに分散したユーザーへ低レイテンシでコンテンツを提供します。また、CloudFrontはWAFと統合でき、セキュリティ強化にも寄与します。

5. SQLインジェクション対策

  • SQLインジェクション攻撃は、ユーザー入力を適切に処理しないアプリケーションに対する一般的な脅威です。これを防ぐためには、ユーザー入力の検証やパラメータ化されたクエリを使用し、データベースアクセスを制限することが重要です。
これらの知識は、AWS上でスケーラブルでセキュアなアプリケーションを構築するために役立ちます。

実践

略

一問道場

質問 #500
ある企業は、AWS上でeコマースのWebアプリケーションを運営しています。Webアプリケーションは、Amazon S3にホストされている静的ウェブサイトで、コンテンツ配信にはAmazon CloudFrontを使用しています。Amazon API Gateway APIは、ユーザーリクエストや注文処理のためにAWS Lambda関数を呼び出します。Lambda関数は、Amazon RDS for MySQL DBクラスターにデータを保存します。このDBクラスターはオンデマンドインスタンスを使用しています。過去12ヶ月間、DBクラスターの使用状況は安定していましたが、最近、WebサイトでSQLインジェクションやWebの脆弱性攻撃が試みられています。顧客からは、ピーク使用時に注文処理時間が遅くなったとの報告があります。この期間、Lambda関数はしばしばコールドスタートをしています。会社の成長に伴い、トラフィックのピーク時にスケーラビリティと低レイテンシのアクセスを確保する必要があります。また、データベースコストを最適化し、SQLインジェクションやWebの脆弱性攻撃に対する保護を追加する必要があります。
この要件を満たすソリューションはどれですか？
A. Lambda関数のタイムアウト値をピーク時に増加させます。データベースにはRDS予約インスタンスを使用します。CloudFrontを使用し、AWS Shield Advancedを購読して、SQLインジェクションやWeb脆弱性攻撃から保護します。
B. Lambda関数のメモリを増加させます。データベースにはAmazon Redshiftに移行します。CloudFrontとAmazon Inspectorを統合して、SQLインジェクションやWeb脆弱性攻撃から保護します。
C. ピーク時にコンピューティングのためにLambda関数にプロビジョンドコンカレンシーを使用します。データベースにはAmazon Aurora Serverlessに移行します。CloudFrontを使用し、AWS Shield Advancedを購読して、SQLインジェクションやWeb脆弱性攻撃から保護します。
D. ピーク時にコンピューティングのためにLambda関数にプロビジョンドコンカレンシーを使用します。データベースにはRDS予約インスタンスを使用します。CloudFrontとAWS WAFを統合して、SQLインジェクションやWeb脆弱性攻撃から保護します。

解説

このシナリオに対する最適な解決策は C です。

解説:

  1. Lambda関数のコールドスタート問題の解決:
      • Webアプリケーションのパフォーマンスを向上させるため、Lambda関数に プロビジョンドコンカレンシー を設定することが最適です。これにより、特定の同時実行数が確保され、コールドスタートを防ぎ、低レイテンシを維持できます。特にトラフィックのピーク時に、Lambda関数が即座に応答できるようになります。
  1. データベースのスケーラビリティとコスト最適化:
      • Amazon Aurora Serverless は、オンデマンドで自動的にスケールし、リクエストに応じて容量を調整します。これにより、通常時のコストを最適化しつつ、ピーク時に必要なスケーラビリティを提供します。Aurora Serverlessは、負荷が低いときにはコストを削減できるため、DBクラスターの使用状況が変動するこのシナリオに適しています。
  1. SQLインジェクションやWeb脆弱性攻撃からの保護:
      • AWS Shield Advanced は、DDoS攻撃からの保護を提供しますが、SQLインジェクションやWebの脆弱性攻撃を防ぐためには Web Application Firewall (WAF) を使用することが一般的です。CloudFrontと統合して、悪意のあるリクエストをブロックできます。Shield AdvancedはDDoS対策として引き続き重要ですが、WAFはSQLインジェクションやXSS攻撃など、アプリケーション層の脅威に対する強力な保護を提供します。

他の選択肢について:

  • A: RDS予約インスタンスはコスト最適化に貢献するかもしれませんが、スケーラビリティの向上やコールドスタートの問題を解決するには不十分です。また、SQLインジェクションやWeb脆弱性攻撃の保護にはAWS WAFやAmazon Shield Advancedの方が適切です。
  • B: Amazon Redshiftはデータウェアハウスサービスであり、トランザクション向けのデータベースとしては不適切です。これにより、パフォーマンスとコストの面で問題が発生する可能性があります。
  • D: RDS予約インスタンスはコスト最適化に役立ちますが、Aurora Serverlessのような柔軟なスケーリングを提供しないため、スケーラビリティの要件に合致しません。また、WAFの使用は適切ですが、Aurora Serverlessの方がパフォーマンスとコスト効率に優れています。

結論:

Cの選択肢が、スケーラビリティの最適化、パフォーマンスの向上、コストの最適化、そしてSQLインジェクションやWeb脆弱性攻撃の保護という要件に最も適しています。
 
 
 
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
48-AWS SAP「理論・実践・10問道場」50-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%