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

配点比率や試験の概要などは => 公式試験ガイド

ネットワーク

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

• リージョン

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

• AZ

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

リージョンの中に複数のAZ, ローカルゾーンはリージョン外

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

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

VPC

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

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

• 本試験のレベル感で必要なことを網羅している資料（この内容が頭に入ればOKだと思う）
• サクッと思い出したいとき役立ちそう

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

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

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

出典: ナレコムAWSレシピ

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時間）オプション
      • 割引率は下がるが、予想外の強制終了を回避できる
    • スポットフリート
      • 指定した性能キャパシティを満たすようにスポットインスタンスを構成するオプション
      • ユースケースに基づいてスポットフリートを最適化できる

ついでにインスタンスタイプ
「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 ルートデバイスボリューム参照のこと

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. 終了するオンデマンドまたはスポットインスタンスの配分戦略に残りのインスタンスが合うように、終了するインスタンスを決定する。このポリシーは、配分戦略を指定する Auto Scaling グループにのみ適用される。
3. どのインスタンスが最も古い起動テンプレートまたは起動設定を使用しているかを判断する。
4. 上記のすべての基準を適用した後で、終了する保護されていないインスタンスが複数ある場合は、どのインスタンスが次の課金時間に最も近いかを判断する。次の課金時間に最も近い保護されていないインスタンスが複数ある場合、これらのインスタンスのいずれかをランダムに終了する。

この配分戦略もしっかり抑えておきたい。AutoScalingの細かい挙動は結構問われるイメージ。

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

も重要な点です。

スケジュールされたAutoScalingも設定できるので、例えば、夜間はほとんどアクセスが無いが、始業時間になるとアクセスが増える業務系のアプリケーションでも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ボリュームそれぞれの特徴とユースケースを頭に入れる必要がある

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

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

S3(+ Glacier)

イレブンナイン(99.999999999%)の堅牢性を誇るAWSの有名なストレージサービス
AWSのマネージドサービスのため単一障害点にはなり得ない（※他にもELBやSQSなど、マネージドサービスと呼ばれるものはAWS内部で冗長化されているため単一障害点にはなり得ない）
S3のデータはリージョンに配置されるので、同一リージョン間で同じパケット名は付けらない（はず）。
AWSのグローバルインフラストラクチャのリージョン表でもサービスの欄に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の一部となりました。

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

S3の整合性について
S3は結果整合性方式を採用しているため、同時にPUTとGETのアクセスなどをするとたまに整合性が合わない結果になることがある。
おそらくSolution Architect Associateの範疇外だが、この結果整合性に対しての操作は開発者が開発しているアプリケーションでケアする必要がある。
詳しくは、Amazon S3 のデータ整合性モデル

小ネタ
S3はオブジェクトのキー（name）の先頭からインデックスをかけるため
その昔、S3のパフォーマンス向上テクニックとして、「ランダムなハッシュ値4桁を頭につける」ってのがあったのですが、現在は日付順の名前を使用できるようになったそうなので、不要なテクニックになったようです。

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

• パフォーマンスガイドライン
• パフォーマンス設計パターン

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

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が切れても即座に削除はされない（少し時差がある）