การแคชและการจำกัดอัตรา
ใช้การแคชเพื่อลดเวลาแฝงและจัดการปริมาณการใช้งานที่พุ่งสูงด้วยการจำกัดอัตราและแผนการใช้งานใน API Gateway
การแคชและการจำกัดอัตรา เป็นบทเรียน Serverless Backend with AWS Lambda & API Gateway ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Serverless Backend with AWS Lambda & API Gateway และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Serverless Backend with AWS Lambda & API Gateway มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Boost API Performance
In the world of APIs, speed and reliability are key. High latency (slow responses) frustrates users, while sudden traffic spikes can crash your backend services.
This lesson explores two powerful features in AWS API Gateway: caching and throttling. They help you deliver fast, stable, and cost-effective APIs.
What is API Caching?
Caching is like having a temporary storage for frequently requested data. Instead of always fetching data from your backend (e.g., a database or Lambda function), API Gateway can store the response and serve it directly.
- Reduces latency: Responses are returned much faster.
- Lowers load: Your backend services receive fewer requests.
- Saves costs: Less compute/database usage.
How API Gateway Caches
When caching is enabled for an API stage, API Gateway stores responses from your backend for a specified duration.
Here's how it works:
- A client sends a request to API Gateway.
- API Gateway checks if a valid response for that request is in its cache.
- If found, API Gateway immediately returns the cached response.
- If not found, API Gateway forwards the request to your backend, caches the response, then returns it to the client.
Enabling API Caching
Caching is configured at the API stage level. You specify a cache capacity and a default Time-to-Live (TTL) for cached responses.
- Cache Capacity: The size of the cache (e.g., 0.5 GB to 237 GB).
- TTL (Time-to-Live): How long responses are stored in the cache, in seconds (default 300s).
- Encryption: Cache data can be encrypted at rest.
You can also override TTL per method or even disable caching for specific methods.
Clearing the Cache
What if your backend data changes? You don't want to serve stale cached data. This is where cache invalidation comes in.
- Client-side: Clients can send a
Cache-Control: max-age=0header to bypass the cache and force a fresh response. - API Key: If using API keys, clients with the key can invalidate the cache for specific requests.
- Manual: You can manually invalidate the entire stage cache via the AWS Management Console or CLI.
Controlling API Traffic
Throttling is about limiting the number of requests your API can receive over a certain period. Think of it as a traffic cop for your API.
It's crucial for:
- Backend Protection: Prevents your backend services from being overwhelmed.
- Cost Control: Reduces unexpected spikes in resource usage.
- Fair Usage: Ensures all users get a reasonable share of API access.
How API Gateway Throttles
API Gateway enforces throttling based on two main metrics:
- Rate: The steady-state number of requests per second (RPS) that clients can submit to your API.
- Burst: The maximum number of concurrent requests API Gateway will fulfill before returning
429 Too Many Requestserrors. This allows for brief spikes above the steady rate.
When limits are hit, API Gateway rejects excess requests, protecting your backend.
Default Throttling Limits
AWS sets default account-level throttling limits for API Gateway to ensure service stability across all users. These are soft limits, meaning you can request increases.
- Example: A default might be 10,000 requests per second (RPS) and a burst of 5,000 concurrent requests across all APIs in a region.
These limits apply before any stage-specific or usage plan limits are considered.
Customizing Stage Throttling
Beyond account-level limits, you can configure stage-level throttling for individual methods or entire API stages.
- You can set a default rate limit and burst limit for the entire stage (e.g., 100 RPS for
dev, 1000 RPS forprod). - You can also override these defaults for specific HTTP methods (e.g., a
POST /itemsmight have a lower limit than aGET /items).
Throttling by User
For more granular control, especially when managing different user tiers or monetizing your API, you use Usage Plans combined with API Keys.
- Usage Plan: Defines custom throttling limits (rate, burst) and quotas (total requests over a period) for a group of clients.
- API Key: A unique identifier that clients include in their requests. API Gateway uses this key to map the client to a usage plan and enforce its specific limits.
This allows you to offer different service levels (e.g., Free, Premium) to different clients.
Quick Check
Understanding the purpose of throttling is crucial for building resilient APIs.
Caching & Throttling Summary
We've explored how caching dramatically improves API performance by reducing latency and backend load. We also learned how throttling protects your services from traffic spikes and ensures fair usage through account-level, stage-level, and usage plan configurations.
These features are essential for building robust and scalable serverless APIs with AWS API Gateway.
คำถามที่พบบ่อย
บทเรียน “การแคชและการจำกัดอัตรา” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การแคชและการจำกัดอัตรา” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Serverless Backend with AWS Lambda & API Gateway ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Serverless Backend with AWS Lambda & API Gateway มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การแคชและการจำกัดอัตรา”
ใช้การแคชเพื่อลดเวลาแฝงและจัดการปริมาณการใช้งานที่พุ่งสูงด้วยการจำกัดอัตราและแผนการใช้งานใน API Gateway คุณปฏิบัติ Serverless Backend with AWS Lambda & API Gateway ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Serverless Backend with AWS Lambda & API Gateway หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Serverless Backend with AWS Lambda & API Gateway บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “การแคชและการจำกัดอัตรา” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Serverless Backend with AWS Lambda & API Gateway นี้ได้ไหม
ได้ บทเรียน Serverless Backend with AWS Lambda & API Gateway ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การแคชและการจำกัดอัตรา
- การแปลงคำขอและการตอบกลับ
- ชื่อโดเมนแบบกำหนดเองและการเพิ่มประสิทธิภาพที่ขอบเครือข่าย
- API ของ WebSocket สำหรับการสื่อสารแบบเรียลไทม์