Amazon CLF-C02: クラウドアーキテクチャと Well-Architected フレームワーク — 学習ガイド

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Cloud Practitioner CLF-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

設計原則とコンピューティング購入の意思決定

優れたクラウドアーキテクチャは、小さく反復的な変更、自動化、そして疎結合から始まります。これにより、アプリケーションの一部を独立してスケールさせることができます。可能な限りステートレスなサービスを設計し、不変性（イミュータビリティ）とエフェメラルなコンピューティングを推進し、アクセスには最小権限の原則を適用することで、弾力性のあるアーキテクチャを構築します。コンピューティングの料金モデルを選択する際は、時間的展望、使用率の予測可能性、中断への耐性を比較検討します。長時間稼働する定常状態のワークロードはコミットメント型料金が適しており、突発的または予測不能なワークロードは、状況に応じてOn-DemandやSpotが適しています。よくある落とし穴は、変動する成長を理解しないまま長期のReserved InstancesやSavings Plansにコミットしてしまい、無駄な支出を生んだり、不適切なインスタンスファミリーにロックインされたりすることです。もう一つの間違いは、中断を想定した設計をせずに、クリティカルなステートフルワークロードにSpotを使用することです。ライセンスや配置の要件も考慮しましょう。Dedicated Hostsはソフトウェアに紐づくライセンスや物理的な分離をサポートし、一方、Savings Plansはコンピューティング費用に対してインスタンスファミリーやリージョンをまたいだ柔軟性を提供します。タグ付けと自動化されたコスト配分は不可欠です。一貫したタグがなければ、Savings Plansを適用したり、適正化（ライトサイジング）分析を実行したりすることが困難になります。モニタリングとアラートを使用して非効率を早期に検出し、使用率の変化に応じて四半期ごとに購入決定を見直しましょう。

On-Demand: 時間/秒単位の支払い、最高の柔軟性、コミットメントなし
Reserved Instances / Standard RIs: 特定のインスタンス属性に対する長期割引、定常状態においてコスト効率が高い
Savings Plans: コミットされた利用料と引き換えに、インスタンスファミリーをまたいで適用される柔軟な割引
Spot Instances: 中断可能なワークロードに対する大幅な割引
Dedicated Hosts: ライセンスやコンプライアンスの制約のための物理ホストの割り当て

Infrastructure as Code、プロビジョニング、および分離

Infrastructure as Code (IaC)は、インフラストラクチャに再現性、レビューのしやすさ、バージョニングをもたらします。AWS CloudFormationは、スタックを記述しプロビジョニングするために使用されるネイティブの宣言的なIaCサービスです。テンプレートはリソース、依存関係、パラメータ化をコード化します。AWS Cloud Development Kit (CDK)は、より高レベルな構成要素を提供し、複数の言語（TypeScript、Python、Java、C#、Goを含む）をサポートしているため、開発者は使い慣れた言語からCloudFormationを合成できます。プログラムによるプロビジョニングは、AWS CLI、SDK、AWS CDK、およびTerraformのようなサードパーティツール経由でも実行できます。AWSの機能との緊密なパリティやCloudFormationのドリフト（構成乖離）検出を求める場合は、ネイティブのツールを選択します。論理的な分離はAmazon Virtual Private Cloud (VPC)によって提供され、サブネット、ルートテーブル、セキュリティグループ、ネットワークACLと組み合わせることでネットワーク境界を確立します。IAMはアイデンティティと権限（ユーザー、ロール、グループ、ポリシー）を制御し、プログラムによる認証情報やリソースへのアクセスを管理するために使用されます。実務でよくある落とし穴には、ルートアカウントのアクセスキーを保存すること、自動化のためのクロスアカウントロールを設定しないこと、テンプレートでタグ付けポリシーを強制しないことなどがあります。CloudFormationテンプレートはコードとして扱うべきです。レビュー、リント（静的解析）、バージョン管理システムへの保存を行い、設定のドリフト（構成乖離）を避け、予測可能なデプロイを可能にする必要があります。

Well-Architectedの柱 — 実践的な焦点

Well-Architectedフレームワークは、設計上の意思決定とトレードオフを導く5つの柱を中心に構成されています。各柱を理解し、サービスをマッピングすることで、作業の優先順位付けや代替案の比較に役立ちます。

Operational Excellence (運用上の優秀性): 可観測性のある運用を設計し、CloudWatchのメトリクス、ログ、Systems Managerの自動化を使用します。ランブックと継続的改善を推進します。
Security (セキュリティ): IAMで最小権限を徹底し、KMSで保管中のデータを暗号化し、CloudTrailとGuardDutyを有効にして監査と検出を行い、WAFとShieldでエッジを保護します。
Reliability (信頼性): マルチAZ、自動復旧、Route 53のヘルスチェック、バックアップ（EBSスナップショット、RDS自動バックアップ、AWS Backup）を用いて障害に備えた設計を行い、復旧目標を達成します。
Performance Efficiency (パフォーマンス効率): Compute Optimizerで適正化（ライトサイジング）し、キャッシング（CloudFront, ElastiCache）を活用し、マネージドサービス（Aurora, DynamoDB）と適切なストレージ階層を選択してI/Oとレイテンシーを最適化します。
Cost Optimization (コスト最適化): ライフサイクルポリシー（即時取得が必要でアクセス頻度の低いオブジェクトにはS3 Intelligent-TieringまたはStandard-IA）を用いたコストを意識したアーキテクチャを実装し、Savings Plansを使用し、非本番環境の停止をスケジュールします。

