みなさん、こんにちは。AWS CLI が好きなテクニカルサポート課の市野です。
現地時間の 2026年6月15日、16日 と立て続けにアップデートがありました。これにより AWS マネジメントコンソールへよりセキュアなアクセスが行えるようになりました。
今日はそれらの機能を検証し注意点などがないか確認します。
なお、CLI での手順が多めなので、コード部分は折りたたんでいますので適宜ご参照ください。
アップデート概要
- 2026/6/15 発表
- AWS Management Console Private Access によりインターネット接続なしで VPC からコンソール利用が可能に(
console-staticエンドポイント追加)
- AWS Management Console Private Access によりインターネット接続なしで VPC からコンソール利用が可能に(
- 2026/6/16 発表
- コンソールサインインをネットワークや認証 ID を条件にリソースベースでの制御が行えるようになった
これらを組み合わせることで「許可されたネットワークからのみ、許可されたアカウントのコンソールにインターネット不要でアクセス」という構成が実現しやすくなりました。
公式発表
やってみる
0. 事前準備:変数定義
export AWS_REGION="ap-northeast-1" export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export VPC_CIDR="172.16.0.0/16" export SUBNET1_CIDR="172.16.1.0/24" export SUBNET2_CIDR="172.16.2.0/24" export KEY_PAIR_NAME="console-vpce-test-key" export ALLOWED_CIDR="211.7.97.203/32" # Sign-In ポリシーで許可する IP 範囲
1. AWS Management Console Private Access の検証
1-1. VPC・サブネット作成
- インターネットゲートウェイ・NAT ゲートウェイを付与しない VPC を作成する
- プライベートサブネットを 2 AZ に配置する
クリックで詳細が表示されます。
# VPC
VPC_ID=$(aws ec2 create-vpc \
--cidr-block $VPC_CIDR \
--query 'Vpc.VpcId' --output text)
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-support '{"Value":true}'
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-hostnames '{"Value":true}'
aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=ConsolePrivateAccess-VPC
# AZ 取得
AZ1=$(aws ec2 describe-availability-zones --query 'AvailabilityZones[0].ZoneName' --output text)
AZ2=$(aws ec2 describe-availability-zones --query 'AvailabilityZones[1].ZoneName' --output text)
# サブネット
SUBNET1_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block $SUBNET1_CIDR \
--availability-zone $AZ1 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=ConsolePrivateAccess-Subnet1}]' \
--query 'Subnet.SubnetId' --output text)
SUBNET2_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block $SUBNET2_CIDR \
--availability-zone $AZ2 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=ConsolePrivateAccess-Subnet2}]' \
--query 'Subnet.SubnetId' --output text)
# ルートテーブル(IGW/NAT なし)
RT_ID=$(aws ec2 create-route-table \
--vpc-id $VPC_ID \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=ConsolePrivateAccess-RT}]' \
--query 'RouteTable.RouteTableId' --output text)
aws ec2 associate-route-table --route-table-id $RT_ID --subnet-id $SUBNET1_ID
aws ec2 associate-route-table --route-table-id $RT_ID --subnet-id $SUBNET2_ID
1-2. セキュリティグループ
- VPC エンドポイント用: VPC CIDR からの TCP 443 を許可
- EC2 用: VPC CIDR からの RDP (3389) を許可
クリックで詳細が表示されます。
# VPC エンドポイント用
VPCE_SG_ID=$(aws ec2 create-security-group \
--group-name vpce-sg \
--description "Allow TLS for VPC Endpoints" \
--vpc-id $VPC_ID \
--tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=ConsolePrivateAccess-VPCE-SG}]' \
--query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress \
--group-id $VPCE_SG_ID \
--protocol tcp --port 443 \
--cidr $VPC_CIDR
# EC2 用
EC2_SG_ID=$(aws ec2 create-security-group \
--group-name ec2-sg \
--description "EC2 Instance SG" \
--vpc-id $VPC_ID \
--tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=ConsolePrivateAccess-EC2-SG}]' \
--query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress \
--group-id $EC2_SG_ID \
--protocol tcp --port 3389 \
--cidr $VPC_CIDR
1-3. VPC エンドポイント作成
VPC エンドポイントを作成します。
これまでのセオリー通りプライベートサブネットに配置したインスタンスへ Fleet Manager 経由でアクセスするための SSM 系のエンドポイントを設置します。
加えて Console、Sign-In、Console Static のエンドポイントを構成します。
| エンドポイント | サービス名 | 用途 |
|---|---|---|
| Console | com.amazonaws.{region}.console |
コンソール本体 |
| Sign-In | com.amazonaws.{region}.signin |
認証 |
| Console Static | com.amazonaws.{region}.console-static |
静的コンテンツの取得 |
| SSM 系 | ssm, ssmmessages |
Fleet Manager で EC2 に接続するため |
クリックで詳細が表示されます。
# ポリシードキュメント作成
cat > /tmp/console-vpce-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": "${ACCOUNT_ID}",
"aws:SourceVpc": "${VPC_ID}"
}
}
}
]
}
EOF
cat > /tmp/signin-vpce-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "signin:Authenticate",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:ResourceAccount": "${ACCOUNT_ID}" }
}
},
{
"Effect": "Allow",
"Principal": "*",
"Action": ["signin:AuthorizeOAuth2Access", "signin:CreateOAuth2Token"],
"Resource": "*",
"Condition": {
"StringEquals": { "aws:PrincipalAccount": "${ACCOUNT_ID}" }
}
}
]
}
EOF
# Console エンドポイント
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.${AWS_REGION}.console \
--subnet-ids $SUBNET1_ID $SUBNET2_ID \
--security-group-ids $VPCE_SG_ID \
--private-dns-enabled \
--policy-document file:///tmp/console-vpce-policy.json \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ConsolePrivateAccess-Console}]'
# Sign-In エンドポイント
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.${AWS_REGION}.signin \
--subnet-ids $SUBNET1_ID $SUBNET2_ID \
--security-group-ids $VPCE_SG_ID \
--private-dns-enabled \
--policy-document file:///tmp/signin-vpce-policy.json \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ConsolePrivateAccess-SignIn}]'
# Console Static エンドポイント
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.${AWS_REGION}.console-static \
--subnet-ids $SUBNET1_ID $SUBNET2_ID \
--security-group-ids $VPCE_SG_ID \
--private-dns-enabled \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ConsolePrivateAccess-ConsoleStatic}]'
# SSM 系エンドポイント(Fleet Manager 接続用)
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.${AWS_REGION}.ssm \
--subnet-ids $SUBNET1_ID $SUBNET2_ID \
--security-group-ids $VPCE_SG_ID \
--private-dns-enabled \
--policy-document file:///tmp/console-vpce-policy.json \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ConsolePrivateAccess-ssm}]'
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.${AWS_REGION}.ssmmessages \
--subnet-ids $SUBNET1_ID $SUBNET2_ID \
--security-group-ids $VPCE_SG_ID \
--private-dns-enabled \
--policy-document file:///tmp/console-vpce-policy.json \
--tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=ConsolePrivateAccess-ssmmessages}]'
1-4. 検証用 IAM ユーザー作成
検証用の IAM ユーザーを作成します。
なお、機微な情報を公開していますが、すでに検証は終わっており AWS アカウントごと削除しています。
クリックで詳細が表示されます。
# 検証用 IAM ユーザー作成 aws iam create-user --user-name console-test-user # コンソールログイン用パスワード設定 aws iam create-login-profile \ --user-name console-test-user \ --password 'C0nsole#Test2026!Xz' \ --password-reset-required # 検証に必要な最低限の権限を付与(ReadOnly) aws iam attach-user-policy \ --user-name console-test-user \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess aws iam attach-user-policy \ --user-name console-test-user \ --policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword
1-5. IAM ロール・インスタンスプロファイル作成
セッションマネージャーでのアクセス要件を満たすためのポリシー付与を目的としてインスタンスプロファイルを作成します。
クリックで詳細が表示されます。
# EC2 用ロール
cat > /tmp/ec2-trust.json << EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}
EOF
aws iam create-role \
--role-name ConsoleVPCE-EC2Role \
--assume-role-policy-document file:///tmp/ec2-trust.json
aws iam attach-role-policy \
--role-name ConsoleVPCE-EC2Role \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam create-instance-profile --instance-profile-name ConsoleVPCE-EC2Profile
aws iam add-role-to-instance-profile \
--instance-profile-name ConsoleVPCE-EC2Profile \
--role-name ConsoleVPCE-EC2Role
1-6. EC2 インスタンス起動
前ステップで作成したインスタンスプロファイルを設定しつつ Windows Server 2022 を起動します。
Fleet Manager で接続したプライベートサブネット配下のインスタンスとし、これまでは AWS マネジメントコンソールへアクセスできなかったはずの環境を想定しています。
クリックで詳細が表示されます。
# Windows Server 2022 AMI 取得
AMI_ID=$(aws ssm get-parameter \
--name /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-Base \
--query 'Parameter.Value' --output text)
# キーペア作成(未作成の場合)
aws ec2 create-key-pair \
--key-name $KEY_PAIR_NAME \
--query 'KeyMaterial' --output text > ${KEY_PAIR_NAME}.pem
chmod 400 ${KEY_PAIR_NAME}.pem
# インスタンス起動
INSTANCE_ID=$(aws ec2 run-instances \
--image-id $AMI_ID \
--instance-type m5.large \
--subnet-id $SUBNET1_ID \
--security-group-ids $EC2_SG_ID \
--iam-instance-profile Name=ConsoleVPCE-EC2Profile \
--key-name $KEY_PAIR_NAME \
--block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=50}' \
--metadata-options HttpTokens=required \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Console-VPCE-Test}]' \
--query 'Instances[0].InstanceId' --output text)
1-7. 動作検証
SSM で管理対象になっていることを確認します。
クリックで詳細が表示されます。
# SSM で管理対象になっていることを確認 aws ssm describe-instance-information \ --filters Key=InstanceIds,Values=$INSTANCE_ID \ --query 'InstanceInformationList[0].PingStatus' --output text # "Online" と返ればOK
ここからは GUI で実施します。
Fleet Manager コンソールから該当のインスタンスに対して RDP 接続します。
ここまではプライベートサブネットに配置しインターネットと直接通信しないインスタンスへのアクセスを VPC エンドポイントを経由して行う従来通りの手法です。
RDP 接続できた先のインスタンスでは、キャプチャでの通り、インスタンス内のブラウザからは AWS 公式サイトへのアクセスができず、cmd.exe でも疎通できていない状況を確認できます。




