自主学習用のまとめノートです
試験配点:24%(採点対象コンテンツ)
このドキュメントは、CLF-C02試験ガイドの4つのタスクステートメントに沿って構成されています。
目次
- タスクステートメント 1.1: AWSクラウドの利点を定義する
- タスクステートメント 1.2: AWSクラウドの設計原則を特定する
- タスクステートメント 1.3: AWSクラウドへの移行の利点と戦略を理解する
- タスクステートメント 1.4: クラウドエコノミクスのコンセプトを理解する
- 試験対策チェックリスト
- 参考リソース
1. AWSクラウドの利点を定義する
対象知識: AWSクラウドの価値提案
対象スキル: グローバルインフラストラクチャの利点、高可用性、伸縮性、俊敏性の理解
1.1 クラウドコンピューティングとは
クラウドコンピューティングとは、ITリソースをインターネット経由で、オンデマンドかつ従量課金制で利用することです。
クラウドコンピューティングの5つの特徴
| 特徴 | 説明 | 新卒向け解説 |
|---|---|---|
| オンデマンド・セルフサービス | 必要な時に自分でリソースを準備できる | 誰かに依頼せず、管理画面からすぐサーバーを立てられる |
| 幅広いネットワークアクセス | どこからでもAPIでアクセス可能 | インターネットがあれば、自宅からでも操作できる |
| リソースのプーリング | AWSが膨大なリソースを保持し、利用者が共有 | 巨大な「リソースの海」から必要な分だけ借りる |
| 伸縮性(Elasticity) | 需要に応じてリソースを増減できる | アクセスが増えたら自動で拡張、減ったら縮小 |
| 従量課金(Measured Service) | 使った分だけ支払う | 電気代のように、使用量に応じた料金 |
1.2 AWSクラウドの6つの利点
試験では「AWSクラウドを使うメリットは何か?」という問いが頻出します。
| カテゴリ | # | 利点 | 説明 |
|---|---|---|---|
| 💰 コスト | 1 | 固定費を変動費に変換 | サーバーを「買う」から「借りる」へ。使った分だけ支払う |
| 💰 コスト | 2 | スケールメリットの享受 | AWSの規模の経済により、低コストでサービスを利用可能 |
| ⚡ 柔軟性 | 3 | キャパシティ予測が不要 | 需要に応じてリソースを増減。予測ミスのリスクがない |
| ⚡ 柔軟性 | 4 | 速度と俊敏性の向上 | 数分でサーバーを起動。新機能の実験も気軽にできる |
| 🎯 集中 | 5 | データセンター運用コストの削減 | 物理的な管理はAWSが担当。本来の仕事に集中できる |
| 🎯 集中 | 6 | 数分でグローバル展開 | 世界中のリージョンを使い、海外向けサービスも即座に展開 |
試験での出題例
「企業がクラウドに移行することで、事前のキャパシティ計画が不要になった。これはクラウドのどの利点か?」
→ 答え:Stop guessing capacity(キャパシティ予測が不要に)
1.3 AWSグローバルインフラストラクチャ
コア基盤の階層構造(包括関係)
読み方: リージョンの中にAZがあり、AZの中にデータセンター(DC)がある
ポイント:
- 1つのAZは1つ以上のデータセンターで構成
- 各AZは物理的に分離(電源・ネットワークが独立)
- AZ間は高速な専用ネットワークで接続
コア基盤の詳細
| 要素 | 目的 | ポイント |
|---|---|---|
| リージョン | 地理的に離れた地域でサービス提供 | 法規制対応、ユーザーに近い場所でサービス提供。全世界に30+リージョン |
| アベイラビリティーゾーン(AZ) | リージョン内の独立したデータセンター群 | 災害・障害対策。2つ以上のAZに分散配置が推奨 |
| データセンター | サーバーやストレージが物理的に設置される施設 | AZを構成する最小単位。ユーザーからは見えない |
リージョン選択の4つの基準
- コンプライアンス(法規制): データを国外に出せない場合は該当国のリージョンを選択
- レイテンシー(遅延): ユーザーに近いリージョンを選択
- サービスの可用性: 一部サービスは特定リージョンのみで提供
- 料金: 同じサービスでもリージョンで料金が異なる
エッジ基盤(ユーザーに近い場所で処理)
3つとも「ユーザーに近い場所」にあり、低遅延を実現するための拠点です。違いは配置場所と用途。
| 種類 | 配置場所 | 主な用途 | 遅延の目安 |
|---|---|---|---|
| 🌐 エッジロケーション | 世界中(600+拠点) | CloudFrontでコンテンツ配信 | 数十ms |
| 🏙️ Local Zones | 大都市近郊 | ゲーム、動画編集 | 数ms〜10ms |
| 📶 Wavelength Zones | 5G基地局内 | AR/VR、コネクテッドカー | 1ms以下 |
覚え方: 遅延の厳しさに応じて選ぶ。普通→エッジロケーション、厳しい→Local Zones、超厳しい→Wavelength
オンプレミス拡張
| 種類 | 説明 |
|---|---|
| 📦 AWS Outposts | 自社データセンターにAWSのラックを設置。データを外に出せない場合に使用 |
試験での出題例
「データを国内に保持しながら、AWSと同じ体験を自社データセンターで実現したい場合、どのサービスを使用するか?」
→ 答え:AWS Outposts
1.4 高可用性・伸縮性・俊敏性
システムの信頼性を高める3つの観点
| 用語 | 定義 | 特徴 |
|---|---|---|
| 高可用性(High Availability) | 障害時にすばやく修復・交換して利用可能時間を最大化 | アクティブ・スタンバイ構成。わずかな中断が発生する可能性 |
| 耐障害性(Fault Tolerance) | 予備のリソースが常に稼働し、障害時も無停止で継続 | アクティブ・アクティブ構成。コストが高くなる傾向 |
| 災害対策(Disaster Recovery) | 広域災害を想定した復旧計画 | 復旧手順を事前に整備し、迅速なシステム復旧を実現 |
スケーリングの種類
| 種類 | アクション | メリット | デメリット |
|---|---|---|---|
| 垂直スケーリング(Scale up/down) | インスタンスのスペックを変更 | アプリ改修が不要な場合が多い | 変更時に再起動(中断)が必要 |
| 水平スケーリング(Scale out/in) | インスタンスの台数を増減 | 無停止で拡張可能 | ロードバランサー等が必要 |
伸縮性(Elasticity)
伸縮性とは、水平スケーリングに自動化を組み合わせた状態です。
- Amazon EC2 Auto Scaling: 台数の自動増減
- Elastic Load Balancing: 通信の振り分け
重要用語の整理(混同しやすい用語)
これらの用語は試験で混同しやすいので、何に焦点を当てているかで区別します。
| 用語 | 焦点 | 説明 | キーワード |
|---|---|---|---|
| 俊敏性(Agility) | 🏃 速度 | 変化への対応スピード | 「すぐ試せる」「数分で起動」 |
| 弾力性(Elasticity) | 🔄 自動 | 需要に応じて自動でリソースを増減 | 「Auto Scaling」「自動」 |
| スケーラビリティ(Scalability) | 📈 能力 | 需要増加に合わせてリソースを追加できる能力 | 「拡張可能」「対応できる」 |
| 信頼性(Reliability) | 💪 継続 | システムが期待通りに動き続ける能力 | 「障害復旧」「稼働し続ける」 |
覚え方:
- Agility = 「速い」(新しいことをすぐ始められる)
- Elasticity = 「自動」(勝手に伸び縮み)
- Scalability = 「できる」(大きくなれる能力)
- Reliability = 「続く」(壊れても動き続ける)
2. AWSクラウドの設計原則を特定する
対象知識: AWS Well-Architected フレームワーク
対象スキル: 6つの柱の理解、各柱の相違点の特定
2.1 AWS Well-Architected フレームワークとは
クラウドでのシステム設計において、「何を目指すべきか」をまとめたドキュメントです。6つの柱を基準にシステムを評価・改善します。
2.2 一般的な設計原則(6つ)
個別の柱に入る前に、クラウド特有の考え方として以下の原則が定義されています。
| 原則 | 説明 |
|---|---|
| キャパシティの推測をやめる | 必要な分だけ使い、後から調整する。Auto Scalingで自動対応 |
| 本稼働規模でテストする | クラウドなら本番と同じ環境を一時的に作ってテストし、終わったら削除できる |
| 自動化でアーキテクチャの実験を容易に | CloudFormationで環境をコード化し、何度でも同じ環境を再現 |
| 発展的アーキテクチャを許容する | 最初から完璧を目指さず、小さく始めて継続的に改善 |
| データに基づいてアーキテクチャを進化させる | CloudWatchのメトリクスやログを分析し、ボトルネックを特定・改善 |
| ゲームデーを通じて改善する | 本番障害を想定した訓練を定期的に実施し、チームの対応力を検証 |
2.3 Well-Architected 6つの柱
| 柱 | 焦点 | 定義 | キーワード |
|---|---|---|---|
| 🔧 運用上の優秀性 | どう運用するか | ビジネス価値を生むための運用改善 | IaC、継続的改善、ランブック |
| 🔒 セキュリティ | 何を守るか | 情報やシステムを保護する能力 | 暗号化、最小権限、トレーサビリティ |
| 💪 信頼性 | 壊れた時どうするか | 期待通りに動き、障害から回復する能力 | 自動復旧、スケーリング、バックアップ |
| ⚡ パフォーマンス効率 | 速さ・効率 | リソースを効率的に使用し維持する能力 | 適切なリソース選択、サーバーレス |
| 💰 コスト最適化 | お金 | 最安のコストでビジネス価値を実現する能力 | 適切なサイジング、リザーブド購入 |
| 🌱 持続可能性 | 地球環境 | 環境への影響を最小化する | 使用率最大化、マネージドサービス |
試験のコツ: 問題文のキーワードから柱を特定する。「障害復旧」→信頼性、「暗号化」→セキュリティ、「コスト削減」→コスト最適化
柱同士のトレードオフ
- セキュリティ vs パフォーマンス: 暗号化を強化するとCPU負荷が増える
- 信頼性 vs コスト: 冗長構成にするとコストが増える
- パフォーマンス vs コスト: 高性能インスタンスはコストが高い
試験での出題例
「システムの障害時に自動的に復旧する設計は、Well-Architectedフレームワークのどの柱に該当するか?」
→ 答え:信頼性(Reliability)
2.4 Infrastructure as Code(IaC)
「運用上の優秀性」の柱にある「運用をコードとして実行する」原則を具体化した概念です。
IaCのメリット
| メリット | 説明 |
|---|---|
| 人的ミスの削減 | 手動操作によるミスを排除 |
| 一貫性の確保 | 同じ設定を何度でも正確に再現 |
| 迅速なデプロイ | 環境構築を数分で完了 |
| スケールへの対応 | 数百台のサーバーも一括管理可能 |
コード例:CloudFormationでS3バケットを定義(YAML)
AWSTemplateFormatVersion: '2010-09-09'
Description: '学習用:S3バケットの作成例'
Resources:
MyStudyBucket:
Type: 'AWS::S3::Bucket'
Properties:
BucketName: 'my-unique-study-bucket-2026'
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
3. AWSクラウドへの移行の利点と戦略を理解する
対象知識: クラウド導入戦略、クラウド移行ジャーニーをサポートするリソース
対象スキル: AWS CAFのコンポーネント理解、適切な移行戦略の特定
3.1 AWS クラウド導入フレームワーク(AWS CAF)
AWS CAF(Cloud Adoption Framework) は、組織がクラウドへの移行を成功させるための包括的なガイドです。
6つのパースペクティブ(視点)
AWS CAFの4つの変革成果(試験頻出)
| 変革成果 | 説明 |
|---|---|
| ビジネスリスクの軽減 | クラウドの冗長性・自動バックアップにより、障害やデータ損失のリスクが減少 |
| ESGパフォーマンスの向上 | AWSの効率的なデータセンター利用でCO2排出量を削減 |
| 収益の増大 | 新サービスを素早く市場投入し、ビジネスチャンスを逃さない |
| 運用効率の向上 | 自動化・マネージドサービスにより、運用コストを削減 |
3.2 7つの移行戦略(7 Rs)
既存のアプリケーションをどのようにクラウドへ持っていくか、7つの戦略を使い分けます。
| 戦略 | 内容 | 特徴 |
|---|---|---|
| Retire(リタイア) | 廃止する | 不要なアプリを捨てる |
| Retain(リテイン) | 保持する | 現状維持。移行の準備ができるまで待つ |
| Rehost(リホスト) | そのまま移動 | 「リフト&シフト」。変更を加えずにクラウドへ移す |
| Relocate(リロケート) | 仮想環境の移設 | VMware環境などを設定変更なしにAWSへ移す |
| Repurchase(リパーチェス) | 買い替え | 既存ライセンスをやめ、SaaSへ移行 |
| Replatform(リプラットフォーム) | 部分最適化 | 基本は変えず、DBをRDSにするなど運用効率を高める |
| Refactor(リファクタリング) | 再設計 | クラウドネイティブな機能を使い、コードから書き換える |
戦略選択のフローチャート
試験での出題例
「オンプレミスのOracleデータベースをAmazon RDSに移行し、運用負荷を軽減したい。どの移行戦略が適切か?」
→ 答え:Replatform(リプラットフォーム)
3.3 データ移行サービス
AWS Snowファミリー(物理デバイスによる移行)
大量データの移行には、ネットワーク転送ではなく物理デバイスを使う方法があります。
| デバイス | サイズ感 | 容量 | ユースケース |
|---|---|---|---|
| AWS Snowcone | 🎒 弁当箱サイズ | 8〜14TB | 小規模データ、遠隔地・過酷な環境 |
| AWS Snowball Edge | 📦 スーツケースサイズ | 80〜210TB | 中〜大規模データ移行 |
| AWS Snowmobile | 🚛 トラック1台 | 100PB | データセンター丸ごと移行 |
選び方: データ量で選ぶ。TB級→Snowcone、数十〜数百TB→Snowball、PB級→Snowmobile
目安: ネットワーク転送で1週間以上かかるならSnowファミリーを検討
その他の移行ツール
| サービス | 役割 |
|---|---|
| AWS DMS | Database Migration Service。稼働中のDBを停止させずに移行 |
| AWS SCT | Schema Conversion Tool。異なるDB間のスキーマ変換 |
| AWS Transfer Family | FTPなどの標準プロトコルでデータ転送 |
| AWS Storage Gateway | オンプレミスからAWSストレージへシームレスに接続 |
試験での出題例
「10PBのデータをAWSに移行したい。最も効率的な方法は?」
→ 答え:AWS Snowball(または複数のSnowball Edge)
3.4 ストレージとデータベースサービス
ストレージの選び方
| 種類 | サービス | イメージ | 選ぶ場面 |
|---|---|---|---|
| オブジェクト | S3 | 🪣 巨大なバケツ | 画像、動画、ログなど何でも |
| アーカイブ | S3 Glacier | 🧊 冷凍庫 | 数年単位の長期保管 |
| ブロック | EBS | 💾 外付けHDD | EC2専用のディスク |
| ファイル | EFS/FSx | 📂 共有フォルダ | 複数EC2からアクセス |
データベースの選び方
| 分類 | サービス | 特徴 | 選ぶ場面 |
|---|---|---|---|
| 🐘 SQL系 | RDS | MySQL、PostgreSQL等を簡単運用 | 一般的なWebアプリ |
| 🚀 SQL系(高性能) | Aurora | RDSの5倍高速 | 高負荷なシステム |
| 🔥 NoSQL | DynamoDB | スキーマ不要、超高速 | ゲーム、IoT、セッション管理 |
| 📊 分析系 | Redshift | PB級データの分析 | BIツール、レポート |
| ⚡ キャッシュ | ElastiCache | ミリ秒単位の応答 | セッション、ランキング |
4. クラウドエコノミクスのコンセプトを理解する
対象知識: クラウドエコノミクスの側面、クラウド移行によるコスト削減
対象スキル: 固定費と変動費の理解、ライセンス戦略、適切なサイジング、規模の経済
4.1 総保有コスト(TCO)の構成要素
TCO(Total Cost of Ownership) とは、ある資産を購入から廃棄までに必要なすべてのコストの合計です。
| 要素 | 分類 | 内容 |
|---|---|---|
| 設備投資(CapEx) | 投資費 | サーバー本体、建物、ネットワーク機器など先行投資 |
| 運用コスト(OpEx) | 運営費 | 光熱費、メンテナンス備品、日々の流動的な費用 |
| 人件費 | 人のリソース | データセンター管理、ハードウェア保守、監視エンジニア |
| ライセンス費用 | ソフトウェア | OSやDBの利用許可費用 |
4.2 固定費から変動費への変化
AWSへ移行することで、ITコストは「固定支出(CapEx中心)」から「変動支出(OpEx中心)」へシフトします。
| オンプレミス(固定支出) | AWS クラウド(変動支出) |
|---|---|
| 需要のピークに合わせた過剰な設備投資 | 実際の需要に合わせた柔軟なリソース利用 |
| 未使用リソースにも維持費が発生 | 使った分だけ支払う従量課金モデル |
4.3 規模の経済(Economies of Scale)
なぜAWSは安いのか?
AWSは世界中の何百万もの顧客のリソースを集約して運用しています。
- 大量購入による割引: サーバー、ネットワーク機器を大量購入し、単価が安い
- 効率的な運用: 巨大なデータセンターを効率的に運用し、1顧客あたりのコストが低下
- 技術革新の共有: 新技術への投資を全顧客で分担
顧客へのメリット
- AWSは規模の経済によるコスト削減効果を定期的な値下げとして顧客に還元
- 2006年のサービス開始以来、130回以上の値下げを実施
試験での出題例
「AWSがオンプレミスよりも低コストでサービスを提供できる主な理由は何か?」
→ 答え:規模の経済(Economies of Scale)
4.4 ライセンス戦略
BYOLとライセンス込みモデルの比較
| モデル | 説明 | メリット | デメリット |
|---|---|---|---|
| BYOL(Bring Your Own License) | 既存ライセンスをAWSに持ち込み | 既存投資を活用、追加費用なし | 管理が複雑、互換性確認が必要 |
| ライセンス込みモデル | AWSがライセンスを含めて提供 | 管理が簡単、従量課金で柔軟 | 長期利用ではBYOLより高くなる場合も |
具体例
- BYOL: Windows ServerやSQL Serverのライセンスを持っている場合、それをEC2で使用
- ライセンス込み: Amazon RDSでSQL Serverを使う場合、ライセンス料金が利用料に含まれる
AWS License Manager
ライセンスの使用状況を追跡・管理するサービス。BYOLの場合に特に重要です。
4.5 コスト削減を促進する4つの戦略
1. 適切なサイジング(Right Sizing)
ワークロードに対して必要最小限のリソースを割り当て、オーバープロビジョニングを避けます。
AWS Compute Optimizer: 機械学習でリソース使用状況を分析し、最適なインスタンスタイプを推奨
2. 運用の自動化
- 負荷に応じてサーバーを自動増減(Auto Scaling)
- 夜間に不要なインスタンスを停止して無駄な課金を防止
3. マネージドサービスの活用
RDSなどを使い、バックアップやパッチ適用などの管理作業(人件費)を削減
4. コンプライアンス範囲の縮小
AWSの認証済みサービスを活用し、自社で監査を行う範囲を限定
4.6 オートメーションの利点
| 利点 | 説明 |
|---|---|
| 人的ミスの削減 | 手動操作によるミスを排除 |
| 一貫性の確保 | 同じ設定を何度でも正確に再現 |
| 迅速なデプロイ | 環境構築を数分で完了 |
| スケールへの対応 | 数百台のサーバーも一括管理可能 |
| コスト削減 | 運用工数の削減 |
自動化を実現するAWSサービス
- AWS CloudFormation: インフラをコード化(IaC)
- AWS Systems Manager: 運用タスクの自動化
- Amazon EventBridge: イベント駆動の自動化
- AWS Lambda: サーバーレスでコードを自動実行
4.7 コスト最適化の実践例
開発環境のインスタンスを夜間に停止する(AWS CLI)
オンプレミスではサーバーを止めてもコストは変わりませんが、AWSでは停止中のコンピューティング料金は発生しません。
# 特定のインスタンスを停止
aws ec2 stop-instances --instance-ids i-0abcdef1234567890
# 動作中のインスタンスを確認
aws ec2 describe-instances \
--filters "Name=instance-state-name,Values=running" \
--query "Reservations[*].Instances[*].[InstanceId,InstanceType]" \
--output table
試験での出題例
「EC2インスタンスのCPU使用率が常に10%程度である。コストを削減するためにどうすべきか?」
→ 答え:より小さいインスタンスタイプにダウンサイズする(Right Sizing)
用語集
| 用語 | 説明 |
|---|---|
| IaC(Infrastructure as Code) | インフラをプログラムコードとして定義・管理 |
| API(Application Programming Interface) | プログラムからAWSサービスを操作するための仕組み |
| SDK(Software Development Kit) | 各プログラミング言語用のAWS操作ライブラリ |
| オンデマンド | 事前予約なしで必要な時にリソースを使用 |
| 従量課金 | 使った分だけ支払う料金モデル |
| プロビジョニング | リソースを準備・割り当てること |
| トレーサビリティ | 「誰が・いつ・何をしたか」を追跡できる状態 |
| サーバーレス | サーバー管理をAWSに任せ、コード実行だけに集中する仕組み |
| マネージドサービス | AWSが運用の手間を引き受けてくれるサービス |
| メカニカルシンパシー | ツールの仕組みを理解し、最適な方法で使いこなすこと |
試験対策チェックリスト
CLF-C02試験のDomain 1(24%)の全範囲をカバーするチェックリストです。
タスクステートメント 1.1: AWSクラウドの利点を定義する
- クラウドコンピューティングの5つの特徴を説明できる
- AWSクラウドの6つの利点を説明できる
- グローバルインフラストラクチャの利点(デプロイのスピード、グローバルリーチ)を説明できる
- 高可用性、伸縮性、俊敏性の違いを説明できる
- リージョン、AZ、エッジロケーションの違いを説明できる
タスクステートメント 1.2: AWSクラウドの設計原則を特定する
- Well-Architected フレームワークの6つの柱を説明できる
- 各柱の主な設計原則を説明できる
- 各柱の相違点(フォーカスの違い)を説明できる
- 一般的な設計原則(6つ)を説明できる
タスクステートメント 1.3: AWSクラウドへの移行の利点と戦略を理解する
- AWS CAFの6つのパースペクティブを説明できる
- AWS CAFの4つの変革成果を説明できる
- 7つの移行戦略(7 Rs)を説明し、適切な戦略を選択できる
- AWS Snowファミリーの使い分けを説明できる
- AWS DMSの役割を説明できる
タスクステートメント 1.4: クラウドエコノミクスのコンセプトを理解する
- TCOの構成要素(CapEx、OpEx、人件費、ライセンス費用)を説明できる
- 固定費から変動費へのシフトのメリットを説明できる
- オンプレミス環境に関連するコスト(隠れたコスト含む)を説明できる
- BYOLとライセンス込みモデルの違いを説明できる
- 適切なサイジング(Right Sizing)のコンセプトを説明できる
- オートメーションの利点を説明できる
- 規模の経済(Economies of Scale)を説明できる