🚀
AWS学びなおし(+TF)_EBS

2025/02/25に公開
EBS (Elastic Block Storage) とは？
AWSのEC2インスタンスで使用できる仮想的なブロックストレージサービスです。物理的なサーバーにおけるハードディスクドライブ（HDD）やSSDに相当すると考えてください。EC2インスタンスは、このEBSボリュームをネットワーク経由でアタッチし、OSやアプリケーションのデータ保存領域として利用します。
EBSの主な特徴

永続ストレージ: EC2インスタンスが停止または削除されても、EBSボリューム内のデータは永続的に保持されます。インスタンスストアとは異なり、データの揮発性を心配する必要はありません。

柔軟なサイズ変更: 必要に応じてEBSボリュームのサイズを後から変更できます。ストレージ容量が不足した場合でも、ダウンタイムなしで拡張可能です。

多様なボリュームタイプ: 用途やパフォーマンス要件に応じて、複数のボリュームタイプから選択できます。（後述）

スナップショット機能: EBSボリュームの特定時点の状態をスナップショットとして保存できます。データのバックアップや災害対策、新しいボリュームの作成に利用できます。

暗号化: 保存データと転送中のデータを暗号化できます。セキュリティ要件の高いシステムでも安心して利用できます。

可用性と耐久性: 高い可用性と耐久性を備えており、データの損失リスクを低減できます。

アタッチ/デタッチ: 複数のEC2インスタンス間でEBSボリュームをアタッチ/デタッチできます。（ただし、同時に複数のインスタンスにアタッチできるボリュームタイプは限定的です。）
EBSボリュームの種類
EBSには、パフォーマンス特性や料金体系が異なる複数のボリュームタイプがあります。主なボリュームタイプは以下の通りです。


ボリュームタイプ
特徴
ユースケース


SSD (Solid State Drive) ボリューム



gp3 (汎用 SSD)
バランスの取れた価格とパフォーマンス。IOPSとスループットを個別にプロビジョニング可能。
幅広いワークロード、ブートボリューム、中小規模のデータベース、開発/テスト環境

gp2 (汎用 SSD)
gp3の前世代。コストパフォーマンスに優れるが、gp3に比べるとパフォーマンスの柔軟性は低い。
幅広いワークロード、ブートボリューム、中小規模のデータベース、開発/テスト環境 (新規ワークロードにはgp3が推奨)

io2 Block Express (プロビジョンドIOPS SSD)
高パフォーマンス、低レイテンシ。高IOPSと高スループットが必要なミッションクリティカルなワークロード向け。最も高価。
大規模データベース (SAP HANA, Oracle, SQL Server)、トランザクション処理が集中するアプリケーション

io2 (プロビジョンドIOPS SSD)
io2 Block Expressの前世代。io2 Block Expressよりもパフォーマンス上限が低い。
高IOPSと低レイテンシが必要なデータベース、大規模なNoSQLデータベース

io1 (プロビジョンドIOPS SSD)
さらに古い世代のプロビジョンドIOPS SSD。io2/io2 Block Expressに比べてパフォーマンスと機能が劣るため、新規ワークロードには推奨されない。
特定のレガシーアプリケーション、io2/io2 Block Expressへの移行が困難なケース

HDD (Hard Disk Drive) ボリューム



st1 (スループット最適化HDD)
低コスト、高スループット。シーケンシャルアクセスが中心のワークロード向け。
ビッグデータ、データウェアハウス、ログ処理、ストリーミングメディア

sc1 (コールドHDD)
最も低コスト。アクセス頻度の低いデータ向け。
バックアップ、アーカイブ、アクセス頻度の低いデータストレージ

EBSの料金体系
EBSの料金は、主に以下の要素で構成されます。

ボリュームストレージ: プロビジョニングされたストレージ容量 (GB/月)

プロビジョンドIOPS (io1, io2, io2 Block Express): プロビジョニングされたIOPS (IOPS/月)

スループット (gp3): プロビジョニングされたスループット (MiB/秒/月)

スナップショットストレージ: スナップショットの保存容量 (GB/月)

データ転送: リージョンを跨ぐデータ転送
料金はボリュームタイプやリージョンによって異なります。詳細はAWSの料金ページをご確認ください。
EBSの主要な機能

ボリューム作成: EC2コンソール、CLI、SDK、Terraformなどから作成できます。

