AWS Game/Media本番運用Vol1｜AppStream×MediaConvert×Live

§1 なぜ Game/Media Vol1 か — AWSメディアスタック全景 + 第20軸目起点 + 全シリーズナビ

エンタメ・メディア・ゲーム業界は、AWS クラウドへの移行が最も加速している産業の一つだ。動画配信サービスが 4K/8K コンテンツを世界規模で届け、オンラインゲームの同時接続プレイヤー数が数千万人に達し、企業のリモートワーク対応としてアプリケーションストリーミング需要が急増している。AWS はこの領域に特化したフルマネージドサービス群を揃え、放送局・OTT プラットフォーム・ゲームスタジオから大企業の IT 部門まで幅広く採用されている。

本シリーズでは AWS のメディア・ゲーム専用サービスとして AppStream 2.0・Elemental MediaConvert・Elemental MediaLive・GameLift の 4 サービスを取り上げる。これらは互いに補完関係にあり、組み合わせることで Application 配信・VOD・Live 映像・ゲームサーバーという 4 大ユースケースを AWS 上で完結できる。Container/Serverless/Database 本番運用に慣れた SRE がメディア・ゲーム領域に踏み出す際の実践ガイドとして設計した。

AWSメディアスタック全景 — 4 領域の役割

AWS のメディア・ゲーム領域は次の 4 柱に分類できる。

各サービスは AWS の共通基盤と深く統合されている。S3 が Media Asset の中核ストレージとして機能し、CloudFront が VOD/Live コンテンツの CDN 配信を担い、IAM がアクセス制御を横断し、CloudWatch がメトリクス監視を提供する。

AWS メディアスタック — サービス構成概要

┌──────────────────────────────────────────────────────────────────┐
│Application 配信層 │
│  AppStream 2.0 │
│  Image Builder → Image → Fleet (Always-On / On-Demand / Elastic) │
│  → Stack → User Pool / AD Connector → HTTPS ブラウザ接続│
├─────────────────────────┬────────────────────────────────────────┤
│VOD 映像処理層│ Live 映像処理層  │
│  Elemental MediaConvert  │  Elemental MediaLive│
│  S3 入力 → Job Queue │  RTMP / HLS / MediaConnect 入力 │
│  → Output Group │  → Channel (Standard / Single)  │
│  → HLS / DASH / CMAF │  → MediaPackage (CDN Origin) │
│  → DRM (Widevine/FairPlay)│  → CloudFront (CDN 配信)│
├─────────────────────────┴────────────────────────────────────────┤
│  ゲームサーバー運用層 │
│  GameLift│
│  Fleet (On-Demand / Spot / Anywhere)  │
│  → FlexMatch → Game Session Queue → Player Session│
├──────────────────────────────────────────────────────────────────┤
│共通基盤 (S3 / IAM / CloudWatch / CloudFront / VPC / KMS) │
└──────────────────────────────────────────────────────────────────┘

サービス選択ガイド — ユースケース別の使い分け

4 サービスは独立して利用できるが、組み合わせると相乗効果が生まれる。自社ユースケースに対応するサービスを以下の基準で選択しよう。

アプリケーションを配信したい場合
– Windows アプリをブラウザから利用させたい → AppStream 2.0
– フルデスクトップ環境が必要 → WorkSpaces (AppStream は個別アプリ配信特化)
– Linux アプリのリモート実行 → WorkSpaces / EC2 + NiceDCV

映像コンテンツを配信したい場合
– 収録済み動画を変換・配信したい (VOD) → Elemental MediaConvert
– リアルタイムの生放送をしたい (Live) → Elemental MediaLive
– VOD + Live の統合配信基盤 → MediaConvert + MediaLive + MediaPackage + CloudFront

ゲームサーバーを運用したい場合
– マルチプレイヤーゲームのマッチメイキングと対戦サーバー → GameLift
– ゲームのバックエンド API サーバー → ECS/EKS + API Gateway
– ゲームデータのリアルタイム同期 → GameLift Realtime Servers

既存 19 軸との接続 — 第20軸目 新シリーズ起点

本シリーズは AWS 本番運用シリーズの第 20 軸目「Game/Media 本番運用」の起点記事だ。既存 19 軸との接続を把握することで、自社の AWS 基盤に Game/Media サービスを段階的に組み込む設計が可能になる。

既存軸との具体的な接続設計については §8 のクロスリンクナビで詳解する。

本記事で達成できること

本記事を読み終えた時点で、次の 5 つを実践できる状態を目指している。

(a) AppStream 2.0 で Desktop 配信を実装する

Image Builder を使って Windows アプリのイメージを作成し、Fleet (Always-On / On-Demand) を構築する。Stack・User Pool・AD Connector の設定、Auto-scaling ポリシーの実装、Session Scripts によるセッション初期化まで Terraform コードで完結できる。

(b) Elemental MediaConvert で VOD 映像処理パイプラインを実装する

S3 に格納した MP4/MXF などのソース映像を Job Template で HLS/DASH/CMAF に変換し、CloudFront を通じてエンドユーザーに配信する。DRM (Widevine / FairPlay) の適用方法と、HLS vs DASH vs CMAF の適用基準も把握できる。

(c) Elemental MediaLive で Live 映像配信を実装する

RTMP / HLS / MediaConnect 入力を受け付ける Channel を構築し、Standard pipeline (冗長化) を設定する。Live to VOD の S3 アーカイブ連携と、MediaPackage を経由した CloudFront 配信フローを理解できる。

(d) GameLift でゲームサーバーを運用する

Fleet (On-Demand / Spot) を構築し、FlexMatch によるマッチメイキング設定と Game Session Queue を実装する。Anywhere を使ったオンプレ・クラウドハイブリッド構成と、Spot Interruption への対応設計を身につけられる。

(e) 詰まり7選 + アンチパターン演習5問で本番設計力を強化する

よくある設計ミスと対処法を体系的に整理し、アンチパターンから正解パターンへの変換を実践形式で確認できる。

対象読者と前提知識

本記事の主な対象読者は次のいずれかに該当するエンジニア・SRE だ。

• アプリケーションストリーミング担当: 社内 Windows アプリを SaaS 化・リモート対応させたい
• 映像配信担当: OTT プラットフォームや社内動画配信を AWS で構築・運用したい
• ゲームサーバー運用担当: マルチプレイヤーゲームサーバーをマネージドに運用したい

前提知識として、AWS 基本操作 (IAM / S3 / VPC / CloudWatch) の実務経験があれば十分だ。Terraform の基本構文を理解していると §2-§5 のコード例をそのまま活用できる。メディア固有の知識 (コーデック詳細・DRM 仕様) は各セクションで必要な範囲を補足するため、メディア業界未経験でも読み進められるよう設計してある。

Container/Serverless/Database 本番運用シリーズを読んでいると、IAM Role 設計・VPC 設計・Auto-scaling の基本パターンが共通しているため理解が速い。特に Storage 本番運用 Vol1 (S3 設計) と Network 本番運用 Vol1 (VPC 設計) を先読みしておくと §2-§5 の Terraform 例をスムーズに活用できる。

本シリーズを読む前の準備として推奨するコマンドライン確認:

# AWS CLI で AppStream 2.0 の Fleet 一覧確認 (事前動作確認)
aws appstream describe-fleets --query 'Fleets[*].{Name:Name,State:State,Type:FleetType}' --output table

# MediaConvert エンドポイントの確認 (リージョンごとに異なる)
aws mediaconvert describe-endpoints --query 'Endpoints[*].Url' --output text

# GameLift のサポートリージョン確認
aws gamelift describe-fleet-location-attributes --fleet-id YOUR_FLEET_ID

§2 AppStream 2.0 本番運用 — Image Builder × Fleet × Stack × User Pool × Auto-scaling × Session Scripts

AppStream 2.0 概要 — フルマネージドアプリケーションストリーミング

AppStream 2.0 は、Windows アプリケーションをクラウドからブラウザ経由でストリーミング配信するフルマネージドサービスだ。ユーザーのデスクトップにアプリをインストールすることなく、AWS 上の仮想デスクトップでアプリを実行し、映像・音声をリアルタイムで転送する。

主な用途は 3 つに整理できる。

AppStream 2.0 の主要コンポーネントは Image Builder・Fleet・Stack・User Pool の 4 つだ。

AppStream 2.0 コンポーネント構成

Image Builder ──(アプリインストール・スナップショット)──→ Image
 ↓
  Fleet ←──(Image 適用)
 ├── Always-On (常時起動)
 ├── On-Demand (オンデマンド起動)
 └── Elastic (エラスティック)
 ↓
  Stack ←──(Fleet 紐付け)
 ├── Storage Connector (S3 / OneDrive)
 ├── User Pool / AD Connector
 └── Streaming URL 発行
 ↓
 User ──(HTTPS ブラウザ接続)──→ Streaming Session

Image Builder — 再現性のあるイメージ作成フロー

Image Builder は専用の EC2 インスタンス上でアプリをインストールし、スナップショットとして保存する。作成したイメージを Fleet に適用することで、全ユーザーが同一環境でアプリを利用できる。

Image Builder の標準フロー:

1. ベースイメージ選択: AWS 提供の Windows Server 2019/2022 ベースまたはカスタムイメージ
2. Image Builder インスタンス起動: stream.standard.medium 〜 stream.graphics.g4dn.xlarge から選択
3. アプリインストール: RDP / AppStream Image Builder コンソールからリモート操作
4. Application Catalog への登録: AppStream Agent でアプリを登録・最適化
5. スナップショット作成: Image Builder からイメージ作成コマンドを実行
6. Image 作成完了: 20-45 分でイメージが利用可能になる

