AWS Solutions Associate対策 


# はじめに

今回AWS Solutions Architect - Associateを受けたので自分の備忘録としてまとめました。
(ただメモとして書き殴っただけですので参考になるかわかりませんが、、、)
年末にノリで申し込んで約10日後に受験しました。(無事取得できました)
特にAWSをガッツリ触っているわけでなく、Azureを業務で軽く触っているぐらいです。
主にUdemyで勉強しました。Udemyオススメです。

# IAM

- IAMとは、安全にAWS操作をするための認証・認可の仕組みと思えば良い

#### ルートアカウント

- AWSアカウントを作成した時に用意したEメールアドレスとパスワードを使用してサインインできるアカウント
- 権限が最強すぎるのでこのアカウントは基本的に使用しないようにする


ルートアカウントしかできないこと

- AWSアカウントの停止
- IAMユーザーの課金情報へのアクセス
- S3バケットへのMFAによる削除の有効化
- CloudFrontのキーペア作成 etc




#### IAMポリシー

- どのリソースに対してどの操作をするかJSON形式で定義するもの
- ユーザー、グループ、ロールにアタッチできる
- `(1)Effect (2)Action (3)Resource [ARNで記述](4)Condition`

ポリシーのタイプ
(1)ユーザーベースのポリシー

- IAMユーザーに対してアタッチする

(2)リソースベースのポリシー

- AWSリソースに対してアタッチ
- 信頼ポリシー


(3)アクセス許可の境界

- 管理ポリシーを使用してユーザーベースのポリシーがIAMエンティティに付与できるアクセス許可の上限を設定できるが、アクセス許可は付与しない機能


#### IAMロール

- AWSリソースに対してアクセス権限をロールとして付与できる

# NAT

|  | インターネットGW | NAT GW |
|:-:|:-:|:-:|
|  機能 | NAT (VPC⇆インターネット)  | NAT(インターネットとの接続にはインターネットGW必要)  |
|  NATの種類 | static NAT  |  Dynamic NAPT |
|  場所 |  VPC | (Public)Subnet |
|  速度 | なし  | 5-45Gbps  |


#### 【Static NAT】

- NATテーブルには通信前から「プライベートIPとパブリックIPの変換ルール」がt定義されているので、EC2から始まる通信であってもインターネットのクライアントから始まる通信であってもIPは変換され通信が可能
- 1対1変換でありインターネットからの通信も変換

#### 【NAT Gateway】

- プライベートIP(多)⇆パブリックIP(1)
- 複数EC2インスタンスから発する通信が各々のプライベートIPでNAT-GWを通過する際、NAT-GWで1つのパブリックIPに変換
- 複数のプライベートIPを1つのパブリックIPに変換してしまうと、戻りの通信においてどの通信がどのプライベートIPに変換すれば良いか一意に定まらない
→ TCP/UDPのポート番号も変換する
→この方式を「動的NAPTT = Dynamic NAPT」

## EC2


#### 【ストレージ選択】

(1)インスタンスストア

- 物理的に接続、内臓ハードディスク的な
- 一時的なストレージで、無料で使用可能


(2)EBS

- ネットワーク接続
- EC2と独立に管理
- 別途コストかかる


#### 【AMIの利用】

- Amazon Machine Image, OSの設定をしたやつ
- EC2のBUとしてEBSを含んだ形でAMI作成できる
- `ゴールデンイメージ` : 最適なEC２インスタンスを作成してそれをAMIにしたもの
- `AMI共有` : AWSアカウントIDを指定して権限を委譲するだけでAMIを特定のAWSアカウントを共有
- `リージョンの移動` : 別リージョンにコピー可能


#### 【キャパシティ予約】 : リザーブドインスタンスとセットで利用

- `キャパシティ予約` : インスタンスタイプが起動可能であることの確保権。あらかじめキャパシティを確保しておくことで実行時のキャパシティ不足エラーを抑制


#### 【スポットフリート】

- スポットインスタンスの買い方の一種で条件を指定しておくとAWSがEC2のスポットインスタンスの価格を監視、条件があったEC2を見つけ出して起動、逆に使いたい価格より高くなったEC2は自動的に廃棄


#### 【スポットブロック】

- スポットインスタンスを1h-6hの間中断することなく継続利用可能
- スポットフリートのオプション
- 安定化できる


#### 【EC2フリート】


- オンデマンドとスポットで構成されるインスタンスグループとして設定を定義する仕組み
- 利用上限も決められる


#### 【Elastic Fabric Adapter】

- HPCとMLを高速化するためのEC２用ネットワークデバイス




#### 【Run Command】

- マネージドコンソール上からPowerScript, windows updateの設定などのコマンド各種コマンドを実行できる機能




#### 【ハイバーネーション】

- シャットダウンする前にメインメモリの内容をハードディスク等に退避し、次回起動時にまたメインメモリに読み込んで、シャットダウンする前と同じ状態で起動する機能


#### 【プレイスメントグループ】

- インスタンス間における⭐️`低レイテンシ`⭐️な通信を実現するための機能
- 複数のインスタンスを論理的にグループ化して、パフォーマンスの向上・耐障害性を高める機能



`(1)クラスタプレイスメントグループ`

- パフォーマンスを高めるもの
- 一般的に使用される、単一AZ内のインスタンスを論理的にグループ化
- **EC２間で高ネットワークスループットが発生する場合に適している**
- ⭐️ 低レイテンシ、高スループット、の時採用
- ⭐️ ネットワークトラフィックの大部分がグループ内のインスタンス間で発生してる場合

`(2)パーティションプレイスメントグループ`

- 耐久性を高めるもの➡︎ ⭐️ アプリケーションに関連するハードウェア障害の頻度を軽減する
- 複数のAZに分散させることができる
- HDFSなど大規模なワークロードに適している
- ⭐️ **Hadoop, cassandra, kafkaなどの大規模な分散及び複製ワークロードで一般的に利用**


`(3)スプレッドプレイスメントグループ`

- 耐久性を高めるもの
- 異なるハードウェアに配置されるグループで複数のAZにまたがることが可能
- ⭐️ インスタンスが同じラックを共有するときに発生する可能性のある同時障害のリスクを減らせる
- ⭐️ 少数の重要なインスタンスが互いに分離して保持される必要があるアプリケーションに推奨


#### 【起動テンプレート】

- インスタンスの作成ウィザードから設定していたパラメータをテンプレートにすることができる
- 一度テンプレートにしてインスタンスの情報を決めてしまえばそれ以降はテンプレートから作成することで手間を減らせる
- 起動設定の代わりに起動テンプレートを定義すると、複数のバージョンのテンプレートを使用できる

#### 【起動設定】

- ASGがEC2インスタンスを起動するために使用するインスタンス設定テンプレート

## 予約  (コスト削減)

| 名前 | 説明 |
|:-:|:---|
|  オンデマンドインスタンス |  ・起動するインスタンスに対して秒単位で課金される |
|  Savings Plans |  ・1-3年間、EC2の利用時間に関係なく、1時間につき一定の料金を支払うことを決めてEC2を利用するプラン <br> ・RIと同等の割引が適用されることに加え、スケールアップ等、構成の変更を行った場合でも割引が適用される |
|  Reserved Instance |  ・1年、3年単位で購入できる格安インスタンス |
|  Spot Instance | ・AWS上サーバー上に存在し使われていないEC2インスタンスに値段をつけ、その入札価格が現在のスポット価格を上回っている限りそのインスタンスを利用→インスタンスが中断することがある。<br>・継続的な処理が必要なく重要なタスクでない<br>・バッチ処理ジョブなどの一時的な処理に利用される|
| Dedicated Hosts |  ・専有ホスト。ホストサーバーを保有したい場合利用。セキュリティー的にとか |
|  Bare Metal  |  ・仮想サーバのような仮想化ハイパーバイザを使わず、物理サーバをそのままユーザが利用できるサービス <br>・AWSの各種サービスとの連携が可能でOSが直接下層のハードウェアにアクセス可能 |
| ハードウェア占有インスタンス(Dedicated インスタンス)|　ハードウェア占有インスタンスは、他のアカウントのEC2インスタンスと共有されることはない。言い換えると、同じアカウントのインスタンスとは共有されることになる|




| SP(Savings Plans) | 説明 |
|:--|:--|
|  Compute | EC2, EMR, ECS, EKSクラスターの一部、Fargate, Lambda<br> 最大、66%の割引が可能  |
|  EC2 Instance  | EC2のみ<br> 最大,72%の割引が可能  |

| RI(Reserved Instance)| 説明 |
|:--|:--|
|  Standard | 割引率が最も高く、設定変更などがあまり発生しない定常状態の使用に良い |
|  Convertible | ・割引きが適用、スタンダードと違ってリザーブドインスタンスの属性を変更できる <br> ・コンバーティブル(Convertible)のみ変更可能→ インスタンスファミリー, OS, テナンシー, 支払いオプション|


