AWSソリューションアーキテクトアソシエイトでよく出た(と思う)内容まとめ

# この記事について
AWSソリューションアーキテクト アソシエイト(以下、SAA)に合格することが出来ました。(合格した試験のバージョンはSAA-C01版です)
そこで、SAAを受験するにあたってよく出たサービスの内容を~~(筆者の独断と偏見で)~~がっつりまとめてみました。
これからSAAを受験する方に向けて知識の確認として利用して頂けると幸いです。

# よく出たサービスとポイント
## EC2
* 仮想サーバサービス
* AZサービス
* EC2で使われる用語
  - Amazon Machine Image(AMI)
      - EC2インスタンスを作成するためのマシンイメージ(OSデータ等)
      - 現在利用しているEC2からもAMIを取得することが可能
  - インスタンスタイプ
      - EC2インスタンスのCPUコア数やメモリ容量等の組み合わせ
  - ユーザデータ
      - EC2が初回起動時に実行される起動スクリプト
  - メタデータ
      - EC2インスタンスに割り当てられた固有のID(ホスト名、AMI ID等)
  - ストレージ
      - EC2インスタンスで使用するブロックストレージ
         - デフォルトでEC2に接続しているストレージにOSイメージがインストールされる
      - 種類としては以下の通り
         - インスタンスストア
             - 無料で、EC2インスタンスの一時的な情報を保存することができるストレージ
             - EC2インスタンスが終了した際、インスタンスストアの内容は削除される
               <br> (ただし、再起動の場合はインスタンスストアの内容は保持される)
         - EBS
             - 別途EBSを使用した料金が発生する
             - EC2インスタンスが終了してもEBS内のデータは保持される
             - EBS単体でスナップショットを取り、S3に保存することができる
* EC2インスタンスの料金モデル
  - オンデマンドインスタンス
     - EC2インスタンスのデフォルトの課金方式
     - 概ね、利用するOS,インスタンスタイプ、リージョンの３要素で料金が決まる
  - スポットインスタンス
     - 入札形式でEC2インスタンスを購入する方式 
     - オンデマンドインスタンスより非常安く利用できる
     - スポットインスタンスの価格が入札した価格を上回るとそのインスタンスは終了するため、突然インスタンスが終了しても問題ない場合(一時的に計算リソースを使用したい場合等)に利用する
  - リザーブドインスタンス(RI)
     - 1年または3年契約でオンデマンドインスタンスより割安でEC2インスタンスを購入する方式
     - 契約後の変更
          - スタンダードリザーブドインスタンス
                  - インスタンスファミリー等を契約後変更できない
          - コンバーティブルリザーブドインスタンス
                   - インスタンスファミリー等を契約後変更ができる
      - 起動時間の選択
          - スケジュールドリザーブドインスタンス
                   - 毎日、毎週、毎月ベースで特定の開始時間、開始期間を指定して、その期間だけ使用する
                   - 特定時間、期間だけ使用するため、基本的に通常のRIより安く利用できる
* ハードウェアの占有
  - ハードウェア専有インスタンス
     - AZ上の特定の物理ホストにAWSアカウントを割り当て、その物理ホスト上でEC2を起動するEC2インスタンス
     - 起動したEC2インスタンス単位に課金される
  - Dedicated Host
     - ハードウェア占有インスタンスに比べ、ハードウェア単位のBYOLやコア、ホスト ID等の監視が可能となるEC2インスタンス
     - 占有したハードウェア単位で課金される
  - ベアメタル
     - 占有したハードウェアのCPUやメモリに直接アクセス可能となるEC2インスタンス

## VPC
* AWS上に仮想ネットワークを構築するサービス
* リージョンサービス
* サブネット
  - VPC内に構築するネットワークセグメントでAZ内に構成する
* ルートテーブル
   - VPC内の仮想ルーターでサブネット内のインスタンスのルーティングを定義する
* インターネットゲートウェイ(IGW)
   - VPC内のAWSリソースからインターネットにアクセスするためのゲートウェイ
   - IGWが割り当ており、ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)がIGWに指定されたサブネットはパブリックサブネット
   - IGWが割り当てられていないサブネットはプライベートサブネット
