デプロイ戦略の重要性​

現代のソフトウェア開発において、デプロイの方法は様々です。開発しているソフトウェアの特性や業界によっても、最適なデプロイ戦略は異なります。

最も原始的な方法は、開発した機能を特に深く考えずにステージング環境や本番環境に直接反映することです。この方式でも追加機能や修正機能はユーザーが利用可能になりますが、もし修正に致命的な不具合がある場合、ユーザー全体に影響が及ぶことになります。ロールバックには人間の手が必要になり、迅速に作業を行える保証はどこにもありません。

ただし、修正を直接反映しなければいけないような業界のシステムでは、直接反映が有効な戦略となる場合もあります。

より現代的なデプロイ戦略としては、カナリアデプロイとリニアデプロイがあります。これらのデプロイ戦略は、デプロイ時の不具合などによるデータ汚染のリスクを減らすために用いられます。

カナリアデプロイとは​

カナリアデプロイは、デプロイ後にアプリケーションに対する全てのトラフィックを最新バージョンに流すのではなく、開発者が指定した少数の割合（例: 10%）のトラフィックのみを最新バージョンに流し、最新バージョンで発生したメトリクスを分析しながら段階的に展開する方式です。

カナリアデプロイの仕組み​

カナリアデプロイでは、2つのバージョンのアプリケーションが同時に稼働します。旧バージョンを「安定版」、新バージョンを「カナリア」と呼びます。

カナリアデプロイにおける最新バージョンへのトラフィック分散には、開発者が指定する重み（トラフィックの割合）が重要になります。この重みに応じて時間経過でトラフィックを分散しながらユーザーに展開されていきます。

カナリアデプロイの展開フロー​

典型的なカナリアデプロイの展開フローは以下の通りです:

1. 初めは、全てのトラフィックが現行バージョンへ送られる
2. 新バージョンを少数のユーザー（例: 5%）に公開
3. 新バージョンに対してスモークテストなどを実施
4. 問題がなければ、段階的にトラフィックを増加（5% → 25% → 50% → 75% → 100%）
5. 問題が発生した場合は、直ちに旧バージョンへロールバック
6. 新バージョンが全トラフィックを受けた時点で、旧バージョンを削除

カナリアデプロイの実装方法​

カナリアデプロイには、主に2つの実装方法があります。

サイドバイサイドデプロイ​

新バージョンを既存環境とは別の新しい環境に展開する方法です。

1. 既存環境（安定版）とは別に、新しい環境（カナリア版）を構築
2. ロードバランサやリバースプロキシを使用して、一部のトラフィックをカナリア版に振り分け
3. 段階的にトラフィックを増やし、問題がなければ最終的に全トラフィックを新環境へ移行
4. 旧環境を廃止

この方法は、データベースや複数のサービスを含む複雑なアプリケーションに適していますが、追加のインフラリソースが必要になります。

ローリングデプロイ​

既存のサーバーやコンテナを段階的に更新する方法です。

1. 複数のサーバーのうち、1台または少数のサーバーを新バージョンに更新
2. 更新したサーバーの動作を監視し、エラーや性能問題がないか確認
3. 問題がなければ、他のサーバーも順次更新
4. 問題が発生した場合は、更新したサーバーを旧バージョンに戻す

この方法は、追加のインフラが不要で、比較的シンプルに実装できます。

カナリアデプロイの特徴​

重みによってはリリースが完全にユーザーに展開されるまで時間がかかる場合がありますが、より重要な機能をリリースする際にリスクを減らしたい場合には有効です。

リニアデプロイとは​

リニアデプロイはカナリアデプロイとは異なり、一定のインターバルでトラフィックを段階的に切り替えるデプロイ戦略です。

リニアデプロイの仕組み​

例えば、開発者がデプロイ時に「2分ごとに10%」という定義でリニアデプロイを実行すると、2分毎に10%のユーザーが最新バージョンに流れるようになります。これは100%になるまで段階的に行われます。

リニアデプロイの設定パラメータ​

リニアデプロイでは、以下のパラメータを設定します:

• ステップの割合: 各ステップでどの程度トラフィックを切り替えるか（例: 10%）
• ステップベイク時間: 切り替えの間にモニタリングや検証を行うための待機時間
• デプロイベイク時間: すべてのトラフィックを新しいリビジョンに切り替えた後、旧リビジョンを終了するまでの待機時間

リニアデプロイの特徴​

カナリアデプロイとは違い、リニアデプロイは線形であり、重みがないため、定義によってはカナリアデプロイより早い時間で全ユーザーに新機能が展開されやすい特徴があります。そのため、リニアデプロイを使用する場合は、リスクを抑えながらもより安定した機能のリリースに使用するといいでしょう。

カナリアデプロイとリニアデプロイの比較​

両者の違いを視覚的に比較すると、以下のようになります:

ブルーグリーンデプロイとの違い​

カナリアデプロイやリニアデプロイと似た戦略として、ブルーグリーンデプロイがあります。

ブルーグリーンデプロイとは​

ブルーグリーンデプロイは、均等なリソースを持つ2つの環境（ブルーとグリーン）を用意し、全ユーザーを一度に切り替えるデプロイ戦略です。

3つのデプロイ戦略の比較​

使い分けの指針​

カナリアデプロイを選ぶべき場合:

• 新バージョンに対する信頼度が不明確
• 性能やスケールに関する懸念が大きい
• 大幅なアップデートや全く新しい機能の追加
• 本番環境で新機能を低リスクでテストしたい

リニアデプロイを選ぶべき場合:

• 更新版に対する信頼が高く、十分なテストが完了
• 短時間で安全にイテレーションを重ねたい
• リスクを抑えながらも、比較的速く展開したい

ブルーグリーンデプロイを選ぶべき場合:

• 更新版に対する信頼が非常に高い
• ダウンタイムを完全になくしたい
• 全ユーザーを一度に切り替える必要がある
• 問題発生時に即座に旧バージョンへ戻せる環境が必要

段階的デプロイ戦略が適切ではないケース​

カナリアデプロイ、リニアデプロイ、ブルーグリーンデプロイなどの段階的デプロイ戦略は、以下の場合には利用を避けるべきです:

• 障害が大きな経済的影響を及ぼす場合: 銀行システムや金融取引システムなど、一部のユーザーでも障害が発生すると重大な損失につながる
• 遠隔更新ができない場合: ユーザーのPC上のソフトウェアやスタンドアロンアプリケーションなど、サーバー側で制御できない環境
• 継続的デプロイが禁止されている分野: 航空宇宙や医療機器など、厳格な認証プロセスが必要で段階的リリースが許可されていない
• データベースの大幅な変更: スキーマ変更やデータ移行を伴う場合、新旧バージョンの同時稼働が困難
• 生命維持や重要ミッションのシステム: 電力網、原子炉制御システム、医療機器など、部分的な障害も許容できない

これらの場合は、より慎重なデプロイ戦略や、厳格なテストプロセス、メンテナンスウィンドウを設けた一括デプロイが必要になります。

まとめ​

この記事では、カナリアデプロイとリニアデプロイという2つの現代的なデプロイ戦略について解説しました。

カナリアデプロイは重みベースで段階的にトラフィックを増加させる方式で、メトリクス分析を行いながら慎重に展開します。サイドバイサイドデプロイとローリングデプロイの2つの実装方法があり、重要な機能や大規模な変更に適しています。

リニアデプロイは時間ベースで一定間隔でトラフィックを切り替える方式で、予測可能な展開スケジュールが特徴です。十分にテストされた安定した機能のリリースに適しており、カナリアデプロイよりも速く展開できます。

また、ブルーグリーンデプロイとの違いについても説明しました。ブルーグリーンデプロイは全ユーザーを一度に切り替える方式で、ダウンタイムをなくすことが主な目的です。一方、カナリアデプロイとリニアデプロイは、本番環境で新機能を低リスクでテストすることが目的です。

段階的デプロイ戦略は、デプロイ時のリスクを大幅に軽減できる強力な手法ですが、金融システムや医療機器など、部分的な障害も許容できない分野では利用できません。アプリケーションのリスク許容度、検証要件、業界の規制に応じて、最適なデプロイ戦略を選択してください。

参考リンク:

• Amazon ECS でリニアデプロイとカナリアデプロイが標準機能としてサポート開始
• カナリアデプロイとは ― 意味と戦略 | Wallarm
• Amazon ECS のリニアデプロイおよびカナリアデプロイに関するドキュメント

ルートユーザーのセキュリティ対策​

AWSアカウントを作成すると、登録メールアドレスとパスワードの組み合わせで認証するルートユーザーが作成されます。ルートユーザーはAWSの全リソースに対するフルアクセス権限を持ち、請求情報や個人情報といった機微な情報にもアクセスできます。

この強力な権限を持つルートユーザーは、作成後は極力使用せず、以下の手順でロックダウンすることがAWSのベストプラクティスとして推奨されています。

1. 予測が困難な強力なパスワードを設定する
2. ルートユーザーの認証情報はパスワードマネージャーに保存し共有しない
3. MFA（多要素認証）を有効化する
4. CLI等で使用するために発行したアクセスキーがある場合は削除する
5. 管理者権限をアタッチしたIAMユーザーを作成し、以降はそのIAMユーザーで作業を行う

IAMとは​

IAM（Identity and Access Management）は、AWSリソースへのアクセスをポリシーベースで管理するサービスです。「誰が」「どのリソースに対して」「どのアクションを」実行できるかを細かく制御できます。

AWSにおいては最小権限の原則での運用がベストプラクティスとして推奨されています。必要最小限の権限のみを付与することで、ヒューマンエラーやセキュリティインシデントのリスクを低減できます。

IAMは以下の4つの構成要素で成り立っています。

ポリシー​

ポリシーは、特定のAWSリソースに対するアクセス権限を定義するJSONドキュメントです。個々のAWSサービスの個々のアクションに対して、許可（Allow）または拒否（Deny）を指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

