본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #2: [S3 마이그레이션] 마스터하기

by Pacloud 2024. 7. 30.
반응형

안녕하세요, AWS SAA(Solution Architect Associate) 자격증을 준비하시는 여러분!

저는 넥스트클라우드에서 SA로 활동하고 있는 손유림이라고 합니다. 😊

 

지난번에 AWS SAA 자격증 문제 접근법과 분석 방법에 대해 이야기를 나눴었죠.

오늘은 그 여정을 이어가되, 조금 새로운 방식으로 준비해 봤어요. 

이번에는 각 문제의 핵심 내용만을 간략히 다루고, 자세한 내용과 추가 정보는 별도의 페이지로 분리했습니다.

이렇게 하면 필요한 정보를 더 효율적으로 찾아볼 수 있을 거예요.

여전히 모든 문제는 세 가지 단계를 거치며 풀어나갈 거예요:

 

  1. 문제의 요구사항 분석하기
  2. 관련 AWS 서비스 생각하기
  3. 선택지 분석하기

여러분의 SAA 자격증 여정에 작은 도움이 되길 바라며, 오늘도 3문제를 분석해 보도록 할게요.

자, 그럼 첫 번째 문제부터 살펴볼까요?


문제

한 회사는 최근 프라이빗 서브넷의 Amazon EC2에서 Linux 기반 애플리케이션 인스턴스를 시작했고 VPC의 퍼블릭 서브넷의 Amazon EC2 인스턴스에서 Linux 기반 배스천 호스트를 시작했습니다.

솔루션 설계자는 회사의 인터넷 연결을 통해 온프레미스 네트워크에서 배스천 호스트 및 애플리케이션 서버에 연결해야 합니다.

솔루션 설계자는 모든 EC2 인스턴스의 보안 그룹이 해당 액세스를 허용하는지 확인해야 합니다.

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 수행해야 합니까? (두 가지를 선택하세요.)

선택지

1. 배스천 호스트의 현재 보안 그룹을 애플리케이션 인스턴스로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.

2. 배스천 호스트의 현재 보안 그룹을 회사 내부 IP 범위의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.

3. 배스천 호스트의 현재 보안 그룹을 회사의 외부 IP 범위로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.

4. 애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 사설 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.

5. 애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 퍼블릭 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.


요구사항에 맞는 서비스

1. 인터넷 연결을 통해 온프레미스 네트워크에서 배스천 호스트 및 애플리케이션 서버에 연결

  • Internet Gateway: VPC와 인터넷 간의 통신을 가능하게 하는 AWS 리소스입니다. 퍼블릭 서브넷에 배치된 EC2 인스턴스가 인터넷과 통신할 수 있게 합니다. 이를 통해 온프레미스 네트워크에서 퍼블릭 서브넷의 배스천 호스트 및 애플리케이션 서버에 접근할 수 있습니다.
  • AWS Transit Gateway: VPC와 온프레미스 네트워크 간의 라우팅을 관리하는 네트워크 허브 역할을 합니다. 여러 VPC와 온프레미스 네트워크를 연결하는 데 유용하며, VPN 연결을 통해 인터넷을 통한 접근을 지원합니다. 이 서비스를 사용하면 네트워크 연결을 중앙에서 관리하고 확장할 수 있습니다.
  • AWS Site-to-Site (VPN): 온프레미스 네트워크와 AWS VPC 간에 안전하게 인터넷을 통해 연결할 수 있는 관리형 VPN 서비스입니다. VPN 연결은 암호화되어 전송되므로 보안성이 높습니다.

2. 모든 EC2 인스턴스의 보안 그룹이 해당 액세스를 허용하도록 설정

  • Amazon EC2 Security Groups(보안 그룹): 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 하는 서비스입니다. 보안 그룹은 상태 저장 방식으로 동작하며, 인스턴스 수준에서 네트워크 접근을 제어할 수 있습니다.
  • AWS Identity and Access Management (IAM): AWS 리소스에 대한 접근 권한을 관리할 수 있는 서비스입니다. 보안 그룹 설정과 연계하여 특정 사용자나 역할에 대해 보안 그룹을 설정하고 변경할 수 있는 권한을 부여할 수 있습니다. IAM을 사용하면 세분화된 접근 제어가 가능하며, 최소 권한 원칙을 적용할 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “배스천 호스트의 현재 보안 그룹을 애플리케이션 인스턴스로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.”입니다.

 선택지가 정답이 아닌 이유는 배스천 호스트에 대한 온프레미스 네트워크 접근을 고려하지 않고, 애플리케이션 인스턴스에서의 접근만 허용하는 설정이기 때문입니다.

 

