DEV Community: Ronak Sharma

Legacy Infrastructure vs. Cloud Infrastructure: Cost and Performance Comparison

Ronak Sharma — Tue, 22 Sep 2026 10:31:42 +0000

This comparison gets oversimplified constantly in both directions cloud advocates presenting migration as an obvious, universal win, and legacy infrastructure defenders pointing to sunk costs as though they were a genuine ongoing advantage. Neither framing holds up to an honest, specific comparison, because the right answer genuinely depends on workload characteristics that vary enormously between businesses.

My position: the comparison that actually matters isn't "legacy versus cloud" in the abstract it's the fully-loaded cost and performance profile of your specific current infrastructure against the fully-loaded profile of a specific cloud alternative, for your specific workloads. Generic comparisons mislead precisely because they skip this specificity.

The Cost Comparison Most Businesses Get Wrong

Legacy on-premises infrastructure cost comparisons frequently only count the visible hardware cost servers, storage, networking equipment against a cloud invoice, which is a genuinely unfair comparison in cloud's favor. The fully-loaded cost of on-premises infrastructure includes power, cooling, facility overhead, and the staff time required to maintain it, none of which shows up on the same simple line item as the hardware purchase price.

Conversely, cloud cost comparisons frequently understate genuine cloud costs by comparing against list pricing without accounting for data transfer charges, the cost of un-optimized resources that accumulate over time, or the genuine operational cost of managing cloud infrastructure well, which despite marketing suggesting otherwise still requires real expertise and real ongoing attention.

Performance Characteristics Genuinely Differ by Workload Type

Latency-sensitive workloads with predictable, steady demand sometimes perform better on dedicated legacy infrastructure, where there's no multi-tenancy or virtualization overhead and no dependency on internet connectivity between the application and its data. Workloads with genuinely variable or unpredictable demand tend to perform better, and cost less, on cloud infrastructure that can scale elastically rather than sitting provisioned for peak capacity around the clock regardless of actual current load.

This means the honest answer to "which performs better" is genuinely workload-dependent, and a business running a mix of both workload types may reasonably keep some infrastructure on-premises while moving other workloads to the cloud, rather than treating the decision as binary across the entire environment.

Legacy Infrastructure's Genuine, Often-Overlooked Advantages

It's worth naming these directly rather than treating legacy infrastructure as purely a cost center to be eliminated. Predictable, already-depreciated hardware has a genuinely known, stable cost profile that doesn't fluctuate with usage the way cloud billing can. Data residency and compliance requirements are sometimes genuinely simpler to satisfy with infrastructure under direct physical control. And workloads with extremely high, sustained, predictable utilization can sometimes be genuinely cheaper on owned hardware than on cloud infrastructure billed for that same sustained usage indefinitely.

Cloud Infrastructure's Genuine, Often-Oversold Advantages

Elasticity is real and valuable specifically for variable workloads the ability to scale up for a demand spike and back down afterward, paying only for what's actually used, genuinely beats provisioning for peak capacity permanently. Reduced operational burden is real for organizations that don't want to manage physical hardware, though it's worth being honest that cloud infrastructure still requires genuine expertise to manage well, just a different kind than physical hardware maintenance requires. And genuine geographic distribution and disaster recovery capability is more accessible on cloud infrastructure than it traditionally was requiring dedicated secondary physical data centers.

The Migration Cost Itself Deserves Honest Accounting

A comparison that only weighs ongoing cost after migration, without genuinely accounting for the migration project's own cost and risk, overstates cloud's advantage for infrastructure that's currently working adequately. Migration carries real cost, real risk, and real disruption, and that cost needs to be weighed against the ongoing savings a migration would eventually produce sometimes the payback period is genuinely short and clearly worth it, and sometimes it's long enough that the migration isn't actually the right near-term priority even if cloud infrastructure would be cheaper in a pure steady-state comparison.

What an Honest Comparison Actually Requires

Fully-loaded on-premises cost, including power, cooling, facilities, and staff time, not just visible hardware cost

Genuinely comprehensive cloud cost, including data transfer, resource optimization overhead, and real operational management effort

Workload-specific performance evaluation, recognizing that the right answer varies by actual usage pattern rather than applying one universal conclusion

Honest accounting of legacy infrastructure's genuine advantages, not treating it as purely a liability to be eliminated

Realistic migration cost and risk factored into the comparison, not just steady-state costs after an assumed-frictionless transition

The Actual Point

There's no universally correct answer to legacy versus cloud, and any comparison that hands you one without genuinely accounting for your specific workloads, your specific current infrastructure's fully-loaded cost, and your specific migration risk is oversimplifying in whichever direction serves the argument being made. The businesses making this decision well aren't the ones who picked a side ideologically they're the ones who ran the actual, honest, workload-specific numbers before deciding.

Enterprise Infrastructure Operations | ArclogiQ

Optimize your cloud spend, achieve absolute regulatory compliance, and build secure, high-performance network environments.

arclogiq.com

Infrastructure Modernization: When and How to Upgrade Legacy Systems

Ronak Sharma — Tue, 22 Sep 2026 10:27:46 +0000

The question everyone actually wants answered isn't "how do we modernize" it's "how do we know it's actually time." That's a harder, more honest question, and most modernization conversations skip straight past it into roadmap-building, which means a lot of modernization projects start before anyone's actually confirmed they're solving a real, current problem rather than chasing a newer technology because it feels overdue.

My take: the right time to modernize isn't a fixed age threshold, and it isn't "whenever budget allows." It's when the genuine risk of not modernizing security exposure, vendor support ending, a specific business need the current system can't support outweighs the genuine cost and disruption of the project itself. That's a real, calculable comparison, not a vibe.

The Question That Actually Matters: Risk, Not Age

