【使い捨て可能なリソースの役割（設計のベストプラクティス）】
目次
🔍 1. 結論
💎 一言でいうと リソースを固定の「ペット」ではなく、いつでも交換可能な「家畜（使い捨て）」として扱う設計原理です。「障害が起きたら直す」のではなく「捨てて新しく作り直す」 アプローチにより、耐障害性とスケーラビリティを劇的に向上させます。
- ゴールデンAMI や EC2ユーザーデータ を活用し、起動時に自動設定させる
- 状態を持たない ステートレス設計 が必須
- イミュータブルインフラストラクチャ（変更不可なインフラ）の概念に直結
📈 2. SAAで出やすいポイント
- トラブルシューティングの手法: 障害が発生したEC2インスタンスにSSHでログインして修理するのではなく、インスタンスを終了（Terminate）し、Auto Scalingに新しいものを立ち上げさせる のが正解。
- 迅速なスケーリング: アプリケーションや設定がすべて組み込まれた 「ゴールデンAMI」 を事前作成しておくことで、スケールアウト時の起動時間を短縮する。
- 動的設定: EC2 User Data（起動時スクリプト）を利用して、起動時に最新のソースコードや設定を反映させる（ブートストラップ）。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| 🔄 「障害時の復旧を迅速に」 | インスタンスを終了し、新しく起動 |
| ⏱️ 「起動時間を短縮したい」 | ゴールデンAMI (事前構成済みAMI) |
| 📜 「起動時に設定を反映したい」 | EC2 User Data (ブートストラップ) |
| 🚫 「サーバー内のデータが消えて困る」 | ステートレス設計 (データはEFSやS3へ) |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「SSHでログインして修復する」 → アンチパターン。AWSでは「異常があれば破棄」が正解。 – 「EC2の中にログやセッションを保存する」 → インスタンスが使い捨てになるためデータが消滅する。ログは CloudWatch Logs へ、セッションは DynamoDB/ElastiCache へ逃がす。
💡 5. 覚え方
🧠 暗記ショートカット – ペット vs 家畜（サーバーの扱い方） – ペット: 名前を付け、病気（障害）になったら看病（修復）する。（オンプレミス的） – 家畜: 番号で管理し、病気になったら処分して新しく補充する。（クラウド的＝使い捨てリソース） – 「直すな、壊して作り直せ」 と覚える。
📚 6. 関連サービス
| アイコン | サービス名 | 役割 |
|---|---|---|
| 💿 | Amazon EC2 (AMI) | 再利用可能なサーバーテンプレート（ゴールデンAMI） |
| 📈 | Auto Scaling | 異常なインスタンスを自動終了し、新しく補充 |
| ☁️ | AWS CloudFormation | インフラ全体を使い捨て可能なコードとして管理 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: Auto ScalingやAMIのライフサイクルを学ぶ際
- 関連ノート候補:
AWS_SAA_Auto_Scaling,AWS_SAA_EC2_AMI,AWS_SAA_Stateless
8. HTMLファイル名:
AWS_設計原理_使い捨てリソース.html