선택지 2번은 “배스천 호스트의 현재 보안 그룹을 회사 내부 IP 범위의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.”입니다.

 선택지가 정답이 아닌 이유는 회사 내부 IP 범위를 사용하여 배스천 호스트에 접근을 허용하지만 외부 IP 범위를 사용하여 온프레미스 네트워크와 연결된 환경에서는 이 설정이 적절하지 않을 수 있기 때문입니다. 외부 IP 범위를 사용하여 접근을 허용하는 것이 더 나은 선택일 수 있습니다.

 

선택지 3번은 “배스천 호스트의 현재 보안 그룹을 회사의 외부 IP 범위로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.”입니다.

 이 선택지는 애플리케이션 인스턴스가 배스천 호스트를 통해서만 접근되도록 하여 보안을 강화하는 방법입니다.

 

선택지 4번은 “애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 사설 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.”입니다.

 이 선택지는 애플리케이션 인스턴스가 배스천 호스트를 통해서만 접근되도록 하여 보안을 강화하는 방법입니다.

 

선택지 5번은 “애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 퍼블릭 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.”입니다.

 선택지가 정답이 아닌 이유는 퍼블릭 IP를 통해 SSH 접근을 허용하므로 보안상의 위험이 있을 수 있기 때문입니다. 배스천 호스트의 사설 IP를 사용하는 것이 더 안전합니다.

 

 

첫 번째 문제에 대한 정답은 선택지 3번과 4번이었습니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요.

  1. 인터넷 연결을 통해 온프레미스 네트워크에서 배스천 호스트 및 애플리케이션 서버에 연결
  2. 모든 EC2 인스턴스의 보안 그룹이 해당 액세스를 허용하도록 설정

"인터넷 연결을 통해 온프레미스 네트워크에서 배스천 호스트 및 애플리케이션 서버에 연결"

회사 사무실(온프레미스)에서 AWS 클라우드의 특정 컴퓨터들에 접속하려고 해요. 이 접속은 일반 인터넷을 통해 이루어집니다. 접속하려는 대상은 두 가지예요:

  • 배스천 호스트: 이건 마치 클라우드로 들어가는 입구 같은 특별한 컴퓨터예요.
  • 애플리케이션 서버: 실제로 여러분의 서비스나 프로그램이 돌아가는 컴퓨터들이에요.

"모든 EC2 인스턴스의 보안 그룹이 해당 액세스를 허용하도록 설정"

→ 인터넷을 통해 AWS의 특정 컴퓨터들에 안전하게 접속할 수 있도록 설정하는 것이에요.

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 인터넷 연결을 통해 온프레미스 네트워크에서 배스천 호스트 및 애플리케이션 서버에 연결

  • Internet Gateway: VPC와 인터넷 간의 통신을 가능하게 하는 AWS 리소스입니다. 퍼블릭 서브넷에 배치된 EC2 인스턴스가 인터넷과 통신할 수 있게 합니다. 이를 통해 온프레미스 네트워크에서 퍼블릭 서브넷의 배스천 호스트 및 애플리케이션 서버에 접근할 수 있습니다.
    • Public Subnet: 인터넷 게이트웨이와 연결되어 있어, 서브넷 내의 EC2 인스턴스가 인터넷과 직접 통신할 수 있습니다.

  

프라이빗 서브넷은 인터넷 게이트웨이와 직접 연결되어 있지 않아, 이 서브넷 내의 EC2 인스턴스는 인터넷과 직접 통신할 수 없습니다. 프라이빗 서브넷의 인스턴스가 외부 인터넷과 통신하려면 NAT 게이트웨이나 NAT 인스턴스와 같은 추가적인 구성이 필요합니다.

  • AWS Transit Gateway: VPC와 온프레미스 네트워크 간의 라우팅을 관리하는 네트워크 허브 역할을 합니다. 여러 VPC와 온프레미스 네트워크를 연결하는 데 유용하며, VPN 연결을 통해 인터넷을 통한 접근을 지원합니다. 이 서비스를 사용하면 네트워크 연결을 중앙에서 관리하고 확장할 수 있습니다.

“VPC (Virtual Private Cloud)”