- `キャパシティ予約` 
    インスタンスタイプが起動可能であるという確保権。リザーブドインスタンスとはセットで使う
    予めキャパシティを確保しておくことで実行時のキャパシティ不足エラーを抑制する
    **確実なEC2 Instanceの起動を確保する**


- **主なリザーブド**
    - [x]   EC2リザーブドインスタンス
    - [x]  RDSリザーブドインスタンス
    - [x]  ElastiCacheリザーブドノード
    - [x]  DynamoDBリザーブドキャパシティ
    - [x]  Redshiftリザーブドノード


⭐️ 基本にSaving Planを優先して考える→柔軟性が高いため
⭐️ スタンダードRIとEC2 Instance SP, コンバーティブルRIとCompute SPの割引率は同一
⭐️ RIを選択するケースとしては、SP非対応のAWSを使用するとき




#### 【インスタンスタイプ】

| 用途| インスタンスファミリー | 説明|
|:-:|:-:|:-:|
| 汎用  |  a, t, m |ウェブサーバーやコードリポジトリなど、インスタンスのリソースを同じ割合で使用するアプリケーションに最適|
|  コンピューティング最適化 | c  |バッチ処理、機械学習推論、科学モデリング|
| メモリ最適化 | r, x, z  |メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスに最適なインスタンス|
| 高速コンピューティング  | p, g, f  |浮動小数点計算、グラフィックス処理、データパターン照合など|
| ストレージ最適化  | i, d, h  |ローカルストレージの大規模データセットに対する高いシーケンシャル読み取りおよび書き込みアクセスを必要とするワークロード用|



## AutoScaling

```
3要素 :
(1) Auto Scalingグループ 
    - Auto Scalingを実行するサーバーグループを指定
(2) Launch Config 
    - AMIインスタンスタイプ、IAMなどを設定知って起動する
(3) スケーリングプラン
    - どのようにインスタンスを起動するか
```

- Auto Scaling設定プロセス
(1) ELB作成
(2) ターゲットグループの作成
(3) 起動するインスタンスの設定
(4) Auto Scalingグループ作成
(5) AutoScalingポリシー or スケジュール設定


- AutoScalingが閾値を超えたにも関わらずスケーリングがうまく実行されず24時間立ったとき`自動的にAutoScalingは停止`

#### 【Auto Scaling Groups】

- EC2インスタンスの開始から削除まで全ての動作に対する規則とポリシーを含んでいる
- ex) 最小サイズ、最大サイズ、お望みの容量、拡大できる容量






#### **【Auto Scaling Plan】**
どのようにスケールするか

- `(1)手動スケーリング` : バッチ処理など高負荷な処理への対応
- `(2)スケジュールドスケーリング` : アクセス予測が可能なとき、日時指定などして指定
- `(3)動的スケーリング` : ⭐️スケーリングポリシー⭐️に従い、自動的にスケーリング


**【Auto Scaling Plan】**
4.1 : シンプルスケーリングポリシー
4.2 : ステップスケーリングポリシー
4.3 : `ターゲット追跡ポリシー` : スケーリングメトリクスを選択してターゲット値を設定
ex) AutoScalingグループの平均集計CPU使用率を40パーセントに維持


#### 【Auto Scalingの挙動】

- インスタンスが最も少ないAZでインスタンスを起動
- `再分散の実施` : AZ間でインスタンス数を不均衡あると調整


#### 【ターミネーションポリシー(終了ポリシー)】

- Auto Scalingでスケールインが発生した時に、どのインスタンスを終了させるかを決めるルール


⭐️ 終了ポリシー  (デフォルト)

-  **最もインスタンスが多いAz選択 → OldestLaunchConfiguration(最も古い起動構成) → ClosestToNextInstanceHour (課金が近い) → ランダム**


| 種類 | 説明 |
|:---|:---|
| OldestInstance  | 最も古いインスタンスを終了する  |
| NewestInstance  | 最も新しいインスタンスを終了  |
| OldestLaunchConfiguration  | 最も古いLaunch Configuration  |
| ClosestToNextInstanceHour  | 課金のタイミングが近い  |




- `クールダウンタイム` : AutoScalingグループが追加のインスタンスを起動または削除することができない時間


#### **【ヘルスチェック】**

- Auto-Scaling配下のEC２のヘルスチェックにはEC２のステータス情報またはELBのヘルスチェックのどちらかを利用

`(1) EC2ステータス` : インスタンスのステータスがrunning以外の状態を異常と判断
`(2) ELB` : ELBのヘルスチェック機能を活用する(正常なインスタンスのみをELBに追加)


#### **【ライフサイクルフック】**

- インスタンス起動時 or 削除時にインスタンスを一時停止してカスタムアクションを実行



---


| 用語 | 説明 |
|:-:|:-:|
|  Desired Capacity |  Auto Scalingが実行されない状態でのインスタンス数を設定<br>この数値を変更することで、手動でスケーリングさせることも可能 |
|  Minimum capacity |  スケールイン時にインスタンスを削除する際の下限のインスタンス数を設定 |
|  Maximum capacity |  最大キャパシティはスケールアウト時に起動するインスタンスの最大数を設定する |

## Redshift

- フルマネージド型のDWH
- DBに対するアクセス競合が発生せず、ノードを増やせば増やすほどリニアに性能が向上
- Redshiftクラスターは`１つのリーダーノード`と`複数のコンピューティングノード`から構成
- `リーダーノードは課金の対象外`となり、`コンピューティングノード数とノードタイプが課金対象`


#### **【Leader Node】**

- SQL処理コードの生成と展開
- クライアントアプリケーションからクエリを受け取って`クエリを解析しクエリ実行プランを作成`
- コンピューティングノードに対するこれらのプランの並列実行を調整しコンピューティングノードから得た中間結果を集計してから、最終的にクライアントアプリケーションに結果を返す
- クラスタの全てを管理

#### **【Compute Node】**

- 実際の処理
- ローカル列志向ストレージ、`クエリの並列実行`
- クエリ実行プランを実行し、これらのクエリを処理するためにデータをコンピューティングノード間で伝送する
- 集計の中間結果は、クライアントアプリケーションに送り返される前にリーダーノードに送り返される

**コンピューティングノードタイプ**


| 種類 | 説明 |
|:-:|:-:|
| DS(高密度ストレージノードタイプ)  | ストレージに最適化されたHDD<br>DS1とDS２の２種類ある  |
| DC(高密度コンピューティングノードタイプ)  |  コンピューティングに最適化されたSSD<br>DC１の１種類しかない |




#### **【ノードスライス】**

- コンピューティングノードはスライスという処理の実行単位に分けたもの
- 各スライスは、ノードのメモリとディスク容量の一部を割り当てられて、ノードに割り当てられたワークロードを一部分を処理
- リーダーノードは、スライスへのデータの分散を管理し、クエリまたは他のDB操作のワークロードをスライスに分配

#### **【MPP(Massive Parallel Processing)】**

- リーダーノードが１タスクを複数のコンピューティングノードで分散割り当てして実行
- コンピューティングノードを追加することで容易にスケールアウト可能

#### **【シェアードナッシング】**

- 複数のサーバやコンピュータを利用した分散処理のシステムにおいて、それぞれに占有のストレージ領域を与えることで、自律的な並列処理を可能とすること
- 同一データなどに対する競合を防ぐことができる雨、処理速度を向上させられる。DWHなどに利用される
- 各のノードスライスは、専用のCPUコア、メモリ、ディスクを持っており、各ノードスライス間で基本的にデータを共有するようなことはしない


#### **【パラメータグループ】**

- パラメータグループ　： DBのコンフィグ
- 静的なパラメータの変更は、DBインスタンスを再起動する必要あり
- パラメータグループを変更することも可能

---
ex)
- auto_analyze
- enable_user_activity_logging
- require_ssl
- search_path
- statement_timeout


####**⭐️ 【拡張 VPCルーティング】**

- Redshiftはクラスターとデータリポジトリ間の全てのCOPYとUNLOADトラフィックがVPCを通るように強制

##Route53


**①シンプルルーティング**

- 静的マッピングによるルーティング方式
- 複数の値を1つのレコードに設定すると、ランダムに応答する(DNSラウンドロビン)


**②加重ルーティング**

- 指定した比率で複数リソースにトラフィックをルーティングする
- 比率の合計100
- ex)A/Bテスト, Blue/Greenデプロイ, サーバー性能に応じた負荷平準化


**③フェイルオーバールーティング**


- ヘルスチェックの結果に応じて利用可能なリソースのみを応答する方式
- プライマリやセカンダリを登録
- 事前にヘルスチェックを作成し、設定時にヘルスチェックとの関連づけが必要

**④複数値回答ルーティング**

- `IPアドレス単位での正常・非正常を判断してルーティングできる`
- 複数レコードのうち、`正常なレコードのみランダムで応答させる方式`
- MAX IP8つ登録

**⑤レイテンシールーティング**

- ネットワークレイテンシーが最も低いリージョンのリソースを応答する方式
- 設定時に指定したIPアドレスのリージョンが選択されるので、セットIDを入力して登録

