Cloud Architecture Services in India
Cloud architecture services in India for CTOs and engineering leaders in the US, UK, Canada, Australia and New Zealand: failure domain design, network and identity topology, cost architecture, and data residency for buyers whose users are nowhere near Mumbai. You get the decisions and the reasoning behind them, written down, so the system your engineers build still makes sense two years and three hires later.
Why Do Cloud Architectures Fail Their First Real Traffic Day?
Because the diagram was never a claim about behaviour. It was a claim about components. Boxes and arrows tell you what exists. They tell you nothing about what happens when the arrow between two of those boxes takes 40 seconds instead of 40 milliseconds, which is the state most outages actually live in. Systems rarely die from a component being gone. They die from a component being slow while everything upstream keeps retrying.
Here is the shape of it. A service calls a downstream API with a default client timeout, which on several popular HTTP libraries is either very long or absent entirely. The downstream slows down. Requests pile up in the caller. The connection pool drains, threads block, health checks start failing because the health endpoint shares the same pool, and the load balancer pulls instances out. Fewer instances now carry the same traffic. The autoscaler reacts, but new instances take two minutes to warm up and immediately hit the same slow dependency. Nothing crashed. Everything stopped.
None of that is visible on an architecture diagram. It comes from four decisions that were made quietly: the timeout, the retry policy, the pool size, and whether the health check tells the truth about capacity. Those decisions are architecture. They just do not have a box.
The second common failure is topological. A team runs its application tier across three availability zones and feels covered, then discovers the database was provisioned as a single instance in one of them, or that a stateful queue broker has two nodes when quorum needs three. Zone redundancy is not a property of an account. It is a property of every stateful component individually, and one of them is almost always missed.
The third is money. Nobody notices the cost of a design decision on day one because the traffic is small. Cross zone chatter, NAT processing on every outbound call, a log pipeline with unbounded cardinality, four permanently warm clusters for four environments: at pilot scale the whole thing costs less than a laptop. At real scale the same design produces a bill that arrives before the revenue does, and by then the shape is expensive to change because everything depends on it.
And then there is the failure that has nothing to do with engineering. A deal comes in from Munich or Melbourne and the contract has a clause about where personal data lives. The architecture has one region, one account, one database, and no notion of tenant location. The engineering work to fix that is not hard. The problem is that it is now on the critical path of a sale, with a quarter's revenue behind it.
Cloud architecture services in India, done properly, are about making those four categories of decision on purpose and writing down why. Reliability, cost, security and data location are not features you bolt on later. They are consequences of a topology you chose in week two.
What a Cloud Architecture Engagement Delivers
Not every engagement includes everything below. A pre-launch startup and a company with 200 accounts and a compliance auditor need different work in a different order. What follows is the full surface, roughly in the sequence we usually build it.
A current state read that includes the parts nobody documents
We start by reading the account, not the wiki. Resource inventory, IAM policies as they actually exist, security group rules, route tables, the last 90 days of billing broken down by service and tag, and the last few incidents with their real timelines. On a system with any history, the gap between the documented architecture and the deployed one is the most useful thing we find in the first fortnight. The undocumented cron box that half the reporting depends on always turns up here.
Account and landing zone topology
How many accounts or subscriptions, what separates them, where the boundary between production and everything else sits, and how identity flows across them. This is the decision that is hardest to reverse later, so it goes first. AWS Organizations with Control Tower, Azure management groups under the Cloud Adoption Framework, or a Google folder hierarchy: the tool matters less than getting the boundary right, because a boundary you draw in year one is a boundary you inherit in year five.
A failure domain map with numbers attached
Every stateful component listed with the zone or region it depends on, what happens when that dependency degrades, how the system detects it, and how long recovery takes. RTO and RPO get set per workload rather than per company, because a checkout path and a monthly reporting job do not deserve the same investment. Written targets turn arguments about resilience into arithmetic about cost.
Network design
Address space allocation across environments and regions, the hub and spoke or mesh decision, private connectivity to your own data centre or a partner, DNS resolution across accounts, and egress control. Address planning sounds trivial until two subsidiaries both used 10.0.0.0/16 and now the merger needs them to talk.
Identity and access design
Role structure, permission boundaries, the guardrails you enforce centrally, how CI authenticates without a stored key, how a human gets emergency access at 3am, and how all of it is logged. Least privilege designed in is cheap. Least privilege retrofitted onto a system where everything already runs as an administrator is a six month project with an outage in the middle.
A cost model tied to a business unit
Cost per tenant, per order, per thousand API calls, whatever your business actually counts. Tagging and allocation come with it, plus a written note on which architectural choices drive which line items. Once the model exists, a proposal to add a second warm region becomes a number you can weigh against the risk it removes.
Data architecture and residency
Where each class of data lives, which regions it may be replicated to, what leaves in backups and telemetry, how keys are managed and by whom, and what your subprocessor position looks like. This is where a lot of otherwise sound architectures fall apart under a customer security questionnaire.
Architecture decision records
Every significant choice gets a short record in the repository: the context, the options considered, the decision, and the consequences we accepted. We use the format Michael Nygard proposed, because it is short enough that people actually write them. This is the deliverable clients underrate at the start and quote back to us a year later, usually when a new engineer wants to know why the queue is where it is.
A build sequence your team can execute
The target architecture split into stages that each leave the system in a working state, with the dependencies between them made explicit. An architecture you can only reach through a six month big bang is not a plan, it is a wish.
Designing for Failure Domains, Zones and Regions
A failure domain is any set of things that fail together. The useful skill is spotting the ones your provider does not draw for you: a shared NAT gateway, a single deployment pipeline, one Redis instance behind six services, a certificate that expires everywhere at once. Zones are the easy part.
What an availability zone actually protects you from
An availability zone is one or more discrete data centres with independent power, cooling and networking, close enough to its siblings that synchronous replication is practical. That gets you protection from a failure with a physical cause. It gets you nothing against a bad deployment, a corrupted schema migration, an expired credential, or a provider control plane problem that spans the region. Those are the incidents most companies actually have, which is why zone redundancy is a floor and not a strategy.
Worth checking with a fresh eye: zone identifiers are scrambled per account on AWS, so your us-east-1a is not necessarily the same physical zone as your partner's us-east-1a. If you are coordinating placement across accounts, use the zone ID rather than the zone name.
The quorum problem nobody plans for
Anything that elects a leader needs a majority to survive a partition. etcd behind Kubernetes, a Kafka controller quorum, ZooKeeper, Consul, a Patroni cluster: three nodes in three zones tolerate one zone going away. Three nodes in two zones do not, because losing the zone with two of them leaves you without a majority. Teams spread compute over two zones for cost reasons and then put a quorum service on top of it, and the arrangement looks redundant right up until the moment it is tested.
Static stability, and why failover should not need a control plane
Amazon's own writing on this is the clearest source, and the principle deserves more attention than it gets. A statically stable system keeps working during a failure without needing to change anything. The opposite is a design where recovery depends on launching new instances, calling an autoscaling API, or updating DNS through a provider control plane, all of which are exactly the systems most likely to be degraded during a large event.
In practice this means pre-provisioning capacity in the surviving zones rather than planning to scale into them, keeping health checks and failover logic in the data plane, and testing whether your recovery path works when the provider console is also having a bad day. It costs money to hold capacity you are not using. That is the trade, and it should be a deliberate one.
Blast radius, cells and shuffle sharding
The question we ask about every shared component is how many customers a single bad instance of it can take down. If the answer is all of them, that component is worth partitioning. Cell based architecture splits the system into complete, independent stacks and routes each tenant to one, so a poison payload or a hot tenant damages one cell instead of the estate. Shuffle sharding, another idea AWS documented well, assigns each tenant a random combination of workers so that any two tenants rarely share the same full set, which reduces the odds that one noisy neighbour affects any specific other.
Both cost complexity. Cells duplicate infrastructure and make deployment orchestration harder. We raise them when a single tenant can plausibly hurt everyone else, which usually means multi-tenant SaaS with uneven tenant sizes, and we leave them out when the estate is small enough that one stack is honest.
Multi-region, and the RTO you can actually defend
Four patterns cover most needs, and the naming from the AWS disaster recovery guidance is as good as any. Backup and restore is cheapest and slowest. Pilot light keeps data replicating with the compute switched off. Warm standby runs a scaled down copy that can take traffic in minutes. Active-active serves from both and is the only one that survives a region loss without a decision being made by a human at 4am.
The cost curve between them is steep, and the difficulty is almost entirely in the data layer. Aurora Global Database and Cosmos DB give you managed cross region replication with documented lag. DynamoDB global tables and Cosmos multi-region writes accept writes in several places and resolve conflicts by last writer wins, which is fine for a session store and quietly wrong for an inventory count. Spanner and CockroachDB give you strong consistency across regions and charge for it in write latency. Choosing here is a business conversation about what an inconsistent record costs you, not a technology preference.
The other half is the part teams skip: a failover you have never run is a hypothesis. If nobody has taken the primary region out during business hours with the customer informed, you do not have an RTO. You have an aspiration.
Is Multi-Cloud a Mistake or a Requirement?
Both, depending on which version of it you mean. The word covers at least three different architectures with different costs, and most arguments about it are two people describing different things.
The version that is usually a mistake
Running the same workload on two providers so that either could serve it. This is the expensive one. To make it work you restrict yourself to the intersection of both platforms, which means giving up the managed services that were the reason to be on a cloud in the first place. You maintain two identity models, two network designs, two sets of security controls, two observability integrations and two on-call runbooks. Your engineers become half as good at each platform. Your provider discounts halve because your spend is split.
And the payoff usually does not arrive. A team that has never failed over to the second provider under load has bought insurance it has not tested. When a real regional event happens, the failover path is the least exercised code in the system, and the people who understand it are on the incident bridge already.
The version we push back on hardest is the one that gets decided in a board meeting after somebody else's outage made the news. The instinct is sound. The remedy is usually wrong, because in most published post-incident reports the cause was a configuration or control plane issue that a second provider would not have helped with, given the failover itself depended on the degraded plane.
When it is genuinely required
There are real cases, and they tend to be contractual or geographic rather than technical. A customer's procurement demands it and the deal is worth more than the complexity. A regulator in your sector treats concentration on one provider as a risk to be managed, which is a live topic for financial entities operating in the EU under the Digital Operational Resilience Act and something to work through with your compliance counsel rather than with us. A region you must serve has one provider and no other. An acquisition arrives already on a different cloud and rewriting it is worse than running it. Or one specific capability exists in one place: a particular database, a particular AI model with the licensing you need, a particular network product.
Notice that none of those are "so we can move if prices rise". Price movement is handled by contract negotiation and by keeping your data exportable, not by running two of everything.
The middle path most teams actually want
Single provider for the workload, multi-vendor around the edges, and portability where it is cheap. Your infrastructure code in Terraform or OpenTofu describes resources with a provider-neutral toolchain even when the resources themselves are provider-specific. Your data lives in formats and stores you can export from without a rewrite. Your container images and your application code carry no hard dependency on a proprietary runtime unless you consciously accepted one. Your CDN, your DNS, your identity provider and your observability stack can sit outside the primary cloud, which spreads the failure domains that most commonly bite without doubling the platform.
That gets you most of the resilience and almost none of the tax. When somebody asks us to design for multi-cloud, this is the version we propose first, and we ask them to write down the specific event that the expensive version would protect against.
Serverless, Containers or Virtual Machines?
This gets treated as an identity question when it is a per-workload question. Nearly every system we design ends up mixed, and the mixing is the point: put each piece where its traffic shape and its runtime want it, and stop trying to be a serverless company or a Kubernetes company.
Where serverless wins, and where it bites
Functions are excellent for spiky, event driven, idle-heavy work. Webhook receivers, image processing, scheduled jobs, glue between services, anything that runs for a few hundred milliseconds a few thousand times a day. You pay nothing when nothing happens, and you delete an entire category of patching and capacity work.
The bites are specific and worth naming. Cold starts hurt latency-sensitive paths, and they hurt most on JVM and .NET runtimes where initialisation is heavy, which is what Lambda SnapStart and provisioned concurrency exist to soften. Execution has a hard ceiling, so a long batch job is the wrong shape for it. Connection-per-invocation against a relational database will exhaust the connection limit under scale, which is why RDS Proxy exists and why a serverless front end over an unprepared Postgres is a classic self-inflicted outage. Local development and debugging are worse. And the economics invert: at low and bursty volume functions are far cheaper, at sustained high concurrency they usually are not, because you are paying a premium for elasticity you have stopped using.
Containers, and the tax that comes with the cluster
Containers are the default middle ground for good reasons: consistent packaging, mature ecosystem, no runtime lock-in worth the name, and a scaling story that fits sustained traffic. The decision inside the category is who runs the control plane. Fargate and Cloud Run take the nodes away and price per task or per request, which suits teams without a platform group. A managed Kubernetes cluster on EKS, GKE or AKS gives you scheduling, autoscaling with Karpenter or the cluster autoscaler, and an operator ecosystem, at the cost of a permanent operational commitment. Node upgrades, add-on compatibility, network plugin behaviour and version end-of-life dates do not manage themselves.
Our rule of thumb is uncomfortable for some clients and worth saying anyway: if you cannot name the person who owns cluster upgrades, you are not ready for Kubernetes. Detail on running that platform properly sits on our Kubernetes services in India and microservices pages rather than here, because this page is about whether you should have a cluster at all.
The case for boring virtual machines
Plenty of workloads belong on an instance with an autoscaling group in front of it and nothing else. Licensed software with per-core terms. Legacy applications with filesystem assumptions. Anything needing a specific kernel module, a GPU driver stack, or sustained heavy IO. Databases you have deliberately chosen to run yourself. There is no prize for containerising something that will never be scheduled twice, and moving Graviton or other ARM instances into the mix often does more for the bill than any orchestration change.
How the decision actually gets made
We take each workload and ask five things: what shape is the traffic across a week, how long does one unit of work run, does it hold state, what latency does the user actually perceive, and who will operate it at 3am. Those five answers place it. A payments API with steady traffic and a p99 target goes on containers. The nightly reconciliation goes to a scheduled task. The webhook fan-in goes to functions with a queue behind it. The reporting warehouse goes managed. Nobody has to win an argument about philosophy.
Cost Architecture: The Decisions That Set Your Bill for Years
Most cost work starts at the wrong end. Rightsizing instances and buying commitments are real, but they adjust a bill whose shape was fixed months earlier by topology. The architectural decisions below are the ones that compound.
Data movement is the line item people design without looking at
Traffic between availability zones is billed on all three major providers, in both directions on AWS, and a chatty microservice mesh spread across three zones can generate a surprising amount of it. So can a Kafka cluster with cross-zone consumers, or a cache read from a random replica. Rack-aware or zone-aware routing is not premature optimisation at that point, it is the difference between a rounding error and a monthly line item you have to explain.
The second one is NAT. Every byte your private subnets send outward through a managed NAT gateway is charged for processing on top of the transfer itself, which turns a chatty container pulling images and calling third party APIs into a real cost. Interface and gateway endpoints for the provider services you call keep that traffic off NAT entirely. This is a twenty minute design decision that quietly saves money every month for years.
Third is egress to the internet, which is where a video, media or data-heavy product finds out that its unit economics were a networking question all along. CDN offload, compression, response shaping and in some cases a storage provider with different egress terms all belong in the design conversation rather than in a panic six months later.
Storage decisions age badly
Object storage is cheap until you have five years of it with no lifecycle policy, three copies for redundancy nobody asked for, and versioning turned on with no expiry so every overwritten object is still there. Decide the classes, the transition rules and the deletion policy at design time. The same applies to block storage snapshots, which accumulate silently, and to database backups retained far beyond any policy anyone can point to. Retention is a compliance decision and a cost decision at once, and it should be written down as both.
Commitment, elasticity and the shape of your traffic
Discount instruments reward predictability. Savings Plans, reserved capacity and committed use discounts pay off when a baseline exists, and they punish you when you commit to a baseline that a re-architecture then removes. So the sequencing matters: change the architecture first, measure the new floor, commit to that, and run everything above the floor on on-demand or spot. Spot and preemptible capacity are excellent for batch, CI runners and anything checkpointed, and dangerous anywhere an interruption is user visible.
Non-production environments deserve their own paragraph because they are the easiest money on the table. Four permanently running environments where two would do, databases with production sizing for a test dataset, clusters running through nights and weekends in a single timezone company. A scheduled shutdown is unglamorous and pays immediately.
Multi-tenancy and unit cost
Whether tenants share infrastructure or get their own is simultaneously a security decision, a reliability decision and a pricing decision, which is why it belongs in architecture rather than in a product meeting. Pooled tenancy is cheaper and makes the noisy neighbour problem yours to solve. Silo tenancy isolates blast radius and satisfies the enterprise buyer who wants their own database, and it multiplies your operational surface by the number of customers. A bridge model, pooling most tiers and siloing the data store, is where a lot of B2B SaaS ends up.
Whatever you choose, tag for it from day one. If you cannot say what your largest customer costs to serve, you cannot tell whether your pricing works, and retrofitting tags across a live estate is miserable.
Observability is a cost architecture problem
Metric cardinality is the trap. Adding a user ID or a request ID as a label to a metric multiplies the series count by your user base, and per-series pricing on commercial platforms turns that into a bill that can rival compute. Debug logging left on in production, full request payload capture, and traces sampled at 100 percent do the same. Sampling strategy, log levels by environment, retention tiers and which fields are indexed versus stored are architecture decisions. We put them in the design, not in a cost review after the invoice lands.
Data Residency and Sovereignty When Your Users Are Not in India
This section is written for a buyer in London, Toronto, Sydney or Chicago who is being asked, usually by their own customer's security team, where the data goes. The answers are architectural, and the legal weight of them belongs with your counsel. We design to the position you take; we do not take it for you.
Where the data sits is a design decision, not a configuration flag
Region choice is the first control, and it is cheap to make and expensive to reverse. If your customers are European and your buyers ask about EU storage, the workload belongs in Frankfurt, Dublin, Paris or Stockholm from the start, not in Virginia with a migration ticket in the backlog. If you sell to Australian government-adjacent buyers, Sydney or Melbourne. Canadian public sector, Montreal or Toronto. UK financial services, London with a documented view on onward transfers.
The harder version is a product that must serve several jurisdictions at once. That usually means a regional data plane per jurisdiction with a thin global control plane, plus a routing layer that resolves a tenant to a region and a hard rule that data never crosses between them. Then the interesting work starts: identity, billing, support tooling and telemetry all want to be global, and every one of them is a path by which regional data escapes. A support tool that caches customer records centrally undoes the whole design. So does an error tracker with request bodies attached.
Access from India is a different question from storage in India
These get conflated constantly, and separating them removes most of the anxiety in the conversation. Storage residency is about where bytes rest. Remote access is about who can reach them and under what controls. An engineer in Mumbai holding a named identity in your directory, with scoped roles, MFA, session logging and no ability to copy data to a local machine, is a controlled access path that your own auditor can inspect. It is not a data transfer in the sense that your storage clause means, though whether it counts as one for your obligations is a question for your privacy counsel and your data protection assessment, not for an architecture page.
What we design for is the version that survives scrutiny: no shared accounts, no long-lived keys, access through a bastion or a browser-based workspace, screen-level controls where the client requires them, and a full audit trail attributable to a person. Where a client's policy simply says no access from outside a region, we say so plainly and scope the work to design and review rather than hands in the account.
Keys, and who holds them
Encryption at rest is table stakes and answers almost nothing on its own, because the question a serious buyer asks is who can decrypt and who can be compelled to. Provider-managed keys, customer-managed keys in the provider's KMS, keys in a dedicated HSM, and external key stores where the key material never enters the cloud provider at all form a ladder of increasing control and increasing operational risk. Losing an external key means losing the data, and that trade needs to be explicit.
The sovereign offerings from the major providers, along with EU data boundary commitments and assured workload controls, keep changing. We check the current documentation and contractual terms during the engagement rather than quoting a position from memory, because this is an area where a year-old assumption is a liability.
What we will not do
We will not tell you that a design makes you compliant with GDPR, HIPAA, the Australian Privacy Principles, PIPEDA or India's data protection regime. Compliance is a determination made by people with professional liability for it. What we do is build the architecture your legal position requires, document where every class of data lives and moves, and give your counsel and your auditors something precise to assess. When a customer questionnaire asks where personal data is stored and which subprocessors touch it, you should be able to answer from the design document.
Network Topology and Private Connectivity
Network design is the part of cloud architecture with the longest half-life. Applications get rewritten. Address space does not.
Address planning, done once
Allocate CIDR ranges across environments, regions and business units before the first VPC, with room to grow and no overlap. Overlapping RFC 1918 ranges are the reason two systems that should talk cannot, and the fix is either NAT gymnastics or a renumbering project with downtime. If there is any chance of acquiring or being acquired, leave gaps. If you have IPv6 anywhere in your future, decide now rather than bolting it on.
Hub and spoke, and where peering runs out
VPC peering is simple, cheap and non-transitive, which means it scales as a mesh: connecting n networks needs n squared links and a route table entry per pair. That is fine at four networks and unmanageable at forty. A transit hub, whether AWS Transit Gateway, Azure Virtual WAN or a Google network hub, centralises routing, inspection and hybrid connectivity at a per-attachment and per-gigabyte cost. The switch point is usually somewhere between six and twelve networks, and it is much easier to start with the hub than to migrate to one later.
Private endpoints instead of a public path
Traffic from your application to a provider service or a partner SaaS does not need to touch the internet. PrivateLink, Private Service Connect and Azure Private Link put a private address for that service inside your own network, which removes an internet path, satisfies a security questionnaire, and takes the traffic off NAT. The cost is per endpoint per hour plus data processed, so you choose them deliberately rather than by default. DNS is where this gets fiddly: private hosted zones, resolver rules and forwarding between accounts need designing or you will spend a week debugging why one subnet resolves a name differently from another.
Controlling what leaves
Most teams filter inbound traffic carefully and let outbound go anywhere, which is exactly backwards from the perspective of data exfiltration and dependency risk. Egress control through a managed firewall or a proxy with an allow list, endpoint policies that restrict which buckets a network can reach, and organisation-level guardrails that block traffic to unapproved regions are the controls that turn a compromised container into a contained event. They also break things loudly the first week they are on, so they get staged with a logging-only phase first.
Hybrid connectivity back to your own data centre or a colocation facility follows the same logic. A dedicated circuit gives predictable latency and better egress terms. A site-to-site VPN over the internet is faster to stand up and cheaper. Running the VPN as a backup path for the circuit is the pattern we usually recommend, and it is worth testing that the backup path actually carries production load before you need it to.
Identity and Least Privilege at Design Time
Access control designed in costs a fraction of access control retrofitted, and everyone knows this, and it still gets deferred because on day one there is one engineer and one account.
Account boundaries are your strongest control
A permission mistake inside an account is a bug. A permission mistake across an account boundary is much harder to make, because the boundary is enforced by the provider rather than by your policy authorship. So production gets its own account or subscription, and so does anything holding regulated data, and so does the security tooling that watches the rest. Service control policies at the organisation level then set the rules nobody can escape, including the ones with administrator rights: no disabling of audit logging, no deployments to unapproved regions, no deletion of the log archive. Guardrails that even the root of an account cannot bypass are worth more than a hundred carefully written role policies.
No long-lived keys anywhere in a pipeline
Static cloud credentials sitting in a CI system are the single most common finding when we read a new client's setup, and they are also the easiest thing on this page to fix. OIDC federation lets GitHub Actions, GitLab or your build system assume a role scoped to a specific repository and branch with a short-lived token. Inside a cluster, workloads get identity through IAM roles for service accounts or pod identity on AWS, workload identity federation on Google, and managed identities on Azure. Applications read secrets from a managed store at runtime instead of carrying them in environment variables baked into an image.
Human access and the 3am path
Day to day, engineers should hold no standing production write access. They get scoped, time-bound elevation through your identity provider with the reason recorded, and everything they do is attributable to a named person in the audit log. Then there is the break-glass path for the night the identity provider itself is broken: a separate credential, hardware MFA, stored where two people must cooperate to use it, alerting loudly when it is touched, and tested on a schedule so that its first use is not during an incident. Policy generation from observed activity, using tools like IAM Access Analyzer, then lets you tighten roles based on what was actually called rather than what somebody guessed at the start.
If identity is the whole problem rather than a slice of it, that work sits on our identity and access management page.
Three Situations We Get Called Into
These are patterns, not client stories. Each one describes a shape we have seen enough times to recognise from the first call, and what the fix normally looks like.
The single-zone database under a three-zone cluster
You run a B2B application on a managed Kubernetes cluster with nodes spread across three zones, and everyone assumes the system is zone-redundant. It is not. The primary Postgres instance was created as a single-AZ deployment during a rushed migration, the Redis cache is one node, and the message broker has two brokers because a third looked wasteful. A zone impairment takes the database offline, the application pods stay healthy and keep retrying, connection pools saturate, and a partial infrastructure failure becomes a total outage.
The work here is not glamorous. Convert the database to a multi-zone deployment with a tested failover, understanding that the failover itself causes a short connection reset that the application must handle rather than log and die on. Move the broker to a three-node quorum across three zones. Give the cache a replica and, more to the point, make the application survive a cold cache without stampeding the database, because a cache failover with no request coalescing is its own outage. Then set pod topology spread constraints so a zone loss does not concentrate the survivors on one node group. Along the way, measure the cross-zone traffic you have created and decide whether zone-aware routing is worth it. The whole thing typically lands in three to five weeks of design plus staged change windows, and the deliverable that matters is the tested failover, not the diagram.
The EU deal the US-only architecture cannot sign
You are a Series A SaaS company in North America. Everything runs in one region, one account, one Postgres cluster with a tenant_id column. A large German customer arrives with a data processing agreement that requires EU storage, and your sales team has already promised it is fine.
The fix is a regional data plane. Stand up the EU region with its own database, object storage and processing, keep a small global control plane for signup, routing and billing metadata, and add a tenant-to-region resolver at the edge so a request lands in the right place before it touches anything stateful. Then do the unglamorous audit: every third party integration, every log line, every analytics event, every backup destination, every support tool that caches a customer record. Those are the leaks. Error tracking with request bodies attached is the one that catches people most often. Key management gets decided here too, along with whether the EU tenants need their own keys.
The engineering is a few weeks. The audit is what takes the time, and it is the part that determines whether the answer you give the customer's security team is true.
The serverless bill that outgrew the revenue
You built fast on API Gateway and Lambda, which was the right call at 5,000 requests a day. At 5 million the shape has changed. A handful of endpoints now run at sustained concurrency, each invocation opens its own database connection, a third party call inside the request path pushes p99 past two seconds, and the per-request pricing that was invisible at launch is now the second biggest line on the invoice.
Rather than a rewrite, we split by traffic shape. The three hot endpoints move to containers with steady autoscaling and a pooled connection story, which usually cuts both the cost and the tail latency for those paths. The genuinely spiky work stays on functions. The third party call comes out of the request path onto a queue with idempotency keys and a dead letter destination, so the user gets a fast response and a retry becomes a background problem rather than a timeout. Connection handling gets a proxy in front of the database. The result is a mixed architecture that looks less tidy on a diagram and costs materially less to run, and the migration happens endpoint by endpoint with traffic shifted gradually rather than in one cut.
Well-Architected Review as a Habit, Not an Event
AWS, Azure and Google all publish an architecture framework, and they agree on most of it: operational excellence, security, reliability, performance, cost, and increasingly sustainability. The frameworks are good. The way they usually get used is not, because a review that produces a PDF with a score and no owner changes nothing.
What a review should produce
A ranked list of risks, each with a workload attached, a named owner, a rough effort, and a decision recorded as accept, mitigate or fix now. High risks get a date. Accepted risks get a line explaining the reasoning, which is the entry that saves an argument eighteen months later when somebody asks why the reporting database has no replica. We run the questions as a conversation with the engineers who operate the workload, not as a form sent to an architect, because the useful answers come from whoever was awake for the last incident.
Which workloads and how often
Review per workload, starting with whatever is closest to revenue and whatever has the widest blast radius. A first review when the design is agreed, another before a launch or a seasonal traffic peak, then a standing cadence of roughly twice a year, plus one whenever the workload changes shape: a new region, a new data class, a major dependency, a tenfold traffic change. Between reviews, the cheap version is a monthly look at what changed in the account against what the design says should have changed. Drift is where risk accumulates quietly.
What Separates a Diagram From an Architecture That Survives Traffic
A diagram is a claim about structure. An architecture is a claim about behaviour under load and under failure, and the gap between the two is where the work is.
Start with a capacity model rather than a shape. How many requests at peak, what is the read to write ratio, how big is the payload, what is the concurrency at the database, how many connections does that imply, and what is the slowest thing in the path. Those numbers turn "we will scale horizontally" into an actual limit. Almost every system has one component that cannot scale horizontally, and knowing which one it is beats any amount of confidence.
Then the interaction rules, which is where the outage in the first section came from. Every outbound call gets a timeout shorter than the caller's own deadline. Retries get exponential backoff with jitter and a budget, because synchronised retries are how a brief blip becomes a retry storm. Circuit breakers open on a failing dependency so the caller fails fast instead of queueing. Anything that mutates gets an idempotency key so a retry is safe. Queues get dead letter destinations and someone who looks at them. Health checks report whether the instance can actually serve work, not whether the process is alive, and they do not share a connection pool with real traffic.
Then the quota check, which people forget entirely. Provider accounts have limits on concurrent function executions, API request rates, network interfaces, instances per family and per region. A design that only works above your current quota is a design that fails at the moment it succeeds. Read the limits, request increases before launch, and put alarms on approach rather than on breach.
And then you test it. A load test with k6, Gatling or Locust against a realistic data volume, not a hundred-row test database, because query plans change with cardinality and the plan that works on a laptop can table-scan in production. A failure exercise where the primary database is taken out on purpose. A restore from backup timed end to end, since a backup nobody has restored is a file, not a recovery plan. None of that is exotic. It is simply the difference between a design you believe and a design you have evidence for. The operational discipline that follows, on-call rotas, error budgets and incident review, belongs to site reliability engineering and works best when it is staffed alongside the architecture work rather than after it.
How the Engagement Runs
Sequence varies with what you already have. This is the usual shape for a company with a live system and a specific pressure, whether that is cost, a compliance question, a reliability problem or a growth wall.
Discovery, roughly the first two weeks
Read-only access to the account, plus interviews with the engineers who operate it and whoever owns the commercial pressure driving the work. We pull the resource inventory, the IAM graph, the network layout, the billing detail and the incident history, and we spend a session on the things that are not in any of those: what people are afraid to touch, what the last big outage actually was, which customer conversation is stuck. Output is a current state document with a risk list, and it is deliberately blunt.
Target design and decision records
Two to four weeks depending on scope. The target architecture, the topology decisions, the failure domain map with RTO and RPO per workload, the cost model, and the decision records behind each significant choice. We bring options rather than a single answer where the trade-off is genuinely yours to make, and we say which one we would pick and why. Review happens in your repository as a pull request against markdown and diagram source, so comments are threaded and the discussion survives.
Sequencing and the first slice
The plan gets split into stages that each leave the system working, with dependencies drawn and the risky ones flagged. Then we build the first slice with your team, usually the landing zone or whichever change unblocks the rest, so the design gets tested against reality early instead of at the end.
Ongoing review
Once the shape is set, the useful cadence is a standing architecture review: new designs read before they are built, drift from the agreed topology flagged, and the decision record set kept current. That can be a few days a month rather than a full-time presence, and it is where a lot of clients end up after the initial build.
How We Run Cloud Architecture Work From India
The honest version, including the parts that are inconvenient.
The overlap window, with real numbers
India runs on IST, which is UTC+5:30, and a standard day of 09:30 to 18:30 IST maps to 05:00 to 14:00 in London during British Summer Time. That is a good five hours against a UK working day. Against Sydney, the same Indian day covers roughly 14:00 to 23:00 local, so you get about three hours in the Australian afternoon. Auckland gets less, closer to two.
US Eastern is the difficult one and pretending otherwise wastes everybody's time. A standard Indian day ends before New York starts. To get real overlap the team shifts: 13:30 to 22:30 IST lands as 04:00 to 13:00 Eastern, giving four working hours against a normal morning there. That shift is genuinely harder on the people doing it, it affects who will take the role and for how long, so it is agreed with you up front rather than assumed. For US Pacific the arithmetic is worse again, and the honest answer is usually a two to three hour window plus a heavier written handover, not a full shift.
Architecture work tolerates thin overlap better than incident response does, which is the one genuinely good piece of news here. The deliverables are documents, diagrams and code that you read on your own time. What needs live hours is the decision conversation, and that is a couple of scheduled sessions a week rather than continuous presence.
What happens in the hours you are asleep
Written handover at the end of the Indian day covering what moved, what is blocked and what needs a decision from you, posted where your team already works rather than in a separate tool. Questions that would block the next day get asked before the window closes, not after. Anything ambiguous gets a proposed answer attached so you can approve rather than compose, which is the single biggest difference between a low-overlap engagement that works and one that stalls for 24 hours at a time.
How the work stays reviewable
Design lives in your repository as markdown and diagram source, not in a slide deck. Decision records go through pull requests. Infrastructure changes are proposed as code with a plan output attached so you can see exactly what would change before it does. Weekly, you get a short written note on progress against the sequence, decisions taken, and anything that has become a risk. If your team cannot audit our work without a meeting, the process is wrong.
The people, and how they are assessed
Cloud architecture is a senior job, so the vetting is about judgement rather than syntax. We test with real scenarios: here is a system, here is what broke, tell us what you would change and what you would deliberately not change. Provider certifications are a floor and not evidence. Written communication gets weighted heavily, because in a low-overlap engagement your architect's writing is the product you actually consume. The person who did the design work is the person on your calls, and if that changes you are told before it changes.
Risks, and the Honest Answers
"How do I know the quality is there when I cannot see the work?"
You see the work, because it arrives as reviewable artifacts rather than status updates. Every design decision is a document you can argue with, every infrastructure change is a diff with a plan attached, and the risk list is ranked with our reasoning visible. The failure mode to watch for is not bad engineers. It is an architecture accepted without being understood, which is why we ask your team to challenge the decision records rather than sign them off. If nobody on your side pushes back in the first month, we usually ask why.
"Who owns what we build?"
You do, and it should be written into the agreement before work starts. IP assignment, confidentiality and data handling terms belong in the MSA and the associated agreements, and they get settled with your legal team rather than described on a web page. What we can say about the shape of it: everything is built in your accounts and your repositories, using your identity provider, so there is no artifact of the work that sits somewhere you cannot reach.
"What if it does not work out?"
The design is in your repository from day one, which is the practical protection. Handover terms, notice and transition arrangements are set in the agreement before the engagement starts, and we would rather you negotiate them properly than take a number off a marketing page. The engineering answer is that we build so that leaving is undramatic: no undocumented state, no tooling only we can run, no decision whose reasoning exists only in someone's head, and infrastructure code your team can apply without us.
"What are the costs I am not seeing?"
Ramp-up is real. An architect landing on an unfamiliar estate spends the first fortnight reading rather than producing, and any proposal that skips discovery is hiding that cost rather than removing it. Your own team's time is the second one: architecture work needs your engineers in review sessions, and a design nobody on your side engaged with does not survive contact with the first sprint. Third, the changes themselves cost money to run during transition, because a migration usually means paying for both shapes at once for a while. We put that in the cost model rather than letting it arrive as a surprise on the invoice.
"How is security handled on your side?"
Named identities in your directory, no shared logins, MFA enforced by your policy rather than ours, access through the path you specify, and every action attributable in your audit log. Access is scoped to what the current piece of work needs and removed when it ends. Where you require managed devices, restricted networks or additional controls, that gets agreed and documented before anyone gets access. We do not claim certifications we do not hold, and where your buyer requires a specific attestation you should ask for the evidence rather than a reassurance.
Engagement Models
Three shapes cover almost everything. Which one fits depends on whether you have a question, a project, or an ongoing gap.
Architecture review and assessment
A time-boxed read of what you have, ending in a current state document, a ranked risk list, a target design and a sequenced plan. This is the right start when the pressure is a specific event: a funding round, a security questionnaire, a cost problem you cannot explain, or a launch that scares you. Plenty of clients stop here, take the plan to their own team, and come back later.
Scoped design and build
A defined outcome with a defined boundary: a landing zone, a multi-region design implemented, a serverless-to-container migration for a named set of services, a residency split for a new market. Deliverables, sequence and acceptance are agreed before work starts, and the architecture work runs alongside implementation rather than being thrown over a wall.
Embedded architect, retained
An architect working inside your team on a continuing basis: reviewing designs before they are built, keeping the decision records current, watching drift, and being available for the conversations that come up mid-sprint. Often part-time. This is what most clients want after the first project, because the expensive mistakes are the ones made quietly between reviews. If what you need is engineering capacity rather than architecture judgement, staffing through DevOps developers in India or AWS developers in India is the cheaper answer and we will say so.
Where This Sits Alongside Our Other Work
Architecture sets the shape. The build and the running of it happen next door. If the immediate job is getting existing systems onto a cloud rather than designing the target, that is cloud migration in India, and the two usually run together with the design a week or two ahead. Turning the agreed topology into code is covered by infrastructure as code in India, the delivery path that ships it by CI/CD pipelines in India, and the operational side once it is live by site reliability engineering in India.
Frequently Asked Questions About Cloud Architecture in India
What does a cloud architect actually produce that an engineer does not?
Decisions with their reasoning attached, and the constraints that keep the build honest. That means an account and network topology, a failure domain map with a stated RTO and RPO per workload, a cost model tied to a unit of business volume, an identity design, and a set of architecture decision records naming what was rejected and why. Engineers then build against it. Without the decision records, the third engineer to join re-litigates every choice from scratch.
Should we design for multi-cloud from day one?
Almost never. Designing for portability before you have a working product costs you every managed service worth using and doubles the surface you have to secure and staff. Keep the portable parts portable, which is mostly your data and your infrastructure code, and stay on one provider until something concrete forces the second: a contract clause, a regulator, a region only one provider serves, or a capability that genuinely exists nowhere else.
How do you decide between serverless, containers and virtual machines?
Per workload, using traffic shape and runtime duration rather than company policy. Spiky, event driven and idle-heavy work suits Lambda or Cloud Run. Sustained throughput with steady concurrency is usually cheaper and more predictable on Fargate or a managed Kubernetes node pool. Long running stateful things, licensed software and anything needing exotic kernel or GPU configuration stay on virtual machines. Most systems end up mixed, and that is fine.
Can our data stay in the EU or Australia if the engineers are in India?
Yes, and that is the arrangement we design for by default. Storage and compute stay in the region you choose. Indian engineers get named identities in your directory, work through your access path, and are logged the same way any employee would be. Data residency and remote access are separate questions and should be answered separately in your data protection assessment. Where the answer has legal weight, your counsel makes the call, not us.
How much overlap do we get with a team in India?
On a standard 09:30 to 18:30 IST day you get roughly five hours with London and about three with Sydney. With US Eastern you get almost none, so the team shifts. A 13:30 to 22:30 IST day lands as 04:00 to 13:00 in New York, which gives four hours against a normal morning there. That shift is real work for the people doing it, so the window is agreed with you before the engagement starts.
What is a well-architected review and how often should we run one?
It is a structured walk through a workload against the pillars in the AWS, Azure or Google architecture frameworks, producing a ranked list of risks with owners rather than a score. Run it per workload, not per company: once when the design is agreed, once before the first significant traffic event, and then roughly twice a year or whenever the workload changes shape. Reviews that produce a document nobody assigns are theatre.
Which cloud costs are set by architecture rather than by usage?
Data movement, redundancy and topology. Cross zone chatter between services, NAT gateway processing on every outbound call, internet egress to customers, replicas you keep warm, log and metric cardinality, and the number of always-on clusters you decided to run. Those are chosen once at design time and then billed forever. Instance sizing and commitment discounts, which is where most cost projects start, move a much smaller share of the bill.
We already have an architecture diagram. What would you do differently?
Ask what happens when each box on it fails, and check whether the answer has ever been tested. Most diagrams show the happy path and hide the dependencies that matter: a control plane call in the failover path, a shared database behind two services drawn as independent, a queue with no dead letter destination. We turn the diagram into a failure inventory first, and only then argue about the target state.