はじめに

この記事は勉強記と題していますが、個人で学習した時の特につまづいたキーワードや覚えておきたいユースケースをメモのように残しているものとなります。

前回のキーワード編に続き、今回はユースケース編です。
キーワードだけでなく、サービスをどのように使用するのが最適かを問われるので、実務などで具体的な経験がないと特に対策が必要ですね。

ということで早速みていきましょう。

AWS移行関連

種類の違うDBシステム間でデータ移行する場合はSchema Conversion Tool(SCT)が有効
- SCTはスキーマ変換のみをサポートしていて初期データの移行はしない
  - AWS側でDBを作成して、移行元DBのスキーマを移行するために利用する
オンプレミスから高速なデータ転送(S3に送るなど)にはDataSync
- DataSyncはオンプレWindowsファイルサーバーとAmazon FSxとの間でスケジュールされたデータのレプリケーションが可能
- DataSyncはDirect Connectがあるとよりデータの転送が高速になり、時間短縮を図ることができる
- オンプレからEFSへのデータ転送はDataSyncを使う(直接EFSに転送できる)
Storage Gatewayのボリュームゲートウェイ：iSCSIブロックプロトコル(ブロックレベル)
主にオンプレとS3間ではファイルゲートウェイ：SMBファイル共有
オンプレのメトリクス収集はApplication Discovery Serviceを使う
- AgentlessとAgentの2種類があり、エージェントの方がより詳細な情報を得られる
- CloudWatchでもできなくはないがメトリクス収集とパブリッシュに費用がかかる
Migration EvaluatorはAWS移行計画の最初のステップに使用する、オンプレのIT環境を評価する
アプリケーション全体の移行にはReplication Agent(Application Migration Serviceでも良い)
- データベースの移行にはDatabase Migration Service(DMS)
- DMSのデータ移行オプションの全負荷+CDCとCDCの違いについて
  - 全負荷＋CDCは既存のデータも含め、移行中に発生したデータも移行してくれる
    - 負荷＋変更データキャプチャを使用するとオンプレDBからDMSタスクを通じてRDSにデータ移行できる
- 大規模なVM移行に適しているのはVM Import/Exportではなく、Server Migration Service(SMS)
- 複数のVMを自動で同時に移行することができる
あまりにもサイズの大きいDBの移行で、十分なネットワーク帯域を持っていない時は、Snowball Edgeを使用して一旦S3におき、その後DMSで移行する
クラウド移行計画の三種の代表的サービス
既存のオンプレActive Directoryを活用するにはManged Microsoft ADではなくAD connectorを使うとコスト効率が良い

アプリケーション・EC2関連

ECSは複数アプリケーションを1つのEC2インスタンスで実行するが、Beanstalkはアプリケージョンごとに1インスタンス使用する
3層ウェブアプリケーションにはアプリケーションレベルでのロードバランシングが必要なのでALBを使用する
ALBに対する直接アクセスを防止するには、CloudFrontからの管理プレフィックスリスト(IPアドレスリストのイメージ)のトラフィックのみを許可するようにセキュリティグループを変更する
ALBはパスベースルーティング(=IPアドレスとアタッチできない)、NLBは静的なIPアドレスでルーティング
- NLBではリージョン間のVPCピア接続がサポートされている
ALBはリージョンをまたいで作成できない、他のリージョンVPCを参照もできない
ALBのラウンドロビンルーティングとスティッキーセッションを有効にすると、流入トラフィックを異なるEC2インスタンスに均等に分散することができる
- (NLBにはスティッキーセッションは設定できない)
ブルー/グリーンデプロイを行いたい時はALBを使用する
API Gatewayは1sあたりの最大リクエスト数を超えると429エラーが返ってくる
API Gatewayにはデッドレターキューを直接設定できない
- SQSを2つ作成してプライマリのDLQ用に2つの目のSQS使う
Gatewayの使用時の安全性とコスト削減をするには、WAF ACLでIPを許可するようにする
WAF ACL x Gatewayは使用プランでAPIのリクエスト数や利用時間を制限することができる
- APIキーで正規の利用者のみがAPIを使用できるように制限
API GatewayのHTTP APIとREST APIの違い
- HTTP：コスト効率良し、パフォーマンス良し、利用プランとAPIキー機能がない
- REST：コストとパフォーマンスはHTTPに劣るが利用プランとAPIキー機能がある(＝ユーザーごとにリクエスト制限をかけるユースケースを満たせる)
API GatewayのHTTP APIはLambdaしか統合できない
- 対してREST APIは直接AWSサービスに統合できる(DynamaDBとか)
Gatewayのセキュリティはメソッドに認可AWS-IAMを設定すること
- CORSというものもあるが、これはブラウザのセキュリティポリシーを制御するもの
エンドツーエンドの通信を実現するにはNLB(TSリスナー)を使用する
- 暗号化トラフィックをターゲットに転送できる
Lambda並列実行制限エラーを防ぐ方法：SQSを導入→S3からLambdaへの大量のリクエストをバッファリングできる
FargateにはEFSしかアタッチできない
DockerイメージはS3ではなくECRに保存する
EC2 Savings PlansはEC2だけだが、Compute Savings Plansは EC2、Lambda、Fargateに適用することができる
- EC2にはEC2インスタンス Savings Plansと Compute Savings Plansどちらも適用できるが、EC2の利用傾向が予測できる場合はEC2インスタンスSavings Plansを使う→割引率がより高いため
Auto Scaling Groupのライフサイクルフック
- CONTINUEは特に何もせず続行
- ABANDONは特定のアクションを待つ
  - そのためASGのインスタンス終了を妨げてしまう(同期処理には向いている)
