PricingLoginStart free
Cloud & IT Cert Prep · Lektion

Scenarier för hög prestanda och kostnadsoptimering

Besvara scenarier om cachelagringsstrategier, optimering av frågor i datasjöar, avvägningar mellan Reserved och Spot samt arkitekturer med läsrepliker.

Lektion 3 av 413 steg

Scenarier för hög prestanda och kostnadsoptimering är en gratis lektion i Cloud & IT Cert Prep på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Cloud & IT Cert Prep, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Scenario 1: Caching för att minska databasbelastningen

Scenario: En nyhetswebbplats RDS MySQL-databas hanterar 90 % lästrafik för artikelinnehåll som ändras högst en gång i timmen. Databasens CPU-användning ligger i genomsnitt på 80 %, kostnaderna ökar och fördröjningen är 200 ms per fråga. Lösning: Lägg till ett ElastiCache Redis-kluster framför RDS och använd mönstret lazy loading (cache-aside). Applikationen kontrollerar cachen först – vid en cacheträff returneras den cachade artikeln på <1 ms. Vid en cachemiss frågar applikationen RDS, returnerar resultatet och skriver det till cachen med en TTL på 1 timme. Förväntat resultat: 90 % cacheträffar, RDS CPU-användning under 20 % och fördröjning under 5 ms för cachade svar.

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

Scenario 2: CloudFront för leverans av statiska resurser

