AWS でいままで起きた大規模障害を振り返る

目的

 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ東京リージョン(主に使っているリージョン)で同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。

所感

  • 毎年どこかのリージョンで大規模な障害が起きている

    • asia-northeast1 で起きていないのはたまたま、運がいいだけ
    • AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの
    • ステータスダッシュボードは時に嘘をつく
    • クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある
    • Chaos Monkey の思想は必須
  • 報告書読むの面白い
  • us-east は呪われている

AWS 障害一覧

  • 報告書が出ているものを網羅できているかとおもいます

    • SimpleDB の障害だけ除外しました。
  • 最近起きたものから過去に遡っていきます

2017/3/1 us-east-1:バージニア北部の S3 が逝く [new!]

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • S3 がアクセス不可
  • 影響した利用者
    • Imgur、IFTTT、Zapier、Slack、Trello など
  • 障害内容
    • まだ
  • 復旧内容
    • まだ
  • 今後の対応
    • まだ
  • 復旧までの時間
    • 3時間 くらい

2016/6/4 ap-southeast-2:豪雨でシドニーの EC2 が逝く

報告書サマリ

  • 障害リージョン

    • ap-southeast-2:アジアパシフィック (シドニー)
  • 障害サービス
    • EC2、Redshift、RDS 等
  • 影響した利用者
  • 障害内容
    • 豪雨により停電
    • UPS への切替時に異常な電圧低下が起きる
    • EC2 落ちまくる
  • 復旧内容
    • 手動で UPS への電源切替を実施
    • 大部分の EC2 は インスタンス管理ソフトにより自動復旧してきた
    • 一部の EC2 インスタンスはインスタンス管理ソフトのバグにより自動復旧されなかったため、手動で回復する
  • 今後の対応
    • 電源周りの見直し
    • 定期的なリカバリテストの実施
  • 復旧までの時間
    • 1.5 時間

2015/9/20 us-east:新機能追加で DynamoDB が逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • DynamoDB がアクセス不可
  • 影響した利用者
    • Netflix、 Reddit 等
  • 障害内容
    • DynamoDB に グローバルセカンダリインデックス(GSI) の機能追加がされる
    • グローバルセカンダリインデックス の利用者増加により、DynamoDB 内部メタデータが急増
    • 内部メタデータを格納しているストレージサーバの容量割当が小さく、メタデータのパーティショニングが発生
    • メタデータの読込性能が劣化し、DynamoDB のエラー率増加
    • 内部的に DynamoDB を使用している EC2 Auto Scaling、SQS、CloudWatch も連鎖的にエラー率増加
  • 復旧内容
    • メタデータサービスの容量追加
  • 今後の対応
    • メタデータサービスの容量割当変更
    • 顧客のサービス利用規模の監視
  • 復旧までの時間
    • 5 時間

2012/12/24 us-east:オペミスにより ELB が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • ELB
  • 影響した利用者
    • Netflix など
  • 障害内容
    • オペレーションミスにより、ELB 管理アプリケーションから ELB の状態管理データが一部論理削除
    • EBL の新規作成はできるが、既存 ELB の状態変更ができない事態へ
  • 復旧内容
    • ELB 状態管理データの手動復旧
  • 今後の対応
    • 運用データへのアクセスポリシー見直し
    • データ復旧プロセスの変更
  • 復旧までの時間
    • 12 時間

2012/10/22 us-east-1:設定ミスにより EBS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS
  • 影響した利用者
  • 障害内容
    • EBS ストレージ管理サーバの交換作業の一貫で、内部 DNS 設定変更を行ったが設定値にミスがあった
    • ミスった DNS 設定値がなぜか EBS 管理サーバの一部だけに反映される
    • 反映された EBS 管理サーバに、データ収集サーバに接続できないとメモリリークが起きるという潜在バグが発生
    • EBS 管理サーバがメモリ不足によりフェイルオーバーしまくり、フェイルオーバー先が枯渇
    • EBS アクセス不可になる
    • RDS も EBS にアクセスでず、シングル構成のものは死亡、一部 Multi-AZ もバグでフェイルオーバーしなかった
    • ELB も EBS に置いてる構成情報にアクセスできないので自動フェイルオーバーするも、EIP が枯渇して死亡
  • 復旧内容
    • EBS ストレージ管理サーバのメモリ手動解放により、EBS 復旧
    • ELB 手動回復
  • 今後の対応
    • EBS 管理サーバのメモリ監視見直し
    • EBS 管理サーバのフェイルオーバー方法見直し
    • DNS 設定が一部にしか反映できないものを修正
    • RDS フェイルオーバーの不具合修正
    • ELB に追加の EIP を確保
  • 復旧までの時間
    • 14 時間

2012/6/29 us-east-1:嵐により、全体的に逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • EC2、EBS、RDS 等
  • 影響した利用者
    • Netflix、Instagram、Pinterest、Heroku、Flipboard 等
  • 障害内容
    • 落雷のため停電が複数回発生
    • 二度目の発電機への切り替えに失敗、UPS 運用となる
    • 発電機復旧前に UPS 電力枯渇して電源喪失
    • EC2、EBS、RDS など AZ サービスが死亡
  • 復旧内容
    • 発電機復旧
    • EC2 インスタンス管理ソフト はブートプロセスにボトルネックがあり復旧が遅れる
    • EBS は整合性チェックに時間がかかり復旧が遅れる
    • ELB はフェイルオーバー処理を開始するも、不具合にスケールアップし始める
    • 別リージョンでの ELB 処理が溜まりまくって
  • 復旧までの時間
    • 4時間程度

2011/4/21 us-east:設定ミスで EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
    • Heroku 等
  • 障害内容
    • NW 増強のための設定変更実施時に、ルーティング設定のミスが発生
    • ルータがトラフィックを捌ききれず、EBS ノードが NW 分離状態となる
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
  • 復旧内容
    • 障害の起きた EBS ノードを手動切り離し、容量確保
    • データ復旧にとりかかるも、AZ 内データの 0.07% が復旧できなかった
  • 今後の対応
    • ストレージの増強
    • EBS クラスタ制御の改善
    • ヘルスツールの改善
  • 復旧までの時間
    • 4 日

2011/4/14 eu-west:電源喪失で EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • eu-west:欧州
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
  • 障害内容
    • 変圧器の故障により、電力喪失
    • PLC が不具合により発電機に接続できなかった
    • UPS に切り替わるも電力が不足
    • EC2 でエラー率上昇
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
      • 一つ上のと同じ事象です
  • 復旧内容
    • 手動で発電機に接続、その後電源復旧
    • 不整合の起きた EBS ボリュームのデータ復旧
  • 今後の対応
    • 電源復旧時の EBS ボリュームを自動復旧するよう機能追加
    • EBS スナップショットのバグもついでに見つかり、修正する
  • 復旧までの時間
    • 1 日

参考

続きを読む

AWS 各種サービス料金早見表

目的

 自分用のメモです。
 AWS サービスの料金を聞かれても即答できないことがあるので、AWS 各ページからまとめて金額を引っ張ってきました。更新時点の料金・円レート・東京リージョンのものを記載しています。よく使うものだけ。

 追記:メモなので、価格改定や為替レート変動には対応しません。

EBS

 1GB あたりの容量月額課金。Provisiond IOPS は IOPS 確保に対して課金もある。マグネティックは旧世代の扱いで I/O にも課金がある。

ストレージタイプ 容量1GBあたり$ 円換算 備考 ボリュームサイズ 最大IOPS/ボリューム 最大スループット/ボリューム
General Purpose SSD (gp2) 0.12 13.54 1 GiB~16 TiB 10,000 160 MiB/秒
Provisioned IOPS SSD (io1) 0.142 16.02 $0.074(¥8.35) * プロビジョニングしたIOPS 4 GiB~16 TiB 20,000 320 MiB/秒
Throughput Optimized HDD (st1) 0.054 6.09 500 GiB~16 TiB 500 500 MiB/秒
Cold HDD (sc1) 0.03 3.38 500 GiB~16 TiB 250 250 MiB/秒
S3 Snapshot 0.05 5.64
Magnetic 0.08 9.02 $0.08(¥9.03) / 1万IOPS 1 GiB~1 TiB 40~200 40 ~ 90 MiB/秒