A ten-year-old system running stable, well-understood operations with no known vulnerabilities is a lower priority than a five-year-old system that's stopped getting security patches and sits in a path that touches sensitive data. Age feels like the obvious sorting criterion and it's genuinely a poor one on its own what actually matters is what happens if this specific thing fails or gets exploited, not how many birthdays it's had.

Signs It's Genuinely Time, Not Just Tempting

Vendor support ending is the clearest, least debatable signal unsupported infrastructure has no path to a fix if something breaks, which is a fundamentally different risk than "old but still supported." A specific, known business need the current system genuinely can't support a new compliance requirement, a scale the system wasn't built for is another clear one. General discomfort with something feeling old, without either of these concrete triggers attached, is worth being honest with yourself about; that's an aesthetic preference, not a business case.

Don't Start With the Technology You're Excited About

This is the trap that catches even genuinely well-intentioned modernization efforts. Someone gets excited about a specific platform or architecture pattern, and the project gets built backward from that excitement rather than forward from an honest assessment of what's actually broken. Start with the assessment what's genuinely at risk, what's genuinely blocking the business and let the technology choice follow from that, not the other way around.

Sequence by Consequence, Not by What's Easiest

The natural instinct is to modernize whatever's simplest first, because it produces a quick, visible win. That instinct routinely leaves the genuinely highest-risk systems sitting untouched the longest, precisely because they're also the hardest and scariest to approach. Rank by what would actually hurt the business most if left alone, not by what would feel most satisfying to check off first.

Fix the Actual Architecture, Not Just the Component's Age

Modernizing hardware while carrying forward the exact same design mistakes that created the original risk gets you infrastructure that's genuinely newer and not meaningfully safer. If segmentation was missing before, build it in now. If nobody documented how the thing actually works, document it as part of the deployment, not as a nice-to-have that gets skipped once the technical work feels done.

Get the Full Budget Approved Upfront, Not Phase by Phase

A modernization effort that gets phase-one budget approved, executes well, and then has to fight for phase-two funding as a brand-new request months later frequently loses momentum right there. Present the whole roadmap and its whole cost at the start, even if execution genuinely spans a year or more it's a harder conversation on day one and a much easier one than explaining, eight months in, why funding for "the thing we already started" needs to be requested again.

Test Like the Business Is Actually Depending on It, Because It Is

Every phase deserves staging before anything touches live production, sequenced by genuine dependency, with a rollback plan specific enough to actually execute under pressure not a vague intention to "roll back if needed." This is the part that determines whether a well-planned roadmap survives contact with a real, live environment or turns into an extended incident halfway through what was supposed to be routine.

What This Actually Requires

An honest risk assessment before any technology decision, sorted by genuine consequence, not component age

Concrete triggers vendor support ending, a specific business need distinguished from general discomfort with something feeling old

Prioritization by actual impact, not by what's easiest or most satisfying to fix first

Architectural problems fixed during modernization, not carried forward in newer hardware

The full roadmap and budget presented upfront, not phase by phase

Real testing and rollback discipline, treating every live change with the caution production infrastructure actually deserves

The Actual Point

Infrastructure modernization done well isn't really a technology upgrade project it's a sequenced set of honest decisions about where the real risk actually sits, and getting that sequence right matters more than which specific platform or architecture you eventually choose. Get the sequence wrong, and even excellent technology choices land in a worse order than mediocre ones applied where they actually needed to go first.

Enterprise Infrastructure Operations | ArclogiQ

Optimize your cloud spend, achieve absolute regulatory compliance, and build secure, high-performance network environments.

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="https://www.arclogiq.com/images/arclogiq-logo-2.png"
          loading="lazy" />
      arclogiq.com
    </div>
  </div>
</div>

Disaster Recovery Planning for Network Infrastructure

Ronak Sharma — Tue, 22 Sep 2026 10:22:57 +0000

Most disaster recovery conversations spend their time on servers, data, and applications, and the network connecting all of it together gets treated like a given something that'll obviously just be there when everything else needs to come back online. That assumption is exactly the wrong way around. If the network's down, it doesn't matter how well everything else recovers, because none of it can actually be reached.

I'll say this plainly: network DR deserves its own real, separate planning, not a line item folded into the broader application recovery conversation. The network is the layer everything else depends on being reachable through, and a DR plan that's thorough about servers and vague about network connectivity is missing the part that determines whether any of the rest of the plan actually matters.

Network Failure Doesn't Always Look Like "The Network Is Down"

A server either failed or it didn't that's usually a clean, binary thing to plan around. Network failure is messier. It can mean fully down, or it can mean degraded some traffic getting through fine, some paths failing, a routing issue that only affects certain destinations, a DNS problem that makes everything technically reachable and practically useless. A DR plan built only around the binary "network is completely down" scenario misses the messier, more common failure modes that are genuinely harder to diagnose and just as disruptive.

Redundant Doesn't Mean What People Assume It Means

Two internet connections is not automatically genuine redundancy. If both connections happen to run through the same facility, or depend on the same upstream provider a few hops up, you've got two paths that fail together the moment that shared point fails. Real redundancy means actually verifying independence different providers, different physical routes, different points where something could go wrong not just counting connections and assuming more equals safer.

DNS Needs Its Own Line in the Plan

It's easy to assume DNS is just part of "the network" and gets covered by whatever general network redundancy exists. It deserves better than that assumption, because a DNS failure specifically can make an entire, otherwise healthy environment appear completely unreachable. Give DNS its own explicit redundancy plan rather than folding it quietly into general network resilience and hoping it's covered.

Actually Test the Failover, Don't Just Trust the Configuration

Configuring a backup path and never actually forcing traffic onto it is close to not having a backup path at all you have a belief about what would happen, not a verified fact. Regular, real failover testing, actually watching the backup path carry genuine load under realistic conditions, is what separates a network DR plan that works from one that just looks complete on paper.

