AWS運用のポイント特集

AWSの運用について今まで気を付けてきたこと、今まで失敗したことをベースにAWS運用のポイントを記載します。

私自身も何度も見返して AWS を運用する上で忘れないようにしたいと思います。

視点としては現場で手を動かしているメンバーの視点です。

AWS 失敗事例で検索するといろいろな事例が出てきますが、現場のメンバーの視点ではなく「だから弊社に御社の AWS 運用管理を任せてください！」という営業戦略に則った架空の失敗事例が多いような気がします（笑）

EC2

EC2インスタンスの運用についてポイントを解説します。

「再起動しない」の「有効化」のチェック

AWS管理コンソールからAMIを取得する際に「再起動しない」の「有効化」にチェックを入れ忘れるとEC2インスタンスが再起動してしまいます。

これにチェックを入れるのを忘れてしまうと、いきなり本番環境のDBが再起動して業務が停止または遅延するという障害が発生します。

AWS のメンテナンスで EC2 や RDS がリブートされる

EC2 や RDS は一度構築したら永遠に起動し続けるわけではありません。

AWS側で定期的にメンテナンスを実施しています。

EC2 ダッシュボードのイベントに「system-reboot」や「instance-reboot」などと記載があります。

こちらを確認することで「イベントタイプ」や「開始時刻」や「期限」を確認することが出来ます。

この AWS メンテナンスに気が付かないと予期せぬタイミングでいきなり EC2 インスタンスや RDS がリブートされることになります。

メンテナンス関連で EC2 インスタンスのリブートを実施する際は「停止」→「起動」が必要なのか確認する

EC2 インスタンスのメンテナンスで EC2 インスタンスをリブートする際は、単純に「再起動」でいいのか、「停止」→「起動」の処理が必要なのか確認しましょう。

ここでのポイントは「system-reboot」か「instance-reboot」かどうかという点です。

system-reboot　←　「停止」→「起動」の処理が必要です。
instance-reboot　←　「再起動」でOKです。

後は「イベント」を確認してイベントに残っていないかどうかを確認することも重要です。

EC2 インスタンスを「停止」→「起動」後にパブリックIPが変わっていることがある

Elastic IP を利用していれば大丈夫ですが、Elastic IP ではなくパブリック IP を割り当てているだけの場合は、EC2 インスタンスの「停止」→「起動」でパブリック IP が変わってしまいます。

しかも ELB などを経由せずに直接 Route53 などで名前解決の設定をしている場合は接続できなくなるので Route53 の再設定も必要になります。

インスタンスタイプのファミリーを変更してスペックアップできない場合がある

例えば t2.micro からメモリの搭載が多い他のインスタンスタイプのファミリーに変更したくなることがあります。

しかしインスタンスタイプのファミリーを変更できることもあればできないこともあります。

実際に計画を立てて、いざインスタンスタイプのファミリーを変えようとしたらエラーが出たり、変更できたけど EC2 インスタンスが起動しない、EC2 インスタンスは起動しているけどログインできないなどの現象が発生することがあります。

事前にインスタンスタイプのファミリーを変更できるのか検証するなどの対応が必要になります。

I/O に問題があるからインスタンスタイプをアップグレードする？

いまだに EC2 インスタンスに DB を載せて運用している企業は多々あります。

そこそこの企業でも Aurora Serverless で運用しているケースは多くないです。

オンプレ（もしくは VMware）からEC2にマイグレーションしてそのまま使っているケースは多いです。

DB を運用していると「I/O にボトルネックがありそうだからインスタンスタイプを上げてよ」と言われることがあります。

しかし EBS の場合は「オンライン」で「ボリュームタイプ」を gp2 から gp3 や io1、io2 に変更することが出来ます。

2022年11月現在、io2 は最新のボリュームタイプですが、IOPS も細かく設定できます。

しかも IOPS を上げるだけでなく下げることも出来ます。（ここ重要です）

ボリュームのサイズは一度上げたら下げられませんが、IOPS は下げることもできます。（簡単です）

なので、DB を運用していて I/O に問題がありそうならボリュームタイプの変更を提案しましょう。

S3

S3 のトラブルは主にポリシー関連になります。

バケットポリシーを編集する際は root になれる管理者と一緒に作業すると良い

S3 にバケットポリシーを細かく設定するとセキュリティは向上します。

しかしバケットポリシーを細かく設定しすぎて Admin 権限を持っている自分自身さえアクセスできなくなってしまうことがあります。（どんなに気を付けてもヒューマンエラーはなくせない）

そんな時に root 権限を持っている更に上の管理者（情シスとか上司とか外部のベンダーとか）にログインして設定を変更してもらう必要が出てきます。

しかしそんなに都合よく root の管理者は捕まりません。（半日くらいかかったりそもそも連絡がつかなかったり誰なのか分からなかったり…）

本番環境の場合だと完全にサービスが止まりますよね。

しかも来週の月曜日までお待ちくださいとか言われたら悪夢です。

