概要

このカリキュラムについて

このカリキュラムは誰のためのもの？

この学習カリキュラムは、エンジニアとしてのスキルを高め、フリーランスとしても活躍できるレベルになりたいと考えている方向けです。

対象となる方：

AWSの基礎カリキュラム（ECサイト構築）を完了し、ALB・EC2・Auroraによる三層構造を理解している方
手作業でのインフラ構築に時間がかかることや、構築手順の属人化に課題を感じている方
インフラ構築を自動化し、再現性と効率性を向上させたい方
SESやSIerで働いていて、顧客への提案の幅を広げたいと考えている方
フリーランスとして活動する際に、インフラエンジニアリングスキルで差別化を図りたい方

何を学ぶカリキュラムなの？

このカリキュラムでは、IaC（Infrastructure as Code：コードによるインフラ構築） を使って、AWSのインフラをコードで管理する方法をゼロから学びます。具体的には、AWS CDK（Cloud Development Kit） というAWS公式のIaCツールを使って、VPC、ALB、ECS on Fargate、RDSなどのAWSリソースを、TypeScriptコードで定義し、自動的に構築・管理する技術を習得します。

このシステムを身近な例で説明すると、建築の設計図と3Dプリンターのようなものです。従来は、家（インフラ）を建てるとき、大工さん（エンジニア）が一つひとつ手作業で木材を組み立て、屋根を張り、壁を塗っていました。これは時間がかかり、大工さんによって仕上がりが異なることもありました。

IaCは、この建築プロセスを設計図（コード）として記述し、3Dプリンター（AWS CDK）で自動的に家を建てる仕組みです。一度設計図を作れば、何度でも同じ品質の家を、短時間で、どこにでも建てることができます。しかも、「窓を1つ追加したい」といった変更も、設計図を少し修正するだけで、すぐに反映できます。

現場で起こる典型的な課題を想像してください。新しいプロジェクトが始まり、コンテナ環境を構築することになりました。ベテランエンジニアが、AWSコンソールを開いて、VPCを作り、ECSクラスターを設定し、タスク定義を作り、ALBを構築し…という作業を5時間かけて行いました。その設定内容を、後輩エンジニアに口頭で説明しますが、細かい設定（タスク定義のCPU/メモリ、ヘルスチェック設定、セキュリティグループルールなど）は忘れてしまっています。

1ヶ月後、本番環境を構築する際、後輩エンジニアが担当することになりました。「開発環境と同じ構成で作ってください」と言われましたが、細かい設定がわからず、ベテランエンジニアに何度も質問。結局6時間かかり、それでもいくつかの設定が開発環境と異なっていることに後で気づきました。

IaCがあれば、このような状況を防げます。ベテランエンジニアが最初に設計図（AWS CDKコード）を作っておけば、後輩エンジニアは cdk deploy というコマンドを1回実行するだけで、全く同じ環境が10分で構築されます。しかも、設定内容はすべてTypeScriptコードに記述されているため、何がどう設定されているか一目瞭然です。

SESやSIerで働くエンジニアにとって、これは強力な武器になります。 顧客から「開発環境と本番環境で同じ構成にしたい」「コンテナ化したアプリケーションのインフラを構築したい」という相談を受けたとき、「AWS CDKを使えば、インフラ構築を自動化し、常に同じ品質のコンテナ環境を短時間で構築できます」と提案できるようになります。

このスキルは、月単価を15万円〜25万円引き上げることができる重要な技術です。なぜなら、多くの企業がインフラ構築の属人化や手作業のミスに課題を感じながらも、IaCの導入方法がわからず困っているからです。あなたがこの技術を提供できれば、企業にとって非常に価値の高いエンジニアとなります。

このカリキュラムを通じて、従来の手作業によるインフラ構築から脱却し、現代的なコードベースのインフラ管理技術を習得することができます。完成したシステムは、実際のスタートアップ企業や大企業が使用するレベルの本格的なIaC環境となります。

なぜIaC（Infrastructure as Code）を題材にしているの？

1. SES・SIerエンジニアの実務課題を直接解決できる

