[AWS-SAA] 개념정리 및 문제풀이 8일차

개념정리

1. AWS Transit Gateway

• 개념 : 여러 VPC, 온프레미스 데이터 센터, 또는 외부 네트워크를 중앙에서 연결하고 관리할 수 있는 서비스입니다. 이를 통해 네트워크 간 연결을 더 효율적으로 설정하고 관리할 수 있습니다.
• 주요 특징:
  • 중앙 허브 역할: 여러 VPC 또는 온프레미스 네트워크가 하나의 Transit Gateway를 통해 연결되므로, 네트워크 복잡도를 줄이고 중앙에서 관리가 가능합니다.
  • 확장성: AWS Transit Gateway는 수백 개의 VPC 및 여러 온프레미스 네트워크를 연결할 수 있어, 대규모 네트워크 환경에서 유용합니다.
  • 경로 설정: Transit Gateway는 각 연결된 네트워크 간의 트래픽 흐름을 제어할 수 있는 경로 테이블을 사용하여 라우팅을 설정합니다.
  • 다양한 연결 지원: VPC, AWS Direct Connect, Site-to-Site VPN을 비롯한 다양한 연결 옵션을 지원하며, 서로 다른 네트워크 간의 트래픽을 통합하여 관리할 수 있습니다.
• 사용 사례:
  • 여러 VPC와 온프레미스 네트워크를 하나의 허브에서 관리해야 할 때.
  • 여러 AWS 리전 간의 VPC를 연결해야 할 때.
  • 대규모 네트워크 아키텍처에서 복잡성을 줄이고, 중앙화된 네트워크 관리가 필요한 경우.
• 비용 : 상대적으로 높음

2. AWS Site-to-Site VPN

• 개념 : AWS VPC와 온프레미스 네트워크(또는 다른 AWS VPC) 간의 안전한 IPsec VPN 연결을 제공하는 서비스입니다.
• 주요 특징:
  • 보안 연결: Site-to-Site VPN은 인터넷을 통해 데이터를 전송하면서도 IPsec 프로토콜을 사용해 데이터를 암호화하여 보안을 보장합니다.
  • 온프레미스와 AWS 연결: 주로 온프레미스 데이터 센터와 AWS 클라우드를 연결할 때 사용되며, VPC 간에도 VPN 터널을 통해 연결할 수 있습니다.
  • 구성의 용이성: VPN 연결은 비교적 간단하게 설정할 수 있으며, 별도의 전용 회선 없이도 AWS와의 연결을 설정할 수 있습니다.
  • 대역폭 제한: VPN은 주로 저용량의 데이터 전송에 적합하며, 대규모 트래픽을 처리할 때 성능이 저하될 수 있습니다.
• 사용 사례:
  • 소규모 기업 또는 테스트 환경에서 AWS와 온프레미스 네트워크를 빠르게 연결할 때.
  • 인터넷을 통한 보안 연결이 필요한 경우.
  • 전용 회선을 사용하지 않고도 네트워크 간 보안 연결을 설정하고자 할 때.
• 비용 : 중간

3. VPC 피어링 (VPC Peering)

• 개념 :  두 개의 VPC 간에 네트워크 연결을 설정하여 서로 통신할 수 있게 해주는 서비스입니다. 동일한 AWS 리전 내의 VPC 간에도, 서로 다른 리전의 VPC 간에도 연결할 수 있습니다.
• 주요 특징:
  • VPC 간 직접 연결: VPC 피어링을 사용하면 두 VPC가 직접 연결되며, 트래픽이 인터넷을 거치지 않고도 서로 통신할 수 있습니다.
  • 데이터 전송 비용 절감: 동일한 리전 내에서 피어링된 VPC 간의 데이터 전송 비용은 매우 저렴합니다. 리전 간 연결의 경우 일부 추가 비용이 발생할 수 있습니다.
  • 구성의 간단함: 피어링 설정이 간단하고, 라우팅 테이블만 업데이트하면 연결이 가능합니다.
  • 제한점: VPC 피어링은 한 번에 두 개의 VPC 간의 연결만 허용하므로, 네트워크가 많아질수록 피어링 연결의 수가 많아질 수 있습니다. 이를 해결하려면 Transit Gateway와 같은 더 확장성 있는 솔루션이 필요합니다.
• 사용 사례:
  • 두 VPC 간에 간단하고 저렴하게 네트워크 연결을 설정해야 할 때.
  • 동일한 리전 또는 다른 리전 내에서 제한적인 트래픽 전송이 필요할 때.
  • 중앙 네트워크 관리가 필요하지 않고, 간단한 VPC 간의 연결만 필요할 때.