# AWS CLI でイメージ一覧確認
aws appstream describe-images \
  --type PRIVATE \
  --query 'Images[*].{Name:Name,State:State,BaseImageArn:BaseImageArn}' \
  --output table

# Terraform: AppStream Image Builder
resource "aws_appstream_image_builder" "main" {
  name= "prod-image-builder-v1"
  instance_type= "stream.standard.medium"
  image_name= "AppStream-WinServer2019-01-19-2024"
  description  = "Production image builder for internal apps"
  enable_default_internet_access = false

  vpc_config {
 subnet_ids= [aws_subnet.private_a.id]
 security_group_ids = [aws_security_group.appstream.id]
  }

  iam_role_arn = aws_iam_role.appstream_image_builder.arn

  tags = {
 Environment = "production"
 ManagedBy= "terraform"
  }
}

Fleet 設計 — Always-On vs On-Demand vs Elastic

Fleet はユーザーがストリーミングセッションを実行するインスタンス群だ。3 種類の Fleet タイプから用途に応じて選択する。

インスタンスタイプ選定の目安:

# Terraform: AppStream Fleet (On-Demand) + Auto-scaling
resource "aws_appstream_fleet" "prod" {
  name = "prod-fleet"
  fleet_type = "ON_DEMAND"
  instance_type = "stream.standard.large"
  image_name = "prod-internal-apps-v3"
  description= "Production fleet for internal applications"

  compute_capacity {
 desired_instances = 2
  }

  vpc_config {
 subnet_ids= [aws_subnet.private_a.id, aws_subnet.private_b.id]
 security_group_ids = [aws_security_group.appstream_fleet.id]
  }

  stream_view= "APP"
  max_user_duration_in_seconds = 57600
  disconnect_timeout_in_seconds= 900
  idle_disconnect_timeout_in_seconds = 600

  enable_default_internet_access = false

  tags = {
 Environment = "production"
 ManagedBy= "terraform"
  }
}

resource "aws_appautoscaling_target" "appstream_fleet" {
  max_capacity = 20
  min_capacity = 1
  resource_id  = "fleet/${aws_appstream_fleet.prod.name}"
  scalable_dimension = "appstream:fleet:DesiredCapacity"
  service_namespace  = "appstream"
}

resource "aws_appautoscaling_policy" "fleet_utilization_tracking" {
  name= "fleet-utilization-tracking"
  policy_type  = "TargetTrackingScaling"
  resource_id  = aws_appautoscaling_target.appstream_fleet.resource_id
  scalable_dimension = aws_appautoscaling_target.appstream_fleet.scalable_dimension
  service_namespace  = aws_appautoscaling_target.appstream_fleet.service_namespace

  target_tracking_scaling_policy_configuration {
 target_value = 75.0
 predefined_metric_specification {
predefined_metric_type = "AppStreamAverageCapacityUtilization"
 }
 scale_in_cooldown  = 300
 scale_out_cooldown = 60
  }
}

Stack とストレージコネクタ

Stack はユーザーへのストリーミング配信設定をまとめるリソースだ。Fleet との紐付けと、ストレージコネクタ・ユーザーアクセス制御を定義する。

# Terraform: AppStream Stack + Fleet-Stack Association
resource "aws_appstream_stack" "prod" {
  name  = "prod-internal-stack"
  description = "Production stack for internal app delivery"

  storage_connectors {
 connector_type= "HOMEFOLDERS"
 resource_identifier = aws_s3_bucket.appstream_home.arn
  }

  user_settings {
 action  = "CLIPBOARD_COPY_FROM_LOCAL_DEVICE"
 permission = "ENABLED"
  }
  user_settings {
 action  = "CLIPBOARD_COPY_TO_LOCAL_DEVICE"
 permission = "DISABLED"
  }
  user_settings {
 action  = "FILE_UPLOAD"
 permission = "ENABLED"
  }
  user_settings {
 action  = "FILE_DOWNLOAD"
 permission = "DISABLED"
  }
  user_settings {
 action  = "PRINTING_TO_LOCAL_DEVICE"
 permission = "DISABLED"
  }

  tags = {
 Environment = "production"
 ManagedBy= "terraform"
  }
}

resource "aws_appstream_fleet_stack_association" "prod" {
  fleet_name = aws_appstream_fleet.prod.name
  stack_name = aws_appstream_stack.prod.name
}

ストレージコネクタは 3 種類から選択できる。

Session Scripts — セッションライフサイクル制御

Session Scripts は、ストリーミングセッション開始・終了時にカスタムスクリプトを実行する機能だ。アプリケーションの初期化・環境設定・後処理を自動化できる。

{
  "SessionStart": {
 "executables": [
{
  "context": "system",
  "filename": "C:\\SessionScripts\\start.bat",
  "arguments": "",
  "s3LogDestination": {
 "bucket": "my-appstream-logs",
 "keyPrefix": "session-start-logs/"
  }
}
 ],
 "waitingTime": 30
  },
  "SessionTermination": {
 "executables": [
{
  "context": "system",
  "filename": "C:\\SessionScripts\\cleanup.bat",
  "arguments": "",
  "s3LogDestination": {
 "bucket": "my-appstream-logs",
 "keyPrefix": "session-end-logs/"
  }
}
 ],
 "waitingTime": 30
  }
}

Session Scripts の主な活用パターン:
– セッション開始: ネットワークドライブのマウント・プロファイル設定・ライセンスサーバー接続確認
– セッション終了: 一時ファイル削除・監査ログ送信・プロファイルバックアップ

ライセンス管理 — BYOL と Windows SAL

AppStream 2.0 のライセンス管理は 2 つのモデルに分かれる。

BYOL (Bring Your Own License)

既存の Windows デスクトップライセンス (Software Assurance 付き) を AWS 上で利用する方式だ。

Windows SAL (Subscriber Access License)

AWS がマイクロソフトと締結した契約に基づき、AppStream 2.0 の料金に Windows ライセンスが含まれるモデルだ。BYOL と比較して管理負担が低く、既存 SA ライセンスを持たない場合はこちらを選択する。

コスト最適化 — Always-On vs On-Demand 比較

Fleet タイプとコスト構造を理解することで、用途に応じた最適化が可能だ。

業務時間 (8-19時) のみ利用するケースでは On-Demand + Auto-scaling の組み合わせが最も費用対効果が高い。Always-On が有利なのは、24 時間 70% 以上の稼働率が見込まれる場合に限られる。スケジュールベーススケーリングを組み合わせれば、深夜帯に最小インスタンス数まで縮退させることも可能だ。

§3 Elemental MediaConvert 本番運用 — Job Template × Queue × Output Group × HLS/DASH/CMAF × DRM ★山場1

§3.1 MediaConvert とは — フルマネージド VOD トランスコーディング

Elemental MediaConvert は AWS が提供するフルマネージドの VOD (Video on Demand) トランスコーディングサービスだ。入力ファイル (RAW 映像 / プロキシ映像 / マルチビットレート素材) を S3 から取り込み、HLS・DASH・CMAF・MP4 など多様な配信フォーマットに変換して S3 に書き出す。サーバー管理は不要で、ジョブ単位の従量課金モデルを採る。

主要コンポーネントを整理しておこう。

MediaConvert の処理フローは明快だ。S3 入力 → Job Template 適用 → 並列トランスコーディング → S3 出力 という 4 ステップで完結する。EventBridge と連携することでジョブ完了通知もリアルタイムに受け取れる。

§3.2 Job Template 設計 — 標準化と再利用性の両立

本番運用では「毎回ゼロから Job を作成する」ことを禁止し、Job Template に設定を集約する。設定の属人化を排除し、コーデック品質・ビットレートラダーを均一に保つためだ。

入力設定 (Input) の JSON 定義例

{
  "Inputs": [
 {
"FileInput": "s3://input-bucket/videos/source.mp4",
"AudioSelectors": {
  "Audio Selector 1": {
 "DefaultSelection": "DEFAULT",
 "SelectorType": "LANGUAGE_CODE",
 "LanguageCode": "JPN"
  }
},
"VideoSelector": {
  "ColorSpace": "FOLLOW",
  "Rotate": "AUTO"
},
"TimecodeSource": "ZEROBASED"
 }
  ]
}

出力グループ (Output Group) — HLS 設定例

{
  "OutputGroups": [
 {
"Name": "HLS Group",
"OutputGroupSettings": {
  "Type": "HLS_GROUP_SETTINGS",
  "HlsGroupSettings": {
 "Destination": "s3://output-bucket/hls/",
 "SegmentLength": 6,
 "MinSegmentLength": 0,
 "DirectoryStructure": "SINGLE_DIRECTORY",
 "ManifestCompression": "NONE",
 "StreamInfResolution": "INCLUDE",
 "CodecSpecification": "RFC_4281"
  }
},
"Outputs": [
  {
 "NameModifier": "_1080p",
 "VideoDescription": {
"CodecSettings": {
  "Codec": "H_264",
  "H264Settings": {
 "Bitrate": 5000000,
 "FramerateControl": "INITIALIZE_FROM_SOURCE",
 "GopSize": 90,
 "GopClosedCadence": 1,
 "QualityTuningLevel": "SINGLE_PASS_HQ"
  }
},
"Width": 1920,
"Height": 1080
 }
  }
]
 }
  ]
}