* NATゲートウェイ
   - NAT機能を提供するゲートウェイ
   - AZ内で冗長化されているため、NAT機能を持つEC2インスタンスを使用するより、可用性は高い
   - プライベートサブネット内のAWSリソースがインターネットへ接続する時によく用いられる
   - IGWによるインターネット接続も必要
   - 構成方法はパブリックサブネット内にNATゲートウェイを配置し、プライベートサブネットからNATゲートウェイへのルートテーブルを定義する
* VPCフローログ
   - VPC内のネットワークインターフェース(ENI)のトラフィック情報(送信元・先IPやアクション等)をキャプチャするサービス
   - CloudWatch LogsにENI単位で保存される
* Elastic IP(EIP)
   - 固定グローバルIPアドレス
   - 起動しているEC2インスタンスに割り当てた場合、料金はかからないが、EC2に割り当てられていない場合やEC2インスタンスが停止中で利用できない場合は料金がかかる
* VPCエンドポイント
   - VPC内のインスタンスからVPC外のAWSサービスへインターネット経由なしでアクセスする方法
   - 以下の種類がある
      - ゲートウェイ型
         - S3とDynamoDBのみ利用可能
         - ルートテーブルで送信先として設定する
      - インターフェース型
         - S3とDynamoDB以外のAWSサービスで利用可能
* VPCピア接続
   - VPC間の接続をインターネット経由なしで実現できる機能
   - 推移的な接続はできない <br>
     (例えば、VPC A↔ VPC BとVPC B↔ VPC Cがピア接続されていた場合、VPC A↔ VPC C間の直接的な接続はされない)
* VPC Transit Gateway
   - ハブを構築し、複数のVPC、オンプレミス間の接続を行える様になった機能
* ファイアウォール機能
   - セキュリティグループ
      - インスタンス単位で割り当てる
      - デフォルトの設定はインバウンドをすべて拒否、アウトバウンドをすべて許可
      - すべてのルールを適用
      - ステートフル
   - ネットワークACL
      - サブネット単位で割り当てる
      - デフォルトの設定はインバウンド・アウトバウンドをすべて許可
      - ルールの番号順に適用
      - ステートレス

## IAM
* AWS内の認証・認可を管理するサービス
* 管理対象
   - IAMユーザ
      - AWSサービスを利用できるユーザ
      - AWSアカウントを作成した直後はルートユーザと呼ばれる管理者権限を持つユーザが作成される
         - ルートユーザは何でもできてしまうため、基本的にはルートユーザではログインせず、IAMから作成したIAMユーザからサービスを利用する
         - ただし、AWSの利用停止やコンソリデイテッドビリングの設定等はルートユーザでしか行えない
      - 1アカウント5000ユーザまで作成可能
      - 認証方式
         - アクセスキー/シークレットキー
         - AWS マネージメントコンソールからのログイン
         - 多要素認証(MFA)
   - IAMグループ
      - IAMユーザをまとめるグループ
      - 1アカウント100グループまで作成可能
   - IAMロール
      - AWSリソースに対して付与する物でIAMポリシーの集合体
   - IAMポリシー
     - 権限のこと
     - 管理ポリシー
        - ポリシー単体として管理できる物で、AWSが管理するポリシーとAWSアカウントで管理するポリシーとで区分される
     - インラインポリシー
        - AWSリソースそのものに埋め込んで権限を付与するポリシー

## S3
* オブジェクトストレージサービス
* グローバルサービス(ただし、データは特定のリージョンに格納)
* 特定のリージョンにS3バケットと呼ばれるデータの格納場所を用意しデータ(オブジェクト)を保存する
* データの総容量とオブジェクトの総数に制限なし
* 1オブジェクトは最大5TBまで保存することができる
* 整合性
   - データの登録
      - 書き込み後の読み取り整合性(データ登録を実行後、登録が反映するまで一覧に表示されない)
   - データの更新・削除
      - 結果整合性(データを更新・削除を実行後、更新・削除が反映されるまで、更新前のデータを取得・一覧に表示される)