• 비용 : 저렴 [리전 내에서는 매우 저렴]

4. S3스토리지 클래스 별 특징

• S3 Standard:
  • 기본 스토리지 클래스로 자주 접근하는 데이터를 저장하는 데 적합합니다.
  • 높은 내구성(99.999999999%)과 가용성(99.99%)을 제공하며, 최소 3개의 가용 영역에 복제됩니다.
• S3 Intelligent-Tiering:
  • 자주 접근하는 데이터를 자동으로 계층화하여 비용을 최적화합니다.
  • 데이터 접근 패턴을 모니터링하고, 자주 사용하지 않는 데이터를 자동으로 저비용 계층으로 이동시킵니다.
  • 엑세스 빈도에 따라 비용을 줄일 수 있으며, 엑세스 요청이 다시 증가하면 고빈도 스토리지로 이동합니다.
• S3 Standard-IA (Infrequent Access):
  • 자주 접근하지 않지만 필요할 때는 즉시 접근할 수 있는 데이터를 위한 스토리지 클래스입니다.
  • 접근 빈도는 낮지만 높은 내구성을 요구하는 데이터를 저장할 때 사용하며, 데이터 접근에 대한 추가 요금이 발생합니다.
• S3 One Zone-IA:
  • 자주 접근하지 않는 데이터 중 한 가용 영역에만 복제해 비용을 줄인 옵션입니다.
  • 내구성은 높지만, 하나의 가용 영역에만 저장되기 때문에 재해 발생 시 데이터 손실 가능성이 있습니다.
• S3 Glacier:
  • 장기 보관을 위한 스토리지 클래스이며, 데이터 액세스 시간이 몇 분에서 몇 시간까지 걸릴 수 있습니다.
  • 저비용으로 데이터를 장기간 저장할 때 적합하며, 법적 기록이나 백업 등의 용도로 사용됩니다.
• S3 Glacier Deep Archive:
  • 가장 저렴한 스토리지 클래스이며, 거의 접근하지 않는 데이터를 장기간 보관할 때 적합합니다.
  • 복원하는 데 몇 시간에서 최대 12시간까지 걸릴 수 있지만, 비용 면에서는 가장 저렴합니다.

 

5. S3 수명 주기 정책

 

• 개념 : 데이터를 특정 스토리지 클래스에서 자동으로 다른 클래스로 전환하거나, 일정 기간 후 데이터를 자동으로 삭제하는 규칙을 설정할 수 있는 기능입니다. 이를 통해 비용을 절감하고, 스토리지 관리를 자동화할 수 있습니다.
• 주요 기능:
  • 스토리지 클래스 전환:
    • 자주 사용되는 데이터를 일정 기간 이후에 접근 빈도가 낮아지면, 비용 효율적인 스토리지 클래스로 자동으로 전환할 수 있습니다.
    • 예를 들어, 데이터를 처음에는 S3 Standard에 저장하다가, 일정 기간이 지나면 S3 Standard-IA나 S3 Glacier로 전환하도록 정책을 설정할 수 있습니다.
  • 데이터 자동 삭제:
    • 데이터를 사용하지 않는 기간이 길어질 경우, 데이터의 보존 기간이 만료되면 자동으로 삭제할 수 있습니다.
    • 예를 들어, 로그 파일처럼 일정 기간이 지나면 필요 없는 데이터를 자동으로 삭제하도록 설정할 수 있습니다.
• 수명 주기 규칙 예시:
  • 30일 후에 Standard-IA로 전환: 30일 동안 자주 접근한 데이터를 S3 Standard에 저장한 후, 30일이 지나면 Standard-IA로 전환합니다.
  • 90일 후에 Glacier로 전환: 데이터가 자주 사용되지 않으면 S3 Glacier로 이동시켜 장기 보관을 위해 비용을 절감합니다.
  • 365일 후에 자동 삭제: 데이터가 1년 동안 사용되지 않으면, 더 이상 필요하지 않은 것으로 간주하고 자동으로 삭제할 수 있습니다.
• 수명 주기 정책 단계:
  • 전환 규칙:
    • S3 Standard -> S3 Standard-IA: 일정 기간 동안 사용되지 않으면 Standard-IA로 전환.
    • S3 Standard-IA -> S3 Glacier: 접근 빈도가 더 낮아지면 Glacier로 전환.
    • S3 Glacier -> S3 Glacier Deep Archive: 아주 오래된 데이터를 비용 절감을 위해 Deep Archive로 전환.
  • 만료 규칙:
    • 객체의 보존 기간이 끝났을 때 자동으로 삭제하는 규칙입니다.
    • 주로 로그 파일, 백업 파일 등의 데이터에서 사용되며, 일정 시간이 지난 후 더 이상 필요하지 않은 데이터를 정리하는 데 유용합니다.

