データベースのパスワードや外部サービスのAPIキー、どう管理していますか？

「とりあえずコードに直書き（ハードコード）して、GitHubに上げないように気をつける」⋯⋯これ、実は非常に危険な運用です。もし設定ファイルが漏洩したら、全てのデータが危険にさらされます。

私は模擬試験で「DBの認証情報を安全に管理し、定期的に変更（ローテーション）するには？」という問いに出会い、正解がAWS Secrets Managerであることを学びました。しかも、これを使うと「パスワードを自分で変える手間」すらなくなるんです！

Secrets Managerができる「3つのすごいこと」

Secrets Managerは、単なる「パスワードの保管庫」ではありません。

• ハードコードの排除
  アプリケーションはコードの中にパスワードを書く代わりに、Secrets Managerに「パスワードを教えて」とリクエストを送ります。
• 自動ローテーション（定期更新）
  「30日ごとにパスワードを自動でランダムなものに変更する」といった設定が可能です。これが試験で最も狙われるポイントです！
• プログラムからの簡単呼び出し
  AWS SDKを使えば、数行のコードで安全に機密情報を取り出せます。

【試験対策】Secrets Manager vs Parameter Strore

AWSには「SSM Parameter Store」という似たサービスがあります。どちらを選ぶべきかの判断基準を整理しましょう。

「パスワードを定期的に変えたい！」という要件があれば、100% Secrets Managerが正解です。

自動ローテーションの仕組み

Secrets Managerがパスワードを更新する際、裏側ではAWS Lamdaが動いています。

1.Secrets ManagerがLamdaを起動。
2.Lamdaがデータベースのパスワードを新しいものに変更。
3.Secrets Manager内の値を更新。

この連携により、人間が一切介入することなく、常に「新鮮で安全なパスワード」を使い続けることができます。

試験で役立つ！キーワード判別法

セキュリティの問題で、以下の言葉があればAWS Secrets Managerが正解です。

• 「機密情報の自動ローテーション（更新）」
• 「ハードコードされた認証情報の削除」
• 「RDSのパスワードを安全に管理」
• 「プログラムからAPI経由でパスワードを取得」

今回の学び：攻略の格言

「秘密は覚えるな、Secrets Managerに預けろ。Lamdaが勝手にパスワードを磨き（更新）、漏洩リスクを最小化する！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「パスワードを定期的に変える」というのは、理屈では分かっていても、手動でやるのは面倒だし事故の元ですよね。それをマネージドサービスで自動化できるのがAWSの良さです。

セキュリティを固めることは、自分たちのシステムだけでなく、ユーザーの信頼を守ること。この一歩が、プロのアーキテクトへの大きな一歩になります。

それでは、次回の記事でお会いしましょう！

私は最初、「読み取りが遅いなら、RDSのリードレプリカを増やせばいいんじゃない？」と考えていました。しかし、試験の要件は「ミリ秒単位の超低遅延」と「極度のコスト効率」。

これらを満たすための、RDSとElastiCacheの「黄金コンビ」について解説します！

データベースの前に「高速なメモ」を置く

ElastiCacheは、ハードディスクではなく「メモリ（RAM）」の上にデータを保存するデータベースです。

• 驚異のスピード
  ミリ秒（1000分の1秒）ではなく、マイクロ秒（100万分の1秒）単位の応答時間を実現します。
• RDSを休ませる
  一度DBから読み取ったデータをElastiCacheにキャッシュしておけば、次に同じリクエストが来た時はDBまで行かずに済みます。これで、高価なDBインスタンスの負荷を劇的に減らせます。

試験で狙われる「Redis」と「Memcached」の選び方

ElastiCacheには2つのエンジンがありますが、SAA試験で問われるのは「どっちを使うべきか」の判断です。

①Redis

• 多機能
  データのバックアップ（スナップショット）や、レプリケーションによる高可用性に対応。