→ AWS 내에서 사용자가 정의한 가상 네트워크를 말해요.

“온프레미스 네트워크”

→ 기업이 자체적으로 보유하고 관리하는 물리적 네트워크로, 주로 회사 내부나 데이터 센터에 있는 네트워크를 의미해요.

“라우팅”

→ 네트워크에서 데이터 패킷이 목적지까지 가는 경로를 결정하는 과정이에요.

“네트워크 허브”

→ 여러 네트워크 연결이 모이는 중심점이에요.

  • AWS Site-to-Site (VPN): 온프레미스 네트워크와 AWS VPC 간에 안전하게 인터넷을 통해 연결할 수 있는 관리형 VPN 서비스입니다. VPN 연결은 암호화되어 전송되므로 보안성이 높습니다.

2. 모든 EC2 인스턴스의 보안 그룹이 해당 액세스를 허용하도록 설정

  • Amazon EC2 Security Groups(보안 그룹): 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 하는 서비스입니다. 보안 그룹은 상태 저장 방식으로 동작하며, 인스턴스 수준에서 네트워크 접근을 제어할 수 있습니다.

“인바운드”

→ 외부에서 인스턴스로 들어오는 데이터 흐름이에요.

“아웃바운드”

→ 인스턴스에서 외부로 나가는 데이터 흐름이에요.

 

"상태 저장 방식과 인스턴스 수준에서 네트워크를 접근한다." 이건 무슨 말일까요?

상태를 저장하기 때문에 한 방향(인바운드 또는 아웃바운드)에서 트래픽을 허용하면 그에 대한 응답 트래픽은 자동으로 반대 방향으로 허용된다는 말이에요. 인스턴스는 클라우드 컴퓨팅 환경에서 가상 서버를 말해요. 예로 EC2, S3, MySQL 등이 있고, 이 인스턴스에 어떤 네트워크 트래픽이 접근할 수 있는지를 결정하는 것을 의미해요.

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “배스천 호스트의 현재 보안 그룹을 애플리케이션 인스턴스로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체하합니다.”입니다.

  • Amazon Security Groups: 보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다.

선택지가 정답이 아닌 이유는 배스천 호스트에 대한 온프레미스 네트워크 접근을 고려하지 않고, 애플리케이션 인스턴스에서의 접근만 허용하는 설정이기 때문입니다.

 

선택지 2번은 “배스천 호스트의 현재 보안 그룹을 회사 내부 IP 범위의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.”입니다.

  • Amazon Security Groups: 보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다.

선택지가 정답이 아닌 이유는 회사 내부 IP 범위를 사용하여 배스천 호스트에 접근을 허용하지만 외부 IP 범위를 사용하여 온프레미스 네트워크와 연결된 환경에서는 이 설정이 적절하지 않을 수 있기 때문입니다. 외부 IP 범위를 사용하여 접근을 허용하는 것이 더 나은 선택일 수 있습니다.

 

선택지 3번은 “배스천 호스트의 현재 보안 그룹을 회사의 외부 IP 범위로부터의 인바운드 액세스만 허용하는 보안 그룹으로 교체합니다.”입니다.

  • Amazon Security Groups: 보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다.

이 선택지는 애플리케이션 인스턴스가 배스천 호스트를 통해서만 접근되도록 하여 보안을 강화하는 방법입니다.

 

선택지 4번은 “애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 사설 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.”입니다.

  • Amazon Security Groups: 보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다.

이 선택지는 애플리케이션 인스턴스가 배스천 호스트를 통해서만 접근되도록 하여 보안을 강화하는 방법입니다.

 

선택지 5번은 “애플리케이션 인스턴스의 현재 보안 그룹을 배스천 호스트의 퍼블릭 IP 주소에서만 인바운드 SSH 액세스를 허용하는 보안 그룹으로 바꿉니다.”입니다.

  • Amazon Security Groups: 보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다.

선택지가 정답이 아닌 이유는 퍼블릭 IP를 통해 SSH 접근을 허용하므로 보안상의 위험이 있을 수 있기 때문입니다. 배스천 호스트의 사설 IP를 사용하는 것이 더 안전합니다.

 

 

이어서 두 번째 문제 살펴볼게요.


문제

회사에는 1,000개의 Amazon EC2 Linux 인스턴스에서 실행되는 프로덕션 워크로드가 있습니다.

워크로드는 타사 소프트웨어로 구동됩니다.

