Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Architects Now Redesign for Co-Location
Transcript
- Lucas: If these conversations are useful for what you're building or running, we want to keep them coming. We deliberately don't run ads on these episodes — no sponsors, no mid-roll interruptions. If you value that approach, you can support the show at buy me a coffee dot com slash fexingo. That's it. Simple, transparent, and it keeps us focused on the tech. Luna: Yeah, it's a small thing that makes a big difference for us. Appreciate anyone who throws a coffee our way. Lucas: Alright, let's get into it. Today we're talking about a trend that's quietly reshaping enterprise cloud architecture: physical co-location inside the cloud provider's own data center. Not virtual peering, not a third-party colo facility — putting your actual racks on the same floor as AWS or Azure. Luna: I've seen a few references to this in contracts lately. It's not exactly new, but it seems like more enterprises are seriously looking at it. What's driving that? Lucas: The short answer is data egress and latency. If you're running a latency-sensitive workload or moving terabytes daily, the cost of pulling data across the public internet — or even through a direct connection — adds up. And the latency, even with something like AWS Direct Connect, is still measured in single-digit milliseconds. But if your gear is physically inside the same building as the cloud provider's routers, you can get sub-millisecond latency. Luna: Sub-millisecond is a big deal for things like high-frequency trading or real-time video processing. But for a typical enterprise? What's the use case that makes the hassle worth it? Lucas: The example I've been tracking is a Fortune 500 manufacturer — let's call them a large industrial automation firm. They had a hybrid setup: on-premises compute running their legacy manufacturing execution system, and they were using AWS for analytics and machine learning. Every hour, they were pushing about 500 gigabytes of sensor data from the plant floor into the cloud. The egress charges alone were running over a million dollars a year. Luna: Ouch. So they were essentially paying the cloud provider to get their own data out. That's the classic data egress tax. Lucas: Exactly. So they looked at options. They could move the entire workload to the cloud, but the legacy system had some hard real-time dependencies that made that risky. Or they could keep everything on-prem, but then they lose the ML analytics. The middle path was co-location inside an AWS facility. They put two racks of their own gear — compute and a storage array — directly into an AWS Direct Connect location in the same metro region. Luna: And that cut egress? Because now the data doesn't leave the AWS network? Lucas: Right. The sensor data flows from the plant to their colo racks over a private fiber link — about a mile away — and then from those racks into AWS over an internal cross-connect. No internet egress. They reduced their data transfer costs by about 40 percent, and latency dropped from about 4 milliseconds to under 0.5 milliseconds. Luna: That's a significant improvement. But I imagine there are trade-offs. You're now managing physical hardware inside someone else's facility, and you're locked into that location. Lucas: Absolutely. The operational complexity is real. You need to have staff who can go on-site for hardware maintenance, or you contract with the colo provider for remote hands. And you're committing to a specific cloud region — if you want to switch to Azure, you can't just lift and shift your colo racks. They're physically inside an AWS facility, so you're essentially anchored. Luna: So it's a form of vendor lock-in, even if it's not intentional. But I've heard that some cloud providers are now offering co-location as a managed service — they'll handle the hardware for you. Lucas: That's where it gets interesting. Both AWS and Azure have programs where they'll let you bring in your own certified hardware, and they'll manage the power, cooling, and physical security. AWS calls it the 'Outposts' rack in a colo facility, but the distinction is that with Outposts you're running AWS software on your hardware. With pure colo, you're running your own operating systems and applications. It's more flexible, but also more hands-on. Luna: So who is this really for? I can see it making sense for a manufacturing company with real-time control systems, or maybe a media company doing heavy video transcoding. But for a standard SaaS company? Probably not. Lucas: Right. The sweet spot is workloads that have both a need for low latency and a large data footprint. Think oil and gas with seismic data, healthcare with large imaging files, or financial services with tick data. For a typical web app, the complexity isn't worth it. But for enterprises moving petabytes, the math can work. Luna: And what about the contract side? I've seen some cloud providers now include specific clauses about co-location space guarantees — promising floor space, power, and cooling for a certain number of racks. Lucas: Yes, that's a growing trend. In the last year, we've seen enterprise cloud contracts with specific appendices for 'dedicated colocation space' within the provider's data center. They'll guarantee a certain number of kilowatts and square footage, often with a sliding scale based on usage. It's basically a real estate deal inside a cloud contract. Luna: So you're negotiating not just compute and storage pricing, but physical floor space. That must be a new skill set for procurement teams. Lucas: Absolutely. And it changes the economics. Instead of paying only for cloud services, you're also paying for facility costs — but you're saving on data egress and getting better performance. The total cost of ownership can be lower, but only if you have enough data throughput to justify the fixed cost of the colo space. Luna: I've also heard that some enterprises are using co-location to meet data residency requirements. If you need to keep data in a specific country, putting your own hardware in a cloud provider's facility there gives you physical control while still having low-latency access to cloud services. Lucas: That's a great point. In Europe especially, we're seeing banks and insurers use this model to satisfy regulatory requirements around data sovereignty. They own the physical hardware, so they can demonstrate that data never leaves the jurisdiction, but they still get the elasticity of the cloud for burst workloads. Luna: So it's like a hybrid cloud, but the hybrid boundary is inside the same data center. It's almost a 'cloud-in-a-room' approach. Lucas: Exactly. And it's leading to some interesting architectural patterns. For example, some enterprises are running their databases on their own colo hardware for performance and compliance, but using cloud-native services for analytics, AI, and serverless functions. The database writes are sub-millisecond, and the analytics queries can scale elastically. Luna: But what about disaster recovery? If your colo gear is in the same building as the cloud region, a regional outage could take out both. Do you need a second colo site in a different region? Lucas: That's the trade-off. Most enterprises we've talked to are running a primary colo in one cloud region, and then using a separate cloud region — or a different cloud provider — for disaster recovery. They replicate data asynchronously. It adds cost, but it's still cheaper than running a full secondary data center. Luna: So the model is evolving. It's not just 'cloud or on-prem' anymore. There's this third option: physically inside the cloud. Lucas: Right. And I think we'll see more providers offering co-location as a standard part of their enterprise contracts over the next year. It's a way to capture workloads that would otherwise stay on-prem, and it deepens the relationship. Luna: One question I've had: how do you handle hardware refreshes? If you put a server in an AWS colo facility, and three years later you need to upgrade, do you have to coordinate with AWS? Or can you just swap it out? Lucas: You typically work with the colo provider — which might be a separate company like Equinix or Digital Realty, even if it's inside an AWS building. They have standard processes for hardware swap-outs. But yes, you need to schedule maintenance windows and ensure the new hardware is certified for the facility. It's more structured than your own data center, but it's manageable. Luna: And security? I imagine having your own hardware inside a shared facility raises some concerns. Lucas: The cloud providers have strict physical security — multi-factor access, biometrics, CCTV. Your racks are in a locked cage, and only your staff have access. The colo provider handles the perimeter, but you're responsible for the cage-level security. Many enterprises also run their own monitoring cameras and sensors inside the cage. Luna: So it's a bit like having a safety deposit box inside a bank vault. You trust the bank's security, but you still want your own lock. Lucas: Exactly the analogy I use. And the cost is not trivial — you're paying for floor space, power, and cooling, plus the cross-connect fees to the cloud network. But for the right workload, the savings on data transfer and the latency improvement can justify it. Luna: I'm curious about the longer-term implications. If more enterprises do this, does it change how cloud providers design their data centers? More colo space, more power density? Lucas: I think so. We're already seeing cloud providers building out 'colony' facilities — data centers specifically designed to host customer hardware alongside the cloud infrastructure. They're essentially becoming real estate operators as well as cloud operators. It's a logical extension of the platform model. Luna: Interesting. So maybe in five years, the default enterprise architecture isn't 'cloud or on-prem' but 'at the cloud' — physically adjacent. Lucas: That's exactly the direction. And it blurs the line between cloud and colocation even further. For the enterprise architect, it's another tool in the toolbox. Not every workload needs it, but for the ones that do, it can be transformative. Luna: Well, that gives us a lot to think about. I'll be keeping an eye on how those colo clauses evolve in enterprise contracts. Lucas: Same here. And if you're evaluating this for your own infrastructure, I'd recommend starting with a data transfer audit. Understand your egress patterns and latency requirements before you sign any floor space agreement.