なお、サインイン URL https://${ACCOUNT_ID}.signin.aws.amazon.com/console の形式ではアクセスできず、https://console.aws.amazon.com/ の URL にアクセスする必要がありましたので注意点となります。

ドキュメントによると IAM は AWS Management Console Private Access でサポートされるサービスに含まれていると理解できます。
それでも今回アクセスできなかったのは、以下に記載がある通り、リージョンごとに VPC エンドポイントが必要とされている点に起因すると考えられます。
AWS Management Console Private Access requires the following VPC endpoints per Region.
2. AWS Sign-in のリソースベースでの制御の検証
ここからがコンソールサインイン(Sign-In)のアップデート範囲となります。
以下の条件で試してみることにします。
- SourceIp が 211.7.97.203/32 からのアクセスの場合のみ許可(冒頭の事前定義の変数定義で定義済み)
- ただし IAM ユーザー console-test-user のみ、接続元ネットワークに依存せず許可し、緊急アクセスのための経路とする
なお AWS Sign-In は AWS マネジメントコンソール経由の GUI での設定実施や確認が行えません。そのため以降の説明では基本的に折り畳まず、AWS CLI の実行を記載します。
2-1. 影響を受けるユーザーの作成
影響を受けるユーザー(緊急用途ではないユーザー)として console-test-user-non-exclude を作成しておきます。
クリックで詳細が表示されます。
aws iam create-user --user-name console-test-user-non-exclude aws iam create-login-profile \ --user-name console-test-user-non-exclude \ --password 'C0nsole#Test2026!Xz' \ --password-reset-required aws iam attach-user-policy \ --user-name console-test-user-non-exclude \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess aws iam attach-user-policy \ --user-name console-test-user-non-exclude \ --policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword
2-2. 許可プリンシパル定義
ALLOWED_USER="arn:aws:iam::${ACCOUNT_ID}:user/console-test-user"
2-3. リソースのアクセス許可ステートメントの作成
--source-ip オプションを指定することで (aws:SourceIp =VPC 外からのアクセスが許可される IP アドレス)を設定します。加えて --excluded-principal オプションでポリシー評価から除外されるプリンシパル ARN を定義します。
aws signin put-resource-permission-statement \ --source-ip "$ALLOWED_CIDR" \ --excluded-principal "$ALLOWED_USER" \ --region us-east-1
実行後、以下のような応答が返れば正しく設定できています。
{ "statementId": "nxPSx7avngBdDz1JCMcyH/rVBbgmUR+gZ3TzRcCI0ylWxxOI+hw8pKdzUp61CuGq" }
2-4. コンソール認証設定の実施
今回は --target-id にアカウント ID を直接指定するため単一のアカウントに対してコンソール認証設定を有効にします。
--target-id には o-xxxxxxxxxx 形式の AWS Organizations 組織 ID を定義でき、組織を指定した場合には RCP として作用します。
なお、前項のリソースのアクセス許可ステートメントはいつでも作成が可能ですが、このステップのコンソール認証設定を有効化するまで適用されません。
また、書き込み系のアクションはすべて us-east-1(バージニア北部)リージョンに対して行う必要があり、設定された値がグローバルに複製される仕組みです。
aws signin put-console-authorization-configuration \ --target-id $ACCOUNT_ID \ --region us-east-1
実行後、以下のような応答が返れば正しく設定できています。
{ "targetId": "60634912XXXX", "scope": "ACCOUNT", "consoleAuthorizationEnabled": true }
Specify --region us-east-1 for all write operations on AWS Sign-In policies. AWS replicates policies globally from this Region. Read operations can target any Region.
2-5. コンソール認証設定 設定状況の確認
aws signin get-console-authorization-configuration \ --target-id $ACCOUNT_ID \ --region us-east-1
実行後、以下のような応答が返ります。
{ "targetId": "60634912XXXX", "scope": "ACCOUNT", "consoleAuthorizationEnabled": true }
2-6. 設定済みの権限ステートメントの確認
読み取り系のアクションとなるため、ap-northeast-1(東京リージョン)に対して実行してみます。
aws signin list-resource-permission-statements \ --region ap-northeast-1
以下のように返却され、us-east-1 に対して put-resource-permission-statement した内容がグローバルに伝播されていることが確認できます。
{ "permissionStatements": [ { "sid": "nxPSx7avngBdDz1JCMcyH/rVBbgmUR+gZ3TzRcCI0ylWxxOI+hw8pKdzUp61CuGq", "condition": { "ArnNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::60634912XXXX:user/console-test-user" ] }, "NotIpAddress": { "aws:SourceIp": [ "211.7.97.203/32" ] } } } ] }
2-6. 設定済みのポリシー全体の確認
読み取り系のアクションとなるため、ここでも ap-northeast-1(東京リージョン)に対して実行してみます。
aws signin get-resource-policy \ --region ap-northeast-1
以下のように返却され AWS Sign-In のリソースベースポリシーとして設定されているポリシードキュメントの全景を確認できます。
{ "signinResourceBasedPolicy": { "version": "2012-10-17", "statement": [ { "effect": "DENY", "principal": { "AWS": "*" }, "action": [ "signin:Authenticate" ], "resource": "*", "condition": { "ArnNotEquals": { "signin:PrincipalArn": [ "arn:aws:iam::60634912XXXX:user/console-test-user" ] }, "NotIpAddress": { "aws:SourceIp": [ "211.7.97.203/32" ] }, "StringEquals": { "aws:ResourceAccount": [ "60634912XXXX" ] } } }, { "effect": "DENY", "principal": { "AWS": "*" }, "action": [ "signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access" ], "resource": "*", "condition": { "ArnNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::60634912XXXX:user/console-test-user" ] }, "NotIpAddress": { "aws:SourceIp": [ "211.7.97.203/32" ] }, "StringEquals": { "aws:ResourceAccount": [ "60634912XXXX" ] } } } ] } }
2-7. 検証実行
許可された IP アドレス 211.7.97.203 からのアクセス時に console-test-user でサインインできることを確認