アタッチ/デタッチ: EC2インスタンスにアタッチ/デタッチできます。

サイズ変更: ボリュームサイズを拡張できます。

ボリュームタイプ変更: ボリュームタイプを必要に応じて変更できます。（制約事項あり）

スナップショット作成/復元: スナップショットを作成し、スナップショットから新しいボリュームを作成できます。

暗号化設定: ボリューム作成時または既存ボリュームを暗号化できます。

タグ付け: ボリュームにタグを付与して管理できます。

モニタリング: CloudWatchメトリクスでパフォーマンスを監視できます。

 【実務レベルの内容と重要事項】実務におけるEBSの重要事項
適切なボリュームタイプの選択: ワークロードの要件（パフォーマンス、コスト）に合わせて最適なボリュームタイプを選択することが重要です。誤った選択はパフォーマンス低下やコスト増につながります。

パフォーマンス要件: IOPS、スループット、レイテンシを考慮し、必要なパフォーマンスを満たすボリュームタイプを選びます。

コスト: 費用対効果を考慮し、過剰なスペックのボリュームタイプを選ばないようにします。

ワークロードの変化: ワークロードの変化に合わせてボリュームタイプを柔軟に変更できることを考慮します。（gp3はIOPS/スループットを柔軟に変更可能）
パフォーマンス設計: EBSボリュームのパフォーマンスは、EC2インスタンスタイプ、ネットワーク帯域幅、アプリケーションのI/Oパターンなど、様々な要因に影響されます。

EC2インスタンスタイプ: EBS最適化インスタンスを使用することで、EBSボリュームへのネットワーク帯域幅を最大限に活用できます。

I/Oパターン: ランダムI/Oが多いワークロードにはSSDボリューム、シーケンシャルI/Oが多いワークロードにはHDDボリュームが適しています。

RAID構成: 複数のEBSボリュームをRAID構成にすることで、IOPSやスループットを向上させることができます。（ただし、RAID構成の複雑性や管理コストも考慮が必要です。）

ファイルシステム: ファイルシステムの選択や設定もパフォーマンスに影響を与えます。（例: XFS, ext4, ファイルシステムのマウントオプション）
可用性と耐久性: EBSは高い可用性と耐久性を備えていますが、障害が発生する可能性はゼロではありません。

スナップショット: 定期的にスナップショットを取得し、データのバックアップとリストア体制を確立することが重要です。

複数AZ構成: EC2インスタンスとEBSボリュームを複数のアベイラビリティゾーン (AZ) に分散配置することで、AZ障害に対する可用性を高めることができます。

EBSミラーリング (RAID1): RAID1構成でEBSボリュームをミラーリングすることで、ボリューム障害時のデータ損失を防ぐことができます。（ただし、コストが増加します。）
バックアップとリストア: データの保護と事業継続計画 (BCP) のために、EBSボリュームのバックアップとリストア戦略は非常に重要です。

EBSスナップショット: 最も一般的なバックアップ方法です。スケジュールを設定して自動的にスナップショットを取得できます。

AWS Backup: 複数AWSサービス (EBS, EC2, RDSなど) のバックアップを一元管理できるサービスです。

リストアテスト: 定期的にリストアテストを実施し、バックアップが正常に機能することを確認することが重要です。
セキュリティ: EBSボリュームのセキュリティ対策も重要です。

暗号化: EBSボリュームを暗号化することで、保存データと転送中のデータを保護できます。

IAMポリシー: IAMポリシーでEBSボリュームへのアクセス制御を行い、不正アクセスを防止します。

セキュリティグループ: EC2インスタンスのセキュリティグループでEBSボリュームへのアクセスを制限できます。（EBS自体にはセキュリティグループの機能はありません。）
コスト最適化: EBSのコストはストレージ容量に比例するため、コスト最適化も重要な課題です。

適切なサイズ設定: 必要なストレージ容量を見積もり、過剰な容量をプロビジョニングしないようにします。

不要なスナップショットの削除: 古いスナップショットや不要なスナップショットを定期的に削除し、ストレージコストを削減します。

ボリュームタイプの見直し: ワークロードの変化に合わせてボリュームタイプを見直し、よりコスト効率の高いボリュームタイプへの変更を検討します。（例: gp2からgp3へ、st1/sc1の活用）

