AWS Solutions Architect · บทเรียน

การตรวจสอบสถานะและการสลับระบบ DNS

บทเรียน 4 จาก 413 ขั้นตอน

การตรวจสอบสถานะและการสลับระบบ DNS เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

การตรวจสอบสถานะของ Route 53 คืออะไร

การตรวจสอบสถานะของ Route 53 จะตรวจสอบสถานะของจุดปลายทางอย่างต่อเนื่อง ไม่ว่าจะเป็นเว็บเซิร์ฟเวอร์ ตัวกระจายโหลด หรือจุดปลายทาง HTTP/HTTPS/TCP ใด ๆ ที่เข้าถึงได้ผ่านอินเทอร์เน็ต จากผลการตรวจสอบสถานะ Route 53 สามารถปรับการกำหนดเส้นทาง DNS โดยอัตโนมัติ เพื่อหลีกเลี่ยงการส่งทราฟฟิกไปยังทรัพยากรที่ไม่พร้อมใช้งาน

การตรวจสอบสถานะจะคิดค่าบริการแยกรายการต่อเดือน ตัวตรวจสอบสถานะทั่วโลกของ Route 53 ซึ่งอยู่ในหลาย Region จะตรวจสอบจุดปลายทางของคุณพร้อมกัน ทำให้การตรวจสอบสถานะมีความซ้ำซ้อน จุดปลายทางจะถือว่าไม่พร้อมใช้งานก็ต่อเมื่อตัวตรวจสอบตามจำนวนเกณฑ์ที่กำหนดเห็นตรงกันว่าจุดปลายทางล้มเหลว

การตรวจสอบสถานะของจุดปลายทาง

การตรวจสอบสถานะของจุดปลายทาง จะตรวจสอบที่อยู่ IP หรือชื่อโดเมนที่ระบุ โดยใช้โพรโทคอล (HTTP, HTTPS หรือ TCP) พอร์ต และเส้นทางที่เลือกได้ สำหรับการตรวจสอบ HTTP/HTTPS Route 53 จะตรวจสอบว่าจุดปลายทางส่งคืนรหัสสถานะ HTTP 2xx หรือ 3xx ภายในช่วงเวลาหมดเวลาหรือไม่ สำหรับการตรวจสอบ HTTPS ระบบยังสามารถตรวจสอบใบรับรอง TLS ได้ด้วย

ตัวเลือกการกำหนดค่าที่สำคัญ ได้แก่ ช่วงเวลาระหว่างคำขอ (10 หรือ 30 วินาที—10 วินาทีตรวจพบได้เร็วกว่าแต่มีค่าใช้จ่ายสูงกว่า) เกณฑ์ความล้มเหลว (ความล้มเหลวติดต่อกัน 1–10 ครั้งก่อนทำเครื่องหมายว่าไม่พร้อมใช้งาน) และ การจับคู่สตริง (ตรวจสอบเพิ่มเติมได้ว่าเนื้อหาการตอบกลับมีสตริงที่ระบุหรือไม่)

# Create an HTTP health check
aws route53 create-health-check \
  --caller-reference hc-2026-06-20 \
  --health-check-config '{
    "Type": "HTTP",
    "IPAddress": "54.100.1.1",
    "Port": 80,
    "ResourcePath": "/health",
    "FailureThreshold": 3,
    "RequestInterval": 30
  }'

การตรวจสอบสถานะแบบคำนวณ

การตรวจสอบสถานะแบบคำนวณ จะรวมผลลัพธ์จากการตรวจสอบสถานะย่อยหลายรายการโดยใช้ตรรกะบูลีน (AND, OR, NOT) ทำให้คุณกำหนดสถานะของแอปพลิเคชันจากสัญญาณหลายรายการได้ โดยไม่ต้องสร้างสายการกำหนดเส้นทางที่ซับซ้อน

ตัวอย่างเช่น เว็บแอปพลิเคชันจะพร้อมใช้งานก็ต่อเมื่อทั้งการตรวจสอบเซิร์ฟเวอร์ API และการตรวจสอบฐานข้อมูลผ่าน ให้สร้างการตรวจสอบสถานะแบบคำนวณที่มีประเภทเป็น AND และอ้างอิงการตรวจสอบจุดปลายทางทั้งสองรายการ หากรายการใดรายการหนึ่งล้มเหลว การตรวจสอบสถานะแบบคำนวณจะล้มเหลว และ Route 53 จะนำระเบียน DNS ที่เกี่ยวข้องออกจากการตอบกลับ

# Create a calculated health check (AND of two child checks)
aws route53 create-health-check \
  --caller-reference hc-calc-2026 \
  --health-check-config '{
    "Type": "CALCULATED",
    "ChildHealthChecks": [
      "hc-api-id",
      "hc-db-id"
    ],
    "HealthThreshold": 2
  }'