許可された IP アドレス 211.7.97.203 からのアクセス時に console-test-user-non-exclude でサインインできることを確認


許可されていない IP アドレス 36.240.198.233 からのアクセス時でも console-test-user ではサインインできることを確認


許可されていない IP アドレス 36.240.198.233 からのアクセス時に console-test-user-non-exclude ではサインインできないことを確認


SigV4 で署名された API 呼び出しは影響を受けないことを IAM Identity Center ユーザーとして確認

IAM Identity Center のユーザーとしては --excluded-principal を設定していないため、コンソールへのアクセスでは影響を受けることを確認

また、ここまでの設定では --excluded-principal に IAM ユーザーしか設定していないため、許可外の IP アドレスからの接続の場合ルートユーザーでのサインインもできませんでした。
ルートユーザーの常用は避けるべきとされており、メンバーアカウントのルートユーザーは ルートアクセス管理 によって認証情報の削除をするべきとされているので、ここで盲目的にルートユーザーが特権扱いになっていないのは好ましいポイントです。
注意事項
なお、前述の IAM Identity Center ユーザーが影響を受けた部分についてです。
本来 --excluded-principal に IAM Identity Center のユーザーの実体である IAM ロールの ARN を設定しようと考えていました。
ただ、実行時に以下のエラーが発生し、put-resource-permission-statement リクエストが受け付けられませんでした。

