LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

実践！AWSネットワーク構築・運用30日チャレンジ: Day 26

Posted at

Day 26: ネットワーク自動化とIaC（Infrastructure as Code）の導入

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 26へようこそ！

昨日はサーバーレスアプリケーションのネットワーク、特にAWS LambdaとAPI GatewayがVPC内でどのように機能するかを学びました。これで、EC2、コンテナ、サーバーレスと、主要なコンピューティングサービスがAWSネットワーク上でどう動くかの全体像が見えてきたことと思います。

これまでの25日間で、あなたはVPC、サブネット、セキュリティグループ、ルーティングテーブル、ロードバランサー、VPN、WAFなど、多くのネットワークコンポーネントを手動で構築してきました。これらの手作業は学習には非常に役立ちましたが、実際の運用環境では、このような手作業はエラーの原因となり、時間の浪費にもつながります。

今日のテーマは、この課題を解決するための強力なアプローチ、「ネットワーク自動化」と「IaC (Infrastructure as Code)」です。IaCを導入することで、ネットワークインフラストラクチャの構築、変更、管理をコードとして扱うことができ、手動作業に伴うリスクを排除し、効率性を劇的に向上させることができます。

1. なぜネットワーク自動化とIaCが必要なのか？

大規模なクラウド環境、特にAWSのようなインフラストラクチャは非常に柔軟で強力ですが、手動での管理には以下のような限界があります。

  • 人為的ミス: 手動設定は、複雑なネットワークでは設定ミスを誘発しやすく、それがサービス停止やセキュリティインシデントにつながる可能性があります。
  • 非一貫性 (Drift): 環境が複数存在する場合（開発、テスト、本番など）、手動設定ではそれぞれの環境間で設定の差異（Configuration Drift）が生じやすく、再現性のあるデプロイが困難になります。
  • 監査性と追跡の困難さ: 手動での変更は、誰が、いつ、何を、なぜ変更したのかを追跡しにくく、監査やコンプライアンス対応の妨げになります。
  • デプロイ速度の限界: 新しい環境のセットアップや変更の適用に時間がかかり、ビジネスの変化に迅速に対応できません。
  • ロールバックの困難さ: 設定ミスが発生した場合、手動で以前の状態に戻すのは非常に困難で時間がかかります。

IaC (Infrastructure as Code) は、これらの課題を解決するためのベストプラクティスです。インフラストラクチャをコードとして定義し、バージョン管理システムで管理することで、ソフトウェア開発の手法をインフラ管理に適用します。

2. IaCの主要なメリット

IaCは、ネットワーク構築を含むクラウドインフラ管理に革命をもたらします。

  • 再現性 (Reproducibility): コードとして定義されているため、いつでも同じ設定で環境を再構築できます。これにより、開発、テスト、本番環境間の一貫性が保たれます。
  • バージョン管理: Gitなどのバージョン管理システムでインフラのコードを管理することで、変更履歴の追跡、変更のレビュー、必要に応じたロールバックが容易になります。
  • 自動化と効率化: コードを実行するだけでインフラが自動的にプロビジョニング・更新されるため、手動作業が不要になり、デプロイや変更の速度が向上します。
  • エラーの削減: コードは自動化ツールによって解釈されるため、人為的な入力ミスが減少します。また、テストを通じて事前にエラーを発見できます。
  • コラボレーション: コードベースでインフラを管理することで、複数のエンジニアが協力してインフラの変更を安全に進められます。
  • ドキュメントとしての機能: コード自体がインフラの構成を明確に記述するため、別途詳細なドキュメントを作成する手間が省け、常に最新の状態を保ちやすいです。

3. AWSにおけるIaCツール

AWS環境でIaCを実現するための主要なツールは以下の通りです。

  1. AWS CloudFormation:

    • AWSネイティブなIaCサービス。YAMLまたはJSON形式のテンプレートでAWSリソースを定義します。
    • テンプレートをデプロイすると、CloudFormationがそのテンプレートに基づいてリソースをプロビジョニングし、更新し、削除します。
    • リソース間の依存関係を自動的に処理し、デプロイの失敗時には自動でロールバックする機能（原子性）があります。
    • メリット: AWSとの連携が非常に強く、新しいAWSサービスや機能への対応が早い。フルマネージドサービスなので、インフラの管理負担が少ない。
    • デメリット: AWSに特化しているため、マルチクラウド戦略には不向き。テンプレートの学習コストがある程度必要。

  2. Terraform by HashiCorp:

    • マルチクラウド対応のIaCツール。AWSだけでなく、Azure、Google Cloud Platform、VMwareなど、様々なクラウドプロバイダやオンプレミスインフラをHCL (HashiCorp Configuration Language) という独自の言語で定義できます。
    • プロバイダのAPIを通じてリソースを操作します。
    • メリット: マルチクラウド環境でのインフラ一元管理に最適。オープンソースでコミュニティが活発。
    • デメリット: ツール自体のインストールと管理が必要。状態管理（terraform.tfstate）の考慮が必要。

  3. AWS CDK (Cloud Development Kit):

    • プログラミング言語でCloudFormationテンプレートを生成するツール。TypeScript, Python, Java, C#, Go などの使い慣れたプログラミング言語でインフラを定義し、最終的にCloudFormationテンプレートにコンパイルしてデプロイします。
    • メリット: 既存のプログラミングスキルを活用できる。より高度なロジックや再利用可能なコンポーネント（Constructs）を構築しやすい。単体テストやIDEのサポートを活用できる。
    • デメリット: プログラミングスキルが必要。学習コストはCloudFormationより高い場合もある。

