# AWS SAAまとめ
## リージョン/AZ/VPC/[サブネット](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Subnets.html)
## 各サービスの場所([参考](https://qiita.com/saitotak/items/d2ede050e7a2224da46d))
※S3はバケット名がグローバルで一意でなければならないためにグローバルサービスに分類される
## IP/CIDR
### VPC/サブネットに設定可能なサイズ
| CIDR | 有効IP数 |
| - | - |
| /16 | 65531 |
| /18 | 16379 |
| /20 | 4091 |
| /22 | 1019 |
| /24 | 251 |
| /16 | 26 |
| /28 | 11 |
### サブネットで設定できないIPアドレス
※/24の例。上記有効IP数は既に下記を引いた数
| ホストアドレス | 用途 |
| - | - |
| .0 | ネットワークアドレス |
| .1 | VPCルーター |
| .2 | Amazon提供のDNSサービス |
| .3 | AWSで予約されているアドレス |
| .255 | ブロードキャストアドレス |

※IPアドレスの範囲は今後の拡張も踏まえ、十分な余裕がありつつ(不足しないよう)、多すぎない(コストに配慮)レンジを指定すること。

## サブネットの制約
* VPCのCIDRブロックの範囲のCIDRブロックをアサイン(サイズは上述)
* 1つのサブネットに1つの仮想ルータ(ルートテーブル/NW-ACL)を持つ
* 作成後にAZは変更できない
* 1つのVPC中200のサブネットを作成可能(申請すれば拡張可能)
* IPアドレスの確保が必要なサービスがある(ELBなら8個のIPが必要)

## [ルートテーブル](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Route_Tables.html)
* サブネットに1つ設定する
* 1つのルートテーブルを複数のサブネットと共有できる
* 1つのサブネットに複数のルートテーブルは適用できない
* 宛先のアドレスと、ターゲットとなるゲートウェイを指定する

## [セキュリティグループ](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_SecurityGroups.html) / [ネットワークACL](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html)

| セキュリティグループ | ネットワークACL |
| -- | -- |
| インスタンス(EC2等)単位の通信制御 | サブネットごとの通信制御 |
| インバウンド/アウトバウンドを制御<br>(プロトコル,ポート,CIDR,セキュリティグループ単位で設定) | インバウンド/アウトバウンドを制御<br>(プロトコル,ポート,CIDR単位で設定) |
| インバウンドは原則ブロック<br>アウトバウンドは原則許可 | デフォルトは全てアクセス許可 |
| ステートフル(状態を保持) | ステートレス(状態を保持しない) |

## ゲートウェイ

## [VPCピアリング](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-peering.html)

## [プレイスメントグループ](https://qiita.com/mzmz__02/items/8651f578601f3a567fa0)
単一AZ内にEC2を論理的にグルーピングしたもので、インスタンス間の通信を広帯域幅・低レイテンシーで通信することができる。

## [VPCフローログ](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html)
* VPC内の通信解析用ログ
* ENI(Elastic Network Interface)単位で記録
* 確認できる内容は、送信元/先アドレス・ポート・プロトコル番号・データ量・許可/拒否の区別

## [Direct Connect Gateway](https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-gateways-intro.html)
1つのDirect Connect接続で、拠点から複数のAWSアカウントやVPCに接続可能

## [AWS Transit Gateway](https://aws.amazon.com/jp/transit-gateway/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
複数のVPCとオンプレネットワークを中央ハブを介して接続可能

## [CloudFront](https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-overview.html)
* ユーザーに近いエッジロケーションにキャッシュするCDN
* バックエンドサーバー(オリジンサーバー)：元コンテンツを保持するサーバー
* オリジンサーバーとして指定可能なのは、①ELB ②EC2 ③S3(静的ホスティング) ④オンプレサーバー
* URLのパスに応じて異なるオリジンサーバーを指定可能(最大25)
　 → 1ドメインで複数サービスが提供可能となる
* 拡張子やURLパスごとにキャッシュ期間を設定可能(例：静的コンテンツは短く、画像は長く、動画サイトはキャッシュを無効化しNW経路だけ利用)

### CloudFrontのディストリビューション
|| ダウンロード<br>ディストリビューション | ストリーミング<br>ディストリビューション |
| -------- | -------- | -------- |
| プロトコル | HTTP,HTTPS | RMTP|
| 用途 | 静的コンテンツ配信 | 動画ストリーミング |
| その他 |-| 2020.12.31以降非推奨<br>→ AWS Media Services を推奨 |

## [Route53](https://aws.amazon.com/jp/route53/)
* ドメイン管理機能と権威DNS機能を持つサービス
* ドメイン名・IPアドレス変換情報を持つ「権威DNS」と持たない「キャシュDNS」がある
* Route53は権威DNS。保持するドメイン名以外の名前解決をリクエストしても応答しないキャッシュDNSは別に用意する必要がある
* 「トラフィックフロー」で設定を可視化できる

### [トラフィックルーティング](https://qiita.com/miyuki_samitani/items/0b2f155da75350629c7c)
| 名称 | 利用シーン |
| - | - |
| シンプルルーティングポリシー | 1レコードに1IPアドレス |
| フェイルオーバールーティングポリシー | プライマリのヘルスチェックに失敗したらセカンダリにルーティング |
| 位置情報ルーティングポリシー | 位置情報によって優先度を変える |
| 地理的近接性ルーティングポリシー | ユーザーとリソースの地理的場所に基づいてルーティング |
| レイテンシールーティングポリシー | レイテンシーが最小になるようルーティング |
| 複数値回答ルーティングポリシー | ランダムにルーティング |
| 加重ルーティングポリシー | 指定した比率でルーティング |

