変更要約: in-scope サービス網羅: 機械学習(SageMaker AI/Comprehend/Kendra/Polly/Rekognition/Textract/Transcribe/Translate)・ストレージ(FSx/Storage Gateway)・メディア(Elastic Transcoder/Kinesis Video Streams)・フロントエンド/API(API Gateway/Amplify/Device Farm)・分析(Kinesis Data Streams/Data Firehose/MSK/Glue/Lake Formation/Athena/EMR/OpenSearch/QuickSight/Data Exchange)・追加DB(Aurora Serverless/DocumentDB/Keyspaces)を各節に追加
3.1コンピュートとストレージの選択
ワークロードに応じたコンピュート（EC2 のインスタンスタイプ・Lambda のサーバーレス）とストレージ（EBS・EFS・S3）の選択を理解します。
高性能な設計の鍵は、ワークロードに最適なリソースを選ぶことです。常時稼働なら EC2、イベント駆動/スパイクなら Lambda、データの形に応じて EBS/EFS/S3 を使い分けます。
3.1.1コンピュートとストレージ
- EC2：仮想サーバー。用途別のインスタンスタイプ（汎用/コンピュート最適化/メモリ最適化/GPU 等）を選ぶ。常時稼働・細かい制御が要る処理向き。
- Lambda：サーバーレスでイベント駆動。スパイクや断続的な処理に向き、使った分だけ課金・自動スケール。
- コンテナ（ECS/EKS/Fargate）：コンテナ化アプリの実行。Fargate はサーバーレスでコンテナを動かす。
- ストレージ：EBS（1 台に接続するブロック）／EFS（複数から共有するファイル NFS）／S3（高耐久のオブジェクト・静的/バックアップ）／インスタンスストア（一時・揮発）。
高性能な設計の出発点は「ワークロードに最適なリソースを選ぶ」ことです。コンピュートは、予測可能で常時稼働・OS レベルの制御が要るなら EC2、断続的・イベント駆動で運用を最小化したいなら Lambda、コンテナを移植性高く動かすなら ECS/EKS（サーバーレスは Fargate）。ストレージは「接続形態」で選びます：1 台の EC2 に高速接続するブロック＝EBS、複数のインスタンスから同時マウントする共有ファイル＝EFS、HTTP でアクセスする高耐久なオブジェクト＝S3。EBS にはさらに汎用 SSD（gp3）・プロビジョンド IOPS SSD（io2、高 IOPS）・HDD（スループット重視）があり、性能要件で選びます。
| 要件 | 選択 |
|---|---|
| 常時稼働・OS 制御 | EC2 |
| 断続的・イベント駆動・運用最小 | Lambda（サーバーレス） |
| 1 台に接続する高速ディスク | EBS（ブロック） |
| 複数から共有するファイル | EFS（ファイル/NFS） |
| 静的ファイル・バックアップ・大容量 | S3（オブジェクト） |
シナリオ：用途で選ぶ。 常時稼働の API は EC2（または ECS/Fargate）、画像アップロード時のサムネ生成のような断続処理は Lambda。OS のディスクは EBS（gp3）、複数の Web サーバーが同じファイルを共有するなら EFS、アップロードされた画像本体や静的サイトは S3。DB のバックアップも S3。要件（接続形態・頻度・耐久性）から逆算します。
混同に注意：
①EBS（1 台に接続・ブロック）と EFS（複数で共有・ファイル）と S3（オブジェクト・HTTP）を取り違えない。
②常時稼働＝EC2／イベント駆動・スパイク＝Lambda。
③インスタンスストアは揮発性（停止で消える）——永続用途に使わない。
④EBS は同一 AZ のインスタンスに接続（AZ をまたがない）。
Q. EC2 と Lambda はどちらを使う？ 常時稼働・細かい制御は EC2、断続的・イベント駆動で運用最小化なら Lambda。Q. EBS と EFS と S3 の違いは？ EBS＝1台に接続するブロック、EFS＝複数から共有するファイル、S3＝HTTP でアクセスするオブジェクト。Q. インスタンスストアは？ 高速だが揮発性（停止で消える）一時領域。永続データには EBS/S3。
「常時稼働＝EC2」「イベント駆動/スパイク＝Lambda」「コンテナ＝ECS/EKS/Fargate」、ストレージは 「1 台＝EBS」「共有ファイル＝EFS」「オブジェクト/静的＝S3」「一時・揮発＝インスタンスストア」 の対応が頻出です。
3.1.2その他の主要 in-scope サービス（機械学習・ストレージ）
高性能なアプリでは、用途特化のマネージド AI/ML や、EC2 のディスク以外のストレージ選択肢も押さえます。学習・推論基盤の中核は Amazon SageMaker AI：機械学習モデルの構築・学習・デプロイを一気通貫で行うマネージドサービスで、自前で ML 基盤を運用したくないときに選びます。次は学習不要で API 呼び出しだけで使える学習済み AI サービスです。Amazon Comprehend はテキストから感情・キーフレーズ・エンティティを抽出する自然言語処理。Amazon Kendra は社内文書に対する自然言語の全文検索（エンタープライズ検索）。Amazon Polly はテキストを音声に変換する音声合成。Amazon Rekognition は画像・動画の物体/顔/不適切コンテンツ検出。Amazon Textract はスキャン文書から文字・表・帳票フィールドを抽出する OCR。Amazon Transcribe は音声を文字起こし（音声からテキスト）。Amazon Translate は多言語の機械翻訳。いずれも自前モデルを学習させず、定番の AI タスクを即座に組み込みたいときに選びます。
ストレージでは、EBS/EFS/S3 以外に次の 2 つが頻出です。Amazon FSx はフルマネージドの共有ファイルシステムで、Windows ファイルサーバー（SMB）や高性能計算向けの Lustre など、特定プロトコル/用途のファイル共有が要るときに選びます。AWS Storage Gateway はオンプレミスと AWS をつなぐハイブリッドストレージで、オンプレのアプリから NFS/SMB/iSCSI で見えるボリュームの実体を S3 等に置き、バックアップやデータ階層化を AWS 側へ寄せたいときに選びます。
| やりたいこと | サービス |
|---|---|
| ML モデルを構築・学習・デプロイ | Amazon SageMaker AI |
| テキストの感情/エンティティ抽出（NLP） | Amazon Comprehend |
| 社内文書の自然言語検索 | Amazon Kendra |
| テキストから音声 / 音声からテキスト | Amazon Polly / Amazon Transcribe |
| 画像/動画の解析・OCR | Amazon Rekognition / Amazon Textract |
| 多言語翻訳 | Amazon Translate |
| マネージド共有ファイル（SMB/Lustre） | Amazon FSx |
| オンプレと AWS のハイブリッドストレージ | AWS Storage Gateway |
3.1.3この節のまとめ
- コンピュート：EC2（常時/制御）／Lambda（イベント駆動/サーバーレス）／コンテナ（ECS/EKS/Fargate）
- ストレージ：EBS（1台/ブロック）／EFS（共有/ファイル）／S3（オブジェクト）／インスタンスストア（揮発）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. イベント駆動で断続的に実行され、サーバー管理が不要なコンピュートはどれですか？
Q2. 複数の EC2 から同時にマウントして共有できるストレージはどれですか？
Q3. 高い耐久性を持ち、静的ファイルやバックアップの保存に適したストレージはどれですか？