Know Exactly What Your Redundancy Actually Covers

Redundant connections within a single building protect against a piece of equipment or a single connection failing. They do nothing if the whole building loses power or the whole region has a genuine, broader outage. Being honest internally about which scenarios your setup actually protects against not what everyone assumes it protects against matters more than most DR conversations give it credit for, because the gap between assumption and reality is exactly where a plan fails when it's actually needed.

Give the Network Its Own Recovery Time Target

Applications get a recovery time objective. The network needs one too, and it needs to be realistic against what the network can actually deliver because if the network takes longer to come back than the applications sitting on top of it were promised, those application-level promises were never actually achievable in the first place, no matter how solid the application recovery plan looks on its own.

What This Actually Requires

Planning for degraded, partial failure, not just a clean "network is down" scenario

Genuinely verified independence for redundant connections, not just a count of how many exist

DNS treated as its own explicit line item, not an assumption inherited from general network redundancy

Real, regular failover testing, not configuration trusted without ever being triggered

Honesty about which specific failure scenarios your setup actually protects against

A realistic, explicit recovery time target for the network itself, coordinated with what applications are being promised

The Actual Point

A disaster recovery plan that's thorough about everything except the network is missing the one layer that determines whether the rest of the plan can actually be reached at all. Give the network the same explicit planning, the same honest scenario coverage, and the same real testing as everything else in the recovery strategy not an assumption that connectivity will simply be there because it always has been before.

Disaster Recovery Planning for Network Infrastructure

Ronak Sharma — Fri, 18 Sep 2026 12:57:08 +0000

Network Failure Doesn't Always Look Like "The Network Is Down"

Redundant Doesn't Mean What People Assume It Means

DNS Needs Its Own Line in the Plan

Actually Test the Failover, Don't Just Trust the Configuration

Know Exactly What Your Redundancy Actually Covers

Give the Network Its Own Recovery Time Target

What This Actually Requires

Planning for degraded, partial failure, not just a clean "network is down" scenario

Genuinely verified independence for redundant connections, not just a count of how many exist

DNS treated as its own explicit line item, not an assumption inherited from general network redundancy

Real, regular failover testing, not configuration trusted without ever being triggered

Honesty about which specific failure scenarios your setup actually protects against

A realistic, explicit recovery time target for the network itself, coordinated with what applications are being promised

The Actual Point

Network Redundancy: How to Eliminate Single Points of Failure

Ronak Sharma — Fri, 18 Sep 2026 12:29:26 +0000

Everybody knows single points of failure are bad. That's not the part anyone actually needs convincing of. The part that's genuinely hard is finding them, because they're rarely sitting somewhere obvious with a sign on them — they're usually hiding one or two layers underneath something that looks perfectly redundant on the surface, and finding them requires a specific kind of stubborn, methodical tracing that most network reviews don't actually do.

My honest take: most networks that call themselves redundant have at least one genuine single point of failure nobody's found yet, hiding not because anyone was careless, but because finding it requires actually tracing every dependency rather than trusting that redundant-looking components are genuinely independent of each other.

Start by Asking "What Else Does This Depend On"

The most common way a single point of failure hides is through a shared dependency underneath two things that look independent. Two internet connections from two different providers sounds genuinely redundant — until you find out both providers' physical lines run through the same conduit under the same street, and a single construction accident takes out both simultaneously. The redundancy was real at the logical level and completely absent at the physical level, and nobody found that out until they went looking specifically for it.

The habit worth building: for anything you believe is redundant, keep asking "and what does that depend on" until you hit something that's genuinely, physically independent, not just administratively labeled as a separate thing.

Power Is the Classic Overlooked Single Point of Failure

Redundant servers, redundant network paths, redundant everything — running off a single power circuit or a single UPS. This is one of the most common findings in real network reviews, and it's genuinely embarrassing once found, because everyone assumed the technical redundancy meant something was covered when the actual vulnerability was sitting one layer down in the electrical infrastructure nobody thought to check.

DNS Deserves Its Own Dedicated Hunt

DNS failure can take down an entire, otherwise perfectly healthy network, because everything depends on being able to resolve names to addresses before any of the rest of the redundancy even gets a chance to matter. DNS redundancy needs to be checked as its own specific item, not assumed to inherit whatever general redundancy exists elsewhere in the network, because it's foundational enough that a gap here undermines every other redundant system you've built.

The Human Single Point of Failure Nobody Wants to Talk About

This one's uncomfortable and worth saying anyway: if the one person who genuinely understands how a specific piece of your network is configured left tomorrow, how long would it take everyone else to safely operate or fix it? That's a real single point of failure too, and it's exactly as dangerous as an unredundant switch, just harder to put on an architecture diagram. Documentation is the fix, and it's consistently the fix that gets skipped because it doesn't feel as urgent as the technical work.

Testing Is How You Actually Find the Ones You Missed

Reviewing a diagram finds the single points of failure someone thought to draw accurately. Actually testing — forcing a specific component offline and watching what genuinely happens — finds the ones that weren't obvious from the diagram at all, including the shared conduit, the shared power circuit, the dependency nobody remembered existed until it suddenly mattered.

What This Actually Requires

Tracing every "redundant" component down to genuine physical and logical independence, not stopping once something looks administratively separate
Checking power infrastructure specifically, since it's one of the most common places redundancy quietly fails underneath otherwise-redundant systems
Treating DNS as its own dedicated redundancy item, not an inherited assumption
Recognizing concentrated human knowledge as a genuine single point of failure, addressed through real documentation
Actually testing by forcing components offline, not just reviewing configuration and trusting it

The Actual Point