4. ネットワーク自動化の具体的な実践：CloudFormationによるVPC構築

これまでの学習で手動で構築してきたネットワーク環境を、AWS CloudFormationを使ってコードで定義し、デプロイする手順を体験してみましょう。今回はDay 1のVPC、サブネット、インターネットゲートウェイ、ルートテーブル、セキュリティグループの作成をCloudFormationテンプレートで表現します。

4.1. CloudFormationテンプレートの作成

以下のYAML形式のCloudFormationテンプレートをnetwork-stack.yamlというファイル名で保存してください。

AWSTemplateFormatVersion: '2010-09-09'
Description: My Network Infrastructure with VPC, Subnets, IGW, Route Table, and Security Group

Parameters:
  ProjectName:
    Type: String
    Default: MyChallenge
    Description: Name for the project, used for resource naming.
  VpcCidrBlock:
    Type: String
    Default: 10.0.0.0/16
    Description: CIDR block for the VPC.
  PublicSubnetACidrBlock:
    Type: String
    Default: 10.0.0.0/24
    Description: CIDR block for the public subnet A.
  PrivateSubnetACidrBlock:
    Type: String
    Default: 10.0.1.0/24
    Description: CIDR block for the private subnet A.
  BastionSshCidr:
    Type: String
    Default: 0.0.0.0/0
    Description: CIDR block allowed for SSH to Bastion Host. Set your specific IP for production.

Resources:
  # 1. VPC (Day 1)
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidrBlock
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-VPC"

  # 2. Internet Gateway (Day 1)
  MyInternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-IGW"

  # 3. Attach Internet Gateway to VPC (Day 1)
  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref MyInternetGateway

  # 4. Public Subnet A (Day 1)
  MyPublicSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref PublicSubnetACidrBlock
      AvailabilityZone: !Sub "${AWS::Region}a" # e.g., ap-northeast-1a
      MapPublicIpOnLaunch: true # Automatically assign public IP to instances
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-PublicSubnetA"

  # 5. Private Subnet A (Day 1)
  MyPrivateSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref PrivateSubnetACidrBlock
      AvailabilityZone: !Sub "${AWS::Region}a"
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-PrivateSubnetA"

  # 6. Public Route Table (Day 1)
  MyPublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-PublicRT"

  # 7. Route for Internet Gateway in Public Route Table (Day 1)
  PublicRouteToIGW:
    Type: AWS::EC2::Route
    DependsOn: AttachGateway # Ensure IGW is attached before adding route
    Properties:
      RouteTableId: !Ref MyPublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref MyInternetGateway

  # 8. Associate Public Subnet A with Public Route Table (Day 1)
  AssociatePublicSubnetA:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref MyPublicSubnetA
      RouteTableId: !Ref MyPublicRouteTable

  # 9. Bastion Host Security Group (Day 9 concept)
  BastionSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${ProjectName}-BastionSG"
      GroupDescription: Allow SSH access to bastion host
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref BastionSshCidr # Parameter for your SSH IP
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-BastionSG"

  # 10. Web Server Security Group (Day 13 concept)
  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${ProjectName}-WebServerSG"
      GroupDescription: Allow HTTP from ALB and SSH from Bastion
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          SourceSecurityGroupId: !GetAtt ALBSecurityGroup.GroupId # Assume ALB SG is created by another stack or later
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          SourceSecurityGroupId: !GetAtt BastionSecurityGroup.GroupId
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-WebServerSG"

  # 11. ALB Security Group (Placeholder - actual ALB needs its own stack or this would need more params)
  #    Note: This is a placeholder for demonstration. In a real scenario, you'd integrate this with your ALB stack.
  ALBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${ProjectName}-ALBSG"
      GroupDescription: Allow HTTP/HTTPS from anywhere to ALB
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: !Sub "${ProjectName}-ALBSG"

