AWS Organizations(2)AWSアカウントの管理

AWS Organizationsに関するホワイトペーパー

AWSの環境を整理するためのガイダンスとして、 Organizing Your AWS Environment Using Multiple Accountsというホワイトペーパーが公開されている。本稿ではその内容について整理/抜粋する。

会社によっては、セキュリティやコンプライアンスの制御が異なる複数のチームが存在する場合があり、明示的なセキュリティの境界、制限やスロットルの可視化、コストや請求の分離等を求めており、AWSアカウントによって環境を分離することでこれを実現できる。このホワイトペーパーは、Well-Architected Frameworkに基づいて、複数アカウントによるAWS環境の構築する方法を提示する。

複数アカウントを使用する利点

AWSを使用する際に複数のアカウントを使用するメリットは以下の通り。

  • ビジネスん目的と所有権に基づいてワークロードをグループ化し、他のワークロードの保護と依存関係や競合を回避する
  • 非本番環境と本番環境のように異なる環境下で異なるセキュリティ制御を適用する
  • 機密データへのアクセスを制御する
  • サンドボックスアカウントや開発アカウントを提供することにより、イノベーションや俊敏性を加速する
  • 問題や構成の誤り、悪意のあるアクションによる影響の範囲を制限する
  • 機能やワークロード別に複数のIT運用モデルをサポート
  • コストを管理する
  • サービスクオータを管理する

example-operating-models

設計原則

アカウント設計の設計原則は以下の通り。

  • 組織のレポート構造を反映するのではなく、機能やコンプライアンス要件などに基づいてOUを設計する
  • アカウントではなくOUにSCPなどのセキュリティガードレールを適用する
  • 深いOU階層は避ける
  • 数年後を見据えて設計するのではなく、小さく設計して必要に応じてOUを拡張する
  • 管理アカウントにはワークロードを展開しない
  • 本番ワークロードと非本番ワークロードを分離し、ワークロード指向のOUを構成する
  • 各本番アカウントには単一または小さなワークロードを割り当てる
  • SSOなどのフェデレーションアクセスを使用してアクセス管理を簡素化する

奨励されるOU構成

奨励されるOUはいくつか存在するがこの全てを作成する必要は無い。セキュリティOUとインフラストラクチャOUが基本となる。基本的なOUはクラウドエンジニアリングチームが所有する。

セキュリティOU

セキュリティOUには、ログアーカイブ、セキュリティツール、セキュリティ読み取り専用アクセス、セキュリティ用緊急アクセスの4つのアカウントを作成する。ログアーカイブアカウントには、CloudTrailのAPIアクセスログ、Configの変更ログ、VPCフローログなどの運用ログデータを保存する。セキュリティツールアカウントでは、SecurityHUb、GuardDuty、Config、IAM Access Analyzer、Detective、Macie、Firewall Managerなどを有効化する。なお、インシデント発生時の対応は、AWS Security Incident Response Guideを参照のこと。セキュリティ読み取り専用アクセスアカウントは、監査や調査のための読み取りアクセス用アカウント。このアカウントを使用する場合には、フェデレーションアクセスを使用することが奨励される。セキュリティ用緊急アクセスアカウントは、セキュリティインシデント発生時等に許可された管理者がアクセスを一時的に取得するために使用する。

Security
 ├ Prod
 │  ├ security-read-only-prod
 │  ├ security-break-glass-prod
 │  ├ security-tooling-prod
 │  └ log-archive-prod
 └ Test
    └ security-tiiling-test

インフラストラクチャOU

共通インフラストラクチャ用のOU。Site-to-Site VPN、 Direct Connect、 Transit Gateway、 DNSサービス、VPCエンドポイントなどが収容される。

Infrastructure
 ├ Prod
 │  ├ network-prod
 │  └ shared-infra-prod
 └ Test
    ├ network-test
    └ shared-infra-test

サンドボックスOU

ビルダーがAWSサービスを自由に実験できるアカウント。内部ネットワークからは隔離されている。実験は一時的かつ様々な用途が予想されることから、パージ処理の自動化や幅広いアクセス許可、非公開データを保管しないことなどが期待される。また、特定のプロダクトの開発環境とこのサンドボックス環境は明確に区別しておくことが奨励される。

Sandbox
 ├ sandbox-team-xxx
 └ sandbox-xxx

ワークロードOU

ワークロードOUは、本番環境とテスト環境の両方を含む。

Infrastructure
 ├ Prod
 │  ├ xxx-service-prod
 │  └ xxx-service-beta
 └ Test
    └ xxx-service-test

ポリシーステージングOU

AWS全体に影響が及ぶポリシーを管理するチームが、ポリシーの変更を適用する前に安全にテストするためのOU。ワークロード固有のポリシー変更時はこのOUでテストする必要は無い。このOUでテストしたあとは、目的のOUに新たなポリシーを一時的に関連付けることが奨励される。

PolicyStaging
 ├ Security
 │  ├ Prod
 │  │  └ security-prod-policy-staging
 │  └ Test
 │     └ security-test-policy-staging
 └ Infrastructure
    ├ Prod
    │  └ infra-prod-policy-stating
    └ Test
       └ infra-test-policy-stating

Suspended OU

一時的もしくは永続的に使用を停止する必要のあるアカウントの保存領域。アプリケーションレベルのアクセスを削除して、各ユーザが各アカウントにアクセスして管理できなくする。一時停止するアカウントについては再度使用される可能性があるため、アカウントを移動した理由とアカウントが所属していたOUを記録することが奨励される。

個々のユーザ向けOU

ワークロードOU外で管理されるリソースを管理するためのOU。例えば、他社との共有を目的としたS3バケットのあるAWSアカウントやアカウントに直接アクセスする必要のないQuickSightを作成しているアカウントなど。これらのアカウントには、SCPとIAMを組み合わせて設定することが奨励される。

例外OU

ワークロードOUに適用されるポリシーの例外を必要とするアカウント。このOUに所属するアカウントはごく少数でなければならない。ワークロードOUの階層を深くすることで対応できないか検討する。

Deployments OU

ワークロードへの変更を構築、検証、リリースする方法をサポートするリソースとワークロードを含むアカウント。例えば、AWS内外のCI/CDサービスとの連携など。デプロイをするために、テスト環境と本番環境の両方にアクセスできなければならない場合が多い。CI/CD環境は、ワークロード別に作成することが望ましい。また、CI/CDパイプライン自体のテスト環境を作ることが奨励される。

Deployments
 ├ Prod
 │  └ xxx-service-cicd-prod
 └ Test
    └ xxx-service-cicd-test

移行用OU

