【無料】AWS SOA-C03練習問題10問｜Udemy講師作成

正解：D

A. 特にクォータの確認や引き上げ申請などは不要です。

不正解 30個のt3.xlargeインスタンスを一度に起動することは、多くのリージョンでデフォルトのオンデマンドインスタンス制限を超える可能性が高い数量です。AWSアカウントの新規作成時やリソース使用履歴が少ない場合、クォータは比較的低い値に初期設定されていることが多いため、事前のクォータ確認と必要に応じた引き上げリクエストが必要です。

B. 起動するインスタンスの台数分だけ Elastic IP アドレスを事前に確保します。

不正解 Elastic IPは、EC2インスタンスに関連付けることができる静的なパブリックIPアドレスです。Elastic IPの確保はインスタンスの起動制限とは直接関係がありません。また、すべてのEC2インスタンスがElastic IPを必要とするわけではなく、プライベートサブネット内のインスタンスやパブリックIPが不要なインスタンスには必要ありません。30個すべてのインスタンスにElastic IPが必要かどうかは要件次第です。

C. AWS Trusted Advisorから直接サービスクォータを引き上げます。

不正解 AWS Trusted Advisorは、AWSリソースの最適化、セキュリティ、パフォーマンス、コスト効率、サービス制限に関する推奨事項を提供するツールです。Trusted Advisorは現在のサービスクォータの使用状況を確認することはできますが、クォータそのものを引き上げる機能は提供していません。クォータの引き上げは、Service Quotasコンソールまたはサポートケースを通じて行う必要があります。

D. Service Quotasコンソールからクォータ引き上げをリクエストします。

正解 AWSでは、各リージョンでオンデマンドEC2インスタンスの起動数にデフォルトの制限（クォータ）が設定されています。t3.xlargeインスタンス30個を起動する場合、デフォルトの制限を超える可能性が高いため、事前にService Quotasコンソールから該当インスタンスファミリーのクォータ引き上げリクエストを申請する必要があります。このプロセスには自動承認の場合で数分、手動レビューの場合で数時間から数日かかることがあるため、起動予定日より前に余裕を持って申請します。

全体的な説明

問われている要件

• アジアパシフィック（東京）リージョンで、t3.xlargeインスタンスをオンデマンドで30個起動するキャンペーンを計画していること。
• インスタンスを起動する前に、事前に済ませておくべき準備作業が何かを判断すること。

前提知識

AWSサービスクォータという考え方

• AWSの各サービスには既定の上限値（クォータ）が設定されており、意図しない大量プロビジョニングや予期しない高額請求を抑止する役割を持ちます。
• クォータには申請により引き上げられる「調整可能なクォータ」と、引き上げのできない「調整不可のクォータ」があり、EC2の起動数に関するクォータの多くは前者に属します。
• 適用範囲はリージョンとアカウントの組み合わせ単位であり、同じアカウントでも東京リージョンと別リージョンでは独立して管理されます。

EC2オンデマンドインスタンスのクォータ

• 現在のEC2オンデマンドインスタンスのクォータは、インスタンスの「個数」ではなく合計vCPU数で管理されています。
• t3.xlargeは4vCPUを持つため、30個起動するには合計120vCPUの枠が必要になります。
• クォータはインスタンスファミリーのグループ（Standard、G/VT、Fなど）ごとに分かれて管理されており、あるグループのクォータを引き上げても別のグループには影響しません。
• 新規に作成したアカウントや利用実績の少ないアカウントでは、この初期値が低めに設定されていることが多いです。

Service Quotasによるクォータ管理

• Service Quotasは、AWS各サービスのクォータを一元的に確認・変更できるサービスです。
• コンソール・CLI・APIのいずれからも操作できます。
• 引き上げリクエストは自動承認されるケースと、AWS側の手動レビューを経るケースがあります。
• 手動レビューになった場合は数時間から数日を要することがあるため、リソースが必要になる日より十分前に申請しておく必要があります。

AWS Trusted Advisorとの違い

• Trusted Advisorはコスト最適化・セキュリティ・耐障害性・パフォーマンス・サービスクォータの5分野でベストプラクティスに基づく推奨事項を提示するチェックツールです。
• 現在の使用量とクォータの近接状況を可視化できますが、クォータ値そのものを変更する機能は持ちません。
• クォータを実際に変更するには、Service Quotasコンソールまたはサポートケースを経由する必要があります。

Elastic IPアドレスの位置づけ

• Elastic IPはEC2インスタンスへ関連付けられる静的なパブリックIPアドレスで、リージョンあたりの既定クォータは5個です。
• 停止・起動を繰り返すインスタンスのIPアドレスを固定したい場合などに利用します。
• オンデマンドインスタンスの起動数クォータとは別物であり、これを確保してもインスタンスの起動可否には影響しません。

クォータ引き上げ申請の流れ

• 現在の使用量と必要量を確認し、妥当な引き上げ後の値を算出します。
• Service Quotasコンソールから申請します。
• AWS側の審査（自動または手動）を経て承認されると、新しいクォータ値が反映されます。

画面の解説

アーキテクチャ図

• このスクリーンショットは、Service Quotasコンソールでオンデマンドの標準インスタンスファミリー（A、C、D、H、I、M、R、T、Z）のクォータを表示した画面の例です。
• クォータコードごとに「適用されたクォータ値」と「AWSのデフォルトのクォータ値」が並記されており、現在の値がデフォルトからどれだけ調整されているかを一目で確認できます。
• この画面から「クォータの引き上げをリクエスト」を選択すると、新しい上限値を申請できます。
• ここで確認すべきは個々のインスタンス数ではなく、ファミリー全体で消費するvCPU数に対するクォータであり、起動計画のvCPU合計をこの値と照らし合わせずに大量起動を試みると、途中でリクエストが失敗し、計画していたタイミングを逃すことになります。

解くための考え方

1. 必要リソース量の見積もり: 30個のt3.xlargeインスタンスは合計120vCPUに相当し、既定クォータを超える可能性が高いと認識します
2. リードタイムの確保: クォータ引き上げリクエストが手動レビューになった場合の所要時間を見込んで、余裕をもって事前申請します
3. 正しいツールを選ぶ: クォータを実際に変更できるのはService Quotasコンソール（またはサポートケース）であり、Trusted Advisorは確認のみであることを区別します。Elastic IPの確保は起動数クォータとは別物です。

参考資料

• Service Quotas とは – Service Quotas
• Amazon EC2 サービスクォータ – Amazon Elastic Compute Cloud
• クォータリクエストテンプレートの作成と使用 – Service Quotas

