AWS 면접 질문

AWS 면접에서 다루는 내용

샘플 AWS 면접 질문

• 보안 그룹과 네트워크 ACL의 차이점을 설명하세요. 각각 언제 사용하나요?
  좋은 답변이 다루는 것

  • 보안 그룹은 인스턴스 수준의 상태 저장 방화벽이며, NACL은 서브넷 수준의 상태 비저장 방화벽입니다.
  • 보안 그룹은 허용 규칙만 지원하고, NACL은 허용 및 거부 규칙을 모두 지원합니다.
  • 보안 그룹은 연결 상태를 추적하여 반환 트래픽을 자동으로 허용하지만, NACL은 명시적 규칙이 필요합니다.
  • 보안 그룹은 일반적으로 애플리케이션 계층의 세분화된 액세스 제어에 사용되고, NACL은 서브넷 수준의 추가 방어 계층으로 사용됩니다.
  • NACL은 서브넷 단위로 적용되므로 IP 차단 목록에 유용하며, 보안 그룹은 인스턴스별로 적용되어 유연성이 높습니다.

  샘플 답변 보기

  보안 그룹과 네트워크 ACL은 모두 AWS에서 트래픽을 제어하는 방화벽이지만 작동 방식과 사용 사례에 차이가 있습니다. 보안 그룹은 인스턴스에 연결되는 상태 저장 방화벽으로, 허용 규칙만 지원하며 응답 트래픽을 자동으로 허용합니다. 반면 NACL은 서브넷 수준의 상태 비저장 방화벽으로, 허용 및 거부 규칙을 모두 지원하며 인바운드와 아웃바운드 규칙을 각각 명시해야 합니다. 보안 그룹은 애플리케이션 계층의 세분화된 제어에 적합하여 주로 EC2 인스턴스, RDS 등에 사용됩니다. NACL은 서브넷 전체의 트래픽을 통제하므로 IP 차단 목록이나 서브넷 경계 보안에 효과적입니다. 일반적으로 보안 그룹을 기본 방화벽으로 사용하고 NACL을 추가적인 방어 계층으로 배치합니다. 성능 측면에서 NACL은 규칙 번호 순서로 평가되는 반면 보안 그룹은 모든 규칙을 평가하지만 상태 저장 방식이므로 복잡한 트래픽 흐름에 더 효율적입니다. 두 가지를 함께 사용할 때는 규칙 충돌 가능성을 고려해야 하며, ACL 규칙 번호 관리에 주의해야 합니다.

• AWS에서 고가용성 및 내결함성을 가진 웹 애플리케이션을 설계하세요. 컴퓨팅, 스토리지 및 네트워킹 구성 요소를 포함하세요.
  좋은 답변이 다루는 것

  • 여러 가용 영역에 걸쳐 EC2 인스턴스를 배포하고 Auto Scaling을 사용하여 트래픽 변화에 대응합니다.
  • ELB(Application Load Balancer)를 앞단에 두어 트래픽을 분산하고 상태 확인을 수행합니다.
  • RDS Multi-AZ를 사용하여 데이터베이스 고가용성을 확보하고, 읽기 전용 복제본을 추가할 수 있습니다.
  • S3를 정적 콘텐츠 저장소로 사용하고 CloudFront로 캐싱하여 지연 시간을 줄입니다.
  • 스토리지는 EBS 볼륨을 사용하되 스냅샷을 정기적으로 생성하고, 필요시 S3로 백업합니다.

  샘플 답변 보기

  고가용성 및 내결함성 웹 애플리케이션을 설계하려면 AWS의 여러 서비스를 조합해야 합니다. 먼저 컴퓨팅 계층에서는 두 개 이상의 가용 영역에 EC2 인스턴스를 배포하고, Auto Scaling 그룹을 구성하여 인스턴스 수를 자동으로 조정합니다. Application Load Balancer를 앞단에 배치하여 트래픽을 여러 가용 영역의 인스턴스로 분산하고, 상태 확인을 통해 비정상 인스턴스를 자동으로 제거합니다. 데이터베이스 계층에서는 RDS Multi-AZ를 사용하여 기본 데이터베이스 장애 시 자동 장애 조치를 지원합니다. 또한 읽기 트래픽이 많다면 읽기 전용 복제본을 추가할 수 있습니다. 정적 콘텐츠(이미지, CSS 등)는 S3에 저장하고 CloudFront로 전 세계 엣지 로케이션에서 캐싱하여 지연 시간을 줄입니다. 스토리지 측면에서 EC2 인스턴스는 EBS 볼륨을 사용하며, 중요 데이터는 정기적인 스냅샷을 S3에 저장하고 필요시 S3 Standard-IA와 같은 스토리지 클래스를 사용하여 비용을 최적화합니다. 네트워킹에서는 VPC 내에 퍼블릭 서브넷(ALB, NAT Gateway)과 프라이빗 서브넷(EC2, RDS)을 구성하고, 보안 그룹과 NACL로 접근을 제어합니다. 각 구성 요소의 단일 실패 지점을 제거하고, 모든 계층에서 중복성을 확보하는 것이 핵심입니다. 피해야 할 함정은 단일 가용 영역에만 의존하거나, 데이터베이스의 쓰기 성능을 고려하지 않고 Multi-AZ만 선택하는 것입니다. 또한 상태 저장 애플리케이션의 경우 세션 관리를 ElastiCache나 DynamoDB로 분리해야 합니다.