• 高度なデータ構造
  リストやセットなど、複雑なデータを扱えます。
• 用途
  ランキング機能、セッション管理、高可用性が必要なシステム。

②Memcached

• シンプル
  機能は少ないですが、その分極めてシンプルで高速。
• マルチスレッド
  複数のCPUコアを効率よく使えます。
• 用途
  構造が単純なキャッシュ。

【比較表】RDS vs ElastiCache

試験で役立つ！キーワード判別法

パフォーマンス最適化の問題で、以下の言葉があればAmazon ElastiCacheが正解の鍵です！

• 「ミリ秒未満（Sub-millisecond）のレイテンシー」
• 「データベースの読み取り負荷を軽減」
• 「インメモリデータストア」
• 「リードレプリカよりも高いパフォーマンス」

今回の学び：攻略の格言

「重いDB、叩く前（読み取る前）にキャッシュを見ろ！ミリ秒未満の壁を超えるならElastiCacheの一択だ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました。

今回の構成は、動画配信サービスなど、現代のWebアプリケーションでは欠かせないアーキテクチャです。RDSだけで無理に頑張るのではなく、キャッシュを組み合わせて「適材適所」で負荷を逃がす。この考え方ができるようになると、インフラ設計がぐっと楽しくなりますね。

「速さは正義」。ユーザー体験を向上させるための強力な武器を、また一つ手に入れました。

それでは、次回の記事でお会いしましょう！

そんな時、一般的なリレーショナルデータベース（RDS）だと、データ量が増えるにつれて検索スピードが落ちてしまい、限界を感じることがあります。

私は模擬試験で「何百万ものレコードに対する全文検索を、低遅延で実現するには？」と問われ、「RDSのインデックスを頑張ればいいのかな？」と悩みましたが、正解はもっと「検索」に特化した専用サービス、Amazon OpenSearch Serviceを使うことでした。

なぜ「検索」にはOpenSearchなのか？

OpenSearch Serviceは、大量のデータに対して「全文検索」や「リアルタイム分析」を行うためのマネージドサービスです。

• 全文検索が得意
  曖昧なキーワード検索や、複雑な条件での絞り込みを驚くほど早く処理できます。
• 可視化ツール「OpenSearch Dashboards」
  検索結果をグラフやチャートにまとめ、ダッシュボードで一目で状況を把握できます（ログ監視などに最適！）。
• スケーラビリティ
  データが増えても、クラスターのサイズを調整することで、常に安定したパフォーマンスを維持できます。

実務・試験でよく出る「データ投入」の黄金パターン

OpenSearchにどうやってデータを入れるか？ここがSAA試験の頻出ポイントです。

• Amazon Kinesis Data Firehoseとの連携
  ストリーミングデータ（ログやクリックストリームなど）を、Firehose経由でほぼリアルタイムにOpenSearchへ流し込む構成が鉄板です。
• Amazon S3からの取り込み
  S3に保存された過去のログを、Lamdaなどを使ってOpenSearchへインデックス（登録）する方法もよく使われます。

【比較表】RDS vs OpenSearch Service

「いつものDB」と「検索エンジン」の使い分けを整理しましょう。

試験で役立つ！キーワード判別法

問題文に以下のキーワードがあれば、Amazon OpenSearch Serviceが正解の最有力候補です。

• 「全文検索（Full-text search」
• 「低遅延な検索レスポンス」
• 「ログの可視化とリアルタイム分析」
• 「何百万ものドキュメントを迅速に検索」

今回の学び：攻略の格言

「探すのが仕事なら、専用の道具を使え。RDSで粘らず、Open Searchで爆速検索を実現しよう！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「適材適所」という言葉がある通り、AWSには特定の目的に特化した強力なサービスがたくさんあります。これらをパズルのように組み合わせることで、ユーザーにとって最高に心地よいレスポンスを提供できるシステムが作れるんですね。