ポリシーにはAWSが事前に作成したAWS管理ポリシーが多く用意されていますが、ユースケースによってはAWS管理ポリシーが必要以上に広い権限を持つ場合があります。そのような場合は、より制限の厳しいカスタム管理ポリシーを作成することが推奨されます。

IAMユーザー​

IAMユーザーは、ルートユーザーのアカウント内に作成する仮想ユーザーです。個々の作業者や用途ごとに作成します。

IAMユーザーの特徴は以下の通りです。

• 作成時点では一切のアクセス権限がない（明示的にポリシーをアタッチする必要がある）
• デフォルトではマネジメントコンソールへのアクセスが許可されていない（必要に応じて有効化する）
• IAMユーザーへの直接的なポリシーのアタッチは非推奨（後述するユーザーグループ経由が推奨）

ユーザーグループ​

ユーザーグループは、単数または複数のIAMユーザーの集合です。ユーザーグループにポリシーをアタッチすると、そのグループに所属するすべてのIAMユーザーにポリシーが伝播します。

ユーザーグループ経由の権限管理が推奨される理由は以下の通りです。

• 担当や部門ごとにグループを作成し、必要最小限のポリシーをアタッチできる
• 担当変更時はIAMユーザーのグループ所属を変更するだけで権限が切り替わる
• 個々のIAMユーザーに直接ポリシーを管理する必要がなくなる

ロール​

ロールは、AWSリソース同士のアクション許可や、IAMユーザーへの一時的な権限付与に使用します。

AWSリソースは、そのリソースを作成したIAMユーザーの権限に関係なく、デフォルトでは他のAWSリソースへのアクセス権を一切持ちません。例えば、Lambda関数からS3バケットにアクセスする場合、Lambda関数に対してS3へのアクセスを許可するロールを明示的にアタッチする必要があります。

このように、AWSでは最小権限の原則を徹底するために、AWSリソースはデフォルトで他のリソースへのアクセス権を持たない設計になっています。

また、IAMユーザーに本来のポリシーとは異なる一時的な作業が必要になった場合に、ロールを使って一時的に権限を付与することも可能です。

AWSの全操作はAPIコール​

AWSの全サービスがポリシーベースのアクセス許可を前提としている背景には、AWSにおけるすべての操作がAPIコールで行われているという仕組みがあります。IAMユーザーがマネジメントコンソールで操作を行った場合も、バックグラウンドではCLIと同様のAPIコールが実行され、ポリシーに基づいた認可処理が行われています。AWSリソース同士のアクションにおいても同様です。

使用されていないIAMユーザーの管理​

不要になったIAMユーザーに対しては、以下の措置を講じてセキュリティリスクを低減します。

• 権限の剥奪（ポリシーのデタッチ、ユーザーグループからの削除）
• アクセスキーの削除
• マネジメントコンソールへのアクセス無効化
• 不要であればIAMユーザーの削除

まとめ​

この記事では、AWSにおけるIAMと最小権限の原則について解説しました。ルートユーザーのロックダウンを行った上で、IAMの4つの構成要素（ポリシー、IAMユーザー、ユーザーグループ、ロール）を組み合わせて、必要最小限の権限のみを付与する運用がAWSのベストプラクティスです。ポリシーはユーザーグループ経由でIAMユーザーに適用し、AWSリソース同士のアクセスにはロールを使用することで、セキュアで管理しやすいアクセス制御を実現できます。

参考リンク:

• AWS IAM公式ページ
• IAMベストプラクティス
• 最小権限の原則への体系的アプローチ
• AWS CloudTrail

AWS Control Towerとは​

AWS Control Towerは、AWS Organizationsと連携してマルチアカウント環境のガバナンスを自動化・標準化するサービスです。組織の規模が拡大しAWSアカウントが増えてくると、個々のアカウントがセキュリティやコンプライアンスなどのガバナンスルールに準拠しているかを一元的に統制する必要があります。

AWS Control Towerは、この課題に対して以下の機能を提供します。

• 事前設定したアカウントテンプレートによる一貫性のあるAWSアカウント作成の自動化
• コントロール（ガードレール）によるポリシーの適用
• ダッシュボードによるコンプライアンスの継続的なモニタリング

ランディングゾーン​

ランディングゾーンは、AWS Control Towerによって自動構成されるマルチアカウント環境の基盤です。ランディングゾーンには、セキュリティやログ管理のためのアカウント、OU構成、基本的なコントロールが含まれており、ベストプラクティスに基づいたマルチアカウント環境が自動的にセットアップされます。

ランディングゾーンの主な構成要素は以下の通りです。

コントロール（ガードレール）​

コントロールは、ランディングゾーン内のAWSアカウントに対してガバナンスルールを適用する機能です。コントロールには予防コントロールと検出コントロールの2種類があります。

予防コントロール​

予防コントロールは、ガバナンスルールに違反する操作を事前に防止するコントロールです。SCPを使用して実装されており、非準拠の操作が実行される前にブロックします。

例: S3バケットのパブリックアクセスを禁止、特定リージョン以外でのリソース作成を禁止

検出コントロール​

検出コントロールは、ガバナンスルールに違反する状態を検出するコントロールです。AWS Configルールを使用して実装されており、非準拠のリソースが存在する場合にアラートを発生させます。

例: MFAが有効になっていないIAMユーザーの検出、暗号化されていないEBSボリュームの検出

ダッシュボード​

AWS Control Towerのダッシュボードでは、ランディングゾーン内のすべてのAWSアカウントのコンプライアンス状態を一元的に確認できます。ポリシー違反のアカウントが存在する場合はフィルタリングによる検知が可能で、非準拠の項目に対して必要なコントロールを追加適用することもできます。

まとめ​

この記事では、AWS Control Towerの基本的な仕組みについて解説しました。AWS Control Towerは、ランディングゾーンによる標準化されたマルチアカウント環境の構築、予防・検出コントロールによるガバナンスルールの適用、ダッシュボードによるコンプライアンスの継続的な監視を提供するサービスです。AWS Organizationsと組み合わせることで、組織のガバナンスルールに準拠したアカウント管理を自動化できます。

参考リンク:

• AWS Control Tower公式ドキュメント
• ランディングゾーンの計画

ソフトウェアライセンス管理の課題​

個人の開発環境ではあまり意識されることが少ないソフトウェアライセンスですが、商用利用や企業でのAWS利用においてはライセンス管理は不可欠な項目です。

従来のライセンス管理には以下のような課題があります。

AWS License Managerとは​

AWS License Managerは、AWSリソースで使用するソフトウェアライセンスの管理を自動化するサービスです。ライセンスルールの定義、使用状況の追跡、制限の適用を一元的に行えます。

License Managerの主な機能​

ライセンス設定の作成​

License Managerでは、ソフトウェアのライセンス条件に基づいたライセンス設定（License Configuration）を作成できます。ライセンス設定には以下のようなパラメータを定義します。

使用状況の追跡​

License Managerのダッシュボードでは、ライセンスの使用状況をリアルタイムに追跡できます。どのAWSリソースがどのライセンスを使用しているかを可視化し、ライセンスの過不足を把握できます。

制限の適用​

ライセンスルールにハードリミットを設定することで、上限に達した場合に新しいAWSリソースの起動を自動的にブロックできます。これにより、ライセンス違反を未然に防ぐことが可能です。

AWS Organizationsとの連携​

AWS License ManagerはAWS Organizationsと連携することで、組織全体のライセンスを一元管理できます。管理アカウントでライセンス設定を作成し、メンバーアカウント全体に適用することで、組織横断的なライセンスコンプライアンスを実現します。

まとめ​

この記事では、AWS License Managerの基本的な仕組みについて解説しました。AWS License Managerは、ソフトウェアライセンスのルール定義、使用状況の追跡、制限の適用を自動化するサービスです。従来のExcelやデータベースによる手動管理と比較して、ヒューマンエラーの防止、リアルタイムの使用状況把握、上限超過時の自動制限により、ライセンスコンプライアンスを効率的に確保できます。

参考リンク:

• AWS License Manager公式ページ
• AWS License Manager公式ドキュメント

AWS Organizationsとは​

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。ルートとなる単一の管理アカウント（メインアカウント）に、複数のメンバーアカウントを紐づける形式で組織を構成します。

OU（組織単位）​

OU（Organizational Unit）は、メンバーアカウントをグループ化するための単位です。企業であれば部門ごと、プロジェクトであれば環境ごと（開発・ステージング・本番）にOUを作成し、その下にメンバーアカウントを配置できます。

OUの主な特徴は以下の通りです。

• OUは階層構造を持ち、OU内にさらにOUをネストすることが可能
• メンバーアカウントは1つのOUにのみ所属できる
• OUに所属せず、直接管理アカウントにメンバーアカウントを紐づけることも可能

SCP（サービスコントロールポリシー）​

SCP（Service Control Policy）は、AWS Organizations内でのリソースへのアクセス制御を行うためのポリシーです。OU単位またはメンバーアカウント単位で適用でき、対象のアカウントで利用可能なAWSサービスやアクションを制限します。

SCPの主なポイントは以下の通りです。

• SCPはOU単位での設定が可能で、OUに属するすべてのメンバーアカウントに適用される
• メンバーアカウント単位での個別設定も可能
• SCPで制限されたアクションは、メンバーアカウント内のIAMポリシーで許可されていても実行できない
• 管理アカウント自体にはSCPは適用されない

メンバーアカウントとIAMの関係​

AWS Organizationsにおけるメンバーアカウントは、IAMユーザーとは異なる概念です。メンバーアカウントはそれぞれ固有のAWSアカウント（アカウントIDを持つ独立したアカウント）であり、各メンバーアカウント内で独自のIAMユーザー、グループ、ロールを管理できます。

管理アカウントや権限のあるアカウントから、IAMの権限グループやロールを各メンバーアカウントに付与することも可能です。SCPとIAMを組み合わせることで、きめ細かい権限管理が実現できます。