Auto Scaling GroupのTerminateプロセスを一時停止するとUnhealthyになったEC2が即終了されないようになる
- SSHやSession Managerでログインして調査ができるようになる
- EC2の終了保護を有効にしても即終了を防ぐことはできない
EFSはLinuxベース、FSx for Windows File ServerはWindowsベース
FSx for Windows File Serverのストレージタイプやスループット容量は作成後に類更できない
Windows ACLを使いたいケースはFSx for Windows File Server
FSx for Lustreは、一度書き込み・多数回読み出しのシナリオに最適
- 頻繁に変更されるケースには向いていない
Elastic Beanstalkには主に開発やテストで使用されるシングルインスタンス環境と複数インスタンス間で負荷分散する負荷分散環境がある
Beanstalkで管理している複数の環境間でURLを交換することができ、ダウンタイムや変更のロールバックを容易にすることができる
- Swap Environment URLsブルーグリーンデプロイという
Amplify Hosting + CloudFront→全地域にわたり高速で配信することができる
Compute OptimizerのExportLambdaFunctionRecommendationはLambdaの推奨構成メモリや推奨コストを自動的に算出してくれる
- スケジュールでレポートを出すことはできずないので、LambdaとEventbridgeの連携が必要
System ManagerのParameter Storeを使用して管理するアカウントIDとOUを一元保持
- これにより管理者が必要に応じてアカウントやOUの追加・削除ができるようになる
Systems ManagerはオンプレサーバーやEC2インスタンスなど、色々なシステムを一元管理しているが、そのうちの一つにパッチ管理がある(Systems Manager Agentも)
Parameter StoreにデータベースのIPを保存しておくことでEC2インスタンス起動時に読み込んで設定ファイルに注入することができる
JavaアプリケーションはLambdaではなく、ECSなどのオーケストレーションサービスに移行する方が適切
X-Rayはアプリケーションのパフォーマンス分析に使用される
- DBパフォーマンスのベンチマークに公開することは想定されていない(X-RAYはアプリケーションのパフォーマンス分析だけに使ってねという意味)

S3関連