• 최소 다운타임으로 모놀리식 온프레미스 애플리케이션을 AWS로 마이그레이션하려면 어떻게 해야 하나요? 전략과 도구에 대해 논의하세요.
  좋은 답변이 다루는 것

  • 단계적 마이그레이션(strangler fig 패턴)을 통해 점진적으로 기능을 전환합니다.
  • AWS Database Migration Service(DMS)를 사용하여 데이터베이스를 지속적으로 복제하고 전환 시 최소 다운타임을 달성합니다.
  • Application Migration Service(MGN)를 사용하여 서버를 리프트 앤 시프트로 마이그레이션할 수 있습니다.
  • Route 53 가중치 라우팅을 사용하여 트래픽을 온프레미스와 AWS 간에 점진적으로 분산합니다.
  • 마이그레이션 전에 철저한 테스트와 롤백 계획을 수립해야 합니다.

  샘플 답변 보기

  최소 다운타임으로 모놀리식 온프레미스 애플리케이션을 AWS로 마이그레이션하려면 점진적인 접근 방식이 필요합니다. 가장 일반적인 전략은 'strangler fig' 패턴을 적용하여 애플리케이션의 일부 기능을 먼저 AWS로 이전하고, 나머지는 점진적으로 마이그레이션하는 것입니다. 데이터베이스 마이그레이션에는 AWS Database Migration Service(DMS)를 활용하여 지속적인 복제를 통해 온프레미스와 AWS 간의 동기화를 유지하고, 전환 시점에 복제 지연을 최소화합니다. 서버 마이그레이션에는 AWS Application Migration Service(MGN)를 사용하여 서버 이미지를 리프트 앤 시프트 방식으로 이전할 수 있으며, 이는 전체 서버 복제를 통해 다운타임을 짧게 유지합니다. 트래픽 전환은 Amazon Route 53의 가중치 기반 라우팅을 사용하여 점차 AWS 환경으로 유입되는 트래픽을 증가시킵니다. 또한 마이그레이션 전에 애플리케이션의 AWS 호환성을 확인하고, 철저한 성능 테스트와 롤백 계획을 수립해야 합니다. 잠재적 함정으로는 데이터 일관성 유지, 레거시 종속성, 라이선스 비용, 네트워크 지연 시간 증가 등이 있으므로 마이그레이션 후 모니터링과 최적화가 필요합니다. CloudEndure나 VM Import/Export와 같은 도구도 고려할 수 있습니다.