会社の買収や第三者が管理していたアカウントの移行など、上記のOU外に存在したアカウントを受け入れる際に、一時的に保存するためのOU。他のOrganizationsと紐づいている場合には、このOrganizationsからの削除を最初に行う。移行時には、他のAWSアカウントとの依存関係がないかどうかを調査する必要がある。

ワークロード指向のOU

ワークロードは特定のコンポーネントとデータのコレクションであり、テスト用や本番用などの複数の環境を有することができ、これらの環境は分離することが奨励される。本番環境がテスト環境のリソースに依存、またはその逆が存在することは望ましくない。ただし、テスト環境から本番環境上の実データへアクセスする場合があり、この場合は読み取り専用とすることが一般的。環境別にOUを構築する場合、本番環境と非本番環境の2つのOUに分割する場合もあれば、本番環境、ステージング環境、テスト環境と3つの環境に分割する場合もある。なお、AWSの場合は、1つのアカウントに単一のワークロードが存在する場合もあれば、1つのアカウントに複数のワークロードが存在する場合もある。

example-workload-accounts-scoping

ワークロードOUでは関連するワークロード同士を同一のOUにまとめることができる。例えば、データベースOU、バックアップOUなどである。OUは組織のレポート構造を真似るのではなく、ワークロードごとにまとめる必要があるが、例えば各ビジネスユニットが独立して存在し、それぞれで大幅にポリシーが異なる場合は、ビジネスユニットごとにOUを構築する場合もある。

AWSアカウントの整理

単一のアカウントしか持っていない場合で本番ワークロードの稼働を予定している場合には、複数アカウントへの移行および移行OUの利用を検討する。また、立ち上げたばかりの組織の場合は、 Control Towerなどを利用して最小限のOUを構築することができる。

example-production-starter-control-tower

さらに拡張された場合には、InfrastructureやSandbox、CI/CDなどのOUを追加する。

example-basic-organization-cicd

このように、AWSの利用が広がるに従って組織を拡大することができる。これらを構築するために、ControlTowerやAWS Managed Servicesの使用を検討できる。

Appendixに記載のある情報

本ホワイトペーパーのAppendixには、以下の記述もある。

AWS Elemental MediaConnect(1)MediaConnect の概要

MediaConnect

MediaConnectは、ライブ動画を伝送することのできるサービスで、これまで衛星やファイバー経由で伝送していた映像をIPベースで安価で伝送、共有することが可能となる。また、CDIをサポートしており、JPEG XSなどのプロトコルを用いることもできる。MediaLiveなどの他のAWSとの連携も可能となっている。伝送状況は15以上のメトリクスで確認することが可能。複数AZ上にリソースを配置しており、さらにSMPTE 2022-7やホット/ホットフェイルオーバ機能を用いることで高い可用性を持つシステムを構築することが可能である。

workflow

MediaConnectは、データ遅延を減らすためにリージョンごとのエンドポイントを設けている。

https://mediaconnect.<region>.amazonaws.com

特徴

MediaConnectの特徴は以下の通り。

  • Zixi, RIST, FEC付きRTPなどの幅広いプロトコルをサポート
  • CDI と JPEG XSにより非圧縮の映像伝送を実現
  • AES(静的キー、SPEKE)によるコンテンツの暗号化
  • 複数アカウントでの共有
  • 複数のメトリクスによるモニタリング

費用

MediaConnect TSフローとJPEG XSフローそれぞれで費用が異なる。前者の場合は、1時間単位の課金と転送されたデータ量によって課金される。JPEG XSフローでは、1時間単位の課金と出力ごとの1時間単位の課金の合計金額となる。スタンバイモードの場合は課金されない。

ユースケース

Distrubution

地理的に異なる場所にコンテンツを配信する。

use-case-distribution

共有

複数のAWSアカウントでコンテンツを共有する。

use-case-entitlement

クラウドへの取り込み

MediaLiveなどへ取り込む。

use-case-contribution2

非圧縮信号の伝送

SMPTE 2022-6, 2110などに準拠した信号をJPEG XSコーデック等を用いて伝送。AWS内ではCDIとして扱うことができる。

use-case-cdi1

複数コンテンツの切り替えと複製

複数のコンテンツをAWSにアップロードし、切り替えと複製を行う。

use-case-cdi-replicatio

AWS Control Tower(1)Control Towerの概要

Control Tower

AWS Control Towerを用いることで、ランディングゾーンと呼ばれる、ロギングの一元管理やセキュリテイ監査の確立などの機能を含む、安全でかつペストプラクティスに従ったAWSマルチアカウント環境の作成をすうクリックで実現できる。AWS Control Towerは、AWS Organizations, AWS Service Catalog, AWS Single Sign-Onなどを用いて、このランディングゾーンを1時間未満で構築する。

またAWS OrganizationsとAWS Configを用いて、発見的ガードレールと予防的ガードレールを提供する。これらを用いることで、ポリシーの適用および違反の検出を可能とする。またこれらの状況はダッシュボードから簡単に確認することができる。

また、アカウントファクトリーと呼ばれるアカウントテンプレートを使用して、コンプライアンスポリシーに適合したAWSアカウントを作成することができる。

ランディングゾーン

セキュリティやコンプライアンスのベストプラクティスに基づいたマルチアカウント環境のこと。例えば、

  • AWS Organizationsを利用したマルチアカウント環境の作成
  • AWS Single Sign-Onを用いたID管理とフェデレーテッドアクセスの実現
  • AWS CloudTrailやAWS Configのログの集中管理
  • AWS IAMやAWS SSOを用いたセキュリティ監査

などを実現できる。

ガードレール

ガードレールとはセキュリティや運用などのガナバンスを維持するためのルールで、発見的ガードレールと予防的ガードレールの2種類から構成される。またこれらのガードレールの適用は、必須、強く奨励、選択の3つにレベル分けされている。

アカウントファクトリー

事前に承認済みのネットワーク構成やリージョン選択を含んだアカウントテンプレートに従って、自動的に標準化された新規AWSアカウントを作成できる。アカウントファクトリーは、AWS Service Catalogを用いて構築される。

ダッシュボード

有効化されたガードレール、ポリシーに非準拠のリソースなどを簡単に確認することができる。

料金

AWS Control Towerは、追加料金なしに利用できる。AWS Control Towerによって利用されたAWS Service Catalog, AWS CloudTrail、AWS Config、Amazon CloudWatch、Amazon Simple Notification Service (SNS)、Amazon Simple Storage Service (S3)、Amazon Virtual Private Cloud (VPC) などについては、その利用量従って課金される。

AWS Control Tower の仕組み

