不正利用と高額請求から AWS アカウントを守る、まずできる5つの対策

アクセスキーが漏れると、第三者がそのキーで高額なリソースを使い、気づいたときには多額の請求が発生していることがあります。請求書や AWS からの通知を待つだけでは、気づくまでに時間がかかります。
漏れた認証情報で生成 AI のモデルを使う攻撃が増えていると、AWS は2026年7月のブログで述べました（AWS Security Blog（英語））。Amazon EC2 と Amazon ECS を狙う暗号資産の採掘の攻撃は、2025年11月から続いています。侵入から10分以内に採掘が動き始めた例も報告されました（AWS Security Blog（英語））。

本記事では、AWS アカウントを運用する上でまず取るべき5つの対策を紹介します。画面や仕様は更新されるため、各項目の設定手順は載せず、AWS 公式ドキュメントへのリンクを添えます。設定の前に確認すべき点と、公式の記述から分かったこともまとめます。
本記事は、2026年10月時点の AWS のドキュメントに基づいています。料金は米国東部（バージニア北部）リージョンの例で、リージョンと利用量によって異なります。

注意：AWS マネジメントコンソールなどの情報は常に更新されるため、設定の前に、各項目のリンク先で最新の情報を確認してください。

クラウドのセキュリティに、不安や課題を感じている方はこちら

KDDIアイレットなら、現状の課題整理からセキュリティ対策の導入、監視・運用までしっかり伴走支援します。

サービスの概要を見るお問い合わせ

前提条件

• KDDIアイレットが提供する cloudpack の AWS 請求代行サービスをご利用で、運用保守はご自身で行なっているお客様に向けた内容です。
• 設定する AWS アカウントに、管理者の権限を持つ AWS Identity and Access Management（以降は IAM）ユーザーかロールでサインインできること
• 単独のアカウントでも、AWS Organizations に属するアカウント（メンバーアカウント）でも、まずはそのアカウント内で設定できるものに絞りました。サービスコントロールポリシー（SCP）のような、組織単位で設定するものは本記事で扱いません。

不正利用に備えて、まず取るべき対策

不正利用の被害を抑えるには、予防と検知に加えて、事後に調べるための備えが要ります。本記事では、次の表の5つの対策を、設定作業で権限エラーが起きないよう進めやすい順に並べました。まずは、この5つの対策に取り組んでください。事故が起きた後の対応は状況によって異なるため、本記事では扱いません。

IAM のセキュリティのベストプラクティスは、システムには IAM ロールを使うよう勧めています（IAM でのセキュリティのベストプラクティス）。既存のシステムをロールに移すには改修が要るため、本記事の項目は、移行の前でも入れられる設定にしました。

項目1：使っていない IAM ユーザーを棚卸しし、MFA を付ける

最初に、使っていない IAM ユーザーとアクセスキーを棚卸しします。そのあと、残ったユーザーに MFA を付けます。

棚卸し

使っていない IAM ユーザーのアクセスキーは、削除するか、無効にしてください。
公式の手順：使用していない AWS 認証情報の検索

次の4点を確認・実施してください。

• IAM コンソールの（Users）の一覧で見る（Access key last used）の列は、最後に使った日ではなく、最後に使ってからの日数です。列が表示されていないときは、設定アイコンから追加します。
• アカウント全体を一覧にするなら、認証情報レポートを使います。レポートは4時間に1回まで作れます。載るのは、ユーザーごとに最初の2つのアクセスキーまでです。Amazon Bedrock の長期 API キーは載らないため、Amazon Bedrock コンソールで別に確認します（認証情報レポートの生成）。
• アクセスキーを削除すると、元に戻せません。まず無効にし、システムに影響が無いことを確かめてから削除します（IAM 管理者が IAM ユーザーアクセスキーを管理する方法）。
• 本記事では「90日以上使われていないアクセスキー」を止める候補として扱います（AWS Security Hub CSPM の IAM.8 に準拠）。ただし、年に数回しか動かないバッチのように、使う頻度の低いキーもあります。止める前に、キーの持ち主と用途を確かめてください。

あわせて、管理者の権限を付けた IAM ユーザーを洗い出し、必要な権限に絞ってください。

MFA

棚卸しのあと、残ったユーザーには MFA を付けます。多要素認証（MFA）は、パスワードに加えて、認証アプリの6桁のコードや物理的なセキュリティキーを組み合わせて本人確認を行なう仕組みです。パスワードが漏れたときに、管理コンソールへ不正にサインインされるリスクを下げられます。AWS は、可能ならパスキーかセキュリティキーを使うよう勧めています。
公式の手順：AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる

注：MFA は管理コンソールのサインインに効きますが、有効にしただけではアクセスキーで署名した API の呼び出しには効きません（MFA を使用した安全な API アクセス）。アクセスキーは漏えい時のリスクが大きいため、棚卸しで不要なものを削除した上で、IAM ロールや OIDC 連携への移行を検討してください。

項目2：Amazon GuardDuty を有効にする

Amazon GuardDuty は、AWS CloudTrail の管理イベント、VPC フローログ、DNS のログを分析し、アカウントの中の不審な操作を検知します。漏れたキーが使われたこと自体に、早く気づける可能性があります。まず、基本の検知を有効にしてください。
公式の手順：GuardDuty の開始方法

設定の前に、次の3点を確認してください。