การตรวจสอบสถานะจากสัญญาณเตือนของ CloudWatch

การตรวจสอบสถานะจากสัญญาณเตือนของ CloudWatch จะเชื่อมการตรวจสอบสถานะของ Route 53 เข้ากับสถานะของสัญญาณเตือน CloudWatch หากสัญญาณเตือนอยู่ในสถานะ ALARM การตรวจสอบสถานะจะถูกทำเครื่องหมายว่าไม่พร้อมใช้งาน หากอยู่ในสถานะ OK หรือ INSUFFICIENT_DATA จะถูกทำเครื่องหมายว่าพร้อมใช้งาน

รูปแบบนี้มีประโยชน์อย่างมากสำหรับจุดปลายทางภายใน VPC ซึ่งตัวตรวจสอบสถานะภายนอกของ Route 53 ไม่สามารถเข้าถึงได้ แทนที่จะตรวจสอบจุดปลายทางส่วนตัวโดยตรง ให้สร้างเมตริกและสัญญาณเตือน CloudWatch สำหรับจุดปลายทางนั้น แล้วใช้สถานะของสัญญาณเตือนเป็นพื้นฐานของการตรวจสอบสถานะ Route 53 นอกจากนี้ยังทำให้ตรวจสอบสถานะตามเมตริกทางธุรกิจ เช่น อัตราข้อผิดพลาดหรือความลึกของคิวได้ด้วย

# Create a health check based on a CloudWatch alarm
aws route53 create-health-check \
  --caller-reference hc-cw-2026 \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {
      "Region": "us-east-1",
      "Name": "HighErrorRate-Alarm"
    },
    "InsufficientDataHealthStatus": "Healthy"
  }'

การตรวจสอบสถานะของจุดปลายทางส่วนตัว

ตัวตรวจสอบสถานะของ Route 53 เป็นเซิร์ฟเวอร์ที่ AWS จัดการ ซึ่งอยู่นอก VPC ของคุณและเข้าถึงจุดปลายทางผ่านอินเทอร์เน็ตสาธารณะ ซับเน็ตส่วนตัวจึงไม่สามารถเข้าถึงได้ด้วยการตรวจสอบสถานะจุดปลายทางมาตรฐาน สำหรับจุดปลายทางส่วนตัว ให้ใช้แนวทางใดแนวทางหนึ่งต่อไปนี้:

เผยแพร่เมตริก CloudWatch แบบกำหนดเองจากภายใน VPC (เช่น สัญญาณสำเร็จ/ล้มเหลวจากแอปพลิเคชัน) สร้างสัญญาณเตือน แล้วใช้การตรวจสอบสถานะจากสัญญาณเตือน CloudWatch
ใช้สัญญาณเตือนแบบรวมของ CloudWatch ที่รวบรวมเมตริกของ ELB, RDS หรือแอปพลิเคชันภายใน VPC

รูปแบบนี้สำคัญอย่างยิ่งสำหรับฐานข้อมูลในซับเน็ตส่วนตัว ตัวกระจายโหลดภายใน และบริการแบ็กเอนด์

สถานะและการตรวจสอบการทำงานของการตรวจสอบสถานะ

คุณสามารถดูสถานะการตรวจสอบสถานะได้ในคอนโซล Route 53 ภายใต้ การตรวจสอบสถานะ หรือเรียกดูผ่าน API Route 53 จะเผยแพร่เมตริกการตรวจสอบสถานะไปยัง CloudWatch ในเนมสเปซ AWS/Route53 ซึ่งรวมถึง HealthCheckStatus (1 = พร้อมใช้งาน, 0 = ไม่พร้อมใช้งาน) และ HealthCheckPercentageHealthy (เปอร์เซ็นต์ของตัวตรวจสอบ Route 53 ที่รายงานว่าจุดปลายทางพร้อมใช้งาน)

ตั้งค่าสัญญาณเตือน CloudWatch สำหรับ HealthCheckStatus เพื่อรับการแจ้งเตือน SNS เมื่อจุดปลายทางไม่พร้อมใช้งาน ทำให้คุณมองเห็นเหตุการณ์ได้ก่อนที่ทีมเวรประจำจะสังเกตพบว่าการสลับระบบ DNS เกิดขึ้นแล้ว

# Get health check status
aws route53 get-health-check-status \
  --health-check-id a1b2c3d4-e5f6-7890-abcd-ef1234567890 \
  --query 'CheckerIpRanges'

การสลับระบบ DNS ด้วยการกำหนดเส้นทางแบบสลับระบบสำรอง