IAM ロールの ARN 中にスラッシュを含んでしまうことで excludedPrincipal で定義されているパターンに合致しなくなっていることで発生すると考えられます。(改善要望は提出済み)
やろうとしたこと
ALLOWED_ROLE="arn:aws:iam::60634912XXXX:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_*" aws signin put-resource-permission-statement \ --source-ip "$ALLOWED_CIDR" \ --excluded-principal "$ALLOWED_ROLE" \ --region us-east-1
弊社提供の AWS 請求代行サービスをお使いの場合の注意点
本エントリで記載した構成をとった場合、弊社での管理上の問題が生じる可能性もございます。
影響度や回避策を検証中ですが、ご検討の際は担当営業、エンジニアやサポートセンターまでお問い合わせください。
弊社が調査やメンテナンス用途で使用する IAM ロールについて
まとめ
今回のアップデートにより AWS マネジメントコンソールへのアクセスをインターネットを経由しない経路に限定しやすくなりました。
さらに 2 つのアップデートを組み合わせることにより、パブリックアクセス自体を限定的にすることも容易にできるようになります。
ただし AWS Management Console Private Access 機能に不具合が発生している場合、AWS マネジメントコンソールへのアクセスができない時間帯の発生が考えられます。そのため緊急用のパブリックアクセス経路の確保が必要と考えられます。
また、AWS Management Console Private Access がリージョンごとの VPC エンドポイントを要する点も留意が必要です。IAM や Route53 などのグローバルリソースの管理も AWS Management Console Private Access 経由に限定するのか、など設計ポイントも多そうです。
本エントリがどなたかのご参考になれば幸いです。
ではまた。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X(Twitter):@kazzpapa3(AWS Community Builder)