AWS SAAの学習まとめ

AWS Certified Solutions Architect - Associateについて学習したことをまとめていきます。羅列しているだけなので、まとめて内容さらい直したい場合にご覧ください。

## よく出てくるIT用語
・I/O処理 = データの出し入れのこと
・テンプレート = ymlファイル等、環境構築の設計図のようなもの。
・エンドポイント = そのサービスの接点
・単一障害点(SPOF) = そこに障害が発生するとシステム全体が停止してしまう箇所
・スループット = 処理性能の事

・スケール = 性能
・スケールイン = 台数を減らして性能を下げる
・スケールアウト = 台数を増やして性能を上げる
・スケールアップ = 機器自体の性能を上げる

・フェイルオーバー = 片方がぶっ壊れたら自動でもう一方に切り替えますよ機能のこと
・冗長化 = 影武者を用意しておいて、主が死んだらサブが昇格するシステム

# ■ネットワーク
## リージョンとAZ
・リージョン：離れた拠点がある
・AZ：リージョンが更に分かれている
→ 数10km離れているので、災害が起きてもOK = <font color="tomato">耐久性と信頼性</font>
・マルチAZにした際、AZ同士の情報は<font color="tomato">遅延なく同期</font>される

## VPC(Virtal Private Cloud)
プライベートなネットワークをAWS内に作成

:::note
・VPCには好きなIPアドレスが振れる(/16 - /28)
・VPCの中には更に箱を作れる = <font color="tomato">サブネット</font>
→ 作成時にAZを指定(後から変更不可)
→ 1箱に対してルートテーブルを1つ指定
→ 最初は<font color="tomato">メインルートテーブル</font>で後から変更可
→ 1VPCに作れる箱は<font color="tomato">200個</font>
→ セキュリティ：ネットワークACLが自動で適用(変更も可)
→ サブネットもマルチAZにする

リージョン > VPC > AZ > サブネット
:::

接続方法が非常に出る。。


##### ◎VPC - VPCを繋ぐ：<font color="tomato">VPCピアリング</font>
通信相手は通信相手はEC2等のサービス本体なので、ゲートウェイは通らない
```
VPC
|
VPCピアリング
|
VPC
```


##### ◎VPC - オンプレミスを繋ぐ：<font color="tomato">仮想プライベートゲートウェイ(VGW)</font>

:::note
オンプレミスと接続するには「VGW」の後に下記を挟む必要がある
・DirectConect：物理的なコード
・VPN：仮想的なコード
・DirectConect Gateway：1つの接続で複数のAWSアカウントやVPCと接続可
・AWS Transit Gateway：複数のVPCとオンプレミスを仲介ハブを介して接続
:::

DirectConectは物理的なコードなのでVPNに比べて「速い」「パケット損失の低下」「大量データの送信」が可能

```plaintext:
VPC
|
仮想プライベートゲートウェイ(VGW)
|
DirectConect = 物理的なコード
|
オンプレミス
```

```plaintext:
VPC
|
仮想プライベートゲートウェイ(VGW)
|
VPN
|
Customer Gateway = VPNが物理的なものでなく、宛先に迷ってしまうので設置が必要
|
オンプレミス
```


##### ◎VPC - AWSの他サービスを繋ぐ：
##### <font color="tomato">インターネットゲートウェイ(IGW)</font> or <font color="tomato">VPCエンドポイント</font> or <font color="tomato">NATゲートウェイ</font> 

・基本的に重要な情報はPrivateサブネットに入れる
・インターネットに接続する場合Publicサブネットにする必要がある
→ セキュリティに考慮した構造にする必要がある

```plaintext:インターネット経由で接続(IGW)
VPC
 Public
 |
インターネットゲートウェイ(IGW)
 |
インターネット
 |
他のAWSのサービス
```

```plaintext:インターネット経由で接続 (NATゲートウェイ)
VPC
  Private
  |  NATゲートウェイ
  Public
  |
インターネット
  |
他のAWSのサービス
```

```plaintext:インターネットを経由しないで接続
VPC
|
VPCエンドポイント
|
他のAWSのサービス
```
※ゲートウェイエンドポイント：S3, DymanoDBと接続
※AWS PrivateLink：上記以外のサービスと接続

##### ◎インターネットゲートウェイ
VPCに1つアタッチ(取り付ける)。インターネットとVPCの接続に使うやつ。