EC2

EC2 インスタンスの料金 – アマゾン ウェブ サービス (AWS)

Linux インスタンス

インスタンスタイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Linux/UNIX 料金
t2.nano 1 可変 0.5 EBS のみ $0.008 /1 時間
t2.micro 1 可変 1 EBS のみ $0.016 /1 時間
t2.small 1 可変 2 EBS のみ $0.032 /1 時間
t2.medium 2 可変 4 EBS のみ $0.064 /1 時間
t2.large 2 可変 8 EBS のみ $0.128 /1 時間
t2.xlarge 4 可変 16 EBS のみ $0.256 /1 時間
t2.2xlarge 8 可変 32 EBS のみ $0.512 /1 時間
m4.large 2 6.5 8 EBS のみ $0.139 /1 時間
m4.xlarge 4 13 16 EBS のみ $0.278 /1 時間
m4.2xlarge 8 26 32 EBS のみ $0.556 /1 時間
m4.4xlarge 16 53.5 64 EBS のみ $1.113 /1 時間
m4.10xlarge 40 124.5 160 EBS のみ $2.782 /1 時間
m4.16xlarge 64 188 256 EBS のみ $4.45 /1 時間
m3.medium 1 3 3.75 1 x 4 SSD $0.096 /1 時間
m3.large 2 6.5 7.5 1 x 32 SSD $0.193 /1 時間
m3.xlarge 4 13 15 2 x 40 SSD $0.385 /1 時間
m3.2xlarge 8 26 30 2 x 80 SSD $0.77 /1 時間
c4.large 2 8 3.75 EBS のみ $0.126 /1 時間
c4.xlarge 4 16 7.5 EBS のみ $0.252 /1 時間
c4.2xlarge 8 31 15 EBS のみ $0.504 /1 時間
c4.4xlarge 16 62 30 EBS のみ $1.008 /1 時間
c4.8xlarge 36 132 60 EBS のみ $2.016 /1 時間
c3.large 2 7 3.75 2 x 16 SSD $0.128 /1 時間
c3.xlarge 4 14 7.5 2 x 40 SSD $0.255 /1 時間
c3.2xlarge 8 28 15 2 x 80 SSD $0.511 /1 時間
c3.4xlarge 16 55 30 2 x 160 SSD $1.021 /1 時間
c3.8xlarge 32 108 60 2 x 320 SSD $2.043 /1 時間
g2.2xlarge 8 26 15 60 SSD $0.898 /1 時間
g2.8xlarge 32 104 60 2 x 120 SSD $3.592 /1 時間
x1.16xlarge 64 174.5 976 1 x 1920 SSD $9.671 /1 時間
x1.32xlarge 128 349 1952 2 x 1920 SSD $19.341 /1 時間
r3.large 2 6.5 15 1 x 32 SSD $0.2 /1 時間
r3.xlarge 4 13 30.5 1 x 80 SSD $0.399 /1 時間
r3.2xlarge 8 26 61 1 x 160 SSD $0.798 /1 時間
r3.4xlarge 16 52 122 1 x 320 SSD $1.596 /1 時間
r3.8xlarge 32 104 244 2 x 320 SSD $3.192 /1 時間
r4.large 2 7 15.25 EBS のみ $0.16 /1 時間
r4.xlarge 4 13.5 30.5 EBS のみ $0.32 /1 時間
r4.2xlarge 8 27 61 EBS のみ $0.64 /1 時間
r4.4xlarge 16 53 122 EBS のみ $1.28 /1 時間
r4.8xlarge 32 99 244 EBS のみ $2.56 /1 時間
r4.16xlarge 64 195 488 EBS のみ $5.12 /1 時間
i3.large 2 7 15.25 1 x 475 NVMe SSD $0.183 /1 時間
i3.xlarge 4 13 30.5 1 x 950 NVMe SSD $0.366 /1 時間
i3.2xlarge 8 27 61 1 x 1900 NVMe SSD $0.732 /1 時間
i3.4xlarge 16 53 122 2 x 1900 NVMe SSD $1.464 /1 時間
i3.8xlarge 32 99 244 4 x 1900 NVMe SSD $2.928 /1 時間
i3.16xlarge 64 200 488 8 x 1900 NVMe SSD $5.856 /1 時間
d2.xlarge 4 14 30.5 3 x 2000 HDD $0.844 /1 時間
d2.2xlarge 8 28 61 6 x 2000 HDD $1.688 /1 時間
d2.4xlarge 16 56 122 12 x 2000 HDD $3.376 /1 時間
d2.8xlarge 36 116 244 24 x 2000 HDD $6.752 /1 時間

Windows インスタンス

インスタンスタイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Windows 料金
t2.nano 1 可変 0.5 EBS のみ $0.0103 /1 時間
t2.micro 1 可変 1 EBS のみ $0.021 /1 時間
t2.small 1 可変 2 EBS のみ $0.041 /1 時間
t2.medium 2 可変 4 EBS のみ $0.082 /1 時間
t2.large 2 可変 8 EBS のみ $0.156 /1 時間
t2.xlarge 4 可変 16 EBS のみ $0.297 /1 時間
t2.2xlarge 8 可変 32 EBS のみ $0.574 /1 時間
m4.large 2 6.5 8 EBS のみ $0.231 /1 時間
m4.xlarge 4 13 16 EBS のみ $0.462 /1 時間
m4.2xlarge 8 26 32 EBS のみ $0.924 /1 時間
m4.4xlarge 16 53.5 64 EBS のみ $1.849 /1 時間
m4.10xlarge 40 124.5 160 EBS のみ $4.622 /1 時間
m4.16xlarge 64 188 256 EBS のみ $7.394 /1 時間
m3.medium 1 3 3.75 1 x 4 SSD $0.146 /1 時間
m3.large 2 6.5 7.5 1 x 32 SSD $0.292 /1 時間
m3.xlarge 4 13 15 2 x 40 SSD $0.583 /1 時間
m3.2xlarge 8 26 30 2 x 80 SSD $1.166 /1 時間
c4.large 2 8 3.75 EBS のみ $0.218 /1 時間
c4.xlarge 4 16 7.5 EBS のみ $0.436 /1 時間
c4.2xlarge 8 31 15 EBS のみ $0.872 /1 時間
c4.4xlarge 16 62 30 EBS のみ $1.744 /1 時間
c4.8xlarge 36 132 60 EBS のみ $3.672 /1 時間
c3.large 2 7 3.75 2 x 16 SSD $0.231 /1 時間
c3.xlarge 4 14 7.5 2 x 40 SSD $0.462 /1 時間
c3.2xlarge 8 28 15 2 x 80 SSD $0.925 /1 時間
c3.4xlarge 16 55 30 2 x 160 SSD $1.849 /1 時間
c3.8xlarge 32 108 60 2 x 320 SSD $3.699 /1 時間
g2.2xlarge 8 26 15 60 SSD $1.01 /1 時間
g2.8xlarge 32 104 60 2 x 120 SSD $3.87 /1 時間
x1.16xlarge 64 174.5 976 1 x 1920 SSD $12.615 /1 時間
x1.32xlarge 128 349 1952 2 x 1920 SSD $25.229 /1 時間
r3.large 2 6.5 15 1 x 32 SSD $0.3 /1 時間
r3.xlarge 4 13 30.5 1 x 80 SSD $0.599 /1 時間
r3.2xlarge 8 26 61 1 x 160 SSD $1.177 /1 時間
r3.4xlarge 16 52 122 1 x 320 SSD $2.276 /1 時間
r3.8xlarge 32 104 244 2 x 320 SSD $4.25 /1 時間
r4.large 2 7 15.25 EBS のみ $0.252 /1 時間
r4.xlarge 4 13.5 30.5 EBS のみ $0.504 /1 時間
r4.2xlarge 8 27 61 EBS のみ $1.008 /1 時間
r4.4xlarge 16 53 122 EBS のみ $2.016 /1 時間
r4.8xlarge 32 99 244 EBS のみ $4.032 /1 時間
r4.16xlarge 64 195 488 EBS のみ $8.064 /1 時間
i3.large 2 7 15.25 1 x 475 NVMe SSD $0.275 /1 時間
i3.xlarge 4 13 30.5 1 x 950 NVMe SSD $0.55 /1 時間
i3.2xlarge 8 27 61 1 x 1900 NVMe SSD $1.1 /1 時間
i3.4xlarge 16 53 122 2 x 1900 NVMe SSD $2.2 /1 時間
i3.8xlarge 32 99 244 4 x 1900 NVMe SSD $4.4 /1 時間
i3.16xlarge 64 200 488 8 x 1900 NVMe SSD $8.8 /1 時間
d2.xlarge 4 14 30.5 3 x 2000 HDD $0.975 /1 時間
d2.2xlarge 8 28 61 6 x 2000 HDD $1.909 /1 時間
d2.4xlarge 16 56 122 12 x 2000 HDD $3.678 /1 時間
d2.8xlarge 36 116 244 24 x 2000 HDD $7.43 /1 時間

