「動くけどAWS Well-Architected じゃない」環境をAIに作らせ、直すことでベストプラクティスを学んでみた

AWSTemplateFormatVersion: '2010-09-09'
Description: >
  Well-Architected Anti-Pattern Challenge.
  This template contains anti-patterns that violate Well-Architected best practices.
  Find and fix them using the AWS Management Console.

Parameters:
  LatestAmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  ChallengeVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true

  PrivateSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref ChallengeVPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']

  PrivateSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref ChallengeVPC
      CidrBlock: 10.0.2.0/24
      AvailabilityZone: !Select [1, !GetAZs '']

  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref ChallengeVPC

  PrivateSubnetARouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnetA
      RouteTableId: !Ref PrivateRouteTable

  PrivateSubnetBRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnetB
      RouteTableId: !Ref PrivateRouteTable

  EC2SecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: EC2 Security Group - No inbound access
      VpcId: !Ref ChallengeVPC
      SecurityGroupIngress: []
      SecurityGroupEgress:
        - IpProtocol: '-1'
          CidrIp: 10.0.0.0/16

  RDSSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: RDS Security Group - VPC internal only
      VpcId: !Ref ChallengeVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          SourceSecurityGroupId: !Ref EC2SecurityGroup
      SecurityGroupEgress:
        - IpProtocol: '-1'
          CidrIp: 10.0.0.0/16

  ChallengeBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Delete
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  AccessLogBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Delete
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: OverlyPermissivePolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action: '*'
                Resource: '*'

  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - !Ref EC2Role

  ChallengeInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: !Ref LatestAmiId
      SubnetId: !Ref PrivateSubnetA
      SecurityGroupIds:
        - !Ref EC2SecurityGroup
      IamInstanceProfile: !Ref EC2InstanceProfile
      PropagateTagsToVolumeOnCreation: true
      BlockDeviceMappings:
        - DeviceName: /dev/xvda
          Ebs:
            VolumeSize: 20
            VolumeType: gp2
            Encrypted: false
            DeleteOnTermination: true

  RDSSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: Challenge RDS Subnet Group
      SubnetIds:
        - !Ref PrivateSubnetA
        - !Ref PrivateSubnetB

  ChallengeDB:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Delete
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: mysql
      EngineVersion: '8.0'
      MasterUsername: admin
      MasterUserPassword: ChallengePw123!
      AllocatedStorage: '20'
      DBSubnetGroupName: !Ref RDSSubnetGroup
      VPCSecurityGroups:
        - !Ref RDSSecurityGroup
      PubliclyAccessible: false
      MultiAZ: false
      BackupRetentionPeriod: 0
      StorageEncrypted: false

  ChallengeTable:
    Type: AWS::DynamoDB::Table
    DeletionPolicy: Delete
    Properties:
      TableName: ChallengeTable
      AttributeDefinitions:
        - AttributeName: PK
          AttributeType: S
      KeySchema:
        - AttributeName: PK
          KeyType: HASH
      BillingMode: PROVISIONED
      ProvisionedThroughput:
        ReadCapacityUnits: 100
        WriteCapacityUnits: 100

  ChallengeLogGroup:
    Type: AWS::Logs::LogGroup
    DeletionPolicy: Delete
    Properties:
      LogGroupName: /challenge/application

  FlowLogsLogGroup:
    Type: AWS::Logs::LogGroup
    DeletionPolicy: Delete
    Properties:
      LogGroupName: /vpc/flow-logs

Outputs:
  VPCId:
    Value: !Ref ChallengeVPC
  FlowLogsLogGroupName:
    Value: !Ref FlowLogsLogGroup
  S3BucketName:
    Value: !Ref ChallengeBucket
  AccessLogBucketName:
    Value: !Ref AccessLogBucket
  EC2InstanceId:
    Value: !Ref ChallengeInstance
  RDSEndpoint:
    Value: !GetAtt ChallengeDB.Endpoint.Address
  DynamoDBTableName:
    Value: !Ref ChallengeTable

誰がいつバケットにアクセスしたかを追跡するための設定を確認してください。S3バケットのプロパティを見てみましょう。

S3のサーバーアクセスログが無効になっています。バケットへのアクセスを監査できません。

• Amazon S3 サーバーアクセスログ

S3コンソール → バケットを選択 → 「プロパティ」→ 「サーバーアクセスのログ記録」を編集 →  「有効にする」を選択し、ログの送信先にスタックで作成済みのアクセスログ用バケット（AccessLogBucket）を指定してください。

• サーバーアクセスログの有効化

リソースの管理・追跡・コスト配分に必要な基本的な設定が欠けています。複数のリソースに共通する問題です。

すべてのリソースにタグが一切付いていません。

• AWS リソースのタグ付けのベストプラクティス

全リソースに Environment, Project, Owner 等のタグを追加してください。各リソースのコンソール画面 → 「タグ」タブから追加できます。

注意:タグエディタで一括タグ付けする場合、リソースタイプでフィルタしてチャレンジのリソースだけを選択してください。アカウント内の全リソースを対象にするとAPIレート制限に抵触したり、マネージドルールなどタグ変更が禁止されているリソースでエラーになります。

