はじめに

さて、前回の第1弾の続きになります！
(前回分をご覧になりたい方はこちらから)

今回の記事もタイトルにもある通り、AWS Solution Architect Associateってなやつを受験してきましたので、学習記録として勉強していく中でメモしたものを知識ベース・箇条書きで残しておこうと思います.

では、早速いきましょう！！！

学習記録

「～エンドポイント」はパブリックアクセスさせない（プライベート間で完了）するイメージ
SQSを標準キューからFIFOキューに変更する場合の注意点
- 標準キュー：最大スループット、少なくとも一回配信(重複する可能性あり)
- FIFOキュー：正確な順番、一回のみ配信
  - バッチでmax 3,000メッセージ/s
  - バッチなしで7max 300メッセージ/s
- FIFOキューの名前は「.fifo」サフィックスで終わる（文字数制限はサフィックス入れて80文字）
- 既存のキューはFIFOに変更できない
- 要するに作り直しが必要
ショートポーリング：クエリでメッセージが見つからなかった場合でも、すぐレスポンスを送信
ロングポーリング：少なくとも1つのメッセージ収集してからレスポンスを送信、
ポーリング待機時間経過した際は空のレスポンスを送信（コスト削限できる）
遅延キュー：キューへの新しいメッセージ配信を遅らせることができる,(0s～15minの間で設定可能)
使用例）メッセージを処理するために時間が必要な時
可性タイムアウト：特定のメッセージと受信および処理するのを防ぐ
VPCゲートウェイエンドポイント：インターネットゲートウェイやNATなしにS3に接続可能 
オンプレからVPC内のリソースに対するDNSクエリを解決するには、インバウンド／アウトバウンドエンドポイント
が必要
AWS起因のEC2入れ替えで復元されたインスタンスは、ID・プライベートIP・ElasticIPなど 元のインスタンスと同じものを保持する.パブリックIPがある場合はそれも保持．
File GatewayはStorage Gateayの一部
Data SyncはDirect Connectを介してAWSストレージサービス間でデータの転送を行う
 EFSやFSx for Windows File Serverなどとも連携できる 