Outputs:
  VpcId:
    Description: The ID of the new VPC
    Value: !Ref MyVPC
    Export:
      Name: !Sub "${ProjectName}-VPCId"
  PublicSubnetAId:
    Description: The ID of the public subnet A
    Value: !Ref MyPublicSubnetA
    Export:
      Name: !Sub "${ProjectName}-PublicSubnetAId"
  PrivateSubnetAId:
    Description: The ID of the private subnet A
    Value: !Ref MyPrivateSubnetA
    Export:
      Name: !Sub "${ProjectName}-PrivateSubnetAId"
  BastionSecurityGroupId:
    Description: The ID of the Bastion Host Security Group
    Value: !Ref BastionSecurityGroup
    Export:
      Name: !Sub "${ProjectName}-BastionSecurityGroupId"
  WebServerSecurityGroupId:
    Description: The ID of the Web Server Security Group
    Value: !Ref WebServerSecurityGroup
    Export:
      Name: !Sub "${ProjectName}-WebServerSecurityGroupId"
  ALBSecurityGroupId:
    Description: The ID of the ALB Security Group
    Value: !Ref ALBSecurityGroup
    Export:
      Name: !Sub "${ProjectName}-ALBSecurityGroupId"

テンプレートのポイント:

  • AWSTemplateFormatVersionとDescription: テンプレートのバージョンと説明。
  • Parameters: デプロイ時に指定できる変数。CIDRブロックやプロジェクト名などを柔軟に変更できます。BastionSshCidrは、あなたの現在のパブリックIPアドレス/32に設定することを強く推奨します (0.0.0.0/0はセキュリティリスクが高いため)。
  • Resources: 作成したいAWSリソースを定義します。各リソースにはType（リソースの種類）とProperties（設定属性）があります。
  • !Ref: パラメータや他のリソースの論理IDを参照します。例: !Ref MyVPC は、MyVPCという論理IDを持つVPCリソースの物理ID（VPC ID）を参照します。
  • !Sub: 組み込み関数で、文字列内の変数を置き換えます。"${ProjectName}-VPC" は、ProjectNameパラメータの値に置き換えられます。
  • DependsOn: リソースの依存関係を明示的に指定します（例: PublicRouteToIGWはAttachGatewayが完了するまで待機）。
  • Outputs: スタックのデプロイ後に、作成されたリソースのIDなどを外部に出力します。Exportを使用すると、他のCloudFormationスタックからこれらの値を参照できるようになります（クロススタックリファレンス）。
  • セキュリティグループのSourceSecurityGroupId: 他のセキュリティグループからのインバウンドを許可する際に、そのSGのIDを参照します。ここでは!GetAttを使って、このテンプレート内で定義したALBやBastionのSGのIDを参照しています。

4.2. CloudFormationスタックのデプロイ

CloudFormationテンプレートを保存したら、AWSマネジメントコンソールまたはAWS CLIを使ってデプロイします。

AWS CLIを使用する場合:

# 事前にAWS CLIが設定されていることを確認
aws configure

# CloudFormationスタックの作成
aws cloudformation create-stack \
    --stack-name MyNetworkChallengeStack \
    --template-body file://network-stack.yaml \
    --parameters ParameterKey=ProjectName,ParameterValue=MyChallenge \
                 ParameterKey=BastionSshCidr,ParameterValue=あなたの現在のパブリックIPアドレス/32 \
    --capabilities CAPABILITY_IAM # IAMリソースを含む場合（このテンプレートには含まれませんが、一般的なベストプラクティス）
  • --stack-name: 作成するスタックの名前。
  • --template-body file://: テンプレートファイルのパス。
  • --parameters: パラメータの値を指定します。あなたの現在のパブリックIPアドレス/32の部分は、実際にSSHで利用するあなたのグローバルIPアドレスに置き換えてください。
  • --capabilities CAPABILITY_IAM: IAMロールやポリシーなど、IAMリソースがテンプレートに含まれる場合に必要です。このテンプレートには含まれませんが、慣例として付けておくと良いでしょう。

AWSマネジメントコンソールを使用する場合:

  1. AWSマネジメントコンソールで「CloudFormation」サービスを開きます。
  2. 「スタックの作成」をクリックし、「新しいリソース（標準）」を選択します。
  3. テンプレートの指定: 「テンプレートファイルのアップロード」を選択し、「ファイルの選択」からnetwork-stack.yamlをアップロードします。
  4. 「次へ」をクリックします。
  5. スタックの詳細指定:
    • スタックの名前: MyNetworkChallengeStack
    • パラメータ: ProjectNameをMyChallengeに、BastionSshCidrをあなたの現在のパブリックIPアドレス/32に設定します。
  6. 「次へ」をクリックします。
  7. スタックオプションの設定: 必要に応じてタグやロールなどを設定します（今回はスキップでOK）。
  8. 「次へ」をクリックします。
  9. レビュー: 設定内容を確認し、IAMリソースの作成に関する警告が表示されたら「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れます（今回のテンプレートには直接的なIAMリソースはありませんが、念のため）。
  10. 「スタックの作成」をクリックします。

