ニアリアルタイムなログ収集・変換・分析基盤の選択
全国のスキー場に設置した約80台の気象観測ゲートウェイが、積雪量と風速のログを絶え間なく送信しています。運用チームは、流れ込むログを継続的に受け取り、おおむね60秒間隔でまとめてオブジェクトストレージに書き出したいと考えています。書き出す前にタイムスタンプの正規化と観測地点マスタの付与という変換処理を挟む必要があり、蓄積されたファイルに対しては後からアドホックな SQL 集計を実行したいという要望もあります。ゲートウェイは今後300台規模まで増える見込みで、サーバーの管理はできる限り避けたいという方針です。
この要件を満たす最も適切な構成はどれですか。
解説を読む（正解: C）
Amazon Data Firehose (旧称 Amazon Kinesis Data Firehose) は、ストリーミングデータを受け取ってバッファリングし、Amazon S3 などの宛先へ自動的に配信するフルマネージドサービスです。配信ストリームにはバッファサイズとバッファ間隔を設定でき、間隔は最短60秒まで短縮できるため「約1分ごとにまとめて書き出したい」という要件にそのまま合致します。さらに Firehose にはレコード変換機能があり、指定した Lambda 関数を Firehose 側が自動的に呼び出して整形やマスタ情報の付与を行えるほか、JSON から Parquet への形式変換もサポートします。S3 に置かれたファイルは Amazon Athena がサーバーレスで直接 SQL クエリできるため、インスタンスを一切運用せずに収集から分析までを完結でき、ゲートウェイが300台に増えても Firehose 側が自動的にスケールします。したがって選択肢 C が最適です。選択肢 A はスケジュール起動のポーリング型であり、継続的に流れてくるログをニアリアルタイムに取り込めず、台数の増加に応じて取得ロジックとエラー処理の運用負荷が跳ね上がります。選択肢 D は Kinesis Data Streams 自体は妥当ですが、コンシューマーを EC2 で自作・運用する手間がかかり方針に反するうえ、Athena は DynamoDB テーブルを標準では直接クエリできません (別途フェデレーテッドクエリ用コネクタの構築が必要です)。選択肢 B は Amazon EBS が単一インスタンスにアタッチするブロックストレージであり、Athena がその上のファイルをクエリすることはできないため、分析基盤の保存先として成立しません。
業務時間のみ使う開発 DB のコスト削減 (2 つ選択)
ある企業の開発チームは、Amazon RDS for MySQL のシングル AZ DB インスタンスを 10 台、開発環境として db.m6i.2xlarge で稼働させています。これらは平日 9 時から 19 時までしか使われず、夜間と週末はまったくアクセスがありませんが、データは翌営業日も引き続き必要です。ワークロードは軽く、CPU 使用率は利用時間帯でも平均 10% 程度で、短時間だけ上がることがあります。コストを削減するために取るべき対応を 2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、D）
使用時間が限られた開発環境のコスト最適化では、「使っていない時間は止める」と「使っている時間も適正なサイズにする」という 2 つの軸を組み合わせるのが定石です。Amazon RDS の DB インスタンスは停止でき、停止中はインスタンス時間の課金が発生せず、ストレージと保持中のバックアップの料金のみとなるため、データは保持したまま夜間や週末の費用をなくせます。Amazon EventBridge Scheduler と AWS Lambda を組み合わせてスケジュール実行すれば、平日夜間と週末の停止・平日朝の起動を自動化できます (A)。加えて、CPU 使用率が平均 10% 程度で短時間だけ上がるという特性は、ベースライン性能が低くクレジットでバーストできる db.t4g 系のバースト可能インスタンスに非常によく合致するため、クラスのダウンサイズも有効です (D)。B は誤りで、自動バックアップの無効化はコスト削減効果がわずかである一方、ポイントインタイムリカバリを失って開発データの復旧手段がなくなるという不当なリスクを負います。C も誤りで、リザーブドインスタンスは対象インスタンスが稼働しているかどうかに関わらず契約期間中ずっと課金されるため、1 日 10 時間・平日のみしか使わない環境では、停止による削減効果を打ち消してしまいます。E はマルチ AZ 配置により待機系のインスタンス料金が追加されるうえ、RDS の待機系レプリカは読み取りにも処理にも使用できないため、要件を満たしません。
開発用 RDS の夜間・週末停止によるコスト削減
あるソフトウェア企業は、開発チーム向けに Amazon RDS for PostgreSQL の DB インスタンスを 12 台運用しています。これらは平日 9 時から 19 時までしか使用されず、夜間と週末は完全にアイドル状態ですが、料金は 24 時間 365 日発生しています。データベースの内容と接続エンドポイントは翌営業日にそのまま利用できる必要があり、運用の手間も最小限に抑えたいと考えています。最もコストを削減できる方法はどれですか。
解説を読む（正解: B）
Amazon RDS の DB インスタンスは実行中の時間に対してインスタンス時間料金が発生します。インスタンスを停止するとこの時間料金の課金が止まり、残るのは割り当て済みストレージ、自動バックアップ、手動スナップショットの料金だけになります。停止中も DB インスタンス識別子とエンドポイント、パラメータグループ、セキュリティグループの設定はすべて保持されるため、起動すれば以前と同じ接続先で利用を再開できます。停止できる期間は連続 7 日間までで、7 日を過ぎると自動的に起動されるという制約がありますが、Amazon EventBridge Scheduler と AWS Lambda を組み合わせて夜間・週末に停止し平日朝に起動するスケジュールを回せば、この制約も自動的に吸収できます。稼働が週 50 時間程度であればインスタンス時間料金を 7 割前後削減できるため、B が最適です。A のインスタンスクラス縮小は時間単価を下げるだけで、使っていない時間帯も課金が続くため削減幅が限られ、開発作業中の性能も低下します。C のリザーブド DB インスタンスは 24 時間 365 日稼働する定常ワークロード向けの割引であり、アイドル時間が大半を占めるこの環境では購入したキャパシティを使い切れず、かえって無駄が増えます。D はスナップショットからの復元となるため、復元のたびに新しいエンドポイントが払い出されてアプリケーションの接続先変更が必要になり、大きなデータベースでは復元に長時間かかるため要件を満たしません。