Lecture 199: Route 53 - TTL
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：05:28
- 来源：Udemy Lecture 28556391
- Slide 数量：7
- 画面切换：01:05、01:52、02:18、02:56、04:04、05:04
扫描说明
逐条读取了 Udemy 页面中的 135 条英文 Transcript cue，并按时间轴扫描全长约 05:28 的视频。依据 TTL/Cache 基本行为、高低 TTL 取舍、变更策略、120 秒 A Record、dig TTL 递减、Record 更新但 Cache 保留、过期后新值与 TTL 重置划分为 7 个小节。截图均在 Transcript 侧栏关闭、播放器控件隐藏后复核，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. TTL 决定 Resolver/Client 缓存 DNS Answer 的时间
时间范围：00:00–01:05
总结 / Summary
中文
TTL（Time To Live）随 DNS Record Answer 返回，例如 A 12.34.56.78 with TTL 300。Resolver/Client 在 300 秒内缓存结果；再次访问同一 Hostname 时不查询 Route 53，而直接使用 Cache 连接 Web Server，从而减少重复 DNS Query 与延迟。
English
TTL (time to live) is returned with a DNS record answer, such as A 12.34.56.78 with TTL 300. The resolver or client caches the result for 300 seconds. Repeated access to the hostname uses the cache rather than querying Route 53 again, reducing DNS traffic and latency.
Transcript
00:00 Okay, so let's have a look at TTLs.
00:02 So a record TTL is a Time To Live.
00:05 And let's take this example where a client is accessing
00:08 our DNS Route 53 and a web server.
00:10 So we do a DNS request for myapp.example.com,
00:13 and we get an answer from the DNS,
00:15 which is saying, hey, please, this is an A record.
00:19 Here is the IP, and there is a TTL,
00:21 maybe a TTL of 300 seconds.
00:24 So TTL is saying, hey clients, please cache this result
00:28 for the duration of the TTL.
00:30 So for 300 seconds,
00:31 the client is going to cache the results.
00:34 That means that if the client is requesting again
00:38 or accessing the same host name,
00:41 what's going to happen is that
00:42 the client will not issue a query to the DNS system,
00:46 because it already knows the answer,
00:48 because the answer has been cached,
00:49 and we're still within the cache period, so the cache TTL.
00:53 The idea behind this
00:53 is that we don't want to query the DNS too often,
00:57 because we don't expect records to change a lot,
00:59 and so, therefore, using the response it has,
01:01 the client can access our web server
01:03 and do HTTP request and responses.
2. High TTL 减少查询，Low TTL 加快变更传播
时间范围：01:05–01:52
总结 / Summary
中文
High TTL（如 24 小时）显著减少 Route 53 Query 和费用，但 Record 修改后客户端可能长期保留旧值。Low TTL（如 60 秒）增加查询量与成本，却缩短 Stale Record 时间，使流量切换和故障恢复更快。TTL 应根据 Change Frequency、Cost 与 Failover RTO 取舍。
English
A high TTL such as 24 hours greatly reduces Route 53 query traffic and cost, but clients may retain stale values long after a record change. A low TTL such as 60 seconds increases queries and cost while shortening stale-record time and accelerating traffic shifts or recovery. Choose based on change frequency, cost, and failover RTO.
Transcript
01:05 So we have, you know, two extreme cases.
01:08 For example, if you set a high TTL of, say, 24 hours,
01:12 then this is going to do a lot less traffic on Route 53,
01:15 because less clients are doing requests,
01:17 because the result are cached for 24 hours,
01:21 and, possibly, while the client will have outdated records.
01:24 If somehow you want to change the record,
01:26 you will need to wait 24 hours
01:28 to make sure that all your clients
01:29 will have the new records in their cache.
01:32 If you said set a low TTL,
01:33 for example, 60 seconds, at the opposite,
01:35 then it's going to do a lot more traffic on your DNS,
01:38 so a lot more dollar you're going to spend,
01:40 because you get price per how many request
01:43 do reach Route 53.
01:45 But the records will be outdated for less time,
01:47 so it's quicker for you to do a record change,
01:49 and it's easier to change records overall.
3. 计划变更时先降 TTL，等待旧 Cache 淘汰后再切换
时间范围：01:52–02:18
总结 / Summary
中文
常见 Change Strategy 是提前约一个旧 TTL 周期把 TTL 降低，等待所有 Resolver 获取较短 TTL；随后修改 Record Value，让新值快速传播；确认稳定后再提高 TTL。除 Alias Record 外，每条 Route 53 Record 都必须设置 TTL，Alias 的 TTL 由目标资源管理。
English
For a planned change, lower TTL roughly one old-TTL period in advance and wait for resolvers to adopt the shorter value. Then change the record so the new value propagates quickly, and raise TTL again after stabilization. Every Route 53 record requires TTL except an alias record, whose TTL follows the target resource.
Transcript
01:52 So it's up to you, really,
01:53 to see what a good TTL or low TTL is.
01:55 If you plan on changing a record,
01:57 the idea is that sometimes
01:58 you will decrease the TTL for, say, 24 hours,
02:01 and then when you know that all the clients
02:02 have a new TTL that is low,
02:04 then you change the record value
02:05 which gets updated for everyone,
02:07 and then you increase the TTL.
02:08 This is a strategy.
02:10 So the TTL is mandatory for every record
02:12 except the Alias record that we'll see in the next lecture.
02:15 So let's have a look how TTL works in the console.
4. 创建 TTL 120 秒的 demo A Record
时间范围：02:18–02:56
总结 / Summary
中文
在 Hosted Zone 创建 demo.stephanetheteacher.com 的 Simple A Record，Value 指向 eu-central-1 EC2 Public IP，TTL 点击两次 +1m 设为 120 Seconds。创建后它成为一个真实可访问的名称，用于直观观察 Browser 与 DNS Tool 的缓存行为。
English
Create a simple A record for demo.stephanetheteacher.com, pointing to the eu-central-1 EC2 public IP. Set TTL to 120 seconds by adding two minutes. The resulting hostname reaches a real server and allows browser and DNS-tool caching behavior to be observed directly.
Transcript
02:18 So let's have a look at how Time To Live works.
02:21 So let's create a new record,
02:22 and this one is going to be called
02:25 demo.stephanetheteacher.com,
02:27 and the value of it is going to be
02:29 one of the EC2 instances we know.
02:31 So let's take the one in eu-central-1.
02:32 So I'm gonna take this EC2 instance
02:35 and paste the value of it.
02:37 And then for the TTL, we're going to set two minutes.
02:39 So to do so I'm going to click twice on this minute button.
02:42 So the TTL is now 120 seconds.
02:45 So let me create this record.
02:48 And now my record has been created.
02:50 So it is an A record pointing to a specific IP
02:52 at demo.stephanetheteacher.com.
5. nslookup/dig 验证 Frankfurt，并观察 TTL 从 115 降到 98
时间范围：02:56–04:04
总结 / Summary
中文
Chrome 打开 demo… 返回 eu-central-1 页面；nslookup 返回正确 IP。第一次 dig 的 Answer TTL 约 115，数秒后再次查询降为 98，说明本地 Recursive Resolver 正在缓存同一 Answer，并按秒递减剩余生命周期；在归零前不会重新向 Authoritative Route 53 获取值。
English
Chrome opens the demo hostname and returns the eu-central-1 page; nslookup returns the correct IP. The first dig answer shows a TTL around 115, and a later query shows 98, proving that the recursive resolver caches the same answer and decrements its remaining lifetime instead of querying authoritative Route 53 again before expiration.
Transcript
02:56 Now, I want to show you that the record is working,
02:58 but Firefox is not very nice with me.
03:00 So if I try to open this in Firefox
03:02 it's going to give me a problem.
03:04 So this is not something I can fix easily,
03:06 so I'm going to use Google Chrome on the right-hand side
03:08 to show you this.
03:09 So if I do demo.stephanetheteacher.com on Google,
03:13 then automatically it should direct me to, yes,
03:17 my eu-central-1 instance.
03:18 So that means that this record, this A record,
03:21 is fully functioning.
03:23 And I can also make sure of that,
03:24 for example, if I'm using CloudShell.
03:26 So if I clear this and do an nslookup
03:30 on demo.stephanetheteacher.com,
03:32 as you can see, the address is correct.
03:34 And if I do a dig command on this, then we get an answer.
03:38 And there's a cool number that we're showing here,
03:40 so the answer section, there's 115.
03:43 So the idea here, that's because I did do a DNS query.
03:47 Then the record get cached for 120 seconds.
03:51 And if I retype again this dig command right here,
03:55 as you can see the number got down to 98.
03:57 So that means that for 98 seconds,
03:59 actually, I will get the same response,
04:01 because, no matter what,
04:02 this is what's cached on my computer.
6. 把 Record 改到 Singapore 后，旧 Cache 仍返回 Frankfurt
时间范围：04:04–05:04
总结 / Summary
中文
TTL 尚未归零时，把 demo A Record Value 改为 ap-southeast-1 Public IP。Route 53 已保存新值，但 CloudShell dig 仍返回旧 Frankfurt IP 与剩余 66 秒，Chrome 刷新也继续显示 eu-central-1。Authoritative Change 无法主动清除各地 Resolver 已缓存的 Answer。
English
Before the TTL reaches zero, change the demo A-record value to the ap-southeast-1 public IP. Route 53 stores the new value, but CloudShell dig still returns the old Frankfurt IP with 66 seconds remaining, and Chrome still shows eu-central-1. An authoritative change cannot proactively purge answers already cached by resolvers.
Transcript
04:04 So if I'm very quick
04:06 and I go to this record right here and I edit it,
04:09 so instead of this IP, I want to go to ap-southeast-1,
04:14 so we'll use the first IP in my list and save this.
04:19 So even though this record was being updated, okay,
04:23 if I go into CloudShell and, again, do this dig command,
04:26 as you can see, the insert is still the same as before.
04:29 That's because for 66 more seconds
04:31 this is going to be cached.
04:32 And if I go to Chrome, I think I was fast enough,
04:35 I go to Chrome and refresh this page,
04:36 as you can see, I still have the answer from eu-central-1.
04:39 And this is because, again,
04:40 my record got cached for two minutes.
04:43 So when the cache is expiring, then only then
04:47 my command line interface or my Chrome web browser
04:50 will ask again Route 53 for the value of this record.
04:54 And then, again, will I get the answer
04:56 and will be redirected to this new IP.
04:59 So the best way to check it is just to wait.
05:01 So I'm going to wait maybe one more minute
05:02 and then get back to you.
7. Cache 过期后返回 Singapore，新 TTL 重置为 120
时间范围：05:04–05:28
总结 / Summary
中文
等待旧 TTL 到期后，Browser 再次查询并显示 ap-southeast-1b；dig 的 Answer 变为新的 Singapore IP，TTL 重新从 120 开始。这个结果证明 Record Update 的生效上限受旧 TTL 约束，故障切换速度不能只看 Route 53 Console 保存是否成功。
English
After the old TTL expires, the browser queries again and displays ap-southeast-1b. dig now returns the new Singapore IP with TTL reset to 120. This proves that propagation of a record update is bounded by the old TTL, so failover speed cannot be judged only by whether the Route 53 console saved the change.
Transcript
05:04 Okay, so it's been a minute
05:05 and now if I refresh my web browser,
05:07 as you can see now, I get a different Hello World
05:09 and this time it's from ap-southeast-1b.
05:12 And if I go into my CloudShell and do the same dig command,
05:16 then, as you can see, there's a new TTL, so 120 seconds,
05:19 and there is a new IP right here
05:22 which is the IPO menu server.
05:23 So this was a cool demo of the TTL.
05:25 I hope you liked it, and I will see you in the next lecture.
整讲总结 / Overall Summary
中文
TTL 控制 DNS Answer 缓存：高值降低查询成本但延迟变更，低值增加查询却加快切换。计划修改时应先降低 TTL、等待旧缓存淘汰、修改 Record，再恢复较高 TTL。Hands-on 的 120 秒示例显示 Record 改到 Singapore 后仍返回 Frankfurt，直到 Cache 过期才切换并重置 TTL。
English
TTL controls DNS answer caching: high values reduce query cost but delay changes, while low values increase queries and accelerate switching. For planned updates, lower TTL, wait for old caches to expire, change the record, then raise TTL again. The 120-second lab keeps returning Frankfurt after the record points to Singapore until cache expiration, when the new value appears and TTL resets.
返回顶部 ↑