AWS入門 Q&A補足資料

AWSが得意なこと

• スケーリング — アクセス増に合わせてサーバーを自動で増減できる
• グローバル展開 — 世界中のリージョンにワンクリックで展開
• マネージドサービス — DB・監視・セキュリティなど運用をAWSに任せられる
• 従量課金 — 使った分だけ。小さく始めて大きく育てられる
• 高い可用性 — 複数AZへの分散で障害に強い構成が作りやすい

AWSが苦手なこと

• コストの予測 — 従量課金ゆえに、使い方次第で想定外の請求になりやすい
• 学習コスト — サービスが200以上あり、選択肢が多すぎて迷う
• シンプルな用途にはオーバースペック — 小規模な静的サイトなら他の選択肢の方が楽な場合も
• ベンダーロックイン — AWS独自のサービスに依存すると他クラウドへの移行が大変

苦手な部分は「知っていれば対策できる」ものが多い。
特にコストは次の質問で詳しく解説

結論: 可能なら、設計段階から考えるべき

AWSは「使った分だけ」課金されるため、設計の選択がそのまま月額に直結する

よくある落とし穴

コストを意識した設計のポイント

1. まず「無料枠」を知る

• S3 は5GBまで無料、Lambda は月100万リクエスト無料

2. 「止められるものは止める」設計

• 開発環境は夜間・休日に自動停止（スケジューラー活用）
• 不要なリソースは即削除する習慣

3. コストアラートを設定する

• AWS Budgets で月額の上限アラートを設定
• 想定の80%で通知 → 100%で再通知、のように段階的に

社内での実践

• AWS Budgets でアカウントごとに月額上限を設定済み
• Cost Explorer で月次のコスト推移を確認している
• インスタンスタイプの選定はSREチームに相談してもらえればOK

迷ったらSREに聞いてください。
「このくらいの用途ならこのスペック」の目安を一緒に考えます

ログ収集・分析は一般的？

非常に一般的。むしろクラウド運用の基本中の基本

AWSでの代表的なログ収集パターン

ログを「見るだけ」で終わらせず、「活用する」のが現代のインフラ運用

社内での実例

CloudWatch Logs → Lambdaで分析

• アプリケーションのログをCloudWatch Logsに集約
• S3にエクスポートして長期保存
• 必要に応じてLambdaで加工・抽出

アクセスログの活用

• ALB（ロードバランサー）のアクセスログをS3に保存
• 異常なアクセスパターンの検知に活用

具体的な構成はプロジェクトによって異なるので、やりたいことがあればSREに相談を

ログ活用の難易度

• 入門〜初級は 今日の研修内容で対応可能
• 中級以上はSREチームと一緒に設計するのがおすすめ

まずはCloudWatch Logsでログを見ることから始めよう