เมื่อ Route 53 ตรวจพบว่าการตรวจสอบสถานะของระเบียนหลักล้มเหลว ระบบจะนำระเบียนหลักออกจากการตอบกลับ DNS และส่งคืนที่อยู่ของระเบียนสำรอง การทำงานนี้เรียกว่า การสลับระบบ DNS การสลับจะเกิดขึ้นภายในช่วงเวลาประเมินผล (จำนวนครั้งที่ตัวตรวจสอบสถานะล้มเหลว × ช่วงเวลาระหว่างคำขอ) บวกกับ TTL ของระเบียน

ตัวอย่างเช่น ช่วงเวลาระหว่างคำขอ = 30 วินาที เกณฑ์ความล้มเหลว = 3 และ TTL = 60 วินาที เวลาสลับระบบที่นานที่สุดโดยประมาณคือ 3 × 30 + 60 = 150 วินาที การตั้งค่า TTL ให้ต่ำลง (เช่น 10 วินาที) และใช้ช่วงเวลาการตรวจสอบสถานะที่เร็วขึ้น (10 วินาที) อาจลดเวลาเหลือ 3 × 10 + 10 = 40 วินาที

การตรวจสอบสถานะสำหรับระเบียนแบบถ่วงน้ำหนักและตามเวลาแฝง

คุณสามารถเชื่อมการตรวจสอบสถานะกับระเบียนแบบถ่วงน้ำหนักและระเบียนตามเวลาแฝงได้เช่นกัน ไม่ใช่เฉพาะระเบียนแบบสลับระบบสำรอง เมื่อการตรวจสอบสถานะของระเบียนแบบถ่วงน้ำหนักล้มเหลว Route 53 จะกระจายน้ำหนักทราฟฟิกของระเบียนนั้นใหม่ตามสัดส่วนให้กับระเบียนแบบถ่วงน้ำหนักที่พร้อมใช้งาน เมื่อการตรวจสอบสถานะของระเบียนตามเวลาแฝงล้มเหลว Route 53 จะกำหนดเส้นทางคำขอไปยังระเบียนที่พร้อมใช้งานถัดไปซึ่งมีเวลาแฝงต่ำที่สุด

การทำเช่นนี้ทำให้นโยบายการกำหนดเส้นทางแบบถ่วงน้ำหนักและตามเวลาแฝงทนทานต่อความล้มเหลวของจุดปลายทาง โดยไม่ต้องสร้างระเบียนแบบสลับระบบสำรองโดยเฉพาะ นี่เป็นรูปแบบที่พบได้บ่อยใน SAA-C03: การกำหนดเส้นทางตามเวลาแฝงข้าม Region ร่วมกับการตรวจสอบสถานะ ช่วยให้ทั้งการเพิ่มประสิทธิภาพและการกู้คืนจากภัยพิบัติโดยอัตโนมัติ

แอ็กทีฟ-แอ็กทีฟหลาย Region พร้อมการตรวจสอบสถานะ

รูปแบบแอ็กทีฟ-แอ็กทีฟหลาย Region ที่ทนทานโดยใช้ Route 53:

สร้าง ระเบียนตามเวลาแฝง สำหรับแต่ละ Region (us-east-1, eu-west-1, ap-southeast-1) โดยแต่ละรายการมีการตรวจสอบสถานะ
เมื่อทุก Region พร้อมใช้งาน ผู้ใช้จะถูกส่งไปยัง Region ที่มีเวลาแฝงต่ำที่สุด
หากการตรวจสอบสถานะของ Region ใดล้มเหลว (แอปพลิเคชันหยุดทำงานหรือไม่ตอบสนอง) Route 53 จะนำ Region นั้นออกจากการตอบกลับ DNS โดยอัตโนมัติ และกำหนดเส้นทางคำขอไปยัง Region ถัดไปที่พร้อมใช้งานและเหมาะสมที่สุด
เมื่อ Region ที่ล้มเหลวกลับมาทำงาน การตรวจสอบสถานะจะผ่าน และ Route 53 จะนำ Region นั้นกลับเข้าสู่การหมุนเวียน

รูปแบบนี้ช่วยให้สลับระบบทั่วโลกโดยอัตโนมัติพร้อมเพิ่มประสิทธิภาพ โดยไม่ต้องดำเนินการด้วยตนเอง

ช่วง IP สำหรับตัวตรวจสอบสถานะของ Route 53

ตัวตรวจสอบสถานะของ Route 53 เริ่มต้นการเชื่อมต่อจากช่วง IP ที่เผยแพร่ไว้ในส่วน ROUTE53_HEALTHCHECKS ของไฟล์ JSON ช่วง IP ของ AWS หากจุดปลายทางของคุณได้รับการป้องกันด้วยไฟร์วอลล์หรือกลุ่มความปลอดภัยที่จำกัดการเข้าถึงขาเข้า คุณต้อง อนุญาตทราฟฟิกจากช่วง IP เหล่านี้ เพื่อให้การตรวจสอบสถานะสำเร็จ