インフラ構築の現場では、手作業による非効率性や属人化が深刻な問題となっています。特に、コンテナ環境（ECS）や複数の環境（開発・ステージング・本番）を管理する必要がある現場では、これらの課題がプロジェクトの進行を大きく妨げます。

典型的な現場の課題：

新しいECS環境を構築するたびに、AWSコンソールで数十個のリソースを手作業で作成。設定ミスが頻発
「開発環境と本番環境で何が違うの？」という質問に答えられない。タスク定義やコンテナ設定がドキュメント化されていない
ベテランエンジニアしかECS環境構築ができず、その人が休むとプロジェクトが止まる
環境を削除する際、「どのリソースを削除すればいいのかわからない」状態になり、無駄なリソースが残り続けてコスト増加
設定変更の履歴が残らず、「誰がいつ何を変更したのか」がわからない

IaCがあれば：

AWS CDKコードを実行するだけで、数分で環境が構築される。人的ミスがゼロに
すべての設定がTypeScriptコードに記述されているため、「何がどう設定されているか」が一目瞭然
ジュニアエンジニアでも、コマンド1つで環境を構築できる。属人化が解消
cdk destroy コマンドで、関連リソースをすべて一括削除。無駄なコストが発生しない
GitでCDKコードを管理すれば、変更履歴がすべて記録される。「誰がいつ何を変更したか」が明確

フリーランスエンジニアとして、この課題解決スキルを持っていると、案件獲得において大きなアドバンテージがあります。多くの企業が「インフラの自動化・標準化」を課題として認識していながらも、実装できるエンジニアが不足しているためです。

2. 企業のコスト削減と効率化に直結する提案ができる

IaCの導入は、企業にとって明確なコスト削減効果と業務効率化をもたらします。これを数値で示せることが、フリーランスエンジニアとしての価値を高めます。

コスト削減効果の例（あくまで参考値）：

例えば、あるSIer企業のケースを見てみましょう。この企業では、新規プロジェクトのたびに開発・ステージング・本番の3環境（ECS on Fargate構成）を構築する必要がありました。

手動構築の場合、VPC・サブネット・ルートテーブルの設定から始まり、ECSクラスター・タスク定義、ALB・ターゲットグループ、セキュリティグループ・IAMロールの設定と進めていきます。さらに、設定確認・動作テスト、そしてドキュメント作成まで含めると、1環境あたり10〜15時間程度の工数がかかります。3環境を構築するとなると、この作業を3回繰り返すことになります。仮に年間10プロジェクトが発生し、エンジニアの時給を5,000円と仮定すると、手動構築では年間で数百時間、金額にして150万円〜200万円程度のコストが発生することになります。

一方、IaCを導入した場合はどうでしょうか。初回はAWS CDKでコードを作成するのに10時間程度かかりますが、一度コードを書いてしまえば、あとはcdk deployコマンドを実行するだけで10分程度で環境が立ち上がります。設定確認・動作テストも自動化されているため30分程度で完了します。さらに、2回目以降のプロジェクトでは、作成したコードを再利用できるため、工数はさらに短縮されます。同じく年間10プロジェクトで計算すると、IaC導入後は年間で数十時間、金額にして20万円〜40万円程度に削減できる可能性があります。

注意: 上記の数値は、あくまで一例です。実際の工数や削減効果は、企業の規模、エンジニアのスキルレベル、インフラの複雑さ、既存のプロセスなどによって大きく異なります。

さらに、設定ミスによるシステム障害やセキュリティインシデントのリスクも大幅に低減されます。例えば、セキュリティグループの設定ミスでコンテナが外部に公開されてしまった場合、情報漏洩のリスクだけでなく、対応コストや信用失墜のコストも発生します。

フリーランスとして顧客にこのような効果を提示する際は、その企業の実際の状況に基づいた試算を行うことで、IaC導入支援の案件獲得につながります。

3. AWS CDKを学ぶメリット：プログラミング言語でインフラを定義できる

AWS CDKは、TerraformやCloudFormationなどの従来のIaCツールとは異なり、TypeScript・Python・Javaなどのプログラミング言語でインフラを定義できます。これにより、通常のプログラミングと同じように、変数・関数・クラス・ループなどを使って、柔軟にインフラを構築できます。

