아무거나 시도해보는 개발일지

1. 준비 기간

1개월 정도. 실제로 공부한 기간은 2주정도이다. ( 하루 2시간 씩 )

이전에 AWS 실습을 해봤기 때문에 EC2 및 네트워크에 대한 기본적인 이해는 있었다.

그 외에는 별다른 배경지식 X.

IT 운영업무를 하고 있긴하나, On-Promise 환경에서의 운영경험은 시험에 크게 도움되지 않았다.

2. 준비 방법

많이들 이용하는 examtopics에서 무료 연습문제를 계속 풀었다.

( https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c02/ ) 

다른 후기들을 보면 연관률이 높다고 하나, 문제은행처럼 문제와 답이 똑같이 나오는 경우는 잘 없는 것 같다.

실제 시험과 출제의도가 비슷하다 정도?

또한, 버전별로 500문제가 넘어가기 때문에 외워서 합격하기는 힘들 것이다.

핵심 키워드나 문제 상황을 AWS 솔루션과 매칭시키며 풀려 하였고,

문제 풀이가 내 의도와 달랐다면, 정리하고 다음 문제로 넘어갔다.

또한 AWS FAQ와 연관이 높다고 하여

자주 나오는 솔루션에 대해 FAQ 초반부분을 정리하며 개념을 익혀나갔다.

이렇게 꼼꼼하게 정리하고, 유형을 익혀가며 300문제를 푸는데 1주 반정도 걸렸고

나머지 2~3일은 빠르게 100문제를 풀며, 눈으로 익혀나갔다.

3. 시험 당일

코로나로 인해 전부 온라인 시험이다.

비 영어권 시험자들을 위해 30분을 주니, 시험전에 신청하도록 하자.

시험 전날 환경 테스트를 모두 마쳤음에도 당일에 40분 이상걸렸다. 

시험시간 30분 전부터 준비가 가능하니, 미리 입장하는것이 좋을 것 같다.

필요한 준비물은 여권, 캠/스피커/마이크가 가능한 PC 혹은 노트북 정도이다.

이는 사전에 테스트가 가능하고, 당일날 추가 환경점검에서 시간이 많이 걸렸다.

시험환경을 360도 보여주는 과정에서 책상위에 작은 물품부터 정리해야했고

선을 뽑은 모니터가 있어서, 이를 계속해서 확인하는 과정이 오래걸렸다.

책, 핸드폰, 노트, 전자기기등 조금이라도 부정행위가 가능한 항목에 대해서

철저하게 검사하니 미리 치워놓는게 좋을 것 같다.

이렇게 환경 검사 후, 손목과 귀를 보여주면 시험이 시작된다.

얼굴이 이동하거나 조금만 가려도 경고가 들어오니, 기타 용무는 사전에 처리하자. ( 2회경고 시 탈락 )

의식적으로 자세를 유지하니, 집중이 잘 안되었다. 컨디션이 떨어지는 것을 감안해야 할 것이다.

완벽하게 문제를 이해하고 풀기 어려웠고

키워드와 솔루션을 매칭해가며 공부한 덕에 그나마 합격할 수 있었던 것 같다.

문제 자체는 기존 덤프보다 쉬웠다.

기존 덤프는 두가지 이상의 복합적인 상황이 많았으나 ex:) CloudFront + S3 + Multi-AZ DB 

실제 시험은 단일 솔루션을 찾는 문제가 대부분이었다.

덤프에서 많이 틀린다고 낙심하지말고

출제의도 (키워드, 상황)만 잘 공부한다면 어렵지 않게 붙을 수 있을 것 같다.

1) Kinesis Data Streams

스트리밍 데이터를 처리 또는 분석. 데이터를 스트리밍하기 위해 필요한 인프라,네트워크 등을 설정해줌

ㅁ 실시간 데이터 분석 및 지표 생성

ㅁ 보존기간에 제한이 있어 24시간/ 7일/ 365일이다.

2) AWS EMR

빅데이터 분석 플랫폼. Spark 및 Hive 기반

1) AWS Shield

DDOS 보호 시스템. Standard 및 Advance 버전 존재

Stnadard - 어플리케이션 계층 및 웹사이트에 대한 DDOS 공격 보호 ( ALB )

Advance - 더 높은 3,4 계층까지 보호. ELB, CloudFront, Global Accelerator, Route 53 리소스에 대한 DDOS 공격 보호

2) Guard Duty

악의적 활동을 모니터링하고, 상세한 보안 결과를 제공하여

검출할 수 있도록 도와주는 서비스

※ DDOS 공격 관련해서 실제로 처리하는건 Shield 솔루션.

  전체적인 보안을 감지할 수 있도록 도와주는게 Guard Duty이다.