• タグエディタを使用したタグの管理

障害時のデータ復旧に関するベストプラクティスを確認してください。RDSの設定を見てみましょう。

RDSの自動バックアップが無効になっています（バックアップ保持期間が0日）。

• Amazon RDS バックアップの操作

RDSコンソール → インスタンスを選択 → 「変更」→ 「バックアップ保持期間」を1日以上（推奨: 7日）に設定してください。

• 自動バックアップの有効化

IAMのアクセス権限に関するベストプラクティスを確認してください。EC2に割り当てられたロールのポリシーを見てみましょう。

EC2ロールのポリシーが Action: "*", Resource: "*" で全権限を許可しています。

• IAM でのセキュリティのベストプラクティス

IAMコンソール → ロール → EC2ロールを選択 → OverlyPermissivePolicy を編集し、必要なアクション/リソースのみに絞ってください。当チャレンジではEC2に特定の用途がないため、インラインポリシー OverlyPermissivePolicy を削除するか、AWS管理ポリシーAWSDenyAll をアタッチして全アクションを拒否する方法でも正解です。

• IAM ポリシーの作成

単一障害点の排除に関するベストプラクティスを確認してください。

RDSがSingle-AZ構成で、AZ障害時にフェイルオーバーできません。

• Amazon RDS の高可用性 (マルチ AZ)

RDSコンソール → インスタンスを選択 → 「変更」→ 「可用性と耐久性」セクションで「マルチAZデプロイメント」を「スタンバイインスタンスを作成する」に変更してください。

• マルチ AZ DB インスタンスのデプロイの変更

データの誤削除からの保護に関するベストプラクティスを確認してください。

S3バケットのバージョニングが無効で、オブジェクトの誤削除から復旧できません。

• S3 バージョニングの使用

S3コンソール → バケットを選択 → 「プロパティ」→ 「バージョニング」を「有効」に変更してください。

• バケットでのバージョニングの有効化

ネットワークトラフィックの監査・可視化に関するベストプラクティスを確認してください。

VPCフローログが無効で、ネットワークトラフィックの監査ができません。

• VPC フローログ
• SEC04-BP01 Configure service and application logging

VPCコンソール → VPCを選択 → 「フローログ」タブ → 「フローログを作成」で以下を設定してください:

• 名前 – オプション: 任意（空欄でもOK）
• フィルタ: すべて
• 最大集約間隔: 10分（デフォルトのまま）
• 送信先: CloudWatch Logsに送信
• 送信先ロググループ: スタックで作成済みの /vpc/flow-logs を選択
• IAMロール: 「Set Up Permissions」から新規作成、または既存のフローログ用ロールを選択
• ログレコードの形式: AWSのデフォルト形式（デフォルトのまま）
• 追加のメタデータ: なし（デフォルトのまま）

• フローログの作成

ストレージの世代選択とデータ保護の2つの観点で確認してください。

2つの問題があります:

1. EBSがgp2（旧世代）で、gp3の方がコスト効率が良い
2. EBSの暗号化が無効

• gp2 から gp3 への移行

gp2→gp3の変更: EC2コンソール → ボリューム → ボリュームを選択 → 「変更」→ タイプをgp3に変更 → 「変更」をクリック。

暗号化の対応: 既存ボリュームでは暗号化を直接有効にできないため、以下の手順が必要です:

1. EC2コンソール → インスタンス → 対象インスタンスを「停止」する
2. ボリューム → 対象ボリュームを選択 → 「スナップショットを作成」
3. スナップショット → 作成したスナップショットを選択 → 「スナップショットをコピー」→ 「暗号化」にチェック → コピー
4. 暗号化済みスナップショットを選択 → 「スナップショットからボリュームを作成」→ AZを元のボリュームと同じにする
5. 元のボリュームをインスタンスからデタッチ
6. 暗号化済みボリュームをインスタンスにアタッチ（デバイス名: /dev/xvda）
7. インスタンスを起動

暗号化の手順は複雑なため、gp2→gp3の変更だけでも正解とします。

• EBS ボリュームの変更

データベースのキャパシティ管理とコスト効率に関するベストプラクティスを確認してください。

DynamoDBがプロビジョンドモードで過剰なRCU/WCU（各100）が設定されており、Auto Scalingも無効です。

• DynamoDB on-demand capacity mode
• DynamoDB Well-Architected Lens

DynamoDBコンソール → テーブルを選択 → 「追加の設定」→ 「読み込み/書き込みキャパシティ」セクションの「編集」をクリック。
以下のいずれかを実施してください:

方法1: オンデマンドモードに変更（推奨）

1. キャパシティモードを「オンデマンド」に変更
2. 「変更を保存」をクリック

方法2: Auto Scalingを有効化

1. キャパシティモードは「プロビジョンド」のまま
2. 読み込みキャパシティ: 「Auto Scaling」をオン → 最小キャパシティを1〜5程度に設定
3. 書き込みキャパシティ: 同様に「Auto Scaling」をオン → 最小キャパシティを1〜5程度に設定
4. 「変更を保存」をクリック

• DynamoDB Auto Scaling