EBS最適化EC2インスタンス: EBS最適化インスタンスを使用することで、ネットワーク帯域幅を効率的に利用し、結果的にコスト削減につながる場合があります。
モニタリング: CloudWatchメトリクスを監視し、EBSボリュームのパフォーマンスや使用状況を把握することが重要です。

VolumeReadOps/VolumeWriteOps: 読み書きIOPS

VolumeReadBytes/VolumeWriteBytes: 読み書きスループット

VolumeQueueLength: I/Oキューの長さ（パフォーマンスボトルネックの兆候）

VolumeIdleTime: ボリュームのアイドル時間（リソース利用率の指標）

DiskQueueDepth: OSレベルでのディスクキューの深さ (より詳細なボトルネック分析に有用)
実務での注意点

AZロックイン: EBSボリュームは特定のアベイラビリティゾーン (AZ) に紐づきます。異なるAZのEC2インスタンスからは直接アタッチできません。AZを跨いでボリュームを共有する場合は、スナップショットからのリストアやレプリケーションなどの追加手順が必要です。

ボリュームのタイプ変更: ボリュームタイプを変更する際には、ダウンタイムが発生する可能性があります。（最新世代のボリュームタイプへの変更では、オンラインでのタイプ変更が可能な場合もあります。）

スナップショットの整合性: アプリケーションによっては、スナップショット取得時にデータ整合性を確保するために、ファイルシステムのフリーズやアプリケーションの一時停止などの対策が必要になる場合があります。

削除保護: 重要なEBSボリュームには削除保護を有効化し、誤って削除されることを防ぎます。

タグ付け: 全てのEBSボリュームに適切なタグを付与し、コスト管理、リソース管理、自動化処理を容易にします。

 【実務でどの程度使用されるのか】EBSは、AWS環境において非常に頻繁に使用されるストレージサービスです。ほぼ全てのEC2インスタンスで、OSやアプリケーションのデータ保存領域としてEBSボリュームが利用されています。
実務での利用頻度が高い理由

EC2の基盤ストレージ: EC2インスタンスの標準的なストレージオプションであり、特別な理由がない限りEBSが選択されます。

永続ストレージの必要性: 多くのアプリケーションは、インスタンスの停止や再起動後もデータを保持する必要があるため、永続ストレージであるEBSが不可欠です。

柔軟性と拡張性: ボリュームサイズの変更やボリュームタイプの変更が容易であり、ワークロードの変化に柔軟に対応できます。

スナップショットによるバックアップ: 容易にスナップショットを取得できるため、バックアップとリストアの仕組みを構築しやすいです。

多様なユースケース: Webアプリケーション、データベース、ファイルサーバー、ビッグデータ処理、開発/テスト環境など、幅広いワークロードに対応できます。
他のストレージサービスとの比較

S3 (Simple Storage Service): オブジェクトストレージ。大量の非構造化データを低コストで保存するのに適しています。EC2インスタンスのOSやアプリケーションデータ保存には通常EBSが使用されます。S3はバックアップ、アーカイブ、静的コンテンツ配信などに利用されます。

Instance Store: EC2インスタンスに物理的に接続された一時的なストレージ。高速ですが、インスタンスの停止/削除時にデータが失われます。一時的なキャッシュやバッファなど、データ永続性が不要な場合に限定的に使用されます。

EFS (Elastic File System): ネットワークファイルシステム。複数のEC2インスタンスから同時にファイルシステムを共有できます。Webサーバーのコンテンツ共有や、複数インスタンスからアクセスするファイルサーバーなどに利用されます。EBSは単一のEC2インスタンスにアタッチして使用するのが一般的です。

FSx (File System): マネージドなファイルシステムサービス。Windows File ServerやLustreなど、特定のファイルシステムをマネージドサービスとして利用できます。EBSは汎用的なブロックストレージであり、ファイルシステムの種類に依存しません。
実務でのEBSの具体的な利用例

Webアプリケーションサーバー: OS、アプリケーションコード、Webコンテンツ、ログファイルなどをEBSボリュームに保存します。

データベースサーバー: データベースファイル、トランザクションログ、バックアップデータなどをEBSボリュームに保存します。

ファイルサーバー: ユーザーファイル、ドキュメント、メディアファイルなどをEBSボリュームに保存します。（EFSやFSxの方が適している場合もあります。）

CI/CD環境: ビルド成果物、テストデータ、デプロイパッケージなどをEBSボリュームに保存します。

開発/テスト環境: 開発用コード、テストデータ、一時的なデータなどをEBSボリュームに保存します。