Scenario: Användare i Asien och Stillahavsområdet upplever laddningstider på 2–4 sekunder för en webbaserad applikation som körs på EC2 i us-east-1. Applikationen levererar stora statiska resurser (bilder, JS, CSS). Lösning: Placera en CloudFront-distribution framför ALB. Konfigurera ett cachebeteende för sökvägen /static/* med en lång TTL (till exempel 1 vecka), så att statiska filer cachas på CloudFronts edge-platser nära användarna i Asien. Dynamiska API-anrop kringgår cachningen med TTL=0. Asiatiska användare läser in statiska resurser från en edge-plats i Singapore eller Tokyo på under 100 ms i stället för att vänta på tur- och returresor till 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}
}'

Scenario 3: Rätt dimensionering med Compute Optimizer

Scenario: Ett företag har 500 EC2-instanser, varav många dimensionerades för tre år sedan med stora instanstyper. AWS-fakturan är hög, men företaget vet inte vilka instanser som är överdimensionerade. Lösning: Aktivera AWS Compute Optimizer (kostnadsfritt och baserat på 14 dagars CloudWatch-mätvärden). Compute Optimizer analyserar varje instans faktiska CPU-, minnes-, nätverks- och diskanvändning och ger rekommendationer för rätt dimensionering. En t3.xlarge med en genomsnittlig CPU-användning på 8 % skulle rekommenderas att skalas ned till t3.small. Om rekommendationerna tillämpas på alla 500 instanser minskar EC2-kostnaderna vanligtvis med 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

Scenario 4: Spot Instances för batchbearbetning

Scenario: Ett genomikföretag kör nattliga batchjobb som tar 8 timmar och kan köras om de avbryts. EC2 On-Demand kostar 10 000 USD per månad för dessa jobb. Lösning: Använd EC2 Spot Instances för batchbearbetningsflottan. Spot Instances är outnyttjad EC2-kapacitet som erbjuds med upp till 90 % rabatt. För batchjobb som tål avbrott kan ni använda AWS Batch, som automatiskt lägger misslyckade Spot-jobb i kö igen och använder en blandad flotta (Spot + ett minimalt On-Demand-reservalternativ). Förväntad besparing: 70–90 % lägre beräkningskostnader – från 10 000 till 1 000–3 000 USD per månad.

# 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

Scenario 5: DynamoDB On-Demand för varierande trafik

Scenario: En topplista för ett spel använder DynamoDB med provisionerad kapacitet. När spel lanseras ökar trafiken 50-faldigt och tabellen begränsar begäranden. Mellan lanseringarna är genomströmningen nära noll – den provisionerade kapaciteten går till spillo. Lösning: Byt DynamoDB till On-Demand capacity mode. On-Demand skalar omedelbart till valfri genomströmning utan manuell kapacitetsplanering och tar betalt per begäran i stället för per provisionerad enhet. Ni betalar bara för de begäranden ni gör – ingen kostnad för outnyttjad kapacitet mellan lanseringarna. On-Demand innebär en något högre kostnad per begäran i utbyte mot garanterad frånvaro av throttling och ingen kapacitetshantering.

# 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'

Scenario 6: S3 Intelligent-Tiering för oförutsägbar åtkomst

Scenario: Ett företag lagrar miljontals användarskapade bilder i S3 Standard. Åtkomstmönstren varierar oförutsägbart — vissa bilder används dagligen, andra inte på flera månader. Företaget vill minska lagringskostnaderna utan att manuellt hantera livscykelpolicyer. Lösning: Använd S3 Intelligent-Tiering. Tjänsten flyttar automatiskt objekt mellan lagringsnivåer baserat på åtkomstmönster: Frequent Access (Standard), Infrequent Access (inte använda på 30+ dagar), Archive Instant Access (90+ dagar) och Archive Access (90+ dagar, kräver aktivering). Det tas inte ut några hämtningsavgifter inom Intelligent-Tiering. Övervakningsavgiften är 0,0025 USD per 1 000 objekt och månad — försumbar för stora datamängder.

# 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"
      }]
    }]
  }'

Scenario 7: Avvägning mellan Athena och Redshift

Scenario: Ett nystartat företag vill köra frågor mot tabeller i en datasjö på S3. Företaget kör cirka 10 ad hoc-frågor per vecka. En leverantör föreslår Amazon Redshift med ett dc2.large-kluster. Lösning för ett nystartat företag: Börja med Amazon Athena — inga infrastrukturkostnader, utan betalning endast för genomsökta data (cirka 5 USD/TB). 10 frågor per vecka mot välpartitionerade Parquet-data kan kosta mindre än 5 USD per månad. Redshift dc2.large kostar cirka 180 USD per månad vid kontinuerlig drift. Redshift blir kostnadseffektivt först när samtidigheten är hög (50+ frågor per dag) eller svar på under en sekund krävs. Nyckelorden "ad hoc, sporadiska" pekar tydligt på 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

Scenario 8: Välja EBS-volymtyp

Scenario: En relationsdatabasserver kräver 64 000 IOPS med konsekvent låg latens. Den nuvarande gp3 EBS-volymen når sitt IOPS-tak. Lösning: Uppgradera till io2 Block Express (en EBS-volymtyp som är utformad för I/O-intensiva databaser). io2 Block Express stöder upp till 256 000 IOPS per volym och latens under en millisekund. Den är dyrare än gp3 (0,125 USD/GB + 0,065 USD/provisionerad IOPS/månad), men är det enda EBS-alternativet som uppfyller kravet på minst 64 000 IOPS. För databasarbetsbelastningar där låg latens är kritisk och gp3:s tak på 16 000 IOPS inte räcker, är io2 det enda genomförbara EBS-alternativet.

# 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

Scenario 9: Reserverade instanser för stabila arbetsbelastningar

Scenario: Ett företag kör 20 r6i.4xlarge EC2-instanser kontinuerligt för en produktionsapplikation och förväntar sig inga förändrade krav under tre år. Den nuvarande On-Demand-kostnaden för dessa instanser är 80 000 USD per år. Lösning: Köp 3-åriga Standard Reserved Instances (eller Compute Savings Plans) med betalning i sin helhet i förskott för maximal rabatt. Standard Reserved Instances ger upp till 72 % rabatt jämfört med On-Demand. Instanserna körs dygnet runt med en förutsägbar arbetsbelastning — den klassiska profilen för Reserved Instances. Förväntad kostnadsminskning: 80 000 USD × 0,72 = 22 400 USD per år jämfört med 80 000 USD per år med On-Demand — en besparing på 57 600 USD per år.

# 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

Scenario 10: Kostnad för Lambda jämfört med EC2 vid varierande trafik

Scenario: Ett företag kör ett REST-API på en t3.micro EC2-instans som kostar 8 USD per månad. API:t tar emot 1 miljon anrop per månad, där varje anrop tar 100 ms att behandla. Teamet undrar om Lambda skulle vara billigare. Analys: Lambda-prissättning: 1 000 000 anrop × 0,0000002 USD = 0,20 USD (anropskostnad) + 1 000 000 × 0,1 s × 128 MB minne × taxa = cirka 1,67 USD (beräkningskostnad) = cirka 1,87 USD per månad. Lambda är billigare än EC2 för detta API med låg trafik. När trafiken ökar till över cirka 40 miljoner anrop per månad blir EC2 billigare. Använd Lambda Cost Calculator för att hitta brytpunkten för varje arbetsbelastning.

# 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)

Scenario 11: Global Accelerator för dynamiska API:er

Scenario: Ett globalt API som betjänar användare i Europa, USA och Asien har varierande latens eftersom trafiken går över oförutsägbara internetvägar. CloudFront övervägdes, men API-svaren är dynamiska (kan inte cachas). Lösning: Använd AWS Global Accelerator. Tjänsten tillhandahåller två globala statiska anycast-IP-adresser. Användartrafiken går in i AWS globala stamnät via den närmaste AWS edge-platsen och färdas över AWS privata nätverk till ursprunget i målregionen — utan att passera det överbelastade offentliga internetnätets mellansträcka. Global Accelerator förbättrar svarstiden för dynamiska API:er med 20–60 % och ger omedelbar redundansväxling när en regionsslutpunkt blir otillgänglig.

# 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}]'

Snabbtest

Testa din förståelse av begreppen i AWS Solutions Architect (SAA-C03) från den här lektionen.

Besvara frågan i den interaktiva lektionen

Sammanfattning av lektionen

I den här lektionen arbetade du igenom scenarier som omfattade: lazy loading i ElastiCache för att minska RDS-CPU-användningen från 80 % till 20 %, Spot Instances och AWS Batch för att sänka kostnaderna för batchjobb med 70–90 %, Athena för sporadiska ad hoc-frågor jämfört med Redshift för analys med hög samtidighet samt S3 Intelligent-Tiering för oförutsägbara åtkomstmönster utan hämtningsavgifter. Nästa steg är det avslutande slutprovet: ett tidsbegränsat miniprov med blandade ämnesområden för att mäta hur väl du är förberedd.

Gratis att börja

Lär dig Cloud & IT Cert Prep med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
150
Lektioner
600
Börja lära dig gratisVisa hela kursen

Vanliga frågor

Är lektionen ”Scenarier för hög prestanda och kostnadsoptimering” gratis?

Ja – hela texten till ”Scenarier för hög prestanda och kostnadsoptimering” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Cloud & IT Cert Prep, kan Ni uppgradera till CoddyKit PRO. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Vad lär jag mig i ”Scenarier för hög prestanda och kostnadsoptimering”?

Besvara scenarier om cachelagringsstrategier, optimering av frågor i datasjöar, avvägningar mellan Reserved och Spot samt arkitekturer med läsrepliker. Ni övar på Cloud & IT Cert Prep med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Cloud & IT Cert Prep?

Du behöver inga förkunskaper. Utbildningen i Cloud & IT Cert Prep på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Scenarier för hög prestanda och kostnadsoptimering”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Cloud & IT Cert Prep-lektionen?

Ja. Varje Cloud & IT Cert Prep-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Scenarier för säker arkitektur
  2. Scenarier för motståndskraftig arkitektur med hög tillgänglighet
  3. Scenarier för hög prestanda och kostnadsoptimering
  4. Mini-examen i full längd med blandade domäner
← Tillbaka till Cloud & IT Cert Prep