• S3 이벤트 알림을 처리하는 Lambda 함수를 Python으로 작성하세요(예: 이미지 크기 조정). 핸들러와 IAM 정책을 보여주세요.
  좋은 답변이 다루는 것

  • Lambda 함수는 S3 버킷에서 발생하는 PUT 이벤트(이미지 업로드)에 의해 트리거됩니다.
  • 핸들러는 boto3를 사용하여 S3에서 이미지 객체를 다운로드하고, Pillow 라이브러리로 크기를 조정한 후 결과를 다른 버킷에 업로드합니다.
  • IAM 정책은 Lambda 실행 역할에 S3 버킷 읽기/쓰기 권한과 CloudWatch Logs 쓰기 권한을 부여해야 합니다.
  • Lambda 함수의 제한 사항(메모리, 시간 제한)을 고려하여 이미지 크기와 리소스를 적절히 설정합니다.

  샘플 답변 보기

  S3 이벤트 알림으로 이미지 리사이즈 Lambda 함수를 구현할 때, 먼저 Lambda 함수가 S3 버킷의 'ObjectCreated' 이벤트를 트리거하도록 설정합니다. 핸들러는 Python과 boto3를 사용하여 이벤트에서 버킷 이름과 객체 키를 추출하고, S3 get_object로 원본 이미지를 다운로드합니다. Pillow(PIL) 라이브러리를 사용하여 이미지를 열고, thumbnail 메서드로 지정된 크기로 리사이즈한 후, 결과 이미지를 바이트로 변환하여 다른 S3 버킷에 put_object로 업로드합니다. Lambda 함수의 실행 역할에는 원본 버킷에 대한 GetObject 권한, 대상 버킷에 대한 PutObject 권한, 그리고 CloudWatch Logs에 대한 CreateLogGroup/Stream/PutLogEvents 권한이 있는 IAM 정책이 필요합니다. 또한 Lambda의 메모리와 제한 시간을 이미지 처리에 맞게 충분히 설정해야 하며, 큰 이미지의 경우 메모리를 많이 사용할 수 있으므로 주의해야 합니다. 에러 처리와 로깅을 추가하고, S3 이벤트 알림 구성 시 접두사/접미사 필터를 사용하여 불필요한 트리거를 방지할 수 있습니다. Lambda가 VPC 내에 있지 않다면 S3 엔드포인트에 접근 가능해야 합니다. 다음은 핸들러 코드와 IAM 정책 예시입니다.

  import boto3
  import os
  from PIL import Image
  import io
  
  s3 = boto3.client('s3')
  TARGET_BUCKET = os.environ['TARGET_BUCKET']
  TARGET_SIZE = (300, 300)  # 리사이즈할 크기
  
  def lambda_handler(event, context):
      for record in event['Records']:
          source_bucket = record['s3']['bucket']['name']
          key = record['s3']['object']['key']
          
          # 이미지 다운로드
          response = s3.get_object(Bucket=source_bucket, Key=key)
          image_data = response['Body'].read()
          
          # 이미지 리사이즈 (Pillow 사용)
          try:
              image = Image.open(io.BytesIO(image_data))
              image.thumbnail(TARGET_SIZE, Image.ANTIALIAS)
          except Exception as e:
              print(f"이미지 처리 오류: {e}")
              raise e
          
          # 리사이즈된 이미지를 바이트로 변환
          buffer = io.BytesIO()
          image.save(buffer, format=image.format if image.format else 'JPEG')
          buffer.seek(0)
          
          # 대상 버킷에 업로드
          target_key = f"resized/{key}"
          s3.put_object(Bucket=TARGET_BUCKET, Key=target_key, Body=buffer, ContentType=response['ContentType'])
          
          print(f"이미지 리사이즈 완료: {key} -> {target_key}")
          
      return {
          'statusCode': 200,
          'body': '이미지 리사이즈 완료'
      }