Single points of failure survive not because anyone's careless, but because finding them requires a specific, patient discipline most reviews skip in favor of confirming things look redundant on paper. The networks that genuinely eliminate them aren't the ones with the most redundant-looking diagrams — they're the ones who kept asking "what else does this depend on" until they ran out of layers to check.

How to Design High Availability Network Infrastructure

Ronak Sharma — Thu, 17 Sep 2026 14:43:17 +0000

Ask ten network engineers what "high availability" means and you'll get ten confident answers, and then ask them to point to the specific number their network is actually designed to hit, and the confidence usually drops off fast. That gap between the phrase and the actual, measurable target is where most high-availability network design quietly falls short of what everyone assumes it delivers.

I'll say the blunt version: "we built it to be highly available" is not a design spec. "This network needs to hit 99.95% availability, which means no more than about 4.4 hours of downtime a year" is a design spec and the difference between those two statements is the difference between hoping your network holds up and actually knowing it will.

Pick a Real Number Before You Design Anything

Every system doesn't need the same availability target, and pretending otherwise wastes money on systems that don't need five-nines reliability while sometimes underinvesting in the one system that genuinely does. A customer-facing service processing transactions every minute deserves a meaningfully higher bar than an internal tool people check twice a day. Put a real number on each system before you design around it everything downstream of that number becomes a much clearer engineering decision instead of a vague aspiration everyone interprets differently.

Find Every Single Point of Failure, Genuinely, Not on the Diagram

This is the part everyone thinks they've already done and usually haven't done thoroughly. A single point of failure isn't just "the one router with no backup" it's anything whose failure takes the whole service down, and finding these requires actually tracing dependencies end to end rather than glancing at an architecture diagram and confirming redundant-looking boxes exist.

We've seen "redundant" setups where two supposedly independent paths both ran through the same physical switch three steps upstream, which made that switch the actual single point of failure the whole design was supposedly protecting against. Nobody found it by looking at the diagram. Somebody found it by actually tracing the path, cable by cable, connection by connection.

Redundancy Comes in Levels, and They're Not Interchangeable

Two power supplies in one server protects against one power supply failing. It does nothing if the whole server dies. Two servers behind a load balancer protects against a server dying. It does nothing if the whole site loses power. Two sites in different regions protects against a site going down. None of these substitute for each other they protect against genuinely different failure scenarios, and confusing "we have redundancy" for "we have redundancy at the level that actually matters for this specific risk" is one of the most common gaps in real network designs.

Untested Redundancy Is a Belief, Not a Fact

This deserves to be said as plainly as possible: if you've never actually forced a failover to happen and watched it work, you don't know it works. You believe it works, based on the configuration looking correct, and configuration looking correct and behavior actually being correct are two different things that only converge when someone genuinely tests it. Regular, deliberate failover testing not a tabletop conversation about how it should theoretically go is the only thing that turns "we believe this is resilient" into "we know this is resilient."

Watch for the Redundancy You've Already Used Up

A system quietly running on its backup path because the primary failed at 3 a.m. and nobody noticed is not actually in a resilient state anymore, even though it's still up and serving traffic. It's one more failure away from a real outage, and if your monitoring only tells you "service is up" rather than "service is up, but on its last remaining redundant path," you won't know you're one step from trouble until you take that last step.

What This Actually Requires

A specific, numeric availability target per system, not a shared, vague aspiration

Dependencies genuinely traced through, not assumed redundant because the diagram shows two boxes

The right level of redundancy for the actual risk component, system, or site deliberately chosen, not defaulted to whichever felt sufficient

Real, regular failover testing, turning belief into verified fact

Monitoring that flags degraded redundancy, not just complete failure

The Actual Point

Highly available infrastructure isn't infrastructure that never has a component fail components fail regardless of how well anything's designed. It's infrastructure where a failure doesn't actually interrupt the service, because someone traced through what would happen, built the right kind of redundancy for the actual risk, and then genuinely tested it instead of trusting a diagram that's never been put under real pressure.

Enterprise Infrastructure Operations | ArclogiQ

Optimize your cloud spend, achieve absolute regulatory compliance, and build secure, high-performance network environments.

arclogiq.com

Site-to-Site VPN vs. Direct Connect: Which Is Better?

Ronak Sharma — Thu, 17 Sep 2026 11:04:36 +0000

Neither one is "better" in any universal sense, and the fact that this question gets asked so often as though it has a single right answer is exactly why so many businesses end up with the wrong option for their actual situation. This comes down to a genuinely simple tradeoff once you strip away the vendor marketing on both sides: cost and setup speed versus performance and consistency.

What VPN Actually Gives You

Site-to-site VPN rides over the regular public internet, encrypted, connecting your infrastructure to the cloud. It's fast to set up often working within hours and cheap, since you're not paying for dedicated physical infrastructure. The tradeoff is genuine and worth being honest about: performance is subject to whatever's happening on the public internet at any given moment, which means latency and throughput can vary in ways you don't control and can't always predict.

What Direct Connect Actually Gives You

A dedicated connection AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect is a genuinely private, physical link between your infrastructure and the cloud provider's network, bypassing the public internet entirely. Performance is considerably more predictable, latency is generally lower, and for high-volume, sustained traffic, it's often genuinely cheaper per gigabyte than the equivalent VPN traffic once you're moving enough data regularly. The cost is real setup time often weeks, sometimes longer depending on your location and meaningfully higher fixed cost, especially at lower volumes.

The Question That Actually Decides This

Ask honestly: how much does performance consistency actually matter for what's crossing this connection, and how much data volume are we actually talking about? A connection carrying occasional file transfers and non-critical traffic genuinely doesn't need the cost and lead time of a dedicated connection. A connection carrying your primary application's database traffic, or supporting real-time, latency-sensitive operations, genuinely benefits from the consistency a dedicated connection provides inconsistent latency on that kind of traffic shows up directly as a worse experience for whoever's depending on it.