・単一障害点(SPOF)か？と思われがちだが、<font color="tomato">冗長化</font>や<font color="tomato">障害時の復旧</font>が自動でなされているので問題なし。

・ルートテーブルは下記内容で設定しておく
```plaintext
ゲートウェイ(通路) = インターネットゲートウェイ
ルート(宛先) = 0.0.0.0/0
→ サブネットをこのIPアドレスにすると「パブリックサブネット」になる
```

##### ◎ルートテーブル
通信の経路(宛先アドレスと通る予定のゲートウェイ)が書いてある。
・個々のサブネットに1つずつ設定
・1つのルートテーブルを複数サブネットで共有可能
・VPCのデフォルトのルートテーブル = <font color="Tomato">メインルートテーブル</font>

##### ◎セキュリティグループとネットワークACL
この２つの違いが非常に出るので違いを抑える。

共通部分：
・インバウンド：外 → VPC内への設定
・アウトバウンド：VPC内 → 外への設定

##### セキュリティグループ：
:::note
サービスに対してのセキュリティ
→ 対象：EC2, ELB, RDS等
:::

・インスタンスに少なくとも<font color="Tomato">1つ以上</font>のセキュリティグループのアタッチが必要
・制御できるのはIPアドレス、ポート番号、<font color="Tomato">セキュリティグループ</font>
・状態は<font color="Tomato">ステートレス</font>

##### ◎ネットワークACL：
:::note
ネットワークに対してのセキュリティ
→ 対象：サブネット等
:::

・制御できるのはIPアドレス、ポート番号
・デフォルトはアクセスを<font color="tomato">拒否</font>
・状態は<font color="tomato">ステートフル</font> → <font color="tomato">エフェメラルポート</font>を許可する必要がある。

##### ◎VPCフローログ

:::note
通信のログ
送受信者のIP, ポート番号, プロトコル, データ量, 許可／拒否の記録
ENI単位で記録される。
:::


##### ◎サブネットとCIDR記法
これは基本情報などとも被る知識。
(例) 000.000.0.0<font color="tomato">/24</font>
この場合頭から数えて24ビット目より後が、IPアドレスに使用可能なビット数になる。
赤の部分が、自由に使える部分
00000000.00000000.00000000.<font color="tomato">00000000</font>

8ビットあるので、２進数でパターンは2^8=256
 → 256個のIPアドレスを利用できる。計算してベストなCIDRを設定することが重要。

## Route53
ドメインの管理と権威DNS
→ IPアドレスをドメイン名に書き換えて管理してくれる。

##### ◎用語：
・ホストゾーン = ドメイン名
・レコード情報 = ドメイン ←→ IPの変換情報　<font color="tomato">Aliasコード</font>
・Zone Apex = 最上位ドメインのこと
・DNSフェイルオーバー = システムに異常が発生した場合、被害を最小限に抑える仕組み
 → <font color="tomato">フォールトトラントアーキテクチャ</font>という設計方法。具体的にはヘルスチェックを行い、その結果をみて発動する仕組み。

# ■コンピューティングサービス
・EC2：仮想サーバー。Elastic Load Balancing, Auto Scalingで上手に負荷分散しよう
・ECS：Dockerコンテナ専用のサーバー。構築が楽。
・Lambda：サーバーなしでプログラムを実行

## EC2
##### ◎<font color="tomato">Amazon Machine Image(AMI)</font>
→ インスタンスの元となるイメージ。これを使うと時間短縮(EC2作る際に選ぶOSのやつ。)

##### ◎インスタンスタイプ：（例）m5.large
・5の部分 = 世代を表している
・largeの部分　= 性能(CPU, メモリ)を表している

##### ◎インスタンスタイプの種類：
| 呼び方                       | 特徴                              | インスタンスタイプ名の頭文字 | 
| ---------------------------- | --------------------------------- | ---------------------------- | 
| 汎用                         | CPUとメモリのバランスが良いタイプ |                              | 
| コンピューティング最適化     | CPUの性能が良いタイプ             | 頭文字がC系統                | 
| 高速コンピューティング最適化 | CPU以外の性能(GPU)が良いタイプ    | 画像のP系, 機械学習のG系     | 
| メモリ最適化                 | メモリの性能が良いタイプ          | 頭文字がR系統                | 
| ストレージ最適化             | 対ローカル用。                    | HDDのD2, SSDのI3系           | 