請求の一元管理​

AWS Organizationsでは、個々のメンバーアカウントで発生した利用料金がルートの管理アカウントの請求に一元化されます。これにより、組織全体のAWS利用コストを単一の請求書で把握できます。

まとめ​

この記事では、AWS Organizationsの基本的な仕組みについて解説しました。AWS Organizationsは、管理アカウントを中心に複数のメンバーアカウントをOU（組織単位）でグループ化し、SCP（サービスコントロールポリシー）でアクセス制御を行い、請求を一元管理するサービスです。IAMポリシーとSCPを組み合わせることで、組織のガバナンスルールに準拠したアカウント管理が可能になります。

参考リンク:

• AWS Organizations公式ページ
• AWS Organizations公式ドキュメント
• サービスコントロールポリシー（SCP）

組織におけるAWSリソース管理の課題​

組織でAWSを使って開発や運用を行う際に、個々のメンバーが独自にAWSリソースを作成・設定できる状態は、以下のリスクを伴います。

これらの問題に対応するために、AWSではAWS Service Catalogが提供されています。

AWS Service Catalogとは​

AWS Service Catalogは、組織がAWS CloudFormationテンプレートを使用して事前に作成した標準化されたリソース構成を、サービスカタログとして組織のメンバーに提供するサービスです。

メンバーはサービスカタログから承認済みのリソース構成を選択してプロビジョニングするため、ガバナンスルールに準拠したリソースのみが作成されます。

Service Catalogの構成要素​

ポートフォリオ​

ポートフォリオは、関連する製品（CloudFormationテンプレート）をグループ化するコンテナです。部門やチーム、ユースケースごとにポートフォリオを作成し、適切なメンバーやOUに共有します。

製品​

製品は、CloudFormationテンプレートとして定義された具体的なリソース構成です。例えば、「標準Webアプリケーション構成」「セキュアデータベース構成」など、ガバナンスルールに準拠した構成をテンプレートとして登録します。

制約​

制約は、メンバーが製品をプロビジョニングする際に適用される追加のルールです。起動制約（どのIAMロールで起動するか）、テンプレート制約（パラメータの選択肢を制限する）などを設定できます。

Service Catalogの利点​

CloudFormationテンプレートの基本については、IaC（Infrastructure as Code）とAWS CloudFormationで解説しています。

まとめ​

この記事では、AWS Service Catalogの基本的な仕組みについて解説しました。AWS Service Catalogは、CloudFormationテンプレートをサービスカタログとして組織のメンバーに提供し、ガバナンスルールに準拠した標準化されたAWSリソースの展開を実現するサービスです。メンバーはカタログから承認済みの構成を選択してプロビジョニングするため、ガバナンスからの逸脱防止と環境の一貫性の確保、開発効率の向上が期待できます。

参考リンク:

• AWS Service Catalog公式ドキュメント
• AWS CloudFormation公式ドキュメント

Amazon VPCとは​

Amazon VPC（Virtual Private Cloud）は、AWSクラウド内に論理的に分離された仮想ネットワークをプロビジョニングするサービスです。VPC内で定義したネットワーク空間にAWSリソースを配置し、外部との通信を制御できます。

VPCはAWSクラウドにおける自分専用のネットワーク空間であり、外部との境界線として機能します。VPC内のリソースには、自分で定義したゲートウェイを通じてのみアクセスが可能です。

サブネット​

VPC内にはサブネットと呼ばれるIPアドレスの範囲を定義し、リソースをグループ化します。サブネットにはパブリックサブネットとプライベートサブネットの2種類があります。

パブリックサブネット​

パブリックサブネットは、インターネットとの通信が可能なサブネットです。インターネットゲートウェイへのルーティングが設定されており、外部からのアクセスを受け付けるリソースを配置します。

主な用途:

• Webサーバー（EC2インスタンス）
• ロードバランサー（ALB / NLB）
• NAT Gateway（プライベートサブネットからインターネットへの通信用）

プライベートサブネット​

プライベートサブネットは、インターネットからの直接アクセスができないサブネットです。外部からのアクセスが想定されない、機密性の高いリソースを配置します。

主な用途:

• データベース（RDS、DynamoDB VPCエンドポイント経由）
• アプリケーションサーバー
• 内部向けのバッチ処理サーバー

VPCへの接続方式​

VPC内のリソースへアクセスする方法は、リソースの公開範囲によって異なります。

インターネットゲートウェイ​

顧客向けのWebサイトなど、パブリックにアクセスされるリソースがある場合は、VPCにインターネットゲートウェイをアタッチします。インターネットゲートウェイはVPCとインターネット間の通信を仲介するゲートウェイです。

VPN接続（仮想プライベートゲートウェイ）​

インターネット経由のパブリックアクセスではなく、プライベートな経路でVPCに接続する場合は、仮想プライベートゲートウェイをVPCにアタッチし、AWS VPN経由で接続します。VPN接続はインターネット上に暗号化されたトンネルを構築し、オンプレミス環境からVPCへの安全な通信を実現します。

Amazon Direct Connect​

Amazon Direct Connectは、オンプレミス環境とAWSの間に物理的な専用回線を敷設するサービスです。VPN接続と同様に仮想プライベートゲートウェイを使用しますが、インターネットを経由せず専用の物理回線を使用します。

VPNとDirect Connectの比較​

まとめ​

この記事では、Amazon VPCの基本概念として、サブネット（パブリック・プライベート）によるリソースの分離、インターネットゲートウェイによるパブリックアクセス、VPNとDirect Connectによるプライベート接続の3つの接続方式について解説しました。VPCはAWSにおけるネットワーク設計の基盤であり、パブリックサブネットとプライベートサブネットの適切な使い分けと、ユースケースに応じた接続方式の選択がセキュアなインフラ構築の基本となります。

参考リンク:

• Amazon VPC公式ドキュメント
• AWS VPN
• Amazon Direct Connect
• VPCインターネットゲートウェイ

AWSグローバルインフラの全体像​

AWSのグローバルインフラストラクチャは、リージョン、アベイラビリティーゾーン（AZ）、エッジロケーションの3つの要素で構成されています。それぞれ異なる目的と役割を持ち、AWSのサービスを支えるインフラ基盤として機能しています。

リージョン​

リージョンは、複数のデータセンターで構成される地理的なエリアです。AWSは世界中に複数のリージョンを展開しており、日本には東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）の2つのリージョンがあります。

リージョンの主な特徴は以下の通りです。

• 各リージョンは地理的に離れた場所に配置されている
• 1つのリージョンには3つ以上のAZが存在する
• リージョン名（例: 東京リージョン）は地理的な位置を示すものであり、管轄のデータセンターが必ずしもその都市に所在するとは限らない
• AWSサービスの利用料金はリージョンごとに異なる

アベイラビリティーゾーン（AZ）​

アベイラビリティーゾーン（AZ）は、リージョン内に存在するデータセンターのグループです。各AZは以下の特徴を持ち、耐障害性と高可用性を実現しています。

この冗長構成により、1つのAZで障害が発生しても、リージョン内の他のAZが稼働可能な限り、コンピューティングを継続できます。マルチAZ構成でシステムを設計することで、高い可用性を実現できます。

マルチAZ構成を活用したトラフィック分散については、Elastic Load Balancingの仕組み - Amazon EC2と連携したトラフィック分散で解説しています。

エッジロケーション​

エッジロケーションは、主にCDN（Content Delivery Network）サービスであるAmazon CloudFrontで使用される、コンテンツ配信拠点です。リージョンやAZとは異なり、世界中の主要都市に数百か所以上配置されています。

エッジロケーションの役割​

あるリージョンにデプロイしたWebサイトやアプリケーションのコンテンツは、リージョンのデータセンターから配信されます。そのため、データセンターから物理的に離れた場所からアクセスすると、距離に応じてレイテンシが発生します。

例えば、東京リージョンにデプロイしたWebサイトを米国からアクセスした場合、東京で閲覧する場合よりもレスポンスが遅くなります。

CloudFrontは、画像や動画などのコンテンツをエンドユーザーに最も近いエッジロケーションにキャッシュし、そこから配信します。これにより、アプリケーションをデプロイしたリージョンに関係なく、世界中のユーザーにコンテンツを高速に配信することが可能になります。

3つの要素の比較​

まとめ​

この記事では、AWSのグローバルインフラストラクチャを構成するリージョン、アベイラビリティーゾーン（AZ）、エッジロケーションの3つの要素について解説しました。リージョンは地理的なサービス提供エリア、AZはリージョン内の冗長化されたデータセンター群、エッジロケーションはCloudFrontによるコンテンツ配信拠点として、それぞれ異なる役割を担っています。

参考リンク:

• AWSグローバルインフラストラクチャ
• リージョンとアベイラビリティーゾーン
• Amazon CloudFront公式ドキュメント
• Amazon Route 53公式ドキュメント

IaC（Infrastructure as Code）とは​

IaC（Infrastructure as Code）は、サーバー、ネットワーク、データベースなどのインフラストラクチャをコード（テンプレートファイル）として定義・管理するアプローチです。従来の手動によるインフラ構築と異なり、インフラの構成をコードとして記述することで、バージョン管理、再現性の確保、自動化が可能になります。

IaCの主なメリットは以下の通りです。

AWS CloudFormationとは​

AWS CloudFormationは、AWSが提供するIaCサービスです。YAMLまたはJSON形式のテンプレートファイルにインフラの構成を記述し、そのテンプレートに基づいてAWSリソースのプロビジョニングと管理を自動化します。

CloudFormationでは、テンプレートから作成されるリソースの集合をスタックと呼びます。スタック単位でリソースの作成、更新、削除が管理されます。

テンプレートの基本構造​

CloudFormationテンプレートはYAMLまたはJSONで記述します。以下はYAML形式の基本的な構造です。

AWSTemplateFormatVersion: '2010-09-09'
Description: サンプルCloudFormationテンプレート

Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-sample-bucket

  MyDynamoDBTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: my-sample-table
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST

このテンプレートでは、S3バケットとDynamoDBテーブルを定義しています。Resourcesセクションに作成するAWSリソースを記述し、Typeでリソースの種類、Propertiesでリソースの設定を指定します。

CloudFormationの利点​

テンプレートによる管理の簡素化​

CloudFormationの利点は、インフラの定義を単一のテンプレートに集約して管理を簡素化できる点です。テンプレートにはAWSリソースの構成が宣言的に記述されているため、現在のインフラの状態をテンプレートを確認するだけで把握できます。

複数リージョンへの複製​

CloudFormationを使用すると、あるリージョンで稼働しているシステムを他のリージョンに複製することが可能です。CloudFormationを使用しない場合はリージョンごとに手動でインフラを構築する必要がありますが、CloudFormationではテンプレートを対象リージョンに対してデプロイするだけで、Lambda関数、DynamoDBテーブル、S3バケットなどの設定が丸ごと複製されます。

テンプレート修正の一括反映​

テンプレートは単一のファイルとして管理されるため、構成に修正が必要な場合はテンプレートを修正して各リージョンに再デプロイするだけで、全リージョンに修正を反映できます。手動で個別のリージョンを修正する必要はありません。

SAM CLIとの連携​

CloudFormationはAWS SAM（Serverless Application Model）と組み合わせて使用することで、サーバーレスアプリケーションの開発・デプロイをさらに効率化できます。SAM CLIを使用すると、sam deployコマンドひとつで対象リージョンに対してCloudFormationテンプレートに基づいたデプロイが実行されます。

SAM CLIを使ったLambda関数の開発・デプロイについては、SAM CLIでAWS Lambdaの開発とデプロイを効率化するで詳しく解説しています。

ビジネスにおけるCloudFormationの活用​

CloudFormationによるインフラのコード管理は、ビジネスの国際展開においても有効です。新しいリージョンへの展開時に、既存環境と同一構成のインフラをテンプレートからデプロイするだけでセットアップが完了します。

テンプレートによるインフラ管理の自動化と人間の手動操作の排除により、システム構築の再現性が担保されます。これにより、運用チームはインフラの手動構築に時間を費やすことなく、より重要な業務に集中できます。

まとめ​

この記事では、IaC（Infrastructure as Code）の概念とAWS CloudFormationの基本的な仕組み、利点について解説しました。CloudFormationを使用することで、インフラの定義をYAML/JSONテンプレートとして管理し、複数リージョンへの一貫性のあるデプロイ、テンプレート修正による一括反映、SAM CLIとの連携によるサーバーレス開発の効率化が可能になります。

参考リンク:

• AWS CloudFormation公式ドキュメント
• AWS SAM（Serverless Application Model）
• AWS CloudFormation テンプレートリファレンス

VPCにおける2つの仮想ファイアウォール​

VPCでは、トラフィックを制御するためにネットワークACLとセキュリティグループの2つの仮想ファイアウォールが提供されています。この2つは動作するレベルとステートの扱いが異なり、組み合わせて使用することで多層的なセキュリティを実現します。

ネットワークACL​

ネットワークACLは、サブネットレベルでインバウンド（受信）とアウトバウンド（送信）のトラフィックを制御する仮想ファイアウォールです。ゲートウェイとサブネットの間で動作し、サブネットに出入りするすべてのトラフィックを検証します。

ネットワークACLの特徴​

• ステートレス: インバウンドとアウトバウンドの双方向で、サブネットの境界でリストの検証が必ず行われる。インバウンドで許可されたトラフィックであっても、アウトバウンドで再度検証される
• デフォルトの動作: デフォルトのネットワークACLはすべてのインバウンド・アウトバウンドトラフィックを許可する
• ルールの評価順序: ルール番号の昇順で評価され、最初にマッチしたルールが適用される
• カスタムルール: 独自のルールを明示的に設定することで、トラフィック制御が可能

セキュリティグループ​

セキュリティグループは、リソースレベル（EC2インスタンス、RDS、Lambda等の個々のリソース）でトラフィックを制御する仮想ファイアウォールです。サブネット内の特定のリソースに対して、許可するトラフィックを定義します。

セキュリティグループの特徴​

• ステートフル: インバウンドで許可されたトラフィックのレスポンスは、アウトバウンドルールに関係なく自動的に許可される。一度検証されたパケットは再検証されない
• デフォルトの動作: すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可する
• 許可ルールのみ: セキュリティグループでは許可ルールのみ設定可能で、明示的な拒否ルールは設定できない
• カスタムルール: アクセスを許可するトラフィックのソース、ポート、プロトコルを指定できる

ネットワークACLとセキュリティグループの比較​

使い分けの指針​

• サブネットレベルでのアクセス制御が必要な場合はネットワークACLを使用する。例えば、特定のIPアドレス範囲からのアクセスをサブネット単位で一括して拒否する場合に有効
• 個々のリソースレベルでアクセス制御が必要な場合はセキュリティグループを使用する。例えば、特定のEC2インスタンスに対して特定のポートのみアクセスを許可する場合に有効
• 多層防御の観点から、ネットワークACLとセキュリティグループの両方を適切に設定することが推奨される

まとめ​

この記事では、VPCにおける2つの仮想ファイアウォールであるネットワークACLとセキュリティグループについて解説しました。ネットワークACLはサブネットレベルでステートレスに動作し、セキュリティグループはリソースレベルでステートフルに動作します。サブネット単位での一括制御にはネットワークACL、個々のリソースに対するきめ細かい制御にはセキュリティグループを使用し、両者を組み合わせた多層防御でVPCのセキュリティを確保できます。

参考リンク:

• ネットワークACL公式ドキュメント
• セキュリティグループ公式ドキュメント
• AWS責任共有モデル

Google Analytics（GA4）とは​

Google Analyticsは、Googleが提供するWebサイトのアクセス解析サービスです。ユーザーの行動分析、トラフィックの把握、コンバージョンの追跡など幅広い分析機能を備えています。GA4（Google Analytics 4）は現行バージョンの名称で、Googleタグ（gtag）を使用してデータを収集します。

Docusaurusでの導入手順​

DocusaurusでGoogle Analyticsを導入するには、公式プラグインの@docusaurus/plugin-google-gtagを使用します。

前提条件​

• Docusaurusプロジェクトがセットアップ済みであること
• GA4の管理画面でGoogleタグ（トラッキングID）を取得済みであること

GA4の管理画面では「測定ID」または「Googleタグ」として表示されます。G-から始まる文字列がトラッキングIDです。

プラグインのインストール​

@docusaurus/preset-classicを使用している場合、plugin-google-gtagは既にプリセットに含まれているため追加のインストールは不要です。

プリセットを使用していない場合は、以下のコマンドでインストールします。

npm install --save @docusaurus/plugin-google-gtag

設定の追加​

プロジェクト直下のdocusaurus.config.tsに設定を追加します。@docusaurus/preset-classicを使用しているかどうかで設定方法が異なります。

preset-classicを使用している場合​

export default {
  presets: [
    [
      '@docusaurus/preset-classic',
      {
        gtag: {
          trackingID: 'G-XXXXXXXXXX',
          anonymizeIP: true,
        },
      },
    ],
  ],
};

プラグインとして追加する場合​

export default {
  plugins: [
    [
      '@docusaurus/plugin-google-gtag',
      {
        trackingID: 'G-XXXXXXXXXX',
        anonymizeIP: true,
      },
    ],
  ],
};

設定オプション​

trackingIDは複数指定が可能です。複数のプロパティでデータを収集する場合に使用します。

gtag: {
  trackingID: ['G-XXXXXXXXXX', 'G-YYYYYYYYYY'],
  anonymizeIP: true,
},

anonymizeIPは、ユーザーのプライバシー保護の観点からtrueに設定しておくことが推奨されます。

動作確認​

設定後、開発サーバーを起動してブラウザの開発者ツールで動作を確認できます。

npm run start

本番ビルドで確認する場合は、以下のコマンドでビルドとローカルサーバーの起動を行います。

npm run build && npm run serve

ブラウザの開発者ツールのネットワークタブで、gtagやgoogle-analytics.comへのリクエストが送信されていれば正常に動作しています。

まとめ​

この記事では、DocusaurusにGoogle Analytics（GA4）を導入する方法について解説しました。@docusaurus/preset-classicを使用している場合は追加インストール不要で、docusaurus.config.tsにトラッキングIDを設定するだけでアクセス解析を開始できます。旧プラグインのplugin-google-analyticsは非推奨のため、新規導入ではplugin-google-gtagを使用します。

参考リンク:

• Google Analytics
• @docusaurus/plugin-google-gtag 公式ドキュメント
• @docusaurus/plugin-google-analytics（非推奨）

AWS Lambdaとは​

AWS Lambdaは、AWSが提供するサーバーレスコンピューティングサービスです。Amazon EC2とは異なり、インスタンスなどの実行基盤を自分で用意・管理する必要がなく、プログラムを作成してデプロイすればいつでも実行可能な状態になります。

SAM（Serverless Application Model）とは​

AWS SAMは、AWSが公式に提供するサーバーレスアプリケーションの構築フレームワークです。AWS CloudFormationを基盤としており、YAMLテンプレートでLambda関数やAPI Gatewayなどのリソースを定義し、デプロイを自動化できます。

同様の仕組みとしてServerless Frameworkなどがありますが、SAMはAWS公式の仕組みであり、IAMをベースにAWSの各種サービスとシームレスに統合できる点が特徴です。

SAM CLIの役割​

SAM CLIは、SAMの仕組みをローカル環境で使用するためのオープンソースのコマンドラインツールです。プロジェクトの初期化、ビルド、ローカルテスト、デプロイなどの操作を提供します。

SAM CLIのインストール​

SAM CLIはHomebrew経由でインストールできます。

brew install aws-sam-cli

インストール後、以下のコマンドでバージョンを確認します。

