AWS ソリューションアーキテクトアソシエイト試験勉強

#前提
・AWS ソリューションアーキテクトアソシエイト試験の問題集で間違えた or 自信がなかった質問を元に、確認した内容を記録していきます。
・問題集の内容をこのページに掲載するのは安全側に倒して載せません。(copyright 的に)
・最終的にはざっくりとサービスや分野毎にまとめられたらいいかなと思っています。（適宜更新予定）

#そもそも AWS ソリューションアーキテクトアソシエイト試験ってなあに？
公式サイトをご参照。
試験時間 130 分、65 問のアソシエイト認定レベルの試験。一問あたり 2 分で解かないといけないんですね。あまりゆっくりとは考えている時間はなさそうです。
1000 点満点中 720 点が合格ライン。分割で勉強するときも解いた問題のうち 8 割正解していることを目標にすれば良さそうですね。

#ストレージ
##S3
###オブジェクトロック
・クラメソさんの記事がわかりやすい。
・バケットを新規に作成するときのみ有効化できる。
・オブジェクトロックはバージョニングオブジェクトに対して有効なため、同一キーのアップロードを禁止するものではない。オブジェクトロックが有効になっているバージョニングオブジェクトを指定して削除することができない機能と考えた方が良さそう。
=>裏技的に AWS サポートに連絡すれば既存バケットもオブジェクトロックを有効化可能。ただこれはテストではでなさそう。
・ガバナンスモードとコンプライアンスモードの 2 つのリテンションモードがあり、コンプライアンスモードではアカウントの root ユーザを含め全てのユーザが保持期間中オブジェクトの削除ができなくなる。また保持期間の変更もできない。
・保持期間と組み合わせてリーガルホールドを使用することも可能。リーガルホールドを使用すると、リーガルホールドを明示的に削除しない限りオブジェクトの削除ができなくなる。

###ストレージクラス
ストレージクラスには 6 種類ある。

	Standard	Intelligent-Tiering	Standard-IA	One Zone IA	Glacier	Glacier Deep Archive
ストレージ料金(東京,GBあたり)	0.025USD	利用中の階層に依存	0.019USD	0.0152USD	0.005USD	0.002USD
AZ数	3つ以上	3つ以上	3つ以上	1つ	3つ以上	3つ以上
データ取得時間	-	利用中の階層に依存	Standardと同等	Standardと同等	数分〜数時間	12時間以内
ユースケース	アクセス頻度が高い	アクセスパターンに伴い自動的にコスト削減したい	アクセス頻度は低いが必要に応じてすぐに取り出したい	アクセス頻度は低いが必要に応じてすぐに取り出したい(＆重要でないデータ保管用)	アーカイブ用	アーカイブ用
・Standard 以外は取り出しを行う際に追加の料金がかかる仕組み。
・Standard-IA と One Zone IA のどちらを選択するか：ログファイルなどのデータは One Zone IA がより適していると判断するようだ。

###Range Get
・HTTP の一般的な機能に則って実装されている。
・HTTP リクエストヘッダの Range で取得したいバイト数を指定してリクエストを行うことで、シーケンシャルに分割されたオブジェクトのパートをダウンロードできる。
・単一オブジェクトのサイズが大きく、ネットワーク接続が不安定な場合に効果的。
・AWS CLI コマンドの get-object であれば --range オプションで指定可能。
・Range Get したオブジェクトパートはローカル側で別途マージする必要がある。

$ aws s3api get-object --bucket <バケット名> --key <キー名> --range bytes=0-100 my_data_range0-100

##Glacier
・Glacier ストレージクラスに格納したオブジェクトの復元は 3 つのオプションから選択することができ、最も早く取り出せる高速取得を使用すると 1 - 5 分で復元できる。（意外と早い！）
・ちなみに通常の復元だと 3 - 5 時間程とのこと。
##Glacier Deep Archive
・Glaceir Deep Archive ストレージクラスに格納したオブジェクトの復元は 12 時間以内に可能。（思ったより短かった)
・スタンダードクラスの S3 をバイパスする必要はなく、PUT 時に直接 Glaceir Deep Archive ストレージクラスに格納することが可能。

