首先

现在，我们继续前一篇的第一部分！（如果您想看上篇内容，请点击这里）

我參加了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のフェイルオーバーの決め方

リードレプリカの優先順位(0～15）で数字が小さい層から見格される
2つ以上のレプリカが同じ優先度の場合、サイズが最大のものが昇格
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アクセスが必要
手頃

古い組織からメンバーアカウントを削除
新しい組織からメンバーアカウントに招待を送信
メンバーアカウントから新しい組織の招待を受け入れる

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：一般的なファイルサービスなど遅延を受けやすいユースケース用、デフォルト設定

インスタンスのデフォルト終了ポリシーの優先順位

オンデマンドとスポットの割り当て戦略に従って削除
起動設定を使用するインスタンスがあれば最も古い起動設定の削除
最も古い起動テンプレートのインスタンスを削除
請求時間が最も近いインスタンスを削除

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サブネット内のインスタンスのインターネットアクセスを有効にする手順

インターネットゲートウェイをVPCにアタッチ
インターネットのトラフィックをサブネットのルートテーブルに追加する
サブネット内のインスタンスがグローバルに一意のIPアドレスを持っていること
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にアクセスする手順

オリジンアクセスコントロール作成(OAC)
S3バケットのアクセス許可を設定する(S3バケットポリシーの更新)

Redshift：列指向、並列クエリ実行、ペタバイト規模データ、数秒で結果を返却

SCP(サービスコントロールポリシー)はメンバーアカウントのルートユーザーを含む、メンバーアカウントのIAMユーザーとロールのアクセス許可を制限する

管理アカウントのユーザーまたはロールに影響はない

SQS Temporaryキュー：開発時間とデプロイコストの部約、高スループット

S3 Intelligent-Tiering：オブジェクトを2つのアクセス層に分ける

1つは低アクセス、もう1つは頻繁にアクセスされる層
30日連続でアクセスされなかったオブジェクトは低アクセス層へ
低アクセス層のオブジェクトにアクセスがあると頻繁アクセス層へ

Amazon MQ(Message Queue)マネージド、メッセージブローカーサービス

様々なプログラミング言語を使用したプラットフォームなどでメッセージングサービスを移行する場合に使う

Elastic Fabric Adapter：高レベルのレード間通信を実現できる

WAFはレートベースのアクセス制限が可能、Shieldはできない

クロスリージョンレプリケーションを利用するには、バージョニングが必要

总结

所以这一次我还是用条目式的方式写了一篇漫长的学习记录！虽然可能有些凌乱不易阅读，但我希望能在复习时改写成更易于阅读的形式。
（我也非常期待像这样的意见“这样做更易读！”）

那么，我们下一篇文章再见吧bb。