AWS CLI で Job Template を作成・使用する手順を示す。

# Job Template 作成
aws mediaconvert create-job-template \
  --name "production-hls-dash-template" \
  --settings file://job-template-settings.json \
  --description "Production HLS+DASH multi-bitrate template" \
  --region ap-northeast-1

# Job Template を使ったジョブ投入
aws mediaconvert create-job \
  --job-template "production-hls-dash-template" \
  --role "arn:aws:iam::123456789012:role/MediaConvertRole" \
  --settings '{"Inputs":[{"FileInput":"s3://input-bucket/source.mp4"}]}' \
  --region ap-northeast-1

§3.3 Output Group 設計 — HLS / DASH / CMAF / MP4 の使い分け

出力フォーマットの選択は配信プラットフォームと視聴環境によって決まる。誤った選択はデバイス互換性問題を引き起こすため、設計段階で明確に決定しておく。

マルチビットレート HLS ラダー設計例

解像度  ビットレートフレームレート
1080p (FHD)5,000 kbps 29.97fps (基準)
720p  (HD) 3,000 kbps 29.97fps
540p 1,500 kbps 29.97fps
360p700 kbps 29.97fps
240p400 kbps 29.97fps

Terraform で IAM ロールと MediaConvert 実行環境を管理する例を示す。

resource "aws_iam_role" "mediaconvert_role" {
  name = "MediaConvertExecutionRole"

  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "mediaconvert.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy" "mediaconvert_policy" {
  name = "MediaConvertPolicy"
  role = aws_iam_role.mediaconvert_role.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect= "Allow"
  Action= ["s3:GetObject", "s3:PutObject"]
  Resource = [
 "arn:aws:s3:::input-bucket/*",
 "arn:aws:s3:::output-bucket/*"
  ]
},
{
  Effect= "Allow"
  Action= ["cloudwatch:PutMetricData"]
  Resource = "*"
}
 ]
  })
}

§3.4 Queue 設計 — On-demand vs Reserved

MediaConvert のキューは 2 種類あり、ワークロードの特性に合わせて使い分ける。

On-demand Queue

処理した分だけ課金される従量制キュー。突発的なジョブや開発・テスト用途に向く。キューの空き状況によっては処理開始が遅延する場合がある。

Reserved Queue (予約キュー)

月額固定料金を支払うことで専用処理キャパシティを確保する。1 RTP (Reserved Transcode Processor) を購入すると常に 1 ジョブを並列実行できる。大量・定常的な映像処理を行う本番環境ではコストが大幅に低下するケースが多い。

コスト試算の目安

月間 1,000 時間の H.264 トランスコーディングを行う場合の比較:

On-demand:$0.0075/分 × 60,000 分 ≒ $450/月
Reserved: 1 RTP = 約 $400〜$500/月 (固定)
→ 処理量が安定していれば Reserved が同等かそれ以下

処理量が月間 500 時間を超えるなら Reserved Queue への移行コスト試算を必ず実施しよう。

§3.5 DRM 設定 — Widevine / FairPlay / PlayReady / SPEKE

有料コンテンツや著作権保護が必要な映像には DRM (Digital Rights Management) が必須だ。MediaConvert は SPEKE (Secure Packager and Encoder Key Exchange) プロトコルを通じて外部 DRM プロバイダーと連携する。

SPEKE の仕組み

SPEKE は AWS が定めた標準規格で、MediaConvert から DRM キーサーバー (Key Provider) に HTTP リクエストを送り暗号化キーを取得する仕組みだ。AWS では Axinom・EZDRM・BuyDRM などのサードパーティ Key Provider との組み合わせが一般的だ。

MediaConvert → SPEKE API → DRM Key Provider
 (Widevine / FairPlay / PlayReady キー生成)
↓
  暗号化済み HLS/DASH → CloudFront → CDN エッジ → 視聴者
↓
  クライアント (iOS/Android/Web) → DRM ライセンスサーバー → 復号

DRM プラットフォーム別設定

MediaConvert DRM 設定 (JSON 抜粋)

{
  "HlsGroupSettings": {
 "Encryption": {
"EncryptionMethod": "SAMPLE_AES",
"SpekeKeyProvider": {
  "ResourceId": "content-id-unique-123",
  "SystemIds": ["94CE86FB-07BB-4B43-ADB8-93D2FA968CA2"],
  "Url": "https://your-speke-key-provider.example.com/copyProtection",
  "EncryptionContractConfiguration": {
 "SpekeAudioPreset": "PRESET-AUDIO-1",
 "SpekeVideoPreset": "PRESET-VIDEO-1"
  }
}
 }
  }
}

DRM 鍵ローテーション

本番運用では定期的な鍵ローテーションが必要だ。MediaConvert ではセグメントごとに鍵を変更する設定と、コンテンツ固定の単一鍵設定を選択できる。長期アーカイブコンテンツでは定期ローテーションを推奨する。SPEKE エンドポイントは API Gateway + Lambda で構築し、鍵管理は KMS に委ねる構成がセキュリティ上の定石だ。

§3.6 CloudWatch 連携 — ジョブ完了通知 / エラー監視 / コスト追跡

MediaConvert はジョブのステータス変化を EventBridge イベントとして発行する。この仕組みを活用することでジョブ完了の自動通知やエラー時のアラートを構築できる。

EventBridge でジョブ完了を検知する Terraform 例

resource "aws_cloudwatch_event_rule" "mediaconvert_job_complete" {
  name  = "mediaconvert-job-complete"
  description = "MediaConvert ジョブ完了通知"

  event_pattern = jsonencode({
 source= ["aws.mediaconvert"]
 detail-type = ["MediaConvert Job State Change"]
 detail = {
status = ["COMPLETE", "ERROR", "CANCELED"]
 }
  })
}

resource "aws_cloudwatch_event_target" "mediaconvert_sns" {
  rule= aws_cloudwatch_event_rule.mediaconvert_job_complete.name
  target_id = "MediaConvertJobSNS"
  arn = aws_sns_topic.mediaconvert_notification.arn
}

resource "aws_cloudwatch_metric_alarm" "mediaconvert_error_rate" {
  alarm_name = "mediaconvert-error-rate-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "1"
  metric_name= "TranscodeJobErrorCount"
  namespace  = "AWS/MediaConvert"
  period  = "300"
  statistic  = "Sum"
  threshold  = "5"
  alarm_description= "MediaConvert エラー率異常"
  alarm_actions = [aws_sns_topic.mediaconvert_notification.arn]
}

コスト追跡のベストプラクティス

1. タグ付け: Job に CostCenter / Project タグを付与し、Cost Explorer でプロジェクト別コストを可視化する
2. Reserved Queue 評価: 月間処理量が一定量を超えたら Reserved Queue への移行を定期的に試算する
3. 不要 Output Group 削除: 未使用の Output Preset が残るとコストが増加する。テスト後は必ず削除する
4. AV1 検討: H.264 比 50% 程度のファイルサイズ削減が可能。バッチ処理の余裕がある長時間コンテンツで検討する

次節では、VOD トランスコーディングを担う MediaConvert と対をなすライブエンコーディングサービス、Elemental MediaLive の本番運用設計を解説する。

§4 Elemental MediaLive 本番運用 — Channel × Input × Schedule × Pipeline redundancy × Live to VOD

§4.1 MediaLive とは — マネージドライブビデオエンコーディング

Elemental MediaLive は AWS が提供するマネージドのライブビデオエンコーディングサービスだ。放送局・スポーツ中継・ライブコマース・オンライン授業など、リアルタイムの映像配信が必要なシーンで広く活用される。MediaConvert がジョブベースの VOD 処理に特化しているのに対し、MediaLive はチャンネルベースの常時稼働型ライブエンコーディングを担う。

主要コンポーネントを整理しよう。

§4.2 Channel 設計 — Standard vs Single Pipeline

MediaLive Channel には Standard Pipeline と Single Pipeline の 2 種類があり、設計段階での選択が運用コストと可用性に直接影響する。

Standard Pipeline (2 Pipeline)

標準構成では Pipeline 1 と Pipeline 2 の 2 つが並列稼働し、どちらかが障害を起こしても自動フェイルオーバーで継続配信できる。本番の放送・ライブイベントでは Standard Pipeline を必須とする。

配信者 (OBS/Wirecast)
  → Primary Input→ Pipeline 1 (Active)  → Output Group → CloudFront
  → Secondary Input → Pipeline 2 (Standby) → (障害時に自動昇格)

Single Pipeline

1 Pipeline のみを使用する構成でコストは Standard Pipeline の約半額になる。ただしフェイルオーバー機能がないため、SLA 要件がない内部配信・テスト配信・低コスト優先の非商用配信に限定して使用する。

Pipeline コスト比較

Terraform で MediaLive Channel の基本設定を定義する例を示す。