ビッグデータ処理: 一時的なデータセット、中間データ、処理結果などをEBSボリュームに保存します。（S3やInstance Storeと組み合わせて使用することもあります。）
このように、EBSはAWS環境における基本的なストレージコンポーネントとして、様々な場面で不可欠な存在となっています。クラウドエンジニアとして、EBSの知識と運用スキルは必須と言えるでしょう。

 【terraformのコードで記述する場合の基本的内容と実務レベルの内容】Terraformコードの基本 (EBSボリューム作成)
TerraformでEBSボリュームを作成する基本的なコードは以下のようになります。
resource "aws_ebs_volume" "example" {
  availability_zone = "ap-northeast-1a" # アベイラビリティゾーン
  size              = 10                # ボリュームサイズ (GB)
  type              = "gp3"             # ボリュームタイプ (汎用SSD gp3)
  tags = {
    Name        = "example-ebs-volume"
    Environment = "dev"
  }
}
コード解説

resource "aws_ebs_volume" "example": aws_ebs_volumeリソースを定義し、exampleという名前を付けています。（リソース名は任意）

availability_zone: EBSボリュームを作成するアベイラビリティゾーンを指定します。EC2インスタンスと同じAZに作成する必要があります。

size: EBSボリュームのサイズをGB単位で指定します。

type: EBSボリュームのタイプを指定します。gp2, gp3, io1, io2, st1, sc1 などが選択可能です。

tags: EBSボリュームにタグを付与します。リソースの識別や管理に役立ちます。
Terraformコードの実務レベルの内容
実務レベルでは、上記の基本コードに加えて、以下の要素を考慮する必要があります。
1. 変数 (Variables) の利用
ハードコードされた値を変数に置き換えることで、コードの再利用性と柔軟性を高めます。
variable "aws_region" {
  default = "ap-northeast-1"
}

variable "availability_zone" {
  default = "ap-northeast-1a"
}

variable "ebs_volume_size" {
  default = 20
}

variable "ebs_volume_type" {
  default = "gp3"
}

resource "aws_ebs_volume" "example" {
  availability_zone = var.availability_zone
  size              = var.ebs_volume_size
  type              = var.ebs_volume_type
  tags = {
    Name        = "example-ebs-volume"
    Environment = "dev"
    Region      = var.aws_region
  }
}
2. データソース (Data Sources) の利用
既存のリソースの情報 (例: AMI ID, VPC ID, サブネット ID) をデータソースから取得することで、コードの可読性と保守性を高めます。
data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_instance" "example" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = "t3.micro"
  availability_zone = var.availability_zone

  root_block_device {
    volume_type = var.ebs_volume_type
    volume_size = var.ebs_volume_size
    tags = {
      Name = "example-root-volume"
    }
  }

  tags = {
    Name        = "example-ec2-instance"
    Environment = "dev"
    Region      = var.aws_region
  }
}
3. モジュール (Modules) の利用
EBSボリューム作成ロジックをモジュール化することで、コードの再利用性と整理性を高めます。
# modules/ebs_volume/main.tf
variable "availability_zone" {
  type = string
}

variable "size" {
  type    = number
  default = 10
}

variable "type" {
  type    = string
  default = "gp3"
}

variable "tags" {
  type    = map(string)
  default = {}
}

resource "aws_ebs_volume" "main" {
  availability_zone = var.availability_zone
  size              = var.size
  type              = var.type
  tags              = var.tags
}
# main.tf (モジュールの呼び出し)
module "example_ebs_volume" {
  source = "./modules/ebs_volume"

  availability_zone = var.availability_zone
  size              = var.ebs_volume_size
  type              = var.ebs_volume_type

  tags = {
    Name        = "example-ebs-volume-module"
    Environment = "dev"
    Region      = var.aws_region
  }
}
4. 高度な設定オプション
実務では、以下のような高度な設定オプションも必要になる場合があります。

iops (io1, io2, io2 Block Express): プロビジョンドIOPS SSDボリュームの場合、IOPS値を指定します。

throughput (gp3): gp3ボリュームの場合、スループット値を指定します。

snapshot_id: スナップショットからボリュームを復元する場合にスナップショットIDを指定します。

encrypted: ボリュームを暗号化するかどうかを指定します。

kms_key_id: 暗号化に使用するKMSキーを指定します。（デフォルトはAWS管理キー）