3) AWS Inspector

어플리케이션 보안 및 규정준수를 도와주는 자동 보안평가 서비스.

※ Guard Duty는 계정에 대한 모니터링 및 취약점 분석을 돕는다면,

   Inspector는 EC2 인스턴스에 대한 취약점 분석

1. CloudFront

엣지 로케이션을 이용해, 사용자에게 짦은 지연시간과 빠른 데이터 전송을 통해 컨텐츠를 배포함

ㅁ Real-time 이나 Video, Streaming 같은 비디오 컨텐츠를 Global 하게 서비스하는 문제에 자주나옴

ㅁ S3와 달리 엑세스 빈도가 높은 정적 콘텐츠를 배포할때 유리

ㅁ 특정 지역에서의 엑세스를 제한할 수 있음

ㅁ AWS certificate Manager와 연동하여 인증서 기반의 통신 가능

ㅁ CloudFront 함수, Lambda@Edge 를 통해 각 엣지로케이션에서 함수 실행

2. Global Accelerator

가속기를 사용해, 전 세계 이용자가 사용하는 서비스의 성능을 향상시켜줌

ㅁ 2개의 정적 IP를 제공하기 때문에, 최적의 리전 엔드포인트로 연결해준다.

  => 가용성 향상

3. AWS Route 53

AWS 도메인 서비스. 도메인 등록, 트랜잭션 라우팅, 리소스 상태확인 기능을 제공한다.

인스턴스의 상태확인만 가능한 ALB와는 달리, ALB의 상태체크 및 Fail over 정책도 포함

다양한 라우팅 정책들이 있지만, 덤프에 나왔던 geolocation 및 geoproximity에 집중하자.

+ Active 서버로만 트래픽을 보내야할 때, Multivalue 정책을 사용

• 단순 라우팅 정책(Simple routing policy) - 도메인에 대해 특정 기능을 수행하는 하나의 리소스만 있는 경우
• 장애 조치 라우팅 정책(Failover routing policy) - 액티브-패시브 장애 조치를 구성하려는 경우에 사용합니다.
• 지리 위치 라우팅 정책(Geolocation routing policy) - 사용자의 위치에 기반하여 트래픽을 라우팅하려는 경우에 사용합니다.
• 지리 근접 라우팅 정책(Geoproximity routing policy) - 리소스의 위치를 기반으로 트래픽을 라우팅하고 필요에 따라 한 위치의 리소스에서 다른 위치의 리소스로 트래픽을 보내려는 경우에 사용합니다.
• 지연 시간 라우팅 정책(Latency routing policy) - 여러 AWS 리전에 리소스가 있고 왕복 시간이 적은 최상의 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우에 사용합니다.
• 다중 응답 라우팅 정책(Multivalue answer routing policy) - Route 53이 DNS 쿼리에 무작위로 선택된 최대 8개의 정상 레코드로 응답하게 하려는 경우에 사용합니다.
• 가중치 기반 라우팅 정책(Weighted routing policy) - 사용자가 지정하는 비율에 따라 여러 리소스로 트래픽을 라우팅하려는 경우에 사용합니다.

4. AWS WAF

고객이 정의한 조건에 따라 트래픽을 허용,차단,모니터링 하는 웹 어플리케이션 방화벽

ㅁ 속도 제한 규칙을 통해 DDOS 공격을 방지할 수 있다.

 - 특정 텀으로 클라이언트 IP에서 보내는 요청수를 제한 할 수 있음

5. Gateway endpoint

AWS 서비스 접근하는 트래픽에 대해, 라우팅으로 접근하게 해줌.

문제예시 : 3개 AZ에 pirvate subnet 서비스를 접근하기위해, 네트워크 구성변경이 필요할때

              gateway endpoint for S3 사용

6. Transit gateway

On-Promise 네트워크와 VPC를 연결해주는 네트워크 허브.

1) AWS Aurora 

MySQL 및 PostgreSQL 과 호환되는 관계형 데이터베이스 엔진.

성능은 2배이상 좋고, 스토리지는 64TB까지 자동으로 증가한다.

ㅁ자동 백업이 이루어지고, 가용성을 위해 3개 가용영역에 데이터 사본을 유지한다.

ㅁ Aurora Serverless를 통해 DB가 가동될때만 비용을 낼 수 있다

 - 간헐적 사용 혹은 예측 불가능한 워크로드의 경우

2) AWS RDS

AWS에서 제공하는 관계형 데이터베이스 서비스.

Maria, MySQL, Oracle, MS SQL, Postgre 엔진 지원