sam --version

SAM CLI, version 1.154.0

プロジェクトの作成​

sam initコマンドで対話形式のプロンプトが開始され、CloudFormationテンプレートとSAMの設定ファイルが生成されます。

sam init

対話形式の手順​

以下の手順でHello World Exampleのプロジェクトを作成します。

1. テンプレートソースの選択

Which template source would you like to use?
        1 - AWS Quick Start Templates
        2 - Custom Template Location
Choice: 1

2. アプリケーションテンプレートの選択

Choose an AWS Quick Start application template
        1 - Hello World Example
        2 - Data processing
        3 - Hello World Example with Powertools for AWS Lambda
        4 - Multi-step workflow
        5 - Scheduled task
        6 - Standalone function
        7 - Serverless API
        8 - Infrastructure event management
        9 - Lambda Response Streaming
        10 - GraphQLApi Hello World Example
        11 - Full Stack
        12 - Durable Functions
        13 - Lambda EFS example
        14 - Serverless Connector Hello World Example
        15 - Multi-step workflow with Connectors
        16 - Hello World Durable Function Example
        17 - DynamoDB Example
        18 - Machine Learning
Template: 1

3. ランタイムの選択

Use the most popular runtime and package type? (python3.14 and zip) [y/N]: y

4. X-Rayトレーシングの設定

Would you like to enable X-Ray tracing on the function(s) in your application?  [y/N]: N

5. CloudWatch Application Insightsの設定

Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: N

6. ログ形式の設定

Would you like to set Structured Logging in JSON format on your Lambda functions?  [y/N]: y

7. プロジェクト名の設定

Project name [sam-app]: sam-app

プロジェクト構造​

sam initが完了すると、以下の構造のプロジェクトが生成されます。

sam-app/
├── README.md
├── __init__.py
├── events/
│   └── event.json
├── hello_world/
│   ├── __init__.py
│   ├── app.py
│   └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests/
    ├── __init__.py
    ├── integration/
    │   ├── __init__.py
    │   └── test_api_gateway.py
    ├── requirements.txt
    └── unit/
        ├── __init__.py
        └── test_handler.py

SAMを利用するうえで重要なファイルは以下の3つです。

主要ファイルの解説​

samconfig.toml​

SAMの動作に必要な設定を定義するファイルです。stack_nameはCloudFormationに登録されるスタック名になります。デプロイ先のリージョンを指定する場合は、[default.deploy.parameters]にregion = "ap-northeast-1"などを追加します。

version = 0.1

[default.global.parameters]
stack_name = "sam-app"

[default.build.parameters]
cached = true
parallel = true

[default.validate.parameters]
lint = true

[default.deploy.parameters]
capabilities = "CAPABILITY_IAM"
confirm_changeset = true
resolve_s3 = true

[default.package.parameters]
resolve_s3 = true

[default.sync.parameters]
watch = true

[default.local_start_api.parameters]
warm_containers = "EAGER"

[default.local_start_lambda.parameters]
warm_containers = "EAGER"

template.yaml​

CloudFormationテンプレートで、デプロイ時に作成されるAWSリソースを定義します。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app

Globals:
  Function:
    Timeout: 3
    LoggingConfig:
      LogFormat: JSON

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.14
      Architectures:
      - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get

Outputs:
  HelloWorldApi:
    Description: API Gateway endpoint URL for Prod stage for Hello World function
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.${AWS::URLSuffix}/Prod/hello/"
  HelloWorldFunction:
    Description: Hello World Lambda Function ARN
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: Implicit IAM Role created for Hello World function
    Value: !GetAtt HelloWorldFunctionRole.Arn

テンプレートの主要なポイントは以下の通りです。

• Resources: Lambda関数の定義。CodeUriで関数のソースコードの場所、Handlerでエントリポイント（app.pyのlambda_handler関数）を指定
• Architectures: CPUアーキテクチャの指定。x86_64またはarm64を選択可能
• Events: API Gatewayのエンドポイント定義。クイックスタートテンプレートではデフォルトで含まれる
• Outputs: デプロイ後に出力される情報（APIエンドポイントURL、Lambda関数のARNなど）

app.py​

Lambda関数の実装コードです。クイックスタートテンプレートでは、HTTPリクエストを受けてステータス200でhello worldを返す関数が生成されます。

import json


def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "hello world",
        }),
    }

eventパラメータにはAPI Gatewayから転送されたリクエスト情報が、contextパラメータにはLambdaの実行環境に関する情報が渡されます。

ビルドとデプロイ​

ビルド​

sam buildコマンドでプロジェクトをビルドします。依存ライブラリのインストールとコードのパッケージングが行われます。

sam build

ビルドが成功すると以下のような出力が表示されます。

Starting Build use cache
Building codeuri: /hello_world runtime: python3.14 architecture: x86_64
 functions: HelloWorldFunction
 Running PythonPipBuilder:CopySource

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

デプロイ​

sam deployコマンドでAWSにデプロイします。

sam deploy

デプロイ時に作成・変更されるリソースの一覧（Changeset）が表示されます。内容を確認し、yを入力するとデプロイが開始されます。

CloudFormation stack changeset
-------------------------------------------------------------
Operation       LogicalResourceId          ResourceType
-------------------------------------------------------------
+ Add           HelloWorldFunction         AWS::Lambda::Function
+ Add           HelloWorldFunctionRole     AWS::IAM::Role
+ Add           ServerlessRestApi          AWS::ApiGateway::RestApi
+ Add           ServerlessRestApiProdStage AWS::ApiGateway::Stage
-------------------------------------------------------------

Deploy this changeset? [y/N]: y

デプロイが完了すると、Outputsに定義した情報（APIエンドポイントURLなど）が表示されます。

スタックの削除​

不要になったCloudFormationスタックは、AWS CLIで削除できます。スタックに関連するすべてのリソース（Lambda関数、API Gateway、IAMロールなど）が削除されます。

aws cloudformation delete-stack --stack-name sam-app

まとめ​

この記事では、SAM CLIを使用してAWS Lambda関数の開発とデプロイを行う方法について解説しました。SAMはCloudFormationを基盤としたAWS公式のフレームワークで、sam initでプロジェクトの雛形を作成し、sam buildでビルド、sam deployでデプロイという一連のワークフローを提供します。template.yamlでインフラ構成をコードとして管理できるため、手動デプロイと比較してヒューマンエラーの削減と再現性の向上が期待できます。

参考リンク:

• AWS Lambda
• AWS SAM 公式ドキュメント
• SAM CLI GitHub リポジトリ
• SAM CLI インストールガイド
• AWS CloudFormation
• AWS Graviton プロセッサ

従来の図作成の課題​

フローチャートやアーキテクチャ図の作成には、ExcelやWordなどのOfficeアプリケーション、または専用のダイアグラムツールが使われることが多いです。しかし、これらのアプリケーションでの図作成にはいくつかの課題があります。

• 作成・更新に時間がかかる: 図形を一つずつ配置し、矢印で接続する作業が必要
• 保守性が低い: フローを追加する際に全体の配置を手動で調整する必要がある
• テキストベースでない: Gitでの差分管理が困難で、LLMなどのテキストを扱う技術との親和性が低い

Mermaidとは​

Mermaidは、JavaScriptベースのオープンソースライブラリで、テキスト（コード）からダイアグラム図を動的に生成します。マークダウンに統合できるため、ドキュメントと図を一元管理することが可能です。

JavaScript Open Source Awards 2019では「The Most Exciting Use of Technology」として表彰されています。

Mermaidの主な特徴​

• テキストベース: コードで図を記述するため、Gitでのバージョン管理が可能
• 自動レイアウト: ノードの配置やフローの描画を自動で処理
• 多様な図に対応: フローチャート、シーケンス図、クラス図など多くの図をサポート
• 幅広い統合: GitHub、GitLab、VSCode、Docusaurusなど多くのプラットフォームで利用可能

Mermaidの基本的な使い方​

Mermaidでは、マークダウンのコードブロック内にmermaidを指定して図を記述します。

フローチャート​

フローチャートは、処理の流れや分岐を表現する図です。flowchartキーワードで定義し、TD（上から下）やLR（左から右）で方向を指定します。

以下はMermaid公式サイトで紹介されているコード例です。

```mermaid
flowchart TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]
```

このコードをMermaidで描画すると、次のようなフローチャートが生成されます。

構文は直感的で、A[テキスト]でノードを定義し、-->で矢印を描画、|ラベル|でラベルを付与します。[]は四角形、()は角丸、{}はひし形（分岐）を表します。

フローの追加と削除​

4番目の選択肢として「Sweet」を追加する場合、1行追加するだけで対応できます。

```mermaid
flowchart TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]
    C -->|Four| G[Sweet]
```

レイアウトはMermaidが自動で調整するため、ノードの位置を手動で変更する必要はありません。不要なフローを削除する場合も、該当する行を削除するだけです。

シーケンス図​

シーケンス図は、システム間のメッセージのやり取りを時系列で表現する図です。API通信や認証フローの可視化に適しています。

クラス図​

クラス図は、クラスの構造と関係を表現する図です。オブジェクト指向設計の可視化に利用されます。

状態図​

状態図は、オブジェクトの状態遷移を表現する図です。ライフサイクルやワークフローの可視化に適しています。

ER図（エンティティ関係図）​

ER図は、データベースのテーブル構造とリレーションを表現する図です。

Mermaidの導入方法​

Mermaidは多くのプラットフォームで利用可能です。代表的な導入方法を紹介します。

Visual Studio Code​

VSCodeでは、拡張機能「Markdown Preview Mermaid Support」をインストールすることで、マークダウンのプレビュー画面でMermaid図を描画できます。

VSCodeのインストールについては、HomebrewでVisual Studio Codeをインストールするで解説しています。

GitHub / GitLab​

GitHubとGitLabでは、マークダウンファイル内のmermaidコードブロックがネイティブで描画されます。READMEやIssue、Pull Requestの説明文にMermaid図を含めることが可能です。