EBS 最適化インスタンス 使用量

インスタンスタイプ EBS 最適化使用料
m1.large $0.025 /1 時間
m1.xlarge $0.05 /1 時間
m4.large $0.00 /1 時間
m4.xlarge $0.00 /1 時間
m4.2xlarge $0.00 /1 時間
m4.4xlarge $0.00 /1 時間
m4.10xlarge $0.00 /1 時間
m3.xlarge $0.025 /1 時間
m3.2xlarge $0.05 /1 時間
c4.large $0.00 /1 時間
c4.xlarge $0.00 /1 時間
c4.2xlarge $0.00 /1 時間
c4.4xlarge $0.00 /1 時間
c4.8xlarge $0.00 /1 時間
c3.xlarge $0.02 /1 時間
c3.2xlarge $0.05 /1 時間
c3.4xlarge $0.10 /1 時間
c1.xlarge $0.05 /1 時間
r3.xlarge $0.02 /1 時間
r3.2xlarge $0.05 /1 時間
r3.4xlarge $0.10 /1 時間
m2.2xlarge $0.025 /1 時間
m2.4xlarge $0.05 /1 時間
i2.xlarge $0.02 /1 時間
i2.2xlarge $0.05 /1 時間
i2.4xlarge $0.10 /1 時間
d2.xlarge $0.00 /1 時間
d2.2xlarge $0.00 /1 時間
d2.4xlarge $0.00 /1 時間
d2.8xlarge $0.00 /1 時間

EIP

未割当への課金は IP 枯渇対策ってことでしょうね。

料金 円換算 課金単位
$0.00 ¥0.00 割当中EIP
$0.01 ¥0.56 追加割当EIP/1時間
$0.01 ¥0.56 未割当EIP/1時間
$0.00 ¥0.00 リマップ
$0.10 ¥11.28 リマップ(1か月間で100リマップ超過分)

ELB

AWS | Elastic Load Balancing | Classic Load Balancer の料金

料金 円換算 課金単位
$0.027 ¥3.05 1時間あたり
$0.01 ¥0.90 処理1GBあたり

RDS

料金 – Amazon RDS | AWS
ライセンス費込みだけ記載。

Aurora

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.medium $0.13 ¥14.10 2 4
db.r3.large $0.35 ¥39.48 2 15
db.r3.xlarge $0.70 ¥78.96 4 30.5 搭載
db.r3.2xlarge $1.40 ¥157.93 8 61 搭載
db.r3.4xlarge $2.80 ¥315.86 16 122 搭載
db.r3.8xlarge $5.60 ¥631.72 32 244 10 ギガビット

Oracle

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.micro $0.04 ¥4.63 1 1
db.t2.small $0.08 ¥9.25 1 2
db.t2.medium $0.16 ¥18.50 2 4
db.t2.large $0.38 ¥43.09 2 8
db.m4.large $0.48 ¥54.49 2 8 搭載
db.m4.xlarge $0.97 ¥109.31 4 16 搭載
db.m4.2xlarge $1.94 ¥218.51 8 32 搭載
db.m4.4xlarge $3.87 ¥437.01 16 64 搭載
db.m3.medium $0.25 ¥27.64 1 3.75
db.m3.large $0.49 ¥55.28 2 7.5
db.m3.xlarge $0.98 ¥110.55 4 15 搭載
db.m3.2xlarge $1.96 ¥221.10 8 30 搭載
db.r3.large $0.53 ¥59.22 2 15
db.r3.xlarge $1.05 ¥118.45 4 30.5 搭載
db.r3.2xlarge $2.10 ¥236.89 8 61 搭載
db.r3.4xlarge $4.20 ¥473.79 16 122 搭載

SQL Server Express

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.micro $0.03 ¥3.50 1 1
db.t2.small $0.06 ¥6.99 1 2
db.t2.medium $0.12 ¥13.99 2 4

SQL Server Enterprise

インスタンスタイプ 時間あたり$ 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.r3.2xlarge $5.81 ¥655.41 8 61 搭載
db.r3.4xlarge $11.40 ¥1,286.45 16 122 搭載
db.r3.8xlarge $19.27 ¥2,173.90 32 244 10 ギガビット

続きを読む

Amazon LinuxにアタッチされているEBSのボリュームサイズを拡張する。

はじめに

つい先日、Amazon EBSのアップデートで 「エラスティックボリューム」の発表 がありました。
これはEC2にアタッチされたEBSに対し、「ボリュームサイズの拡張」「パフォーマンスの調整」「ボリュームタイプの変更」がオンラインで行うことができます。
ということで今回、「ボリュームサイズの拡張」を行ってみたいと思います。

事前確認

今回作業するOSは Amazon Linux 2016.09 です。
まずは状況確認しておきます。

デバイスの確認
$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  10G  0 disk /data

現在、 xvdb という名前でボリュームサイズが10GBのデバイスがEC2インスタンスにアタッチされています。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  984M  6.7G   13% /
/dev/xvdb        9.8G   23M  9.2G    1% /data

また、 ファイルシステムとしても10GBのボリュームが /data 領域にマウントされているのを確認できます。

今回はこの xvdb のボリュームサイズを拡張します。

EBSサイズの拡張

[EC2] > [ボリューム] から対象となるボリュームをチェックし、[アクション]から[Modify Volume]をクリックします。
expand-ebs01.png

今回は 20GB へ拡張するので「Size」の1020に変更し[Modify]をクリックします。
expand-ebs02.png

「ボリュームの変更をしても本当にいいですか?」と聞かれるので、[Yes]をクリックします。
expand-ebs03.png

すると「in-use optimizing」というステータスになります。変更したサイズへ拡張中です。
expand-ebs04.png

しばらくして「in-use completed」になったらEBS拡張処理の完了です。
expand-ebs05.png

ファイルシステムサイズの拡張

それでは先ほど拡張したボリュームサイズがちゃんと20GBに増えているか確認してみます。

デバイスの確認
$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  20G  0 disk /data

無事、20GBのボリュームとして認識されているのが確認できました。
ですが、今のままだとEBSデバイスのサイズが増えただけです。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  985M  6.7G   13% /
/dev/xvdb        9.8G   23M  9.2G    1% /data

なので、まだこのままではOSから利用することはできません。
ということでOSから利用できるようにresize2fsでファイルシステムをリサイズします。

ファイルシステムの拡張
$ sudo resize2fs /dev/xvdb 
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvdb is mounted on /data; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvdb is now 5242880 (4k) blocks long.

これでファイルシステムのリサイズ完了です。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  985M  6.7G   13% /
/dev/xvdb         20G   28M   19G    1% /data

ということで無事にOSから利用できるようになりました。

おわりに

これで「とりあえず多めに確保」をする必要も無くなり、「今必要なサイズ」を割り当てれば良くなりました。
また、拡張作業もオンタイムで行えるので、費用面だけでなく運用面のコスト削減にもなります。
これで「いろんな人の負担」がかなり軽くなりますね。