ㅁ 다중 AZ 배포를 통해 DR 가능

3) AWS DynamoDB

비 관계형 데이터베이스. 성능적으로 관계형 데이터베이스보다 뛰어남

ㅁ 읽는 방법

Eventually Consistent Reads - 읽기 처리량을 최대화 하여, 빠르게 결과값을 가져옴.

                                       그러나 최근 업데이트분을 가져오지 못할 수도 있음

Strongly Consistent Read - 최신 데이터를 포함하는 응답. 지연시간 있을수 있음

4) AWS Elasticahe 

Memcached 또는 Redis와 호환되는 인 메모리 캐싱

5) AWS Redshift

클라우드 데이터 웨어하우스 서비스

ㅁ Advanced Query Accelerator(AQUA)를 통해 분산형으로 관리 가능 ( 10배 빠른 속도 )

6) AWS athena

표준 SQL을 사용하여 S3 데이터를 분석하는 대화식 쿼리 서비스.

따로 구성할 필요 없는 서버리스고, 사용한 쿼리만큼 비용을 지불한다.

7)  AWS Neptune

그래프 데이터베이스 관리 시스템

AWS 스토리지

1) Instance Store 

인스턴스에 직접 연결된 블록 형태의 스토리지.

임시 스토리지로, 인스턴스 중지/종료 또는 하드웨어 장애 시에 데이터를 유지할 수 없다.

2) EBS ( Elastic Block Storage )

인스턴스 중지/종료 시에도 데이터를 보존해주며 EBS 스냅샷을 통한 정기적인 백업도 가능하다.

다른 인스턴스로 붙일 수 있고, 스토리지 암호화를 제공한다.

ㅁ 크게 HDD (처리량 워크로드)와 SSD (트랜잭션 워크로드 - IOPS, 지연시간 및 내구성) 로 나뉜다.

ㅁ API Call 혹은 SDK를 통해 스냅샷을 저장할 수 있다. ( S3 API는 X , 오직 EC2 API를 통해서만 )

ㅁ AWS KMS (Key Management Service)를 통해 데이터 암호화 가능

ㅁ CMK ( Customer Master Key ) 를 통해 인스턴스 시작시, 암호화된 볼륨 생성

ㅁ CMK를 통해 암호화된 AMI 및 스냅샷 공유 가능

3) EFS ( Elastic File Storage )

클라우드에서 제공하는 서버리스 파일 시스템. 인스턴스, 컨테이너, Lambda 등 다양한 목적으로 사용된다.

ㅁ Linux 기반의 AMI와 호환됨

ㅁ Linux Mount 명령어 및 파일시스템 DNS를 사용해서 접근

ㅁ Data Sync를 통해 On-Promise에서 데이터 이관 가능

ㅁ 클래스는 Standard ( Multi-AZ ) 및 One-Zone ( Single-AZ )로 나뉜다

ㅁ IA ( Infrequent-Access ) 스토리지를 통해, 사용이 적은 파일을 저렴한 가격으로 보관할 수 있다.

   => 수명주기를 통해 기준을 정하거나 Intelligent-Tiering을 통해 자동으로 분류한다.

ㅁ Provisioned Throughput 모드를 통해, 용량 대비 처리량이 높은 스토리지 사용 가능

   ※ 기본 모드는 버스트 모드

ㅁ Cloud Watch를 통한 파일시스템 모니터링 및 Cloud Trail을 통해 API 호출로그 기록 가능

4) S3 ( Simple Storage Service )

객체 스토리지 서비스 이다.

EFS 처럼 IA 및 Intelligent-Tiering이 존재하며

아카이빙용도로 S3 Glacier / S3 Glacier Deep Archive(1년에 1,2번 엑세스)가 있다.

ㅁ ACL보다 IAM을 통해 정책으로 제어하고, 리소스 기반 정책을 통해 권한 관리를 한다

ㅁ IA를 제외하고 Standard, Glacier 클래스는 최소 3개의 가용영역에 저장된다

ㅁ PUT, DELETE 등의 S3작업에 이벤트를 걸어 SNS,SQS를 통해 전송되거나 Lambda로 직접 연결될 수 있다

ㅁ S3 Transfer Acceleration로 엣지 로케이션을 통해, 빠르게 데이터 전송 가능

    => GB 및 TB 단위의 데이터를 정기적으로 전송할때 유용

    => 더 큰 대량의 데이터는 Snowball을 통해 전송

ㅁ Direct Connect를 통한 프라이빗 네트워킹

