AWS 面接の質問

AWS 面接で問われる内容

AWS 面接の質問例

• セキュリティグループとネットワークACLの違いを説明し、それぞれを使用する場面を教えてください。
  良い回答が押さえる点

  • Stateful vs stateless: セキュリティグループはステートフル、ネットワークACLはステートレス
  • ルール評価: セキュリティグループは許可ルールのみ、ネットワークACLは許可と拒否の両方
  • 適用範囲: セキュリティグループはインスタンスレベル、ネットワークACLはサブネットレベル
  • デフォルトルール: セキュリティグループは全てのインバウンドを拒否、全てのアウトバウンドを許可；ネットワークACLは全てのインバウンド/アウトバウンドを許可
  • ルール順序: セキュリティグループは全てのルールが評価される；ネットワークACLは番号順に評価され、最初に一致したルールが適用される

  サンプル回答を見る

  セキュリティグループ（SG）とネットワークACL（NACL）はどちらもAWSのファイアウォール機能ですが、いくつかの重要な違いがあります。SGはステートフルで、一度許可された戻りトラフィックは自動的に許可されます。一方、NACLはステートレスで、戻りトラフィックも明示的に許可する必要があります。SGは許可ルールのみを定義でき、すべてのルールが評価されますが、NACLは許可と拒否の両方のルールを持ち、番号順に評価され、最初に一致したルールが適用されます。SGはインスタンスレベル（ENI）で適用され、NACLはサブネットレベルで適用されます。デフォルトでは、SGはすべてのインバウンドトラフィックを拒否し、アウトバウンドは許可しますが、NACLはすべてのトラフィックを許可します。使用場面としては、SGはインスタンスごとの細かいアクセス制御に適しており、例えば特定のインスタンスのみにSSHを許可する場合に使用します。NACLはサブネット全体のトラフィックを制御するのに適しており、例えば特定のIPアドレス範囲からのトラフィックをブロックするために使用します。ただし、NACLはステートレスであるため、戻りトラフィック用のルールも忘れずに追加する必要があります（よくある落とし穴）。また、SGでは拒否ルールを設定できないため、特定のIPをブロックしたい場合にはNACLを使用する必要があります。両方を併用することで、多層防御を実現できます。

• AWS上で高可用性と耐障害性を持つWebアプリケーションを設計してください。コンピューティング、ストレージ、ネットワーキングコンポーネントを含めます。
  良い回答が押さえる点

  • コンピューティング: マルチAZのAuto Scalingグループを持つEC2インスタンス
  • ロードバランシング: クロスゾーン負荷分散が有効なALB（Application Load Balancer）
  • データベース: マルチAZ配置のRDS（例：Amazon Aurora）
  • ストレージ: 静的コンテンツ用のS3バケットとCloudFront CDN
  • ネットワーキング: パブリック/プライベートサブネット、NAT Gateway、VPCエンドポイント

  サンプル回答を見る

  AWS上で高可用性と耐障害性を持つWebアプリケーションを設計するには、複数のアベイラビリティゾーン（AZ）にリソースを分散させることが基本です。コンピューティングにはEC2インスタンスをAuto Scalingグループに配置し、最小/最大インスタンス数を設定して、負荷に応じてスケールさせます。これらのインスタンスをALB（Application Load Balancer）の背後に置き、クロスゾーン負荷分散を有効にしてトラフィックを複数のAZに分散します。ALBはヘルスチェックを行い、異常なインスタンスを自動的に除外します。データベースにはマルチAZ対応のRDS（Aurora推奨）を使用し、プライマリインスタンスがダウンした場合にスタンバイに自動フェイルオーバーします。読み取り負荷が高い場合はリードレプリカを追加します。静的コンテンツ（画像、CSSなど）はS3バケットに保存し、CloudFrontでキャッシュしてユーザーに低レイテンシで配信します。ネットワーキングでは、VPC内にパブリックサブネット（ALB用）とプライベートサブネット（アプリケーションとデータベース用）を用意します。プライベートサブネットからのインターネットアクセスにはNAT Gatewayを使用するか、S3やDynamoDBへのアクセスにはVPCエンドポイントを使います。この設計により、単一AZ障害に耐え、自動スケーリングで負荷変動にも対応できます。ただし、コストと複雑さが増すため、アプリケーションの要件に応じてバランスを取る必要があります。例えば、非クリティカルなアプリケーションではマルチAZを省略することも検討します。