続きを読む

オンラインでボリュームや性能追加できるAmazon EBSのElastic Volume

利用はAWSマネジメントコンソールやAPIコール、AWS CLIから行なえる。AWS CloudFormationのスタック更新機能も利用でき、対象のボリュームに必要な変更 … 続きを読む

Elastic Volumes (Amazon EBS)

ついにEC2インスタンスを起動したままEBSのボリュームタイプと容量・IOPSの変更ができるようになりました!

Elastic Volumes(エラスティックボリューム)という機能だそうです。
新しいボリュームタイプではないのですね。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/considerations.html
を見ると
– Magneticは対象外
– サイズ縮小は当然NG
– 変更後は6時間変更不可
– 2016/11/1以前にアタッチされたボリュームはインスタンスの停止・起動、またはボリュームのデタッチ・アタッチが必要
らしい。他にも制約や前提ありますね。読み込まないと。

紹介記事

続きを読む

EFSとEBS

AWSのストレージサービス

AWSには以下のようなストレージサービスが提供されています。

  • インスタンスストレージ
  • EBS
  • EFS
  • S3
  • Glacier
  • Storage Gateway
  • RDS
  • Redshift
  • ElastiCache
  • DynamoDB
  • (SimpleDB)

ここではEFSとEBSの比較について特徴と利用方法を取り上げます。

EFSとEBSの比較

EFSはNFSでアクセス可能な共有ストレージのファイルストレージサービスで、EBSはブロックレベルのストレージサービスで、共にEC2にマウント可能なストレージです。EFSとEBSの利用比較の図については以下のようになります。
efs_ebs.png

公式ページの比較表を引用させて頂くと以下のようになります。

Amazon EFS Amazon EBS PIOPS
パフォーマンス オペレーションあたりのレイテンシー 低、一定 最低、一定
スループットスケール 1 秒間あたり数 GB 1 秒間あたり 1 GB
特徴 データ(可用性/耐久性) 複数 AZ に冗長的に保存 単一 AZ に冗長的に保存
アクセス 複数 AZ の 1~数千の EC2 インスタンスから同時 単一 AZ の単一 EC2 インスタンスから
ユースケース ビッグデータと分析、メディア処理ワークフロー、コンテンツ管理、ウェブ配信、ホームディレクトリ ブートボリューム、トランザクションおよび NoSQL データベース、データウェアハウスと ETL

制限

マウントコマンド まとめ

EFS

$ sudo yum install nfs-utils
$ sudo mkdir -p /mnt/efs/0
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0
$ df -h
$ sudo bash -c "echo 'fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0 nfs4 defaults 0 0' >> /etc/fstab"

EBS

$ sudo mkfs.xfs /dev/sdf
$ sudo mkdir -p /mnt/ebs/0
$ sudo mount -t xfs /dev/sdf /mnt/ebs/0
$ df -h
$ sudo bash -c "echo '/dev/sdf /mnt/ebs/0 xfs defaults 0 0' >> /etc/fstab"

利用方法

EFS

マネジメントコンソールから[Elastic File System]を選択。
[Create file system]を選択。

Step 1: Configure file system access

VPC: vpc-xxxxxxxxx
Create mount targets:
Availability Zone, Subnet, IP address, Security groupsの各項目について、利用するリージョン中のアベイラビリティゾーンが幾つか表示される。

[Next step]を選択。

Step 2: Configure optional settings

Add tags

Key: Name
Value: SampleEFS

Choose performance mode

  • General Purpose
  • Max I/O

パフォーマンスモードは2種類から選択できる。Max I/Oはインスタンスが10個〜1000個の規模で接続するのに向いている。通常はGeneral Purposeで良い。CloudWatchのPercentIOLimitのIOの様子を見てMax I/Oを考える。

[Next step]を選択。

Step 3: Review and create

内容を確認したら、[Create File System]を選択。

※注意点で、EFS側のセキュリティグループでインバウンドでEFSの通信を許可しておかないとタイムアウトでマウントに失敗するので、ポートを開放しておく。

EFSのMount targetsで各AZに適用されているSecurity Groupを確認しておく。
マネジメントコンソールから[VPC]を選択。
[セキュリティグループ]を選択。
先ほど確認したセキュリティグループを選択し、インバウンドルールを選択して、[編集]を選択。

[別のルールの追加]を選択して、以下を追加して[保存]を選択する。

カスタムTCPルール TCP(6) 2049 0.0.0.0/0

$ ssh -i ~/.ssh/id_rsa.pem ec2-user@XXX.XXX.XXX.XXX

以下を入力しても何も表示されない場合はnfs-utilsがインストールされていないのでインストールする。

$ yum list installed | grep nfs-utils
nfs-utils.x86_64                         1:1.3.0-0.21.amzn1           @amzn-main
$ sudo yum install nfs-utils
$ sudo mkdir -p /mnt/efs/0
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0
$ df -h
ファイルシス                              サイズ  使用  残り 使用% マウント位置
/dev/xvda1                                  7.8G  1.2G  6.6G   15% /
devtmpfs                                    488M   60K  488M    1% /dev
tmpfs                                       498M     0  498M    0% /dev/shm
fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/   8.0E     0  8.0E    0% /mnt/efs/0
$ sudo bash -c "echo 'hoge' > /efs/sample.txt"
  • ユーザに実行権限がないディレクトリのファイルに対してリダイレクトでデータを書き込みとsudo をつけても失敗する。
  • もしくは、sudo tee -a /efs/sample.txt

としておき、別のインスタンスからも同様の手順でマウントすると、

$ cat /efs/sample.txt 
hoge

ファイルが共有できることが確認できる。

Amazon Linux, Red Hat Enterprise Linux, or SuSE Linuxでは、nfs-utilsパッケージ
Ubuntuでは、nfs-commonパッケージ

nfs-utilsパッケージを使用するが、Amazon Linuxではデフォルトでインストールされているので、yumなどでインストールする必要はない。

再起動してもマウントが外れないように/etc/fstabにマウントの情報を追記しておく。

$ sudo bash -c "echo 'fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0 nfs4 defaults 0 0' >> /etc/fstab"

注意点

nfs-utilsを入れ直さないと

$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /efs
mount: wrong fs type, bad option, bad superblock on fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

(参考) http://qiita.com/Accent/items/0d99c4652e2101760b50

$ sudo yum install nfs-utils

ファイアウォールを解放しないと

$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ efs
mount.nfs4: Connection timed out

EBS

マネジメントコンソールの操作

1.マネジメントコンソールから、[EC2]を選択。
2.ELASTIC BLOCK STOREの[ボリューム]を選択。
3.[ボリュームの作成]を選択。

4.
ボリュームタイプ: 汎用SSD(GP2)
サイズ(GiB): 5(最小: 1 GiB、最大: 16384 GiB)
IOPS: 300 / 3000(Baseline of 3 IOPS per GiB with a minimum of 100 IOPS, burstable to 3000 IOPS)
スループット (MB/秒): 該当しません
アベイラビリティーゾーン : us-east-1d
スナップショット ID: (空欄)
暗号化: (チェックしない)

[作成]を選択。

EBSはアベイラビリティーゾーンに属するので、アタッチしたいEC2インスタンスがあるものと同じものにしておかないといけないことに注意。

5.作成したボリュームを選択した状態で[アクション]から[ボリュームのアタッチ]を選択。

6.
ボリューム : us-east-1d にある vol-0bf1030e59290b4f8
インスタンス : i-e25cdcd2 us-east-1d 内の
デバイス : /dev/sdf

  • Linux のデバイス: /dev/sdf から /dev/sdp

[アタッチ]を選択。

7.デバイスの存在を確認。

CUIからの操作

$ ssh -i ~/.ssh/id_rsa.pem ec2-user@XXX.XXX.XXX.XXX
$ ls -al /dev/ | grep sdf
lrwxrwxrwx  1 root root           4  1月  2 06:16 sdf -> xvdf

xfsprogsパッケージが必要。Amazon Linuxではデフォルトでインストールされている。

