0Pricing
AWS Solutions Architect · บทเรียน

สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน

ตอบคำถามสถานการณ์เกี่ยวกับกลยุทธ์การแคช การเพิ่มประสิทธิภาพการค้นหาดาต้าเลค ข้อแลกเปลี่ยนระหว่าง Reserved กับ Spot และสถาปัตยกรรมแบบรีพลิกาอ่าน

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

สถานการณ์ที่ 1: การแคชเพื่อลดภาระฐานข้อมูล

สถานการณ์: ฐานข้อมูล RDS MySQL ของเว็บไซต์ข่าวแห่งหนึ่งให้บริการการอ่าน 90% สำหรับเนื้อหาบทความที่เปลี่ยนแปลงไม่เกินชั่วโมงละครั้ง การใช้งาน CPU ของฐานข้อมูลเฉลี่ยอยู่ที่ 80% ค่าใช้จ่ายเพิ่มขึ้น และความล่าช้าอยู่ที่ 200ms ต่อคำสั่ง วิธีแก้ไข: เพิ่ม คลัสเตอร์ ElastiCache Redis ไว้ด้านหน้า RDS โดยใช้รูปแบบ การโหลดแบบขี้เกียจ (แคชแยกจากแอปพลิเคชัน) แอปพลิเคชันจะตรวจสอบแคชก่อน หากพบข้อมูลในแคช ให้ส่งคืนบทความที่แคชไว้ภายใน <1ms หากไม่พบ ให้สอบถาม RDS ส่งคืนผลลัพธ์ และเขียนผลลัพธ์ลงแคชพร้อม TTL 1 ชั่วโมง ผลลัพธ์ที่คาดหวังคือ อัตราการพบข้อมูลในแคช 90% การใช้งาน CPU ของ RDS ลดลงต่ำกว่า 20% และความล่าช้าสำหรับการตอบกลับจากแคชลดลงต่ำกว่า 5ms

import boto3, json

elasticache = boto3.client('elasticache')
redis_client = None  # assume redis-py client connected to ElastiCache endpoint

def get_article(article_id):
    cache_key = 'article:' + str(article_id)
    # Check cache first
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)  # cache hit: <1ms
    # Cache miss: query RDS
    article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
    # Write to cache with 1-hour TTL
    redis_client.setex(cache_key, 3600, json.dumps(article))
    return article

สถานการณ์ที่ 2: CloudFront สำหรับส่งมอบสินทรัพย์แบบคงที่