6. 네트워크 ACL[Network Access Control List, NACL]

• 개념 :
  • 네트워크 ACL(Network Access Control List, NACL)은 AWS에서 제공하는 보안 계층 중 하나로, VPC(Virtual Private Cloud) 내의 서브넷에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 무상태(Stateless) 방화벽입니다. NACL은 네트워크 레벨에서 작동하며, 트래픽이 VPC 서브넷으로 들어오거나 나갈 때 허용 규칙과 거부 규칙을 통해 트래픽을 필터링합니다.
• 주요 특징:
  • 1. 무상태(Stateless):
    • NACL은 무상태 방화벽이므로, 인바운드 트래픽과 아웃바운드 트래픽을 별도로 처리합니다. 즉, 인바운드 규칙에서 허용한 트래픽이라도 아웃바운드 규칙에서도 따로 허용해줘야 합니다. 반대로 아웃바운드 트래픽도 동일하게 설정해야 합니다.
    • 예를 들어, 인바운드 트래픽에서 TCP 포트 80을 허용한 경우, 아웃바운드에서도 TCP 포트 80을 허용하지 않으면 응답 트래픽이 차단될 수 있습니다.
  • 2. 허용 및 거부 규칙:
    • NACL은 허용 규칙(Allow)과 거부 규칙(Deny)을 모두 지원합니다. 이를 통해 특정 IP 주소, 포트, 또는 프로토콜에 대해 허용하거나 차단할 수 있습니다.
    • 규칙은 순서대로 처리되며, 낮은 번호의 규칙이 우선적으로 평가됩니다. 규칙이 순서대로 평가되다가 특정 트래픽에 맞는 규칙이 발견되면 그 규칙에 따라 허용 또는 거부됩니다.
  • 3. 서브넷 단위로 적용:
    • NACL은 서브넷 단위로 적용되며, 서브넷 내의 모든 리소스(EC2 인스턴스, RDS 인스턴스 등)에 적용됩니다. 각 서브넷은 하나의 NACL만 연결할 수 있습니다.
    • 기본적으로 AWS에서 제공하는 기본 NACL은 모든 인바운드 및 아웃바운드 트래픽을 허용합니다.
  • 4. 기본 NACL과 커스텀 NACL:
    • 기본 NACL(Default NACL): 모든 트래픽을 허용하는 상태로 제공됩니다. 특별히 설정하지 않으면 서브넷은 기본 NACL을 사용합니다.
    • 커스텀 NACL(Custom NACL): 사용자가 직접 허용 및 거부 규칙을 설정할 수 있습니다. 커스텀 NACL을 설정하면 서브넷의 트래픽을 더욱 세밀하게 제어할 수 있습니다.
  • 5. 규칙의 우선순위:
    • NACL 규칙은 번호 순서로 평가됩니다. 낮은 번호의 규칙이 먼저 적용되며, 규칙이 적용되면 이후의 규칙은 무시됩니다. 예를 들어, 100번 규칙에서 특정 IP를 허용하고, 200번 규칙에서 모든 트래픽을 거부하면, 해당 IP는 허용되고 나머지는 거부됩니다.
  • 6. 여러 규칙 적용:
    • NACL은 다중 규칙을 적용할 수 있습니다. 예를 들어, 특정 IP 범위는 허용하고, 다른 IP는 차단하는 식의 규칙을 설정할 수 있습니다. 각 규칙은 서로 독립적이므로 순서와 내용에 따라 트래픽 필터링이 결정됩니다.
• 네트워크 ACL과 보안 그룹의 차이

특징	네트워크 ACL[NACL]	보안 그룹[Security Group]
상태	무상태 [Stateless]	상태 저장 [Stateful]
제어 대상	서브넷 단위	인스턴스[EC2 등] 단위
허용/거부 규칙	허용 및 거부 규칙 가능	허용 규칙만 가능
적용 순서	규칙 번호 순서에 따라 적용	모든 규칙이 동시에 적용됨
인바운드/아웃바운드 설정	인바운드와 아웃바운드 규칙을 별도로 설정해야함	한 번의 설정으로 인바운드와 아웃바운드 트랙픽 자동 관리

