AWS
IAM
AWSのリソースに対するアクセス管理を行うサービス。
簡単にいうと
・誰が（ユーザー、アプリケーション）
・何に（S3、EC2などのAWSリソース）
・どのように（読み取り、書き込み、削除など）
アクセスできるかを細かく制御する仕組み。
Route53
DNS（Domain Name System）サービスです。
特徴
・ドメイン名をIPアドレスに変換するサービス
例えば、example.com → 192.0.2.1。
・ドメインの取得・管理ができる
Route 53内でドメインの新規登録や移管も可能です。
・高可用性・高耐障害性のDNS
世界中に分散したインフラで動作しているので、非常に安定しています。
・ヘルスチェック機能がある
サーバーが正常か監視し、異常時に別のエンドポイントにトラフィックを切り替えることができます。
・トラフィックルーティングが多機能
例えば：
加重ルーティング（複数のサーバーに対して重みづけした分散ができる）
レイテンシールーティング（最も応答速度が速いリージョンに誘導）
フェイルオーバールーティング（プライマリ・セカンダリの切替）
加重ルーティング、レイテンシールーティング、フェイルオーバールーティング
主な用途
・Webサイトやアプリのドメイン解決
・可用性の高いDNSサービスを使いたい場合
・マルチリージョン・マルチサーバー構成のトラフィック制御
EFS
EC2などのAWSサービスからアクセスできる「共有ストレージ」を提供してくれるサービス
特徴
・NFS互換
NFS（Network File System）プロトコルをサポートしていて、LinuxベースのEC2などからマウントして使えます。
・スケーラブル
ストレージ容量が自動でスケールします（数GBからペタバイトクラスまで）。自分で容量を事前に確保する必要はありません。
・複数インスタンスから同時アクセス
複数のEC2インスタンスが同時に同じファイルシステムを共有して使えます。アプリケーションのクラスタ構成などに便利です。
・高可用性・耐障害性
データは自動的に複数のAZ（アベイラビリティゾーン）間で冗長化されるので、耐障害性が高いです。
ユースケース
・Webサーバークラスタの共通ストレージ
・データ分析や機械学習などでの共有データストア
・コンテンツ管理システム（CMS）
・ホームディレクトリのストレージ
CloudWatch
AWS上のリソース（EC2、RDS、Lambdaなど）や、アプリケーションのパフォーマンスをモニタリングするための仕組みを提供します。
主な機能
・メトリクス収集
CPU使用率、メモリ使用率、ディスクI/O、ネットワークトラフィックなどのシステムメトリクスを自動で収集します。また、独自アプリケーションのカスタムメトリクスも送れます。
・ログ管理（CloudWatch Logs）
アプリケーションやOS、Lambdaのログなどを集めて、検索・分析できます。S3などへの保存や他ツールとの連携も可能。
・アラーム設定
しきい値を決めて「CPU使用率が80%超えたら通知する」などのアラートを作れます。SNS（メール、Slackなど）と組み合わせて通知したり、Auto Scalingと連携して自動対処も。
・ダッシュボード
メトリクスを見やすいグラフにして、ダッシュボード上でリアルタイムに可視化できます。
・イベント検知（CloudWatch Events / EventBridge）
インフラの状態変化（EC2の起動・停止など）や、一定スケジュールのイベントをトリガーしてLambda関数を実行するなど、自動化できます。
用途
・EC2のCPUが高負荷になったときに自動でアラートが飛ぶ
・Lambda関数のログをCloudWatch Logsで確認する
・RDSのパフォーマンスを可視化する
・毎晩決まった時間にLambda関数を起動するスケジュールを組む
Fargate(ファーゲート)
コンテナをサーバーレスで実行できるサービスです。通常、ECS（Elastic Container Service）やEKS（Elastic Kubernetes Service）では、EC2インスタンスを自分で用意してクラスターを構成しますが、Fargateを使うとインフラの管理が不要になります。
特徴
・コンテナ専用のサーバーレス環境
・インフラ管理不要（EC2などの管理が不要）
・ECS/EKSのランタイムオプションとして動作
・コンテナ単位でリソース（CPU・メモリ）を指定して起動
・起動ごとに課金（秒単位課金）
インフラ管理不要（EC2などの管理が不要）とは
通常、EC2ベースでECSやEKSを使う場合は、自分で次のような「インフラ管理」をやる必要があります。
・1. クラスターのEC2インスタンス準備:
EC2インスタンスを自分で立てる（台数、サイズの選定）。
OS（Amazon Linux, Ubuntuなど）を決める。
・2. セキュリティパッチ・OSアップデート管理:
EC2のOSに対して定期的にパッチ適用。
セキュリティホールがあれば即対応。
・3. スケーリング管理:
自分でオートスケーリンググループを設計して、負荷に応じてEC2の増減を考える。
・4. コンテナエージェント/デーモン管理:
ECSのエージェント（コンテナを管理するソフト）がちゃんと動いているかを確認。
DockerエンジンやKubernetesのデーモンが壊れていないかも監視。
・5. インスタンスのモニタリング:
EC2自体のCPU、メモリ、ディスク、ネットワークなどの監視が必要。
障害が起きたら復旧対応。
・6. ネットワークのチューニング:
EC2上でのVPC設定、セキュリティグループ、IAMロールをきめ細かく設計。
・7. ログ/ストレージ管理:
インスタンス上で発生するログをCloudWatchやS3に送る設定。
EC2のディスク容量が足りなくならないように注意する。
Fargateでは？
これらのすべてが不要になります。
・EC2を立てる必要なし：Fargateが裏で自動的に必要なサーバーを確保してくれます。
・OSのメンテ不要：パッチ適用・アップデートはFargateが勝手にやります。
・スケーリングはコンテナ単位で自動：指定したコンテナ数だけを意識すればOK。
・モニタリングはタスク単位：Fargate自体のインフラはAWSが責任を持つので、自分はアプリの監視だけすればいい。
コールドスタート問題、ランタイム制限、ベンダーロックイン問題はあるのか？
GitHubAction
GitHubのCI/CD（継続的インテグレーション／継続的デリバリー）機能で、AWSのリソースを操作・管理・デプロイするために使えるアクション。
つまり、GitHubのリポジトリにプッシュしたタイミングなどで、自動的にAWSにデプロイしたり、インフラを更新したりできるようにするのが目的です。
特徴
・GitHub Actions = GitHubが提供するCI/CD自動化ツール
→ 例: コードのプッシュ時にテスト・ビルド・デプロイを自動実行。
・AWS関連のGitHub Actions = AWSが公式やサードパーティとして提供しているアクションで、AWSのサービスと連携できる。
→ 例:
aws-actions/configure-aws-credentials: AWSの認証情報をセット。
aws-actions/amazon-ecr-login: ECRにログインしてDockerイメージをPush。
aws-actions/amazon-ecs-deploy-task-definition: ECSにアプリをデプロイ。
ELB
ELBは、複数のサーバー（EC2インスタンスなど）に対して、トラフィックを自動的に分散するサービス です。
これにより、アプリケーションは次のようなメリットを得られます
・高可用性（障害発生時も他の正常なサーバーに振り分け）
・スケーラビリティ（アクセスが増えても複数台で処理できる）
・自動ヘルスチェック（故障したインスタンスは自動で除外）
機能
・ヘルスチェック（ターゲットの監視と自動切り離し）
・SSL終端（HTTPS通信をELBで処理してバックエンドはHTTPに）
・スケーラブル（自動でキャパシティを調整）
・アクセスログ（ALB/NLBはS3にアクセスログを出力可）
・IPベース/インスタンスベースのターゲット（ECSやIP直指定でもOK）
ELBの種類
・ALB（Application Load Balancer）
レイヤー7（アプリケーション層）
HTTP/HTTPS専用
パスベース/ホストベースルーティングが可能
WebSocket対応
・NLB（Network Load Balancer）
レイヤー4（トランスポート層）
TCP/UDP対応（低レイテンシ向き）
大量のリクエストを高速処理
・CLB（Classic Load Balancer）
レイヤー4と7に対応（古いタイプ）
新規では推奨されず、レガシー用途向け
ALBとNLBの使い分け
ELBとNginx(Apache)
ユースケース
・Webアプリを冗長化したいとき
ALBでHTTP/HTTPSのリクエストを複数のEC2やFargateコンテナに分散
・TCPベースのゲームサーバーでスケールしたいとき
NLBを使って、低レイテンシかつ高パフォーマンスな接続を維持
ECS
コンテナ化したアプリケーションを簡単にデプロイ・管理できるフルマネージドなサービス。
簡単にいうと
・Dockerコンテナを動かすためのAWSのサービス。
・インフラ管理を最小限にして、アプリの起動・スケーリング・管理ができる。
・EC2（仮想マシン）またはFargate（サーバーレス実行環境）のどちらかを基盤にしてコンテナを動かせます
特徴
| 特徴 | 内容 |
|---|---|
| オーケストレーション | コンテナの配置、スケジューリング、自動再起動を管理 |
| 柔軟な実行環境 | EC2起動タイプとFargate起動タイプ |
| ロードバランシング | ALB/NLBと統合してリクエストを分散 |
| オートスケーリング | タスク数を自動で増減 |
| IAM連携 | コンテナごとに細かくIAMロールを設定可能 |
| クラスタ管理 | クラスタ単位でリソースをまとめて管理 |
サービスとタスクの違い
ユースケース
・WebアプリをNginx＋PHP＋DBのマルチコンテナ構成で作りたい。
・コンテナが落ちたとき自動で復旧してほしい。
・トラフィックが増えたときだけコンテナ数を自動で増やしたい。
Kubernetes(クバネティス)とECSの違い
ECSとEKSの違い
ECR
Dockerコンテナイメージのプライベート・パブリックなレジストリサービス。
作ったDockerイメージをプッシュ（アップロード）プル（ダウンロード）できる、AWSが管理するDocker Hubみたいなもの。
特徴
・プライベートレジストリ
他の誰にも見えない自分専用のレジストリを簡単に作れます。
・パブリックレジストリ
公開用イメージもホストできます（例: OSS向け）。
・IAM統合
AWSのアクセス管理（IAM）と統合していて、細かくアクセス制御できます。
・高可用性 & セキュリティ
AWSのインフラを使うので、信頼性が高く、イメージは暗号化されて保存されます。
・他のAWSサービスと連携
ECS（Elastic Container Service）、EKS（Kubernetes）、CodeBuildなどとシームレスに連携。
マルチコンテナ構成
Elastic IP対応
AWS CLI
AWSのさまざまなサービスをコマンドラインから操作できるツールです。
AWS CLIが便利なケース
・大量・繰り返し作業：
例）S3に100個ファイルをアップロード、複数のインスタンスを一括起動。
1回だけS3バケットを作る → コンソールで十分。
毎日データをS3に自動アップロードする → CLIやスクリプトが必須。
・自動化したいとき：
デプロイ、バックアップ、監視などをスクリプトで自動化できる。
・CI/CDやDevOps環境：
CLIがあるとGitHub ActionsやGitLab CIなどのパイプラインで使える。
・GUIの制限を超える処理：
CLIではGUIにない細かいオプションが使えることもあります。
結論
普段はAWSコンソールで十分ですが、
自動化・スクリプト化・繰り返し作業が出てくるとCLIの出番です。
料金アラート設定
Discussion