ㅁ 키관리

 = SSE-S3 : 아마존에서 키 관리 및 키 보호를 수행

 = SSE-C : 암호화 라이브러리는 구현하지 않지만, 키 관리는 고객이 해야함

 = SSE-KMS : 사용자가 서버 암호화 및 키 관리 수행. 엑세스 차단 및 접근 시도 로그를 볼 수 있음

ㅁ Endpoint를 통해 VPC 내에서 S3에 바로 붙을 수 있다.

  => 주로 인터넷 게이트웨이, NAT 게이트웨이로 연결하던 네트워킹을 저렴한 금액으로 연결하기 위한 문제로 나옴

  => 다른 리전일 경우 인터페이스 기반 Endpoint 사용 / 같은 리젼일 경우 게이트웨이 기반 Endpoint 사용 ( 무료 )

ㅁ 보안, 성능 등의 이유로 Cloud Front를 통해 붙을 수 있다. - OAI (origin access identity) 설정

ㅁ Amazon Macie을 통해 AI 머신러닝 기반으로 S3 데이터를 보존할 수 있다

ㅁ 버전관리를 통해 데이터 변경될때마다 객체를 보존, 검색 및 복원 가능

ㅁ MFA ( Multi-Factor Authentication ) Delete를 사용하여

   객체 삭제시에 AWS 자격증명 외에 추가 인증을 설정할 수 있다

ㅁ 기존 Tape에서의 마이그레이션

 - 가상 테이프 라이브러리 (VTL)을 통한 통합

 - Snowball 혹은 Snowmobile

 - Direct connect

ㅁ 객체 태그를 통해 엑세스 제어, 태그별 데이터 분류 등 스토리지 관리에 용이

ㅁ 배치를 통해 단일 객체작업 혹은 Lambda 실행, Cloud trail 전송을 자동화 할 수 있음

ㅁ 객체 잠금을 통해 날짜를 지정하여 객체 버전 삭제 및 덮어쓰기 차단

    WORM 보호 - Write-Once-Read-Many(WORM)
ㅁ 스토리지 렌즈를 통해 사용량 및 활동지표 분석

ㅁ Global Accelerator를 사용하여 다중 리전 엑세스 포인트 설정가능.

 - 네트워크 요청을 가까운 리전으로 자동 라우팅

ㅁ 접근성이 낮은 데이터에 대해 Infrequent Access로 관리가능

 - Standard IA : 최소 3개 AZ에 저장. 가용성 및 복원력

 - One Zone IA : 단일 AZ에 저장. 빠르게 접근하고 비용도 낮으나, 가용성과 복원력이 보장 안됌

5) AWS Backup

자동으로 백업 플로우를 구축해주어 규제 및 내구성을 충족해주는 백업 서비스

ㅁ RTO, RPO 같은 복구시점 얘기가 나오면 Backup 관련한 문제

 ※ RTO ( Recovery Time Objectives ) : 목표 복구 시간 / RPO ( Recovery Point Objectives ) : 목표 복구 지점

ㅁ 백업 저장소 잠금을 통해 수명주기 변경 및 수동 삭제를 방지

 - Write-Once-Read-Many(WORM) 모델 사용

6) Storeage gateway

온프레미스 환경에서 클라우드 스토리지로의 연결을 제공하는 서비스 

ㅁ 파일기반 게이트웨이와 ( S3, FSx for windows file server ) 볼륨/테이프 기반 스토리지로 나뉜다.

ㅁ 파일기반은 NFS 혹은 SMB 프로토콜 / 볼륨 기반은 iSCSI 디바이스를 사용한다.

ㅁ 볼륨기반 게이트웨이는 캐싱방식과 저장방식으로 나뉜다

 - 캐싱 : 모든 데이터를 S3에 저장하고 자주 접근하는 데이터를 로컬에 복사한다. -> 로컬 스토리지 확장이 최소화

 - 저장 : 모든 데이터를 로컬에 저장하고, 시점마다 스냅샷을 S3에 보관 -> 낮은 지연시간 및 우수한 내구성

ㅁ 테이프기반 스토리지는 가상 테이프 라이브러리 (VTL) 사용한다 정도로 기억

ㅁ Private Link 및 Direct Connect와 함께 사용 가능

7) Snowball Edge

Edge 환경에서 AWS와 데이터를 주고받을 수 있는 디바이스

원격 공장/발전소, 모바일 환경등에서 사용 가능하며, 인터넷이 통하지 않아 Datasync를 사용할 수 없을때도 사용한다.

ㅁ Compute Optimized 기준 50TB 이므로, 문제에서 데이터 사이즈가 비슷하면 정답확률이 올라간다.

 => 유사 서비스로 Snowmobile 이 존재하고, 엑사바이트의 대규모 마이그레이션에 사용된다.

     ( 보통 10PB 를 넘냐 안넘냐로 구분함 )

