Go to Qiita Advent Calendar Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@mukai3(ムカイさん)

2025年版 AWS全サービス完全ガイド - Compute / Container / Storage / Network 編

Last updated at Posted at 2025-07-30

#1 Compute / Container / Storage / Network 編

本記事

#2 Data / Analytics / AI・ML / Integration 編

#3 Security / Governance / Migration / Operations 編
鋭意制作中

本記事のねらい
AWS を“サービス名の暗記”ではなく“用途で選べる判断軸”から理解する。
まずは 4 大カテゴリ（Compute / Container / Storage / Network）を、いつ・なぜ・どの基準で選ぶかまで一気に整理する。

対象読者

  • AWS 初学者〜中級者。クラウド設計の全体感と「正しい選び方」を掴みたい読者
  • マルチクラウド／オンプレ経験はあるが、AWS の地図がまだ曖昧である読者

到達点（この記事で分かること）

  • ユースケースから AWS を逆引きするための判断フローと早見表を獲得する
  • Compute／Container／Storage／Network 主要サービスの使い分けと落とし穴を把握する
  • すぐに試せる最小構成テンプレートと学習ロードマップ（30 日） を得る

断り書き・更新方針

  • 本記事は 2025 年 7 月時点の情報に基づく。今後のアップデートは適宜追記する。
  • 公式ドキュメントを一次情報として参照し、設計判断は最新情報を確認のうえ行うこと。

目次

設計の出発点：用途から選ぶ思考法

クラウドは“箱を借りる”のではなく“責務を分割して委譲する”設計である。はじめに以下の 6 つを順に判定すると迷いにくい。

  1. ワークロードの性格：イベント駆動（突発/短時間）か、常時稼働（長時間/安定）か
  2. 実行形態：関数（サーバーレス）、コンテナ、VM のどれが自然か
  3. 可用性要件：AZ またはリージョン跨ぎが必要か、RTO/RPO は何か
  4. スケール特性：水平/垂直、同時実行の上限、コールドスタート許容度
  5. 運用責務：OS/ランタイム/ミドル/ネットワークのどこまでを自分で持つか
  6. コスト構造：従量（リクエスト/秒課金）か、常時（時間/台数課金）か

まずはこれ：用途別の推奨サービス早見表

“先にこれを当てる → 代替候補で微調整”の順で選ぶと速い。

用途 推奨（第一想起） 代替候補 判断の目安
API・バックエンド（突発負荷/短処理） AWS Lambda + API Gateway Fargate + ALB / Lambda + Function URLs コールドスタート許容・イベント駆動・最小運用に寄せたいとき
常時稼働の Web/Batch（コンテナ） ECS on Fargate + ALB EKS / ECS on EC2 Kubernetes が要件でない限り ECS/Fargate が速い
既存アプリ Lift & Shift EC2 + ASG + ALB Lightsail（小規模） OS/ミドル制御が必要、移行優先
静的サイト/SPA 配信 S3 + CloudFront + (Route 53) Amplify Hosting 動的機能は別の API/Edge で補う
リレーショナル DB Aurora（MySQL/PostgreSQL） RDS Engine 各種 水平スケール/高可用性/パフォ基準で Aurora 優位
キー・バリュー/超低レイテンシ DynamoDB ElastiCache / Aurora Serverless アクセスパターンが決まっているなら最強
画像/アーカイブ S3（IA/Glacier 併用） EFS（共有 POSIX） ライフサイクルでコスト最適化
メッセージング SQS（Queue）/ SNS（PubSub） EventBridge 疎結合・再試行・DLQ を前提に設計
エッジ最適化/グローバル配信 CloudFront + Route 53 Global Accelerator レイテンシ重視/マルチリージョン

Compute の選び方

最初の分岐は Lambda / Container / VM である。以下の簡易フローが有効である。

短時間・イベント駆動？ → Yes: Lambda
↓ No
コンテナ化容易？ → Yes: ECS/Fargate（K8s要件なら EKS）
↓ No
OS/ドライバ/ライセンス要件？ → Yes: EC2

主要サービス（概要）

サービス 使うとき 強み 注意・落とし穴
AWS Lambda 短処理/イベント駆動/ゼロ運用 スケール即応・従量課金 コールドスタート、同時実行制限、実行時間上限
Amazon ECS on Fargate 常時/バースト混在の API/BK/Batch サーバーレス運用・単純明快 高速 I/O/超特殊ネットは EC2 実行の検討
Amazon EKS K8s 前提/既存マニフェスト流用 エコシステム活用 制御プレーン理解・運用コスト
Amazon EC2 OS/デバドラ/独自監視が必要 自由度と互換性 パッチ/台数の運用責務が増える
AWS Batch バッチ/ジョブキュー スポット活用/キュー制御 依存の理解が必要
Lambda を選ぶ基準と設計の型
  • 向いている：リクエスト駆動、非同期処理、スパイク、夜間停止
  • 合わせ技：API Gateway(REST/HTTP) + Lambda + DynamoDB/S3、EventBridge + Lambda + SQS(DLQ)
  • 設計ポイント
    • コールドスタートを嫌う経路は Provisioned Concurrency
    • 高スループットは SQS + Lambda で並列度を制御
    • 外部接続は VPC エンドポイントで閉域／コスト最適化
ECS/Fargate を選ぶ基準と設計の型
  • 向いている：常時稼働 API、状態レス Web、ワーカー、バッチ
  • 合わせ技：ALB + ECS(Fargate) + RDS/Aurora
  • 設計ポイント
    • Capacity Provider と オートスケールで負荷に追従
    • タスク定義の明確化（CPU/メモリ/ログ/環境変数/Secrets）
    • 内部通信は Service Connect で簡素化できる

