Redshift
問題文・選択肢・解説を、右クリックでコピーできるようになりました。お手元のAIに貼り付けて、理解を深める学習にご活用ください（試験的な取り組みです）。ソラカナタへのAI質問も、これまでどおりご利用いただけます。
※学習目的以外のご利用（他社の問題集を当社のAI質問で回答させる等）が確認された場合は、AI質問の利用を制限させていただきます。
採点する
22問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース（無料）に登録してください。
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数22
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- DEA-分野1-データの取り込みと変換 0%
- DEA-分野2-データストア管理 0%
- DEA-分野3-データの運用とサポート 0%
- DVA-分野2-セキュリティ 0%
- MLA-分野4-MLソリューションのモニタリングと維持 0%
- SAP-分野2-新しいソリューションの設計 0%
- SAP-分野4-ワークロードの移行とモダナイゼーション 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 22
1. 質問
カテゴリ: DVA-分野2-セキュリティ【DVA-86】ある会社は、モバイルアプリケーションから送信される分析データを Amazon Redshift に蓄積し、大規模なデータ分析を行う計画です。
このアプリケーションでは、モバイルクライアントから直接 Redshift のテーブルを読み取るのではなく、安全な方法で一時的なアクセス許可を付与し、必要な期間だけテーブルに対する読み取りアクセスを許可したいと考えています。Redshift テーブルへのアクセスを提供する最適な方法はどれでしょうか。
正解不正解ヒントボタン
Amazon Redshift は大量データの集計・分析（OLAP）に特化したフルマネージドのデータウェアハウスサービスです。RDS のようなトランザクション処理向け DB とは用途が異なります。モバイルアプリなどクライアント側から AWS リソースにアクセスさせる場合は、常に「一時的な認証情報＋ロール委任（Cognito など）」を優先し、静的キー埋め込みを避ける、という方針を徹底するのが安全です。
-
質問 2 of 22
2. 質問
カテゴリ: MLA-分野4-MLソリューションのモニタリングと維持【MLA-75】
ある企業では、Amazon Redshift を唯一の分析データベースとして利用しており、その中には個人情報などの機密データも含まれています。データサイエンティストは、機密列を含むテーブルに対してクエリを実行したいものの、元のテーブルを書き換えたり、匿名化済みデータを別テーブルとして永続保存することは避けたいと考えています。実装作業を最小限に抑えつつ、クエリ実行時だけ機密列の値をマスクして見せるには、どのように構成すべきでしょうか。正解不正解ヒントボタン
『元の Redshift テーブルを変えずに、クエリ結果だけをマスクしたい』という要件にピッタリ対応している機能がどれかを思い出してみてください。
-
質問 3 of 22
3. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-4】ある企業は、RA3 ノードタイプの Amazon Redshift クラスタを本番分析基盤として利用しています。日中のピーク時間帯にはクエリが集中してキューが伸びる一方で、夜間は負荷が低い状態が続いています。データエンジニアは、必要なときだけ一時的に追加クラスターを自動起動して読み取り・書き込みキャパシティを増やす、Redshift の同時実行スケーリング機能を有効化したいと考えています。この要件を満たすために、どのように設定すべきでしょうか。
正解不正解ヒントボタン
同時実行スケーリングを有効化する場所が「クラスタ全体」ではなく「WLM キュー単位」である点と、RA3 ベースのプロビジョンドクラスタで利用できる機能である点を意識して選択肢を見比べてください。
-
質問 4 of 22
4. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-11】あるヘルスケア企業は、ウェアラブル端末や院内機器、電子カルテシステムからのイベントを Amazon Kinesis Data Streams に集約し、リアルタイムでヘルスケアデータを取り込んでいます。データエンジニアは、このストリーミングデータを処理して Amazon Redshift Serverless のデータウェアハウスに取り込み、最新のストリームと前日までの履歴データをほぼリアルタイムに分析できるようにしたいと考えています。運用負荷を抑えつつ、この要件を満たす取り込み方式として最も適切なものはどれでしょうか。
正解不正解ヒントボタン
Kinesis から Redshift Serverless へ、追加の中間ストレージを置かずに直接取り込めるネイティブ機能がないかどうかを思い出してみてください。
-
質問 5 of 22
5. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-16】ある企業は、ETL 処理専用の Amazon Redshift プロビジョンドクラスターを 1 つ用意し、そこに集約されたデータを元に重要な分析バッチを実行しています。別途、営業部門は自分たちの BI ダッシュボード用に独立した Redshift クラスタを持っており、これまでは主に営業データだけを扱ってきました。最近になって営業部門から、ETL クラスタ側にある集約データと、自身の BI クラスタにあるデータを結合して分析したいという要望が出てきました。重要な ETL クラスタの処理を妨げることなく、かつ ETL クラスタのコンピューティングリソースの消費を最小限に抑えながら、このデータ共有要件を満たすにはどうすべきでしょうか。
正解不正解ヒントボタン
Redshift 間でデータを共有したいときに「コピーではなく参照」で実現できる仕組みが Data Sharing です。生産系クラスターの負荷を増やさずに、分析用クラスター側のリソースでクエリを実行できる点がポイントになります。
-
質問 6 of 22
6. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-19】
ある金融サービス企業は、取引履歴やポジション情報などの財務データを Amazon Redshift に格納し、Web ベースのトレーディングアプリケーションからそのデータに対してオンデマンドでクエリを実行したいと考えています。アプリケーション側ではコネクションプールやドライバの管理を極力シンプルに保ちたいという要件があり、運用チームも接続管理の負担を増やしたくありません。これらの要件を満たす、最も運用オーバーヘッドの小さい接続方式はどれでしょうか。正解不正解 -
質問 7 of 22
7. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-34】ある企業は分析用データを Amazon Redshift クラスターに保存しており、クエリ性能のボトルネックを解消したいと考えています。クラスタサイズを大きくするための予算はなく、現在はすべてのテーブルで EVEN ディストリビューションスタイルを採用しています。数百 GB 規模の大きなファクトテーブルに加え、10 MB 未満の小さな参照テーブルも多数存在します。限られたリソースの中で SQL クエリの性能を最大化するには、どのようなテーブル設計が適切でしょうか。
正解不正解ヒントボタン
テーブルのサイズと役割ごとにディストリビューションスタイルを変える、という Redshift の設計指針を思い出してみましょう。
-
質問 8 of 22
8. 質問
カテゴリ: DEA-分野3-データの運用とサポート【DEA-35】あるデータエンジニアは、月に 1 度だけ非常に重い分析バッチを実行するために Amazon Redshift を利用しています。現在は毎月新しいプロビジョニング済み Redshift クラスターを作成し、必要な期間だけ分析処理を流してから、S3 に結果をアンロードしてクラスターごと削除する運用を手動で繰り返しています。今後はインフラの作成・削除やスナップショット管理を極力自動化し、分析ジョブの実行にだけ集中したいと考えています。運用上のオーバーヘッドを最も小さくできる選択肢はどれでしょうか。
正解不正解ヒントボタン
「Redshift は使いたいが、クラスターという概念は極力意識したくない」という要件から、従量制のサーバーレスオプションを思い出してみてください。
-
質問 9 of 22
9. 質問
カテゴリ: DEA-分野1-データの取り込みと変換【DEA-37】ある分析基盤チームは、10 個の業務システムから出力される CSV・JSON・Apache Parquet ファイルを、15 分ごとに 1 つの Amazon S3 バケットに集約しています。各ファイルのサイズはおおよそ 10 MB〜20 GB でばらつきがあり、それぞれを Amazon Redshift 内の 10 個のテーブルに取り込む ETL パイプラインを構築したいと考えています。今後、ソースシステム側でカラム追加などのスキーマ変更が発生しても、パイプラインをほとんど手作業なしで追従させたい場合、どのようなデータパイプライン構成を選ぶべきでしょうか。（2 つ選択）
正解不正解ヒントボタン
スキーマ変更に耐えられるかどうかに注目し、Glue クローラーとワークフローの組み合わせが出てくる構成を探してください。
-
質問 10 of 22
10. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-40】ある企業は、業務アプリケーションから発生するログやイベントを、秒あたり数ギガバイトの規模でストリーミング収集しています。今後、このデータを Amazon Kinesis Data Streams と Amazon Redshift を組み合わせて取り込み、ほぼリアルタイムで集計・可視化できる分析基盤を構築したいと考えています。既存の BI／分析ツールから Redshift に接続して最新の指標を確認できるようにしつつ、運用オーバーヘッドは最小限に抑えたい場合、どの構成を採用すべきでしょうか。
正解不正解ヒントボタン
ストリーミングデータと Redshift を組み合わせる問題では、「バッチで溜めてからロードする」のか「マテリアライズドビューなどでなるべくリアルタイムに近づける」のかに着目すると、要件に合う構成を選びやすくなります。
-
質問 11 of 22
11. 質問
カテゴリ: DEA-分野3-データの運用とサポート【DEA-42】あるチームは、トランザクションデータを保持する Amazon RDS データベースと、ドキュメントデータを保存している MongoDB クラスターから情報を集約し、分析用として Amazon Redshift にロードするデータパイプラインを AWS Glue で構築しています。更新頻度は 1 時間ごとで、できるだけマネージドな仕組みだけで運用したいと考えています。ETL ジョブの実行とデータソース／ターゲットへの接続を、最も運用オーバーヘッド少なく実現するタスクの組み合わせはどれでしょうか。（2 つ選んでください。）
正解不正解ヒントボタン
Glue ベースのパイプラインでは、「ジョブの定期実行は Glue トリガー」「データベースとの接続は Glue 接続」でマネージドに扱えることを押さえておくと、余計なコンポーネントを増やさずに済みます。
-
質問 12 of 22
12. 質問
カテゴリ: DEA-分野3-データの運用とサポート【DEA-44】ある企業は、`orders` という Amazon Redshift テーブルを 6 か月ほど運用しており、毎週の更新・削除処理を継続的に実行してきました。このテーブルには AWS リージョンを含む列に対してインターリーブソートキーが設定されています。クエリ性能が低下してきたため、インターリーブソートキーを再構成し、ソートキー列の統計情報も見直したいと考えています。どの Redshift コマンドを実行すべきでしょうか。
正解不正解ヒントボタン
Redshift で VACUUM を選ぶ際は、テーブルのソートキーが通常のソートキーかインターリーブソートキーかによって適切なサブタイプが異なる点と、統計情報の更新には ANALYZE が関与する点に注意してください。
-
質問 13 of 22
13. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-48】あるセキュリティ企業は、IoT デバイスから送られてくる JSON 形式のイベントデータを Amazon S3 バケットに蓄積しています。デバイスのファームウェア更新により、今後もデータ構造が変化する可能性があります。同社は、これらの IoT データについてスキーマやバージョンを把握できるデータカタログを整備し、分析チームがそのカタログを基にデータをインデックス化して検索・分析できるようにしたいと考えています。また、スキーマの変更履歴を専用のレジストリで管理し、どのイベントがどのスキーマバージョンに対応するかを追跡したいと考えています。最もコスト効率よくこの要件を満たすアーキテクチャはどれでしょうか。
正解不正解ヒントボタン
スキーマが変化しうるストリーミング／IoT データでは、「どの時点でどのスキーマだったか」を管理できる仕組みが重要です。Glue Data Catalog＋Schema Registry の組み合わせはその代表的な解となります。
-
質問 14 of 22
14. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-54】ある企業は、5 ノード構成の Amazon Redshift プロビジョンドクラスタ（ra3.4xlarge）を運用しており、ディストリビューションスタイルとして KEY 分散を使用しています。監視の結果、特定の 1 ノードだけ CPU 使用率が 90% を超える状態が続き、そのノードに割り当てられたクエリが頻繁にキュー待ちになる一方で、他の 4 ノードは日常的に 15% 程度の負荷にとどまっていることが分かりました。コンピュートノード数は増やさずに、この不均一な負荷をできるだけ均等に分散したい場合、どの対策を取るべきでしょうか。
正解不正解ヒントボタン
Redshift のスケーリング問題では、「どこに行が置かれているか」を意識して、分散スタイルと分散キーの選び方から見直すのが定石です。
-
質問 15 of 22
15. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-57】あるメディア企業は SaaS 型の外部ツールを使ってユーザー行動データを収集しており、そのデータを自社の Amazon S3 バケットに自動連携したいと考えています。取り込んだデータは Amazon Redshift にロードして分析に利用する予定です。カスタムコードや複雑なパイプラインを極力書かず、運用オーバーヘッドを抑えてこの連携を実現するためには、どのサービスや機能を使うのが最も適切でしょうか。
正解不正解ヒントボタン
サードパーティ SaaS と AWS の連携では、「専用コネクタがあるかどうか」を最初に確認すると設計が大幅に楽になります。AppFlow はその代表的な選択肢です。
-
質問 16 of 22
16. 質問
カテゴリ: DEA-分野3-データの運用とサポート【DEA-65】ある企業は、分析基盤として Amazon Redshift を利用しており、複数のマテリアライズドビューを ETL 結果のキャッシュとして活用しています。現在は手動で REFRESH 文を実行していますが、今後はスケジュールに沿って自動的にマテリアライズドビューを更新したいと考えています。最小限の設定変更で、Redshift 内からこの更新を自動化するにはどうすべきでしょうか。
正解不正解ヒントボタン
Redshift クエリエディタ v2 のスケジュールクエリ機能の有無や制約を確認し、最小限の設定で定期的な SQL 実行を自動化できる方法を検討してください。必要に応じて EventBridge や Redshift Data API などのマネージドな実行基盤との組み合わせも考慮してください。
-
質問 17 of 22
17. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-68】ある企業は、Amazon S3 をデータレイクとして、Amazon Redshift をデータウェアハウスとして利用する分析基盤を構築しています。S3 側にはログや明細データが膨大な件数で蓄積されており、Amazon Redshift Spectrum を使って S3 上のデータに直接クエリを投げたいと考えています。データエンジニアは、クエリ時間を短縮しつつコストも抑えられるように、ファイル形式や配置方法を見直したいと考えています。Redshift Spectrum のクエリ性能を最大限に引き出す構成として、どのような対策を組み合わせるべきでしょうか。（2 つ選んでください。）
正解不正解ヒントボタン
Spectrum では「列指向フォーマット＋パーティション設計＋適切なファイルサイズ」がクエリ性能の三本柱です。どれがスキャン量を減らし、どれが逆にオーバーヘッドを増やすかを意識して選択肢を見るとよいです。
-
質問 18 of 22
18. 質問
カテゴリ: DEA-分野2-データストア管理【DEA-72】あるデータエンジニアリングチームは、Amazon Redshift クラスタを運用レポーティング用途で使用しています。最近、複雑なクエリや誤った結合条件によって一部のクエリが極端に遅くなり、他のユーザーの処理にも影響を与えるケースが発生しました。チームは、クエリオプティマイザが潜在的なパフォーマンス問題を検知した際に、その内容を記録しているシステムテーブルを定期的に確認したいと考えています。どのシステムビューを参照すべきでしょうか。
正解不正解ヒントボタン
Redshift で「警告」「アラート」というキーワードが出てきたときに、STL_ALERT_EVENT_LOG の存在を思い出せるようにしておくと、ボトルネック調査の起点を素早く見つけられます。
-
質問 19 of 22
19. 質問
カテゴリ: SAP-分野4-ワークロードの移行とモダナイゼーション【SAP-68】ある総合小売業向けに SaaS 型の販売分析プラットフォームを提供しているある会社は、オンプレミス環境から AWS へ段階的に移行し、世界中の加盟店にリアルタイムの売上ダッシュボードを配信している。
社内では CFO から「次年度までにソフトウェアライセンス費を 30％削減し、同時に DBA チームの保守作業を軽減せよ」との方針が示されているほか、24 時間 365 日の運用をわずか 3 名のエンジニアで回すという体制上の制約がある。
ソリューションアーキテクトが AWS Application Discovery Service を用いてサーバフリートを調査した結果、Oracle で構築された大規模データウェアハウスと、複数の PostgreSQL データベースが稼働していることが判明した。
Oracle についてはライセンスコストが高く、スケールアウトにも制限がある点が財務・技術双方の課題となっている。
一方、PostgreSQL 群は複数環境に分散しており運用負荷が高い。
これらを AWS ネイティブあるいはマネージドサービスへ再配置することで、コスト最適化と保守工数削減を同時に実現したいと考えている。
ソリューションアーキテクトは、インフラ設計レベルでどの移行パターンの組み合わせを採用することで、ライセンス費用と運用オーバーヘッドの双方を最小化できると判断すべきか。
最も適切な組み合わせはどれか？（２つ選択）正解不正解ヒントボタン
本問には「データウェアハウス（DWH）」と「データベース（DB）」という2種類のシステムが登場し、それぞれ別の課題を抱えている。
【DWH と DB の違いをざっくり理解しよう】
・データベース（DB）＝お店のレジのようなもの。「今この瞬間の注文を記録・更新する」など、1件1件の処理（トランザクション）を高速にさばくのが得意。PostgreSQL や MySQL が代表例。
・データウェアハウス（DWH）＝倉庫に過去の売上伝票を全部集めて分析するようなもの。「過去3年分の売上を地域別・月別に集計する」など、大量データをまとめて分析するのが得意。Amazon Redshift や Oracle DWH が代表例。
つまり DB は「書き込み・更新が多い日常業務向け」、DWH は「読み取り・集計が多い分析向け」と覚えておくとよい。【Amazon Redshift と Amazon EMR の違いも押さえよう】
どちらも「大量のデータを扱う」サービスだが、役割が異なる。
・Amazon Redshift ＝ SQLで集計・分析するための「データウェアハウス」。BIツールやダッシュボードから SQL を投げて、売上集計やレポートを素早く返すのが得意。フルマネージドで運用負荷が低い。
・Amazon EMR ＝ Hadoop/Spark などを動かす「ビッグデータ処理基盤」。ログ解析、機械学習の前処理、ETL パイプラインなど、プログラムを書いて大規模データを加工・変換するのが得意。柔軟だが、クラスタ管理やジョブ設計など運用の手間が多い。
簡単に言えば、Redshift は「SQLで問い合わせる倉庫」、EMR は「プログラムでデータを加工する工場」とイメージするとよい。本問のように「Oracle DWH の置き換え」が目的なら、同じ DWH カテゴリの Redshift が自然な移行先となる。Oracle DWH はライセンス費が課題→『AWS SCT＋DMS で Redshift』、PostgreSQL 群は運用分散が課題→『DMS で RDS for PostgreSQL に統合』という、ライセンス削減と運用軽減を同時に狙う移行パターンを思い出す。両方を移行して初めて CFO の要件を満たせる点がポイント。
-
質問 20 of 22
20. 質問
カテゴリ: SAP-分野2-新しいソリューションの設計【SAP-176】あるヘルスケア機器メーカーでは、人口統計研究向けに開発した携帯型遺伝子スキャナを世界各地の病院に配備し、研究者がブラウザからリアルタイムで遺伝子多様性の指標を閲覧できる SaaS を運営している。
装置は毎秒 8 KB の遺伝子データをクラウドに送出し、プラットフォーム側では①ほぼ即時に解析結果をダッシュボードへ反映し論文執筆までのリードタイムを短縮するというビジネス上の狙いがある。
技術的には②スループット可変に追従できる並列処理基盤、③障害時にも生データを損なわない耐久性、④集計結果をデータウェアハウスへ安定配信し BI から横断的にクエリできることが必須条件となっている。
運用は少人数の DevOps チームで継続的に改善しており、自動スケールとフルマネージドサービスを優先したい。
ソリューションアーキテクトはこれらの前提を踏まえ、インフラ設計レベルでどの AWS サービス構成を採用すべきか？正解不正解ヒントボタン
秒単位で流れ続けるセンサーデータの取り込みには Kinesis 系サービスと S3／Redshift を組み合わせたストリーム＋DWH パターンを思い出す。問題文に「データウェアハウス」とあれば AWS では Amazon Redshift が該当する。QuickSight は可視化ツール、OpenSearch は検索・ログ分析基盤であり、DWH とは役割が異なる点に注意。Kinesis Data Streams と Data Firehose の選び分けもポイント：「カスタム処理・複数コンシューマ・リアルタイム集計」が必要なら Data Streams、「特定の宛先への簡単な配信」だけなら Firehose。Lambda での集計結果は DynamoDB 等の高速データストアを経由してダッシュボードに反映される。
-
質問 21 of 22
21. 質問
カテゴリ: SAP-分野2-新しいソリューションの設計【SAP-186】あるデータ分析会社は金融機関向けに不正検知レポートを提供しており、日次ETLで取り込んだデータを Amazon Redshift クラスタ（予約ノード構成）上に蓄積し、社内外のユーザーへ SQL ベースのダッシュボードを公開している。
四半期決算期になると監査部門が詳細レポートを大量発行するため、CPU 集約型の複雑な読み取りクエリが短時間に集中し、通常トラフィックを大幅に上回るバーストが発生している。
コスト最適化方針のため恒常的なノード追加は認められず、運用部門も夜間や週末に手動スケールを行わない運用体制を採用している。
ビジネス要件は、①監査レポートを SLA 内に生成し顧客への提出遅延を防ぐこと、②同時に ETL の書き込みや日常的なダッシュボード閲覧を中断させないこと、である。
技術的には、読み取り負荷の急増時のみ自動的に計算リソースを拡張し、ピークが過ぎれば追加コストを抑制できる仕組みが必要と考えている。
ソリューションアーキテクトはこれらの制約を踏まえ、インフラレベルで突発的なリードクエリの増大に追随しながら書き込みワークロードも継続可能な構成を決定する責任を負う。
読み取りと書き込みのクエリを随時処理しつつ、予期しないスパイクに自動対応できる AWS の機能を採用する場合、最適な選択肢はどれか？正解不正解ヒントボタン
Redshift の読み取りスパイク対応には、ノード増減（Resize）ではなく Concurrency Scaling を使ったオンデマンドな追加コンピュートを優先して考える。Concurrency Scaling は「キューが混んだら自動で別クラスタを立ち上げて読み取りクエリを肩代わり（オフロード）し、空いたら自動停止する」機能で、ユーザー側の接続変更は不要。Classic Resize（時間がかかりダウンタイムあり）や Elastic Resize（高速だが構成変更が走る）との違いを整理しておくこと。
-
質問 22 of 22
22. 質問
カテゴリ: SAP-分野4-ワークロードの移行とモダナイゼーション【SAP-190】ある小売チェーンを運営する会社では、店舗とECサイトの販売実績を分析する30 TBのOracleデータウェアハウスをオンプレミスで稼働させている。
経営層は集計時間短縮と繁忙期のクエリ増加に備えた弾力的スケールを求め、Amazon Redshiftへの移行を決定した。
システムは営業部門に日次ダッシュボードを提供しており、ダウンタイムは年度決算前の２週間のデータ凍結期間に限られる。
スキーマはAWS Schema Conversion ToolでRedshift用に変換済みで、移行評価レポートから一部手作業が残ることも把握している。
運用チームは少人数のため極力マネージドサービスを利用したい。
オンプレミスとAWS間の接続は50 Mbpsのインターネット回線のみで、この帯域では凍結期間内に30 TBを転送できないと試算している。
ソリューションアーキテクトは、初回のフルロードと残りの差分同期を効率的かつ安全に行い、凍結期間内に切り替えを完了させるために、どの移行戦略を採用すべきか？正解不正解ヒントボタン
帯域の細い回線しかないとき、初回 30 TB のフルロードとその後の差分同期を別の手段で行う、という観点で Snowball 系サービスと DMS の使い分けをイメージする。判断のコツは「大量の初回データ（TB 級）をネットワークで送ると何日かかるか」を計算し、期限内に終わらないなら Snowball（物理デバイスで輸送）、期限内に終わる量なら DMS（ネットワーク経由の差分レプリケーション）と切り分けること。
改善リクエスト