AWSマネジメントコンソールからEC2インスタンスの再起動を行う方法(非エンジニア向け)

morimorihogeです。外が暑くて融けます。

インフラ管理をしているエンジニアだといまやおなじみのAWSマネジメントコンソールですが、土日や深夜などのイレギュラーなタイミングで非エンジニアな担当者がEC2インスタンス(サーバー)の緊急再起動を対応することもあると思います。今回はそういったときのための手順をまとめます。
※なお、本記事の手順に従って作業して起こったいかなる損害も弊社及び僕個人は保証・サポートしません(免責)

事前確認

再起動を行う以前に、そもそも調子が悪いときに再起動して良いかをインフラ担当者に確認しておきましょう。
システムの構成や設定に寄っては、単純に再起動するだけではなく合わせて他の設定やプログラムを実行したりする必要があります。

もし再起動時に自動的にサービスが起動する設定になっていないサーバーの場合、障害範囲をさらに広げてしまう可能性があります。
インフラ周りを把握していない人がインフラを触るのはそもそも危険だということは認識した上で、それでもどうしても対応しないといけない時だけ本記事にあるような再起動作業を行いましょう。

作業手順

以下、スクリーンショット付きで解説していきます。

AWSマネジメントコンソールにログインする

まずは(AWSトップページ)[https://aws.amazon.com/jp/]の右上メニューから、AWSマネジメントコンソールを選択します

以下のログイン画面からメールアドレスとパスワードでログインできます(ルートアカウントでログインする場合)。

もしアカウント情報として「メールアドレス」ではなく「ユーザー名」を共有されている場合は別途ログイン画面へのURLをもらっているはずです。その際はこの手順ではなくそちらのURLからログインして下さい(https://XXXXXXX.signin.aws.amazon.com/consoleといったURLになるはずです)。

再起動したいEC2インスタンス(サーバー)を捜す

AWSマネジメントコンソールにログインした直後は下図の様なダッシュボード画面に遷移します。
AWSはEC2サーバー以外にも多数のサービスがあるため、まずは再起動したいEC2インスタンス(サーバー)が見られるページまで移動する必要があります。

マネジメントコンソール画面の上部メニューの「サービス」から「EC2」を選択します。

EC2のダッシュボード画面に移動しますが、ここで右上の地名表示部分(リージョンと呼ばれます)が利用しているシステムのリージョン(地域)に一致しているのかを確認して下さい。
※少なくともここ最近リリースされた日本向けのサービスであれば、特別な利用がない限りは「東京」を選べば大丈夫なはずです

システムで利用しているとは異なるリージョンが選択されている場合、右上の地名表示をクリックしてお使いのリージョンを選択して下さい。

正しいリージョン(地域)が選択できていることを確認できたら、左メニューの「インスタンス」を開きます。今起動しているEC2インスタンス(サーバー)の一覧が出てくればOKです。

EC2インスタンス(サーバー)を再起動する

実際にEC2インスタンス(サーバー)を再起動するには、再起動したいインスタンスを選んで右クリックメニューを開き「インスタンスの状態」から「再起動」を選びます。
ここで大事なこととして「停止」してから「開始」するのではなく、必ず「再起動」を選択して下さい
比較的最近のサービス(EC2-VPC)であれば問題ないはずですが、古くから使っているサービス(EC2-Classic)の場合「停止」してから「開始」するのと「再起動」では挙動が異なります。ここで間違えると再起動してもサービスが停止したままという事故に繋がりますので、充分に注意して行って下さい。

また、「削除」を実行してしまうと、サーバーが停止するだけでなく、データが全消去されて復元できなくなります。繰り返しますが充分に注意して行うようにして下さい。

参考: AWSドキュメント: インスタンスの停止と起動

以上で再起動作業は完了です。

システムの構成にもよりますが、通常再起動には数分程度の時間がかかりますのでまったりと待ちましょう。

おまけ:削除保護の設定

インスタンスの「削除」はとても危険で取り返しが付かないということを書きましたが、これについてはAWS側でもちゃんと間違って削除しないための仕組み(削除保護機能)が用意されています。
削除保護が有効な場合、削除しようとしても削除できなくなります(削除保護を無効化してからでないと削除できなくなる)。

保護したいインスタンスをチェックして「アクション」から「インスタンスの設定」「削除保護の変更」をクリックします。

削除保護が無効であれば有効化、有効であれば無効化することができます。

なお、削除保護機能による保護は人力操作のミス以外に、自動化されている処理からも保護してしまうため、システム構成によっては削除保護を有効にすることによって思わぬ動作をする可能性があります(サーバーの台数を増減させるAutoScaling等を利用している場合など)。
システムによっては意図的に削除保護を有効化していないこともあり得るため、こちらも設定変更の際は基本的にインフラ担当者の確認を取りながら設定変更しましょう。

まとめ

主にサーバー設定等に慣れていない非エンジニア向けという視点でEC2インスタンスの再起動手順をまとめてみました。
基本的にはこうした作業は熟練したエンジニアに作業してもらうのが安心なのですが、様々な事情によりどうしても非エンジニアメンバーで対応しなくなった時などには参考になるかと思います。

記事中にも書きましたが、インフラ設定は色々な設定の組み合わせが匠の技で構成されているケースもあるため、よく分からない人が適当に触るのはとても危険です。場合によっては復旧不可能な障害を発生させてしまう可能性もあるので充分に注意して作業するようにしましょう。

関連記事

GitLab自社運用のための注意点とノウハウ(2018/06版)

無料で使えるAWSアカウント用セキュリティ監査ツールの紹介(翻訳)

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

morimorihoge

高校卒業後,学生をやりながらずっとWebアプリ開発に携わってきました.2010くらいまではPHP/Symfonyプログラマでしたが,それ以降のWeb開発はRailsほぼ一本に宗旨替えしました.開発とは別にサーバ構築・運用も10年以上やってきているので,要件定義から設計・実装・環境構築・運用まで一通り何でもこなせます.開発以外では季節により大学でWebサービス開発やプログラミング関連の非常勤講師もしており,技術の啓蒙・教育にも積極的に関わっています.最近はPM的な仕事が増えていますが,現役開発者としていつでも動ける程度にはコードもサーバも弄る日々を送っています.AWS 認定ソリューションアーキテクト – アソシエイトレベル取りました

morimorihogeの書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