はじめに
「AWS認定資格試験テキスト＆問題集 AWS認定ソリューションアーキテクト – プロフェッショナル」の書籍を半分まで読んだので、勉強したことをアウトプットします。
SAA-C03取りたてで、SAPはまだまだ難い状況ですので、たぶん、こういう事だろうという想像だけで解釈している事もあろうかと思います。間違ったことを書いている可能性がありますが、ご了承ください。
VPCエンドポイント
VPCエンドポイントには２つあります。ゲートウェイエンドポイントとインターフェイスエンドポイントです。ゲートウェイエンドポイントはVPCにアタッチされるのに対し、インターフェイスエンドポイントはサブネットにアタッチされます。
インターフェイスエンドポイントはノードではなくNICに該当します。とはいっても、NICだけが単体で動くはずがなく、物理的にイメージするとすればルータでしょう。AWSではNICのことをENIと呼びます。ENIにはプライベートIPが割り当てられます。
ゲートウェイエンドポイントは無料で使えますが、インターフェイスエンドポイントを使うとコストが発生します。
クロスアカウントアクセス
BアカウントからAアカウントにクロスアカウントアクセスをしたい場合、Bアカウント、Aアカウント共にIAMユーザーを作成する必要はありません。IAMユーザーを作成するのはAアカウントだけです。Bアカウントには不要です。BアカウントにはAアカウントにアクセスできるロール（AssumeRole）だけを作成して、Bアカウントにアタッチさせておきます。そうすればBアカウントで作成したすべてのユーザーがAアカウントのサービスを使えるようになります。外部にあるサードパーティー製の製品からAWSにアクセスするような場合にも、クロスアカウントアクセスが使われます。サードパーティー製の製品がAWSにアクセスができるように、AssumeRoleのIAMロールをアタッチさせておきます。
IAMロールにはARNというユニークな番号が付与されており、AWSに接続するときにARNで認証が行われます。認証にはARNだけでなく、外部IDといった情報も必要です。万が一、ARNが漏洩しても外部IDさえ漏洩しなければ、第三者からAWSにログインされることが防げるようになっています。
VPN
一言でVPNといっても、ソフトウェアVPN、AWSクライアントVPN、site-to-site VPNと
３種類の実現方法があります。
site-to-site VPNはオンプレからルータを経由してインターネットVPNを構築するような場合に利用されます。データをカプセル化させる技術にはIPsecというプロトコルが標準的に利用されます。
Site-to-Site VPNで、オンプレ側に設置するルータのことをカスタマーゲートウェイといいます。そして、AWS側のルータに該当するサービスを仮想プライベートゲートウェイといいます。
site-to-site VPNはマネージド型です。site-to-site VPNと同じような構成をアンマネージドで実現させる方法は恐らく存在しません。
ソフトウェアVPN、AWSクライアントVPNは、共にsite-to-site VPNとは実装の仕様が異なります。
ネットワーク層レベルでカプセル化をさせるのではなく、アプリケーション層レベルで暗号化させてVPNを実現させる仕組みです。
AWSクライアントVPNはマネージド型であるのに対し、ソフトウェアVPNはアンマネージド型です。よって、AWSクライアントVPNは運用コストがゼロで利用できるのに対し、ソフトウェアVPNは自力でEC2にソフトウェアVPNアプリをインストールして、設定をすることになります。
CloudFormation
CloudFormationではResourcesの個所にLambda関数を記述して、CloudFormationから、Lambda関数を実行させることができます。CloudFormationだけでは対応できない処理をLambda関数を使って、外部から実行させるといった使い方ができます。Resourcesに記述するコードのことを、カスタムソースともいいます。
また、CloudFormationを使ってEC2にデプロイするときに、CloudFormationの機能だけでは対応できないような応用的な処理をする場合、ヘルパースクリプトを使うこともできます。ヘルパースクリプトはEC2の中にインストールされており、CloudFormationからキックして実行することができます。Amazon Linux2にはデフォルトでインストールされているが、EC2にUbuntu、CentOSなどを採用した場合は、別途インストールしないといけないことになります。
CloudFormationの内容を他から書き換えられないように保護をかけたい場合は、CloudFormationにスタックポリシーをアタッチすることで保護をかけることができます。
CloudFormationのスタックを削除すると、作成済のサービスが削除されることになるが、CloudFormationにDeletionPolicyをアタッチさせておくことで、削除を未然に防ぐことができるようになります。
ブルー/グリーンデプロイ
ブルー/グリーンデプロイというデプロイの仕方がります。既存ソースがブルーで、新ソースがグリーンとなります。本番サーバーにブルーとグリーンの２つの環境を用意しておいて、ブルーの環境を少しづつグリーンにしていくデプロイの仕方のことを言います。
ブルーからグリーンになる割合が増えるごとに、Route53でルーティングさせるユーザーの割合を増やしていくことなります。このようなルーティングのことを加重ルーティングといいます。
VPCフローログ
ENIに流れるパケットはVPCフローログを使って、CloudWatch Logs、または、S3に送信することができます。VPCフローログでキャッチできる情報は、流れるすべてのパケットではありません。すべてのパケットの情報をそのままごっそり取得したい場合は、トラフィックミラーリングを使うことになります。
OpenSearch Service
AWSの各サービスで取得した様々なログを一元集約させて分析をするツールが、OpenSearch Serviceとなります。このようなツールのことを一般的にSIEMといいます。
各サービスが集めたログをOpenSearch Serviceで扱えるように整える必要があるが、その処理はLambdaで行います。OpenSearch Serviceに集めたデータをGUIで表示するツールがOpenSearch Dashboardsとなります。
Systems Managerエージェント
通常のSession ManagerはSSHを使ってEC2に接続するわけではないため、SSHポートを開けることなく利用することができます。（マネージド型なので、実は裏側でSSHが使われていのかも分かりませんが、だったとしても意識する必要はありません）Systems ManagerはAWSが提供されているツールで、Systems Managerを提供しているサーバーがどこにあるのかは分かりません。
自分でEC2をSystems Managerサーバーに仕立てて、そこで、独自のSystems Managerを使いたい場合は、EC2にSystems Managerエージェントをインストールすることで実現できるようになります。
ルート権限の検知
ルート権限は基本的には使わないことが推奨されています。意図せずにルート権限が使われた場合には、GuardDutyを使って検知することができます。検知したらAmazon SNSで通知するような使い方ができます。
GuardDutyを使った検知は、GuardDutyが自動で行ってくれるのではなく、EventBridgeを使わないと検知することはできません。恐らく、EventBridgeがメモリに常駐して常時監視しているのだと思います。
ルート権限が使われた場合の検知は、CloudWatch Logsでも行えます。ルート権限が使われた場合のログはCloudWatchには出力されず、CoudTrailに出力されます。CoudTrailに書き込まれたログはCloudWatch Logsに転送することができます。CloudWatch Logsに転送して、CloudWatch Logsの中で検知するといった使い方になります。（少々回りくどい使い方のような印象ではありますが、このような使い方しかできないのでしょう）
KMS
キー（鍵）をAWS側でマネージド的に管理してもらうツールがKMSです。ユーザーが作成したキーをCMK（カスタマー管理キー）といい、KMSはCMKを管理するツールです。ユーザーが作成したキーをCMKというのに対し、AWSで始めから用意されているキーをAWS管理キーと呼びます。キーと一言で言っても、CMKとAWS管理キーの２つあるということになります。
一般的にはキーの種類には公開鍵暗号方式と共通鍵暗号方式とがありますが、AWSでは公開鍵暗号方式に該当する方式を非対称暗号化といい、共通鍵暗号方式に該当する方式を対称暗号化（エンベローブ暗号化）といいます。キーを作成する元になる文字列のことをキーマテリアルといいます。
キーマテリアルはKMSで生成することができます。また、サードパーティー製のツールで生成したものをKMSにインポートして使うこともできます。
キーはS3やRDSなどで使われますが、KMSを使うと、すべてのサービスで使うでキーを一元で管理することができます。
キーの管理には、KMSを使う場合と、Systems Manager Parameter Storeを使う場合とがあります。少し脱線しますが、Securets Managerはパスワード、トークンを管理するツールです。パスワード、トークンを暗号化するときに使うキーはKMSを使って管理することになります。
DynamoDBへ接続するときに認証で使うパスワードの暗号化は、DynamoDB側でも行えるが、KMSを使うこともできます。ただし、KMSを使った場合、キーの保管料が発生すると、KMSに問い合わせるときのリクエストコストが発生することになります。
暗号化の設定変更
EBSボリュームを暗号化させるかどうかはEBSを作成するときに決めることになります。一旦、作成した後に変更することはできません。スナップショットから変更することはできます。（というか、そうするしかしようがありません）EBSボリュームを暗号化させるときに使うキーもKMSで管理することができます。
RDSで管理するデータの暗号化もEBSと同じです。暗号化させるかどうかは、RDSを作成するときに設定します。作成した後に変更することはできません。変更する場合は、RDSもスナップショットから設定を変えることになります。
S3でのキーの管理
S3のキーを暗号化するときに、サーバー側ではなくクライアント側で暗号化することを
CSE（クライアントサイド暗号化）といいます。（CMK（カスタマー管理キー）と混乱しないように）CSEはクライアント側で暗号化して暗号化したものをS3に送ることになります。CSEで暗号化する場合のキーをKMSで管理することができます。KMSを使わずに独自で保管することもできます。CSEを採用する場合で、キーをKMSで管理することをCSE-KMS、自分で管理することをCSE-Cといいます。
CSEではなく、S3側でキーを管理することをSSEといいます。S3でキーを保管することをSSE-S3、KMSを使って管理することをSSE-KMSといいます。SSE-KMSを採用した場合の利点として、ClouTrailを使った追跡監査ができるといった点があります。
CloudHSM
キーの保管をKMSではなく、物理的に外部のハードウェアで管理することができます。そのサービスをCloudHSMといいます。KMSはFIPS 140-2 レベル2に準拠しているが、CloudHSMはFIPS 140-3に準拠しています。
KMSをやめてCloudHSM１本で管理することもできますが、KMSとCloudHSMを併用して使うといった運用もあります。併用して使う場合は、KMSのキーストア（キーの保管庫のこと）だけをCloudHSMで利用し、暗号化はKMSを使って行うといった運用になります。
ACM
ACM（Certificate Manager）はSSL/TLS証明書を保管するツールです。プライベート用に使うSSL/TSL証明書を発行する機能を、Private Certificate Authorityといいます。
Secrets Manager
Secrets Managerはパスワードを管理するツールです。（KMS、Certificate Managerと混乱しないように）Secrets Managerにアクセスしてパスワードを取得するには、GetSecretValueリクエスト（APIリクエスト）を発行して取得します。
RDSに接続するときのパスワードをSecrets Managerで管理する場合、マネージドローテーションの設定を有効にすると、パスワードが一定期間の間でローテーションされます。マネージドローテーションでは内部でLambda関数が流れます。Lambda関数は自作するのではなくRDS側で既に用意されています。
マネージドローテーションを使わずにローテーションをすることもできます。その場合は、自分でLambadを立てて、そこでLambad関数を流すようにします。Lambdaはサブネット内に立てるサービスのではなくVPC内に立てるサービスですので、ambdaがSecrets ManagerとRDSの両方に接続できるように設定する必要があります。
マネージドローテーションを使ってローテーションをする場合、シングルユーザーローテーションにしか対応していません。マネージドローテーションを使わずに、自分でLambdaを立てて、そこでLambad関数を実行する場合は、交代ユーザーローテーションに対応させることができます。
シングルユーザーローテーションの仕組みだと、ローテーションが発生してパスワードが切り替わったタイミングで、たまたま接続があると、認証エラーが発生するリスクがあります。しかし、交代ユーザーローテーションの仕組みだとそれが発生しないようにできます。
Inspector
Inspectorはセキュリティの脆弱性を診断するツールです。診断のスキャンはSSM（System Manager）から行われます。InspectorはEC2、ECR、Lambdaに対応しているが、EC2だけに対応している、Inspector Classicというレガシー版もあります。また、Inspectorは手動で実行するのではなく、EventBridgeを使って自動で実行させることもできます。
WAF
WAFを導入するには、導入したいサービスにWebACLをアタッチさせます。そして、WebACLには適用させるルールを設定します。WAFのルールには、一般的な脅威を保護するベースラインルール、OWASPに記載されている脅威から保護する、コアルールセットなどのルールがります。
WAFのログの解析は、Kinesis Data Firehoseに送って、そこでLambdaで処理をするのが一般的な使い方となります。その他、S3、CloudWatch Logsに送信する使い方もできます。
Storage Gateway
Storage GatewayはAWS側に設置されるサービスで、オンプレからS3に接続するサービスです。主に、オンプレのデータのバックアップを取るときに利用されます。オンプレからStorage Gatewayにデータを転送すると、そこからS3へは自動で転送されます。
Storage Gatewayには、ファイルゲートウェイ型とボリュームゲートウェイ型とがあります。また、Storage Gatewayには、FSxファイルゲートウェイというのもあります。オンプレがWindowsの場合、FSxファイルゲートウェイを採用する手もあります。
クロスリージョンコピー
ディザスタ対策で、別リージョンにバックアップを取る場合、クロスリージョンコピーというやり方があります。EC2でAMIを取得し、EBS、RDSでスナップショットを作成して、別リージョンにコピーしてバックアップをとります。AMIとEBSのスナップショットは、データライフサイクルという機能で、定期的に自動で取得して、自動でコピーされるようにします。バックアップは各サービス単位で行うが、それを一元管理するツールにAWS Backupというのがあります。
クロスリージョンレプリケーション
クロスリージョンコピーとクロスリージョンレプリケーションは異なります。クロスリージョンコピーはバックアップのコピーをするだけで、復元するには時間がかかります。クロスリージョンレプリケーションは同じものを複製するので、復元が発生しません。S3でクロスリージョンレプリケーションを高速にするには、S3レプリケーション・タイム・コントロールを有効にすると早くすることができます。
Global Accelerator
普通IPは１つのNICに１つだけ割り当てます。このことをユニキャストといいます。複数のNICに同じIPを割り当てることをエニーキャストといいます。Global AcceleratorにはエニーキャストIPが割り当てられます。つまり、すべてのGlobal Acceleratorで同じIPが割り当てられていることになります。どこのGlobal Acceleratorにルーティングされても同じIPが利用されることになります。ルーティングは、一番レイテンシーが低いGlobal Acceleratorにルーティングされるようになっています。
RDS Proxy
LambdaとDynamoDBの組み合わせが一般的な構成になるが、Lambdaを使って、データベースにRDSを使うといった組み合わせも使えます。ただし、Lambdaからの接続数が少ない場合は問題ないのだが、接続数が増大すると接続ができなくなるといったリスクが発生します。そのようなリスクがある場合は、RDS Proxy経由で接続することでリスクを回避させることができます。
RDS Proxyを使うと一度確立したセッションは解除して、再度、また新しいセッションを張り直すのではなく、解除したセッションを再利用する仕組みがあるため、セッションがいっぱいになってしまうことが発生しないようになっています。
ただし、RDS ProxyはRDSでは使えてもAuroraでは使えないといった制限があります。また、RDS Proxyを使うと、RDS側にゲートウェイとなるエンドポイントを設定する必要があります。
クールダウンとウォームアップ
スケールイン/アウトが頻繁に行われないように、スケールイン/アウトが一度実行されたら、一定の期間はスケールイン/アウトが行われないように制御ことができます。この設定をクールダウンといいます。
クールダウンとよく似た機能にウォームアップというのがあります。クールダウンよりもウォームアップの方が性能がいいということが言えます。クールダウンが設定されていると、何が何でもその期間中はスケールイン/アウトされなくなるが、ウォームアップは少し賢くて、スケールイン/アウトが絶対に必要な場合は、期間中であっても、スケールイン/アウトを強行するようになっています。ただし、だからといって、無駄なスケールイン/アウトはしないような仕組みにはなっています。
同期設計と非同期設計
EC2からRDSに直接書き込みを行うような設計を同期設計といいます。EC2でからでなくLambdaを使って、SQSキューを経由してRDSに書き込むといった設計は非同期設計になります。
同期設計と非同期設計をハイブリッドで導入して、アクセス件数に応じて切り替えるようなやり方もあります。このことをオフロード戦略といいます。
SQSを利用して非同期設計をしている場合で、EC2のスケールイン/アウトの判断を、SQSキューの負荷状況によって判断させたい場合はちょっと複雑なことをしなくてはいけなくなります。CloudWatchの標準のメトリクスには判断する材料がないため、Lambda関数を使って、判断となる材料をCloudWatchに書き込む必要が出てきます。そして、書き込んだCloudWatchのメトリクスを拾って、スケールイン/アウトさせるといったやり方になります。
ライフサイクルフック
ライフサイクルフックとは、スケールイン/アウトするときに、直前に何らかの処理を実行させる機能のことをいいます。実際の使い方としては、スケールアウトされて、EC2が構築された後、新しいアプリをデプロイさせて、デプロイが完了したことを確認した後に、InServiceの状態にするといった使い方をします。
スケールインするときは、EC2にあるデータを退避させて、退避処理が完了した後に始めて、スケールインをさせるといった使い方をします。
ライフサイクルフックが実行される時間はハートビートで設定します。ハートビートとは、言い換えれば待機時間のことで、ライフサイクルフックが完了する時間よりも、やや多い時間を設定しておくことになります。
CPUバーストパフォーマンス
EC2でT（汎用）のインスタンスファミリーを選択したときに、CPUの機能で、CPUバーストパフォーマンスという機能を使うことができます。CPUを使っていて、通常は使用率が100%になれば、それ以上は使うことができないが、100%以上になっても使えるようになるといった機能です。CPUの使用率が100%以下のときは、余剰の使用分がCPUクレジットという形で蓄積されていきます。そして、使用率が100%以上になったときに、CPUクレジットから消費していくといった使い方となります。
MTU
EC2の設定でMTUの値を変更することができます。
インターネットを利用する場合は、通常、MTUはデフォルト値の1500で利用するが、Direct Connectを利用する場合は、ジャンボフレームといって、MTU値を9001に拡張させて使うことができます。当然、ジャンボフレームを使った方が多くの高速にデータを転送することができます。
OACとカスタムヘッダー
CloudFrontを導入しているのに、CloudFrontを経由しないで、直接オリジンをみに行ってしまうことがないようにすることができます。OACはCloudFrontを経由した場合にパケットになんらかのデータに付加して、データが付加されていないパケットはオリジンとなるS3側で受け付けないようにする仕組みになります。
オリジンがALBの場合は、カスタムヘッダーという仕組みを取っています。カスタムヘッダーは、HTTPヘッダーにカスタムヘッダーを書き込みを行います。
Cloud Adoption Readiness Tool
オンプレからAWSにインフラを移行するときに、推奨される内容についてレポートを出力してくれるサービスです。
オンプレの現状のシステム関する情報を取得するサービスがApplication Discovery Serviceです。Application Discovery Serviceで収集されたデータはKinesis Data Firehoseを使って、S3に送信されて、
AthenaでSQLを使った分析ができるようになります。
Snowファミリー
オンプレのデータをAWSに移動する場合、回線が充分に太い場合はDataSyncを使って移動することができるが、移動するデータ量と比べて細い回線しかない場合は、Snowを使って物理的にデータを移動することになります。Snowの移動先はS3一択となります。EFSへ直接移動することはできません。
Snowball Edgeには３種類あります。デバイスの中で処理を行わない場合は、Storage Optimizedを選択します。最大容量は80TBです。100TBありますが、実際に利用できる領域は80TBまでなのが注意点です。
デバイスの中で処理を行う場合は、Compute OptimizedかCompute Optimized with GPUになります。中にEC2インスタンスが起動しています。デバイスというか、サーバー機器そのものといった方がいいでしょう。GPUを搭載しているかCPUかの違いだけです。推論処理をしたい場合はGPUの方を選びます。エクサバイト単位のデータを転送する場合はSnowmobileになります。モバイルではありませんモービルです。
DataSync
オンプレのデータを回線を使って転送するツール。転送先はS3だけでなく、EFSへの転送もできる。オンプレにDataSyncエージェントをインストールする必要がある。オンプレとAWS間の転送だけでなく、AWS間のデータ転送にも使われる。インフラはインターネットだけでなく、Direct Connectでも利用できる。
Glue
S3のデータをカタログ形式に変換うする。データカタログという。Glueのようなツールのことを一般的にETLサービスというカタログ化はETLジョブによっておこなわれる。
Athena
S3のデータをSQLで分析できるようにするツール。Athenaで分析した結果をQuickSightというAWSのBIツールを使って可視化することができる。
ECS
EC2にDockerを構築する方法もあるが、管理コストを安くするのであれば、ECSかEKSを導入した方がいいことになる。
Local Zones
既存のリージョンのように使えます。例えば台湾に台北リージョンがあるが、これが東京リージョンのLocal Zonesとして利用することができます。東京と台北と距離が離れているにも関わらず、台北Local Zonesは東京リージョンのAZのよう使うことができます。東京リージョンに作成したVPCの中に台北Local Zonesを含めてVPCを構成することができます。ただしサブネットは分かれます。台湾から東京リージョンにアクセスする場合、台北Local Zonesを見に行った方が低レイテンシーを実現することができます。
Wavelength
インターネットを使うのではく、KDDIが持っている5Gのモバイル用の閉鎖ネットワークに接続するサービスです。
Direct Connect
Direct Connectには２つの接続方法があります。それは専用接続とホスト接続です。
専用接続は恐らくアマゾンが運用している専用回線網のことで、ホスト接続は任意のベンダーが持っている専用回線網を利用することっぽいです。専用接続は1Gbps～100Gbpsと高速な回線を利用することができるが、ホスト接続では50Mbps～500Mbpsとそれ程高速ではありません。アマゾンからしてみれば専用接続を推奨していることの見せつけなのだろうか。
Direct Connectのバックアップ回線にDirect Connectを利用することもできるが、コストを最優先したい場合はインターネットVPNを利用することになります。インターネットVPNの場合、早くても1Gbpsであるため、Direct Connectで1Gbps以上を使っている場合は、インターネットVPNになると運用が耐えられなくなることが想定されるため、推奨されていないようます。
ちなみに、Direct ConnectでもインターネットVPNでもAWS側に設定する仮想プライベートゲートウェイは同じものが利用されます。
仮想インターフェイス
Direct Connectを導入する場合、オンプレ側にはカスタマーゲートウェイを設置し、AWS側には仮想プライベートゲートウェイを設置します。
Direct ConnectはAWSからオンプレに直接接続されるわけではなく、DXロケーションを経由して接続されることになります。DXロケーションとオンプレとの間の接続が本当の専用線で、DXロケーションとAWSの仮想プライベートゲートウェイの間はまだAWS内部の接続となります。ここの接続は専用線ではなく、AWS内部のVLANで構成されます。ここの接続のことを仮想インターフェイス（VIF）といいます。
インターフェイスをいうくらいなのでNICのようなものがイメージされがちですが、物理的にイメージすれば、LANケーブルが張られるといったイメージになりそうです。
DXロケーションとAWSの仮想プライベートゲートウェイが同じリージョンにある場合は、プライベート仮想インターフェイスを張ることになります。
異なるリージョンになる場合は、Direct Connect Gateway経由でDXロケーションとAWSの仮想プライベートゲートウェイを接続することになります。
どのような場合に別リージョンでの接続にするのかは分かりませんが、専用線のランニングコストを抑えるために、極力オンプレの場所に近いところのリージョンにあるDXロケーションまでは内部LANで接続しにいこうという魂胆なのだろうと想定されます。
Direct Connect Gatewayは、オンプレに接続するAWSの仮想プライベートゲートウェイが複数リージョンある場合、接続をまとめるハブのようなものだとイメージされます。
AWSの仮想プライベートゲートウェイの先がVPC内のEC2である場合は、プライベート仮想インターフェイスを利用するが、AWSの仮想プライベートゲートウェイの先がS3やDynamoDBのように外部から直接続できるようなサービスの場合は、パブリック仮想インターフェイスを使って接続します。恐らくインターネット経由と思われます。
VPCピア接続
異なる２つのVPC（当然ネットワークアドレスも異なる）を接続することをVPCピア接続といいます。そのままではありますが。VPC-AとVPC-Bとがあり、VPC-AがVPC-Bに接続させてとなった場合、VPC-Aのことをリクエスタといい、VPC-Bのことをアクセプタといいます。アクセプタが承諾することで、晴れてVPC-AはVPC-Bに接続ができるようになります。
VPCピア接続ができたら、実際にアクセスができるようにVPCの内部にあるサブネットのルートテーブルにサブネット内部から別VPCに接続ができるようにするルートを追加する必要があります。VPCピア接続をすれば自動でルートテーブルが追加されるようなことはないので、手動でメンテしないといけないことになります。ピア接続は各部門ごとにVPCを持っていて、双方接続したいような場合に使われると想定されます。
Transit Gateway
複数のVPCを接続したい場合は、ピア接続ではなくTransit Gatewayが利用されます。Transit Gatewayはルータのようなものだと想定されます。
Transit GatewayはVPCどうしの接続だけでなく、Direct Connect経由でオンプレに接続するようなネットワークも繋げることができます。また、AWSとオンプレとの接続は、Direct Connect経由ではなく、インターネットVPN経由で接続する場合でもTransit Gatewayに接続することができます。
Transit GatewayにDirect Connectを接続する場合は、Transit Gatewayに直接続する場合と、間に、Direct Connectトランジット仮想インターフェイスを経由して接続するような場合とがあるようです。どういう違いがあるのかは分かっていません。
Transit Gatewayで接続されているネットワークを視覚化して監視したい場合は、Transit Gateway Network Mangerを導入します。
Transit Gatewayのピアリング接続
Transit Gatewayどうしをピアで接続することができます。異なるリージョンにあるTransit Gatewayどうしをピアで接続することができます。本店と支店にあるVPCどうしを接続するようなイメージです。本社にあるTransit Gatewayに支店のTransit Gatewayを接続したい場合、支店のTransit Gatewayがリクエスタで本社の支店のTransit Gatewayがアクセプタとなります。
Route53
インターネットでグローバルに名前解決を行いたい場合は、ホストゾーンを作成します。あくまでも、内輪VPCのネットワークだけで名前解決を行いたい場合は、プライベートホストゾーンを作成します。
Route53リゾルバ
オンプレとAWSが接続されていて、オンプレ側に設置されたDNSサーバーからAWS側に設置されたRoute53に問い合わせをすることができます。
オンプレのDNSからの問い合わせを受けるには、Route53でインバウンドエンドポイントを設定することになります。逆にAWS側にあるRoute53からオンプレのDNSサーバーに問い合わせを行う場合は、アウトバンドエンドポイントを設置することになります。
オンプレ側のネットワークでAWS側にあるノードへの名前解決が発生した場合は、まずは、オンプレ側にあるDNSサーバーに問い合わせをします。当然、そこでは解決できないため、次にAWS側のRoute53に問い合わせするという流れになります。このときのRoute53のゲートウェイがインバウンドエンドポイントということになります。
ちなみにDNSには権威DNSサーバとDNSリゾルバの２種類があります。権威DNSサーバはドメインとIPアドレスの情報を持っており、DNSリゾルバが権威DNSサーバに問い合わせをします。DNSリゾルバはキャッシュを持っており、基本的にいちいち問い合わせにいくようなことはしません。
クロスアカウントアクセス
AアカウントのユーザーがBアカウントのリソースにアクセスする場合、Bアカウントで新規にユーザーを作るのではなく、クロスアカウントアクセスを使って、Aアカウントのユーザーでも使えるようにします。
クロスアカウントアクセスを実現するには、Bアカウントでロールを作成して、そのロールをAアカウントのユーザーにアタッチします。このことをスイッチロールといいます。
クロスアカウントアクセスの認証はSTSで行います。また、接続はARNを指定して接続します。クロスアカウントアクセスでスイッチロールが使えるようにするのはAssumeRoleがやっています。
クロスアカウントアクセスはAWSどうしだけでなく、オンプレのアプリからもできます。その場合は、アプリにSDKで作成したコードを埋め込むことになります。このことをカスタムIDブローカーアプリケーションといいます。
AD Connector
オンプレとAWSとが接続されている環境で、オンプレ側で稼働しているADを使って、AWSのユーザーも認証したい場合に利用されるのがAD Connectorです。
Simple AD / Management Microsoft AD
AWSでアカウントをADで管理したい場合に使われるのが、Simple AD / Management Microsoft ADです。
Simple ADはManagement Microsoft ADの簡易版です。ユーザー数が5000人未満の場合は、Simple ADを導入し、5000人以上の場合は、Management Microsoft ADを導入することになります。
CodeDeploy
CodeDeployを使ってECSへのデプロイするには３つの方法があります。
Canary：２回に分けてデプロイします。１回目は10%だけデプロイした後、２回目に９０％デプロイするします。
Linear：Canaryが２回に分けるのに対し、何回でも細分化させてデプロイできます。
AllAtOnce：戦略がなく一気にすべてのプログラムをデプロイします。
EC2インスタンスへのデプロイの仕方には３種類あります。
AllAtOnce：戦略がなく一気にすべてのプログラムをすべてのインスタンスにデプロイします。
HalfAtATime：ホストが１台しかない場合の戦略になります。１台のホストに最初は50%デプロイし、その後残りの50%をデプロイします。
OnceAtAtime：ホストが２台以上ある場合の戦略になります。１台のホストにすべてをデプロイし、その後残りのホストすべてにデプロイします。
ルートにしかできないこと
アカウント設定の変更。アカウント設定とは、アカウント名、メールアドレス、パスワードなどです。
アクセスキーの作成。一般のIAMユーザーが請求情報にアクセスできるように許可します。
AWSにログインするときのMFA Deleteの設定。S3バケットにアクセスする際の設定です。
誰もアクセスできないS3バケットポリシーを設定してしまった場合は、ルートによって削除してもらうことになります。
ルートユーザーの検出
ルートユーザーの使用は推奨されていません。もしルートユーザーが使われた場合は２つのやり方で検出することができます。
１つ目のやり方はGuardDutyで検出するする方法です。GuardDutyで検出してEventBridgeを使ってSNSで通知させることができます。
２つ目のやり方はCloudWatchLogsで検出する方法です。CloudTrailのログをCloudWatchLogsに送信し、CloudWatchLogsで検出します。検出されればCloudWatchLogsからメールを送信することができます。このときはEventBridgeを使うのではなく、SNSトピックを利用して送信することになります。
IAM Access Analyzer
基本的に、AWSを利用する際は最小権限での運用が推奨されています。最小権限で運用されているかどうかを調べるには、IAM Access Analyzerを利用します。
例えば、インターネットの外部に接続されるサービスが立ち上がっていれば検知してくれます。検知されてEvenBridgeでSNSで通知することができます。
IAMポリシーを作成するときもやばいポリシーが作成されないか検知してくれます。また、IAMユーザー、IAMロールが実際に実行したCloudTrailsのログを分析してIAMポリシーの生成をしてくれるといったアシスタント的なこともしてくれます。
権限設定
アカウント全体に権限を設定する場合は、OUにSCP（サービスコントロールポリシー）を設定することになります。
VPCのセキュリティ
VPCのファイアウォールには２種類あります。セキュリティグループとネットワークACLです。
サブネットのインターフェイスに置かれるものがネットワークACLで、各ノードのインターフェイスに置かれるのがセキュリティグループです。セキュリティグループがステートフルであるのに対し、ネットワークACLはステートレスです。
物理的にある通常のファイアウォールはステートフルです。インバウンドのポート番号を記憶し、アウトバンドの時は来たときの道から帰っていってくれます。それに対し、ステートレスは来た道を帰り道が別々のルートになります。よって、行き帰りそれぞれ別々に設定してやらないといけないことになります。
KMS
KMSが管理するキーには大きく２種類のキーがあります。カスタマー管理キーとAWS管理キーです。
カスタマー管理キー（CMK）はユーザー自身が作成して管理も自分で行います。キーを管理するストレージ料金とリクエスト量が課金されます。ユーザー自身で作成したキーを無効にしたり削除することもできます。
AWS管理キーはAWS側で事前に用意されているキーで、管理はAWS側で行われます。キーはAWSが管理するためストレージ料金は発生しません。しかし、利用すればリクエスト量は課金されます。キーの無効化、削除はユーザーにはできません。
KMSではエンベローブ暗号化というアルゴリズムを使っています。KMSを使うとキーは１年ごとに自動でローテーションをしてくれます。キーのローテではキーマテリアルが毎年新しく生成されます。キーマテリアルをもとにしてキーが作成されます。
AWS管理キーでは１年に１回キーローテが強制的に行われるが、カスタマー管理キーの場合は、キーローテは任意で行います。カスタマー管理キーでキーローテを自動ではなく手動で行いたい場合は、キーにエイリアスを指定することになります。
System Manager Paramerter Store
キーの管理はKMSだけでなく、System Manager Paramerter Storeを使うこともできます。System Manager Paramerter Storeには無料のスタンダード版と有償のアドバンスト版とがあります。
スタンダード版はKMSキーというアルゴリズムによって暗号化されるが、アドバンス版はエンベロープ暗号化で暗号化されます。
DynamoDBの暗号化
DynamoDBの暗号化はデフォルトでは、DynamoDB側で用意されているキーを使って暗号化されます。デフォルトのキーを使うと料金は発生しません。デフォルトのキーよりも、よりセキュアに暗号化をしたい場合はKMSが使えます。KMSを使う場合、AWS管理キー、カスタマー管理キーのどちらも利用することができます。
Certificate Manager
サイトシールに対応していないため、サイトシールが欲しい場合は、サードパーティー製の証明書を利用することになります。
Shield
DDos攻撃を自動検知して、それをトリガーにしてLambda関数を流すことができます。
DDos攻撃が発生し、Shieldで検知されたアラートはCloudWatchで拾うことができます。そして、CloudWatchで検知されればSNSでLambdaに向けて送信し、Lambdaを実行させるといった流れになります。
Network Firewall
AZのゲートウェイに置かれるファイアウォールです。ステートフルであるためインバウンドの情報を保持します。ネットワークACLやセキュリティグループではカバーできない部分をカバーするために設置します。
Firewall Manager
Network Firewallと混合しがちですが、Firewall Managerはファイヤーウォール機能そのものではなく、WAF、Sheldなどのセキュリティ関係のツールを一元管理するためのツールです。
RPO / RTO
RPOは直前にバックアップしたデータが何日前のものかを表します。RTOは障害が発生してサーバーが止まっていた時間を表します。
バックアップ＆リカバリー
オンプレで動かしていて、バックアップだけをS3に作成するような運用で利用されます。
復元時には、CloudFormationスタックからAWSに復元をします。オンプレからS3へのバックアップはStorage Gatewayを利用して行います。
Storage Gatewayにはファイルゲートウェイとボリュームゲートウェイとがあります。ファイルゲートウェイはSMB、NFSプロトコルを利用してS3に転送するが、ボリュームゲートウェイではiSCSIプロトコルを利用します。
バックアップはEBSスナップショットの形式で取得されます。保存先はどこかは分かりませんがマネージドされたS3だと思われます。
ボリュームゲートウェイには更に保存型とキャッシュ型とがあります。保存型はオンプレ側にも、AWS側と同じようにデータが増えていくが、キャッシュ型はAWS側だけでデータを保存するため、オンプレ側でデータ容量が圧迫されることはありません。
マルチリージョンのバックアップ＆リカバリー
AWS側で構成されているシステムを別のリージョンにバックアップを取ることができます。
EBSとRDSのスナップショットを作成して、クロスリージョンコピーを取ります。スナップショットはデータライフサイクルマネージャーを利用してスケジューリングをします。
RDSのスナップショットはRDSの機能を利用して取得することもできるが、各DBエンジンが持っている機能を利用して取得することもできます。
パイロットライト
マルチリージョンのバックアップ＆リカバリーとの違いは、スナップショットを取っておいて、スナップショットから復元するのではなく、クロスリージョンレプリカを本番環境と同じリージョンに作っておいて、そこから別リージョンに同じ環境を復元させるといったところになります。
RDS、S3はクロスリージョンレプリケーションを作ることができるが、DynamoDBに関してはそのような機能がないため、グローバルテーブルでて他リージョンに作成することになります。
パイロットライトはバックアップ＆リカバリーよりもRTOを短くなります。
S3でクロスリージョンレプリケーションを作成すると通常では時間がかかるが、
RTOを短くしたい場合は、S3レプリケーション・タイム・コントロール（S3 RTC）を利用すると高速にすることができまする。
S3レプリケーション・タイム・コントロールを利用してコピー漏れが発生している場合、EventBridgeで検知することができます。復元はCloudFormationのスタックを実行して復元することになります。
Elastic Disaster Recovery
パイロットライトはAWSからAWSへの復旧になるが、オンプレ環境からAWSへパイロットライトで復旧させることができます。そのときに使うツールが、Elastic Disaster Recoveryです。
Elastic Disaster Recoveryのエージェントをオンプレ側にインストールしておくと、AWS側に定期的にレプリケーションが作成されるようになります。復元はCloudFormationのスタックを実行して復元することになります。
ウォームスタンバイ
パイロットライトよりも更にRTOを短くしたい場合はウォームスタンバイになります。ウォームスタンバイはパイロットライトのように、障害が発生してからCloudFormationで新規に構成し出すのではなく、最小構成で始めから構成しておいておくことになります。本番環境からウォームスタンバイに切り替わったときには、Route53のヘルスチェックを利用して、ルーティング先を自動で切り替えることができます。
マルチサイトアクティブ/アクティブ
本番環境と同じ構成を別リージョンに２つ構成しておくことになります。
Global Accelerator
マルチサイトアクティブ/アクティブ構成で本番環境がダウンしても、Global Acceleratorは影響を受けないようになっています。Global AcceleratorがエニーキャストIPアドレスを採用しているためです。
エニーキャストIPアドレスなので、本番環境の近くにあるGlobal Acceleratorに接続してレスポンスがないと判断すれば、別のGlobal Acceleratorに接続するようになります。
RDS Proxy
EC2やLambdaからRDSに接続する場合、接続数がMAXを超えると接続ができなくなります。接続数が膨大になっても
制限なく使えるようにするのがRDS Proxyです。
RDS ProxyはAuroraでも使えるが、Auroraサーバーレスには使えないといった制限があります。
RDS Proxyを使うとSecrets Managerが必須になります。データベースへ接続するための、ユーザー名、パスワードなどの情報をSecrets Managerで管理して、Secrets Managerに問い合わせをして接続しにいくといった運用になります。また、RDSのセキュリティグループでRDS Proxyからの接続を許可するようにする必要があります。
AuroraサーバーレスではRDS Proxyは使えないが、同じようなことを実現したい場合は、Aurora Data APIを使うと実現できます。Aurora Data APIを使う場合でも、Secrets Managerの使用は必須になります。
EC2をステートレスにする
障害に対して復旧を早くするにはEC2にデータを保存しないようにする必要があります。つまり、EC2をステートレスにする必要があります。
保存するデータはEC2ではなくS3に保存することになります。S3に保存するようにするには、SDKを使ってアプリをカスタマイズする必要があります。アプリがカスタマイズできない場合は、EFSを使うことになります。
ログファイルはEC2にCloudWatchエージェントをインストールして、CloudWatch Logsに出力することができるため、ログをEC2で保管しないようにできます。
障害が発生してEC2を削除する場合は、Auto Scalingを使うことで自動で削除が行えます。
SQSに基づくスケジューリング
SQSを使って非同期処理を行っている場合、スケジューリングする基準をSQSのメッセージ数にすることができます。SQSのメッセージ数と現在立ち上がっているEC2のインスタンス数から考慮してスケジューリングするかどうかを決めることになります。
SQSのメッセージ数はSQSから直接取得することができます。そしてインスタンス数はAutoScalingグループから取得することになります。取得した２つの情報をCloudWatchに送信します。CloudWatchへの送信はPutMetricDataAPIを使って送信します。このような処理をLambdaを使って実装します。
CloudWatchをポーリングして、EC2インスタンスの数に比べてSQSメッセージ数が多すぎると判断された場合は、自動でAutoScalingが走るといったことになります。
ファンアウト
非同期でSQSを使っている環境で、トラフィックが大量にきた場合、SQSキューを並列で送信することができます。SQSキューにトラフィックを振り分ける役割をするのが、SNSトピックです。SNSトピックでSQSキューの優先度を決めることができます。
サブスクリプションに優先度を設定して、サブスクリプションフィルターによってSQSの振り分けを行うことになります。
ライフサイクルフック
スケールアウトするときに、EC2にアプリのデプロイを行い、デプロイが完了したことを確認してからInServiceにする場合、ライフサイクルフックを利用してInServiceするまでの時間を延ばすことができます。
また、スケールインするときに、EC2のデータを退避させて、処理が完了した後に、Terminatingにさせるときもライフサイクルフックを利用します。
待機時間はハートビートタイムアウトによって設定します。ハートビートタイムアウトを60秒にした場合、60秒間待機してくれます。