# AWS-SAA
AWS SAA 자격증 후기
인프라 엔지니어로써 커리어를 정하고 공부하면서 현대 IT 인프라 부분에서 퍼블릭 클라우드의 중요성을 매우 느끼게 되었다. 퍼블릭 클라우드에서 가장 많은 영역을 차지하고있는 AWS를 배우기 위해 AWS Certified Solutions Architect - Associate(SAA) 자격증을 취득하기로 결정했다. 공부 과정 개념 학습 개념을 처음 공부하지 않고 문제만 본다면 이해하는것이 어려워서 certified-solutions-architect-associate 문서의 skill builder 나 강의를 활용하는 것이 좋다. 나는 패스트캠퍼스의 온라인 학습 플랫폼의 강의를 이용했고, 이를 통해 AWS의 주요 서비스와 아키텍처에 대한 이해를 높일 수 있었다. 키워드 공부 핵심 키워드들이 있다. AWS S3등 스토리지, AWS Lambda, ec2 등등 키워드 자체를 모른다면 문제를 아예 읽을 수 조차 없다! 여러 키워드들을 그냥 외우는것보
AWS Certified Solutions Architect Associate 시험 후기 | 합격❤️
지난 주말에 AWS Certified Solutions Architect Associate 자격증 시험에 합격했다❤️ 생각보다 고득점을 맞아서 넘 행복했다 : ) 그래서 적는 후기!! 공부 방법 개념 공부 유데미 강좌 1회 듣기 : 링크 이해 안되면 한 번 더 듣고 어려워보이는건 듣기 전에 한국어 자막본 미리 읽고서 시청했다. 해당 강좌가 굉장히 유익하고 알찼다. 게이트웨이 타임아웃이 나요!! 라고 한다면 보안그룹을 확인해봐라 같이 실제 회사에서 일어날 법한 예시들을 들면서 설명을 해
AWS SAA 자격증 취득 후기
카카오 클라우드 스쿨을 통해 배웠던 AWS의 여러 서비스와 수행 프로젝트의 경험을 기반으로 AWS Certified Solutions Architect - Associate 자격증에 도전했다. 필자가 응시한 버전은 SAA-C03이다. 시험 준비 공부 하면서 참고한 것이 몇가지 있다. > AWS 각 서비스의 FAQ(리소스) examtopics 덤프 chatGPT 필자는 시험 준비를 위해 우선 examtopics의 덤프를 풀었다. 문제를 풀면서 모르는 서비스가 있다면 해당 서비스의 공식 문서를 읽은 뒤 정리했다. 문제를 풀다보면 공식 문서를 읽어도 잘 이해가 되지 않거나, 비슷한 서비스 간의 용도나 차이를 파악하기 힘든 경우가 발생할 수 있다. 이때 유용하게 사용했던 것이 chatGPT이다.
[후기]aws-certified-solutions-architect-associate 자격증 시험 후기
사건의 발단 23년 2월 15일 같이 스터디를 하던 팀원들과 이야기 하던 중 정말 충동적으로 SAA를 신청하게 되었다. 이미 합격한 1분과 신청한 1분의 조합은 나를 자극하기에 충분했고 몇 마디를 듣다보니 어느새 17만원을 결재하고 있었다. ㅋㅋㅋㅋㅋ 시험 준비 과정 시험 일자는 2월 27일 준비는 16일부터 진행했다. 일단 합격한 사람의 말을 따라 좋다는 Udemy강의를 구매했다. 이때부터는 거의 브레이크가 뽑힌 8톤 트럭마냥 앞만 봤던 것 같다. 처음에는 굉장히 자신감이 있었다. 대학교때부터 외우는건 잘했으니까... 아날로그가 더 편한 내가 손으로 강의를 필기하며 하루 하루가 지나다 보니 필기한 페이지가 40페이지를 넘어간다... 점점 뭔가 잘못되어가는 것을 느꼈지만 이미 브레이
AWS 파일 공유 시스템 , Storage Gateway
파일이 수정되어 EC2가 수정된 파일을 모두 반영하거나 , 하나의 EC2가 파일에 쓰기 작업을 했을 때 일관성을 유지하기 위해서는 다른 EC2도 해당 쓰기 작업을 반영해야한다. 변경사항을 일일이 각 EC2마다 접속해서 읽기/쓰기 작업을 한다면 비효율적일 것이다. 이때 사용하는 것이 파일 공유 시스템이다. EFS (Elastic File System) > - S3와 같은 스토리지로 많은 EC2에 탑재된다. NFS(Network File System) 프로토콜에 의해 관리된다. 여러 EC2가 '동시' 접속을 가능하게 해준다. -> 하나의 EC2에서 변경사항을 기록하면 다른 EC2들이 동시에 접속해서 변경사항을 읽거나 쓸 수 있다. Linux기반이다. USE CASE : 음식
서버리스 / AWS의 Container Management
서버리스 > 완전관리형 서비스를 서버리스 컴퓨팅이라고 한다. 완전관리형 서비스라는 것은 개발자가 인프라(서버)를 직접 관리할 필요가 없다는 것이다. 비용효율적, 운영 효율적, 접근성과 확장성이 높다 코드수정이 적다 운영의 자동화가 가능하다 개발자는 그저 fuction만 배치하면 된다. AWS에는 Fargate, Lambda, API Gateway, Aurora Serverless 등이 서버리스다. 💡 서버리스는 직역하면 "서버가 없다"이다. 하지만 실제로는 서버가 없는 것이 아니고 특정 작업을 수행하기 위해서 컴퓨터를 혹은 가상머신에 서버를 설정하고 이를 통해 처리하는 것이 아닌 BaaS, Faas에 의존하여 작업을 처리한다는 것이다. Lambda > 개발자가 원하는 작업을 람다 함수로 만들어서 람다와 통합된 특정 리소스에 data가 들어왓을 때 함수가 실행되어 원하는 작업을 수행할 수 있다. 개발자는 기능만 구현할 뿐 지속적으로 관리하는
DC vs Snow Family vs VPN vs Transit Gateway
하이브리드 클라우드 네트워킹 > 기존의 AWS환경의 VPC는 온프레미스와 인터넷 연결을 중심으로 상호작용했다면, 기업 데이터센터의 경우 하이브리드 클라우드 네트워킹을 통해 인터넷과도 연결성이 없으며, 프라이빗 속성을 가지고 상호작용한다. DC, VPN,Transit Gateway 세가지가 있다. 💡 AWS-AWS, 온프레미스-온프레미스 연결이 아닌 반드시 온프레미스 - AWS환경의 연결이어야 한다. DC(Direct Connect) > 대용량의 데이터를 저지연으로 마이그레이션 해주는 것으로, 온프레미스와 AWS를 지정된 Private Network를 통해 연결하여 데이터를 전송한다. 인터넷을 우회해서 접속하기 때문에 퍼블릭 인터넷을 사용하지 않는다. -> 문제 발생 가능성을 낮추고 광대역
CloudFront / GlobalAccelerator
CloudFront > CDN(Content Delivery Network)라 부르며, 전 세계에 걸쳐 저지연의 속도 로 사용자에게 컨텐츠를 전달할 수 있는 캐싱 서비스이다. 📌 Elastic cache, DAX는 KB수준의 작은 데이터를 캐싱하는데 적합하지만 Cloudfront는 이미지,비디오,스트리밍 데이터등 큰 단위의 데이터를 캐싱하는데 적합하다. 📌 정적컨텐츠 (이미지,비디오,스트리밍 영상 등)를 캐싱하여 전달한다. 동적컨텐츠 X 📌 프로토콜 = HTPP / HTTPS > Cloudfront를 사용하는 이유는 예를들어, 사용자가 한국에 위치하는데 미국에서 데이터를 전송해서 받는다면 이것은 매우 느리고 비효율적이기 때문이다. 마치 돈을 인출하기 위해서 해당 은행에 가지 않고 곳곳에 배치된 ATM에 가서 인출하는것과 같다. ( 우리가 흔히 아는 NETFLIX도 이 CDN을 이용하여 컨텐츠를 전달한다. ) >> 전세계에 216개의 edge locations
CloudTrail / Config
우리는 AWS리소스와 애플리케이션의 상태, 성능 , 보안수준을 관리하기 위해 AWS환경을 지속적으로 모니터링한다. 이것을 가능하게 해주는 서비스가 Cloudwatch , CloudTrail, Config다. >주로 모니터링 하는 것은 성능, 애플리케이션 문제점, 보안 문제점, 로그 이벤트, 리소스 인벤토리 관리 등이 있다. CLoudTrail >이벤트란 IAM유저, 사용자가 리소스에 대해 행한 액션이다. 이러한 이벤트(읽기 / 쓰기)를 기록하고, 액션의 종류, 영향을 받는 리소스와 리전, 액션을 위한 사용자, 액션이 취해진 시기등 상세한 내역을 수집하고 기록한다. 이러한 이벤트를 유형에 따라 관리 이벤트, 데이터 이벤트로 분류해 저장한
SNS(Simple Notification Service)
특정 리소스에 값이 들어왔을 때 사용자는 값이 들어왔다는 것을 어떻게 인지하며, 다른 서비스로 옮길 수 있을까? 이것을 가능하게 해주는 것이 SNS다. SNS > SNS는 일종의 게시판이라 생각하면 간단하다. AWS리소스의 대부분은 SNS로 데이터를 전송할 수 있다. 데이터를 받은 게시판(SNS)는 자신을 구독하고 있는 서비스에게 알림,데이터 전송을 할 수 있다. SNS 구독자 SNS를 구독할 수 있는 구독자는 위의 그림처럼 총 6가지이다. 구독하는 방법에는 Topic Publish와 Direct Publish 두가지가 있다. > T
CloudWatch
서비스간,네트워크간의 트래픽의 흐름, 즉 로그를 파악하기 위해 AWS CloudTrail,CloudWatch,Config 세가지의 서비스를 지원한다. 이번 포스팅에서는 그 중 CloudWatch에 대해서 다루어 볼 예정이다. 추가로 EventBridge에 대해서도 다루어 볼 것이다. CloudWatch > AWS리소스의 메트릭스(지표)를 수집하고 수정,시각화 하는 서비스이다. 모든 리소스는 CloudWatch로 자신의 매트릭스를 전송하며 , 매트릭스는 CPU활성화율, S3버킷용량,EBS의 IOPS, DynamoDB의 읽기/쓰기 용량등이 있다. CloudWatch는 이 메트릭스를 수집해 특정 조건을 만족하면 CloudWatch Alarms을 통해 알람을 울리고 알람에 해당하는 액션을 수행할 수 있다. CloudWatch Metrics CloudWatch는 EC2와 같은 AWS리소스에서 매트릭스(지표)를 수집해 이것을 통해 알람과 액션을 한다. 이러한 매트릭스는 CloudWa
Kinesis
저번 포스팅에서는 루스커플링 원칙에따라 여러컴포넌트로 나눈 마이크로서비스에서 각 컴포넌트가 서로 통신할 수 있게 해주는 SQS에 대해서 다루어 보았다. 이번 포스팅에서는 마이크로서비스간 실시간으로 데이터를 수집하고 데이터를 다른 컴포넌트에 전달해주는 역할을 하는 Kinesis에 대해서 다루어보겠다. Kinesis > Kinesis는 보다 '실시간' 이 중점인 서비스이다. 스트리밍 데이터의 수집,처리,저장,전송을 위한 서비스이며 오디오,비디오,로그등 다양한 데이터를 매우 빠른 속도로 처리할 수 있다. 이전에 다룬 SQS와 Kinesis는 컴포넌트간의 통신에 있어서 유사한점이 많다. 그렇다면 차이점은 무엇이 있을까? SQS : 단기간의 데이터 , 경량의 데이터 , 하나의 컨슈머를 대상 Kinesis : 장기간의 데이터, 대규모의 데이터, 다수의 컨슈머를 대상 Kinesis Video Streams > 다양한 스트리밍 비디오 데이터를 거의 무한대로 처리할 수
SQS(Simple Queue Service)
애플리케이션을 개발하는 개발자는 루스커플링이라는 설계 원칙을 이용해 어플리케이션의 확장성과 신뢰성을 높인다. 루스커플링이란 불필요한 요소를 최소화해 하나의 서버에서 실행하는 단일 어플리케이션을 구현하되 어플리케이션 안에는 여러 컴포넌트들이 존재하는 마이크로서비스로 세분화 하는 것이다.마이크로서비스의 각 서비스들은 각기 다른 서버에서 실행된다. 그렇다면 이 각각의 서버는 어떻게 서로 소통할 수 있는걸까? 이것을 가능하게 해주는 것이 바로 SQS이다. SQS > 마이크로서비스, 즉 여러 서비스(서버,컴포넌트)들이 서로에게 메세지를 전송할 수 있도록 돕는 관리형 메세지 서비스다. 메세지 처리속도가 매우 빠르며, 고가용성 및 고탄력성이다. 큐 > SQS에서 처리해야 할 메세지를 담는 공간이 Queue다. 쉽
IAM(Identity and Access Management)
지난 포스팅에서는 트래픽의 유출과 유입을 어떻게 통제하는지에 대해서 다루어 보았다. 하지만 누구에게 접근권한을 주고 누구에게는 권한을 주지않고를 어떻게 선택할 수 있는지 궁금할 것이다. 이번 포스팅에서는 신분기반 정책을 통해 어떤 방식으로 접근을 제어하는지 알아볼 것이다. 신분기반 정책 VS 리소스 기반 정책 >접근을 제어하는 방식에 AWS는 크게 두가지 정책이 있다. 바로 신분기반 정책과 리소스 기반 정책이다. 신분기반 정책 : 내가 접근 권한을 부여하는 대상이 누구인지 알며, 대상의 숫자가 많지 않을 때 사용한다. 📌 IAM이 대표적이다. 리소스기반 정책 : 만약 인터넷에서 익명으로 접근하는 대상이라면 대상이 누구인지 알고 권한을 증명하는 신분증을 줄 수 있겠는가, 이렇게 대상이 불문명하며, 일일이 신분증을 다 부여할 수 없을 정도로 매우 많은 대상이 접근한다면, 리소스 기반 정책을 사용한다. 📌 S3 : 버킷정책 , KMS : 키정책 , SNS
Security Group VS NACL
저번 포스팅에서 AWS의 네트워크 VPC에 대해서 알아보았다. 하지만 서브넷간의/인스턴스간의 트래픽의 유출/유입에 대해서 어떻게 원하지않는 트래픽을 거부하고 원하는 트래픽만 허용하는지 궁금할 것이다. 이번 포스팅에서는 트래픽의 유출과 유입을 통제하는 보안그룹과 NACL을 다루어 볼 것이다. Security Group >보안그룹은 방화벽과 같은 역할을 하며 ENI에 부착되어 인스턴스 의 트래픽의 유출과 유입을 통제한다.모든 ENI에는 최소 하나 이상의 보안그룹이 연결돼야 하고, 여러개의 보안그룹이 하나의 ENI에 부착될 수도 있고, 하나의 보안그룹이 여러 ENI에 부착될 수 있다. 📌 보안그룹은 다른 보안그룹을 포함하는, 즉 다른 보안그룹 규칙을 포함한 새 보안그룹을 만들 수 있는데 이것은 네트워크 계층간 트래픽 출입 통제에 있어서 가장 유연하고 안전한 방식이다. ENI 
NAT 디바이스 , Bastion Hosts, VPC 엔드포인트
이전 포스팅에서 VPC에 대해서 다루어보면서 프라이빗 서브넷은 인터넷 연결이 안되기때문에 외부에서도 접근할 수 없지만, 내부에서도 외부로 나갈수가 없다고 설명했다. 하지만 인터넷 연결을 해야하는 상황이 있다면 어떻게 해야할까? 이번 포스팅에서는 이것을 가능하게 해주는 기술들을 다루어 볼 예정이다. Bastion Hosts > 프라이빗 서브넷에 있는 인스턴스는 외부에서 접근이 안된다. 인터넷에 연결되어 있지 않기 때문이다. 그렇다면 왜 프라이빗 서브넷에 인스턴스를 프로비전 하는걸까? 이유는 보안수준이 높아야하는 기업같은 경우는 퍼블릭 서브넷에 배치하면 누구나 접근이 가능해지기 때문이다. 그렇다면 이 프라이빗 서브넷에 접근이 불가능한 걸까? Bstion Hosts를 사용하면 프라이빗 서브넷에 있는 프라이빗 인스턴
VPC(Virtual Private Cloud)
VPC >VPC는 EC2의 네트워크 계층이며 EC2인스턴스를 비롯한 여러 AWS서비스에 네트워크 리소스를 담을 수 있는 가상 네트워크이다. 이름에서도 알 수 있다시피 가상 네트워크이므로 기존의 전통적인 네트워크 방식과 달리 물리적 하드웨어를 추가하지 않고도 네트워크를 확장할 수 있다. CIDR블록 > Classless Inter Domain Routing(이하 CIDR)은 VPC내 할당되는 IP주소의 범위를 나타내며 IP주소의 개수라고 생각하면 된다. 프리픽스 '/'로 표기한 빗금문자 표기법으로 IP주소의 개수를 나타내는데 예를들어, 172.16.0.0/16은 172.16.0.0 ~ 172.16.255.255를 나타낸다. 프리픽스길이를 N이라 했을 때 IP주소의 개수는 2의 (32-N)승이다. 즉, 프리픽스의 길이와 IP주소의 개수는 역의 관계를 가진다. 📌IPV4의 프리픽스 길이는 /16~/28까지 가능하다. 보조 CIDR블록 사용자는 할당한
비관계형 DB(NoSQL)
지난 포스팅에서 관계형DB에 대해서 포스팅했었다. 이번에는 비관계형DB에 대해서 다루어보겠다. 비관계형 DB(NoSQL) >비관계형 DB는 말그대로 관계가 없는 즉 SQL처럼 순서대로 저장후 이 순서에서 관계가 있는 구조화가 아닌 비구조화 DB이다. 하지만 모든 데이터가 나름의 구조를 갖고 있기 때문에 다중 구조라 함이 좀 더 옳은 표현 같다. NoSQL은 관계형 + 비관계형 데이터 둘다 저장 가능하다. 💡 Schema의 유연성을 가진다. ex) 당장 무슨 DB를 쓸지모르고 추후에 DB를 바꿀 예정이라면 비관계형 DB를 사용해야한다. 초당 100밀리초 이하의 처리량을 가진 매우 빠른 성능을 가진다. 400KB이하의 데이터를 저장해야 효율적이다. 📌 400KB이상의 데이터도 저장할 수 있지만 성능이 낮아진다. 따라서 문서나 이미지와 같은 큰 용량을 가진 콘텐츠는 저장하기 적합하지않다. 데이터 정렬/조회 비관계형은 관계형과 다르게 스키마가 없다는 것이고
Data Base
데이터베이스는 관계형,비관계형 데이터베이스 두가지가 있다. 이번 포스팅에서는 관계형 데이터베이스에 대해서 다루어 볼 예정이다. 관계형 데이터베이스 > 최소 하나 이상의 테이블을 가지고있고 테이블은 Columns과 rows로 이루어져있다.칼럼은 속성, 로우는 레코드로 보면 될거같다. 칼럼은 순서에 따라 조직화되고 이러한 순서가 결국 구조화를 이루는 것이다. 이 순서안에서 속성 간 관계를 알 수 있고 따라서 우리는 SQL(Structured Query Language)라 부른다.순서,즉 관계가 구조화 되어있기 때문에 저장 및 관리 작업이 쉬워지고 복잡하고 임의적인 쿼리도 가능하다. OLTP : Online Transaction Processing, 빈번한 읽기 및 쓰기 작업이 요구되는 애플리케이션에 적합하며, 접근 중심의 작업에 용이하다. 따라서 대용량에 데이터에 신속한 접근을 위해 높은 수준의 메모리 용량을 지닌다. OLAP : Online Analytics Proce
Redshift vs EMR vs Athena
지난 포스팅에서 스토리지의 종류중 객체 스토리지, 블록스토리지에 대해서 다루어 보았다. 오늘은 마지막 칼럼형 스토리지 Redshift에 대해서 다루어보고 이와 비교되는 EMR, Athena에 대해서 다루어 보겠다. Redshift > OLAP(online analytical processing) 데이터베이스 기반의 고성능 컴퓨팅 파워가 요구되는 복잡한 쿼리를 위해 여러개의 데이터베이스를 쌓아서 하나의 큰 데이터베이스, 즉 '데이터 웨어하우스'다. 칼럼단위로 데이터를 저장하는 칼럼형 스토리지 로도 불린다. 컴퓨트 노드 Dense node 마그네틱 스토리지에 최대 326TB의 데이터 저장 SSD에는 최대 8192TB의 데이터 저장 leader node 하나 이상의 컴퓨트 노드가 있는 경우 이 노드들의 커뮤니케이션을 조정하고 클라이언트와 소통하도록 할 수 있게 해주는 Node 데이터 분산 유형 EVEN,KEY,ALL EVEN : 리