正解：D

A. 各アカウントでAWS Configのカスタムルールを作成し、対象サービスの利用を検知します。

不正解 AWS Configは既存リソースの構成がルールに準拠しているかどうかを継続的に評価し、非準拠を検知して通知する仕組みです。サービスが使われたことを事後的に検知することはできても、そのAPIコール自体を拒否して事前に利用を止める機能は備えていません。今回のような「一切使わせない」という予防的な統制には向きません。

B. 各アカウントでIAMポリシーを作成し、IAMグループにアタッチしたうえで全ユーザーをそのグループに参加させます。同じポリシーのJSON定義を他のアカウントにもそれぞれ複製して設定します。

不正解 IAMポリシーは単一アカウントの中だけで有効なため、20以上のアカウントに展開するには各アカウントで個別に同じ設定作業を繰り返す必要があります。新しいアカウントが増えるたびに手順を再実行しなければならず設定の抜け漏れが生じやすいうえ、IAMポリシーはそのアカウントのルートユーザーの権限を制限できないため、完全な禁止にはなりません。

C. AWS Organizationsで対象アカウントをまとめたOUを作成し、OUにタグポリシーをアタッチします。

不正解 タグポリシーはリソースに付与するタグのキーや値の書式を組織全体で統一するための仕組みで、必須タグの強制やタグ値の検証は行えますが、特定のAPIコールやサービスの実行そのものを拒否する機能は持ちません。OUへの適用方法はSCPと似ていますが、タグの命名規則を統一することとサービスの利用可否を制御することはまったく別の目的です。

D. AWS Organizationsで対象アカウントをまとめた組織単位（OU）を作成し、OUにサービスコントロールポリシー（SCP）をアタッチします。

正解 SCPはOUに一度設定すれば、そのOU配下のすべてのメンバーアカウントに自動的に継承される権限の上限設定です。禁止対象のサービスをDenyするSCPをOUにアタッチするだけで、既存のアカウントはもちろん、後からOUに追加されるアカウントにも即座に同じ制限が適用されます。アカウント内のIAMユーザーやIAMロールだけでなく、そのアカウントのルートユーザーにも制限が及ぶため、抜け道のない禁止を最小の設定変更で実現できます。

全体的な説明

問われている要件

• 複数のAWSアカウントにまたがるガバナンスを一元化する方法が問われていること。
• 既存のアカウントだけでなく、今後追加されるアカウントにも自動的に適用される仕組みを選ぶこと。
• アカウントのルートユーザーを含む、すべての操作を対象にできる方法を選ぶこと。
• アカウント数が増えても、追加の運用負荷をかけずに実現できる方法を選ぶこと。

前提知識

AWS Organizationsと組織単位（OU）について

• 複数のAWSアカウントを横断して同じ制約を強制したい場合、鍵になるのは「誰に」ではなく「アカウントというまとまりに」制約をかけられるかどうかです。
• AWS Organizationsは複数アカウントを1つの組織としてまとめ、組織単位（OU）という階層でアカウントをグループ化する仕組みを提供します。
• OUは子会社や部門ごとにアカウントを整理するのに使われ、あるOUに設定したポリシーはそのOU配下のすべてのアカウント、および後から追加されるアカウントにも自動的に継承されます。

サービスコントロールポリシー（SCP）について

• OUに適用できるポリシーの1つがサービスコントロールポリシー（SCP）です。
• SCPは「そのアカウントで実行できる操作の上限」を定義するポリシーで、Allow（許可の範囲を限定）とDenyの両方を書けますが、実務では特定のサービスやアクションをDenyする使い方が中心になります。
• SCPが優れているのは適用対象の広さで、メンバーアカウント内のIAMユーザー・IAMロールだけでなく、そのアカウントのルートユーザーにも及びます。
• 一方でSCPには見落とされがちな例外が2つあります。組織の管理アカウント（マネジメントアカウント）自体にはSCPは適用されないこと、そしてAWSのサービスリンクロールはSCPの制約を受けないことです。

タグポリシーについて

• 似た仕組みに見えて目的が異なるのがタグポリシーです。
• タグポリシーもOUに適用できますが、扱うのはリソースに付与するタグの命名規則・必須化・値の検証であり、サービスの実行可否には一切関与しません。

IAMポリシーとAWS Configの限界について

• IAMポリシーとAWS Configはどちらも便利な機能ですが、いずれも「アカウント単位」で完結する仕組みです。
• IAMポリシーはそのアカウント内のプリンシパルに対する許可・拒否を定義するもので、複数アカウントに展開するには各アカウントで同じ設定を繰り返す必要があり、しかもルートユーザーの権限には及びません。
• AWS Configは既存の設定がルールに準拠しているかを継続的に評価する監査サービスであり、非準拠を検知して通知はできても、APIコール自体を差し止める予防的な制御はできません。

解くための考え方

1. まず「全アカウント・将来のアカウントにも自動適用されるか」で絞り込みます。単一アカウント完結のIAMポリシーはこの時点で候補から外れます。
2. 次に「事前に止められるか、事後検知に留まるか」を確認します。Configは事後評価の仕組みなので予防的な禁止には不向きです。
3. 残るSCPとタグポリシーは同じOUという入れ物を使いますが、Denyできる対象が異なります。タグポリシーはサービス制御機能を持たないため除外されます。
4. 最後に、ルートユーザーにも及ぶかを確認すると、SCPだけが全要件を満たします。

SCPをOUにアタッチすると、アカウント数が増えても同じ統制を維持できます。

参考資料

• サービスコントロールポリシー (SCP) – AWS Organizations
• 組織単位 (OU) の管理 – AWS Organizations
• AWS Organizations とは – AWS Organizations

正解：C

A. アップロードから31日目以降のファイルをS3 Glacier Flexible Retrievalへ移行するライフサイクルルールを設定します。

不正解 S3 Glacier Flexible Retrievalは長期保管を前提としたアーカイブ用クラスで、取り出しには数分から数時間を要します。迅速取得を選んでも数分の待ち時間が発生するため、「職員がいつでも即座に開ける」という要件には合いません。年に数回程度しか参照されないデータの保管には適していますが、今回の証憑のように突発的に確認が必要になるデータには不向きです。

B. アップロードから30日を過ぎたファイルには誰もアクセスできないようにバケットポリシーを設定します。