「検索といえばOpenSearch」という引き出しが一つ増えるだけで、アーキテクトとしての提案の幅がぐっと広がった気がします。

それでは、次回の記事でお会いしましょう！

「普通のVPN」と「加速されたVPN」の違い

通常、Site-to-Site VPNはインターネットの荒波を超えてAWSまで繋がります。しかし、今回の構成は一味違います。

• AWS Grobal Acceleratorの活用
  ユーザーに近い拠点（エッジロケーション）から、即座にAWSの高速なプライベートネットワークに通信を取り込みます。
• 高速道路を走るVPN
  インターネットの混雑を回避して、AWSの専用網を通ってVPN接続を行うため、安定性が劇的に向上します。

これが、専用線（Direct Connect）を使わずに、コストを抑えつつ高品質な通信を実現する「第3の選択肢」です。

実務で役立つ！もう一つの重要サービス「Transit Gateway」

拠点が複数ある場合や、VPCがたくさんある場合に登場するのがAWS Transit Gatewayです。

• ハブ・アンド・スポーク構成
  たくさんのVPCやオンプレミス拠点を、この「ハブ」にガチャンと繋ぐだけで、網の目のような複雑な接続をスッキリと一本化できます。
• 管理の簡素化
  新しいVPCが増えても、Transit Gatewayに繋ぐだけで既存のVPNや専用線を利用できるため、拡張性が非常に高いのが特徴です。

【比較表】オンプレミス接続、どれを選ぶ？

試験で「どの接続方法がベストか」を見極めるための表です。

試験で役立つ！キーワード判別法

ネットワーク構成の問題で、以下のフレーズがあればこの組み合わせが正解です！

• 「Direct Connectを使わずにパフォーマンスを向上させたい」
• 「グローバルな拠点から安定したVPN接続を行いたい」
• 「AWS Grobal AcceleratorをVPNのフロントに使用する」
• 「複数のVPCや拠点を一元管理したい」→AWS Transit Gateway

今回の学び：攻略の格言

「専用線が高いなら、VPNを加速しろ！Grobal AcceleratorでAWSの専用網（ハイウェイ）へ滑り込め！」

あとがき：一歩ずつ、合格へ！

最後まで読んでいいただき、ありがとうございました！

今回の構成を知った時、「専用線かVPNか」という二択ではなく、その中間を埋める「賢い折衷案」があることに驚きました。AWSのサービスをパズルのように組み合わせることで、予算という制約の中でも最高のパフォーマンスを引き出せる。これこそがアーキテクトの腕の見せ所ですね。

学びはまだまだ止まりません！次回はさらに踏み込んだテーマに挑戦します！

「データベースのパスワード、コードに直書きしちゃおうかな⋯⋯」
「オンプレミスで使っていたIPアドレス、AWSでもそのまま使いたいな⋯⋯」

そんな悩みをAWSの標準機能でスマートに解決する方法を、私の失敗談とともに整理しましょう！

データベース接続に「パスワード」はもういらない？

通常、RDSに接続する際にはユーザー名とパスワードが必要ですが、これだと「パスワードの管理」が大きなリスクになります。そこで登場するのがIAMデータベース認証です。

• パスワードの代わりに「トークン」
  一時的な署名付き認証トークンを使用してログインします。パスワードをアプリに保存する必要がありません。
• IAMロールで権限管理
  「このEC2インスタンスには、このDBへの接続を許可する」という設定をIAMロールで行なえます。
• メリット
  パスワードの漏洩リスクがゼロになり、運用が圧倒的に楽になります。

【試験のひっかけ！】
「SSL接続」は通信の暗号化であり、認証（誰がアクセスしていいか）ではありません。認証をセキュアにするなら、迷わず「IMAデータベース認証」を選びましょう。

独自のIPアドレスをAWSへ！「BYOIPの仕組み」

企業によっては、セキュリティ上の理由（ホワイトリスト登録など）で、オンプレミスで使っていた特定のパブリックIPアドレスをAWSでも使い続けたい場合があります。これを実現するのがBYOP（Bring Your Own IP）です。

ここで重要になるのがROA（Route Origin Authorrization）というキーワードです。

• ROAとは
  「このIPアドレスは私のものです。AWSがこれを使ってもいいですよ」ということを証明するための電子署名付きデータです。
• 手順
  RIR（地域インターネットレジストリ）を通じてROAを作成し、AWSアカウントに登録することで、持ち込んだIPアドレスをAWS上で利用可能（アドバタイズ）にします。

【比較表】セキュリティと移管のポイント

試験で役立つ！キーワード判別法

セキュリティや移行の問題で、以下の言葉があればこれらが正解の鍵です！

• 「パスワードのハードコードを避けたい」
  IAMデータベース認証
• 「インスタンスのプロファイル認証情報を使用する」
  IAMデータベース認証
• 「オンプレミスのIPアドレスをAWSへ移管」
  BYOIP / ROA (Route Origin Authorization)

今回の学び：攻略の格言

「DB接続はトークン（IAM）でスマートに。IPの引っ越しはROA（証明）で正当に！」

あとがき：一歩ずつ、合格へ

「SAA対策・想定問題集の振り返りシリーズ」ということで、早くも14回目を迎えました。

最初は「なんで間違えたんだろう⋯⋯」と落ち込むこともありましたが、こうして一つ一つの「なぜ」を深堀りし、ブログという形でアウトプットすることで、知識が血肉になっていくのを実感しました。

それでは、次回の記事でお会いしましょう！

「サブネットの設定を間違えたかな？」「セキュリティグループのせい？」とあちこち設定をいじくり回して時間を溶かした経験はありませんか？

私は模擬試験でこの原因を問われ、「サブネットの設定」と答えて不正解。実は、犯人はVPCそのものの「あるオプション」がオフになっていたことだったんです。

犯人は「DNSホスト名（DNS Hostname）」設定

パブリックサブネットにあるEC2インスタンスが、ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.comのような名前（パブリックDNSホスト名）を取得するには、VPCの属性設定で以下の2つがEnabled（有効）になっている必要があります。

1.DNS解決（enableDnsSupport）
　VPC内のAmazon提供DNSサーバーを使って名前解決をするかどうか。

2.DNSホスト名（enableDnsHostnames）
　VPC内で起動されるインスタンスにパブリックDNSホスト名を割り当てるかどうか。

特に、カスタムVPCを「ウィザードを使わず手動」で作ると、これらがデフォルトで無効になっていることがあるため、注意が必要です！

なぜ「サブネット」ではなく「VPC」の設定なのか？

試験で迷いやすいのが、「設定の適用範囲」です。

DNSの設定は、個別のサブネットやEC2インスタンスごとにポチポチ設定するものではなく、VPCという「ネットワーク全体」のルールとして管理されます。VPCという大きな箱のルールで「名前を付けない」と決まっている以上、その中のどのサブネットで起動しても名前は付かない⋯⋯というわけです。

解決手順：コンソールでどこで直す？

もし名前が表示されていないことに気づいたら、以下の手順で一瞬で直せます。

1.VPCマネジメントコンソールを開く。

2.対象のVPCを選択。

3.［アクション］メニューから［VPC 設定を編集］を選択。

4.［DNS ホスト名を有効化］にチェックを入れて保存！

これだけで、次に起動するインスタンス（または再起動したインスタンス）にはちゃんと名前が付くようになります。

試験で役立つ！キーワード判別法

通信トラブル系の問題で、以下のフレーズがあればVPCのDNSホスト名設定を疑いましょう。

• 「インスタンスがパブリックDNS名を取得していない」
• 「パブリックIPはあるが、名前解決ができない」
• 「新規作成したVPCで名前解決が失敗する」
• 「enableDnsHostnames オプション」

今回の学び：攻略の格言

「名前が出ないなら、サブネットを疑う前にVPCの横顔（属性設定）を見ろ。DNSホスト名にチェック一発で解決！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

今回のトラブルは、実務でも「あるある」の筆頭です。特にTerraformやCloudFormationでインフラをコード化（IaC）しているとき、このパラメータを書き忘れて「SSHできない！」と騒ぐのは新米アーキテクチャの登竜門（笑）。

華やかな新サービスだけでなく、こうした地味なネットワークの基礎設定を一つずつ押さえていくことが、結局は一番の近道になるんですよね。

それでは、次回の記事でお会いしましょう！

私は模擬試験で「古いバージョンを2年間保存しつつ、コストを最小にするには？」という問いに対し、「タグを付けてバッチ処理で消せばいいのかな？」と遠回りな回答を選んでしまいました。

実は、S3には「ライフサイクルポリシーという、設定するだけで自動的にデータを整理してくれる「お掃除ロボット」のような機能があるんです。

データの「鮮度」に合わせて置き場所を変える

S3ライフサイクルポリシーの核となるのが、「移行アクション」と「有効期限切れアクション」の2つです。

今回の「2年間は保持したいが、めったにアクセスしない」という要件には、この組み合わせが最強のソリューションになります。

• S3 Glacier Deep Archiveへ移行
  作成から一定期間（今回の場合は旧バージョンになってすぐ）経ったデータを、最も安価な「氷河の底（Deep Archive）」へ自動で移動させます。
• 2年後に失効（削除）
  「作成から2年（730日）経過したら削除する」というルールをセットしておけば、管理者が手を下さずとも自動で消えてくれます。

「最新ではないバージョン」への特別ルール

ここが試験のひっかかりポイントです。S3のライフサイクルポリシーでは、「現行バージョン」と「最新ではない（Noncurrent）バージョン」を分けて設定できます。

• 現行バージョン
  今まさに使っている最新のファイル。
• 最新ではないバージョン
  上書きや削除によって過去のものになったファイル。

今回のケースのように「古いバージョンだけを安く保存したい」なら、「NoncurrentVersionTransition（最新ではないバージョンの移行）」というルールを指定するのが正解です。

【比較表】S3ライフサイクルでできること

試験で役立つ！キーワード判別法

S3の長期保存とコストの問題で、以下の言葉があればS3ライフサイクルポリシーが正解です！

• 「コスト最適にアーカイブ」
• 「一定期間後に削除（失効）」
• 「最新ではないバージョンの管理」
• 「S3 Glacier Deep Archiveへ移行」

今回の学び：攻略の格言

「過去の自分（バージョン）はアーカイブへ。ライフサイクルを設定して、2年経ったらサヨナラ（失効）しよう！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

今回の設定を使えば、「万が一のためにデータは取っておきたい、でもお金はかけたくない」という、一見わがままな願いも叶えられます。

私は「S3 = ただの箱」だと思っていましたが、時間の経過とともに中身を整理してくれるインテリジェンスな機能があるのだと学び、設計の深さを感じました。これで、ストレージ貧乏からは卒業ですね！

それでは、次回の記事でお会いしましょう！

私は最初、「データをS3に移行するだけなら、SnowballやDirect connectで十分では？」と考えていました。しかし、試験の要件はもっと欲張り。「オンプレミスに高速なアクセス用データを残しつつ、メインはS3に置きたい」。

この「いいとこ取り」を可能にする「キャッシュ型ボリューム」について、仕組みをスッキリ整理しましょう。

「キャッシュ型」と「保存型」の違い、分かりますか？

試験で最も狙われるのが、ボリュームゲートウェイの2つのモードの使い分けです。

①キャッシュ型ボリューム（Cached Volumes）【今回の正解】