同じデータに異なるリージョンからアクセスする場合のS3設定は以下が必要
- 1. Cross Region Replication(CRR)を有効にして双方向のS3クロスリージョンレプリケーションをいれる
- 1. データの一貫性を保つためのS3 Multi-Region Access Pointを入れる
- プラスアルファでバージョニングまでいれると間違った操作からデータロスを防げる
S3はインタフェースエンドポイントではなくゲートウェイエンドポインドが使用できる(VPC←→S3)
- S3アクセスポイントはバケットを所有するアカウントで作成が必要
S3 ACLはデータのアクセス制御なので、暗号化に関係なし
- 転送中と静止時に暗号化するには
- 1. S3のサーバー側暗号化をオン
- 1. S3のバケットポリシーで、暗号化されていない操作を拒否
- 1. CloudFrontでHTTPをHTTPSにリダイレクトする
S3 Storage Lensは使用状況分析を行うことができ、デフォルトでダッシュボードを持ち、全リージョンを一元化して追跡できる
S3 Batch Operationsは大量のS3オブジェクトに対する操作を簡単に管理することができる
- オブジェクトをコピーして暗号化するなどに使用
Transfer Familyを使うとFTPを通じてS3にファイルを直接アップロードできる(スケーラブル)
KMS, SSE-S3,SSE-Cの特徴
- KMS：マネージドだが、サーバーサイドで暗号化する際にコストが発生する
- SSE-S3：S3がキーを管理する、KMSよりコストは低い
- SSE-C：ユーザー管理、管理の負荷が発生する
S3のアップロードパフォーマンスを向上させるにはTransfer Acceleration x マルチパートアップロードを使う
S3ではカスタマーマネージドキーによるAES-256はサポートされていない
S3サーバーアクセスロギングは無料で利用できる
Access Analyzer for S3はS3のACLとバケットポリシーの監視、公開バケットの識別

RDS関連

DynamoDBグローバルテーブルを活用するにはDynamoDB Streamsが必要
Lambda x SQSのアプローチは労力がかかる(DynamoDBオートスケーリングの方が楽)
DynamoDBの書き込みパフォーマンスを向上させたい時にはWCUを設定することで大量のデータ書き込みを処理することが可能
DynamoDB オンデマンドキャパシティモードは負荷の変動により読み取り・書き取りをスケーリングしてくれる
- ただし、一定の負荷が存在する場合はコストが高くなる可能性がある(対策は予約済み(プロビジョンドモード)を使用する)
ゲームなどのセッションデータに関してはDynamoDBが適している
DAX (DynamoDB Accelerator)は読み取りパフォーマンスを向上させるためのもの
- DynamoDB Accelerator(DAX)には少なくとも3つノードが必要
Aurora MySQL グローバルデータベース：RPOやRTOなどの要件を満たすために使う
Aurora Auto Scalingはライターではなくレプリカに適用するのが適切
RDS for SQL Serverはライセンスコストがかかる
- しかしAurora PostgreSQL with BabelfishはSQL Server互換を持ちつつ、ライセンスコストはかからない
RDS proxyを使用するとフェールオーバーやスケーリングされた後でも、アプリケーションとDBの接続を自動で再確立してくれる

ネットワーク関連

異なるIPアドレスから攻撃されている(DDos)場合はShield Advancedを使う
ゲートウェイVPCエンドポイントはS3とDynanoDBに対応している
- プライベートサブネットから直接アクセスできる
- 対してインターフェイスVPCエンドポイントは他のAWSサービスやVPC内の所有しているアプリケーションに接続できる
CloudFrontは特定のIPレンジを持っているので、マネージドプレフィックスリストを使用することで特定のトラフィックのみを許可できる
- CloudFrontにはセキュリティグループをアタッチできない
CloudFrontのLambda@Edge関数でエッジロケーションのリダイレクションルールが管理できる
レスポンスヘッダーの操作→特に削除できるのはCloudFront関数のみ(Lamba@Edgeと別)
CloudFrontはフィールドレベルで暗号化が可能(公開鍵と秘密鍵)
- ディストリビューションに公開鍵をアップロードすると特定のマイクロサービスが秘密鍵を保持し、その鍵だけで復号化できるようになる
- ※KMSで生成した対象鍵は、公開鍵暗号化方式と互換性がないのでフィールドレベルの暗号化に使用できない
Global AcceleratorはIPアドレスがー貫している
- Global AcceleratorはS3バケットに直接エンドポイントを設定できない
CloudFrontはダウンロードを高速化するためにも使用される
インターネント接続したくない時
- DynamoDBとLambdaはゲートウェイVPCエンドポイント
- NeptuneとLambdaはVPC内のプライベートサブネットに配置
TransitゲートウェイとVPCの接続自動化
1. 中央アカウントでTransitゲートウェイ作成&RAMでリソース特有
2. CloudFormation StackSetsでVPC作成&Transitゲートウェイに紐づけ
Transitゲートウェイは複数のVPCやVPN接続を中心に管理できる
- ハブアンドスポーク向け
TransitゲートウェイはVPCやオンプレと接続できるのであって、Direct Connectには接続できない
VPCを複数持つ場合は、直接Direct ConnectとつながずにTransitゲートウェイに集約
- また、VPCを複数持っている時もVPCピアリングではなくTransitゲートウェイを使用する
- ただし、各VPC同士で設定がいる
複数のNATゲートウェイに同じElasticIPアドレスを割り当てることはできない
NATのデータ転送料を削減したい場合は、VPCエンドポイントの利用が有効
できるだけ環境ごとにVPCは作成しないようにする、VPCが増えると管理が大変になるため
Direct Connect, VPCピアリング, Site-to-Site VPNの特徴
- Direct Connect：オンプレとAWSの間を専用回線でプライベート接続する
  - Direct Connectゲートウェイ同士をピア接続はできない
