AWS SAA 합격으로 가는 길 #174

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 😊

연휴 잘 보내셨나요? 요즘 부쩍 더워져서 벌써 여름이 기다리지는 달인 것 같습니다.

변화가 일어나는 계절이지만, 저희는 꾸준히 3문제씩 문제 풀어보도록 하겠습니다!

 

문제는 세 가지 단계를 거치며 풀어보겠습니다.

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

---

문제1

회사에는 VPC의 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 있습니다. 애플리케이션 중 하나는 Amazon S3 API를 호출하여 객체를 저장하고 읽어야 합니다. 회사의 보안 규정에 따라 애플리케이션의 트래픽은 인터넷을 통해 이동할 수 없습니다.

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

 

선택지

A. S3 게이트웨이 엔드포인트를 구성합니다.
B. 프라이빗 서브넷에 S3 버킷을 생성합니다.
C. EC2 인스턴스와 동일한 AWS 지역에 S3 버킷을 생성합니다.
D. EC2 인스턴스와 동일한 서브넷에서 NAT 게이트웨이를 구성합니다.

---

풀이

VPC 내부 EC2에서 S3로의 트래픽이 인터넷을 거치지 않아야 합니다. S3 게이트웨이 엔드포인트를 구성하면 VPC와 S3 사이에 AWS 내부 네트워크 경로가 생성되어 인터넷을 우회한 프라이빗 통신이 가능합니다.

 

정답 : A

 

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

---

1.  문제의 요구사항 분석하기

• VPC 내부 EC2에서 S3 API를 호출하기
• 객체 저장 및 읽기 작업을 수행하기
• 트래픽이 인터넷을 경유하지 않도록 하기 

2. 관련 AWS 서비스 생각하기

 

• Amazon S3 : 객체 스토리지 서비스로 무제한에 가까운 데이터를 저장하고 API를 통해 객체를 읽고 쓸 수 있습니다. 리전 단위로 운영되며 기본적으로 퍼블릭 엔드포인트를 통해 접근합니다.
• VPC 게이트웨이 엔드포인트 : S3와 DynamoDB에 대해 제공되는 엔드포인트 유형으로, 라우팅 테이블에 프리픽스 목록을 추가하여 AWS 내부 네트워크를 통해 서비스에 접근하도록 합니다. 추가 비용이 없으며 인터넷 게이트웨이나 NAT 장치가 필요하지 않습니다.
• VPC 인터페이스 엔드포인트 : AWS PrivateLink 기반으로 ENI를 통해 다양한 AWS 서비스에 프라이빗하게 접근하는 방식입니다. 시간당 요금과 데이터 처리 요금이 발생합니다.
• NAT 게이트웨이 : 프라이빗 서브넷의 인스턴스가 인터넷으로 아웃바운드 통신을 할 수 있도록 하는 관리형 서비스입니다. 외부에서의 인바운드 연결은 차단되지만 트래픽 자체는 인터넷을 경유합니다.

 

3. 선택지 분석하기

A. S3 게이트웨이 엔드포인트를 구성합니다.
→ VPC와 S3 간 트래픽이 AWS 내부망으로 라우팅되어 인터넷을 거치지 않는 선택지이기에 적절한 방법입니다.

 

B. 프라이빗 서브넷에 S3 버킷을 생성합니다.
→ S3는 리전 단위 서비스로 VPC 서브넷 안에 생성할 수 없습니다.

 

C. EC2 인스턴스와 동일한 AWS 지역에 S3 버킷을 생성합니다.
→ 동일 리전이어도 기본 접근 경로는 퍼블릭 엔드포인트라 인터넷을 경유합니다.

 

D. EC2 인스턴스와 동일한 서브넷에서 NAT 게이트웨이를 구성합니다.

→ NAT 게이트웨이는 결국 인터넷을 통해 S3로 통신하므로 보안 요구사항에 위배됩니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사는 데이터베이스 계층에 대한 기본 백업 설정과 함께 Amazon RDS를 사용합니다. 회사는 규제 요구 사항을 충족하기 위해 데이터베이스를 매일 백업해야 합니다. 회사는 30일 동안 백업을 보관해야 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 매일 RDS 스냅샷을 생성하는 AWS Lambda 함수를 작성합니다.
B. 자동 백업을 위해 30일의 보존 기간을 갖도록 RDS 데이터베이스를 수정합니다.
C. AWS 시스템 관리자 유지 관리 기간을 사용하여 RDS 백업 보존 기간을 수정합니다.
D. AWS CLI를 사용하여 매일 수동 스냅샷을 생성합니다. RDS 백업 보존 기간을 수정합니다.