**⑥位置情報ルーティング⭐️**

- クライアントの位置情報に基づいて応答する方式
- ex)適切な言語でローカライズされたコンテンツの提供


**⑦地理的近接性ルーティング⭐️**

- ユーザーとリソースの地理的場所に基づいて応答


####**【IPフローティング】➡︎ ENIの付け替え**

- 障害発生時にダウンタイムをなくすため、Elastic IPを自動で付け替える機能




## CloudFront


- 世界中にある`エッジロケーションを利用してCDNとして利用できるグローバルなコンテンツ配信サービス`
- `GZIP圧縮`によってコンテンツを軽くすることで高速な処理可能 : リクエストヘッダー `Accept-Encoding:gzip`
→ 圧縮ファイルを供給すると非圧縮ファイルを供給するよりもコスト安い
- リージョナルエッジキャッシュというロケーションが追加されたが、ユーザー側で選択可能ではない
- 無料で新規ユーザーは50GBのデータ通信と2,000,000件のHTTPorHTTPSリクエストを毎月１年間利用できる
- CloudFrontへのHTTP GET/POST/PUTリクエストの最大ファイルは20GB
- ⭐️ プロキシされるHTTPメソッド PUT/POST/PATCH/OPTIONS/DELETEは直接オリジンに送信される (エッジキャッシュがスキップ)
- ⭐️ リクエスト時に決定される動的コンテンツもエッジキャッシュをスキップしてオリジンサーバーへアクセス
- webサイトのパフォーマンスを改善できる

#### CloudFront → S3

- OAI
- 署名付きURL
- 署名付きcookie


#### **【コスト】**

ざっくり : 転送量 x 単価 ＋ リクエスト数 x 単価　 = 料金

- インターネットへのリージョンデータ転送アウト(GB単位)
- HTTPメソッドのリクエスト料金(1万件あたり)
- オリジンへのリージョン内データ転送アウト

#### **【CDN(Content Delivery Network)】**

- webサーバーがコンテンツを配信する際にその前段としてCDNを配置
- `コンテンツをキャッシュすることでwebサーバーの負荷を軽減`
- キャッシュがないときはサーバーに取りに行く
- キャッシュがあるときはCDNがコンテンツを返す

#### **【CloudFrontディストリビューション (CloudFrontの設定のこと)】**


- オリジンサーバーでオブジェクトを保存した後、`オブジェクトがどこにあるかをCloudFrontに伝える役割を持つ`
- ディストリビューションを作成すると、CloudFrontはあなたがオブジェクトを管理するために使用する一意のドメイン名を提供
- 作成可能なディストリビューションは2つ

(1)ダウンロードディストリビューション : HTTP or HTTPSを使用してコンテンツを配信
(2)ストリーミングディストリビューション

- `コンテンツオリジン` : どのサービスのコンテンツ配信を高速化するか
- `地域制限` : 特定の国のユーザーがコンテンツにアクセスできないようにする
- `セキュリティ` : HTTPSを必須にするかどうか
- `アクセスログ` : cloudFrontでviewerのアクティビティを示すアクセスログを作成するかどうか


#### **【オリジンアクセスアイデンティティ(OAI)】**

- `S3にあるwebコンテンツを配信する時に、CloudFrontからのみアクセスさせる仕組み`
- **閲覧者のS3への直接アクセスはブロック**

#### **【署名付きURL】**

- URLを知っている人だけが、CloudFrontからコンテンツを取得することができる
- 個々のファイルへのアクセスを制御する場合に使用
- 署名付きCookieはRTMPディストリビューションではサポートされていないため署名付きURLを利用する
- ユーザーがCookeiをサポートしてない場合は使う


#### **【署名付きcookie】**

- 特定のcookieをセットされている人だけが、cloudfrontからコンテンツを取得することができる
- 複数の制限されたファイルへのアクセスを提供する場合など
- **URLを変更したくないときに利用** ⭐️

#### **【コスト】**

- トラフィックの分散
- リクエスト数
- データ転送アウト


| 用語 | 説明 |
|:-:|:-:|
|  OAI |  ・OAIはS3バケットへのアクセスをCLoudFrontからのリクエストを絞るための仕組み<br>・OAIと呼ばれる特別なユーザーを作成し、そのユーザーに限定してアクセスを許可 |
|  カスタムヘッダー | カスタムヘッダーをオプションで設定して、カスタムオリジンへのアクセスを制限する仕組み  |
|  Viewer Protocol Policy |  ・HTTPとHTTPS両方nにアクセスできる<br>・HTTPをHTTPSにリダイレクトにする<br>・HTTPSのみアクセスさせる |
|  Origin Protocol Policy | CloudFrontからオリジンへのアクセスプロトコルをここで指定できる  |



#### **【キャッシュ有効期限】**

| 用語 | 説明 |
|:-:|:-:|
|  TTL | CloudFront配信時に設定されるキャッシュ保持時間  |
| Expires  |  キャッシュの期限切れを設定 |
|  Cache-Control max-age | CloudFrontがオリジンサーバーからオブジェクトを再度取得するまでオブジェクトをキャッシュに保持する期間を指定  |


#### 【フィールドレベル暗号化】

- 個人を特定できる情報などの機密データのセキュリティをより強化
- ユーザーが決めたフィールド固有の暗号化キーを使用して、リクエストがオリジンに転送される前にhttps内で機密データをさらに暗号化


## Global Accelerator

- TCP or UDPを介して様々なアプリケーションのパフォーマンス向上
- 1つ以上のAWSリージョンで実行されているアプリケーションにエッジでパケットをプロキシすることにより、TCPまたはUDPを介した幅広いアプリケーションのパフォーマンスを向上
- CloudFrontに似ている
- HTTPだけでなく、TCP/UDPのトラフィック・ルーティングに対応
- クライアント証明書は利用する、クライアントIPは保存する
- アプリケーションをエッジロケーションで実行、CDNのアプリケーション版
- キャッシュを使わず幅広く柔軟に対応できるので Global Accelerator、キャッシュを使ってお手軽にCDNを構築するのでCloudFront
- HTTPの特に静的IPアドレスを必要とするユースケースや、高速なリージョン間フェイルオーバーに適しているだけでなく、HTTP以外のユースケース、例えばゲーム(UDP), IoT(MQTT), VoIPにも適している

## S3  (Simple Storage Service)

- オブジェクトストレージ
- デフォルトで複数AZに冗長化
- ⭐️ アプリケーションでバケット内のprefixごとに1sあたり3,500回以上のPUT/COPY/POST/DELETEリクエスト or 5,500回以上のGET/HEADリクエスト達成できる
- prefixを増やせば並列化できる

| 名称 | 取り出し時間 | 説明 | 
|:-:|:-:|:--|
| S3 standard<br>（標準） |  即時 |  ・複数箇所にデータ複製、**最もコストが高い**<br>・頻繁にアクセスされるデータに高い耐久性、可用性、パフォーマンスオブジェクトストレージ |   
|  S3 Standard-IA <br>(標準-低頻度アクセス) | 即時 |  ・標準に比べて安価<br>・データの読み出しに対してコスト発生<br>・低頻度アクセス用だが読み込みはすぐできる |  
| S3 Intelligent-Tiering |  即時 |  ・アクセスパターンに基づいてコスト効率の高いストレージ階層に自動で移動、または不明な存続期間が長いデータ向け |   
| S3 One Zone IA <br> (1ゾーン低頻度アクセス) | 即時 | ・標準-IAより安価。<br>・1つのAZのみにデータを保存。<br>・ログファイルとかがベスト<br>・データへのアクセス頻度が低く、高い耐久性を必要とせずかつ必要に応じてすぐに取り出したい場合に適している。<br>・AZで障害時にデータが消滅する場合がある  |   
| Glacier |  数分-数時間 |  ・アーカイブ目的。標準と比べても格納コスト1/5<br>・データの読み出しに料金がかかる<br>・最低保持期間が90日|   
|  S3 Glacier Deep Archive |  数時間 | ・長期アーカイブデータ向け<br>・Glacierより安価。  |   

| - | S3 Glacier | S3 Glacier Deep Archive |
|:-:|:-:|:-:|
|  迅速 | 1-5分  | 利用なし  |
|  標準 |  3-5h | 12時間以内  |
|  大容量 |  5-12h  | ４８時間以内 |




#### **【コスト】**



- `ストレージ容量`
- `データ転送` : 課金されるのはS3からの送信だけ、受信(upload)は無料

*インターネットへの送信、別のAWSリージョン、CloudFrontへの送信は別料金
*同一リージョン内のAWSサービスとの通信は無料


- `リクエスト数`

*S3では、GET/PUT/POST/LIST/COPYなどのリクエストに対しても課金ある
*GETは安い、PUT/POST/LIST/COPYは高め
*DELETEは無料

#### **【署名付きURL(Presigned-URL)】**

- 特定のURLからのみS３にアクセスできるようにする機能

#### **【ライフサイクル機能】**

