意外なコトでAWSにIAMでログインできなくなった話

最終更新日:2026/08/08 公開日:2026/05/01

はじめに

ある日突然、AWSで動作させていた社内ツールの監視がアラートを上げました。 HTTPS/SSH でサーバーが反応しなかったため、調査のためにAWSマネジメントコンソールにログインしようとしたところ、いつも使っているIAMユーザーで何度試してもログインできない状態に。

「AWSアカウントが乗っ取られて、IAM情報に変更を加えられたのでは…？」

一瞬そんな最悪のシナリオが頭をよぎりましたが、さらに調べていくと原因はまったく別のところにありました。数か月にわたってAWS利用料が正常に支払われておらず、アカウント内のサービスが停止してしまっていたのです。

この記事では、実際に体験した「支払い未完了によるAWSアカウント停止」の経緯と、そこから得た教訓をまとめます。

何が起きたのか

サービスが突然ダウンした

ある日、社内で利用していたAWS上のサービスが応答しなくなりました。特にデプロイや設定変更をした覚えはありません。インフラ側で何かが起きたと考え、AWSマネジメントコンソールにアクセスして調査を始めようとしました。

IAMユーザーでログインできない

いつも通りIAMユーザーの認証情報でログインを試みたところ、正常にログインができず、認証情報が誤っているというメッセージだけが表示されました。

Authentication failed：認証情報が正しくありません。もう一度試してください。

パスワードを間違えたわけでもなく、IAMユーザーとしての認証そのものが拒否されている状態でした。

この時点で、誰かに AWS アカウントを乗っ取られて IAM ユーザーが削除されてしまったのではと頭によぎりました。もしそうだとすると大きなセキュリティインシデントであり、正直なところかなり焦りました。

問題の原因：クレジットカードの変更に伴う支払い停止

追加で調査を行い、ルートアカウントに登録されているメールを確認したところ、支払いが行われていないという内容のメールが来ていることが確認でき、本件の問題の原因が確定しました。

AWSに登録していたクレジットカードが不正利用の検知に伴うカード会社側の措置で利用停止・番号変更になっており、こちらの変更対応が漏れていました。その結果AWSへの支払いが失敗し、それが数か月続いた結果、アカウントの内部リソースが停止されることになりました。

対応と復旧

ルートアカウントでのログインが必須

アカウントが停止された状態では、IAMユーザーではコンソールにアクセスできません。支払いの確認や決済情報の更新は、ルートアカウントでログインして行う必要があります。

つまり、普段IAMユーザーだけで作業している一開発者では、この問題を単独で解決することができません。ルートアカウントの認証情報を管理している担当者（多くの場合、管理部門やアカウント管理者）に連絡を取る必要があります。

サービスの自動復旧

ルートアカウントでログイン後、Billing and Cost Managementコンソールの「支払い」ページから、未払い分の請求書を確認しました。新しいクレジットカード情報を登録し、未払い分を支払いました。

支払いが完了すると、停止していたサービスは自動的に復旧しました。IAMでもログインができ、EC2インスタンスなどのリソースの状態は保持されており、手動で再起動やリストアをする必要はありませんでした。

今回のケースでは、クレジットカードでの支払い完了後数分～十数分程度で再アクティブ化されました。

この経験から得た教訓

1. IAMでログインできない＝乗っ取りとは限らない

IAMユーザーでログインできなくなった場合、セキュリティインシデントを真っ先に疑うのは自然な反応です。しかし、支払い未完了によるアカウント停止という、まったく別の原因でも同じ症状が発生します。もしここでログイン時のエラーメッセージが変わっていれば分かりやすくて助かるのですが、通常のログイン失敗時と同じメッセージしか出てこないので、この点は注意が必要です。

「IAMでログインできない」場面に遭遇したら、乗っ取りの可能性と並行して、支払い状況の確認も実施してください。これは知っていないとなかなか思い当たらないので、今後のメッセージが改善される可能性がありますが、知識の１つとして身につけておくと万が一の時に対応時間を大幅に短縮できる可能性があります。

2. ルートアカウントの管理体制を整えておく

IAMに権限を与えてできることが増え、ルートアカウントを使う機会は激減しているとは思いますが、万が一の時にはルートアカウントを利用する必要があります。支払い関連の問題が起きた場合、対応できるのはルートアカウントだけです。以下の点を事前に確認しておくことをおすすめします。

ルートアカウントの認証情報（メールアドレス・パスワード）を誰が管理しているか
ルートアカウントのMFA設定はどうなっているか
緊急時にルートアカウントへアクセスできる手順が共有されているか

普段の運用ではルートアカウントの使用を避けるのがベストプラクティスですが、「いざというとき確実にアクセスできる」状態にしておくことが重要です。

3. 支払い失敗の通知メールを見逃さない仕組みを作る

AWSは支払いに失敗した際にメールで通知を送ってくれます。しかし、その宛先はルートアカウントのメールアドレスです。

ここで厄介なのが、AWSのセキュリティベストプラクティスに従ってルートアカウントの使用を最小限にするほど、ルートアカウント宛のメールを日常的に確認する機会が減るという点です。セキュリティ上正しい運用をしているがゆえに、支払い関連の通知が埋もれやすくなるという構造的な矛盾があります。

また、弊社では本番環境のAWSアカウントには請求代行サービスを利用しており、支払い周りの管理が仕組み化されていました。しかし、今回問題が発生したのは社内ツール用に独自管理していた例外的なアカウントでした。こうした「メインの運用フローから外れたアカウント」こそ、支払いトラブルの盲点になりやすいと感じています。

対策としては以下のようなものが考えられます。