##### ◎インスタンスの状態：
・起動中: Running
・停止中: Stopped
・削除済: Terminated
※EC2インスタンスを停止していても、この後出てくるEBSの料金はかかるので注意！

## ELB
トラフィック(ネットワークに流れる情報量)の制御がしたい時に使用。
EC2インスタンスを複数並べて、ELBを前に置くと処理を分配してくれる
単一障害点(SPOF)を防ぐ、負荷分散用のもの


##### ◎プレウォーミング申請：
急激な負荷増(スパイク)が予測できる場合は、予め<font color="tomato">プレウォーミング申請</font>を行なっておく。

##### ◎ヘルスチェック機能：
失敗するとEC2を切り離し、正常になったら再度紐付け


##### ◎ELBの種類：
・CLB = L4, 7用 古いやつ
・ALB = L7用 HTTP(S)のプロトコル用
・NLB = L4用 HTTP(S)以外のプロトコル用

:::note
アプリケーションと出てきたら「ALB」それ以外は「NLB」
古いものは「CLB」でOK
:::

## Auto Scaling
EC2等の起動台数管理をしてくれる。増やす, 常に最小台数をキープすることが可能。
条件に合わせて台数の増減をしてくれるので、消されちゃうことも考えてステートレス & マルチAZにしておく必要がある。

##### ◎スケジューリングポリシー
台数増減の条件は下記から設定する。

・スケジュールスケーリング
・予測スケーリング
・動的なスケーリング
┣ 簡易 = 域値を設定(CPUが70%を超えたら増加させる等)現在非推奨。
┣ ステップ = １つ〜複数の域値を設定
┗ ターゲット追跡 = 目標を設定して、その条件をキープ出来るように台数を調整

※インスタンス起動中はヘルスチェックを止める機能がある。猶予期間は<font color="tomato">300秒</font>。しかしCLI, SDKで作成した場合はデフォルトfont color="tomato">0秒</font>なので注意。

##### ◎インスタンス増減の調整
・ウォームアップ
・クールダウン

##### ◎その他用語
・ライフサイクルフック = インスタンスのスタート, 停止時にアクションの実行
・終了ポリシー = スケールイン(減らす)時に、どのインスタンスを消すのか設定

## ECS
コンテナ簡単に作成できるサーバー(EC2の１つ)。
→ Dockerのサーバーと言ったらこれ。

・AutoScalingで動的にスケーリング可能
・コンテナごとにIAMロールの割り当ても可能

##### ◎用語
・Task = コンテナのこと
・Cluster = EC2インスタンスのこと
・Task Definiton = コンテナの定義を設定(ymlファイル的な)
・Service = コンテナを同時条件で複数用意

## その他コンテナのEC2
・AWS Fargate = インスタンス不要といったらこれ。
・EKS = kubernetesと言ったらこれ。
・ECR = Dockerのイメージを管理する。

## Lambda
サーバーなしで簡単にメソッドを構築できる。
何(他AWSサービス)をトリガーに発動させるか？を設定して、メソッドを書く。

##### ◎料金：
実行数と処理時間で変動
→ そのため、実行回数が数回のものに向いている

# 監視系
##### ◎CloudWatch Logs
・機械視点
・エラーなどの記録
・条件に当てはまったら通知して処理などの設定も可能。

##### ◎CloudWatch Events
・機械視点
・インスタンスが減ったら…とか状態の変化をトリガーにする
・スケジュール設定も可能。

##### ◎CloudWatch エージェント
EC2でCloudWatchを使う時はこれが必要。

##### ◎Cloud Trail
・人視点
・動作を記録
・監査に使える。監査と言ったらこれ。
・処理の実行は不可なので、人の動作で通知を…みたいにしたい時はCloud Watchと連携させる。

##### ◎Cloud Config
・設定履歴の確認

# ■アプリケーションサービス
## SQS
キューの実行。順序を保証したい系の文章が出てきたら大体これのFIFOキュー。

・<font color="tomato">水平スケーリング</font>が得意
・メッセージサイズは<font color="tomato">256KB</font>まで。処理に失敗したら<font color="tomato">デッドレターキュー</font>に移動する。

##### ◎種類と設定:
・standardキュー = 速い、配信順序を保証しない
・FIFOキュー = 遅い、順序保証

・ロングポーリング = メッセージの有無を確認してからレスポンスする
・ショートポーリング = メッセージの有無は確認せずに、即レスする