• NACL 설정 예시:
  • 1. IP 주소 차단:
    • 203.0.113.0/24 IP 범위에서 오는 인바운드 트래픽을 차단하는 규칙을 추가할 수 있습니다.
    • rule_number 100, action DENY, source 203.0.113.0/24, protocol ALL
  • 2. 포트 차단:
    • 특정 포트, 예를 들어, TCP 포트 22(SSH)에 대한 접근을 차단하는 규칙을 만들 수 있습니다.
    • rule_number 110, action DENY, protocol TCP, port_range 22, source 0.0.0.0/0
  • 3. 전체 트래픽 허용:
    • 기본적으로 모든 트래픽을 허용하는 규칙을 추가할 수 있습니다.
    • rule_number 200, action ALLOW, source 0.0.0.0/0, protocol ALL

• 언제 NACL을 사용하는가?
  • 서브넷 레벨에서 트래픽 제어: 특정 서브넷에서 들어오고 나가는 트래픽을 세밀하게 제어하고자 할 때 사용합니다.
  • IP 블록킹: 특정 IP나 IP 범위를 차단해야 할 때 NACL의 DENY 규칙을 사용합니다.
  • 추가적인 보안 계층: 보안 그룹과 함께 사용할 때, NACL은 트래픽에 대한 추가적인 보안 계층을 제공할 수 있습니다. 보안 그룹은 인스턴스 레벨에서 세부적인 트래픽 제어를 하고, NACL은 서브넷 단위로 더 큰 범위의 트래픽 제어를 합니다.

미리 서명된 URL(Pre-signed URL)

• 개념 :
  • Amazon S3의 객체(파일)에 대한 일시적인 접근 권한을 부여하기 위해 생성되는 임시 링크입니다.
  • 이 URL을 통해 S3에 저장된 파일을 지정된 시간 동안 누구나 접근할 수 있게 합니다.
  • AWS의 인증된 사용자가 이 URL을 생성할 수 있으며, 링크가 만료되면 더 이상 접근이 불가능합니다.

• 미리 서명된 URL의 주요 특징:
  • 일시적 접근:
    • 미리 서명된 URL을 생성할 때 만료 시간(예: 1시간, 24시간)을 지정할 수 있습니다. 링크는 그 시간이 지나면 자동으로 무효화되므로, 이후에는 더 이상 접근할 수 없습니다.
  • 권한을 기반으로 생성:
    • URL을 생성하는 사용자는 해당 S3 객체에 대한 적절한 권한을 가지고 있어야 합니다. 예를 들어, 객체를 다운로드하려면 S3 객체에 대한 s3:GetObject 권한이 있어야 합니다.
  • 접근 제어:
    • 미리 서명된 URL은 S3 객체의 읽기(read), 쓰기(write), 삭제(delete) 등의 작업에 대한 접근을 제한적으로 허용할 수 있습니다. 예를 들어, 다운로드할 수 있는 URL을 제공하거나, 업로드할 수 있는 URL을 제공할 수 있습니다.
  • 보안:
    • URL이 생성될 때 해당 객체에 대한 서명(signature)이 포함됩니다. 서명은 AWS의 비밀 키를 기반으로 생성되므로, 이 URL이 외부에 노출되어도 지정된 만료 시간 이후에는 사용할 수 없습니다.
    • 또한, URL을 생성한 사람이 객체에 대한 권한을 가지고 있어야 하기 때문에, 권한 없는 사용자가 링크를 생성하는 것을 방지할 수 있습니다.
• 미리 서명된 URL 사용 사례:
  • 파일 다운로드:
    • • 대용량 파일이나 로그 파일을 S3에 저장하고, 해당 파일을 외부 클라이언트나 파트너에게 일시적으로 공유하고 싶을 때 사용합니다. 클라이언트는 미리 서명된 URL을 통해 S3 객체에 접근해 파일을 다운로드할 수 있습니다.
  • 파일 업로드:
    • 외부 사용자나 애플리케이션이 S3에 파일을 업로드해야 할 때, 미리 서명된 URL을 생성하여 업로드용 URL을 제공할 수 있습니다. 이 방법을 통해 사용자는 S3 버킷에 직접 접근하지 않고도 파일을 업로드할 수 있습니다.
  • 보안 로그 파일 공유:
    • 성능 문제나 버그 해결을 위해 파트너 또는 공급업체에게 로그 파일을 전달할 때, 미리 서명된 URL을 통해 제한된 시간 동안만 파일을 공유할 수 있습니다.

용어정리

• 파일 게이트웨이(File Gateway): 온프레미스 애플리케이션이 S3 버킷을 네트워크 파일 시스템처럼 사용할 수 있게 하는 솔루션으로, 주로 파일 기반 데이터에 적합합니다.
• 볼륨 게이트웨이(Volume Gateway): 온프레미스에서 블록 스토리지 형태로 데이터를 관리하면서, AWS 클라우드에 백업 및 스냅샷을 저장하는 솔루션으로, 주로 블록 기반 데이터에 적합합니다.

 

문제풀이

 

문제 1 :회사가 다른 리전에서 해당 환경의 격리된 백업을 생성했습니다. 응용 프로그램이 웜 대기 모드에서 실행 중이고 ALB(Application

Load Balancer)가 앞에 있습니다. 현재 장애 조치 프로세스는 수동이며 보조를 가리키도록 DNS 별칭 레코드를 업데이트해야 합니다. 다른 리전의 ALB 장애 조치 프로세스를 자동화하기 위해 솔루션 설계자는 무엇을 해야 합니까?

-> 다른 리전에 생성된 응용 프로그램의 장애 조치 프로세스를 자동화하는 방안을 찾는 문제입니다. 응용 프로그램이 웜 대기 모드에로 실행중이며, ALB가 앞에 배치되어 있습니다. 장애가 발생할 경우, DNS 레코드를 업데이트하여 보조 리전으로 트래픽을 전환하는 작업이 필요합니다.

 

A. ALB 상태 확인 활성화

• ALB 자체적으로 상태 확인 기능이 활성화되면, 해당 ALB가 정상 동작하는지 확인할 수 있습니다. 하지만 이는 DNS 레코드를 자동으로 변경해주지는 않기 때문에, 트래픽을 다른 리전의 ALB로 전환하는 역할을 하지 않습니다. 따라서 이 방법은 장애 조치를 위한 자동화에는 적합하지 않습니다.

B. Amazon Route 53 상태 확인 활성화

• Amazon Route 53의 상태 확인 기능을 사용하면, 장애가 발생한 ALB를 감지하고 DNS 레코드를 자동으로 업데이트하여 다른 리전으로 트래픽을 전환할 수 있습니다. 상태 확인이 활성화된 경우, ALB가 비정상으로 판단되면 자동으로 보조 리전의 ALB로 트래픽을 전환할 수 있어 장애 조치를 자동화하는 데 적합한 선택입니다.

C. ALB 엔드포인트를 가리키는 Amazon Route 53에서 CNAME 레코드를 생성합니다.

• CNAME 레코드를 생성하는 것은 특정 도메인에 대해 별칭을 제공하는 작업입니다. 이 작업은 DNS 설정에 도움을 줄 수 있지만, 장애 조치 자동화를 위해 필요한 “상태 확인”이나 “자동 전환”을 수행하는 것은 아닙니다. 따라서 이 선택지도 문제의 요구 사항을 충족하지 못합니다.

D. 내부 BIND DNS 서버를 가리키는 Amazon Route 53에서 조건부 전달 규칙 생성

• 내부 BIND DNS 서버를 사용하는 방법은 BIND 서버를 통해 조건부로 트래픽을 전달하는 방식이지만, 이 방식은 AWS의 장애 조치 자동화와는 맞지 않으며 AWS에서 제공하는 자동화된 장애 조치 기능인 Route 53 상태 확인 기능을 활용하는 것이 더 적합합니다.

문제 2 : 회사에 Auto Scaling 그룹의 여러 Amazon EC2 인스턴스에 배포된 다 계층 애플리케이션이 있습니다. Oracle용 Amazon

RDS 인스턴스는 애플리케이션의 데이터 계층에서 Oracle 관련 PL/SQL 기능을 사용합니다. 애플리케이션에 대한 트래픽은 꾸준히 증가하고 있습니다. 이로 인해 EC2 인스턴스에 과부하가 걸리고 RDS 인스턴스에 스토리지가 부족해집니다. Auto Scaling 그룹에는 조정 지표가 없으며 최소 정상 인스턴스 수만 정의합니다. 회사는 트래픽이 일정하지만 예측할 수 없는 속도로 계속 증가할 것으로 예측합니다. 시스템이 증가된 트래픽에 맞게 자동으로 확장되도록 하려면 솔루션 설계자가 무엇을 해야 합니까? (2개를 선택하십시오.)

 

A. RDS for Oracle 인스턴스에서 스토리지 Auto Scaling을 구성합니다.

• RDS 스토리지 Auto Scaling은 스토리지 용량을 자동으로 조정할 수 있게 하여, 저장 공간이 부족할 때 자동으로 확장되도록 해줍니다. 이 기능을 활성화하면 RDS 인스턴스의 스토리지 부족 문제를 해결할 수 있습니다. 트래픽 증가에 대비하여 RDS가 자동으로 확장되는 기능이므로 적합한 선택입니다.