不正解 バケットポリシーはアクセスの許可・拒否を制御する仕組みであり、ストレージクラスやコストには影響しません。この設定はむしろ30日を過ぎたファイルへのアクセスを職員自身から奪ってしまい、「いつでも即座に開ける」という要件に真っ向から反します。

C. アップロードから31日目以降のファイルを低頻度アクセスストレージクラスへ移行するライフサイクルルールを設定します。

正解 S3 Standard-IA（Standard-Infrequent Access）は、アクセス頻度は低いものの必要になったときには即座に取得したいデータのために設計されたストレージクラスです。取得時のレイテンシーとスループットはS3 Standardと同じで、職員が思い立ったときにすぐファイルを開けるという要件を満たします。ストレージ単価はStandardの約半分に抑えられるため、めったに開かれない証憑をまとめて移行すればコスト削減の効果も得られます。

D. S3バケットのバージョニングを有効化します。

不正解 バージョニングは同じオブジェクトキーに対して複数の版を保持し、誤削除や上書きからデータを守るための機能です。有効化すると古い版もストレージに残り続けるため、むしろ保存容量とコストが増える方向に働きます。データ保護の目的では有用ですが、今回のようなストレージコスト削減には寄与しません。

全体的な説明

問われている要件

• ストレージコストを削減すること。
• 職員がファイルへ即座にアクセスできる状態を維持すること。
• アップロードから30日を境にアクセス頻度が落ちるという利用パターンを活かした解決策を選ぶこと。

前提知識

S3のストレージクラスについて

• Amazon S3はアクセス頻度に応じて複数のストレージクラスを使い分けられるサービスです。もっとも頻繁にアクセスされるデータ向けのS3 Standardを基準に、アクセス頻度が下がるほど単価が安くなる代わりに何らかの制約が付くクラスが用意されています。
• S3 Standard-IAとS3 One Zone-IAは「取得速度はStandardと変わらないが単価が安い」という中間的な位置づけです。Standard-IAはStandardと同等の複数AZ耐久性を保ちながら単価を約半分に抑え、One Zone-IAは単一のアベイラビリティーゾーンにしか保存しない代わりにさらに割安になります。
• 取得に数分から数時間、あるいは半日以上を要するS3 Glacierアーカイブ系のクラス（Flexible Retrieval、Deep Archive）は、取得速度を犠牲にしてより安価な長期保管に振り切ったクラスであり、四半期に一度程度しか参照しないアーカイブ向けです。
• 同じGlacier系でもS3 Glacier Instant Retrievalは取得速度の面で例外にあたり、アクセス頻度の想定はFlexible Retrievalに近い一方、取得のレイテンシーとスループットはS3 Standardと同水準を維持したまま単価だけを下げたクラスで、即時性を保ちたい低頻度データに向いています。
• アクセスパターンが読めない場合はS3 Intelligent-Tieringが監視料金と引き換えに自動で最適なクラスへ振り分けてくれます。

S3ライフサイクルルールについて

• これらのクラス間の移動は、S3ライフサイクルルールを使ってオブジェクト作成からの経過日数を基準に自動化できます。移行は必ずより安価なクラスへ向かう一方通行で、削除ルールを組み合わせることも可能です。
• 2026年7月のアップデートにより、S3 StandardからStandard-IA・One Zone-IAへ移行させる際に必須だった「作成から30日待つ」というライフサイクル側の制約自体は撤廃され、作成当日からでも移行できるようになりました。
• ただし、これはライフサイクルの移行タイミングの制約が緩和されただけで、Standard-IA・One Zone-IAの料金には現在も最小保存期間30日分の課金が適用されます。
• つまり移行直後にファイルを削除・移動しても30日分の保存料金は発生するため、実際にアクセスが落ち着くタイミングまで待って移行する運用は今回のケースのように依然として合理的です。

バケットポリシーとバージョニングとの違いについて

• バケットポリシーはアクセス許可の制御に特化した仕組みで、ストレージクラスや物理的な保存コストには影響しません。
• バージョニングはデータ保護のための機能であり、旧バージョンが残ることでむしろ保存量が増える点に注意が必要です。

解くための考え方

1. 「いつでも即座にアクセスできる」という要件から、取得に時間のかかるアーカイブ系クラスをまず除外します。
2. 「ストレージコストを削減する」という要件から、コストに影響しない機能（バージョニング）や、コスト削減効果のない機能を除外します。
3. アクセス制限をかける選択肢は、要件が求める「いつでもアクセス可能」と正反対の効果を生むため除外します。
4. 残るS3 Standard-IAへのライフサイクル移行が、速度・コストの両方を満たす唯一の選択肢として残ります。

30日を過ぎるとほとんど参照されなくなるという利用パターンと、Standard-IAが持つ即時アクセス性・低コストという特性は合致しており、31日目以降に移行するライフサイクルルールがもっとも合理的な設定です。

参考資料

• Amazon S3 ストレージクラス – Amazon Simple Storage Service
• S3 ライフサイクル設定の管理 – Amazon Simple Storage Service
• S3 Standard-IA ストレージクラス – Amazon Simple Storage Service

正解：C

A. このサーバーにElastic IPアドレスを割り当てます

不正解 プライベートサブネット内のインスタンスにElastic IPを割り当てても、そのサブネットのルートテーブルにインターネットゲートウェイへの経路がなければインターネット接続は成立しません。仮に経路を追加すれば接続は可能になりますが、その時点でそのサブネットは実質的にパブリックサブネットとなり、外部からの直接接続を避けたいという要件そのものに反してしまいます。

B. サブネットのNACL（ネットワークアクセスコントロールリスト）を更新します

不正解 NACLはサブネット単位で通信を許可・拒否するフィルタ機能であり、既存の経路上のトラフィックを制御するだけで、新たにインターネットへの接続経路を作り出す機能は持ちません。ルーティング経路が存在しない状態でNACLをどう変更してもインターネットアクセスは実現できません。

C. NATゲートウェイを作成し、プライベートサブネットのルートテーブルを更新します

正解 NATゲートウェイは、プライベートサブネット内のインスタンスが安全にインターネットへアウトバウンド接続するための標準的な手段です。パブリックサブネットに配置したNATゲートウェイを経由させることで、更新パッケージのダウンロードに必要な外向き通信は許可されますが、インターネット側からこのサーバーへ新規に接続を開始することはできません。実現にはプライベートサブネットのルートテーブルに0.0.0.0/0宛のトラフィックをNATゲートウェイへ向けるルートを追加します。

D. サーバーのセキュリティグループで0.0.0.0/0からのインバウンド通信を許可します