• オンプレミスのモノリシックアプリケーションを最小限のダウンタイムでAWSに移行するにはどうすればよいですか？戦略とツールについて議論してください。
  良い回答が押さえる点

  • 評価と計画: アプリケーションの依存関係をマッピングし、移行パターンを選択
  • ツール: AWS Migration Hub、AWS Server Migration Service (SMS)、AWS Database Migration Service (DMS)、CloudEndure Migration
  • 戦略: リホスト（リフト＆シフト）を基本に、段階的な移行とブルー/グリーンデプロイメントでダウンタイム最小化
  • データ移行: DMSで継続的データレプリケーション（CDC）を使用し、カットオーバー時にダウンタイムを数分に抑える
  • テストとカットオーバー: 移行先環境で徹底的にテストし、Route53加重ルーティングで徐々にトラフィックを切り替える

  サンプル回答を見る

  オンプレミスのモノリシックアプリケーションをAWSに移行する際、最小限のダウンタイムを実現するには、リホスト（リフト＆シフト）戦略が最も現実的です。まず、アプリケーションとその依存関係（データベース、ミドルウェアなど）を徹底的に評価し、移行計画を策定します。AWS Migration Hubを使用して移行を一元管理し、AWS SMS（Server Migration Service）でサーバーイメージを段階的にAWSにレプリケートします。データベースの移行にはAWS DMS（Database Migration Service）を使用し、変更データキャプチャ（CDC）を有効にして、移行中もデータの同期を維持します。カットオーバー時には、ソースデータベースを読み取り専用にして、最終同期を行い、数分以内にターゲットに切り替えます。アプリケーションサーバーは、事前にAMIを作成しておき、Auto Scalingグループに展開します。移行の検証後、Route53の加重ルーティングポリシーを使用して、徐々にトラフィックを新しいAWS環境に移行することで、問題発生時にはすぐにロールバックできます。また、AWS CloudEndure Migrationは、継続的なブロックレベルのレプリケーションを提供し、リフト＆シフトを効率化します。落とし穴として、オンプレミスとAWSのネットワークレイテンシの違いや、ライセンスモデルの変更に注意が必要です。移行後は、段階的にアプリケーションをリファクタリングして、クラウドネイティブなアーキテクチャに進化させることが推奨されます。

• S3イベント通知を処理するLambda関数をPythonで書いてください（例：画像のリサイズ）。ハンドラーとIAMポリシーを示してください。
  良い回答が押さえる点

  • S3イベント通知で画像アップロードをトリガーにLambda関数を起動
  • Lambda関数はPythonで記述し、Pillowライブラリを使用して画像リサイズ
  • 入力：バケット名とキー、出力：リサイズ画像を別のバケットに保存
  • IAMポリシー：LambdaにS3読み取り/書き込み権限とCloudWatch Logs権限が必要
  • エラーハンドリング：try/exceptで例外をキャッチし、ログ出力

  サンプル回答を見る

  以下は、S3バケットに画像がアップロードされた際にLambda関数でリサイズするPythonコードです。Lambda関数はS3イベント通知でトリガーされ、画像をダウンロードして指定サイズにリサイズし、出力先バケットに保存します。IAMポリシーでは、ソースバケットからの読み取りとターゲットバケットへの書き込み、およびCloudWatch Logsへのログ出力権限が必要です。コードにはエラーハンドリングを含め、例外発生時はログに出力します。Lambda関数のタイムアウトは画像サイズに応じて適切に設定してください。

  import boto3
  import os
  from PIL import Image
  import io
  
  s3 = boto3.client('s3')
  
  def lambda_handler(event, context):
      # S3イベントからバケット名とキーを取得
      for record in event['Records']:
          bucket = record['s3']['bucket']['name']
          key = record['s3']['object']['key']
          
          try:
              # 画像ファイルのみ処理
              if not key.lower().endswith(('.png', '.jpg', '.jpeg', '.gif', '.bmp')):
                  print(f"Skipping non-image file: {key}")
                  continue
  
              # S3から画像をダウンロード
              response = s3.get_object(Bucket=bucket, Key=key)
              image_content = response['Body'].read()
              
              # PILで画像を開く
              image = Image.open(io.BytesIO(image_content))
              
              # リサイズ（例: 幅200pxにリサイズ、アスペクト比維持）
              base_width = 200
              w_percent = (base_width / float(image.size[0]))
              h_size = int((float(image.size[1]) * float(w_percent)))
              resized_image = image.resize((base_width, h_size), Image.ANTIALIAS)
              
              # リサイズ画像をバイトストリームに保存
              buffer = io.BytesIO()
              resized_image.save(buffer, format=image.format)
              buffer.seek(0)
              
              # 出力先バケットに保存（元のバケット名＋'-resized'に）
              target_bucket = bucket + '-resized'
              target_key = 'resized/' + key
              s3.put_object(Bucket=target_bucket, Key=target_key, Body=buffer)
              
              print(f"Resized image saved to {target_bucket}/{target_key}")
          except Exception as e:
              print(f"Error processing {key}: {str(e)}")
              raise e