resource "aws_medialive_channel" "live_channel" {
  name = "production-live-channel"
  channel_class = "STANDARD"

  input_attachments {
 input_attachment_name = "primary-rtmp-input"
 input_id  = aws_medialive_input.rtmp_primary.id

 input_settings {
source_end_behavior = "CONTINUE"
input_filter  = "AUTO"
filter_strength  = 1
deblock_filter= "DISABLED"
denoise_filter= "DISABLED"
 }
  }

  encoder_settings {
 video_descriptions {
name = "video_1080p"
width= 1920
height  = 1080
respond_to_afd= "NONE"
sharpness  = 50
scaling_behavior = "DEFAULT"

codec_settings {
  h264_settings {
 adaptive_quantization= "HIGH"
 bitrate  = 5000000
 buf_fill_pct= 90
 entropy_encoding  = "CABAC"
 flicker_aq  = "ENABLED"
 framerate_control = "INITIALIZE_FROM_SOURCE"
 gop_closed_cadence= 1
 gop_num_b_frames  = 2
 gop_size = 90
 gop_size_units = "FRAMES"
 level = "H264_LEVEL_AUTO"
 look_ahead_rate_control = "HIGH"
 num_ref_frames = 1
 par_control = "INITIALIZE_FROM_SOURCE"
 profile  = "HIGH"
 rate_control_mode = "CBR"
 scene_change_detect  = "ENABLED"
 spatial_aq  = "ENABLED"
 temporal_aq = "ENABLED"
  }
}
 }

 output_groups {
output_group_settings {
  hls_group_settings {
 destination {
destination_ref_id = "hls-output-destination"
 }
 codec_specification = "RFC_4281"
 index_n_segments = 10
 mode = "LIVE"
 output_selection = "MANIFESTS_AND_SEGMENTS"
 segment_length= 6
 segments_per_subdirectory = 10000
 stream_inf_resolution  = "INCLUDE"
  }
}

outputs {
  audio_description_names = ["audio_aac"]
  video_description_name  = "video_1080p"
  output_settings {
 hls_output_settings {
name_modifier = "_1080p"
segment_modifier = "$dt$"
 }
  }
}
 }
  }

  destinations {
 id = "hls-output-destination"
 settings { url = "s3ssl://output-bucket/live/1/" }
 settings { url = "s3ssl://output-bucket/live/2/" }
  }

  tags = {
 Environment = "production"
 Service  = "live-streaming"
  }
}

§4.3 Input 設計 — RTMP / RTP / MediaConnect / HLS

MediaLive は複数の入力タイプに対応している。配信現場の機材・ネットワーク環境に応じて適切な Input タイプを選択する。

RTMP Input の Terraform 設定例

resource "aws_medialive_input" "rtmp_primary" {
  name= "primary-rtmp-input"
  type= "RTMP_PUSH"
  input_security_groups = [aws_medialive_input_security_group.sg.id]

  destinations {
 stream_name = "live/primary"
  }
}

resource "aws_medialive_input_security_group" "sg" {
  whitelist_rules {
 cidr = "203.0.113.0/24"
  }
}

本番環境では whitelist_rules を配信者の固定 IP に限定し、不正な映像の差し込みを防ぐことが重要だ。0.0.0.0/0 のまま本番投入するケースが散見されるが、第三者による不正映像挿入のリスクがある。

Input Redundancy (入力冗長化)

Standard Pipeline では Primary Input と Backup Input の 2 系統を設定できる。Primary Input に障害が発生すると自動で Backup Input に切り替わり映像配信を維持する。

§4.4 Schedule — 入力切替 / スプライス / クリップ挿入

MediaLive の Schedule 機能は、チャンネル稼働中に時刻ベースのイベントを制御するための仕組みだ。事前にスケジュールを設定しておくことで複数の映像ソースを自動切り替えしたり CM 挿入タイミングを制御したりできる。

主要 Schedule アクション

AWS CLI で Schedule アクションを追加する例

aws medialive batch-update-schedule \
  --channel-id "1234567" \
  --creates '{
 "ScheduleActions": [{
"ActionName": "switch-to-backup-input",
"ScheduleActionStartSettings": {
  "FixedModeScheduleActionStartSettings": {
 "Time": "2024-12-01T11:00:00.000Z"
  }
},
"ScheduleActionSettings": {
  "InputSwitchSettings": {
 "InputAttachmentNameReference": "backup-rtmp-input"
  }
}
 }]
  }' \
  --region ap-northeast-1

Schedule の時刻指定は UTC 基準だ。日本時間 (JST = UTC+9) で考えている場合は必ず変換を確認すること。

§4.5 Live to VOD — MediaLive → S3 → MediaConvert → CloudFront

ライブ配信を終了後に VOD コンテンツとして再利用するパターンが「Live to VOD」だ。MediaLive の Archive 出力を活用することで、同一の映像エンコード処理で Live と VOD の両方をカバーできる。

Live to VOD の処理フロー

配信者 (OBS/Wirecast)
  → RTMP Input
  → MediaLive Channel (Standard Pipeline)
├─→ HLS Output Group → MediaPackage → CloudFront → 視聴者 (ライブ)
└─→ Archive Output Group → S3 (録画ファイル .ts)
↓ (ライブ終了後)
MediaConvert Job
↓
 HLS / DASH / CMAF 変換
↓
  S3 + CloudFront → 視聴者 (VOD)

Archive Output Group の Terraform 設定

output_groups {
  name = "archive-output"
  output_group_settings {
 archive_group_settings {
destination {
  destination_ref_id = "archive-s3-destination"
}
rollover_interval = 60
 }
  }

  outputs {
 audio_description_names = ["audio_aac"]
 video_description_name  = "video_1080p"
 output_name = "archive_1080p"
 output_settings {
archive_output_settings {
  name_modifier = "_archive"
  extension  = "ts"
  container_settings {
 m2ts_settings {
absent_input_audio_behavior = "ENCODE_SILENCE"
audio_frames_per_pes  = 2
pat_interval = 100
pmt_interval = 100
program_num  = 1
rate_mode = "CBR"
 }
  }
}
 }
  }
}

EventBridge でライブ終了を検知して MediaConvert をトリガーする

resource "aws_cloudwatch_event_rule" "medialive_channel_stopped" {
  name = "medialive-channel-stopped"
  event_pattern = jsonencode({
 source= ["aws.medialive"]
 detail-type = ["MediaLive Channel State Change"]
 detail= { state = ["IDLE"] }
  })
}

resource "aws_cloudwatch_event_target" "trigger_mediaconvert" {
  rule= aws_cloudwatch_event_rule.medialive_channel_stopped.name
  target_id = "TriggerMediaConvertJob"
  arn = aws_lambda_function.start_mediaconvert.arn
}

§4.6 コスト設計 — チャンネル稼働時間課金

MediaLive は「チャンネルが起動している時間」に対して課金される。停止しているチャンネルは課金されないため、必要な時間帯だけ起動するコスト最適化が重要だ。

コスト計算の主要因子

コスト最適化 Tip

1. イベント配信は EventBridge Scheduler でチャンネルの自動起動・停止を制御する
2. テスト時は Single Pipeline + 最低解像度で検証コストを抑える
3. 長時間 (24 時間以上) 稼働する常設チャンネルは Reserved Channel (契約制) を検討する
4. Archive 出力先 S3 のライフサイクルを設定し、不要なアーカイブを自動削除する

次節では、ゲームサーバーのフルマネージドサービス GameLift の本番運用設計を解説する。Fleet × FlexMatch × Spot Instance の最適化でコストを抑えながらプレイヤー体験を最大化する方法を体系化する。

§5 GameLift 本番運用 — Fleet × FlexMatch × Spot Instance × Game Session Queue × Anywhere ★山場2

Amazon GameLift はフルマネージドのゲームサーバーホスティングサービス。ゲームインフラの運用負荷 (スケーリング・障害対応・マッチメイキング) を AWS に移譲し、開発チームがゲームロジックに集中できる環境を提供する。サーバーレス型 Realtime Server (Node.js ベースの簡易ゲーム向け) と、C++ / C# の Custom Server (本格タイトル向け) の 2 種類に対応する。

GameLift の主要コンポーネントは次の 4 層で構成される。

5-1 Fleet 設計 — On-Demand vs Spot vs Anywhere

On-Demand Fleet はスポット中断のない安定稼働が必要なランクマッチやトーナメント向け。Spot Fleet はコスト最適化優先のカジュアルマッチ向けで、通常 On-Demand 比 60〜80% 削減が見込める。Anywhere Fleet はオンプレミスや別クラウドの自前サーバーを GameLift の管理下に置く形態。

Fleet を Terraform で定義する例を示す。

resource "aws_gamelift_build" "game_server" {
  name = "my-game-server"
  operating_system = "AMAZON_LINUX_2"

  storage_location {
 bucket= aws_s3_bucket.builds.bucket
 key= "builds/game-server-v1.0.zip"
 role_arn = aws_iam_role.gamelift_build.arn
  }
}

resource "aws_gamelift_fleet" "spot_fleet" {
  name = "my-game-spot-fleet"
  build_id= aws_gamelift_build.game_server.id
  ec2_instance_type= "c5.large"
  fleet_type = "SPOT"
  new_game_session_protection_policy = "FullProtection"

  runtime_configuration {
 game_session_activation_timeout_seconds = 300
 max_concurrent_game_session_activations = 1

 server_process {
concurrent_executions = 1
launch_path  = "/local/game/GameServer"
 }
  }

  ec2_inbound_permission {
 from_port = 1935
 to_port= 1935
 ip_range  = "0.0.0.0/0"
 protocol  = "UDP"
  }
}

new_game_session_protection_policy = "FullProtection" を設定すると、アクティブなゲームセッションが存在するインスタンスは Auto-scaling のスケールインや Spot 中断から保護される。Spot Fleet では必ずこの設定を有効にする。

5-2 FlexMatch — マッチメイキングルール・バックフィル・カスタムロジック

FlexMatch は GameLift 内蔵のマッチメイキングエンジン。JSON で記述したルールセットに基づき、プレイヤーをチームに振り分ける。