不正解 セキュリティグループで0.0.0.0/0からのインバウンドを許可すると、インターネット上のあらゆるIPアドレスからの接続を受け入れることになり、深刻なセキュリティリスクを招きます。加えて、プライベートサブネットはインターネットゲートウェイへの経路そのものを持たないため、この設定だけではインターネットへの接続経路は生まれません。

全体的な説明

問われている要件

• プライベートサブネットに置いたインスタンスから、外部からの直接接続を許さないまま、インターネットへのアウトバウンド通信だけを実現する方法が問われていること。
• OSのセキュリティパッチや解析ライブラリの更新パッケージを、定期的にインターネットから取得できるようにすること。
• 外部からこのサーバーへ直接接続されることは避けること。
• パッチ取得という外向きの通信要件と、外部からの侵入経路を作らないというセキュリティ要件を両立させる方法を選ぶこと。

前提知識

パブリックサブネットとプライベートサブネットについて

• VPC内のサブネットがパブリックかプライベートかは、そのサブネットのルートテーブルがインターネットゲートウェイへの経路を持つかどうかで決まります。
• インターネットゲートウェイへの経路を持つサブネットはパブリックサブネットと呼ばれ、外部からの直接アクセスを受けるWebサーバーや踏み台サーバーなどに使われます。
• そのような経路を持たないプライベートサブネットは外部から直接到達できないため、データベースや今回のバッチ処理サーバーのように内部完結で動作させたいリソースの配置場所として選ばれます。

NATゲートウェイについて

• プライベートサブネットから外向きの通信だけを行いたいときに使うのがNATゲートウェイです。
• NATゲートウェイはAWSが可用性とスケーリングを管理するマネージド型のアドレス変換サービスで、必ずパブリックサブネットに配置し、専用のElastic IPを1つ関連付けて使います。
• プライベートサブネット側では、ルートテーブルの0.0.0.0/0宛のデフォルトルートをこのNATゲートウェイに向けることで、内部のインスタンスはインターネット上のリソースへアクセスできるようになります。
• 重要なのはこの通信がアウトバウンド専用である点で、インターネット側から新規にセッションを開始してNATゲートウェイ経由でプライベートサブネットへ到達することはできません。
• 自前でNATインスタンスを構築して同じ役割を持たせることも可能ですが、その場合は可用性確保やスケーリングを利用者側で設計する必要があり、運用負荷はNATゲートウェイより高くなります。

セキュリティグループ・NACL・Elastic IPの役割について

• セキュリティグループやNACLはあくまで「すでにある経路上」の通信を許可・拒否するフィルタであり、経路そのものを作り出す機能ではありません。
• セキュリティグループはインスタンス単位でステートフルに動作し、既定ではすべてのインバウンドを拒否します。0.0.0.0/0からのインバウンドを許可するルールを足しても、そもそもプライベートサブネットにインターネットゲートウェイへの経路がない限り外部との通信は成立せず、逆に経路がある環境でこの設定を行えば無差別な着信を許してしまいます。
• NACLはサブネット単位でステートレスに動作し許可・拒否の両方を明示的に設定できますが、これもトラフィック制御のみでルーティング機能は持ちません。
• Elastic IPは静的なパブリックIPアドレスを付与する仕組みにすぎず、それ自体が経路を作るわけではないため、ルートテーブルの設定と組み合わせない限り接続性には影響しません。

解くための考え方

1. まず「経路を作る機能か、既存の経路上を制御する機能か」で選択肢を分けます。セキュリティグループの変更、NACLの変更、Elastic IPの割り当ては、いずれもプライベートサブネットに新しい経路を作りません。
2. 次に「外部からの直接接続を避ける」という要件から、インバウンドを広く開ける設定や、サブネットを実質パブリック化する設定を除外します。
3. 残るNATゲートウェイの作成とルートテーブル更新が、アウトバウンド専用の経路を安全に確立できる唯一の選択肢です。

NATゲートウェイをパブリックサブネットに作成し、プライベートサブネットのルートテーブルにデフォルトルートを追加する構成が、外部からの侵入経路を作らずにソフトウェア更新を実現する標準的な方法です。

参考資料

• VPC の NAT ゲートウェイ – Amazon Virtual Private Cloud
• プライベートサブネットの設定 – Amazon Virtual Private Cloud
• ルートテーブル – Amazon Virtual Private Cloud

正解：D

A. Amazon GuardDutyを有効化し、異常なアクティビティを検出します。

不正解 Amazon GuardDutyは機械学習を用いて異常なアクセスパターンや既知の悪意あるIPアドレスからのアクセスを検出する脅威検出サービスです。異常が疑われる場合にのみ検知結果を出す仕組みのため、正常なアクセスも含めたすべてのリクエストを漏れなく記録するという要件1を満たせません。

B. S3バケットポリシーで、すべてのアクセスリクエストをAmazon CloudWatch Logsに記録するよう設定します。

不正解 バケットポリシーはアクセスの許可・拒否を定義するJSON形式のポリシーであり、ログを記録する機能そのものを持ちません。またS3にはアクセスログを直接CloudWatch Logsへ送信する仕組みも存在しないため、この構成を実現するにはLambda関数などの仲介処理を別途組む必要があり、バケットポリシーの設定だけでは要件を満たせません。

C. AWS Configを使用して、S3バケットの構成変更を監視します。

不正解 AWS Configはバケットポリシーやパブリックアクセス設定といったバケット自体の構成変更を記録・評価するサービスであり、個々のオブジェクトに対する読み取りやダウンロードといったアクセスリクエストそのものは記録しません。「すべてのアクセスリクエストを記録する」という要件1を満たせません。

D. S3バケットのサーバーアクセスログを有効化し、Amazon Athenaでログをクエリします。

正解 S3サーバーアクセスログは、バケットに対するGET・PUT・DELETEなどのリクエストをベストエフォートで1件ごとに記録するS3の標準機能で、要件1を実務上満たします。ログにはリクエスト時刻、送信元IPアドレス、リクエスト元、実行された操作、対象オブジェクトのキーなどが含まれます。ログファイルはS3上に保存されるテキストファイルなので、Amazon AthenaからSQLで直接クエリして過去の履歴を検索・集計でき（要件2）、S3に置かれたデータであるがゆえに他のAWSサービスや外部ツールからも自由に読み出して分析できます（要件3）。

全体的な説明

問われている要件