$ sudo mkfs.xfs /dev/sdf
meta-data=/dev/sdf               isize=256    agcount=4, agsize=327680 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=1310720, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo mkdir -p /mnt/ebs/0
$ sudo mount -t xfs /dev/sdf /mnt/ebs/0
$ df -h
ファイルシス                              サイズ  使用  残り 使用% マウント位置
/dev/xvda1                                  7.8G  1.2G  6.6G   15% /
devtmpfs                                    488M   64K  488M    1% /dev
tmpfs                                       498M     0  498M    0% /dev/shm
fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/   8.0E     0  8.0E    0% /mnt/efs/0
/dev/xvdf                                   5.0G   33M  5.0G    1% /mnt/ebs/0

再起動してもマウントが外れないように/etc/fstabにマウントの情報を追記しておく。

$ sudo bash -c "echo '/dev/sdf /mnt/ebs/0 xfs defaults 0 0' >> /etc/fstab"

その他

ルートデバイスボリュームの容量の追加

AMIの作成
AMIや元々のインスタンスの設定によっては、サイズの変更が反映されないので以下のコマンドを入力する。

$ sudo resize2fs /dev/xvda1

追加ボリュームの容量の追加。

$ sudo resize2fs /dev/xvdf

ファイルシステムがXFSの場合は以下のコマンドを入力する。

$ sudo xfs_growfs /mnt/ebs/0

参考

http://docs.aws.amazon.com/efs/latest/ug//mounting-fs.html
http://dev.classmethod.jp/cloud/aws/amazon-elastic-file-system-is-generally-available/
http://dev.classmethod.jp/cloud/efs-ataglance/
http://blog.serverworks.co.jp/tech/2016/06/29/efs-2/

続きを読む

AWS EC2にMongoDBインストールとレプリケーション設定

MongoDBインストールとレプリケーション設定について、簡易的な抜粋メモとして書いています。
詳細に関しては、記事の最後の参考サイトを確認するようにしてください。

◆ 今日やること

  • MongoDBをEC2にインストール
  • レプリケーションの設定と確認
    • 今回せっていするレプリケーションの形式は、以下の図の通り、「Primary with Secondary Members」です。

mongorepl.png
引用元:Replication — MongoDB Manual 3.4

◆ バージョン

  • MongoDB 3.2
  • Linux 4.4.30-32.54.amzn1.x86_64 #1 SMP Thu Nov 10 15:52:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

◆ 実装編

> EC2へのインストール

sudo yum update -y
sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc
sudo yum install -y mongodb-org
sudo service mongod start

sudo chkconfig mongod on

> 設定周り

  • WoredTigerストレージエンジンの主な設定

    • cacheSizeGB: システムメモリの6、7割
    • blockCompressor:デフォルトはsnappy(中間です)
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
       cacheSizeGB: 1
       journalCompressor: snappy
    collectionConfig:
       blockCompressor: snappy

> EBSボリュームをAttach

  • EBSボリュームにmongoのデータを溜めるようにする。

Amazon EBS ボリュームを使用できるようにする – Amazon Elastic Compute Cloudに従って、EBSボリュームをアタッチする

  • パーミッションを変更するのを忘れないように。
sudo chown -R mongod:mongod /data
  • /etc/mongod.conf
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data

> レプリケーションの設定

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。
MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

  • ネットワークインターフェイスの設定で、レプリケーションを組むサーバのIPを記述しておくこと

レプリケーション設定前には、お互いに通信できることを確認しないといけません
Troubleshoot Replica Sets — MongoDB Manual 3.4

mongodb が listen するIPアドレスはデフォルトでは 127.0.0.1 に設定されており、ローカルからのみアクセスを許可するようになっています
mongod.conf の bind_ip に設定されたIPアドレスで listen するのでこれを変更することで外部からの接続を許可します
ここに 0.0.0.0 を設定すると全てのIPアドレスからの接続を許可します

/etc/mongod.conf
# network interfaces
net:
  port: 27017
  bindIp: [127.0.0.1,10.1.52.111,10.1.51.227,10.1.51.68]


  • レプリケーション名を決める
  • Oplogのサイジングと設定サイズを決める
/etc/mongod.conf
replication:
   oplogSizeMB: 500
   replSetName: testRepl

第4回 MongoDBのレプリケーションを構築してみよう:MongoDBでゆるふわDB体験|gihyo.jp … 技術評論社

OplogはCapped Collectionなので,作成時以外にサイズ変更することができません。 デフォルトのOplogのサイズは「1GBまたは,ディスクの空き領域の5%」
Staleを避けるために,Oplogのサイジングは非常に重要となります。
Oplogのサイズは,mongodの初回起動時にoplogSizeオプションで変更可能です。
Oplogの適切なサイズを見積もる方法のひとつに,本番を想定した書き込みテストを実施し,作成されたOplogのサイズを取得する方法があります。
1時間程度,本番想定と同程度の書き込みテストを行った後,以下のコマンドでレプリケーションの最新情報を取得します。

> db.getReplicationInfo()

1時間で作成されたOplogのサイズがわかれば,Oplogのサイジングの目安となります。
少なくとも8時間のセカンダリのダウンタイムに耐えられるようにしておくことが推奨されています。

  • レプリケーションの設定

どれかのサーバに入って、以下のコマンドを実行

config = {
  _id : "testRepl",
  members : [
    { _id : 0, host : "10.1.51.227:27017" },
    { _id : 1, host : "10.1.51.68:27017" },
    { _id : 2, host : "10.1.52.111:27017"} ] }

rs.initiate(config)
  • スレーブの読み取り専用動作設定

そのままだと、スレーブが読み取り専用としてアクセスできないので以下の設定を行っておく。

スレーブノードで、以下のコマンドを実行

 db.getMongo().setSlaveOk()
  • レプリケーションステータスの確認
testRepl:PRIMARY> rs.status();
{
    "set" : "connobaRepl",
    "date" : ISODate("2017-01-12T07:03:05.556Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "members" : [
        {
            "_id" : 0,
            "name" : "10.1.51.227:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 100310,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "electionTime" : Timestamp(1484104344, 1),
            "electionDate" : ISODate("2017-01-11T03:12:24Z"),
            "configVersion" : 3,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "10.1.51.68:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 100245,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:04.017Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:04.020Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        },
        {
            "_id" : 2,
            "name" : "10.1.52.47:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 99751,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:05.025Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:05.022Z"),
            "pingMs" : NumberLong(2),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        }
    ],
    "ok" : 1
}

> mongoログインの時の警告メッセージを消す方法

[ec2-user@ip-10-1-52-47 ~]$ mongo
MongoDB shell version: 3.2.11
connecting to: test
Server has startup warnings:
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
testRepl:SECONDARY>

◆ 参考サイト

続きを読む

OpsWorks Instancesで起動したEC2から作成したカスタムAMIをOpsWorks Instancesで利用する際の注意点

1. はじめに


  • OpsWorks Instances で起動した EC2 をイメージ(AMI)化して、それを OpsWorks Instances のカスタムAMIとして利用する際の注意点。
  • EC2は、”Amazon Linux 2016.09″, “Amazon Linux instance Chef 12 stack”, “Amazon EBS-backed” で作成している。
  • 下記の作法の通りに作成していないカスタムAMIを利用して OpsWorks Instances で EC2 を起動すると、Status が “running_setup” 中のままとなり、作成が完了しない。

2. OpsWorks Instances で起動した EC2 から カスタムAMI を作成する

(参考:本家ドキュメント → ”To create a custom AMI from an AWS OpsWorks instance”)


  • AMI を作成する EC2 を起動した OpwsWorks Layers の “Auto healing enabled” を “No” へ変更する

  • AMI を作成する EC2 へ SSH ログインして、次のコマンドを実行する

$ sudo /etc/init.d/monit stop

$ sudo /etc/init.d/opsworks-agent stop

$ sudo rm -rf /etc/aws/opsworks/
$ sudo rm -rf /opt/aws/opsworks/
$ sudo rm -rf /var/log/aws/opsworks/
$ sudo rm -rf /var/lib/aws/opsworks/
$ sudo rm -rf /var/lib/cloud/
$ sudo rm -rf /etc/chef
$ sudo rm -rf /var/chef
$ sudo rm -rf /opt/chef
$ sudo rm -f /etc/monit.d/opsworks-agent.monitrc
$ sudo rm -f /etc/monit/conf.d/opsworks-agent.monitrc

