AWS or Google Cloud for a Solo Cloud or DevOps Consultant

Say you've spent six years deep in AWS, from EC2 and VPC networking through Lambda and CloudFormation. A new client shows up already running on Google Cloud. Do you force a migration to your comfort zone, or learn their platform? For a solo or two-person shop, the honest answer is usually to meet the client where they are. Relearning a second platform's core services is a manageable few weeks of ramp-up; migrating a working client environment for your own convenience is a much larger, harder-to-justify project.

With five client accounts, you need a way to jump between them without keeping five sets of credentials in five browser tabs. AWS's cross-account IAM role assumption is a well-worn pattern for exactly this, letting you use one identity to assume scoped roles in each client's account. Google Cloud's equivalent, using service account impersonation across projects, does the same job with a different set of commands to learn. Set this up properly for whichever platform a client is on rather than falling back to shared root-level credentials out of convenience, since that convenience is exactly what turns into a security incident.

A solo consultant doesn't have a finance team to reconcile a complicated multi-service bill every month. When a client asks you to pick their platform from scratch, weigh how easy the resulting monthly bill will be for them to read without your help, since a client who can't understand their own cloud bill will call you every month asking why it changed. Simpler, more predictable workloads favor whichever platform gives the client the clearer invoice for their specific mix of services.

Without a platform team to catch mistakes, your own deployment habits are the whole safety net. Keeping your own change failure rate low matters more when you're the only person on call, and building a habit of testing changes in a staging environment before touching a client's production system pays for itself the first time it catches a mistake¹. This holds regardless of which cloud a given client runs.

There's one case where forcing a migration makes sense: a client's existing setup is actively unsafe, like shared root credentials across a team or no backup strategy at all. In that case, the platform they're on matters less than fixing the underlying practice. Otherwise, five clients on a mix of AWS and Google Cloud is a normal, sustainable way to run a solo or small consultancy, as long as you're disciplined about not mixing up which credentials belong to which account.

Quoting a fixed-price project on the platform you know less well is where solo consultants lose money quietly, because the extra hours spent looking things up don't show up until the invoice doesn't cover the time. Bill hourly, or pad a fixed quote honestly, when a project calls for the platform you're less fluent in, and use that engagement to build real fluency for the next client who shows up on the same platform. Treat every unfamiliar-platform project as paid training, because that's effectively what it is, and price it accordingly rather than eating the ramp-up cost yourself.

Keep a running note of which services on the less familiar platform tripped you up, so the next engagement on it goes faster and you can quote it more tightly. Over a year or two, this turns what started as your weaker platform into a second real strength rather than a recurring source of underbid projects.

Not every client is worth taking on, even at solo-consultant rates. A prospective client asking for deep expertise on a specialized service you've never touched, on a platform you barely know, with a tight deadline and no room to learn on the job, is a project worth referring elsewhere rather than accepting and improvising. Protecting your reputation for the clients where you're genuinely strong matters more than filling every gap in your calendar.

Consider referring a client elsewhere when several of these are true:

• The engagement needs deep expertise on a specialized service you have never touched.
• The client's platform is one you barely know, and the project offers no room to learn on the job.
• The deadline is tight enough that improvising would put your reputation at risk.
• The existing setup is actively unsafe, for example shared root credentials or no backup strategy, and fixing the practice matters more than the platform.