- S3上で一定期間経過したオブジェクトを自動的に削除したり標準IAやGlacierに移行する機能

#### **【バージョニング】**

- 有効にすると、S3内のオブジェクトのあらゆるバージョンを取得できる
- **意図しないオブジェクトの削除を行ったときも復元できる**
- ⭐️ 一度バケットのバージョニングを有効にすると、バージョニング無効の状態に戻すことはできない (停止は可能)

#### **【静的webサイトホスティング】**

- htmlファイルや画像ファイルなどをS3において、クライアントからのリクエストに応じてそのまま表示
- サーバーなしにwebサイトをホスティング可能
- サーバーが必要ないために値段が安い
- 動的サイトは不可、SSL設定はCloudFront必須

#### **【S3の暗号化】**

| 名前 | 説明 | 鍵の管理場所 | 手間 | 料金| 
|:-:|:-:|:-:|:-:|:-:|
|  SSE-S3 |  ・AES-256 暗号化タイプ <br>・"x-amz-server-side-encryption":"AES256" <br>・利用状況の監査証拠がとれない|  S3 |  少 |無料|
|  SSE-KMS | ・"x-amz-server-side-encryption":"aws:kms"ヘッダーを設定して利用する<br>・cloudtrailにより証跡ログが取得可能 |  KMS |  中 | KMSの料金が適用|
|  SSE-C |  ・AES-256 暗号化タイプ |  ユーザー |  多 |?|
|  CSE(Client Side Encryption) | クライアント側 |  ユーザー |  多 |?|


- KMSでカスタマーマスターキー(CMK)を削除することは破壊的行為であ利、危険性を伴う
- だから、KMSには`削除待機期間が設定されている`
- KMSでCMKを削除するには、キーの削除スケジュールを設定しておく必要がある
- 待機期間は、最短7日から最長３０日(デフォルトでは30日)

#### **【アクセス制御】**


| 種類 | 対象 | 説明 |
|:-:|:-:|:-:|
| ACL  | バケット・オブジェクト   | 簡単に設定できるがその分柔軟なアクセス制御はできない  |
| バケットポリシー  | バケット  |  設定は複雑、柔軟なアクセス可能 |
| IAMポリシー  |  IAMユーザー/グループ |  S３への操作権限をIAMユーザー・グループに対して付与 |


- `Public Access`
- バケットポリシーが不正に書き換えられ、バケット内のオブジェクトが公開されることを防ぐ機能
- 外部に公開しないバケットは有効化

####**【CORS (Cross-Origin Resource Sharing)】**

- すでにドメインが設定されているS3バケットを他のドメインに共有することができる

#### **【S3 クロスリージョンレプリケーション(CRR)】**

- S3オブジェクトを別リージョンのバケットに自動で複数することが可能
- オブジェクトの登録と同時に実行
- バケットにおけるオブジェクトの作成・更新・削除をトリガーにレプリケーションを実行


#### **【S3 select vs Athena vs Redshift Spectrum】**

| 用語 | 説明 | 
|:-:|:-|
|  s3 select | ・単一ファイルが対象<br>・GZIP圧縮データやCSV・jsonに対して実行可能<br>・クエリの機能が少ない<br> | 
|  Athena | ・複数のファイルを対象にできる<br>・クラスタ(サーバ)を必要とせず、S3にデータがあればすぐに利用可能<br>リトライ機能がなく、データを絞って高速にスキャンする<br>S3上のログ等にデータを保管しておりそれを分析用途に簡単に利用したい場合<br>S3をデータレイクとして位置付け、S3上のデータに直接アクセスできるインターフェースを用意<br>Athena SQLクエリでSageMaker機械学習モデルを呼び出し、機械学習による推論も実行可能| 
|  Redshift Spectrum | Redshiftクラスタが起動されている前提であるため、RedShiftを利用している場合におすすめ<br>大規模データに対して、複数クラスタで動作するため高速なレスポンスが期待できる <br>・S3にデータをおいたままそのデータにアクセスできる方法 | 
|  Macie | 機械学習によりS3の機密データを検出、分類、保護する、フルマネージド型のサービス |

- S3をデータレイクとして位置付け、S3上のデータに直接アクセスできるインターフェースを用意


- S3に格納された複数のファイルに対してクエリを行う→`Athena, Redshift Spectrum`



 
#### 【S3 Transfer Acceleration】

- 地理的に一番近いエッジロケーションを利用して高速にデータアップロードを実施
- 送信元から遠く離れたs3へのデータ転送をAWSのエッジロケーションとしてネットワークプロトコルの最適で高速化するサービス
-  ユースケース : 世界中からアップロード, 大陸間で定期的にGBからTBのデータを転送するケース
-  費用 : 1GB uploadあたり、$0.04が上乗せ  


#### 【S3 マルチパートアップロード】

- 大容量のファイルを分割して転送する機能→**S3へのアップロード時間の短縮**
- オブジェクトサイズが100MB以上の場合は、単一のオペレーションでオブジェクトをアップロードする代わりにマルチアップロードを使用する必要がある
-  S3 Transfer Accelerationと併用すると転送速度が一段と向上 


- S3バケットに保存できるオブジェクトの最大ファイルサイズ→5TB
- `prefix`を利用して日付ベースでuploadを分散することで少なくとも3,500 request/s, データ取得で5,500/sサポート
- S3のPath : `s3://<bucket>/<prefix>/<object>` (prefix : ディレクトリみたいなもの)

#### 【S3イベント】

- S3オブジェクト操作と連動したシステム連動処理
- SNS / SQS / Lambdaに通知設定


## RDS  (Relational Database Service)

- RDBSサービス
- データ操作にSQL使用
- 障害時や誤作動が起きた際に５分前の状態に戻せる
- RDSインスタンスにSSHはできない
- DBインスタンスはMAX７日間停止できる
- `最大で５個のリードレプリカ`を作成して、読取処理の負荷分散可能
- ファイルシステムとの連携はサポートされていないため、連携を実現するためにはEC2インスタンスにデータベースをインストールしてサーバを構築する必要がある
- ライフサイクルポリシーによるBUはできない
- `EC2インスタンス＋EBSの構成が例えばMYSQLをインストールして動かしている`
- マルチAZ構成のRDSでは、プライマリデータベースのインスタンスがダウンした場合に管理者の介入なしにDB操作できるようにフェールオーバーが自動的に処理される。フェイルオーバーするとRDSはDBインスタンスのCNAMEレコードをスタンバイから切り替えて、新しいプライマリに昇格


#### **【RDS暗号化】**

- RDSの暗号化されたDBインスタンスDBでは、基盤となるストレージに保存されているデータが暗号化され、自動化されたバックアップ、リードレプリカ、スナップショットも同様に暗号化される

#### **【RDSのスケールアップ】**

- インスタンスサイズの変更
- インスタンスタイプの変更
- ストレージタイプの変更

#### **【リードレプリカ】**

- RDSにおいてDB読み取り処理をオフロードすることできる機能
- 読み込み専用
- マスターの複製DB
- マスターの読み取りにかかる負荷を軽減でき、これによりマスターのパフォーマンスが向上


#### **【レプリケーションラグ】**

- リードレプリカは非同期にレプリケート
- レプリケーションデータが遅れることが多く、最新のトランザクションのいくつかを表示できないことあり


#### **【IAMデータベース認証】**

- 通常のパスワードを使ったデータベースの認証の代わりが権限を付与したIAMロールを用いることで認証を行う



#### **【RDSプロキシ】**

- アプリケーションとRDSの間に配置され、ProxyとしてDBへの接続を効率的に管理
- 高速フェイルオーバーによる可用性の向上
- Lambdaを利用してRDSのデータベースnに接続する際は、RDSプロキシをエンドポイントの代わりに利用して、接続することでコネクションを効率的に実行することができる
- 「接続が多すぎる」エラーが頻繁に発生するDBインスタンスやクラスターは、プロキシ経由が良い
- Lambda -> RDS Proxy -> RDS Good!

#### **【ストレージオートスケーリング】**

- 実際にストレージが少なくなって来ると自動でストレージがサイズアップしてくれるようになり、実際に使う分＋αだけ支払えば良い


#### ⭐️【読み取りリクエストが急増した時の対応】

- リードレプリカ増設(コスト低い)
- インスタンスタイプの性能変更
- キャッシュレイヤーでElastiCache(コスト高)

## Aurora

- 大規模なクエリ処理が発生するRDB
- クラウド専用の分散型のRDS
- `MySQLと比べて最大５倍、標準的なPostgreSQLと比べて最大で３倍高速`
- 商用DBと同等のセキュリティ、可用性とかを`1/10で実現`
- `最大15のリードレプリカ`を利用した高速読み込みが可能
- Auroraはクラスターが`3つのAZに分散されて構成`され、さらにRDSと同様にマルチAZのフェールオーバー構成を有効化することが可能
- フェールオーバーの実行時間はAuroraレプリカを作成している場合は`30s以内`に完了



#### 【Aurora Multi-Master】