- 代わりにTransitゲートウェイをピア接続するようにする
- VPCピアリング：複数のVPC間のルーティングを行う、Direct Connectに比べてスループットは低下する
  - VPCピアリングを利用する時は同じCIDR範囲を持つVPC間では利用できない
  - VPCピアリングでは重複しないアドレス範囲を使用しなければいけない、またピアセプターのIAMロールも必要
  - VPCピアリングは同ーリージョン内の接続には有効だが、リージョンをまたがる場合には使用できない
  - VPCピアリングを使用しても、ALBは1つのVPCでしか動作しないので、ピアリングしたVPC間ではロードバランシングはできない
  - VPCピアリングとDirect Connectは接続できない
- Site-to-Site VPN：オンプレとVPC間接続、一般的にはDirect Connectが推奨される
  - Site-to-Site VPNはDirect Connectよりもコストが安い
    - ただし、要件としてネットワーク速度が重視される場合は選択できない
  - Site-to-Site VPNはインターネットを一部経由する
    - 全くインターネットを経由しないためにはDirect ConnectとDirect Connectゲートウェイをの組み合わせを使用する
パブリックVIFを使用すると、パブリックAWSサービスと他のリージョンのVPCにSite-to-Site VPNすることができる
プライベートVIFは複数のVPCに対して使用できない
- クロスリージョンのケースはトランジットVIFを使用する
VPNは帯域幅を保障しない、VPCピアリングはアウトバウンドトラフィックのコストが発生する
Azure ADとAWS Managed Microsoft ADは異なるもの
Network Firewallを使用すればネットワークトラフィックの監視ができる
- また、エンドポイントを作成してデフォルトルートをエンドポイントすると強制的にNetwork Firewallを通るようになる
- 高速なトラフィックにも適している(25Gbpsはいける)
Route 53の位置情報ルーティングはあくまで地理的な場所に基づいてルーティングする
- つまり接続速度やパフォーマンスには関係ない
  - 上記を気にするのであればレイテンシーベースのルーティングを使う

バックアップ系

RTOやRPOが厳しい条件の場合は別リージョンに同じ構成を用意する(リードレプリカとか)
- アクティブーパッシブ構成という
- 比較的条件が緩い場合はバックアップ→復元で対応するイメージ
アクティブパッシブ構成を構成すると、自動でフェールオーバーする(Route 53のフェールオーバールーティングポリシーが該当)
動的なアプリケーションのフェールオーバーにはRoute 53が適している
Grobal AcceleratorとNLBをリンクすると各リージョンに分散化した高可用と冗長性を提供できる
- 自動フェールオーバーも実現
- ※ CloudFrontのエッジロケーションのIPアドレスは変動する
- Route 53のフェールオーバールティングとまで書いてあればこちらでも実現できる
  - CloudFrontで管理する場合はオリジングループのプライマリ・セカンダリで行う
  - ※ディストリビューションをAレコードに登録することはできない
