This role sits with a team building and maintaining cloud infrastructure on Google Cloud Platform, with the architect responsible for how the pieces fit together.
Most companies at this stage already have a working setup. The job is less about starting from zero and more about making sure that setup keeps holding up as traffic, data, and team size all grow at once.
Cloud architecture work at this level is rarely about picking the newest available service just because it exists. More often the right call is the boring, well-tested option that a team not yet familiar with a system can actually maintain after you move on to the next project.
Cost is part of nearly every decision too. A technically elegant solution that quietly triples a client's monthly cloud spend is not actually a good solution, and knowing how to weigh performance against cost is a skill this role expects you to already have. Being able to justify a design choice in plain terms to a non-technical stakeholder, not just to another engineer, is part of that same skill. Clients paying for architect-level work generally expect a clear explanation of the tradeoffs, not just a finished diagram handed over without context.
Security considerations run through nearly every design decision as well, from how service accounts are scoped to how sensitive data moves between components. Treating security as a final review step rather than something baked in from the start tends to create expensive rework later, and reviewers on this team will push back on a design that skips it during the review stage. It is one of the more common reasons a proposed design goes back for a second pass before it gets approved.
You would work alongside a mix of backend engineers, a platform or DevOps lead, and occasionally product staff who need to understand what a given infrastructure change means for a feature they are shipping. Architecture decisions here rarely happen in isolation, so being able to explain a tradeoff clearly to someone outside the infrastructure team matters as much as making the right call technically.
A typical project might involve redesigning how a client's application scales during traffic spikes, moving from a single overloaded instance to a properly load-balanced setup across multiple zones. You would own that redesign from initial architecture through the testing that confirms it actually holds up under load.
Documentation is not an afterthought here. A design decision that lives only in your head becomes a problem the day you are out sick and something breaks, so writing down the reasoning behind a setup, not just the setup itself, is treated as part of finishing the work rather than an optional extra step.
A bachelor's degree in computer science, software engineering, or a related field is required, along with 24 months of demonstrated experience in cloud architecture work. A strong portfolio of relevant projects matters here, ideally ones you can walk through in detail rather than just list on a resume.
Proficiency with modern development tools is assumed. If your most recent hands-on cloud work was several years ago, this particular role is probably not the right fit right now, and that is fine to acknowledge upfront rather than discover mid-interview.
Depth matters more than breadth for most of these. Knowing one or two languages and the relevant cloud services thoroughly tends to serve you better here than a surface-level familiarity with a long list of tools you have only used once or twice.
Architects who spend a couple of years here often deepen into a specific area such as data infrastructure, security architecture, or cost optimization at scale. Others broaden out toward a staff-level or principal role, taking on responsibility for infrastructure decisions across multiple teams rather than a single system. The direction usually follows individual interest more than a fixed track.
The strongest applicants for this kind of role usually bring one or two projects they can describe in real depth, including what went wrong along the way, rather than a long list of technologies they have merely touched. Being able to explain why a particular architecture choice was made, and what you would do differently now, carries more weight in an interview than a long certification list on its own. Comfort admitting a past design decision did not hold up, and explaining what you learned from fixing it, tends to read as a strength rather than a weakness during that conversation.
This full-time position pays $160,000 annually, reflecting the specialized nature of the work. Architect-level listings on Remoteroles in this category tend to sit toward the higher end of the pay range for remote technical roles, and this one is no exception. The package includes:
This is a fully remote position with no office tied to it and no city requirement of any kind. Your working hours have some flexibility, though you will need reasonable overlap with your team for planning and reviews.
Submit your resume along with a portfolio or description of cloud architecture projects you have led or contributed to significantly. Be ready to discuss a specific design decision you made and why you made it, since that conversation tends to matter more than a general resume review, and plan for a technical follow-up round after it.