• バケットへのすべてのアクセスリクエストを記録すること。
• 記録した過去のリクエスト履歴を、クエリ可能な形式で保持すること。
• 必要に応じてログデータを他のサービスと連携して分析できるようにすること。
• これら3つの要件を同時に満たす監査ソリューションを選ぶこと。

前提知識

AWS Configと構成変更の監査について

• S3バケットへのアクセスを監査する際にまず区別すべきは、「バケットの設定がどう変わったか」を追う仕組みと、「バケットに対して何のリクエストが行われたか」を追う仕組みは別物だという点です。
• AWS Configは前者に特化しており、バケットポリシーの変更やパブリックアクセスブロック設定の変更といった構成変更を継続的に記録・評価しますが、GETやPUTのような個々のオブジェクトへのリクエストは対象外です。
• 今回の要件が求めているのは後者、つまりオブジェクトレベルのアクセスそのものの記録なので、Configだけでは要件を満たせません。

S3サーバーアクセスログとAmazon Athenaについて

• オブジェクトレベルのアクセスを記録する代表的な仕組みがS3サーバーアクセスログです。これはソースバケットに対するリクエストの詳細（リクエスト時刻、送信元IP、実行されたオペレーション、対象オブジェクトキー、レスポンスのステータスコードなど）を、指定したターゲットバケットにテキスト形式のログファイルとして出力し続ける機能で、通常は数時間以内にログが配信されます。
• ログはS3オブジェクトとして保存されるため、そのままではテキスト検索しかできませんが、Amazon Athenaを使えばログの形式に合わせたテーブルを定義し、標準SQLで過去の履歴を横断的に検索・集計できます。
• Athenaはサーバーレスでスキャンしたデータ量に応じた従量課金のサービスであり、AWS Glueのデータカタログと組み合わせてパーティション分割すればクエリ性能もさらに向上します。
• S3に置かれたログはAthena以外のサービスや外部のBIツールからも読み出せるため、「他サービスとの連携」という要件も自然に満たされます。

CloudWatch LogsとAmazon GuardDutyとの違いについて

• CloudWatch LogsはS3のアクセスログを直接受け取る経路を持っていません。S3からCloudWatch Logsへログを流すにはLambda関数などで能動的に転送する仕組みを別途構築する必要があり、そもそもバケットポリシー自体にはログを生成する機能がないため、選択肢が想定する構成は成立しません。
• Amazon GuardDutyはS3データイベントを含む挙動を分析して異常なアクセスパターンを検知する脅威検出サービスですが、目的は異常検知であり、正常なアクセスも漏れなく記録し続ける監査ログとは性質が異なります。

解くための考え方

1. 「すべてのアクセスリクエストを記録する」という要件から、構成変更のみを追うConfigと、異常検知に特化したGuardDutyをまず除外します。
2. 「クエリ可能な形式で保持する」という要件から、ログを生成する機能を持たないバケットポリシー単体の案を除外します。
3. 残るサーバーアクセスログは、記録・保存・クエリ・他サービス連携のすべてを自然に満たす組み合わせとして残ります。

S3サーバーアクセスログとAthenaを組み合わせる構成は、追加のインフラを構築せずに3つの要件をまとめて満たせる、もっとも直接的なソリューションです。

参考資料

• サーバーアクセスのログ記録 – Amazon Simple Storage Service
• Amazon Athena とは – Amazon Athena
• Amazon S3 アクセスログを使用したリクエストの分析 – Amazon Athena

正解：B

A. インスタンスタイプをdb.m5.largeに変更し、CPUとメモリのリソースを増強します。

不正解 インスタンスタイプの変更はCPUとメモリのリソースを増やす効果はありますが、EBSベースのストレージI/O性能そのものを直接引き上げるものではありません。一部のインスタンスタイプではEBS帯域幅の違いにより間接的な改善が見られる場合もありますが、原因がストレージスループットと特定されている今回のケースでは、根本的な解決策にはなりません。

B. ストレージタイプをプロビジョンドIOPS（io1）に変更します。

正解 ボトルネックがストレージスループットだと明確に特定されているため、ストレージそのものの性能を底上げする対処が直接的に効きます。汎用SSD（gp2）はボリュームサイズに比例したベースラインIOPS（1GiBあたり3IOPS、最小100IOPS）にバーストクレジットを組み合わせて動く方式のため、db.t3.medium程度の中規模データベースでは持続的な高負荷時に性能が頭打ちになりやすい構成です。プロビジョンドIOPS（io1）はボリュームサイズとは切り離して必要なIOPS値を明示的に指定でき、MySQLエンジンでは最大256,000IOPSまで設定可能で、バーストに頼らない安定したI/O性能を継続的に提供します。

C. データベースキャッシュを強化し、I/Oリクエストの発生自体を減らします。

不正解 InnoDBバッファプールなどのキャッシュを拡張すれば、頻繁に参照されるデータをメモリ上に保持できるためディスクI/Oはある程度減らせます。しかしキャッシュに収まらないデータへのアクセスやキャッシュミスが発生する状況、そしてトランザクションログや書き込みデータのディスクへの反映は、キャッシュの有無にかかわらず必ずストレージI/Oを伴うため、ストレージスループット不足という根本問題の解決には至りません。

D. 読み取りレプリカを作成し、読み取りクエリの負荷を分散します。

不正解 読み取りレプリカは読み取りクエリの負荷をプライマリDBから逃がす有効な手段ですが、今回の問題はストレージ層のI/Oスループット不足であり、CPUやメモリの飽和ではありません。読み取りレプリカを追加してもプライマリDB自体のストレージスループットは変わらず、書き込み処理は引き続きプライマリDBのストレージを経由するため、根本原因への対処にはなりません。

全体的な説明

問われている要件

• RDS for MySQLインスタンスで、ストレージスループットがボトルネックになっていると特定されていること。
• この原因に直接効く対処を選ぶこと。
• CPU・メモリ・レプリケーションなど別レイヤーの対処に飛びつかず、指摘されたレイヤーそのものを見て解決策を選ぶこと。

前提知識

汎用SSD（gp2/gp3）について

• Amazon RDSのストレージタイプは、性能の出し方が根本的に異なる2系統に大別できます。
• 1つは汎用SSD（gp2/gp3）で、ボリュームサイズに応じて決まるベースライン性能にバーストクレジットを組み合わせて動く方式です。
• gp2は1GiBあたり3IOPS（最小100IOPS）がベースラインで、容量が小さいうちは一時的に3,000IOPSまでバーストできますが、バーストクレジットを使い切ると設定容量に応じたベースラインまで性能が落ち込みます。
• gp3はベースラインとバースト性能の考え方を整理し、20GiB以上であれば容量に関わらず3,000IOPS・125MB/sを基本性能として保証し、必要に応じてIOPSとスループットを個別に追加プロビジョニングできる点がgp2との大きな違いです。