EBSボリュームで既存のものは暗号化できないので、スナップショットを作成してから暗号化が必要
DLMは追加のリージョンへのスナップショットコピーのポリシーも設定可能(=別リージョンにコピー)
RTOとRPOを低減するための策として、DBではAuroraグローバルデータベースを使用する
- 異なるリージョンでの書き込み・読み込みが可能
- セカンダリリージョンのデータベースをプライマリに昇格させる機能もある
CloudFrontのオリジングループ機能を使うと複数のオリジンからコンテンツを取得するようになり、さらにオリジンフェールオーバーを設定すると、一方のオリジンがダウンした時でももう一方のオリジンからコンテンツを取得できるようになる
CloudFrontはカスタムエラーページを設定するとエラー応答が主じた際に特定のページを返せる
- 最終的に一般にアクセス可能なWebページを指すようにDNSレコードを修正する必要がある
- もう一つの実現方法はプライマリオリジンにALB、セカンダリオリジンにS3を設定して、CloudFront ディストリビューションのオリジンフェールオーバーを設定する方法もある
Backupの対象はAWS環境内のRDSやEFSなど(オンプルのファイルなどは送れない)
全体的にダウンタイムを最小にするには既存のリソースは消さない
BackupはEC2やその付随するEBSボリュームのバックアップとリストアを自動化してくれる
- →セカンダリリージョンにバックアップしたいときに有効、イメージとしてはEC2インスタンス全体のバックアップを作成するイメージ
- 対してData Lifecycle Manger(DLM)はEBSボリュームのバックアップしか作成しない
  - ※EFSやRDSのバックアップは行わない
オンプレミスのホスト名を解決するには、Route 53リゾルバを用いてオンプレのネームサーバーにリクエストを転送する必要がある
EKSのワークロードに対する回復力を最大化するには、AZに基づくトポロジースプレッド制約を使用する

データストリーム、リアルタイム関連

Data Streamはシャード数を手動で調整する必要があり管理が大変
- Firehoseはデータのスループットに合わせて自動でスケーリング
非構造化データに対して簡単に照会や分析を行うには、Glue Data Catalogと Athenaが適している
ElastiCache for Redisはオートスケーリング機能なし、Multi-AZを使う
- 障害に対する策はMulti-AZや別リージョンに構成をもつこと
ElastiCacheクラスターの転送時の暗号化を有効にする際はダウンタイムが発生しない
- また、AUTHトークンでユーザー認証を要求することができる
OpenSearchサービスでUltraWarmノードを使用すると運用コストの削減ができるが、すべて置き換えてしまうとデータノードがなくなり処理が遅くなるので注意
Gateway Load Balancer：リアルタイムのトラフィック検査ができる、ファイアウォールなどのセキュリティアプライアンスをデプロイさせるなどが主な用途
Data Exchange：データの発行・購読・使用を簡単に行うことができる
- Redshiftと直接接続が可能
Redshiftはデータウェアハウスサービスのため運用上のオーバーヘッドが増える可能性がある
- 対してAthenaはS3バケット内のデータに直接SQLを実行できるなどシンプルで管理の必要がない
- Redshiftはビッグデータかつ固定のスキーマが必要(NoSQLではない)
Redshiftの同時実行スケーリング機能は、予期しないバーストに対応ができる
- 無制限に読み取り・書き込みのクエリを処理することが可能
Redshift(データウェアハウス)は、起動時間で従量課金
- Athena(S3を直接分析)は実行したクエリ時間のみに課金がされる
Kinesis Data FirehoseとKinesis Data Streamsでは、高度なデータ処理や分析が求められる場合はData Streamが適している
Kinesis Data StreamsはFirenoseに比べて、分析処理をリアルタイムにできるためセンサーデータなどに適している
- 逆にFirehoseはランダムアクセスが可能だったり、データをS3やRedshiftに直接送ることができる
Kinesis Data StreamsはApache Kafkaの移先に適していない
- Managed Streaming for Apache Kafka(MSK)が適している
Glue Data Catalogを使用してメタデータ管理を行うとEMRクラスターを立ち上げて管理するという大変なことはせずにSQLでクエリ実行できる

IAM・Organizations関連

IAM Access Analyzerを使うとCloudTrailに記録されたアクティビティに基づき最適なIAMポリシーを自動生成してくれる
VPCやサブネット、Transitゲートウェイなどを複数のアカウントで使い回したい時はResource Access Manager(RAM)(管理アカウントのリソース共有オン)
- RAMはLambdaをサポートしていない
- 移行はデプロイパッケージをダウンロードして移行する
サービス制御ポリシー(SCP)を用いるとEC2インスタンスの作成を拒否するなど決めることが可能になる
- SCPはアカウントレベルでの制限しかできないので、特定のインスタンスタイプを禁止できない
  - EC2を起動できなくするとかは可能
  - SCPはEC2インスタンスがパブリックIPを取得するのを防止できる(新規&既存)