Docusaurus​

Docusaurusでは、@docusaurus/theme-mermaidテーマを導入することでMermaid図を利用できます。docusaurus.config.tsで以下のように設定します。

export default {
  markdown: {
    mermaid: true,
  },
  themes: ['@docusaurus/theme-mermaid'],
};

Docusaurusの基本的な使い方については、Docusaurusで静的サイトを構築するで解説しています。

Mermaid Live Editor​

Mermaid Live Editorは、ブラウザ上でMermaid図を編集・プレビューできる公式ツールです。環境構築不要で、Mermaidの構文を試すことができます。

まとめ​

この記事では、テキストベースでダイアグラム図を作成できるMermaidについて解説しました。Mermaidを使用することで、フローチャート、シーケンス図、クラス図、状態図、ER図など多様な図をコードで記述でき、Gitでのバージョン管理やLLMとの連携も可能になります。VSCode、GitHub、Docusaurusなど多くのプラットフォームで利用できるため、ドキュメント作成の効率化に有効です。

参考リンク:

• Mermaid公式サイト
• Mermaid公式ドキュメント
• Mermaid Live Editor
• Mermaid GitHub リポジトリ
• JavaScript Open Source Awards 2019

rebaseとは​

git rebaseは、コミット履歴の基準点（ベース）を変更・再構成するためのコマンドです。コミット履歴を整理したり、ブランチの起点を変更したりする際に使用します。

普段mainブランチで直接作業するような場合にはあまり使用しませんが、プルリクエストを作成するワークフローでは、マージ前にコミット履歴を整理する目的で活用できます。

インタラクティブrebaseの活用例​

コミット履歴が散らかるケース​

開発中、以下のようなコミット履歴になることがあります。

このfeatureブランチのコミット履歴を見ると、本質的な変更である「機能実装」と「テスト追加」に加えて、「typo修正」や「デバッグ用print削除」といった小さな修正コミットが混在しています。このままマージすると、mainブランチのコミット履歴にもこれらの細かいコミットがそのまま残ります。

rebaseでコミットを統合する​

git rebase -i（インタラクティブrebase）を使用すると、複数のコミットを1つに統合（squash）できます。

直近4件のコミットを対象にインタラクティブrebaseを開始します。

git rebase -i HEAD~4

エディタが開き、対象のコミット一覧が表示されます。

pick jkl3456 機能実装
pick ghi9012 typo修正
pick def5678 テスト追加
pick abc1234 デバッグ用print削除

各行の先頭にあるpickは、そのコミットをそのまま残すことを意味します。統合したいコミットのpickをsquash（または省略形のs）に変更します。

pick jkl3456 機能実装
squash ghi9012 typo修正
pick def5678 テスト追加
squash abc1234 デバッグ用print削除

編集が完了したら、エディタを保存して終了します（Vimの場合は:wq）。続いてコミットメッセージの編集画面が表示されるので、統合後のコミットメッセージを記述して保存します。

rebase後のコミット履歴​

rebaseが完了すると、コミット履歴は以下のように整理されます。

4つあったコミットが2つに整理され、プルリクエストをマージした際にmainブランチに残るコミット履歴もきれいな状態になります。

rebase -iで使用できるコマンド​

インタラクティブrebaseでは、pickとsquash以外にもいくつかのコマンドが使用できます。

参考: git-rebase - Git公式ドキュメント

rebaseを中断・取り消す​

rebase中に問題が発生した場合、以下のコマンドで操作を中断・取り消すことができます。

git rebase --abort

git reflog
git reset --hard HEAD@{n}

git reflogでrebase前のコミットハッシュを確認し、git reset --hardで戻ることができます。

まとめ​

この記事では、git rebase -iを使ってコミット履歴を整理する方法について解説しました。インタラクティブrebaseを活用することで、開発中に増えてしまった細かいコミットを論理的な単位にまとめ、プルリクエストのコミット履歴を整理できます。ただし、rebaseはコミット履歴を書き換える操作であるため、共有ブランチでの使用には注意が必要です。

参考リンク:

• git-rebase - Git公式ドキュメント
• Git - リベース

git-remote-codecommitとは​

git-remote-codecommitは、AWS CodeCommitリポジトリへのGitアクセスを簡略化するためのAWS公式ツールです。Pythonパッケージとしてpipで配布されています。

AWS CodeCommitはGitベースのマネージドリポジトリサービスですが、デフォルトのHTTPSアクセスではGit認証情報（ユーザー名とパスワード）の発行・管理が必要になります。git-remote-codecommitを使用すると、IAMユーザーの認証情報で直接アクセスできるため、Git認証情報を別途管理する必要がなくなります。

前提条件​

git-remote-codecommitを使用するには、以下の環境が必要です。

参考: git-remote-codecommit - PyPI

Pythonのインストールについては、HomebrewでPythonをインストールするで解説しています。

セットアップ手順​

手順1: pipのバージョンを確認する​

git-remote-codecommitにはpip 9.0.3以降が必要です。まず、pipのバージョンを確認します。

pip3 --version

pip 26.0 from /opt/homebrew/lib/python3.14/site-packages/pip (python 3.14)

バージョンが9.0.3未満の場合は、pipを更新します。

pip3 install --upgrade pip

または、Homebrewで管理している場合はbrewコマンドでPythonを更新します。

brew upgrade python3

手順2: IAMユーザーの準備​

CodeCommitリポジトリがあるリージョンで、適切な権限を持つIAMユーザーを準備します。

1. IAMユーザーを作成し、CodeCommit関連のポリシー（AWSCodeCommitFullAccessまたはAWSCodeCommitPowerUserなど）をアタッチする
2. AWS CLIでプロファイルを設定する

aws configure --profile my-codecommit-profile

AWS CLIのプロファイル設定の詳細については、AWS CLIでIAMユーザーのプロファイルを設定するで解説しています。

手順3: git-remote-codecommitをインストールする​

pipでgit-remote-codecommitをインストールします。

pip3 install git-remote-codecommit

インストールが完了すると、Gitコマンドでcodecommit://プロトコルが使用できるようになります。

使用方法​

デフォルトプロファイルでクローンする​

AWS CLIのデフォルトプロファイルを使用してリポジトリをクローンする場合は、以下のコマンドを実行します。

git clone codecommit://YourRepositoryName

プロファイルを指定してクローンする​

デフォルト以外のプロファイルを使用する場合は、@の前にプロファイル名を指定します。

git clone codecommit://my-profile@YourRepositoryName

リージョンを指定してクローンする​

特定のリージョンを明示的に指定する場合は、以下の形式を使用します。

git clone codecommit::ap-northeast-1://my-profile@YourRepositoryName

クローン後の操作​

codecommit://プロトコルでクローンしたリポジトリでは、通常のGitコマンドでプル・プッシュなどの操作が可能です。

git pull
git push
git fetch

codecommitプロトコルの形式まとめ​

使用するプロファイルとリージョンに応じて、以下のURL形式を選択します。

まとめ​

この記事では、git-remote-codecommitを使用してAWS CodeCommitの認証をIAMベースに簡略化する方法について解説しました。git-remote-codecommitを導入することで、Git認証情報の管理が不要になり、AWS CLIのプロファイルをそのまま活用してCodeCommitリポジトリにアクセスできます。

参考リンク:

• git-remote-codecommit - PyPI
• git-remote-codecommit - GitHub
• AWS公式 - git-remote-codecommitを使用したセットアップ

Claude Codeとは​

Claude Codeは、Anthropicが開発したCLIベースのAIコーディングアシスタントです。ターミナル上で動作し、コードの生成・編集・デバッグ・リファクタリングなど、幅広いソフトウェア開発タスクを支援します。

Claude Codeは公式の定額制サブスクリプションでも利用可能ですが、Amazon Bedrockと連携することで従量課金制での利用が可能になります。

Amazon Bedrockを使用するメリット​

Claude CodeをAmazon Bedrock経由で使用することには、以下のような利点があります。

Claude Codeのインストール​

ターミナルで次のコマンドを実行してClaude Codeをインストールします。

npm install -g @anthropic-ai/claude-code

インストールが完了したら、次のコマンドでバージョン情報を確認します。

claude --version

バージョン情報が出力されれば、インストールは正常に完了しています。

2.1.63 (Claude Code)

環境変数の設定​

Claude CodeでAmazon Bedrockを使用するには、いくつかの環境変数を設定する必要があります。

Amazon Bedrockの有効化​

Claude CodeからAmazon Bedrockを使用する設定を有効化します。

export CLAUDE_CODE_USE_BEDROCK=1

AWSリージョンの設定​

Amazon Bedrockを使用するAWSリージョンを設定します。

export AWS_REGION=ap-northeast-1

推論プロファイルIDの設定​

Claude Codeで使用するモデルの推論プロファイルIDを設定します。推論プロファイルは、Amazon Bedrockで利用可能なモデルを識別するためのIDです。

ANTHROPIC_MODELにはメインで使用するモデル、ANTHROPIC_SMALL_FAST_MODELには軽量・高速なモデルを指定します。

export ANTHROPIC_MODEL='jp.anthropic.claude-sonnet-4-5-20250929-v1:0'
export ANTHROPIC_SMALL_FAST_MODEL='jp.anthropic.claude-haiku-4-5-20251001-v1:0'

利用可能な推論プロファイルの一覧は、Amazon Bedrockでサポートされている推論プロファイルから確認できます。グローバル推論プロファイル（global.プレフィックス）はリージョンに依存せず使用でき、リージョン別推論プロファイル（jp.などのプレフィックス）は特定のリージョンに紐づいています。

AWSプロファイルの指定（任意）​

AWS CLIのデフォルトプロファイル以外を使用する場合は、AWS_PROFILE環境変数で対象のプロファイルを指定します。

export AWS_PROFILE=bedrock-user

AWS CLIのプロファイル設定については、AWS CLIでIAMユーザーのプロファイルを設定するで詳しく解説しています。