회사는 중요한 보안 취약성을 수정하기 위해 가능한 한 빨리 모든 EC2 인스턴스에서 타사 소프트웨어를 패치해야 합니다.

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

선택지

1. 모든 EC2 인스턴스에 패치를 적용할 AWS Lambda 함수를 생성합니다.

2. 모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager Patch Manager를 구성합니다.

3. 모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager 유지 관리 기간을 예약합니다.

4. AWS Systems Manager Run Command를 사용하여 패치를 모든 EC2 인스턴스에 적용하는 사용자 지정 명령을 실행합니다.


요구사항에 맞는 서비스

1. 소프트웨어 패치

  • AWS Systems Manager: 대규모 인스턴스 관리 및 자동화를 지원하는 서비스로, 인스턴스의 상태를 모니터링하고 제어할 수 있습니다. 이 서비스를 통해 여러 EC2 인스턴스를 중앙에서 관리하고 운영할 수 있습니다.
    • AWS Systems Manager Automation: 사용하면 타사 소프트웨어를 포함한 다양한 워크로드를 자동화된 방식으로 관리할 수 있습니다. 이는 패치 작업을 자동으로 수행하는 데 유용합니다.
    • AWS Systems Manager Patch Manager: AWS에서 패치 관리를 자동화하는 서비스입니다. 보안 패치를 포함한 다양한 패치 작업을 신속하게 수행할 수 있습니다. 이를 통해 모든 EC2 인스턴스에 대해 신속하게 패치 작업을 실행할 수 있습니다.
    • AWS Systems Manager Run Command: 여러 인스턴스에 대해 원격으로 명령을 실행할 수 있는 서비스입니다. 패치 작업을 신속하게 수동 또는 자동화된 방식으로 실행하는 데 유용합니다. Run Command를 사용하면 긴급한 패치 작업을 즉시 수행할 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “모든 EC2 인스턴스에 패치를 적용할 AWS Lambda 함수를 생성합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 Lambda 함수는 대규모 패치 작업에 적합하지 않기 때문입니다. Lambda는 주로 짧은 시간 내에 완료되는 작업에 적합하며, 1,000개의 EC2 인스턴스를 패치하는 데에는 적절하지 않습니다.

 

선택지 2번은 “모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager Patch Manager를 구성합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 Patch Manager는 패치 작업을 자동화할 수 있지만, 특정 시점에 신속하게 패치를 적용하려면 Run Command와 같은 다른 도구가 더 적합할 수 있기 때문입니다.

 

선택지 3번은 “모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager 유지 관리 기간을 예약합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 유지 관리 기간을 예약하는 것은 패치 작업을 계획된 시간에 수행하게 하지만, 긴급한 보안 패치의 즉각적인 적용에는 적합하지 않기 때문입니다.

 

선택지 4번은 “AWS Systems Manager Run Command를 사용하여 패치를 모든 EC2 인스턴스에 적용하는 사용자 지정 명령을 실행합니다.”입니다.

 이 선택지는 AWS Systems Manager Run Command를 사용해 EC2 인스턴스에 패치를 빠르게 배포하는 방법을 제안합니다. 이를 통해 운영 오버헤드를 최소화하면서도 보안 취약성을 즉각적으로 수정할 수 있습니다. 이는 가능한 한 빨리 모든 인스턴스에 패치를 적용해야 하는 요구 사항을 충족합니다.

 

 

문제에 대한 정답은 선택지 4번이었습니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 1가지의 요구사항이 존재해요. 그렇지만 세부적으로 알아야 할 게 존재한답니다.

 

1. 소프트웨어 패치

  • 1,000개의 Amazon EC2 Linux 인스턴스에서 실행되는 프로덕션 워크로드
  • 워크로드가 타사 소프트웨어로 구동
  • 가능한 한 빨리 모든 EC2 인스턴스에서 타사 소프트웨어를 패치
  • 중요한 보안 취약성을 수정