AWS Control Towerが作成するランディングゾーンは、以下を含む。なお、これらの作成には、CloudFormation StackSets が利用される。Control Towerが作成したリソースを手動で削除すると、ガードレールの状態が不明になるなどの問題が生じる可能性がある。

構成 内容
セキュリティOU ログアーカイブアカウントと監査アカウントが作成される。アカウント名称は後から変更できない。
サンドボックスOU ユーザがAWSワークロードを実行するための環境
AWS SSO ディレクトリ AWS SSO ユーザを含むディレクトリ
AWS SSO ユーザ ランディングゾーンでAWSワークロードを実行するユーザ

また、ランディングゾーンを設定すると、20個の予防的ガードレールと2個の発見的ガードレールを適用する。これら必須のガードレールは常に適用され変更することはできない。これとは別に強く奨励されるガードレール、選択できるガードレールについては、コンソール上からいつでも変更が可能である。なお、SCPをベースに作成される予防的ガードレールは、管理アカウントには適用されない。

Control Towerのセットアップ

Control Towerは、既存のOrganizationsに適用することも、まだOrganizationsを設定していないAWSアカウントに対して作成することもできる。Control Towerを設定する前に 管理アカウントが条件を満たしているかどうか を確認する。

制限事項

Control Towerを設定するホームリージョンと、新規に作成されるAWSのアカウント名は設定後変更できないことに注意。また、ネストされたOUはControl Towerではサポートされず表示もできない。またそれ以外に、OUに同時に設定できるSCPは5つ以内、300を超えるAWSアカウントを持つOUは登録できないなどの制限も存在する。

ベストプラクティス

リソースへのアクセスや予防的ガードレール(SCP)について、一般のユーザに事前に説明を行う。また、Control Towerをセットアップする上では、

  • 最も使用する頻度の高いリージョンをホームリージョンにする
  • 監査用などに作成されたS3バケットは削除しない

などに注意する。またワークロードと同じリージョンにControl Towerのホームリージョンを置くことで、リージョン間でのログの移動と取得に対するコストを削減できる。Control Towerのサポート外のリージョンでは、Control Towerによって作成されたVPCが使用できない。この場合はこのVPCを無効化しておく。

Control Towerを使用することで、AWSアカウントはリソースのコンテナ、リソースの境界として機能する。これにより、セキュリティの脅威を限定し、複数のワークロードやその課金を適切に管理できる。マルチアカウントを利用することで、適切なセキュリティコントロール、リソースの分離、チーム別のリソースの提供、データの分離、ビジネスプロセスに沿ったアカウント管理、費用の管理、適切なクオータの割り当てなどを実現できる。詳細については、AWS Organizations(2)AWSアカウントの管理を参照のこと。

### VPC アカウントファクトリーは、デフォルトVPCを削除してそれとは異なるVPCを作成する。このVPCはデフォルトでは、1つのAZに1つのパブリックサブネットと2つのプライベートサブネットを作成するため、3つのAZで合計9個のサブネットが作成される。これらの数は変更可能。VPCのデフォルトのCIDR範囲は、172.31.0.0/16で、作成されたサブネット間は全て通信が許可される。CIDR範囲は変更可能だが、変更後に作成した新規のAWSアカウントからこの設定が反映される。

設定変更管理

ランディングゾーンの設定は、バージョン管理されていて、定期的にAWSから最新のバージョンが提供される。自身の環境が最新のランディングゾーンの設定になっていない場合をドリフト状態と呼び、更新が促される。更新を行うためには、まずランディングゾーンを更新し、その後の状況によって個々のAWSアカウントを個々に更新する。

AWS Elemental MediaStore(1)MediaStore の概要

MediaStore

AWS Elemental MediaStoreは、メディア向けに最適化されたストレージサービス。動画ワークフローにおけるオリジンストアの役割を担う。高いパフォーマンス、一貫性、低レイテンシーの読み取りと書き込みを同時に実現することで、バッファリングのリスクが低減され、エンドツーエンドのレイテンシーも短縮できる。また、受信するリクエストの量に合わせてスケーリングを行うこともできる。理想的なユースケースは、HTTPを用いたビットレート可変型のライブストリーミングの処理で、MediaStoreを単独のサービスとしても、他のMediaServicesと組み合わせることも出来る。ライブストリーミングを配信しない場合には、Amazon S3によって代替できる。

### 料金

GBあたりの取り込み料金とストレージ料金によって課金される。またリクエストについても課金され、ストレージクラスとリクエストタイプによって単価が異なる。

CloudFrontをCDNとして利用する際には、CloudFrontまでの転送費用は発生しない。ただし、他のCDNを利用する際には転送費用が発生する。

コンテナ

MediaStore のコンテナを使用して、フォルダとオブジェクトを保存できる。コンテナ名は、同一リージョンのアカウント内で一意である必要があり、大文字、小文字、数字、および下線(_)を含めることができる。コンテナ名は変更できない。

AWS Elemental MediaLive(1)MediaLive の概要

MediaLive

AWS Elemental MediaLiveは、テレビ放送やインターネット接続のマルチスクリーンデバイス向けに高品質なビデオストリームを作成できる、 ライブ動画処理サービス 。ライブ動画ストリーミングをリアルタイムにエンコードする。AWS Elemental MediaLive は統計的多重化、高校マーカーサポート、音声機能などの ブロードキャストグレードの機能 を有しており、数分で簡単なライブチャンネルをデプロイすることが可能 である。 また、 複数のAZのリソースを透過的に管理 して、自動的に状態をモニタリングできるなど、 高い信頼性と可用性 有している。また、利用するだけ課金されるために、 効率性を向上 させて コストを削減 することが可能となっている。

AWS Elemental MediaLiveは、スタンドアローンサービスとして利用することも、他AWS Media Servicesと組み合わせて使用することも可能である。H.264やH.265などの最新のコーデックやRTP、HLS、RTMPなどの伝送規格をサポートしており、Statistical Multiplexing (Statmux)を利用することで、衛星やケーブル等を介して配信することもできる。

費用

インプット、アウトプット、アドオン、アイドルリソース、データ転送に対して従量課金で課金される。なお、 インプットがコンテンツを受信せず、アウトプットがコンテンツを生成しない場合でもコストが発生することに注意 が必要である。また高度なオーディオ機能を有効にすると、追加料金が発生する。

オンデマンド以外に、12ヶ月/36ヶ月利用の リザーブド料金の設定 もあり、これを利用することで大幅な割引を受けることができる。なお、料金適用時の解像度の定義は、 SD解像度は720px未満、 HD解像度は720px以上、1080以下、UHD解像度は1080pxより大きく、2160px以下 である。