deletion_policy: ボリューム削除時の動作を指定します。（delete or snapshot）

tags_all: tagsに加えて、AWSによって自動的に付与されるタグも管理する場合に使用します。
5. ルートボリュームとアタッチされたボリューム
EC2インスタンスのルートボリューム (OSがインストールされるボリューム) と、追加でアタッチするボリュームは、Terraformコードで個別に定義できます。

ルートボリューム: aws_instanceリソースの root_block_device ブロック内で定義します。

アタッチされたボリューム: aws_ebs_volumeリソースと aws_volume_attachment リソースを組み合わせて定義します。
resource "aws_ebs_volume" "data_volume" {
  availability_zone = var.availability_zone
  size              = 100
  type              = "gp3"
  tags = {
    Name = "data-volume"
  }
}

resource "aws_volume_attachment" "data_volume_attachment" {
  device_name  = "/dev/sdh" # EC2インスタンス内でのデバイス名
  instance_id  = aws_instance.example.id
  volume_id    = aws_ebs_volume.data_volume.id
  force_detach = true # インスタンス停止時に強制デタッチ
}
6. イミュータブルインフラストラクチャとの連携
イミュータブルインフラストラクチャ (Immutable Infrastructure) を実現するために、EBSボリュームをAMIに焼き込み、AMIからEC2インスタンスを起動するパターンも実務でよく利用されます。この場合、TerraformコードではAMI作成処理とEC2インスタンス起動処理を組み合わせることになります。
7. IaC (Infrastructure as Code) のベストプラクティス

DRY (Don't Repeat Yourself): コードの重複を避け、モジュールや変数などを活用して再利用性を高めます。

バージョン管理: TerraformコードをGitなどのバージョン管理システムで管理し、変更履歴を追跡できるようにします。

テスト: Terraformコードの変更を適用する前に、terraform plan コマンドで変更内容を確認し、必要に応じてテスト環境で検証します。

ステート管理: Terraformステートファイルを適切に管理し、チームで共有する場合はリモートステート (S3, Terraform Cloudなど) を利用します。

セキュリティ: APIキーやクレデンシャルなどの機密情報をコードにハードコードせず、環境変数やシークレット管理ツール (HashiCorp Vault, AWS Secrets Managerなど) を利用します。
これらの実務レベルの内容を考慮することで、より堅牢で保守性の高いTerraformコードを記述し、EBSボリュームを効率的に管理することができます。
ボリュームタイプ	特徴	ユースケース
SSD (Solid State Drive) ボリューム
gp3 (汎用 SSD)	バランスの取れた価格とパフォーマンス。IOPSとスループットを個別にプロビジョニング可能。	幅広いワークロード、ブートボリューム、中小規模のデータベース、開発/テスト環境
gp2 (汎用 SSD)	gp3の前世代。コストパフォーマンスに優れるが、gp3に比べるとパフォーマンスの柔軟性は低い。	幅広いワークロード、ブートボリューム、中小規模のデータベース、開発/テスト環境 (新規ワークロードにはgp3が推奨)
io2 Block Express (プロビジョンドIOPS SSD)	高パフォーマンス、低レイテンシ。高IOPSと高スループットが必要なミッションクリティカルなワークロード向け。最も高価。	大規模データベース (SAP HANA, Oracle, SQL Server)、トランザクション処理が集中するアプリケーション
io2 (プロビジョンドIOPS SSD)	io2 Block Expressの前世代。io2 Block Expressよりもパフォーマンス上限が低い。	高IOPSと低レイテンシが必要なデータベース、大規模なNoSQLデータベース
io1 (プロビジョンドIOPS SSD)	さらに古い世代のプロビジョンドIOPS SSD。io2/io2 Block Expressに比べてパフォーマンスと機能が劣るため、新規ワークロードには推奨されない。	特定のレガシーアプリケーション、io2/io2 Block Expressへの移行が困難なケース
HDD (Hard Disk Drive) ボリューム
st1 (スループット最適化HDD)	低コスト、高スループット。シーケンシャルアクセスが中心のワークロード向け。	ビッグデータ、データウェアハウス、ログ処理、ストリーミングメディア
sc1 (コールドHDD)	最も低コスト。アクセス頻度の低いデータ向け。	バックアップ、アーカイブ、アクセス頻度の低いデータストレージ
【実務レベルの内容と重要事項】

【実務でどの程度使用されるのか】

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

Discussion
