【AWSサービス 基礎編】Amazon EBS でボリュームを追加・拡張し、スナップショットを取る

目次

概要

EC2 インスタンスを起動すると、OS やアプリケーションが入ったディスクが最初から付いてきます。このディスクの正体が Amazon EBS(Elastic Block Store)です。EBS は EC2 インスタンスにアタッチして使うブロックストレージで、パソコンに外付けのハードディスクをつなぐのと同じ感覚で、ボリュームを追加したり、容量を後から増やしたりできます。

EBS を使いこなすには、用途に応じたボリュームタイプの選び方、ボリュームが 1 つのアベイラビリティーゾーン(AZ)に属すること、インスタンスストアとの違い、暗号化、そしてバックアップの手段であるスナップショットを押さえておく必要があります。いずれも CLF・SAA で繰り返し問われる基本です。

本記事では、EBS の基本を解説したうえで、起動済みの EC2 インスタンスに gp3 ボリュームを作成・アタッチし、OS からフォーマット・マウントして使い、ボリュームのサイズを拡張してファイルシステムを広げ、最後にスナップショットを作成するまでを体験します。

クラウドおさる

EC2 のディスクを後から足したり広げたりできるのでござるか。猿山のバナナ倉庫は一度建てたら広げられぬので、弊猿、手順をしっかり確かめるでござる!

EBS の全体像: EC2 にボリュームをアタッチし、スナップショットで別 AZ・別リージョンへ
EBS の全体像: EC2 にボリュームをアタッチし、スナップショットで別 AZ・別リージョンへ

この記事のメリット

  • EBS が EC2 インスタンスのディスクとしてどのように動いているかを理解できる
  • gp3 / io2 / st1 / sc1 などのボリュームタイプを用途に応じて選び分けられる
  • EBS ボリュームが AZ に縛られることと、インスタンスストアとの違いを説明できる
  • EBS の暗号化と、スナップショット(増分バックアップ・リージョン間コピー)の仕組みを把握できる
  • ボリュームの作成・アタッチ・フォーマット・マウント・サイズ拡張・スナップショット作成を一通り体験できる

執筆者とキャラクター紹介

執筆者:土肥(とひ)

株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

土肥

クラウドおさる

クラウドおさる

はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。

クラウドおさる

基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。

クラウドおさる

猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。

技術解説

EBS は EC2 のディスクの正体

クラウドおさる

とひさん、EC2 を起動したら、最初からディスクが付いていたでござる。あれは何者でござるか?

土肥

それが Amazon EBS のボリュームだよ。EBS は EC2 インスタンスにアタッチして使うブロックストレージで、OS からはローカルのハードディスクと同じように見えるんだ。EC2 のルートボリュームには EBS を使うのが一般的で、AWS も EBS-backed の AMI を使うことをおすすめしているよ。

クラウドおさる

ネットワークの向こうにあるのに、手元のディスクのように使えるのでござるな。インスタンスを止めたら中身は消えるのでござるか?

土肥

消えないよ。EBS ボリュームは EC2 インスタンスの稼働状態とは独立した永続性を持っていて、インスタンスを停止してもデータは残るんだ。さらに、ボリュームのデータは同じ AZ 内の複数のサーバーに自動でレプリケートされるから、1 つのコンポーネントが壊れてもデータが失われないようになっているよ。

クラウドおさる

倉庫の中身を、同じ猿山の中の別の小屋にも写しておいてくれるのでござるな!

土肥

そうそう。ただ「同じ AZ の中で」っていうところは覚えておいてね。あとで大事になるから。

ボリュームタイプの使い分け

クラウドおさる

ボリュームを作るときに「gp3」とか「io2」とか選ぶ欄があったでござる。どう違うのでござるか?

土肥

大きく分けると SSD 系と HDD 系があるよ。主なものをまとめるとこんな感じだね。

ボリュームタイプ種類サイズ最大 IOPS最大スループットブートボリューム主な用途
gp3(汎用 SSD)SSD1 GiB~64 TiB80,0002,000 MiB/秒可ブートボリューム、開発・テスト環境、中規模のデータベース
io2 Block Express(プロビジョンド IOPS SSD)SSD4 GiB~64 TiB256,0004,000 MiB/秒可高い IOPS を持続的に必要とする I/O 集約型のデータベース
st1(スループット最適化 HDD)HDD125 GiB~16 TiB500500 MiB/秒不可ビッグデータ、データウェアハウス、ログ処理
sc1(Cold HDD)HDD125 GiB~16 TiB250250 MiB/秒不可アクセス頻度の低いデータ、とにかく保存コストを下げたい場合
クラウドおさる