IAMポリシーの設定​

Claude CodeからAmazon Bedrockに接続するIAMユーザーには、以下のポリシーをアタッチする必要があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    },
    {
      "Sid": "AllowMarketplaceSubscription",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
      }
    }
  ]
}

このポリシーには2つのステートメントが含まれています。

AllowMarketplaceSubscriptionにはConditionが設定されており、Amazon Bedrock経由での呼び出し時のみ有効になります。

IAMポリシーをアタッチしたIAMユーザーのプロファイルをAWS CLIで設定することで、Claude CodeはAWS認証情報を参照してAmazon Bedrockのモデルを呼び出します。

Claude Codeの起動​

環境変数の設定とIAMポリシーの構成が完了したら、Claude Codeを起動します。任意のプロジェクトディレクトリで次のコマンドを実行します。

claude

初回起動時はカレントディレクトリへのアクセス許可を求められます。

────────────────────────────────────────────────────────────────────────────────
 Accessing workspace:

 /xxx/yyy

 Quick safety check: Is this a project you created or one you trust? (Like your
  own code, a well-known open source project, or work from your team). If not,
 take a moment to review what's in this folder first.

 Claude Code'll be able to read, edit, and execute files here.

 Security guide

 ❯ 1. Yes, I trust this folder
   2. No, exit

信頼できるディレクトリであれば「1. Yes, I trust this folder」を選択します。

許可すると、以下のようにClaude Codeが起動し、設定した推論プロファイルが反映されていることを確認できます。

 ▐▛███▜▌   Claude Code v2.1.63
▝▜█████▛▘  global.anthropic.claude-opus-4-6-v1 · API Usage Billing
  ▘▘ ▝▝    ~/xxx/yyy/zzz

  Welcome to Opus 4.6

2行目に表示されているモデル名が環境変数で設定した推論プロファイルIDと一致し、「API Usage Billing」と表示されていれば、Amazon Bedrock経由での接続が正常に行われています。

環境変数の永続化​

上記の環境変数はターミナルセッション終了時に失われるため、シェルの設定ファイルに記述して永続化することが推奨されます。

# Claude Code - Amazon Bedrock
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export ANTHROPIC_MODEL='jp.anthropic.claude-sonnet-4-5-20250929-v1:0'
export ANTHROPIC_SMALL_FAST_MODEL='jp.anthropic.claude-haiku-4-5-20251001-v1:0'
# export AWS_PROFILE=bedrock-user  # 必要に応じて有効化

設定ファイルを編集した後、次のコマンドで変更を反映します。

source ~/.zshrc

まとめ​

この記事では、Claude CodeをAmazon Bedrock経由で使用するためのセットアップ手順を解説しました。環境変数の設定（CLAUDE_CODE_USE_BEDROCK、AWS_REGION、推論プロファイルID）とIAMポリシーの構成を行うことで、AWSの請求体系とアクセス管理の仕組みを活用しながらClaude Codeを利用できます。

参考リンク:

• Claude Code 公式ドキュメント
• Amazon Bedrock でのClaude Code利用
• Amazon Bedrockでサポートされている推論プロファイル
• Amazon Bedrock 料金

Route53のドメイン登録とDNSホスティングの違い​

Amazon Route53には主に2つの機能があります。

Route53の公式ドキュメントにも、ドメイン登録でサポートされていないTLDであっても、Route53をDNSサービスとして使用できることが記載されています。

つまり、.devのようにRoute53でドメイン登録ができないTLDであっても、パブリックホストゾーンを作成してDNSホスティングのみをRoute53で行うことが可能です。

Route53でDNSホスティングが必要になるケース​

Route53でのDNSホスティングが有効なケースとして、Amazon CloudFrontでのネイキッドドメイン（Apexドメイン）の使用があります。

DNS仕様上、ゾーンのApexにCNAMEレコードを設定することはできません。そのため、example.devのようなネイキッドドメインでCloudFrontディストリビューションを使用する場合、Route53のALIASレコードを利用する方法が一般的です¹。

移行の全体フロー​

手順1: 移行元のDNSレコードをバックアップする​

移行元のドメイン管理プロバイダにログインし、現在設定されているDNSレコードとネームサーバー名をすべて控えます。

バックアップする項目は以下の通りです。

• すべてのDNSレコード（レコード名、レコードタイプ、値、TTL）
• 現在使用中のネームサーバー名

手順2: Route53でパブリックホストゾーンを作成する​

AWSマネジメントコンソールでRoute53の管理画面を開き、パブリックホストゾーンを作成します。ホストゾーン名には実際のドメイン名（例: example.dev）を入力します。

パブリックホストゾーンを作成すると、以下の2つのDNSレコードが自動で作成されます。

手順3: DNSレコードをRoute53に移植する​

移行元プロバイダで設定されているDNSレコードを、Route53のパブリックホストゾーンに移植します。レコード名、レコードタイプ、値を移行元と一致させます。

この作業を事前に行うことで、後のネームサーバー切り替え時にダウンタイムを発生させずに移行を進めることができます。

手順4: ネームサーバーを変更する​

Route53のパブリックホストゾーンに表示されているNSレコードから、割り当てられた4つのネームサーバー名を確認します。

ns-xxx.awsdns-yy.com
ns-xxx.awsdns-yy.net
ns-xxx.awsdns-yy.org
ns-xxx.awsdns-yy.co.uk

この4つのネームサーバー名を、移行元プロバイダの管理画面でカスタムネームサーバーとして設定します。

手順5: DNS伝播を確認する​

ネームサーバーの変更は、世界中のDNSリゾルバにキャッシュされた旧ネームサーバー情報が更新されるまでに最大48時間程度かかる場合があります。

次のコマンドで、ドメインに設定されているネームサーバーを確認できます。

nslookup -type=NS example.dev

dig example.dev NS

特定のDNSサーバーを指定して確認する場合は、以下のようにします。

dig example.dev NS @8.8.8.8

出力にRoute53のネームサーバー名（ns-xxx.awsdns-yy.comなど）が表示されていれば、ネームサーバーの切り替えが反映されています。旧ネームサーバー名が表示される場合は、伝播が完了するまで待機します。

伝播の完了後、以下の項目を確認します。

• Webサイトが正常に表示されるか
• メールの送受信が正常に行えるか（MXレコードを使用している場合）
• その他のサブドメインやサービスが正常に動作しているか

Route53の料金​

Route53のDNSホスティングには料金が発生します。詳細はRoute53の料金ページを参照してください。

まとめ​

この記事では、Amazon Route53でドメイン登録がサポートされていないTLD（.devなど）のドメインを、Route53でDNSホスティングする方法を解説しました。Route53ではドメイン登録とDNSホスティングは独立した機能であり、ドメイン登録未対応のTLDであってもパブリックホストゾーンを作成してDNSの名前解決を行うことが可能です。移行時にはDNSレコードの事前移植とネームサーバーの切り替えを段階的に行うことで、ダウンタイムを最小限に抑えた移行が実現できます。

参考リンク:

• Amazon Route53 公式ドキュメント
• Route53でドメイン登録に対応しているTLD一覧
• Route53のNSレコードとSOAレコード
• Amazon Route53 料金

プロファイルとは​

プロファイルは、CLIやアプリケーションからAWSのサービスを利用する際に使用するIAMユーザーの認証情報を保管・使用するための仕組みです。プロファイルを使用することでIAMユーザーの認証情報をコードにハードコーディングする必要がなくなり、安全な開発と運用を行うことができます。

プロファイルはIAMユーザーに応じて複数作成でき、用途に合わせて任意に切り替えることが可能です。

前提条件​

• AWS CLIがインストール済みであること
• IAMユーザーが作成済みであること
• IAMユーザーのアクセスキーとシークレットアクセスキーを取得済みであること

プロファイルの構造​

プロファイル情報は~/.awsディレクトリに保存されます。

~/.aws/
├── config        # リージョンや出力形式の設定
└── credentials   # アクセスキーとシークレットアクセスキー

この2つのファイルが、プロファイル作成時に指定した名前で関連付けられています。

config​

configにはIAMユーザーが存在するリージョンの情報や、CLIの実行結果の出力形式が保存されています。

[default]
region = ap-northeast-1
output = json

[profile my-project]
region = ap-northeast-1
output = json

credentials​

credentialsにはIAMユーザーのアクセスキーとシークレットアクセスキーのペアが保存されています。

[default]
aws_access_key_id = xxx
aws_secret_access_key = yyy

[my-project]
aws_access_key_id = xxx
aws_secret_access_key = zzz

デフォルトプロファイルの作成​

デフォルトプロファイルは、特定のプロファイルを指定しない場合にすべてのCLI操作で使用される共通プロファイルです。デフォルトプロファイルは1つのみ作成可能で、2回目以降の実行では上書きされます。

以下のコマンドで対話形式で作成できます。

aws configure

対話形式でIAMユーザーの認証情報を入力します。

AWS Access Key ID [None]: IAMユーザーのアクセスキー
AWS Secret Access Key [None]: IAMユーザーのシークレットアクセスキー
Default region name [None]: ap-northeast-1
Default output format [None]: json

以下のコマンドでデフォルトプロファイルの設定値を確認できます。

aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ******************* shared-credentials-file
secret_key     ******************* shared-credentials-file
    region           ap-northeast-1      config-file    ~/.aws/config

名前付きプロファイルの作成​

デフォルトプロファイルは1つしか作成できないため、複数のIAMユーザーを使い分ける場合は不便です。名前付きプロファイルを作成することで、IAMユーザーの役割ごとにプロファイルを管理できます。

以下のコマンドで、--profileオプションに任意のプロファイル名を指定して作成します。

aws configure --profile my-project

デフォルトプロファイルと同様に、対話形式でIAMユーザーの認証情報を入力します。

AWS Access Key ID [None]: IAMユーザーのアクセスキー
AWS Secret Access Key [None]: IAMユーザーのシークレットアクセスキー
Default region name [None]: ap-northeast-1
Default output format [None]: json

