【AWS初学者向け】AWS認定資格DVA直前対策

1. API GatewayでWebSocket APIを作成し，バックエンドにlambda関数を指定し，DynamoDBをデータストアとして利用する。いわゆるRestAPI。
2. AppSyncでGraphQLのSubscriptionをWebSocket経由で利用し，DynamoDBをデータストアとして利用する。

できる。

キャッシュヒットした場合はキャッシュを返し，キャッシュミスした場合はDBからレコードを取得する戦略。いわゆるキャッシュを使った実装そのもの。

• クエリフィルター
  • クエリの取得後にフィルターを適用する
• スキャン制限パラメータ
  • テーブル内の全てのデータを走査するため効率が悪いスキャン操作において，スキャン操作のパフォーマンスを向上させるための条件を指定するための仕組み
• クエリのページサイズ
  • クエリ操作で一度に返されるアイテム数を制限するためのパラメータ。基本的に，1つの Query は1MB以内の結果セットだけを返すが，クエリのLimitパラメータを使用してページサイズを小さくすることができる。

• 遅延読み込み
  • いわゆるキャッシュの利用。キャッシュにデータがあればキャッシュから取り出し，なければDBから値を取りだしつつキャッシュに書き込む戦略。キャッシュのデータが古くなってしまうという問題がある。
• ライトスルー
  • 毎回DBへの書き込みとキャッシュへの書き込みを同時に行う戦略。キャッシュに大量のデータが格納されるという問題がある。
• TTL
  • 遅延読み込みにおけるデータが古くなってしまうという問題を解消しつつ，ライトスルーのキャッシュにデータを大量に格納してしまう問題も解決するための概念。TTLで定めた時間が経過すると，キャッシュからデータが削除される仕組み。

• リソースベースポリシー
  • 「誰がlambda関数を呼び出せるか」を定義する。S3のバケットポリシーと同じようなイメージ。
• 実行ロール
  • lambdaにおけるアイデンティティベースのポリシー。lambdaが使用する権限を定義。

lambdaを特定のイベントソースに関連付けるための仕組み。S3やDynamoDBをソースとして設定できる。

新バージョンのlambdaにエイリアスを割り当て，エイリアスのARNを利用してイベントソースマッピング更新する。これにより，lambdaのバージョンアップおよびロールバック時にイベントソースマッピングを毎回行う必要がなくなる。エイリアスを利用しないと，毎回新バージョンのlambdaのARNを利用してソースマッピングを更新する必要がある。

HeartBeatSecondsで定められた時間をHeartBeatの間隔が超えると，SFが失敗する。ただし，HeartBeatとは長時間実行されるステップが正常に進行していることをSFに通知するための仕組みで，アクティビティワーカーとはSFのステップ内で特定の処理を行うためのコンポーネントである。SFでは，HeartBeatSecondsを超えた状態でHeartBeatを受け取らない場合には，Retry.MaxAttemptの再試行ポリシーによって別のアクティビティワーカーによって当該Jobを再試行することができる。

ハンドラメソッドの外で接続を初期化し，ハンドラメソッドで再利用する。

できる

できない。DynamoDBでは，ストリームを有効にすることでトリガーを設定できる。

• GetItem：プライマリキーを指定して単一のアイテムを取得
• BatchGetItem：プライマリキーを指定して複数のアイテムを取得
• Query：プライマリキーおよびセカンダリインデックスに基づいて複数のアイテムを取得
• Scan：テーブル内のすべてのアイテムから複数のアイテムを取得

ただし，プライマリキーはパーティションキー，もしくはプライマリキーとソートキーの複合プライマリキーのいずれかを指し，セカンダリインデックスはグローバルセカンダリーインデックス，もしくはローカルセカンダリインデックスのいずれかを指す。詳しくはSSA対策を参照されたい。

配置しようと思えば配置できる。例えば，private subnetに配置したRDSにアクセスするlambdaはprivate subnetに置いて，RDSはlambdaにアタッチしたSGからのみアクセスを受け付けるようにする。