B. 데이터베이스를 Amazon Aurora로 마이그레이션하여 Auto Scaling 스토리지를 사용합니다.

• Amazon Aurora는 AWS에서 제공하는 고성능 관계형 데이터베이스 서비스로, Auto Scaling 스토리지를 지원합니다. Amazon Aurora는 Oracle RDS와 호환되지 않으며, Oracle 관련 기능을 사용할 수 없습니다.
• MySQL 및 PostgreSQL과 호환되는 버전을 지원합니다.

C. 사용 가능한 저장 공간 부족에 대한 Oracle Instance용 RDS에 대한 경보 구성

• 경보를 구성하는 것은 시스템 상태를 모니터링하는 데 유용하지만, 실제로 트래픽 증가에 맞춰 자동으로 시스템을 확장하는 방법은 아닙니다. 따라서 자동화된 확장과는 직접적으로 관련이 없습니다.
• RDS 경보를 다른 애플리케이션과 트리거 할 수 없습니다. 

D. 평균 CPU를 스케일링 메트릭으로 사용하도록 Auto Scaling 그룹을 구성합니다.

• 평균 CPU 사용률을 Auto Scaling 메트릭으로 설정하면 EC2 인스턴스의 트래픽 증가에 맞춰 Auto Scaling이 작동할 수 있습니다. CPU 사용률은 트래픽 증가와 연관성이 높으므로, 이를 기준으로 EC2 인스턴스를 확장하는 것은 적절한 선택입니다.

E. 평균 여유 메모리를 보는 메트릭으로 사용하도록 Auto Scaling 그룹을 구성합니다.

• 여유 메모리 사용량을 기준으로 Auto Scaling 그룹을 구성하면, 메모리가 부족해질 때 인스턴스가 자동으로 확장됩니다. 그러나 CPU 사용률이 더 적절한 스케일링 메트릭이 될 가능성이 큽니다. 메모리보다는 CPU가 더 자주 트래픽 증가와 관련된 성능 지표이기 때문에 덜 효율적일 수 있습니다.
• 인스턴스의 과부하가 걸리는 것을 지표로 해야 하기에 CPU를 조정 지표로 사용해야 합니다.

문제 3 : 회사에 동일한 AWS 계정 내 us-west-2 리전에 위치한 두 개의 VPC가 있습니다. 회사는 이러한 VPC 간의 네트워크 트래픽을 허용해야 합니다. 매월 약 500GB의 데이터 전송이 VPC 간에 발생합니다. 이러한 VPC를 연결하는 가장 비용 효율적인 솔루션은 무엇입니까?

 

A. VPC를 연결하는 AWS Transit Gateway 구현

• AWS Transit Gateway는 다중 VPC 및 온프레미스 네트워크를 중앙에서 관리하고 연결할 수 있는 서비스입니다. 많은 VPC를 연결해야 하거나 네트워크의 복잡성이 높은 경우에 유리합니다. 하지만 VPC 두 개 간의 연결에는 다소 과도한 방법일 수 있으며, 비용 효율적이지 않을 수 있습니다.

B. VPC 간에 AWS Site-to-Site VPN 터널을 구현

• Site-to-Site VPN은 AWS VPC와 온프레미스 네트워크를 안전하게 연결하는 데 유용하지만, VPC 간 트래픽을 처리하는 데에는 적합하지 않습니다. 또한 VPN은 트래픽 양이 많을 경우 성능이 떨어지고, 비용도 더 높을 수 있습니다.

C. VPC 간에 VPC 피어링 연결을 설정

• VPC 피어링은 두 개의 VPC 간에 직접 연결을 설정하여 트래픽을 전송하는 방법입니다. 동일한 리전 내에서 VPC 피어링을 사용하면 데이터 전송 비용이 매우 저렴하며, 성능도 뛰어납니다. 이 방법은 관리가 쉽고 추가적인 네트워크 장비나 설정이 필요 없으므로 비용 효율성이 뛰어납니다.

D. VPC 간에 1GB AWS Direct Connect 연결 설정

• AWS Direct Connect는 온프레미스 데이터 센터와 AWS를 연결할 때 사용하는 고속 전용 회선입니다. 그러나 VPC 간 통신을 위해 Direct Connect를 사용하는 것은 과도한 설정이며, 비용적으로도 비효율적입니다. 이 방법은 주로 AWS와 온프레미스를 연결할 때 사용됩니다.