- 全てのDBインスタンスで書き込みオペレーションを実行
- ⭐️ DBの書き込み操作のためダウンタイムを許容できない時使用

#### **【Aurora Serverless】**

- 自動でスケールして、アクセスがなければ勝手に停止するAWSのMySQL/PostgreSQLインフラ

#### **【Aurora Global Database】**

- Auroraクラスターを複数のリージョンにまたがって構築
- AWSリージョン障害時の災害復旧実現
- 世界中からデータベースを高速に読み書き実現
- プライマリ・リージョンから別リージョンへ低レイテンシーにデータがレプリケート
- `書き込み転送機能` : 有効にするとセカンダリリージョンでは読み込みだけでなく書き込みも可能

## DynamoDB

- マネージドの`NoSQLデータベースサービス`
- データが`3つのAZに分散`して格納されるため耐久性が高く、格納容量に上限がない
- また、key-value形式で簡易に操作できるかつレイテンシーが低いため、`キャッシュやwebセッションの格納先`としても利用
- 小規模データを保存、処理するためにはNoSQLDBを利用することが最適
- `API経由操作`キーに対するvalueのCRUD操作は可能、ただしJOIN/Transaction/Commit/rollbackは不可
- Read/Writeが多いシステムにgood
- `WEBセッション管理`, `S3オブジェクトのメタデータ`の保存に使用
- データサイズは無制限、1つのデータは４００KBに制限



####**【DAX  (DynamoDB Accelerator)】**

- `DynanoDBに特化したインメモリキャッシュ`→DynamoDBテーブルへの数ミリ秒のレイテンシーを数マイクロ秒に短縮
- DAXは、開発者がキャッシュの無効化、データ入力、クラスターの管理を実施する必要なし


#### **【DynamoDBストリーム】**

- テーブル上の作成、更新、削除の時に別のAWSサービス(ほぼlambda)を`トリガーとする機能`
- トリガーを利用してLambdaを実行するなど
- DynamoDBテーブルに保存された項目の追加・変更・削除の発生時の`履歴をキャプチャできる機能`

データの保存

- 過去２４時間以内のデータ変更の履歴を保存し、２４時間を経過すると削除される
- データ容量はマネージド型で自動的に管理

データ保存の順番 : 操作が実施された順番に応じてデータはシリアライズされる

#### **【DynamoDBグローバルテーブル】**

- ほかのリージョンにテーブルのレプリカ作成
- グローバルテーブルを作成するためにはまず１つのDynamoDBテーブルを作成してストリームを有効にする

#### **【DynamoDB AutoScaling】**

- テーブルとインデックスを監視してアプリケーショントラフィックの変化に応じて、自動的にスループットを調整
- DynamoDBテーブルを作成するとAutoScalingがデフォルトで有効
- CloudWatchのモニタリングに基づいてトラフィックパターンに応じてプロビジョンスループット性能をユーザーにかわって動的に調整

#### **【整合性モデル】**

- 結果整合性
- 強い整合性

#### **【料金】**

(1) キャパシティユニット(read/write)
(2) ストレージ容量
(3) データ転送量

## ElastiCache

- 大量かつミリ秒未満の応答時間のデータを扱うアプリケーションのインメモリデータストアとして活用
- キャッシュエンジンは、`RedisとMemcached` が選択可能
- ユーザー行動データの高速な処理には最適なDB
- `ノード、シャード、クラスタ`の単位が存在する
- ユースケース : `セッション管理, メタデータの蓄積、ソーシャルメディアのデータ分析、DBキャッシュ処理、Pub/Sub処理、ランキング、レコメンデーション`

**ノード(Node)**

- キャッシュサーバで、ElastiCacheの最小単位
- 選択したノードタイプによって性能(メモリやCPUなど)が異なる

**シャード(Shard)**

- ノードをまとめるグループ
- 1つのシャードにプライマリノード1個と、リードレプリカ(読み込み専用)0-5個持つ

**クラスタ**

- シャードをまとめるグループ
- クラスタ毎にキャッシュエンジンを選択可能
- クラスタモードは有効と無効を選択可能



**インメモリキャッシュパターン**

- CDNのデータベース版
- 頻繁にアクセスするデータをDBではなくインメモリキャッシュに格納することで、`DBの負荷を軽減する設計パターン`



| Redis | Memcached |
|:-:|:-:|
|  ・高速に値をRead/Writeできるインメモリキャッシュ型DB<br>・シングルスレッド<br>・スナップショット機能がある<br>・データを永続化できる | ・ 高速に値をRead/Writeできるインメモリキャッシュ型DB<br>・マルチスレッド <br>・スナップショット機能がない<br>・データを永続化できない<br>・フェイルオーバーや復元できない|
|  ・複雑なデータ型が必要な時<br>・永続化が必要な時<br>・ フェールオーバーが必要な時<br>・pub/subが必要な時 | ・シンプルなデータ型だけで充分な時<br>・マルチスレッドが必要な時<br>・バックアップと復元の機能がない<br>・ キーストアに永続性がない |


- Redis : インターネットスケールのリアルタイムアプリケーションにミリ秒未満のレイテンシーで動作する超高速インメモリデータストア
- Redis : `ゲームリーダボード、機械学習、メディアストリーミング、リアルタイム分析、セッションストア`
- *RedisをDynamoDBと統合することもできるが、DynamoDBにフィットしているDAXを使うことに比べるとはるかに複雑
- ElastiCache for Memcached はS3の静的コンテンツを配信するためのキャッシュとしては使用できない

## 移行関連

**①AWS Application Discovery Service(ADS)**

- 移行計画を支援するサービス

**②AWS Database Migration Service(DMS)**

- データベースを短期間で安全にAWSに移行することが可能
- DB移行ツール

**③AWS Server Migration Service(SMS)**

- 仮想マシンの移行サービス
- VMware, Hyper-V, Azure上の仮想サーバーをAMIとしてAWSに移行
- 手間がかからない
- 無料

**④AWS Schema Conversion Tool**

- あるDBエンジンにおける既存のDBスキーマを、別のDBエンジンのスキーマに変換するツール


## LB

####**(1) 【Connection Draining】**

- `バックエンドのサーバーがELBから切り離されてもセッションを持ち続ける機能`
- `バックエンドのEC2を登録解除しても処理中のリクエストが終わるまで一定期間待つ`
- ソフトウェアのメンテナンスなどで使える機能
- 既存の接続を開いたまま、登録解除または異常なインスタンスへのELBのリクエスト送信を停止することができる
- これにより、LBは登録解除または異常なインスタンスに対して行われた実行中のリクエストを完了するトラフィック処理を実施
- `LBが接続を維持する最大時間を指定 : 1~3,600s (デフォルトは300s)`

#### **(2) 【スティッキーセッション】**

- セッションの維持を行う機能→`クライアントからのリクエストを毎回同じインスタンスに転送する機能のこと`
- HTTPレスポンスにELBでCookieを埋め込んでそのCookieを基にバインド先のインスタンスを固定する
- 送信先のEC2が障害によってダウンした場合は、セッションが途切れる問題が発生するのでELBによるスティッキーセッションは一時的に利用が良い



#### **(3) 【Cross-Zone Load Balancing】**

- `配下のEC2の負荷分散に応じて、複数のAzにまたがるEC2インスタンスに均等に負荷分散を行う`
- 各LBはすべてのAZの有効なインスタンスにリクエストを分散する
- これによりクライアントのDNSキャッシュが効いていてもバックエンドのインスタンスには適切に負荷分散がかけられる
- ALBでは常にクロスゾーンバランシングが有効になっている

#### **【Proxy Protocol (プロキシプロトコル)】**

- HTTPでいうところのX-Forwaded-forをHTTP以外で使いたい時のプロトコル

## EBS (Elastic Block Store)

- EC2インスタンスに接続して利用できるブロックレベルのストレージ
- OSから見えるストレージボリュームで、`アプリケーションやユーザーデータなどを格納`
- `スナップショットでバックアップされS3に保存、増分バックアップ`
- スナップショットはEBSの利用状況に関係なく、非同期に作成
- EC2とは独立
- SGによる通信制御対象外であり、全ポートを閉じてもEBSは利用可能
- 他のAZのインスタンスにはアタッチできない
- プロビジョンドIOPSのみ複数インスタンスで共有できる
- スナップショットの管理→DLMによる管理

**ストレージタイプ**

| 名称 | 説明 |
|:--|:--|
| ①汎用SSD<br>(GP2,GP3) | ・デフォルトのボリュームタイプ<br>**・安定したI/O性能が利用できる** <br>・ストレージの読み書きに関しては課金されない|
| ②プロビジョンドIOPS SSD <br> (io1, io2, io2 block express)|  ・**汎用SSDよりも高いI/O性能が求められるケース<br>・複数のEC２への接続が可能**<br>・ストレージ容量だけでなく指定したIOPS数に対しても課金されるため注意。 |
|③スループット最適化HDD(st1)|  ・主にファイルのシーケンシャルアクセスが多い場合に高いスループットを提供するタイプ。<br>・大規模なデータを扱う時good <br>・用途としてはMapReduce,ETL処理、ログ処理、DWH、ビックデータ分析など <br>・小さなファイルサイズを大量に読み書きするには向いていない|
| ④コールドHDD |  ・高いスループトが不要な場合には、より低価格なコールドHDDのタイプ。<br>・**ログファイル**の保管など高いスループットを求められないバックアップ領域などが主な用途 |
| ⑤マグネティック | 旧世代のボリュームタイプ |