* ストレージクラス
   - 標準
      - 耐久性は99.999999999%(保存したデータは複数のAZに複製される)
      - 1年で可用性が99.99%
      - すぐに格納したデータを取り出すことができる
   - 低頻度アクセス(Standard IA)
      - 格納したデータはあまりアクセスしないが、取り出す場合はすぐに取り出したい場合に利用する
      - 標準よりコストが安い
      - 1年で可用性が99.9%
   - 1ゾーン 低頻度アクセス(Standard 1zone IA)
      - 1つのAZのみに保存
      - Standard IAよりコストが安いが、信頼性は下がるため、一時的なデータ保存等で利用する
   - Glacier
      - 他のストレージクラスよりコストが最安のストレージクラス
      - 過去のアーカイブログなどデータを取得することがほぼないオブジェクトを格納する際にコストが最適
      - 取り出すには以下のオプションがあり、最速でも数分がかかる
         - 迅速
             - 1～5分で利用できるオプション
             - 他の取り出しオプションよりコスト高
         - 標準
             - 3～5時間で利用できるオプション
         - 大容量
             - 5～12時間で利用できるオプション
             - 他の取り出しオプションよりコスト安
      - 3か月以上保存しているオブジェクトの削除は無料だが、 <br>
        3か月未満で保存しているオブジェクトの削除には早期削除料金が発生する
* セキュリティ
   - アクセスコントロールリスト(ACL)
      - バケットとオブジェクトごとにAWSアカウント単位で権限を設定 
   - バケットポリシー
      - バケットごとに自・他アカウントのIAMユーザやグループに権限を設定
   - IAM
      - 自アカウント内のIAMユーザやグループにS3へアクセス可能なポリシーを割り当てて権限を設定
* 暗号化
   - クライアントサイド暗号化
      - SSC-S3
         - クライアント側で暗号化を行いS3バケットにアップロードする方式
   - サーバサイド暗号化
      - SSE-S3
         - S3によるキー管理で暗号化を行う方式
         - 暗号化キーの管理をしたくない場合に利用する
      - SSE-KMS
         - AWS KMSサービスによるキー管理で暗号化を行う方式
         - 暗号化キーに関するAPIコールの監視をAWS CloudTrailで可能となる
      - SSE-C
         - クライアント側で管理している暗号化キーによる暗号化を行う方式
         - 暗号化キーをクラウド上に保存しないセキュリティ要件等で利用される
   - サーバサイド暗号化の場合、取り出す際の複合化はS3が自動的に行ってくれる
* バージョニング
   - オブジェクトの世代管理機能
   - S3バケット単位で設定可能
   - ユーザによる誤ったオブジェクト更新・削除等でオブジェクトを復元したい場合に利用する
* ライフサイクル機能
   - オブジェクトのライフサイクルを管理する機能
   - 例えば、オブジェクト登録後1か月間は頻繁にそのオブジェクトがアクセスされるが、1か月後はまったくアクセスされない要件があった場合、<br>
     まず、S3 標準に格納しておき、1か月後にGlacierに移動するライフサイクルを設定することでコストが最適となる
* Webサイトホスティング機能
   - S3上に静的なWebサイト(HTML等)をホスティングできる機能
   - 手早く静的なWebサイトを用意したい場合に最適
   - Route53(DNSサービス)を使用することで独自ドメインに静的なWebサイトを作ることが出来る

## ELB
* AZサービス
* マネージド型のロードバランシングサービス
* 特徴
  - 複数AZにまたがるEC2インスタンス負荷分散を行う
  - EC2インスタンスのヘルスチェック
  - ELB自体の自動スケーリング
  - Connection Draining
     - 異常が起きたEC2インスタンスに対して、ELBとの切断前に処理中のリクエストが完了するまで待つ機能
  - スティッキーセッション
     - 特定のクライアントと特定のEC2インスタンスを紐づける機能
