LASSIC Media らしくメディア
AWS Backupの保管コストを削減する外注の進め方
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- AWS Backupの保管コストは、バックアップボールトに溜まる復元ポイントとEBSスナップショットが長期保持されることで膨らみます。バックアッププランのライフサイクルとリテンション設計の見直しが圧縮の起点になります。
- ウォームストレージからコールドストレージ(EBSはEBS Snapshots Archive)への移行や、クロスリージョン/クロスアカウントコピーの範囲見直しが、保管コストを抑える主な打ち手です。ただしコールドストレージには最低90日の保持要件があります*1。
- 外注では、対象ボールトとプランの棚卸し・ライフサイクル設計・復元要件(RTO/RPO)の確認を契約前に合意し、削減だけでなく復元できる状態を保つことが大切です。
目次
AWS Backupの保管コストはどこで膨らむのか—ボールトとプランの仕組み
AWS Backup(Amazon Web Servicesのマネージドバックアップサービス)は、EBS(Amazon Elastic Block Store)ボリュームをはじめとする各種リソースのバックアップを、ポリシーに沿って自動で取得・保持するサービスです。保管コストは、取得したバックアップデータがストレージを占有する量(GB-month、月平均の使用容量)に応じて課金されます*1。つまり「どれだけのデータを、どのストレージ階層で、どれだけの期間保持するか」が費用を左右します。
AWS Backupの費用構造を理解するうえで押さえておきたい主な構成要素は次の3つです。
第一に、バックアップボールトです。ボールトはバックアップデータ(復元ポイント)を格納するコンテナで、暗号化やアクセス制御、ライフサイクルのルールを持ちます*2。ここに復元ポイントが世代として積み上がっていきます。
第二に、バックアッププランとバックアップルールです。プランは「いつ・どのように」バックアップを取得し保持するかを定めるポリシーで、取得頻度や保持期間、コールドストレージへの移行(ライフサイクル)を指定します*3。プランの設計がそのまま保管容量に反映されます。
第三に、ストレージ階層です。バックアップは通常、ウォームストレージに保持されますが、ライフサイクル設定により、より単価の低いコールドストレージへ移行できます。EBSの場合、コールドストレージはEBS Snapshots Archive(アーカイブ階層)に該当します*1。
増分バックアップでも保管容量が積み上がる理由
AWS Backupは、対応するリソースについて増分バックアップを行います。最初のバックアップはフルコピーですが、以降は変更分のみを取得するため、頻繁なバックアップでもストレージコストを抑えやすい設計です*3。ただし、増分であっても世代を多く・長く保持すれば、ボールトに蓄積されるデータ総量は増えていきます。なお、増分に対応しないリソースタイプでは各バックアップがフルコピーとなり、保管コストが高くなる場合があります*3。
このため、保管コストの見直しでは「取得頻度を減らす」よりも先に、不要に長い保持期間と、ウォームのまま放置された古い世代に着目するのが起点になります。
ライフサイクルでウォーム→コールドストレージへ移行する
保管コスト削減の中心的な打ち手が、バックアッププランのライフサイクル設定によるコールドストレージへの移行です。アクセス頻度の低い古い復元ポイントを、単価の低いコールドストレージ(EBSではEBS Snapshots Archive)へ自動的に移すことで、保管コストを抑えやすくなります*1。
ライフサイクル設定の2つのパラメータ
ライフサイクルは、主に次の2つの日数で制御します*4。
MoveToColdStorageAfterDaysは、作成からこの日数が経過した復元ポイントをコールドストレージへ移行する設定です。DeleteAfterDaysは、作成からこの日数が経過した復元ポイントを削除する設定です。
ここで重要な制約があります。AWS公式ドキュメントによれば、コールドストレージへ移行したバックアップは最低90日間コールドストレージに保持する必要があり、そのためコンソール上では保持(削除)の設定が移行設定より90日以上長くなければなりません*4。また、コールドストレージへの移行日数は、いったん移行されたバックアップに対しては変更できません*4。
コールドストレージ移行の最低保持要件に注意する
コールドストレージに移したバックアップを90日より前に削除すると、残りの日数分に相当する保管料金が日割りで課金されます*1。短期間で削除する見込みの世代を無理にコールドへ移すと、かえって割高になる場合があります。「長く保持する世代をコールドへ、短期で消す世代はウォームのまま」という切り分けが、設計のポイントになります。
設計のヒント
「移行までの日数+90日以上」を満たす保持期間を設定したうえで、削除予定が90日未満の短期世代はコールドへ移さない。これにより最低保持要件による割高な課金を避けやすくなります*1 *4。
本稿はAWS Backupというマネージドサービス固有の保管コストに絞って解説します。EBSスナップショットを含むクラウドのバックアップ・スナップショット全般の最適化はクラウドのバックアップ・スナップショットコストを外注で最適化する進め方で整理しているので、あわせてご覧ください。
保持期間(リテンション)設計で過剰な世代を削る
ライフサイクルと並んで重要なのが、保持期間(リテンション)そのものの設計です。AWS Backupは保持設定に基づいてバックアップのライフサイクルを管理し、不要になった世代を自動で削除します*3。逆にいえば、保持設定が過大なまま、あるいは無期限のままだと、復元ポイントが消えずに積み上がり続けます。
業務要件から逆算してリテンションを決める
保持期間は「念のため長め」ではなく、復旧要件や法令・社内規程から逆算して決めることが大切です。日次・週次・月次・年次といったバックアップルールごとに、それぞれ何世代・何日保持するかを定義します。たとえば日次は数週間、月次は数か月、年次は規程に沿った長期保持、といった具合に階層化することで、必要な復元性を保ちつつ容量の肥大化を抑えやすくなります。
無期限保持を指定する場合、AWS Backupではライフサイクルの両パラメータに-1を指定することで復元ポイントを無期限に保持できます*4。長期保管が本当に必要な世代に限定し、それ以外は明確な削除日数を持たせることが、保管コストの抑制につながります。
複数プランの重複保持を棚卸しする
運用が長くなると、似たようなバックアッププランが複数作られ、同じリソースが重複してバックアップされている場合があります。AWS Backupでは、要件の異なるワークロードごとに複数のプランを作成できますが*3、意図せぬ重複は保管容量の無駄につながります。対象リソースとプランの割り当てを棚卸しし、重複や使われていないプランを整理することも、保管コスト見直しの一部です。
クロスリージョン/クロスアカウントコピーのコストを見直す
災害対策(DR)や統制の観点から、バックアップを別リージョンや別アカウントのボールトへコピーする運用があります。AWS Backupでは、プライマリリージョンで取得したバックアップを別リージョンのボールトへ自動コピーするクロスリージョンコピーや、別アカウントのボールトへ複製するクロスアカウントコピーが利用できます*2。これらは可用性やコンプライアンスを高める一方で、保管コストの観点では見直し対象になります。
コピー先でも保管料金が発生する
コピーされたバックアップは、コピー先リージョンやコピー先アカウントのストレージ料金が発生し、その費用はコピー先で積み上がります*1。リージョンによって単価が異なる場合もあるため、コピー先の保管容量と単価は元のリージョンと分けて把握する必要があります。さらに、コピー操作自体に加えて、標準的なデータ転送料金が適用される場合があります*1。
コピー対象と保持期間を必要分に絞る
保管コストの観点では、「全リソース・全世代を別リージョンへコピーする」運用が割高になりやすい典型です。DR要件上、復旧に本当に必要なリソースとデータだけをコピー対象に絞り、コピー先でも適切なライフサイクルと保持期間を設定することで、二重に保管されるデータ量を抑えやすくなります。コピー先のボールトにも、移行・削除のライフサイクルを設定することが大切です。
EBSスナップショット連携とアーカイブ階層の使いどころ
EBSボリュームのバックアップは、内部的にEBSスナップショットとして保管されます。AWS Backupのコールドストレージ移行をEBSに適用すると、バックアップはEBS Snapshots Archive(アーカイブ階層)へ移行されます*1。長期保持が必要だがアクセス頻度の低いスナップショットを、より単価の低い階層へ移すことが保管コスト削減の打ち手になります。
標準階層とアーカイブ階層の単価差
AWS公式の料金ページでは、EBS Snapshots Archiveの保管料金として1か月あたり0.0125 USD/GB、標準のEBSスナップショット保管料金として1か月あたり0.05 USD/GB が例として示されています(いずれもページ内の試算例として記載・2026年6月時点)*5。リージョンによって実際の単価は異なるため、具体的な金額はAWS Pricing Calculator等で対象リージョンの料金を確認してください*5。
| 比較軸 | 標準(ウォーム)階層 | アーカイブ(コールド)階層 |
|---|---|---|
| 想定用途 | 直近世代・短期復元を見込むスナップショット | 長期保持・アクセス頻度の低いスナップショット |
| 保管単価の傾向 | アーカイブ階層より高い(例:0.05 USD/GB・月、試算例・2026年6月時点)*5 | 標準階層より低い(例:0.0125 USD/GB・月、試算例・2026年6月時点)*5 |
| 最低保持要件 | 特段の最低保持日数の指定なし | 最低90日。90日より前の削除は残り日数分が日割り課金*1 *5 |
| 向くケース | 頻繁に取得し短期で削除する世代 | 90日以上保持する前提の古い世代・コンプライアンス保管 |
アーカイブ移行が向かないケースもある
アーカイブ階層は単価が低い一方、最低90日の保持要件があるため、頻繁に取得して短期間で削除する世代には向きません*1 *5。また、コールド/アーカイブからの復元には、ウォーム階層と比べて追加の時間やコストを要する場合があります。復元のスピード要件(RTO)と保管コストのバランスを踏まえ、どの世代をアーカイブへ移すかを判断することが大切です。具体的な単価・復元条件はリージョンや時点で変わるため、AWS公式の料金情報で確認してください*1 *5。
AWS Backupの保管コスト削減を外注する進め方
ここまでの打ち手は、ボールト・プラン・ライフサイクル・コピー設定にまたがり、復元要件と料金体系の両方を理解して設計する必要があります。社内に専門人材が不足する場合、外注で進めるのが選択肢になります。段階を踏むことで、削減と復元性の両立につながりやすくなります。
ステップ1:ボールトとプランを棚卸し・可視化する
まず、どのボールトにどのリソースの復元ポイントがどれだけ溜まっているか、各バックアッププランの取得頻度・保持期間・ライフサイクル設定を一覧化します。AWS BackupのダッシュボードやCost Explorerで保管容量とコストの内訳を把握しておくと、委託先との初回打ち合わせを効率的に進められます。
ステップ2:復元要件(RTO/RPO)を確認する
保管コストの削減は、復元できる状態を保ったうえで行うことが前提です。システムごとにRPO(どこまでのデータ損失を許容するか)・RTO(どれだけ早く復旧する必要があるか)・法令や社内規程上の保管期間を整理し、削ってはいけない世代を明確にします。ここを飛ばすと、コスト削減と引き換えに復旧できないリスクを抱えることになります。
ステップ3:ライフサイクル・保持・コピー設定を設計し合意する
棚卸しと復元要件をもとに、どの世代をコールドへ移行するか、保持期間をどう階層化するか、クロスリージョン/クロスアカウントコピーの対象をどこまで絞るかを設計します。コールドストレージの最低90日要件など料金体系上の制約を反映し*1 *4、委託範囲・適用手順・ロールバック方針を契約前に合意します。
ステップ4:設定を適用し復元テストで検証する
設計した設定を、影響の小さい範囲から段階的に適用します。重要なのは、設定変更後に実際に復元できることをテストで確認することです。保管コストが下がっても復元できなければ意味がないため、代表的なリソースで復元テストを行い、要件どおりに復旧できるかを検証します。
ステップ5:継続運用とモニタリングを回す
適用後も、新規リソースの追加やワークロードの変化に応じて設定は陳腐化します。保管容量とコストを定期的にモニタリングし、不要なプラン・世代の整理を継続する運用体制を整えることが大切です。委託する場合も、発注者側でレポートを確認し、変更の承認を行う体制を持つことが成果につながります。
外注でつまずきやすい失敗パターンと対策
AWS Backupの保管コスト削減を外注する際、成果が出にくくなる典型的なパターンを挙げます。事前に把握しておくことで回避しやすくなります。
失敗1:復元要件を確認せずに保持期間を一律短縮する
保管容量を減らそうとして保持期間を一律に短くすると、法令上必要な世代や復旧に必要な世代まで削除してしまうおそれがあります。RPO・RTO・規程上の保管要件を先に整理し、システムごとに必要な保持を定義したうえで削減することが大切です。
失敗2:短期世代までコールドへ移行し割高になる
コールドストレージには最低90日の保持要件があり、それより前に削除すると残り日数分が日割りで課金されます*1。削除予定が90日未満の世代まで一律にコールドへ移すと、かえって費用が増える場合があります。「90日以上保持する世代だけをコールドへ」という切り分けが対策になります。
失敗3:クロスリージョンコピーを全件のまま放置する
DR目的で設定したクロスリージョン/クロスアカウントコピーを、対象や保持期間を見直さず全件のまま運用すると、コピー先で保管コストが積み上がります*1。復旧に本当に必要な範囲へコピー対象を絞り、コピー先ボールトにもライフサイクルと保持を設定することで、二重保管の無駄を抑えやすくなります。
まとめ—AWS Backup保管コスト削減の3つの判断軸
本稿では、AWS Backupの保管コストが膨らむ仕組みと、ライフサイクル・保持期間・コピー設定・EBSアーカイブ階層を使った削減の打ち手、そして外注で進める手順を整理しました。要点を3つに集約します。
第一に、保管コストはボールトに溜まる世代と保持期間で決まるということです。取得頻度を下げる前に、過剰な保持期間とウォームのまま放置された古い世代に着目するのが起点になります。
第二に、コールドストレージ移行とコピー範囲の見直しが主な打ち手です。ただしコールドには最低90日の保持要件があり*1 *4、短期世代まで移すと割高になります。料金体系の制約を踏まえた設計が前提です。
第三に、削減は復元できる状態とセットです。RPO/RTOと法令・規程上の保管要件を先に整理し、設定変更後は復元テストで検証する。外注する場合も、復元要件の合意とモニタリング体制を発注者側が主体的に持つことが、コスト削減と事業継続性の両立につながります。
よくある質問
AWS Backupのコールドストレージへ移行すると保管コストはどれくらい変わりますか?
単価はリージョンや時点によって異なるため一律には言えません。AWS公式の料金ページでは、EBS Snapshots Archive(アーカイブ階層)の保管料金が1か月あたり0.0125 USD/GB、標準のEBSスナップショット保管料金が1か月あたり0.05 USD/GB と試算例として示されています(2026年6月時点)*5。実際の削減幅は対象データ量・保持期間・リージョンで変わるため、AWS Pricing Calculatorで対象リージョンの料金を確認することをお勧めします*5。
コールドストレージに移したバックアップはいつでも削除できますか?
コールドストレージへ移行したバックアップには最低90日の保持要件があります。90日より前に削除すると、残りの日数分に相当する保管料金が日割りで課金されます*1。また、コンソール上では保持(削除)の設定が移行までの日数より90日以上長くなければならず、移行までの日数は移行後には変更できません*4。短期間で削除する世代は、コールドへ移さずウォームのまま保持する設計が向いています。
クロスリージョンコピーはコスト削減の妨げになりますか?
クロスリージョン/クロスアカウントコピー自体は災害対策や統制のために有効ですが、コピー先でも保管料金が発生し、標準的なデータ転送料金が適用される場合があります*2。妨げになるのは、対象や保持期間を見直さずに全件をコピーし続けている状態です。復旧に必要なリソースへコピー対象を絞り、コピー先ボールトにもライフサイクルと保持期間を設定することで、保管コストを抑えやすくなります。
保管コストを下げると復元できなくなるリスクはありませんか?
保持期間の短縮や世代の削除を、復元要件を確認せずに行うとリスクがあります。システムごとにRPO(許容できるデータ損失)・RTO(許容できる復旧時間)・法令や社内規程上の保管期間を先に整理し、削ってはいけない世代を明確にしたうえで削減することが大切です。設定変更後は代表的なリソースで復元テストを行い、要件どおり復旧できるかを検証することをお勧めします。
AWS Backupの保管コスト削減は社内対応と外注のどちらが向いていますか?
両者は排他的ではありません。社内にAWS Backupのライフサイクルや料金体系に通じた担当者がいる場合は内製で進められますが、専門知識が不足する場合は外注で早期に着手しつつ、設計の考え方を社内に蓄積していくのが現実的です。いずれの場合も、復元要件の整理と設定変更後の復元テスト、継続的なモニタリングは発注者側が主体的に関与することが成果につながります。
著者:テレリモ総研編集部 鈴木 亮佑
ITアウトソーシング・システム保守運用のご相談はLASSICへ
元請(プライムベンダー)として、貴社のAWS Backup保管コスト削減と運用体制の構築をご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:Amazon Web Services「AWS Backup Pricing」(2026年6月時点)
- *2 出典:Amazon Web Services「Backup vaults(AWS Backup Developer Guide)」(2026年6月時点)
- *3 出典:Amazon Web Services「Backup plans(AWS Backup Developer Guide)」(2026年6月時点)
- *4 出典:Amazon Web Services「Lifecycle(AWS Backup API Reference)」(2026年6月時点)
- *5 出典:Amazon Web Services「Amazon EBS pricing」(2026年6月時点)