---

풀이

매일 백업과 30일 보존을 최소 운영 오버헤드로 구현해야 합니다. RDS는 기본 자동 백업 기능에서 보존 기간을 최대 35일까지 설정할 수 있으므로, 보존 기간을 30일로 수정하는 것만으로 요구사항을 충족합니다.

 

 

 

정답 : B

 

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

---

1.  문제의 요구사항 분석하기

• 매일 데이터베이스 백업 수행하기
• 백업을 30일간 보관하기
• 최소한의 운영 오버헤드로 구현하기

2. 관련 AWS 서비스 생각하기

• Amazon RDS : AWS에서 제공하는 관리형 관계형 데이터베이스 서비스로 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 등 다양한 엔진을 지원합니다. 하드웨어 프로비저닝, 패치 적용, 백업 같은 운영 작업을 AWS가 자동으로 처리합니다. 다중 AZ 배포, 읽기 전용 복제본, 자동 스케일링 등 고가용성과 확장성 기능을 제공합니다.
  • Amazon RDS 자동 백업 : RDS가 매일 지정된 백업 윈도우에 자동으로 전체 스냅샷을 생성하고 트랜잭션 로그를 저장하는 관리형 기능입니다. 보존 기간은 1일에서 35일까지 설정할 수 있으며, 보존 기간이 지난 백업은 자동으로 삭제됩니다. 특정 시점 복구를 지원합니다.
  • Amazon RDS 수동 스냅샷 : 사용자가 직접 생성하는 스냅샷으로 명시적으로 삭제하기 전까지 유지됩니다. 자동 백업과 달리 수명 주기를 사용자가 직접 관리해야 합니다.

3. 선택지 분석하기

A. 매일 RDS 스냅샷을 생성하는 AWS Lambda 함수를 작성합니다.
→ 기본 자동 백업으로 충분한 작업을 Lambda로 구현하면 운영 오버헤드가 증가합니다.

 

B. 자동 백업을 위해 30일의 보존 기간을 갖도록 RDS 데이터베이스를 수정합니다.
→ 설정 변경만으로 매일 백업과 30일 보존이 동시에 충족되기에 최소 운영 오버헤드이면서 적절한 방법입니다.

 

C. AWS 시스템 관리자 유지 관리 기간을 사용하여 RDS 백업 보존 기간을 수정합니다.
→ AWS Systems Manager Maintenance Windows는 EC2 인스턴스나 온프레미스 서버 같은 관리형 노드에 대해 운영 작업을 수행할 시간대를 정의하는 기능입니다. 따라서 RDS 백업 보존 기간을 제어하는 기능이 아니기에 적절하지 않습니다.

 

D. AWS CLI를 사용하여 매일 수동 스냅샷을 생성합니다. RDS 백업 보존 기간을 수정합니다.

→ 수동 스냅샷을 매일 실행하려면 별도 스케줄러와 삭제 관리가 필요해 오버헤드가 크기에 적절하지 않습니다.

---

 

마지막 문제 살펴보겠습니다.

---

문제3

한 회사에서 Amazon Elastic Container Service(Amazon ECS)를 사용하여 하이브리드 환경에서 온프레미스 애플리케이션을 실행하려고 합니다. 애플리케이션은 현재 온프레미스 컨테이너에서 실행됩니다. 

회사에는 온프레미스, 하이브리드 또는 클라우드 환경에서 확장할 수 있는 단일 컨테이너 솔루션이 필요합니다. 회사는 AWS 클라우드에서 새로운 애플리케이션 컨테이너를 실행해야 하며 HTTP 트래픽용 로드 밸런서를 사용해야 합니다. 

이러한 요구 사항을 충족하는 작업 조합은 무엇입니까? (2개를 선택하세요.)

 

선택지

A. 클라우드 애플리케이션 컨테이너에 대해 AWS Fargate 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 온프레미스 애플리케이션 컨테이너에는 Amazon ECS Anywhere 외부 시작 유형을 사용합니다.
B. 클라우드 ECS 서비스를 위한 Application Load Balancer를 설정합니다.
C. 클라우드 ECS 서비스를 위한 Network Load Balancer를 설정합니다.
D. AWS Fargate 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 클라우드 애플리케이션 컨테이너와 온프레미스 애플리케이션 컨테이너에는 Fargate를 사용하세요.
E. 클라우드 애플리케이션 컨테이너에 Amazon EC2 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 온프레미스 애플리케이션 컨테이너에 대해 AWS Fargate 시작 유형과 함께 Amazon ECS Anywhere를 사용하십시오.