→ 종합하면, 회사가 사용하고 있는 다른 회사의 소프트웨어에서 심각한 보안 문제가 발견되었고, 이를 해결하기 위해 1,000개의 모든 서버에 최대한 빨리 소프트웨어 업데이트를 적용해야 하는 상황이에요.

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 소프트웨어 패치

  • AWS Systems Manager: 대규모 인스턴스 관리 및 자동화를 지원하는 서비스로, 인스턴스의 상태를 모니터링하고 제어할 수 있습니다. 이 서비스를 통해 여러 EC2 인스턴스를 중앙에서 관리하고 운영할 수 있습니다.
    • AWS Systems Manager Automation: 사용하면 타사 소프트웨어를 포함한 다양한 워크로드를 자동화된 방식으로 관리할 수 있습니다. 이는 패치 작업을 자동으로 수행하는 데 유용합니다.
    • AWS Systems Manager Patch Manager: AWS에서 패치 관리를 자동화하는 서비스입니다. 보안 패치를 포함한 다양한 패치 작업을 신속하게 수행할 수 있습니다. 이를 통해 모든 EC2 인스턴스에 대해 신속하게 패치 작업을 실행할 수 있습니다.
    • AWS Systems Manager Run Command: 여러 인스턴스에 대해 원격으로 명령을 실행할 수 있는 서비스입니다. 패치 작업을 신속하게 수동 또는 자동화된 방식으로 실행하는 데 유용합니다. Run Command를 사용하면 긴급한 패치 작업을 즉시 수행할 수 있습니다.

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “모든 EC2 인스턴스에 패치를 적용할 AWS Lambda 함수를 생성합니다.”입니다.

  • AWS Lambda: 서버리스 컴퓨팅 서비스로, 이벤트 기반으로 코드를 실행할 수 있습니다. 그러나 Lambda 함수는 일반적으로 짧은 실행 시간을 가지며, 대규모 인스턴스 패치 작업에는 적합하지 않을 수 있습니다. Lambda 함수로 1,000개의 EC2 인스턴스를 패치하는 것은 비효율적일 수 있으며, 운영 오버헤드가 많이 발생할 수 있습니다.

이 선택지가 정답이 아닌 이유는 Lambda 함수는 대규모 패치 작업에 적합하지 않기 때문입니다. Lambda는 주로 짧은 시간 내에 완료되는 작업에 적합하며, 1,000개의 EC2 인스턴스를 패치하는 데에는 적절하지 않습니다.

 

선택지 2번은 “모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager Patch Manager를 구성합니다.”입니다.

  • AWS Systems Manager Patch Manager: AWS Systems Manager의 기능으로, EC2 인스턴스에 자동으로 패치를 적용할 수 있습니다. 이 서비스는 패치 관리 작업을 자동화하고, 보안 패치 적용을 신속하게 수행할 수 있도록 도와줍니다.

이 선택지가 정답이 아닌 이유는 Patch Manager는 패치 작업을 자동화할 수 있지만, 특정 시점에 신속하게 패치를 적용하려면 Run Command와 같은 다른 도구가 더 적합할 수 있기 때문입니다.

 

선택지 3번은 “모든 EC2 인스턴스에 패치를 적용하도록 AWS Systems Manager 유지 관리 기간을 예약합니다.”입니다.

  • AWS Systems Manager 유지 관리 기간: 패치, 업데이트, 기타 유지 관리 작업을 예약할 수 있는 기능입니다. 유지 관리 기간 동안 시스템은 자동으로 작업을 수행하며, 운영 오버헤드를 줄일 수 있습니다. 그러나 패치 작업의 즉각적인 실행에는 적합하지 않을 수 있습니다.

이 선택지가 정답이 아닌 이유는 유지 관리 기간을 예약하는 것은 패치 작업을 계획된 시간에 수행하게 하지만, 긴급한 보안 패치의 즉각적인 적용에는 적합하지 않기 때문입니다.

 

선택지 4번은 “AWS Systems Manager Run Command를 사용하여 패치를 모든 EC2 인스턴스에 적용하는 사용자 지정 명령을 실행합니다.”입니다.

  • AWS Systems Manager Run Command: 여러 인스턴스에 대해 원격으로 명령을 실행할 수 있는 서비스로, 패치 작업을 신속하게 수동 또는 자동화된 방식으로 실행하는 데 유용합니다. Run Command를 사용하면 긴급한 패치 작업을 즉시 수행할 수 있습니다.

이 선택지는 AWS Systems Manager Run Command를 사용해 EC2 인스턴스에 패치를 빠르게 배포하는 방법을 제안합니다. 이를 통해 운영 오버헤드를 최소화하면서도 보안 취약성을 즉각적으로 수정할 수 있습니다. 이는 가능한 한 빨리 모든 인스턴스에 패치를 적용해야 하는 요구 사항을 충족합니다.

 

 

마지막 문제 살펴볼게요.