種類が多くて迷うでござる……。まずはどれを選べばよいのでござる?

土肥

迷ったら gp3 から考えるといいよ。gp3 はボリュームのサイズに関係なく、ベースラインとして 3,000 IOPS と 125 MiB/秒のスループットが料金に含まれていて、必要なら IOPS とスループットを別々に追加できるんだ。gp3 で足りないくらい高い IOPS を持続的に出したいミッションクリティカルなデータベースなら io2 Block Express。io2 Block Express は耐久性が 99.999% と、ほかのタイプより高いのも特徴だよ。

クラウドおさる

HDD の st1 と sc1 は、どういうときに使うのでござるか?

土肥

大きなファイルを先頭から順番に読み書きするような処理向けだよ。ログ処理やデータウェアハウスみたいに、頻繁にアクセスして高いスループットがほしいなら st1、めったに読まないデータを安く置いておきたいなら sc1 だね。どちらも小さいランダム I/O には向かないし、ブートボリュームにはできないから注意してね。

クラウドおさる

迷ったら gp3、速さが命なら io2、大きなデータを順番に流すなら st1、寝かせておくなら sc1 でござるな。バナナも、毎日食べる分は手元、熟成用は奥の蔵、と置き場所を分けるのと同じでござる!

AZ に縛られることと、インスタンスストアとの違い

クラウドおさる

さっき「同じ AZ の中で」と言っていたのは、どういうことでござるか?

土肥

EBS ボリュームは 1 つの AZ に作られて、同じ AZ にあるインスタンスにしかアタッチできないんだ。たとえば ap-northeast-1a に作ったボリュームは、ap-northeast-1c のインスタンスには付けられないよ。

クラウドおさる

では、別の AZ のインスタンスにデータを持っていきたいときは困るのでござるな……。

土肥

そこで使うのが、あとで出てくるスナップショットだよ。スナップショットから同じリージョン内の好きな AZ に新しいボリュームを作れるんだ。それと、もう 1 つ紛らわしいものにインスタンスストアがあるから、違いを整理しておこうか。

項目Amazon EBSインスタンスストア
実体ネットワーク経由でアタッチするブロックストレージホストコンピュータに物理的にアタッチされたディスク
データの永続性インスタンスの停止・終了とは独立して保持できるインスタンスの停止・休止・終了、ディスク障害などで失われる(再起動では保持)
付け外し同じ AZ の別のインスタンスに付け替えられるそのインスタンス専用
料金プロビジョニングした分の料金がかかるインスタンスの料金に含まれる
主な用途OS、データベース、アプリケーションのデータバッファ、キャッシュ、スクラッチデータなどの一時データ
EBS とインスタンスストアの違い
EBS とインスタンスストアの違い
クラウドおさる

インスタンスストアは、当番猿が手元に置いておく黒板のようなものでござるな。当番が交代したら消してしまう、と。

土肥

いい例えだね! 停止しても残したいデータはインスタンスストアには置かない、と覚えておけば大丈夫だよ。

暗号化

クラウドおさる

ボリュームの中身を盗み見られないようにする方法はあるのでござるか?

土肥

EBS の暗号化を使えばいいよ。暗号化したボリュームでは、保存されているデータだけでなく、インスタンスとボリュームの間でやり取りされるデータ、そのボリュームから作ったスナップショット、さらにそのスナップショットから作ったボリュームまで暗号化されるんだ。鍵は AWS KMS のキーを使っていて、何も指定しなければ AWS マネージドキーの aws/ebs が使われるよ。

クラウドおさる

すでに暗号化せずに作ってしまったボリュームは、後から暗号化できるのでござるか?

土肥

暗号化されていない既存のボリュームを、そのまま直接暗号化することはできないんだ。スナップショットを取って、そこから暗号化したボリュームを新しく作る流れになるよ。最初から漏れなく暗号化したいなら、リージョン単位の「デフォルトで暗号化」の設定を有効にしておくと、そのリージョンで新しく作る EBS ボリュームが自動で暗号化されるんだ。

クラウドおさる

後から鍵を付けるのは手間がかかるので、最初から鍵付きの蔵を建てるのが楽でござるな!

スナップショット(増分バックアップとコピー)

クラウドおさる

スナップショットとは、ボリュームの写真のようなものでござるか?