{
  "name": "my-matchmaking-ruleset",
  "ruleLanguageVersion": "1.0",
  "playerAttributes": [
 {
"name": "skill",
"type": "number"
 },
 {
"name": "latency",
"type": "number",
"default": 9999
 }
  ],
  "teams": [
 {
"name": "red",
"minPlayers": 4,
"maxPlayers": 4
 },
 {
"name": "blue",
"minPlayers": 4,
"maxPlayers": 4
 }
  ],
  "rules": [
 {
"name": "skill-balance",
"type": "comparison",
"measurements": ["avg(teams[*].players.attributes[skill])"],
"operation": "abs_difference",
"threshold": 10
 },
 {
"name": "latency-limit",
"type": "latency",
"maxLatency": 80
 }
  ],
  "expansions": [
 {
"target": "rules[skill-balance].threshold",
"steps": [
  {"waitTimeSeconds": 60, "value": 20},
  {"waitTimeSeconds": 120, "value": 50}
]
 },
 {
"target": "rules[latency-limit].maxLatency",
"steps": [
  {"waitTimeSeconds": 60, "value": 150}
]
 }
  ]
}

expansions が核心。待機 60 秒後にスキル差許容幅を 10→20、120 秒後に 50 まで拡大する。レイテンシも 80ms→150ms と段階的に緩和し、長時間待機を防ぐ。

バックフィル: 試合途中で参加プレイヤーが離脱した場合、FlexMatch のバックフィルリクエストを自動送信して欠員補充ができる。Automatic Backfill (SDK から自動) と Manual Backfill (アプリ側でリクエスト制御) の 2 方式がある。PvP タイトルでは Manual で欠員補充タイミングをゲームロジック側が制御するケースが多い。

カスタムロジック: FlexMatch の組み込みルールでは表現しきれない複雑なマッチ条件 (勝率・行動スコアなど) は、マッチメイキングイベントを EventBridge 経由で Lambda に渡し、カスタム判定後に FlexMatch へ結果を返すハイブリッド構成で実現する。

5-3 Game Session Queue — 複数Fleet横断・レイテンシポリシー・エイリアス

Game Session Queue は複数のリージョン・Fleet をまたいでゲームセッションを最適配置するためのルーターコンポーネント。

resource "aws_gamelift_fleet" "ondemand_fleet" {
  name  = "my-game-ondemand-fleet"
  build_id = aws_gamelift_build.game_server.id
  ec2_instance_type = "c5.xlarge"
  fleet_type  = "ON_DEMAND"

  new_game_session_protection_policy = "FullProtection"

  runtime_configuration {
 max_concurrent_game_session_activations = 2
 server_process {
concurrent_executions = 2
launch_path  = "/local/game/GameServer"
 }
  }
}

resource "aws_gamelift_alias" "ondemand_alias" {
  name = "ondemand-fallback"

  routing_strategy {
 type  = "SIMPLE"
 fleet_id = aws_gamelift_fleet.ondemand_fleet.id
  }
}

resource "aws_gamelift_game_session_queue" "main" {
  name = "my-game-queue"
  timeout = 600

  player_latency_policy {
 maximum_individual_player_latency_milliseconds = 100
 policy_duration_seconds= 60
  }

  player_latency_policy {
 maximum_individual_player_latency_milliseconds = 200
  }

  destinations {
 destination_arn = aws_gamelift_fleet.spot_fleet.arn
  }

  destinations {
 destination_arn = aws_gamelift_alias.ondemand_alias.arn
  }
}

エイリアス は Fleet の論理名。Fleet を差し替える際にエイリアスの向き先を切り替えるだけでよく、クライアント設定変更不要でブルーグリーンデプロイが実現できる。本番運用では Queue の destinations に直接 Fleet ARN を指定せず、必ずエイリアス ARN を使う。

player_latency_policy の多段設定は重要。最初の 60 秒は 100ms 以内の Fleet のみを対象とし、それ以降は 200ms まで許容範囲を拡大する。この設定でレイテンシ優先の配置を確保しつつ、最終的にはどのプレイヤーにもセッションが割り当たるフェイルセーフを実現する。

5-4 Spot Instance 活用 — 中断対応とOn-Demand fallback設計

GameLift Spot Instance は通常の EC2 Spot と異なり、Spot Interruption Notice を GameLift SDK 経由でゲームサーバーが受け取れる。通知受信後 2 分以内に以下の対応を実装する。

Spot 中断フロー:
  1. GameLift → ゲームサーバー SDK に OnProcessTerminate() コールバック通知
  2. ゲームサーバー: 新規セッション受付停止 → 現在セッションにゲーム内通知
  3. GameLift: FullProtection 設定のインスタンスはセッション終了まで中断保留
  4. セッション終了後: インスタンス回収 → Queue が On-Demand Fleet に自動再配置
  5. クライアント: SDK の再接続ロジック → 新規 Game Session に自動復帰

実装の要点は OnProcessTerminate() コールバック内で現在のゲームセッションを graceful に終了し、GameLiftServerSDK::TerminateGameSession() を呼び出すこと。このハンドラーを未実装のまま Spot 運用すると、中断時にプレイヤーが強制切断される。

コスト削減効果の目安: Spot Fleet を全体の 70% に設定し、残り 30% を On-Demand で fallback 確保するモデルが多くのタイトルで採用されている。この構成でインフラコスト 40〜60% 削減を達成しつつ、中断率は一般的に 5% 未満に抑えられる。

5-5 GameLift Anywhere — オンプレ・別クラウドをGameLift管理下に統合

GameLift Anywhere を使うと、AWS 外 (オンプレミス・別クラウド・開発者のローカルマシン) のゲームサーバーを GameLift の Fleet として登録できる。FlexMatch や Game Session Queue による統一マッチメイキングとセッション管理を維持したまま、既存インフラを段階的にクラウド移行する際に最も有効なアプローチ。

セットアップの流れ:

# Anywhere の Location を登録
aws gamelift create-location \
  --location-name "custom-onprem-datacenter"

# Anywhere Fleet を作成
aws gamelift create-fleet \
  --name "onprem-anywhere-fleet" \
  --compute-type ANYWHERE \
  --locations "Location=custom-onprem-datacenter"

# オンプレサーバーを Compute として登録
aws gamelift register-compute \
  --fleet-id "fleet-xxxx" \
  --compute-name "onprem-server-01" \
  --ip-address "203.0.113.10" \
  --location "custom-onprem-datacenter"

# 認証トークン取得 (ゲームサーバープロセス起動前に実行)
aws gamelift get-compute-auth-token \
  --fleet-id "fleet-xxxx" \
  --compute-name "onprem-server-01"

Anywhere Fleet では AWS への通信のために GameLift SDK の初期化時に取得した認証トークンを渡す。トークンは 15 分で失効するため、更新ロジックをゲームサーバーのライフサイクルに組み込む。

5-6 Auto-scaling — ゲームセッション数ベースのスケーリング

GameLift Auto-scaling はゲームセッション稼働率 (Utilization) をメトリクスとしてスケーリングを制御する。EC2 Auto Scaling とは独立した GameLift 独自の仕組みで、TargetBasedScaling と RuleBasedScaling の 2 方式がある。

resource "aws_gamelift_scaling_policy" "session_utilization" {
  fleet_id  = aws_gamelift_fleet.spot_fleet.id
  name= "target-available-sessions"
  policy_type  = "TargetBased"
  metric_name  = "PercentAvailableGameSessions"
  target_value = 25.0

  scaling_adjustment_type = "ChangeInCapacity"

  min_size = 2
  max_size = 50
}

PercentAvailableGameSessions = 25% の Target-based スケーリングは「空きセッション容量を常に 25% 維持」するポリシー。急激なアクセス増加時にも事前に余裕容量を確保するため、プレイヤー待機時間を最小化できる。

重要な CloudWatch メトリクス:

5-7 コスト最適化

GameLift のコストドライバーは Fleet インスタンス稼働時間とデータ転送量の 2 つ。ゲームサーバーは常時起動が必要なため、コスト最適化には以下の 3 軸が効く。

1. Spot Fleet 比率の引き上げ: 耐障害性を実装済みのゲームなら Spot 比率を 70〜90% まで引き上げられる。On-Demand fallback を 10〜30% 残すことで中断時の UX 劣化を防ぐ。
2. Auto-scaling の精緻化: 1 インスタンスあたりの並行セッション数 (concurrent_executions) をベンチマークして最大化する。セッション密度が低いままスケールアウトするのが最も無駄。
3. Game Session Queue による最安 Fleet 優先: Queue の destinations 順序は優先度順。Spot Fleet を先頭に置くことで、Spot に空きがある間は On-Demand を使わない配置を実現する。

GameLift 公式ドキュメント

§5 で解説した GameLift の各コンポーネント (Fleet / FlexMatch / Queue / Anywhere / Auto-scaling) は単体ではなく、連動して機能する。次の §6 では AppStream / MediaConvert / MediaLive / GameLift の 4 本柱で実際に詰まりやすいポイントを 7 選に絞り、判断ツリーと対処法を整理する。

§6 詰まりポイント7選 図解

AppStream 2.0 / MediaConvert / MediaLive / GameLift を本番運用で扱う際に SRE チームが繰り返し直面する落とし穴を7パターンで整理する。症状・原因・解の構造で解説し、Mermaid 判断ツリーで問題箇所を素早く特定できるよう体系化した。

詰まり1: AppStream Image更新 → Image Builder 再実行 / Fleet 切替手順

