ストレージ

Amazon EBS

EC2 インスタンスにアタッチして使用するブロックストレージサービスで、SSD と HDD の複数のボリュームタイプから用途に応じて選択できる

約 2 分で読めます

概要

Amazon Elastic Block Store (EBS) は、EC2 インスタンスに接続して使用する高性能なブロックストレージサービスです。ファイルシステムやデータベースのストレージとして利用でき、インスタンスを停止・再起動してもデータが永続化されます。汎用 SSD (gp3)、プロビジョンド IOPS SSD (io2)、スループット最適化 HDD (st1)、コールド HDD (sc1) の 4 つのボリュームタイプがあり、IOPS 性能、スループット、コストのバランスに応じて選択できます。EBS ボリュームは同一アベイラビリティゾーン内で自動的に複製されるため、単一ハードウェアの障害からデータを保護します。スナップショット機能を使えば、ボリュームのポイントインタイムバックアップを S3 に保存し、別のアベイラビリティゾーンやリージョンに復元することも可能です。

gp3 と io2 - IOPS 要件で分かれるボリューム選定

EBS のボリューム選定は、ワークロードが求める IOPS とスループットの数値から逆算します。gp3 (汎用 SSD) はベースラインとして 3,000 IOPS / 125 MB/s が含まれ、追加料金で最大 16,000 IOPS まで拡張できます。Web サーバーのルートボリューム、中小規模の RDS、開発環境のほとんどは gp3 で十分です。gp2 から gp3 への移行はオンラインで実行でき、同等以上の性能を維持しつつ最大 20% のコスト削減が見込めます。一方、io2 Block Express は最大 256,000 IOPS を提供し、Oracle や SAP HANA のような大規模データベースで求められるサブミリ秒レイテンシを実現します。Azure Managed Disks の Premium SSD v2 も IOPS の独立設定に対応していますが、io2 Block Express の 256,000 IOPS は Azure Ultra Disk の上限 160,000 IOPS を上回る点で差があります。HDD 系では、st1 がログ処理やビッグデータのシーケンシャル読み取りに、sc1 がアクセス頻度の低いアーカイブデータに適しており、GB 単価を大幅に抑えられます。

スナップショットと暗号化の設計

EBS スナップショットは増分バックアップ方式を採用しており、初回のフルコピー以降は変更されたブロックだけを S3 に保存します。この仕組みにより、数 TB のボリュームでも日次スナップショットのコストと作成時間を最小限に抑えられます。スナップショットは別の AZ やリージョンに復元できるため、災害復旧 (DR) 戦略の基盤としても機能します。Amazon Data Lifecycle Manager (DLM) を使えば、スナップショットの作成・保持・削除をスケジュールベースで自動化でき、手動管理の負担を排除できます。暗号化については、アカウントレベルで EBS のデフォルト暗号化を有効にし、KMS のカスタマーマネージドキーを指定するのがベストプラクティスです。キーポリシーで暗号化・復号を実行できるプリンシパルを制限し、CloudTrail でキー使用履歴を監査することで、コンプライアンス要件にも対応できます。ブロックストレージの関連書籍 (Amazon) では、暗号化設計のパターンも詳しく解説されています。

コスト最適化とサイジングの勘所

EBS のコスト最適化で最も効果が大きいのは、ボリュームタイプの見直しです。gp2 のまま放置されているボリュームを gp3 に変更するだけで、性能を維持しつつ約 20% のコスト削減が可能です。CloudWatch の VolumeReadOps / VolumeWriteOps メトリクスを確認し、実際の IOPS 消費がベースラインを大幅に下回っているボリュームは過剰スペックの可能性があります。逆に、gp3 の 16,000 IOPS 上限を超える要件がある場合にのみ io2 への移行を検討します。未使用ボリュームの検出も重要で、EC2 インスタンスを終了した後にデタッチ状態で残り続けるボリュームは課金が継続します。AWS Cost Explorer のリソース別コストビューや Trusted Advisor の「使用率の低い Amazon EBS ボリューム」チェックを活用して、定期的に棚卸しを行いましょう。スナップショットについても、DLM で保持期間を適切に設定し、不要な世代が蓄積しないよう管理します。

共有するXB!

関連する用語

Amazon EC2Amazon S3Amazon EFS

関連するサービス

Amazon EC2Amazon S3

関連する記事

AWS の API はなぜ XML を返すのか - Query API から REST JSON への進化の歴史S3 や EC2 の API が XML レスポンスを返す歴史的経緯、Query API と REST API の違い、Signature V2 から V4 への認証方式の進化、SDK が隠蔽している複雑さを解説します。AWS の API エンドポイントはなぜリージョンごとに異なるのか - グローバルサービスとリージョナルサービスの設計ec2.us-east-1.amazonaws.com のようなリージョナルエンドポイントと iam.amazonaws.com のようなグローバルエンドポイントが分かれている設計理由、デュアルスタックエンドポイント、FIPS エンドポイントの存在を解説します。re:Invent の発表から読む AWS の 3 年後 - サービスのライフサイクルと廃止の法則CodeCommit の新規受付停止、SimpleDB の事実上の終了など、AWS サービスにも寿命があるという事実を直視し、サービスのライフサイクル分析と「消えないサービス」を見極める技術選定の視点を提供します。AWS サービス名の由来と命名規則 - なぜ S3 は S が 3 つなのかS3、EC2、Lambda、Aurora など主要サービスの名前の由来を掘り下げ、AWS の命名規則に潜むパターン、命名の失敗例、リブランディングの歴史を雑学的に解説します。AWS Batch で実行する GPU ベースの機械学習トレーニング - コスト効率の高い大規模学習既存の Docker コンテナで GPU トレーニングを実行し、スポットインスタンスとチェックポイントでコストを最大 90% 削減する。SageMaker との使い分けも紹介します。

内容が近い用語・記事

Amazon EBS のボリューム設計と運用 - gp3 ・ io2 の選定基準とスナップショット戦略gp3・io2 のボリュームタイプ選定基準を明確にし、IOPS・スループットの設計指針とスナップショットによるバックアップ戦略を実践的に紹介します。Amazon EBSEC2 インスタンスに接続して使うブロックストレージサービスEBS スナップショットは増分なのに全復元できる仕組み - ブロックレベルの差分管理の裏側EBS スナップショットが増分バックアップでありながら任意のスナップショットから完全なボリュームを復元できる仕組みを、ブロックレベルの差分管理、S3 への保存構造、高速スナップショット復元の内部動作から解説します。Amazon EBS の暗号化とスナップショット共有 - クロスアカウント・クロスリージョンの設計デフォルト暗号化の有効化からスナップショットのクロスアカウント共有、クロスリージョンコピーによる DR 設計までを一貫して紹介します。コンピュートリソース最適化 - AWS Compute Optimizer による適正サイジングAWS Compute Optimizer を使ったリソースの適正サイジングを解説。EC2 ・ Lambda ・ EBS ・ ECS on Fargate の推奨事項、コスト削減効果の試算、導入手順を紹介します。