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
Discover how to design zero-trust, multi-cloud security architectures. This session covers the interplay of native security controls (SGs, NACLs, IAM) with third-party tooling.
You’ll gain insights into segmenting cross-cloud traffic, enforcing identity-aware policies, and building for audit-readiness, compliance, and operational safety.
Presented by: Shawn Nunley and David Gargan.
The supplied transcript presents a technical session delivered by Marcos Luga, a delivery lead with Amazon Web Services, focused on cloud networking design and application latency. While the page context identifies this webinar as a cloud security architecture session, the transcript itself centers on how cloud infrastructure choices affect end-to-end application performance, with security controls addressed as part of the latency and operational design discussion.
The central message is that cloud networking requires a different mental model from traditional on-premises networking. Network engineers are no longer responsible only for switches, routers, and subnets; their decisions are tied directly to compute placement, storage access, application services, database design, load balancing, edge delivery, observability, and security controls.
The session uses AWS terminology and services as its reference architecture. It explains how regions, Availability Zones, subnets, VPCs, load balancers, edge locations, CloudFront, Route 53, Outposts, Wavelength, database services, security groups, network ACLs, DDoS protection, web application firewalls, and monitoring tools all influence application responsiveness and operational safety.
Moving from traditional IT infrastructure to cloud changes the responsibilities of the network engineer. In an on-premises environment, networking work often centers on physical infrastructure: switches, routers, cabling, firewalls, and data center topology. In the cloud, the network becomes part of a larger service orchestration model.
That shift means network design must account for how multiple cloud services interact:
The practical consequence is that network architecture can directly affect application response times. A poorly placed workload, an inappropriate load balancer, or a misunderstanding of cross-zone latency can create measurable performance issues even when the network appears logically correct.
The session emphasizes that latency is not only a technical metric; it can affect business outcomes. The transcript cites research from sources including Amazon, Google, Akamai, and others indicating that an additional 100 milliseconds of application latency can reduce conversions by 7%. The example given is an advertisement or page component that loads too late to be seen by a user before they scroll past it. In that scenario, the content technically loads, but it fails to deliver value because the timing is wrong.
Cloud applications are often intended for broad or global audiences, so region selection becomes one of the first meaningful latency decisions. A region should generally be chosen based on proximity to the users the application serves.
If customers are primarily in the United States, deploying in a U.S. region avoids unnecessary transcontinental latency. If customers are in Singapore, a Singapore region is the more appropriate primary location. Traffic between major geographies, such as the United States and Europe, can add dozens of milliseconds before the application itself does any work.
Region placement does not eliminate all latency, because users still reach the cloud through their ISP, local internet exchanges, and intermediate network paths. However, starting with a nearby region reduces the physical distance traffic must travel and improves the baseline available to the rest of the architecture.
The session also distinguishes between regional latency and latency inside a region. A region is not a single data center. In AWS terminology, a region is composed of multiple connected Availability Zones, and those Availability Zones contain one or more data centers. Understanding this structure is essential because the physical and logical placement of subnets and services determines the latency profile of the application.
Availability Zones are a major performance boundary in AWS-style cloud design. Services placed within the same Availability Zone can generally communicate with very low latency. The transcript describes the typical expectation inside an Availability Zone as under one millisecond, while acknowledging that 90th or 99th percentile measurements may sometimes exceed that.
This differs from many on-premises assumptions. In a traditional environment, two subnets might be connected through a router, and crossing between them may add measurable overhead compared with staying within one subnet. In the AWS design described in the transcript, latency is less about whether two resources are in the same subnet and more about whether the relevant subnets are in the same Availability Zone.
Key distinctions include:
For traffic between Availability Zones, the transcript describes typical latency as single-digit milliseconds, often around two to five milliseconds, with a general expectation of staying below 10 milliseconds. If latency is materially higher than that, the likely cause may be an application issue, an overloaded database, or another service-level bottleneck rather than the basic inter-AZ network path.
The design implication is clear: when establishing a latency baseline, engineers should look beyond subnet boundaries and understand exactly which Availability Zones host each component.
A VPC is described as a logical grouping of networks and IP address space. Within that larger address space, teams create and consume subnets for workloads. VPCs can also be connected to each other, most simply through VPC peering.
The transcript also references transit-style connectivity that can connect up to 5,000 networks or VPCs. The important performance point is that logical network separation does not necessarily mean high latency. If two VPCs are connected and the relevant subnets reside in the same Availability Zone, the traffic may still experience latency comparable to other same-AZ communication.
This can create results that feel counterintuitive to engineers coming from traditional network environments. A workload communicating with a database in another Availability Zone may see a two-to-five millisecond penalty, while a workload communicating with a different VPC in the same Availability Zone may remain below one millisecond.
The practical recommendation is to treat the Availability Zone as the primary latency component and the subnet as the primary addressing component. VPCs, subnets, routes, and peering still matter for segmentation and reachability, but application performance depends heavily on where workloads physically and logically land within the cloud provider’s regional architecture.
Load balancers are another major design decision. The transcript 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 and can inspect request information to route traffic to different backends. This enables flexible application-aware routing patterns, such as sending mobile requests, desktop application requests, and internal user requests to different backend services.
That flexibility comes with overhead. Because the load balancer reads the request and uses protocol-level information to make routing decisions, it adds processing compared with a simpler forwarding model.
A Network Load Balancer operates at layer 4. It is presented as a high-performance option for TCP, UDP, and TLS/SSL traffic. It does not inspect the application payload in the way an Application Load Balancer does; it forwards traffic across backend targets. The transcript states that this model can handle tens of millions of packets per second.
The design trade-off is:
The session’s recommendation is direct: when performance is the primary requirement, use the Network Load Balancer.
Even with a well-chosen region, public internet paths can introduce unpredictable latency. Users reach cloud applications through ISPs, local exchanges, and intermediate hops. The transcript notes that internet exchange performance can vary because multiple vendors operate shared infrastructure and may provision only enough capacity for their own needs. As traffic crosses more hops, performance can degrade significantly, potentially producing high tens of milliseconds or even around 100 milliseconds of response time within the same general geography.
Content delivery and edge services help reduce that dependency on long, variable internet paths. The AWS example in the transcript includes more than 500 points of presence. The goal is to give users a nearby path into the cloud provider’s edge network rather than forcing traffic through many public internet hops before it reaches a region.
Two edge services receive specific attention:
DNS time to live matters in this model. If there is a failure, DNS-based redirection depends on how quickly clients and resolvers honor updated routing decisions. Low or appropriate TTL values can improve failover behavior, while longer TTL values may delay redirection.
CloudFront can also accept connections and offload TLS certificate handling. This reduces work on backend services and enables faster connection handling at the edge. For cached content, users can receive responses directly from the nearby edge location. For dynamic requests such as posts, CloudFront can still provide a fast initial response path and forward the backend operation over the cloud provider’s backbone to the origin service.
For workloads that need very low latency to a specific physical environment, the transcript describes specialized deployment models that bring cloud-style infrastructure closer to users or devices.
Local Zones are described as Availability Zone-like deployments outside a standard region. They can be connected back to a region while placing cloud resources closer to a particular metropolitan area or user base.
Outposts bring AWS-managed infrastructure into an on-premises environment, data center, colocation facility, or office. The transcript describes Outposts as full racks or single servers that can be managed through the same AWS console and accessed using familiar tooling such as the AWS CLI, CloudFormation, Terraform, or other orchestration options. Once deployed locally, applications can run inside the local network and target single-millisecond latency to nearby users or systems.
Wavelength is presented as a deployment model for mobile-provider networks. Its purpose is to reduce latency for 5G mobile applications by placing services closer to mobile users. The transcript describes a goal of under 30 milliseconds and notes that real-world measurements may be closer to 10 to 15 milliseconds in some scenarios.
These deployment models reinforce the broader design principle: application performance is not solved only by scaling compute or increasing bandwidth. Physical placement, network path length, and proximity to users or devices remain central architectural considerations.
Network placement matters, but application and database behavior can outweigh network latency. The transcript cautions that front-end protocols, data persistence models, database replication, and access patterns all influence user-facing performance.
Several application design questions are important:
The database example is especially important. A compute instance and primary database may reside in the same subnet and Availability Zone, but the SQL connection itself can take tens of milliseconds. The transcript gives a range of roughly 10 to 100 milliseconds for SQL-level connection or access behavior in some scenarios, while acknowledging that a well-performing SQL database can respond in under 10 milliseconds and a poor design may take seconds.
In that context, an extra two to five milliseconds of inter-AZ latency may not matter. If the database protocol and query path dominate the response time, changing Availability Zone placement alone may not materially improve the application.
Caching is one common acceleration strategy. Services such as ElastiCache or MemoryDB can keep frequently retrieved data closer to the application and provide under-one-millisecond access when placed appropriately. However, cache placement also has to follow the Availability Zone latency model. A cache in another Availability Zone may add two to five milliseconds, reducing its effectiveness. The transcript therefore recommends deploying caching instances in each Availability Zone when low latency is required.
That design can introduce a different problem: split cache behavior. If application components in different Availability Zones use separate caches, cache efficiency and consistency may be affected. In some cases, changing the database type may be a better architectural move.
The transcript gives DynamoDB as an example of a database option that can provide single-digit millisecond reads and writes regardless of Availability Zone. It also mentions DynamoDB Accelerator (DAX), described as a write-through cache that can bring reads and writes below one millisecond. The broader lesson is that network engineers need enough understanding of the database service to advise on realistic performance architecture.
Security controls are part of the application performance model. The transcript distinguishes between controls that have little or no latency impact and controls that can add request-processing overhead.
Security groups are described as mandatory for instances and services placed in a VPC, including EC2 instances, databases, SageMaker instances, and other resources. They function as stateful, port-based firewalls. Once a port is allowed inbound, return traffic is allowed automatically. The transcript characterizes security groups as having very low overhead and no meaningful latency effect.
Network access control lists, or network ACLs, are stateless. They evaluate ordered rules and require both inbound and outbound rules to be configured. The added complexity is primarily operational: engineers must manage bidirectional rule logic and ordering. The transcript does not describe network ACLs as adding meaningful latency, but it does emphasize the configuration overhead.
Used together, security groups and network ACLs can provide strong network security controls without introducing latency overhead.
DDoS protection should be transparent in modern application architectures. The transcript describes AWS Shield 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. The key architectural point is that network-layer DDoS mitigation should not become a visible performance penalty when implemented correctly.
Web application firewalls require more caution from a latency perspective. The transcript states that a WAF can add roughly two to 50 milliseconds per request, depending on how optimized the rules are. Overly complicated rule sets can add significant latency. The recommendation is to avoid unnecessary complexity and focus WAF rules on important edge cases such as cross-site scripting or injection attacks.
Security therefore should not be treated as separate from performance architecture. Low-overhead controls can be used broadly, while request-inspecting controls should be designed and tuned carefully.
The session closes with monitoring and observability considerations. Traditional network metrics still matter in the cloud, including packet loss, bandwidth utilization, connection counts, and latency percentiles.
Packet loss helps identify where quality is degrading. Bandwidth utilization is important for capacity planning, especially when VPNs or dedicated connectivity such as Direct Connect are involved. Connection counts may require coordination with application teams because relevant data can exist at the load balancer, Kubernetes, or application layer. Latency percentiles remain important in the cloud just as they are on premises, because averages can hide tail-latency problems.
Cloud environments also provide observability tools that correlate logs, metrics, and traces:
This observability model is essential because cloud application latency is usually distributed across multiple services. Troubleshooting requires visibility into the network path, application layer, load balancing tier, compute services, and backend dependencies.
Cloud architecture requires a service-aware approach to networking. Engineers need to understand not only routes, subnets, and firewalls, but also how application protocols, database access, load balancers, edge networks, and security tools shape the end-user experience.
The most effective designs begin with placement: choosing the right region, understanding Availability Zone boundaries, and locating workloads, caches, and databases where they support the required latency profile. From there, architects can choose load balancers, edge services, and specialized deployments based on whether the application needs flexibility, throughput, global reach, or sub-millisecond local access.
Security and observability are not separate concerns. Stateful security groups, network ACLs, DDoS protection, and web application firewalls must be selected and tuned with awareness of their operational and latency characteristics. Monitoring and distributed tracing then provide the evidence needed to identify whether a performance problem lives in the network, the application tier, the database layer, or a supporting cloud service.
The overall lesson is that cloud performance and resilience come from coordinated architecture. Network engineers remain central to that work, but success depends on understanding the full application path from user to edge, from edge to region, and from application services to the data layer.
With a Megaport Solutions Architect
We’ve helped hundreds of customers, just like you, to simplify their connectivity.
