Tonggak Pengoptimuman Kos dan Kelestarian
Amalkan kesedaran perbelanjaan, saiz sumber yang sepadan dan pemilihan model harga untuk mengawal kos; minimumkan jejak infrastruktur dan tingkatkan kecekapan tenaga demi kelestarian.
Tonggak Pengoptimuman Kos dan Kelestarian ialah pelajaran AWS Solutions Architect percuma di CoddyKit. Ini ialah pelajaran 3 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran AWS Solutions Architect, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus AWS Solutions Architect merangkumi sejumlah 4 pelajaran.
Gambaran Keseluruhan Tonggak Pengoptimuman Kos
Tonggak Cost Optimisation memberi tumpuan kepada mengelakkan kos yang tidak diperlukan dan memperoleh nilai maksimum daripada perbelanjaan AWS anda. Tonggak ini sering memberikan kesan paling segera kerana resource awan mudah diperuntukkan secara berlebihan. Prinsip reka bentuk utama: Laksanakan pengurusan kewangan awan — anggap kos sebagai metrik utama. Gunakan model penggunaan — bayar hanya untuk perkara yang anda gunakan. Ukur kecekapan keseluruhan — jejak kos bagi setiap unit nilai perniagaan. Kurangkan perbelanjaan untuk kerja berat yang tidak membezakan — gunakan perkhidmatan terurus dan bukannya mengurus infrastruktur sendiri.
# Cost Optimisation pillars:
# 1. Expenditure awareness - visibility into what you spend
# 2. Cost-effective resources - right instance types, storage classes
# 3. Matching supply to demand - auto scaling, spot instances
# 4. Optimising over time - regularly review and adjust
# Example: undifferentiated heavy lifting
# Instead of managing your own Redis: use ElastiCache
# Instead of managing Kubernetes: use EKS or Fargate
# Managed services reduce operational overhead AND costPelarasan Saiz Sumber
Pelarasan saiz ialah tindakan pengoptimuman kos yang paling berimpak — mengenal pasti dan menghapuskan sumber yang diperuntukkan secara berlebihan. Corak yang biasa berlaku ialah melancarkan instances besar semasa penyediaan awal dan tidak menyemaknya semula. AWS Compute Optimizer menganalisis metrik penggunaan dan mengesyorkan jenis instance yang optimum. Penemuan yang biasa: m5.4xlarge yang berjalan pada 5% CPU sepatutnya menggunakan t3.medium, sekali gus menjimatkan 80% kos pengkomputeran. Pelarasan saiz terpakai pada EC2, Lambda (memori), RDS dan volum EBS.
# Get Compute Optimizer recommendations for all EC2
aws compute-optimizer get-ec2-instance-recommendations \
--filters Name=finding,Values=Overprovisioned
# Response includes:
# currentInstanceType: m5.4xlarge
# recommendedInstanceType: t3.large
# estimatedMonthlySavings: $280
# performanceRisk: VeryLow
# Also check EBS volumes:
aws compute-optimizer get-ebs-volume-recommendations \
--filters Name=finding,Values=OverprovisionedPengoptimuman Model Pembelian
Bagi beban kerja keadaan mantap, harga On-Demand ialah pilihan yang paling mahal. Penjimatan yang ketara boleh diperoleh melalui: Reserved Instances (1 atau 3 tahun) — penjimatan sehingga 72% untuk beban kerja yang boleh diramal. Savings Plans — komitmen fleksibel (penjimatan sehingga 66%) yang terpakai merentas keluarga instance dan rantau. Spot Instances — penjimatan sehingga 90% untuk beban kerja yang boleh diganggu (kelompok, CI/CD, tanpa keadaan). Armada yang dioptimumkan kos biasanya menggabungkan ketiga-tiganya: Savings Plans untuk kapasiti asas, Spot untuk lonjakan dan On-Demand untuk kes tertentu.
# Purchasing model comparison:
# On-Demand: $0.192/hr (m5.large) No commitment
# 1yr Reserved: $0.114/hr $0.78/hr effective
# 3yr Reserved: $0.074/hr Highest savings
# Compute SP: ~$0.128/hr Flexible family/region
# Spot: $0.05-0.08/hr Interruptible
# Savings Plans cover:
# - Compute Savings Plans: EC2 + Lambda + Fargate
# - EC2 Instance Savings Plans: specific family in one regionSpot Instances untuk Pengoptimuman Kos
Spot Instances menggunakan kapasiti AWS yang berlebihan dengan diskaun sehingga 90%, tetapi boleh diganggu dengan notis 2 minit apabila AWS memerlukan semula kapasiti tersebut. Spot sesuai untuk: pemprosesan kelompok (buat titik semak dan sambung semula), ejen binaan CI/CD, pelayan web tanpa keadaan (di belakang ALB; ELB menghalakan trafik menjauhi instances yang terganggu) dan nod pekerja EMR dan EKS. Gunakan Spot Fleet atau ASG dengan pelbagai jenis instance dan AZs untuk mempelbagaikan kumpulan dan mengurangkan risiko gangguan.
# ASG with mixed instances (On-Demand + Spot)
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-mixed-asg \
--mixed-instances-policy '{
"LaunchTemplate": {"LaunchTemplateSpecification":{"LaunchTemplateId":"lt-12345","Version":"$Latest"},"Overrides":[{"InstanceType":"m5.large"},{"InstanceType":"m5a.large"},{"InstanceType":"m4.large"}]},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 20,
"SpotAllocationStrategy": "capacity-optimized"
}
}' \
--min-size 2 --max-size 20 --desired-capacity 5Pengoptimuman Kos Storan S3
Kos storan S3 boleh dikurangkan dengan banyaknya dengan menggunakan kelas storan yang betul dan mengautomatikkan peralihan. S3 Intelligent-Tiering mengalihkan objek secara automatik antara peringkat akses berdasarkan corak akses — sesuai apabila corak akses tidak diketahui. Peraturan kitar hayat mengalihkan objek mengikut jadual: daripada Standard → Standard-IA selepas 30 hari → Glacier selepas 90 hari → Deep Archive selepas 180 hari. Pertimbangkan juga S3 Select untuk mendapatkan hanya subset data objek yang diperlukan, sekali gus mengurangkan kos pemindahan dan pemprosesan data.
# S3 lifecycle policy for cost optimisation
aws s3api put-bucket-lifecycle-configuration \
--bucket my-data-bucket \
--lifecycle-configuration '{
"Rules": [{
"ID": "auto-archive",
"Status": "Enabled",
"Transitions": [
{"Days": 30, "StorageClass": "STANDARD_IA"},
{"Days": 90, "StorageClass": "GLACIER_IR"},
{"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
]
}]
}'Pemberian Tag dan Peruntukan Kos
Tanpa pemberian tag yang betul, adalah mustahil untuk memahami jumlah perbelanjaan setiap pasukan atau projek. Tag Peruntukan Kos membolehkan anda memecahkan kos mengikut pasukan, projek, persekitaran atau mana-mana dimensi yang anda tentukan. Aktifkan tag dalam Console Pengebilan, kemudian gunakan AWS Cost Explorer untuk menapis dan mengumpulkan kos mengikut tag. Wajibkan pemberian tag dengan Tag Policies dalam AWS Organizations dan gunakan peraturan AWS Config untuk mengesan sumber tanpa tag. Ini membolehkan showback (keterlihatan) dan chargeback (pengaitan kos) kepada pasukan tertentu.
# Enforce required tags with Config rule
aws configservice put-config-rule \
--config-rule '{
"ConfigRuleName": "required-tags",
"Source": {"Owner":"AWS","SourceIdentifier":"REQUIRED_TAGS"},
"InputParameters": "{\"tag1Key\":\"Project\",\"tag2Key\":\"Environment\",\"tag3Key\":\"Owner\"}"
}'
# Query cost by tag in Cost Explorer
aws ce get-cost-and-usage \
--time-period Start=2026-06-01,End=2026-06-30 \
--granularity MONTHLY \
--group-by Type=TAG,Key=ProjectGambaran Keseluruhan Pillar Sustainability
Sustainability pillar (ditambah pada 2021) memfokuskan pengurangan kesan alam sekitar beban kerja awan dengan mengurangkan penggunaan tenaga dan meningkatkan kecekapan. Prinsip reka bentuk: Fahami kesan anda — ukur jejak karbon beban kerja anda. Tetapkan matlamat sustainability. Maksimumkan penggunaan — laraskan saiz untuk mengelakkan sumber melahu. Jangka dan gunakan perkakasan yang lebih cekap — gunakan generasi instance terkini. Gunakan perkhidmatan terurus — AWS mengendalikan pusat data dengan lebih cekap berbanding kebanyakan organisasi.
# Sustainability improvement areas:
# 1. Right-size instances (reduce idle energy use)
# 2. Use Graviton (ARM) instances: 60% less energy than x86
# 3. Use Spot instances: uses otherwise idle capacity
# 4. Use managed services: AWS optimises their utilisation
# 5. Use serverless: no idle servers
# 6. Move to S3/EFS instead of EC2 instance storage
# 7. Implement data lifecycle (don't store forever)AWS Graviton untuk Sustainability dan Kos
pemproses AWS Graviton (berasaskan ARM) menawarkan sehingga kecekapan tenaga 60% lebih baik dan harga/prestasi 20-40% lebih baik berbanding instances x86. Instances Graviton3/4 (keluarga c7g, m7g, r7g, t4g) tersedia untuk kebanyakan beban kerja EC2, Lambda dan Fargate. Peralihan daripada x86 kepada Graviton meningkatkan pillar Sustainability dan Cost Optimisation secara serentak — watt yang lebih rendah bagi setiap pengiraan dan harga instance yang lebih rendah. Most beban kerja (Linux, aplikasi berbekas, JVM) boleh dipindahkan dengan perubahan minimum.
# Compare: m5.large (x86) vs m7g.large (Graviton3)
# m5.large: $0.096/hr, 2 vCPU, 8 GB
# m7g.large: $0.0808/hr, 2 vCPU, 8 GB
# Savings: ~16% cheaper + 40% better performance
# Switch Lambda function to Graviton (arm64)
aws lambda update-function-configuration \
--function-name my-function \
--architectures arm64
# Lambda arm64 is 20% cheaper than x86
# Most Python, Node.js, Java functions work unchangedMenghapuskan Sumber Melahu
Salah satu sumber utama kos yang tidak perlu dan pembaziran tenaga ialah sumber melahu — instances EC2 yang berada pada CPU 1%, volum EBS yang tidak dilampirkan, IP Elastik yang tidak digunakan dan persekitaran dev/test yang terlupa dan berjalan 24/7. Laksanakan jadual henti/mula untuk persekitaran bukan production menggunakan peraturan EventBridge dan Automasi Systems Manager — hentikan instances pembangunan pada 6 petang dan mulakan pada 8 pagi. Gunakan AWS Trusted Advisor dan Cost Explorer untuk mengenal pasti instances melahu, volum EBS yang tidak digunakan dan Reserved Instances yang kurang digunakan.
# EventBridge + SSM to stop dev instances nights/weekends
aws events put-rule \
--name stop-dev-instances \
--schedule-expression 'cron(0 22 ? * MON-FRI *)'
aws events put-targets \
--rule stop-dev-instances \
--targets '[{
"Id": "StopDevInstances",
"Arn": "arn:aws:ssm:us-east-1::automation-definition/AWS-StopEC2Instance",
"RoleArn": "arn:aws:iam::123:role/EventBridgeRole",
"Input": "{\"InstanceId\":[\"i-dev1\",\"i-dev2\"]}"
}]'Kitar Hayat Data untuk Sustainability
Menyimpan data selama-lamanya membazirkan tenaga. Pillar Sustainability mengesyorkan pelaksanaan dasar kitar hayat data untuk memadamkan atau mengarkibkan data yang tidak lagi diperlukan secara automatik. Gunakan peraturan S3 Lifecycle dengan tarikh luput untuk memadam objek selepas tempoh pengekalan. Gunakan DynamoDB TTL untuk meluputkan rekod lama secara automatik. Gunakan dasar pengekalan CloudWatch Logs untuk memadam kumpulan log selepas tempoh yang ditetapkan. Memadam data yang tidak diperlukan mengurangkan kos storan anda serta tenaga yang diperlukan untuk menyimpan dan menyejukkannya.
# DynamoDB TTL for session data
# Add ttl attribute to items (Unix epoch timestamp)
aws dynamodb update-time-to-live \
--table-name UserSessions \
--time-to-live-specification Enabled=true,AttributeName=expiresAt
# Item will be deleted automatically after expiresAt timestamp
# Example: {'userId': 'u1', 'expiresAt': 1750000000}
# CloudWatch Logs: set 30-day retention
aws logs put-retention-policy \
--log-group-name /aws/lambda/my-function \
--retention-in-days 30Cost Optimisation berbanding Pillar Lain
Cost Optimisation kadangkala bercanggah dengan pillar lain. RDS Multi-AZ menggandakan kos pangkalan data anda tetapi diperlukan untuk pillar Reliability. Replikasi Rentas Rantau meningkatkan kebolehpercayaan tetapi menambah kos storan dan pemindahan. Multi-rantau aktif-aktif mengurangkan kependaman (Performance Efficiency) tetapi kosnya 2-3 kali ganda. Well-Architected Framework tidak mengatakan supaya anda sentiasa memilih pilihan yang paling murah — sebaliknya, anda perlu membuat pertukaran secara sedar antara pillar dan mendokumenkan alasannya. Peperiksaan menguji keupayaan anda memilih penyelesaian paling menjimatkan kos yang masih memenuhi keperluan yang dinyatakan.
# Cost vs reliability trade-off example:
# Single-AZ RDS: $100/month, no HA
# Multi-AZ RDS: $200/month, automated failover
# Decision: if database failure = $10,000/hour of revenue loss
# Even 1 event/year justifies Multi-AZ
# ($10,000 expected loss > $1,200/year extra cost)
# SAA-C03 exam approach:
# Meet the stated requirements FIRST
# Then choose the cheapest option that meets themSemakan Pantas
Uji pemahaman anda tentang konsep AWS Solutions Architect (SAA-C03) daripada pelajaran ini.
Ringkasan Pelajaran
Dalam pelajaran ini, anda telah mempelajari bahawa: Cost Optimisation menggabungkan pelarasan saiz, model pembelian (Reserved/Savings Plans/Spot) dan pengurusan kitar hayat S3, Sustainability memfokuskan pemaksimuman penggunaan, penggunaan instances Graviton dan pelaksanaan dasar kitar hayat data, dan pertukaran kos dengan pillar lain hendaklah dibuat secara sedar berdasarkan keperluan perniagaan. Tag kos membolehkan showback dan chargeback merentas pasukan. Seterusnya, kita akan meneroka Well-Architected Tool dan proses semakan.
Pelajari AWS Solutions Architect dengan tutor kecerdasan buatan — percuma
Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.
- Kursus
- 30
- Pelajaran
- 120
Soalan Lazim
Adakah pelajaran “Tonggak Pengoptimuman Kos dan Kelestarian” percuma?
Ya — sebanyak 3 pelajaran dalam laluan pembelajaran AWS Solutions Architect, termasuk “Tonggak Pengoptimuman Kos dan Kelestarian”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus AWS Solutions Architect merangkumi sejumlah 4 pelajaran.
Apakah yang akan saya pelajari dalam “Tonggak Pengoptimuman Kos dan Kelestarian”?
Amalkan kesedaran perbelanjaan, saiz sumber yang sepadan dan pemilihan model harga untuk mengawal kos; minimumkan jejak infrastruktur dan tingkatkan kecekapan tenaga demi kelestarian. Anda berlatih AWS Solutions Architect menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.
Adakah saya memerlukan pengalaman untuk memulakan AWS Solutions Architect?
Tiada pengalaman terdahulu diperlukan. Pembelajaran AWS Solutions Architect di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 3 daripada 4.
Berapa lamakah pelajaran “Tonggak Pengoptimuman Kos dan Kelestarian” diambil?
Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.
Bolehkah saya menulis dan menjalankan kod dalam pelajaran AWS Solutions Architect ini?
Ya. Setiap pelajaran AWS Solutions Architect menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.
Semua pelajaran dalam kursus ini
- Tonggak Kecemerlangan Operasi dan Keselamatan
- Tonggak Kebolehpercayaan dan Kecekapan Prestasi
- Tonggak Pengoptimuman Kos dan Kelestarian
- Alat Well-Architected dan Proses Semakan