Lecture 234: The legacy way of using the Network appliances
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：07:30
- 来源：Udemy Lecture 29240432
- Slide 数量：5
- 画面切换：01:28、02:54、03:52、06:04
扫描说明
逐条读取了 Transcript 面板中的 176 条英文 cue，并按播放器可见时钟扫描全长约 07:30 的视频。依据 GWLB Motivation、On-Prem Hardware Hairpin、IGW Ingress Routing、Single Virtual Appliance、HA/Scaling Limitation 划分为 5 个小节。5 张截图从实际视频内容区精确裁取，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. GWLB 之前缺少统一的 Transparent Appliance Insertion 与 Scale
时间范围：00:00–01:28
总结 / Summary
中文
Gateway Load Balancer（GWLB）在 re:Invent 2020 推出，用于把 Third-party Virtual Network Appliance 透明插入 Traffic Path，并提供 High Availability 与 Horizontal Scaling。它既可处理 North-South Flow（Internet Ingress/Egress），也可处理 East-West Flow（VPC-to-VPC），适用于 Firewall、IPS/IDS、Deep Inspection、Network Analytics 等 Appliance。此前架构能做 Traffic Steering，但没有标准化的 Health-aware Load Balancing。
English
Gateway Load Balancer launched at re:Invent 2020 to insert third-party virtual network appliances transparently into traffic paths while providing high availability and horizontal scale. It handles north-south Internet ingress and egress as well as east-west VPC-to-VPC flows, supporting firewalls, IPS or IDS, deep inspection, and network analytics. Earlier architectures could steer traffic but lacked a standardized, health-aware load-balancing layer.
Transcript
00:00 Hello and welcome to this lecture,
00:01 gateway load balancer.
00:03 Now, this is one of the most important service
00:05 that AWS launched recently in the networking domain
00:08 and this service was launched during the re:Invent 2020.
00:12 Now, before gateway load balancer,
00:14 there wasn't a standard way or a good way to really deploy
00:18 third party virtual network appliances in AWS
00:21 and then the ability to route all ingress or egress traffic
00:26 through that third party virtual appliances.
00:28 There are some architectures
00:29 that we are going to talk throughout this lecture
00:31 but then there wasn't a very good way
00:34 which will give you the high availability
00:36 as well as scaling capability
00:38 and that is what exactly the problems,
00:40 this gateway load balancer that solves.
00:42 So whether your traffic is a north-south,
00:44 that means it's going to the internet
00:46 or coming from the internet
00:47 or the traffic between multiple VPCs,
00:50 which we typically call east-west traffic.
00:52 You can put a gateway load balancer
00:54 as a transparent gateway in between
00:57 and then all the traffic can be then inspected
01:00 using the gateway load balancer endpoints.
01:03 Now, when we say traffic can be inspected,
01:06 it is not just about,
01:08 say a firewall or IPS or IDS system
01:11 but maybe you want to do some analysis of that traffic,
01:14 or you want to mirror that traffic.
01:16 So there are so many use cases that you can implement
01:19 using the gateway load balancer.
01:21 So with that, let's get started
01:23 and see why gateway load balancer was introduced
01:26 and what problems it solves.
2. Hardware Appliance 留在 On-Prem，Cloud Traffic 被迫 Hairpin
时间范围：01:28–02:54
总结 / Summary
中文
早期许多 Vendor Appliance 只有 Hardware Form Factor，企业又希望 On-Prem 与 AWS 使用同一 Inspection Policy，于是通过 VPN 把 Cloud Application Traffic 先送回 Corporate Data Center Appliance，检查后再送回 AWS Workload。这个 Hairpin 需要复杂的 Route/Re-route，依赖 Hybrid Link，而且 Packet 往返 On-Prem 会增加 Latency、Bandwidth Usage 与 Failure Domain，明显不适合高吞吐 Cloud-native Workload。
English
Many early vendor appliances existed only as hardware, while enterprises wanted the same inspection policies on premises and in AWS. Cloud application traffic therefore crossed a VPN to appliances in the corporate data center, was inspected, and returned to the AWS workload. This hairpin required complex routing and rerouting, depended on the hybrid link, and added latency, bandwidth consumption, and another failure domain—poor characteristics for high-throughput cloud-native workloads.
Transcript
01:28 Okay. So if you go a few years back,
01:30 we had hardware-based network appliances
01:33 and typically any organization
01:35 wanted to have the same policies
01:37 or same network traffic inspection policies
01:39 whether they're operating on premises or in AWS Cloud.
01:43 Then the only option was to host this network appliances
01:46 in on-premise data centers.
01:48 Now, in this case, if you look at this architecture,
01:50 there needs to be a VPN connection
01:52 between a cloud and your on-premise network.
01:55 And then any traffic that lands into your cloud application
01:59 first has to get routed back
02:01 to your on-premise network appliances,
02:03 do whatever analysis you want to do,
02:05 and then the packet comes back to the applications.
02:08 So this is an architecture that people use to implement
02:12 because one, the appliances were hardware-based.
02:15 They were not virtualized.
02:17 And second, the companies wanted to have same policies
02:21 across both the networks.
02:24 Now, if you look at this architecture, it's complex,
02:27 there is a lot of routing and re-routing involved here
02:29 because as the traffic lands here,
02:31 you have to force this traffic
02:33 to on-premise data center network appliances
02:36 then you have to route that back to your applications.
02:39 So you can imagine, you know,
02:41 there are very complex routing policies involved there.
02:44 And of course, there would be a high latency
02:46 because packet has to flow from AWS
02:49 to your on-premise data center and come back,
02:51 so this clearly is inefficient.
3. VPC Ingress Routing 简化 AWS 端 Steering，但不消除 On-Prem Latency
时间范围：02:54–03:52
总结 / Summary
中文
VPC Ingress Routing 允许把 Route Table Edge-associate 到 Internet Gateway：若 Destination 是 Application Subnet，可先把 Packet Target 指向 Virtual Private Gateway，再经 VPN 到 On-Prem Appliance；检查后的 Traffic 回到 VGW 并进入 Workload。AWS 端 Route 变得更清晰，但物理路径仍然 AWS → On-Prem → AWS，High Latency 与 Hybrid Link Capacity 问题没有消失。
English
VPC ingress routing allows a route table to be edge-associated with an Internet gateway. Traffic for an application subnet can target a virtual private gateway first, cross the VPN to on-premises appliances, and then return through the VGW to the workload. This simplifies AWS-side routing, but the physical path still runs AWS to on premises and back, so latency and hybrid-link capacity constraints remain.
Transcript
02:54 And in order to solve some part of this problem,
02:57 what AWS did in 2019, again,
03:01 launched something called ingress routing for your VPC.
03:04 Now what does that mean is, from internet gateway,
03:07 if there is an ingress traffic
03:09 that is coming to an internet gateway from outside,
03:12 you can route that traffic to your on-premises
03:15 via your virtual private gateway.
03:18 So you can associate the route table to internet gateway
03:21 and you can say if the traffic
03:23 is for your application server,
03:25 it has to first go through VGW
03:28 and in VGW, you have already an VPN connection
03:31 which will take that all the traffic to on-premises
03:34 and from there,
03:34 traffic will come back to the VGW
03:36 and to your application server.
03:38 So this is, again, the same problem of latency is there
03:41 but now routing is becoming simple for you at the AWS end
03:46 because you are using the VPC ingress routing.
03:49 So in this case, routing is simple
03:50 but still is the high latency.
4. Virtual Appliance 放进 VPC，用静态 ENI Route 实现双向检查
时间范围：03:52–06:04
总结 / Summary
中文
Vendor 将 Appliance Virtualize 后，可在 EC2 上运行。IGW Ingress Route 把 Application Subnet CIDR 指向 Appliance ENI；Application Subnet Default Route 也指向同一 ENI；Appliance Subnet 再把 Internet-bound Traffic 送到 IGW。这样 Inbound 与 Return/Egress 都经过 Appliance，避免 On-Prem Hairpin。Appliance Instance 还需适当关闭 Source/Destination Check，并正确配置 Forwarding、SG/NACL 与对称路由。
English
Once vendors virtualized their appliances, they could run on EC2. The IGW ingress route sends the application-subnet CIDR to the appliance ENI, the application subnet's default route also targets that ENI, and the appliance subnet sends Internet traffic to the IGW. Inbound and return or egress traffic now traverse the appliance without an on-premises hairpin. The appliance instance also needs source and destination checks handled appropriately, forwarding configured, and correct SG, NACL, and symmetric routing.
Transcript
03:52 So how do you solve that problem?
03:54 So the partners of AWS or that are known companies
03:59 which operates in the appliance world
04:01 for the network, like Cisco Juniper
04:04 and so many there are checkpoints, right?
04:06 They virtualize their network appliances
04:09 which means that now you could have the network appliances
04:12 running on the virtual machine
04:14 inside your VPC on EC2 machine, right?
04:17 So now instead of having hardware-based network suppliers,
04:21 you could have EC2 based network appliance
04:23 and now as you learnt about the VPC ingress routing,
04:27 you can configure the internet gateway route table
04:29 and say, if the traffic is going to your application subnet,
04:34 it has to go first to the ENA of your network appliances.
04:37 So this is what VPC ingress routing can do, right?
04:41 Now, you host your network appliance on this EC2 instance
04:45 and then if you look at, say an ingress traffic flow,
04:48 as the traffic comes from the internet,
04:50 it looks at this route table
04:52 and if the traffic is for your application.
04:55 So, you know, that internet gateway also does the natting
04:58 and it would send the traffic to 10,0,10,0,24 subnet
05:03 because application is there
05:04 and it is having a public IP of itself
05:07 and before sending it to this,
05:09 it will directly send it to the ENA of network appliance
05:12 and then once it lands into the network appliance,
05:15 it knows how to send this traffic to the application
05:17 because it has the destination IP,
05:20 application would receive the packet
05:22 and then it will respond.
05:24 While responding, it will also look at its own route table
05:27 and here the ingresses,
05:29 if the traffic is going out,
05:30 it has to again go through the network appliance ENI.
05:33 Now that ENI is of this network appliance here
05:37 and the traffic comes back.
05:39 Again, it looks at its own route table,
05:40 it says traffic is going to the internet,
05:42 it has to go through the internet gateway
05:44 and that's where the data and traffic also goes out.
05:47 So with VPC in this routing,
05:50 you can see that you can use network appliance
05:52 for any ingress or egress traffic, right?
05:55 So you can inspect the traffic centrally
05:57 via this network appliance.
05:59 So this is a good solution
06:00 and a lot of companies are using this on AWS.
5. Single ENI Target 没有 Health Failover，也无法透明 Horizontal Scale
时间范围：06:04–07:30
总结 / Summary
中文
静态 Route 指向单一 Appliance ENI，构成 Single Point of Failure。即使在另一 AZ 启动第二台 Appliance，也要手工维护 Route；第一台失败时 Route Table 不会根据 Health 自动切换，仍把 Packet 发往失效 ENI。吞吐还受单 Instance 的 Bandwidth/Packet Processing Capacity 限制，无法在不改 Route 的情况下横向扩展。这正是 GWLB 解决的问题：在 Endpoint 与健康的 Appliance Fleet 之间提供透明分发、Health Check 与 Scale-out。
English
A static route to one appliance ENI creates a single point of failure. Even with a second appliance in another AZ, routes require manual management, and a failed first instance does not cause the route table to select the healthy ENI automatically. Throughput is also capped by one instance's bandwidth and packet-processing capacity, with no transparent horizontal scale. GWLB solves this by distributing endpoint traffic across a health-checked appliance fleet and scaling it out without changing consumer routes.
Transcript
06:04 But do you see a problem with this architecture?
06:07 Now, if you go to the AWS documentation or best practices,
06:10 it always says that your application architecture
06:13 should be highly available
06:15 and this architecture isn't highly available
06:18 for the reason that there are no multiple AZs.
06:20 We are still talking about single AZ or availability zone.
06:24 Now, if you bring in another network appliance
06:26 in another AZ,
06:28 typically what you would have to do
06:30 is to add one more route table into here
06:32 in the ingress routing table
06:34 and say the traffic has to go through another ENI.
06:38 But if one of the network appliance goes down,
06:41 the route table will still send traffic to the same ENI
06:44 which doesn't exist.
06:45 That means your traffic will be dropped.
06:47 Now this is not what you want, right?
06:49 And that was the problem.
06:50 That means with this architecture,
06:52 you cannot have a change,
06:54 neither you can scale your network appliances.
06:57 If there is so much traffic coming to your application
07:00 and suppose there is a bandwidth limit
07:02 of this network appliance,
07:03 or say a packet processing limit appliance
07:06 then you are bound by the highest capacity, right?
07:09 You can't horizontally scale this network appliances.
07:12 So that is what exactly the problem was
07:15 and in order to solve this problem,
07:17 AWS introduced the gateway load balancer.
07:19 So in the next lecture,
07:20 let's see how gateway load balancers solve this problem
07:23 and how the architecture
07:25 and traffic for gateway load balancer looks like.
07:27 So, stay tuned. Thank you.
整讲总结 / Overall Summary
中文
传统 Network Appliance 架构经历了两步：先把 AWS Traffic 经 VPN Hairpin 到 On-Prem Hardware，后把 Virtual Appliance 放到 VPC 并用 IGW Ingress/Application Route 静态指向 EC2 ENI。后者降低 Latency，但仍有静态路由、单点故障、无 Health-aware Failover 与无法 Horizontal Scale 的问题。Gateway Load Balancer 的价值就在于把这些 Appliance 变成透明、可扩展且具健康检查的服务。
English
Legacy appliance insertion evolved from VPN hairpinning AWS traffic through on-premises hardware to running a virtual appliance in the VPC and pointing IGW ingress and application routes at its EC2 ENI. The latter reduced latency but retained static routing, single points of failure, no health-aware failover, and no transparent horizontal scale. Gateway Load Balancer turns the appliance fleet into a transparent, scalable, health-checked service.
返回顶部 ↑