Megaport Connect Cloud Networking Summit

Cost Optimization & ROI in Hybrid/Multi-Cloud Strategies - Key Takeaways

Overview

Corey Quinn, Chief Cloud Economist at The Duckbill Group, frames cloud networking cost optimization as a business and architecture problem, not simply a billing exercise. The session focuses heavily on AWS examples, but the central point applies across major public clouds: data transfer pricing is complicated and powerful enough to shape where workloads live.

The core argument is that cost and architecture are inseparable in cloud environments. Data transfer fees influence multi-region design, hybrid connectivity, CDN usage, disaster recovery planning, and vendor lock-in. Moving compute can be straightforward, but moving data is expensive and operationally consequential.

The practical message for finance-conscious IT leaders is to evaluate hybrid and multi-cloud strategies through measurable return: better performance, reduced risk, greater negotiating leverage, or concrete business flexibility. If a network connection or data movement pattern does not support one of those outcomes, it may be complexity without a defensible payoff.

1. Data Transfer Pricing Starts Simple, Then Becomes Complicated

The simplest part of cloud data transfer pricing is inbound traffic. Data moving into the cloud is free.

Outbound data is where the complexity begins. In the AWS-oriented examples from the session, the first 100 GB of outbound data is free, after which traffic from U.S. regions to users starts around $0.09 per GB. Prices can decline with volume tiers, but destination geography changes the economics. Europe costs more than U.S. destinations, Asia-Pacific can cost more again, and regions such as Sydney and Sao Paulo are called out as higher-cost examples.

Special environments can increase the bill further. GovCloud outbound transfer is described at $0.15 per GB, roughly 60% more than a standard packet in the comparison. The point is that cloud networking pricing changes with direction, geography, service, and compliance context.

The simplified map is that inbound traffic is mostly free, outbound traffic usually costs money, cross-region traffic adds another layer of fees, and special cases change the bill based on service path, region pair, or traffic classification.

2. Private Connectivity Reduces Some Costs but Does Not Make Data Movement Free

Private connectivity can change the cost profile, but it does not remove the economics of data transfer. In the AWS example, Direct Connect provides a dedicated path that avoids the public internet, with port fees charged by the hour according to the amount of bandwidth reserved. Quinn describes port pricing as ranging from about $0.03 per hour up to $85 per hour, depending on capacity.

Direct Connect also has its own data transfer model. Inbound traffic through the port remains free, but outbound data is still charged. In U.S. examples, egress can start around $0.02 per GB, which is materially lower than the standard $0.09 per GB outbound rate. That discount can be meaningful, but the port fee must be included before declaring the design cheaper.

The decision is therefore not “internet versus private line” in isolation. It is a workload-specific calculation: how much data will leave the cloud, whether traffic volume is steady enough to justify hourly port costs, whether the private path improves performance or operational control, and whether total cost falls after both port fees and egress charges are included.

3. Inter-AZ Traffic Can Turn Resilience Into a Cost Driver

Availability zone design is one of the most important hidden cost areas. Multi-AZ architecture is widely used for resilience, but moving data across AZ boundaries can become billable. The bill is often effectively one cent in and one cent out per GB, creating a two-cent-per-GB round trip in common cases.

Because both sides of the transfer can be metered, the bill may show double the volume of the actual data transferred. At 10 TB per month between availability zones, the cost becomes hundreds of dollars per month simply to support the cross-AZ traffic pattern.

The strategic question is whether the architecture actually delivers the resilience it is paying for. A multi-AZ design that cannot survive a full AZ loss, or that leaves another dependency as a single point of failure, may be paying for the appearance of high availability without delivering it.

There is also an asymmetry between first-party cloud services and customer architectures. Some AWS-managed services can replicate across zones without customers seeing the same data transfer charges, while customer-managed cross-AZ traffic often incurs fees. That makes it important to understand which traffic paths are actually billable rather than assuming that “same region” means free.

4. Interservice Traffic Is Often Free Until Architecture Details Change

Many teams think of networking cost mainly as “data transfer out,” but interservice transfer is another hidden cost category. Architecture diagrams often show arrows between services with an implied assumption that traffic inside a region is free. In many common cases, such as EC2 talking to S3 or Lambda interacting with API Gateway, there may be no direct data transfer charge within the same region.