---

풀이

하이브리드 환경에서 클라우드와 온프레미스 양쪽에서 컨테이너를 운영해야 하므로, 클라우드용은 서버 관리가 필요 없는 Fargate를 쓰고 온프레미스용은 자체 서버에서 ECS를 돌릴 수 있게 해주는 ECS Anywhere를 사용합니다. HTTP 트래픽 분산에는 ALB가 가장 적합합니다.

 

정답 : A, B

 

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

---

1.  문제의 요구사항 분석하기

• 온프레미스와 클라우드를 단일 ECS 솔루션으로 통합 운영하기
• AWS 클라우드에서 새 애플리케이션 컨테이너 실행하기
• HTTP 트래픽용 로드 밸런서 구성하기

2. 관련 AWS 서비스 생각하기

• Amazon ECS : AWS의 관리형 컨테이너 오케스트레이션 서비스로 Docker 컨테이너의 배포와 확장, 운영을 자동화합니다. 시작 유형으로 EC2, Fargate, EXTERNAL을 지원하며 단일 컨트롤 플레인으로 다양한 환경의 컨테이너를 관리할 수 있습니다.
• AWS Fargate : 서버 인스턴스를 직접 관리하지 않고 컨테이너를 실행하는 서버리스 컴퓨팅 엔진입니다. ECS와 EKS에서 시작 유형으로 사용되며 AWS 클라우드 환경에서만 동작합니다.
• Amazon ECS Anywhere : 고객이 소유한 온프레미스 또는 외부 인프라에서 ECS 작업을 실행할 수 있게 해주는 기능입니다. EXTERNAL 시작 유형을 사용하며 AWS의 ECS 컨트롤 플레인이 외부 노드를 관리합니다.
• Application Load Balancer : OSI 7계층에서 동작하는 로드 밸런서로 HTTP와 HTTPS 트래픽을 처리합니다. 경로 기반, 호스트 기반 라우팅과 컨테이너 동적 포트 매핑을 지원해 ECS 서비스와 잘 통합됩니다.
• Network Load Balancer : OSI 4계층에서 동작하는 로드 밸런서로 TCP, UDP, TLS 트래픽을 초저지연으로 처리합니다. 정적 IP가 필요하거나 매우 높은 처리량이 요구되는 워크로드에 적합합니다.

3. 선택지 분석하기

A. 클라우드 애플리케이션 컨테이너에 대해 AWS Fargate 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 온프레미스 애플리케이션 컨테이너에는 Amazon ECS Anywhere 외부 시작 유형을 사용합니다.
→ 클라우드는 Fargate, 온프레미스는 ECS Anywhere의 EXTERNAL 시작 유형을 사용하는 표준 하이브리드 구성입니다.

 

B. 클라우드 ECS 서비스를 위한 Application Load Balancer를 설정합니다.
→ ALB는 HTTP 트래픽 처리에 최적화된 L7 로드 밸런서이므로 요구사항과 부합합니다.

 

C. 클라우드 ECS 서비스를 위한 Network Load Balancer를 설정합니다.
→ NLB는 L4 기반으로 HTTP 라우팅 기능이 없어 HTTP 트래픽 요구사항에 부적합합니다.

 

D. AWS Fargate 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 클라우드 애플리케이션 컨테이너와 온프레미스 애플리케이션 컨테이너에는 Fargate를 사용하세요.
→ Fargate는 AWS 클라우드 전용이라 온프레미스 환경에서는 실행할 수 없어 적절하지 않습니다.

 

E. 클라우드 애플리케이션 컨테이너에 Amazon EC2 시작 유형을 사용하는 ECS 클러스터를 설정합니다. 온프레미스 애플리케이션 컨테이너에 대해 AWS Fargate 시작 유형과 함께 Amazon ECS Anywhere를 사용하십시오.

→ ECS Anywhere는 EXTERNAL 시작 유형을 사용하며 Fargate와 결합할 수 없기에 적절하지 않습니다.

---

 

오늘 내용 중 1번과 2번 문제는 프로덕션에서 알고 있으면 좋은 아키텍처 방법입니다.

익숙해지시면 좋을 것 같아요! 그리고 3번은 하이브리드 방식이라 와닿지 않으실 수 있지만, 중요한 아키텍처이기에 꼭 명확히 이해하시기를 추천드립니다.

다음주 월요일에 뵙겠습니다! 😊