Don't Treat This as All-or-Nothing

A genuinely reasonable pattern a lot of businesses land on: dedicated connection for the traffic that actually needs the consistency, VPN for everything else, and this part gets missed constantly VPN as a legitimate failover path if the dedicated connection ever goes down, since dedicated connections aren't themselves immune to outages despite their reliability advantages.

The Setup Timeline Trap

This is worth flagging directly because it burns businesses regularly: Direct Connect and its equivalents take real time to provision, and that timeline needs to be planned around well in advance, not discovered the week before a project needs the connection live. Businesses that wait until they're certain they need a dedicated connection, then try to set it up on a tight deadline, frequently end up stuck on VPN longer than they wanted simply because nobody started the provisioning process early enough.

What Actually Determines the Right Choice

How much performance consistency genuinely matters for the specific traffic crossing the connection

Actual sustained data volume, since dedicated connections often become cheaper per gigabyte past a certain threshold

Realistic setup lead time, planned for well ahead of when the connection actually needs to be live

Whether a hybrid approach genuinely fits dedicated for critical traffic, VPN for everything else and as failover

The Actual Point

This was never really a competition between a better option and a worse one. It's a genuine tradeoff between speed-and-cost on one side and performance-and-consistency on the other, and the right answer is whichever side of that tradeoff actually matches what's crossing your specific connection not whichever technology sounds more impressive in a vendor's pitch deck.

Enterprise Infrastructure Operations | ArclogiQ

Optimize your cloud spend, achieve absolute regulatory compliance, and build secure, high-performance network environments.

arclogiq.com

VPC Peering vs. Transit Gateway: Which One Should You Use?

Ronak Sharma — Thu, 17 Sep 2026 10:58:41 +0000

This question genuinely has a clean answer once you understand what actually breaks down as an environment scales, and the answer isn't the same for everyone, which is exactly why the question keeps getting asked. VPC peering and transit gateway both connect VPCs together they solve the same basic problem at genuinely different scales and with genuinely different operational characteristics.

VPC Peering: Simple, Direct, and Genuinely Fine at Small Scale

VPC peering creates a direct, one-to-one connection between two VPCs. It's simple to set up, has no additional hourly cost beyond data transfer, and for a small number of VPCs two, three, maybe four it's genuinely the right, uncomplicated choice. The traffic path is direct, latency is minimal, and there's no additional managed service sitting in the middle to configure or pay for.

Where Peering Stops Scaling Cleanly

The problem with peering isn't that it stops working it's that the number of connections needed grows quadratically as you add VPCs. Two VPCs need one peering connection. Five VPCs, fully meshed, need ten. Ten VPCs need forty-five. Beyond a relatively small number, managing this many individual peering relationships becomes a genuine operational burden, and peering also doesn't support transitive routing VPC A peered with B, and B peered with C, does not mean A can reach C, which surprises teams who assume peering behaves more like a traditional network.

Transit Gateway: Centralized, Scalable, and Worth the Added Cost Past a Certain Point

Transit gateway acts as a central hub that VPCs connect to individually, with the gateway handling routing between them. This eliminates the quadratic scaling problem entirely adding a new VPC means one new connection to the transit gateway, not new connections to every existing VPC. It also supports transitive routing naturally, and centralizes routing policy in one place rather than requiring it to be replicated correctly across many individual peering relationships.

The tradeoff is genuine added cost transit gateway carries both hourly and data processing charges that peering doesn't and a small amount of added latency from traffic passing through the gateway rather than a direct peering path.

The Actual Decision Point

For a small, stable number of VPCs roughly under five, as a rough guide rather than a hard rule direct peering is genuinely simpler and cheaper, and adopting transit gateway at that scale adds cost and complexity without a corresponding benefit. Once you're managing more VPCs than that, or you know growth is coming, transit gateway's centralized management and clean scaling considerably outweigh the added cost, and the migration effort required to move from peering to transit gateway later only grows as more peering relationships accumulate.

This is worth deciding deliberately rather than defaulting to whichever pattern happened to be used for the first two VPCs and never revisited as more got added over time.

Hybrid Approaches Are Genuinely Reasonable Too

Some organizations use transit gateway for their core, growing set of VPCs while maintaining direct peering for a specific, stable pair of VPCs with unusually high traffic volume where the marginal latency reduction genuinely matters. This isn't a compromise to be avoided it's a legitimate architecture when the actual traffic patterns and requirements genuinely justify treating different connections differently.

What Actually Determines the Right Choice

Current and near-term VPC count, since peering's quadratic scaling problem only becomes a genuine issue past a certain number
Whether transitive routing is actually needed, which peering structurally cannot provide
Whether centralized routing policy matters for your security or compliance requirements
The genuine cost tradeoff, weighing transit gateway's added charges against the operational cost of managing many individual peering relationships manually

The Actual Point

This isn't a question of which technology is better in the abstract both are mature, well-supported options solving the same basic problem at different scales. The right choice is whichever one matches your actual current and near-term VPC count, and the businesses that get this wrong are usually the ones who never revisited their original choice as the environment genuinely outgrew it.

Google Cloud VPC: Architecture and Security Best Practices

Ronak Sharma — Wed, 16 Sep 2026 15:21:53 +0000

Google Cloud's VPC model has a genuinely distinct architectural feature that trips up engineers coming from AWS or Azure: GCP VPCs are global by default, spanning all regions natively, rather than scoped to a single region the way AWS VPCs and Azure VNets are. This isn't a minor implementation detail it changes how you should actually think about network design on the platform from the ground up.