$ sudo rpm -e opsworks-agent-ruby
$ sudo rpm -e chef
  • OpsWorks のコンパネから、AMI を作成する EC2 インスタンスを停止(Actions:stop)する

    Status が stopped となったことを確認

  • イメージ(AMI)を作成する

3. OpsWorks Instance でカスタムAMI から EC2 を起動する CloudFormation の例


"Resources": {
    "OpsWorksStack": {
        "Type": "AWS::OpsWorks::Stack",
        "Properties": {
            "Name": "example",
            "ConfigurationManager": {
                "Name": "Chef",
                "Version": "12"
            },
            "VpcId": "vpc-********",
            "DefaultSubnetId": "subnet-********",
            "DefaultInstanceProfileArn": "arn:aws:iam::************:instance-profile/**********",
            "ServiceRoleArn": "arn:aws:iam::************:role/**********",
            "DefaultOs": "Custom",
            "DefaultRootDeviceType": "ebs",
            "DefaultSshKeyName": "aws-tonishy",
            "HostnameTheme": "Layer_Dependent",
            "UseOpsworksSecurityGroups": "false"
        }
    },
    "OpsWorksLayer": {
        "Type": "AWS::OpsWorks::Layer",
        "Properties": {
            "Type": "custom",
            "Name": "example",
            "Shortname": "example",
            "StackId": {
                "Ref": "OpsWorksStack"
            },
            "EnableAutoHealing": "true",
            "AutoAssignPublicIps": "true",
            "AutoAssignElasticIps": "false",
            "CustomSecurityGroupIds": [
                "sg-********"
            ],
            "CustomInstanceProfileArn": "arn:aws:iam::************:instance-profile/**********"
        }
    },
    "OpsWorksInstance": {
        "Type": "AWS::OpsWorks::Instance",
        "Properties": {
            "AmiId": "ami-********",
            "Os": "Custom",
            "StackId": {
                "Ref": "OpsWorksStack"
            },
            "LayerIds": [
                {
                    "Ref": "OpsWorksLayer"
                }
            ],
            "InstanceType": "t2.micro"
        }
    }
}

※ AWS::OpsWorks::Instance の AmiId に、カスタムAMIの id を設定する

続きを読む

AWSでLinuxしか触ったことない人が、AWSでWindowsServerを利用するときに知っておかないといけないことまとめ

はじめに

  • AWSでLinuxばかりやってたんですがWindowsServerを触らないといけない機会が凄く増えててビビってます。
  • WindowsServer利用するときも、まぁ大体Linuxと一緒なんでしょ!?と思ってたら火傷しますのでしっかりと抑えておきましょう。
  • 他にもWindowsだと気をつけないといけない!なんてことがあればご指摘ください。

ライセンスはどうなってるのか?押さえておこう。

  • WindowsServerのライセンス

    • EC2の費用に含まれている。
    • OSにCALの料金が含まれているのでCALの購入は不要
  • WindowsServerのライセンス持ち込みについて
  • 以下の既存のマイクロソフトライセンスはAWS上に持ち込み可能。
    • 1サーバ1ライセンス、1プロセッサライセンス4コアまでの1インスタンスに対応
    • Exchange Server
    • SharePoint Server
    • SQLServer Enterpriseなど
  • Officeのライセンスについて
    • ハードウェア占有インスタンス、占有ホストで利用可能
  • その他ライセンスについて不明な点があればAWS と Microsoft に関するよくある質問 – ライセンシングを読んでおく。

サポート&トラブル

どのイメージを利用すればよいのか?

  • EC2の画面から「パブリックイメージ」「所有者:Amazonイメージ」「search:Windows_Server-2012-R2_RTM-」で検索するとたくさん出てくる。
  • 「search:Windows_Server-2012-R2_RTM-Japanese」で検索するとLocaleがJapaneseで設定済のものもあるのでこれを選んでおくと楽ですね。

EC2 Management Console 2016-10-07 14-33-05.png

  • 最新のパッチが当たったAMIを公開してくれており、10月5日現在だと6月以前のAMIは無くなっていました。どうしても元のAMIをとっておきたい場合はプライベートイメージとして保管しておく必要がありそう。(が、、、そういうケースはあるんだろうか)

AWS は、Microsoft の火曜パッチ(毎月第 2 火曜日)の 5 営業日以内に、更新されパッチが全面的に適用された Windows AMI を提供します。

  • 新しいAMIがリリースされた時や以前のAMIが非公開になった時に通知をAmazonSNSで受けることができるようです。Subscriptionの設定で以下のARNを設定すればよいようです。
arn:aws:sns:us-east-1:801119661308:ec2-windows-ami-update
arn:aws:sns:us-east-1:801119661308:ec2-windows-ami-private

インストールメディアは使えるのか?

  • 使える。
  • マネジメントコンソールでスナップショットを開いて以下の条件で検索
    • パブリックスナップショットを選択
    • 所有者:Amazonイメージ
    • 説明:Windows 2012 R2
  • あとはボリュームの作成してWindowsServerにAttachすれば利用できる

どうやってWindowsServerに接続するのか?

  • RDPで接続する。パスワードはManagementConsoleからパスワードの取得を行うことで取得できる。
  • インスタンス起動後すぐに取得できるわけではなく、「あとN分後に取得できます。」のメッセージが出てくる。
  • これは後述するEC2Configがパスワードの初期化を行っているから。

拡張ネットワーキングは有効にしておこう

インスタンスの自動復旧設定をしておこう

  • Windowsに限った話ではないが、AutoRecoveryは設定しておく。やっといて損しない。
  • AutoRecoveryはシステムステータスチェックが失敗した場合(ネットワークとか電源とかホスト側の問題でこちらではどうしようもない問題)に自動で復旧してくれる機能で無料で利用できる。
  • 利用条件
    • インスタンスタイプはC3、C4、M3、M4、R3、T2、および X1
    • VPC内で動作しEBS-Backedとなっていること
    • 占有インスタンスではないこと
  • 参考

AutoHealingの設定

  • これもWindowsに限った話ではないが1台構成でもAutoHealingの設定をしておくことを検討しておく。
  • AutoHealingとはAutoScalingGroupの起動数をmin:N,max:Nにしておくことで常にN台起動する状態を作ることを言います。
  • 詳しくは別記事にしますが簡単に触れておく。
  • AutoScalingGroupを利用する場合
    • トリガーはStateがRunningじゃなくなったとき。
    • PrivateIPが変わってしまうので上位にELBを挟むなどの考慮が必要。
    • CloudWatch→SNS→Lambda→AutoScalingGroupをUnHealthyにすることで細かい障害の検知などが可能になる。
  • OptsWorksを利用する場合
    • トリガーはOptsWorksAgentがOptsWorksに通信できなくなったとき。
    • PrivateIPを変更することなくAutoHealingが動かせるが、AutoScalingGroupのような細かい制御は無理

EC2Configの役割について知っておく

  • EC2ConfigはWindows版Cloud-initみたいなものです。EC2Configがやってくれる役割については認識しておこう。
  • AWSが提供するWindowsServerイメージを利用すると既にインストール済になっています。
    C:\Program Files\Amazon\Ec2ConfigService¥Ec2ConfigServiceSettings.exe
  • サービスも自動で起動しているので特に何かしておく必要はありません。
  • こんなことをやってくれます。
* 初回起動時のタスクには以下のものがあります。
    * 管理者アカウントに、ランダムに生成した暗号化パスワードを設定する
    * リモートデスクトップに使用されるホスト証明書を生成しインストールする
    * オペレーティングシステムパーティションを動的に拡張して、未使用の領域が含まれるようにします。
    * 指定されたユーザーデータ(および、インストールされていれば Cloud-Init)を実行します。