The trap is that specific configurations can change the billing path. Traffic that looks like ordinary service-to-service communication may become chargeable when it passes through:

• VPC endpoints with PrivateLink
• NAT gateways processing traffic
• Load balancers in the service path
• Cross-AZ boundaries introduced by placement or routing

These may be required for security, isolation, routing, or operations. The problem is when teams do not realize that adding one of these components changes the cost model.

This is why teams need to map the top data flows by cost. Without that visibility, they may optimize instance sizes or storage classes while ignoring the service-to-service traffic patterns driving the real bill.

5. Cross-Region Replication and Hybrid Links Need a Business Case

Cross-region replication often sounds prudent: data is copied to another region for redundancy, disaster recovery, or proximity to users. The cost issue is that every byte leaving its original region can incur transfer fees, and the sending side pays. In the AWS examples, cross-region charges vary, with rates beginning around $0.02 per GB.

S3 Cross-Region Replication is used as an example of a pattern that can create strong redundancy while also turning a calm storage cost curve into a steep data transfer bill. The storage itself is not the only expense; every replicated copy has a movement cost attached.

Hybrid and multi-cloud links create a similar problem. “Bursting into Azure” or running workloads across two regions can sound agile or resilient, but the data must move through a paid path first. If replication traffic costs more than the compute it protects, the design needs a clear business justification.

Multi-cloud is therefore not automatically a best practice. It should be driven by a compelling strategic requirement, not by the assumption that distributing workloads across providers is inherently more mature. Different applications can reasonably live in different clouds, especially after acquisitions or when an application is already tied to a platform. Moving everything just to create uniformity can be heavy, expensive work without sufficient return.

6. CDN and Edge Services Move the Meter Rather Than Removing It

Putting traffic behind a CDN can improve user experience, but it does not make egress free. CloudFront is the example: edge traffic is charged based on where the requesting client is located, which can make costs more dependent on user geography than teams expect.

The caching model matters. If traffic patterns align with the CDN configuration, an edge service may reduce origin load, improve latency, and produce a measurable business benefit. If the configuration does not match how users actually access data, the organization may add complexity while paying twice in effect: once to store or move the data, and again to serve it through the edge path.

CDN optimization should be measured against the outcome it is supposed to improve. In one ROI framing example, a CDN change increases egress costs by 40% but reduces latency by 12 milliseconds, improves customer conversion by 0.3%, and produces a net business impact of $87,000 per year.

7. Data Gravity Is a Major Source of Lock-In

The session distinguishes technical portability from economic portability. Compute can often move: containers, functions, and even virtual machines can be shifted with the right engineering effort. Data is harder. Every stored, replicated, and synchronized gigabyte makes the environment harder and more expensive to move.

This is one way vendor lock-in emerges. It is not always the result of choosing one provider’s proprietary service. Often, it is the accumulated cost of moving data away from where it already lives.

Hybrid and multi-cloud strategies are often presented in terms of flexibility, best-of-breed services, and placing each workload in the right location. The warning is that every “right place” requires paying to get the data there, and often paying again to get it back.

For engineering teams, networking may look like packets and routes. For finance teams, it looks like patterns and predictability.

8. ROI Should Be Measured by the Return the Network Provides

Cost optimization does not simply mean spending less. It means spending with intent. A network connection should improve performance, reduce risk, or increase leverage. If it does none of those, it is not a strong architectural decision.

The session identifies three major forms of networking ROI:

• Performance ROI. Faster connections, lower latency, and better user experience can translate into business value, such as higher conversion rates.
• Resilience ROI. Redundant paths and replicated environments are forms of insurance. The cost should be measured against the risk reduction they provide, and the architecture should be tested to ensure it can actually survive the failure scenario it is meant to cover.
• Flexibility ROI. Hybrid and multi-cloud designs can provide optionality, including the ability to move workloads, negotiate pricing, or avoid lock-in. But optionality only has value if the organization can actually use it.

Practical ROI framing examples include:

• A multi-region setup costing $47,000 per month may be justified if it prevents an outage whose expected financial impact supports roughly a three-year return timeline.
• Moving 2 TB per day between services for $1,800 per month may be reduced to $600 per month by consolidating services into the same availability zone, with a two-week engineering effort and a three-month payback.
• A CDN optimization may be worthwhile even with higher egress costs if the performance gain produces measurable annual business value.

This is the difference between asking “How much does it cost?” and asking “Where is the return?”

9. Resilience and Optionality Must Be Tested to Be Real

Disaster recovery and multi-region plans often fail the first time they are tested. A common pattern is that a DR test fails, the team improves it, it fails later in the path, and the cycle repeats until the quarterly checkbox is satisfied. Then the next change to the environment can break the plan again.

Resilience is not real unless it is continuously validated. A passive multi-region environment that is rarely tested may create ongoing cost without reliable recovery. Active-active operation, regular failover testing, or repeated failback exercises are ways to make the investment concrete.

The same scrutiny should apply to dependencies outside the team’s own cloud architecture. An e-commerce company may decide to add Azure in case AWS has an outage, but if its payment processing depends on a provider that is itself heavily dependent on AWS, the design may not eliminate the business-level single point of failure. It may simply add another failure mode at significant cost.

Flexibility has the same requirement. If a team cannot quantify what it would cost to migrate off a provider, it does not truly have that flexibility. It has an aspiration.

10. Intentional Design Starts With Data Locality and Measurement

The recommended operating model begins with intent. Teams should identify which data must move, which data can stay put, and which workflows can be designed around locality.

Useful questions include:

• What are our top five data flows by cost? If the team cannot answer quickly, cloud spend is being managed by assumptions rather than data.
• What business outcome does each data movement enable? Vague answers indicate that the organization may be paying for motion rather than value.
• Would we build this the same way today? If not, what prevents change, and does fixing it have a measurable payoff?
• What would it cost to migrate away from this provider? Without a quantified answer, optionality is not a proven capability.
• Can the data be recreated, delayed, or left unavailable for a period of time? Not all data requires immediate replication to another region or provider.

The mature approach is to optimize for choices that improve business outcomes. Some organizations will benefit from multi-cloud as a portfolio strategy. Others can be fully committed to one provider and be making the right choice. Context determines the answer.

Key Takeaways

• Cloud networking cost is architectural pressure. Data transfer fees influence workload placement, resilience design, cloud provider strategy, and long-term portability.
• Inbound and outbound traffic behave very differently. Inbound traffic is generally free, while outbound, cross-region, inter-AZ, CDN, and special-case traffic can create material charges.
• Private connectivity still requires a full cost model. Lower egress rates may be offset by hourly port fees, so the total economics must be calculated before choosing a connection model.
• Resilience has to justify its spend. Multi-AZ and multi-region designs should be measured against the failure scenarios they actually survive.
• Multi-cloud is not automatically a best practice. It should be adopted for specific strategic reasons, not because it looks flexible on an architecture diagram.
• CDNs and edge services are not free egress. They can improve latency and business outcomes, but only when traffic patterns and caching behavior support the design.
• Data gravity is a major form of lock-in. Compute may be portable, but accumulated data movement costs can keep workloads anchored.
• Optimization means spending with intent. Every network path should improve performance, reduce risk, or increase business leverage.
• Measurement is the starting point. Teams need visibility into their highest-cost data flows before they can make credible architectural decisions.

Conclusion

The central lesson is that cloud networking costs are not secondary details to be handled after architecture decisions are made. They are part of the architecture itself. Every region choice, replication policy, inter-AZ dependency, CDN configuration, and private connection has an economic consequence that can either support or undermine the business case.

Hybrid and multi-cloud strategies should therefore be evaluated through measurable ROI rather than abstract flexibility. Performance improvements, resilience investments, and optionality all have value, but only when the organization can quantify the benefit and prove the design works under real conditions.

For practitioners and decision-makers, the right next step is visibility: know where the data flows, how much each flow costs, and what outcome each movement enables. The best cloud strategies are not the ones that chase every portability ideal. They are the ones that consciously choose where data should live, when it should move, and why the cost is worth paying.