・可視性タイムアウト = 同じメッセージの受信防止。デフォで<font color="tomato">30秒 ~ 最大12時間</font>

##### ◎すぐ処理したら問題のものには…
・遅延キュー = 受信メッセージを一定期間見えなくする
・メッセージタイマー = 受信メッセージを個別に一定時間見えなくする

## その他のメッセージサービス
・SNS = プッシュ型通知
・SES = メール
・MQ = マネージド型メッセージブローカーサービス（メッセージを受け取って送る機能？）

# ■ワークフロー
・Simple Workflow(SWF) = 使いづらいらしい…？
・Step Functions = 可視化されていて使いやすいらしい

# ■ストレージサービス
## EBS
・EC2インスタンスと1対１で作成する、DBを入れる用の箱。
・ファイルシステムの構築や、処理の速さと<font color="tomato">不揮発性</font>を生かしてデータ分析に使用。
・拡張○
・縮小×
・ボリュームタイプの変更○
・<font color="tomato">スナップショット</font>(特徴でメッッチャクチャ出る)
・自動でAZ内の複数ディスクに複製機能あり。
・暗号化も可能 → 途中からこの機能をONにする場合は、スナップショットを利用して新規に作成して設定の必要あり
・EBSマルチアタッチ = 複数のインスタンスから同一のEBSをアタッチ
・DeleteOnTermination ＝ EC2が消えたらEBSのデータも削除する機能。


##### ◎ボリュームタイプ
これもめちゃくちゃ出る。。
| 呼び方            | 速度               | 向いているデータ量 | 向いているDB                 | 
| ----------------- | ------------------ | ------------------ | ------------------------------ | 
| 汎用SSD           | 250MB/秒　 遅 | 少                 | 通常                           | 
| プロビジョンドSSD | 1000MB/秒　速      | 少                 | I/O負荷の高いDB                | 
| スループットHDD   | 500MB/秒　 速       | 多                 | 分析, 大容量                   | 
| Cold HDD          | 500MB/秒　 遅       | 多                 | アクセスの低いアーカイブDB | 

## EFS
複数EC2インスタンスから同時アクセス可能 → <font color="tomato">複数人でファイルの共有</font>

同時アクセスするために、１つの共通のアクセスポイントを作る。 = <font color="tomato">マウントターゲット</font>

##### ◎種類：
・汎用パフォーマンス: 通常のもの
・最大I/Oパフォーマンス: 数百 ~ 数千からアクセスする場合。ビックデータの並列処理など。
→ どちらにするかは<font color="tomato">CloudWatchのPrecentOlimit</font>で計測して判断すると良い。

##### ◎スループットモード
・バースト = データサイズ普通、スループット1GBあたり50KB/秒
・プロビジョニング = データサイズ小、アクセス多、スループット値の増減は前の作業から24時間以上開ける
→ どちらも急激に上がるのはOK。<font color="tomato">CloudWatchのBurstCreditBrance</font>で計測して判断すると良い。

:::note
EC2関連で、EFCとEBSの選択肢が良く出る。
ファイルシステムと言ったらEFC, それ以外はEBS
他、違いを押さえておく。
:::

## S3
長期間、大容量、消えたら困るデータを保管するのに使用する。

##### ◎用語：
・メタデータ = オブジェクトの管理情報
・イレブンナイン = 耐久性
・99.9 = 可用性
・バージョニング = 1つのオブジェクトに対して複数バージョン管理
・ACL = バケットとオブジェクトの公開、非公開を切り替えられる
・クライアント暗号化 = AWS SDK
・ブロックパブリックアクセス機能 = 外部からのアクセスを禁止する
・S3 Access Analyzer = S3バケットの監視と保護
・S3 select = オブジェクト取り出しの際に、フィルターをかけられる
・S3 Transfer Acceleration = 遠隔地のS3データ転送をサポート

##### ◎種類：
通常のS3意外に、下記種類がある。

・S3 OneZone
 → 単一AZでデータを複製。Glacierと低頻度アクセスの間の存在

・S3 Intelligent - Tiering
 → 30日以上参照されなかったデータは標準から低頻度モードになる

・Glacier
 → ほぼ取り出さない、アーカイブデータ保存用。