- SCPで特定のリージョンでのみリソースを作成する許可は設定できない
  - 拒否する設定はできる
SAMLフェデレーションはIAMユーザーではなく、IdPを通して認証される
- この時にAWS STS AssumeRoleWithSAMLAPIを時び出している
Single Sign Onを利用すると複数のAWSアカウントへのカスタムアクセス制御を管理できる
- さらにSAML2.0を使ってオンプレのActive Directoryを活用することも可能
IAMアイデンティティセンターにAD ConnectorをIDソースとして設定するとユーザー認証と権限付与のプロセスが一元化される
- ADとIAMユーザー両方を保持する必要がない
Control TowerとOrganizationsはマルチアカウント構造を一元管理させることができる
Control Towerランディングゾーンはブループリントとガードレール機能を持つ
- 本番用と開発用アカウントを異なるOUに分けることができる
Organizationsを使用して複数のAWSアカウントを管理する時に、異なる組織に移動させるには以下の2つのAPIオペレーションが最適
「Remove Account From Organization」と「Invite Account To Organization」
Cloud Towerの必須のコントロールと強く推奨されるコントロール
- 必須のコントロール
- 強く推奨されるコントロール：必須のコントロールよりも強く、暗号化されていないボリュームの検出やより高度なセキュリティ
全てのサービスへのアクセスを拒否するには、Full AWS Access SCPを削除する
- 特定のサービスに対するアクセスを制限するには、拒否リスト戦略に基づいて権限の制限を行う
RI共有の設定をオフにするには組織の管理アカウントから行う
Budgetsはコスト予算だけでなく、サービスの利用状況を追跡することができる
- 例えば、EC2使用率が予定以上になった時など
- 管理アカウントでBudgetsを用いると全体の支出状況を一元管理できる
  - 各アラートのSNSトピックに各ビジネスユニットを追加することで、それぞれに通知を送ることができる
Organizationsの管理アカウントでは全てのアカウントのコストと使用状況に関するCost and Usage Report(CUR)が作成できる
IAMロールを引き受けるにはリソースペースのポリシーではなく、アクセス許可のIDベースのポリシーと信頼ポリシーが必要になる
部門ごとにタグ管理、一括更新などを行いたい場合はTag Editorを使用する
組織のAWSリソースのタグ付けを一貫にしたい場合はタグポリシー
- タグ付けの強制にはリソースポリシーやSCP
タグポリシーはすでに存在しているリソースのタグがポリシーに準拠しているかを評価する
リソースベースのポリシー(JSON式のやつ)はAWS管理キーにアタッチできない
CloudFormationのDeletionPolicy：特定のリソースを削除する時のCloudFormationの挙動を設定できる(Retainを用いることで重要なリソースは削除させない等)
Organizations + CloudFormation Stack→複数のアカウントでインフラのデプロイが容易にすることができる
Organizations + CloudFormation StackSetsの組み合わせは管理アカウントから一元的にテンプレートをデプロイすることができる
IAM policy周りの条件
- aws：Requestdリージョン→リクエストが行われたリージョンを指定
- EC2： Instance Type→EC2インスタンスのタイプを指定
一時的にOUを体成し、アカウントにポリシーを適用したあとに元々のOUに戻すことで特定のOUにのみ特定のポリシーを適用することができる

グループ分けなし

Cognitoはユーザープール内でMFAを設定することができる
サーバーレスアーキテクチャ(Lambdaとか)は運用の労力を最小限に抑えられる
LambdaレイヤーはDockerイメージをサポートしていない
WorkSpacesのMFAを有効にするには、オンプレ側にRADIUSサーバーが必要
App Stream2.0はローカルホストがWindowsでなくてもリモートデスクトップのように使える
- ユーザープールを使用するので認証プロセスが楽(Workspaceは一人一人必要)
- 複数人が同一アプリケーションにアクセスするケースに適している
Web ACLでは初期設定時にどのリクエストがブロックされるか確認するために「Count」ルールにしておくことが推奨される
WAF ACLでSQLデータベースのルールグループを使用すると、SQLインジェクションなどの特定の種類の攻撃からAPIを保護可能
- ALBに関連づけることでバックエンドサーバに到達することを防げる
- 特定の国からのアクセスを制限することも可能
ACMの証明書はエクスポートできない
EventBridgeはコードプッシュなどのイベントをトリガーにして他のサービスを動作できる
ALBのAPIパフォーマンスを向上させたい
- 標準HTTPメソッドの場合はCloudFront
- カスタムメソッドの場合はGlobal Accelerator
CloudTrailはAPIの呼び出し記録を提供
- CloudTrailのログは基本S3バケットに保存される、CloudWatch Lagsには直接保存されない
アカウントのアクティビティを監視・追跡などはCloudTrailでもできるが、変更のアラート発報やコンプラ違反の追跡はConfigとSNSの組み合わせた方が良い
- 特にコンプラ違反はCloudTrailではできない
CloudWatchはNATゲートウェイ、プライベートインスタンスのENIフローログが確認できる
- CloudWatch Logs Subscription： Logsのデータをリアルタイムで処理することができる
  - LambdaやFirehoseに連携できる