よくある意思決定の基準は、運用オーバーヘッドをコストと引き換えにマネージドサービスを利用するかどうかです。一般的な落とし穴は、オートスケーリングやキャッシングを活用して低コストでパフォーマンスを維持するのではなく、最悪のピークケースに備えて過剰にプロビジョニングしてしまうことです。

運用ツール、データサービス、セキュリティ、エッジの選択肢

運用上の可視性とセキュリティツールは、Well-Architectedな環境のバックボーンです。AWS CloudTrailは監査のためにAPIアクティビティを記録し、Amazon GuardDutyはアカウントレベルの異常な振る舞いに対する継続的な脅威検出を提供します。CloudWatchはメトリクスとログを収集し、EBSボリュームの書き込みスパイクなどのイベントに対するアラームをサポートします。ネイティブメトリクスが不十分な場合は、CloudWatch Agentを使用してOSレベルのメトリクスを取得します。マネージドデータサービスとして、RDSはリレーショナルデータベースの自動パッチ適用とバックアップを提供し、DynamoDBはNoSQLのフルマネージドなキーバリューストアおよびドキュメントストアです。そしてAmazon Neptuneは、高度に接続されたデータセットに最適化されたマネージドグラフデータベースです。グローバルなコンテンツ配信と低レイテンシーでの配布には、エッジのCloudFrontをShieldおよびWAFと組み合わせることで、CDNに加えてDDoS保護とアプリケーション層のフィルタリングを提供します。エッジまたはオンプレミスでの低レイテンシーのニーズには、AWS OutpostsまたはLocal Zonesを評価します。Outpostsは、可能な限り低いレイテンシーと一貫したAPIを実現するために、AWSハードウェアをオンプレミスに設置します。ユーザーのIDフェデレーションとアカウントアクセスは、AWS IAM Identity Center（旧AWS SSO）によって処理されます。モニタリングを設計する際は、アラームと自動修復（LambdaまたはSystems Manager）を組み合わせ、単一のアベイラビリティーゾーンへの依存、ルート認証情報の使用、即時取得が必要なオブジェクトにディープアーカイブストレージ（Glacier）を選択するなどのよくある間違いを避けてください。

主要なサービスの選択肢とユースケース: マネージドリレーショナルDBにはRDS、NoSQLにはDynamoDB、グラフにはNeptune、チャットボットにはLex、グローバルなWeb配信とDDoS保護にはCloudFront + WAF + Shield

実践的な問題: ユースケースシナリオ

シナリオ: Acme Manufacturing社は、VPC内の本番EC2インスタンス、注文処理用のRDSインスタンス、S3とCloudFrontを介してデプロイされた静的アセットウェブサイトといった混合ワークロードをAWSで実行しています。チームはAWS CLIとCloudFormationを使用しており、開発者はCI/CDのために安全なクロスアカウントアクセスを必要としています。

課題: 継続的に実行されているアプリケーションサーバーのコンピューティングコストを削減し、ルート認証情報を使用せずに自動化を保護し、EBSベースのインスタンスを最小限のダウンタイムで迅速に復旧できるようにする必要があります。

推奨アプローチ:

持続的なコンピューティングの時間単位の支出に合致するSavings Planにコミットし、対象インスタンスをSavings Planを使用するように変換して、即時のコスト削減を実現します。
使用率を分析した上で、長期間稼働する特定のインスタンスのニーズをリザーブドインスタンスに移行し、適切な場合にはインスタンスサイズの柔軟性を適用します。
ルートアカウントによるアクセスをIAMユーザーとロールに置き換えます。最小権限ポリシーを持つCI/CD用のIAMロールを作成し、クロスアカウントの自動化にはSTS AssumeRoleを介した短期的な認証情報を使用します。
AWS BackupまたはスケジュールされたData Lifecycle Managerポリシーを使用して自動EBSスナップショットを実装し、迅速なインスタンス交換のためにAMIとユーザーデータを使用し、最小限のダウンタイムのためにアタッチされたEBSスナップショットの復元を行うAuto Scalingグループを使用します。

論理的根拠: コミットメント型の料金体系を予測可能な支出に合わせることで、可用性を犠牲にすることなくコストを削減できます。ルートの使用をIAMロールと短期的な認証情報に置き換えることは、最小権限のベストプラクティスに従っています。自動スナップショットとAMIは、「信頼性」および「オペレーショナルエクセレンス」の柱に沿った迅速な復旧をサポートします。

← 請求、料金、サポート · すべてのドメイン · 管理、モニタリング、分析 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →