examlab .net 最も価値のある認定資格への最も効率的な道。
Support
このノートについて 約 21 分

デプロイと運用方法

4,120 語 · 約 21 分の読書 ·

CLF-C02 タスク3.1を完全網羅：Management Console・AWS CLI・AWS SDKの使い分け、CloudFormationとCDKによるInfrastructure as Code、Elastic Beanstalk、Systems Manager、Direct ConnectとVPNによるハイブリッド接続、そしてクラウド・ハイブリッド・オンプレミスの各デプロイモデル。

20問の模擬問題に挑戦 → 無料 · 登録不要 · CLF-C02

AWSにおけるデプロイと運用とは、グローバルなAWSインフラ全体にわたってクラウドリソースをプロビジョニング・設定・更新・自動化する方法を選択することである。CLF-C02試験（タスクステートメント3.1）では、3つのAWSデプロイアクセス方法（Management Console・AWS CLI・AWS SDK）の区別、AWS CloudFormationとAWS CDKによるInfrastructure as Codeの説明、デプロイモデル（クラウド・ハイブリッド・オンプレミス）の選択、そしてAWS Elastic BeanstalkやAWS Systems Managerといったマネージドデプロイプラットフォームの特定が求められる。

AWSのデプロイと運用方法とは何か？

AWSデプロイ方法とは、AWSリソースを作成・管理するために使用するツール・インタフェース・パターンの総称である。AWS運用方法とは、デプロイ後にそれらのリソースを実行・監視・パッチ適用・更新するためのツールを指す。CLF-C02試験がデプロイと運用を単一のタスクステートメント3.1として扱う理由は、実際のAWS業務では両者が常に組み合わさるからである。AWS CloudFormationでデプロイし、AWS Systems Managerで運用する。AWS CLIでデプロイし、AWS SDKで継続的な運用をスクリプト化する。ハイブリッドトポロジにデプロイし、AWS Direct ConnectとAWS VPNでそのトポロジを運用する。

CLF-C02試験が最上位レベルで求める知識は、「AWSにどうアクセスするか」という問いへの3つの答えである。

  1. AWS Management Console — 人間向けのブラウザベースのグラフィカルユーザインタフェース。
  2. AWS CLI — スクリプト・ターミナル・自動化パイプライン向けのコマンドラインツール。
  3. AWS SDK — Python・JavaScript・Java・Go・.NET・Ruby・PHP・C++などの言語からAWS API呼び出しを行うアプリケーションを作るためのソフトウェアライブラリ。

また、「ワークロードをどこで実行するか」という問いへの3つの答えも必要である。

  1. クラウド（オールイン） — すべてのワークロードがAWS Regionsで動く。
  2. ハイブリッド — 一部のワークロードがオンプレミスで動き、AWS Direct ConnectまたはAWS Site-to-Site VPN経由でAWSに接続する。あるいはデータセンターに設置されたAWS Outpostsハードウェア上で動く。
  3. オンプレミス（クラウドツール活用） — AWS CDKやAWS CloudFormationなどのAWS互換ツールを使って一貫した設定を実現しながら、従来のデータセンターで動かす。

この2軸（アクセス方法とデプロイモデル）が、Infrastructure as Code（AWS CloudFormation・AWS CDK）とマネージドデプロイプラットフォーム（AWS Elastic Beanstalk）と組み合わさることで、CLF-C02が問うAWSデプロイ方法の全体像が完成する。

AWSデプロイ方法とは、AWSリソースを作成・設定・管理するためにAWSが提供するプログラム的・対話的な仕組みである。3つの標準的なアクセス経路は、AWS Management Console（GUI）・AWS CLI（シェル）・AWS SDKライブラリである。3つすべてが同じ基盤となるAWSサービスAPIを呼び出すため、AWS Management Consoleでクリックできることは、AWS CLIでスクリプト化でき、AWS SDKでコードから呼び出すことができる。参照: https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html

やさしい解説: AWSのデプロイ方法

頭文字が乱立する前に、3つの身近な比喩でAWSデプロイ方法を記憶に定着させよう。それぞれの比喩はCLF-C02試験が重視する異なる側面を照らしている。手動クリック対プログラム的自動化、単発プロビジョニング対再現可能なInfrastructure as Code、そして初期デプロイ対継続的な運用だ。すべて読めば、AWS Management Console・AWS CLI・AWS SDK・AWS CloudFormation・AWS CDK・AWS Systems Managerの違いが試験当日もスラスラ出てくる。

Analogy 1 — 回転寿司のオーダー方法（手動対プログラム的アクセス）

同じ回転寿司チェーンに3つの注文方法があると想像してほしい。席に座ってタッチパネルのメニューを指差しながら板前に声をかけるのがAWS Management Console——視覚的でわかりやすく初めてでも迷わないが、50貫まとめて頼む場合は相当手間がかかる。スマートフォンアプリでサっと商品コードを打ち込むのがAWS CLI——手順を覚えたレギュラー客向きで、スクリプト化すれば何百貫でも一括注文できる。会社のオフィスに設置した自動発注システムが寿司屋のAPIに繋がっていて、在庫が減るたびに自動補充するのがAWS SDK——人間が介在せず、コードが注文を出す。どの方法も同じ厨房APIに到達し、同じ寿司が届く。違うのは操作の作法だけだ。CLF-C02の教訓：「自動化」「スケジュール実行」という言葉が出たら、タッチパネルの選択肢は外せる。

Analogy 2 — マンションの管理方法（単発対再現可能なインフラ）

今度はマンション管理で考えてみよう。漏水した蛇口をモンキーレンチで自分で直すのは、コンソールから手動でEC2インスタンスをプロビジョニングする行為——一つの問題は解決するが記録は残らない。スマートホームアプリで部屋の照明やエアコンを遠隔操作するのはAWS Systems Manager——既存の建物を管理するには便利だが、あくまで今ある建物の運用だ。建築家に詳細な設計図を渡して「10棟、同じ間取りで建ててほしい」と頼むのがAWS CloudFormationとAWS CDK——設計図はバージョン管理でき、レビューでき、冪等性がある。2回実行しても同じマンションが1棟できるだけで、微妙に異なる2棟が生まれることはない。この比喩が伝えるのは、繰り返し発生するデプロイにInfrastructure as Codeがコンソールクリックより優れる理由だ。

Analogy 3 — 旅行の手配方法（プロビジョニング対継続的な運用）

旅行の手配で最後の比喩を完成させよう。旅行代理店にすべておまかせでツアーを組んでもらうのがAWS Elastic Beanstalk——旅の好みを伝えるだけで（アプリケーションコードをアップロードするだけで）、EC2・ロードバランサー・Auto Scalingがマネージドプラットフォームによって自動的に手配される。自分でオンライン予約サイトを使い、フライトとホテルを宣言的なフォームで組み合わせるのがAWS CloudFormation。会社の経費精算システムが航空会社APIに繋がっていて、カレンダーイベントが登録されるたびに自動的に出張チケットが取られるのがAWS SDKだ。旅の手配が完了した後も、フライト変更・ホテル振替・トラブル対応が必要になる——この旅中の継続サポート役がAWS Systems Managerであり、すべてのデプロイ方法と並走するDay-2運用レイヤーだ。デプロイは目的地に連れていく。運用は現地で走り続けさせる。

Core Operating Principles — AWSにおけるプロビジョニング・運用・自動化

あらゆるAWSデプロイ方法は最終的に同じ目的地、すなわちAWSサービスAPIに到達する。AWS Management Console・AWS CLI・AWS SDKは同じ建物への3つの入口だ。この単一の原則を理解すれば、CLF-C02タスク3.1の大半が解けるようになる。

AWS Management Consoleで「インスタンスを起動」をクリックすると、コンソールはEC2のRunInstances APIにHTTPS呼び出しを行う。AWS CLIでaws ec2 run-instancesと入力しても、CLIは同じHTTPS呼び出しを行う。PythonコードがAWS SDKのboto3.client('ec2').run_instances(...)を呼び出しても、やはり同じHTTPS呼び出しだ。3つのAWSデプロイ方法の違いは操作体験のみである。

  • AWS Management Console: 初めての探索・単発の手動作業・リソースの視覚的確認に最適。
  • AWS CLI: スクリプト化・自動化・シェルパイプライン・CI/CDジョブ・アカウント横断の繰り返し作業に最適。
  • AWS SDK: アプリケーションの内部にAWSの動作を組み込み、プロダクトコードがAWSリソースをプログラム的に作成・読み取り・更新・削除できるようにするために最適。

このAPI基盤の上に、AWSはより高水準のデプロイ方法を追加している。

  • AWS CloudFormation — 宣言的テンプレートをリソースのスタックに変換する。
  • AWS CDK — 一般的なプログラミング言語からAWS CloudFormationテンプレートを生成する。
  • AWS Elastic Beanstalk — アプリケーションコードを受け取り、周辺インフラをデプロイする。
  • AWS Systems Manager — 運用レイヤーを提供する：パッチ適用・コマンド実行・パラメータ保管・セッション管理。

CLF-C02のすべてのデプロイ・運用問題は、これらのレイヤーの中から適切なものを選ぶ問題だ。

AWSが複数のデプロイ方法を提供する理由

AWSが複数のデプロイ方法を提供するのは、ワークフローによって必要な抽象化のレベルが異なるからだ。Amazon S3を初めて触る個人開発者はAWS Management Consoleが必要だ。12のAWS Regionsに200のマイクロサービスをデプロイするDevOpsエンジニアはAWS CloudFormationが必要だ。S3を使って写真アップロードをサポートするモバイルチームはSwiftまたはKotlin向けのAWS SDKが必要だ。AWS Management Console・AWS CLI・AWS SDK・AWS CloudFormation・AWS CDKを補完的な（競合ではない）選択肢として提供することで、AWSはデプロイニーズ全体のスペクトラムをカバーしている。

AWSへのアクセス方法：Management Console・CLI・SDK・API

すべてのCLF-C02受験者は、主要なアクセスポイントとなる3つのAWSデプロイ方法をすらすら区別できなければならない。

AWS Management Console（GUI）

AWS Management Consoleはconsole.aws.amazon.comのウェブブラウザGUIだ。AWSを学ぶ際に多くの人が最初に経験するエントリポイントである。