• RDS, DynamoDB, ElastiCache를 비교하세요. 실시간 리더보드의 경우 어떤 것을 선택하고 그 이유는 무엇인가요?
  좋은 답변이 다루는 것

  • RDS는 관계형 데이터베이스, DynamoDB는 NoSQL(키-값/문서), ElastiCache는 인메모리 캐시입니다.
  • RDS는 SQL 조인이 필요하고 데이터 무결성이 중요한 트랜잭션에 적합합니다.
  • DynamoDB는 읽기/쓰기가 빈번하고 확장성이 중요한 애플리케이션에 최적화되어 있습니다.
  • ElastiCache는 매우 낮은 지연 시간이 필요한 실시간 데이터 액세스(예: 리더보드)에 사용됩니다.
  • 실시간 리더보드의 경우 쓰기 빈도가 높고 빠른 읽기가 필요하므로 ElastiCache(Redis)가 적합하며, DynamoDB DAX와 조합하여 사용할 수도 있습니다.

  샘플 답변 보기

  RDS, DynamoDB, ElastiCache는 각각 다른 용도에 최적화된 데이터베이스 서비스입니다. RDS는 MySQL, PostgreSQL, SQL Server 등 관계형 데이터베이스 관리 서비스로, 조인, 트랜잭션, 데이터 무결성이 중요한 워크로드에 적합하지만 확장 시 다운타임이 발생할 수 있습니다. DynamoDB는 완전관리형 NoSQL 데이터베이스로, 키-값 및 문서 구조를 지원하며, 자동 확장과 초당 수백만 건의 요청을 처리할 수 있어 게임, IoT, 실시간 애플리케이션에 좋습니다. ElastiCache는 Redis 또는 Memcached를 기반으로 하는 인메모리 캐시 서비스로, 마이크로초 단위의 지연 시간으로 데이터를 제공합니다. 실시간 리더보드의 경우 Redis의 정렬된 셋(Sorted Set)을 사용하면 점수 순위를 즉시 조회할 수 있고, 쓰기 성능도 뛰어납니다. DynamoDB도 DAX(DynamoDB Accelerator)를 사용하면 캐싱을 통해 지연 시간을 줄일 수 있지만, ElastiCache가 더 낮은 지연 시간과 유연한 데이터 구조(Set, Sorted Set 등)를 제공하므로 실시간 리더보드에는 ElastiCache(Redis)가 가장 적합합니다. 또한 ElastiCache는 데이터를 메모리에만 저장하므로 영구성이 필요한 경우 DynamoDB를 백업 저장소로 사용하는 조합도 가능합니다. 비용 측면에서 ElastiCache는 메모리 기반이라 대용량 데이터에 비용이 많이 들 수 있으므로, 리더보드의 데이터 크기를 신중히 고려해야 합니다.

• NAT 게이트웨이 대신 VPC 엔드포인트를 사용하는 시나리오를 설명하세요. 비용과 성능 면에서 어떻게 다른가요?
  좋은 답변이 다루는 것

  • VPC 엔드포인트는 인터넷 게이트웨이를 통하지 않고 AWS 서비스(S3, DynamoDB)에 비공개로 접근할 수 있습니다.
  • NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷에 아웃바운드로 접근할 때 사용됩니다.
  • VPC 엔드포인트를 사용하면 데이터 전송 비용이 절감되고, 데이터가 AWS 네트워크 내에서만 전송되어 보안이 향상됩니다.
  • NAT 게이트웨이는 시간당 요금과 데이터 처리 요금이 발생하며, 가용 영역별로 배포해야 합니다.
  • S3나 DynamoDB에만 접근해야 하는 워크로드는 VPC 엔드포인트가 더 적합하고, 일반 인터넷 접근이 필요하면 NAT 게이트웨이가 필요합니다.

  샘플 답변 보기

  VPC 엔드포인트와 NAT 게이트웨이는 모두 VPC와 외부 서비스 간의 연결을 제공하지만 목적과 동작이 다릅니다. VPC 엔드포인트는 인터넷 게이트웨이, NAT, VPN 등을 거치지 않고 AWS 서비스(S3, DynamoDB, SQS 등)에 프라이빗하게 연결할 수 있게 해줍니다. 이는 데이터가 AWS 네트워크를 벗어나지 않으므로 보안이 강화되고, 인터넷 대역폭 비용이 발생하지 않아 비용이 절감됩니다(엔드포인트 자체 요금은 시간당 및 처리량 기준). 반면 NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷에 아웃바운드로 접근할 수 있도록 해주며, 시간당 요금과 데이터 처리 요금이 부과됩니다. 또한 고가용성을 위해 각 가용 영역에 하나씩 배포하는 것이 좋습니다. S3에만 접근해야 하는 워크로드(예: 데이터 백업, 로그 전송)는 VPC 엔드포인트를 사용하는 것이 비용 효율적이고 안전합니다. 그러나 인터넷을 통해 패키지 업데이트, 외부 API 호출 등이 필요한 경우 NAT 게이트웨이가 필요합니다. 성능 측면에서 VPC 엔드포인트는 AWS 내부 네트워크를 사용하므로 지연 시간이 짧고 대역폭이 높지만, NAT 게이트웨이는 인터넷 경유로 인해 추가 지연이 발생할 수 있습니다. 두 서비스를 함께 사용할 수도 있으며, 비용 분석 시 데이터 전송량과 가용 영역 수를 고려해야 합니다.

