BackupPilot

Loading page
EBS Snapshots
Backup Targets
Policies
Backup History
Dashboard
reports and analytics

Managing backups in cloud environments is often fragmented, manual, and error-prone. During cloud deployments and project work, we noticed how easy it is to lose track of snapshots, forget backup schedules, or accidentally make backups inaccessible across users. This inspired BackupPilot , a centralized, automated backup management system that brings structure, reliability, and multi-user control to AWS backups. We wanted to solve a real problem: “What if backups were not something you manually manage, but something that just happens intelligently in the background?” for backup failures

How We Built It

BackupPilot is built using a control-plane / data-plane architecture inspired by real-world SaaS platforms. The control plane (SaaS layer) is built with Next.js 14, TypeScript, Prisma, and Cognito The data plane (customer AWS accounts) runs isolated infrastructure using CloudFormation, Lambda, Aurora PostgreSQL, EventBridge, and SNS We designed a system where: The SaaS never stores customer data or AWS credentials permanently All operations are executed inside the customer’s AWS account Access is granted dynamically using AWS STS AssumeRole with ExternalId-based trust A major engineering focus was runtime tenant isolation, where each API request dynamically resolves: Customer identity (via Cognito JWT) AWS role assumption (STS) Database connection (tenant-specific Aurora instance) This allowed us to build a true multi-tenant, stateless control plane.

What We Learned

This project gave us deep, hands-on experience with production-grade cloud architecture, including: Designing multi-tenant SaaS systems on AWS Implementing secure cross-account IAM trust models Working with STS AssumeRole and Confused Deputy protection Building dynamic database routing with Prisma Structuring serverless event-driven workflows using EventBridge + Lambda Managing real-world concerns like connection pooling, secrets handling, and blast-radius isolation We also gained a much clearer understanding of how real SaaS platforms separate: Control logic Execution environments Data ownership boundaries

Challenges We Faced

1. Multi-Tenant Isolation at Scale Initially, all tenants shared a single database model, which created serious isolation risks. Solution: We moved to a physically isolated model where each customer has their own Aurora PostgreSQL instance.

2. Dynamic AWS Credential Handling We needed secure cross-account access without storing long-term AWS keys. Solution: Implemented STS AssumeRole with short-lived credentials and ExternalId-based trust validation.

3. Runtime Database Switching Prisma is typically designed for single static connections. Solution: We built a tenant-aware Prisma client factory with caching, allowing safe reuse while avoiding connection exhaustion.

4. Fully Automated Customer Onboarding Provisioning AWS resources manually was not scalable. Solution: We created a CloudFormation-based onboarding pipeline that provisions: VPC Aurora PostgreSQL Lambda workers IAM roles Secrets Manager EventBridge schedules

5. Cross-Account Serverless Coordination

Coordinating EventBridge → Lambda → Aurora → SNS across accounts introduced complexity in tracing and debugging.

Solution: We implemented structured logging, audit trails, and standardized job state tracking inside the customer database.