土肥

そう、ある時点のボリュームの中身を丸ごと保存したバックアップだよ。スナップショットは Amazon S3 に保存されるんだけど、自分の S3 バケットに見えるわけじゃなくて、EC2 のコンソールや API から管理するんだ。

クラウドおさる

毎回まるごと保存していたら、すぐに容量があふれそうでござる……。

土肥

そこがよくできているところで、スナップショットは増分バックアップなんだ。2 回目以降は、前回のスナップショットから変更されたブロックだけが保存されるから、作成時間もストレージ料金も抑えられるよ。

クラウドおさる

増分だと、古いスナップショットを消したら新しいほうが壊れたりしないのでござるか?

土肥

大丈夫。スナップショットを削除すると、そのスナップショットだけが参照しているデータが消えて、ほかのスナップショットが参照しているデータは残るようになっているよ。だから逆に「古いものを 1 つ消したのに、料金があまり減らない」ってことも起こるんだ。

クラウドおさる

スナップショットからは、どこにでもボリュームを戻せるのでござるか?

土肥

スナップショットのデータはリージョン内の全 AZ に自動でレプリケートされるから、同じリージョンならどの AZ にでもボリュームを復元できるよ。さっきの「AZ をまたいでデータを持っていきたい」はこれで解決だね。さらに、スナップショットは別のリージョンにコピーすることもできて、災害対策や別リージョンへの移行に使えるんだ。コピーのときに、暗号化されていないスナップショットを暗号化したり、別の KMS キーで暗号化し直したりもできるよ。

やりたいこと方法
別の AZ にボリュームを移すスナップショットを取り、移したい AZ を指定してボリュームを作成する
別のリージョンにバックアップを置くスナップショットを別リージョンへコピーする
暗号化されていないボリュームを暗号化するスナップショットを取り、暗号化を有効にしてボリュームを作成する(またはスナップショットを暗号化してコピーする)
スナップショットは増分で S3 に保存され、別 AZ への復元や別リージョンへのコピーに使える
スナップショットは増分で S3 に保存され、別 AZ への復元や別リージョンへのコピーに使える
クラウドおさる

毎日スナップショットを取るのは、手作業だと忘れそうでござる。

土肥

定期的な取得と古いスナップショットの削除は、Amazon Data Lifecycle Manager で自動化できるよ。EBS 以外もまとめてバックアップを管理したいなら AWS Backup だね。今回は仕組みを理解するために、手動で 1 つ作ってみよう。

ボリュームの変更と料金の考え方

クラウドおさる

容量が足りなくなったら、インスタンスを止めて付け替えるのでござるか?

土肥

止めなくていいんだ。Elastic Volumes という機能で、アタッチしたまま使い続けながらサイズやボリュームタイプ、IOPS などを変更できるよ。ただし注意点が 3 つあるんだ。

  • サイズは増やすことしかできない(小さくしたい場合は、小さいボリュームを作ってデータを移す)
  • ボリュームを広げても、OS 側のファイルシステムは自動では広がらない。変更が optimizing 状態になったら、OS でファイルシステムを拡張する
  • 同じボリュームへの変更は、前の変更が completed になってから。変更できるのはローリング 24 時間で最大 4 回まで
クラウドおさる

「とりあえず大きく作って後で小さくする」はできないのでござるな。料金はどう決まるのでござる?

土肥

EBS はプロビジョニングした分、つまり作ったボリュームのサイズに対して料金がかかるんだ。中身が空でも 20GiB で作れば 20GiB 分だね。それから、インスタンスからデタッチしたボリュームも、削除するまで料金がかかり続けるよ。スナップショットも削除するまで保存料金がかかるから、使い終わったものは消すのが基本だね。

クラウドおさる

小さく作って足りなくなったら広げる、使わなくなったら消す。バナナを無駄にしない作法でござるな!

新卒・未経験の方へ
クラウドおさる

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

  • ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
  • ✓未経験から入社した社員の声を含む社員アンケートを掲載
  • ✓応募フォームから 1 分で応募できます

実践

ハンズオンガイド9 ステップ画面 7 枚

コンソールの横に開いて、チェックしながら進めましょう。

ガイドを開く

別タブで開きます。チェックはこのブラウザに保存されます。

起動済みの EC2 インスタンスに gp3 ボリュームを追加し、OS からフォーマット・マウントしてファイルを書き込みます。続いてボリュームのサイズを拡張してファイルシステムを広げ、最後にスナップショットを作成します。

