はじめに
「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を持っていて、双方接続したいような場合に使われると想定されます。