他にも，lambdaはユーザが作成したVPCとは別にAWSが管理するVPCに作成することもできる。この場合は，ユーザのVPCで作成したENIがlambdaからの通信を受け付ける。

オンプレサーバにX-Rayデーモンをインストールする。lambdaでPutTraceSegmentsのAPIをコールすることでもX-Rayトレーシングを有効にすることはできるが，X-Rayデーモンを利用した方が効率が良い。

できない。PUT・POST・COPY・DELETEとマルチパートアップロードイベントで発火される。

lambdaを使用して，標準S3のGET・HEADおよびLISTリクエストの出力を自動的に処理する仕組み。

ショートポーリング。

どちらも利用しない。WebSocket APIはHTTP APIやREST APIと並列の概念と捉える。

（APIの）処理が完了した後に遷移するURL

レコードに主キーを埋め込む。メッセージ重複排除IDは，Kinesis Data Streamsでは利用できない。

Kinesis Data Streams。SQSやKinesis Data Firehoseでは，複数のコンシューマが同時にキューを処理できないため不適切。

TransformセクションにおいてSAMのバージョンを指定する。

IAMユーザとアクセスキーを発行し，サーバに認証情報ファイルを作成する。基本的に，権限制御はIAMロールを使う方法がベストプラクティスだが，オンプレミスのサーバや開発者のローカルなど，AWSクラウド外の端点はアクセスキーを直接使って認証するしか方法がないと理解する。

• クラスターエンドポイント：プライマリに接続
• リーダーエンドポイント：レプリカに接続
• インスタンスエンドポイント：各インスタンスに接続
• カスタムエンドポイント：複数のインスタンスに接続

ただし，インスタンスエンドポイントはフェールオーバーに対応しておらず，カスタムエンドポイントはエンドポイントタイプを適切に設定すればフェールオーバにも対応できることに注意する。

• Query：パーティションキーとソートキーで検索する。
• Scan：パーティションキーとソートキー以外の属性で検索する。

• filter-expression（フィルタ式）
  • QueryとScanの後に結果を絞り込む。SQLでいうWHEREのイメージ。
• projection-expression（プロジェクション式）
  • 特定の属性を取得しないようにする。SQLでいうSELECTのイメージ。

ただし，フィルタ式ではパーティションキーとソートキー以外を指定する必要がある点に注意する。また，フィルタ式では適用前の料金が加算されため，Queryで十分絞り込んだ後でフィルタ式を使う，もしくはそのようなテーブル設計を行うべきといえる。

GSIは元々のパーティションキーとソートキーとは別にインデックスを作成したい場合，LSIは元々のパーティションキーとソートキーに加えてインデックスを作成したい場合に有効。

各シャード内のレコードは順序が保証され，各シャード間の順序は保証されない。特に，APIを使ったとしても，LIFOやランダムなどFIFO以外の指定はできない点に注意する。

削除される。重複排除間隔で指定された時間経過後に再度メッセージを送ると，正常に受け付けられる。

putMetricData

API gatewayの機能で，バックエンドから受け取ったデータを加工することができる。

• プロキシ統合：リクエストパラメータの受け渡しは行い，マッピングテンプレートを利用しない。
• 非プロキシ結合：リクエストパラメータの受け渡しは行わず，マッピングテンプレートを使用する。

プロキシ結合ではリクエストパラメータの制限ができないこと，およびプロキシ結合ではマッピングテンプレートの管理が煩雑になる傾向がある点に注意する。また，非プロキシ結合はカスタム結合ともよばれる。統合タイプとしては，プロキシ統合がAWS_PROXY，非プロキシ統合がAWSとなる。

あるイベントがイベントソースに書き込まれた時点と，lambdaがイベントソースからデータをポーリングした時点との差を表す。

lambdaの割り当てメモリを増やすこと。lambdaでは，CPU・ネットワーク帯域・ディスクのI/Oは，lambdaの割り当てメモリに比例して割り当てられる。

35日間。

存在する。

