RDS - Support for VPC Encryption Controls
Designing enforced encryption for regulated, high-stakes infrastructure workflows. A system-level experience that allows customers to audit, enforce, and recover from encryption constraints.
DECEMBER 2025
TEAM
Lead UX Designer (Me)

2 Software Development Engineers
Program Manager
EC2 Partner Team
WHAT I DID?
Compliance Architect: Led the end-to-end UX strategy for integrating EC2’s VPC Encryption Controls into RDS - transforming manual audit enforcement into automated, system-aware validation.
Failure State Orchestrator: Designed synchronous and asynchronous validation patterns that made provisioning failures transparent, actionable, and recoverable.
Technical Governance: Aligned EC2 Networking and RDS Database teams on shared validation logic, API parity, and consistent error handling across Console and CLI.
IMPACT
Raised the bar on data encryption
Enabled RDS to integrate with EC2’s new VPC Encryption Controls, allowing regulated customers to confidently enforce encryption-in-transit while maintaining reliable database provisioning.
LAYING THE LAND
The Problem: An Awareness Gap Between Services
Prior to this work, a critical gap existed between the network layer (EC2) and the database layer (RDS). Customers could enforce encryption at the VPC level - but RDS had no visibility into those constraints during database creation.
The Resulting Failure Loop
Errors surfaced too late
Compliance couldn’t be validated upfront
Customers were stuck in provision–fail–retry cycles
In regulated environments, this isn’t friction — it’s risk.
THE CHALLENGE
The Sequential Trap
A core architectural constraint shaped the design: AWS console workflow requires users to select their Instance Type (1) before selecting their VPC (2).
This sequencing meant:
Encryption compatibility could not always be evaluated upfront
Some violations were only discoverable after additional context was known
A purely preventative UX was not technically feasible
This was not a UI issue - it was a system-ordering reality.
Any solution had to respect existing RDS creation flow order, enforce VPC-level encryption without false positives, provide clear, actionable recovery paths, and avoid forcing users to restart database creation
%206%201.png)
THE PRODUCT
A Two-Layer Enforcement Model
To work within system constraints, I designed a dual feedback model:
Synchronous Feedback
(Preventative, When Possible)
Asynchronous Feedback
(Recoverable, When Necessary)
No silent failures. No dead ends.
The database is put into a "Failed State" with a tooltip explaining the specific encryption mismatch, providing a clear roadmap to remediation when hovered over it.
The Meta-Data Tags
VPC dropdown surfaced encryption-enforced states via metadata tags.
Additionally a user can create a new VPC without leaving this page.
%204%202.png)
%204%203.png)
The Warning
Immediate compatibility warning is triggered upon selection that explained the specific encryption mismatch
The Resolution Path included a three remediation options - (1)Change instance type, (2)Select a different VPC (3)”Modify VPC” encryption settings (deep link to EC2 console)
Designing for Recovery: Added a refresh mechanism to re-evaluate updated VPC configurations
STRATEGIC TRADE-OFFS
1. Why not use a "Hard Filter" to hide incompatible VPCs from the dropdown?
The Logic: Hiding them would create “system silence.” An empty dropdown is more confusing - and more expensive - than a visible, explained conflict. Visibility builds trust.
2. Why not disable incompatible VPC options altogether?
The Logic: Disabling without explanation feels arbitrary to power users. By keeping them selectable and triggering immediate validation, we preserved transparency, explained the constraint and empowered users to decide how to resolve it
3. Why not re-order the form to put VPC selection before Instance Type?
The Logic: While reordering would have solved this feature’s constraint it would have also broken global AWS provisioning consistency. Form architecture consistency is a higher-order design system requirement. Local optimization would have created ecosystem fragmentation across RDS and other Databases.
REFLECTION AND LEARNINGS
​​
Designing for Failure
This project reinforced that in infrastructure design, the failure state is as important as the success state. A well-designed error is a roadmap to remediation.
​
Prevention over Correction
By "shifting left" on validation, we transformed a potential support-ticket nightmare into a self-service compliance tool.