- `IOPS` : ストレージが1sあたりに処理できる(I/O)アクセスの数(ストレージに書き込むのが早いかどうか)
- `スループット` : 単位時間あたりでどれくらいデータを転送できたか(処理能力が高いかどうか)
- ⭐️ ブートボリュームとしてスループット最適化HDD, Cold HDDは使用できない

#### **【DeleteOnTermination】**

- インスタンスが終了すると、EC2は接続されていた各EBSボリュームのDeleteOnTermination属性を使用して、ボリュームを存続させるかどうか判断
- 「非有効化」にすることでEBSボリュームのみ保持可能

#### **【DLM(Data Lifecycle Management)】**

- EBSのスナップショット作成や削除をスケジューリングできる
- EBSの定期的なバックアップスケジュールを実施して貴重なデータを保護
- 古いBUを削除してストレージコストを削減する

#### **【EBSボリュームの削除】**

- インスタンスを終了すると、EC２は接続されていた各EBSボリュームのDeleteOnTermination属性を使用してボリュームを存続させるか削除すべきか判断する

| 1 | 2 |
|:-:|:--|
|  ルートボリュームのEBS | デフォルト設定ではEC2インスタンスの削除と共にEBSボリュームも削除される  |
|  DeleteOnTermination属性 | ・有効にしているとEC2インスタンスの削除に応じてEBSも削除される<br>・非有効化することでEBSボリュームのみ保持可能  |

| 1 | 2 |
|:-:|:-:|
|  EBS |  ネットワークで接続されたブロックレベルのストレージでEC２とは独立管理<br> EC2を終了してもEBSデータは保持可能<br>SnapshotはS3で保存 |
| インスタンスストア  | EC2の一時的なデータが保持され、EC2の停止・終了と共にデータがクリアされる  |


- `EBSミラーリング` : 同じデータを複数のディスクに書き込むこと可能

#### 【Multi-Attach機能】

- 1つのプロビジョンドIOPS SSD(io1, io2)ボリュームを同じAZにある複数のインスタンスにアタッチ可能

#### 【RAID】

- RAID0 : 複数のディスクを１台のディスクのように扱う、ストライピング
- RAID1 : 2つのボリュームを同時に、ミラーリング

#### 【インスタンスストア】

- EBSよりもパフォーマンスが優れる
- データは揮発性
- インスタンスが停止・終了だと**データは失われる**
- スナップショットを取得することもできない
- `ただし、再起動ではデータは維持される`
- EBSは「ボリューム、IOPS、スナップショット」で費用が発生するのに対し、インスタンスストアの費用はEC2に含まれる

## **EFS (Elastic File System)**

- 複数のEC2インスタンスからアクセス可能な共有ストレージ(インターネットからは直接アクセスできない)
- 複数AZに分散して保存
- **NFSv4プロトコル** (Amazon FSx ときたら SMB Protocol)




#### 【マウントターゲット】

- EC2インスタンスから接続先のマウントターゲットを設定
- EC2→マウントターゲット→EFSの流れ


#### 【EFS Standard】

- 最高レベルの耐久性と可用性を必要とするワークロードに最適


 
#### 【EFS Standard-IA】

- EFSの低頻度アクセス用のストレージ
- 低頻度アクセスと判断されたものが自動的に安価なEFS IAストレージに移行してくれる
- ライフサイクル管理を有効に



| パフォーマンスモード | 使用例 |
|:-:|:--|
| 汎用  | ・ウェブ配信環境<br>・コンテンツ管理システム<br>・一般的なファイルサービス  |
| 最大I/O  |  ・ビッグデータ解析<br>・メディア処理 |




**AWS DataSync**

- `オンプレミスストレージとEFSの間`でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービス



#### 【Amazon FSx for Lustre】

- 多くのスーパーコンピュータで利用される高性能な分散ファイルシステム
- データリポジトリとのシームレスな統合
- S3のデータセットとAmazon FSx for Lustreファイルシステムを関連づけ実際に処理を行う時にのみLustreを使用する
- 処理が終了したら、ファイルシステムを削除したらFXs for Lustreについては課金されない

## Kinesis

#### **【Kinesis Data Stream】**

- バッチ間隔を60sに設定など、バッチサイズまたはバッチ間隔を指定可能
- kinesis data streamのデータ保持期間はデフォルトで`24時間で、最大値は168時間`
- 配信ストリームは自動的にスケーリングされ1つのシャードは１sあたり１MBのデータを取り込むことができ、書き込みは１sあたり1,000レコードを取り込み可能
- 送信先にアップロードされたデータをKMS暗号化キーを指定して、自動的に暗号化を実施
- コンソールやCloud Watchからメトリクスを参照可能
- `送信データ量とデータ形式の変換に対してのみ料金が発生`
- ビッグデータのストリーミングをリアルタイムで処理

## CloudWatch

#### **【VPCフローログ】**

- VPCフローログはネットワークトラフィックを取得しCloudWatchでモニタリングできるようにする機能
- NICを送信先/送信元とするトラフィックが対象
- キャプチャウィンドウと言われる時間枠10minで収集・プロセッシング・保存する

## SQS

- フルマネージド型のメッセージキューサービス
- SQSを利用したポーリング処理 : イベントのトリガーをタイミングに依存しない連携が可能- 水平スケーリング : webシステムおアプリケーションの間にSQSキューを追加することによりスケーリングを実現
- SQSのキューによってEC２インスタンス側のワーカー処理を複数で並行処理をすることが可能
- メッセージ数は`無制限` (ただし、拡張クライアントライブラリーを利用すると２GBまでのメッセージのやりとりが可能)
- SQSに送信できる最大サイズは`256KB`
- デフォルト４日間 (SQS側での最長保持期間は`14日間`)
- オンプレ上でメッセージングサービスを利用しているシステムをそのまま移行する場合MQで、クラウドネイティブなサービスを構成する場合はSQSを利用する
- SQSは、リクエスト毎に課金が発生。MQは、利用した時間およびMQを通過したデータ量に応じて課金が行われる


#### キューの種類

| 種類| 説明 |
|:-:|:--|
| スタンダード  |  ・一回以上の配信 : １回は確実に送信されるが、複数回送信されることもある<br>・⭐️`ベストエフォート型` : メッセージが送信された時と異なる順序で配信されることがある <br>・メリットはほぼ無制限のスループット<br>・基本的に、順序性に依存せず、処理の重複を許容できるのであれば**スタンダードキュー**|
|  FIFO | ・ ⭐️ 一回だけの送信 : メッセージの重複は発生しない<br>・ 順序保証 : 先入れ先出しのため<br>・|


- バッチ処理を使用する時は、FIFOキューはAPIメソッド(SendMessageBatch, ReceiveMessage, DelettetMessageBatch)ごとに1sあたり最大3,000のトランザクションをサポート
- 3000のトランザクションは300のAPIコールを表し、それぞれに10このメッセージのバッチがある
- `デフォルトではFIFOキューは1sあたり300メッセージしか処理できない`


#### **【ライフサイクル】**

1. Producerがメッセージ送信
2. Consumerがメッセージを取得
3. Consumerが処理を終了し、メッセージを削除

*最長メッセージ保持期間を超えてキューに残っているメッセージは自動的に削除される
*`デフォルトのメッセージ保持期間は４日間`


#### **【可用性タイムアウト】**

- この時間内は他のコンシューマによる同じメッセージの受信と処理が防止される
- メッセージのデフォルトの`可視化タイムアウトは30s (min0s, max 12h)`


#### **【遅延キュー】**

- キューへの新しいメッセージの配信を数秒延期させることができる
- 遅延期間の間コンシューマーに表示されなくなる


#### **【SQSパラメータ】**



| パラメータ | - |
|:-:|:-:|
| receiveMessageWaitTimeSeconds  | ・Lambdaがメッセージをポーリングして応答を返す前に待機する時間(1-20s) <br> ・ 0を指定すればショートポーリング0を指定すればショートポーリング |
| visibilityTimeout  | メッセージがキューから読み取られた後、メッセージがconsumerに表示されない時間の長さ  |
| maxReceiveCount  | メッセージをDLQに移動する前に、送信元キューに表示されるように配信できる回数  |
| maximumBatchingWindow  | Lambda関数を起動する前に。SQSのレコードを集めるための最大時間。最大300sまで設定可能  |