• RDS、DynamoDB、ElastiCacheを比較してください。リアルタイムのリーダーボードにはどれを選びますか？その理由は？
  良い回答が押さえる点

  • RDS: リレーショナルデータベース、ACID準拠、スキーマ固定、SQLクエリ
  • DynamoDB: NoSQLキーバリュー/ドキュメントストア、スキーマレス、自動スケーリング、単一桁ミリ秒のレイテンシ
  • ElastiCache: インメモリキャッシュ、RedisまたはMemcached、サブミリ秒のレイテンシ、ソート済みセットをサポート
  • リアルタイムリーダーボードには、ElastiCache（Redis）のソート済みセットが最適
  • 理由: O(log N)でスコア追加、範囲取得、競合状態の回避、高いスループット

  サンプル回答を見る

  リアルタイムリーダーボードには、ElastiCache（特にRedis）のソート済みセット（Sorted Set）が最適です。ソート済みセットは、スコア順に要素を保持し、ランキングの挿入・更新・範囲取得をO(log N)で実行できます。また、インメモリであるためサブミリ秒のレスポンスが可能で、高い書き込みスループットにも対応できます。RDSはACIDトランザクションが必要な場合に適していますが、リーダーボードのように高頻度の書き込みと読み取りにはスケーリングが難しく、レイテンシも大きくなります。DynamoDBは自動スケーリングと低レイテンシを提供しますが、ランキングの計算（例えば全ユーザーのスコアを並び替えて上位を取得）には苦手で、グローバルセカンダリーインデックスを使ってもコストと複雑さが増します。一方、ElastiCacheにはデータ永続性の欠如という落とし穴がありますが、リーダーボードのような一時的なデータには許容できます。永続性が必要な場合は、定期的にDynamoDBなどにバックアップすることで対応します。したがって、リアルタイムリーダーボードにはElastiCache（Redis）が最も適しています。

• NAT Gatewayの代わりにVPCエンドポイントを使用するシナリオを説明してください。コストとパフォーマンスの点でどのように異なりますか？
  良い回答が押さえる点

  • VPCエンドポイント（ゲートウェイ型）: S3またはDynamoDBへのアクセスをNAT経由せずに、プライベートIPで直接接続
  • NAT Gateway: プライベートサブネットからインターネット（他のAWSサービスも含む）へアクセスするために使用
  • コスト: VPCエンドポイントは時間課金＋データ処理課金（通常NATより安い）、NATは時間課金＋データ処理課金＋データ転送料
  • パフォーマンス: VPCエンドポイントはNATボトルネックがなく、低レイテンシ、ただしS3/DynamoDBのみ
  • シナリオ: プライベートサブネット内のEC2がS3にアクセスする場合、NATではなくVPCエンドポイントを使用するとコスト削減とパフォーマンス向上

  サンプル回答を見る

  VPCエンドポイント（ゲートウェイ型）は、プライベートサブネット内のリソースがインターネット経由せずにS3やDynamoDBにアクセスできるようにするサービスです。これにより、NAT Gatewayを経由する必要がなくなり、コストとパフォーマンスの面でメリットがあります。NAT Gatewayは時間単位の課金（約0.045ドル/時間）に加えて、転送データ量（GBあたり約0.045ドル）の課金が発生します。一方、VPCエンドポイント（ゲートウェイ型）は時間課金がなく、データ処理料金のみ（S3の場合GBあたり約0.01ドル）で、一般的にNATより低コストです。パフォーマンス面では、VPCエンドポイントはAWS内部ネットワークを通るため、NAT Gatewayのようにインスタンスを経由する必要がなく、レイテンシが低く、スループットのボトルネックもありません。ただし、VPCエンドポイントはS3とDynamoDBにしか使用できません。例えば、プライベートサブネットのEC2インスタンスがS3にログを保存する場合や、EMRクラスターがS3からデータを読み取る場合に、NAT Gatewayの代わりにVPCエンドポイントを使用することで、コストを削減し、データ転送速度を向上させることができます。落とし穴として、VPCエンドポイントを使用するにはルートテーブルの更新が必要で、インターネットアクセスが必要な他のトラフィックには別途NATが必要です。また、S3へのアクセスがVPCエンドポイント経由であることをセキュリティグループやバケットポリシーで制限することも可能です。