前提条件

  • リージョン: ap-northeast-1(東京)
  • AWS マネジメントコンソールにログイン済みであること
  • 以下のリソースが作成済みであること
リソース種別リソース名内容
VPCebs-vpc10.0.0.0/16
サブネットebs-public-subnet10.0.1.0/24(ap-northeast-1a、インターネットゲートウェイ経由で外部に出られる)
EC2 インスタンスebs-serverAmazon Linux 2023 / t3.micro / ap-northeast-1a。AmazonSSMManagedInstanceCore を含む IAM インスタンスプロファイルが付与されており、Session Manager で接続できる

作成するリソース一覧

リソース種別リソース名用途
EBS ボリュームebs-data-volumeebs-server に追加するデータ用ボリューム(gp3 / 10GiB で作成し、20GiB に拡張)
EBS スナップショットebs-data-snapshotebs-data-volume のバックアップ

ステップ1: インスタンスの AZ を確認する

EBS ボリュームはインスタンスと同じ AZ に作る必要があるため、先に ebs-server の AZ を確認します。

  • AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1(東京)であることを確認します
  • 上部の検索バーに EC2 と入力し、表示された「EC2」を選択します
  • 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します
  • ebs-server を選択し、下部の「ネットワーキング」タブで「アベイラビリティーゾーン」が ap-northeast-1a であることを確認します
  • 下部の「ストレージ」タブで、ルートデバイスとして EBS ボリュームが 1 つアタッチされていることも確認しておきます

ステップ2: gp3 ボリュームを作成する

  • 左側ナビゲーションの「Elastic Block Store」→「ボリューム」を選択します
  • 右上の「ボリュームの作成」をクリックします
  • 「ボリューム設定」で以下を入力します
  • ボリュームタイプ: 汎用 SSD (gp3)
  • サイズ (GiB): 10
  • IOPS: 3000(デフォルト)
  • スループット (MiB/秒): 125(デフォルト)
  • アベイラビリティーゾーン: apne1-az4 (ap-northeast-1a)(ステップ1で確認した AZ)
  • スナップショット ID: スナップショットから作成しない(デフォルト)
  • 暗号化: 「このボリュームを暗号化する」にチェックを入れ、KMS キーは (デフォルト) aws/ebs を選択します(リージョンで「デフォルトで暗号化」が有効な場合は、最初からチェックが入っています)
  • 「タグ – オプション」で「新しいタグを追加」をクリックし、キー Name、値 ebs-data-volume を入力します
  • その他の項目はデフォルトのままにします
ボリュームの作成画面(gp3 / 10GiB / ap-northeast-1a / 暗号化 / Name タグの入力内容)
ボリュームの作成画面(gp3 / 10GiB / ap-northeast-1a / 暗号化 / Name タグの入力内容)
  • 右下の「ボリュームの作成」をクリックします
  • ボリューム一覧で ebs-data-volume の「ボリュームの状態」が「使用可能」になるまで待ちます

ステップ3: ボリュームをインスタンスにアタッチする

  • ボリューム一覧で ebs-data-volume を選択し、右上の「アクション」→「ボリュームのアタッチ」をクリックします
  • 「インスタンス」で ebs-server を選択します(同じ AZ のインスタンスだけが候補に表示されます)
  • 「デバイス名」で /dev/sdf を選択します
  • 「ボリュームのアタッチ」をクリックします
  • ボリューム一覧で ebs-data-volume の「ボリュームの状態」が「使用中」になり、「アタッチされたリソース」に ebs-server のインスタンス ID が表示されることを確認します
ボリューム一覧で ebs-data-volume が「使用中」になり、ebs-server にアタッチされている状態
ボリューム一覧で ebs-data-volume が「使用中」になり、ebs-server にアタッチされている状態

ステップ4: Session Manager で接続し、フォーマット・マウントする

アタッチしただけのボリュームは、まだファイルシステムがない「生のディスク」です。OS からフォーマットしてマウントします。

  • 左側ナビゲーションの「インスタンス」→「インスタンス」を選択し、ebs-server を選択して右上の「接続」をクリックします
  • 「セッションマネージャー」タブを選択し、「接続」をクリックします
  • ブラウザ上にターミナルが開いたら、ブロックデバイスの一覧を確認します
lsblk