| 1 | 2 |
|:-:|:---|
|  Step Function | ・細分化した機能を連結させて、視覚的に設計ができるサービス<br>・ユースケース : 注文処理、在庫追跡、複雑なユーザー登録プロセス、管理者が承認した場合に限り処理を行う  |
|  Simple WorkFlow | ・ワークフローを構築・実行するためのサービス<br>・EC2インスタンスを利用したサーバーベースのワークフロー機能であるためサーバーレスオーケストレーションは提供していない |




##SNS

- フルマネージド型のPub/Subメッセージングサービス
- Push機能
- 更新を定期的に確認したり、「ポーリング」したりする必要性がない
- 送信側がトピックを作成して受信側をポリシー指定することで制御された非同期通信を実現



## Amazon MQ

- メッセージブローカー
- 業界標準のAPIおよびプロトコルをサポート (従来のメッセージコードを書き換える必要なく現状維持できる)



## VPN

- VPN設定に必要 : `仮想プライベートゲートウェイ`, `カスタマーゲートウェイ`


## CloudFormation

| 用語 | 説明 |
|:-:|:---|
|  変更セット | ・スタックの更新前にリソースの更新や削除を把握することができる  |
|  ドリフト |  ・CFテンプレートの内容と、実際のリソースの異なる点を発見してくれる便利な機能 |
|  StackSets | ・複数のアカウントおよびリージョンのスタックを一度のオペレーションで、作成、更新、削除できる機能  |



## AWS Secrets Manager

- DBの認証情報やパスワードなどの任意のシークレット情報をAPIコールで取得できるもの
- アプリケーションにシークレット情報を保存する必要がなくなる
- DB認証情報を格納して自動ローテートするたのセキュアな方法


## AWS KMS(Key Management Service)

- データを暗号化するための鍵の管理を行ってくれるサービス
- 暗号鍵をAWSの責任範囲において保管したり、更新したりしてくれる
- データの暗号化の鍵(データキー)と暗号化のための鍵(マスターキー)を管理
- CloudHMSより安価
- サポートされる暗号鍵は、KMS:共通鍵, CloudHMS : 共通鍵と公開鍵

## AWS CloudHSM

- 専用のハードウェアで暗号化キーを保管
- CloudHSMの方がより安心してキーを管理することができる
- KMSに比べると高価

## AWS Directory Service

**セキュリティ保護サービス**

(1) AWS WAF

#### (2) AWS Shield : DDoS攻撃からリソースを守るサービス

- 

#### (3) GuardDuty : 脅威を検出するサービス

- **CloudTrailイベントログ、VPC フローログ、DNSログ**などの複数のAWSデータソース全体で何百億件ものイベントを分析
- AWSのアカウント、ワークロード、S３に保存されたデータを保護するために、悪意あるアクティビティや不正な動作を継続的にモニタリングする脅威検出サービス
- 設定画面でGuardDutyを無効にする : GuardDutyがAWS環境を監視して新しい結果を生成するのを停止するだけでなく、既存の結果とGuardDutyの設定も失う


#### (4) Inspector :  セキュリティの脆弱性評価

- 自動化されたセキュリティ評価サービスで、EC2インスタンスへの意図されていないネットワーク経路や、脆弱性をチェックできる

## AWS Storage Gateway

- `オンプレミス環境にあるデータをクラウド上のストレージにおく`。そのためのゲートウェイ
- EC2インスタンスだけでなくオンプレミスサーバーにs3をマウントして利用も可能
- データを暗号化できる
- データの格納先　: S3, EBS, Glacier(ストレージゲートウェイの種類によって格納先が異なる)


| 1 | 2 | 3 |
|:-:|:-:|:---|
| (1)ファイルゲートウェイ  |   |  ・**オンプレミスに保存しているファイルをS3のオブジェクトとして保存**<br>・S3の1オブジェクト = オンプレミスの１ファイル<br>・NFS / SMBプロトコルで接続NFS / SMBプロトコルで接続 |
| (2)ボリュームゲートウェイ  |  キャッシュ型 | ・`プライマリはS3ストレージ`<br>・プライマリーデータをS3に保存して、頻繁にアクセスされるデータはキャッシュしてローカルに保存  |
|   | 保管型  | ・`プライマリーオンプレミスストレージ`<br> ・メインデータはローカルに保存する一方で、そのデータを`非同期にS3にバックアップする |
| (3)テープゲートウェイ  |   | ・物理テープライブラリへの代替として、ストレージゲートウェイを仮想テープライブラリとして使用  |






## API Gateway

- APIの作成・管理を行う
- REST(ステートレス)とWebSocket(ステートフル)のAPI対応

#### **【設定項目】**


| 用語 | 説明 |
|:-:|:---|
| メソッドリクエスト  |  リクエストに認証が必要か、どのようなクエリパラメータを受け付けるかといったAPI Gatewayの受付設定を行う  |
| 統合リクエスト  | アップストリームの指定、リクエストボディの変換といったAPI Gatewayとアップストリーム間の統合を行う  |
| 統合レスポンス  | ステータスレコードのマッピング、レスポンス内容の変換といったアップストリームとAPI Gateway間の統合を行う  |
| メソッドレスポンス  | ステータスレコードごとのレスポンスヘッダーやレスポンスボディの設定といったAPI Gatewayからクライアントへのレスポンス設定を行う  |



#### **【APIの公開】**

- 作成したAPIを外部に公開するためにはデプロイを行う
- 各APIはデプロイ先としていくつかのステージを持ち、それぞれ異なるバージョンのAPIを公開することができる



#### 【スロットリングの利用】

- リクエスト数が多すぎる場合、制限をかけることで、トラフィックの急増に対してバックエンドサービスを守る

| 1 | 2 |
|:-:|:-:|
|  サーバ側 | 全てのクライアントに対するリクエストを制御する。全体のリクエストが多すぎるためにバックエンドサービスが処理できなく事を防ぐ  |
|  クライアントあたり | クライアントごとに「使用プラン」に応じて制限を行う。特定のユーザーからのリクエストが多い場合に有効  |

#### **【アクセス制御】**


◇ リソースポリシー(RESTのみ)

- JSON形式のリソースポリシーを定義することで、API Gatewayのどのリソースに、どのアクセスからの、どのようなアクションを許可/拒否するかを指定できる
- API Gatewayのリソースポリシー作成・更新のために必要な権限 : `apigateway:UpdateRestApiPolicy`と`apigateway:PATCH`権限必要
- リソースポリシーを設定・変更したら、APIのデプロイを実行

◇ IAM認証

- APIの各要素へのアクセス権限を設定したIAMポリシーを作成し、アタッチすることによりAPIへのアクセスの制御が可能になる
これには、対象の各APIメソッドでIAM認証を有効化する必要がある

⭐️ ◇ Lambdaオーソライザー

- `Lambda関数を作成することで、認証プロバイダーでの認証結果を元にAPIへのアクセス制御をメソッド単位で行えるようにする`

◇ Cognitoオーソライザー

- 認証プロバイダーとしてCognitoユーザープールを用いて、APIへのアクセス制御をメソッド単位で行うことも可能
- Lambda関数を作成する必要がない

◇ APIキー

- API Gatewayの使用量を制限するために発行するアクセスキー
- APIキーの使用量制限はそれぞれのAPIキーに対して設定するのではなく、`使用量プラン`という設定項目でスロットリング設定を行い、APIキーで使用量プランに紐付けることで設定



## Lambda

- DynamoDBから取得したデータに任意の集計をかける関数
- Lambda関数は実行数に応じて支払いが発生するため、Lambda関数が無期限に実行されないようにタイムアウト設定がされている
- 同一アカウントの同一リージョン内で1,000までの同時実行をサポート
- Lambdaの言語サポート : `C#/.NET, Go, Java, Node.js, Python, Ruby`

#### **【Lambdaの制限】**

- **タイムアウト(デフォ3s, max15分)** ⭐️
- 実行数はデフォルト100, max1000
- /tmp ディレクトリのストレージの保存可能容量512MB
- Lambdaレイヤー MAX5つまで
- Lambda関数は最大512MBまでのデータ容量


#### **【Lambdaレイヤー】**

- Lambdaファンクション間で共通するコンポーネントをLambda Layerとして定義し参照できる(5つまで)

## Fargate

- コンテナを実行する時にホストマシンとなるEC2のスペックを意識することなく設計できる
- ⭐️ コンテナ化されたアプリケーションが使用するvCPUとメモリリソースの量に応じて課金される
- vCPUとメモリリソースは、コンテナイメージがPullされてからECSタスクが終了するまでの時間が計算され、最も近い秒数に切り上げれる
- ⭐️ `EC2起動タイプのECSは、使用されたEC2インスタンスとEBSボリュームに基づいて課金`


## AWS Systems Manager

- AWSで利用のインフラストラクチャーを可視化し制御するためのサービス
- RGごとに運用データを確認できる
- EC2のパッチ、更新、設定変更、削除、停止、およびデプロイなどを自動化


## AWS Step Functions