• LSI：強い整合性
• GSI：結果整合性

• LSI：パーティションキーは同じで異なるソートキーを設定できる
• GSI：異なるパーティションキーとソートキーを設定できる

BeanStalkコンテナ内のEC2インスタンスでsqsdデーモンを動作させ，指定されたSQSにメッセージが溜まったときに，そのメッセージを取得する環境を作成する設定のことを指す。つまり，長い時間を要する処理をバックグラウンドで担当するような，EC2で構築された環境のこと。

バージョン番号を指定したオプティミスティックロック。楽観的排他制御と訳されるが，差し当たりは単なる排他制御を捉えておけばよい。

GetSessionToken APIでMFAコードをリクエストパラメータに含めることで，一時的な認証を得ることができる。

CloudFormationで事前に定義された変数。例えばAWS::Regionでは，デプロイされるリージョンを参照できる。

シャード数。

実装するべきでないとベストプラクティスに明記されている。

CloudWatch

パーティションキーの後ろに乱数を付け加える。書き込み時は単に乱数を付け加えれば分散され，読み込み時は乱数以前のパーティションキーで検索する。

• sam local invoke：lambdaをローカルで実行する
• sam local start-lambda：lambdaのエンドポイントをローカルで提供する

512MB

一定時間内に受信可能なリクエスト数を制限し，制限を上回るリクエストは拒否してエラーを返却すること。時間経過によって再び受信可能となる。

同時並行数だけlambdaを事前に立ち上げておく機能。concurrencyは同時実行性という意味。リソースを確保するためコストがかかる。

最も狙われやすいポイントとしては，Parameter Storeは認証情報自動更新ができず，Secrets Managerは認証情報自動更新できるという点。

• APIの設定
  • メソッド認可タイプをAWS_IAMにする
  • 各IAMユーザのみにアクセスを許可するリソースベースのポリシーをAPIにアタッチする
• 発信元での操作
  • アクセス許可を与えるIAMポリシーをIAMユーザにアタッチする
  • 署名バージョン4（Sigv4）プロトコルを利用してAPIリクエストに署名する

他にも，IAMユーザではなくIAMロールを用いた制御方法も挙げられるため，注意する。

• 暗号化されたデータ
• 暗号化されたデータキー

対称暗号化キーは共通鍵暗号の鍵，非対称暗号化キーは公開鍵暗号の鍵と理解する。通常，AWSのKMSでは対称暗号化キーが使われるが，暗号化や署名には非対称暗号化キーが使われる。デフォルトは対称暗号化キー。非対称暗号化キーペアのプライベートキーは，対称暗号化キーによって保護される。非対称暗号化キーは，特殊な要件が求められない限り使う場面は少ない。

• クライアント側：対称暗号化キー（データ自体は共通鍵で暗号化）
• 転送中：非対称暗号化キー（通信路は公開鍵暗号で暗号化）

• ユーザプール：認証
• IDプール：認可

署名付きURL。アプリケーションに対して署名を行うのであって，任意のユーザに対して署名付きURLを発行するわけではないため注意する。

1. AuthorizationというHTTPヘッダに署名を格納する
2. X-Amz-Signatureという名前のクエリパラメータに署名を追加する

特に，1.に関してはAuthenticationと間違えないように注意する。Authorizationは認可なので，署名本来の意味合い的にはAuthenticationの方が正しいように思えるが，HTTPの仕様と理解する。

1. KMS Encrypt API：一つのKMSキーを使用して暗号化する
2. KMS GenerateDataKey API：毎回データキーを取得し，そのキーで暗号化する

• CMK（カスタマーマスターキー）はCDK（カスタマーデータキー）を暗号化する
• CDKはデータを暗号化する

CodeBuildではCMKを指定することで，（裏側でCDKが生成されて）データを暗号化できる。

Lambda@Edge。CloudFront Functionsは軽量な処理を行うワークロードに適している。

x-amz-server-side-encryption: AES256を指定する。

4KB。CMKは，データではなく鍵自体を暗号化することが目的であるため。