症状: アプリをアップデートしたのに既存ユーザーのセッションに変更が反映されない。古いイメージを参照した Fleet が残っている。

原因: AppStream では Image Builder で新しいイメージを作成した後、Fleet の「Update Image」操作が別途必要。Active セッション中の切替タイミングを制御しないと、ユーザーが強制切断されるリスクがある。

解:
1. Image Builder で新バージョンのイメージを作成・公開
2. Maintenance Window (深夜帯) を定義し Fleet の「Update Fleet Image」を実行
3. 既存セッション保護のため MaxConcurrentSessions に余裕を持たせる
4. Fleet が Healthy になってから旧イメージを削除

# Fleet Image 更新 (AWS CLI)
aws appstream update-fleet \
  --name prod-fleet \
  --image-name my-app-v2 \
  --desired-capacity 10

# 旧イメージ削除前に Fleet 参照を確認
aws appstream describe-fleets \
  --query 'Fleets[*].{Name:Name,Image:ImageName}'

詰まり2: MediaConvert Codec 選定 → HLS vs DASH vs CMAF 適用基準

症状: 配信先デバイスによって再生できない形式が混在し、Output Group 設定を試行錯誤で繰り返している。

原因: HLS / DASH / CMAF はそれぞれ最適なユースケースが異なるが、判断基準なく「とりあえず HLS」で設定すると Android / Smart TV での再生問題が頻発する。

解:
– iOS デバイス優先: HLS (MPEG-2 TS または fMP4 セグメント)
– Android / Web ブラウザ: DASH (fMP4 セグメント)
– DRM 要件あり / 統合配信: CMAF (HLS + DASH 兼用 / Widevine + FairPlay 対応)
– 超低遅延配信 (1-2s): CMAF Low-Latency + MediaPackage

{
  "OutputGroups": [
 {
"OutputGroupSettings": {
  "Type": "HLS_GROUP_SETTINGS",
  "HlsGroupSettings": {
 "SegmentLength": 6,
 "MinSegmentLength": 0
  }
}
 }
  ]
}

詰まり3: MediaLive Pipeline 冗長化 → Standard vs Single Pipeline 判断

症状: ライブ配信中に突然 Channel が停止。Single Pipeline 構成のため自動フェイルオーバーが機能しなかった。

原因: MediaLive には Single Pipeline (1系統) と Standard Pipeline (2系統 Active-Active) があるが、コスト削減を優先して Single Pipeline を選ぶと単一障害点になる。

解:
– 本番ライブ配信 (SLA 99.9%以上): Standard Pipeline を選択。料金は約2倍だが自動フェイルオーバー付き
– テスト / 非クリティカル配信: Single Pipeline でコスト削減
– Standard Pipeline では Pipeline 1 が異常でも Pipeline 0 が継続配信し、自動切替を CloudWatch アラームで監視

resource "aws_media_live_channel" "live" {
  name = "prod-live-channel"
  channel_class = "STANDARD"

  input_specification {
 codec= "AVC"
 input_resolution = "HD"
 maximum_bitrate  = "MAX_20_MBPS"
  }
}

詰まり4: GameLift Spot Interruption → On-demand Fallback 設計

症状: Spot Instance が突然回収され、ゲームセッションが強制終了。プレイヤーからクレームが続出している。

原因: GameLift Spot Fleet はコスト削減効果が大きいが、Interruption Notice (2分前通知) の処理と On-demand への自動フォールバック設計が不十分。

解:
1. Game Session Queue を構成し Spot Fleet と On-demand Fleet を優先度付きで登録
2. Spot Fleet に Interruption Notice が来たら SDK 側でセッション移行処理を実装
3. Queue 設定で prioritizedLocations + playerLatencyPolicies を調整

{
  "Name": "prod-game-queue",
  "TimeoutInSeconds": 600,
  "PriorityConfiguration": {
 "PriorityOrder": ["COST", "LATENCY", "DESTINATION"]
  },
  "Destinations": [
 { "DestinationArn": "arn:aws:gamelift:ap-northeast-1::fleet/fleet-spot-id" },
 { "DestinationArn": "arn:aws:gamelift:ap-northeast-1::fleet/fleet-ondemand-id" }
  ]
}

詰まり5: コスト最適化罠 → AppStream Always-on Fleet / GameLift 無駄起動の検知と対処

症状: 毎月のコストが予想を大幅超過。AppStream の Fleet と GameLift の Fleet が業務時間外も常時稼働している。

原因: AppStream の Always-on Fleet と GameLift の On-demand Fleet は使用ゼロでも課金が発生する。Auto-scaling や Schedule 設定なしで放置すると無駄コストが膨らむ。

解:
– AppStream: Always-on → On-demand / Elastic に変更し、Business Hours Schedule で容量を制御
– GameLift: CloudWatch Alarm + Auto-scaling で最小容量を業務時間外に 1 に絞る
– Cost Anomaly Detection で急増を早期検知

# AppStream Fleet スケールダウンスケジュール (夜間)
aws application-autoscaling put-scheduled-action \
  --service-namespace appstream \
  --resource-id fleet/prod-fleet \
  --scheduled-action-name scale-down-night \
  --schedule "cron(0 20 * * ? *)" \
  --scalable-target-action MinCapacity=0,MaxCapacity=0

# 朝のスケールアップ
aws application-autoscaling put-scheduled-action \
  --service-namespace appstream \
  --resource-id fleet/prod-fleet \
  --scheduled-action-name scale-up-morning \
  --schedule "cron(0 8 * * ? *)" \
  --scalable-target-action MinCapacity=5,MaxCapacity=20

詰まり6: ライセンス管理 → AppStream BYOL / Windows SAL / 監査証跡の残し方

症状: Microsoft ライセンス監査対応で AppStream の Windows SAL (Subscriber Access License) が不十分と指摘された。BYOL 設定が正しく機能しているか不明。

原因: AppStream BYOL は既存の Windows Server SA ライセンスを持ち込む機能だが要件が厳格。不完全な設定では監査で違反とみなされる。

解:
– BYOL を利用する場合: Image Builder で BYOL イメージを作成し、Windows SA ライセンス要件 (1ユーザー 1 SA) を満たす
– SAL (Subscriber Access License) は Microsoft とのボリュームライセンス契約が前提
– 監査証跡: CloudTrail で AppStream セッション作成ログを S3 に保存し 7 年間保管

# CloudTrail で AppStream セッションログを確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateStreamingURL \
  --start-time 2026-01-01T00:00:00Z \
  --end-time 2026-05-22T00:00:00Z \
  --query 'Events[*].{Time:EventTime,User:Username}'

詰まり7: Network 設計 → AppStream VPC / MediaLive VPC / GameLift Anywhere ネットワーク分離

症状: AppStream のユーザーが内部リソースにアクセスできない。MediaLive が S3 バケットへの出力に失敗する。GameLift Anywhere でオンプレサーバーとの通信が不安定。

原因: AppStream / MediaLive / GameLift Anywhere はそれぞれ独立した VPC / Subnet / Security Group 設計が必要。共通 VPC に混在させると権限分離・帯域設計が崩れる。

解:
– AppStream: Private Subnet に Fleet を配置し、NAT Gateway + VPC Endpoint (S3 / AD) で外部接続
– MediaLive: Input / Output に専用 Security Group (RTMP 1935, HLS 443) を設定し、S3 出力は VPC Endpoint 経由
– GameLift Anywhere: Site-to-Site VPN または Direct Connect でオンプレ ↔ AWS の専用回線を確保

# AppStream VPC Endpoint (S3)
resource "aws_vpc_endpoint" "s3_appstream" {
  vpc_id= aws_vpc.appstream.id
  service_name= "com.amazonaws.ap-northeast-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [aws_route_table.private.id]
}

# MediaLive Security Group (RTMP Input)
resource "aws_security_group" "medialive_input" {
  name= "medialive-input-sg"
  vpc_id = aws_vpc.medialive.id

  ingress {
 from_port= 1935
 to_port  = 1935
 protocol = "tcp"
 cidr_blocks = ["203.0.113.0/24"]
  }
}

詰まりポイント7選の判断ツリーを Mermaid で整理する。問題発生時にこのフローに従って診断することで、対処法まで素早く到達できる。

flowchart TD
 A[Game/Media問題発生] --> B{AppStream Image更新?}
 B -->|Yes| C[Image Builder再実行+Fleet切替確認]
 B -->|No| D{MediaConvert Codec選定?}
 D -->|Yes| E[HLS/DASH/CMAF判断基準確認]
 D -->|No| F{MediaLive Pipeline冗長化?}
 F -->|Yes| G[Standard vs Single pipeline確認]
 F -->|No| H{GameLift Spot中断?}
 H -->|Yes| I[On-demand fallback Queue設計]
 H -->|No| J{コスト超過?}
 J -->|Yes| K[Always-on/無駄起動検知]
 J -->|No| L{ライセンス問題?}
 L -->|Yes| M[BYOL/SAL監査証跡確認]
 L -->|No| N[Network設計・VPC分離確認]

§7 アンチパターン → 正解パターン変換演習 (5問)

Game/Media 本番運用で頻出するアンチパターンと、AWS サービスを使った正解パターンの変換演習。各問、Before (悪い例) → After (良い例) + 解説の形式で学ぶ。

Q1: Desktop 手動配信 → AppStream 2.0

状況: ゲーム会社の社内ツール (映像編集アプリ / ゲーム開発 IDE) を各エンジニアの PC に手動インストールして配信している。バージョン管理が煩雑でセキュリティポリシーの統一が困難。