t3.micro のような Nitro ベースのインスタンスでは、EBS ボリュームが NVMe デバイスとして見えます。そのため、コンソールで指定した /dev/sdf ではなく nvme1n1 のような名前で表示されます。サイズが 10G でパーティションもマウントポイントもないデバイスが、追加した ebs-data-volume です。以下は表示例です(ルートボリュームのパーティション構成は AMI によって異なります)。

NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0   8G  0 disk
├─nvme0n1p1   259:1    0   8G  0 part /
├─nvme0n1p127 259:2    0   1M  0 part
└─nvme0n1p128 259:3    0  10M  0 part /boot/efi
nvme1n1       259:4    0  10G  0 disk

以降のコマンドの /dev/nvme1n1 は、lsblk で確認したデバイス名に置き換えてください。まず、ファイルシステムがまだないことを確認します。

sudo file -s /dev/nvme1n1

/dev/nvme1n1: data と表示されれば、ファイルシステムがない空のボリュームです。XFS でフォーマットします。

sudo mkfs -t xfs /dev/nvme1n1

マウントポイントを作成してマウントし、ファイルを書き込みます。

sudo mkdir /data
sudo mount /dev/nvme1n1 /data
echo "hello ebs" | sudo tee /data/hello.txt
df -hT /data

/data の行に、タイプ xfs、サイズ約 10G のファイルシステムが表示されれば、マウントは成功です。

Session Manager のターミナルで lsblk の結果と、df -hT で /data に約 10G の xfs がマウントされている画面
Session Manager のターミナルで lsblk の結果と、df -hT で /data に約 10G の xfs がマウントされている画面

ここでは一時的なマウントです。インスタンスの再起動後も自動でマウントしたい場合は、sudo blkid で確認した UUID を使って /etc/fstab に UUID=<UUID> /data xfs defaults,nofail 0 2 の形で追記します。nofail を付けておくと、ボリュームがアタッチされていない状態でもインスタンスが起動できます。

ステップ5: ボリュームのサイズを 20GiB に拡張する

ebs-data-volume をアタッチしたまま、サイズを 10GiB から 20GiB に増やします。

  • Session Manager のタブはそのままにして、EC2 コンソールのタブに戻ります
  • 左側ナビゲーションの「Elastic Block Store」→「ボリューム」を選択します
  • ebs-data-volume を選択し、右上の「アクション」→「ボリュームの変更」をクリックします
  • 「サイズ (GiB)」を 20 に変更します。ボリュームタイプ・IOPS・スループットはそのままにします
ボリュームの変更画面(サイズを 20GiB に変更した状態)
ボリュームの変更画面(サイズを 20GiB に変更した状態)
  • 右下の「変更」をクリックします。確認のダイアログが表示された場合は、内容を確認して「変更」をクリックします
  • ボリューム一覧で ebs-data-volume を選択し、「ボリュームの状態」に optimizing が表示されるまで待ちます(サイズの増加は、変更が optimizing 状態になった時点で有効になります)

ステップ6: ファイルシステムを拡張する

ボリュームを広げただけでは、OS 側のファイルシステムは 10GiB のままです。Session Manager のターミナルに戻り、確認します。

lsblk /dev/nvme1n1
df -hT /data

lsblk ではデバイスのサイズが 20G になっている一方、df ではファイルシステムのサイズが約 10G のままであることが確認できます。今回のボリュームはパーティションを作らずに丸ごと XFS でフォーマットしたので、パーティションの拡張(growpart)は不要です。XFS のファイルシステムを拡張します。

sudo xfs_growfs -d /data
df -hT /data
cat /data/hello.txt

df の /data のサイズが約 20G に増え、hello.txt の中身 hello ebs もそのまま読めることが確認できます。インスタンスを止めず、データも消さずに容量を増やせました。

Session Manager のターミナルで、xfs_growfs の前後で /data のサイズが約 10G から約 20G に増えている画面
Session Manager のターミナルで、xfs_growfs の前後で /data のサイズが約 10G から約 20G に増えている画面
クラウドおさる

コンソールで広げるのは「蔵の拡張」、xfs_growfs は「中の棚を広げる」作業でござる。両方やってはじめてバナナを多く置けるのでござるな。

ステップ7: スナップショットを作成する

