Amazon CLF-C02: コアコンピューティングサービス — 学習ガイド

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

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

EC2のコアコンセプト、購入モデル、可用性パターン

Amazon EC2は、基本的なIaaSコンピュートサービスです。CPU、メモリ、ストレージ、ネットワークのインスタンスタイプを選択し、管理下のオペレーティングシステムを実行し、オプションで永続的なブロックストレージとしてElastic Block Store (EBS) ボリュームをアタッチします。可用性を考慮した設計では、ワークロードを複数のアベイラビリティーゾーン (AZ) に配置し、必要に応じて複数のリージョンに配置する必要があります。マネージド型リレーショナルデータベースには、同期スタンバイと自動フェイルオーバーのためにAmazon RDS Multi‑AZを使用します。極端な読み取りスケールやクロスリージョンでの災害復旧には、Amazon Aurora Global Databaseを検討します。インスタンスの購入選択は、コストと回復力のトレードオフを決定します。オンデマンドはコミットメントなしで柔軟性を提供し、リザーブドインスタンスやCompute Savings Plansは、定常的で継続的な使用に対して最大の予測可能な割引を提供します。スポットインスタンスは、耐障害性があり中断可能なワークロードに対して最も低い価格を提供します。よくある落とし穴には、単一のAZへの依存、インスタンスへの長期的な認証情報の埋め込み、「念のため」の過剰なプロビジョニングなどがあります。Auto Scalingグループをヘルスチェック、ライフサイクルフック、混合インスタンスポリシー (オンデマンド + スポット) と共に使用して、コストと可用性のバランスを取ります。リザーブド/Savings Plansとスポットのどちらを選択するかは、必要なアップタイム、中断への耐性、予測の正確さを評価して決定します。Multi‑AZかマルチリージョンかは、RTO/RPO要件とクロスリージョンのレイテンシー制約に基づいて選択します。

マネージドコンテナ、バッチ、サーバーレスコンピューティング：意思決定の基準

AWSは、アーキテクチャの目標に合わせて複数のマネージドコンピューティングプラットフォームを提供しています。AWS Lambdaは、イベント駆動型のサーバーレス関数を実現し、自動スケーリングとミリ秒単位の課金が特徴で、ステートレスで短時間のタスクに最適です。Amazon ECSは、マネージド型のコンテナオーケストレーションオプションを提供し、サーバーレスなコンテナ実行のためにFargateと統合するか、より詳細な制御のためにEC2と統合します。Amazon EKSは、Kubernetesを標準とするチーム向けに、マネージドコントロールプレーンとしてKubernetesを実行します。ワーカーノードはEC2またはFargateです。AWS Batchは、EC2またはスポットキャパシティ全体でバッチコンピューティングジョブをスケジュールおよびスケーリングし、高性能または大容量のジョブのスループットを最適化します。Elastic Beanstalkは、基盤となるインフラストラクチャを管理することなくWebアプリケーションをデプロイするためのアプリケーションプラットフォームです。EC2、オートスケーリング、ELB、RDSのセットアップを抽象化し、より迅速なリフト＆シフトのデプロイを可能にします。主要な決定基準には、運用スキルセット (Kubernetesの専門知識があればEKSが有利)、デプロイ速度 (Beanstalk)、コストの予測可能性 (Fargateは簡素化しますがコストが高くなる可能性あり)、ワークロードの特性 (短時間でイベント駆動のタスクにはLambda、長時間実行されるサービスにはECS/EKS) が含まれます。よりシンプルなマネージドサービス (LambdaやFargate) が運用負荷を軽減し、俊敏性を高めることができる場合に、最も機能豊富なオプションを選択するという罠を避けてください。

オートスケーリング、伸縮性、コスト最適化戦略

伸縮性 (Elasticity) とは、需要に合わせてリソースをスケールアップおよびスケールダウンする能力であり、オートスケーリングはそれを実現するためのメカニズムです。EC2にはAuto Scalingグループ (ASG) を使用し、ターゲット追跡、ステップ、または予測ポリシーに基づいてインスタンスを追加または削除します。コンテナには、タスクとクラスターのためにECSまたはEKSのオートスケーリングを使用し、関数にはLambdaの組み込み同時実行制御を使用します。ステートレスになるようにアーキテクチャを設計し、状態をAmazon RDS、DynamoDB、ElastiCache、S3などのマネージドサービスに外部化することで、インスタンスを一時的なものにできるようにします。定期的なサイジングレビューでインスタンスを適正化し、モニタリング (CloudWatchメトリクスとアラーム) を使用し、安定したベースライン使用量にはSavings Plansまたはリザーブドインスタンスを検討し、変動するワークロードはスポットに配置します。検討すべき料金モデル：

