Q226 수천 개의 원격 장치에서 발생하는 원시 데이터를 EC2 서버로 수신하여 처리하고 S3에 저장하고 있습니다. 앞으로 장치 수가 수백만 개로 늘어날 예정인데, 운영 오버헤드를 줄이면서 무한히 확장할 수 있는 가장 스마트한 조합은 무엇일까요? (2개 선택) S3에 쌓인 원시 데이터를 AWS Glue로 처리합니다. Route 53을 사용하여 트래픽을 여러 EC2 인스턴스로 분산합니다. EC2 인스턴스를 수동으로 계속 추가하여 부하를 감당합니다. SQS 대기열을 거쳐 EC2가 데이터를 처리하도록 구조를 바꿉니다. API Gateway와 Kinesis Data Streams를 통해 데이터를 받고, Firehose를 거쳐 S3에 자동 저장합니다. 정답 확인 및 해설 📖 해설 정답은 A와 E입니다. 수백만 개의 장치에서 쏟아지는 대량의 데이터를 수동으로 서버(EC2)를 늘려 받는 것은 운영상 재앙에 가깝습니다. 대신 관리형 서비스인 API Gateway로 요청을 받고, 이를 Kinesis Data Streams라는 데이터 고속도로에 태운 뒤, Firehose라는 자동 배달부를 통해 S3에 착륙시키는 구조(E)가 훨씬 확장성 있고 관리가 편합니다. 이렇게 저장된 원시 데이터는 서버를 띄울 필요 없는 서버리스 ETL 도구인 AWS Glue(A)를 사용하여 깔끔하게 가공하면 전체 시스템의 운영 오버헤드를 획기적으로 낮출 수 있습니다. 다른 옵션인 B와 C는 여전히 관리 포인트가 많은 EC2 서버 기반이라 '운영 오버헤드 최소화'라는 목표에 어긋나며, D 역시 대규모 트래픽 상황에서 EC2 관리 부담을 완전히 털어내지 못합니다. 💡 이 문제의 핵심 용어 Kinesis Data Streams: 대규모로 쏟아지는 데이터를 실시간으로 수집하고 저장하는 데이터 고속도로 AWS Glue: 복잡한 코딩 없이 데이터를 자유자재로 변환해주는 서버리스 데이터 전담 서비스 Firehose: 스트리밍 데이터를 받아서 S3나 Redshift로 자동 배달해주는 완전 관리형 배달부
Q227 규정상 CloudTrail 로그를 3년 동안 보관해야 합니다. S3 버킷에 3년이 지나면 파일을 지우는 수명 주기 정책을 걸어뒀는데도, 이상하게 4년 차가 되었는데 창고에 물건(객체 수)이 줄지 않고 계속 쌓이기만 합니다. 범인은 누구이며 어떻게 해결해야 할까요? CloudTrail 설정에서 로그 만료 기간을 다시 설정합니다. 현재 버전뿐만 아니라 S3의 '이전 버전'까지 지우도록 수명 주기 정책을 보강합니다. 3년 넘은 파일을 일일이 찾아서 지워주는 람다 함수를 코딩합니다. S3 버킷의 소유주를 상위 계정으로 바꾸어 권한 문제를 해결합니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. 범인은 바로 '버전 관리(Versioning)'입니다. S3 버킷에 버전 관리가 켜져 있으면, 파일이 삭제되어도 '삭제 마커'가 붙은 채로 예전 기록(이전 버전)들이 창고 구석에 고스란히 남게 됩니다. 단순히 현재 파일을 지우라는 정책만으로는 이 유령 같은 이전 버전들을 없앨 수 없습니다. 따라서 수명 주기 정책 설정에서 '이전 버전 만료' 항목을 체크하여 3년이 지난 과거 버전들까지 싹 정리하도록 수정해야 합니다. 다른 옵션인 A는 S3의 물리적 저장 상태를 해결해주지 못하며, C는 이미 S3 자체 기능으로 가능한 일을 어렵게 코딩하는 낭비입니다. D 역시 데이터 삭제 로직과는 전혀 관련이 없는 권한 설정일 뿐입니다. 💡 이 문제의 핵심 용어 S3 Versioning: 파일을 덮어쓰거나 지워도 이전 기록을 모두 남겨두는 보험 같은 기능 Lifecycle Policy (수명 주기 정책): 시간이 지난 파일을 자동으로 삭제하거나 더 저렴한 저장소로 옮겨주는 관리 규칙 Noncurrent Versions (이전 버전): 버전 관리가 켜진 상태에서 수정되거나 삭제되기 전의 과거 파일 기록
Q228 실시간 데이터를 RDS 데이터베이스에 직접 저장하고 있는데, 손님이 몰리는 피크 타임만 되면 DB가 비명을 지르며 '타임아웃' 오류를 뱉어냅니다. 수집 효율을 높이고 데이터 유실을 막으면서 DB 연결 수도 줄이는 가장 확실한 처방은? 돈을 더 들여서 DB 서버 사양(메모리 등)을 대폭 업그레이드합니다. 다중 AZ 설정을 켜고 모든 인스턴스에 쓰기 작업을 골고루 나눠줍니다. 입구에서 데이터를 일단 SQS 대기열에 담아두고, 람다가 DB 컨디션에 맞춰 꺼내 넣게 합니다. SNS 주제에 데이터를 쏘고 람다가 이를 받아 DB에 저장하는 방식으로 바꿉니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 데이터베이스가 힘들어하는 이유는 '동시에 너무 많은 손님(연결)이 한꺼번에 들이닥쳐서'입니다. 이때 SQS라는 입국 심사 대기줄을 만들면 좋습니다. API는 DB를 직접 건드리지 않고 SQS에 데이터를 휙 던져놓기만 하면 임무 완료입니다. 그러면 람다 일꾼이 DB가 소화할 수 있는 속도로 대기열에서 하나씩 꺼내 차곡차곡 집어넣게 되어, DB 연결 수도 줄어들고 아무리 트래픽이 몰려도 데이터가 버려지지 않습니다. 다른 옵션인 A는 임시방편일 뿐이며 비용이 많이 듭니다. B는 Aurora가 아닌 일반 RDS의 경우 쓰기 분산이 어렵고, D의 SNS는 '방송' 서비스라 데이터를 차례대로 줄 세워 DB에 넣는 버퍼 역할로는 적합하지 않습니다. 💡 이 문제의 핵심 용어 SQS (Simple Queue Service): 할 일을 잊지 않게 차곡차곡 쌓아두는 클라우드의 안전한 작업 바구니 Lambda: 서버 관리 없이 코드만 실행하면 되는 서버리스 컴퓨팅 서비스 Tightly Coupled (강한 결합): 부품들이 너무 꽉 묶여 있어 하나가 고장 나면 전체가 멈추는 위태로운 상태
Q229 직접 EC2에 MySQL을 깔아서 고군분투 중인 팀이 있습니다. 사람이 일일이 복제본을 만들고 서버를 늘렸다 줄였다 하느라 운영 오버헤드가 너무 큽니다. 최소한의 노력으로 성능과 확장성, 그리고 '자동 조절' 기능까지 한 번에 챙기는 마법의 솔루션은? Aurora MySQL Serverless로 데이터베이스를 마이그레이션합니다. Aurora PostgreSQL Serverless로 이사하여 새 출발을 합니다. 현재 EC2 사양을 세상에서 제일 큰 타입으로 바꿔서 단일 DB로 운영합니다. DB 서버 전용 오토 스케일링 그룹을 만들어서 서버 대수를 자동 조절합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 기존 MySQL 환경을 유지하면서 운영의 고통에서 벗어나는 최선의 선택은 Aurora Serverless입니다. 이 서비스를 이용하면 더 이상 '서버 사양을 얼마로 할까' 고민할 필요가 없습니다. 손님이 많으면 알아서 고성능으로 변신하고, 손님이 없으면 비용을 아끼기 위해 스스로 작아집니다. 복제와 고가용성 관리도 AWS가 알아서 다 해주니 운영자는 이제 발 뻗고 잘 수 있습니다. 다른 옵션인 B는 데이터베이스 종류가 바뀌어 코드 수정이 필요할 수 있고, C는 확장의 한계가 명확하며 돈 낭비가 심합니다. D는 DB 서버의 상태값 전이(복제 동기화 등)를 오토 스케일링으로만 해결하려다 데이터가 꼬일 수 있는 위험한 방식입니다. 💡 이 문제의 핵심 용어 Aurora Serverless: 사용량에 따라 알아서 성능(용량)이 늘어났다 줄어드는 똑똑한 가변형 데이터베이스 Migration (마이그레이션): 살던 집(온프레미스/EC2)을 떠나 새집(관리형 서비스)으로 모든 짐을 옮기는 이사 과정 MySQL: 가장 대중적으로 널리 쓰이는 오픈소스 관계형 데이터베이스
Q230 현재 사용하는 두 개의 NAT 인스턴스가 트래픽을 감당하지 못할까 봐 걱정입니다. 가용성이 높고 고장 나도 끄떡없으며(내결함성), 부하에 따라 무한히 늘어나는 '완벽한 인터넷 통로'를 만들려면 어떻게 해야 할까요? 두 인스턴스를 지우고 같은 가용 영역(AZ)에 NAT 게이트웨이 두 개를 몰아넣습니다. NAT 인스턴스 전용 Network Load Balancer와 오토 스케일링을 조합해 구축합니다. 인스턴스를 과감히 버리고, 서로 다른 가용 영역(AZ)에 NAT 게이트웨이를 하나씩 설치합니다. NAT 인스턴스를 저렴한 스팟 인스턴스로 바꾸고 로드 밸런서를 연결합니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 예전 방식인 NAT 인스턴스는 우리가 서버를 직접 관리해야 해서 번거롭고 확장도 어렵습니다. 반면 'NAT 게이트웨이'는 AWS가 관리해주는 바구니 같은 서비스로, 초당 최대 45Gbps까지 알아서 확장됩니다. 특히 서로 다른 가용 영역(AZ)에 하나씩 두어야 한쪽 데이터 센터에 불이 나도 다른 쪽을 통해 인터넷 연결이 유지되는 진정한 고가용성을 확보할 수 있습니다. 다른 옵션인 A는 한 AZ가 무너지면 끝장이라 위험하고, B와 D는 여전히 우리가 관리해야 할 '서버(인스턴스)'가 남아 있어 운영 부담과 관리 포인트가 사라지지 않습니다. 💡 이 문제의 핵심 용어 NAT Gateway: 프라이빗 서버들이 인터넷으로 나갈 때 쓰는 일종의 '일방통행 보안 관문' High Availability (고가용성): 장애가 나도 중단 없이 서비스가 끈기 있게 계속되는 성질 Fault Tolerance (내결함성): 시스템의 일부가 고장 나도 전체 기능은 정상적으로 작동하는 능력
Q231 VPC A에 있는 서버가 VPC B에 있는 데이터베이스에 접근해야 합니다. 두 VPC는 같은 계정 안에 있습니다. 공용 인터넷을 거치지 않고 가장 안전하고 빠르게 프라이빗하게 연결하는 방법은? 데이터베이스 보안 그룹에서 서버의 퍼블릭 IP를 허용해줍니다. VPC A와 VPC B 사이에 'VPC 피어링' 통로를 뚫습니다. 데이터베이스를 외부 공개(Publicly Accessible)로 바꾸고 직접 접속합니다. 탄력적 IP를 가진 프록시 서버를 중간에 세워서 데이터를 전달합니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. 두 네트워크(VPC)를 하나처럼 묶어주는 가장 표준적인 방법은 VPC 피어링입니다. 이를 설정하면 내부망(Private IP)으로만 트래픽이 흐르게 되어 보안상 매우 안전하며, 성능도 마치 같은 네트워크에 있는 것처럼 빠릅니다. 인터넷 게이트웨이를 통과할 필요조차 없으므로 해킹 위험도 현저히 낮아집니다. 다른 옵션인 A와 C는 귀중한 데이터가 담긴 DB를 공용 인터넷에 노출해야 하므로 보안팀에서 당장 달려올 위험한 설계입니다. D는 관리가 복잡할 뿐만 아니라 성능 저하와 장애 포인트만 늘리는 비효율적인 방식입니다. 💡 이 문제의 핵심 용어 VPC Peering: 서로 다른 VPC를 내부 사설망으로 직접 연결해주는 무선 다리 같은 기능 Private IP: 공용 인터넷에서는 보이지 않는 우리만의 내부 집 주소 VPC (Virtual Private Cloud): AWS 클라우드 내에 나만의 전용 가상 네트워크 공간
Q232 여러 고객용 데모 환경을 VPC별로 나누어 운영 중입니다. 보안상 중요한 규칙 하나가 있는데, 누군가 관리자 권한(RDP나 SSH)으로 서버에 접속하면 즉시 운영팀에 비상벨이 울려야 합니다. 가장 정확한 감시 방법은? CloudWatch Application Insights를 켜고 접속 로그가 뜨면 보고하게 합니다. 모든 서버에 SSM 관리 정책을 달아주고 알아서 보고하기를 기다립니다. VPC 흐름 로그(Flow Logs)를 CloudWatch에 쌓고, 특정 포트(22, 3389) 접속을 감지하는 메트릭 필터와 경보를 만듭니다. EventBridge로 인스턴스 상태가 '실행 중'으로 바뀔 때마다 SNS 알림을 쏩니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 네트워크에 누가 들어오고 나가는지를 가장 정확하게 기록하는 장부는 'VPC 흐름 로그'입니다. 모든 통신 기록이 남기 때문에, 여기서 RDP(3389)나 SSH(22) 포트로 트래픽이 발생하는 순간을 포착하는 메트릭 필터를 걸어두면 됩니다. 이 필터가 반응할 때 SNS를 통해 알림을 쏘게 설정하면, 관리자가 서버에 발을 들이는 즉시 운영팀에 문자가 가게 됩니다. 다른 옵션인 A와 B는 앱 내부나 인스턴스 관리에 집중되어 있어 '네트워크 접근' 자체를 실시간으로 낚아채기에 부족합니다. D는 서버가 켜지는 것만 알 뿐, 실제로 누군가 원격 접속을 시도했는지는 알 수 없습니다. 💡 이 문제의 핵심 용어 VPC Flow Logs: VPC를 오가는 모든 트래픽의 발자취를 낱낱이 기록하는 네트워크 블랙박스 Metric Filter (메트릭 필터): 방대한 로그 속에서 우리가 원하는 특정 단어나 숫자만 골라내서 그래프로 그려주는 도구 RDP/SSH: 서버에 직접 들어가서 관리하기 위해 쓰는 원격 접속 통로
Q233 AWS 계정을 새로 만들었습니다. 계정의 주인인 '루트(Root) 사용자'는 전지전능한 권한을 가졌기에 해킹당하면 계정 전체가 날아갑니다. 보안을 위해 가장 먼저 해야 할 두 가지 조치는? (2개 선택) 절대 뚫리지 않을 만큼 강력한 암호를 설정합니다. MFA(다단계 인증)를 활성화하여 폰 인증까지 받아야 로그인이 되게 합니다. 루트 사용자의 액세스 키를 만들어서 안전하게 S3에 저장해둡니다. 루트 사용자를 관리자 그룹에 추가하여 권한을 더 튼튼하게 보강합니다. 루트 사용자에게만 적용되는 특별한 보안 정책(Inline Policy)을 작성합니다. 정답 확인 및 해설 📖 해설 정답은 A와 B입니다. 루트 사용자는 모든 것을 할 수 있는 왕과 같습니다. 보안의 제1 원칙은 이 '왕의 권한'을 최대한 사용하지 않는 것입니다. 먼저 추측 불가능한 강력한 비번을 걸고(A), OTP 기기나 폰 앱을 통한 MFA(B)를 걸어서 비번이 유출되더라도 로그인을 막아야 합니다. 그 후엔 별도의 IAM 사용자를 만들어 일상 업무를 보고 루트 계정은 금고에 깊숙이 넣어둬야 합니다. 다른 옵션인 C는 루트 계정의 액세스 키를 만드는 것 자체가 보안상 금기 사항입니다. D와 E는 이미 모든 권한을 가진 루트 사용자에게는 아무런 의미가 없는 작업이며, 오히려 관리 포인트만 늘리는 셈입니다. 💡 이 문제의 핵심 용어 Root User: AWS 계정 생성 시 만들어지는 모든 권한을 가진 단 하나의 조상 계정 MFA (Multi-Factor Authentication): 비밀번호 외에 추가적인 인증 수단(폰, 보안키 등)을 하나 더 요구하는 이중 보안 장치 IAM User: 루트 대신 실제 업무를 처리하기 위해 권한을 제한해서 만든 하위 계정
Q234 새로운 앱을 개발하는데 경영진이 '자나 깨나 보안'을 강조합니다. 데이터가 하드디스크에 있을 때(유휴)나 전선 타고 이동할 때(전송)나 모두 암호화되어야 한다네요. 가장 편하게 이 요건을 충족하는 방법은? ALB에 KMS 키를 직접 심어버리고 인증서 관리 도구(ACM)로 하드디스크를 암호화합니다. 모든 관리는 루트 계정으로만 하고 콘솔에서 '전체 암호화' 체크박스 하나를 찾아서 누릅니다. KMS 키를 써서 EBS와 Aurora 저장소를 암호화하고, ALB에는 ACM에서 발급받은 인증서를 답니다. 윈도우 보안 도구인 BitLocker를 서버마다 깔고 ALB 앞에 타사 유선 암호화 장비를 둡니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. AWS에서 '유휴 데이터' 암호화의 표준은 KMS입니다. EBS 하드디스크나 Aurora DB를 만들 때 KMS 키를 선택만 하면 저장되는 순간 암호화가 됩니다. '전송 중 데이터'는 HTTPS 통신이 필수인데, 이때 ACM(인증서 관리자)에서 무료로 발급받은 인증서를 ALB 로드 밸런서에 붙여주기만 하면 손님과 서버 사이의 모든 대화가 안전하게 암호화됩니다. 다른 옵션인 A는 도구의 용도를 거꾸로 말하고 있어 틀렸고, B는 그런 마법 같은 단 하나의 체크박스는 존재하지 않습니다. D는 클라우드 시대에 어울리지 않는 엄청난 운영 노가다와 추가 비용을 유발합니다. 💡 이 문제의 핵심 용어 Encryption at Rest (유휴 암호화): 데이터가 저장 장치에 가만히 누워있을 때 훔쳐 가도 못 읽게 만드는 기술 Encryption in Transit (전송 암호화): 데이터가 인터넷 공간을 이동할 때 가로채도 내용을 알 수 없게 만드는 기술 ACM (AWS Certificate Manager): 웹사이트의 자물쇠(SSL/TLS 인증서)를 무료로 발급하고 알아서 갱신해주는 관리 서비스
Q235 온프레미스의 오라클 DB를 AWS Aurora로 이사하려 합니다. 앱이 너무 많아서 한 달에 하나씩 천천히 옮겨야 하는데, 그동안 두 DB의 데이터가 거울처럼 똑같이 유지되어야 합니다. 어떤 장비들을 동원해야 할까요? DataSync로 짐을 옮기고 DMS의 CDC 기능을 써서 실시간 복제를 합니다. DataSync로 전체 부하(Full Load)를 걸고 DMS로 테이블 매핑만 대충 합니다. Schema Conversion Tool(SCT)로 설계도를 바꾸고, 메모리 최적화 등급의 DMS로 전체 데이터 전송과 실시간 복제(CDC)를 동시에 수행합니다. SCT를 쓰고 컴퓨팅 최적화 DMS를 써서 가장 큰 파일 몇 개만 우선적으로 옮깁니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 오라클과 PostgreSQL은 서로 말이 안 통하는 외국인과 같습니다. 먼저 SCT(설계도 변환 도구)를 써서 DB 구조를 번역해야 합니다. 그 후 데이터를 옮길 때는 DMS(데이터베이스 마이그레이션 서비스)를 쓰는데, '전체 로드'로 기존 데이터를 넘기고 'CDC(변경 데이터 캡처)' 기능으로 새로 들어오는 수정사항을 실시간으로 따라잡게 만들어야 합니다. 이때 성능 저하 없이 대량의 데이터를 소화하려면 메모리가 넉넉한 DMS 서버를 쓰는 것이 고수의 선택입니다. 다른 옵션인 A와 B의 DataSync는 단순 파일 복사용이지 DB 내부의 복잡한 트랜잭션을 따라잡기엔 역부족입니다. D는 일부 데이터만 옮기기 때문에 전체 동기화라는 목표를 달성할 수 없습니다. 💡 이 문제의 핵심 용어 AWS SCT (Schema Conversion Tool): 서로 다른 종류의 데이터베이스 설계도를 호환되는 언어로 바꿔주는 번역기 AWS DMS: 데이터베이스 작동 중에 중단 없이 데이터를 다른 곳으로 이사시켜 주는 서비스 CDC (Change Data Capture): 데이터베이스에서 새로 수정되거나 추가된 내용만 쏙 골라내서 실시간으로 전달하는 기술
Q236 웹 서버, 앱 서버, DB 서버가 각각 하나인 구식 3계층 서비스가 있습니다. 앱 코드는 거의 안 고치면서도 사용자가 늘어나면 알아서 사양을 높이고 고장 나도 튼튼한 '신식 시스템'으로 개조하고 싶습니다. 최선의 방안은? S3, Lambda, DynamoDB로 싹 다 갈아엎는 서버리스 혁명을 선택합니다. Elastic Beanstalk에 다 맡기고, DB는 RDS 읽기 전용 복제본 수십 개를 만듭니다. S3에 화면을 올리고 EC2 무리를 오토 스케일링으로 묶은 뒤 메모리 빵빵한 DB로 이사합니다. Elastic Beanstalk로 전체 서비스를 감싸고, DB는 RDS 다중 AZ로, 이미지는 S3에 따로 분리해 저장합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. '최소한의 코드 변경'으로 고가용성을 얻으려면 Elastic Beanstalk가 최고입니다. 서버 운영(OS 업데이트, 로드 밸런싱 등)을 대신 해주기 때문입니다. 여기에 데이터베이스는 RDS의 '다중 AZ' 기능을 켜서 한쪽 센터가 무너져도 1~2분 안에 복구되게 하고, 용량이 크고 변하지 않는 이미지는 무제한 저장소인 S3에 따로 보관하는 것이 클라우드 아키텍처의 정석입니다. 다른 옵션인 A는 앱 코드를 완전히 새로 짜야 해서 부담이 크고, B는 DB의 읽기 성능은 좋지만 쓰기 장애 시 대응이 늦습니다. C는 여전히 운영자가 서버 인프라를 직접 챙겨야 할 부분이 많아 효율이 떨어집니다. 💡 이 문제의 핵심 용어 3-Tier Architecture: 프레젠테이션(화면), 애플리케이션(로직), 데이터(DB)를 세 계층으로 나눈 표준 설계 AWS Elastic Beanstalk: 코드만 올리면 서버 설정부터 배포까지 알아서 다 해주는 관리용 보자기 같은 서비스 Multi-AZ Deployment: 데이터베이스를 두 개의 데이터 센터에 상시 복제해두어 장애에 대비하는 기술
Q237 서로 다른 AWS 계정을 쓰는 두 친구의 VPC가 있습니다. 한쪽 계정의 서버가 다른 쪽 계정의 서버 파일에 접근해야 하는데, 절대 끊기지 않아야 하고 속도도 빨라야 한답니다. 보안까지 챙기는 가장 깔끔한 연결법은? VPC 피어링(Peering) 연결을 맺고 내부망으로 직접 대화하게 합니다. 맞은편 서버를 위해 VPC 게이트웨이 엔드포인트를 하나 뚫어줍니다. 가상 전용망(VPN) 게이트웨이를 양쪽에 달고 암호화 터널을 만듭니다. 전용선(Direct Connect) 장비를 임대해서 두 계정 사이를 선으로 연결합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. VPC 피어링은 계정이 달라도 같은 지역(리전)에 있다면 클릭 몇 번으로 둘을 하나처럼 묶어줍니다. 별도의 장비(VPN 등)를 거치지 않고 AWS의 내부 고속 전용 통로를 타기 때문에 성능 저하나 대역폭 제한 걱정이 거의 없습니다. 단일 장애 지점(Single Point of Failure)도 없으니 '안 끊기고 빠른' 이번 요구 사항에 딱 맞는 정답입니다. 다른 옵션인 B의 엔드포인트는 S3나 DynamoDB 같은 특정 서비스를 위한 것이지 서버 대 서버 연결용이 아닙니다. C는 VPN 장비 자체의 성능 한계와 설정의 복잡함이 있고, D는 본래 온프레미스와 연결할 때 쓰는 비싼 기술이라 계정 간 연결에는 과한 선택입니다. 💡 이 문제의 핵심 용어 VPC Peering: 서로 다른 VPC를 내부 사설망으로 직접 연결해주는 무선 다리 같은 기능 Single Point of Failure (단일 장애 지점): 그 부품 하나만 고장 나면 전체 시스템이 멈춰버리는 위태로운 급소 Bandwidth (대역폭): 통신 통로의 넓이, 즉 한 번에 보낼 수 있는 데이터의 양
Q238 여러 엔지니어에게 공부용으로 계정을 하나씩 줬는데, 누가 실수로 비싼 사양의 서버를 켜서 요금 폭탄이 나올까 봐 걱정입니다. 특정 금액을 넘는 순간 즉시 알림을 받고 싶은데, 가장 가성비 좋고 설정이 편한 방법은? Cost Explorer에서 매일 수동으로 보고서를 뽑아 이메일로 쏩니다. 매달 말에 비용 보고서가 나오도록 설정하고 비싸지면 알림을 설정합니다. AWS Budgets(예산)를 써서 'EC2 사용량'이 목표치를 넘으면 SNS로 알림을 쏘게 합니다. 비용 명세 로그를 Athena로 일일이 쿼리해서 비싸면 알람 주는 코드를 짭니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 돈 문제를 가장 확실히 감시하는 수문장은 AWS Budgets입니다. 단순히 전체 비용뿐만 아니라 'EC2만 콕 집어서' 혹은 '특정 태그가 붙은 것만' 예산을 정해둘 수 있습니다. 예상 금액이나 실제 사용액이 설정한 임계값(예: 80%)을 넘으면 즉시 SNS로 문자를 주도록 설정할 수 있어, 요금 폭탄이 터지기 전에 미리 대처할 수 있는 최고의 도구입니다. 다른 옵션인 A와 B는 이미 돈이 다 나간 뒤에 확인하는 '소 잃고 외양간 고치기' 식이고, D는 고작 예산 알림 하나 받으려고 너무 큰 개발 공수를 들이는 배보다 배꼽이 더 큰 방식입니다. 💡 이 문제의 핵심 용어 AWS Budgets: 내가 정한 예산 한도를 넘을 것 같으면 미리 경고 신호를 보내주는 재무 관리 비서 Threshold (임계값): 알림이 울려야 하는 기준점(예: 예산의 80% 사용 시) Cost Explorer: 우리 회사가 돈을 어디에 썼는지 예쁘게 그래프로 그려서 시각화해주는 도구
Q239 Go 언어로 짠 람다 함수 하나로 마이크로서비스를 만들려고 합니다. 외부에 HTTPS 주소를 공개해야 하고, 보안상 반드시 IAM 인증을 거친 사람만 이 서비스를 쓰게 하고 싶습니다. 운영 오버헤드를 줄이는 가장 스마트한 배포 방식은? API Gateway REST API를 만들고, 람다를 연결한 뒤 IAM 인증을 켭니다. 람다 전용 URL(Function URL)을 만들고 인증 타입을 AWS_IAM으로 정합니다. CloudFront 뒤에 Lambda@Edge를 배치하고 인증 코드를 직접 짜넣습니다. CloudFront Functions에 앱 로직을 통째로 넣고 실행시킵니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 단순히 주소만 필요한 게 아니라 '인증과 관리'가 필요할 때는 API Gateway가 왕입니다. REST API 방식을 선택하면 IAM 인증 기능을 클릭 한 번으로 활성화할 수 있을 뿐만 아니라, 나중에 요청이 폭주해도 알아서 막아주는(Throttling) 기능이나 주소 관리 기능까지 한꺼번에 얻을 수 있습니다. 운영자가 일일이 코딩하지 않아도 보안 요건을 완벽히 충족합니다. 다른 옵션인 B는 정말 단순한 호출용이지 기업용 서비스로 관리하기엔 기능이 부족하고, C와 D는 '에지(Edge) 위치'라는 특수한 환경에서 돌아가는 서비스라 일반적인 마이크로서비스 배포용으로는 복잡성만 키울 뿐입니다. 💡 이 문제의 핵심 용어 API Gateway: 앱의 모든 진입로(API)를 한곳에서 만들고 관리하며 보안을 지키는 문지기 서비스 Microservice (마이크로서비스): 거대한 앱을 잘게 쪼개서 각각 독립적으로 개발하고 운영하는 현대적인 설계 방식 IAM Authentication: ID/PW가 아닌 AWS 계정의 고유 권한(Access Key 등)으로 신분을 확인하는 절차
Q240 본사 사람들이 AWS의 데이터 창고(Redshift)를 자꾸 뒤집니다. 한 번 쿼리를 날릴 때마다 50MB씩 데이터를 가져가는데, 이 통신비(송신 비용)를 한 푼이라도 아끼려면 어떤 배치가 좋을까요? (참고: 전용선인 Direct Connect는 이미 깔려 있습니다.) 지금처럼 본사에서 시각화 도구를 돌리고 그냥 인터넷으로 직접 쏩니다. 시각화 서버를 AWS 리전 안에 두고, 본사 사람들은 브라우저로 접속하게 합니다. 본사 장비는 그대로 쓰고, 통신만 전용선(Direct Connect)을 태웁니다. 시각화 서버를 AWS 리전 안에 두되, 본사와는 전용선(Direct Connect)으로만 대화하게 합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. AWS 요금 체계에서 가장 비싼 것 중 하나가 'AWS 밖으로 나가는 데이터(Egress)' 비용입니다. 50MB씩 수천 번 나가는 걸 막으려면, 결과 값을 보여주는 '시각화 서버'를 데이터 창고(Redshift) 바로 옆인 AWS 안에 두어야 합니다. 그러면 50MB는 내부망(무료 또는 저렴)으로 이동하고, 본사 사람들에게는 가공된 가벼운 화면 정보(500KB)만 전용선을 타고 전송되므로 전체 송신 비용이 획기적으로 줄어듭니다. 다른 옵션인 A, B, C는 여전히 50MB라는 무거운 데이터를 리전 밖으로 내보내야 하므로, 인터넷 비용이든 전용선 비용이든 결국 비싼 요금 청구서를 받게 됩니다. 💡 이 문제의 핵심 용어 Egress (송신) 비용: 데이터가 AWS 클라우드 바깥 세상(인터넷이나 본사)으로 나갈 때 부과되는 통행료 Data Warehouse (데이터 웨어하우스): 기업의 의사 결정을 위해 방대한 데이터를 모아두고 분석하는 대형 창고 서버 Low Latency (저지연): 데이터 요청과 응답 사이의 시간이 아주 짧아 반응이 빠릿빠릿한 상태
Q241 학생들의 성적 데이터가 담긴 PostgreSQL DB를 AWS로 이사합니다. 전 세계 어디서든 이 데이터를 실시간으로 볼 수 있어야 하고, 어느 한 지역이 마비되어도 서비스가 계속되어야 합니다. 가장 운영이 편한 방법은? EC2 서버를 여러 지역에 띄우고 직접 PostgreSQL 클러스터를 구성해서 관리합니다. RDS PostgreSQL을 쓰고 다중 AZ(Multi-AZ) 옵션만 켭니다. RDS PostgreSQL로 이사한 뒤, 다른 리전에 '읽기 전용 복제본(Read Replica)'을 만듭니다. 한 지역에 DB를 가동하고, 매시간 찍은 스냅샷 파일을 다른 리전으로 계속 복사합니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. '여러 리전에서 온라인 사용'이라는 요건을 충족하려면 지역 간 복제가 필수입니다. RDS의 읽기 전용 복제본 기능을 쓰면, 메인 지역(한국)에 데이터를 쓰는 즉시 다른 지역(미국, 유럽 등)의 복제 DB로 내용이 전달됩니다. 그쪽 지역 사람들은 자기 근처의 DB에서 데이터를 빠르게 읽을 수 있고, 한국 지역에 큰 장애가 나도 복제본을 메인으로 승격시켜 서비스를 이어갈 수 있습니다. 다른 옵션인 A는 서버 관리가 너무 힘들고, B의 다중 AZ는 한 지역 안에서의 장애만 막아줄 뿐 리전 전체 장애에는 속수무책입니다. D는 실시간이 아닌 '과거 데이터'만 복구하는 방식이라 항상 온라인 사용이라는 요건에 맞지 않습니다. 💡 이 문제의 핵심 용어 Read Replica (읽기 전용 복제본): 메인 DB의 내용을 그대로 복사해둔 서브 DB. 조회 성능을 분산하고 재해 복구용으로 사용 Cross-Region (교차 리전): 지리적으로 멀리 떨어진 두 개 이상의 지역(예: 서울과 버지니아)을 아우르는 규모 High Availability (고가용성): 장애가 나도 중단 없이 서비스가 끈기 있게 계속되는 성질
Q242 서버 7대를 운영 중인데, 손님이 주소창에 우리 홈페이지를 쳤을 때 모든 정상적인 서버 아이피를 무작위로 하나씩 다 알려주고 싶습니다. Route 53에서 어떤 정책을 써야 할까요? 단순 라우팅 정책 (Simple routing policy) 레이턴시(지연 시간) 라우팅 정책 (Latency routing policy) 다중값 응답 라우팅 정책 (Multivalue routing policy) 지리적 위치 라우팅 정책 (Geolocation routing policy) 정답 확인 및 해설 📖 해설 정답은 C입니다. 다중값 응답 정책은 로드 밸런서(ALB) 없이도 여러 서버에 부하를 나누는 가장 원시적이면서도 강력한 방법입니다. Route 53에 7대 서버 아이피를 다 등록해두면, 손님의 쿼리에 대해 정상인 녀석들의 아이피를 최대 8개까지 무작위로 골라 응답해줍니다. 장애가 난 서버는 상태 확인(Health Check)을 통해 알아서 명단에서 제외하니 안심하고 쓸 수 있습니다. 다른 옵션인 A는 고정된 결과만 주고, B는 가장 빠른 서버만 추천하며, D는 접속자의 국가에 따라 다른 서버를 알려주는 정책이라 '모든 정상 아이피 반환'이라는 목표와는 방향이 다릅니다. 💡 이 문제의 핵심 용어 Multivalue Answer Routing: 하나의 도메인 주소에 여러 서버 아이피를 넣어두고 무작위로 응답해주는 부하 분산 기술 Health Check (상태 확인): 서버가 살아있는지 주기적으로 찔러보고 죽었으면 명단에서 빼버리는 감시 기능 DNS (Domain Name System): 인터넷 주소(google.com)를 컴퓨터가 읽는 아이피(1.2.3.4)로 바꿔주는 주소록
Q243 의학 연구소에서 전국 진료소에 대용량 파일을 공유하려 합니다. 진료소의 구식 파일 앱은 그대로 쓰면서도, S3에 저장된 최신 데이터를 로딩 지연 없이 바로 '내 하드디스크'처럼 읽게 해주는 가장 좋은 방법은? 각 진료소 컴퓨터에 AWS Storage Gateway의 '파일 게이트웨이'를 VM으로 설치합니다. DataSync 서비스를 써서 매번 S3 파일을 진료소 로컬 컴퓨터로 복사해줍니다. 진료소마다 '볼륨 게이트웨이'를 깔고 S3를 통째로 포맷해서 하드로 인식시킵니다. 클라우드용 공유 하드인 EFS를 전국의 모든 진료소 서버에 강제로 연결(Mount)합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 파일 게이트웨이는 '구식 파일 서버(NFS/SMB)'와 '최첨단 S3 창고' 사이를 이어주는 가교입니다. 진료소 직원은 자기네 익숙한 폴더에 파일을 넣고 빼는 것처럼 쓰지만, 실제 데이터는 S3에 보관됩니다. 특히 자주 쓰는 파일은 진료소 내부 장비인 VM(파일 게이트웨이)에 '캐시'로 저장해두므로 인터넷 속도와 상관없이 빛의 속도로 읽을 수 있습니다. 다른 옵션인 B는 실시간성이 떨어지고 관리가 복잡하며, C는 '파일' 단위 접근이 아닌 '블록' 단위라 이번 용도에 맞지 않습니다. D의 EFS는 전용선 없는 상태에서 전국 규모로 연결하기엔 성능 이슈와 설정 난이도가 너무 높습니다. 💡 이 문제의 핵심 용어 AWS File Gateway: S3를 마치 내 컴퓨터의 외장 하드나 공유 폴더처럼 쓰게 해주는 연동 장치 Virtual Machine (VM): 컴퓨터 안에 가상으로 만든 또 다른 소형 컴퓨터 Caching (캐싱): 자주 쓰는 데이터를 가까운 곳에 임시로 저장해두어 로딩 속도를 획기적으로 높이는 기술
Q244 단 한 대의 EC2 서버에서 웹과 DB를 다 돌리고 있는 위험한 서비스가 있습니다. '확장성'과 '고가용성'이라는 두 마리 토끼를 잡기 위해 설계도를 다시 그린다면 무엇이 포함되어야 할까요? RDS를 쓰고 똑같은 서버를 수동으로 한 대 더 띄워서 로드 밸런서에 묶습니다. Aurora로 이사하고 옆 동네에 읽기 복제본을 둔 다음, 수동으로 새 서버를 더 만듭니다. DB는 다른 지역 복제본이 있는 Aurora로 옮기고, 웹 서버는 두 지역에 걸쳐 오토 스케일링 그룹으로 묶어 ALB 뒤에 배치합니다. DB 전용 EC2를 하나 더 만들고 S3에 백업하며, 웹 서버는 한 지역 안에서만 오토 스케일링을 돌립니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 진정한 고가용성은 '자동화'와 '분산'에서 나옵니다. 데이터베이스는 죽지 않는 Aurora를 쓰고, 웹 서버는 이미지를 떠서(AMI) 오토 스케일링 그룹에 담아야 합니다. 여기에 로드 밸런서(ALB)가 두 지역(AZ)에 손님을 나눠주게 설정하면, 서버 한 대가 죽거나 심지어 데이터 센터 하나가 통째로 정전이 되어도 서비스는 중단 없이 계속됩니다. 다른 옵션인 A와 B는 '수동으로 서버를 띄운다'는 점에서 확장성이 부족하고 사람의 실수가 개입될 여지가 큽니다. D는 DB를 여전히 우리가 관리해야 할 '서버' 형태로 두었기에 관리 부담과 장애 위험을 완전히 떨쳐내지 못했습니다. 💡 이 문제의 핵심 용어 Auto Scaling Group: 상황에 따라 서버 대수를 알아서 넣고 빼주는 자동 조절 군단 ALB (Application Load Balancer): 교통정찰관처럼 손님들을 가장 한가한 서버로 친절히 안내해주는 장치 AMI (Amazon Machine Image): EC2 서버를 그대로 복사해둔 소프트웨어 붕어빵 틀
Q245 개발 환경과 운영 환경을 따로 만들었는데, 자꾸 비용이 걱정입니다. 개발 환경은 손님이 거의 없으니 가성비를 극한으로 끌어올리고 싶은데, 가장 간단한 조치는? 개발 서버는 딱 '한 대'만 쓰도록 대상 그룹 설정을 바꿉니다. 로드 밸런서의 알고리즘을 '가장 일 안 하는 서버 찾기'로 바꿉니다. 개발과 운영 서버 모두 사양(CPU/메모리)을 한두 단계씩 낮춥니다. 오토 스케일링의 '최댓값'만 살짝 낮춰놓고 요행을 바랍니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 개발 환경은 내부 직원들만 테스트용으로 쓰기 때문에 굳이 여러 대의 서버를 띄워 고가용성을 유지할 필요가 없습니다. 로드 밸런서 뒤에서 일하는 서버 숫자를 1대로 줄여버리는 것이 가장 직접적이고 확실한 돈 절약 방법입니다. 서버 대수 자체가 줄어드니 월세(EC2 비용)가 반토막 이상으로 줄어듭니다. 다른 옵션인 B는 일하는 방식만 바꾸는 거지 서버 월세는 똑같이 나가고, C는 운영 환경의 성능까지 낮춰버려 실제 서비스에 지장을 줍니다. D는 손님이 몰릴 때의 상한선만 정하는 거지 평소 나가는 기본 요금을 줄여주지는 못합니다. 💡 이 문제의 핵심 용어 Target Group (대상 그룹): 로드 밸런서가 트래픽을 전달할 '서버들의 집합' Cost-Effectiveness (비용 효율성): 최소한의 비용으로 최대한의 효과를 뽑아내는 가성비 전략 Development Environment: 사용자가 아닌 개발자들이 기능을 만들고 테스트하기 위해 만든 임시 실험실
Q246 프라이빗 서브넷에 서버를 숨겨두고 ALB로 연결했는데, 손님들이 홈페이지에 들어오지 못한다고 합니다. 아키텍처를 뒤져보니 ALB 자체도 프라이빗 서브넷에 갇혀 있네요. 이 '고립된 섬'을 구출하려면? ALB를 갖다 버리고 더 비싼 Network Load Balancer를 설치합니다. 보안이고 뭐고 서버를 전부 인터넷 활짝 열린 퍼블릭 서브넷으로 끌어냅니다. 서버가 직접 인터넷 게이트웨이와 통신하게 경로를 억지로 뚫어줍니다. 데이터 센터마다 '퍼블릭 서브넷'을 새로 만들고, ALB를 그곳으로 옮겨서 인터넷과 마주보게 합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. 인터넷 로드 밸런서(ALB)는 반드시 '퍼블릭 서브넷'에 발을 걸치고 있어야 외부 손님의 요청을 받을 수 있습니다. 하지만 실제 데이터를 다루는 서버는 '프라이빗 서브넷'에 숨겨두는 것이 보안의 정석입니다. 따라서 ALB만 햇볕이 드는 퍼블릭 서브넷으로 옮기고, 거기서 프라이빗 서브넷에 있는 서버로 트래픽을 쏙 쏴주도록 라우팅을 잡으면 보안과 소통이라는 두 마리 토끼를 다 잡게 됩니다. 다른 옵션인 A는 로드 밸런서 종류를 바꿔도 위치 문제가 해결되지 않으면 똑같고, B는 보안을 포기하는 행위입니다. C는 프라이빗 서버가 직접 인터넷에 노출되어 해킹의 표적이 되기 쉬운 위험한 구성입니다. 💡 이 문제의 핵심 용어 Public Subnet: 인터넷과 직접 대화할 수 있는 '열린 마당' 같은 네트워크 구역 Private Subnet: 인터넷에서 보이지 않는 '안전한 안방' 같은 보이지 않는 구역 Internet Gateway: VPC라는 집 내부와 바깥 인터넷 세상을 이어주는 대문
Q247 MySQL DB가 읽기 작업이 너무 많아져서 버벅거립니다. '읽기 전용 복제본'을 하나 붙여서 짐을 덜어주려는데, 그전에 반드시 체크해야 할 두 가지 필수 조건은? (2개 선택) DB 엔진 내부의 바이너리 로그(binlog) 복제를 켭니다. 장애 조치 때 누가 먼저 대장이 될지 우선순위를 미리 정해둡니다. 현재 돌아가는 아주 긴 작업(트랜잭션)이 끝날 때까지 잠시 기다립니다. 글로벌 테이블을 만들고 어느 지역에 복사할지 지도에서 고릅니다. 백업 보존 기간을 '0'초과로 설정해서 자동 백업 기능을 활성화합니다. 정답 확인 및 해설 📖 해설 정답은 C와 E입니다. 복제본을 만드는 원리는 '현재 상태의 사진(스냅샷)'을 찍어 옆동네에 똑같은 DB를 굽는 것입니다. 그러려면 일단 AWS가 자동으로 사진을 찍을 수 있게 '자동 백업'이 켜져 있어야 합니다(E). 또한 사진 찍는 도중에 데이터가 계속 바뀌면 사진이 흔들릴 수 있으니, 진행 중인 무거운 작업들은 다 끝난 뒤에 시작하는 것이 안전합니다(C). 다른 옵션인 A는 RDS가 내부적으로 알아서 하는 영역이며, B는 고가용성(Multi-AZ) 승격 문제지 단순히 읽기용 복제본을 만드는 조건은 아닙니다. D의 글로벌 테이블은 DynamoDB 전용 용어라 MySQL과는 어울리지 않습니다. 💡 이 문제의 핵심 용어 Read Replica (읽기 전용 복제본): 메인 DB의 내용을 그대로 복사해둔 서브 DB. 조회 성능을 분산하고 재해 복구용으로 사용 Backup Retention: 백업 파일을 얼마나 오랜 기간(며칠) 보관할지 정하는 설정 Transaction (트랜잭션): 관련된 여러 데이터 작업을 하나의 덩어리로 묶어서 처리하는 단위
Q248 S3에 파일이 올라올 때마다 서버가 처리하는데, 손님이 몰리니 서버 CPU가 100%를 찍으며 항복 선언을 합니다. 일부 요청은 처리조차 안 되고 누락된다는데, 성능도 올리고 확장도 자동으로 되게 하려면? 서버 사본을 여러 대 만들고 로드 밸런서(ALB) 뒤에 나란히 세웁니다. VPC 엔드포인트를 뚫어서 S3 통신 속도만 올려봅니다. 서버를 일단 잠시 끄고 사양이 두 배 더 좋은 비싼 아재 서버로 수동 교체합니다. 요청을 SQS 대기열에 쌓고, 대기표가 길어지면 서버 숫자가 알아서 늘어나도록(Auto Scaling) 설정합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. 서버가 '나 죽겠다'고 비명을 지르면, 일단 일감을 길에 쏟지 말고 안전한 바구니(SQS)에 담아두어야 합니다. 그러면 서버가 감당 못 할 만큼 요청이 쏟아져도 일단 바구니에 보관되니 유실은 사라집니다. 여기에 바구니에 쌓인 일의 양(대기열 크기)을 보고 서버 대수를 늘려주는 오토 스케일링을 붙이면, 손님이 많을 땐 서버가 일제히 달려들고 적을 땐 퇴근하는 아주 유연하고 경제적인 시스템이 됩니다. 다른 옵션인 A는 S3에서 직접 쏘는 요청(이벤트)을 받기엔 부적절하고, B는 네트워크 통로만 넓힐 뿐 서버의 연산 한계를 해결해주진 못합니다. C는 확장의 한계가 있고 손님이 없을 때도 비싼 월세를 내야 합니다. 💡 이 문제의 핵심 용어 Auto Scaling Group: 상황에 따라 서버 대수를 알아서 넣고 빼주는 자동 조절 군단 SQS (Simple Queue Service): 할 일을 잊지 않게 차곡차곡 쌓아두는 클라우드의 안전한 작업 바구니 CPU Utilization: 서버의 두뇌(CPU)가 얼마나 빡세게 일하고 있는지를 나타내는 백분율
Q249 미디어 회사에서 윈도우 사용자들이 주로 쓰는 SMB 프로토콜로 파일을 주고받으려 합니다. 서버 관리 같은 귀찮은 일은 하기 싫고 AWS가 다 알아서 해주는 '관리형 공유 저장소'를 찾는다면? 파일 게이트웨이를 만들고 온프레미스 서버를 연결합니다. 테이프 게이트웨이를 만들고 S3에 가상 테이프를 채웁니다. 윈도우 EC2를 한 대 사서 파일 서버 역할을 직접 설치하고 관리합니다. Amazon FSx for Windows File Server를 생성해서 바로 연결합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. 윈도우용 공유 폴더(SMB)가 필요하다면 'FSx for Windows'가 정답입니다. 이건 우리가 윈도우 서버를 직접 조립할 필요 없이, AWS가 미리 다 만들어 놓은 '완성된 공유 하드' 서비스입니다. 보안, 백업, 확장까지 버튼 하나로 다 되니 운영 노가다가 가장 적고 신뢰성도 높습니다. 다른 옵션인 A는 온프레미스와 연동할 때나 쓰는 기술이고, B는 예전 영화관 테이프처럼 장기 보관용이라 실시간 파일 공유와는 거리가 멉니다. C는 서버 설치부터 업데이트까지 우리가 다 해야 해서 '완전 관리형'이라는 목표에 탈락입니다. 💡 이 문제의 핵심 용어 Amazon FSx for Windows: 윈도우 서버가 쓰는 파일 시스템(SMB)을 클라우드에서 바로 쓸 수 있게 만든 공유 저장소 SMB (Server Message Block): 윈도우 컴퓨터끼리 파일을 주고받을 때 쓰는 표준 통신 언어 Fully Managed (완전 관리형): 설치, 패치, 복구 같은 귀찮은 일을 AWS가 대신 다 해주는 서비스
Q250 보안팀에서 네트워크 통행 기록(VPC Flow Logs)을 따오라고 합니다. 처음 90일 동안은 수시로 들여다볼 거지만, 그 후엔 가끔씩만 볼 예정이랍니다. 돈도 아끼면서 접근성도 챙기는 로그 보관 전략은? CloudWatch로 보내고 90일 만료 기간을 걸어둡니다. Kinesis로 쏴서 90일 동안만 소용돌이치게 둡니다. CloudTrail을 경유해서 S3 지능형 계층화 저장소에 담습니다. S3에 바로 저장하고, 수명 주기 정책으로 90일이 지나면 저렴한 'Standard-IA' 등급으로 자동 이동시킵니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. VPC 흐름 로그는 곧바로 S3로 던질 수 있습니다. S3는 장기 보관에 최적화되어 있고 수명 주기 정책(Lifecycle Policy)이 매우 강력합니다. 처음 90일은 언제든 빨리 볼 수 있는 Standard 등급에 두고, 90일이 지나는 순간 '자주 안 보는 등급(Standard-IA)'으로 옮기라고 규칙만 정해두면 성능과 비용이라는 두 마리 토끼를 다 잡게 됩니다. 다른 옵션인 A는 90일 후에 로그가 영원히 사라져버려 '간헐적 액세스' 요건을 못 지키고, B는 스트리밍용이지 보관용이 아닙니다. C는 API 로그용 도구를 굳이 거쳐가는 불필요하게 복잡한 방식입니다. 💡 이 문제의 핵심 용어 VPC Flow Logs: VPC를 오가는 모든 트래픽의 발자취를 낱낱이 기록하는 네트워크 블랙박스 Standard-IA (Infrequent Access): 자주 보진 않지만 볼 때는 똑같이 빠른 속도를 내주는 가성비 저장소 등급 Lifecycle Policy (수명 주기 정책): 시간이 지난 파일을 자동으로 삭제하거나 더 저렴한 저장소로 옮겨주는 관리 규칙