My position: teams that treat GCP VPC design as "AWS VPC design with different terminology" consistently miss the specific advantages the global model offers, and end up recreating region-by-region complexity that GCP's architecture was specifically built to avoid.

Understand the Global VPC Model Before Designing Anything

Because a single GCP VPC can span multiple regions, achieving multi-region connectivity doesn't require the explicit peering or transit gateway work that AWS or Azure would need for equivalent reach. Subnets within a single VPC can exist in different regions while remaining part of the same network, communicating without the additional connectivity layer other platforms require. Designing as though this weren't true creating separate VPCs per region and connecting them the way you would on another platform recreates complexity GCP's model was specifically built to eliminate.

Shared VPC for Multi-Project Organizations

GCP's Shared VPC feature lets a central "host" project own the network while other "service" projects use it, providing centralized network management without requiring every project to manage its own networking independently. This is genuinely valuable for organizations running many GCP projects and deserves deliberate adoption rather than each project team independently standing up its own VPC and creating exactly the kind of fragmented, inconsistent network management that Shared VPC exists to prevent.

Firewall Rules Are Global, and That Changes How You Should Organize Them

GCP firewall rules apply at the VPC level by default, which combined with the global VPC model means firewall policy can be genuinely consistent across regions in a way that requires deliberate replication effort on platforms with region-scoped networking. This is a real advantage worth designing around explicitly: organizing firewall rules by network tags and service accounts, rather than by region, takes fuller advantage of what the platform's architecture actually enables.

Private Google Access and Private Service Connect Reduce Public Exposure

Resources without external IP addresses can still reach Google APIs and services through Private Google Access, and Private Service Connect extends similar private connectivity to specific services and even third-party or cross-VPC connections. Using these deliberately, rather than defaulting to external IPs and public internet routing for service-to-service communication, reduces exposure meaningfully and is often underused simply because the public path works without anyone specifically evaluating the private alternative.

VPC Service Controls for Genuine Data Exfiltration Protection

For organizations with genuine data sensitivity concerns, VPC Service Controls create a security perimeter around GCP resources that restricts data movement even for otherwise properly authenticated access a meaningfully stronger control than IAM alone provides, specifically addressing the scenario where legitimate credentials get used to move data somewhere it shouldn't go.

Network Tags and Service Accounts as Firewall Targets

Rather than targeting firewall rules at specific IP ranges, which drift out of sync as infrastructure changes, GCP's model of targeting rules at network tags or service accounts ties firewall policy to what a resource actually is or does, remaining accurate even as the underlying IP addressing changes. This is a genuine architectural advantage worth using deliberately rather than falling back to IP-based rules out of habit from other platforms.

What This Actually Requires

Designing around the global VPC model explicitly, not recreating region-by-region complexity unnecessarily

Shared VPC adopted for multi-project organizations, rather than each project managing its own fragmented networking

Firewall rules organized by tags and service accounts, taking advantage of the platform's global consistency rather than replicating region-specific rules

Private Google Access and Private Service Connect used deliberately, reducing public exposure for service-to-service communication

VPC Service Controls evaluated for genuinely sensitive data, providing protection beyond IAM alone

The Actual Point

GCP's networking model offers genuine architectural advantages specifically because it was built differently from AWS and Azure, and those advantages only materialize for teams that design around the actual model rather than importing assumptions from a different platform's architecture. The teams getting the most out of GCP networking aren't using more services they're using the platform's genuinely distinct global model the way it was actually designed to be used.

Azure Virtual Network Best Practices for Enterprises

Ronak Sharma — Wed, 16 Sep 2026 15:19:05 +0000

Azure Virtual Networks get approached by a lot of teams with an AWS VPC mental model loosely applied on top, and while the concepts genuinely overlap, the specifics diverge enough that porting assumptions directly produces real, subtle gaps particularly around how Azure handles routing, peering, and the hub-and-spoke pattern the platform genuinely encourages more explicitly than AWS does.

My position: Azure VNet architecture rewards a hub-and-spoke topology considerably more than a flatter, more ad hoc structure, and enterprises that resist adopting it usually because it feels like more upfront complexity than a simpler design end up managing genuinely more complexity later once multiple VNets and multiple teams are all trying to coordinate connectivity independently.

Hub-and-Spoke: Adopt It Earlier Than Feels Necessary

Azure's hub-and-spoke topology centralizes shared services connectivity, security inspection, DNS in a hub VNet, with spoke VNets peered to it for individual workloads or business units. This pattern scales considerably better than direct peering between every VNet as the environment grows, for the same quadratic-relationship reason that plagues direct peering on any cloud platform. Adopting it while the environment is still small enough that migration is easy avoids a genuinely more disruptive restructuring once dozens of VNets exist with ad hoc peering relationships between them.

Network Security Groups Need Layered, Deliberate Application

NSGs can be applied at both the subnet and network interface level, and understanding how these interact and deliberately choosing where each specific rule genuinely belongs matters more than defaulting to applying everything at one level out of convenience. Subnet-level NSGs are generally easier to manage consistently; NIC-level NSGs offer more granular control where genuinely needed for a specific resource.

User-Defined Routes Deserve Careful, Documented Management

Azure's default routing can be overridden through User-Defined Routes, which is powerful and genuinely easy to misconfigure in ways that create confusing routing behavior nobody can quickly diagnose later. Every UDR deserves documentation explaining why it exists and what it's overriding an undocumented UDR is exactly the kind of configuration that becomes a genuine mystery once the person who created it moves to a different team or leaves the company.

Azure Firewall or Third-Party NVA: A Real, Deliberate Choice

Centralizing traffic inspection through Azure Firewall or a third-party network virtual appliance in the hub VNet, rather than relying purely on distributed NSGs, provides genuine centralized policy and logging that's considerably harder to achieve consistently through NSGs alone spread across many spokes. This decision deserves deliberate evaluation against your specific security and compliance requirements, not a default choice made without comparing the actual tradeoffs.