Kinesis Data AnalyticsはSQLクエリとJavaアプリケーションの構築に使用される
起動横成テナンシーまたはVPCテナンシーのいずれかがdedicataの場合、インスタンステナンシーもdedicateになる
下記2点は意外と間違えやすいので注意
- AWS Configはリソース構成の評価や監査ができる(コンプライアンス評価)→「ある時点までのAWSリソースはどういう状態か調べられる」
- Cloud Trailは「リソース変更したのは誰かを知ることができる」
SCPはrootユーザーを含む関連づけられたアカウントのすべてのコーザーとロールに影響する
サービスにリンクされたロールには影響しない
Windows システムと互換性があるのはFSx for Windows ファイルサーバーとStorage Gatewayのファイルゲートウェイ構成(NFSやSMBを使用)
EC2のテナンシー展性について
- デフォルト：共有テナンシーベース
- 専用(dedicated）：顧客専用のインスタンス、異なるAWSアカウントに属するdedicatedインスタンスはハードウェアレベルで物理的に分離されている
- dedicated host：'客専用の物理サーバーでもある、インスタンスがサーパーに配置される方法が可視化される
  される方法が可化される
テナンシーはdedicated ←→ dedieated hostしか移行できない
Cloud Formation Stack Set：単一の操作で複数のアカウントとリージョンに渡ってスタックを作成・更新・削除できる
Global Accelerater はゲーム(UDP)・IoT(MQTT)・ボイスオーバーIPなどHTTP以外に適している
複数のリージョンのALBを管理して、エンドポイントの障害を減らすこともできる
Guard Duty：アカウント・ワークロード・S3に保存されたデータを継続的に監視できる「脅威検出」
Macie：機械学習とパターンマッチングでS3上にある機密データを検出&保護
セキュリティグループのインバウンドルールにインターネットゲートウェイは設定できない
スポットインスタンスはについて
- 中断されないように設計されている(1~6hの間で設定可能)
- スポットインスタンスリクエストをキャンセルしてもインスタンスは終了されない
- スポットインスタンスリクエストが有効であれば再開できる
Dynamo DBのポイントインタイムリカバリ（PITR）は破損したデータが書き込まれる直前のテーブルに戻せる
Elasticacheはインメモリデータストアなので、NoSQL DBではない
S3マルチパートアップロードを使用する基準：100MB以上
マルチパートアップロードとS3 Transfer Accelerationを組み合わせるとより高速に転送できる
KMS(SSE-KMS)はCMKがいつ誰によって使用されたか示す監査証跡を提供
- 他2つ（SSE-S3、SSE-C）は使用状況を追跡することはできない
S3バージョニングは有効にした後にのみ一時停止できる（無効にはできない）
Kinesis Data Analyticsの一般的なユースケースはETLのストリーミング
新しいAMIがリージョンAからリージョンBにコピーされるとAMIは基盤となるスナップショットに基づいているため、
コピー先リージョン(この場合はB)にスナップショットが自動作成される
Auroraのフェイルオーバーの決め方
1. リードレプリカの優先順位(0～15）で数字が小さい層から見格される
2. 2つ以上のレプリカが同じ優先度の場合、サイズが最大のものが昇格
3. 2つ以上のレプリカが同じ優先度&サイズの場合、同じ昇格層で任意のレプリカが昇格
LambdaはリージョンごとにAWSアカウントごとに1,000の同時実行がサポートされている
上限を上げるには、AWSサポートに連絡
EFSはEC2インスタンスからはAZ・リージョン・VPC全体でアクセスできる。
オンプレミスサーバーからはDirect ConnectまたはVPCを使用してアクセスできる
RDSのリードレプリカは標準のDBインスタンスと同じ料金で請求され、
同じAWSリージョン間でデータを複製する場合はデータ転送に料金はかからない(異なるリージョンはかかる)
Amazon Cognito：大枠はwebおよびモバイルアプリの認承・ユーザー管理
- ユーザープール：webおよびモバイルアプリ(FacebookとかGoogleのID)を使用してサインインできる(こっちは認承メカニズム)
- IDプール：AWSサービスにアクセスするための一時的なAWS認証情報
Cloud Formationはプロビジョニングに時間がかかる(ダウンタイム最小には不向き）
EFS(IAもあったりする) ←→ NFS(ネットワークファイルシステム)
ブルー/グリーンデプロイのDNS使用時の注意点
- DNSはキャッシュできる特徴がある→トラフィックの高速で制御された移行が必要な場合に適していない
  - レコード更新や障害時に全てのユーザが更新されたIPを受け取るまでの時間がわからない
  - この場合はAWS Global Acceleratorを使用することでトラフィックを徐々にまたは一気にシフトできる
RDSの自動スケーリング有効時、いつ起動するか
- 使用可能が割り当てられたストレージの10%未満
- 低ストレージ状態が少なくとも5分間継続
- 最後のストレージ変更から少なくとも6時間経過している
ある組織から別の組織にアカウントを移行するには
- 前提：メンバー/マスターアカウント両方にルートアクセス or IAMアクセスが必要
- 手頃
  1. 古い組織からメンバーアカウントを削除
  2. 新しい組織からメンバーアカウントに招待を送信
  3. メンバーアカウントから新しい組織の招待を受け入れる
S3はオブジェクトストレージサービスでEFSはファイルストレージサービス
KMSはマルチリージョンキーをサポートしている
Aurora マルチマスターDBクラスターは全てのDBインスタンスで書き込み処理が可能
フェイルオーバー時にダウンタイムも発生しない
マルチAZ構成とリードレプリカの違い
- マルチAZ：可用性向上
- リードレプリカ：スケーラビリティ対策(読み取り負荷の軽減)
VPCとオンプレミスの接続→Transit Gateway
VPCエンドポイントを使用するとプライベートVPCリソース(EC2など)とAWSのサービス(RDSとか)間のネットワーク通信に起因するデータ転送料金を削減できる
Snowball Storge OptimizeからGlacierに直接データは置けない
ElastiCacheはキーと値のペアでデータを格納するのは適切ではない
Data SyncにオンプレミスのストレージシステムとAWS Storageサービス間の大量のデータのコピーを簡素化・自動化・高速化するサービス
S3・EFS・FSx系に移行できる
VPCピアリング x Direct Connect接続を介してオンプレミスからAWSにデータ転送はできない
インスタンスの休止をするとハイバネーションされ、コンテンツをインスタンスメモリ(RAM)からEBSルートボリュームに保存する
EBSルートボリュームとEBSデータボリュームを永続化、この状態からインスタンスを起動すると以前実行されていたプロセスが再開される
S3オブジェクトはアップロードしたアカウントによって所有される(別アカウントAからBにアップロードするとか) → 解決策はクロスアカウント
異なるアカウント間でE2インスタンスをプライベートに通信させるには、RAMを使用してVPC内でサブネットを共有する
Resource Access Managerを使用する
- 追加料金なし、AWSリソースを任意のアカウントで共有できる
起動テンプレートはオンデマンドとスポットインスタンス両方を使用して容量をプロビジョニング可能(起動設定ではできない)
Kinesis Data StreamがFirehose delivery Streamのソースとして指定されている場合はKinesisエージェントはFirehose delivery Streamに、直接書き込めない
→ Data Stream側で何とかする必要がわる
RDS作成時に暗号化していなくても、スナップショットを暗号化して復元することで、RDSの暗号化を実現できる
フリート内のスポットインスタンスが終了した場合に代替インスタンスを起動することでターゲット容量を維持してくれるのはスポットフリート
バケットのARNは末尾に「/」がいらない、オブジェクトのARNは「/*」でバケット内すべての意味になる
Delete On Terminationは、インスタンス終了後もルートボリュームを削除するか決めることができる(Falseにすると削除後も残る)
Kinesis Data Firehoseはサーバレスでマネージド、Data Stream(EMRも同様)はシャードの調整があるのでマネージドではない
EFSにはパフォーマンスモードが2つあるから
- 最大I/O：より高いレベルの集約スループット、ビッグデータ分析やメディア処理などで活躍
- General Performance：一般的なファイルサービスなど遅延を受けやすいユースケース用、デフォルト設定
インスタンスのデフォルト終了ポリシーの優先順位
1. オンデマンドとスポットの割り当て戦略に従って削除
2. 起動設定を使用するインスタンスがあれば最も古い起動設定の削除
3. 最も古い起動テンプレートのインスタンスを削除
4. 請求時間が最も近いインスタンスを削除
Route53 のCNAMEレコードの注意点
- DNSプロトコルでは最上位ノードのCNAMEレコードを作れない
  例)example.comを登録した場合、example.com のCNAMEレコードは作れない
  www.example.comやnewproduct.example.comは作成することができる
VPC共有(Resurce Access Managerの一部)：設定方法はVPCを共有するアカウントがAWS Organizationの同じ組織に属する他アカウントと一つ以上サブネットを消すること
AMIの特致
- リージョン間でコピーできる
- 別のアカウントと共有できる
- 暗号化されたAMIをコピーするとスナップショットも暗号化される(RDSとかのスナップショットと同じ)
EBSの話
- gp2はio1よりも費用対効果高い&パフォーマンスをバーストできる
Cloud Formationの利用自体は無料
VPCサブネット内のインスタンスのインターネットアクセスを有効にする手順
1. インターネットゲートウェイをVPCにアタッチ
2. インターネットのトラフィックをサブネットのルートテーブルに追加する
3. サブネット内のインスタンスがグローバルに一意のIPアドレスを持っていること
4. NACL(Network Access Control List)とセキュリティグループで関連するトラフィックがインスタンスとの間でやり取りできるようにする
Cloud Frontはフィードレベルでの暗号化を利用して、特定のコンテンツの機密データを保護できる(10個まで)
Amazon Neptune(グラフデータベースサービス）：大量のユーザープロファイルとインタラクションをすばやく簡単に処理することができ、ソーシャルネットワーキングアプリケーションに向いている
Route 53の地理的近接性ルーティングと仕置情報ルーティングの違い
- 地理：ユーザーとリソースの地理的関係に基づいてトラフィックをリソースにルーティングできる
  ユーザーの場所に一番近いリソースにリクエスト流せる
- 位置：リクエストの発信元に基づいて、トラフィックを処理するリソースを選択できる
  →ヨーロッパのリクエストはフランクフルトリージョンのELBに流すとか
Compute Optimizer：EC2インスタンスタイプの最適なコスト削減できるしポートを提供
Disester Recovery のシナリオ（4種）
- マルチサイト：アクティブ/アクティブなinfra横成、復旧用の環境でも本番と同じリソースが動いている(本番リソースが2つ)
- ウォームスタンバイ：本番と同じリソースが縮小されて動いている、本番の一部のサービスだけ稼動しているイメージ
- パイロットライト：本番と同じリソースが最低限のバージョンで稼動している、バックアップインフラは常に同期されるなど
- バックアップ&リストア：災害時にバックアップからリソースを復元する
- 上から順に費用が高くなるが復旧時間も短くなる(トレードオフ)
DAX(DynamoDB Accelerator)：DynamoDBのインメモリキャッシュ、リファクタリング不要でホットキーをキャッシュする
Redis(Elasticache)にもマルチAZがある
NLBは固定IPを、パブリッグwebに公開する、IPを使用してASGをスケーリングする
- 逆にALB・CLBは国定のDNS(=URL)を公開する
VPN接続のイメージはオンプレミスとVPC間の接続
VPNのスループットをスケーリングするにはTransit Gatewayのマルチパスルーティングを活用
Athenaはりアルタイムデータを処理するのは不向き
ゾーン間負荷分散のイメージ(ALBではデフォルトでオン、NLBはオフ）
- 無効の場合
  - ぞれぞれのAZので均等に負荷が分散されるようにする
  - 例えばAZがaとbあるとするとaとbそれぞれで50%ずつに負荷分散されるように調整
- 有効の場合
  - AZ全体で負荷分散を行う
    - 例えばAZがaとbあるとすると、そこに属する全体のインスタンスで100%になるように調整
VPCエンドポイントには2種類あり、インターフェイスとゲートウェイの2つ
- インターフェイス：サブネットのIPアドレス範囲からのプライベートIPアドレスを持つENI
- ゲートウェイ：ルートのターゲットとして指定する、S3とDynamo DBがサポート対象
IAM認証はElasticacheではサポートされていないので、Redis認証を使う
WAFはCloud Front(エッジロケーション)およびALB(リージョン)と構成できる
EBSはAZ内で自動的に複製されるが、同じAZ内のインスタンスにしかアタッチできない
S3はメタデータ暗号化できない
Dymano DBはマルチAZで起動できない、Redshiftも同様
launch configurationは変更できない
CIDR範囲は116～128まで
ChefレシピときたらOps Works
インスタンスの終了 → EBSをルートボリュームとしていた場合、デフォルトで削除される
プロビジョンドEBSを使う目安：大規模データベースワークロード(MangoDB, Cassandra, Microsoft SQL Server, MySQL,PostgreSQL)
Glacierは12時間、Deep Archiveは標準取得で12時間、一括取得でも48時間
Transit GatewayはVPCとオンプレミスネットワークを相互接続する
Redshift Spectrumを使うとReashiftテーブルにロードすることなくS3から構造化・半構化データを効率的にクエリ&取得できる
(Redshift自体はデータウェアハウス)
インスタンスストアが最適な時 → バッファ・キャッシュ・スクラッチデータ・一時的なコンテンツなどの頻繁に変更される一時的なデータを扱う時
EBSボリュームの保存データ・スナップショット・インスタンス間で移動するデータは暗号化される
S3イベント通知先はSNS・lambda・SQS(標準キュー)
Beanstalkのユースケースは「webアプリケーションやワーカー環境の構築」・「実行時間の長いワーカープロセス」
STS(Security Token Service)はAWSリソースへの一時的なセキュリティ認証情報を提供できる
Auto Scalingは古いインスタンスを終了する前に新しいインスタンスを起動する
- 異常なインスタンスを終了するための新しいスケーリングアクティビティを作成してから終了する
Direct Connectの最大限の回復力（可用性）は複数のDirect Connectionロケーションにある別々のデバイスで終端する別々の接続で実現できる
デフォルトで保存中のデータと転送中データを暗影化するのはS3 Glacier
EC2の起動中にカスタムスクリプトを実行するには、EC2インスタンスでユーザーデータスクリプトとして実行する
1つのrdsインスタンスで5つまでリードレプリカ作れる
Firewall Manager の対象はWAF・Shield Advanced・VPCセキュリティグループ・~~ファイアウォール
高可用なNATゲートウェイは各AZにNATゲートウェイを作成→インスタンスは同じAZのNATを使うようにする(NATはパブリックに置く）
NLB → TLSオフロードをサポートしている(ALBも)パブリックサブネットに置く
ALB + 動的ポートマッピングでECSクラスター上の同じサービスで、複数のタスクを実行できる
10PB以上のデータセットをAWSに移動する → Snowmobile、100PBまで(Snowballは10TBまで）
EBSマルチアタッチボリューム機能はプロビジョンドIOPSSSD（io1、io2）のみサポート
Memcached
単純なモデル
- マルチスレッドで大規模なノードを実行
- システムの需要によりスケールアウト/スケールインできる
- オブジェクトをキャッシュできる
Redis
- レプリケーション、アーカイブをサポート
- リアルタイムトランザクション分析をサポート
マルチAZのRDSのデータベースエンジンの変更とエンジンアップグレードは、プライマリ・セカンダリ両方が同時にアップグレードされる
→ つまりダウンタイムが発生する
フォールトトレランスを優先 → RAID1、I/Oパフォーマンスを優先 → RAID0(EBSはRAID構成を取れる)
Lambdaは最大15分まで
パブリック間の通信はコストが高いのでプライベートIPで通信する
S3の暗号化：サーバー側はSSE-C(顧客、ユーザーが独自に暗号化するのとは別)、SSE-sS3(S3で管理)、SSE-KMS
アップロード時はx-amz-sever-side-encryprionヘッダーを使う
Cloud Frontを介してのみS3にアクセスする手順
1. オリジンアクセスコントロール作成(OAC)
2. S3バケットのアクセス許可を設定する(S3バケットポリシーの更新)
Redshift：列指向、並列クエリ実行、ペタバイト規模データ、数秒で結果を返却
SCP(サービスコントロールポリシー)はメンバーアカウントのルートユーザーを含む、メンバーアカウントのIAMユーザーとロールのアクセス許可を制限する
- 管理アカウントのユーザーまたはロールに影響はない
SQS Temporaryキュー：開発時間とデプロイコストの部約、高スループット
S3 Intelligent-Tiering：オブジェクトを2つのアクセス層に分ける
- 1つは低アクセス、もう1つは頻繁にアクセスされる層
- 30日連続でアクセスされなかったオブジェクトは低アクセス層へ
- 低アクセス層のオブジェクトにアクセスがあると頻繁アクセス層へ
Amazon MQ(Message Queue)マネージド、メッセージブローカーサービス
- 様々なプログラミング言語を使用したプラットフォームなどでメッセージングサービスを移行する場合に使う
Elastic Fabric Adapter：高レベルのレード間通信を実現できる
WAFはレートベースのアクセス制限が可能、Shieldはできない
クロスリージョンレプリケーションを利用するには、バージョニングが必要

おわりに

というわけで今回も箇条書きで長々と学習記録を書きました！
少々まとまっておらず見づらいものかもしれませんが復習の際に見やすい形へと変えていけたらと思っていますmm
(こうしたら見やすいよという意見もドシドシ待っています！！)

というわけで、また次回の記事でお会いしましょうbb