インプットは、 入力ストリームのコーデック、ビットレート、チャンネルモード、解像度 の組み合わせによって決まる。アウトプットは、 ビットレート(H.264のみ)、解像度、フレームレート、チャンネルモード の組み合わせによって決まる。

なお、同じリージョン内で AWS Elemental MediaPackage、AWS Elemental MediaStore、または Amazon S3 との間でデータ転送する場合は、追加料金は発生しない

MediaLiveとは

MediaLiveを含むライブストリーミングワークフローには以下のシステムが含まれる

  • MediaLiveチャンネル
  • コースコンテンツを提供するアップストリームシステム
  • アウトプットの宛先であるダウンストリームシステム

MediaLiveは、これらと以下の関係を構築する。 内部の処理を2つのパイプラインを用いて行うことが奨励 されており、2つのパイプラインを設定することで復元力を高めることができる。

components-workflow

インプットの方法には、プッシュインプットとプルインプットが存在し、 プッシュインプットの場合は、入力セキュリティグループと関連 付けられてIPアドレスの範囲を指定することができる。各MediaLiveチャンネルには、1つの 「スケジュール」が関連づけられており、様々なアクションを行うことができる

クオータ

チャンネル数や入力数、セキュリティグループの数などに クオータが設定 されている。これ以上のリソース利用をする場合には、上限緩和申請を行う。

制限

インプットに対する制限事項は以下の通り。

  • プッシュ入力の上限は、2入力
  • プル入力の上限は、20入力
  • CDI入力の上限は、1入力
  • ElementalLink入力の上限は、2入力
  • プッシュ入力は、フェールオーバペアに設定できない

アウトプットに対する制限事項は以下の通り。

  • アーカイブ出力グループの上限は、1出力
  • HD対応しているコーデックは、H.264とH.265のみ
  • UHD対応しているコーデックは、H.264とH.265のみ

その他の制限は以下の通り。

  • 画像オーバレイの上限は8レイヤー
  • 入力フェールオーバはチャンネル全体ではなくインプットに適用される

インプット

インプットは、MediaLiveワークフローのコンポーネントの1つ。入力セキュリティグループもしくは、チャンネルと接続されるインプットは、 「ソースタイプ」、「配信プロトコル」、「ライブ or VOD」、「プッシュ or プル」、「インプットクラス(標準 or シングル)」、「静的URL or 動的URL」で分類 できる。なお、 動的URLが指定できるのは、MP4のみ

自動入力フェールオーバ

アップストリームやネットワーク上の異常が発生した場合に、黒味や無音を検知してフェールオーバを実施することが可能である。インプットは、2つのプッシュ入力を使用し、どちらをプライマリーに指定するのか決めることが出来る。シングルパイプラインチャンネルにて、自動入力フェールオーバを使用しても、パイプライン上の障害は防ぐことができないことに注意が必要。

aif-single-setup

aif-single-input-failover

標準チャンネルにて、自動入力フェールオーバを使用する場合は、アップストリーム側で合計4つのストリームを用意する必要がある。

aif-standard-beforefailure

この状態で、アップストリーム上で異常が発生した場合には、自動フェールオーバが発生する。ダウンストリーム側は、パイプライン0を使い続けることができる。

aif-standard-input-failure

パイプライン上に異常が発生した場合は、ダウンストリームシステム側で他のパイプラインへの切り替えが発生する。これは、自動入力フェールオーバの機能ではない。

aif-standard-pipeline-failure

フェールオーバ後の動作は以下の2つを選択することが出来る

  • EQUAL_INPUT_PREFERENCE : セカンダリで動作を続ける
  • PRIMARY_INPUT_PREFERENCE : プライマリ入力に戻って動作を続ける

MP4(プル)

MP4のコンテンツは、1つのビデオトラックと1つ以上の音声トラックで構成され、キャプションが含まれている場合もある。オーディオは、トラック番号と言語コードを取得できると良い。

HTTP/HTTPSサーバ、AWS Elemental MediaStore もしくは Amazon S3 からのプル入力 が可能で、シングルクラスもしくは標準クラスの入力として設定が可能。ID/パスワードが必要な場合は、これらのデータはパラメータストアに保存される。 $urlPath$を用いて動的なパス名を指定 することが可能。

サーバ URL
HTTP/HTTPS http:// or https://<path>
AWS Elemental MediaStore mediastoressl://<data endpoint container>/<path>
Amazon S3 s3ssl://<bucket>/<path>

標準チャンネルの場合、2つのファイルソースを用意しなければならないことに注意する。

mp4-pull-uss-input.png

RTMP(プッシュ)

RTMPSプロトコルには対応しない。VPCもしくはVPC外の固定のエンドポイントからストリームを送信できる。シングルクラスもしくは標準クラスの入力として設定が可能。入力セキュリティグループで、 送信元のIPを制限 できる。

rtmp-push-uss-input

チャンネル

チャンネルは、エンコード、アウトプット、アウトプットグループから構成される。チャンネルは、 インプットからのソースコンテンツを取り込んでトランスコードし、新しいコンテンツをアウトプットにパッケージ化 する。このためチャンネルを設定するときには、

  • インプット
  • アウトプットグループ
  • アウトプット

をそれぞれ設定する必要がある。 インプットの要件の詳細が不明な場合は、より高いオプションを選択 する。

output-group

IAM権限

他のサービスと連携させるためには、MediaLive自体にリソースを操作する権限を設定する必要があるため、 通常は各チャンネルに MediaLiveAccessRole ロールを付与する。

チャンネルクラス

チャンネルを作成する際には、2つのパイプラインを有する標準クラスか、1つのパイプラインを有するシングルパイプラインクラスかのいずれかを選択する。標準クラスの場合、アップストリームシステムは同一のストリームを2つのエントリーポイント送信し、2つのパイプライン上にコンテンツを提供し、MediaLiveは 両方のパイプラインで同じ処理を実行 する。

pipeline-redundancy-standard-channel

ダウンストリームに2つのインプットを受けることのできる機能が無い場合は、標準チャンネルとして設定するメリットは存在しない。また、アップストリームシステムが単一のソースコンテンツしか送信できない場合も同様である。

なお、チャンネルを最初に作成するときには、標準のインプットを用いて単一のパイプラインを構築することが奨励されている。この場合、インプットには2つのパイプラインが含まれているが、チャンネル内は単一のパイプラインとなっている。

pipeline-redundancy-single-channel-standard-input

また、インプットも単一のパイプランとし、単一のインプットを用いて単一のパイプラインを構築することも可能である。

pipeline-redundancy-single-channel-single-input

セレクタ

入力方式によってはセレクタを設定することができる。セレクタには、色空間を設定するビデオセレクタ、オーディオトラック/PIDを選択するオーディオセレクタ、キャプションを選択するキャプションセレクタがある。