* EC2Config は、インスタンスが起動するたびに次のタスクを実行します。
    * 16 進数表記のプライベート IP アドレスと一致するようにコンピュータのホスト名を変更する(このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります)。
    * key management server (KMS)を構成し、Windows アクティベーションのステータスを確認して、必要に応じて Windows のアクティベーションを行う。
    * すべての Amazon EBS ボリュームおよびインスタンスストアボリュームをマウントし、ボリューム名をドライブ文字にマップします。
    * イベントログエントリをコンソールに出力し、トラブルシューティングに役立てる(このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります)。
    * コンソールに Windows の準備が完了した旨の通知を出力する
    * 複数の NIC がアタッチされているとき、プライマリネットワークアダプタにカスタムルートを追加して、IP アドレス 169.254.169.250、169.254.169.251、および 169.254.169.254 を有効にする。これらのアドレスは Windows ライセンス認証が使用し、またユーザーがインスタンスのメタデータにアクセスする際にも使用します。
* EC2Config は、ユーザーがログインするたびに以下のタスクを実行します。
    * デスクトップ背景に壁紙情報を表示する
  • 他の用途については以降で説明します。

AMIの作成方法は2パターンあることを知っておく

  1. マネージメントコンソールやCLIからAMIの作成を行う
  2. EC2ConfigからAMIを作成する
  • 所謂システムバックアップを取得する場合は1を利用すれば良い。
  • EC2ConfigからAMIを作成する理由は、展開用のイメージを作るときです。実行するとセキュリティ識別子(SID)、コンピュータ名、イベントログなど固有の情報が削除され、インスタンスが停止します。停止した状態でコンソールやCLIからイメージを作成すればインスタンス固有の情報が排除されたAMIの作成ができます。
  • 作成の方法についてはSysprep を使って標準の Amazon マシンイメージを作成します。を参考にしてください。

  • 参考

AWS Diagnostics for Microsoft Windows Serverは入れとけ

  • このツールを使うとWindowsServer上から様々な情報を収集し、AWSテクニカルサポートに問い合わせるときに情報を集めるのが非常に楽になるということと、既知の問題に引っかかっていないかを検査してくれるらしいです。素晴らしい。
  • いざサポートに問い合わせる必要が出た時にも慌てないようにダウンロードしておいておき、動くことも確認しておくこと!
  • 集められる情報
IP アドレスとルートテーブルなどのネットワーク情報
ドメインとコンピュータ名
ライセンスの状態、Key Management Server (KMS) の構成などのアクティベーション設定
現在の時刻と時間帯などの時間設定
インスタンス上にインストールされたドライバ
セキュリティグループのルールに沿った Windows ファイアウォールの設定
インストールされた更新
Windows が 1 週間以内にクラッシュした場合のミニダンプファイル
  • 分析ルール
アクティベーションステータスと KMS 設定のチェック
メタデータと KMS アクセスに対する適切なルートテーブルエントリのチェック
セキュリティグループルールと Windows ファイアウォールルールの比較
PV ドライバのバージョン確認(Redhat または Citrix)
RealTimesUniversal レジストリキーが設定されているかの確認
複数の NIC を使用している場合のデフォルトゲートウェイ設定
ミニダンプファイルのコードのバグチェック
  • 動かすのは非常に簡単で、こちらからダウンロードして、exeをクリックするだけです。credentialの入力を求められるますが、予めEC2にReadonlyのRoleを設定しておき利用すると良いでしょう。

10.0.0.117  2016-10-07 15-08-35.png

  • 「OpenReport」をクリックするとテキストでレポートが出力されます。Windowsがライセンスされてるか。SecurityGroupの設定とFirewallの設定が合致しているかなどです。
  • 収集されたデータは実行ディレクトリと同じディレクトリに出力されていました。
  • 10.0.0.117  2016-10-07 15-14-48.png

  • 参考

監視はどうやる?(Cloudwatch)

  • プロセス、パフォーマンス

    • パフォーマンスカウンタで取得したデータをCloudWatchにメトリクスとして登録することが出来ます。パフォーマンスカウンタを利用すると大体のデータは取れるのでpowershellでcloudwatchにput-metricsする必要は無いです。
    • ただし、すべてカスタムメトリクスになるのでガンガン登録するとそれだけコストがかかります。監視するものはカスタムメトリクスとして登録、後々みれれば良いものはパフォーマンスカウンタとして取得しておくよう選別しておこう。
  • ログ
    • イベントログ含め、任意のログデータをEC2Configを利用することでCloudWatchLogsに取り込むことが出来ます。
  • 監視

    • CloudWatchのカスタムメトリクス、CloudWatchLogsに取り込めればこちらのものですね。Cloudwatchの標準機能を使って通知まで実現出来そうですね。
  • パフォーマンスカウンタのデータや、ログをCloudWatch,CloudWatchLogsに取り込む手順は以下の通りです。

共通の設定(CloudWatch Logs の認証情報、リージョン、ロググループ、ログストリームを設定)

  • EC2インスタンスにCloudwatch,CloudwatchLogsにアクセスするためのロールを付与します。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "cloudwatch:*",
        "logs:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
  • EC2Configの設定を開きます。

C:¥Program Files¥Amazon¥Ec2ConfigService¥Ec2ConfigServiceSettings.exe

  • [Cloudwatch Logs] – [Enable CloudWatchLogs Integration]にチェックを入れます。

10.0.0.117  2016-10-07 15-27-36.png

  • 下記の設定ファイル内のリージョンを変更しておきます。今回は東京(ap-northeast-1)にしてあります。
  • ロールの設定が行われている場合は、AccessKey,SecretKeyは無視されるので空のままで良いです。

C:\Program Files\Amazon\Ec2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json

AWS.EC2.Windows.CloudWatch.json
            {
                "Id": "CloudWatchLogs",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "LogGroup": "Default-Log-Group",
                    "LogStream": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": 
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "Windows/Default"
                }
            }
  • ここまでで事前の設定はおしまいです。

イベントログをCloudWatchLogsでみえるようにしてみます

  • このあたりがイベントログの設定になります。
AWS.EC2.Windows.CloudWatch.json
{
    "EngineConfiguration": {
        "PollInterval": "00:00:15",
        "Components": [
            {
                "Id": "ApplicationEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "LogName": "Application",
                    "Levels": "1"
                }
            },
            {
                "Id": "SystemEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "LogName": "System",
                    "Levels": "7"
                }
            },
            {
                "Id": "SecurityEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                "LogName": "Security",
                "Levels": "7"
                }
            },
  • イベントログをCloudWatchLogsに出力するには、IdをFlows加えてあげれば良いです。今回はSecurityEventLogを出力するように追記してみました。
AWS.EC2.Windows.CloudWatch.json
        "Flows": {
            "Flows": 
            [
                "(ApplicationEventLog,SecurityEventLog,SystemEventLog),CloudWatchLogs"
            ]
        }
  • EC2Configを再起動して少し待つとCloudWatchLogsにログが出力されました。

CloudWatch Management Console 2016-10-07 16-52-29.png

パフォーマンスカウンタのデータをCloudWatchカスタムメトリクスに表示してみよう

  • この設定はAvailable MBytesをパフォーマンスカウンタから抽出してCloudWatchのカスタムメトリクスに名前空間Windows/Defaultの中にMemoryというメトリクスを追加しています。
AWS.EC2.Windows.CloudWatch.抜粋.json
            {
                "Id": "PerformanceCounter",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Memory",
                    "CounterName": "Available MBytes",
                    "InstanceName": "",
                    "MetricName": "Memory",
                    "Unit": "Megabytes",
                    "DimensionName": "",
                    "DimensionValue": ""
                }
            },
・・・
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": 
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "Windows/Default"
                }
            }
・・・
        "Flows": {
            "Flows": 
            [
                "(ApplicationEventLog,SecurityEventLog,SystemEventLog),CloudWatchLogs",
                "(PerformanceCounter),CloudWatch"
            ]
        }
  • これも設定後再起動すると、このようにメモリがカスタムメトリクスに表示できます。

CloudWatch Management Console 2016-10-07 17-00-16.png

  • いやー便利ですね。

