Let's talk networking. And AI. And infrastructure. And everything. Register for Connect 2026
Megaport Connect
A first-of-its-kind virtual summit built to help network engineers and IT leaders upskill, share ideas, and connect around the future of cloud and hybrid networking
See how even milliseconds of latency can impact revenue and user experience in high-performance applications.
Marko Sluga walks through tuning strategies like east-west traffic optimization, DNS tweaking, and colocation. Learn how technical tuning delivers real business outcomes.
Presented by: Marko Sluga, Delivery Lead, Enterprise Skills Transformation at AWS.
Marcos Luga, a delivery lead with Amazon Web Services, presented this Megaport Connect session on how cloud network design affects application latency. Drawing on his background in IT, cloud, and networking, he framed cloud as a shift from physical infrastructure toward service orchestration, where network decisions are tied directly to compute, storage, application services, databases, security controls, and observability.
The core message is that network engineers working in the cloud have a broader performance responsibility than they may have had in traditional environments. In a cloud application, latency is shaped by region choice, Availability Zone placement, subnet design, VPC connectivity, load balancing, edge services, database architecture, caching, security controls, and monitoring. A design that is logically correct can still produce avoidable milliseconds of delay if these components are placed or combined poorly.
The webinar uses AWS terminology and services as the reference model. It focuses on where to deploy workloads, how to think about subnets and Availability Zones, when to choose a Network Load Balancer instead of an Application Load Balancer, how Route 53 and CloudFront improve global performance, and why application and database behavior can dominate the latency budget.
Cloud changes the mental model for network design. In an on-premises environment, networking often centers on physical devices and visible infrastructure: switches, routers, cables, subnets, and firewalls. In the cloud, the network is intertwined with managed services and application architecture.
That means network engineers need to understand how compute, storage, databases, and application services connect to one another. Compute placement can affect subnet choice; database placement can affect replication latency; load balancer choice can affect both routing flexibility and response time. These decisions define how traffic flows through the application.
This expanded scope matters because architecture can directly affect business outcomes. The transcript cites research from Amazon, Google, Akamai, and others indicating that an additional 100 milliseconds of application latency can reduce conversions by 7%. The example is a page element, such as an advertisement, that technically loads but appears too late for the user to see it before scrolling past.
The first major latency decision is where the application is deployed. A cloud region should generally be selected based on proximity to the users the application serves. U.S. users should be served from a U.S. region; users in Singapore should be served from a Singapore region.
Traffic between distant geographies can add dozens of milliseconds before the application does any work. Deploying close to users does not eliminate all latency, but it improves the baseline for the rest of the architecture.
In AWS terminology, a region is a set of connected Availability Zones. Each Availability Zone may contain multiple data centers. This distinction is important because a region is not a single physical site, and the placement of services across Availability Zones becomes a major latency and resilience design choice.
Availability Zones are one of the most important performance boundaries in the AWS-style model described in the session. Services placed within the same Availability Zone can typically communicate with very low latency. The expected baseline is generally under one millisecond, although higher percentile measurements may sometimes exceed that.
This differs from many traditional on-premises assumptions. In a data center, crossing between subnets may require traffic to pass through a router. In the cloud design described here, the more important distinction is often whether the subnets are in the same Availability Zone.
The webinar distinguishes the roles clearly:
For traffic between Availability Zones, the normal expectation is single-digit milliseconds. The session describes typical observed values around two to five milliseconds and a general expectation of staying under 10 milliseconds. If measured latency is materially higher, the issue may be an overloaded database, an application component, or another service-level bottleneck.
A VPC is a logical grouping of network address space. Teams define a larger IP address range and then create subnets from that range for specific workloads. VPCs can also be connected to one another, with VPC peering as the simplest model and AWS Transit Gateway referenced as a way to connect up to 5,000 networks or VPCs.
The important latency point is that logical separation does not always mean higher latency. If two VPCs are peered and the relevant subnets reside in the same Availability Zone, traffic can still remain in the same low-latency profile as other same-AZ communication.
That can feel unusual to engineers coming from traditional networking. A workload reaching a database in another Availability Zone may see two to five milliseconds of added latency, while a workload reaching a subnet in a separate VPC but the same Availability Zone may remain below one millisecond.
The design lesson is to treat the Availability Zone as the primary latency component and the subnet as the primary addressing component. VPCs, subnets, route tables, peering, and transit connectivity remain essential for segmentation and reachability, but latency depends heavily on where resources land within the region.
Load balancers affect both application design and latency. The session focuses on two AWS options: the Application Load Balancer and the Network Load Balancer.
An Application Load Balancer operates at layer 7. It understands HTTP requests and can route based on application-layer information. That makes it useful when requests need to go to different backends, such as mobile services, desktop services, or internal user services.
That flexibility has overhead. The load balancer must inspect the request and make protocol-aware routing decisions. For applications that need this behavior, the trade-off may be appropriate, but it is not the lowest-latency option.
A Network Load Balancer operates at layer 4. It forwards TCP, UDP, and TLS/SSL traffic without inspecting application payloads in the same way. The session describes it as capable of forwarding tens of millions of packets per second. When raw performance and low latency are the main requirements, the Network Load Balancer is the preferred choice.
The practical guidance is straightforward: choose the Application Load Balancer when application-aware routing is required; choose the Network Load Balancer when performance is the priority.
Even when a region is close to users, public internet routing can add unpredictable latency. Users pass through their ISP, local internet exchanges, and potentially multiple intermediate hops before reaching a cloud region. The session describes how shared internet exchange infrastructure can suffer from uneven capacity planning. As traffic crosses more hops, performance can degrade into high tens of milliseconds or even around 100 milliseconds within the same broad geography.
Edge services reduce that dependency by giving users a nearby path into the cloud provider’s network. The AWS example includes more than 500 points of presence. The objective is for users to reach an edge location quickly, often within less than 10 milliseconds, and then use the provider backbone to reach regional services more efficiently.
Two AWS edge services are central to the design:
DNS time to live matters for this architecture. If a region or endpoint fails, DNS redirection depends on how quickly clients and resolvers honor new answers. Appropriate TTL settings help users move to the next available region or frontend more quickly.
CloudFront can also accept connections and offload TLS certificate handling. This reduces backend work and allows TLS handshakes to happen close to the user. Cached content can be returned directly from the edge. Dynamic requests still need to reach the backend, but they can travel from the edge location to the region over the provider backbone rather than through a long chain of public internet hops.
For workloads that need very low latency to a specific place or user population, the session describes deployment models that move cloud infrastructure closer to users.
Local Zones are described as Availability Zone-like deployments outside a standard region. They can place cloud resources closer to a metropolitan area while remaining connected to a parent region.
Outposts bring AWS-managed infrastructure into an on-premises environment, colocation facility, data center, or office. Outposts can be full racks or single servers managed through the same AWS console and familiar tooling such as the AWS CLI, CloudFormation, Terraform, and other orchestration options. Once deployed locally, workloads can operate inside the local network and target single-millisecond latency to nearby users or systems.
Wavelength places services in mobile provider networks to reduce latency for 5G mobile applications. The stated goal is below 30 milliseconds, with real-world measurements described as often closer to 10 to 15 milliseconds in some scenarios. This can represent a significant improvement compared with traffic traveling from a mobile device through the provider network, across the internet, into a region, and back.
These options reinforce the main architectural principle: latency is not solved only by scaling compute or increasing bandwidth. Physical placement, route length, and proximity remain central design variables.
The network path is only one part of application performance. The front-end protocol, persistence model, replication design, database type, and caching strategy can add more latency than the network itself.
Important application design questions include:
The database example is especially important. A compute instance and database may reside in the same subnet and Availability Zone, but SQL-level access can still take tens of milliseconds. The transcript gives a rough range of 10 to 100 milliseconds for some SQL connection or access behavior, while noting that a well-performing SQL database may respond in under 10 milliseconds and a poor design may take seconds.
In that context, an extra two to five milliseconds between Availability Zones may not materially affect the user experience. If the database protocol or query path dominates response time, changing network placement alone will not solve the problem.
Caching can help, but cache placement must match the latency model. Services such as ElastiCache or MemoryDB can provide under-one-millisecond access when deployed close to the application. If the cache sits in another Availability Zone, the application may add two to five milliseconds to reach it. A low-latency design may require a cache in each Availability Zone.
That creates another trade-off: separate caches can behave inefficiently or inconsistently because application components may not share the same cached state. In some cases, changing the database type is the better solution. DynamoDB is presented as an option for single-digit millisecond reads and writes across Availability Zones, while DynamoDB Accelerator (DAX) is described as a write-through cache that can bring reads and writes below one millisecond. Network engineers need enough database and application awareness to advise on realistic latency design.
Security is part of the latency discussion. Some controls add little or no measurable overhead, while others can add request-processing time if configured heavily.
Security groups are stateful, port-based firewalls and are mandatory for resources deployed into a VPC, including EC2 instances, databases, SageMaker instances, and other services. Once inbound traffic is allowed, return traffic is allowed automatically. They have very low overhead and no meaningful latency effect.
Network ACLs are stateless and evaluate ordered rules. Engineers must configure both inbound and outbound rules, which adds configuration complexity. The session does not describe network ACLs as adding meaningful latency.
Together, security groups and network ACLs can provide strong controls without creating latency overhead when designed well.
DDoS protection should be transparent. AWS Shield is described as available for public-facing services such as CloudFront, Route 53, and API Gateway when run through edge locations. Its role is to block known layer 3 and layer 4 attacks. Shield Advanced is mentioned as an option for additional features.
Web application firewalls are different because they inspect requests against rules. A WAF can add roughly two to 50 milliseconds per request depending on rule optimization. Overly complex rules can add avoidable latency. The guidance is to keep low-overhead protections in place broadly and use WAF rules carefully for cases such as cross-site scripting and injection attacks.
Latency design requires measurement. The session recommends monitoring packet loss, bandwidth utilization, connection counts, and latency percentiles. Packet loss helps identify where quality is degrading. Bandwidth utilization is especially important for VPNs and Direct Connect because it informs capacity planning. Connection counts may require collaboration with application teams, load balancer metrics, or Kubernetes metrics.
Cloud environments also provide observability tools that go beyond basic network monitoring. Observability combines logs, metrics, and traces so teams can correlate behavior across distributed systems.
The AWS examples include:
Distributed tracing is especially relevant in multi-stack applications because one user request may pass through multiple services before completing. By attaching a trace identifier to requests, teams can determine whether latency is coming from the network, a service boundary, a function, a database backend, or another dependency.
Shaving milliseconds from a multi-stack application requires more than tuning a single network path. It requires understanding how cloud regions, Availability Zones, VPCs, load balancers, edge services, databases, caches, security controls, and observability tools work together. A small placement decision can be insignificant in one architecture and critical in another, depending on protocols and data access patterns.
The most important shift for practitioners is to think beyond traditional subnet and routing boundaries. In the AWS model described in the session, Availability Zone placement is often the more important latency boundary, while subnets primarily structure address space. Similarly, the fastest network path may not matter if the database or application protocol adds far more delay than the network.
For decision-makers, the session reinforces that low-latency cloud architecture is a design discipline, not a default outcome of moving to cloud. The right region, the right load balancer, the right edge strategy, the right database model, and the right monitoring approach all contribute to the user experience. The goal is to make latency visible, understand which components actually add delay, and choose architectures that match the performance requirements of the application.
With a Megaport Solutions Architect
We’ve helped hundreds of customers, just like you, to simplify their connectivity.
