안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
Amazon EC2 관리자는 여러 사용자를 포함하는 IAM 그룹과 연결된 다음 정책을 생성했습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.100.100.0/24"
}
}
},
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ec2:Region": "us-east-1"
}
}
}
]
}
이 정책의 효과는 무엇입니까?
선택지
A. 사용자는 us-east-1을 제외한 모든 AWS 리전에서 EC2 인스턴스를 종료할 수 있습니다.
B. 사용자는 us-east-1 지역에서 IP 주소가 10.100.100.1인 EC2 인스턴스를 종료할 수 있습니다.
C. 사용자의 소스 IP가 10.100.100.254인 경우 사용자는 us-east-1 지역에서 EC2 인스턴스를 종료할 수 있습니다.
D. 사용자의 소스 IP가 10.100.100.254인 경우 사용자는 us-east-1 지역에서 EC2 인스턴스를 종료할 수 없습니다.
풀이
위 정책은 특정 IP 주소 범위(10.100.100.0/24)에서 EC2 인스턴스를 종료할 수 있도록 허용하는 동시에 us-east-1 리전을 제외한 모든 지역에서 EC2 관련 작업을 거부해요.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 해당 정책의 효과
2. 관련 AWS 서비스 생각하기
AWS 정책(Policy)은 AWS 리소스에 대한 접근 권한을 관리하는 핵심 도구로, 사용자, 그룹, 역할의 권한을 세밀하게 정의해요.
JSON 형식으로 작성되고, Version과 Statement를 주요 요소로 포함합니다.
정책의 Statement는 Effect, Action, Resource, Condition 요소로 구성되며, 각각 다음과 같은 역할을 합니다.
- Effect는 특정 작업을 "Allow"(허용) 또는 "Deny"(거부)로 지정해요.
- Action은 AWS 서비스에서 수행할 수 있는 특정 작업들을 나타냅니다.
- Resource는 정책이 적용될 특정 AWS 리소스를 지정하는데, Amazon 리소스 이름(ARN)을 사용해요.
- Condition은 정책이 적용되는 조건을 설정합니다. 특정 IP 범위에서만 접근을 허용하거나, 특정 시간대에만 작업을 허용하는 등의 세부적인 제어가 가능합니다.
예를 들어서, 아래와 같은 정책이 있다고 해볼게요.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ec2:Describe*", "ec2:StartInstances", "ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:RequestedRegion": "us-west-2"}
}
}
]
}
이 정책은 사용자에게 us-west-2 리전에서 EC2 인스턴스를 조회, 시작, 중지할 수 있는 권한을 부여해요. "Effect"는 이 작업들을 허용하고, "Action"은 구체적인 EC2 작업(조회, 시작, 중지)을, "Resource"는 모든 EC2 리소스를 대상으로 한다는 걸 지정한 거죠. "Condition"은 이 권한이 특정 리전(us-west-2)에서만 적용되도록 제한한 거예요.
정책은 IAM 사용자, 그룹, 역할에 직접 연결되거나(Identity-based), S3 버킷 같은 특정 리소스에 직접 적용됩니다(Resource-based). AWS는 최소 권한 원칙을 권장하며, 여러 정책이 적용될 경우 모든 관련 정책을 종합적으로 평가하되 명시적 거부"Deny"가 허용보다 우선합니다.
3. 선택지 분석하기
A. 사용자는 us-east-1을 제외한 모든 AWS 리전에서 EC2 인스턴스를 종료할 수 있습니다.
→ us-east-1 이외의 리전에서는 모든 EC2 작업이 거부됩니다.
B. 사용자는 us-east-1 지역에서 IP 주소가 10.100.100.1인 EC2 인스턴스를 종료할 수 있습니다.
→ IP 범위가 더 넓습니다 (10.100.100.0/24).
C. 사용자의 소스 IP가 10.100.100.254인 경우 사용자는 us-east-1 지역에서 EC2 인스턴스를 종료할 수 있습니다.
D. 사용자의 소스 IP가 10.100.100.254인 경우 사용자는 us-east-1 지역에서 EC2 인스턴스를 종료할 수 없습니다.
→ 조건을 만족하므로 종료할 수 있습니다.
이어서 다음 문제입니다.
문제2.
회사의 동적 웹 사이트는 미국의 온프레미스 서버를 사용하여 호스팅됩니다.
이 회사는 유럽에서 제품을 출시하고 있으며 새로운 유럽 사용자를 위해 사이트 로드 시간을 최적화하려고 합니다.
사이트의 백엔드는 미국에 남아 있어야 합니다. 이 제품은 며칠 안에 출시되며 즉각적인 솔루션이 필요합니다.
솔루션 설계자는 무엇을 추천해야 합니까?
선택지
A. us-east-1에서 Amazon EC2 인스턴스를 시작하고 사이트를 여기로 마이그레이션합니다.
B. 웹사이트를 Amazon S3로 이동합니다. 리전 간 교차 리전 복제를 사용합니다.
C. 온프레미스 서버를 가리키는 사용자 지정 오리진과 함께 Amazon CloudFront를 사용합니다.
D. 온프레미스 서버를 가리키는 Amazon Route 53 지리 근접 라우팅 정책을 사용합니다.
풀이
CloudFront는 콘텐츠 전송 네트워크(CDN) 서비스로, 이 서비스를 사용하면 현재의 온프레미스 서버를 그대로 유지하면서도 전 세계에 분산된 AWS의 엣지 로케이션을 활용할 수 있어요.
CloudFront를 설정 시, 현재의 온프레미스 서버를 '사용자 지정 오리진'으로 지정하면 CloudFront는 이 서버에서 콘텐츠를 가져와 전 세계의 엣지 로케이션에 분산 저장하게 됩니다.
유럽의 사용자가 웹사이트에 접속하면, 가장 가까운 엣지 로케이션에서 콘텐츠를 제공받게 되어 로딩 시간이 크게 단축돼요.
만약 요청된 콘텐츠가 엣지 로케이션에 없다면, CloudFront가 미국의 온프레미스 서버에서 해당 콘텐츠를 가져와 사용자에게 전달하고, 동시에 엣지 로케이션에 저장합니다. 이후 동일한 콘텐츠에 대한 요청이 있으면 엣지 로케이션에서 빠르게 제공할 수 있게 되는 거죠.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 현재 웹사이트는 미국의 온프레미스 서버에서 호스팅
→ "온프레미스 서버"란 기업이나 조직이 자체적으로 보유하고 운영하는 물리적인 서버를 말해요. 보통 회사 내부의 데이터 센터을 의미합니다. - 유럽 사용자를 위해 사이트 로드 시간을 최적화
- 백엔드는 미국에 유지
- 즉각적인 솔루션이 필요
2. 관련 AWS 서비스 생각하기
CloudFront는 글로벌 콘텐츠 전송 네트워크(CDN) 서비스입니다. 전 세계에 분산된 엣지 로케이션을 통해 웹 콘텐츠를 사용자에게 빠르게 전달합니다. 웹사이트, API, 비디오 콘텐츠 등을 캐싱하여 제공함으로써 지연 시간을 줄이고 성능을 향상합니다.
헷갈릴 수 있는 단어들이 나오는데 설명하자면,
→"CDN (Content Delivery Network)"란 사용자와 가까운 위치에서 콘텐츠를 제공하는 분산 서버 네트워크를 말해요.
→ "엣지 로케이션"는 CDN의 분산된 서버 위치입니다.
→ "캐싱"이란 자주 사용되는 데이터를 임시로 저장하여 빠르게 접근할 수 있게 하는 기술이에요.
CloudFront의 작동 방식은 사용자의 웹사이트 접속부터 시작돼요. 사용자가 웹사이트에 접속하면, DNS 시스템이 해당 요청을 사용자와 지리적으로 가장 가까운 CloudFront 엣지 로케이션으로 라우팅합니다. 요청을 받은 엣지 로케이션은 먼저 해당 콘텐츠가 자신의 캐시에 저장되어 있는지 확인합니다. 만약 요청된 콘텐츠가 이미 엣지 로케이션에 캐싱되어 있다면(Cache Hit), 즉시 그 콘텐츠를 사용자에게 전달합니다. 이 경우, 사용자는 매우 빠른 응답 시간을 경험하게 됩니다.
그러나 요청된 콘텐츠가 엣지 로케이션에 캐싱되어 있지 않다면(Cache Miss), CloudFront는 오리진 서버로 요청을 전달합니다. 오리진 서버는 온프레미스 서버일 수도 있고, Amazon S3 버킷이나 EC2 인스턴스 같은 AWS 리소스일 수도 있습니다. 오리진 서버에서 콘텐츠를 받아오면, CloudFront는 이를 사용자에게 전달함과 동시에 해당 엣지 로케이션의 캐시에 저장합니다. 이렇게 함으로써 동일한 지역의 다른 사용자가 같은 콘텐츠를 요청할 때 더 빠르게 응답할 수 있게 됩니다.
CloudFront를 사용하면 성능 향상, 비용 절감, 확장성 개선, 보안 강화 등의 이점을 얻을 수 있습니다. 정적 웹사이트 호스팅, 동적 웹 애플리케이션 가속, 비디오 스트리밍 서비스, 모바일 앱 API 가속, 소프트웨어 배포 등 다양한 사용 사례에 적용될 수 있어요.
또한 CloudFront는 다른 AWS 서비스들과 쉽게 통합되어 더욱 강력한 솔루션을 구축할 수 있게 해 줍니다. 사용자는 캐시 동작 설정, 오리진 설정, Lambda@Edge 등을 통해 서비스를 커스터마이징 할 수 있습니다. 이를 통해 특정 URL 패턴에 대한 캐싱 정책을 세밀하게 조정하거나, 여러 오리진을 설정하고 요청에 따라 다른 오리진으로 라우팅 하거나, CloudFront의 엣지에서 코드를 실행하여 요청과 응답을 커스터마이징 할 수 있습니다.
3. 선택지 분석하기
A. us-east-1에서 Amazon EC2 인스턴스를 시작하고 사이트를 여기로 마이그레이션합니다.
→ EC2로의 마이그레이션은 시간이 오래 걸리고, 유럽 사용자의 로드 시간 개선에 직접적인 도움이 되지 않습니다.
→ "마이그레이션"란 시스템이나 데이터를 한 환경에서 다른 환경으로 이동하는 과정을 말해요.
B. 웹사이트를 Amazon S3로 이동합니다. 리전 간 교차 리전 복제를 사용합니다.
→ S3로의 이동은 동적 웹사이트에 적합하지 않으며, 마이그레이션에 시간이 필요합니다.
C. 온프레미스 서버를 가리키는 사용자 지정 오리진과 함께 Amazon CloudFront를 사용합니다.
D. 온프레미스 서버를 가리키는 Amazon Route 53 지리 근접 라우팅 정책을 사용합니다.
→ Route 53의 지리 근접 라우팅만으로는 콘텐츠 전송 속도를 크게 개선하기 어렵습니다.
마지막 문제 살펴볼게요.
문제3.
회사에는 VPC의 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 있습니다.
애플리케이션 중 하나는 Amazon S3 API를 호출하여 객체를 저장하고 읽어야 합니다.
회사의 보안 정책은 애플리케이션에서 인터넷에 연결된 모든 트래픽을 제한합니다.
이러한 요구 사항을 충족하고 보안을 유지하는 조치는 무엇입니까?
선택지
A. S3 인터페이스 엔드포인트를 구성합니다.
B. S3 게이트웨이 엔드포인트를 구성합니다.
C. 프라이빗 서브넷에 S3 버킷을 생성합니다.
D. EC2 인스턴스와 동일한 지역에 S3 버킷을 생성합니다.
풀이
회사의 보안 정책은 애플리케이션의 인터넷 연결 트래픽을 제한하고 있기 때문에, 이를 충족하면서 S3에 접근해야 합니다.
S3 게이트웨이 엔드포인트는 VPC 내부에서 S3로 직접 연결할 수 있는 경로를 제공합니다. 이를 통해 EC2 인스턴스는 인터넷을 거치지 않고 VPC 내부 네트워크를 통해 S3에 안전하게 접근할 수 있어요. 게이트웨이 엔드포인트는 VPC의 라우팅 테이블에 추가되어 S3로 향하는 트래픽을 제어하며, 추가 비용 없이 사용할 수 있고 높은 가용성과 확장성을 제공합니다.
S3 게이트웨이 엔드포인트를 사용하면 회사는 보안 정책을 준수하면서도 EC2 인스턴스에서 S3 API를 효과적으로 사용할 수 있게 됩니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- EC2 인스턴스에서 S3 API를 호출
- 애플리케이션의 인터넷 연결 트래픽 제한
- 보안 유지
2. 관련 AWS 서비스 생각하기
S3 게이트웨이 엔드포인트는 Amazon VPC 내의 리소스가 인터넷을 통하지 않고 직접 Amazon S3에 접근할 수 있게 해주는 AWS의 네트워킹 기능입니다. 이 엔드포인트는 VPC의 라우팅 테이블에 추가되어 S3로 향하는 트래픽을 VPC 내부에서 처리합니다.
예시 라우팅 테이블의 "Destination pl-63a5400a | Target vpce-11bb22cc" 이 규칙이 S3 게이트웨이 엔드포인트와 관련된 부분이에요. S3로 향하는 모든 트래픽은 VPC 엔드포인트(vpce-11bb22cc)로 라우팅 되는 거죠.
→ "라우팅 테이블"은 VPC 내에서 네트워크 트래픽의 방향을 결정하는 규칙들의 집합이에요. 각 규칙은 특정 목적지로 향하는 트래픽을 어디로 보낼지 지정합니다.
pl-63a5400a는 S3 서비스의 IP 범위를 나타내는 프리픽스 리스트 ID입니다.
→ "프리픽스 리스트 ID"란 하나 이상의 IP 주소 범위를 그룹화한 것이에요. S3 서비스는 여러 IP 주소 범위를 사용하기 때문에 S3로 향하는 트래픽을 정의할 때, 개별 IP 범위 대신 이 프리픽스 리스트 ID를 사용합니다.
게이트웨이 엔드포인트를 설정하면, VPC 내의 EC2 인스턴스나 다른 리소스들이 프라이빗 IP 주소를 사용하여 S3와 통신할 수 있게 됩니다. 이는 보안을 강화하고 데이터 전송 비용을 절감하는 효과가 있습니다. 특정 VPC와 서브넷에 연결되며, 해당 VPC 내의 모든 인스턴스가 이를 사용할 수 있기 때문에, 이 엔드포인트는 고가용성을 제공하며, AWS에 의해 자동으로 관리되므로 사용자가 별도로 유지보수할 필요가 없어요.
게이트웨이 엔드포인트를 사용하면 S3에 접근하기 위해 NAT 게이트웨이나 인터넷 게이트웨이가 필요 없어집니다. 이는 네트워크 구조를 단순화하고 잠재적인 보안 위험을 줄이는 데 도움이 됩니다. 또한, S3 게이트웨이 엔드포인트는 무료로 제공되어 추가 비용 없이 사용할 수 있습니다. 이는 데이터 전송 비용을 절감하는 데 큰 도움이 됩니다.
S3 게이트웨이 엔드포인트를 구성할 때는 VPC의 DNS 설정을 활성화해야 하며, 엔드포인트 정책을 통해 S3 버킷이나 특정 작업에 대한 접근을 제어할 수 있습니다. 이를 통해 세밀한 보안 제어가 가능해집니다.
3. 선택지 분석하기
A. S3 인터페이스 엔드포인트를 구성합니다.
→ VPC 내부에서 S3에 접근할 수 있게 해 주지만, 게이트웨이 엔드포인트와 달리 추가 비용이 발생하고 설정이 더 복잡합니다.
→ "VPC(Virtual Private Cloud)"란 AWS 내에서 사용자가 정의한 가상 네트워크예요.
→ "인터페이스 엔드포인트"는 VPC 내부에 생성되는 ENI(탄력적 네트워크 인터페이스)를 통해 AWS 서비스에 연결하는 방식 말해요.
→ "ENI"는 컴퓨터의 네트워크 카드와 비슷한 개념이에요. 실제 컴퓨터에 네트워크 카드가 있어 인터넷에 연결되듯이, AWS의 가상 서버(EC2 인스턴스)에는 ENI가 있어 네트워크에 연결됩니다.
B. S3 게이트웨이 엔드포인트를 구성합니다.
C. 프라이빗 서브넷에 S3 버킷을 생성합니다.
→ S3 버킷은 VPC 내부에 생성할 수 없습니다. S3는 리전 수준의 서비스이기 때문입니다.
→ "리전"은 전 세계 여러 지역에 분산된 데이터 센터의 집합이에요.
D. EC2 인스턴스와 동일한 지역에 S3 버킷을 생성합니다.
→ 접근성을 높일 수는 있지만, 인터넷 연결 트래픽을 제한하라는 요구사항을 충족시키지 못합니다.
글의 구조를 개선했어요. 글을 읽을 때 핵심 내용만 쏙쏙 골라 가실 수 있도록 바꿨답니다.
바쁜 일상 속에서도 꼭 필요한 정보를 빠르게 얻으실 수 있을 거예요.
저는 늘 더 유익하고, 더 편리한 블로그를 만들기 위해 열심히 고민하고 있답니다.
그러니 피드백은 언제나 환영입니다!
오늘 글도 여러분께 도움이 됐길 바라며, 행복한 하루 보내세요!🍀
감사합니다. 다음 글에서 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
AWS SAA 합격으로 가는 길 #13 (1) | 2024.09.06 |
---|---|
AWS SAA 합격으로 가는 길 #12 (1) | 2024.09.05 |
AWS SAA 합격으로 가는 길 #10 (5) | 2024.09.03 |
AWS SAA 합격으로 가는 길 #9 (2) | 2024.09.02 |
AWS SAA 합격으로 가는 길 #8 (0) | 2024.08.26 |