Migrating from Firebase to AWS: Why We Made the Switch for Azarr Technologies

When we launched Azarr Technologies, Firebase on Google Cloud Platform (GCP) was the obvious choice. It was fast to prototype, had a generous free tier, and handled authentication and real-time data effortlessly. But our relationship with GCP took a dramatic turn when we started receiving bills for services we had never enabled—a nightmare that would repeat itself over several months and ultimately force us to migrate entirely.

The billing nightmare: When trust breaks

In early 2026, we noticed our GCP bill had increased by nearly $3,000 USD for what appeared to be Gemini model usage—a service we had never provisioned. We had only ever used Firebase and Firestore etc. Upon investigation, we discovered that the charges were an internal google misattribute to our project (likely from a misconfigured or system glitch).

“We spent weeks going back and forth with Google Cloud support, providing screenshots, access logs, and billing history—all to prove we weren't using a service they were charging us for. The adjustment eventually came, but the stress and uncertainty were exhausting.”

Jason Ball, Founder & CEO ― Azarr Technologies

The initial resolution took 12 days from the time we first reported the issue. Google's billing support team eventually credited the amount back to our account after multiple escalation tickets. We breathed a sigh of relief and moved on.

The repeating cycle: Deja vu all over again

One month later, the same charge appeared on our bill. Again, we were being billed a huge amount for a Gemini model. Again, we had never used it. Again, we opened support tickets, provided documentation, and waited for a resolution.

• **Month 1**: Wrongful charge appears → 12 days to resolve → Platform unaffected
• **Month 4**: The cycle continued—Google support acknowledged the "known issue" but only provided basic troubleshooting tips

The most damaging part wasn't the financial cost—it was the operational impact. Each wrongful charge triggered automated billing alerts that resulted in our platform being temporarily disabled. Our enterprise clients were receiving "Service Unavailable" errors while we scrambled to resolve a billing dispute that we didn't cause. The reputational damage was incalculable.

“Every billing cycle became a crisis. We couldn't predict if our platform would be taken offline by a billing error we had no control over. That's not a sustainable way to run an enterprise SaaS business.”

Jason Ball, Founder & CEO ― Azarr Technologies

AWS: The enterprise alternative we should have chosen

We evaluated AWS with a critical lens: Could they provide better billing clarity, faster support, and a more predictable operating environment? The answer was a resounding yes.

1. Transparent and Predictable Billing

AWS Cost Explorer and Budget Alerts give us real-time visibility into every dollar spent. We've never been billed for a service we didn't enable, and on the rare occasion a billing question arises, AWS support resolves it within hours, not weeks. AWS also provides detailed cost allocation tags, making it easy to track spending by project, team, or client.

2. Granular Security Controls

B2B clients demand SOC 2, ISO 27001, and HIPAA compliance. AWS provides comprehensive compliance certifications out of the box. More importantly, AWS IAM lets us implement least-privilege access at the resource level—something Firebase's role-based system couldn't match. We can now enforce zero-trust security across our entire infrastructure, from API gateways to database clusters.

3. VPC and Private Networking

With AWS VPC, we can keep our database, caches, and internal services completely private—accessible only from within our virtual network. This eliminates attack vectors and ensures that only our application layer is publicly exposed. For enterprise clients, this is non-negotiable.

4. Database Choice and Flexibility

Firebase's Firestore is excellent for real-time data, but B2B platforms need relational data for analytics, reporting, and complex business logic. On AWS, we deployed PostgreSQL on RDS for transactional data while keeping DynamoDB for high-velocity operational data. This hybrid approach gives us the right tool for every job, with predictable performance and full ACID compliance.

5. Global Performance and Edge Computing

B2B clients operate globally, and latency matters. AWS's 30+ global regions and CloudFront edge network deliver content with sub-millisecond latency. We deployed Lambda@Edge for regional request handling, ensuring enterprise clients in Europe, Asia, and the US all experience sub-100ms response times.

The migration strategy: How we did it

• 1. **Assessment Phase**: Mapped all Firebase data models to AWS equivalents (Firestore → DynamoDB, Cloud Functions → Lambda + API Gateway, Firebase Auth → Cognito)
• 2. **Parallel Run**: Ran both Firebase and AWS in production for 30 days, routing 5% of traffic to AWS initially, gradually increasing
• 3. **Data Migration**: Used ETL pipelines to transfer historical data, with custom validation scripts ensuring consistency
• 4. **Performance Testing**: Load-tested every endpoint to ensure AWS handled peak loads without degradation
• 5. **Cutover**: Switched traffic completely to AWS, keeping Firebase as a fallback for 14 days
• 6. **GCP Account Closure**: Finally, we shut down our Google Cloud account entirely—no more billing disputes, no more uncertainty

Key technical wins post-migration

• **Billing certainty**: Zero wrongful charges in the 6 months since migration, zero platform downtime from billing issues
• **API response times**: Improved from 280ms to 85ms (70% improvement)
• **Database query performance**: Complex joins now execute in 50ms vs Firebase's multi-query approach taking 400ms+
• **Cold starts eliminated**: Lambda's provisioned concurrency ensures zero delay for enterprise clients
• **Cost reduction**: $4,200/month on GCP → $2,500/month on AWS (40% savings) with 3x the traffic
• **Global coverage**: Edge caching reduced EU and APAC latency from 450ms to 120ms
• **Support resolution time**: Weeks → Hours for any billing or technical inquiry

Global network infrastructure

1 / 4

The hidden costs of billing uncertainty

Beyond the direct financial costs, the billing disputes with Google Cloud caused significant indirect damage:

• **Team productivity**: Our engineering team spent an estimated 40+ hours per billing cycle on support tickets and escalations
• **Client trust**: Two enterprise clients questioned our reliability after experiencing downtime during billing disputes
• **Stress and morale**: The monthly uncertainty created a culture of anxiety—no one wants to wake up to a disabled platform notification
• **Opportunity cost**: We could have shipped 3 major features in the time spent managing billing issues

Advice for teams considering the same move

• **Don't wait for the problem to resolve itself**—if you're experiencing recurring billing issues, they won't magically fix themselves.
• **Document everything**—screenshots, tickets, responses, and the impact on your business. This builds the business case for migration.
• **Start with a single non-critical service** as proof of concept.
• **Invest in automated migration scripts** with validation checks.
• **Use AWS RDS for transactional data**, not DynamoDB, unless you have specific performance requirements.
• **Set up comprehensive CloudWatch monitoring** before the cutover.
• **Budget for a 30-day parallel run** to validate everything before committing.

The move from Google Cloud to AWS wasn't just about fixing technical debt or optimizing costs—it was about regaining control over our business operations. We couldn't afford to have our platform disabled by billing errors we didn't cause. AWS gave us stability, predictability, and a partnership we could trust.

Since migrating, we've had zero billing incidents, zero platform downtime from payment issues, and zero sleepless nights waiting for support tickets to resolve. That peace of mind is worth more than any cost savings or technical improvement.