สถานการณ์: ผู้ใช้ในเอเชียแปซิฟิกใช้เวลาโหลดเว็บแอปพลิเคชันที่โฮสต์บน EC2 ใน us-east-1 นาน 2–4 วินาที แอปพลิเคชันให้บริการสินทรัพย์แบบคงที่ขนาดใหญ่ (รูปภาพ, JS, CSS) วิธีแก้ไข: วาง การกระจายเนื้อหา CloudFront ไว้ด้านหน้า ALB กำหนดค่า ลักษณะการแคช สำหรับเส้นทาง /static/* โดยตั้ง TTL ให้นาน (เช่น 1 สัปดาห์) เพื่อให้ไฟล์แบบคงที่ถูกแคชไว้ที่ตำแหน่งขอบเครือข่ายของ CloudFront ใกล้ผู้ใช้ในเอเชีย คำขอ API แบบไดนามิกจะข้ามการแคชด้วย TTL=0 ผู้ใช้ในเอเชียจะโหลดสินทรัพย์แบบคงที่จากตำแหน่งขอบเครือข่ายในสิงคโปร์หรือโตเกียวภายในเวลาไม่ถึง 100ms แทนที่จะรอการรับส่งข้อมูลไปกลับยัง us-east-1

# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
  'Origins': {
    'Quantity': 1,
    'Items': [{
      'Id': 'alb-origin',
      'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
      'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
    }]
  },
  'CacheBehaviors': {
    'Quantity': 1,
    'Items': [{
      'PathPattern': '/static/*',
      'DefaultTTL': 604800,
      'MaxTTL': 604800
    }]
  },
  'DefaultCacheBehavior': {"DefaultTTL": 0}
}'

สถานการณ์ที่ 3: การปรับขนาดให้เหมาะสมด้วย Compute Optimizer

สถานการณ์: บริษัทแห่งหนึ่งมีอินสแตนซ์ EC2 จำนวน 500 รายการ ซึ่งหลายรายการจัดสรรไว้เมื่อ 3 ปีก่อนโดยใช้ประเภทอินสแตนซ์ขนาดใหญ่ ใบเรียกเก็บเงิน AWS สูง แต่บริษัทไม่ทราบว่าอินสแตนซ์ใดจัดสรรเกินความต้องการ วิธีแก้ไข: เปิดใช้ AWS Compute Optimizer (ไม่มีค่าใช้จ่าย และใช้เมตริก CloudWatch ย้อนหลัง 14 วัน) Compute Optimizer วิเคราะห์การใช้งาน CPU หน่วยความจำ เครือข่าย และดิสก์จริงของแต่ละอินสแตนซ์ แล้วให้คำแนะนำเพื่อปรับขนาดให้เหมาะสม อินสแตนซ์ t3.xlarge ที่มีการใช้งาน CPU เฉลี่ย 8% จะได้รับคำแนะนำให้ลดขนาดเป็น t3.small การนำคำแนะนำไปใช้กับอินสแตนซ์ทั้ง 500 รายการโดยทั่วไปจะลดค่าใช้จ่าย EC2 ได้ 20–40%

# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
  --status Active

# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=Finding,Values=OVER_PROVISIONED \
  --query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
  --output table

สถานการณ์ที่ 4: อินสแตนซ์ Spot สำหรับการประมวลผลแบบกลุ่ม

สถานการณ์: บริษัทด้านจีโนมิกส์แห่งหนึ่งทำงานประมวลผลแบบกลุ่มทุกคืน ใช้เวลา 8 ชั่วโมง และสามารถเริ่มใหม่ได้หากถูกขัดจังหวะ ค่าใช้จ่าย EC2 On-Demand สำหรับงานเหล่านี้อยู่ที่ 10,000 ดอลลาร์ต่อเดือน วิธีแก้ไข: ใช้ อินสแตนซ์ EC2 Spot สำหรับกลุ่มการประมวลผลแบบกลุ่ม อินสแตนซ์ Spot คือความจุ EC2 ที่ไม่ได้ใช้งาน ซึ่งให้ส่วนลดได้สูงสุด 90% สำหรับงานแบบกลุ่มที่รองรับการหยุดชะงัก ให้ใช้ AWS Batch ซึ่งจะจัดคิวงาน Spot ที่ล้มเหลวใหม่โดยอัตโนมัติ และใช้กลุ่มอินสแตนซ์แบบผสม (Spot + On-Demand สำรองเพียงเล็กน้อย) คาดว่าจะประหยัดค่าใช้จ่ายการประมวลผลได้ 70–90% หรือลดจาก 10,000 ดอลลาร์เหลือ 1,000–3,000 ดอลลาร์ต่อเดือน

# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
  --compute-environment-name spot-genomics \
  --type MANAGED \
  --state ENABLED \
  --compute-resources '{
    "type": "SPOT",
    "bidPercentage": 60,
    "minvCpus": 0,
    "maxvCpus": 256,
    "instanceTypes": ["optimal"],
    "subnets": ["subnet-1a", "subnet-1b"],
    "securityGroupIds": ["sg-batch"],
    "instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
    "spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
  }' \
  --service-role arn:aws:iam::123456789012:role/AWSBatchServiceRole

สถานการณ์ที่ 5: DynamoDB On-Demand สำหรับการรับส่งข้อมูลที่ผันแปร

สถานการณ์: กระดานผู้นำเกมใช้ DynamoDB ที่มีปริมาณงานที่จัดสรรไว้ เมื่อเปิดตัวเกม ปริมาณการใช้งานเพิ่มขึ้น 50 เท่าและตารางจำกัดคำขอ นอกช่วงเปิดตัว ปริมาณงานเกือบเป็นศูนย์ ทำให้ความจุที่จัดสรรไว้สูญเปล่า วิธีแก้ไข: เปลี่ยน DynamoDB เป็น โหมดความจุแบบ On-Demand On-Demand จะปรับขนาดเพื่อรองรับปริมาณงานใด ๆ ได้ทันทีโดยไม่ต้องวางแผนความจุด้วยตนเอง และคิดค่าบริการตามคำขอแทนหน่วยที่จัดสรรไว้ คุณจ่ายเฉพาะคำขอที่เกิดขึ้นเท่านั้น จึงไม่มีค่าใช้จ่ายสำหรับความจุว่างระหว่างการเปิดตัว On-Demand แลกกับค่าใช้จ่ายต่อคำขอที่สูงขึ้นเล็กน้อย เพื่อรับประกันว่าจะไม่เกิดการจำกัดคำขอและไม่ต้องจัดการความจุ

# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
  --table-name Leaderboard \
  --billing-mode PAY_PER_REQUEST

# Verify the change
aws dynamodb describe-table \
  --table-name Leaderboard \
  --query 'Table.BillingModeSummary.BillingMode'

สถานการณ์ที่ 6: S3 Intelligent-Tiering สำหรับรูปแบบการเข้าถึงที่คาดเดาไม่ได้

สถานการณ์: บริษัทจัดเก็บรูปภาพที่ผู้ใช้สร้างขึ้นหลายล้านภาพใน S3 Standard รูปแบบการเข้าถึงเปลี่ยนแปลงอย่างคาดเดาไม่ได้ — รูปภาพบางส่วนถูกเข้าถึงทุกวัน ขณะที่บางส่วนไม่มีการเข้าถึงเป็นเวลาหลายเดือน บริษัทต้องการลดค่าใช้จ่ายในการจัดเก็บโดยไม่ต้องจัดการนโยบายวงจรชีวิตด้วยตนเอง วิธีแก้ไข: ใช้ S3 Intelligent-Tiering ซึ่งจะย้ายออบเจ็กต์ระหว่างระดับพื้นที่จัดเก็บโดยอัตโนมัติตามรูปแบบการเข้าถึง ได้แก่ Frequent Access (Standard), Infrequent Access (ไม่มีการเข้าถึงเป็นเวลา 30 วันขึ้นไป), Archive Instant Access (90 วันขึ้นไป) และ Archive Access (90 วันขึ้นไป โดยต้องเลือกเปิดใช้) Intelligent-Tiering ไม่มีค่าธรรมเนียมการเรียกคืนข้อมูล ค่าบริการตรวจสอบอยู่ที่ 0.0025 ดอลลาร์สหรัฐต่อออบเจ็กต์ 1,000 รายการต่อเดือน ซึ่งถือว่าน้อยมากสำหรับชุดข้อมูลขนาดใหญ่

# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket user-images-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "AutoTier",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [{
        "Days": 0,
        "StorageClass": "INTELLIGENT_TIERING"
      }]
    }]
  }'

สถานการณ์ที่ 7: การแลกเปลี่ยนระหว่าง Athena กับ Redshift

สถานการณ์: สตาร์ทอัปต้องการเรียกดูตารางใน Data Lake บน S3 โดยทำการเรียกดูข้อมูลแบบเฉพาะกิจประมาณ 10 ครั้งต่อสัปดาห์ ผู้ให้บริการรายหนึ่งเสนอ Amazon Redshift พร้อมคลัสเตอร์ dc2.large วิธีแก้ไขสำหรับสตาร์ทอัป: เริ่มต้นด้วย Amazon Athena ซึ่งไม่มีค่าโครงสร้างพื้นฐาน และชำระเฉพาะข้อมูลที่สแกน (ประมาณ 5 ดอลลาร์สหรัฐต่อ TB) การเรียกดูข้อมูล 10 ครั้งต่อสัปดาห์จากข้อมูล Parquet ที่แบ่งพาร์ทิชันอย่างเหมาะสมอาจมีค่าใช้จ่ายไม่ถึง 5 ดอลลาร์สหรัฐต่อเดือน ส่วน Redshift dc2.large มีค่าใช้จ่ายประมาณ 180 ดอลลาร์สหรัฐต่อเดือนอย่างต่อเนื่อง Redshift จะคุ้มค่าก็ต่อเมื่อมีการเรียกดูข้อมูลพร้อมกันจำนวนมาก (มากกว่า 50 ครั้งต่อวัน) หรือต้องการการตอบสนองภายในเวลาไม่ถึงหนึ่งวินาที คีย์เวิร์ด 'เฉพาะกิจ ไม่บ่อย' ชี้ไปที่ Athena อย่างชัดเจน

# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshift

สถานการณ์ที่ 8: การเลือกประเภทโวลุม EBS

สถานการณ์: เซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ต้องการ 64,000 IOPS โดยมีเวลาแฝงต่ำอย่างสม่ำเสมอ โวลุม gp3 EBS ปัจจุบันกำลังแตะขีดจำกัด IOPS วิธีแก้ไข: อัปเกรดเป็น io2 Block Express (ประเภทโวลุม EBS ที่ออกแบบมาสำหรับฐานข้อมูลที่ใช้การดำเนินการรับส่งข้อมูลจำนวนมาก) io2 Block Express รองรับสูงสุด 256,000 IOPS ต่อโวลุม และมีเวลาแฝงต่ำกว่าหนึ่งมิลลิวินาที มีค่าใช้จ่ายสูงกว่า gp3 (0.125 ดอลลาร์สหรัฐต่อ GB + 0.065 ดอลลาร์สหรัฐต่อ IOPS ที่จัดสรรต่อเดือน) แต่เป็นตัวเลือก EBS เดียวที่รองรับความต้องการ IOPS ตั้งแต่ 64,000 ขึ้นไป สำหรับงานฐานข้อมูลที่ให้ความสำคัญกับเวลาแฝงและขีดจำกัด 16,000 IOPS ของ gp3 ไม่เพียงพอ io2 คือตัวเลือก EBS เดียวที่ใช้งานได้

# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
  --volume-type io2 \
  --size 500 \
  --iops 64000 \
  --availability-zone us-east-1a \
  --encrypted

# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed data

สถานการณ์ที่ 9: Reserved Instances สำหรับงานที่มีปริมาณคงที่

สถานการณ์: บริษัทใช้อินสแตนซ์ r6i.4xlarge EC2 จำนวน 20 รายการอย่างต่อเนื่องสำหรับแอปพลิเคชันที่ใช้งานจริง และคาดว่าจะไม่มีการเปลี่ยนแปลงข้อกำหนดเป็นเวลา 3 ปี ปัจจุบันบริษัทมีค่าใช้จ่ายแบบ On-Demand สำหรับอินสแตนซ์เหล่านี้ 80,000 ดอลลาร์สหรัฐต่อปี วิธีแก้ไข: ซื้อ 3-year Standard Reserved Instances (หรือ Compute Savings Plans) โดยชำระแบบ All Upfront เพื่อรับส่วนลดสูงสุด Standard Reserved Instances มอบส่วนลดได้สูงสุด 72% เมื่อเทียบกับ On-Demand อินสแตนซ์ทำงานตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ และมีปริมาณงานที่คาดการณ์ได้ จึงเป็นรูปแบบการใช้งานแบบคลาสสิกสำหรับ Reserved Instances การลดค่าใช้จ่ายที่คาดไว้: 80,000 × 0.72 = 22,400 ดอลลาร์สหรัฐต่อปี เทียบกับ 80,000 ดอลลาร์สหรัฐต่อปีแบบ On-Demand ซึ่งประหยัดได้ 57,600 ดอลลาร์สหรัฐต่อปี

# Reserved Instance purchase decision matrix:
# On-Demand:          No commitment, highest price, any workload
# 1-yr RI (All Up):   40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up):   60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot:           90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savings

สถานการณ์ที่ 10: ค่าใช้จ่ายของ Lambda เทียบกับ EC2 สำหรับทราฟฟิกที่เปลี่ยนแปลง

สถานการณ์: บริษัทให้บริการ REST API บนอินสแตนซ์ t3.micro EC2 ซึ่งมีค่าใช้จ่าย 8 ดอลลาร์สหรัฐต่อเดือน API ได้รับคำขอ 1 ล้านรายการต่อเดือน โดยแต่ละรายการใช้เวลาประมวลผล 100 มิลลิวินาที ทีมงานสอบถามว่า Lambda จะมีราคาถูกกว่าหรือไม่ การวิเคราะห์: ราคาของ Lambda: คำขอ 1,000,000 รายการ × 0.0000002 ดอลลาร์สหรัฐ = 0.20 ดอลลาร์สหรัฐ (ค่าใช้คำขอ) + 1,000,000 × 0.1 วินาที × หน่วยความจำ 128 MB × อัตราค่าบริการ = ประมาณ 1.67 ดอลลาร์สหรัฐ (ค่าประมวลผล) รวมประมาณ 1.87 ดอลลาร์สหรัฐต่อเดือน Lambda จึงถูกกว่า EC2 สำหรับ API ที่มีทราฟฟิกต่ำนี้ เมื่อทราฟฟิกเพิ่มขึ้นเกินประมาณ 40 ล้านคำขอต่อเดือน EC2 จะมีราคาถูกกว่า ใช้ Lambda Cost Calculator เพื่อหาจุดคุ้มทุนสำหรับงานแต่ละประเภท

# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
#   GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
#   Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
#   + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)

สถานการณ์ที่ 11: Global Accelerator สำหรับ API แบบไดนามิก

สถานการณ์: API ระดับโลกที่ให้บริการผู้ใช้ในยุโรป US และเอเชียมีเวลาแฝงไม่สม่ำเสมอ เนื่องจากทราฟฟิกเดินทางผ่านเส้นทางอินเทอร์เน็ตที่คาดเดาไม่ได้ เคยพิจารณา CloudFront แล้ว แต่การตอบกลับของ API เป็นแบบไดนามิกและไม่สามารถแคชได้ วิธีแก้ไข: ใช้ AWS Global Accelerator ซึ่งมี anycast IP addresses แบบคงที่ 2 รายการทั่วโลก ทราฟฟิกของผู้ใช้จะเข้าสู่โครงข่ายหลักระดับโลกของ AWS ที่ตำแหน่งขอบเครือข่าย AWS ซึ่งใกล้ที่สุด แล้วเดินทางผ่านเครือข่ายส่วนตัวของ AWS ไปยังต้นทางใน Region เป้าหมาย โดยหลีกเลี่ยงช่วงกลางทางของอินเทอร์เน็ตสาธารณะที่มีความหนาแน่นสูง Global Accelerator ช่วยลดเวลาตอบสนองของ API แบบไดนามิกได้ 20–60% และทำให้สลับไปยังระบบสำรองได้ทันทีเมื่อ Endpoint ของ Region ไม่พร้อมใช้งาน

# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
  --name my-api-accelerator \
  --ip-address-type IPV4 \
  --enabled

# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
  --accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
  --protocol TCP \
  --port-ranges '[{"FromPort": 443, "ToPort": 443}]'

# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
  --listener-arn arn:aws:globalaccelerator::123:listener/xyz \
  --endpoint-group-region us-east-1 \
  --endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'

ตรวจสอบความเข้าใจอย่างรวดเร็ว

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

สรุปบทเรียน

ในบทเรียนนี้ คุณได้ฝึกวิเคราะห์สถานการณ์เกี่ยวกับ: การโหลดแบบ lazy loading ของ ElastiCache เพื่อลด CPU ของ RDS จาก 80% เหลือ 20%, Spot Instances และ AWS Batch เพื่อประหยัดค่าใช้จ่ายของงานแบบชุด 70–90%, Athena สำหรับการเรียกดูข้อมูลแบบเฉพาะกิจที่ไม่บ่อย เทียบกับ Redshift สำหรับการวิเคราะห์ที่มีการเรียกดูพร้อมกันจำนวนมาก และ S3 Intelligent-Tiering สำหรับรูปแบบการเข้าถึงที่คาดเดาไม่ได้โดยไม่มีค่าธรรมเนียมการเรียกคืนข้อมูล ถัดไปคือบททดสอบสรุปขั้นสุดท้าย: การสอบย่อยแบบผสมหลายโดเมนที่จับเวลา เพื่อวัดความพร้อมของคุณ

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

บทเรียน “สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน”

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

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

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

บทเรียน “สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน” ใช้เวลานานแค่ไหน

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

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

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

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

  1. สถานการณ์สถาปัตยกรรมที่ปลอดภัย
  2. สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง
  3. สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน
  4. ข้อสอบจำลองฉบับสั้นแบบเต็มชุดจากหลายหมวด
← กลับไปที่ AWS Solutions Architect