VPCフローログ：VPCによるIPトラフィックのキャプチャログ
カスタマーマネージドプレフィックスリスト：CIDRブロックのサブネットをグループ化したもの
- セキュリティグループやルートテーブルで使用する
- RAMを使用してカスタマーマネージドプレフィックスリストを組織内で共有すると、共通のIPリストを他のアカウントに共有でき、セキュリティグループの更新を効率良くできる
Apexドメイン：第2レベルドメイン(www.example.comのexample.comの部分)のことで、最上位に位置するドメイン
- このドメインのレコードにCNAMEを設定してはいけない
Lambda関数のエイリアスを使用すると、関数の特定バージョンを指す一方で実際の関数バージョンを更新してもアプリケーションの更新が不要になる
SQSはアプリケーションを疎結合にできるが、メッセージ処理が遅延するというデメリットもある
SQSはシンプルなメッセージキューのため、RabbitMQのような高度なものの移行先としては向いてない
- RabbitMQの移行先にはAmazon MQが適切
  - インスタンスを立ち上げるのでコスト、スケーリングなども必要
- MQTTはIT Coreに移行するのが適切
Cloud HSMはハードウェアセキュリティモジュールを提供、安全に鍵を管理できるがコストがかなり高い
Simple Email Service(SES)は、STARTTLSを通じてTLSコネクションすることが可能
- SESはメールテンプレートの保存が可能
- SESはStep Functionsのワークフロー失敗に対して自動的に反応して通知はしない
  - 特殊な要件でない限り、通知といったらSNSが基本
- Lambda関数を使用してSendTemplated EmailAPIオペレーションを呼び出せば、顧客データをパラメータとして渡して各顧客データに基づいたメールを送ることができる
テキストメッセージやプッシュ通知を送るサービスとしてSNSがあるが、Pinpointもある
- SNSは双方向通信やパーソナライズされたアンケートの送信には必ずしも最適ではない
Secrets Managerは秘密情報の管理・ローテーション・取得を行う
Key Management Service(KMS)は公開鍵と秘密鍵を作成及び管理する
- 認証情報の保存やローテーションは行わない
Enterprise Supportプランは高額
- Trusted Advisorは一般的な最適化の推奨をするが具体的なワークロードに適している推奨はしないため鵜呑みにしすぎないように
マネージドKMSキーはマルチリージョン化できない、カスタマーマネージドキーはマルチリージョン化ができる

イメージ図があると良かったもの

別のアカウントへのアクセス権限を付与するイメージ（Assume Roleも同じく）

上記図でアカウントAのIAMユーザーからアカウントBにあるEC2を起動したいケース

①アカウントB側でやること

アカウントBにあるEC2を起動するポリシーの作成、引き渡し
アカウントAのIAMユーザーを信頼するポリシーを作成(引き受けられる側で設定が必要)

②アカウントA側でやること

アカウントBのIAMロールを被ることを許可するポリシーを用いてアクセス
トランジットゲートウェイを使うイメージの一例
- トランジットゲートウェイを使用しないと、VPCが増えるたびにそれぞれの設定が必要なので管理が面倒
トランジットゲートウェイを使用するとVPCが増えてもトランジットゲートウェイとリンクさせるだけなので管理が楽になる

おわりに

以上、ユースケース一覧でした。
なかなかに記憶と想像を結びつけるのが難しかったと思います。
キーワード編と同じようにオンプレからAWSへの移行やバックアップの面が特に重要だと思いますので、ぜひ参考になればと思います。