* 種類
   - CLB(Classic Load Balancer)
     - Classicの名の付く通り、ELBの最初期に提供されたEBL
     - レイヤー4(TCP/SSL),7(HTTP/HTTPS)対応
     - 複雑な負荷分散はできない
   - ALB(Application Load Balancer)
     - レイヤー7部分を強化版
     - URLパスに基づくルーティングも可能
   - NLB(Network Load Balancer)
     - レイヤー4対応
     - 大規模なアクセスを伴う負荷分散を行う際に利用

## Auto Scaling
* リージョンサービス
* 自動スケーリングサービス
* スケーリングの用語
  - スケールイン
     - EC2インスタンスの台数を減らすこと
  - スケールアウト
     - EC2インスタンスの台数を増やすこと
  - スケールアップ
     - EC2インスタンスの性能(CPUやメモリサイズ)をアップさせること
  - スケールダウン
     - EC2インスタンスの性能(CPUやメモリサイズ)をダウンさせること
* 構成要素
  - オートスケーリンググループ
     - スケーリング対象のEC2インスタンスの設定(サブネットや最小・最大のEC2インスタンス数等)
  - スケーリングポリシー
     - どのタイミングでどのくらいスケーリングを行うかを設定する物
        - 動的に変えたり、スケジューリングで変えたりすることが出来る
  - 起動設定
     - 起動するEC2の種類(AMI,インスタンスタイプ等)を設定
* ELB + Auto Scaling + EC2の組み合わせでよくSAAの試験に出ることが多い

## RDS
* AZサービス
* フルマネージド型のリレーショナルデータベースサービス
   - フルマネージド型のため、OSレベルのアクセスやパッチの手動適用を行うことはできない
* 利用できるDBエンジン
   - Amazon Aurora
   - PostgreSQL
   - MySQL
   - MariaDB
   - Oracle
   - MS SQL Server
* マルチAZ構成
   - 複数のAZにRDSインスタンスを配置して可用性を高める機能
* 自動バックアップ
   - 1日1回、自動的にデータのバックアップを取る機能
   - バックアップから復元する場合、バックアップ元のRDSがロールバックされるのではなく、<br>
     バックアップから新規RDSインスタンスが作成される
* リードレプリカ
   - マスターのRDSインスタンスから複製される読み込み専用のRDSインスタンス
   - DBの読み取り性能を向上したい場合に使用する
   - AWS SAAの試験では、コストを度外視する場合、ElastiCacheを使用したほうが良いが、<br>
     コスト最適であることを求められている場合、リードレプリカを使用する

## Aurora
* MySQL および PostgreSQL と互換性のあるリレーショナルデータベース
* 性能は標準的なMySQLだと5倍、PostgreSQLだと3倍高速になる(AWS Aurora公式サイトより)
* 商用データベースと同等のセキュリティ、可用性、信頼性を、10分の1のコストで実現(AWS Aurora公式サイトより)
* 1つのリージョンの3つのAZにDBクラスター間のデータをレプリケートしていることで99.99%の可用性を実現
* おおむね、AWS SAAの試験にてコスト最適や高速化の観点でリレーショナルデータベースのデータベースエンジンを選ぶ問題では<br>
  本データベースエンジンを選択する
* 暗号化対象
   - DBインスタンス
   - スナップショット
   - リードレプリカ
   - ログ

## ElastiCache
* マネージド型のインメモリのキャッシュサービス
* キャッシュエンジン
   - とくにかく高速でシンプルなデータを保存したい要件以外ではRedisを使用したほうが良い
   - Memcached
      - マルチスレッドで動作
      - データの永続化不能
      - シンプルなデータ型(String)のみ対応
   - Redis
      - シングルスレッドで動作
      - データの永続化可能
      - 複雑なデータ型に対応

## RedShift
* データウェアハウスサービス
* 列指向のDB
* PostgreSQLと互換性あり
* 格納された大量のデータをBIツール等で確認する用途に適している
* RedShiftにロードせず、S3に置かれたデータを直接SQLを実行することができるRedShift Spectrumがある

