高性能与成本优化场景
回答有关缓存策略、数据湖查询优化、预留实例与 Spot 的权衡以及只读副本架构的场景题
高性能与成本优化场景 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 3 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。
场景 1:通过缓存减少数据库负载
场景:某新闻网站的 RDS MySQL 数据库中,文章内容的读取流量占 90%,且内容每小时最多变化一次。数据库 CPU 平均使用率为 80%,成本不断上升,每次查询延迟为 200ms。解决方案:在 RDS 前增加一个 ElastiCache Redis 集群,使用延迟加载(旁路缓存)模式。应用程序先检查缓存——命中缓存时,在 <1ms 内返回缓存的文章。未命中时,查询 RDS,返回结果,并将其以 1 小时 TTL 写入缓存。预期结果:缓存命中率达到 90%,RDS CPU 降至 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 分发静态资源
场景:在亚太地区,用户访问托管于 us-east-1 EC2 上的 Web 应用程序时,加载时间需要 2 至 4 秒。该应用程序提供大型静态资源(图片、JS、CSS)。解决方案:在 ALB 前放置一个 CloudFront 分配。为 /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 选择合适的实例规格
场景:一家公司拥有 500 个 EC2 实例,其中许多实例是在 3 年前使用大型实例类型配置的。该公司的 AWS 账单很高,但不知道哪些实例配置过度。解决方案:启用 AWS Compute Optimizer(免费,使用 14 天的 CloudWatch 指标)。Compute Optimizer 会分析每个实例的实际 CPU、内存、网络和磁盘利用率,并提供调整实例规格的建议。例如,平均 CPU 使用率为 8% 的 t3.xlarge 会被建议缩小为 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 Instances 进行批处理
场景:一家基因组学公司每晚运行批处理任务,每次需要 8 小时,且中断后可以重试。这些任务使用 EC2 按需实例时每月成本为 10,000 美元。解决方案:使用 EC2 Spot Instances 运行批处理实例集。Spot Instances 是未使用的 EC2 容量,折扣最高可达 90%。对于能够容忍中断的批处理任务,使用 AWS Batch,它会自动将失败的 Spot 任务重新加入队列,并使用混合实例集(Spot + 少量按需实例作为后备)。预期节省:计算成本降低 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 以略高的单请求成本为代价,换取保证不限制请求以及零容量管理开销。
# 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。它会根据访问模式自动在不同层之间移动对象:频繁访问层(标准)、非频繁访问层(超过 30 天未访问)、即时归档访问层(超过 90 天未访问)以及归档访问层(超过 90 天未访问,需要选择启用)。使用 Intelligent-Tiering 不收取检索费用。监控费用为每月每 1,000 个对象 $0.0025,对于大型数据集而言几乎可以忽略不计。
# 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 的权衡
场景:一家初创公司希望查询 S3 数据湖中的表。他们每周大约执行 10 次临时查询。一家供应商建议使用配备 dc2.large 集群的 Amazon Redshift。针对初创公司的解决方案:从 Amazon Athena 开始——无需基础设施成本,只需按扫描的数据量付费(约 $5/TB)。如果 Parquet 数据经过良好分区,每周 10 次查询的费用可能低于每月 $5。Redshift dc2.large 持续运行的费用约为每月 $180。只有在查询并发量较高(每天 50 次以上)或要求亚秒级响应时,Redshift 才具有成本效益。“临时、低频”这一关键词明确指向 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(专为 I/O 密集型数据库设计的 EBS 卷类型)。io2 Block Express 每个卷最多支持 256,000 IOPS,并可提供亚毫秒级延迟。它比 gp3 更昂贵(每月 $0.125/GB + $0.065/已预置 IOPS),但它是唯一能满足 64,000+ IOPS 要求的 EBS 选项。对于对延迟敏感且 gp3 的 16,000 IOPS 上限不足的数据库工作负载,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
场景:一家公司持续运行 20 台 r6i.4xlarge EC2 实例,为生产应用提供服务,并预计 3 年内需求不会发生变化。这些实例当前的按需支出为每年 $80,000。解决方案:购买 3 年期 Standard Reserved Instances(或 Compute Savings Plans),并选择 All Upfront 付款以获得最大折扣。与按需定价相比,Standard Reserved Instances 最多可享受 72% 的折扣。这些实例全天候运行,工作负载可预测——这是最适合 Reserved Instances 的典型场景。预计成本降低:$80,000 × 0.72 = 每年 $22,400,而按需定价为每年 $80,000,因此每年可节省 $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 的成本比较
场景:一家公司在一台每月成本为 $8 的 t3.micro EC2 实例上运行 REST API。该 API 每月接收 100 万个请求,每个请求处理时间为 100 毫秒。团队想知道使用 Lambda 是否更便宜。分析:Lambda 定价:1,000,000 个请求 × $0.0000002 = $0.20(请求费用)+ 1,000,000 × 0.1 秒 × 128MB 内存 × 费率 = 约 $1.67(计算费用),合计约 $1.87/月。对于这个低流量 API,Lambda 比 EC2 更便宜。当流量增长到每月约 4,000 万个请求以上时,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
场景:一个面向欧洲、US 和亚洲用户提供服务的全球 API,由于流量经过不可预测的互联网路径,因此延迟不稳定。团队曾考虑使用 CloudFront,但 API 响应是动态的(无法缓存)。解决方案:使用 AWS Global Accelerator。它在全球提供两个静态 任播 IP 地址。用户流量会在距离最近的 AWS 边缘站点进入 AWS 全球骨干网络,然后通过 AWS 的私有网络传输到目标 Region 中的源站,从而避开拥堵的公共互联网中段。Global Accelerator 可将动态 API 的响应时间缩短 20%–60%,并在某个 Region Endpoint 变得不健康时提供即时故障转移。
# 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)概念的理解。
课程回顾
本课通过多个场景讲解了以下内容:使用 ElastiCache 惰性加载,将 RDS CPU 使用率从 80% 降低到 20%、使用 Spot Instances 和 AWS Batch,将批处理任务成本节省 70%–90%、低频临时查询使用 Athena,高并发分析使用 Redshift,以及针对不可预测访问模式使用 S3 Intelligent-Tiering,且无需支付检索费用。接下来是最终综合实践:一场限时的混合领域小型考试,用于评估您的准备程度。
常见问题解答
「高性能与成本优化场景」课时是免费的吗?
是的 — 「高性能与成本优化场景」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Cloud & IT Cert Prep 课程的其余内容,请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。
「高性能与成本优化场景」这节课中我会学到什么?
回答有关缓存策略、数据湖查询优化、预留实例与 Spot 的权衡以及只读副本架构的场景题 你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Cloud & IT Cert Prep 需要有经验吗?
无需任何先前经验。CoddyKit 上的 Cloud & IT Cert Prep 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 3 节课,共 4 节。
「高性能与成本优化场景」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 Cloud & IT Cert Prep 课中编写并运行代码吗?
能。每节 Cloud & IT Cert Prep 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 安全架构场景
- 弹性与高可用架构场景
- 高性能与成本优化场景
- 混合领域全长模拟考试