AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

正解

A. 新規に作成する各アイテムに、作成時刻の45日後を表すUnixタイムスタンプ値を持つ属性を追加し、その属性をテーブルのTTL属性として設定する

DynamoDB の TTL は、アイテムごとに指定した有効期限（エポック秒の数値属性）を過ぎたアイテムを、DynamoDB がバックグラウンドで自動削除する機能です。
削除処理に書き込みキャパシティを消費せず、追加料金もかからないため、増え続けるテレメトリデータのストレージ料金を抑える手段として最も安価です。
アプリケーション側は書き込み時に「作成時刻＋45 日」の属性を 1 つ追加するだけで、削除用のコードもスケジューラも不要なので、運用の手間も最小になります。

B. テーブルに新しいアイテムが作成されるたびにAmazon DynamoDB StreamsからAWS Lambda関数を呼び出し、作成から45日を超えたアイテムを削除する処理を実装する

DynamoDB Streams と AWS Lambda を組み合わせれば削除処理は実装できますが、関数の開発・デプロイ・エラー監視・スロットリング対策という運用負荷を自前で抱えることになります。
さらに削除は通常の DeleteItem として書き込みキャパシティを消費して課金されるため、TTL よりコストが高くつきます。
そもそもストリームの契機は「アイテム作成時」であり、その 45 日後に削除するには別途スケジュール実行の仕組みが必要で、構成も複雑化します。

C. DynamoDBのオンデマンドバックアップを日次で取得し、AWS Backupのライフサイクルポリシーで45日を超えたバックアップを自動的に削除するよう運用を切り替える

オンデマンドバックアップと AWS Backup のライフサイクルで消えるのはバックアップの世代であって、テーブル本体のアイテムではありません。
テーブルサイズは増え続けたままで、むしろ日次バックアップの保管料金が上乗せされます。
「45 日」という数字が要件と一致して見えるだけの誤答で、増加するストレージ料金という課題を解決しません。

D. アプリケーション全体をAWS CloudFormationテンプレートでデプロイし、45日ごとにスタックを再作成してから元のスタックを削除する

AWS CloudFormation でスタックを再作成すればテーブルごとデータが失われるため、直近 45 日分を参照するという前提が崩れます。
稼働中のアプリケーションのデータストアを 45 日ごとに作り直す運用は、停止やデータ移行の手間が極端に大きく、「運用の手間を最小」とは正反対です。
IaC はインフラ管理の手段であり、データのライフサイクル管理の仕組みではありません。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
アプリケーションが参照するのは直近 45 日分のみ	期限切れデータをアイテム単位で自動的に消す仕組みが必要 →選択肢（A）は候補
コストと運用の手間を最小限に抑える	TTL は追加料金なし・書き込みキャパシティを消費しない。Lambda 実装は開発と削除課金の両方が乗る →選択肢（A）が正解・選択肢（B）を消す
テーブルのサイズ増加そのものを止めたい	バックアップの保持期間はテーブル本体のサイズに影響しない。むしろ保管料金が増える →選択肢（C）を消す
多数の EC2 インスタンスから書き込み中の稼働システム	スタックの再作成はデータ消失と停止を伴うため、稼働中のデータストアには適用できない →選択肢（D）を消す
TTL を使う際の実装要件	エポック秒（Unix タイムスタンプ）の数値型属性を書き込み時に付与し、テーブルの TTL 属性として 1 つ指定する →選択肢（A）が正解

ひっかけポイント

• TTL 属性は秒単位のエポック時刻を数値型で持たせる必要がある。ミリ秒や ISO 8601 形式の文字列では削除対象にならない
• TTL の削除は即時ではなく期限経過後に数日以内で完了するベストエフォート。厳密な期限削除を問う設問なら別設計になる
• 選択肢 B は「技術的には実現できる」ため残しやすいが、判断軸はコストと運用の手間の最小化。実現可能性ではなく判断軸で切る
• 選択肢 C の「45 日を超えたバックアップを削除」は要件の数字と一致して見えるが、消しているのはバックアップでテーブルのアイテムではない

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「期限切れデータもアーカイブとして残したい」	TTL ＋ DynamoDB Streams で削除イベントを拾い、Amazon S3 へ退避する構成が正解軸に。
「古いデータも参照するがアクセス頻度は低い」	DynamoDB Standard-IA テーブルクラスや S3 へのエクスポートが正解に。
「45 日経過後に厳密かつ即時に削除する必要がある（コンプライアンス要件）」	TTL の削除遅延が許容できないため、自前の削除処理や設計変更が論点になる。
「一部のアイテムだけは恒久的に保持したい」	TTL 属性を持たないアイテムは削除されないという性質を使う設計が正解に。
「テレメトリを時系列で大量に集計分析したい」	Amazon Timestream や S3 ＋ Athena といった分析向けの構成が候補になる。

関連サービスの解説

Amazon DynamoDB