## DynamoDB
* マネージド型のNoSQLデータベース(Key-Value型)サービス
* データ容量制限なし
* Auroraと同様に3つのAZにデータを複製する仕様となっているため、可用性が高い
* データの読み取りに関して、強い整合性(データ保存後の読み取りで必ず最新のデータを取得できる)を設定することができる
* ユースケース
   - 大量のデータを格納、高速な検索をしたい
   - ユーザの行動履歴を残したい
   - セッション管理
* Dynamo Streams
   -24時間以内にDynamoDBで実行された追加・更新・削除の変更履歴を保存する機能で、<br>
    データの更新を検知して変更内容に応じた処理を実行できる
* DynamoDB Accelerator(DAX)
   - メモリキャッシュサービスで読み取り性能が向上する
* 400KB以上のデータは格納できない

## Kinesis
* マネージド型のストリーミングデータを収集・処理・分析するためのサービス
* 機能
   - Data Streams
      - 複数のデータソースからのデータストリーミングを読み取り、他のサービスへ転送するサービス
   - Data Firehose
      - ストリーミングデータをS3やRedShiftに保存するサービス
   - Analytics
      - ストリーミングデータに対するリアルタイム分析をSQL等で行うサービス
   - Video Streams
      - データソースからAWSへ動画のストリーミングを行うサービス

## Route 53
* マネージド型のDNSサービス
* ヘルスチェック機能あり
* ルーティングポリシーの種類
   - シンプルルーティングポリシー
      - 特殊なルーティングは行わずに1対1のルーティングを行う
   - フェイルオーバールーティングポリシー
      - リソースに異常を検知した際、セカンダリのシステムへのルーティングを行う(アクティブ/パッシブ方式)
   - 位置情報ルーティングポリシー
      - ユーザの位置情報に基づいてルーティングを行う
   - 地理的近接ルーティングポリシー
      - リソースの場所に基づいてルーティングを行う
   - レイテンシルーティングポリシー
      - レイテンシが最も低いリソースにルーティングを行う
   - 複数値回答ルーティングポリシー
      - 1つのDNSレコードに複数のIPを登録して、それらのどれかをランダムに返すルーティングを行う
   - 加重ルーティングポリシー
      - リソースごとに特定の比率を指定してルーティングを行う
* トラフィックフロー
   - 複数のルーティングポリシーをGUIで分かりやすく組み合わせて作成するツールで、複雑なルーティングを行う際に利用する
* [サポートされているレコード](https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)で以下のタイプの概要は押さえておいた方が良い
   - A
   - AAAA
   - CNAME
   - SOA
* ALIASレコード
   - Route 53独自のDNSレコードでAWSリソースへのルーティングを行うことができる

## CloudWatch
* AWSのリソースを監視やログの収集、イベントのトリガを行うサービス
* 機能
   - CloudWatch
      - AWSリソースの状態を定期的に取得する
      - 取得した状態はメトリクスと呼ばれる
      - メトリクスの種類
         - 基本メトリクス
              - CPU使用率、ディスクIO、ネットワークIO等がある
              - ただし、メモリ使用率は取得できない(カスタムメトリクスで取得する)
              - 基本メトリクスは5分間隔で状態を取得する
         - カスタムメトリクス
              - 監視対象のリソースにCloudWatchエージェント等を入れて、CloudWatchに定期的にログを送る方式
   - CloudWatch Logs
      - Lambdaやアプリケーションログなどのログをモニタリングするサービス
   - CloudWatch Events
      - AWSリソースの状態が変わる等イベントを検知し、指定したアクションを実行するサービス
      - Cron形式でスケジュール実行も可能

## CloudTrail
* AWS上の操作ログを収集するサービス
* 5分間隔でログを収集する

## CloudFormation
* AWSリソースをコーディングによって自動構築・管理することが出来るサービス
* 使用可能なファイルフォーマットはJSONとYAML
* CloudFormationデザイナーで視覚的に構築することもできる

## EBS
* ブロックストレージサービス
* 複数のEBSをEC2にアタッチすることができる(逆に複数のEC2が1つのEBSを同時にアタッチすることはできない)
* ボリュームタイプ
   - プロビジョンドIOPS SSD
      - ボリュームタイプの中で高性能で、非常に高いIOPS性能が必要な場合に使用
   - 汎用SSD
      - 汎用的なSSD
   - スループット最適化HDD
      - スループットを重視したボリュームタイプ
      - 主にログファイル等のシーケンシャルにデータを取得することが多い場合に使用
   - Cold HDD
      - ボリュームタイプの中で低い性能だが、最もコストが低いボリュームタイプ