문제

회사는 NFS를 사용하여 온프레미스 네트워크 연결 스토리지에 대용량 비디오 파일을 저장합니다.

각 비디오 파일의 크기는 1MB에서 500GB까지입니다.

총 스토리지는 70TB이며 더 이상 증가하지 않습니다.

회사는 비디오 파일을 Amazon S3로 마이그레이션 하기로 결정합니다.

회사는 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 비디오 파일을 마이그레이션 해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

1. S3 버킷을 생성합니다. S3 버킷에 쓸 수 있는 권한이 있는 IAM 역할을 생성합니다. AWS CLI를 사용하여 모든 파일을 S3 버킷에 로컬로 복사합니다.

2. AWS Snowball Edge 작업을 생성합니다. 온프레미스에서 Snowball Edge 디바이스를 받습니다. Snowball Edge 클라이언트를 사용하여 데이터를 디바이스로 전송합니다. AWS가 데이터를 Amazon S3로 가져올 수 있도록 장치를 반환하십시오.

3. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 공용 서비스 엔드포인트를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.

4. 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 가상 인터페이스 (VIF)를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.


요구사항에 맞는 서비스

1. 비디오 파일을 Amazon S3로 마이그레이션

  • AWS DataSync: 온프레미스 스토리지를 Amazon S3로 전송하는 관리형 데이터 전송 서비스입니다. DataSync는 네트워크 최적화 기능을 통해 네트워크 대역폭을 효율적으로 사용하며, NFS(네트워크 파일 시스템)와 통합되어 온프레미스의 NFS 스토리지에서 Amazon S3로 데이터를 직접 전송할 수 있습니다.
  • AWS Snowball: 대용량 데이터를 AWS로 전송하기 위한 물리적 디바이스 솔루션입니다. 인터넷 대역폭이 제한적이거나 데이터 전송 시간이 중요한 경우 Snowball을 통해 데이터를 빠르게 전송할 수 있습니다. Snowball 디바이스를 사용하면 대량의 데이터를 로컬에서 AWS로 전송할 수 있으며, 인터넷을 통한 데이터 전송에 비해 네트워크 대역폭 사용을 최소화할 수 있습니다.
  • AWS Storage Gateway: 온프레미스 데이터를 AWS S3로 전송하기 위한 하이브리드 클라우드 스토리지 솔루션입니다. S3 파일 게이트웨이(S3 File Gateway)를 사용하면 온프레미스의 기존 NFS 파일 공유를 S3로 마이그레이션 할 수 있습니다.
  • AWS Transfer Family: SFTP, FTPS, FTP를 통해 파일을 Amazon S3로 전송할 수 있는 완전 관리형 서비스입니다. Transfer Family를 사용하면 파일 전송을 위해 기존의 SFTP, FTPS, FTP 클라이언트를 사용할 수 있으며, 이를 통해 기존 온프레미스 스토리지에서 Amazon S3로 파일을 전송할 수 있습니다. 네트워크 대역폭을 효율적으로 사용하면서 데이터 전송을 자동화할 수 있습니다.
  • AWS Direct Connect: 온프레미스 환경과 AWS 간의 전용 네트워크 연결을 제공하는 서비스입니다. 네트워크 대역폭을 효율적으로 사용하면서도 안정적이고 빠른 데이터 전송을 가능하게 합니다. Direct Connect를 통해 데이터를 AWS로 전송할 때 공용 인터넷을 우회하여 전송 속도와 안정성을 향상할 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “S3 버킷을 생성합니다. S3 버킷에 쓸 수 있는 권한이 있는 IAM 역할을 생성합니다. AWS CLI를 사용하여 모든 파일을 S3 버킷에 로컬로 복사합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 AWS CLI를 사용하여 데이터를 로컬에서 S3로 직접 복사하는 것은 네트워크 대역폭을 많이 소비할 수 있습니다. 또한, 70TB의 대용량 데이터를 네트워크를 통해 전송하는 데 시간이 오래 걸릴 수 있어, 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못합니다.

 

