Q1 — 単一選択既存システムでは、キャンペーン開始前に担当者がアクセス数を予測してAmazon EC2ワーカーを増設し、終了後に縮小している。
処理はイベント単位へ分離でき、呼び出し間のローカル状態にも依存しない。Serverless化によって現在の容量管理作業を減らしたい場合、最も適切な評価はどれですか。
A. AWS Lambdaを候補にし、イベント量に応じた自動スケーリングで事前増設・事後縮小を減らせるか評価しつつ、同時実行クォータと下流サービスの容量も確認する
B. AWS Lambdaへ移行し、Provisioned Concurrencyを年間を通してキャンペーン時のピーク値へ固定することで現在と同じ容量計画を維持する
C. Amazon ECS on AWS Fargateへ移行し、キャンペーンごとに担当者がDesired Countを手動変更することをServerless化の主な効果とする
D. Amazon EC2 Auto Scalingを導入すればLambdaと同じ実行モデルになるため、イベント単位への分離や呼び出し間状態の評価は不要とする
答えと解説
答え：A
イベント単位で独立して実行できる処理では、Lambdaの自動スケーリングによってピーク前後の手動キャパシティ管理を減らせます。ただし同時実行クォータや接続先サービスの処理能力は別の制約として評価します。
Q2 — 単一選択既存システムでは、REST APIの公開、ルーティング、認証、流量制御のために複数のAmazon EC2プロキシサーバーを常時運用しています。
バックエンド処理はAWS Lambda関数やHTTPサービスとして既に独立しています。
API入口のOperational Overheadを減らすモダナイゼーションとして最も適切なものはどれですか。
A. Amazon API GatewayをAPIの公開・ルーティング・認証などの入口として利用し、バックエンド処理へ接続する
B. 各APIリクエストのたびに新しいAmazon EC2インスタンスを起動し、終了後に削除する
C. AWS AppSyncをREST APIのHTTPメソッドとURLパスをそのまま維持するためだけに使用する
D. API入口のサーバー群を維持し、利用量が少ない時間も固定台数を常時起動する
答えと解説
答え：A
Amazon API GatewayはAPIのマネージドな入口として利用でき、AWS LambdaやHTTPバックエンドなどへ接続できます。
このシナリオでは、ビジネスロジックではなくAPI入口のためだけに維持しているサーバー群がOperational Overheadになっています。
Q3 — 単一選択モバイルアプリ向けにカスタムGraphQLサーバーをAmazon EC2上で運用しています。
GraphQLからAmazon DynamoDB、AWS Lambda、Amazon OpenSearch Serviceへアクセスし、利用者へのリアルタイム更新も提供しています。
GraphQLサーバーのスケーリングと接続管理のOperational Overheadを減らしたいと考えています。
最初に評価すべきサービスはどれですか。
A. AWS AppSync GraphQLを評価し、GraphQLスキーマから複数データソースへ接続し、必要なリアルタイム更新も提供する
B. Amazon API GatewayのREST APIだけでGraphQLスキーマとリゾルバーを自動生成し、リアルタイム購読も同じ仕組みで提供する
C. AWS Lambdaだけを公開エンドポイントとして使用し、GraphQL APIやリアルタイム接続の管理をすべて関数内へ実装する
D. Amazon EC2上の既存GraphQLサーバーを固定台数で維持し、接続管理のOperational Overheadは変更しない
答えと解説
答え：A
AWS AppSync GraphQLはGraphQL APIを提供し、Amazon DynamoDB、AWS Lambda、Amazon OpenSearch Serviceなど複数のデータソースへ接続できます。
GraphQLサブスクリプションによるリアルタイム更新も利用できるため、カスタムGraphQL基盤の運用がモダナイゼーション対象ならServerless Opportunityとして評価できます。
Q4 — 単一選択AWS Lambda関数では同じ実行環境が後続呼び出しで再利用される場合があり、開発者はSDKクライアントをハンドラー外で初期化して再利用している。
注文処理の進捗状態も同じ仕組みで保持したいという提案に対し、最も適切な設計はどれですか。
A. SDKクライアントや静的キャッシュには実行環境の再利用を活用するが、注文進捗はDynamoDBなど耐久性のある外部ストアへ保存し、実行環境が変わっても処理を継続できるようにする
B. Provisioned Concurrencyを設定すれば同じ実行環境が継続利用されるため、注文進捗をモジュールのグローバル変数へ保持する
C. 注文進捗を/tmpへ保存し、実行環境終了時にまとめて永続ストレージへ同期する設計を前提にする
D. Reserved Concurrencyを1に設定して同時実行を防げば、単一の実行環境が維持されるためローカルメモリを永続ストアとして利用する
答えと解説
答え：A
Lambdaの実行環境再利用はSDKクライアントや静的キャッシュの最適化には利用できますが、同じ環境が次回も使われる保証はありません。業務上の永続状態はDynamoDBやAmazon S3などの耐久性のある外部ストアへ保存し、どの実行環境でも処理を継続できる設計にします。
Q5 — 単一選択1日に数百回だけ呼ばれ、その他の時間はほぼアイドル状態の小さな処理を、常時起動したAmazon EC2で実行しています。
処理は短時間かつStatelessで、標準のAWS Lambda関数へ移行できます。
Pay-per-useの観点で最も適切な評価はどれですか。
A. 標準のLambda関数を候補にし、リクエスト数と実行時間に基づく利用量課金を含めて総コストを比較する
B. アイドル時間が長くても常時起動EC2と標準Lambda関数の課金モデルは同じなので比較しない
C. Pay-per-useなら利用量に関係なく必ず最安になるため、実行時間や呼び出し回数を見積もらない
D. Lambdaを選べばProvisioned Concurrencyなど追加のキャパシティ費用も一切発生しないとみなす
答えと解説
答え：A
標準のLambda関数はリクエスト数と実行時間を中心とした利用量課金であるため、長いアイドル時間を持つワークロードではServerless Opportunityになり得ます。
ただしPay-per-useだから必ず最安になるわけではなく、実際の呼び出し回数、実行時間、データ転送、必要な追加機能まで比較します。
また現在のAWS Lambdaには、標準のLambda関数とは異なる料金モデルを持つLambda Managed Instancesもあるため、「Lambdaはすべて同じ課金モデル」と一般化しません。
Q6 — 単一選択Amazon EC2上の常駐プログラムが、共有フォルダを一定間隔で確認しています。
新しいファイルを見つけると内容を検証し、検証結果をデータベースへ保存した後、再び共有フォルダの監視へ戻ります。
この処理からEvent-drivenなServerless Opportunityを切り出す方法として最も適切なものはどれですか。
A. 「ファイルが到着した」というイベントを実行開始条件とし、ファイル検証と結果保存を1回ごとに独立して完了できる処理境界として抽出する
B. 共有フォルダを確認し続ける無限ループをそのまま1回のAWS Lambda呼び出しとして移し、常に実行し続ける
C. 常駐プログラムの起動処理、監視ループ、検証処理、待機処理を区別せず、すべてを1つのイベントとして扱う
D. ファイル到着とは無関係に一定台数のAmazon EC2を維持し、既存の定期監視方式をEvent-drivenと呼び替える
答えと解説
答え：A
ここで判断するのは「イベント駆動ならAWS Lambdaを選ぶ」というサービス選択ではありません。
既存の常駐処理を分析し、ファイル到着 → 検証 → 結果保存という、イベントから開始して1回ごとに完了できる処理境界を抽出します。
これにより、常時監視するプロセス全体ではなく、イベント発生時に必要となる処理部分をServerless Opportunityとして評価できます。どのイベントルーティングサービスを利用するかは後続の設計判断です。