Before (アンチパターン):

各開発者 PC に個別インストール (手動管理)
- ソフトウェアバージョンが各自バラバラ
- VPN 経由でオンプレリソースへ接続 → レイテンシ問題
- ライセンスの追跡が困難
- セキュリティパッチの適用漏れが発生しやすい

After (正解パターン):

resource "aws_appstream_image_builder" "dev_tools" {
  name = "dev-tools-image-builder"
  instance_type = "stream.graphics.g4dn.xlarge"
  image_name = "AppStream-WinServer2019-03-13-2024"
  vpc_config {
 subnet_ids= [aws_subnet.private.id]
 security_group_ids = [aws_security_group.appstream.id]
  }
  enable_default_internet_access = false
}

resource "aws_appstream_fleet" "dev_fleet" {
  name = "dev-tools-fleet"
  instance_type = "stream.graphics.g4dn.xlarge"
  fleet_type = "ON_DEMAND"
  compute_capacity { desired_instances = 5 }
  vpc_config {
 subnet_ids= [aws_subnet.private.id]
 security_group_ids = [aws_security_group.appstream.id]
  }
}

解説: AppStream 2.0 により、Image Builder で標準化されたアプリイメージを一元管理。Fleet の On-demand 設定でコストを最適化。Active Directory 連携でユーザー認証を統一し、Session Scripts で起動時に個人設定を動的適用できる。ライセンスは SAL で一元追跡。

Q2: 手動 MP4 変換 → MediaConvert Job Template

状況: 映像コンテンツを手動で ffmpeg を使って MP4 変換しアップロードしている。品質が担当者によってバラつき、変換設定の再現性がない。

Before (アンチパターン):

# 手動 ffmpeg 変換 (品質バラつき / 属人的)
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
# 問題点:
# - 設定がドキュメント化されておらず属人化
# - HLS 変換未対応 / DRM 未適用
# - エラー時の再実行が手動

After (正解パターン):

{
  "Name": "HLS-Standard-Template",
  "Settings": {
 "OutputGroups": [
{
  "OutputGroupSettings": {
 "Type": "HLS_GROUP_SETTINGS",
 "HlsGroupSettings": {
"SegmentLength": 6,
"Destination": "s3://output-bucket/hls/"
 }
  },
  "Outputs": [
 {
"VideoDescription": {
  "CodecSettings": {
 "Codec": "H_264",
 "H264Settings": {
"Bitrate": 5000000,
"GopSize": 60
 }
  }
}
 }
  ]
}
 ]
  }
}

解説: MediaConvert の Job Template で変換設定を標準化し、S3 Event Trigger → Lambda → MediaConvert の完全自動化パイプラインを構築。品質の一貫性が保証され、DRM 設定 (Widevine/FairPlay) も Template で一元管理できる。

Q3: 単一 Pipeline → MediaLive Pipeline Redundancy

状況: スポーツライブ配信で MediaLive Single Pipeline を使用。本番放送中に Channel が停止し、配信断が発生した。

Before (アンチパターン):

resource "aws_media_live_channel" "live" {
  name = "sports-live"
  channel_class = "SINGLE_PIPELINE"
  # 問題点:
  # - Pipeline 障害 → 自動フェイルオーバーなし
  # - 手動復旧に 5-15 分必要
  # - SLA 99.9% を満たせない
}

After (正解パターン):

resource "aws_media_live_channel" "live" {
  name = "sports-live"
  channel_class = "STANDARD"

  input_attachments {
 input_attachment_name = "rtmp-primary"
 input_id  = aws_media_live_input.primary.id
 input_settings {
source_end_behavior = "CONTINUE"
 }
  }
}

resource "aws_cloudwatch_metric_alarm" "pipeline_alert" {
  alarm_name = "medialive-pipeline-error"
  comparison_operator = "GreaterThanThreshold"
  metric_name= "DroppedFrames"
  namespace  = "AWS/MediaLive"
  threshold  = 100
  alarm_actions = [aws_sns_topic.ops_alert.arn]
}

解説: channel_class = "STANDARD" に変更するだけで Active-Active Pipeline になり、一方の Pipeline 障害時に自動フェイルオーバーする。コストは約2倍になるが、本番ライブ配信の SLA 要件を満たすには必須の設定。CloudWatch アラームで DroppedFrames > 100 を監視し即時通知する。

Q4: Always-on Fleet → GameLift Auto-scaling + Spot

状況: GameLift On-demand Fleet を24時間稼働させているが、深夜 1:00-8:00 のゲームサーバー使用率が 5% 未満なのにフルスケールで課金されている。

Before (アンチパターン):

{
  "Name": "prod-game-fleet",
  "FleetType": "ON_DEMAND",
  "EC2InstanceType": "c5.2xlarge",
  "DesiredEC2Instances": 20,
  "MinSize": 20,
  "MaxSize": 20
}

After (正解パターン):

{
  "Name": "prod-game-fleet-spot",
  "FleetType": "SPOT",
  "EC2InstanceType": "c5.2xlarge",
  "ResourceCreationLimitPolicy": {
 "NewGameSessionsPerCreator": 3,
 "PolicyPeriodInMinutes": 1
  }
}

# Auto-scaling ポリシー設定
aws gamelift put-scaling-policy \
  --fleet-id fleet-spot-id \
  --name "scale-on-sessions" \
  --scaling-adjustment-type PercentChangeInCapacity \
  --scaling-adjustment 25 \
  --threshold 70 \
  --comparison-operator GreaterThanThreshold \
  --metric-name PercentAvailableGameSessions

解説: Spot Fleet + Auto-scaling に切り替えることで On-demand 比 最大 70% のコスト削減が可能。Interruption 対策には Game Session Queue で On-demand Fleet をバックアップとして登録。深夜の最小キャパシティを 2 に設定し、緊急時のみスケールアップ。

Q5: オンプレゲームサーバー → GameLift Anywhere

状況: 既存のオンプレサーバー (専用ゲームサーバー) を GameLift のマッチメイキング・ロビー機能と組み合わせたいが、完全移行はリスクが高い。段階的なクラウド統合が必要。

Before (アンチパターン):

オンプレ独自マッチメイキング
- スケーラビリティなし
- GameLift FlexMatch 未活用
- 地域ごとのレイテンシ最適化なし
- 運用コストが高い (サーバー維持 + 独自開発)
- クラウド移行のロードマップが描けない

After (正解パターン):

# Custom Location 作成
aws gamelift create-location \
  --location-name custom-location-tokyo

# GameLift Anywhere Fleet 作成
aws gamelift create-fleet \
  --name "hybrid-anywhere-fleet" \
  --compute-type ANYWHERE \
  --anywhere-configuration '{"Cost":"0.015"}'

# オンプレサーバーを Anywhere Fleet に登録
aws gamelift register-compute \
  --fleet-id fleet-anywhere-id \
  --compute-name onprem-server-tokyo-01 \
  --ip-address 203.0.113.10 \
  --location custom-location-tokyo

解説: GameLift Anywhere により既存オンプレサーバーを GameLift のエコシステムに組み込み、FlexMatch によるマッチメイキング・ロビー機能をそのまま活用できる。段階的移行が可能で、オンプレ → AWS のクラウドシフトリスクを最小化できる。Anywhere Fleet と AWS Fleet を同一 Queue に登録することでハイブリッド運用が実現。

§8 まとめ + 第20軸目 Game/Media 起点 + 48記事化告知 + 全軸クロスリンクナビ

§8-1 本記事のまとめ

本記事では AWS Game/Media 本番運用の主要4サービスを体系的に解説した。各サービスの要点を振り返る。

AppStream 2.0 のポイント

AppStream 2.0 は企業向けマネージドデスクトップ配信サービス。Image Builder でアプリイメージを標準化し、Fleet で配信基盤を構築する。Always-on / On-demand / Elastic の3種 Fleet から用途に応じて選択する。Auto-scaling と Schedule の組み合わせで業務時間外のコストを最大 60% 削減できる。BYOL と Windows SAL のライセンス管理は監査対応に備えた証跡の整備が不可欠。VPC 設計は Private Subnet + VPC Endpoint で外部通信を最小化し、Active Directory 連携でユーザー認証を統一する。Image Builder → Fleet Image 更新 → Active Session 保護の手順を Runbook 化しておくことで、アップデート時の停止リスクを最小化できる。

MediaConvert のポイント

Elemental MediaConvert は VOD 映像処理のマネージドサービス。Job Template で変換設定を標準化し属人化を排除できる。Output Group の選択 (HLS / DASH / CMAF) はデバイス対応要件と DRM 要件から判断する。iOS 向けは HLS、Android + Web 向けは DASH、マルチデバイス + DRM には CMAF が最適解。S3 Event → Lambda → MediaConvert の完全自動化パイプラインにより手動変換作業をゼロにできる。Queue の Priority 設定で緊急コンテンツを優先処理し、通常変換との並列実行でスループットを最大化する。

MediaLive のポイント

Elemental MediaLive はライブ映像処理のマネージドサービス。Pipeline Redundancy (Standard vs Single) の選択が可用性を左右する。本番ライブ配信は Standard Pipeline 必須。Schedule 機能で広告挿入・番組切替を自動化し、Live to VOD アーカイブで S3 → MediaConvert の後処理パイプラインを構築する。CloudWatch メトリクス (DroppedFrames / NetworkIn) で配信品質をリアルタイム監視し、異常時は SNS で即時通知する体制が必要。MediaPackage との組み合わせで HLS / DASH 両対応のオリジンサーバーを構成できる。