そのためバケットポリシーをいじる時はまず第一に root 管理者（root になれる人）は誰なのか確認しておくことが必要です。

本番環境の場合は検証環境で検証するのはもちろんのこと、本番環境の作業中も常に連携を取って待機をしてもらうくらい気を使って作業をした方がいいです。

RDS

RDS も様々なトラップがあります。しかも RDS は EC2 と比べると高額になりやすいため注意が必要です。

RDS を停止しても 7日後に勝手に起動する

RDS を停止しても 7日後に勝手に起動すると記載しましたが、何か不具合があるわけではありません（笑）

私も昔、検証やテストで使った RDS を削除せずに停止していたところ、後ほど RDS が起動しているのを見てビックリしたことがあります（笑）

この業界では有名なトラップですね。

ただし、AWS 側の言い分（？）は以下となっています。

この説明を読んで「だったら RDS インスタンスを起動する際に時間をかけてメンテナンスをしてから起動すればいいじゃん。それで RDS の起動に30分くらいかかっても気にしないよ。それよりも勝手に RDS が起動してコストが掛かる方が嫌なんだよ！」と思いました。

この7日間問題に対応するには Lambda 関数を作成してスケジューリングして定期的に RDS を起動停止をすればいいようです。

SES

SES（Simple Email Service）について記載します。

SES で SMTP 認証を利用する場合は IAM ユーザーが作成されアクセスキーが発行されるので注意

SES のダッシュボードで SMTP 認証用のアカウントとパスワードを発行して、そのアカウントとパスワードを利用して SES からメールを配信することが出来ます。

ここで注意点ですが SMTP 認証用のアカウントとパスワードを発行すると同時に IAM ユーザーも作成され、アカウントキーとシークレットアクセスキーも発行されます。

問題となりそうなのが、「IAM ユーザーは作成してはいけない。スイッチロールのみ認める。例外は絶対に認めない」というガチガチのルールで運用されている場合です。それと「アクセスキーとシークレットアクセスキーの発行は絶対に認めない。発行したら自動的に削除する」というルールだったり、多少ゆるく「アクセスキーとシークレットアクセスキーの発行は認めるがその代わり30日ごとに再発行してローテートしなければいけない」などの場合です。

例外なしで厳密に守らなければいけない場合に何が問題になるかというと、自動的に IAM ユーザーを削除されたり、自動的にアクセスキーとシークレットアクセスキーを無効化されると今まで送信できていたメールが突然エラーになります。

その為最初にアクセスキーとシークレットアクセスキーの運用を確認してから SES を採用するのかどうかを決めるのがいいでしょう。

ドメインを管理している DNS サーバのレコードを変更できるかどうか？

例えば、tama-chan.com というドメインを所有しているとします。

DNS サーバは「お名前.com」だったとして、インフラメンバーの自分たちで「お名前.com」にログインして DNS レコードを修正・変更できるでしょうか？

もし「できない」、もしくは「申請して別の部署の情シスの人に作業してもらう」という場合は、障害時に苦労するかもしれません。

障害は夜間・土日に発生することが多いです。

その際にすぐに別の部署の情シスのメンバーを捕まえて作業してもらうことが出来るのか？ある程度の企業になると上長の承認などが必要になってきてすぐにはできないと思います。

そこら辺のリスクも計算して要件定義・設計する必要があります。

運用が難しそうなら SES を諦めるのがベストプラクティスです。

無理やり SES を使って現場のエンジニアが無駄に辛い思いをする必要はありません。

Return-Pathを設定したいか？MX レコードが既に別サービスで使われているか？

例えば、既にドメイン「tama-chan.com」で、AWS ではなく他の業者（例：Pochi株式会社）のメールサービスを利用しているとします。

例えば、nslookup コマンドで tama-chan.com の MX レコードを引くと「mail.pochi.com」が返ってくるとします。（Pochi株式会社のメールサーバ mail.pochi.comがメールを処理している）

あらたに SES で「tama-chan.com」ドメインを利用して「test01@tama-chan.com」でメールを送信することはできます。

Return-Path の設定を何もしなければデフォルトの Return-Path（xxxx@ap-northeast-1.amazonses.com）になります。（これはこれで仕様なので何も問題はありません）

しかし事情を知らない（ITやメールの仕様、AWSの仕様などを知らない）偉い人が突然割って入ってきて「え？Return-Pathがamazonses.comになるの？それはおかしいでしょ？tama-chan.comでメールを送信するならReturn-Pathもtama-chan.comにしなきゃいけないよね？」と発言することがよくあります。

というか、現場のエンジニアはそこまで計算しておく必要があります。

結論から言えば、すでに他の業者で MX レコードを使って「xxx@tama-chan.com」でメールを送信している場合は SES での「xxxx@tama-chan.com」での Return-Path を「tama-chan.com」にすることはできません。

「MX レコードを複数にすればできるのでは？」負荷分散や冗長構成にするために複数のレコードを登録することはできますが、異なるベンダーではできません。

そこらへんも考慮に入れて要件定義や設計をする必要があります。