コスト最適化とサステナビリティの柱
コスト面では支出への意識、適正なリソースサイズ、料金モデルの選択を取り入れ、サステナビリティのためにインフラの規模を抑えてエネルギー効率を高めます。
「コスト最適化とサステナビリティの柱」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
コスト最適化の柱の概要
コスト最適化の柱は、不要なコストを避け、AWS への支出から最大限の価値を得ることに重点を置いています。クラウドリソースは過剰にプロビジョニングしやすいため、多くの場合、最もすぐに効果を実感できる柱です。主な設計原則は次のとおりです。クラウド財務管理を実装する — コストを最重要指標の 1 つとして扱います。従量課金モデルを採用する — 使用した分だけ支払います。全体的な効率を測定する — ビジネス価値の単位あたりのコストを追跡します。差別化につながらない重い作業への支出を削減する — インフラストラクチャを管理するのではなく、マネージドサービスを使用します。
# 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 costリソースの適正化
適正化は、コストを最も大きく削減できる施策です。過剰にプロビジョニングされたリソースを特定し、削減します。よくあるのは、初期プロビジョニング時に大きなインスタンスを起動したまま、見直しを行わないケースです。AWS Compute Optimizerは使用率のメトリクスを分析し、最適なインスタンスタイプを推奨します。よくある検出例として、CPU使用率5%のm5.4xlargeはt3.mediumで十分であり、コンピューティングコストを80%削減できます。適正化は、EC2、Lambda(メモリ)、RDS、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=Overprovisioned購入モデルの最適化
安定して稼働するワークロードでは、On-Demand pricingが最も高コストです。次の方法で大幅なコスト削減が可能です。Reserved Instances (1 or 3 years) — 予測可能なワークロードで最大72%削減できます。Savings Plans — インスタンスファミリーやリージョンをまたいで適用できる柔軟な利用コミットメントで、最大66%削減できます。Spot Instances — 中断が許容されるワークロード(バッチ、CI/CD、ステートレス)で最大90%削減できます。一般的なコスト最適化済みのフリートでは、基礎的なキャパシティにSavings Plans、急増分にSpot、例外的なケースにOn-Demandを組み合わせます。
# 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 regionコスト最適化のためのSpot Instances
Spot Instancesは、余剰のAWSキャパシティを最大90%の割引で利用できますが、AWSがキャパシティを必要とした場合は2分前に通知され、中断される可能性があります。Spotは、バッチ処理(チェックポイントを保存して再開)、CI/CDビルドエージェント、ステートレスなWebサーバー(ALBの背後に配置し、ELBで中断されたインスタンスを避けてルーティング)、EMRおよびEKSのワーカーノードに適しています。Spot Fleetまたは複数のインスタンスタイプとAZを使用するASGを利用して複数のプールに分散し、中断のリスクを抑えます。
# 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 5S3ストレージコストの最適化
適切なストレージクラスを選択し、移行を自動化することで、S3のストレージコストを大幅に削減できます。S3 Intelligent-Tieringは、アクセスパターンに基づいてオブジェクトをアクセス階層間で自動的に移動します。アクセスパターンが不明な場合に適しています。ライフサイクルルールを使用すると、スケジュールに従ってオブジェクトを移行できます。Standardから30日後にStandard-IAへ、90日後にGlacierへ、180日後にDeep Archiveへ移行します。また、オブジェクトデータの必要な部分だけを取得できるS3 Selectも検討してください。データ転送と処理のコストを削減できます。
# 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"}
]
}]
}'タグ付けとコスト配分
適切なタグ付けを行わなければ、各チームやプロジェクトがどれだけコストを使っているかを把握できません。Cost Allocation Tagsを使用すると、チーム、プロジェクト、環境、その他任意に定義した軸でコストを分解できます。Billingコンソールでタグを有効化し、AWS Cost Explorerでタグごとにコストをフィルタリングおよびグループ化します。AWS OrganizationsのTag Policiesでタグ付けを強制し、AWS Config rulesでタグのないリソースを検出します。これにより、個々のチームに対するshowback(可視化)とchargeback(コストの帰属)が可能になります。
# 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=Projectサステナビリティの柱の概要
サステナビリティの柱(2021年に追加)は、エネルギー消費を削減し、効率を高めることで、クラウドワークロードの環境への影響を最小限に抑えることを重視します。設計原則は次のとおりです。影響を理解する — ワークロードのカーボンフットプリントを測定します。サステナビリティの目標を設定する。利用率を最大化する — アイドル状態のリソースを避けるために適正化します。より効率的なハードウェアを予測して採用する — 最新世代のインスタンスを使用します。マネージドサービスを使用する — AWSは多くの組織よりも効率的にデータセンターを運用しています。
# 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
AWS Graviton processors(ARMベース)は、x86インスタンスと比較して、エネルギー効率が最大60%向上し、価格性能比が20~40%向上します。Graviton3/4インスタンス(c7g、m7g、r7g、t4gファミリー)は、ほとんどのEC2、Lambda、Fargateワークロードで利用できます。x86からGravitonへ移行すると、1回の計算に必要な電力とインスタンス料金の両方を削減できるため、サステナビリティとコスト最適化の柱を同時に改善できます。ほとんどのワークロード(Linux、コンテナ化されたアプリ、JVM)は、最小限の変更で移行できます。
# 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 unchangedアイドル状態のリソースの削除
不要なコストとエネルギーの浪費を生む大きな要因が、アイドル状態のリソースです。たとえば、CPU使用率1%のまま稼働するEC2インスタンス、アタッチされていないEBSボリューム、未使用のElastic IP、忘れられた開発・テスト環境が24時間365日稼働しているケースなどです。EventBridgeルールとSystems Manager Automationを使用して、本番環境以外に停止・起動スケジュールを実装します。たとえば、開発用インスタンスを午後6時に停止し、午前8時に起動します。AWS Trusted AdvisorとCost Explorerを使用して、アイドル状態のインスタンス、未使用のEBSボリューム、利用率の低いReserved Instancesを特定します。
# 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\"]}"
}]'サステナビリティのためのデータライフサイクル
データを無期限に保存すると、エネルギーを浪費します。サステナビリティの柱では、不要になったデータを自動的に削除またはアーカイブするデータライフサイクルポリシーの実装を推奨しています。S3 Lifecycle rulesで有効期限を設定し、保持期間を過ぎたオブジェクトを削除します。DynamoDB TTLで古いレコードを自動的に期限切れにします。CloudWatch Logs retention policiesで、定めた期間が経過したロググループを削除します。不要なデータを削除すると、ストレージコストだけでなく、データの保存と冷却に必要なエネルギーも削減できます。
# 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 30他の柱とのコスト最適化の比較
コスト最適化が他の柱と競合する場合があります。Multi-AZ RDSはデータベースコストを2倍にしますが、信頼性の柱の要件を満たすために必要です。Cross-Region Replicationは信頼性を高めますが、ストレージと転送のコストが増加します。Active-active multi-regionはレイテンシーを低減します(パフォーマンス効率)が、コストは2~3倍になります。Well-Architected Frameworkは、常に最も安価な選択肢を選ぶよう求めているのではありません。柱同士のトレードオフを意識的に判断し、その理由を文書化するよう求めています。試験では、提示された要件を満たしながら最も費用対効果の高いソリューションを選択する能力が問われます。
# 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 themクイックチェック
このレッスンで学んだAWS Solutions Architect(SAA-C03)の概念について理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、次のことを学びました。コスト最適化では、リソースの適正化、購入モデル(Reserved/Savings Plans/Spot)、S3のライフサイクル管理を組み合わせます。サステナビリティでは、利用率の最大化、Gravitonインスタンスの使用、データライフサイクルポリシーの実装を重視します。また、他の柱とのコストのトレードオフは、ビジネス要件に基づいて意識的に判断する必要があります。コストタグを使用すると、チーム間でshowbackとchargebackを実現できます。次は、Well-Architected Toolとレビューのプロセスについて学びます。
よくある質問
「コスト最適化とサステナビリティの柱」レッスンは無料ですか?
はい。「コスト最適化とサステナビリティの柱」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
「コスト最適化とサステナビリティの柱」で何を学びますか?
コスト面では支出への意識、適正なリソースサイズ、料金モデルの選択を取り入れ、サステナビリティのためにインフラの規模を抑えてエネルギー効率を高めます。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Cloud & IT Cert Prepを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「コスト最適化とサステナビリティの柱」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?
はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- 運用上の卓越性とセキュリティの柱
- 信頼性とパフォーマンス効率の柱
- コスト最適化とサステナビリティの柱
- Well-Architected Toolとレビュー手順