提供されない。

API Gatewayでステージ変数ごとにAPIをデプロイし，各ステージ変数に対応するエイリアスをlambda関数で参照する。

ライブラリやその他の依存関係を含む.zipファイルアーカイブをレイヤーとよび，デプロイパッケージにライブラリを含めることなくlambdaでライブラリを使うことが可能になる。

そもそもSAMとはServerless Application Modelの頭文字をとった略称であり，サーバレスアプリケーションの構築を行うことができるオープンソースのフレームワークである。AWSでは，CloudFormationの拡張機能として提供される。基本的に，下記の流れでアプリケーションの構築を行う。

1. sam init
   • Node，Python，Javaなど，アプリケーションの種類を選択
   • アプリケーションに応じたディレクトリ構成を自動構築
   • アプリケーションに応じてデフォルトのツールをインストール
2. sam build
   • アプリケーションのビルド
3. sam deploy
   • CloudFormationを通じてAWS環境にサーバレスアプリケーションが構築

CloudFormationのStackSets。単純にCloudFormationのStackをdeployするだけである場合，複数リージョンにデプロイするためには手動操作が必要になることに注意する。

まず，lambdaには装飾ARNと非装飾ARNが存在する。

• 装飾ARN：バージョンを指定したARN
• 非装飾ARN：バージョンを指定しないARN

非装飾ARNではバージョンを指定しないため，自動で$LATESTを指す仕様になっている。また，バージョンの別名であるエイリアスも，装飾ARNに対しては指定できるが，非装飾ARNに対しては指定できない。

stagevariable（ステージ変数）はAPI gatewayの機能で，lambdaと統合することを目的として利用される。具体的には，lambdaのエイリアス名をdevやprodといった環境名に設定し，API gateway側のステージ変数で環境名を指定すると，API Gatewayとlambdaを連携することができる。

リージョン内で一意。

1. ApplicationStop
2. DownloadBundle
3. BeforeInstall
4. AfterInstall
5. ApplicationStart
6. ValidateService

特に，Applicationを停止させてからinstall関連のフックが発火することに注意する。ダウンタイムを最小化したければ，Applicationを停止させる前にInstallの準備をしておきたい印象があるが，BeforeInstallではバックアップを取得することを踏まえると，サービスが停止していなければ最新のバックアップが取得できないからと理解する。

• sam package：zip化してS3にアップロードする
• sam deploy：configがある場合はzip化してS3にアップロードしてdeployする

Transform

amplify.yml

デプロイパッケージが50MB以上である場合。

APIキーにもとづく使用量プランを利用する。

• run：単発起動
• create-service：実行され続ける

C言語のカスタムランタイムを含む新しいlambdaレイヤーを作成して利用する。

連携できない。CodePipelineとCloudFormationを利用してCI/CDを構築する。

ECSのタスク配置戦略は，ECS on EC2を選択した際にECSをEC2上で起動させる方式のオプションである。

• binback：未使用のCPU/メモリを最小化。インスタンス数を最小限に抑えるコスト最適。
• random：ランダム。
• spread：インスタンスまたはAZ間で均等に配分。可用性最適。

X-Ray。CloudWatchメトリクスは問題を特定する前に利用しようとすると，複雑に相互作用するサービスから問題を特定することが難しいため，X-Rayで問題を特定する。

DynamoDB。RDSではないため注意する。

• xray:PutTraceSegments
  • リクエストの経路や処理時間を送出
• xray:PutTelemetryRecords
  • 追加のメトリクスやイベント情報を送出

AWS SAM（Serverless Application Model）で，API Gatewayとlambdaをデプロイできる。

エラーの再試行間隔を指数関数的に伸ばすという一般的な方法。全く同じ指数関数を利用するとアクセスが集中してしまう可能性があるため，ジッタと呼ばれる時間的なノイズを差し込むことでランダム性を担保している。

1. GetTraceSummaries でトレースIDのリストを取得する
2. BatchGetTraces で1.で取得したトレースIDを指定することで，トレースデータを取得する