Container の選び方

  • ECS は “AWS ネイティブでシンプル”。EKS は “K8s エコシステムを活用”
  • “K8s でなければできない理由”がなければ ECS/Fargate が学習・運用コストともに低い
観点 ECS EKS
学習/運用コスト 低 中〜高
拡張性/移植性 中 高
マネージド度 高 中
初期実装スピード 速い 構築整備が必要
最小構成の決定フロー
  1. まず ECS on Fargate で PoC
  2. サイドカーや高度なネットワーク要求が出たら ECS on EC2 または EKS を検討
  3. 既存 K8s マニフェスト流用・Istio 等が必須なら EKS

Storage の選び方

三択を押さえると迷わない：S3（オブジェクト）／EFS（共有 POSIX）／EBS（ブロック）。

サービス 使うとき 強み 注意
S3 静的ファイル/バックアップ/データレイク 耐久性・コスト 小ファイル大量 PUT/GET の設計
EFS 複数インスタンスで共有/コンテナの共有ストレージ マネージド NFS レイテンシ/スループット特性の把握
EBS EC2 のディスク/高 IOPS 予測可能な性能 AZ 単位・スナップショット設計
S3 の実務パターン
  • 配信：S3 + CloudFront (+ OAC) + Route 53
  • ライフサイクル：Standard → IA → Glacier で自動階層化
  • セキュリティ：Block Public Access、バケットポリシー最小化、SSE-KMS

Network の選び方

最小は VPC / Subnet / Route Table / SG / NACL / IGW / NATGW。ここに ALB/NLB と Route 53/CloudFront を重ねる。

コンポーネント 役割 使いどころ
ALB L7 ロードバランサ HTTP/HTTPS、パス/ホストベース振り分け
NLB L4 ロードバランサ 高スループット・超低レイテンシ、TCP/UDP
CloudFront CDN/エッジ グローバル配信/キャッシュ/オリジン保護
Route 53 DNS/ヘルスチェック ドメイン管理、フェイルオーバー
基本構成の型
  • 公開 API：ALB (Public) → ECS/Fargate (Private) → RDS/Aurora (Private)
  • 静的配信：CloudFront → S3 (OAC)
  • 内部通信：Private Subnet + NATGW + VPC Endpoint
  • カスタムドメイン：Route 53 Hosted Zone + ACM 証明書

最小構成テンプレート

“とりあえず動く” を最短でつくるためのミニマム例である。

A. サーバーレス API（HTTP API + Lambda + DynamoDB）

# CloudFormation（抜粋イメージ）
Resources:
  Api:
    Type: AWS::ApiGatewayV2::Api
    Properties:
      ProtocolType: HTTP
  Function:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: python3.12
      Handler: app.handler
      MemorySize: 512
      Timeout: 15
  Ddb:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH

B. コンテナ API（ALB + ECS on Fargate + Aurora Serverless v2）

# Terraform（抜粋イメージ）
resource "aws_ecs_cluster" "this" {}
resource "aws_lb" "alb" { load_balancer_type = "application" }
resource "aws_ecs_task_definition" "api" {
  requires_compatibilities = ["FARGATE"]
  cpu    = "512"
  memory = "1024"
  network_mode = "awsvpc"
}
resource "aws_ecs_service" "api" {
  launch_type = "FARGATE"
  desired_count = 2
}

C. 静的サイト（S3 + CloudFront + Route 53）

aws s3 sync dist/ s3://example-site --delete
# OAC/ACM/Route 53 はコンソール or IaC で設定

学習ロードマップ（30 日）

Week 1：地図を持つ

  • AWS Well-Architected の設計原則、アイデンティティ/IAM の最小権限、VPC 基礎

Week 2：Compute × Network

  • Lambda（イベント・並列・DLQ）、ECS/Fargate（デプロイ/オートスケール）、ALB/NLB/CloudFront/Route 53

Week 3：Storage × Database

  • S3（OAC/ライフサイクル/暗号化）、Aurora/DynamoDB の使い分け、バックアップ/DR

Week 4：信頼性・運用

  • CloudWatch/Logs/Alarm、X-Ray、コスト最適化（Compute Optimizer/Graviton/ライフサイクル）、IaC（CFn/Terraform）

次回予告

#2：Data / Analytics / AI・ML / Integration 編

  • RDS/Aurora/DynamoDB/ElastiCache/Redshift/Athena/Glue/Kinesis/MSK/OpenSearch/SageMaker/Bedrock/EventBridge ほか

#3：Security / Governance / Migration / Operations 編

  • IAM/Organizations/Control Tower/KMS/Secrets/CloudTrail/Config/GuardDuty/Security Hub/Backup/Systems Manager/DMS/AMS ほか

付録（用語ミニ辞典）

  • サーバーレス：サーバー運用責務を極小化し、従量課金でスケールするアーキテクチャの総称
  • OAC (Origin Access Control)：CloudFront から S3 オリジンへのプライベートアクセス制御
  • DLQ (Dead-Letter Queue)：処理失敗メッセージの待避キュー
  • RTO/RPO：復旧目標時間/復旧目標時点

#1 Compute / Container / Storage / Network 編

本記事

#2 Data / Analytics / AI・ML / Integration 編

#3 Security / Governance / Migration / Operations 編
鋭意制作中

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?