AWS Management Consoleの強み：

  • インストール不要——どのブラウザでも動く。
  • 視覚的な発見——すべてのAWSサービスを確認してカテゴリ別にナビゲートできる。
  • ガイド付きウィザード——Amazon RDS・AWS Elastic Beanstalk・Amazon VPCなどのサービスには、適切なデフォルト値を提案するリソース作成ウィザードがある。
  • コストと請求ダッシュボード——AWS Billing and Cost ManagementはAWS Management Consoleで最もよく確認できる。

AWS Management Consoleの弱み：

  • 自動化不可——「ボタンをクリックする」cronジョブはスケジュールできない。
  • 再現性がない——同じウィザードを2人の人間がクリックすると、微妙に異なる選択をして設定ドリフトが生じる可能性がある。
  • 大量操作が遅い——S3バケットを50個コンソールから1つずつ作成するのは苦痛だ。
  • バージョン管理がない——コンソールクリックのコミット履歴は存在しない。

AWS CLI

AWS CLIはシェルからAWS API呼び出しを発行するために、ローカルにインストールするコマンドラインツールだ。DevOps・SRE・CI/CDパイプラインにとって基盤となるAWSデプロイ方法だ。

AWS CLIコマンドの構造：aws <service> <operation> --<parameter> <value>。例として、aws s3 cp localfile.txt s3://my-bucket/はファイルをアップロードし、aws ec2 describe-instances --region us-east-1はEC2インスタンスを一覧表示する。

AWS CLIの強み：

  • bash・zsh・PowerShell・どのシェルでもスクリプト化できる。
  • すべてのAWSサービスで一貫している——パターンを覚えればどのサービスも扱える。
  • Linux・macOS・Windows・AWS CloudShell・Amazon EC2インスタンス・AWS Systems Managerマネージドノードにインストールできる。
  • バッチ操作が高速——単一スクリプトで1000リソースをループ処理できる。

AWS CLIの弱み：

  • AWS Management Consoleよりも学習曲線が急だ。
  • 設定済みの認証情報（アクセスキー・IAM Role・AWS SSOプロファイル）が必要だ。

AWS SDK

AWS SDKは、AWS APIをネイティブ関数呼び出しとして公開する言語固有のライブラリセットだ。AWSはPython（Boto3）・JavaScript/TypeScript・Java・.NET・Go・Ruby・PHP・C++・Swift・Kotlin・Rust向けの公式SDKを提供している。AWS SDKは、AWSの機能をアプリケーションコード内に組み込む必要がある場合の正しいAWSデプロイ方法だ。

AWS SDKの強み：

  • ネイティブ言語構造——慣用的なオブジェクト・async/awaitサポート・型付きパラメータ。
  • 統合された認証情報解決——EC2のIAM Role・Lambda実行ロール・ローカルプロファイルを自動で使用する。
  • リトライ・タイムアウト・ページネーターヘルパーが組み込まれている。
  • 言語が動く場所ならどこでも動く——モバイルアプリ・バックエンドサービス・AWS Lambda関数・Amazon ECSコンテナ。

AWS SDKの弱み：

  • コーディングスキルが必要だ。
  • アプリケーション内での依存関係管理が必要だ。

CLF-C02のシナリオ問題で「自動化をサポートするAWSデプロイ方法はどれか？」と問われる場合がある。正解はAWS CLIまたはAWS SDKだ。どちらもプログラム的アクセスを提供するからである。AWS Management Consoleは自動化をサポートしない——人間が操作するものだ。覚え方：Management Console=クリック、AWS CLI=スクリプト、AWS SDK=コード。3つともAWSデプロイ方法として有効だが、プログラム的アクセスを提供するのはAWS CLIとAWS SDKだけだ。参照: https://docs.aws.amazon.com/general/latest/gr/aws-apis.html

プログラム的アクセス：AWS CLIとAWS SDKの詳細

プログラム的アクセスとは、人間がクリックしない、あらゆるAWSデプロイ方法に対するCLF-C02の包括的な用語だ。知っておくべき2つのプログラム的アクセスAWSデプロイ方法は、AWS CLIとAWS SDKだ。

AWS CLIによるプログラム的アクセス

AWS CLIを使ったプログラム的アクセスは、アクセスキー（アクセスキーID＋シークレットアクセスキー）または、より推奨される、AWS STSを介した短期間の認証情報を使用するIAM Roleで実現する。AWS CLIは、単発のジョブを自動化したいとき、出力をシェルパイプに渡したいとき、またはインスタンスフリート全体でAWS Systems Manager Run Commandを実行したいときに最速のパスとなる。

CLF-C02でテストされるAWS CLIプログラム的アクセスの一般的なパターン：

  • DevOpsエンジニアがAWS CLIを使ったbashスクリプトを書き、アカウント全体でIAMアクセスキーをローテーションする。
  • CI/CDパイプラインがAWS CLIを使ってアーティファクトをAmazon S3にプッシュし、AWS CodeDeployをトリガーする。
  • 管理者がAWS Management Consoleにバンドルされたブラウザベースのシェル（AWS CloudShell）からAWS CLIを使い、ローカルにインストールせずに操作する。

AWS SDKによるプログラム的アクセス

AWS SDKは、アプリケーション内部でAWS API呼び出しが必要な場合のプログラム的アクセス経路だ。AWS SDKはAWS CLIと同じIAM権限モデルと認証情報解決チェーンを使用する：環境変数・共有認証情報ファイル・EC2用IAM Role・サービスアカウント用IAM Roleなど。

