Regional NAT Gateway
Designed the AWS Console experience for regional NAT gateway creation, reducing costs and complexity by removing the need to create multiple zonal NAT gateways and guiding users through multi-AZ setup with Elastic IPs.
Role: Lead UX Designer
Responsibilities: Led the UX design for regional NAT gateway creation in the AWS Console, collaborating with backend engineers and cross-service teams to translate complex networking and Elastic IP requirements into a clear, guided user flow. Designed in-console education, validation logic, and configuration tools to reduce user errors, improve cost efficiency, and support multi-AZ deployment.
Duration: 4 months
Users & Audience: Cloud Infrastructure Engineer / Cloud Architect, DevOps engineer, IT Admin
This project is currently in development. Due to AWS policy, cannot post certain mocks and pictures.
Problem
Previously, users could only create zonal NAT gateways, which means it serves one availability zone. This meant high costs, manual replication across zones, and complicated maintenance.
With the launch of regional NAT gateways, users could now centralize this, but the existing console flow didn’t support it. Users also need to understand which one to choose.
Step 1 | Understand NAT Gateway
This was my first time working with the NAT Gateway team, so I needed to quickly ramp up on what NAT gateways are, how they’re used, and why introducing a regional option mattered. I started by reading a one-pager provided by the product manager, then scheduled a kickoff meeting with the PM, the lead SDE, and several backend engineers. I came prepared with a focused list of questions to better understand backend behavior, user workflows, and how Elastic IPs and availability zones impact the creation experience.
For reference, a NAT gateway (Network Address Translation gateway) is a service in AWS that allows resources (like EC2 instances) in a private subnet to connect to the internet — without allowing inbound traffic from the internet back to them. For regional NAT gateway it would be at a VPC-level, not subnet.
Step 2 | Frame the challenge
For this project, the main challenge wasn’t visual design complexity — it was deeply understanding the product, how it works, and how it impacts users’ networks. AWS users often turn to the AWS console as a way to learn about a service, even if they eventually rely on the CLI or APIs to implement it. That meant the design needed to be clear, educational, and aligned with backend logic.
Through conversations with the product manager and reviewing customer feedback, I uncovered two key insights:
There was strong demand for a regional NAT gateway option, since maintaining separate zonal gateways for each Availability Zone was costly and hard to manage.
Regional NAT gateways introduced a new concept: allocating Elastic IPs per AZ to enable coverage — something users weren’t familiar with and would need guidance on.
AWS users typically don’t expect flashy UI — they prefer straightforward, logic-aligned designs that reflect how the API behaves. This informed every part of my approach, from layout and terminology to validation and error handling.
Step 3 | Early design & API alignment
After speaking with potential users, stakeholders, and API engineers, I created the first draft of the regional NAT gateway creation form in Figma and shared it during our weekly sync. This working prototype helped uncover gaps in the API design and clarify ambiguous requirements.
For instance, the one-pager from the product manager specified that users should be able to allocate Elastic IPs (EIPs) to Availability Zones — but it wasn’t clear:
If there was a limit per zone
Whether the same EIP could be used across multiple zones
What users needed to know in order to map EIPs correctly
Surfacing these questions early helped drive critical decisions across teams.
Step 4 | Design
Based on that feedback, I designed a flow where:
Users can choose between zonal and regional NAT gateways, with clear descriptions to help them decide what fits their use case
Info panels explain technical differences between the two options in plain language
The UI validates EIP availability, surfacing gaps before submission
Error states and inline guidance help users troubleshoot issues like missing EIPs or zone coverage before continuing
This approach reduced the chance of misconfiguration while still keeping the experience lightweight and familiar to AWS Console users. In addition to the creation flow, I created the details page of the regional NAT gateway as well as the editing flow.
Closer look:
Automatic EIP allocation
For a fully hands-off setup, users can select “Automatic” to have Elastic IP addresses automatically allocated whenever a new Availability Zone is added to the region of the selected VPC.
This option is ideal for users who want to get up and running quickly without needing to manage EIP assignments manually after creating the NAT gateway.
Closer look: Manual EIP allocation
For users who want more control, selecting “Manual” allows them to assign Elastic IPs themselves. They’ll see a list of Availability Zones in the region of the selected VPC and can choose which EIPs to allocate to each zone.
This option is ideal for teams with specific networking requirements or who prefer to manage resources explicitly.
What I learned
This feature has not yet launched, so I don’t have user results to share, but the project taught me several important lessons:
I learned how critical it is to ground UI design in backend logic, especially in infrastructure tools where users expect the console experience to reflect CLI and API behavior. Understanding system dependencies was essential to making the interface intuitive and reliable.
Designing for technical accuracy
Balancing education and simplicity
Introducing a new concept like regional EIP allocation required thoughtful UX writing and hierarchy. I learned how to balance just-in-time education with a clean, familiar layout, offering enough information at first glance while allowing users to dig deeper only if needed.
Advocating for user needs in a tech/business-driven culture
There was initial pressure to remove the zonal NAT gateway option entirely, since the business goal was to push adoption of the newer regional model. However, through customer conversations, I discovered that many small and mid-sized businesses still relied on zonal gateways due to cost and simplicity. I advocated for keeping both options available until a better solution for these users could be designed, ensuring we weren’t only building for enterprise.