オンデマンド: コミットメントなし、時間/秒単位で支払い。
リザーブドインスタンス / Savings Plans: 1年または3年のコミットメントで大幅な割引。
スポットインスタンス: 中断可能なワークロードに対する最大の割引。
Dedicated Hosts/Instances: コンプライアンスのための物理的な分離、コストは高め。よくある落とし穴には、オートスケーリングのウォームアップ時間を過小評価すること、正常なシャットダウンのためにライフサイクルフックを使用しないこと、ステートフルで重要なワークロードにスポットを過度に使用することなどがあります。安全なリリースのためにブルー/グリーンまたはカナリアデプロイメントを使用し、未使用リソースのコスト管理を自動化するためにライフサイクルポリシーを使用します。

コンピューティングのためのセキュリティ、コンプライアンス、運用ツール

セキュリティと運用は、AWSにおけるコンピューティングの基盤です。責任共有モデルに基づき、AWSはグローバルインフラストラクチャとマネージドサービスを保護し、一方、顧客はIaaSを使用する際にゲストOS、アプリケーション設定、データ、IAM権限に責任を負います。長期的なアクセスキーを埋め込むことは避け、代わりにIAMロールをEC2インスタンスにアタッチするか、EKSにはIAM Roles for Service Accounts (IRSA) を使用し、AWS Secrets ManagerまたはSystems Manager Parameter Store (SecureString) を使ってシークレットをローテーションし、一元管理します。監査と調査のためには、AWS CloudTrailを有効にしてアカウント全体のAPIアクティビティをキャプチャし、AWS Configを使用してリソース設定を記録します。S3内の機密データを発見・分類するにはAmazon Macieを、アカウント間またはパブリックなリソース共有を見つけるにはIAM Access AnalyzerまたはS3 Access Analyzerを使用します。コンプライアンスの証跡については、AWS Artifactを使用して監査レポートを取得します。運用上の可視性は、ネットワークトラフィックのためのVPC Flow Logs、アカウント固有のイベントのためのAWS Personal Health Dashboard、グローバルなサービスステータスのためのService Health Dashboardによって向上します。実務者によくある間違いには、ルートアカウントにアクティブなキーを残すこと、ルートユーザーでMFAを有効にしないこと、外部アプリケーションへのSAMLベースのシングルサインオンのためにIAM Identity Center (旧 AWS SSO) でIDを一元化しないことなどがあります。

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

シナリオ: Acme Analytics社は、本番AWSアカウント内の単一AZで、EC2上でデータ処理アプリケーションを実行しています。彼らは夜間に大量のデータを処理するバッチジョブを抱えており、コストの削減、AZ障害からの迅速な復旧、そして安全なシークレットの取り扱いを望んでいます。

課題: アプリケーション全体をすぐに再設計することなく、夜間バッチのスループットを確保しつつコンピューティングコストを削減し、AZをまたいだ可用性を向上させること。

推奨アプローチ:

コストを削減しつつベースラインキャパシティを維持するために、混合インスタンスポリシー (スポット + オンデマンド) を使用して、バッチワーカーをAWS Batchコンピューティング環境に移行します。
AWS Batchが複数のAZを使用するように設定し、耐障害性のためにAZ間に分散されたジョブキューでRetry/RetryStrategyを有効にします。
埋め込まれた認証情報をEC2/Batchジョブ用のIAMロールに置き換え、ローテーションされるシークレットをAWS Secrets Managerに保存します。IAMと統合して自動的に取得できるようにします。
残りのステートフルなコンポーネントのために、最小限のEC2フリートにCloudWatchアラームとAuto Scalingポリシーを実装し、DBが使用されている場合はクロスAZのRDS Multi‑AZを有効にします。

論理的根拠: マネージドなバッチとスポットインスタンスを利用することで、コストと運用オーバーヘッドが削減されます。一方、マルチAZへの分散とIAM/Secrets Managerの利用は、可用性とセキュリティを向上させます。これは、伸縮性、最小権限、シークレットの自動ローテーションといったベストプラクティスに沿ったものです。

← AWS グローバルインフラストラクチャ · すべてのドメイン · コアストレージサービス →

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