この記事は作者本人がAWS-SAAの学習を通じて、曖昧や覚えづらい部分をサービス単位でまとめたものです。
特に、概要だけではイメージがわきづらいので、できるだけユースケースを活用して理解しやすいようにしています。
教材はSHOEISHAのAWS教科書 AWS認定ソリューションアーキテクトアソシエイトテキスト＆問題集を参考にしています。

EC2/EC2 AUto Scalingに関する曖昧な部分

EC2／EC2 Auto ScalingはAWSの初歩中の初歩であり、サービスの基本的な概要は割愛します。詳細の中で曖昧になりがちな部分は以下の通りです。（あくまでも私個人が曖昧であると感じた部分です）

キーペア
プレイスメントグループ
Auto Scalingポリシー

本記事では、これらの内容やユースケースについて解説していきます。

キーペア

概要

AWSにおけるキーペアとは、公開鍵暗号方式を利用したセキュリティ認証のためのツールです。具体的には、公開鍵と秘密鍵のペアで構成されており、主にEC2インスタンスへのアクセスに使用されます。

役割

名称	役割
公開鍵	EC2インスタンスに保存され、誰でも見ることができます。
秘密鍵	あなたのローカルマシンに保存され、厳重に管理されます。この秘密鍵を使って、インスタンスへのSSH接続を行います。

秘密鍵の管理: 秘密鍵は一度しかダウンロードできないため、紛失しないように注意が必要です。
セキュリティ: 秘密鍵を他人に渡さないようにし、適切に保護することが重要です。

ユースケース

キーペアは、EC2インスタンスにSSHで安全にアクセスするために使用されます。
例えば、ウェブサーバーをセットアップする際に、キーペアを使ってリモートからサーバーにログインし、必要なソフトウェアをインストールしたり、設定を行ったりします。

プレイスメントグループ

概要とユースケース

AWSのプレイスメントグループは、EC2インスタンスの配置を最適化するための機能です。
これにより、パフォーマンスの向上や耐障害性の強化が図れます。
プレイスメントグループには以下の3種類があります。

グループ	特徴	ユースケース
クラスタープレイスメントグループ	同一のAZ内でインスタンスを密集させ、低レイテンシーと高スループットを実現します。	高速なネットワーク通信が必要なアプリケーションや、分散コンピューティングのワークロードに適しています。
パーティションプレイスメントグループ	インスタンスを複数のパーティションに分け、それぞれが異なるラックに配置されます。これにより、ハードウェア障害の影響を最小限に抑えます。	大規模なデータ処理や、耐障害性が求められるアプリケーションに適しています。
スプレッドプレイスメントグループ	各インスタンスを異なるラックに配置し、同時障害のリスクを減らします。1つのAZ内で最大7つのインスタンスを配置できます。	少数の重要なインスタンスを分散させる必要がある場合に適しています。

プレイスメントグループを利用することで、特定のワークロードに対して最適な配置戦略を選択でき、システムのパフォーマンスや信頼性を向上させることができるという訳です。

クラスターは「集まり」という意味なので、EC2が密集していて早いんだなあ。
パーティションは「仕切り」という意味なので、EC2が仕切られていて耐障害性が高いんだなあ。
スプレッドは「広がり」という意味なので、EC2が分散させられていて耐障害性が高いんだなあ。

スプレッドパーティショングループとパーティションプレイスメントグループの違いが分かりづらいですね。

大規模→パーティションプレイスメントグループ
小規模→スプレッドプレイスメントグループ
と覚えましょう。

Auto Scalingポリシー

概要

Auto Scalingポリシーは、EC2インスタンスの数を自動的に調整するための設定です。これにより、アプリケーションの需要に応じてリソースを増減させることができます。主なAuto Scalingポリシーには以下の種類があります。

動的スケーリングポリシー
- ターゲット追跡スケーリングポリシー
- ステップスケーリングポリシー
- シンプルスケーリングポリシー
スケジュールドスケーリングポリシー
予測スケーリングポリシー

スケジュールドスケーリングポリシーは、特定の日時に基づいてスケーリングを行うものです。
予測スケーリングポリシーは、CloudWatchからの履歴データを利用し、機械学習によるキャパシティの予測を行うものです。
この２つは文字の通りで理解し易いため、詳細は割愛します。

各動的スケーリングポリシーの特徴

まずは、各スケーリングポリシーの特徴を説明します。

名称	特徴
ターゲット追跡スケーリングポリシー	特定のメトリクス（例：CPU使用率）をターゲット値に維持するようにスケーリングします。ステップスケーリング等と比較して、細かな設定を行う必要がないため、管理を容易に行うことができます。
ステップスケーリングポリシー	メトリクスの値に応じて段階的にスケーリングします。CloudWatchアラームの設定に対して、上限値と下限値を設定することにより、多段階でかつ柔軟な制御を行うことができます。
シンプルスケーリングポリシー	基本的にステップスケーリングと同様の設定を行うが、一段階のアクションのみの設定となります。多くの場合は、将来的な拡張を考慮すると、シンプルスケーリングよりステップスケーリングの使用が勧められています。

各動的スケーリングポリシーのユースケース

ターゲット追跡スケーリングポリシー

オンラインゲームでは、プレイヤー数が時間帯やイベントによって変動します。
ターゲット追跡スケーリングポリシーを使用して、サーバーのCPU使用率やメモリ使用率を一定に保つことで、ゲームのパフォーマンスを最適化します。
例えば、大規模なゲームイベントやアップデートが行われる際に、プレイヤー数の急増に対応することができます。

ステップスケーリングポリシー

バッチ処理やデータ解析システムで、処理負荷が段階的に増減する場合に使用します。
例えば、夜間に大量のデータを処理するシステムで、負荷が高まるにつれてインスタンスを追加し、処理が終わると減らすといった使い方ができます。

シンプルスケーリングポリシー

特定のイベント（例：新製品のリリースやキャンペーンの開始）に応じてスケーリングする場合に使用します。例えば、新製品のリリース時にアクセスが急増することが予想される場合、事前にインスタンスを追加しておくことで、スムーズなサービス提供を実現します。
ただし、セール等の開始時間が明確なケースの場合は、スケジュールドスケーリングポリシーの方が有効かもしれません。

なお、これらのスケーリングポリシーは１つのAuto Scalingグループに対して併用することも可能です。

まとめ

本記事では、以下のサービスについて概要とユースケースをまとめました。

キーペア
プレイスメントグループ
Auto Scalingポリシー

あくまでも作者個人の曖昧な部分を整理したものですが、少しでもお役にたてたら幸いです。

次回は【AWS-SAA勉強記】第2回_Amazon S3編です。