• S3는 PUT 및 DELETE 작업에 대해 어떻게 강한 일관성을 달성하나요? 기본 모델을 설명하세요.
  좋은 답변이 다루는 것

  • S3는 2020년 12월 이후 모든 객체에 대해 강한 일관성을 제공합니다.
  • 이전에는 최종 일관성을 제공했지만, 내부적으로 복제 지연을 해결하여 읽기 후 쓰기 일관성을 보장합니다.
  • PUT 및 DELETE 작업 후 즉시 GET, LIST, HEAD 요청이 최신 결과를 반환합니다.
  • 이는 S3의 분산 시스템이 여러 복제본 간 동기화를 유지하고, 쓰기 작업이 완료된 후에만 읽기 요청을 처리하도록 설계되었기 때문입니다.
  • 강한 일관성 덕분에 애플리케이션에서 별도의 캐시 무효화 로직이 필요하지 않게 되었습니다.

  샘플 답변 보기

  Amazon S3는 2020년 12월 이전에는 새 객체 쓰기(PUT) 후 최종 일관성을 제공했지만, 이후 모든 리전에서 모든 객체(기존 및 신규)에 대해 강한 일관성을 제공합니다. 이는 PUT 요청이 성공적으로 완료된 후에 GET, LIST, HEAD 요청이 항상 최신 데이터를 반환함을 의미합니다. DELETE 작업도 마찬가지로, 객체를 삭제한 직후 GET 요청은 404(Not Found)를 반환합니다. 이러한 강한 일관성은 S3의 내부 아키텍처 변경을 통해 달성되었습니다. S3는 여러 복제본을 유지하며, 쓰기 작업이 모든 복제본에 커밋된 후에만 완료 응답을 반환합니다. 읽기 요청은 복제본 중 하나를 조회하지만, 쓰기 작업이 완료되기 전에는 읽기 요청을 처리하지 않도록 조정되었습니다. 따라서 애플리케이션 개발자는 이전처럼 최종 일관성으로 인한 지연 시간이나 복제 불일치를 걱정할 필요가 없습니다. 그러나 강한 일관성으로 인해 쓰기 처리량에 영향을 줄 수 있으므로 매우 높은 쓰기 요구사항이 있는 경우 S3의 성능 특성을 이해하는 것이 중요합니다.