## EC2
* 起動用のイメージ = AMI(Amazon Machine Image) ※AMIデザインについて([参考](https://dev.classmethod.jp/articles/aws-answers-2019-ami-design/))
* 設定できるタグ(タグキー)の最大数は50
### インスタンスタイプ
| 種類 | 特徴 |
| - | - |
| オンデマンドインスタンス | 通常 |
| スポットインスタンス | 余剰分の入札。中断可能性あり |
| リザーブドインスタンス | 予約購入。スケジュール購入も可能 |

※Savings Plansという予約購入方法もある([参考](https://dev.classmethod.jp/articles/ec2-reserved-instances-savings-plans-comparison/))
### インスタンスファミリー([参考](https://zenn.dev/matsu7089/articles/meaning-of-ec2-instance-types)・[公式](https://aws.amazon.com/jp/ec2/instance-types/))
汎用
| ファミリー | 特徴 | 覚え方 |
| - | - | - |
| T | CPUバースト対応 | テスト用 |
| M | 最も汎用的 | |
| A | Armプロセッサ搭載 | |
| Mac | Apple Mac Mini搭載 | |

高速コンピューティング
| ファミリー | 特徴 | 覚え方 |
| - | - | - |
| P | 高速GPU搭載 | |
| G | グラフィックス最適化 | |
| F | FPGAカスタマイズ | |
| Inf | 機械学習最適化 | Inference |

コンピューティング最適化
| ファミリー | 特徴 | 覚え方 |
| - | - | - |
| C | 高い計算能力 | |

ストレージ最適化
| 種類 | 特徴 | 覚え方 |
| - | - | - |
| I | I/O性能が高い | |
| D | 最大48TBのHDD搭載 | |
| H | 高HDDスループット | |

メモリ最適化
| ファミリー | 特徴 | 覚え方 |
| - | - | - |
| R | メモリ最適化 | RAM |
| X | 最大メモリ量が大きい | Xサイズ |
| z | Armプロセッサ搭載 | |

### Termination Protection([参考](https://dev.classmethod.jp/articles/creating_and_deleting_ec2_with_delete_protection_in_cloudformation/))
- EC2を誤操作による削除（terminate）から守ってくれる機能
- EC2ダッシュボードの以下赤枠から設定できる
- CloudFormationで設定する場合は、DisableApiTerminationプロパティをtrueにすることで設定できる

### Elastic IP(EIP)
* EC2用の固定IP(リージョンごとに最大5まで)
* 起動中のEC2に1つのみ割り当てれば無料
* 未使用、停止中のEC2への割当て、1つのEC2に複数のEIPの割当ては有料

### [キーペア](https://stakiran.hatenablog.com/entry/2019/05/22/203921)
* EC2ログインに使用するパブリックキー(公開鍵)とプライベートキー(秘密鍵)
* ユーザーはプライベートキーを使い当該EC2インスタンスにログインする

## ELB
* ロードバランサー
* スケールアップ ... インスタンスのスペックを垂直に上げる
* スケールアウト ... インスタンスを並列に並べて負荷分散する
* スケールイン... 増やしたインスタンスを減らす
* SPOF ... 単一障害点
* ヘルスチェック
* 設定した感覚でEC2にリクエストを送り、異常なインスタンスは切り離し、正常になったインスタンスとELBとを紐付ける
* スケールアウトの種類
* 猶予期間
* ウォームアップ
* クールダウン
* その他
* ライフサイクルフック(起動/削除時に一時停止しカスタムアクションを実行)

### ELBの種類
| 種類 | 特徴 |
| - | - |
| CLB | L4/L7(古い)<br>ただしWebSocket,HTTP/2,パスベースルーティングに対応 |
| ALB | L7 |
| NLB | L4 |

### AutoScallingの種類
| 種類 | 特徴 |
| - | - |
| 動的 / 簡易 | 1つの閾値(非推奨) |
| 動的 / ステップ | 複数の閾値 |
| 動的 / ターゲット追跡 | 目的値を維持 |
| 予測 | |
| スケジュール | |

### 終了ポリシーの種類
| 種類 | 動作 |
| - | - |
| OldestInstance | 最も古いインスタンスを削除 |
| NewestInstance | 最も新しいインスタンスを削除 |
| OldestLaunchConfiguration | 最も古い起動設定のインスタンスを削除 |
| ClosetToNextInstanceHour | 次の課金時間に最も近いインスタンスをを削除 |
| Default | AZ間の台数の均衡を保つようにインスタンスを削除 |
| OldestLaunchTemlate | 最も古い起動テンプレを使用するインスタンスを削除 |
| AllocationStrategy | インスタンスタイプ(EC2参照)の配分戦略に沿って削除 |

Auto ScalingでスケールアウトしたEC2インスタンスは以下の順番でスケールインする(デフォルト)
1. インスタンス数が最も多いAZ
2. AZのインスタンス数が同じ場合は、起動設定が古いインスタンスがあるAZ
3. 起動設定が古いインスタンスが複数ある場合は、次の課金発生までの時間が最も短いインスタンス
4. 次の課金発生までの時間が同じインスタンスが複数ある場合はランダムで選択

## ECS
* Task ... EC2上で実行されるコンテナ
* Cluster ... (この場合の)EC2インスタンス
* Task Definition ... Cluster上で動作するTaskの定義
* Service ... 同じTaskを複数用意する場合に使用
* Taskに対しIAMを割り当てられる
* 一部のインスタンスには揮発性のストレージ「**インスタンスストア**」が利用可能([参考](https://dev.classmethod.jp/articles/howto-ec2-volatile-block-storage-instance-store/))
* 揮発性のため、一時ストレージにしか利用できないが、そのトレードオフとして、高いパフォーマンスを発揮する
* 以下の場合・タイミングでデータが消失する
* 基盤となるディスクドライブで障害が発生した場合
* インスタンスが停止した場合
* インスタンスが終了した場合
* スナップショットも取得不可
* ただし、再起動時はデータは維持される
* 一部のインスタンスでしか利用できない
* 第5・6世代ではC5d, M6gdのように「d」がつくインスタンスタイプ
* I3、F1

## Fargate
* Cluster用のEC2が不要
* ECSでのTask定義時にEC2/Fargateが選択できる

## EKS
* Kubernetesマネージドサービス
* Kubernetes用のEC2

## ECR
* Dockerイメージレジストリ
* レジストリへのpush/pull権限のIAM管理も可能

## CloudWatch
* AWSリソースからメトリクス(リソースの状態)を取得し、一定条件を満たした場合に通知することが可能(通知先:SNS等)
* 標準的なメトリクスは[こちらを参照](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)

### CloudWatch Logs
- アプリケーション、Apache等のログをモニタリング
- 収集したログに応じてアラートを発報できる
- 利用するにはインスタンスにエージェントをインストールする必要がある

### CloudWatch Events
- 独自のトリガー(「イベントソース」と呼ぶ)と何らかの後続サービスを組み合わせて定義できるサービス
- イベントソース：①スケジュール ②AWSリソースのイベント
- <b>[EventBridge](https://www.sunnycloud.jp/column/20210802-01-2/#:~:text=Cloudwatch%20Events%E3%81%A8%E4%BD%95%E3%81%8C%E9%81%95%E3%81%86%EF%BC%9F)</b>：CloudWatchの後継にあたるサービス。連携サービスの増加や、同一アカウント内におけるリージョンをまたいだイベントの集約が可能に。将来的にCloudWatch Eventsと統合予定

## CloudTrail
- AWSの操作ログを自動取得するサービス
- 自動取得できるイベントの種類
- 管理イベント
- マネジメントコンソールのログイン、リソース作成
- デフォルトで90日取得する設定になっている(90日前を残す場合はS3に証跡を残せる)
- データイベント
- S3バケット上のデータ操作、Lambda実行履歴
- デフォルトでは取得する設定になっていない → 設定することでS3に残せる
- CloudWatch Logsと連携させることで、事前に不正な操作を登録し、検知することができる

## Trusted Advisor([参考](https://dev.classmethod.jp/articles/cm-advent-calendar-2015-getting-started-again-aws-td/))
- EC2,RDSなどの設定についてベストプラクティスに基づき自動で推奨設定をアドバイスしてくれる
1. コスト
2. セキュリティ
3. パフォーマンス
4. 耐障害性
5. サービスの制限
- アドバイスはダッシュボードやメール通知で確認できる
- [詳細なチェックリスト(覚える)](https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/best-practice-checklist/)

## AWS Config([参考1](https://business.ntt-east.co.jp/content/cloudsolution/column-try-26.html),[参考2](https://cloudnavi.nhn-techorus.com/archives/3878))
- AWSリソースの設定を記録し、設定の変更や他のリソースとの依存関係が時間経過とともに確認できる
- あらかじめ設定したルールに基いた監視ができる(約200のルールが用意されている)
- 設定できるリソースは約40([詳細](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/resource-config-reference.html))
- サードパーティのリソースも監視できる(GitHubリポジトリ、MicrosoftADリソース、オンプレミスサーバーなど)

## IAM Access Analyzer([参考](https://dev.classmethod.jp/articles/iam-access-analyzer-vs-config-rules/))
- 外部公開できるサービスが、不要に公開されていないかを確認できる
- AWS Configでも外部公開サービスの監視・是正はできるが、IAM Access Analyzerの方が簡単に設定・是正ができる。(その分カスタマイズが効かない)
- 設定できるリソース
- Amazon S3バケット
- 外部公開可能
- **S3に特化した`Access Analyzer for S3`というサービスもある([参考](https://dev.classmethod.jp/articles/s3-access-analyzer/))**
- 見やすく、ボタン一つで是正も可能
- AWS KMSキー
- 外部から参照可能
- Amazon SQSキュー
- 外部からキューを入れることが可能
- AWS IAMロール
- クロスアカウントでRoleを引き受けることが可能
- AWS Lambda関数
- 外部から関数を実行可能

## EBS
- ブロックストレージ
- 追加ボリュームとして複数のEBSをEC2にアタッチすることも可能
- (逆に)複数のEC2から単一のEBSにアタッチすることは'原則'できない
※EBSマルチアタッチ機能により可能にはなったが制約が多い
- EBSは作成時にAZを指定する→指定したAZのEC2からのみアタッチ可能
- スナップショットを取得可能
→ そのスナップショットを利用して他のAZでEBSボリュームを作成し、そのAZのEC2にアタッチすることは可能
- 性能の指標＝「IOPS」(1秒あたりに処理できるI/Oアクセスの数)

### ボリュームタイプ
| 名称 | 略称 | 特徴 |
| - | - | - |
| 汎用SSD |　gp2 | SSDベースの汎用的なボリューム(後継のgp3もある) |
| プロビジョンドIOPS SSD |　io1 | 最も高性能なSSDをベースにしたボリューム。DBサーバー構築などに向く |
| スループット最適化HDD |　st1 | HDDベースのスループット重視のボリューム。大容量ファイルの読み込み等に向く |
| Cold HDD |　sc1 | 低コストなボリューム。アクセスが低頻度のアーカイブ用途等に適す |

※旧世代の「マグネティック」というHDDのストレージタイプもあるが新規作成時は利用しないこと

### EBSの拡張・変更
#### (前提)
- 変更から変更までは6h開ける必要がある
- EC2が現行世代以外のインスタンスタイプである場合、停止やデタッチが必要になる場合がある

#### 容量拡張
- 全タイプ最大16TB
- 拡張後はEC2インスタンス上でOSに応じたFSの拡張作業が必要
- 拡張はできるが縮小はできない

#### ボリュームタイプの変更
- 現行世代の4タイプの間でのタイプ変更が可能

#### SLA
- 99.99%

#### セキュリティ
- 暗号化オプションを有効にするとボリューム、スナップショットが暗号化される

### EBSマルチアタッチ
- 同一AZでのみマルチアタッチが可能
- プロビジョンどIOPS SSD(io1)のみ利用可能
- OSの標準FSはサポート外 → 排他制御の検討が必要

## EFS
- フルマネージド型のファイルストレージ
- 容量無制限
- 複数EC2インスタンスから同時アクセス可能
- NFSクライアントがあれば利用可能
- amazon-efs-utils というツールも公式から出ている

### EFSの構成(流れ)
1. ファイルが作成されると同時に3箇所以上のAZに分散FSを構成
2. 1.のFSにアクセスするために各AZの指定したサブネットにマウントターゲットを作成
3. 2.を作成すると2.へアクセスするためのターゲットポイント(接続FQDN)と各マウントターゲットへのアクセス用のIPアドレスが発行される

※マウントターゲットにセキュリティグループを設定可能：EC2→EFSへのアクセス制限が設定可能

### EFSのパフォーマンスモード
| モード | 特徴 |
| - | - |
| 汎用パフォーマンスモード | 殆どの場合はこちらを使えばよい。 |
| 最大I/Oパフォーマンスモード | 数百〜数千のクライアントからの同時接続が想定されるようなケースで使用。スループットが最大化する代わりにレイテンシーが高くなる。 |

#### パフォーマンスモードの見分け方・留意点
- CloudWatchのPercentIOLimitというメトリックスを参考にする
- 汎用パフォーマンスモードを選択し性能テストを実施
→ PercentIOLimitが長時間80-100%である場合は最大I/Oパフォーマンスモードを選択した方が良い場合がある
- パフォーマンスモードは一度設定すると変更ができない

### EFSのスループットモード
#### バーストスループットモード
- EFSに保存データ容量に応じ、ベースラインのスループット・期間を設定
- バースト機能を持つ。バースト期間は上述スループット・期間による
- 保存データ容量が1TBを超えると、毎日12h、1TBあたり100MB/秒のバーストクレジットが付く

#### プロビジョニングスループットモード
- バーストスループットモードの基準を超えるスループットが必要な場合に使用
- 任意のスループットの値を設定できるが1GB/秒まで。それ以上の設定は緩和申請が必要
- データサイズはそこまで大きくないものの、頻繁なアクセスが想定されるデータをEFSに配置する場合に選択

#### スループットモードの見分け方・留意点
- CloudWatchのBurstCreditBalanceというメトリックスを参考にする
- 以下の場合は、プロビジョニングスループットモードを選択
- クレジットバランスを全て使い切っている場合
- クレジットバランスが減少傾向の場合
- スループットモードは途中で変更できる
- ただし24h空ける必要がある

## S3
- 優れた耐久性を持つ容量無制限のオブジェクトストレージ
- REST APIでアクセス
- 「大量・大容量」「長期間保存」「なくなると困る」データの保存に向く

### ストレージクラス
| ストレージクラス | 対象 | AZ | 可用性 | 最低保存期間 |
| - | - | - | - | - |
| 標準 | ・頻繁にアクセスされるデータ | 3以上 | 99.99% | 30日間 |
| Intelligent-Tiering | ・アクセスパターンが変動/不明なデータ<br>→アクセスがあるファイルは高頻度(標準)に維持しつつ、アクセスがないファイルは低頻度(標準IA)に自動で移動<br>・長期アーカイブデータ | 3以上 | 99.9% | 30日間 |
| 標準 – 低頻度アクセス | ・頻繁にアクセスされないデータ<br>・すぐに取り出す必要のあるデータ | 3以上 |99.9% | - |
| 1ゾーン IA | ・長期アーカイブデータ<br>・頻繁にアクセスされないデータ<br>・重要度の低いデータ | 1 | 99.5% | 30日間 |
| Glacier Instant Retrieval | ・すぐに取り出す必要のあるデータ<br>・アクセスが四半期毎程度のデータ<br>・長期アーカイブデータ | 3以上 | 99.99% | 90日間 |
| Glacier Flexible Retrieval (旧Glacier) | ・取得に数分〜数時間程度かかる<br>・長期アーカイブデータ | 3以上 | 99.99% | 90日間 |
| Glacier Deep Archive | ・取得に12時間程度かかる<br>・長期アーカイブデータ | 3以上 | 99.99% | 180日間 |

### ライフサイクル管理
| 名称 | 特徴 |
| - | - |
| 移行アクション | データ利用頻度に応じてストレージクラスを変更する |
| 有効期限アクション | 指定期限を超えたオブジェクトを削除する |
#### 移行可能なアクションの相関

### バージョニング
有効にすると1つのオブジェクトに対して複数のバージョンを管理可能

### Webサイトホスティング
- 静的コンテンツに限りホスティング可能
- ホスティングすると自動的にドメイン(FQDN)が作成される
- 独自ドメインを設定する場合はDNS(Route53など)にCNAME情報を設定
- バケット名とドメイン名を一致させること

### アクセス管理
- バケットポリシー ... バケット全体
- ACL ... オブジェクト単位
- IAM ... ユーザー単位　←推奨

### 署名付きURL
- アクセス許可したいオブジェクトに対し期限を指定してURLを発行
- バケット等のアクセス設定を変えることなく一時的にアクセスを許可する場合
- URLを知っていれば誰でもアクセスできる

### 暗号化
| 暗号化する場所 | 暗号化タイミング | 複合化タイミング
| - | - | - |
| サーバー | ストレージ書込時 | ストレージ読出時　|
| クライアント | SDKでの送信前 | メタデータから複合キーを判別 |

### セキュリティ
#### ブロックパブリックアクセス機能
- バケットの意図しない公開を防ぐ機能[参考](https://qiita.com/you8/items/44e580ad350acd114fb8)
#### S3 Access Analizer
- バケットの監視・保護を行う
#### 誤った削除を防ぐ方法
- バージョニングを有効にする([上述](###バージョニング))
- [MFA削除](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html)の有効化

※バケット全体に対しては予め削除禁止設定ができる(ただし作成時のみ設定可能)

### その他
#### S3 Select
- SQLを使ったコンテンツフィルタリング機能
- Glacier版の「Glacier Select」もある
#### S3 Transfer Acceleration
- 遠隔地のS3へのデータ転送をサポート
- 転送量に応じた費用が発生する(S3へのULには費用は発生しない)
#### Glacier独自の機能
- Glacierに保存されたデータは標準で暗号化される
- 削除禁止機能(ボールドロック)を使い削除を防止できる

## Strage Gateway
- オンプレ→S3、EC2→S3を繋ぐためのGateway
### Stage Gateway の種類
#### ファイルゲートウェイ
- S3をNFSでマウントしファイルサーバーのように扱う
- 1ファイル1オブジェクトとして扱う
-> APIでアクセス可能
=> 保管後にAPIでアクセス(閲覧)するようなケースで利用
#### ボリュームゲートウェイ
- S3をiSCSIで接続しボリュームとして扱う
-> APIではアクセスできない
- ボリュームなのでスナップショットが作成可能
-> そのスナップショットからEBSを作成しそれにEC2をアタッチ
- 頻繁に扱うデータの有無でキャッシュ型と保管型を選択する
##### キャッシュ型ボリューム
- 頻繁にアクセスするデータがある場合に選択
- 頻繁にアクセスするデータのみStrage Gateway内のキャッシュディスクに保存
- 全てのデータをStrage Gatway内のアップロードバッファボリュームを経由してS3(プライマリストレージ)に保存

##### 保管型ボリューム
- 全てのデータをS3(プライマリストレージ)にスナップショットとして保存

#### テーブゲートウェイ
- テープバックアップの代替でS3を使用

### Strage Gatewayのセキュリティ
- CHAP認証が設定可能
- KMSを使った暗号化が可能
- データ転送はHTTPS

## FSx
- フルマネージド型のファイルストレージ
- Winサーバー型のFSx for Windowsファイルサーバーと、高速処理に特化したFSx for Lustreがある
- FSx for WindowsはWindows系、for LustreはLustre系、EFSはLinux系という違いがある
- FSx for Lustreは内部的にS3と関連づく
- 一度目の読み込みはキャッシュするのに時間を要する
- 二度目はキャッシュされているため高速
→ 機械学習などに用いられる
- オンプレからFSx for WindowsへのSMBによる接続を可能にするFSx File Gatewayが2021.4に追加
- オンプレミスから低レイテンシーで Amazon FSx for Windows に接続できる
- 頻繁にアクセスされるデータはオンプレ環境にキャッシュすることもできる

## ストレージサービス使い分け

## RDB/NoSQL
| RDB | NoSQL |
| - | - |
| ・RDS<br>・RedShift | ・DynamoDB<br>・ElasticCache<br>・Naptune<br>・DocumentDB<br>・Keyspace|

## RDS
- マネージドサービス
- MySQL・MariaDB・PostgreSQL・Oracle・Microsoft SQL ServerなどのDBエンジンを選択可能
- RDSでは一部機能が利用できない場合がある
- 利用したい場合はEC2に当該DBエンジンをインストールして利用することになる
- DBインスタンスはDBエンジンによって利用可否がある
- マネージドサービスのAmazon Auroraも選択可能
- RDSのストレージにはEBSを利用する
- 基本的には[汎用SSD(場合によってはプロビジョンドIOPS)](###ボリュームタイプ)を利用
- ストレージの容量は64TB
- Microsoft SQL Serverは16TB

### マルチAZ構成時の注意点
- 複数AZへの書き込みにつき書き込み速度が遅くなる
- フェイルオーバーに60-120秒かかる(接続用FQDNのDNSレコードが書き換えられるため)

### リードレプリカ
- 参照用のDBを別に作成しておくこと
- 書込用→参照用には非同期であるため登録情報に差異が生じることがある

### バックアップ
1. 1日1回スナップショットを取得(保存期間は最大35日←指定可)
2. 手動でスナップショットを取得(リージョンごとに100個まで※RDSごとではない)

#### リストア
- 保存したスナップショットから新規RDSを作成可能
- 直近5日前〜35日前の状態のRDSを新規で作成可能

### IAMデータベース認証([参考](https://blog.serverworks.co.jp/rds-iamdblogin))
- 接続元リソースのロール認証情報と認証トークンを使用してRDSにログインする認証方法
- パスワード(を仕込む必要)が不要となり、セキュリティの向上につながる

#### RDSへのログイン方法
- パスワード認証
- パスワードとIAMデータベース認証
- パスワードと[Kerberos認証](https://barley-tea.hatenablog.com/entry/2019/06/10/224915)

## Amazon Aurora
- DBインスタンスを作成すると同時にDBクラスタが作成される
- Auroraのデータストレージは、
- SSDベースのクラスタボリューム
- クラスタボリュームは単一のリージョン内、3つのAZに2つのデータコピーで構成
- 容量の指定は不要で最大64TBまで拡縮
- 参照専用のレプリカインスタンスを作成可能
- 他のRDSと異なり、フェイルオーバーの際はレプリカインスタンスがプライマリインスタンスに昇格する
- 接続用エンドポイント(FQDN)は以下の3種類
- クラスタエンドポイント ... プライマリインスタンスに接続。RWAD全ての操作が可能
- 読み取りエンドポイント ... レプリカインスタンスに接続
- インスタンスエンドポイント ... DBインスタンスに接続(プライマリ/レプリカから指定したDBインスタンスに接続可能)
- カスタムエンドポイント ... 任意のインスタンスに接続

## Redshift
- 分散並列実行
- Redshiftクラスタ ... Redshiftを構成する複数のノードのまとまり
- 1つのリーダーノードと、複数のコンピュートノードに分かれる
- **リーダーノード** ... SQLを受けクエリ解析や実行プランを作成しコンピュートノードに処理を割り振る・コンピュートノードから返却された処理結果をレスポンスとして返す
- **コンピュートノード** ... リーダーノードからの実行クエリを処理するノード。コンピュートノードを増やす＝ストレージ・CPU・メモリが増える＝パフォーマンスが向上する
- **ノードスライス** ... コンピューターノード内で分散処理を行なった際の最小単位
- 列指向型(カラムナ)データベース
- 9種類の圧縮エンコード
- ゾーンマップ ... ブロック単位で格納されたデータの最大値と最小値をメモリに保存することで検索速度を向上させる
- 拡張性
- **MPP** ... 1回の集計処理を複数ノードに分散する
- **シェアードナッシング** ... 各ノードがディスクを共有せず、ノードとディスクのセットで拡張する(ディスクを共有しないことでI/O性能の劣化を防ぐ)
- Redshiftパラメータグループ内のwlm_json_configurationパラメータでクエリ実行の定義が可能。各キューのプロパティは以下のとおり
- Redshift SpectrumでS3のデータを外部テーブルとして使用できる

## DynamoDB
- マネージド型のNoSQL(Key-Value型)データベースサービス
- 単一障害点(SPOF)を持たない構成
- 自動的に3つのAZに保存される

### スループットキャパシティ
- テーブルごとに予めR/Wに必要なスループットを指定してリソースを確保する
- 読み込み時の「**Read Capacity Unit(RCU)**」
- 書き込み時の「**Write Capacity Unit(WCU)**」とがある
- 自動スケーリング機能もある(急激な上昇には耐えられない)

### データパーティショニング
- DynamoDBではパーティション単位でデータを保存している
- 最低1テーブルを3つに分ける＝AZが3つに分かれているため
- 1パーティションごとに容量・スループットの上限が決まっている
- データ量やスループットの増減に応じ最適化される
→ ユーザーが気にする必要はない

### プライマリーキー/インデックス
- プライマリーキー ... キー値
- パーティションキー ... (単なる)キー値
- 「ハッシュキー」ともいう
- 複合キーテーブル ... パーティションキー+ソートキー※パーティションキーだけで一意に特定できない場合に使用
- ソートキーは「レンジキー」ともいう
- セカンダリインデックス ... プライマリーキー以外でインデックスを作成する場合に使用(1テーブルLSI,GSI各5個ずつ設定可能)
- [ローカルセカンダリインデックス(LSI)](https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-lsi/) ... 同一パーティション内で既に設定されているプライマリーキー・ソートキーとは別の規則で設定されるインデックス
- [グローバルセカンダリインデックス(GSI)](https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-gsi/) ... テーブルに対して自由に追加できるインデックス(LSIのような制限がない)
- 1つのテーブルには最小で1個、最大で11個のインデックスがある(プライマリーキー×1 + LSI×5 + GSI×5 = 11)
- プライマリーキーのことを、シンプルに「テーブル」と呼ぶこともある
- 具体的には「テーブルに対するクエリ」と言えば、このプライマリーキーを使った検索
- LSI/GSIには固有の名前が付いており「(その名前)に対するクエリ」という表現で表す

### TTL(Time to Live)
- データの有効期限を設定できる
- 期限経過後48h以内に削除
- 削除処理はスループットキャパシティユニットが生じない

### DynamoDB Streams
- 直近24hのCRAD履歴を保持

#### [「強力な整合性のある読み込み」オプション](https://dev.classmethod.jp/articles/pricing_dynamodb-strongly-consistent-read/)
- DynamoDBは結果整合性で「書き込みが成功してもそれが反映された最新のデータが取れる保証はない」が、このオプションを設定することで「書き込んだ情報が取得できることが保証される」
- getやqueryのオプションで、 ConsistentRead 属性を true にすることで、「強力な整合性のある読み込み」を行うことができる
- ただし、読み込み時のコストが2倍
- グローバルセカンダリインデックス(GSI)では利用できない

### DynamoDB Accelerator(DAX)
- DynamoDBの前段に設置するキャッシュクラスタ
- DynamoDB単体だと通常ミリ秒単位の応答速度のところ、DAXを設定することでマイクロ秒単位での応答速度を実現できる
- DynamoDBに直接読込みにいく回数が減るためコスト削減にも繋がる

## ElastiCathe
- インメモリ型DB
- 「Memcathed」と「Redis」のエンジンをサポート
- **Memcathd**
- KVS(Key-Valueストア)型インメモリDBのデファクト
- データの永続性がない → 再起動により全消去される
- シンプルなキャッシュシステム、キャッシュの増減が激しいケースなどがユースケース
- Memcathdクラスタは最大20のインスタンスで構成
- Memcatheクラスタには2種類のエンドポイントが作成される
- ノードエンドポイント ... 各ノードへのアクセス用
- 設定エンドポイント ... 設定用(クラスタ全体に割当て)
- スケールイン/スケールアウト時 = ノード数を増減させる
→ 正しいノードに再マッピングされるまでキャッシュミスが増加する
- スケールアップ/スケールダウン時 = 新規クラスタを作成
→ データ永続性がないためデータが消去される
- 暗号化非対応
- **Redis**
- Memcatheよりも多くのデータを扱える
→ キャッシュに加え、メッセージブローカー、キューを構成する要素でも使用可能
- ノード間のレプリケーションに対応
- データ永続性あり
- 多くのデータ型を扱うケース、障害発生時のフェイルオーバーやBU等の可用性を持たす必要があるケースなどがユースケース
- 2種類のクラスタモード
- 無効
- クラスタを構成しない = キャッシュデータは1つのElastecatheインスタンスに保存される
- 1つのマスターに対し5つのリードレプリカが作成できる
→ マスター&リードレプリカのまとまりを「シャード」と呼ぶ
- 有効
- 最大500のシャードにキャッシュデータを分散保存
- リードレプリカは1つのシャードあたり5つまで作成可能
- Redisのアクセス用エンドポイントは3種類
- ノードエンドポイント ... 各ノードへのアクセス用
- プライマリエンドポイント ... 書込処理用のElasticatheインスタンスアクセス用(クラスタモード無効時のみ利用可能)
- 設定エンドポイント ... 設定用(クラスタ全体に割当て)
- 暗号化対応
- シングルスレッド(インスタンスがマルチコアでも1コアしか使用されない)

## Amazon Neptune ([参考](https://dev.classmethod.jp/articles/first-time-graphdb-amazon-neptune/))
- グラフデータベース
- フルマネージドサービス
- 3つのAZで最大15のリードレプリカをサポート
- 変更の必要に応じてインスタンスタイプを変更し、簡単にスケールアップ・スケールダウンを行うことが可能
- 3つのAZにデータのコピーが6つ作成される(Auroraと同じ構成)
- データはS3にバックアップ
- インスタンスのフェイルオーバーは30秒以内で完了

## Amazon DocumentDB([参考](https://dev.classmethod.jp/articles/amazon-documentdb/))
- MongoDB互換のドキュメントDB
- v3.6,v.4.0 ただし4.0の全ての機能が使えるわけではない
- フルマネージド(つまりOSSだけどAWSがサポートしてくれる)
- データは3つのAZにまたがり、6つのレプリケーションが保存される(Aurora,Neptuneと同じ構成)
また、アプリケーションからはMongoDBのレプリカセットクラスタのフェイルオーバーと同様のハンドリングが可能
- バックアップはS3に保存
-

## Amazon Keyspaces([参考](https://dev.classmethod.jp/articles/amazon-keyspaces-for-apache-cassandra-is-now-generally-available/))
- Apache Cassandra 互換DB ([Cassandra詳細](https://techblog.yahoo.co.jp/entry/20200129803067/))
- マネージドデータベースサービス

## Amazon Timestream([参考](https://tech-blog.optim.co.jp/entry/2021/03/15/100000))
- 時系列DB
- フルマネージドサービス

## Amazon QLDB([参考](https://dev.classmethod.jp/articles/amazon-qldb-ga/))
- 台帳DB
- 変更履歴などを全て残し、検証可能な状態にするもの
- フルマネージドサービス

## AWSアカウント・IAM関係性
### AWS Organizations
- 組織アカウント
- 複数アカウントの請求をまとめることができる
- SCP(サービスコントロールポリシー)によりアカウントごとのサービス利用可否を設定できる
※IAMユーザー/グループ/ロールごとに設定する場合は、[アクセス権限の境界](#アクセス権限の境界)を設定する

### AWSアカウントへの設定のベストプラクティス
1. AWSアカウントルートユーザーのアクセスキーをロックする
2. MFAの有効化
3. ユーザーのために強度の高いパスワードポリシーを設定する
4. 最小限の特権を認める
5. AWS管理ポリシーを使用したアクセス許可の使用開始
6. インラインポリシーではなくカスタマー管理ポリシーを使用する
7. ポリシーの検証(IAMコンソール・Access Analyzer)
8. Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
9. ロールを使用してアクセス許可を委任する
10. アクセスキーを共有しない
11. 追加セキュリティに対するポリシー条件を使用する
12. 認証情報を定期的にローテーションする
13. 不要な認証情報の削除
14. AWSアカウントのアクティビティのモニタリング

#### 参考
- [詳細はここを読む](https://qiita.com/c60evaporator/items/0121399880625cc1de51#aws%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E3%82%A2%E3%82%AF%E3%83%86%E3%82%A3%E3%83%93%E3%83%86%E3%82%A3%E3%81%AE%E3%83%A2%E3%83%8B%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0)
- [公式(わかりにくい)](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html#keep-a-log)

## IAM([参考](https://qiita.com/micropig3402/items/df5be6caa425140bfcd8))
IAMには以下の4つの機能を用いてユーザーに権限を付与する。

- __IAMポリシー__
- __IAMユーザー__
- __IAMグループ__
- __IAMロール__

なお、ユーザー及びロールを総称して __IAMプリンシパル__ と呼ぶこともある

権限付与の流れとしては以下のようになる。

1. AWSサービスやリソースに対する操作権限を **『IAMポリシー』** として定義する
2. IAMポリシーを **『IAMユーザー』** や **『IAMグループ』** にアタッチ（付与）する

### IAMポリシー
IAMポリシーは、
- Effect(許可)
- Action(どのサービス)
- Resouuce(どの範囲、機能)

の3つのルールをJSON形式で記述し、AWSのサービスを利用する上での権限を設定する。

---

(例)

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "Action": "*",

            "Resource": "*",

            "Condition": {

                "NotIpAddress": {

                    "aws:SourceIp": [

                        "172.103.1.0/24"

                    ]

                }

            }

        }

    ]

}

上記のポリシーでは、
- 前半のステートメント(`"Resource": "*"`まで)により全てのリソースの全てのアクションを拒否
- その上で、後半のステートメント(`"Condition"`以降)でIPアドレスをNOT指定で限定

→ これらの設定により、後半で指定されたIPアドレス(172.103.1.0/24)以外は前半のアクションによりアクセスを拒否される

---
また、IAMポリシーは以下の２種類が使い分けられている

- インラインポリシー
- 対象毎に個別に適用
- 管理が煩雑になるので基本的には使わない
→ 一時的な権限付与に使う程度
- 管理ポリシー
- 複数のユーザー、グループに適用可能
- 以下の2種類がある
- AWS管理ポリシー
- AWSが用意したポリシー
- 管理者権限・PowerUser・サービスごとのポリシー
- 基本的な権限を付与するのに使う
- カスタマー管理ポリシー
- 自由に設定可能なポリシー
- 過去5世代まで管理可能→即時のロールバックが可能
- IPアドレスなどの制御で使う

### IAMユーザー
#### 認証方法
- ユーザーID/PASS .. コンソールログインで使用。MAFの併用を推奨
- アクセスキー・シークレットアクセスキー .. CLI,APIからのアクセス時に使用
#### 新規作成時の権限
- 新規に作成されたIAMユーザーは何も権限を有していない

### IAMグループ
- 認証情報は持たない → それはIAMユーザー
- 認証 → IAMユーザー　権限(IAMロール)を与えるグループ管理 → IAMグループ　 という使い分けを

### IAMロール
以下のような使い方が考えられる
- AWSリソースへの一時的な権限付与([参考](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_create_for-user.html))
- 複数AWSアカウントに跨るリソースの操作権限(クロスアカウントアクセス)
- ADサーバーのアカウントを使いAWSリソースにアクセス(IDフェデレーション)
- Google,Facebook等のアカウントを使いAWSリソースにアクセスする(Web IDフェデレーション)

## アクセス権限の境界([参考](https://dev.classmethod.jp/articles/iam-policies-evaluation-logic-rikai/))
- IAMプリンシパル（IAMユーザー/IAMロール）に付与できる最大権限を設定/制御できる
- 例えIAMロールに必要以上の権限を付与しても、アクセス権限許可の境界が設定されていなければ、当該権限は付与されない

## STS([参考](https://docs.aws.amazon.com/ja_jp/sdk-for-java/v1/developer-guide/prog-services-sts.html))
- AWS Security Token Service の略
- アクセスに使用できる一時的な認証情報を取得・提供
- IAMユーザー場合、認証情報の有効期間は15分〜36時間の範囲で設定できる。デフォルトは12時間
- ルートアカウントの場合、認証情報の有効期間は15分〜1時間の範囲で設定できる。デフォルトは1時間

## CloudHSM
- 専用のハードウェアで暗号化キーを保管
- CloudHSMの方がより安心してキーを管理することが可能
- 秒間100超の暗号化リクエストがある場合、あるいは公開鍵暗号化を利用する場合に選択
- KMSに比べると高価

## KMS
- マネージドサービス = AWS管理のサーバを共有で利用し、そこで暗号化キーを管理
- システム的に他の組織へのアクセス制限はされていますが、物理的には同じサーバ上に存在

### CDKとCMK
- CDK .. Customer Data Key ： データを暗号化するためのキー
- CMK .. Customer Master Key ： CDKを暗号化するためのキー

### 暗号化・複合化の流れ
[こちらを参照](https://business.ntt-east.co.jp/content/cloudsolution/column-186.html)

### クライアントサイド暗号化/サーバーサイド暗号化
- クライアントサイド暗号化の対象サービスは少ない(S3など)
- なお、S3はサーバーサイド暗号化にも対応

## ACM(AWS Certificate Manager)
- SSL/TLS化対応に必要な証明書をAWS自身が認証局となって発行するサービス
- 証明書の有効期限は13ヶ月：自動更新設定可
- **無料**
- ドメイン所有が条件(メール/DNS)
- ACMは以下のサービスで利用可能
- ELB
- CloudFront
- [Elastic Beanstalk](https://dev.classmethod.jp/articles/cm-advent-calendar-2015-aws-re-entering-elasticbeanstalk/)
- API Gateway
- [Nitro Enclaves](https://dev.classmethod.jp/articles/nitro-enclaves-getting-started/)

## SQS
- キューイングマネージャーを導入することでシステム間の密結合を疎結合にすることができる
- SQSは「キュー管理」と「メッセージ管理」の機能がある
- それ以外にも以下のような機能もある
- 複数のキューをまとめて処理するバッチ用API
- 処理中に他のプロセスから取得できなくする可視性制御のAPI

- キューは以下の2種類
- Standardキュー
- メッセージの配信順序が保証されない
- 同一のメッセージが2度配信される場合がある
→ 利用システム側で影響を受けない構成(冪等性)を保証する必要がある
- FIFOキュー
- 配信順序を保証する
- 秒あたりの処理件数がStandardキューに劣る(Standardはほぼ無制限)
- キューがメッセージを取得する方法は以下の2種類
- ロングポーリング(推奨)
- キューがメッセージ入りのリクエストを受け取った場合のみ即レスポンスを返す
- キューの受信メッセージ待機時間の秒数プロパティを0より大きい値に設定する必要あり
- ショートポーリング
- デフォルト
- キューがリクエストを受けたら即レスポンスを返す(リクエストにメッセージが含まれているか否かは問わない)
→ 実行数が多い = コスト高

### SQSのオプション
- 可視性タイムアウト .. 設定した時間は他のクライアントがメッセージを受信できないようにする
- 遅延キュー .. キューに送られたメッセージを一定時間見えなくする
- メッセージタイマー .. 個別のメッセージを一定時間見えなくする
- デッドレターキュー .. 処理できないメッセージを別のキュー(デッドレターキュー)に移動する = キューに処理できないメッセージが残り続けることを防ぎ、例外処理を簡素化する

### メッセージサイズ
- 256kb/メッセージ
- 画像情報などは格納しきれないため、その場合はS3やDynamoDBに格納した情報のパスやキーをメッセージにて受け渡す

## SWF(Simple Workflow)とStep Functions
- ワークフローのサービス
- いずれも1回限りの実効保証付き
- Step Functionsの方がワークフローを可視化でき操作しやすい

## SNS
- SQSやCloueWatchなどと組み合わせて使用
- Subscriber(受信者)は利用する「トピック」と受け取るプロトコルを登録する(「購読」)
- 「トピック」に対しPublisher(送信者)がメッセージを送信することで、事前にとSubscriber(受信者)が登録した設定に応じメッセージが配信/通知される(PublisherはSubscriberもプロトコルも意識しなくてよい)
- SNS→人、SNS→Lambdaへの送信が可能

## SES
- Eメール送信及び受信(してS3への保存)が可能なサービス
- 信頼性を保つための条件が課される
- 登録済のアドレス・ドメインからのみ送信できる
- 配信不能メール(Bounce Mail)の比率を5%以下に保つ
- SNSと組み合わせて対応を自動化することができる
- 苦情を防ぐ(0.1%未満)
- 悪意のあるコンテンツを送らない

## CodeCommit
- Gitリポジトリのマネージドサービス
- IAMユーザーを用いて権限管理を行う
→ 開発者全員がIAMユーザーならGit用の権限管理が不要で済む
- HTTPSでアクセスする場合、ローカル上のIAMのクレデンシャル情報を用いてGitリポジトリに接続する
- SSHでアクセスする場合、ターミナル上で秘密鍵・公開鍵を作成 → マネジメントコンソールでIAMユーザーに紐づけることでGitリポジトリに接続する
- Gitリポジトリで何らかのイベントが発生したらSNSのトピックを呼び出せる
→ SNSトピック経由で他のAWSサービスをキックできる

## CodeBuild
- ソースコードのコンパイル/ビルド環境を提供するマネージドサービス
- CodeBuild上でユニットテストも行える
- ランタイムとしてJava,PHP,Python,Ruby,Nodeをサポート。加えてDockerイメージも利用できる
- ソースコードの取得先はCodeCommitに加え、GitHub,Bitbucketを選択可能。またS3からも取得可能(その場合は一度ソースコードをS3へ転送する必要がある)
- ビルドの定義は**buildspec.yml**に記述
- 料金は従量課金型

## CodeDeploy
- デプロイの自動化サービス
- デプロイ先はEC2,Lambdaに加え、オンプレミスサーバーを指定可能
- オンプレにデプロイする場合、対象サーバーにCodeDeployエージェントをインストールする
- デプロイ時の配置先の設定等はappspec.ymlに記述する
- デプロイ方法は以下3通り(一気にデプロイ/半分ずつデプロイ/1つずつデプロイ)。停止時間とパフォーマンスとのトレードオフになる。
- CodeDeployではAutoScallingグループをデプロイ対象として選択できる

## CodePipeline
- ソースコードのPush→(Pushを検知して)ビルド→(ビルドを検知して)デプロイ を自動化したPipelineを作成できる
- 一部のプロセスはAWS外のサービスを指定できる(GitHubなど)
- 承認プロセスを定義できる

## ElasticBeanstalk
- 定番のインフラ構成を自動構築するサービス
- 構築できる構成は以下2種類
- Webサーバー構成(ELB+AutoScalling+EC2)
- Batchワーカー構成(SQS+AutoScalling+EC2)
- コストや性能等以下のような設定が可能
- 無料枠をなるべく使う「低コスト」の構成
- 複数サーバーを用意しAutoScallingの設定を含める「高可用性」の構成
- 個別カスタマイズ(例:高可用性にしつつサーバー台数の上限を2に設定 etc.)
- プラットフォームとして以下が選択可能
- Java
- Rubby
- Python
- PHP
- 様々な利用方法
- マネジメントコンソール
- AWS Toolkit for Eclipse
- AWS CLI
- 各言語のSDK
- EB CLI(ElasticBeanstalk専用のCLI：AWS CLIより複数APIが束ねられている
- デプロイ方式は次のとおり

| 設定 | デプロイ方法 | メリット | デメリット |
| -------- | -------- | -------- | -------- |
| **All at Once** | 既存インスタンスに一括でデプロイ | 早い | 止まる。失敗すると影響大 |
| **Rolling** | 1.既存インスタンスの一部をELBから切断<br>2.デプロイ後ELBに復帰したら次<br>※最初にデプロイする数・割合は設定可| 止まらない | 縮退後世になる |
| **Rolling with additional batch** | 1.新規インスタンスを指定台数作成<br>2.Rpllingデプロイ<br>3.1.の分余ったインスタンスを破棄 | 早い。縮退構成期間がない | ・新規インスタンス作成分の時間がかかる<br>・インスタンス破棄を前提にデータを持つ必要性 |
| **Immutable** | 1.新規に1つインスタンスを作成しデプロイ<br>2.残りのインスタンスを新規作成・デプロイ<br>3.既存インスタンスを破棄| 切り戻ししやすい | (Rolling with additional batch とほぼ同じ) |
| **ebコマンドによるURL Swap** | ebコマンドでデプロイ | ・事前に新環境を試せる<br>・旧環境がそのまま残る：リスク回避 | ・環境を全て作り直し<br>・DNSキャッシュが長いとアクセスできない |
| **ebコマンドによるRoute53レイヤーでの切り替え** | ebコマンドでRoute53の設定を変更 | (URL Swapと同じ) | (URL Swapと同じ) |

## OpsWorks
- Chefを利用した(ミドルウェアの)構成管理ができる
- サーバー等の構成管理は「レシピ」といファイルに定義する
- Chefの利用方法は以下の2通り
- Chef Clientローカル方式 .. 各サーバーがレシピを持ち、自分自身にレシピを適用する方式
- スタック .. ミドルウェアを配置するレイヤー構成の情報:JSONで定義
- スタック内の各レイヤー内のEC2インスタンスが起動した際にレシピに記載した情報を基に各ミドルウェアをマッピングしていく仕組み
- レイヤー内に起動したEC2インスタンスにはOpsWorksエージェントがインストールされる
→ OpsWoksからレシピ情報を取得しマッピングする※EC2-OpsWorks間の通信経路の設定が必要
- Chef Server/Client方式 .. マスターサーバーを用意し、レシピやレシピの適用状況を管理する方式
- ChefAutomate
- Chefを統合的に利用するための機能
- マスターサーバーにレシピを登録し、そこから各クライアントにレシピを適用する
- OpsWorks版ChefAutomate ： **OpsWoks for ChefAutomate**
- ChefAutomateサーバー(=マスターサーバー)の作成・バックアップを自動で行ってくれる
- ChefAutomateサーバーにcookbook(レシピを保存するリポジトリのようなもの)を登録しておくことで、クライアントノード(=EC2インスタンス)を起動するとレシピが適用される
- AutoScallingにも対応
- ノードやレシピはダッシュボード上で管理できる

## CloudFormation
- AWSリソースを自動構築する
**※OpsWoksはミドルウェア以上のレイヤー、CloudFormationは全リソースの構築が可能([参考](https://techblog.zozo.com/entry/cloudformation-and-opsworks))**
- 「テンプレート」(JSON/YAML)からCloudFormationにより「スタック」(=CloudFormationにより作成されたリソース群)を作成
- テンプレートは次の3種類の「セクション」に分けて記述する
- Resourcesセクション
- メインのセクション
- 各リソースに対しては必ず論理IDを付けてリソース間を紐付ける必要がある
- 各リソースには型定義が必要 → 定義する型によってParametersセクションに記述する内容が変わる
- VPCリソースの場合はCidrBlockの定義が必要
- Tagsは任意の定義で使う
- Parametersセクション
- 各リソースのパラメータを定義する
- 定義された値はRef関数(後述)で呼び出せる
- Mappingセクション
- 変数をMap形式で定義
- 実行環境で変わる値を定義することが多い
→ ResorcesセクションでFindMap関数を使って呼び出す

- 疑似パラメータ .. 事前定義されたパラメータ(AWS::Region,AWS::AcountIdなど)
- 組み込み関数
- Ref関数 .. AWSリソースや設定値を取得する
- FindMap関数 .. Mappingセクションで定義した変数を取得する
- Select関数 .. リストからインデックスを指定して値を取得する
- ImportValue .. 他のCloudFormationスタックから値を取得する

## EMR
- 分散処理フレームワーク
- 分散処理基盤
- リソース調整機能(EC2の調達・廃棄)
- デフォルトでは処理完了時にリソースを解放する設定に
- スポットインスタンスと相性がよい → オプションもある
- **オートスケール+スポットインスタンス → EMRの低コスト化の定石**
- EMRFS(S3を分散処理に扱いやすいストレージとして扱う)
- 分散処理アプリケーション基盤　
- Hadoopとそのフレームワーク(Apache Sparc,HBase,Presto,Flinkなど)が事前に用意されている(サポートアプリケーションと呼ぶ)
- AthenaのエンジンはPresto
- Athenaはフルマネージドなので立ち上げが不要 → 使い分けを
- EMRのアーキテクチャ
- マスターノード .. コアノード・タスクノードへ処理を振分。マスターノードの処理が失敗すると処理全体が失敗する
- コアノード .. 処理を実行するノード。HDFS(データ保存領域)を持つ
- タスクノード .. 処理を実行するノード。HDFSを持たない

## ETLツール群
### Kinesis
- ストリーミング処理プラットフォーム(=リアルタイム処理/準リアル処理に向く)
- 以下の4種類
- Data Streams
- センサー・ログを**リアルタイム**で処理
1. EC2上のKinesis Producer Library on EC2からKinesis StreamへデータをPush
2. データをシャードに保管
3. コンシューマーアプリケーション(EC2)上のKinesis Client Library on EC2によりPull(Lambdaなどから呼び出し)
4. DynamoDB,S3などに保存
- Data Firehose .. センサー・ログを**準リアル**で処理
- 設定するだけでデータをS3などに送れる(Data Streamsでは必要なEC2でのポーリングやLambdaのコーディングは不要)
- Video Streams .. 動画処理用
- Data Analytics .. データ可視化・分析用
- SQL,Javaを使ったストリーミングでの分析までを行ってくれる
- 参考
- [Kinesis 種類多くて混乱してきたので一旦整理する](https://sayjoyblog.com/kinesis/)
- [KinesisDataStreamsのデータ処理用Lambda作成](https://business.ntt-east.co.jp/content/cloudsolution/column-try-23.html)
- [kinesisまとめ - Qiita](https://qiita.com/yShig/items/500d4139efed91bc432d)
- [Amazon Kinesis StreamsとAmazon Kinesis Firehoseは何が違うのか](https://dev.classmethod.jp/articles/difference-between-kinesis-streams-and-kinesis-firehose/)
- [リアルタイム分析がやりたい！はじめての Kinesis Data Analytics](https://dev.classmethod.jp/articles/first-time-kinesis-data-analytics/)

### Data Pipeline
- データ処理・移動をサポートするサービス
- オンプレやAWSリソースに定期アクセス → データ変換 → S3,RDS,DynamoDB等に保存
- スケジュール実行、エラー時実行(=**バッチ処理**)
- ビジュアル操作が可能
- 参考
-　[AWS再入門 AWS Data Pipeline編](https://dev.classmethod.jp/articles/cm-advent-calendar-2015-getting-started-again-datapipeline/)
-　[AWS Data Pipelineってなんだろ？](https://zenn.dev/mn87/articles/ec0f7dfde1dc43)
### Glue
- データレイク・データウェアハウスと一緒に使われることが多い
- S3などのデータを管理 → RedShiftなどに変換し格納するといった用途で使用
- データ管理機能・データ変換機能を持つ
- データ管理機能
- データをクロールする機能
- データカタログ(メタデータとして管理する)機能
- メタデータはApache Hive形式
- データ変換
- エンジンを提供
- 処理は自信で書く(PythonやSparkなど)
- AWSのETLツールとしてはLambda(小規模)かGlue(中・大規模)を使う
- 参考
- [AWS再入門ブログリレー AWS Glue編](https://dev.classmethod.jp/articles/relay_looking_back_aws_glue/)
- [「アナリティクス強化月間 Glue DataBrew」(亀田氏ハンズオン資料)](https://github.com/harunobukameda/Amazon-Redshift-Spectrum-AWS-Glue-Amazon-Athena-Amazon-S3-Select/blob/master/datalake-handson-text_20201115.pdf)

## その他
### サポートプラン
[AWS Support プラン比較](https://aws.amazon.com/jp/premiumsupport/plans/)