一般設定

TBD

出力グループ

目的に合った出力グループを作成する。

アーカイブ出力グループ

出力をS3バケットに送信する。出力先のフィールドには、S3の情報を入力する。他の所有者のS3に送信する場合は、CDN設定フィールドの固定ACL設定を入力する必要がある。ロールオーバ間隔は、ファイルの分割単位を表す。

URL 名前修飾子 拡張
s3ssl://<bucket>/<path> $dtなど m2ts で固定

フィレームキャプチャ出力グループ

JPEG画像を含む一連のファイルで、ファイルはS3に保存される。設定項目は、上述のアーカイブ出力グループと同様。

HLS出力グループ

HLS出力グループは、出力先にAmazon S3、 MediaStore、MediaPackage、HTTPサーバを選択することができる。

入力セキュリティグループ

VPCを使用しないRTP入力およびRTMPプッシュ入力に適用 される。1つのセキュリティグループには、最大10個のルールを含めることができる。これを活用することで、許可されていない第三者がエンドポイントに意図せぬ入力を行うことを防ぐことが出来る。また、 1つのセキュリティグループを複数のインプットにアタッチ することができる。

配信の準備

配信を行うにあたっては、MediaLiveと接続するアップストリーム、ダウンストリームを含めた全体のワークフローを計画する必要があり、これが決まったあとにチャンネルの設定を行う。

1. 出力グループタイプの特定

MediaLiveがストリームを出力するシステムを特定して、以下を特定/決定する。なお、DRMや広告の挿入が必要な場合には、 AWS Elemental MediaStoreではなく、 再パッケージ機能を有する AWS Elemental MediaPackage を選択 する。なお、シングルパイプラインチャンネルの場合、AWS Elemental MediaPackage との接続は HLS出力グループのみ使用できる。

  1. 必要な出力形式とプロトコル、およびこれらがMediaLiveに対応しているか
  2. VPCを介した通信が必要であるか
  3. ダウンストリームシステムの選択(上述)
  4. Microsoft Smooth Streaming を使用する場合のオプションの選択
  5. アーカイブ出力グループを作成するかどうか
  6. フレームキャプチャ出力グループを作成するかどうか

2. 出力グループのエンコード要件の特定

出力グループのエンコード要件を特定する。例えば、サポートできるビデオコーデックや最大のビットレートと解像度、オーディオコーデックや最大のビットレートなど。また、アナログプレイヤーの機能を模倣するためのtrick-play機能が必要であるかどうかの確認も行う。

3. 復元力の要件の特定

複数のパイプラインを用意することで、現在のパイプラインに異常が生じた場合に、ダウンストリームシステムがもう片方のパイプラインに中断なく切り替えることが可能になる。また、単一のパイプラインの複数のインプットに対して、自動フェールオーバ設定を行うことで、アップストリーム側、もしくはアップストリーム側とMediaLiveの間のネットワークに異常が生じた場合の切り替えを行うことができる。この機能は、標準チャンネルにもシングルパイプラインチャンネルにも適用できる。自動入力フェールオーバを利用するためには、ソースコンテンツが異なるエンコーダから発信されている必要がある。

4. アップストリームシステムの評価

アップストリームシステムが、MediaLiveとの互換性を有しているのか確認する。

  1. 必要なストリーム数が用意できるか、配信フォーマットとプロトコルに互換性はあるか、Live or ストリーム、暗号化の有無、RTPの場合にFECが含まれているかどうかなどを確認する。
  2. ビデオコーデックと解像度、最大入力ビットーレートを確認する。コーデックが途中で変更になるようなケースはNG。
  3. オーディオコーデックと言語、音声モードを確認する。コーデックが途中で変更になるようなケースはNG。

MediaLiveの機能

音声のみの出力

音声のみの入力は、MediaConnect入力もしくはRTP入力である必要がある。また、音声とビデオの両方を含むインプットも音声のみの出力に利用することができる。音声のみの出力グループで指定できる形式は、HLS、Microsoft Smooth、RTMP、UDPのみである。

オーディオレンディショングループ(HLS)

出力グループに、多言語、異なる音声モードなどの複数の音声チャンネルを含むことができる。単一のビデオに対して複数の音声チャンネルが紐づく場合も、複数のビデオに対して複数の音声チャンネルが紐づく場合もある。

ARG_threeV_threeA.png

ARG_twoV_twoA

入力切り替えとスケジュール

入力準備

切り替え時の遅延を減らすために、即時切り替えに紐づいた入力を準備しておくことが出来る。チャンネルスケジュールにこの入力準備アクションを追加しておくことで、その入力はプローブされデコードを開始する。入力準備が出来るアクションは同時に1つだけで、少なくともスイッチングの10秒前に開始しておく必要がある。RTMPプル入力には、入力準備は使用できない。入力準備を有効にするためには、 [Feature Activations] の [Input Prepare Schedule Actions] を選択する。

入力準備には、

  • 固定時間
  • 即時
  • フォロー(特定の入力スイッチに依存)

の3つのタイプが存在する。ファイル入力に対しても入力準備を行うことが可能。

入力切り替え

スケジュールを用いてチャンネル内のインプットを切り替えることが可能。暗黙的に切り替えることはなく、特定のメインストリームというものは存在しない。利用用途としては、ライブ映像と静止画との切り替え、ライブ映像から別のライブ映像への切り替えなどが考えられる。

入力切り替えにには、

  • 固定時間
  • 即時
  • フォロー(前の入力が終了した場合に切り替え)

の3つのタイプが存在する。これらの組み合わせをまとめると以下のようになる。

| 現在の入力 | 次の入力 | 可能な開始タイプ | |

MediaLive

AWS Elemental MediaLiveは、テレビ放送やインターネット接続のマルチスクリーンデバイス向けに高品質なビデオストリームを作成できる、 ライブ動画処理サービス 。ライブ動画ストリーミングをリアルタイムにエンコードする。AWS Elemental MediaLive は統計的多重化、高校マーカーサポート、音声機能などの ブロードキャストグレードの機能 を有しており、数分で簡単なライブチャンネルをデプロイすることが可能 である。 また、 複数のAZのリソースを透過的に管理 して、自動的に状態をモニタリングできるなど、 高い信頼性と可用性 有している。また、利用するだけ課金されるために、 効率性を向上 させて コストを削減 することが可能となっている。

AWS Elemental MediaLiveは、スタンドアローンサービスとして利用することも、他AWS Media Servicesと組み合わせて使用することも可能である。H.264やH.265などの最新のコーデックやRTP、HLS、RTMPなどの伝送規格をサポートしており、Statistical Multiplexing (Statmux)を利用することで、衛星やケーブル等を介して配信することもできる。

