メインコンテンツに移動

東京と大阪リージョンを活用して、 パイロットライト戦略で災害対策 (DR) を実現したい

データレプリケーションを常時稼働させながら、アプリケーションは必要時のみ起動するコスト効率の高い DR 環境を実現する AWS クラウド構成例とその概算料金をご紹介します

構成概要

この構成例のクラウドレベル:

応用編

入門編:該当するユースケースの知識が全くない方が対象
基礎編:該当するユースケースの入門知識がある方が対象
応用編:該当するユースケースにある程度精通している方が対象

この構成例で解決できる課題・困りごと:

  • 単一リージョンのマルチ AZ では事業継続計画(BCP)の要件を満たせない

  • 10 分~ 60 分の目標復旧時間(RTO)と目標復旧時点(RPO)を実現したい

  • 災害発生時に迅速にシステムを復旧させる必要がある

  • DR 環境のコストを最適化したい

この構成例の概算料金:

1,187.86 ドル (月額)

この構成例のメリット:

  • プライマリリージョンと DR 用リージョン間でデータを継続的にレプリケーション

  • DR 用リージョンではコアリソースのみを稼働させることでコストを最適化

  • Infrastructure as Code (IaC) によって災害時の DR サイトへの復旧を自動化

  • Aurora Global Database によって 1 分以内のフェイルオーバーを実現

Missing alt text value

月額合計料金:1187.86(USD)

この構成例で使用したサービスと概算料金内訳

サービス
項目
数量
単価
料金 (USD)
Amazon Route 53

ホストゾーン

標準クエリ

1

1 百万

0.50 USD/毎月のホストゾーンあたり

0.40 USD/100 万クエリ

0.50

0.40

[東京リージョン] Elastic Load Balancing

時間当たりの料金

ロードバランサーキャパシティーユニット *a

730 時間

1 LCU × 730 時間

0.0243 USD/時間

0.008 USD/時間

17.74

5.84

[東京リージョン] Amazon EC2

インスタンス (m5.large)

2 × 730 時間

0.124 USD/時間

181.04

[東京リージョン] Amazon Elastic Block Store

汎用SSD (30 GB の gp2 ボリューム) *b

2 × 30 GB

0.12 USD/GB

7.20

[東京リージョン] Amazon Aurora

インスタンス (db.r6g.large)

ストレージ料金

ベースライン I/O レート (200 リクエスト/秒 を 690 時間)

ピーク時の I/O レート (300 リクエスト/秒 を 40 時間)

2 インスタンス x 730 時間

100 GB

496.8 百万リクエスト

43.2 百万リクエスト

0.313 USD/時間

0.12 USD/毎月のGBあたり

0.24 USD/100 万リクエスト

0.24 USD/100 万リクエスト

456.98

12.00

119.23

10.37

[大阪リージョン] Amazon Aurora

インスタンス (db.r6g.large)

ストレージ料金

ベースライン I/O レート (200 リクエスト/秒 を 690 時間)

ピーク時の I/O レート (300 リクエスト/秒を 40 時間)

Aurora Global Database に レプリケートされた書き込み I/O *c

1 インスタンス x 730 時間

100 GB

248.4 百万リクエスト

21.6 百万リクエスト

270 百万件

0.312 USD/時間

0.12 USD/毎月の GB あたり

0.24 USD/100 万リクエスト

0.24 USD/100 万リクエスト

0.24 USD/レプリケートされた書き込み I/O 100 万件

227.76

12.00

59.62

5.18

64.80

[大阪リージョン] Amazon Elastic Block Store

汎用SSD (30 GB の gp2 ボリューム ) *b

2 × 30 GB

0.12 USD/GB

7.20

  • 東京リージョンと大阪リージョンをご利用で、通常運転時の費用を想定しています。災害発生時に 大阪リージョンがスイッチオンされた後は、DR 元と同等の各種リソースの費用が発生します。

  • 別途、データ転送料金が発生します。詳細は Amazon EC2 料金ページのデータ転送でご確認ください。

  • この構成の RTO は、大阪リージョンをスイッチオンしてから準備が整い、同リージョンのリードレプリカが昇格し、トラフィックの切り替えが完了するまでです。目安は 10 分〜 60 分です。

  • この構成の RPO は RDS の最終レプリケーション完了時点です。 Amazon Aurora Global Database では、セカンダリリージョンへのレプリケーションに伴うレイテンシーは、一般的に 1 秒未満 です。

  • よりコストをかけて RTO/RPO の短縮を目指す場合は、ウォームスタンバイ戦略、マルチサイト アクティブ-アクティブなどの戦略を採用します。

  • コスト削減を優先して RTO/RPO の要件を緩和する場合は、バックアップ&レストア戦略を採用します。目安は 1 時間〜 24 時間です。

  • a) LCU の決定には複数の指標があり使用量が最も多いもののみに請求が発生します。詳細は Elastic Load Balancing の料金ページをご確認ください。

  • b) EC2 ではストレージとして Amazon EBS を組み合わせて利用します。

  • c) 災害が発生していない状況では、このインスタンスに読み込みは発生しない想定です。東京リージョンのインスタンスにおける読み書きの比率を 5:5 と仮定した場合、大阪リージョンのインスタンスに発生する書き込みは、全体の 5 割であるといえます。その為、ここでは東京リージョンの5 割の負荷で見積もりをしています。

※ 2024 年 12 月 18 日時点での試算です

この AWS サービスに関する参考ページ

AWS 内で利用できる災害対策の戦略は、4 つのアプローチに大別できます。以下のホワイトペーパーでご確認いただけます。