📝

僕のAWSやらかし全集

2021/07/09に公開

そろそろAWS歴が2年になりそうなので、記念に(?)書いておこうかと思いました。
今回は思い出せる範囲でレベル1～5まで書いてみました。
早速見てみましょう！

レベル1 MFAの移行を忘れる

スマホを修理に出したときに、MFAを設定しているアプリで引継ぎを忘れており、修理から戻ってきたときにMFAをかけたIAMユーザーやアカウントにログインできなくなってしまいました。
とりあえず、公式QAを見て、サポートに連絡し、電話でのやり取りで解決しました。

MFAも引継ぎが必要だということを学びました。

レベル2 IAMユーザーを各アカウントに作成

マルチアカウント運用する中で、各アカウントのリソースをCLIから操作したいと思い、各アカウントにIAMユーザーを作成し、認証情報をaws configureで切り替えていました。
・・・
何故こんなことをしたかって？
「ふ・・・CLIでもスイッチロールができることを知らなかったからさ・・・」

ごめんなさい、ちゃんとドキュメントにも記載がありました。
IAM ロールの切り替え (AWS CLI)

そしてAWS CLIでのスイッチロールという記事で、実際に設定方法も残しましたので、参考になれば幸いです。

IAMユーザーは増えれば増えるほど認証情報漏洩のリスクも増すので、少ないほうが良いということ、CLIでもスイッチロールができることを学びました。

レベル3 日常的にルートユーザーを使用

強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、root ユーザーを使用しないことです。
AWS アカウントのルートユーザー

AWSを何も知らなかった僕は、2か月ほどルートユーザーで作業していました。
AWSの勉強を始めてからようやくIAMユーザーを使うべきだと知り、以降はIAMユーザーやIAMロールでのスイッチロールに切り替えました。

ルートアカウントは神様の権限なので、普段は使わないということを学びました。

レベル4 請求額が・・・

よくある請求額が多かったシリーズ(?)です。
僕の場合はリソースの消し忘れと設定時の選択ミスです。

リソースの消し忘れ
VPCエンドポイント(インターフェイス型)の検証後に放置していたら10USDを超えてアラートが来ました
設定時に選択ミス
RDS作成時のインスタンスクラス選択で、t2.microを選択したつもりがt2.xlargeを選択しており、アラームに捕捉されました。

請求アラームは10USDでかけていたので、1,000円ちょっと超えた段階ですべて気づきました。
予期せぬ請求額増加に気づくための、請求アラームの重要性を学びました。

請求アラームの作成手順については
CloudWatchで請求アラームを作成する
にまとめたので、気になる方はご覧ください。

レベル5 Elastic Beanstalk環境を破壊

この辺になると、「やらかしたあああ！！！」ってかんじです(笑)
何したかをご説明しましょう！
「あー、テスト環境のリソース色々作りすぎてごちゃごちゃしてきたから掃除するかあ」
「CloudFormationスタックもなんかいっぱいあんなあ」
「これはいらない、これもいらない、これもなんか削除保護ついてたけどいらない！」
「Elastic Beanstalkは消さなくていいからそのままでOK！・・・ん？」
「あれ？EBの環境が削除中になってる！？なぜに？？？」
「もしやさっきのCloudFormationスタックって・・・。や・ら・か・し・た☆」

はい、やらかしました！
まさかCloudFormationスタックとEB環境がつながっているとは思わずやってしまいました。
CloudFormationスタックの削除は止められないし、どうすりゃいいかわからないままEB環境は墓地に送られました・・・。

しかしここで
「死者蘇生！！」
と言わんばかりの「環境の再構築」という文字を発見しました！

念のためドキュメントを読みます。

Elastic Beanstalk の機能を使用せずに環境内の AWS リソースを変更または終了すると、その AWS Elastic Beanstalk 環境は使用できない状態になる可能性があります。その場合は、環境を再構築して、動作状態になるよう復元を試みることができます。環境を再構築すると、すべてのリソースが終了し、同じ設定の新しいリソースに置き換えられます。
また、6 週間 (42 日) 以内であれば、終了した環境を再構築できます。再構築の際、Elastic Beanstalk は同じ名前、ID、および設定で新しい環境の作成を試みます。
Elastic Beanstalk 環境の再構築

大丈夫そうなので、「環境の再構築」をポチりました。
僕「・・・」
EB「エラーだよ(ニコッ」
僕「・・・」
CloudFormation「エラーだよ(ニコッ」
僕「な・ぜ・に？」

CloudFormationのエラーを見たところ、どうやらセキュリティグループの依存関係でエラーが起きているようでした。再構築の際、一度既存のグループを削除するようなのですが、削除対象のグループが他のセキュリティグループから参照されており、それが原因で削除に失敗していました。
なので、参照元のセキュリティグループの設定で削除対象のグループの参照を削除して、再度再構築を試みたところ、無事環境が復活しました！

テスト環境とはいえ、やらかしました。
Elastic BeanstalkはCloudFormationで作成されているということ、削除保護やIAMポリシーでの削除拒否権限などが重要であることを学びました。

まとめ

いかがでしたか？
エラーにハマるのは日常茶飯事ですが、破壊レベルの「やらかし」はマジで焦りますね(苦笑)
AWSにはやらかさないように「ガードレール」という考え方があります。
先日のBuilders Online Seriesで、シニアエバンジェリストの亀田さんもおっしゃっていましたが、「ビルダーが全力で走れるよう、走る場所を最初に決めておく」ということですね。
開発者などのユーザーに「これはやっちゃダメ！」ってことを管理者が最初に設定しておき、対象リソースの削除や変更をできないようにします。そうすればユーザーは決められた範囲でリソースに触ることができるので、盛大なやらかしのリスクを減らすことができます。大切な考え方ですよね。

最後に、これまでのやらかしを振り返り、「ガードレール」の考え方が重要だと学びました。
どなたかの参考になれば幸いです。