CloudWatchのメトリクスデータの保管

  • CloudWatchのメトリクスは2週間経つと自動で消えてしまいます。
  • 2週間より大きい期間のデータの保管が必要な場合は、定期的にAPIを使ってローカルに落としておくなどの工夫が必要。

CloudWatchLogsの保管期間を決めておこう

  • CloudWatchLogsも勿論お金が掛かります。
  • CloudWatchLogsのログの保管期間はデフォルトで無制限なので変更しておきましょう。
  • 参考

RunCommandの活用検討及び利用準備はしておく。

  • RunCommandはWindows,Linux共にEC2にログインせずともコマンドが実行できる機能
  • Windowsの場合はEc2Configが入っているのでOS側にエージェントのインストールは不要。
  • Javaのアプリケーションを運用していた場合、事前に準備さえしておけばJavaのThreadDumpもOSにログインしないで実行することができるわけです。
デフォルトで利用できるRunCommand
AWS-JoinDirectoryServiceDomain to join an AWS Directory
AWS-RunPowerShellScript to run PowerShell commands or scripts
AWS-UpdateEC2Config to update the EC2Config service
AWS-ConfigureWindowsUpdate to configure Windows Update settings
AWS-InstallApplication to install, repair, or uninstall software using an MSI package
AWS-InstallPowerShellModule to install PowerShell modules
AWS-ConfigureCloudWatch to configure Amazon CloudWatch Logs to monitor applications and systems
AWS-ListWindowsInventory to collect information about an EC2 instance running in Windows.
AWS-FindWindowsUpdates to scan an instance and determines which updates are missing.
AWS-InstallMissingWindowsUpdates to install missing updates on your EC2 instance.
AWS-InstallSpecificWindowsUpdates to install one or more specific updates.
  • 事前に利用できないかは検討しておこう。利用しない場合でも動かせるように準備はしておいた方が良いと思う。
  • RunCommandが利用できる条件は「RunCommandの前提条件」を参照。

おわりに

  • どうでしょうか。結構色々ありますね。何かあったときに慌てないようにNATやロールの設定は予め考えておきたいですね。

続きを読む

AWS EC2インスタンスにSSHで接続できなくなったとき

ec2_image.png

設定ミスでログインできなくなったインスタンスを復旧することになった時の作業記録です。
Unix系OSにおける一般的な起動ディスクの障害対応手順を、単にAWSならこうやる、というだけの話で恐縮ですが、何かのお役に立てれば幸いです。

症状と効能

こんな人によく効きます。

  • iptablesやTCP Wrapperの設定をミスったとき
  • キーペアを紛失したとき
  • OSの設定をミスって起動しなくなったとき

何かしらの原因で、ログインできなくなったり、インスタンスが起動しなくなったりしたときにファイルシステムにアクセスすれば糸口が掴める、といった時に使えます。

オンプレミス環境やホスティングサービスなら、ブートディスクを変更してからの復旧や、コンソールログインからの設定修正など、何かしらの手段が提供されていますが、AWSだとこのような方法になるかと思います。

なお、利用しているインスタンスはAmazon Linux、rootボリュームはElastic Block Store(EBS)ですが、LinuxのDistributionならば、ほぼ共通の手順になると思われます。

注意点

システムステータスチェックやインスタンスステータスチェックがNGのケースは、この方法では対処できない可能性が高いと思われますのであしからず。その場合は、こちらを参考に対処してください。
参考:『Amazon EC2ユーザガイド』インスタンスのステータスチェック

対応手順サマリ

  1. 障害が発生した「インスタンスA」を停止
  2. 「インスタンスA」のEBSボリュームをデタッチ
  3. 正常起動できる「インスタンスB」に対象ボリュームをアタッチ
  4. 「インスタンスB」を開始&ログイン
  5. 対象ボリュームをマウント
  6. 原因調査と対処
  7. 対象ボリュームをアンマウント&デタッチ
  8. 「インスタンスA」に対象ボリュームをアタッチ&起動

以下に順を追って内容を記します。

障害が発生したインスタンスの停止

まずはマネジメントコンソールで作業します。
対象インスタンスの「ルートデバイス」名を確認してから、インスタンスを停止します。
confirm_rootdevice.png
ルートデバイス名は、「/dev/xvda」もしくは「/dev/sda1」となっているかと思います。今回使用しているAmazon Linuxでは、「/dev/xvda」となっていました。
AWS CLIコマンドを使って調べることも可能です。この辺の詳細は『Amazon EC2ユーザガイド』Linux インスタンスでのデバイスの名前付けを参照してください。

stop_instance.png
対象デバイスを右クリックして「停止」を選択します。

EBSボリュームをデタッチ

インスタンスが停止されたことを確認してから対象のEBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

正常なインスタンスにボリュームをアタッチ

ボリュームの状態が「available」になったら、別の正常なインスタンスにアタッチします。
atach_ebs.png


対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。
atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。今回は「/dev/sdf」を指定。


atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。

正常なインスタンスを開始~ログイン

通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。ちなみに、今回使用したインスタンスはCentOS6.7です。
centos_login.png

対象ボリュームをマウント

ログイン後、先ほどアタッチしたボリューム「/dev/sdf」をマウントします。
このときのデバイス名は、/dev/sdfか/dev/xvdfなど、異なる名前でアタッチされる可能性があります。
参考:『Amazon EC2 ユーザガイド』Amazon EBSボリュームを使用できるようにする

現在のマウントボリュームを確認
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  666M  6.7G   9% /
tmpfs           498M     0  498M   0% /dev/shm

ここで、ルートデバイスが/dev/xv*となっていたら、先ほどアタッチしたボリュームの名前も/dev/xv*となっています。
stop_instance.png

ブロックデバイスを確認
$ ls -la /dev |grep sd
$ ls -la /dev |grep xv
lrwxrwxrwx.  1 root root           5 Oct  8 14:47 root -> xvda1
brw-rw----.  1 root disk    202,   0 Oct  8 14:47 xvda
brw-rw----.  1 root disk    202,   1 Oct  8 14:47 xvda1
brw-rw----.  1 root disk    202,  80 Oct  8 14:47 xvdf
brw-rw----.  1 root disk    202,  81 Oct  8 14:47 xvdf1
マウントするパーティションを確認
$ lsblk -i
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
`-xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
`-xvdf1 202:81   0   8G  0 part

マウントするディレクトリを作成して、マウント実行。

マウント先のディレクトリを作成
$ sudo mkdir /mnt/vol_ebs
マウント実行
$ sudo mount /dev/xvdf1 /mnt/vol_ebs
$ mount
/dev/xvda1 on / type ext4 (rw)
...<snip>...
/dev/xvdf1 on /mnt/vol_ebs type ext4 (rw)

正常にマウントされました(マウントポイントは/)

原因調査と対処

システムログや、作業履歴などから原因を調査し、設定を修正するなどして復旧します。
今回はTCP Wrapperの設定ミスで、SSHログインができなくなっていたため、hosts.allowおよびhosts.denyを適切に修正しました(修正内容は割愛)。

アンマウント~対象ボリュームをデタッチ

念のためアンマウントして、対象インスタンスを停止してから、EBSボリュームをデタッチします。

アンマウント
$ sudo umount /mnt/vol_ebs
マウントされていないことを確認
$ mount
/dev/xvda1 on / type ext4 (rw)
...<snip>...
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

マネジメントコンソールで停止
stop_instance.png
対象デバイスを右クリックして「停止」を選択します。


インスタンスの状態が「stopped」に変わったことを確認して、EBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

対象ボリュームをアタッチ~インスタンス開始

デタッチしたボリュームは元のインスタンスにルートデバイスとしてアタッチします。
ボリュームの状態が「available」であることを確認の上、アタッチします。
atach_ebs.png
対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。


atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。元の状態に戻すため「/dev/xvda」を指定してアタッチします。


atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。


通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。無事ログインできれば成功です。
login_success.png

以上です。

参考にした記事

手順をまとめるにあたり、こちらの記事を参考にさせて頂きました。ありがとうございます。
AWSサーバーにログインできなくなった場合の対処

続きを読む