문제 4 : 한 회사에서 이미지 처리를 위한 2계층 애플리케이션을 운영하고 있습니다. 애플리케이션은 각각 하나의 퍼블릭 서브넷과 하나의 프라이빗 서브넷이 있는 두 개의 가용 영역을 사용합니다. 웹 계층용 ALB(Application Load Balancer)는 퍼블릭 서브넷을 사용합니다. 애플리케이션 계층의 Amazon EC2 인스턴스는 프라이빗 서브넷을 사용합니다. 사용자는 응용 프로그램이 예상보다 느리게 실행되고 있다고 보고합니다. 웹 서버 로그 파일의 보안 감사에 따르면 애플리케이션이 소수의 IP 주소로부터 수백만 건의 불법적인 요청을 수신하고 있습니다. 솔루션 설계자는 회사가 보다 영구적인 솔루션을 조사하는 동안 즉각적인 성능 문제를 해결해야 합니다.

솔루션 설계자는 이 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

 

A. 웹 계층에 대한 인바운드 보안 그룹을 수정합니다. 리소스를 소비하는 IP 주소에 대한 거부 규칙을 추가합니다.

• 보안 그룹은 AWS에서 상태 저장(stateful) 방식의 트래픽 필터링을 제공합니다. 웹 계층이 퍼블릭 서브넷에 위치해 있으므로, 퍼블릭 네트워크에서 접근하는 IP를 필터링하는 것이 적절할 수 있습니다. 불법적인 IP를 차단할 수 있지만 보안 그룹은 직접적으로 허용 규칙만 적용할 수 있고, 거부 규칙은 적용할 수 없습니다.

B. 웹 계층 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.

• 네트워크 ACL은 AWS에서 무상태(stateless) 방식으로 동작하며, 허용 규칙과 거부 규칙 모두를 설정할 수 있습니다. 퍼블릭 서브넷에서 불법적인 요청이 발생하고 있으므로, 네트워크 ACL을 사용해 특정 IP 주소에서 들어오는 트래픽을 차단하는 것은 적절한 대응책입니다.

C. 애플리케이션 계층에 대한 인바운드 보안 그룹을 수정합니다. 리소스를 소비하는 IP 주소에 대한 거부 규칙을 추가합니다.

• 애플리케이션 계층은 프라이빗 서브넷에 위치해 있으므로, 퍼블릭 트래픽이 직접적으로 접근하지 않습니다. 따라서 애플리케이션 계층에서 보안 그룹을 수정하는 것은 부적절한 대응입니다.

D. 애플리케이션 계층 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.

• 애플리케이션 계층은 프라이빗 서브넷에서 실행되므로 퍼블릭 트래픽이 접근할 수 없습니다. 이 때문에 애플리케이션 계층에 네트워크 ACL을 설정하는 것은 이 문제를 해결하는 데 적합하지 않습니다.

문제 5 : AWS에서 호스팅되는 애플리케이션에 성능 문제가 발생하고 애플리케이션 공급업체에서 추가 문제 해결을 위해 로그 파일 분석을 수행하려고 합니다. 로그 파일은 Amazon S3에 저장되며 크기는 10GB입니다. 애플리케이션 소유자는 제한된 시간 동안 공급업체에서 로그 파일을 사용할 수 있도록 합니다. 이 작업을 수행하는 가장 안전한 방법은 무엇입니까?

 

A. S3 객체에 대한 공개 읽기를 활성화하고 공급업체에 대한 링크를 제공합니다.

• 공개 읽기를 활성화하는 것은 매우 위험한 방법입니다. 공개적으로 파일을 열어 두면 누구든지 링크만 알면 파일에 접근할 수 있기 때문에, 보안이 취약해집니다. 민감한 데이터가 포함된 로그 파일을 공개로 설정하는 것은 좋은 방법이 아닙니다.

B. Amazon WorkDocs에 파일을 업로드하고 공급업체와 공개 링크를 공유합니다.

• Amazon WorkDocs는 문서 저장 및 협업 도구로, 파일 공유에 사용될 수 있지만, 이 방법은 S3에 저장된 10GB의 로그 파일을 다른 서비스로 옮겨야 한다는 문제가 있습니다. 파일 크기가 크고, WorkDocs의 용도와 맞지 않아 적절한 선택은 아닙니다.

C. 미리 서명된 URL을 생성하고 만료되기 전에 공급업체가 로그를 다운로드하도록 합니다.

• 미리 서명된 URL (Pre-signed URL)은 S3 객체에 대해 일시적으로 접근 권한을 부여하는 안전한 방법입니다. 미리 서명된 URL은 일정 시간 동안만 유효하며, 그 시간이 지나면 자동으로 만료됩니다. 이 방법을 사용하면 공급업체가 제한된 시간 동안만 안전하게 로그 파일에 접근할 수 있습니다. 이는 AWS에서 권장하는 안전한 파일 공유 방식입니다.