8) FSx for Lustre

AI 분석 및 고성능 컴퓨팅의 경우 사용하는 고성능 공유파일 시스템

여러s3에 연결하여 데이터를 빠르게 처리하기도한다.

ㅁ 임시로 사용되는 scratch와 영구로 사용되는 persistent 로 분리됨

AWS 서버 제공 유형

1) EC2

가장 중요한 인스턴스 서비스이나, 시험에는 단독으로 나오지 않는 경향.

EC2는 기본으로 설정되어있는경우가 많고

관련하여 고가용성을 위한 로드밸런싱이나 , DR등 관련 시스템을 물어보는 문제들이 많다.

ㅁ Spot Instance : 온디맨드 가격보다 저렴한 비용으로 제공되는 예비 EC2 용량을 사용하는 인스턴스

                        스팟 인스턴스는 경매 방식으로, 현재 최고가보다 높은 금액이 나오면 종료된다.

                        따라서 언제 중단되어도 이상없는 서비스에 적합하다.

2) ECS, EKS

AWS에서 제공하는 컨테이너 관리 서비스.

EKS (쿠버네티스)와 함께 컨테이너 서비스를 물어볼때 나오며

ECS와 EKS에 대한 설명을 문제에서 주고, 구현을 위해 AWS Fargate를 정답으로 하는 문제도 자주 나온다.

※ AWS Fargate ( 서버 관리가 필요없는 종량제 서버리스 컴퓨팅 엔진 ) 

3) AWS Lightsail

개발자용으로, 가상 private 서버를 시작하고 관리해주는 서비스

인스턴스, 컨테이너, DB, CDN, 로드밸런서, 고정IP, 백업 등 대부분을 자동으로 지원해주어 편리하게 사용 가능

4) AWS Batch

배치 컴퓨팅을 위한 서비스. 리소스가 동적으로 설정되고 결과 분석에만 집중하면 된다.

ㅁ 배치그룹

 - 클러스터 : 인스턴스들을 가용영역 안에 하나의 그룹으로 묶음. 낮은 지연시간

 - 파티션 : 가용영역 안에서, 논리적으로 파티션을 두어 다른 그룹과 공유를 하지않음.

               하둡이나 카프카 같은 대규모 분산솔루션에 적합

5) AWS Elastic Beanstalk

어플리케이션 구동에 대한 서비스 제공.

소스코드만 올리면 자동으로 인프라, 모니터링, 부하분산 등 구현에 필요한 모든것을 수행해준다.

GO, JAVA, Node, Python 등 다양한 언어와 플랫폼을 지원한다.

6) AWS Lambda

서버를 띄우지 않고, 코드를 실행하는 서비스. ( 최대 15분 )

코드가 수행되는 동안 사용된 리소스만큼만 요금이 부과된다.

ㅁ Lambda 설정을 위한 API Gateway 를 묻는 문제

ㅁ Lambda를 통한 S3와 Dynamodb 데이터 처리 트리거 

   => Bucket 內 이미지 리사이징 혹은 DB에 업데이트 된 데이터 처리

ㅁ Kinesis 혹은 SQS ( Queue 서비스 )에 저장된 스트리밍 데이터 처리

ㅁ EC2 혹은 On-Promise 환경에서 어플리케이션 처리 및 속도를 높이기 위한 Lambda 사용

ㅁ Lambda@Edge를 통한 엣지 로케이션에서 코드 실행. 빠른 응답

ㅁ Lambda RIE ( Runtime Interface Emulator ) - 로컬에서 Http 요청을 통한 Lambda 기능 테스트

7) Auto Scaling

Request 처리를 위한 EC2 인스턴스의 수를 유지하는 서비스.

EC2를 묶어 그룹을 생성하고, Minimum / Desired / Maximum 을 통해 개수를 조절한다.

ㅁ Cloud Watch를 통해 경보를 전송하고, 인스턴스 관리 가능 ( ex: CPU )

ㅁ ELB ( Elasitc Load Balancing )을 사용해 Scaling Group 트래픽 분산 가능

   => ELB 사용하지 않을 시 Route 53을 통해 트래픽을 정상 인스턴스로 포워딩

ㅁ metric을 (ex: 리퀘스트 수) 지정하여 인스턴스 수를 조정할 수 있다 - 대상 추적

ㅁ 같은 가용영역(AZ) 내에서는 이전이 가능하나, 다른 리전으로 확장 될 수는 없음

ㅁ target tracking 을 통해 원하는 지표로 인스턴스 관리 가능 ( ex: CPU )