Private Endpoints Reduce Public Exposure for PaaS Services

Azure PaaS services storage accounts, databases can be accessed via private endpoints within your VNet rather than over the public internet, considerably reducing exposure. This is genuinely underused relative to how straightforward it is to configure, often because the default public endpoint "just works" without anyone specifically revisiting whether that default is actually the right choice for a given service handling sensitive data.

DNS Architecture Needs Explicit Design in Hybrid Scenarios

For organizations connecting Azure VNets to on-premises infrastructure, DNS resolution needs deliberate architecture Azure Private DNS zones, conditional forwarding to on-premises DNS rather than assuming default Azure DNS behavior will handle hybrid name resolution correctly without explicit configuration.

What This Actually Requires

Hub-and-spoke topology adopted early, before the environment grows large enough that migrating to it becomes genuinely disruptive

NSGs applied deliberately at the right level, subnet or NIC, based on genuine need rather than convenience

UDRs documented explicitly, so routing overrides don't become an undocumented mystery later

A deliberate choice between Azure Firewall and NSG-only architecture, based on actual security and compliance requirements

Private endpoints used for PaaS services handling sensitive data, rather than defaulting to public endpoints

Explicit hybrid DNS architecture, not assumed default behavior

The Actual Point

Azure Virtual Network architecture that scales well isn't about avoiding complexity hub-and-spoke is genuinely more complex to set up than a flat design. It's about accepting that complexity deliberately, early, while it's still manageable, rather than discovering later that a simpler initial design has become the thing actively blocking growth and consistent management across a genuinely mature Azure environment.

AWS VPC Best Practices for Secure and Scalable Infrastructure

Ronak Sharma — Sat, 12 Sep 2026 09:28:44 +0000

Most AWS environments have a VPC that technically works and hasn't actually been revisited since it was first set up, often by whoever was standing there when the account was created. That's fine at small scale. It becomes a genuine liability once real workloads, real compliance requirements, and real growth start depending on decisions that were never meant to carry that much weight.

My position: VPC design mistakes are among the most expensive to unwind in AWS specifically, because so much else gets built on top of the initial network layout. Getting the foundational decisions right early is disproportionately valuable compared to almost any other AWS architecture decision.

CIDR Block Sizing: Bigger Than You Think You Need

The single most common regret in AWS VPC design is a CIDR range sized for current needs that runs out of room within a couple of years. Since VPC CIDR blocks are genuinely difficult to resize after subnets and resources are already deployed within them, allocate generously from the start a /16 for a VPC that might only need a /20 today costs nothing extra and saves a painful future migration.

Use Multiple Availability Zones Deliberately, Not Just Nominally

Subnets should be genuinely distributed across multiple AZs, and critically, actual resources need to be deployed across those subnets in a way that provides real redundancy — not just technically available multi-AZ subnets sitting mostly empty while everything actually runs in one zone. Verify this directly rather than assuming multi-AZ subnet creation alone constitutes multi-AZ resilience.

Security Groups vs. Network ACLs: Use Both, Understand the Difference

Security groups are stateful and instance-level; NACLs are stateless and subnet-level. A lot of AWS environments rely purely on security groups and never seriously use NACLs, missing a genuine additional layer of defense. NACLs are particularly useful for explicit deny rules at the subnet level blocking known-bad ranges broadly, for instance in a way that complements rather than duplicates security group logic.

VPC Endpoints Reduce Both Cost and Exposure

Traffic to AWS services like S3 or DynamoDB doesn't need to route through a NAT Gateway or the public internet if VPC endpoints are properly configured. This reduces NAT Gateway data processing costs meaningfully and keeps that traffic off the public internet entirely, which is both a cost optimization and a genuine security improvement, and it's consistently underused because NAT Gateway routing works "well enough" without anyone specifically optimizing it.

Flow Logs Should Be Enabled by Default, Not Added Reactively

VPC Flow Logs provide genuine visibility into traffic patterns and are frequently only enabled after an incident makes their absence painfully obvious. Enable them from the start, at the VPC level, and route them to a genuinely reviewed destination not just enabled and left uncollected in a log group nobody's watching.

Multi-Account VPC Strategy Matters at Real Scale

For organizations running multiple AWS accounts, deciding how VPCs relate across accounts shared VPC via Resource Access Manager, or separate VPCs connected via Transit Gateway deserves deliberate architecture rather than an ad hoc pattern that emerged as accounts were added one at a time without an overarching plan.

What This Actually Requires

Generous CIDR allocation from day one, avoiding a painful future resize

Genuine, verified multi-AZ resource distribution, not just multi-AZ subnet availability

Both security groups and NACLs used deliberately, not relying on one layer alone

VPC endpoints configured for AWS service traffic, reducing both cost and public internet exposure

Flow logs enabled by default and genuinely reviewed, not added reactively after an incident

A deliberate multi-account VPC strategy, not an emergent pattern from adding accounts individually over time

The Actual Point

VPC design decisions are foundational in a way that's easy to underestimate when the account is new and the stakes feel low. Getting the CIDR sizing, AZ distribution, and account strategy right early saves a considerably more painful and disruptive correction once real workloads depend on the structure already in place.

ArclogiQ | Cloud Solutions, Security, Network & Infrastructure

Optimize your cloud spend, achieve absolute regulatory compliance, and build secure, high-performance network environments.

arclogiq.com

How Zero Trust Networking Improves Cloud Security

Ronak Sharma — Sat, 12 Sep 2026 07:05:28 +0000