D. 공급업체에 대한 IAM 사용자를 생성하여 S3 버킷 및 연결 애플리케이션에 대한 액세스를 제공합니다. 다단계 인증 시행

• 공급업체에 대해 별도의 IAM 사용자를 생성하는 것은 복잡하고 불필요할 수 있습니다. IAM 사용자는 영구적인 권한을 부여하는 방식이며, 공급업체에게 S3와 애플리케이션에 대한 권한을 부여하는 것은 과도한 접근 권한을 제공하게 됩니다. 또한, 설정 및 관리 측면에서 추가적인 오버헤드가 발생할 수 있습니다.

문제 6 : 의학 연구실은 새로운 연구와 관련된 데이터를 생성합니다. 연구소는 온프레미스 파일 기반 애플리케이션을 위해 전국의 클리닉에서 최소 대기 시간으로 데이터를 사용할 수 있도록 하려고 합니다. 데이터 파일은 각 진료소에 대한 읽기 전용 권한이 있는 Amazon S3 버킷에 저장됩니다. 이러한 요구 사항을 충족하기 위해 솔루션 설계자는 무엇을 권장해야 합니까?

 

A. AWS Storage Gateway 파일 게이트웨이를 각 클리닉의 온프레미스 가상 머신(VM)으로 배포합니다.

• AWS Storage Gateway는 온프레미스 애플리케이션이 클라우드 스토리지와 연동될 수 있게 하는 서비스입니다. 특히, 파일 게이트웨이(File Gateway)는 온프레미스에서 NAS(Network Attached Storage)처럼 작동하면서 데이터를 S3에 저장하고, 클라이언트는 이를 네트워크 파일 시스템으로 액세스할 수 있습니다. 이 방식은 데이터를 S3에 저장하면서 온프레미스 애플리케이션이 해당 데이터에 로컬 파일처럼 접근할 수 있게 합니다.
• 정답 가능성: 높은 편입니다. 파일 게이트웨이는 S3 버킷과 온프레미스를 연결하여 대기 시간을 최소화하면서 S3 버킷의 데이터를 읽을 수 있도록 합니다.

B. 처리를 위해 AWS DataSync를 사용하여 각 클리닉의 온프레미스 애플리케이션으로 파일 마이그레이션

• AWS DataSync는 데이터를 자동으로 동기화 및 마이그레이션하는 서비스입니다. 온프레미스에서 클라우드로 데이터를 이동하거나 반대로 클라우드에서 온프레미스로 데이터를 이동할 수 있습니다. 그러나 이 방법은 지속적인 실시간 파일 접근보다는 데이터를 전송하고 마이그레이션하는 데 중점을 둡니다. 클리닉에서 데이터를 지속적으로 사용해야 하는 상황에서는 적합하지 않을 수 있습니다.
• 정답 가능성: 낮습니다. DataSync는 데이터 전송과 마이그레이션에 적합하지만, 지속적으로 데이터를 실시간으로 접근하는 경우에는 적합하지 않습니다.

C. AWS Storage Gateway 볼륨 게이트웨이를 각 클리닉의 온프레미스 가상 머신(VM)으로 배포합니다.

• 볼륨 게이트웨이(Volume Gateway)는 온프레미스의 데이터를 블록 스토리지 형태로 관리하며, 이를 S3에 백업할 수 있습니다. 이는 주로 백업이나 재해 복구 용도로 사용되며, 실시간 데이터 접근이 필요한 시나리오에서는 적합하지 않을 수 있습니다.
• 정답 가능성: 낮습니다. 볼륨 게이트웨이는 블록 스토리지 형식이므로, 파일 기반 접근을 원하는 이 문제의 요구사항에 적합하지 않습니다.

D. Amazon Elastic File System(Amazon EFS) 파일 시스템을 각 클리닉의 온프레미스 서버에 연결

• Amazon EFS는 완전 관리형 네트워크 파일 시스템입니다. 이는 주로 AWS 내에서 사용되며, 온프레미스 환경에서 EFS를 연결하려면 복잡한 네트워크 설정과 AWS Direct Connect 등의 인프라가 필요합니다. 또한 문제의 요구 사항인 S3와의 연동과는 직접적인 연관이 없습니다.
• 정답 가능성: 낮습니다. EFS는 온프레미스에서 사용하기에 적합하지 않으며, S3와의 통합성이 떨어집니다.