• メインの保存先：Amazon S3（クラウド）
• ローカル（オンプレ）：よく使うデータ（ホットデータ）のみを「キャッシュ」として一時保存。
• メリット：オンプレミスのストレージ容量を最小限に抑えつつ、S3の膨大なスケーラビリティを「自分のディスク」のように使えます。

②保管型ボリューム（Stored Volumes）

• メインの保存先：ローカル（オンプレ）
• クラウド（S3）：バックアップとして、非同期でスナップショットを保存。
• メリット：低レイテンシーを最優先し、クラウドはあくまで「控え」として使う構成です。

なぜ「BCP対策」に有効なのか？

今回の問題には「将来的に複数リージョンにデータを保存したい」という要件がありました。

Storage Gatewayの本体（プライマリ）をS3に置くことで、S3の標準機能である「クロスリージョンレプリケーション（CRR）」を組み合わせて、別のリージョンへ自動でコピーを送ることが容易になります。オンプレミスの物理的な制約を飛び越えて、世界規模のバックアップ体制が作れるわけです。

【比較表】どっちのボリュームを選ぶべき？

試験問題の「一言」で判断しましょう。

試験で役立つ！キーワード判別法

ハイブリッドストレージの問題で、以下の言葉があればStorage Gateway（Cached）が正解です！

• 「オンプレミスストレージの拡張」
• 「S3をプライマリーストレージとして利用」
• 「頻繁にアクセスするデータのみをローカルに保存」
• 「iSCSI接続でマウント」

今回の学び：攻略の格言

「S3をメインに、手元はキャッシュに。容量不足はクラウドの無限の胃袋（S3）で解決しろ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

Storage Gatewayは、「オンプレミス」と「クラウド」という別々の世界を繋ぐ、魔法の橋のようなサービスです。

私は「クラウドに移行する = オンプレを捨てる」というイメージを持っていましたが、実際には両方の「美味しいところ」を組み合わせて、今の環境を強化していく道がある。こうした「共存」の設計こそが、ハイブリッド構成の醍醐味ですね。

それでは、次回の記事でお会いしましょう！

「Application Load Balancer（ALB）を並べればなんとかなる？」
そう考えた私は、模擬試験で見事に撃沈しました。

実は、極限のパフォーマンスとグローバルな低遅延を両立させるには、「ネットワークの専用道路」と「超高性能な交通整理」の組み合わせが必要だったんです。

秒間数百万件を捌く「交通整理のプロ」

このレベルのトラフィックを処理できる唯一のロードバランサー、それがNewwork Load Balancer（NLB）です。

• 圧倒的なスケーラビリティ
  ALBが「アプリケーション層（第7層）」で中身を詳しく見るのに対し、NLBは「ネットワーク層（第4層）」で機械的に振り分けます。そのため、秒間数百万リクエストという超高負荷でも、ビクともせずにすけーりんぐします。
• 低遅延
  処理がシンプルな分、遅延が極めて少ないのが特徴です。

世界中のユーザーをAWSの「専用道路」へ

NLBだけでは、世界中からインターネット経由でアクセスしてくるユーザーの「遅延」は解消できません。そこで登場するのがAWS Global Acceleratorです。

通常、インターネット経由での通信は多くのプロバイダーを経由して不安定になりますが、Global Acceleratorを使うと

1.ユーザーに最も近い「エッジロケーション（入口）」から、即座にAWSの爆速プライベートネットワーク（専用道路）に取り込みます。
2.そこから目的地（NLBなど）まで、最短・最速のルートでデータを運びます。

【最強タッグ】NLB ✕ Global Acceleratorのメリット

試験で「この組み合わせが正解だ！」と判断するためのポイントは3つです。

• 究極のスループット
  NLBの処理能力を最大限に活かせる。
• 固定IPアドレス
  Global Acceleratorは「Anycast IP」という変わらないIPアドレスを2つ提供します。クライアント側でのキャッシュ設定が容易になります。