อีกทางเลือกหนึ่งคือใช้จุดปลายทางที่เปิดให้เข้าถึงจากสาธารณะ ซึ่งทำหน้าที่ส่งต่อไปยังแบ็กเอนด์ส่วนตัว (เช่น ALB) สำหรับการตรวจสอบสถานะ กลุ่มความปลอดภัยของ ALB ต้องอนุญาตเฉพาะช่วง IP ของ Route 53 ส่วนกลุ่มความปลอดภัยของแบ็กเอนด์ต้องอนุญาตเฉพาะกลุ่มความปลอดภัยของ ALB ซึ่งช่วยรักษาแนวทางการป้องกันแบบหลายชั้น

# Fetch Route 53 health checker IP ranges
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "
import json,sys
data=json.load(sys.stdin)
ranges=[p['ip_prefix'] for p in data['prefixes'] if p['service']=='ROUTE53_HEALTHCHECKS']
print('\n'.join(ranges))
"

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบสถานะ

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบสถานะของ Route 53:

สร้างจุดปลายทาง /health โดยเฉพาะ เพื่อตรวจสอบการพึ่งพาที่สำคัญทั้งหมด (การเชื่อมต่อฐานข้อมูล การเข้าถึงแคช) และส่งคืน 200 เฉพาะเมื่อระบบทำงานได้อย่างสมบูรณ์
ใช้ ช่วงเวลาระหว่างคำขอ 10 วินาที สำหรับจุดปลายทางการใช้งานจริงที่สำคัญ เพื่อให้ตรวจพบความล้มเหลวได้เร็วขึ้น
ตรวจสอบ HealthCheckPercentageHealthy ใน CloudWatch—ความล้มเหลวเพียงบางส่วน (ตัวตรวจสอบ Route 53 ล้มเหลวเพียงบางตัว ไม่ใช่ทั้งหมด) อาจบ่งชี้ถึงปัญหาเครือข่ายระดับภูมิภาคหรือปัญหาที่เกิดเป็นครั้งคราว
สำหรับทรัพยากรส่วนตัวใน VPC ให้ใช้ การตรวจสอบสถานะจากสัญญาณเตือน CloudWatch โดยอิงจากเมตริกของแอปพลิเคชัน
ทดสอบการสลับระบบในสภาพแวดล้อมที่ไม่ใช่การใช้งานจริงก่อนพึ่งพาการทำงานนี้ในระบบจริง

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ตอบคำถามในบทเรียนแบบโต้ตอบ

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า การตรวจสอบสถานะของจุดปลายทางจะตรวจสอบ HTTP/HTTPS/TCP จากตัวตรวจสอบ Route 53 ภายนอก การตรวจสอบสถานะจากสัญญาณเตือน CloudWatch ทำให้ตรวจสอบทรัพยากรส่วนตัวใน VPC ได้ และ การตรวจสอบสถานะแบบคำนวณจะรวมสัญญาณหลายรายการ ด้วยตรรกะบูลีน ความเร็วในการสลับระบบ DNS ขึ้นอยู่กับช่วงเวลาการตรวจสอบสถานะ เกณฑ์ความล้มเหลว และ TTL ต่อไปเราจะศึกษาเกี่ยวกับดิสทริบิวชันและต้นทางของ CloudFront

เริ่มต้นได้ฟรี

เรียนรู้ AWS Solutions Architect ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 30
บทเรียน: 120

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “การตรวจสอบสถานะและการสลับระบบ DNS” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การตรวจสอบสถานะและการสลับระบบ DNS” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การตรวจสอบสถานะและการสลับระบบ DNS”

ตั้งค่าการตรวจสอบสถานะของปลายทาง แบบคำนวณ และการแจ้งเตือน CloudWatch เพื่อให้ Route 53 เปลี่ยนเส้นทางการรับส่งข้อมูลออกจากปลายทางที่ไม่พร้อมใช้งานโดยอัตโนมัติ คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การตรวจสอบสถานะและการสลับระบบ DNS” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

โซนโฮสต์และประเภทระเบียน DNS
นโยบายการกำหนดเส้นทาง: แบบง่าย แบบถ่วงน้ำหนัก และแบบหน่วงต่ำ
การสลับระบบสำรองและการกำหนดเส้นทางตามภูมิศาสตร์
การตรวจสอบสถานะและการสลับระบบ DNS

← กลับไปที่ AWS Solutions Architect