スタックの作成が開始され、数分でVPC、サブネット、IGW、ルートテーブル、セキュリティグループなどが自動的に作成されます。CloudFormationコンソールの「イベント」タブで、各リソースの作成状況を確認できます。

4.3. 作成されたリソースの確認と削除

スタックの作成が完了したら、VPCコンソールなどで作成されたリソース（VPC、サブネット、SGなど）が正しく作成されていることを確認しましょう。名前（Nameタグ）にMyChallengeが含まれているはずです。

スタックの削除:
作成されたリソースをまとめて削除するには、CloudFormationスタックを削除するだけです。

AWS CLIを使用する場合:

aws cloudformation delete-stack --stack-name MyNetworkChallengeStack

AWSマネジメントコンソールを使用する場合:

  1. CloudFormationコンソールでMyNetworkChallengeStackを選択します。
  2. 「削除」ボタンをクリックします。

これにより、CloudFormationがテンプレートで定義されたすべてのリソース（VPC、サブネット、IGWなど）を依存関係を考慮して自動的に削除してくれます。手動で一つずつ削除する手間が省けます。

5. AI時代におけるネットワーク自動化とIaCの活用シナリオ

AI/MLワークロードは、実験的な性質や環境の頻繁な変更が伴うため、IaCは特に重要です。

  • 学習・推論環境の迅速なプロビジョニング:
    • 新しいMLプロジェクトを開始するたびに、学習用VPC、GPUインスタンス、ストレージ（EFS/FSx for Lustre）、PrivateLinkエンドポイントなどをIaCテンプレートで定義し、数分で安全かつ一貫性のある環境をプロビジョニングできます。
  • モデルデプロイメントパイプラインとの統合:
    • CI/CDパイプラインにIaCツールを組み込み、MLモデルの新しいバージョンが準備されるたびに、その推論APIをホストする新しいALB、Lambda関数、EKS Podなどを自動的にデプロイ・更新します。
  • 環境間の再現性の確保:
    • 開発、ステージング、本番といった異なる環境間で、ネットワーク構成（VPC、サブネット、ルーティング、セキュリティグループ、WAFルールなど）をIaCで完全に同一に保ちます。これにより、「開発環境では動いたのに本番では動かない」といった問題を防止し、トラブルシューティングの労力を削減します。
  • セキュリティとコンプライアンスの強制:
    • 組織のセキュリティポリシー（例: 特定のポートのみ開放、SSHは特定のIPからのみ許可）をIaCテンプレートに組み込み、すべてのデプロイ環境で自動的に適用・強制します。これにより、手動ミスによるセキュリティホールを防ぎ、コンプライアンス監査を容易にします。
  • A/Bテストやカナリアリリースの自動化:
    • 新しいMLモデルのA/Bテスト環境をIaCで定義し、Route 53の重み付けルーティングなどの設定変更もコードで管理します。テストが完了したら、以前の環境へのロールバックや、新しい環境への完全移行もIaCで自動的に行えます。

本日のまとめと次へのステップ

今日は、AWSネットワークの構築と運用を効率化・安全化する「ネットワーク自動化」と「IaC (Infrastructure as Code)」について学び、AWS CloudFormationを使ってVPCとその周辺ネットワークリソースをコードでデプロイする実践を行いました。

  • IaCは、人為的ミスの削減、再現性の確保、デプロイ速度の向上、監査性の向上といった多くのメリットをもたらす。
  • AWSにはCloudFormation、Terraform、CDKといった強力なIaCツールがある。
  • ネットワーク構成をコードとして管理し、バージョン管理システムで追跡する重要性を理解した。

これで、あなたはAWSネットワークを手動で構築するスキルに加え、コードを使って自動的にインフラを管理する、より高度なスキルを習得しました。これは、現代のクラウドエンジニアにとって不可欠な能力であり、あなたのキャリアを大きく前進させるでしょう。

明日のDay 27では、「AI/MLワークロードを支えるネットワーク設計の考慮事項」と題して、これまでの学習内容を総動員し、AI/MLアプリケーション特有のネットワーク要件（大容量データ転送、低レイテンシ、セキュリティ、GPUネットワークなど）に焦点を当てた設計のポイントについて学びます。

今日のIaC実践、無事にスタックをデプロイ・削除できましたか？コードでインフラを管理する感覚を掴めましたか？ぜひ「いいね」👍で教えてください！

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?