AWS ソリューションアーキテクト 備忘録



配点比率や試験の概要などは => [公式試験ガイド](https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate%20Exam%20Guide%20001%20v1.5%20JPN.pdf)

<!--
目次
リンク生成されたらあとで＃付けて対応
-->

## ネットワーク

### リージョン、アベイラビリティゾーン(AZ)

- リージョン
    - 各リージョンは、1つの地理的エリアにある複数のそれぞれが隔離され物理的にも分離されたAZによって構成される
    - 複数のAZで実行するようにアプリケーションの設計をすることで、より強力な障害耐性を実現できる（高可用性）
    - **リージョン間の通信は低レイテンシー**(高パフォーマンス)
    - 国・拠点（北米、南米、欧州、中国、アジアパシフィック、中東）に地理的なリージョンを保持

- AZ
    - 1つのAWSリージョン内でそれぞれ独立
    - **同一リージョンの複数のAZにシステムを構成すること**（マルチAZ）で、高可用性と高い耐障害性と高いパフォーマンス効率を実現
    - 各AZはそれぞれ他のAZから数キロメートル離れているが、**すべて100km以内(互いに60マイル)に配置されている**

リージョンの中に複数のAZ, ローカルゾーンはリージョン外
![image.png](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/aws_regions.png)

補足
ローカルゾーン（あんまり出ない）

- AWSサービスをエンドユーザから近い場所に配置する
    - エンドユーザーに対するレイテンシーが**10ミリ秒未満**であることが要求される高性能なアプリケーション向け（*メディア、エンタメコンテンツ、リアルタイムゲーミング、貯水池のシミュレーション、電子自動設計、機械学習*など）

### VPC
試験だけでなく、普段AWSを活用するうえでも超重要な項目だと思う。

VPCについては、不安なことを残すとそれを起点に混乱を起こすことが私は良くあるため、用語を整理して理解したい。
以下の資料が参考になりそう。圧倒的感謝。