CLF-C02でテストされるAWS SDKプログラム的アクセスの一般的なパターン：

  • Amazon EC2上で動くPythonアプリケーションがBoto3（Python向けAWS SDK）を使ってAmazon DynamoDBにレコードを書き込む。長期的な認証情報は保存されない——インスタンスプロファイルIAM Roleが短期認証情報を自動的に提供する。
  • JavaScriptウェブアプリがブラウザ向けAWS SDK for JavaScriptを使い、Amazon Cognitoと組み合わせてアイデンティティを管理する。
  • Goで書かれたAWS Lambda関数がAWS SDK for Goを使ってAmazon SNSにメッセージを配信する。

AWS CLIまたはAWS SDKのプログラム的アクセスを使う場合、長期的なアクセスキーよりもIAM Roleを常に優先すること。IAM RoleはAWS STSを介して一時的な認証情報を発行するため、認証情報が漏洩した場合の被害範囲を縮小できる。Amazon EC2・AWS Lambda・Amazon ECS・AWS Fargate上で動くAWSデプロイ方法には、コンピューティングリソースにIAM Roleをアタッチして、AWS SDKが自動的に取得できるようにするのが正しいパターンだ——コードや設定ファイルにアクセスキーが書かれるべきではない。参照: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

Infrastructure as Code：AWS CloudFormation・AWS CDK・AWS SAM

Infrastructure as Code（IaC）とは、クラウドインフラをテキストファイルで定義し、バージョン管理・ピアレビュー・繰り返しデプロイを可能にする手法だ。Infrastructure as Codeは、手動のAWS Management Consoleクリックが生み出す再現性の問題を解決するため、本番ワークロードでの主流AWSデプロイ方法となっている。

AWS CloudFormation

AWS CloudFormationはネイティブAWSのInfrastructure as Codeサービスだ。YAMLまたはJSONでCloudFormationテンプレートを書き、必要なAWSリソース（EC2インスタンス・S3バケット・IAM Role・VPCなど）を記述すると、AWS CloudFormationがそれらをスタックと呼ばれる単一のユニットとしてデプロイする。

CLF-C02向けAWS CloudFormationのコア概念：

  • テンプレート — リソース・パラメータ・マッピング・出力・条件を記述したYAMLまたはJSONファイル。
  • スタック — 1つのテンプレートから作成されるAWSリソースの集合。
  • Change Set — 更新を適用する前にAWS CloudFormationが変更する内容のプレビュー。
  • Drift Detection — スタック内のリソースがテンプレート外で変更されたことを検出する。
  • 宣言的 — 望ましい最終状態を記述するだけでよく、AWS CloudFormationが操作の順序を把握する。

AWS CloudFormationは宣言的である：「何が欲しいか」を述べるのであって、「どう作るか」を述べるのではない。「ステップ1を行い、次にステップ2を行い、次にステップ3を行う」と指定する命令的スクリプトとは異なる。宣言的なInfrastructure as Codeの方が安全なのは、AWS CloudFormationが失敗したデプロイをロールバックし、ドリフトを検出し、スタックを冪等的に更新できるからだ。

AWS CDK（Cloud Development Kit）

AWS CDKはより高水準なInfrastructure as Codeフレームワークで、TypeScript・JavaScript・Python・Java・C#・Goといった使い慣れたプログラミング言語でAWS CloudFormationスタックを定義できる。AWS CDKは内部でAWS CloudFormationテンプレートを生成し、デプロイのためにAWS CloudFormationに渡す。

AWS CDKが存在する理由：複雑なアーキテクチャではAWS CloudFormationのYAMLが冗長になりがちだ。開発者は汎用言語のループ・条件・再利用可能なクラスを好む。AWS CDKはそれらのツールを提供しながら、デプロイエンジンとしてAWS CloudFormationを維持する。

AWS SAM（Serverless Application Model）

AWS SAMはサーバーレスアプリケーション向けに調整されたAWS CloudFormationのInfrastructure as Code拡張だ。AWS Lambda・Amazon API Gateway・Amazon DynamoDBのテンプレートをシンプルに書けるようにする。AWS SAMはデプロイ時にその省略記法を完全なAWS CloudFormationテンプレートに変換する。

AWS OpsWorks

AWS OpsWorksはChefとPuppet——2つのオープンソース構成管理ツール——をサポートするAWS構成管理サービスだ。AWS OpsWorksを使うと、命令的な設定レシピをAmazon EC2インスタンスに適用できる。CLF-C02ではAWS CloudFormationほど頻繁にはテストされないが、引っかけの選択肢として登場する。

CLF-C02試験では、以下のInfrastructure as Code AWSデプロイ方法を名前で知っていることが求められる：

  1. AWS CloudFormation — 宣言的なYAML/JSONテンプレート、基盤となるInfrastructure as Codeサービス。
  2. AWS CDK（Cloud Development Kit） — TypeScript・Python・Java・C#・GoでインフラをコードとしてAWS CloudFormationにコンパイルする。
  3. AWS SAM（Serverless Application Model） — サーバーレス（Lambda＋API Gateway＋DynamoDB）向けのAWS CloudFormationの省略記法。
  4. AWS OpsWorks — ChefとPuppetの構成管理。 「宣言的テンプレート」または「バージョン管理されたインフラ」という言葉があれば、答えはほぼ常にAWS CloudFormationだ。参照: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html