##### ◎Glacierの取出時間：
モードによって取り出し時間が変わる。めちゃくちゃ出る。
| 名前         | 取り出し時間 | 用途                               | 
| ------------ | ------------ | ---------------------------------- | 
| Deep Archive | 12 時間      | ほぼ使わないデータ。<br>料金が安い | 
| 大量         | 5 - 12 時間  | 大容量データ                       | 
| 標準         | 3 - 5 時間   | 標準                               | 
| 迅速         | 1 - 5 分     | 早めに取り出したいデータ           

:::note
そこまで取り出し機会の多くない場合は、<font color="tomato">Glacier</font>か<font color="tomato">S3の低頻度アクセスモード</font>を使う。ここの使い分けは「5分待てるか」である。
Glacierの方が安いが、一瞬で取り出さなければいけない場合はS3の低頻度アクセスモードを使わないといけない。
:::

## Storage Gateway
オンプレミス - AWSのサービスでデータを連携(移行というより連携)
・暗号化される
・CHAP認証でなりすましを抑える

##### ◎種類：
・ファイルゲートウェイ
 → ファイル形式で保存

・ボリュームゲートウェイ
 → キャッシュ型：メインをS3とする。高速
 → 保管型：メインをオンプレミス、スナップショットなどをS3に保存する

・テープゲートウェイ
 → データのバックアップ用

## FS× for Lustre
これもストレージ系の一つ。
2回目のアクセス以降はキャッシュを利用するので高速。
LinuxのサービスでNAS(クラウド上のファイルサーバー(情報の置き場))のように使える

## データベース
##### ◎RDS：
・SQL方式
・自動バックアップ
・手動スナップショットからデータのリストアも可能
・ポイントインタイムリカバリー = <font color="tomato">5分前 - 35日前</font>のDBの状態で新規DBを作成可能
・マルチAZ構成, リードレプリカ構成どちらも可能
 → リードレプリカ = 参照用のDBインスタンスを作成できるサービス

##### ◎RDSのAurora：
・AWS独自開発のDBエンジン
・容量を最初に決める必要なし、データ量で最大64TBまで自動的に拡縮
・<font color="tomato">マルチAZ構成ができない</font>ので、レプリカを作成する

##### ◎Red shift Specturum：
 → S3内のデータを分析可能

##### ◎Athena：
 → S3内のデータにクエリを実行できる。これも分析などで使える。

##### ◎DynamoDB：
・単一障害点(SPOF)を持たない
・メタデータの保存が得意
・Time to Live(TTL) = 有効期限が過ぎたデータを削除する機能
・DynamoDB Streams = 24時間以内の操作ログを保存
・DymnamoDB Accelerator(DAX) = キャッシュを使って読み込みがマイクロ秒になる機能。コストが高い。

※AppSync ＝ DynamoDBの値をいじれる。今までLmbdaとAPIGatewayが必要だったが、これ1つで可能になった。


##### ◎ElastiCache：
・キャッシュしてしょっちゅう使うデータの取り出しパフォーマンスを上げる
・Memcahedと多くのデータ型が使える + 永続性のRedisがある。
・Redisはクラスタモードでリードレプリカを作成する
・ユーザーのマッチング処理、 おすすめ表示機能、　画像データの高速表示などで使用
 → 同じ動作を繰り返し行う + 高速に処理したい場合におすすめ

##### ◎Neptune：
 → グラフ用データベース

##### ◎QLDB：
 → 台帳用データベース

:::note
個人的に混ざるものの比較：
・RDS = SQLで取得可能、表(リレーショナルデータ)形式
・DynamoDB = SQLのクエリは使えない、オブジェクト型

・Aurora = RDSの種類の1つ。AWSオリジナルのDB
・Athena = S3分析用
・Neptune = グラフ用
:::
S3とDB系の使い分けも苦手。。

# ■権限
##### ◎IAM系：
| 呼び方      | 対象                                                        | 
| ----------- | ----------------------------------------------------------- | 
| IAMユーザー | 人                                                          | 
| IAMグループ | 人々のグループ                                              | 
| IAMロール   | 一時的な人(アカウント)<br>AWSのサービスとサービスをつなぐ等 | 
| IAMポリシー | ルールの内容を書くところ(これを人に割当)                    | 

IAMポリシーはAWS管理と、カスタマー管理がある

##### ◎AWS Certificate Manager：
AWSが認証局となって、証明書の発行をしてくれる。無料。

# ■Code系