* AZ内に複数のサーバにデータをレプリケートしており、可用性が99.999%と高い
* スナップショットを取得して、バックアップを取ることができる
* AWS DLMと使用することでスナップショットのライフサイクル管理を行える
* ボリュームの暗号化が可能で、暗号化されたボリュームから取得したスナップショットも暗号化される

## EFS
* フルマネージド型のNFSサービス
* 容量無制限
* POSIX準拠のファイルシステム
* 複数のEC2インスタンスからアクセス可能
* 複数のAZにデータがレプリケートされる

## Lambda
* サーバレスにプログラムを実行することができるコンピューティングサービス
* 実行のトリガーとなるイベントを定義する等を行い、以下の例の様に他のAWSサービスとの連携が容易
   - CloudWatch Eventでスケジュール実行
   - S3のファイル登録イベントを受け取り、登録したファイルの加工処理を実行
   - API GatewayがHTTPリクエストを受け取り、HTTPリクエスト処理を実行
* LambdaにアップロードしたプログラムはLambda関数という単位で定義される
* 使用可能なプログラミング言語
   - Node.js
   - Python
   - Java
   - Ruby
   - C#
   - Go
   - PowerShell
* 制限事項
   - メモリは128MBから3008 MB まで指定可能
   - 処理のタイムアウト時間は15分

## SQS
* フルマネージド型のメッセージキューイングサービス
* プル型のメッセージサービス
* 他のAWSサービスで組み合わせて使用することでシステムの疎結合化を図れる
* 種類
   - スタンダードキュー
      - 最低1回はメッセージを配信できることが保証されている
      - 同じメッセージを2度配信されることがある
      - 配信順序は保証されない
   - FIFOキュー
      - 同じメッセージを2度配信されることはない
      - 配信順序が保証される
* 可視性タイムアウト
   - キュー内の配信済みメッセージが他のクライアントから取得できない時間を設定
   - メッセージ受信したクライアントの処理中に同じメッセージを他のクライアントが取得しないようにしたい用途で使用
* デッドレターキュー
   - 指定回数処理できなかったメッセージを格納するキュー
* ポーリング
   - メッセージの取得方法でロングポーリングとショートポーリングがある
   - ロングポーリング
      - 取得リクエストをキューに投げるとメッセージがない場合、メッセージが来るか、タイムアウト時間が来るまでレスポンスを返さない
   - ショートポーリング(デフォルト)
      - 取得リクエストをキューに投げると(メッセージがあってもなくても)即レスポンスが返る

## SNS
* フルマネージド型のメッセージングサービス
* プッシュ型のメッセージサービス
* SQSと同様にシステム間の疎結合化を図れる
* トピック単位で通知を管理
   - トピックの通知者はPublisher
   - トピックの受信者はSubscriber

# たまに出たサービス
以下のポイントを押さえておくとよいと思います。

- 何をするサービスか？
- 似たようなサービスがある場合、どの点(ユースケース等)で異なるか？

|カテゴリ|  サービス名  |
| ---- | ---- |
|コンピューティング| Elastic Beanstalk|
|ストレージ| Storage Gateway|
|データベース| Neptune|
|ネットワーキングとコンテンツ配信| API Gateway |
|| Direct Connect |
|移行と転送| DataSync|
| | Snowball|
|分析| Data Pipeline|
|| Athena|
|管理とガバナンス| OpsWorks |
|セキュリティ| Config|
|| Trusted Advisor|
|| System Manager|
|| GuardDuty|
|| Shield|
|| WAF|
|| Cognito |
|| Firewall Manager|
|| Certificate Manager|
|| Inspector|
|カスタマーエンゲージメント| SES|
|アプリケーション統合| SWF|
|| Step Functions|
|コンテナ|ECS|
||ECR|
||EKS|