費用

インプット、アウトプット、アドオン、アイドルリソース、データ転送に対して従量課金で課金される。なお、 インプットがコンテンツを受信せず、アウトプットがコンテンツを生成しない場合でもコストが発生することに注意 が必要である。また高度なオーディオ機能を有効にすると、追加料金が発生する。

オンデマンド以外に、12ヶ月/36ヶ月利用の リザーブド料金の設定 もあり、これを利用することで大幅な割引を受けることができる。なお、料金適用時の解像度の定義は、 SD解像度は720px未満、 HD解像度は720px以上、1080以下、UHD解像度は1080pxより大きく、2160px以下 である。

インプットは、 入力ストリームのコーデック、ビットレート、チャンネルモード、解像度 の組み合わせによって決まる。アウトプットは、 ビットレート(H.264のみ)、解像度、フレームレート、チャンネルモード の組み合わせによって決まる。

なお、同じリージョン内で AWS Elemental MediaPackage、AWS Elemental MediaStore、または Amazon S3 との間でデータ転送する場合は、追加料金は発生しない

MediaLiveとは

MediaLiveを含むライブストリーミングワークフローには以下のシステムが含まれる

  • MediaLiveチャンネル
  • コースコンテンツを提供するアップストリームシステム
  • アウトプットの宛先であるダウンストリームシステム

MediaLiveは、これらと以下の関係を構築する。 内部の処理を2つのパイプラインを用いて行うことが奨励 されており、2つのパイプラインを設定することで復元力を高めることができる。

components-workflow

インプットの方法には、プッシュインプットとプルインプットが存在し、 プッシュインプットの場合は、入力セキュリティグループと関連 付けられてIPアドレスの範囲を指定することができる。各MediaLiveチャンネルには、1つの 「スケジュール」が関連づけられており、様々なアクションを行うことができる

クオータ

チャンネル数や入力数、セキュリティグループの数などに クオータが設定 されている。これ以上のリソース利用をする場合には、上限緩和申請を行う。

制限

インプットに対する制限事項は以下の通り。

  • プッシュ入力の上限は、2入力
  • プル入力の上限は、20入力
  • CDI入力の上限は、1入力
  • ElementalLink入力の上限は、2入力
  • プッシュ入力は、フェールオーバペアに設定できない

アウトプットに対する制限事項は以下の通り。

  • アーカイブ出力グループの上限は、1出力
  • HD対応しているコーデックは、H.264とH.265のみ
  • UHD対応しているコーデックは、H.264とH.265のみ

その他の制限は以下の通り。

  • 画像オーバレイの上限は8レイヤー
  • 入力フェールオーバはチャンネル全体ではなくインプットに適用される

インプット

インプットは、MediaLiveワークフローのコンポーネントの1つ。入力セキュリティグループもしくは、チャンネルと接続されるインプットは、 「ソースタイプ」、「配信プロトコル」、「ライブ or VOD」、「プッシュ or プル」、「インプットクラス(標準 or シングル)」、「静的URL or 動的URL」で分類 できる。なお、 動的URLが指定できるのは、MP4のみ

自動入力フェールオーバ

アップストリームやネットワーク上の異常が発生した場合に、黒味や無音を検知してフェールオーバを実施することが可能である。インプットは、2つのプッシュ入力を使用し、どちらをプライマリーに指定するのか決めることが出来る。シングルパイプラインチャンネルにて、自動入力フェールオーバを使用しても、パイプライン上の障害は防ぐことができないことに注意が必要。

aif-single-setup

aif-single-input-failover

標準チャンネルにて、自動入力フェールオーバを使用する場合は、アップストリーム側で合計4つのストリームを用意する必要がある。

aif-standard-beforefailure

この状態で、アップストリーム上で異常が発生した場合には、自動フェールオーバが発生する。ダウンストリーム側は、パイプライン0を使い続けることができる。

aif-standard-input-failure

パイプライン上に異常が発生した場合は、ダウンストリームシステム側で他のパイプラインへの切り替えが発生する。これは、自動入力フェールオーバの機能ではない。

aif-standard-pipeline-failure

フェールオーバ後の動作は以下の2つを選択することが出来る

  • EQUAL_INPUT_PREFERENCE : セカンダリで動作を続ける
  • PRIMARY_INPUT_PREFERENCE : プライマリ入力に戻って動作を続ける

MP4(プル)

MP4のコンテンツは、1つのビデオトラックと1つ以上の音声トラックで構成され、キャプションが含まれている場合もある。オーディオは、トラック番号と言語コードを取得できると良い。

HTTP/HTTPSサーバ、AWS Elemental MediaStore もしくは Amazon S3 からのプル入力 が可能で、シングルクラスもしくは標準クラスの入力として設定が可能。ID/パスワードが必要な場合は、これらのデータはパラメータストアに保存される。 $urlPath$を用いて動的なパス名を指定 することが可能。

サーバ URL
HTTP/HTTPS http:// or https://<path>
AWS Elemental MediaStore mediastoressl://<data endpoint container>/<path>
Amazon S3 s3ssl://<bucket>/<path>

標準チャンネルの場合、2つのファイルソースを用意しなければならないことに注意する。

mp4-pull-uss-input.png

RTMP(プッシュ)

RTMPSプロトコルには対応しない。VPCもしくはVPC外の固定のエンドポイントからストリームを送信できる。シングルクラスもしくは標準クラスの入力として設定が可能。入力セキュリティグループで、 送信元のIPを制限 できる。

rtmp-push-uss-input

チャンネル

チャンネルは、エンコード、アウトプット、アウトプットグループから構成される。チャンネルは、 インプットからのソースコンテンツを取り込んでトランスコードし、新しいコンテンツをアウトプットにパッケージ化 する。このためチャンネルを設定するときには、

  • インプット
  • アウトプットグループ
  • アウトプット

をそれぞれ設定する必要がある。 インプットの要件の詳細が不明な場合は、より高いオプションを選択 する。

output-group

IAM権限

他のサービスと連携させるためには、MediaLive自体にリソースを操作する権限を設定する必要があるため、 通常は各チャンネルに MediaLiveAccessRole ロールを付与する。

チャンネルクラス

チャンネルを作成する際には、2つのパイプラインを有する標準クラスか、1つのパイプラインを有するシングルパイプラインクラスかのいずれかを選択する。標準クラスの場合、アップストリームシステムは同一のストリームを2つのエントリーポイント送信し、2つのパイプライン上にコンテンツを提供し、MediaLiveは 両方のパイプラインで同じ処理を実行 する。

pipeline-redundancy-standard-channel

