はじめに

皆様こんにちは、あかいけです。

AWSサポートのコンソールを開いたところ、アクセス許可の更新を促すバナーが表示されていました。

期限が書かれているので放置はできませんが、バナーを読んだだけでは何をどこまで直せばよいのかがわかりませんでした…。

というわけで今回は何が変わるのかを確認した上で、対応方法をまとめます。

バナーの内容

バナーの内容はざっくり以下の2点です。

• 2026年11月16日より、AWSサポートはよりきめ細かな許可でアクセス制御を強化する
• 対応方法は以下2通りある
  • AWSSupportAccessマネージドポリシーをアタッチする
  • support-console:*を許可するカスタムポリシーを用意する

また以下ドキュメントでも、期限までにポリシーを用意しない場合はAccessDeniedになる、と書かれているので何らかの対応が必要そうです。

2026 年 11 月 16 日より前に、サポートセンターコンソール API オペレーションの AWS Identity and Access Management ポリシーを作成する必要があります。2026 年 11 月 16 日までにこれらのポリシーを作成しないと、AccessDeniedエラーが発生します。

https://docs.aws.amazon.com/ja_jp/awssupport/latest/user/support-console-access-control.html

何が変わる？

前述のsupport-consoleは、従来のsupportとは別のサービスプレフィックスです。
support-consoleはサポートセンターコンソール専用のアクションで、CLIやSDKからは呼び出せません。

ただドキュメントを読んでも何が変わるかよくわからなかったので、CloudTrailログにて権限がある場合とない場合で見比べてみます。

権限がないときのログ

ReadOnlyAccessのみを持つロールで、サポートセンターからケースのドラフトを作成しようとしたときのログです。
（以降のログはアカウントIDなどをマスクし、一部フィールドを省略しています）

{
    "eventTime": "2026-09-24T08:06:22Z",
    "eventSource": "support-console.amazonaws.com",
    "eventName": "CreateCaseDraft",
    "awsRegion": "us-east-1",
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_ReadOnlyAccess_xxxxxxxxxxxxxxxx/test-user"
    },
    "errorCode": "AccessDenied",
    "errorMessage": "User: arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_ReadOnlyAccess_xxxxxxxxxxxxxxxx/test-user is not authorized to perform: support:CreateCase because no identity-based policy allows the support:CreateCase action",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "tlsDetails": {
        "clientProvidedHostHeader": "api.us-east-1.prod.support-console.support.aws.dev"
    }
}

イベント名はCreateCaseDraft、イベントソースはsupport-console.amazonaws.comです。
ただしerrorMessageが指しているのはsupport-console:CreateCaseDraftではなく、従来からあるsupport:CreateCaseのほうです。

権限があるときのログ

次にsupport:*を許可するポリシーを権限セットに追加して、同じ操作をしてみます。

{
    "eventTime": "2026-09-24T08:13:32Z",
    "eventSource": "support-console.amazonaws.com",
    "eventName": "CreateCaseDraft",
    "awsRegion": "us-east-1",
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_ReadOnlyAccess_xxxxxxxxxxxxxxxx/test-user"
    },
    "additionalEventData": {
        "authZHeader": "User: arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_ReadOnlyAccess_xxxxxxxxxxxxxxxx/test-user is not authorized to perform: support-console:CreateCaseDraft because no identity-based policy allows the support-console:CreateCaseDraft action"
    },
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "tlsDetails": {
        "clientProvidedHostHeader": "api.us-east-1.prod.support-console.support.aws.dev"
    }
}

errorCodeが消えてリクエストは成功しています。
ただしadditionalEventData.authZHeaderに、「support-console:CreateCaseDraftが許可されていない」というメッセージが残っています。

つまり現時点での認可は従来のsupport:*で行われていて、support-console:*での評価結果はログに記録されるだけ、という状態のようです。
このことから2026年11月16日以降はこれらが実際の拒否に切り替わる、と推測できます。

また具体的に対象となる権限は、以下ドキュメントに記載の権限だと思われます。

https://docs.aws.amazon.com/ja_jp/awssupport/latest/user/support-console-access-control.html

対処方法

マネージドポリシーを使う

AWSSupportAccessをアタッチする方法です。

https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/AWSSupportAccess.html

現在のバージョン（v4）では、support:*とsupport-console:*の両方が許可されているので、これをアタッチするだけでOKです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "support:*",
        "support-console:*"
      ],
      "Resource": "*"
    }
  ]
}

カスタマー管理ポリシーを使う

「ケースの参照はさせたいけど、ケースの起票は許可したくない」、といった細かい制御をしたい場合はこちらです。
ドキュメントのオペレーション一覧にアクセスレベルが書かれているので、必要なものだけを選びましょう。

https://docs.aws.amazon.com/ja_jp/awssupport/latest/user/support-console-access-control.html

たとえば閲覧だけを許可する場合は以下のようになります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "support-console:GetAccountState",
        "support-console:GetAccountGovCloudEnabled",
        "support-console:GetCaseDraft",
        "support-console:GetBanner",
        "support-console:DescribeDynamicHelp",
        "support-console:CheckSubscription",
        "support-console:GetQuestionnaire"
      ],
      "Resource": "*"
    }
  ]
}

ただしカカスタマー管理ポリシーの場合は都度追従が必要（AWSがアクションを追加したときなど）になるので、細かい制御が要件でないなら、素直にマネージドポリシーを使うほうが楽だと思います。

具体的な権限付与のイメージ

ここではIAM Identity Centerの事前定義された権限セットで考えてみます。

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/permissionsetpredefined.html

ベースとなるAWS管理ポリシーがsupport-consoleを含んでいるかどうかが確認の観点で、結果は以下の通りでした。

AdministratorAccess

Actionが"*"なので、AWSがあとから追加した名前空間もそのまま含まれます。
そのため対応は不要です。

https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/AdministratorAccess.html

PowerUserAccess

NotActionでiam:*・organizations:*・account:*だけを除外する方式です。
こちらも許可するアクションを列挙していないため、support-console:*は自動的に含まれます。
そのため対応は不要です。

https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/PowerUserAccess.html

ReadOnlyAccess

サポート関連で持っている権限はsupport:Describe*とsupport:SearchForCasesだけで、support-consoleは含まれていません。
そのため対応が必要です。

https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/ReadOnlyAccess.html

なおReadOnlyAccessはケース起票するための権限は含まれていませんが、AWSSupportAccessをアタッチするとsupport:*が付与され、ケース起票もできるようになります。
そのため参照専用の権限セットとして扱っている場合は、設計に沿った権限になるかは確認しておくとよさそうです。

ViewOnlyAccess

こちらはサポート関連のアクションを1つも持っていないため、ReadOnlyAccessと同じく対応が必要です。

https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/ViewOnlyAccess.html

さいごに

以上、AWSサポートのよりきめ細かな許可を使ったアクセス制御へ対応してみました。

対応自体は AWSSupportAccessをアタッチ or カスタマー管理ポリシーを作成してアタッチ するだけですが、現状との差分を把握するのに時間がかかりました。
CloudTrailのログを見比べるのが一番わかりやすく、support:*で認可されつつsupport-console:*の評価結果は記録されるだけ、という移行中の状態が確認できました。

同じようにAWS サポートのバナーの内容を確認している方の助けになれば幸いです。