AWS CDKの独自メリット：

従来のIaCツール（Terraform、CloudFormation）では、YAML や HCL という専用の設定ファイル形式を学ぶ必要がありました。これは、例えるなら、新しい外国語を学ぶようなものです。

AWS CDKでは、すでに慣れ親しんだプログラミング言語（TypeScript）を使うため、学習コストが大幅に低減されます。例えば：

従来のYAML/HCL（静的な設定ファイル）：

同じような設定を何度も書く必要がある（DRY原則に反する）
条件分岐やループが書きにくい
IDEの補完機能が限定的
テストが困難

AWS CDK（TypeScriptなどのプログラミング言語）：

関数化・クラス化で再利用性が高い（DRY原則に従える）
if文、for文などの制御構文が自由に使える
TypeScriptの型チェックとIDEの強力な補完機能
Jest等のテストフレームワークで自動テストが可能

例えば、「開発・ステージング・本番の3環境を作りたい」という場合：

従来のツール：同じような設定ファイルを3つコピペして作成 AWS CDK：cdk.context.jsonで環境設定を管理し、複数環境を効率的にデプロイできる

AWS CDKでは、環境ごとの設定をcdk.context.jsonファイルで管理するのが推奨されています。


{
  "environments": [
    {
      "name": "dev",
      "account": "123456789012",
      "region": "ap-northeast-1",
      "minCapacity": 1,
      "maxCapacity": 2
    },
    {
      "name": "stg",
      "account": "123456789012",
      "region": "ap-northeast-1",
      "minCapacity": 2,
      "maxCapacity": 4
    },
    {
      "name": "prod",
      "account": "987654321098",
      "region": "ap-northeast-1",
      "minCapacity": 4,
      "maxCapacity": 10
    }
  ]
}

CDKコードでは、このコンテキスト値を読み込んで使用します：


const environments = app.node.tryGetContext('environments');
environments.forEach((env: any) => {
  new EcsStack(app, `EcsStack-${env.name}`, {
    env: {
      account: env.account,
      region: env.region
    },
    minCapacity: env.minCapacity,
    maxCapacity: env.maxCapacity
  });
});

この方法により、環境ごとの設定をコードから分離し、環境差分を管理しやすくなります。

参考資料: Scheduled scaling of Amazon Aurora Serverless with Amazon EventBridge Scheduler - AWS公式ブログで、cdk.context.jsonを使った設定管理の実例が紹介されています。

この柔軟性により、複雑なインフラ構成も簡潔に記述でき、保守性が大幅に向上します。

4. 段階的に成果を実感しながら学習できる

このカリキュラムは、基礎カリキュラムで手作業で構築したEC2ベースのインフラを、AWS CDKでコンテナ化されたECS環境に進化させていきます。各ステップで具体的なインフラリソースがコード化されるため、学習の達成感を感じながら進めることができます。

段階的な成果の実感：

ステップ1（AWS CDKの基礎とVPC構築）：AWS CDKの基本的な使い方を学び、VPCをTypeScriptコードで構築します。手作業で30分かかっていた作業が、コマンド1つで完了する体験をします
ステップ2（ECSクラスターとALBの構築）：ECS on FargateクラスターとALBをコードで管理し、コンテナ環境の「再現性」を実感します
ステップ3（コンテナアプリケーションのデプロイ）：タスク定義とサービスをコードで構築し、実際のコンテナアプリケーションがECS上で動作する様子を確認します
ステップ4（RDSとの統合、環境分離）：RDSデータベースをコードで追加し、dev/stg/prodの複数環境を効率的に管理する方法を学びます
ステップ5（CI/CD統合の準備とベストプラクティス）：CDKコードをGitHubで管理し、次のCI/CDカリキュラムに向けた統合準備を行います

Tip

【解説】AWS CDK vs Terraform - プロジェクトに適したIaCツールの選択

Infrastructure as Code（IaC）ツールを選択する際、AWS CDKとTerraformはどちらも優れた選択肢ですが、それぞれ異なる強みと特性を持っています。AWS Prescriptive Guidanceによると、この選択は組織の目標や開発者のスキルセットに合わせた戦略的な決定となります。