プロビジョンドIOPS SSD（io1/io2）について

• もう1つの系統がプロビジョンドIOPS SSD（io1/io2）で、こちらはボリュームサイズと切り離して必要なIOPS値を直接指定する方式です。
• io1・io2はいずれもMySQLエンジンで最大256,000IOPSまで設定でき（SQL Serverでは上限が64,000IOPSにとどまるなど、上限値はデータベースエンジンによって異なります）、バーストに依存しない一定した性能を継続的に発揮します。
• io2はio1の後継にあたる世代で、耐久性が99.999%（io1は99.8〜99.9%）まで引き上げられており、AWSは同価格帯であるio2への切り替えを推奨しています。
• 持続的に高いI/O負荷がかかるデータベースワークロードでは、バースト前提のgp2よりもプロビジョンドIOPS系のストレージの方が安定した性能を出しやすいという特性があります。

パフォーマンス切り分けと他の対処法との違いについて

• パフォーマンス問題を切り分ける際は、CloudWatchのReadIOPS・WriteIOPS・ReadLatency・WriteLatency・QueueDepthといったストレージ関連メトリクスと、CPUUtilizationやFreeableMemoryといったコンピューティング関連メトリクスを区別して確認します。
• 読み取りレプリカはCPUやメモリが読み取りクエリで飽和している場合には有効ですが、書き込みは常にプライマリDBのストレージを経由するため、ストレージI/O自体のボトルネックには効果がありません。
• 同様に、インスタンスタイプの変更はCPU・メモリ・ネットワーク帯域を増強しますが、EBSストレージそのものの性能を直接引き上げるものではありません。
• InnoDBバッファプールなどのキャッシュ最適化はディスクI/Oを減らす効果があるものの、キャッシュミスや書き込み処理、トランザクションログの反映は避けられないため、ストレージ層の性能不足を根本的に解消することはできません。

解くための考え方

1. 問題文で「ボトルネックのレイヤー」がストレージスループットだと明示されている点に注目し、そのレイヤーに直接効く選択肢を優先します。
2. 読み取りレプリカとインスタンスタイプ変更は、それぞれ読み取り負荷分散とコンピューティング増強という別レイヤーへの対処であるため除外します。
3. キャッシュ強化はI/Oを減らす効果はあっても、書き込みやキャッシュミス時のI/Oは避けられないため根本解決にはならず除外します。
4. 残るプロビジョンドIOPSへの変更が、ストレージ性能そのものを直接引き上げる唯一の選択肢として残ります。

ストレージタイプをio1に変更し、ワークロードに見合ったIOPSを明示的に確保すると、ストレージ性能そのものを直接引き上げられます。

参考資料

• Amazon RDS ストレージタイプ – Amazon Relational Database Service
• DB インスタンスストレージ – Amazon Relational Database Service
• Amazon RDS Performance Insights の使用 – Amazon Relational Database Service

正解：D

A. 他リージョンにリードレプリカを配置し、障害時に手動で昇格させる運用にします。

不正解 クロスリージョンのリードレプリカはリージョン障害への備えにはなりますが、常に元のDBインスタンスとほぼ同期した状態を保つため、レコードが誤って削除されるとその変更は即座にレプリカ側にも伝わってしまい、削除前の状態への復元手段にはなりません。特定時点の保持機能もなく、EC2やEFSなど他サービスの一元管理にも対応しないため、要件のごく一部しか満たせません。

B. 定期的に手動スナップショットを取得し、都度別リージョンへコピーする運用に切り替えます。

不正解 手動スナップショットのコピーで技術的に別リージョンへの複製は可能ですが、取得のタイミング管理、コピー実行、古いスナップショットの削除をすべて人手で行う必要があり、28日間という保持期間の管理も自前で作り込む必要があります。運用負荷が高くヒューマンエラーのリスクも大きい上、EC2やEFSなど他サービスとの統合管理にも対応できないため、長期運用には不向きです。

C. 自動バックアップの保持期間を28日に変更し、バックアップの自動レプリケーション先を他リージョンに設定します。

不正解 RDSの自動バックアップは保持期間を1〜35日の範囲で設定できるため28日への変更自体は可能で、クロスリージョン自動バックアップレプリケーションを有効にすれば別リージョンへの自動コピーとポイントインタイム復旧にも対応できます。しかし、この機能はRDSインスタンス単体の保護に閉じており、EC2やEFSなど他のAWSサービスのバックアップを同じ仕組みで一元管理することはできないため、要件の一部を満たせません。

D. AWS Backupでバックアッププランを作成し、コピー先ルールで別リージョンへ複製します。

正解 AWS Backupは、この4つの要件を単一の仕組みで満たせる唯一の選択肢です。バックアッププランにはスケジュールと保持期間（28日間は容易に設定可能）を定義でき、コピー先ルールを追加するだけでバックアップが自動的に別リージョンへ複製されます。ポイントインタイム方式の復元にも対応するため誤削除への対応も速く、RDSに加えてEC2やEFSなど対応する複数サービスを同じバックアッププランと管理コンソールでまとめて扱えるため、将来の対象拡大にも追従できます。

全体的な説明

問われている要件

• 大規模障害時に、データを別リージョンへ復旧できるようにすること。
• バックアップの保持期間を28日間まで延ばすこと。
• 誤って削除されたレコードを速やかに復元できるようにすること。
• 将来的にEC2やAmazon EFSなど複数のAWSサービスのバックアップも一元管理できるようにすること。
• RDS単体で完結する方法と、複数サービスにまたがって使える方法のどちらが最後の条件をクリアできるかがポイントであること。

前提知識

この問題の判別軸について

• この設問を解くカギは「4つの要件のうち、どれか1つでも満たせない選択肢は不正解になる」という発想です。
• 特に4番目の「EC2やEFSなど複数サービスの一元管理」は、RDSの機能だけでは原理的に到達できない条件であり、ここが最大の判別軸になります。

RDSがネイティブに持つ保護機能について