선택지 2번은 “AWS Snowball Edge 작업을 생성합니다. 온프레미스에서 Snowball Edge 디바이스를 받습니다. Snowball Edge 클라이언트를 사용하여 데이터를 디바이스로 전송합니다. AWS가 데이터를 Amazon S3로 가져올 수 있도록 장치를 반환하십시오.”입니다.

 이 선택지는 AWS Snowball Edge는 대용량 데이터를 물리적으로 전송함으로써 네트워크 대역폭을 절약할 수 있습니다. 이 방법은 70TB의 데이터를 빠르게 전송할 수 있어, 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족합니다. 또한, Snowball Edge 디바이스는 데이터 전송을 위한 고속 네트워크 인터페이스를 제공하여, 데이터를 빠르게 디바이스로 전송할 수 있습니다.

 

선택지 3번은 “온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 공용 서비스 엔드포인트를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 S3 파일 게이트웨이를 사용하여 데이터를 전송하는 경우, 네트워크 대역폭을 사용하게 되기 때문입니다. 70TB의 대용량 데이터를 네트워크를 통해 전송하는 데 시간이 오래 걸릴 수 있으며, 이는 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못할 수 있습니다.

 

선택지 4번은 “온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 가상 인터페이스 (VIF)를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.”입니다.

 이 선택지가 정답이 아닌 이유는 AWS Direct Connect를 통해 네트워크 대역폭을 높이고 안정적인 연결을 제공할 수 있지만, 여전히 네트워크를 통해 데이터를 전송하는 방식이기 때문입니다. 70TB의 데이터를 전송하는 데 시간이 많이 걸릴 수 있으며, 이는 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못할 수 있습니다.

 

 

문제에 대한 정답은 선택지 2번이었습니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 1가지의 요구사항이 존재해요. 그렇지만 세부적으로 알아야 할 게 존재합니다.

 

1. 비디오 파일을 Amazon S3로 마이그레이션

  • 각 비디오 파일의 크기는 1MB에서 500GB까지 다양
  • 총 스토리지는 70TB
  • 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 비디오 파일을 Amazon S3로 마이그레이션

  • AWS DataSync: 온프레미스 스토리지를 Amazon S3로 전송하는 관리형 데이터 전송 서비스입니다. DataSync는 네트워크 최적화 기능을 통해 네트워크 대역폭을 효율적으로 사용하며, NFS(네트워크 파일 시스템)와 통합되어 온프레미스의 NFS 스토리지에서 Amazon S3로 데이터를 직접 전송할 수 있습니다.
  • AWS Snowball: 대용량 데이터를 AWS로 전송하기 위한 물리적 디바이스 솔루션입니다. 인터넷 대역폭이 제한적이거나 데이터 전송 시간이 중요한 경우 Snowball을 통해 데이터를 빠르게 전송할 수 있습니다. Snowball 디바이스를 사용하면 대량의 데이터를 로컬에서 AWS로 전송할 수 있으며, 인터넷을 통한 데이터 전송에 비해 네트워크 대역폭 사용을 최소화할 수 있습니다.
  • AWS Storage Gateway: 온프레미스 데이터를 AWS S3로 전송하기 위한 하이브리드 클라우드 스토리지 솔루션입니다. S3 파일 게이트웨이(S3 File Gateway)를 사용하면 온프레미스의 기존 NFS 파일 공유를 S3로 마이그레이션할 수 있습니다.
  • AWS Transfer Family: SFTP, FTPS, FTP를 통해 파일을 Amazon S3로 전송할 수 있는 완전 관리형 서비스입니다. Transfer Family를 사용하면 파일 전송을 위해 기존의 SFTP, FTPS, FTP 클라이언트를 사용할 수 있으며, 이를 통해 기존 온프레미스 스토리지에서 Amazon S3로 파일을 전송할 수 있습니다. 네트워크 대역폭을 효율적으로 사용하면서 데이터 전송을 자동화할 수 있습니다.
  • AWS Direct Connect: 온프레미스 환경과 AWS 간의 전용 네트워크 연결을 제공하는 서비스입니다. 네트워크 대역폭을 효율적으로 사용하면서도 안정적이고 빠른 데이터 전송을 가능하게 합니다. Direct Connect를 통해 데이터를 AWS로 전송할 때 공용 인터넷을 우회하여 전송 속도와 안정성을 향상시킬 수 있습니다.

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “S3 버킷을 생성합니다. S3 버킷에 쓸 수 있는 권한이 있는 IAM 역할을 생성합니다. AWS CLI를 사용하여 모든 파일을 S3 버킷에 로컬로 복사합니다.”입니다.

  • Amazon S3: 객체 스토리지 서비스로, 데이터를 저장하고 관리하는 데 사용됩니다. 대규모 데이터 저장에 적합합니다.
  • AWS CLI: AWS 서비스와 상호 작용하기 위한 명령줄 도구로, 데이터를 S3로 복사하는 데 사용할 수 있습니다.