• Amazon GuardDuty はリージョンごとのサービスです。AWS は、使っていないリージョンも含め、アカウント内で有効になっているすべてのリージョン（標準で有効な全リージョン）で Amazon GuardDuty を有効にするよう強く勧めています。有効にしていないリージョンがあると、IAM などのグローバルサービスの操作を検知する力も下がります。
• AWS 公式では初回有効化時に30日間の無料トライアルが案内されていますが、弊社の請求代行サービスをご利用のアカウントでは無料トライアルは適用されず、有効化時点から従量課金となります。また、有効化時には Amazon S3・Amazon EKS・Amazon RDS・AWS Lambda の保護など一部の保護プランも既定で有効になり課金対象となります。使っているサービスに合わせた保護プランの利用を検討してください。
• 検出結果をメールで受け取るには、Amazon EventBridge のルールで結果を Amazon SNS のトピックに送ります（Amazon EventBridge を使用した GuardDuty 検出結果の処理）。

項目3：AWS Budgets で請求の急増を知らせる

Amazon GuardDuty で気づけなかったときに備えて、AWS Budgets で請求の急増を知らせます。AWS Budgets は、実績または予測の費用がしきい値を超えたときに、メールなどで通知します。予算の監視と通知に料金はかかりません。
公式の手順：コスト予算の作成

• 実際の利用額による通知を、しきい値を変えて複数設定します。
• 予測による通知も設定することで、実際の費用がしきい値に達する前に気づきやすくなります。ただし、一定期間の利用データが溜まるまでは通知されません。

設定の前に、次の3点を確認してください。

• 通知先のメールアドレスは、届いた確認のメールで承認するまで、通知を受け取れません。
• AWS Budgets の情報の更新は、1日最大3回です。通常は、前回の更新から8〜12時間後に更新されます（AWS Budgets によるコストの管理）。
• 予算の金額は、直近3か月で最も大きい月の利用額（AWS マネジメントコンソール上の USD 換算額）を目安にします。この金額は、本記事で決めた目安です。

注：通知が届くまでに、しきい値を超えて請求が増えることがあります。AWS Budgets は、即時に気づくための手段ではありません。早く気づくための検知は、項目2 の Amazon GuardDuty で行います。

項目4：AWS CloudTrail の証跡を作る

CloudTrail のイベント履歴では、証跡が無くても、過去90日分の管理イベントを検索できます。90日より前の操作は、証跡かイベントデータストアに記録を残して調べます。キーが漏れてから発覚するまでに90日以上かかることもあります。証跡は作った時点からしか記録しないため、事故が起きてからでは過去の分を取り戻せません。前もって証跡を作り、90日より長く記録を残しておきます。
公式の手順：CloudTrail コンソールで証跡を作成する

設定の前に、次の3点を確認してください。

• コンソールで作った証跡は、有効なすべてのリージョンのイベントを記録します。
• ログファイルの SSE-KMS 暗号化は、コンソールの既定で有効です。有効のままにすると、AWS KMS の料金がかかります（AWS CloudTrail のよくある質問）。
• 管理イベントを Amazon S3 に送る最初の1コピーは無料です。Amazon S3 の保存料は別にかかります。データイベントには追加料金がかかります（AWS CloudTrail の料金）。

項目5：使わないリージョンやサービスを IAM ポリシーで制限する

最後に、使わないリージョンやサービスを IAM ポリシーの Deny で使えないようにします。アクセスキーが漏れて第三者に使われても、被害を許可したリージョンの中に抑えやすくなるためです。
IAM ユーザーは IAM グループにまとめ、グループにポリシーを付けます。ユーザーごとに付けるより、設定の手間が減ります。本記事では例として、使わないリージョンの止め方を紹介します。
公式の例：リクエストされたリージョンに基づいて、AWS へのアクセスを拒否する

設定の前に、次の3点を確認してください。

• 利用中のリージョンとサービスを確認してください。使っているものを止めると、システムが動かなくなることがあります。影響範囲を確認してから設定してください。
• リージョンのほかに、サービスも制限できます。たとえば、生成 AI のサービスである Amazon Bedrock を使っていなければ、Amazon Bedrock の利用を拒否することで、Amazon Bedrock 不正利用による高額請求を防げる可能性があります。
• リージョン制限のポリシーを先に適用すると、制限したリージョンでの Amazon GuardDuty の有効化（項目2）や、米国東部リージョンで動作する AWS Budgets の設定（項目3）が権限エラーで行えなくなる場合があります。項目2〜4の設定を済ませた後に適用し、適用後もそれらの画面確認や設定変更を行う場合は、公式サンプルの除外リスト（NotAction）に「guardduty:*」や「budgets:*」を追加してください。

コストの考慮事項

本記事の設定で料金がかかるのは、Amazon GuardDuty と、AWS CloudTrail のログを保存する Amazon S3（および SSE-KMS を使う場合の AWS KMS）です。なお、弊社の請求代行サービスでは AWS 無料利用枠・無料トライアルは適用されません。

最新の料金は、Amazon GuardDuty・AWS CloudTrail・AWS Budgets の料金ページで確認してください。

まとめ

万が一の不正利用や高額請求を防ぐためにも、5つの対策から設定を確認してみてください。
始めるときは、次の順に進めてください。

1. 使っていない IAM ユーザーとアクセスキーを棚卸しし、残ったユーザーに MFA を付けます（項目1）
2. Amazon GuardDuty を有効にします（項目2）
3. Amazon GuardDuty で気づけなかったときに備えて、AWS Budgets で請求の急増を知らせます（項目3）
4. AWS CloudTrail の証跡を作り、後から調べられるようにします（項目4）
5. 使わないリージョンやサービスを、影響範囲を確認したうえで IAM ポリシーで制限します（項目5）

ご利用の AWS アカウントで、まず項目1から項目5までを、各項目の公式ドキュメントで確かめながら試してみてください。

使い終わったアカウントをそのままにしていませんか？

検証や過去のプロジェクトで使い終わり、そのまま放置しているアカウントはありませんか。持ち主が存在を把握していないアカウントは、キーが漏れても確かめる人がいません。整理して、不要なアカウントは解約（閉鎖）の手続きを進めてください。