• RDSがネイティブに持つ保護機能は3種類あります。
• 自動バックアップは1〜35日の範囲で保持期間を設定でき、5分間隔のトランザクションログによってポイントインタイム復旧ができるほか、クロスリージョン自動バックアップレプリケーションを有効にすれば別リージョンへスナップショットとログを自動コピーできます。ただしこの仕組みはRDSインスタンスの保護に特化しており、対象を他サービスに広げることはできません。
• 手動スナップショットはユーザーが任意のタイミングで作成・コピー・削除を制御できる反面、スケジュール管理や保持期間の運用をすべて手作業で行う必要があり、規模が大きくなるほど破綻しやすくなります。
• リードレプリカは読み取り負荷分散や低レイテンシーアクセス、災害時の昇格による復旧を主目的とした機能で、常時最新データと同期しているためバックアップの代わりにはならず、誤削除されたデータの復元にも使えません。

AWS Backupについて

• AWS Backupは、RDS・EC2・EBS・EFS・DynamoDB・Storage Gateway・FSxなど幅広いAWSリソースを対象に、単一のバックアッププランでスケジュール、保持期間、クロスリージョンへのコピー先ルールをまとめて定義できるサービスです。
• バックアップ対象はタグやリソースIDで柔軟に指定でき、実行にはIAMロールを、暗号化にはKMSキーを利用します。
• さらにコンプライアンス要件が厳しい環境では、Backup Vault Lockを使ってバックアップボールトにWORM（Write Once Read Many）ポリシーを適用し、保持期間中の削除や短縮を運用者自身も含めて禁止することができます。

クロスリージョンバックアップ戦略の設計について

• クロスリージョンでのバックアップ戦略を設計する際は、地理的に十分離れたリージョンを選ぶこと、データ保護規制への適合、復旧時のアクセス性能、データ転送コストを総合的に検討します。
• RTO（復旧時間目標）とRPO（復旧時点目標）のバランスを取ることが基本的な考え方になります。

解くための考え方

まず4条件をすべて書き出し、各選択肢がどこで脱落するかを1つずつ確認します。手動スナップショットは運用負荷、リードレプリカは誤削除への無力さで早期に除外できます。残るRDS自動バックアップ延長とAWS Backupは、リージョン間コピーや保持期間の面ではどちらも要件を満たしますが、「複数サービスの一元管理」という条件だけはRDS自動バックアップでは満たせません。単一サービスの機能なのか、AWSリソース全体を横断できる管理サービスなのかという軸で選ぶのがこの問題の要点です。

参考資料

• AWS Backup とは – AWS Backup
• Amazon RDS のバックアップと復元 – Amazon Relational Database Service
• AWS Backup を使用した Amazon RDS リソースのバックアップ – AWS Backup

正解：A

A. 2つのVPCの間にVPCピアリング接続を確立します。

正解 VPCピアリング接続は、異なるアカウント・異なるリージョンにあるVPC同士でもプライベートなルーティングを実現できる接続方式です。AWSの既存ネットワークインフラストラクチャ上で完結するため、物理的な機器や専用線の調達は不要で、設定も比較的短時間で完了します。接続自体に料金はかからず、発生するのはリージョン間のデータ転送料金のみのため、今回のような費用対効果を重視するケースに適した選択です。重複しないCIDRブロックという条件も、ピアリング接続の前提条件を満たしています。

B. Site-to-Site VPN接続を新たに確立します。

不正解 Site-to-Site VPNは、インターネット経由の暗号化されたIPsecトンネルでオンプレミス環境とVPCを接続するためのサービスです。オンプレミス側にカスタマーゲートウェイ機器が必要になるほか、VPN接続には稼働時間に応じた料金がかかり続けます。AWS内の2つのVPC同士を結ぶという今回の要件には直接適用できず、コスト面でもVPCピアリングより不利です。

C. AWS Direct Connectで拠点間の専用線接続を新規に構成します。

不正解 AWS Direct Connectは、オフィスやデータセンターなどのオンプレミス拠点とAWSの間を専用線で結ぶためのサービスです。安定した帯域幅を確保できる一方、物理的な回線の敷設が必要でリードタイムも長く、初期費用と月額のポート利用料が発生します。今回問われているのはAWS内にある2つのVPC同士の接続であり、オンプレミス接続を前提とするDirect Connectの用途とは一致しません。

D. 各VPCの外側にNATゲートウェイを配置します。

不正解 NATゲートウェイは、プライベートサブネットのリソースがインターネットへアウトバウンド通信を行うためのマネージド型アドレス変換サービスです。VPC同士を直接結び付ける機能は持たず、インバウンド通信も扱えません。VPC間の相互通信という今回の要件には対応できず、そもそも用途が異なります。

全体的な説明

問われている要件

• 異なるAWSアカウント・異なるリージョンにある2つのVPC（CIDRブロックは重複しない）を相互接続すること。
• 追加の物理的な機器導入は避けること。
• 費用対効果の高い方法を選ぶこと。
• 判断軸は「AWS内のVPC同士を直接つなげる機能かどうか」と「コストの低さ」の2点であること。

前提知識

Direct Connect・VPN・NATゲートウェイの用途について

• この問題を整理する上で有効なのは、4つの選択肢を「そもそも用途が合っているか」と「合っている場合のコスト構造」の2段階で評価することです。
• Direct ConnectとSite-to-Site VPNはいずれもオンプレミス環境とAWSを接続するためのサービスであり、AWS内部にある2つのVPC同士を直接結ぶ機能ではありません。
• Direct Connectは専用線による高帯域・低遅延な接続を提供しますが、物理回線の敷設に伴う初期コストと構築期間が必要です。
• VPNはインターネット経由の暗号化トンネルでオンプレミスとAWSを結ぶもので、比較的手軽に構築できますが、やはりオンプレミス側の拠点を前提としています。
• NATゲートウェイに至っては、プライベートサブネットからインターネットへの片方向（アウトバウンド）通信を仲介するアドレス変換サービスであり、VPC間接続そのものとは無関係です。

VPCピアリング接続について

• VPCピアリング接続は、同一アカウント内の異なるVPC間はもちろん、異なるAWSアカウント間、異なるAWSリージョン間、さらにその組み合わせでも確立できる、AWS内のVPC同士を直接つなぐための唯一の選択肢です。
• ゲートウェイ機器やVPN装置を経由せず、AWSのネットワークバックボーン上でプライベートIPアドレスによる直接通信を実現するため、単一障害点や帯域幅のボトルネックが生じにくいという特徴もあります。

VPCピアリングの制約について