ダウンストリームに2つのインプットを受けることのできる機能が無い場合は、標準チャンネルとして設定するメリットは存在しない。また、アップストリームシステムが単一のソースコンテンツしか送信できない場合も同様である。

なお、チャンネルを最初に作成するときには、標準のインプットを用いて単一のパイプラインを構築することが奨励されている。この場合、インプットには2つのパイプラインが含まれているが、チャンネル内は単一のパイプラインとなっている。

pipeline-redundancy-single-channel-standard-input

また、インプットも単一のパイプランとし、単一のインプットを用いて単一のパイプラインを構築することも可能である。

pipeline-redundancy-single-channel-single-input

セレクタ

入力方式によってはセレクタを設定することができる。セレクタには、色空間を設定するビデオセレクタ、オーディオトラック/PIDを選択するオーディオセレクタ、キャプションを選択するキャプションセレクタがある。

一般設定

TBD

出力グループ

目的に合った出力グループを作成する。

アーカイブ出力グループ

出力をS3バケットに送信する。出力先のフィールドには、S3の情報を入力する。他の所有者のS3に送信する場合は、CDN設定フィールドの固定ACL設定を入力する必要がある。ロールオーバ間隔は、ファイルの分割単位を表す。

URL 名前修飾子 拡張
s3ssl://<bucket>/<path> $dtなど m2ts で固定

フィレームキャプチャ出力グループ

JPEG画像を含む一連のファイルで、ファイルはS3に保存される。設定項目は、上述のアーカイブ出力グループと同様。

HLS出力グループ

HLS出力グループは、出力先にAmazon S3、 MediaStore、MediaPackage、HTTPサーバを選択することができる。

入力セキュリティグループ

VPCを使用しないRTP入力およびRTMPプッシュ入力に適用 される。1つのセキュリティグループには、最大10個のルールを含めることができる。これを活用することで、許可されていない第三者がエンドポイントに意図せぬ入力を行うことを防ぐことが出来る。また、 1つのセキュリティグループを複数のインプットにアタッチ することができる。

配信の準備

配信を行うにあたっては、MediaLiveと接続するアップストリーム、ダウンストリームを含めた全体のワークフローを計画する必要があり、これが決まったあとにチャンネルの設定を行う。

1. 出力グループタイプの特定

MediaLiveがストリームを出力するシステムを特定して、以下を特定/決定する。なお、DRMや広告の挿入が必要な場合には、 AWS Elemental MediaStoreではなく、 再パッケージ機能を有する AWS Elemental MediaPackage を選択 する。なお、シングルパイプラインチャンネルの場合、AWS Elemental MediaPackage との接続は HLS出力グループのみ使用できる。

  1. 必要な出力形式とプロトコル、およびこれらがMediaLiveに対応しているか
  2. VPCを介した通信が必要であるか
  3. ダウンストリームシステムの選択(上述)
  4. Microsoft Smooth Streaming を使用する場合のオプションの選択
  5. アーカイブ出力グループを作成するかどうか
  6. フレームキャプチャ出力グループを作成するかどうか

2. 出力グループのエンコード要件の特定

出力グループのエンコード要件を特定する。例えば、サポートできるビデオコーデックや最大のビットレートと解像度、オーディオコーデックや最大のビットレートなど。また、アナログプレイヤーの機能を模倣するためのtrick-play機能が必要であるかどうかの確認も行う。

3. 復元力の要件の特定

複数のパイプラインを用意することで、現在のパイプラインに異常が生じた場合に、ダウンストリームシステムがもう片方のパイプラインに中断なく切り替えることが可能になる。また、単一のパイプラインの複数のインプットに対して、自動フェールオーバ設定を行うことで、アップストリーム側、もしくはアップストリーム側とMediaLiveの間のネットワークに異常が生じた場合の切り替えを行うことができる。この機能は、標準チャンネルにもシングルパイプラインチャンネルにも適用できる。自動入力フェールオーバを利用するためには、ソースコンテンツが異なるエンコーダから発信されている必要がある。

4. アップストリームシステムの評価

アップストリームシステムが、MediaLiveとの互換性を有しているのか確認する。

  1. 必要なストリーム数が用意できるか、配信フォーマットとプロトコルに互換性はあるか、Live or ストリーム、暗号化の有無、RTPの場合にFECが含まれているかどうかなどを確認する。
  2. ビデオコーデックと解像度、最大入力ビットーレートを確認する。コーデックが途中で変更になるようなケースはNG。
  3. オーディオコーデックと言語、音声モードを確認する。コーデックが途中で変更になるようなケースはNG。

MediaLiveの機能

音声のみの出力

音声のみの入力は、MediaConnect入力もしくはRTP入力である必要がある。また、音声とビデオの両方を含むインプットも音声のみの出力に利用することができる。音声のみの出力グループで指定できる形式は、HLS、Microsoft Smooth、RTMP、UDPのみである。

オーディオレンディショングループ(HLS)

出力グループに、多言語、異なる音声モードなどの複数の音声チャンネルを含むことができる。単一のビデオに対して複数の音声チャンネルが紐づく場合も、複数のビデオに対して複数の音声チャンネルが紐づく場合もある。

ARG_threeV_threeA.png

ARG_twoV_twoA

入力切り替えとスケジュール

入力準備

切り替え時の遅延を減らすために、即時切り替えに紐づいた入力を準備しておくことが出来る。チャンネルスケジュールにこの入力準備アクションを追加しておくことで、その入力はプローブされデコードを開始する。入力準備が出来るアクションは同時に1つだけで、少なくともスイッチングの10秒前に開始しておく必要がある。RTMPプル入力には、入力準備は使用できない。入力準備を有効にするためには、 [Feature Activations] の [Input Prepare Schedule Actions] を選択する。

入力準備には、

  • 固定時間
  • 即時
  • フォロー(特定の入力スイッチに依存)

の3つのタイプが存在する。ファイル入力に対しても入力準備を行うことが可能。

入力切り替え

スケジュールを用いてチャンネル内のインプットを切り替えることが可能。暗黙的に切り替えることはなく、特定のメインストリームというものは存在しない。利用用途としては、ライブ映像と静止画との切り替え、ライブ映像から別のライブ映像への切り替えなどが考えられる。

入力切り替えにには、

  • 固定時間
  • 即時
  • フォロー(前の入力が終了した場合に切り替え)

の3つのタイプが存在する。これらの組み合わせをまとめると以下のようになる。

現在の入力 次の入力 可能な開始タイプ
ファイル ファイル 固定時間 or 即時
ファイル ファイル フォロー
ファイル ライブ 固定時間 or 即時
ファイル ライブ フォロー
ライブ ファイル 固定時間 or 即時
ライブ ライブ 固定時間 or 即時

