결론
AWS를 어느정도 실무에서 사용해본 사람이라면 생각보다 쉽게 자격증 취득이 가능하다. (3~4일정도)
단순하게 덤프를 암기하기만 하더라도 생각보다 얻을 수 있는 내용이 많았다.
현재 150달러에 50%할인 받아서 시험을 쳤었는데
가격이 싸지 않기 때문에 할인 받을 수 있는 쿠폰이 있다면 꼭 사용하는걸 추천한다.
서론
현재 다니고 있는 회사는 cloud native 환경에서 애플리케이션을 운영을 하게 되면서 클라우드 공부에 대한 필요성을 느꼈었다
사실 자격증을 따는것 보다는 공부를 하고 싶었던 마음이 커서 작년에 AWS Certified Solutions Architect 책을 구매하고 친구들과 스터디를 진행했었다. 스터디가 끝나고 자격증을 취득할까 고민했었는데 시험비용이 너무 비싸고 그 당시에 별다른 할인 코드가 없어서 시험에 응시하지 않다가 올해말에 50% 할인 쿠폰을 받을 수 있다는걸 알고 공부를 시작하고 자격증을 취득했다.
시험 준비
사실 업무중에 aws를 많이 사용하기 때문에 용어등에 있어서는 이미 익숙한 상태였고 작젼에 책으로 스터디를 했던 것도 있어서 시험 준비기간은 4일정도로 굉장히 짧게 잡았었다. 블로그에서 개념 정리해준 부분을 보고 (블로그 링크) 덤프 문제를 한번 (약 600문항) 읽어보는 정도로 시험을 준비했다.
다만 이정도로 준비하는거로는 시험 치기전에 좀 불안함이 있었다. 완벽하게 시험을 준비하려면 일주일정도 잡고 덤프문제도 2~3번 풀어보는게 더 좋을 것 같다. 참고로 시험은 한국어를 선택하면 한국어 지문과 영어지문을 모두 볼 수 있기 때문에 한국어로 신청하는걸 추천한다.
자격증 신청 및 시험 과정
자격증 신청은 aws trainng 페이지에 접속해서 신청을 진행하면되는데 대면/온라인으로 진행중에 나는 온라인으로 신청을했다.
온라인으로 신청하는경우가 선택 가능한 날짜와 시간이 굉장히 다양하기 때문에 대면으로 가서 칠 필요성을 느끼지 못했다.
온라인으로 시험을 치는경우 OnVUE로 시험을 치게되고 시험일 30분전에 체크인을 통해서 시험을 치기에 문제가 없는지 체크한다
시험중에는 해당 시험 프로그렘을 제외하고 모두 종료가 되어야하는데
나는 NSAttributedStringAgent 프로그램이 종료가 안된다고 계속 나와서 당황했었는데 혹시 이런 분들이 있으면 활성 상태 보기 창에 들어가서 해당 프로세스를 종료해주면 된다 (mac 환경, 활성상태보기는 activity moitor 를 spotlight에 검색)
체크인을 진행하면서 주변 사진들을 모두 찍어서 보내고 시험이 진행되기 전에 담당자가 캠을 통해서 주변에 특이사항이 없는지 체크하고 시험이 진행되게 된다.
시험을 진행하다보면 잘 모르는 문제가 나올때 검토할 수 있게 별도로 표기해주는 항목이 있으며 시험을 한번 쭉 풀고 나면 해당 검토 항목들로 쉽게 이동해서 시험을 풀 수 있다.
결과
시험 결과는 바로 나올줄 알았는데 시험을 치고나서 5~6시간정도 후에 시험을 신청했던 이메일로 결과를 받아 볼 수 있었다.
1000점중에 720점 이상이면 통과인데 다행히 무난하게 나는 통과 할 수 있었다.
시험 내용 정리
사실 시험에서 나온 내용들 중에 도움이 되는 내용들이 많아서 실무에서 자주 사용하는 개념과, 사용할 수 도 있는 개념은 잊어 버리기 전에 정리하고 싶어서 아래에 간략하게 작성해 본다.
S3
S3 Storage Gateway
온프레미스 환경과 S3를 연동시키는 서비스다
주로 온프레미스의 데이터를 AWS 스토리지에 백업시켜 연동된 상태로 만들고자 할때 사용한다.
- S3 file Gateway
on-premise -> s3 file gateway -> s3
온프레미스의 데이터를 s3에 저장
- FSx File Gateway
on-premise -> FSx file gateway -> FSx for Windows File Server
온프레미스 데이터를 FSx for Windows FIle Server에 저장하는 게이트웨이
프로토콜 : NFS(리눅스/유닉스 기반 파일 공유), SMB(윈도우 기반 네트워크 환경 파일 공유)
- Tape Gateway
on-premise -> tape gateway -> s3 or s3 glacier
온프레미스의 물리 tape를 s3나 s3 glacier로 백업하는 게이트웨이
VTL ( 데이터 백업 복구 기술)
- Volume Gateway
on-premise -> volume gateway -> s3 or s3 glacier
온프레미스의 데이터를 s3에 저장해서 캐시형 또는 보관형 모드로 동작
저장 볼륨 : 데이터를 aws에 비동기 백업
캐시 볼륨 : 최근에 엑세스한 데이터를 온프라미스에 보관
프로토콜: iSCSI (블록 스토리지 프로토콜)
S3의 스토리지 클래스 종류
버킷을 그냥 단순하게 S3로만 생성했었는데 해당 버킷을 생성하고난 뒤에 객체에 대한 추가 적인 설정이
가능하다. 데이터의 접근빈도에 맞춰서 적합한 스토리지 클래스를 선택 할 수 있다.
- S3 Standard
자주 엑세스 하기 위한 데이터 (기본적으로 사용하는 설정)
- S3 Standard-IA
엑세스 빈도가 낮은 데이터 보관 (접근에 따라서 비용이 부과됨)
- S3 Standard Intelligent-Tiering
엑세스 패턴이 변경되거나 알 수 없는 액세스 패턴이 있는 경우 보관
(왜냐면 자동적으로 최적의 비용절감을 제공해주기 때문임, AWS가 자동으로 분석해서 계층을 조정함)
- S3 Glacier Flexible Retrieval
자주 사용되지 않는 데이터로, 낮은 비용으로 데이터를 보관 할 수 있다
복구 속도 3~5시간 정도로 굉장히 느리다
- S3 Glacier Deep Archive
가장 낮은 저장비용을 가지지만 복구 속도가 12시간 이상 걸리기 때문에
극히 드문 복구가 필요한 데이터에서만 사용 해야한다.
수동 조정 방법
S3 gateway endpoint
EC2에서 S3를 호출하는건 기본적으로 IGW(인터넷 게이트웨이) 를 통해서 통신을 한다
이렇게 처리를 하는경우 인터넷을 통해서 통신이 되기 때문에 비용이 들어가게되고 IGW가 없는 private VPC에서는 S3 와 통신이
안되게 될 수 있다.
이런 상황에서는 VPC에서 Endpoint를 설정해서 AWS내부적으로 통신이 이뤄지게 할수 있다 (그리고 무료)
위의 이미지 처럼 VPC에 들어가서 엔드포인트를 생성해줄 수 있다. 서비스/네트워크 VPN 설정/ 라우팅 테이블 선택
등의 작업을 하면 된다.
암호화
- SSE-S3
Amazon s3의 관리형 키를 사용한 서버로 서버측 암호화 이다.
각 객체는 고유한 키로 암호화된다.
- SSE-KMS
AWS KMS를 사용한 서버측 암호화
(s3에서 kms 접근 가능하도록 권한 줘야함)
KMS에서 제공하는 기능을 사용할 수 있으며 감사 추적 기능도 제공한다.
- SSE-C
고객이 제공한 키를 사용해서 서비키 암호화를 처리한다
객체 잠금 모드
저장된 객체를 삭제하지 못하도록 설정이 가능하다
- 거버넌스 모드
특별한 권한 없으면 삭제나 변경 불가능 (but 일부사용자 가능하도록 권한부여할 수 있음)
- 규정 준수 모드
보안된 객체는 aws 루트 사용자도 삭제 변경 불가능 (정해진 준수 기간동안)
EBS/EFS
EBS, EFS, S3의 비교
| EBS(Elastic Block Storage) | S3 | EFS(Elastic File System) |
| EC2에 마운트 가능 | EC2에 마운트 불가능 | EC2에 마운트 가능 |
| 빈번한 읽기/ 쓰기 추천 | 빈번한 읽기와 가끔 쓰기 쓸때 추천 | 빈번한 읽기/쓰기 추천 |
| 서비스 붙을때 AZ에 제한이 있다 | 서비스 붙을때 AZ에 제한이 없다 | 서비스 붙을때 AZ에 제한이 없다 |
| 가격 평균 | 저렴한 가격 | 비싼 가격 |
참고로 이러한 외부 저장소가 없어도 기본적으로 EC2는 인스턴스 스토어를 가지고 있다 물론 휘발성이고 많은 용량을 처리하지는 못한다 해당하는 ec2 스펙에 맞춰져서 정해진 용량만 상용이 가능하다.
AWS WAF
고객이 정의한 조건에 따라 웹 요청을 허용 , 차단 또는 모니터링하는 규칙을 구성하여 공격자로 부터 웹애플리케이션을 보호 할 수 있다.
SQL 명령어 주입, XSS 공격 과 같은 OWASP Top 10의 공격 기술로 부터 웹사이트를 보호 할 수 있다. 또한 속도 제한을 지저앟여 특정 시간 동안의 요청수를 제한해서 ddos 방어도 가능하며, 정규 표현식 및 사용자 정의로 정밀한 필터링 기능도 제공한다.
(alb, cloundfront , api gateway 등 다양한 aws 서비스에 적용이 가능하다)
AWS Global Accelerator
글로벌 사용자를 위해서 애플리케이션의 성능을 개선하기 위해서 가속기를 생성하는 서비스이며 여러 AWS리전에서 엔드포인트를 지원하는 글로벌 엑세스 기능이다. AWS 글로벌 네트워크를 사용하여 구성한 상태, 클라이언트 위치 및 정책을 기반으로 해서 최적의 리전 엔드포인트로 트래픽을 라우팅하기때문에 애플리케이션의 가용성이 향상된다.
엑셀레이터에 적용가능한 엔드포인트 NLB, ALB, EC2인스턴스의 , 탄력적 IP 등
Route53 과의 차이점
: global accelerator는 지연시간 및 헬스 체크에 따라 트래픽을 AWS 네트워크 경로로 최적화 하는데 Route53은 DNS 기반 라우팅으로
라우팅 정책(지연시간, 가중치 등) 을 지원하지만 네트워크 성능 최적화는 제공하지 않는다.
CloudFront
CloudFront Origin Access Contorl (OAC) 방식
s3에 대한 접근을 cloudfront를 통해서만 제공할 수 있도록 설정하는 방식
시험에서는 OAI로 나오는데 이건 오래된 방식이여서 요즘에는 OAC 방식을 선호한다고 한다.
CloudFront 설정에서 Origin Access Control을 생성하고 연결해주고 해당하는
S3버킷에서 아래와 같은 접근 정책을 설정해주면 된다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::YOUR_ACCOUNT_ID:distribution/DISTRIBUTION_ID"
}
}
}
]
}
Cloudfront의 origin 설정과 사용 목적
기본적으로 cloudfront의 경우는 단순하게 이미지를 더 빠르게 보여주는 캐싱 용도로만 생각하고 사용을 했었는데 생각보다 다양한
orign을 설정하고 활용할 수 있다는걸 알게 되었다.
기본적으로 origin으로 설정이 가능한 서비스 들은 s3, alb,nlb,ec2,mediapackage 등이 가능하고
단순하게 정적인 컨텐츠(이미지, 비디오, js 등)을 캐싱해서 제공하는 것 뿐만 아니라
동적인 콘텐츠 (alb, ec2 등) 에 대해서도 캐싱을 제한하거나 ttl을 설정하고 백엔드로 최적화된 경로로 전달해서 지연 시간을 줄이는 등의 처리를 진행할 수 있다.
또한 Lambda@Edge를 활용해서 동적인 요청을 사전에 처리하거나 사용자 지정 로직을 수행할 수 있다
*Lambda@Edge란
Cloudfront가 콘텐츠를 제공하기 전이나 후에 사용자 요청 또는 응답을 커스터마이징 할 수 있다
(사용자 요청 리다이렉션 , 보안 강화, 이미지 사이즈 조정등 정말 다양하게 활용 가능)
AWS Key Management Service (KMS)
암호화 작업에 사용되는 키를 쉽게 생성하고 제어할 수 있도록 지원하는 관리형 서비스
데이터에 대한 엑세스를 제어하는 암호화 키를 중앙에서 관리하며 있다.
AWS SQS (Simple Queue Service)
완전 관리형 메시지 대기열 서비스로 분산 시트엠이나 애플리케이션간의 비동신 통신을 간으하도록 한다.
(메시지 보존 기한은 1분에서 14일 사이로 설정 가능)
유형
- Standard Queue
메시지가 최소 1회 전달 (중복의 가능성 존재)
메시지의 순서 보장 x
높은 처리량을 가지고 있다
(증복이 허용되거나 별로 중요하지 않은 애플리케이션에서 사용)
- FIFO Queue
메시지가 정확히 한번 전달
메시지 순서가 보장됨
처리량이 상대적으로 낮음 (초당 300TPS)
(초당300은 2016년에 초기 출시당시의값이고 현재는 9,000tps이상이고 일부지역은 700,000이상)
가시성 제한 시간
기본적으로 사용했다고 바로 삭제되는 형태가 아니기 때문에 필요함
다른 소비자가 메시지를 수신하면 한동안 처리할 수 없도록 차단하는 시간으로
기본은 30초 (최소 0초 최대 12시간)
Dead letter Queue(DLQ)
실패하면 dlq에 보관했다가 다시 처리하게하는 기능을 가지고 있다.
AWS Key Management Service (KMS)
암호화 작업에 사용되는 키를 쉽게 생성하고 제어할 수 있도록 지원하는 관리형 서비스
데이터에 대한 엑세스를 제어하는 암호화 키를 중앙에서 관리하며 있다.
RDS
RDS Proxy
AWS의 데이터 베이스를 사용하는데 ( aurora mysql, RDS mysql ,RDS prostgreSql 등등 ) 성능적으로 이슈가 있어서 지연되는 상황등에서 고려해볼 수 있는 서비스로 데이터베이스와의 연결 풀링 기능을 제공하는 관리형 프록시.
RDS Proxy와 데이터베이스 연결 비교
| 특징 | 직접 연결 | RDS Proxy연결 |
| 연결 설정 시간 | 각 요청마다 새로 연결 | 기존 연결 재사용 |
| 연결 수 관리 | 애플리케이션이 직접관리 | 프록시에서 자동 관리 |
| 장애 조치 | 애플리케이션에서 수동 처리 | 자동으로 활성 인스턴스로 전환 |
| 확장성 | 연결 수 제한으로 확장성 낮음 | 높은 연결 수 처리 가능 |
Aurora 클러스터
Aurora는 aws에서 직접 설계한 고성능 데이터 베이스로 클러스터 기능이 존재한다.
기본적으로 Aurora의 데이터베이스를 사용하면 클러스터 구성이 잗동으로 설정되며
Primary 로 기본적으로 메인이 되는 인스턴스가 존재하며 여러 복제본 인스턴스가 존재한다
각 복제본 인스턴스는 읽기 전용으로 항상 primary와 데이터 동기화를 유지하고 있으며
장애가 발생하는 경우 해당 복제본이 새로운 primary로 승격되게 된다
Amazon Kinesis Data Stream/Amazon Kinesis Data Firehose
요거 두개에 대한 설명 부분이 먼가 가장 헷갈리는 부분 중에 하나였다 이름도 비슷해가지고
결과적으로 보면 Amazon Kinesis Data Stream은 카프카와 같은 실시간 데이터 스트리밍 플랫폼이라고 볼 수 있다.
데이터의 스트리밍은 관리해주지만 해당 데이터를 생성하고 처리하는 거는 별도의 애플리케이션으로 관리해야한다.
그래서 AWS Lambda, Kinesis Data Analytics, 또는 사용자 정의 애플리케이션과 같이 사용을 하면서 데이터를 처리 할 수 있다.
Amazon Kinesis Data Firehose은 데이터를 전달 하는 서비스라고 생각하면 될것 같다. 데이터를 직접적으로 특정 위치에 적재할 수 있고 그러한 적재 전에 데이터를 변환 하는 작업도 제공한다. 즉 데이터를 처리할 별도의 애플리케이션을 구현 안해도 괜찮다
데이터 적재가 가능한 서비스는 Amazon S3, Amazon Redshift, Amazon OpenSearch Service (Elasticsearch) 등이 있다.
Amazon Kinesis Data Stream를 보면 사실상 카프카와 동일한 기능이라고 볼수있는데 카프카를 AWS에서 사용할때는 보통 MSK를 생각하는데 이런 MSK는 아파치 카프카를 완전관리형에서 AWS에서 사용할 수 있는 기능이고 Kinesis Data Stream은 AWS에서 독자적으로 생성한 스트리밍 서비스라고 보면 된다! 카프카보다 설정도 간단하고 완전관리형으로 요청수 당 과금을 하기 때문에 나중에 한번 사용해볼 법 한것 같다.
Kafka vs msk vs kinesis data streams 비교
| 특징 | Apache Kafka | Amazon MSK | Amazon Kinesis Data Strems |
| 설치 및 관리 | 사용자가 직접 설치 및 관리 | AWS가 관리 | 완전 관리형 |
| API 호완성 | Kafka API | Kafka API(100% 호환) | 독자적인 API |
| 확장성 | 파티션 단위 확장 | 파티션 단위 확장 | 샤드 단위 확장 |
| 보존 기간 | 사용자 정의 (몇주~ 몇년 가능) | 사용자 정의 (몇주 ~ 몇년 가능) | 기본 24시간 최대 7일 |
| AWS 통합 | 수동 통합 필요 | Cloudwatch, IAM, KMS등 통합가능 | AWS Lambda, Kinesis Analytics 등 통합 가능 |
| 사용 사례 | 온프레미스 or 멀티 클라우드 환경 | AWS에서 사용 | AWS에서 서버리스 실시간 데이터 처리 |
| 운영 복잡성 | 높음 | 중간 | 낮음 |
| 비용 모델 | 인프라 비용 및 관리 비용 | MSK 클러스터 크기 기준 과금 | 샤드 및 요청 수 기반 과금 |
Amazon Simple Notification Service (SNS)
SNS는 완전 관리형 Pub/Sub 서비스이다. SQS와 차이점을 초반에는 조금 헷갈렸는데
결과적으로 SQS는 대기열을 기반으로 수신자에게 전달(한명) 하는 시스탬이고 SNS는 여러 구독자에게
동시에 데이터를 전달 할 수 있다.
SNS는 그래서 AWS의 내부 시스템 SQS, Lambda등에 데이터를 전달할 수 도 있고 외부의 시스템에도 데이터를 보낼 수 있다.
아래와 같은 이미지로 이해하면 되고 결론적으로 사용하는 case는
여러 사용자에게 일괄적으로 알림을 보낸다거나 여러 컴포넌트에서 병렬로 처리를 수행하는 시스템에서 사용할 수 있다.
SNS 관련해서 설명 잘 되어있는 블로그 링크