• VPCピアリングには2つの重要な制約があります。
• 1つは接続する双方のVPCでCIDRブロックが重複していてはならないという点で、今回の問題文はこの条件を満たすことを明示しています。
• もう1つは推移的な接続をサポートしない点です。VPC AとVPC Bがピアリングされ、VPC BとVPC Cもピアリングされていても、AとCの間で自動的に通信できるようにはならず、AC間の通信が必要であれば別途ピアリング接続を作成する必要があります。

コスト面について

• ピアリング接続の確立自体に料金は発生せず、課金対象は転送したデータ量に対するリージョン間データ転送料金のみです。
• Direct Connectのポート利用料やVPNの接続時間料金のような固定費が発生しないため、今回のように継続的なコスト効率を重視する場面では優位性があります。

解くための考え方

まず「AWS内のVPC同士を直接結べる機能かどうか」でDirect Connect・VPN・NATゲートウェイを除外できます。いずれもオンプレミス接続やアウトバウンド専用の通信を目的とした機能であり、VPC間の双方向通信という要件に合致しません。残るVPCピアリングは、アカウントやリージョンをまたいでも構築可能で、CIDRの重複がないという問題文の前提条件もクリアしており、かつ接続料金が発生しないため費用対効果の面でも最適な選択となります。

参考資料

• VPC ピアリング接続とは
• VPC ピアリング接続の作成と承認
• AWS Direct Connect とは
• NAT ゲートウェイ

正解：C

A. パラメーターグループのmax_connect_errorsの値を引き上げます。

不正解 max_connect_errorsは、特定のホストから連続して接続エラーが発生した際に、そのホストからの以降の接続を一時的にブロックするまでの許容回数を制御するパラメーターです。同時に確立できる接続数の上限とは無関係であり、この値を変更しても「Too many connections」エラーは解消しません。

B. Lambda関数の予約済み同時実行数をさらに引き上げます。

不正解 予約済み同時実行数を引き上げると、同時に起動できるLambda実行環境の数が増え、その分だけデータベースへ同時に接続を試みる実行環境も増加します。これは接続数の上限超過をさらに悪化させる操作であり、エラーの解決にはつながりません。

C. RDS Proxyを作成し、Lambda関数の接続文字列をプロキシエンドポイントへ変更します。

正解 「Too many connections」エラーの原因を根本から取り除ける選択肢です。Amazon RDS Proxyはデータベースとの間に確立した接続をプールし、多数のLambda実行環境からの接続要求を少数の実データベース接続にまとめて中継します。Lambda関数側はプロキシのエンドポイントに接続文字列を向けるだけで導入でき、実データベースへの同時接続数を大幅に抑えられます。

D. 読み取り専用のリードレプリカを追加作成し、Amazon Route 53の加重DNSレコードで両方のインスタンスに振り分けます。

不正解 リードレプリカは読み取り専用であり、予約処理のような書き込みを伴うリクエストを処理できません。また、加重DNSレコードでアクセス先を振り分けたとしても、それぞれのDBインスタンスが受け入れられる同時接続数の上限そのものは変わらないため、根本的な解決にはなりません。データの整合性管理も複雑になり、今回の問題には適していません。

全体的な説明

問われている要件

• Lambdaベースの予約APIがRDS for MariaDBに接続する際に発生している「Too many connections」エラーを解消する方法が問われていること。
• データベース側のmax_connectionsは、すでに設定可能な上限まで引き上げ済みであること。
• パラメーター調整だけでは解決しないことが前提になっていること。

前提知識

エラーの原因（Lambdaとmax_connectionsの構造的ギャップ）について

• このエラーの本質は、Lambdaのスケーリング特性とデータベースが受け入れられる接続数の上限との間にある構造的なギャップです。
• Lambdaはリクエストが増えると需要に応じて実行環境を自動的に増やしますが、増えた実行環境の1つ1つが独立してデータベースへ新規接続を確立しようとします。
• 従来のアプリケーションサーバーであれば接続プールを常駐させて接続を使い回せますが、Lambda実行環境は短命でスケールアウトの数も読みにくいため、同じ発想の接続プールをアプリケーション側だけで実現するのは困難です。
• その結果、同時に稼働する実行環境の数がデータベースのmax_connectionsを超え、新規接続が拒否されて「Too many connections」が発生します。

max_connectionsとmax_connect_errorsについて

• max_connections自体を引き上げる対処は、今回の問題文にあるとおりすでに上限まで設定済みであり、かつデータベースインスタンスのメモリ容量に応じた実質的な上限があるため、これ以上の引き上げでは解決しません。
• 似た名前のパラメーターであるmax_connect_errorsは接続数の制御とは別物で、認証失敗などの接続エラーが連続した際にホスト単位で一時的な接続拒否を行うためのしきい値にすぎず、今回の問題の解決策にはなりません。

Amazon RDS Proxyについて

• この構造的な問題を解決するのがAmazon RDS Proxyです。
• RDS Proxyはアプリケーションとデータベースの間に配置されるフルマネージドの接続プロキシで、多数のクライアントからの接続を少数の実データベース接続にまとめて管理し、既存の接続を再利用します。
• アプリケーション側からは通常のデータベース接続と同じように見えるため、SQLクエリの発行方法など既存のロジックを変更する必要はなく、接続文字列をプロキシのエンドポイントに切り替えるだけで導入できます。
• Lambda関数の同時実行数がどれだけ増えても、データベースへの実接続数は一定の範囲に保たれるため、スケーラビリティを損なわずに接続超過を防げます。

リードレプリカと加重DNSレコードの限界について

• リードレプリカは読み取り専用クエリのオフロードや地理的に離れた場所からの低レイテンシー参照、障害時の昇格による復旧を目的とした機能であり、書き込みを扱うAPIの接続数問題を解決する手段ではありません。
• Route 53の加重DNSレコードで複数のエンドポイントにトラフィックを振り分けても、各インスタンス側の接続上限という制約自体は変わらないため、根本的な解決策にはなり得ません。

解くための考え方

エラーの原因が「同時接続数がデータベースの上限を超えていること」だと特定できれば、選択肢は接続数そのものを減らす方向の対策に絞り込めます。max_connect_errorsは接続数制御と無関係、予約済み同時実行数の引き上げは接続要求をさらに増やす逆効果、リードレプリカと加重DNSは書き込みへの対応も接続数上限の緩和もできません。残るRDS Proxyだけが、Lambdaのスケーラビリティを維持したまま実データベースへの接続数を抑制できる唯一の選択肢です。

参考資料

• Amazon RDS Proxy の使用
• AWS Lambda から Amazon RDS Proxy への接続
• Amazon RDS のパフォーマンスインサイト