Building a Fortress with LEGOs: A Cloud SSO Architecture

Senior Engineer FAANG, Unicorns, Startups

Q: "Now, take the same SSO system and design it for the cloud, specifically AWS. Don't just list services. Explain the architectural philosophy and how it differs from on-premise."

Why this matters: This question tests your understanding of leverage. The cloud isn't just a different location; it's a different way of thinking. They want to know if you can move beyond a 1:1 mapping of on-prem components and embrace the native capabilities of a cloud platform to build a system that is not just hosted, but truly cloud-native: resilient, scalable, and agile.

Interview frequency: Very High. This is the new standard for senior system design interviews.

❌ The Death Trap

The candidate simply replaces the on-premise components with their AWS equivalents. "Instead of an F5, we use an ALB. Instead of physical servers, we use EC2." This is called "lift and shift" thinking. It shows you know the AWS product catalog but not the underlying philosophy.

"This approach treats AWS like a remote data center, not a platform of leverage. It misses the superpowers the cloud gives you, like elasticity and managed services."

🔄 The Reframe

What they're really asking: "How do you use the cloud's pre-built, world-class components to build a superior fortress, faster and with less effort, than you could ever build by hand?"

This reveals if you think in terms of force multipliers. A great answer shows you see AWS not as a menu of products, but as an infinite set of LEGO bricks. You're not just rebuilding your old fortress; you're using superior materials to build something fundamentally more resilient and dynamic.

🧠 The Mental Model: The LEGO Fortress

If the on-premise architecture was a fortress built stone by stone, the cloud architecture is a fortress built from a massive, infinitely supplied LEGO set. You stop making your own bricks and start focusing on the design.

🧱

Leverage, Not Labor

On-prem, you hire masons to build your walls. In the cloud, you get perfectly formed, pre-fabricated wall sections (VPCs, Security Groups) via an API. Your focus shifts from construction to assembly.

🔄

Elasticity, Not Static Capacity

An on-prem fortress has fixed walls. A LEGO fortress can add or remove towers on demand. If you're under attack (a traffic spike), you can instantly add more archers (Auto Scaling Groups). When the attack subsides, they vanish. You pay only for what you use.

🤖

Automation, Not Administration

On-prem, you need guards to patrol the walls (manual monitoring). In the cloud, the walls patrol themselves (Health Checks, CloudWatch). Failure is detected and remediated automatically. The system heals itself.

✅ The Answer

"My philosophy for designing in the cloud is to trade granular control for strategic velocity. I want to leverage Amazon's billions of dollars of R&D in infrastructure so my team can focus exclusively on authentication logic. We're still building a 'Fortress of Trust,' but this time we're building it with LEGOs."

The Blueprint for the LEGO Fortress

The principles of Defense in Depth remain, but the implementation becomes dramatically more powerful and dynamic.

1. The Twin LEGO Baseplates (Availability Zones): We don't build two data centers; we use two of AWS's highly-resilient Availability Zones. We get superior physical separation and redundancy on day one with a click of a button. This is our foundation for high availability.

2. The Software-Defined Moat (VPC and Subnets): Our fortress layout is defined in a VPC. We create a `Public Subnet` for our Outer Wall and a `Private Subnet` for our Inner Sanctum. This separation is logical, not physical, making it incredibly flexible.

3. The Self-Healing Outer Wall (ELB + ASG): Our sacrificial reverse proxies are EC2 instances within an Auto Scaling Group (ASG), sitting behind a public Elastic Load Balancer (ELB). This is where the magic happens. The ELB's health checks are the automated guards. If an EC2 instance fails, the health check detects it, the ELB stops sending traffic to it, and the ASG automatically terminates the faulty instance and launches a perfect, new replacement. The wall heals itself without human intervention.

4. The Intelligent Inner Gatehouse (Private ALB): Traffic that passes the outer wall is directed to a Private Application Load Balancer (ALB). It operates entirely within our private network, directing traffic to the PingFederate engines.

5. The Elastic Throne Room (PingFederate Engines in an ASG): Our core PingFederate engines also live in an Auto Scaling Group within the private subnet. If authentication load spikes, we can automatically add more engine nodes. When it subsides, they scale back down. We achieve true elasticity, paying only for the compute we actually consume.

The traffic flow for external vs. internal users follows the same differentiated trust model as on-prem. However, the cloud version is superior because it's not just redundant; it's anti-fragile. It's designed to absorb failure and traffic spikes automatically, making it more resilient and cost-effective at scale."

🎯 The Memorable Hook

"The cloud isn't just someone else's computer. It's someone else's army of world-class SREs, network engineers, and security experts, all available via API."

This reframes the cloud from a simple utility to a massive source of human capital leverage. It shows that you understand the true product you're buying is not servers, but the expertise and automation that come with them.