AWS CDKは、TypeScript、Python、Java、C#、Goなどの一般的なプログラミング言語でインフラを定義できるオープンソースフレームワークです。最大の特徴は、開発者が慣れ親しんだプログラミング言語を使用できることで、変数、関数、クラス、ループなどの制御構文を自由に活用できます。AWS公式ツールであるため、CloudFormationをベースとしており、AWSの最新機能をリリースと同時に利用できる点も大きな利点です。さらに、L2/L3 Constructsと呼ばれる高レベルな抽象化により、複雑なインフラ構成を少ないコードで表現でき、Jestなどのテストフレームワークでユニットテストやスナップショットテストも実行できます。Thomson Reutersの事例では、AWS CDKを活用することで、標準化、ガバナンス強化、開発スピード向上を同時に実現しています。

一方、TerraformはHashiCorp社が開発したマルチクラウド対応のIaCツールで、AWS、Azure、GCP、オンプレミス環境など、4000以上のプロバイダーをサポートしています。HCL（HashiCorp Configuration Language）という宣言的な言語でインフラの「あるべき姿」を記述するため、YAML/JSONに慣れている方には学習しやすい特徴があります。Terraform Registryには豊富な公開モジュールが存在し、成熟したエコシステムが形成されています。ただし、AWSの新機能がリリースされた際には、Terraformプロバイダーの更新を待つ必要があり、terraform.tfstateファイルの状態管理が必要になります。

選択の基準として、AWS専用のプロジェクトでプログラミングスキルの高いチームがいる場合、またはテスト駆動開発でインフラを管理したい場合はAWS CDKが適しています。一方、マルチクラウド環境や既存のTerraform資産を活用したい場合、またはシンプルな宣言的記述を好む場合はTerraformが適切です。このTENARAI Blueprintでは、AWS専用環境でCI/CDとの統合を重視するため、AWS CDKを採用しています。

参考資料：

学習を始める前に

このプログラムは実践的な内容になっているため、手を動かしながら学習することが重要です。理論だけでなく、実際にAWS CDKコードを書き、AWSインフラを構築して、自分の手でIaC環境を作り上げてください。

学習を効果的に進めるためのコツ：

学習を効果的に進めるためには、基礎カリキュラムで学んだ知識を積極的に活用しましょう。基礎カリキュラムで手作業で構築したECサイトのインフラを、このカリキュラムではコンテナ化してコード化していきます。最初から完璧なCDKコードを目指すのではなく、まずは簡単なリソース（VPC、サブネット）から始めて、徐々に複雑なリソースに挑戦していくのがおすすめです。

AWS CDKを使う際には、cdk deployの前に必ずcdk diffを実行し、何が作成・変更・削除されるかを確認する習慣をつけることが大切です。TypeScriptの型システムとIDEの補完機能を最大限に活用することで、タイポやミスを防ぐことができます。また、AWS CDKの公式ドキュメントは非常に充実しているため、わからないことがあれば、まず公式ドキュメントを確認する習慣をつけましょう。

準備しておくもの：

AWSアカウント
Node.js（v18以上）とnpm：AWS CDKの実行に必要です
AWS CLI：AWS認証情報の設定に使用します
GitHubアカウント：CDKコードをバージョン管理するために使用します
TypeScript対応のエディタ：VS CodeやIntelliJ IDEAなどを推奨します
Dockerの基礎知識：コンテナ化されたアプリケーションを理解するために役立ちます

最初は難しく感じるかもしれませんが、ステップごとに丁寧に説明しますので、安心して学習を進めてください。完了する頃には、自信を持って「AWS CDKを使ってAWSインフラをコードで管理できます」と言えるようになるはずです。

学習完了後のあなたは：

インフラエンジニアとして、高単価のフリーランス案件を獲得できるスキルと実績を持つ
IaC導入支援案件で、企業のインフラ構築効率化とコスト削減を実現できる
次のCI/CDカリキュラムで、このECS環境を使ったCI/CDパイプラインを構築できる