また、ファイルによる入力の場合は、ファイル名を動的に指定して切り替えることができる。

AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【ネットワーク篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。移行と転送 および ネットワーク サービスの詳細はこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

移行と転送

AWS Database Migration Service

AWS Database Migration Serviceは、RDBのAWSへの移行 を支援するサービス。本サービスを利用することで、短期間で安全にデータベースを移行することができる。また、移行作業中も オンプレミス上のデータベースは使用可能なまま、レプリケーションが継続される ため、ダウンタイムを最小限に抑えることができる。同種のデータベースだけでなく 異なるデータベースプラットフォーム間の移行も可能 。異種間の移行では、まず AWS Schema Conversion Tool を用いてスキーマの移行を行い。次に AWS Database Migration Service を利用してデータの移行を行う。これらの仕組みを利用することで、オンプレミス上の本番環境をもとにAWS上に開発環境を作成するなどのシナリオを実行できる。また、AWS上の異なるデータベースを AWS Database Migration Service を用いて統合することもできる。AWS Schema Conversion Tool に加えて、 Workload Qualification Framework を用いることで、mワークロードの評価や移行手順のレコメンドを受けることもできる。

AWS Application Discovery Service

AWS Application Discovery Serviceは、クラウド移行を支援するために、ホスト名、IPアドレス、CPUなどのインフラ情報に加えて、サーバのパフォーマンス情報など、オンプレミス上のデータを収集するサービスである。収集されたデータは暗号化形式で保存され、CSV等でエクスポートすることもできる。また、TCOの計算に使用したり、AWS Migration Hub でも利用できる。エージェントモードエージェントレスモード が存在する。エージェントレスモードは、VMWare上の環境で動作する。一方、非VMWare環境の場合や、詳細情報等を取得したい場合には、Application Discovery Agent をインストールする。

なお、クラウドへの移行方式にはいくつかの一般的手法が存在し、移行コストが低いものから順に、「Retain」(= 現状維持) 、「Retire」(= 廃止) 、「Re-host」(= 単純移行) 、「Re-purchase」(= アプリケーションの新規導入) 、「Re-platform」(= アプリケーションの一部改修) 、「Refactor」(= アプリケーションの修正や再構築) と呼ばれる。

AWS Server Migration Service

AWS Server Migration Serviceは、オンプレミスのワークロードを簡単にAWSに移行できる エージェントレス サービス。VMware vSphere、Windows Hyper-V、 Microsoft Azure などのデータをレプリケートし、AMIの作成を行う。

AWS Server Migration Service Connector と呼ばれる、VMware vCenter上で稼働する仮想マシンを稼働させることで、VMware vCenter のインベントリ情報をキャプチャすることができる。

AWS Migration Hub

AWS Migration Hubを用いることで、上述のサービスを横断的追跡することができ、それぞれのタスクのメトリクスや進捗状況を確認することができる。

AWS Storage Gateway(1)Storage Gatewayの概要

Storage Gateway

Storage Gatewayは、 オンプレミスからクラウドストレージに対してアクセスを提供 する ハイブリッドストレージサービス 。Storage Gatewayを使用することで、ストレージ管理を簡素化し掛かるコストを低減することができる。クラウドへのデータ移行のみならず、バックアップアーカイブDR などにも活用できる。

Storage Gatewayは、

  • テープゲートウェイ
  • ファイルゲートウェイ
  • ボリュームゲートウェイ

の3タイプで構成され、NFS、SMB、iSCSI などの標準ストレージプロトコルでクラウドストレージにアクセスできる。クラウドストレージにデータを保存することで、AWSの他のサービスを活用して保存したデータの処理を行うことができる。Storage Gatewayは、 VMware ESXi などで実行するVMとして、もしくは ハードウェアアプライアンス として オンプレミス上にデプロイ される。EC2上で動作させることも可能

テープゲートウェイ

iSCSI ベースの 仮想テープライブラリVTL)として使用することができる。データは、 S3 もしくは Gracier に保存することができる。主要なバックアップアプリケーションとの互換性があり、データのバックアップやアーカイブに使用することができる。ゲートウェイはそのデータをローカルに保存した後、S3に 非同期的にアップロード する。

ファイルゲートウェイ

ファイルゲートウェイを使用することで、 NFS および SMB プロトコルを使用して S3 にファイルを保存できる。ファイルゲートウェイは、S3に 非同期でデータを更新 し、データはS3上で SSE-S3 で暗号化される。

ローカルキャッシュ を利用することで、最近アクセスしたデータへの底レイテンシーアクセスとコストの低減が可能になる。

ボリュームゲートウェイ

ボリュームゲートウェイを用いることで、 iSCSI プロトコルを使用している ブロックストレージ をオンプレミスのアプリケーションに提供する。このデータはボリュームの スナップショット としてバックアップして、 EBSスナップショット として保存できる。バックアップは、スケジューラを使うことも、 AWS Buckup を使用することもできる。スナップショットは、差分のみが保存されるため料金を最低限に抑えることができる。ボリュームゲートウェイは、Stored Volume 型と Chached Volume 型に分類される。ボリュームゲートウェイを使用してDR対策を実現できる。

Stored Volume

データ全体をローカルに保存 した上で、非同期コピー を用いて S3ボリュームへのコピーEBSスナップショットの作成 ができる。ボリュームは、 1 GiB~32 TiBの間で設定でき、最大32個のボリュームがサポートされる。 データはオンプレミスに置いておきたいが、バックアップはAWSに置いておきたい という場合に最適。ローカルのディスクは、DAS もしくは SAN ディスクとしてオンプレミスから利用可能。データを復元する場合は、EBSスナップショットをゲートウェイストレージ上に復元できる。また、EC2にEBSボリュームとしてアタッチすることもできる。

Chached Volume

プライマリデータをS3 に保存し、 頻繁に利用するデータをローカルに保存 する。ボリュームは、 1 GiB~32 TiBの間で設定でき、最大32個のボリュームがサポートされる。ゲートウェイストレージ上には、cache storageupload buffer が作成される。データを復元する場合は、EBSスナップショットをゲートウェイストレージ上に復元できる。また、EC2にEBSボリュームとしてアタッチすることもできる。

AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【分析篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。分析 サービスの詳細はこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

Amazon CloudSearch

AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【管理&ガバナンス篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。管理ガバナンス に関するサービスはこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【セキュリテイ&コンプライアンス篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。セキュリテイコンプライアンス に関するサービスはこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

セキュリティ & コンプライアンス

AWS Identity and Access Management

AWS Resource Access Manager