定期実行するWindowsコンテナジョブのコスト最適な実行基盤
国内の物流企業が、オンプレミスのWindows Server上で .NET Framework を用いて開発した配送状況の集計ジョブを運用しています。このジョブは10分間隔で起動し、毎回数十秒で処理を完了する短時間のバッチです。同社はこのジョブをWindowsコンテナとしてイメージ化したうえでAWSへ移行したいと考えており、サーバーのパッチ適用やスケーリングといった運用作業をなくし、ジョブが動いていない時間にはコンピューティング費用が発生しない構成を望んでいます。移行の労力を最小限に抑えつつコストを最適化できるソリューションはどれですか。
解説を読む（正解: C）
AWS Fargate は Amazon ECS のサーバーレス起動タイプで、コンテナが実行された時間ぶんの vCPU とメモリだけが課金され、基盤となるEC2インスタンスの管理やスケーリングが不要になります。Fargate は Windows コンテナの実行にも対応しているため、.NET Framework のようにWindowsに依存するアプリケーションでも、コンテナイメージ化さえすればコードを書き換えずに移行できます。また Amazon EventBridge Scheduler は、cron式やレート式で定義したスケジュールから直接 ECS の RunTask を呼び出せるため、ジョブスケジューラー用のサーバーを別途用意する必要がありません。この二つを組み合わせるCが、10分ごとに数十秒だけ動くジョブに対して「実行時間ぶんだけ課金」「サーバー管理不要」「アプリ改修不要」をすべて満たす最小労力の構成です。AはECSクラスターの実体がEC2インスタンスであるため、ジョブが動いていない大半の時間もインスタンス料金が発生し、パッチ適用やキャパシティ管理の運用も残ります。Bは .NET Framework で書かれたWindows依存のアプリを Lambda 向けに実装し直す必要があり、移行の労力が最大になるうえ、Windowsコンテナを Lambda で実行することもできません。Dはコンテナを常時稼働させてその中でスケジューラーを動かす構成であり、待機時間にも Fargate 料金が課金され続けるためコスト最適とは言えず、スケジュール管理をコンテナ内に閉じ込めることで可観測性も下がります。
RDS のデータ更新を複数システムへ非同期配信する設計
化粧品の D2C ブランドを展開する企業が、Application Load Balancer 配下の Amazon EC2 インスタンスで受注サイトを運用し、商品マスタを Amazon RDS for PostgreSQL に保持しています。商品の価格や在庫が更新されるたびに、社内の物流システム、レコメンドエンジン、パートナー向け API という 3 つのターゲットへ更新内容を非同期に配信する必要があります。運用チームはデータベースエンジンの変更や既存アプリケーションの大規模改修を避けたいと考えており、可能な限りマネージドサービスだけで実装したいと要望しています。この要件を満たす最も適切なアプローチはどれですか。
解説を読む（正解: C）
Amazon RDS のイベント通知は、DB インスタンスの作成・削除・フェイルオーバー・バックアップ完了・ストレージ不足といったインフラ側のライフサイクルイベントを Amazon SNS や Amazon EventBridge へ通知する仕組みです。Amazon DynamoDB Streams のようにテーブルの行変更を捕捉して外部へ配信する機能は、リレーショナルデータベースサービスには用意されていません。そのためデータの更新を起点とした連携を組む場合は、アプリケーション側から明示的にイベントを発行するか、定期的に差分を取得する方式を採る必要があります。
本シナリオでは、DB エンジンやアプリケーションの大規模改修を避けつつ、更新された商品データを複数のターゲットへ非同期に届けることが求められています。Amazon EventBridge Scheduler で AWS Lambda を定期起動し、更新日時列を手掛かりに前回実行以降の差分行を RDS Proxy 経由で取得して各ターゲットへ配信する構成であれば、マネージドサービスのみで実装できます。Lambda の同時実行によるデータベース接続数の急増も RDS Proxy がコネクションプールとして吸収します。したがって C が正解です。
A と B は「行の追加・更新で RDS のイベント通知が発火する」という誤った前提に立っており、実際にはその通知自体が発生しないため処理が一度も起動しません。さらに B は Amazon SQS の 1 メッセージを 1 コンシューマーだけが取り出すという性質上、同じデータを 3 系統へ届けるファンアウトにも適していません。D については、Amazon SNS に「FIFO キュー」という構成要素は存在せず（存在するのは FIFO トピックです）、サブスクライバーはプッシュ配信を受ける方式であるためポーリング前提の記述も誤りです。
業務時間のみ使う開発 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 の待機系レプリカは読み取りにも処理にも使用できないため、要件を満たしません。