| サービス名    | 概要                                    | 
| ------------- | --------------------------------------- | 
| Code Commit   | ソースコードの管理、Git的な。           | 
| Code Build    | ビルドとテストをしてくれる              | 
| Code Deploy   | デプロイ                                | 
| Code Pipeline | 上の3つを束ね、一連のプロセスを自動化   | 
| Code Star     | Code Pipelineをテンプレートから構築可能 | 
| CodeGuru      | 機械学習を使ったコードレビュー          | 
| CodeArtifact  | pipやnpmなどパッケージ化したものを配布  | 

# ■自動化
##### ◎Elastic Beanstalk
インフラ系の自動化。EC2と言ったらこれ。
Eclipseから使うときはAWS Toolkit for Eclipsが必要

##### ◎Ops Works
・OS以上のレイヤー自動構築
・chef, puppetと言ったらこれ。
・Clientローカル方式 = 各サーバーでレシピを使う
・Server/Client方式 = マスターサーバーがレシピを管理

##### ◎Cloud Formation
・OS以下の構築
・webアプリ、テンプレートと言ったらこれ。

まとめると。。

| サービス名         | 対象領域         | キーワード              | 
| ------------------ | ---------------- | ----------------------- | 
| Elastic Bean Stalk | インフラ         | EC2                     | 
| Ops Works          | OS以上のレイヤー | chef, puppet            | 
| Cloud Formation    | OS以下のレイヤー | webアプリ、テンプレート | 

正直Elastic Bean Stalk と Ops Works の違いは良くわからないので、完全にキーワードで判断している。。

# ■分析
##### ◎EMR
 → 分散処理、スポットインスタンス(EC2のちょっとだけ使うやつ)と相性が良い

##### ◎Kinesis
・Datastreams, Data Firehose = センサーやログをリアルタイム解析
※データの変換にはLambdaを合わせて使う

・Video Streams = 動画処理
・Data Analytics = 収集したデータの可視化と分析

:::note
StreamsとFirehoseの違い
・Kinesis Data Streams
＝ 処理が早いのでリアルタイム処理向け

・Kinesis Data Firehose
＝　処理に60秒以上必要なので時間関係ないもの向け
:::

##### ◎<font color="tomato">Data</font> pipeline
 → データ処理、移動を支援
※Code Pipelineとめちゃくちゃ混ざる。。

##### ◎Glue
 → データレイク、データウェアハウスを利用

# ■その他
##### ◎AWS STS, IAM cognito
 → アプリなどのユーザーがパスワードなどを使ってサインインできる機能。
この２つの違いはわからない。

##### ◎App Sync
DynamoDBをつかって超リアルタイム処理(Lambdaよりも高速)

##### ◎Snowball
ここらへんも良く出る。。条件が書いてあって、この場合に一番いい方法は？
A: Snowball 2つ
B: Snow mobile 1つ
的な感じである。。難しい。

| サービス名  | 容量  | かかる時間  | 届くもの   | 
| ----------- | ----- | ----------- | ---------- | 
| Snowcone    | 8 TB  | 約 1 週間？ | 小さめの箱 | 
| Snowball    | 80TB  | 約 1 週間   | 箱         | 
| Snow mobile | 100PB | 10 日未満   | 車         | 

さらにSnowballの中にも種類あり
・Snowball Edge Compute Optimized
→ 42TB、機械学習データなどに

・Snowball Edge Storage Optimized
→ 80TB



##### ◎AWS Shield
DDos攻撃から保護
・Standard = 無料 L3, L4が対象
・Advance = 有料 上記に加えて、L7も対象

##### ◎WAF
複数の攻撃から保護。対象はL7, DDosも防げる。

:::note
AWS ShieldかWAFかは、レイヤーの幅が広い方がいいか、攻撃防御の幅を広げるかといった感じである。
:::


##### ◎Amazon Kinesis Data　Streams と Firehose
・Amazon Kinesis Data　Streams　 = IoTデータの取得
・Amazon Kinesis Data　Firehose = 取得したデータを適切な形式に変換、S３に保存
※Firehoseは<font color="tomato">DynamoDBには格納不可</font>

# ■鍵
##### ◎CSE
ユーザーで鍵を暗号化、ユーザーが管理

##### ◎SSE-S3
S3を使って鍵を管理
自動で暗号化される

##### ◎AWS KMS
これを使ってユーザーが暗号化キーを作成、管理可能

:::note
監理をどれだけユーザーがやるか
SSE-S3 < AWS KMS < CSE
:::

終わり