• 高可用性
  リージョン間で負荷を分散できるため、片方のリージョンがダウンしても瞬時に切り替えが可能です。

試験で役立つ！キーワード判別法

パフォーマンスとスケーリングの問題で、以下の言葉があればこの構成が正解です！

• 「秒間数百万件（Millions of requests per second）」
• 「グローバルな低遅延」
• 「リアルタイム（入札、取引、ゲームなど）」
• 「Network Load Balancer + AWS Grobal Accelerator」

今回の学び：攻略の格言

「桁違いのトラフィックにはNLB。世界を近くに、通信を早くするならGlobal Acceleratorを前段に置け！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

今回の構成は、まさに「プロの設計」という感じがしてワクワクしますね。私は「ALBで何でもできる」と思いこんでいましたが、サービスの規模や要件によっては、あえて「シンプルなNLB」を選ぶ方が正解になる。

「何が何でも多機能」ではなく、「目的（今回は速度と規模）に合わせた最適な道具を選ぶ」ことの重要さを学びました。

それでは、次回の記事でお会いしましょう！

負荷がかかってから慌てて増やす（ステップスケーリング）のも手ですが、それでは間に合わずにユーザーを待たせてしまうこともあります。

私は模擬試験で「毎日12:00 〜 13:30のピークをどうさばくか？」と問われ、「ターゲットグループをいじればいいのかな？」と迷って不正解。正解は、「あらかじめ増えることがわかっているなら、時間を指定して増やしておく」という攻めの戦略、スケジュールドスケーリングでした。

「予測できる敵」には先手を打つ

今回の解決策の核となるのが、Auto Scalingグループの「スケジュールされたアクション」です。

ECSでECインスタンスを使っている場合、以下の3つの要素を連携させて「12時前に自動でサーバーを増強し、13時半に自動で戻す」仕組みを作ります。

１．Auto Acalingグループ：EC2インスタンスの「数」を管理。
２．スケジュールドスケーリングポリシー：「何時に何台にするか」のスケジュールを定義。
３．キャパシティープロバイダー：ECSが「このAuto Scalingグループを使っていいよ」と許可するための橋渡し役。

構築のポイント：ALBとヘルスチェック

試験で特に引っかかりやすいのが、「どこに何をアタッチするか」という順序です。

• ALBターゲットグループは「Auto Scalingグループ」に構成する
  ECSクラスターではなく、Auto Scalingグループに構成するのが正解です。
• ELBヘルスチェックを有効にする
  これを有効にすることで、もしインスタンスが不調になっても自動で入れ替えてくれるようになり、可用性が高まります。

スケジュール設定のメリット

「負荷を見てから増やす（ステップスケーリング）」ではなく、スケジュール設定（cron式など）を使うメリットは絶大です。

• ウォームアップ不要
  ピークが始まる「前」に増やしておけるので、12:00ジャストに100%のパワーを発揮できます。
• コストの最適化
  13:30のピーク終了に合わせて確実に台数を減らせるので、無駄な料金が発生しません。

試験で役立つ！キーワード判別法

ECSやAuto Scalingの問題で、以下のフレーズがあればこの構成が正解です！

• 「特定の時間帯（12:00 〜 13:00など）に動作が遅くなる」
• 「ピークの時間帯が予測可能である」
• 「キャパシティープロバイダー」
• 「スケジュールされたスケーリングポリシー」

今回の学び：攻略の格言

「決まった時間に待ち伏せろ！Auto Scalingにスケジュールを仕込み、キャパシティープロバイダーでECSに繋げ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

今回の構成は、設定項目が多くて一見複雑に見えますが、「サーバーを増やす時間割を作る」と考えれば非常にシンプルです。

私は最初、ECS単体でなんとかしようとしていましたが、土台となる「EC2（Auto Scaling）」をしっかり制御することが、結局は安定したコンテナ運用に繋がるのだと痛感しました。

それでは、次回の記事でお会いしましょう！