GameLift のポイント

Amazon GameLift はマネージドゲームサーバーホスティングサービス。Spot Instance を活用することで On-demand 比 最大 70% のコスト削減が可能。Spot Interruption への対応は Game Session Queue に On-demand Fleet をバックアップとして登録する設計が安定する。FlexMatch によるスキルベースマッチメイキングを活用することでプレイヤー体験を向上させ、離脱率を削減できる。GameLift Anywhere によるオンプレハイブリッドは段階的なクラウドシフトに最適な移行経路を提供する。Auto-scaling の閾値は PercentAvailableGameSessions を 70% として設定し、ピーク時に自動拡張する構成が推奨される。

§6 詰まりポイント7選の総括

AppStream Image 更新 → MediaConvert Codec 選定 → MediaLive Pipeline 冗長化 → GameLift Spot Fallback → コスト最適化 → ライセンス管理 → Network 設計の7パターンは、本番稼働後に必ず直面する課題。Mermaid 判断ツリーを活用して問題の発生箇所を素早く特定し、対処法を適用することで平均復旧時間 (MTTR) を大幅に短縮できる。各パターンの ep-box に示した「対処スナップショット」をインシデント発生時の初動チェックリストとして活用することを推奨する。

§7 アンチパターン演習の総括

手動配信 → AppStream / 手動 MP4 変換 → MediaConvert Job Template / Single Pipeline → Standard Pipeline / Always-on Fleet → Spot + Auto-scaling / オンプレゲームサーバー → GameLift Anywhere の5パターンは、いずれも「既存の運用習慣をそのまま AWS に持ち込んだ」結果発生するアンチパターン。AWS マネージドサービスの設計哲学 (自動化 / スケーラビリティ / コスト最適化) を受け入れることで、運用コストと可用性の両方を改善できる。

Vol1 読了後 想定 FAQ

Q1: AppStream 2.0 と Amazon WorkSpaces の違いは何ですか?

AppStream 2.0 はアプリケーションのストリーミング配信に特化したサービス。プールされた Fleet インスタンスを複数ユーザーで共有し、セッション終了後にユーザーデータは消去される。一方 WorkSpaces は個人専用の永続 Virtual Desktop (VDI)。ゲーム開発ツールや映像編集アプリの社内配信には AppStream 2.0 が適し、個人の作業環境が必要な場合は WorkSpaces を選択する。

Q2: MediaConvert と Elemental MediaPackage の役割はどう違いますか?

MediaConvert は VOD/Live の映像トランスコード (形式変換) を担当するサービス。MP4 → HLS / DASH などの変換を行う。MediaPackage はパッケージングとオリジンサーバーの役割を担い、DRM 適用・CDN 向け HLS/DASH エンドポイント提供・タイムシフト再生などを担当する。本番 VOD 配信では MediaConvert → S3 → CloudFront の構成が基本で、Live 配信では MediaLive → MediaPackage → CloudFront の構成が一般的。

Q3: GameLift Spot Instance の中断率は実際どの程度ですか?

AWS の公開情報ではリージョン・インスタンスタイプによって異なるが、ゲームワークロードでよく使われる c5 / m5 系では月平均中断率 5-10% 程度が目安。ゲームセッション中の中断は即プレイヤー影響になるため、必ず On-demand Fleet を Game Session Queue にフォールバックとして登録し、FullProtection ポリシーでアクティブセッション中断を防止する構成が必須。

Q4: MediaLive Standard Pipeline にアップグレードするとコストは倍になりますか?

基本的には Standard Pipeline は Single Pipeline の約2倍のコスト (2 系統のインスタンス課金)。ただし Scheduled Channel (特定時間のみ稼働) と組み合わせることでコスト増を最小化できる。24時間稼働の場合は2倍だが、1日4時間のライブ配信であれば月額コストの絶対値は抑えられる。本番ライブ配信の SLA 要件とコストのトレードオフとして、通常は Standard Pipeline 採用が正解。

Q5: AppStream BYOL はどのようなライセンス種類に対応していますか?

AppStream BYOL (Bring Your Own License) は主に Microsoft Windows Server SA (Software Assurance) と、その上で動作するアプリケーションの既存ライセンス持ち込みに対応する。対象: Microsoft Office 365 / Visual Studio / Adobe Creative Cloud (ライセンスポータル対応版) など。BYOL を利用するには AWS との BYOL 合意と、Microsoft とのボリュームライセンス/SA 契約が前提。詳細は AWS 公式の AppStream BYOL ガイドと Microsoft ライセンス要件を必ず確認すること。

§8-4 第20軸目 Game/Media 全軸接続図

Game/Media Vol1 が既存シリーズとどのように接続するかを Mermaid で可視化する。各軸の詳細は対応する本番運用シリーズ記事を参照されたい。

graph LR
  GM[Game/Media Vol1 第20軸目起点] --> CONT[Container Vol1-3]
  GM --> AI[AI/ML Vol1-3]
  GM --> DEV[DevOps Vol1-3]
  GM --> OBS[Observability Vol1-2]
  GM --> SRV[Serverless Vol1-2]
  GM --> DB[Database Vol1-4]
  GM --> IOT[IoT Vol1]
  GM --> EDGE[Edge/CDN Vol1]
  GM --> STG[Storage Vol1-2]
  GM --> NET[Network Vol1-2]
  GM --> SEC[Security Vol1-3]

Game/Media 領域の AWS 実装は、単一サービスで完結するのではなく、既存19軸との組み合わせで真価を発揮する。たとえば AppStream Image Builder の自動更新は DevOps 軸の CodePipeline で、GameLift のゲームセッション状態管理は Database 軸の DynamoDB と組み合わせることで、完全自動化されたゲーム基盤が実現できる。

§8-5 全軸クロスリンクナビ + 読者 CTA

Game/Media 本番運用を進める際に合わせて参照すべき関連シリーズへのリンクをまとめる。各シリーズは Game/Media 軸の設計・実装・運用と直接連携する。

IoT → Game/Media 連携: IoT デバイスからのゲームイベント収集・プレイヤー行動分析に IoT Core / Greengrass が活用できる。GameLift と組み合わせることでリアルタイムゲームデータパイプラインを構築できる。

IoT Vol1 — IoT Core × Greengrass × SiteWise × Device Defender

IoT Vol2 — IoT Events × IoT Analytics × IoT TwinMaker × IoT FleetWise

DevOps → Game/Media 連携: AppStream Image Builder の自動更新パイプライン、MediaConvert Job Template の CI/CD 管理、GameLift Fleet の Blue/Green デプロイは CodePipeline / CDK Pipelines で完全自動化できる。

DevOps Vol3 — CodePipeline V2 × CDK Pipelines × GitOps

Database → Game/Media 連携: ゲームのプレイヤーセッション管理 / スコアランキング / 映像メタデータ管理には Aurora DSQL / DynamoDB Strong が最適。低レイテンシ要件の厳しいゲーム用途に対応している。

Database Vol4 — Aurora DSQL × Limitless × DynamoDB Strong

Game/Media 領域の AWS 本番運用に取り組む際は、本記事で解説した4本柱 (AppStream / MediaConvert / MediaLive / GameLift) の基礎を固めてから、隣接軸 (Container / DevOps / AI-ML / Database) との統合設計に進むことを推奨する。

AppStream 2.0 はエンタープライズのデスクトップ配信 DX として即効性が高い。MediaConvert + MediaLive は VOD/Live の映像処理基盤を手軽にマネージドで構築できる。GameLift は Spot + Auto-scaling + Anywhere のハイブリッド設計でコストと可用性を両立できる。詰まりポイント7選と演習5問を手元に置き、本番環境の設計・トラブル対応に役立てていただきたい。

本シリーズ 第20軸目 Game/Media は、エンタメ・メディア・ゲーム業界での AWS 採用を加速させるための実践的リファレンスとして設計した。各サービスの Terraform 完全例・Mermaid 判断ツリー・アンチパターン演習を通じて、実際の本番環境構築の自信を持って進めていただきたい。

Game/Media Vol1 を皮切りに、MediaPackage / MediaConnect / IVS (Interactive Video Service) / Kinesis Video Streams をカバーする Vol2 以降も順次公開予定。AWS Game/Media 本番運用シリーズの続報は watchittrend.com で更新していく。

Vol2 以降の予告内容 (予定):
– MediaPackage: オリジンサーバーのマネージド化 / DRM 適用 / タイムシフト再生 / Harvest Job
– MediaConnect: 放送グレード映像伝送 / Zixi / RIST / RTP プロトコル対応 / 冗長伝送設計
– IVS (Interactive Video Service): 超低遅延ライブ配信 (3-5秒) / チャット統合 / クイズ機能
– Kinesis Video Streams: カメラ映像取り込み / ML パイプライン連携 / 録画アーカイブ

各サービスの詳細解説と Terraform 完全例 / 詰まりポイント7選 / アンチパターン演習を Vol1 と同じ構成で提供予定。本シリーズの更新通知は watchittrend.com のニュースレターから受け取れる。

Game/Media 領域の AWS 実装を進める際に参照すべき追加リソース:
– AWS Elemental 公式ドキュメント (AppStream / MediaConvert / MediaLive / GameLift)
– AWS Well-Architected Framework — メディア配信ワークロードのベストプラクティス
– AWS GameTech ブログ — GameLift / FlexMatch の最新機能アップデート情報