"A Note from the Author"
I work as a technical support engineer at an AWS reseller in Japan, operating under the AWS Solution Provider Program. Our customers range from large enterprises to small businesses, and a significant part of my role involves helping them navigate the AWS Management Console and understand new features.
One thing worth noting for international readers: Japan's IT industry has traditionally relied heavily on outsourcing to external vendors and system integrators for building and managing cloud infrastructure. In-house engineering teams are less common compared to the U.S., which means decision-making around AWS configurations often involves multiple stakeholders across organizational boundaries. Features like the one discussed in this post can have outsized impact in that context — a single account-level setting made by one party can affect everyone who signs into that account.
Also, full disclosure: my English writing skills are limited, so I used GenAI (Kiro CLI) to help translate and edit this post from the original Japanese. I hope it reads well!
Hello, everyone. I'm Ichino ( @kazzpapa3 ), a Technical Support Engineer at an AWS partner company. My favorite AWS services are the AWS CLI and AWS CloudTrail. My least favorite (as a support engineer) is AWS Billing — the billing logic is just too convoluted.
On March 27, 2026 (local time), AWS announced an update that lets you configure visibility settings for regions and services in the AWS Management Console.
This is an addition to the Account User Experience Customizations (UXC) utility, which previously only supported the "account color" feature. After taking a closer look, I found a few caveats worth writing about.
Please note that the Management Console screenshots in this post reflect the UI at the time of writing and may change in the future. Also, while I've left AWS account IDs and role names visible for clarity, the accounts shown have already been deleted — so no need to worry.
TL;DR
- AWS Account User Experience Customizations now lets you configure account-level visibility settings
- Configurable items: Account Color, Service Visibility, and Region Visibility
- Visibility can be set to "All" or defined as an allow-list of specific services/regions
- These settings affect all IAM entities in the account — including IAM users, IAM roles, IAM Identity Center users, and even the root user
- This is purely a Management Console display setting — API calls are not restricted
Official Announcement and Documentation
- AWS Management Console now supports settings to control service and Region visibility
- AWS User Experience Customization (UXC)
Exploring the Feature
Configuring via the Management Console
The "Account color" setting is found under Billing and Cost Management → Account page in the "Account display settings" section. The visibility settings, however, are accessed through a different path:
- Click the gear icon at the top of the console, then click "See all user settings"
- On the "Unified Settings" page, navigate to the "Account settings" tab
- You'll see sections for "Visible Regions" and "Visible services" — click the "Edit" button for each to configure
An important note: the screenshot above states "Manage settings for the current user. These settings do not apply to other IAM users or accounts." As I'll explain in the "Problematic Scenarios" section below, this is misleading — the settings actually affect all IAM entities, including IAM roles and IAM Identity Center users.
Configuring via the AWS CLI
You can configure these settings using the aws uxc update-account-customizations subcommand.
From the AWS CLI Command Reference, the command accepts the following options:
update-account-customizations
[--account-color ]
[--visible-services ]
[--visible-regions ]
...
update-account-customizations — AWS CLI 2.34.41 Command Reference
Testing the Settings
I used AWS CloudShell to test with the AWS CLI. For reference, this feature is supported in AWS CLI v1 starting from 1.44.66, and in AWS CLI v2 starting from 2.34.17. I also noticed that the UXC endpoint appears to exist only in us-east-1 (I couldn't find it in the Service endpoints and quotas documentation), so you need to explicitly specify the region.
Checking the Current State
Let's check the current region visibility settings.
In the Management Console, the default is "All available regions." Via the CLI, you can check with aws uxc get-account-customizations --region us-east-1.
The region selector dropdown also shows all default-enabled regions:
Changing the Settings
Let's restrict visibility to only the Tokyo region (ap-northeast-1):
aws uxc update-account-customizations \
--visible-regions ap-northeast-1 \
--region us-east-1
The command completed without errors.
Verifying the Change
After navigating to the EC2 console in a non-Tokyo region, a message appears indicating that the region is restricted. The bottom of the browser also shows the output of aws uxc get-account-customizations --region us-east-1 from CloudShell.
Note: while it's hard to tell which service you're viewing from the screenshot alone, the URL https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Overview: confirms this is the EC2 console in US East (N. Virginia).
Verifying API Access Still Works
As you may have noticed in the previous screenshot, even though the Management Console blocks access to US East (N. Virginia), the aws uxc get-account-customizations command with --region us-east-1 still works perfectly fine.
Furthermore, running aws ec2 describe-vpcs against US East (N. Virginia) returns a valid response — confirming that API-level access is not restricted by visibility settings.
Problematic Scenarios
Here's where things get tricky. When you try to access IAM or CloudFront in the console, they are also affected by region visibility settings.
As we've seen, API calls still work as long as you have the right permissions. But global services that depend on US East (N. Virginia) — like IAM and CloudFront — become inaccessible in the console when that region is hidden.
Additionally, as I briefly mentioned earlier, even IAM roles and the root user are subject to these visibility restrictions:
Concerns
The "Unified settings" affect every user who signs into the Management Console for that account, regardless of their existing permissions.
Of course, any entity with uxc:UpdateAccountCustomizations permission can modify the settings — but that means if you restricted visibility for certain users, those restrictions can be undone by anyone with that permission.
In this post I only tested region visibility, but service visibility works the same way. You cannot set granular per-user visibility — for example, showing only EC2 to one user while also allowing another user to see CloudTrail. And since this is only a display restriction, API access remains unaffected, so you can't rely on visibility settings as a security control.
The bottom line: you should still use IAM policies and SCPs to enforce actual access restrictions.
Wrapping Up
As we've seen, the fact that these settings apply to every IAM entity in the account is a notable limitation.
That said, I understand the concern that users might accidentally interact with services or regions they shouldn't be touching. The concept of decluttering the console to show only what's relevant is genuinely appealing.
I think this feature would be much more powerful if visibility could be controlled per IAM entity, and I've submitted that feedback to AWS through AWS Support.
For now, the tried-and-true approach of using IAM policies and SCPs to deny actions at the user level remains the recommended path. But if you understand the capabilities and caveats, this feature can still be a useful addition to your toolkit.
I hope this post helps someone out there. Until next time!
Top comments (0)