• 사용자 정의 보안 그룹과 태그가 있는 EC2 인스턴스를 생성하는 CloudFormation 템플릿 스니펫을 작성하세요.
  좋은 답변이 다루는 것

  • CloudFormation 템플릿은 YAML 또는 JSON으로 작성하며, Resources 섹션에 EC2 인스턴스, 보안 그룹, 태그를 정의합니다.
  • EC2 인스턴스 리소스는 AWS::EC2::Instance 유형이며, ImageId, InstanceType, SecurityGroupIds, Tags 등의 속성을 설정합니다.
  • 보안 그룹은 AWS::EC2::SecurityGroup 유형으로, 인바운드 규칙을 정의합니다.
  • 태그는 Key-Value 쌍으로 정의하며, EC2 인스턴스와 보안 그룹 모두에 적용할 수 있습니다.
  • VPC와 서브넷을 지정하거나 기본 VPC를 사용할 수 있으며, 필요에 따라 사용자 지정 VPC를 참조합니다.

  샘플 답변 보기

  CloudFormation 템플릿을 사용하여 EC2 인스턴스와 보안 그룹을 생성하려면 YAML 형식으로 리소스를 선언합니다. 먼저 'Resources' 섹션에 보안 그룹 리소스(AWS::EC2::SecurityGroup)를 정의하고, 인바운드 규칙으로 예를 들어 HTTP(80)와 SSH(22)를 허용합니다. 그런 다음 EC2 인스턴스 리소스(AWS::EC2::Instance)에서 ImageId(예: Amazon Linux 2 AMI), InstanceType(예: t2.micro), SecurityGroupIds를 위에서 생성한 보안 그룹의 참조(!Ref MySecurityGroup)로 설정합니다. Tags 속성은 Key-Value 형태의 리스트로, 예를 들어 Name, Environment 등의 태그를 추가합니다. 템플릿은 파라미터와 출력 섹션을 포함하여 유연성을 높일 수 있습니다. 주의할 점은 기본 VPC가 아닌 특정 VPC에 리소스를 배포하려면 VPC와 서브넷을 명시적으로 지정해야 하며, SecurityGroup 리소스에 VpcId 속성을 추가해야 합니다. 또한 SSM 파라미터 스토어나 Secrets Manager를 사용하여 민감한 정보를 안전하게 처리할 수 있습니다.

  AWSTemplateFormatVersion: '2010-09-09'
  Description: 'EC2 인스턴스와 사용자 정의 보안 그룹 생성 템플릿'
  Resources:
    MySecurityGroup:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: 'SSH 및 HTTP 접근 허용'
        SecurityGroupIngress:
          - IpProtocol: tcp
            FromPort: 22
            ToPort: 22
            CidrIp: '0.0.0.0/0'
          - IpProtocol: tcp
            FromPort: 80
            ToPort: 80
            CidrIp: '0.0.0.0/0'
        Tags:
          - Key: Name
            Value: 'MyWebServerSG'
    MyEC2Instance:
      Type: AWS::EC2::Instance
      Properties:
        ImageId: 'ami-0abcdef1234567890'  # 실제 AMI ID로 변경 필요
        InstanceType: 't2.micro'
        SecurityGroupIds:
          - !Ref MySecurityGroup
        Tags:
          - Key: Name
            Value: 'MyWebServer'
          - Key: Environment
            Value: 'Production'

준비 방법

• 실습: EC2, S3, RDS를 사용하여 작은 앱을 배포하세요. 고장을 내고 CloudWatch Logs와 VPC Flow Logs로 디버깅하세요.
• AWS Well-Architected Framework의 핵심 기둥(비용, 성능, 안정성, 보안, 운영 우수성)을 마스터하고 트레이드오프를 논의할 준비를 하세요.
• 일반적인 설계 패턴을 이해하세요: 멀티 AZ, 읽기 복제본, 오토 스케일링, 블루/그린 배포. AWS Free Tier를 사용하여 실험하세요.
• 적어도 하나의 Infrastructure as Code 도구(CloudFormation, CDK, Terraform)와 하나의 스크립팅 언어(Python, Node.js)에 능숙해지세요.
• AWS re:Invent 세션과 자신이 전문 분야로 주장하는 서비스의 공식 문서를 검토하세요. 면접관은 종종 '최신 기능'에 대해 묻습니다.

자주 묻는 질문