FAQs: Cloud Architect

AWS and GCP primarily, with some Azure experience — I’ll work within whatever you’ve already committed to.

Yes, but only where it’s actually justified — I won’t force a rewrite your team doesn’t need.

Yes — IAM design, network segmentation, and baseline compliance controls are part of the architecture work.

A cost audit is usually step one — most accounts have 20–40% of spend recoverable through right-sizing alone.

A full architecture audit and migration plan typically starts around ₹2–3L, scaling with infrastructure complexity. Ongoing infrastructure management after the initial build is priced separately as a monthly retainer.

A full-time DevOps hire is worth it once you have enough ongoing infrastructure work to keep them busy. This gets your architecture redesigned and documented as code first, so a future hire — or your existing engineers — inherit a clean, well-documented system instead of tribal knowledge.

An architecture audit and redesign for a mid-sized system usually takes 4–8 weeks, including migration. Ongoing monitoring and optimisation can continue as a lighter retainer afterward.

Very early-stage products still validating an idea, where a simple managed platform like Vercel or Render is more than enough. Full infrastructure-as-code investment pays off once you have real production traffic and reliability requirements.

An architecture audit — reviewing current infrastructure, cost drivers and single points of failure — so any redesign starts from a clear picture of what’s actually running today, not assumptions.

No — without careful architecture and ongoing optimization, cloud costs frequently end up higher than the on-premise setup replaced.

Lift-and-shift migrates faster but often disappoints on cost; cloud-native re-architecture takes longer but captures cloud benefits more fully.

An assessment of current infrastructure and actual business requirements, before any architecture decisions are made.

Companies migrating from on-premise, businesses with unexplained cloud costs, and organizations needing a security and disaster recovery review.

Yes — designed based on the client's actual risk tolerance and budget, rather than a blanket recommendation regardless of business criticality.

Meaningfully longer than marketing materials suggest for complex systems; honest timelines are set based on actual system complexity.

This project-scoped engagement is often more cost-effective for a defined migration or redesign versus needing continuous ongoing capacity.

Migrating without cost monitoring or governance, only discovering months later that spending grew far beyond expectations.

An initial requirements call, an assessment of existing architecture and costs, then a proposal with clear milestones and cost projections.

Yes — all infrastructure details and credentials are treated as strictly confidential, handled with appropriate security practices.

Yes — many start as an initial migration project and grow into ongoing cost and performance optimization as needs evolve.

Unpredictable cost growth, a planned on-premise migration, or a security audit revealing architecture gaps.

An independent, evidence-based recommendation with clear tradeoffs is presented, rather than favoring one internal faction over another.

Not by default — it's a separate, optional arrangement discussed based on the client's internal operational capacity.

Arrive with existing architecture diagrams, cost reports, and a clear description of pain points for sharper recommendations.

Yes — a brief follow-up review can be requested to ensure the new architecture performs as expected in real production conditions.

Yes — a healthcare application differs fundamentally from a media platform or internal tool, and recommendations reflect that.

Yes — identifying a pragmatic initial path that doesn't foreclose future scalability is part of the value provided.

Yes — architecture is scoped around the client's actual industry context and compliance requirements.

No — engagements range from a focused cost or security review to a full migration project.

Yes — clear architecture documentation and runbooks ensure the client's team can operate and extend the infrastructure independently.

Yes — architecture recommendations and cost projections can be packaged specifically for that audience.

Yes — complementing an existing IT team by focusing on specialized architecture expertise rather than duplicating existing capabilities.

Yes — periodic architecture reviews ensure infrastructure continues to serve business needs as usage evolves.

Yes — capacity planning under time pressure and revisiting smaller-scale architecture decisions are accounted for during rapid growth.

Yes — tradeoffs are evaluated honestly when a client's situation genuinely calls for a multi-cloud or hybrid approach.

It varies — a focused review may take weeks, while a full migration can extend across several months depending on complexity.

Yes — Kubernetes or simpler alternatives are evaluated honestly based on actual operational complexity the team can support.

Yes — infrastructure is defined as code by default, ensuring changes are tracked, reviewable, and reproducible rather than made manually through a console.