- [本試験のレベル感で必要なことを網羅している資料（この内容が頭に入ればOKだと思う）](https://d1.awsstatic.com/webinars/jp/pdf/services/20190313_AWS-BlackBelt-VPC.pdf)
- [サクッと思い出したいとき役立ちそう](https://qiita.com/ryosukes/items/9ad289e1d673899fc628)

中でも下記の用語の違いなどはしっかり説明できるようにしておいた方が良さそう

- パブリックサブネット / プライベートサブネット
- セキュリティグループ / ネットワークACL
- CIDR表記
- ルートテーブル
- インターネットゲートウェイ（IGW）
- 仮装プライベートゲートウェイ（VPW)
- VPCピアリング

また、VPC関連の用語を把握するだけでなく、一緒に基本的なアーキテクト設計についても見ておくと良さそう。
例えば、DBインスタンスをパブリックな領域に置いてしまうのはセキュリティの観点でNGケース。
以下のように必ずプライベートな領域に設置し、やりとりするインスタンスに対してのみアクセスを許可するように設計する。
[本番は紙とペンが渡される](https://blog.trainocate.co.jp/blog/aws_10points#5caadaeff875dd37a4002251-1554701715978)ようなので、これはしっかり図示して凡ミス回避と脳のリソースを割かないようにした方が良さそう。

![image](https://recipe.kc-cloud.jp/wp-content/uploads/2018/07/AWS%E6%A7%8B%E6%88%90%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E5%9B%B3.png)
出典: [ナレコムAWSレシピ](https://recipe.kc-cloud.jp/archives/11819)

SGとNACLの違いは、自分が出題者だったら絶対出すぞ～～～って印象
担任の先生が「ここ試験に出すからな」って言う確率99％
 
|SG| NACL|
|:-:|:-:|
| **ステートフル**なFW | **ステートレス**なFW|
| **ホワイトリスト**方式で許可 | **ブラックリスト**方式でブロック|
|**インスタンス単位**で使用| **サブネット単位**で使用|
|IPか**他のSGを指定可能** | IP指定のみ|

※ステートフルなFWってどゆこと？
=> 通信の状態（ステート）を保持するので、何の送信に対しての応答トラフィックなのを判断できる。ステートレスだといちいち応答トラフィックのことも考えて設計しないといけない。なのでステートフルの方が設定すること少なくて楽チン♪

## コンピューティングサービス

### EC2

言わずと知れたEC2。
ここでは主にコスト最適化やユースケースなどの観点でインスタンスの利用オプションをまとめる。

- オンデマンド
    - 初期利用なしで使用した分だけの従量課金
    - 標準で適用される
    - 開発・テスト環境などの**決められた時間帯に使用するサーバ群や一時的なWebサイト**での使用が望ましい
- リザーブドインスタンス
    - あらかじめ決められた利用期間（1〜3年）分を購入することで**最大75％オフ**
    - あらかじめ最低限の台数が必要なサーバ用途
    - 同様の考え方で、CloudFrontやDynamoDBなどにもリザーブドキャパシティがある
    - StandardタイプとConvertibleタイプの2種類が提供されている
        - Standardタイプ
            - **リージョンやAZを指定してインスタンスを購入**できる
            - 同じインスタンス構成であれば**購入時に指定したリージョンまたはAZ内でインスタンスの配置変更が可能**
            - それ以外の場所に配置変更したい時は、**手続きをすれば可能**
        - Convertibleタイプ
            - あらかじめ指定したインスタンス構成に依らず、構成変更が可能
            - 割引率はStandardより低い
- スポットインスタンス
    - 最大で割引率が**90％オフ**にもなる**もっとも割引率が高い**購入オプション
    - (ちなみにスポット価格はオンデマンドよりも高くなることがあるので最高価格をしっかり設定した方が良いらしい)
    - 変動制のEC2インスタンスのスポット価格に対して希望購入価格で入札する
    - スポット価格が入札価格を上回ると**インスタンスは強制終了**される
    - 処理が中断しても問題がない用途で使われる（何かのタスクのノードの一つなど）（メインではなくお助け的な数台に使われるイメージ）
    - スポットブロックとスポットフリートのオプションがある
        - スポットブロック
            - あらかじめ決められた時間の起動を保証する（**最大6時間**）オプション
            - 割引率は下がるが、予想外の強制終了を回避できる
        - スポットフリート
            - 指定した性能キャパシティを満たすようにスポットインスタンスを構成するオプション
            - ユースケースに基づいて[スポットフリートを最適化できる](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-fleet.html)

ついでにインスタンスタイプ
「t2.xlarge」を例にとると、
「t」がインスタンスファミリー。色々特化型があるので下で書く
「2」がインスタンス世代。数字が大きい方が新しいのでより良いものであることが多い
「xlarge」がインスタンスサイズです。

#### インスタンスファミリー

- 汎用
    - T,M系
    - 一般的な用途、バランス型
- コンピューティング最適化
    - C系
    - コストの高いCPU処理に特化
- メモリ最適化
    - X,R系
    - 大容量のメモリに特化
- 高速コンピューティング
    - P,G,F系
    - GPUやFGPAなど高速処理に特化
- ストレージ最適化
    - H,I,D系
    - ストレージ容量やI/Oスループット性能に特化

ついでにAMI(Amazon Machine Image)を取る際のルートデバイスについて
（これよくどっちだっけってなる・・😭）

|特徴|Amazon EBS-Backed AMI|Amazon Instance Store-Backed AMI|
|:-:|:-:|:-:|
|インスタンスの起動時間|１分以内|５分以内|
|データの永続性|**インスタンスの終了後も保持される**|**インスタンスの終了後は破棄される**|
|停止状態[Stop]|**できる**。ルートボリュームはEBSに保持|**できない**。実行か終了しかないロックな生き様|
|AMI保存先|EBS|S3|

**EBS-backedインスタンスはデータを永続化**できるが、**Instance Store-Backedインスタンスは揮発性のためインスタンス停止時にはデータが削除**される。
=> そのため、**ブートボリュームは、EBS-backedインスタンス**でなければならない！

詳しくは、[Amazon EC2 ルートデバイスボリューム](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/RootDeviceStorage.html)参照のこと

### ELB(+ Auto Scaling)

高可用性、高パフォーマンスの面で重要。
単一障害点をどうやって無くすかというプラクティス、EC2を複数台にしてELBをその前段に置きがち。
大事なこと、ELBはAWSのマネージドサービスなのでAWS内で十分冗長化されており**単一障害点にはなり得ない**。
AWSは以下3つのロードバランサーをマネージドサービスとして提供している

- Classic Load Balancer(CLB)
- Application Load Balancer(ALB)
- Network Load Balancer(NLB)

CLBとALBの比較
=> 基本的にALBの方が後発な分、安価で機能も優れている。

NLBはHTTP(S)以外のプロトコル通信での負荷分散に用いる。

用途的に無理な話
=> Auto Scalingはスケールアウトに数分かかるため、**スパイク的なアクセスは対応不可**です。

高可用性な話
=> 単一障害点を作らない意味で、作られるインスタンスは**複数のAZに配置**するべき。


コスト最適化の大事な話
インスタンスの課金形態が時間性なので、利用時間を課金が発生する時間未満に収めることができれば安く済む。
AutoScalingの終了ポリシーを制するものはコスト最適化を制する
スケールインの際の終了ポリシーは開発者が定義できるが、デフォルトの終了ポリシーの動作は以下の通り。

1. インスタンスが最も多く、スケールインから保護されていないインスタンスが 1 つ以上あるアベイラビリティーゾーンを決定
2. 終了するオンデマンドまたはスポットインスタンスの[配分戦略](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)に残りのインスタンスが合うように、終了するインスタンスを決定する。このポリシーは、[配分戦略](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)を指定する Auto Scaling グループにのみ適用される。
3. どのインスタンスが最も古い起動テンプレートまたは起動設定を使用しているかを判断する。
4. 上記のすべての基準を適用した後で、終了する保護されていないインスタンスが複数ある場合は、どのインスタンスが次の課金時間に最も近いかを判断する。次の課金時間に最も近い保護されていないインスタンスが複数ある場合、これらのインスタンスのいずれかをランダムに終了する。

この[配分戦略](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)もしっかり抑えておきたい。AutoScalingの細かい挙動は結構問われるイメージ。

- **リザーブドインスタンスはAutoScalingの対象外**であること
- **オンデマンドとスポットを混合したAutoScalingを設定できる**こと
- **あらかじめスケジュール設定されたAutoScalingも設定できる**こと

も重要な点です。

[スケジュールされたAutoScalingも設定できる](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/schedule_time.html)ので、例えば、夜間はほとんどアクセスが無いが、始業時間になるとアクセスが増える業務系のアプリケーションでもAutoScalingを活用することでコスト最適化できる。


また、開発者がカスタマイズできる終了ポリシーは以下の通り。

- `OldestInstance`
    - グループ内の最も古いインスタンスを削除します。
- `NewestInstance`
    - グループ内の最も新しいインスタンスを削除します。
- `OldestLaunchConfiguration`
    - 最も古い起動設定のインスタンスを削除します。
- `ClosestToNextInstanceHour`
    - 次の課金時間に最も近いインスタンスを削除します。 *__← コスト最適化__*
- `Default`
    - デフォルトの終了のポリシーに従って、インスタンスを終了します。
- `OldestLaunchTemplate`
    - 最も古い起動テンプレートを使用するインスタンスを終了します。
- `AllocationStrategy`
    - Auto Scaling グループのインスタンスを終了して、残りのインスタンスを、終了するインスタンスのタイプ (スポットインスタンスまたはオンデマンドインスタンス) の配分戦略に合わせます。


チェックポイント
`OldestInstance`も一見コスト最適化しそうだが、古いからと言って、次の課金時間に最も近いとは限らないのがポイント。
1番古いインスタンスが直前に課金時間の閾値を超えてしまったケースなどがそれ。

小ネタ
AutoScalingは最小台数(min size)、最大台数(max size)に0を指定できる。（というか出来ないとAutoScalingグループを削除するにはインスタンスが停止されている必要があるので成り立たない）

### Lambda
AWS Lambdaは、サーバーレスアーキテクチャの中核を担う存在で、疎結合で高可用性に富んだアーキテクチャを導入できる。
ここでは試験対策（主にコスト最適化）として料金体系について


以下2点がLambdaに対して課金される項目。

1. Lambda関数の**実行数**
2. Lambda関数の**実行時間**

使うほどにお金がかかる従属課金みたいな感じなので、

1. 単位時間当たりに**数回実行するバッチ処理**
2. どれくらい**リクエストが来るか分からないAPI**

に対して、コスト最適化 💪



## ストレージサービス
そもそもAWSのストレージサービスは以下の3つに分類される

- ブロックストレージ
    - 例）EBS
- ファイルストレージ
    - 例）EFS
- オブジェクトストレージ
    - 例）S3

### EBS

ストレージのパフォーマンス 💪 的には、
`プロビジョンドIOPS SSD > 汎用SSD > スループット最適化HDD > コールドHDD`
で、弱い方が安いです。


ここでのコスト最適な設計に求められるのは、
「〇〇の用途ならコールドHDDで良いな」といったように如何にパフォーマンスを落とさず最も安いEBSタイプを選択していけるかだと思う

そのためにはEBSボリュームそれぞれの特徴とユースケースを頭に入れる必要がある

<!--

|EBSボリューム|ユースケース|
|:-:|:-:|
|プロビジョンドIOPS SSD|レイテンシーの影響が大きいトランザクションワークロード向け<br>極めてパフォーマンスの高いSSDボリューム<br>I/O負荷の高い**DB向け**|
|汎用SSD|幅広いトランザクションワークロードに対応<br>価格とパフォーマンスのバランスが取れたSSDボリューム<br>**ブートボリューム**やインタラクティブで低レイテンシーの**アプリケーション**向け|
|スループット最適化HDD|高いスループットを必要とするアクセス頻度の高いワークロード向け<br>低コスト<br>**ビッグデータ、データウェアハウス、ログ処理**向け|
|コールドHDD|アクセス頻度の低いワークロード向け<br>極めて低コスト<br>アクセス頻度の少ない**コールドデータ**向け|
-->

- プロビジョンドIOPS SSD
    - レイテンシーの影響が大きいトランザクションワークロード向け
    - 極めてパフォーマンスの高いSSDボリューム
    - I/O負荷の高い**DB向け**
- 汎用SSD
    - 幅広いトランザクションワークロードに対応
    - 価格とパフォーマンスのバランスが取れたSSDボリューム
    - **ブートボリューム**やインタラクティブで低レイテンシーの**アプリケーション**向け
- スループット最適化HDD
    - 高いスループットを必要とするアクセス頻度の高いワークロード向け
    - 低コスト
    - **ビッグデータ、データウェアハウス、ログ処理**向け
- コールドHDD
    - アクセス頻度の低いワークロード向け
    - 極めて低コスト
    - アクセス頻度の少ない**コールドデータ**向け

また、EBSは**データボリューム、ブートボリューム、およびスナップショットがシームレスに暗号化**される。

### S3(+ Glacier)
イレブンナイン(99.999999999%)の堅牢性を誇るAWSの有名なストレージサービス
AWSのマネージドサービスのため**単一障害点にはなり得ない**（※他にもELBやSQSなど、マネージドサービスと呼ばれるものはAWS内部で冗長化されているため**単一障害点にはなり得ない**）
S3のデータはリージョンに配置されるので、同一リージョン間で同じパケット名は付けらない（はず）。
[AWSのグローバルインフラストラクチャのリージョン表](https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/)でもサービスの欄にS3が登場しているのでリージョンサービスで良いはず

主なユースケースは以下の通り

- データバックアップ（高い堅牢性）
- データレイク（様々なデータ形式を保存できる）
- ログ転送先
- **静的コンテンツのホスティング**
- 簡易的なkey-value型のDB用途

「大量・大容量」、「長期間」、「なくなると困る」といったデータの保存先には、まずS3を検討すると良い


次に、S3のストレージクラスと特徴は以下の通り

- S3 標準
    - いわゆる普通の性能の良いS3
    - アベイラビリティーゾーン3つ以上
    - **アクセス頻度の高いデータ向け**
    - クラウドアプリケーション、動的なウェブサイト、コンテンツ配信、モバイルやゲームのアプリケーション、ビッグデータ分析など、幅広いユースケース
- S3 Intelligent-Tiering
    - 最もコスト効率の高いアクセス階層に自動的にデータを移動する
    - **コストを最小限に抑える**ように設計されている
- S3 標準 – 低頻度アクセス
    - アクセス頻度は低いが、必要に応じてすぐに取り出すことが必要なデータに適する
    - 長期保存、バックアップ、災害対策ファイルのデータストアとして理想的
- S3 1 ゾーン – 低頻度アクセス
    - アクセス頻度は低いが、必要に応じてすぐに取り出すことが必要なデータに適する
    - 1つのAZのみに配置することでコストを20％ほど削減できる
    - **オンプレミスデータ**または**容易に再作成可能なデータのセカンダリバックアップのコピー**を保存するのに適する
- S3 Glacier(アーカイブ)
    - セキュアで耐久性が高い、低コストのストレージクラスで、データのアーカイブに適する
    - **数分から数時間**まで、3種類の取り出しオプションを用意している
- S3 Glacier Deep Archive
    - **最も低コストのストレージクラス**
    - **1年のうち1回か2回しかアクセスされないようなデータを対象**とした長期保存やデジタル保存をサポート
    - **金融サービス、ヘルスケア、パブリックセクター**などの規制が厳しい業界向け
    - **7〜10年間保持されるデータ**の長期保存用
    - 磁気テープの代替策として、費用効率が高く、管理が簡単
    - 3つ以上のAZにレプリケート
    - **12時間以内**に復元可能

link: https://aws.amazon.com/jp/s3/storage-classes/
ちなみに、2018年に[GlacierがS3の一部](https://dev.classmethod.jp/etc/s3-glacier-reinvent2018/)となりました。

S3とClacierの使い分けので押さえておきたいポイントは、取り出しにかかる時間です
例えば、「次の日までに取得できれば良い」なら最もコストの低いS3 Glacier Deep Archiveで良かったり。
「即座」に欲しいならS3標準形
「即座ではない」ならGlacierが視野に入るはず。


S3の整合性について
S3は結果整合性方式を採用しているため、同時にPUTとGETのアクセスなどをするとたまに整合性が合わない結果になることがある。
おそらくSolution Architect Associateの範疇外だが、この結果整合性に対しての操作は開発者が開発しているアプリケーションでケアする必要がある。
詳しくは、[Amazon S3 のデータ整合性モデル](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/Introduction.html#ConsistencyModel)

小ネタ
S3はオブジェクトのキー（name）の先頭からインデックスをかけるため
その昔、S3のパフォーマンス向上テクニックとして、「ランダムなハッシュ値4桁を頭につける」ってのがあったのですが、[現在は日付順の名前を使用できるようになった](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/optimizing-performance.html)そうなので、不要なテクニックになったようです。

Watch 👀
最新のS3のパフォーマンス最適化に関する情報については、

- [パフォーマンスガイドライン](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/optimizing-performance-guidelines.html)
- [パフォーマンス設計パターン](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/optimizing-performance-design-patterns.html)

をウォッチしておくと良さそうです


### Redshift
厳密には、ストレージサービスというよりは、DWH（データウェアハウス）と呼ばれるようなデータ分析するためのデータのため場所、データレイクに用いるサービスです。

Web系のアプリケーションエンジニアは普段業務などでRedshiftを使わない人が多いんじゃないかと思いますが、そこそこ問われるイメージ。

Redshiftは、フル**マネージドサービス**でデータウェアハウスやデータレイクにあるペタバイト規模の構造化データと半構造化データを、標準的なSQLを使用してクエリすることができます。JSONなどの**半構造化データも扱える**のがポイント。

キーワードは「**列指向**型データベース」
Redshiftの最大の特徴でもあり、よく選択肢に絡んでくる印象。これによりデータの持ち方が異なるRDSにはできない手法でのデータ分析を高速化できる。

## データベースサービス

### RDS(Aurora)
RDSにおいて、AWS SAAでよく問われるのは間違いなくAuroraについてだと思う。
（AWSが独自開発したこともあり、推していきたいのかな）
ここは特にAuroraに特化したことについて

まず、Auroraは**MySQLとPostgreSQLとの互換性**があり、**MySQLの最大5倍**、**PostgreSQLの最大3倍高速**
パフォーマンスの問題であればだいたいAuroraに置き換える選択肢が入ってきそう

また、S3への継続的なバックアップ、3つのAZ間でのレプリケーションにより、優れたパフォーマンスと可用性を発揮することも抑えておきたい

Auroraはフェイルオーバー時間についても明記されており、普通**30秒未満**で完了するようです

### DynamoDB
非リレーショナルデータベース（NoSQL）で問われやすいのはこちらもAWS独自のサービスであるDynamoDBだと思う。

主な特徴は以下の通り

- **フルマネージドサービス**
- データの格納と取得に特化（高度な最適化）されている
    - 表結合など柔軟なクエリを発行するのは不得意
- Auto Scalling対応
- 保管時**デフォルトで暗号化**（KMS利用もできる）
- ポイントインタイムリカバリ（PITR）
    - DynamoDB テーブルが誤って上書きされたり削除されたりしないようにできる
    - 過去 35 日間の特定の時点に 2 つ目まで復元できる（連続バックアップ）
- DynamoDB テーブルのデータの完全なバックアップを作成して長期間の保存とアーカイブできる
- 「**ドキュメントデータベース**」でもある
    - 半構造化データをJSONのようなドキュメントとして保存する
    - 柔軟なインデックス作成、強力なアドホッククエリ、およびドキュメントのコレクション 🙆‍♀️
    - ブログプラットフォームや動画プラットフォームなどのコンテンツ管理アプリケーションによく用いられる
    - https://aws.amazon.com/jp/nosql/document/
- 1桁ミリ秒単位のレイテンシーを要求するアプリケーションにも対応
- 期限切れになった項目を自動的にテーブルから削除することも可能
    - ただしTTLが切れても即座に削除はされない（少し時差がある）