이 선택지가 정답이 아닌 이유는 AWS CLI를 사용하여 데이터를 로컬에서 S3로 직접 복사하는 것은 네트워크 대역폭을 많이 소비할 수 있습니다. 또한, 70TB의 대용량 데이터를 네트워크를 통해 전송하는 데 시간이 오래 걸릴 수 있어, 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못합니다.

 

선택지 2번은 “AWS Snowball Edge 작업을 생성합니다. 온프레미스에서 Snowball Edge 디바이스를 받습니다. Snowball Edge 클라이언트를 사용하여 데이터를 디바이스로 전송합니다. AWS가 데이터를 Amazon S3로 가져올 수 있도록 장치를 반환하십시오.”입니다.

  • AWS Snowball Edge: 대용량 데이터를 AWS로 전송하기 위한 물리적 디바이스 솔루션으로, 인터넷을 통한 데이터 전송 대신 물리적 전송을 통해 네트워크 대역폭을 절약할 수 있습니다.

이 선택지는 AWS Snowball Edge는 대용량 데이터를 물리적으로 전송함으로써 네트워크 대역폭을 절약할 수 있습니다. 이 방법은 70TB의 데이터를 빠르게 전송할 수 있어, 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족합니다. 또한, Snowball Edge 디바이스는 데이터 전송을 위한 고속 네트워크 인터페이스를 제공하여, 데이터를 빠르게 디바이스로 전송할 수 있습니다.

 

선택지 3번은 “온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 공용 서비스 엔드포인트를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.”입니다.

  • AWS Storage Gateway (S3 File Gateway): 온프레미스 데이터를 AWS S3로 전송하기 위한 하이브리드 클라우드 스토리지 솔루션으로, 네트워크를 통해 데이터를 전송합니다.

이 선택지가 정답이 아닌 이유는 S3 파일 게이트웨이를 사용하여 데이터를 전송하는 경우, 네트워크 대역폭을 사용하게 되기 때문입니다. 70TB의 대용량 데이터를 네트워크를 통해 전송하는 데 시간이 오래 걸릴 수 있으며, 이는 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못할 수 있습니다.

 

선택지 4번은 “온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 가상 인터페이스 (VIF)를 생성합니다. S3 버킷을 생성합니다. S3 File Gateway에서 새 NFS 파일 공유를 생성합니다. 새 파일 공유가 S3 버킷을 가리키도록 합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.”입니다.

  • AWS Direct Connect: 온프레미스와 AWS 간의 전용 네트워크 연결을 제공하여 안정적이고 고속의 데이터 전송을 가능하게 합니다.
  • AWS Storage Gateway (S3 File Gateway): 온프레미스 데이터를 AWS S3로 전송하기 위한 하이브리드 클라우드 스토리지 솔루션으로, 네트워크를 통해 데이터를 전송합니다.

이 선택지가 정답이 아닌 이유는 AWS Direct Connect를 통해 네트워크 대역폭을 높이고 안정적인 연결을 제공할 수 있지만, 여전히 네트워크를 통해 데이터를 전송하는 방식이기 때문입니다. 70TB의 데이터를 전송하는 데 시간이 많이 걸릴 수 있으며, 이는 최소한의 네트워크 대역폭을 사용하면서 가능한 한 빨리 마이그레이션 해야 하는 요구사항을 충족하지 못할 수 있습니다.

 

 

새롭게 선보인 문제 분석 블로그 형식은 어떠신가요?

핵심만 쏙쏙 뽑아 간단히 보여드리고, 더 자세한 내용은 링크로 연결해 두었어요.

이렇게 하면 여러분이 공부하실 때 시간도 절약하고, 필요한 부분만 골라서 볼 수 있어 더욱 효율적일 거예요.

이 새로운 방식이 여러분의 학습에 많은 도움이 되길 진심으로 바랍니다.

앞으로도 여러분에게 더 좋은 정보를 전달하기 위해 계속 고민하고 노력할게요.

함께 더 나은 학습 경험을 만들어 갈 수 있길 기대합니다! 함께 성장해요! 🌱

오늘 글이 유익하셨길 바라며, 다음에는 또 다른 문제로 찾아뵙겠습니다.

 

감사합니다. 다음 글에서 만나요! 😊