Zero trust and cloud security get discussed together so often that it's worth asking directly: why does zero trust fit cloud environments specifically well, rather than just being a general security trend that happens to apply everywhere equally? The honest answer is that cloud infrastructure broke the assumption zero trust was built to replace and understanding that connection matters more than treating zero trust as a checkbox to add to an existing cloud security program.

My take, stated plainly: traditional network security assumed a trusted interior and an untrusted exterior, with a clear boundary between them. Cloud infrastructure doesn't really have that boundary in any meaningful sense anymore, and pretending it still does is exactly what leaves cloud environments exposed in ways teams don't notice until something's already gone wrong.

The Perimeter Cloud Broke

Traditional security drew a line: inside the corporate network, trusted; outside, verify carefully. Cloud infrastructure genuinely doesn't have a clean version of that line. Your applications live outside a traditional network boundary by definition. Your users connect from everywhere. Your data moves between services that were never all sitting behind one shared firewall to begin with.

Applying old perimeter thinking to this environment means either trusting far too broadly treating cloud resources as "inside" simply because they're in your account or building an artificial, brittle perimeter around infrastructure that was never designed to have one. Zero trust sidesteps this entirely by not depending on a perimeter existing in the first place.

Every Request Verified, Regardless of Where It Came From

This is the actual mechanical shift, stated simply: instead of trusting a request because it came from inside your VPC or your cloud account, zero trust verifies identity and context on every single request, every time, regardless of origin. A request from inside your own cloud environment gets the same scrutiny as one from outside it, because "inside" stopped being a meaningful trust signal the moment infrastructure moved to the cloud.

This matters enormously for lateral movement specifically. A compromised credential or service inside your cloud environment, under a genuine zero trust model, still has to verify for every subsequent request it makes it doesn't get to move freely just because it's already "inside," which is exactly the freedom traditional perimeter-based trust would have handed it by default.

Identity Becomes the Actual Control Point

In cloud environments specifically, identity user identity, service identity, workload identity does the job network location used to do. Genuine zero trust in a cloud context means access decisions are made based on who or what is actually requesting access and under what verified conditions, not based on which subnet or VPC the request happens to originate from.

This is why cloud identity platforms have become so central to genuine cloud security posture they're not just an authentication convenience, they're the actual enforcement point zero trust depends on, in an environment where network location alone genuinely can't be trusted to mean much anymore.

Microsegmentation and Zero Trust Reinforce Each Other

Genuine microsegmentation isolating individual cloud workloads from each other rather than just perimeter isolation around a broader environment pairs naturally with zero trust's identity-based verification. Even where segmentation allows a connection to technically exist, zero trust verification adds a second, independent layer confirming that specific request should actually be permitted right now, rather than relying on network-level permission alone as sufficient proof of legitimacy.

Where This Gets Genuinely Hard: Legacy and Third-Party Integrations

Worth being honest about this rather than pretending zero trust is simple to fully implement everywhere. Older systems and third-party integrations that weren't built with modern identity-based access in mind genuinely can't always support full zero trust verification directly. This needs real, deliberate compensating controls rather than either pretending full coverage exists or letting these systems quietly sit outside the zero trust model entirely, unaddressed.

What This Actually Requires in a Cloud Environment

Every request verified based on identity and context, regardless of whether it originated inside or outside your cloud account

Cloud identity platforms treated as the genuine security control point, not just an authentication convenience layered on top

Microsegmentation paired with identity verification, so segmentation and zero trust reinforce rather than substitute for each other

Honest, deliberate compensating controls for legacy and third-party systems that can't fully support identity-based access

The Actual Point

Zero trust isn't an add-on feature for cloud security it's the model that actually matches how cloud infrastructure works, replacing a network perimeter that cloud environments never really had to begin with. Cloud security programs still operating on old perimeter assumptions aren't behind on a trend. They're working from a mental model the infrastructure itself already stopped supporting.

Why This Feels Harder Than It Actually Is Once You've Started

Teams that haven't begun a zero trust transition often perceive it as an enormous, all-or-nothing undertaking, and that perception is a genuine barrier to actually starting. In practice, the transition is considerably more incremental than it feels from the outside identity-based verification can be extended to one application or one service at a time, proving the model works before extending it further, rather than requiring a single, sweeping architectural change applied everywhere simultaneously. Organizations that treat it as an all-or-nothing project tend to stall before making genuine progress; organizations that treat it as an incremental, expandable practice tend to actually get somewhere.

What Changes for End Users, and Why That Matters

A genuine zero trust rollout does change the day-to-day experience of accessing systems more frequent verification, device health checks that weren't there before. If this change isn't explained and doesn't come with a genuinely smooth implementation, it generates real user friction and, eventually, workarounds that undermine the entire model. The technical architecture is only half the project; the other half is making sure the verification burden placed on users is proportionate and well-implemented enough that people don't start looking for ways around it, which defeats the purpose entirely if it happens at any real scale.

Measuring Whether It's Actually Working

Beyond "have we deployed zero trust tooling," genuine measures of progress include: what percentage of access to critical cloud resources is actually governed by identity-based verification versus legacy, broader access patterns still in place; how quickly anomalous access gets detected and investigated; and whether lateral movement testing genuine, deliberate attempts to move from one compromised resource to another actually gets stopped by the architecture rather than succeeding because some part of the environment still operates on old, broader trust assumptions.

The Relationship to Broader Zero Trust Efforts

Cloud-specific zero trust networking doesn't exist in isolation from an organization's broader zero trust initiative spanning on-premises and hybrid infrastructure too. Treating cloud zero trust as a separate, disconnected effort from whatever's happening elsewhere in the environment risks building two genuinely inconsistent models one for cloud, one for everything else which recreates exactly the kind of seam-level gap that undermines the whole point of adopting zero trust principles in the first place.
https://arclogiq.com/