ebs-data-volume のスナップショットを作成します。スナップショットにはリクエストした時点でボリュームに書き込まれているデータが含まれるので、書き込み中の処理がない状態で取るのが推奨されています。今回は書き込みをしていないため、このまま進めます。

  • EC2 コンソールの左側ナビゲーションの「Elastic Block Store」→「スナップショット」を選択します
  • 右上の「スナップショットの作成」をクリックします
  • 以下を設定します
  • リソースタイプ: ボリューム
  • ボリューム ID: ebs-data-volume のボリューム ID を選択
  • 説明: ebs-data-volume backup
  • 「タグ」で「新しいタグを追加」をクリックし、キー Name、値 ebs-data-snapshot を入力します
  • 「暗号化」の欄に元のボリュームの設定(「暗号化済み」)が表示され、変更できないことを確認します
スナップショットの作成画面(リソースタイプ「ボリューム」、ボリューム ID、説明、Name タグの入力内容)
スナップショットの作成画面(リソースタイプ「ボリューム」、ボリューム ID、説明、Name タグの入力内容)
  • 右下の「スナップショットを作成」をクリックします
  • スナップショット一覧で ebs-data-snapshot の「スナップショットのステータス」が「保留中」から「完了済み」になるまで待ちます。作成中もボリュームはそのまま使い続けられます
  • 「完了済み」になったら、ebs-data-snapshot を選択し、下部の「詳細」タブでボリュームサイズが 20 GiB、暗号化が「暗号化済み」になっていることを確認します
スナップショット一覧で ebs-data-snapshot のステータスが「完了済み」になり、詳細タブにボリュームサイズと暗号化状態が表示されている状態
スナップショット一覧で ebs-data-snapshot のステータスが「完了済み」になり、詳細タブにボリュームサイズと暗号化状態が表示されている状態

このスナップショットから、ap-northeast-1 内の別の AZ にボリュームを作成したり、「アクション」→「スナップショットをコピー」で別のリージョンにコピーしたりできます。

クラウドおさる

デタッチしたボリュームも、元のボリュームを消した後のスナップショットも、削除するまで料金がかかり続けるのでござる。試し終わったら、ボリュームとスナップショットの両方が残っていないか確かめるでござるぞ。

まとめ

  • Amazon EBS は EC2 インスタンスにアタッチして使うブロックストレージで、インスタンスの停止とは独立してデータを保持できる
  • ボリュームタイプは、迷ったら gp3、高い IOPS を持続的に必要とするなら io2 Block Express、大きなシーケンシャル処理なら st1、アクセス頻度の低いデータを安く置くなら sc1 を選ぶ。HDD 系はブートボリュームにできない
  • EBS ボリュームは 1 つの AZ に属し、同じ AZ のインスタンスにしかアタッチできない。インスタンスストアはホストに付いた一時ストレージで、停止・終了でデータが失われる
  • 暗号化したボリュームでは、保存データ・インスタンスとの間の通信・スナップショットまで暗号化される。既存の暗号化されていないボリュームは、スナップショット経由で暗号化する
  • スナップショットは S3 に保存される増分バックアップで、リージョン内の任意の AZ への復元や、別リージョンへのコピーができる。定期取得は Data Lifecycle Manager や AWS Backup で自動化する
  • Elastic Volumes でアタッチしたままサイズを増やせるが、小さくはできない。拡張後は OS 側でファイルシステムを広げる必要がある
  • EBS はプロビジョニングしたサイズに課金され、デタッチしたボリュームやスナップショットも削除するまで料金がかかる

関連記事:

参照先

キャリア相談
クラウドおさる

独学の先に、AWS の仕事がある ── ジュニアおさるのキャリア相談

CLF には受かったけれど、次に何をすればいいのか分からない。独学で AWS を学ぶジュニアおさるの相談に、株式会社ジェニュイン代表の土肥が答えています。

  • ✓資格はゴールか、CLF の次に何から手を付けるか
  • ✓EC2 の次に作ってみる構成と、IaC・コスト管理
  • ✓実務経験ゼロでも、面接で話せる「これまで」の作り方
新卒・未経験の方へ
クラウドおさる

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

  • ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
  • ✓未経験から入社した社員の声を含む社員アンケートを掲載
  • ✓応募フォームから 1 分で応募できます

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

株式会社ジェニュイン(https://genuine-pt.jp)の代表取締役.

2018年〜インフラエンジニアとしてキャリアをスタートし、オンプレミスのネットワーク・サーバ環境で3年半、クラウド環境で4年半の8年間エンジニアとして従事。
2021年に佐藤氏の創業した株式会社Luxyを引き継ぎ、代表に就任。
その後アガルートグループ内の株式会社ジェニュインと合併。
合併後同社代表に就任。

目次