$ aws s3api put-object --bucket <バケット名> --key <キー名> --storage-class DEEP_ARCHIVE

・復元の仕方は restore-object コマンドを使用。指定した期間のみコピーができる。

$ aws s3api restore-object --bucket <バケット名> --key <キー名> --restore-request '{"Days":<日数>,"GlacierJobParameters":{"Tier":"Standard"}}'

##Amazon FSx for Luster
・ストレージ速度が重要なユースケースで使用。
・S3 バケットとリンクさせることにより、FSx for Lustre から S3 のオブジェクトを透過的に読み書きできる。
・Luster クライアントをインストールし、ファイル共有領域をマウントすることで、ローカルディスクと同じように使用することができる。
・クラメソさんの記事：新発表されたAmazon FSx for Lustreを構築してEC2からアクセスしてみた 参照。

##EFS
同一 VPC 内であれば異なる AZ に作成されたマウントターゲットを使用することもできる。
繋がらない場合にはマウントターゲット (ENI) にアタッチされた SG を疑うべし。
VPC Peering 経由で別 VPC からもアクセス可能。
###パフォーマンス
EFS で選択可能なパフォーマンスオプションはパフォーマンスモードとスループットモードの 2 種類がある。
それぞれ特徴やユースケースをまとめておく。
参考ドキュメント：Amazon EFS パフォーマンス
###パフォーマンスモード

	汎用パフォーマンスモード	最大 I/O パフォーマンスモード
ユースケース	右記以外全て	ビッグデータ解析、メディア処理、ゲノム解析などの高度に並列化されたアプリケーションやワークロード
特徴	レイテンシーに敏感なユースケース	集計スループットと 1 秒あたりのオペレーション数が高い。一方レイテンシーがわずかに高くなるので高いレイテンシーが求められるユースケースでは使用しない
追加コスト	なし	なし

###スループットモード

	バーストスループットモード	プロビジョンドスループットモード
ユースケース	右記以外全て	ストレージへのスループット速度が高い (TiB あたり MiB/秒) アプリケーション
特徴	データ量が大きくなるにつれてスループットが上昇。一定期間内のスループットレベルのバーストが許可されている	データ量に限らず指定したスループットが出る
追加コスト	なし	あり

#ネットワーク
##VPC
###インターリージョン VPC ピアリング
・異なるリージョン間の VPC を接続する機能。
・インターリージョン VPC ピアリングを使用することで、リージョン A の VPC に作成したインタフェース VPC エンドポイント (PrivateLink) をリージョン B の VPC から使用することができる。そうすることで例えば VPC 外のリソース (DynamoDB) にもプライベートにアクセスすることが可能。

###セカンダリ ENI を使用するユースケース
2 本足の意義は？と思っていたが、公式ドキュメントにも記載があった。低予算で可用性の高いソリューションを作成するのに使用できるとのこと。

低予算で可用性の高いソリューションを構築する
特定の機能にサービスを提供しているインスタンスのいずれかが機能しなくなった場合は、そのネットワークインターフェイスを同じ役割で構成された交換用またはホットスタンバイ用のインスタンスにアタッチすることで、サービスを迅速に回復できます。たとえば、データベースインスタンスや NAT インスタンスなどの重要なサービスに対するプライマリまたはセカンダリのネットワークインターフェイスとしてネットワークインターフェイスを使用することができます。そのインスタンスが機能しなくなった場合、お客様 (通常はお客様に代わって実行されるコード) がネットワークインターフェイスをホットスタンバイ用のインスタンスにアタッチすることができます。インターフェイスでは、プライベート IP アドレス、Elastic IP アドレス、および MAC アドレスがそのまま維持されるため、交換用のインスタンスにネットワークインターフェイスを接続するとすぐに、ネットワークトラフィックはスタンバイ用のインスタンスに流れ始めます。インスタンスに障害が発生してから、ネットワークインターフェイスがスタンバイ用のインスタンスにアタッチされるまで、一時的な接続断が発生しますが、VPC ルートテーブルや DNS サーバーに変更を加える必要はありません。