- JSON形式でステートマシンを定義して、ワーカーフローやワーク処理系のアプリケーションを構築することが可能
- Lambda関数およびAWSの複数のサービスをビジネスプロセスとして配列することができるサーバーレスのワークフロー作成・管理サービス
- ワークフローに手動アクションを必要とするいくつかのタスクが存在する可能性があると、その手動アクションが処理されなければワークフローがアクション待ちの状態となるため、タスクが停滞

## AWS Organizations

- 複数のAWSアカウントに対してポリシーを設定してアクセス権限を管理
- AWSアカウントの作成と管理の自動化
- 複数アカウントをまとめたグループを作成し、アカウントを自動化し、それらのグループにサービスコントロールポリシーを適用することが可能
- 単一の組織内の複数AWSアカウントの支払いを統合できる
→ストレージの利用量を統合して請求することによって、コストを削減できる可能性


## AWS X-Ray

- ユーザーがAmazon APIからの`APIリクエストを通じてサービスを呼び出した場合に、ユーザーリクエストを追跡および分析`できる
- アプリケーションが処理するリクエストに関するデータを収集するサービスで、レスポンスタイムやレスポンスステータス、アプリケーションに対するリクエストに関するデータを収集し、コンソール上で表示したり分析することで問題を特定
- サービスマップと呼ばれるグラフから全体のパフォーマンスを確認することができ、リソースのレイテンシーや障害の発生率の特定などを確認できる


**サービスマップ**

- アプリケーションから生成されたトレースしたデータを可視化したもの
- クライアントが始点で、各サービスのノードが終点になる


##コストまわり

**AWS Billing and Cost Management**


**AWS Budgets**

- コストまたは使用量が予算額を超えた時にアラートを出すカスタム予算を設定可能
- 予約アラートできる

**Cost Explorer**

- これまでに発生したコストをグラフィカルに視覚化(過去のコスト確認)
- 課金状況を確認
- RIの使用率レポート / カバレッジレポート
- 課金状況を確認
- **RIの使用状況までわからない**


**コストと使用状況レポート (Cost & Usage Reports)**

- 利用可能な最も包括的なコストと使用状況のデータが含まれている
- RIの使用状況わかる
- AWSのコストと使用状況に関する最も包括的なデータを提供でき、またAthenaのデータ統合機能を使うことで、自分のコストと使用状況に関する情報に対してSQLできる
- Redshift or QuickSightにデータをupload可能
- コストを時間または日、製品または製品リソース、または自分で定義したタグごとに分類したレポートを受け取ることができる

**AWS 料金計算ツール**

- 費用見積もりツール
- 1ヶ月は７３０時間を前提


## AWS Snowball

- 物理ストレージデバイスを使用してS3に大量のデータを送るデバイス

####**(1)Snowball  (古い)**
50TB, 80TB

####**(2)Snowball Edge (推奨)**

- 100TB転送 (**利用可能は80TB**)
- 複数ディスクでクラスタリングを組むことできる
- snowballよりエンドポイントの選択肢が多い

| 1 | 2 |
|:-:|:-:|
| Snowball Edge Compute Optimized  |  機械学習とか |
|  Snowball Edge Storage Optimized | 大規模なデータ移行と定期的な転送ワークフロー、およびさらに高容量を必要とするローカルコンピューティングに適している  |

*`Snowball Edge Storage Optimized` : 数十テラバイトからペタバイトのデータをAWSに安全かつ迅速に転送する必要がある時に採用

#IAMロール
アプリケーションやAWSサービスに権限を与える仕組み。以下の2つの機能

**①Switchロール**

- IAMユーザーが異なるAWSアカウントを管理するために使用できる機能

**②IDフェデレーション**

- AWSのIDとは異なるIDを連携させる
(IAMユーザーを作成しなくても、FacebookのアカウントにAssumeRoleで権限を引き渡す)

**(1) Open ID Connector**

**(2) AD Connector**

**(3) SAML2.0** : オンプレでID管理サーバがSAML2.0に対応している場合



#### **【IAMの記録管理】**

| 用語 | 説明 |
|:-:|:-:|
|  IAM アクセスアナライザー | 外部エンティティと共有されているS3バケットやIAMロールなど分析してt、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスをt特定 |
| Access AdvisorのService Last Accessed Data  |  IAMエンティティが、最後にAWSサービスにアクセスした日付と時刻を表示する |
| Credential Report | 利用日時などが記憶されたIAM認証情報のレポートファイル  |
|  AWS Config | AWS ConfigはIAMユーザー、グループ、ロール、ポリシーの変更履歴、構成変更を管理するサービス  |
|  AWS CloudTrail|  各種アカウントアクティビティやAPIコールをログに記録し、モニタリングするサービス |



## 用語

- `AWS Lake Formation` : S3を利用したデータレイク構成を容易に実施
- `cloud9` : クラウドベースのIDE,エディタのインターフェースと実行環境を一緒にしたIDE
- `AWS Service Health Dashboard` : すべてのAWSリージョンで全てのAWSサービスの現在のステータスを確認できる
- `AWS Artifact` : 重要なコンプライアンス関連情報の頼りになる一元管理のリソース
- `Amazon Lightsail` : コンピューティング、ストレージ、データ転送などwebサイトやwebサービスなどに使うサーバーとして必要な機能を組み合わせてパッケージしたもの
- `Amazon Elastic Transcoder` : クラウドメディア変換サービス
- `Amazon Polly` : 文章をリアルな音声に変換するサービス
- `Amazon Rekognition` : 画像分析と動画分析をアプリケーションに簡単に追加
- `Amazon Lex` : 音声やテキストを使用して任意のアプリケーションに対話型インターフェースを構築するサービス


- `AWS IoT Core` : 外部のデバイスとクラウド側を安全に接続するためのサービス。IoTに特化したサービスなので、IoTを扱う場合はAPI Gatewayなどではなくこちらのサービスを使用することでデバイスからAWSにアクセスする際のエンドポイントや認証処理、イベント実行などを統合的に管理することができる

- `QuickShight` : RedShift, S3, Athena, Aurora, RDS, IAM, CloudTrainl, CloudDirectoryなどのAWSサービスと連携してBIツールとして

- `EMR` : オープンソースとしてのフレームワークであるsparkとHadoopを使用して、膨大な量のデータを迅速かつコスト効率よく処理。高速データ処理
- `AppSync` : GraphQLというwebAPIを用いてデータにアクセスでき、処理を行うことができるもの。APIで自動でデータを取りにいってくれる
- `Neptune` : グラフDB


## 試験Tips

- エッジロケーションで提供しているサービス : `CloudFront, Route53, WAF`
- VPC Peering : 中国リージョンでは利用できない

**顧客からの読み取りリクエスト増加対応**

- (1)リードレプリカの増設
- (2)インスタンスタイプの変更
- (3)キャッシュレイヤーでのElastiCacheの利用 (これは高価)

**特定の国からアクセスを拒否**

- Route53の位置情報ルーティングする
- CloudFrontの地域制限を利用する

**CPU70%でアプリが応答しない**

- RDS DBインスタンスにリードレプリカを追加して、アプリケーションの読み込み負荷を分散する
- 複数のRDS DBインスタンスを構築し、データをシェーディングする

**webページの平均読み込み時間を短縮**

- セッションとSQLクエリを保存するためにElastiCacheを使用し、DBの負荷を軽減する
- RDSのリードレプリカを使用する

**特定のユーザーに配信可能な方式**

- cloudFrontへのアクセスをOAIに限定
- cloudFrontの署名付きURLを利用

- VPC間の管理を効率化 = AWS Transit Gateway


**S3へのファイルをアップロード速度を向上させるための最も費用効果の高い方法**

- マルチパートアップロード
- S3 Transfer Acceleration


| 用語 | 説明 |
|:-:|:-:|
|  simple AD |  AWS側にフルマネージド型のディレクトリを新規作成 |
|  AD Connector | オンプレミス環境のActive DirectoryとIAM管理を統合<br>SSOと連携したtシングルサインオンが可能  |
|  AWS Managed Microsoft AD | AWS側にMicrosoft Active Directoryとの互換性があるフルマネージド型のADを作成  |




## 参考文献

- [【合格したので】AWS SAA 対策まとめ](https://nwengblog.com/aws-saa/)
- [Amazon Redshift まとめ](https://qiita.com/fururun02/items/1a8d938fae7ba1fc60ad)
- [Amazon SQSの学習(AWS認定Developer associate対策)](https://qiita.com/Junpei_Takagi/items/19e891368db8af8204e7)
- [Amazon API Gateway](https://qiita.com/leomaro7/items/66ea3233097fa410fef9)
- [Redshift Spectrumと Athenaの違いを探ってみた](https://qiita.com/kitaj/items/f6a1367f071cbe8e09e6)
- [AWSソリューションアーキテクト取得に向けて～Auto Scaling～](https://note.com/muroy/n/n0307b52ff17d)
- [Udemy : 【世界で3万人が受講】演習テスト: AWS 認定 ソリューションアーキテクトアソシエイト]()
- [Udemy : AWS認定ソリューションアーキテクト アソシエイト試験：短期突破講座（300問の演習問題）]()