マネージドデプロイプラットフォーム：AWS Elastic Beanstalk

AWS Elastic Beanstalkはマネージドデプロイサービスで、アプリケーションコード（Java・.NET・PHP・Node.js・Python・Ruby・Go・Docker）を受け取り、周辺インフラを自動的にプロビジョニングする：Amazon EC2インスタンス・Elastic Load Balancer・Auto Scalingグループ・AWS CloudWatchモニタリング。AWS Elastic Beanstalkはサーバーではなくアプリを管理するため、「PaaSライク」と呼ばれることが多い。

CLF-C02向けのAWS Elastic Beanstalkの主要な特性：

  • コードをアップロードするだけで、AWS Elastic Beanstalkがデプロイを担当する。
  • プラットフォームを選択する（Python・Node.js・Dockerなど）と、AWS Elastic Beanstalkが対応するランタイムをプロビジョニングする。
  • 基盤となるAWSリソースに対する完全な制御を保持する——それらはAWSアカウントに表示され、検査または変更できる。
  • AWS Elastic Beanstalk自体に追加料金は発生しない——基盤となるAWSリソース（EC2・ELB・Auto Scaling）の料金のみ支払う。

AWS Elastic Beanstalkはデプロイ方法であり、コンピューティングサービスではない。 試験では以下を区別する：

  • コンピューティングサービス（タスク3.3）：Amazon EC2・AWS Lambda・Amazon ECS・Amazon EKS・AWS Fargate。
  • デプロイ方法（タスク3.1）：AWS CloudFormation・AWS CDK・AWS Elastic Beanstalk・AWS OpsWorks。

AWS Elastic Beanstalkは内部でAmazon EC2を使用するが、CLF-C02の試験ガイドではデプロイ方法として分類される。その価値はデプロイの自動化にあり、コンピューティングプリミティブではないからだ。

CLF-C02のシナリオ問題では、ワークロードの説明に合わせて適切なAWSデプロイ方法を選ぶことが頻繁に求められる。罠は間違った抽象化レベルを選ぶことだ：

  • 「開発者がサーバーを管理せずにウェブアプリをアップロードしたい」→ AWS Elastic Beanstalk（ウェブアプリ向けのプラットフォーム抽象化）。
  • 「チームがDockerコンテナを実行し、マネージドオーケストレーションを望んでいる」→ Amazon ECSまたはAmazon EKS（コンテナサービスであり、デプロイ方法ではない）。
  • 「ワークロードはイベント駆動で短いバーストで実行される」→ AWS Lambda（サーバーレスコンピューティング）。
  • 「チームがOSとインスタンスタイプを完全に制御したい」→ Amazon EC2（IaaSコンピューティング）。

AWS Elastic BeanstalkはこのリストでCLF-C02において公式にデプロイ方法としてタグ付けされている唯一の選択肢だ。他はタスク3.3のコンピューティングサービスである。「ウェブアプリケーションのデプロイ」または「コードをアップロードすればAWSがインフラを担当する」という表現があれば、答えはAWS Elastic Beanstalkだ。参照: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

AWS Systems Manager — 運用の自動化

AWS Systems Managerは、AWSデプロイ方法と並走するAWS運用サービスだ。リソースがデプロイされた後（AWS Management Console・AWS CLI・AWS SDK・AWS CloudFormation・AWS Elastic Beanstalkのいずれを通じてであっても）、AWS Systems Managerが継続的な運用を担う：パッチ適用・コマンド実行・パラメータ保管・セキュアなシェルライクアクセス。

CLF-C02でテストされるAWS Systems Managerのコア機能：

  • AWS Systems Manager Patch Manager — Amazon EC2インスタンスとハイブリッドオンプレミスサーバーのOSパッチ適用を自動化する。
  • AWS Systems Manager Run Command — SSHやRDPなしで、インスタンスフリート全体にコマンドを実行する。
  • AWS Systems Manager Parameter Store — 設定値とシークレットを保管する（プレーンテキストまたはKMS暗号化）。
  • AWS Systems Manager Session Manager — インバウンドポートを開けたりSSHキーを管理したりせずに、EC2インスタンスへのブラウザベースのシェルアクセスを提供する。
  • AWS Systems Manager State Manager — マネージドインスタンス全体に望ましい設定状態を適用する。
  • AWS Systems Manager Automation — 繰り返しの運用タスク向けのランブック形式のワークフロー。

AWS Systems ManagerはAWSデプロイ方法とDay-2運用を結ぶ接着剤だ。CLF-C02試験はAWS Systems Managerを運用AWSデプロイ方法として扱う。タスク3.1の「運用」の半分を担うからだ。

デプロイモデル：クラウドネイティブ・ハイブリッド・オンプレミス

CLF-C02はワークロードの所在を説明する3つのAWSデプロイモデルを定義している。

オールインクラウド（クラウドネイティブ）デプロイ