以下のコマンドで名前付きプロファイルの設定値を確認できます。

aws configure list --profile my-project

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile               my-project           manual    --profile
access_key     ******************* shared-credentials-file
secret_key     ******************* shared-credentials-file
    region           ap-northeast-1      config-file    ~/.aws/config

プロファイルの特定項目を更新​

プロファイルの設定値を更新する場合は、~/.aws配下のファイルを直接編集するのではなく、CLIからaws configure setコマンドで更新します。

デフォルトプロファイルの場合は以下の通りです。

aws configure set region ap-northeast-1

名前付きプロファイルの場合は--profileオプションを指定します。

aws configure set region ap-northeast-1 --profile my-project

CSV形式での一括インポート​

AWSマネジメントコンソールからダウンロードしたCSV形式のIAM認証情報を、以下のコマンドで一括インポートできます。

aws configure import --csv file://credentials.csv

まとめ​

この記事では、AWS CLIでIAMユーザーのプロファイルを設定する方法について解説しました。プロファイルは認証情報をコードから分離して管理するための仕組みであり、デフォルトプロファイルと名前付きプロファイルを使い分けることで、複数のIAMユーザーを用途に応じて切り替えることが可能です。configとcredentialsの2つのファイルで構成され、CLIコマンドを通じて安全に管理できます。

参考リンク:

• AWS CLI の設定と認証情報ファイルの設定
• IAM ユーザーの作成
• AWS CLI の名前付きプロファイル

Elasticとは​

Elasticは「伸縮性」を意味する言葉で、クラウドコンピューティングにおいてはリソースを需要に応じて柔軟に拡大・縮小できる特性を表します。Amazon EC2の「E」（Elastic Compute Cloud）やElastic Load Balancingの「Elastic」は、この特性に由来しています。

Elasticはスケーリングを包括する概念であり、Elasticという特性の下でスケーリングが実行されます。

スケーリングとは​

スケーリングとは、サービスの需要に応じてコンピューティングリソースの規模を調整することです。需要が増加した場合にはメモリの増強やノード数の追加を行い、需要が減少した場合には不要なリソースを削減します。

オンプレミス環境ではこれらのスケーリングをすべて手動で行う必要がありますが、EC2のようなクラウドの仮想サーバーにはオートスケーリングの仕組みが組み込まれており、需要に応じて自動的にスケーリングが実行されます。

Elasticとスケーリングの関係​

Elasticの概念とスケーリングの種類の関係を以下の図に示します。

スケーリングの種類​

スケーリングには大きく分けて垂直スケーリングと水平スケーリングの2種類があります。

垂直スケーリング（スケールアップ / スケールダウン）​

垂直スケーリングは、サーバーのCPU、メモリ、ストレージなどのスペックを調整する方法です。

スケールアップでは増強した分だけサーバーの処理能力が向上します。しかし、サーバー1台あたりのリソース増強には物理的な限界があるため、大規模な需要の増加には対応しきれない場合があります。そのような場合は、水平スケーリングが重要になります。

EC2におけるオートスケーリングでは、垂直スケーリングは自動化の対象外です。ユーザーが必要に応じてEC2インスタンスタイプを変更することで対応します。

水平スケーリング（スケールアウト / スケールイン）​

水平スケーリングは、需要の増減に応じてEC2インスタンスの稼働数を調整する方法です。EC2インスタンスをノードとして捉え、ノード数を増減させるとも表現できます。

水平スケーリングはEC2 Auto Scalingによる自動化の対象です。例えば、稼働中のEC2インスタンスに急激な需要の増加があった場合、デフォルトまたはユーザーが事前に設定した条件に基づいて、自動的に必要な数のEC2インスタンスが追加・起動されます。これにより、ECサイトの繁忙期のような急激なトラフィック増加にも対応できます。逆に需要が減少した場合は、不要になったEC2インスタンスが自動的に停止されます。

こうしたEC2インスタンスの増減に伴うトラフィックを適切に分散し最適化するために、Elastic Load Balancing（ELB）が使用されます。

まとめ​

この記事では、クラウドコンピューティングにおけるElastic（伸縮性）の概念と、スケーリングの2つの種類について整理しました。Elasticは需要に応じてリソースを柔軟に拡大・縮小できる特性であり、その下で垂直スケーリング（スペックの変更）と水平スケーリング（台数の増減）が実行されます。EC2のオートスケーリングでは水平スケーリングが自動化の対象であり、ELBと連携することでトラフィックの分散と最適化が実現されます。

参考リンク:

• Amazon EC2
• Elastic Load Balancing
• Amazon EC2 Auto Scaling
• Amazon EC2 Instance Types

Elastic Load Balancing（ELB）とは​

Elastic Load Balancing（ELB）は、受信したアプリケーショントラフィックを複数のターゲット（EC2インスタンス、コンテナ、IPアドレスなど）に自動的に分散するAWSのロードバランシングサービスです。1つまたは複数のアベイラビリティゾーン（AZ）にまたがってトラフィックを分散し、アプリケーションの可用性と耐障害性を向上させます。

ELBの主な役割は以下の通りです。

• トラフィック分散: 受信リクエストを複数のターゲットに均等に分配し、特定のインスタンスへの負荷集中を防ぐ
• ヘルスチェック: ターゲットの稼働状態を定期的に監視し、正常なターゲットにのみトラフィックをルーティングする
• SSL/TLS終端: AWS Certificate Manager（ACM）と連携し、HTTPS接続の暗号化・復号処理をロードバランサー側で実行する
• 高可用性: 複数のAZにまたがる構成により、特定のAZに障害が発生した場合でも他のAZにトラフィックを振り分ける

EC2と組み合わせるメリット​

Amazon EC2を使用したシステムでは、ELBを組み合わせることでコンピューティングリソースを効率的に活用できます。

例えば、時間帯によって混雑具合が異なるレストランの予約システムを考えます。このシステムではAmazon EC2上でバックエンドサーバーを運用し、フロントエンドとバックエンドの間にELBを配置しています。

昼の時間帯は他の時間帯よりもアクセスが集中するため、EC2 Auto Scalingによってインスタンス数が増加します。このとき、ELBはオートスケールで追加されたインスタンスを自動的にルーティング対象に組み込み、トラフィックを最適に分散します。

ELBがない場合、オートスケールで追加されたEC2インスタンスにトラフィックが適切に振り分けられず、新しいインスタンスがアイドル状態のまま放置されたり、既存のインスタンスが過負荷状態になる可能性があります。ELBはこの問題を解決し、フロントエンド層とバックエンド層を疎結合に保ちながら、トラフィックの同期を最適化します。

ロードバランサーの種類​

ELBには4種類のロードバランサーがあり、ユースケースに応じて選択します。

ALBとNLBの使い分け​

一般的なWebアプリケーションではALBが適しています。ALBはHTTPヘッダー、パスパターン、ホスト名などに基づく高度なルーティングルールを設定でき、マイクロサービスやコンテナベースのアプリケーションに対応しています。

一方、ゲームサーバーやIoTデバイスとの通信のように、低レイテンシかつ高スループットが求められるケースではNLBが有効です。NLBは毎秒数百万リクエストの処理に対応し、固定IPアドレスの割り当ても可能です。

ルーティングアルゴリズム​

ELBのトラフィック分散は、ロードバランサーの種類ごとに異なるルーティングアルゴリズムで動作します。

ALBのルーティング​

ALBでは、以下のルーティングアルゴリズムが利用できます。

ラウンドロビンはリクエストを均等に分配するシンプルな方式です。ターゲットの処理能力が均一な場合に有効です。一方、最小未処理リクエスト（Least Outstanding Requests）は、各ターゲットの負荷状況を考慮して振り分けるため、処理時間にばらつきがあるアプリケーションで効果的です。

NLBのルーティング​

NLBではフローハッシュアルゴリズムを使用します。プロトコル、送信元/送信先IPアドレス、送信元/送信先ポート、TCPシーケンス番号をもとにハッシュ値を算出し、ターゲットを決定します。同一の接続元からのリクエストは同じターゲットにルーティングされるため、セッションの一貫性を保つことができます。

CLBのルーティング​

CLBでは、プロトコルに応じて異なるアルゴリズムが適用されます。

• HTTP/HTTPS: ラウンドロビン
• TCP: 最小接続数（Least Connections）

ELBの主要コンポーネント​

ELBは以下の3つの主要コンポーネントで構成されています。

リスナー​

リスナーは、設定されたプロトコルとポートで接続リクエストを受け付けるプロセスです。例えば、ポート443でHTTPSリクエストを受け付け、定義されたルールに基づいてターゲットグループにルーティングします。

ターゲットグループ​

ターゲットグループは、リクエストのルーティング先となるターゲット（EC2インスタンス、コンテナ、IPアドレスなど）の論理的なグループです。ルーティングアルゴリズムやヘルスチェックはターゲットグループ単位で設定します。

ヘルスチェック​

ヘルスチェックは、ターゲットの稼働状態を定期的に確認する仕組みです。HTTP GETリクエストやTCPの接続確認などで応答をチェックし、正常なターゲットにのみトラフィックをルーティングします。異常と判定されたターゲットはルーティング対象から自動的に除外されます。

まとめ​

この記事では、AWSのElastic Load Balancing（ELB）について、基本的な仕組みからロードバランサーの種類、ルーティングアルゴリズム、EC2 Auto Scalingとの連携までを解説しました。ELBはEC2ベースのシステムにおいてトラフィックの最適な分散を実現し、アプリケーションの可用性とリソース効率の向上に寄与するサービスです。ALB、NLB、GLBの3種類の現行ロードバランサーから、ユースケースに応じた選択が可能です。

参考リンク:

• Elastic Load Balancing公式ドキュメント
• Application Load Balancerドキュメント
• Network Load Balancerドキュメント
• EC2 Auto Scaling