###NATGateway
NATGateway は AZ 毎に作成し、AZ 障害に備えて冗長化させることがベストプラクティス。
参考ドキュメント：NATGatewayの基本

複数のアベイラビリティーゾーンにリソースがあって、1 つの NAT ゲートウェイを共有している場合、その NAT ゲートウェイが属するアベイラビリティーゾーンがダウンすると、その他のアベイラビリティーゾーンのリソースはインターネットにアクセスできなくなります。アベイラビリティーゾーンに依存しないアーキテクチャを作成するには、アベイラビリティーゾーン別に NAT ゲートウェイを作成し、同じアベイラビリティーゾーンに属する NAT ゲートウェイをリソースで使用するようにルーティングを設定します。

#コンピューティング
##EC2
###プレイスメントグループ
EC2 インスタンスが起動する仮想サーバの定義付けを行うことのできる機能。ワークロードのタイプに応じて 3 つから選択可能。
プレイスメントグループはリージョンに固有。

	クラスター	パーティション	分散
ワークロード	低レイテンシー、高スループット	ハードウェア障害を軽減	ハードウェア障害を軽減(パーティションより高度)
ユースケース	HPC	HDFS、HBase、Cassandra	-
特徴	AZ内のインスタンスを論理的にグルーピング	他のパーティションとラックを共有しない	インスタンスを別々のラックに配置

###EFA
拡張ネットワーキング (ENA) の高度版のようなもの。OS バイパス機能によりアプリケーションは OS のカーネルをバイパスして EFA デバイスと直接やり取りできるためより高速。
ユースケースは HPC や機械学習アプリケーション。
サポートされるインスタンスタイプが狭く (m5dn.24xlargeなど)、OS として Windows は利用できない。

###インスタンスの休止 (Hibernate)
インスタンスのステータスの一種。インスタンスを事前にウォーミングしておきたいときに使用する。
ルートボリュームが EBS のインスタンスのみ利用可能。AutoScaling や ECS では使用できない。

##EBS
###ボリュームタイプ

	プロビジョンド IOPS SSD	汎用 SSD	スループット最適化 HDD	Cold HDD
ユースケース	ミッションクリティカル	デフォルト	ビッグデータ、データウェアハウス、ログ処理	アクセス頻度の低いワークロード
ストレージ料金	1(高)	2	3	4(安)
上限サイズ	64TiB	16TiB	16TiB	16TiB
最大IOPS	256,000(16KiB I/O)	16,000(16KiB I/O)	500(1MiB I/O)	250(1MiB I/O)
最大スループット	4,000 MiB/秒	250 MiB/秒	500 MiB/秒	250 MiB/秒
ブートボリューム使用	可	可	不可	不可
マルチアタッチ	可(io2 Block Expressでは不可)	不可	不可	不可
・料金は基本的にストレージ、IOPS、スループットに対してそれぞれかかる。
・本当は上記よりももっと細かく分かれている。詳細は公式ドキュメントを参照。

##AutoScaling
###ライフサイクルフック
スケールインのとき：ステートフルインスタンスがスケールインする時に重要なデータを抜き取る時間を確保するのに役立つ。

スケールインイベントが発生すると、ライフサイクルフックによってインスタンスが終了される前に一時停止され、Amazon EventBridge を使用して通知が送信されます。インスタンスが待機状態の間に、AWS Lambda 関数を呼び出すか、インスタンスに接続して、インスタンスが完全に終了される前にログやその他のデータをダウンロードできます。

スケールアウトのとき：起動直後の処理 (ユーザデータの実行みたいなもの) の猶予みたいなユースケースで使うのかな。ユーザーデータまたは cloud-init スクリプトでライフサイクルフックを制御できるみたい。
###スケーリングプロセスの中断と再開
設定上の問題により、スケールアウトの条件を満たしていてもインスタンスの起動ができなかった場合は、おとなしく起動プロセスを中断する。中断したプロセスは任意のタイミングで再開することができる。

Amazon EC2 Auto Scaling は、お客様が中断するだけでなく、インスタンスの起動に繰り返し失敗する Auto Scaling グループのプロセスを中断することもできます。これは、管理上の中断と呼ばれます。管理上の中断は一般に、24 時間以上インスタンスの起動を試みているが、インスタンスの起動に成功していない Auto Scaling グループに適用されます。管理上の理由で Amazon EC2 Auto Scaling によって中断されたプロセスは、お客様が再開できます。

#データベース
##Aurora
###可用性設計
アベイラビリティゾーンを跨いでフェイルオーバーをさせたい場合：マルチAZ配置
リージョンを跨いでフェイルオーバーをさせたい場合：リードレプリカをマスタと別リージョンに作成
Amazon Aurora グローバルデータベースの概要

Aurora グローバルデータベースは、データのマスターが作られるを 1 つのプライマリAWSリージョンと、最大 5 つの、読み取り専用のセカンダリAWSリージョンで構成されます。書き込み操作は、プライマリ AWS リージョンにあるプライマリ DB クラスターに直接発行します。Aurora は、専用のインフラストラクチャを使用してセカンダリ AWS リージョンにデータをレプリケートします。レイテンシーは通常 1 秒未満です。

Amazon Aurora グローバルデータベースの利点

リージョン全体にわたる停止からの回復 – セカンダリクラスターを使用すると、従来のレプリケーションソリューションよりも迅速に (低い RTO)、少ないデータ損失 (低い RPO) で Aurora グローバルデータベースを新しいプライマリ AWS リージョンで使用できるようになります。

##RDS
###暗号化
・暗号化は DB インスタンスの作成時にしか行うことができず、一度暗号化した DB インスタンスの暗号化を無効化することはできない。
・つまり、現在平文の DB インスタンスを暗号化したいという要件が持ち上がった場合には、一度 DB インスタンスのスナップショットを作成し、スナップショットの暗号化コピーを実施のうえ、暗号化されたスナップショットから DB インスタンスを復元する必要がある。
Amazon RDS の暗号化された DB インスタンスの制限事項

###フェイルオーバーの仕組み
Multi AZ 配置のプライマリ DB インスタンスに何かしらの問題が生じるとセカンダリ DB インスタンスへのフェイルオーバーが発生する。
このとき、セカンダリ DB インスタンスをポイントするように DNS の CNAME レコードが自動的に切り替わる。

フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。

##DynamoDB
完全マネージド型の NoSQL データベースサービスであり、高速で予測可能なパフォーマンスとシームレスな拡張性が特長
###スケーリング
####AutoScaling と DynamoDB Accelerator(DAX)
・AutoScaling：EC2 の AutoScaling と同等。実際のトラフィックパターンに応じてキャパシティを動的に変動させることが可能。
実装方法として、は予め CWA を設定しておき、アラームの閾値を超えた場合にスケーリングが実行されるような流れ。
・DynamoDB Accelerator(DAX)：DynamoDB に特化したフルマネージド型高可用性インメモリキャッシュ。やはり少々お値段は高くなる模様。
=>トラフィックやワークロードが予測可能な場合には、AutoScaling を組んだ方が安価。コスト最適化という文言が出てきたときには AutoScaling を利用できないか検討し、できる限り AutoScaling を選択した方が良さそう。(私見)
####グローバルテーブル
マルチリージョンにマルチアクティブデータベースをデプロイするためのソリューション。

たとえば、米国東海岸、米国西海岸、西ヨーロッパという 3 つの地域にわたる大規模な顧客ベースがあるとします。ユーザーは、アプリケーションの使用中に自分のプロファイル情報を更新できます。このユースケースを満たすには、という名前の同一の DynamoDB テーブルを 3 つ作成する必要があります。CustomerProfilesが所在する 3 つの異なる AWS リージョンで作成されます。この 3 つのテーブルは、互いに完全に独立しています。1 つのテーブルのデータを変更しても他のテーブルに反映されることはありません。マネージド型のレプリケーションソリューションを使用しなくても、コードを書き込んで、このテーブル間のデータ変更をレプリケートすることができます。ただし、これを行うには時間も労力もかかります。

独自のコードを書き込む代わりに、リージョン固有の 3 つのリージョン固有のCustomerProfilesテーブル。DynamoDB は、これらのテーブル間でデータの変更を自動的にレプリケートし、CustomerProfilesデータは、他のリージョンにシームレスに伝播します。さらに、いずれかの AWS リージョンが一時的に利用できない場合は、顧客は他のリージョンの同じ CustomerProfiles データにアクセスできます。

#その他

##SQS
FIFO の特徴：
・重複がないように設計されている(稀に重複があるケースはある)
・メッセージの順序が担保される。
・標準キューと比較して、100 万リクエストあたり 0.1 USD 程度高い。

・キューに優先度を設定することができる。有料ユーザと無料ユーザが存在するサービスで、有料ユーザの処理を優先させるようなことが可能。
実装方法例：
１．SQSを用いて優先順位ごとに複数のキューを用意する。
２．処理を急ぐリクエストは優先順位の高いキューに入れる。
３．優先順位に応じてキューを処理するサーバー台数を用意する。

・ロングポーリング機能あり。ポーリング待ち時間の最大長は 20 秒で空のレスポンスを削減できる。

###デッドレターキュー
メッセージの失敗を処理するために使用。正しく処理できないメッセージを分離して、処理が成功しなかった理由を調べることができる。

##ElasticBeanstalk
アプリケーションのデプロイと管理を簡単に行うことができるサービス。プロビジョニング、ロードバランシング、スケーリング、およびアプリケーション状態モニタリングを自動でやってくれる。
一般的なのは HTTP リクエストを処理する Web サーバ環境に思われるが、もう一つ SQS からタスクを取り出すバックエンド環境としてワーカー環境も作成できる。

##OpsWork
環境構築とアプリケーションのデプロイの自動化・統合管理を実現するサービス。Chef レシピを使用。
CloudFormation / Elastic Beanstalk と何が違うの？
CloudFormation との違い：CloudFormation はほぼ全ての AWS のリソースのプロビジョニングを行うことができるが、OpsWork は EC2 / EBS / EIP / CW などアプリケーション志向の AWS リソースに限られる。json と Chef の違いもある。
Elastic Beanstalk との違い：Beanstalk はコードをアップロードするのみでインフラのキャパシティーやロードバランシングなどは全部サービスにお任せ。一方 OpsWork はセットアップは自動化されるものの、Beanstalk のような全自動はできないものと考えられそう。

##CloudFormation
###ドリフト
EC2 や RDS などのリソースのパラメータを直接変更したときに CloudFormation のテンプレートとの差異を検出する機能。テンプレートに明示的に指定したパラメータが確認の対象になるので、ドリフト検知させたい場合にはデフォルトから変更をしていないパラメータも明示的にテンプレートに記載する必要がある。

CloudFormation は、スタックテンプレートを通じて、またはテンプレートパラメータを指定することによって、明示的に設定されたプロパティについてのみドリフトを判断します。これには、リソースプロパティのデフォルト値は含まれません。ドリフトを決定する目的で CloudFormation がリソースプロパティを追跡させるには、デフォルト値に設定している場合でも、プロパティ値を明示的に設定します。

##CloudTrail

デフォルトでは、CloudTrail S3 のイベントログファイルは Amazon S3 のサーバー側の暗号化 (SSE) を使用して暗号化されます。AWS Key Management Service (AWS KMS) キーを使用して、ログファイルを暗号化する選択もできます。

###グローバルサービスイベント
IAM、STS、CloudFront などのグローバルサービスはログが重複して記録されることがある。重複を防ぐためには、グローバルサービスイベントのログの無効化をする必要がある。

$ aws cloudtrail update-trail --name --no-include-global-service-events

##Simple Workflow Service
ジョブ管理システム (JP1のようなもの) と理解。