オールインクラウドとは、アプリケーションスタック全体の100%がAWS Regionsで動くことを意味する。顧客のデータセンターにサーバーは存在しない。これはスタートアップ・グリーンフィールドプロジェクト・モダナイズされたエンタープライズワークロードのデフォルトAWSデプロイモデルだ。オールインクラウドはAWSグローバルインフラの恩恵を最大化する：オートスケーリング・マルチAZの耐障害性・従量課金モデル・すべてのAWSサービスとの統合。

ハイブリッドデプロイ

ハイブリッドデプロイはオンプレミスのデータセンターをAWSに接続し、ワークロードが両方の場所にまたがるようにする。ハイブリッドは数年にわたるクラウド移行の途中にある企業、またはデータ主権・レイテンシー・ライセンス上の理由から一部をオンプレミスに残す必要があるワークロードで典型的だ。

ハイブリッドAWSデプロイ方法の3つの柱：

  1. AWS Direct Connect — データセンターからAWS Direct Connect拠点への専用プライベートファイバー。安定した低レイテンシー・高帯域幅（1 Gbps・10 Gbps・100 Gbpsのオプション）で、トラフィックは公共のインターネットを経由しない。安定した高スループットのハイブリッドワークロードに使用される。
  2. AWS Site-to-Site VPN — オンプレミスのVPNデバイスとAWS Virtual Private GatewayまたはAWS Transit Gatewayの間の公共インターネット経由の暗号化されたIPsecトンネル。設定が速く、Direct Connectよりコストが低いが、公共インターネットがトラフィックを運ぶためレイテンシーにばらつきがある。
  3. AWS Outposts — データセンターに物理的に設置されるAWS管理のサーバーラック。AWS Outpostsは、AWS Regionsのような体験を持つAWSサービス（EC2・EBS・RDS・ECS・EKS・S3 on Outposts）をオンプレミスに拡張し、ローカルコンピューティングをAWS APIとAWS Management Consoleから操作できるようにする。超低レイテンシー・データ主権・エアギャップのユースケースに使用される。

オンプレミスデプロイ

オンプレミスデプロイとは、ワークロードが顧客のデータセンター内で完全に動くが、一貫性のためにAWS互換ツール（AWS CloudFormationテンプレート・AWS CDKコンストラクト・AWS SDK統合・AWSコンテナイメージ）を使用することがある状態を指す。AWSのオンプレミスAWSデプロイ方法には、AWS Outposts・VMware Cloud on AWS・AWS Local Zones（大都市圏に近いエッジRegion）・Amazon ECS Anywhere / Amazon EKS Anywhere（自社ハードウェアでAWSコンテナオーケストレーションを実行する）が含まれる。

CLF-C02はDirect Connect vs Site-to-Site VPNのシナリオでハイブリッドAWSデプロイ方法をテストする：

  • AWS Direct Connect → 専用プライベートファイバー、安定した高帯域幅、公共インターネットを経由しない。「高スループット・安定したレイテンシー・厳格なセキュリティ」に最適。
  • AWS Site-to-Site VPN → 公共インターネット経由の暗号化トンネル、迅速な設定、低コスト。「迅速なハイブリッド接続」または「既存のインターネット経由の暗号化リンク」に最適。
  • AWS Outposts → データセンター内のAWSハードウェア。「AWS Regionsのサービスをオンプレミスで物理的に必要とする」または「データ主権・ローカル低レイテンシーコンピューティング」に最適。

CLF-C02にはこれら3つのハイブリッドAWSデプロイ方法のいずれかにシナリオをマッチングさせる問題が少なくとも1問登場すると予想される。参照: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

単発操作と繰り返し自動化プロセス

AWSデプロイ方法に対するCLF-C02の有用な視点は、単発操作と繰り返し自動化の違いだ。

単発操作とは、一度だけ行い、繰り返すことを期待せず、手動で安全に実施できるタスクだ。例：初期IAM管理者ユーザーの作成・AWS CloudTrail組織トレイルの有効化・新しいAWSサービスの探索。ここではAWS Management Consoleが適切だ。

繰り返し自動化プロセスとは、何度も繰り返され、多くのアカウントとAWS Regionsにわたることが多いタスクだ。例：フィーチャーブランチごとに新しい環境をプロビジョニングする・毎月IAM認証情報をローテーションする・1日50回マイクロサービスをデプロイする。ここではAWS CLI・AWS SDK・AWS CloudFormation・AWS CDK・AWS Systems Managerが適切だ。

CLF-C02試験は、繰り返されるものに対してAWS Management Consoleクリックよりも一貫してInfrastructure as Codeとプログラム的アクセスAWSデプロイ方法を選ぶ受験者に報いる。

API — すべてのAWSデプロイ方法の基盤

すべてのAWSデプロイ方法は最終的にAWSサービスAPI——署名されたリクエストを受け付けて構造化されたレスポンスを返すHTTPSエンドポイント——と通信する。AWS Management Console・AWS CLI・AWS SDK・AWS CloudFormation・AWS CDKはすべてAPIクライアントだ。

CLF-C02ではAPIエンドポイントや署名アルゴリズムの暗記は不要だ。知っておくべきことは：

  • すべてのAWSサービスはAPIを公開している。
  • AWS CLI・AWS SDK・AWS Management ConsoleはそれらのAPIのクライアントだ。
  • AWS CloudFormationはスタックを作成する際にこれらのAPIをユーザーの代わりに呼び出す。
  • AWS Identity and Access Management（IAM）は誰がどのリソースのどのAPIを呼び出せるかを制御する——これがAWSデプロイ方法がIAMと不可分である理由だ。

重要な数値と必須暗記事項

CLF-C02は基礎試験であり、深い数値のトリビアは避けているが、AWSデプロイ方法に関する数値はいくつかよく登場する：

  • 3つの主要アクセス方法: AWS Management Console・AWS CLI・AWS SDK。
  • 3つのデプロイモデル: クラウド（オールイン）・ハイブリッド・オンプレミス。
  • 2つのハイブリッドネットワークオプションとAWS Outposts: AWS Direct Connect・AWS Site-to-Site VPN・AWS Outposts。
  • AWS Direct Connectの帯域幅: 1 Gbps・10 Gbps・100 Gbps（ホスト接続は1 Gbps未満も利用可能）。
  • AWS CloudFormationテンプレート形式: YAMLとJSON。
  • AWS CDKサポート言語: TypeScript・JavaScript・Python・Java・C#・Go。
  • AWS SDKサポート言語（CLF-C02スコープ）: Python・JavaScript・Java・.NET・Go・Ruby・PHP・C++（さらにSwift・Kotlin・Rust）。
  • AWS Elastic Beanstalkサポートプラットフォーム: Java・.NET・PHP・Node.js・Python・Ruby・Go・Docker。
  • AWS Elastic Beanstalkの料金: AWS Elastic Beanstalk自体は0円。基盤となるEC2・ELB・EBSなどの料金のみ支払う。

よくある試験の罠 — 覚えておくべき落とし穴

罠1：「AWS Management Consoleは自動化をサポートする」

誤りだ。AWS Management ConsoleはブラウザGUIで人間が使うものだ。自動化にはAWS CLIまたはAWS SDKが必要だ。CLF-C02の問題で「チームはプロビジョニングを自動化する必要がある」と書かれていたら、回答リストからAWS Management Consoleを除外すること。

罠2：「AWS CloudFormationは命令的だ」

誤りだ。AWS CloudFormationは宣言的だ。望ましい状態を記述するだけで、順序はAWS CloudFormationが判断する。命令的なAWSデプロイ方法は、AWS CLIコマンドを上から下へ実行するbashスクリプトになる。

罠3：「AWS Elastic Beanstalkはコンピューティングサービスだ」

誤りだ。AWS Elastic Beanstalkはデプロイ方法だ。基盤となるコンピューティングサービスはAmazon EC2だ。CLF-C02タスク3.1がAWS Elastic Beanstalkをカバーし、タスク3.3がAmazon EC2を直接カバーする。

罠4：「AWS CDKはAWS CloudFormationを置き換える」

誤りだ。AWS CDKはAWS CloudFormationテンプレートを生成し、AWS CloudFormationをデプロイエンジンとして使用する。両者は補完的であり、競合ではない。

罠5：「Direct ConnectはVPNより常に優れている」

誤りだ。AWS Direct Connectは物理的なインストール（数週間のリードタイム）が必要で、AWS Site-to-Site VPNよりもコストが高い。迅速なハイブリッド接続や低帯域幅のニーズには、AWS Site-to-Site VPNが適切なAWSデプロイ方法だ。

罠6：「AWS OutpostsはDirect Connectの一形態だ」

誤りだ。AWS Outpostsはデータセンター内のAWSハードウェアであり、ネットワークリンクではない。AWS Outpostsを使う際にもAWS Direct ConnectをAWS Regionへのバックホール接続に組み合わせることは多いが、両者は別のサービスだ。

罠7：「AWS Systems Managerはデプロイ方法に過ぎない」

部分的に誤りだ。AWS Systems Managerは主に運用サービス（パッチ適用・Run Command・Parameter Store）だが、デプロイ後のDay-2運用を自動化するためにタスク3.1に含まれている。

デプロイ方法とコンピューティングサービス — スコープ境界（3.1 vs 3.3）

CLF-C02試験ガイドはタスク3.1（デプロイと運用方法）とタスク3.3（コンピューティングサービス）を分けている。境界は以下の通りだ：

タスク3.1（デプロイ）に属するもの タスク3.3（コンピューティング）に属するもの
AWS Management Console Amazon EC2
AWS CLI AWS Lambda
AWS SDK Amazon ECS
AWS CloudFormation Amazon EKS
AWS CDK AWS Fargate
AWS SAM Amazon Lightsail
AWS OpsWorks AWS Batch
AWS Elastic Beanstalk （内部はEC2だが、Beanstalk自体はデプロイ）
AWS Systems Manager
AWS Direct Connect
AWS Site-to-Site VPN
AWS Outposts

CLF-C02が「どのデプロイ方法を選ぶか？」と尋ねる場合、正解は左列にある。CLF-C02が「このワークロードを動かすコンピューティングサービスはどれか？」と尋ねる場合、正解は右列にある。この境界を意識することで、Elastic Beanstalk vs EC2 vs Lambdaの罠を防げる。

類似概念との比較：AWS CloudFormation vs Terraform vs AWS CDK

  • AWS CloudFormation: ネイティブAWSのInfrastructure as Code、YAML/JSON、宣言的、すべてのAWSサービスを最初にサポートする。
  • AWS CDK: 実際のプログラミング言語（TypeScript・Python・Javaなど）でAWS CloudFormationをラップする。
  • HashiCorp Terraform: サードパーティのマルチクラウドInfrastructure as Code。AWSサービスではない——CLF-C02の回答としてはスコープ外だが、引っかけの選択肢として登場することがある。AWSネイティブの正解は常にAWS CloudFormationまたはAWS CDKだ。

演習問題リンク — タスク3.1対応練習問題

このトピックを読んだ後、以下のパターンを練習しよう：

  • シナリオを適切なAWSデプロイ方法にマッチングする：Management Console・AWS CLI・AWS SDK・AWS CloudFormation・AWS CDK・AWS Elastic Beanstalk。
  • ハイブリッド接続についてAWS Direct Connect・AWS Site-to-Site VPN・AWS Outpostsの中から選ぶ。
  • どのサービスがデプロイ方法でどれがコンピューティングサービスかを識別する（タスク3.1 vs タスク3.3）。
  • Infrastructure as Code vs 手動クリックのワークフロー、どちらが正解かを認識する。

FAQ — デプロイと運用方法のよくある質問

Q1: CLF-C02でAWSデプロイ方法とやり取りする3つの主な方法は何か？

A: AWS Management Console（ブラウザGUI）・AWS CLI（コマンドラインスクリプト）・AWS SDK（言語ライブラリ）の3つだ。すべてが同じ基盤となるAWS API呼び出しを行うが、それぞれのワークフローが異なる：探索・自動化スクリプト・アプリ内統合である。

Q2: AWS Elastic BeanstalkはCLF-C02でコンピューティングサービスかデプロイ方法か？

A: AWS Elastic Beanstalkはタスク3.1でデプロイ方法として分類される。内部でAmazon EC2をプロビジョニングするが、試験ではマネージドデプロイプラットフォームとして評価される。基盤となるAmazon EC2はタスク3.3のコンピューティングサービスだ。

Q3: AWS CloudFormationとAWS CDKの違いは何か？

A: AWS CloudFormationはYAMLまたはJSONテンプレートを使用するネイティブの宣言的Infrastructure as Codeエンジンだ。AWS CDKを使うと、そのインフラを実際のプログラミング言語（TypeScript・Python・Java・C#・Go）で書き、AWS CloudFormationテンプレートに合成できる。AWS CDKはAWS CloudFormationを置き換えるのではなく、その上に乗っている。

Q4: ハイブリッドAWSデプロイ方法でAWS Direct ConnectとAWS Site-to-Site VPNのどちらを選ぶべきか？

A: 安定した高帯域幅・予測可能な低レイテンシー・公共インターネットを経由しないトラフィックが必要な場合はAWS Direct Connectを選ぶ——大規模なデータ量を移動するエンタープライズワークロードで典型的だ。迅速な設定・低コスト・既存のインターネット接続を使った暗号化接続が必要な場合はAWS Site-to-Site VPNを選ぶ。

Q5: AWS Management Consoleを自動化できるか？

A: できない。AWS Management Consoleは人間向けのブラウザインタフェースだ。自動化にはAWS CLI・AWS SDK・AWS CloudFormation・AWS CDKを使う。これはよくあるCLF-C02の罠だ：シナリオに自動化・スケジュールジョブ・繰り返しデプロイが書かれていたら、答えは常にプログラム的アクセス（AWS CLI・AWS SDK）またはInfrastructure as Code（AWS CloudFormation・AWS CDK）だ。

Q6: AWS Elastic Beanstalkは基盤となるリソース以外に追加コストがかかるか？

A: かからない。AWS Elastic Beanstalk自体に追加料金はない。代わりにプロビジョニングするAWSリソースの料金のみ支払う：Amazon EC2インスタンス・Elastic Load Balancer・Amazon EBSボリューム・Amazon CloudWatch。これにより、AWS Elastic BeanstalkはAmazon EC2を直接実行するのと比べてコスト中立なAWSデプロイ方法となる。

Q7: AWS OutpostsはハイブリッドかオンプレミスのAWSデプロイ方法か？

A: 表現によっては両方だ。AWS Outpostsは顧客のデータセンターに設置されるAWSハードウェアで、AWS Regionsのサービスをオンプレミスに拡張する。ハイブリッドアーキテクチャを可能にし（通常はAWS Direct Connectでリージョンへのバックホール接続と組み合わせる）、CLF-C02が「自社データセンターでAWSサービスを実行する」と表現する場合の主要なAWSネイティブの答えだ。

公式AWSドキュメント — さらに学ぶために

AWSデプロイ方法をマスターすることは、CLF-C02のドメイン3スコアを最も速く上げる方法だ。3つのアクセス方法（AWS Management Console・AWS CLI・AWS SDK）・2つの主要なInfrastructure as Codeツール（AWS CloudFormation・AWS CDK）・マネージドデプロイプラットフォーム（AWS Elastic Beanstalk）・運用サービス（AWS Systems Manager）・3つのデプロイモデル（クラウド・ハイブリッド・オンプレミス）を体に染み込ませること。タスクステートメント3.1のすべてのCLF-C02問題は、これらのリストから正しい項目を選ぶことに集約される。

公式ソース

その他の CLF-C02 トピック