• S3はPUTおよびDELETE操作に対してどのように強い一貫性を実現しますか？基礎となるモデルを説明してください。
  良い回答が押さえる点

  • 2020年12月以降、S3は全リージョンで強い書き込み後読み取り一貫性を提供
  • PUT: 新しいオブジェクトの書き込み後、直後のGETでそのデータが読み取れる
  • DELETE: オブジェクト削除後、直後のGETで404が返る
  • 基盤モデル: S3はオブジェクトを複数のストレージノードにレプリケートし、メタデータを永続化してから応答を返す
  • 注意: リスト操作（ListObjects）は依然として結果整合性（イベンチュアルコンシステンシ）

  サンプル回答を見る

  S3は2020年12月以降、PUT（新規オブジェクトの書き込み）およびDELETE操作に対して強い一貫性（read-after-write consistency）を提供しています。これは、オブジェクトを書き込んだ直後に発行されるGETリクエストが、そのオブジェクトを確実に返すことを意味します。同様に、DELETEが成功した後は、そのオブジェクトに対するGETは404エラーを返します。この強い一貫性は、S3の内部アーキテクチャによって実現されています。具体的には、S3はオブジェクトを複数のアベイラビリティゾーンにまたがる複数のストレージノードにレプリケートし、すべてのレプリカが正常に保存されたことを確認してから、書き込み成功の応答をクライアントに返します。また、メタデータは一貫性のある方法で管理されています。ただし、バケット内のオブジェクト一覧を取得するListObjects操作や、バケット内のタグなどのメタデータ操作は、依然として結果整合性（eventual consistency）です。そのため、書き込み直後にListObjectsを実行すると、新しいオブジェクトがリストに含まれない可能性があります。このトレードオフにより、S3は高いスケーラビリティとパフォーマンスを維持しながら、ほとんどのユースケースで十分な一貫性を提供しています。

• カスタムセキュリティグループとタグを付けてEC2インスタンスを作成するCloudFormationテンプレートのスニペットを書いてください。
  良い回答が押さえる点

  • リソース: AWS::EC2::Instance と AWS::EC2::SecurityGroup
  • セキュリティグループ: インバウンドルール（SSH, HTTP）を定義
  • EC2インスタンス: セキュリティグループを関連付け、タグを指定
  • パラメータ: ImageId, InstanceType, KeyName などはテンプレートのパラメータ化が推奨
  • 注意: セキュリティグループのルールは適切なCIDRに制限

  サンプル回答を見る

  以下は、カスタムセキュリティグループとタグを持つEC2インスタンスを作成するCloudFormationテンプレートのYAMLスニペットです。このテンプレートでは、セキュリティグループにSSH（ポート22）とHTTP（ポート80）のインバウンドルールを定義し、EC2インスタンスにはKeyName、ImageId、InstanceTypeをパラメータ化しています。また、インスタンスとセキュリティグループの両方にタグを付与しています。

  AWSTemplateFormatVersion: '2010-09-09'
  Description: EC2インスタンスとカスタムセキュリティグループを作成
  Parameters:
    KeyName:
      Type: AWS::EC2::KeyPair::KeyName
      Description: SSH接続用のキーペア名
    InstanceType:
      Type: String
      Default: t2.micro
      AllowedValues:
        - t2.micro
        - t2.small
      Description: EC2インスタンスタイプ
    ImageId:
      Type: AWS::EC2::Image::Id
      Description: AMI ID（例: ami-0c55b159cbfafe1f0）
  Resources:
    WebServerSecurityGroup:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: Webサーバー用セキュリティグループ
        SecurityGroupIngress:
          - IpProtocol: tcp
            FromPort: 22
            ToPort: 22
            CidrIp: 0.0.0.0/0
            Description: SSHアクセス
          - IpProtocol: tcp
            FromPort: 80
            ToPort: 80
            CidrIp: 0.0.0.0/0
            Description: HTTPアクセス
        Tags:
          - Key: Name
            Value: WebServerSG
          - Key: Environment
            Value: Production
    WebServerInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: !Ref InstanceType
        ImageId: !Ref ImageId
        KeyName: !Ref KeyName
        SecurityGroupIds:
          - !Ref WebServerSecurityGroup
        Tags:
          - Key: Name
            Value: WebServer
          - Key: Environment
            Value: Production
      DependsOn: WebServerSecurityGroup

準備方法

• 実践的な練習：EC2、S3、RDSを使って小さなアプリをデプロイし、CloudWatch LogsやVPC Flow Logsを使って壊してデバッグしましょう。
• AWS Well-Architected Frameworkの柱（コスト、パフォーマンス、信頼性、セキュリティ、運用上の優秀性）をマスターし、トレードオフについて議論できるようにしましょう。
• 一般的な設計パターン（マルチAZ、読み取りレプリカ、オートスケーリング、ブルー/グリーンデプロイメント）を理解しましょう。AWS Free Tierを使って実験しましょう。
• 少なくとも1つのInfrastructure as Codeツール（CloudFormation、CDK、Terraform）と1つのスクリプト言語（Python、Node.js）に習熟しましょう。
• AWS re:Inventのセッションと、専門知識を主張するサービスの公式ドキュメントを確認しましょう。面接官は「最新の機能」についてよく質問します。

よくある質問