21년 11월 8일 ~ 9일 양일간 온/오프라인으로 진행된 AWS Cloud Practitioner Essential 교육 과정에 참여 후 정리한 내용입니다.
평소 EC2 인스턴스를 만들거나 클라우드 서비스를 사용할 때 명확한 이해 없이 사용하게 되는 상황이 답답하던 찰나에 좋은 교육을 들을 기회가 있어 참여하게 되었습니다. 교육을 들으면서 궁금하고 관심 있는 부분이 있어 추후에 더 공부하고 자세한 내용을 포스팅하려 합니다 :)

모듈 01 - AWS 소개 (aws.amazon.com)

1. 여러 클라우드 컴퓨팅 배포 모델

1. 올인클라우드 : 클라우드에 모든 서비스가 올라가있음
2. 온프레미스 : 프라이빗 클라우드
3. 하이브리드 : 클라우드 기반 리소스를 온프레미스 인프라에 열결, 클라우드 기반 리소스와 레거시 IT애플리케이션을 통합

2. AWS 의 이점

1. 가변비용

2. 비용 최적화 (데이터 센터 직접 운영하지 않기 때문)

   관리적인 비용을 줄일수있는 여러 요소들 존재

3. 용량 : 서버 성능 바로 업그레이드, 다운그레이드 가능 (인프라 구현 시 용량 추정 필요 없음)

4. 규모의경제

5. 속도 및 민첩성 : 몇 분 만에 전 세계에 배포

3. AWS 핵심 서비스 범주 : 하위서비스들의 묶음 (180개 정도)

1. 컴퓨팅 : EC2
2. 네트워킹 및 콘텐츠 전송
3. 스토리지 : S3 (vs https://youtu.be/-AwLsUuzgLw (Cloudflare의 R2))
4. 데이터베이스 : RDS
5. 보안,자격증명, 규정 준수 : IAM
6. 관리 및 거버넌스

모듈 02 - 클라우드 컴퓨팅

1. Amazon Elastic Compute Colud (Amazon EC2)

• 인스턴스 (가상의 서버) - 온프레미스 환경이 아닌 일회성 자원
• 완벽하게 세팅된 서버를 백업해서 보관 → 필요시에 운영

2. EC2 인스턴스 유형

• 인스턴스 타입 - cpu 개수, 메모리 크기, instance storage 등 이미 만들어놓은 사양 중 선택 (선택하는 서버의 스펙) configure security group : 방화벽 자동 생성
  

1. 범용 : 메모리, 컴퓨팅, 네트워킹 리소스 균형있게 제공
2. 컴퓨팅 최적화 : CPU 성능 업그레이드 되어있음(고성능 프로세서 제공에 적합)
3. 메모리 최적화 : 메모리 용량이 큼 (고성능 DB에 적합)
4. 액셀러레이티드 컴퓨팅 : 그래픽카드 달려있음, 머신러닝 (암호화폐에는 적합하지 않음)
5. 스토리지 최적화 : 분산 파일 시스템 및 데이터 웨어하우징 애플리케이션, 고성능 DB에 적합

3. Amazon EC2 요금

우분투 등 라이센스 비용 없는 os : 초단위로 계산

윈도우 등 라이센스 비용 있는 os : 시간단위로 계산

• 온디맨드 요금제 (테스트 환경) : 초기 선결제 비용이나 최소 약정 없음, 불규칙한 단기 워크로드에 적합
  
• 스팟 요금제 (단기 서비스) : 유휴자원 줄이는 방안, 할인비율 최대 90%(보통 50~60%), 변동폭을 가지는 시세가 있고, 시세에 해당하는 만큼 비용 (유휴자원이 부족할때 스팟 인스턴스 꺼짐, 인스턴스 중지 못함) (머신러닝 학습시킬때 활용 가능)
  
• 예약, compute savings plans (장기 서비스, 지속) : 장기간 계속 켜져있어야하는 경우
  
• 전용 인스턴스, 전용 호스트 점유 가능, 내가 만든 인스턴스들만 올라가있음 전용 호스트 : 나에게 특정 물리적 서버가 할당됨 (호스트 고정되어야 할 경우)
  

4. Auto Scaling

AWS 사용시 미리 용량을 확보할 필요가 없음 → 필요에 따른 즉각적인 공급 조정(인스턴스 추가, 제거)

1. 동적 조정 - 모니터링 결과에 따른 조정 (관리자 x , 인프라가 알아서 조정)
2. 예측 조정 - 과거 트레픽 보고 머신러닝 분석, 패턴에 따라 스케줄링 걸기 등

5. Elastic Load Balancing

처리해야되는 작업에 대한 균형을 맞춰줌

워크로드의 크기는 동일하게 유지, 자동으로 트레픽 분산시켜줌

Auto Scaling 그룹에 단일 접점 제공

(인스턴스 추가시 할당되는 IP 주소를 다 DNS 설정해야함 → load balancers DNS name 으로 접근하면 해결가능. load balancers 주소를 DNS 서버에 등록시켜놓으면 됨. 추가된 인스턴스 알아서 인식→ 트레픽 분산시켜줌,어떤 ip 주소가 할당되는지 신경안써도 됨.)

클라우드 워치 : 모니터링 서비스

6. 메시징 서비스

• 모놀리식 애플리케이션 아키텍쳐 (전통적)
• 마이크로서비스 : 기능 하나하나가 분리, API 이용해서 서로 호출하며 통신. 특정 기능에 문제가 생기더라도 나머지 기능은 문제 없음. 관리하기, 확장하기 편함. (비동기방식으로 통신)

1. SNS : 게시/구독 서비스. 주제 만들고 메세지를 받을 구독자 지정. 게시자가 주제를 올리자마자 구독자에게 메세지를 뿌려줌. (모바일푸시, 이메일 등)
2. SQS : 구성요소 간에 메세지를 잠시 보관해주는 queue 역할. 누적되어 처리속도가 느려지거나 장애가 생길시 auto scaling을 걸어 해결 가능

7. 서버리스 컴퓨팅 서비스

내가 소유하고 내가 관리해야하는 서버가 없음 (AWS 가 대신 관리해줌)

• AWS Lambda 개발자가 코드만 잘 개발하고 언제 실행되는지만 지정해주면 끝. 내가 원하느 코드가 원하느 시점에 정확하게 실행 됨. 코드가 실행 안되면 비용이 안듦 (쓴만큼만 정확하게 계산) 트리거 : 코드를 실행시켜주는 주체 ex. 트리거를 S3 서비스로 지정하면 S3 파일이 업로드 되자마자 만들어둔 코드가 실행
  1. lambda 에 코드 업로드
  2. 이벤트 소스에서 트리거 되도록 코드 설정
  3. 코드는 트리거될떄만 실행됨
  4. 사용한 시간에 따라 비용 지불

8. 컨테이너 서비스

서비스가 커질수록 컨테이너의 수도 늘어나 관리가 불편해짐.

오케스트레이션 서비스 : 컨테이너 기술 관리 자동화

ex) kubernetes , ECS(AWS 자체 컨텐츠), EKS (kubernetes이용한 AWS서비스)

• AWS Fargate (ECS, EKS 를 사용하여 서버리스 컨테이너 실행)

컨테이너는 대응 속도 빠름, 갑자기 컨테이너가 많이 만들어져야하는경우 지연 생김, fargate는 이런 문제 해결. aws 가 대신 관리.

모듈 03 - 글로벌 인프라 및 안정성

• 리전 선택 : 어떤 리전에 리소스를 만들거냐 (25개)

데이터 거버넌스 및 법적 요구 사항 준수 → 고객과의 근접성(네트워크상 느려지지 않는 범위내에서)→ 리전 내에서 사용 가능한 서비스 → 요금(리전마다 요금 상이) 등을 고려.

가용영역을 고려하지 않아도 되는 서비스가 있음 ex) S3 가용영역을 고려하는 서비스 ex) EC2

가용영역 별로 거리가 있음, 리전간에 가용역역을 여러개 만들어 놓음 : 서비스의 안정성을 위해

1. Cloud Front

엣지 로케이션

2. Outposts

AWS 인프라 및 서비스를 온프레미스 데이터 센터로 확장

서비스 사용시 물리적 서버가 회사 데이터 센터에 설치됨.

3. AWS 서비스와 상호작용

API 호출로 AWS 서비스 요청하는 것

먼저 AWS Management console : 제한이 있음

AWS CLI(client line interface)

모듈 04 - 네트워킹

Network VPC

Subnet

고객이 접근하는 서버(웹 서버)와 아닌 서버(내부의 어플리케이션 서버, DB 서버)가 분리되어야 함. ⇒ VPC

1. Amazon Virtual Private Cloud (Amazon VPC)

VPC 안에 subnet 만들어야함. - 실제 네트워크

• 인터넷에서 접근 가능한 subnet : public subnet
• 인터넷에서 접근 불가능한 subnet : private subnet

→ public, private subnet 자체가 필요한지(어떤 종류의 네트워크가 필요한지, 트래픽이 제어 기능이 필요한지) 부터 판단하여 생성.

VPC 만들고 → subnet 생성 → public/private 유형 선택 (언제든 변경 가능)

라우팅 테이블 게이트웨이 등록되어 있으면 public subnet (고객대응 지원 웹사이트 지원, 대중이 엑세스 할 수 있어야 하는 리소스가 포함되어있음)

라우팅 테이블을 수정(게이트웨이 정보 등록)하는 방식으로 관리.

• private-public인지 확인하는 방법은 라우팅 테이블을 확인 하는 것
• vpc 만든다고 게이트웨이 자동으로 만들어지는 것 아님, 따로 만들어서 붙여주는 작업 필요
• default vpc : 기본으로 만들어져있는 vpc, 네트워크이긴 하지만 서비스할때 계속해서 쓸수있는 네트워크 아님.
• 네트워크는 탄력성 없음. 변경 안됨.

2. subnet 만들기

1. vpc 선택
2. 이름 정하기
3. 가용영역 선택
4. private - public (gateway 필요) 선택

이름으로는 public-private 구분할 수 없음. 라우팅 테이블 확인해야.

igw : 게이트웨이 public.

임시로 public → private 바꿀 수는 있음. (일반적 방법은 아님, NAT 지정해주기)

VPN 연결 (인터넷 게이트웨이가 vpn 환경 지원 x → 가상 프라이빗 게이트웨이 따로 붙여야함)

3. Direct Connect

하이브리드 컴퓨팅 구성시 vpn 영향력 낮아짐. 온프레미스 데이터 센터와 vpc 간 전용 연결 설정

로드밸랜서는 디도스 공격에 대한 대응능력도 높음.

→ 퍼블릭으로 하는것보다 로드밸랜서 이용해서 프라이빗으로 만드는게 보안성을 위해 좋음

4. 네트워크 액세스 제어 목록 (ACL)

상태 비저장 패킷 필터링을 수행

아웃바운드 규칙을 기준으로 심사 (양방향, 번거로움)

5. 보안그룹

인스턴스에 접근하는 트레픽 필터링

보안그룹은 상태 저장 패킷 필터링 수행 (들어오는 패킷에 대해 내린 이전 결정 기억)

기본 설정 : 아웃바운드 트래픽 허용 + 인바운드 트래픽

6. DNS

DNS 할당이 되더라도 매우 복잡함. (IPv4)

Amazon Route53 : 아마존에서 제공하는 DNS 도메인 구입/등록 서비스

CloudFrount : 접근하는 위치에 따라 가장 가까운 엣지 로케이션으로 라우팅

ex. 200개 이상의 서버가 있는 경우, 고객과 가장 가까운 걸로 라우팅

별칭 지정 → 라우터53에 등록 : 지정한 도메인으로 고객들 들어오기 가능

모듈 05 - 스토리지 및 데이터베이스

1. 블록 스토리지

1. 인스턴스 스토리지(스토어) : 성능이 월등히 좋음, 휘발성 저장공간

   인스턴스가 올라가있는 실제 서버에 장착되어있는 스토리지를 가상화시켜서 바로 쓰는 것.

   가상화를 하기 때문에 100%는 아니지만 거의 100% 가까이 스토리지의 성능

   하드디스크 or SSD 로 만들어져 있음.

   중지시 백업한후 내려오고 재시작하면 원래 서버에 돌아가지 않을 확률이 높아 데이터도 함께 휘발. (따로 비용 없지만 인스턴스 비용에 포함됨)

   • 스토리지 처리 성능이 좋아야 하는 경우
   • 원본 데이터가 없어도 되는 경우

2. EBS 볼륨 : 하드웨어를 가상화 시켜서 쓰는 방식이 아닌 스토리지 관리 서비스가 따로 있어서 요청한 만큼 따로 할당됨. 인스턴스와 네트워크로 연결됨. 직접 장착이 아님. 하드웨어 성능을 직접 가져다 쓰는것이 아님.

• 백업기능 (스냅샷) : 증분 백업 형태로 제공
• 특정 볼륨을 백업하고 싶으면 create snap shot
• 스냅샷으로 백업되면 S3에 저장됨 (어디저장되는지는 모름)

인스턴스를 만들때 팬딩(보류단계) : 요청한 인스턴스가 올라갈수있는 호스트를 찾는 단계 , 중지시키면 내려오고 시작하면 다시 찾음. 원래 있던 서버에 올라가지 않을 확률이 훨씬 더 큼.

2. 객체 스토리지 : 웹 하드 서비스 ⇒ S3

각 객체는 데이터, 메타데이터, 키로 구성

객체 형태로 관리, 동일한 레벨에서 관리가 됨. 파일 사이즈, 업로드 개수 제한 없음.

내구성 좋음, 삭제, 수정 전까지 손상될 가능성 없음.

http https 프로토콜 사용

객체 데이터에 대한 url이 개별적으로 생성됨. url을 가지 모든 사람이 데이터에 접근 가능.

1. 객체를 버킷에 저장

   버킷은 이름 중복 안됨. 파일 업로드 하게되면 url 생성됨.

2. 객체에 대한 엑세스를 제어하는 권한을 설정

   정책을 이용한 접근제어 등

3. 다양한 사용사례에 맞는 일단의 스토리지 클래스 중에서 선택

• S3 스토리지 클래스 (어떤 패턴으로 쓰고 있는지, 클래스 마다 저장비용 요청비용 달라짐)

  1. 스탠다드 (요청비용 더 저렴)

  2. 스탠다드-IA (Infrequent Access) (저장비용 더 저렴)

     1. 접근 자주 안할때 저렴하게 사용
     2. 데이터 얼마나 많이 전송했냐
     3. 얼마나 많이 요청했냐

  3. S3 One Zone-IA

     1. 가용영역 하나만 이용해서 데이터 저장. 내구성이 낮아짐
     2. 데이터에 접근할수없는 순간이 생길 수 있음

  4. Intelligent-Tiering

     엑세스 패턴을 알아서 판단하여 스탠다드와 IA를 변경

  5. Glacier 요청 처리비용 굉장히 비쌈. 저장 비용 굉장히 저렴

     (ex. cctv )

  6. Glacier Deep archive 기가바이트당 1원 정도

3. 파일 스토리지 (EFS)

: 트리가 길어질수록 느려짐. 파일 만들수 있는 개수의 제한 있음. = 공유파일 시스템

EBS는 인스턴스 전용의 스토리지임

FSx : 윈도우용 공유파일시스템, 사용하기 까다로움..

4. AWS 데이터베이스 (RDS)

관계형 데이터베이스를 꼭 써야하는지 먼저 생각해보기

관계형(SQL) vs 비관계형(noSQL) → 테이블 하나로 처리 가능하다면 비관계형 고려 의미가 있음.

비관계형 : 가격대비 성능 뛰어남

인스턴스를 만들엇 모든것을 다 하면 내 마음대로 할수 있음

RDS를 사용하면 관리작업을 AWS 해줌.

Aurora는 mySQL, postgre보다 성능이 월등, 라이센스 비용 없게 하고 싶어서 AWS에서 개발

5. Amazon DynamoDB

: 간편하게 이용 가능

서버리스 : 내가 관리하는 서버가 없음

6. DMS(database migraton service)

많은 부분을 마이그레이션 해줌

모듈 06- 보안

1. 공동책임 모델

AWS가 관리하는 영역이 있고 고객이 해야하는 영역이 구분되어 있음

→ AWS가 소유하고 있기 때문에 마음만 먹으면 접근하지 못하는 것이 없다.

고객 : 클라우드 내부 보안

• 인스턴스 운영 체제
• 호스트 기반 방화벽
• 애플리케이션
• 계정 관리
• 보안 그룹

AWS : 클라우드 자체 보안

⇒ 기능 및 정책의 설정은 고객이, 기능, 정책의 관리와 보안은 AWS가 관리해줌

2. IAM (Identity and Access Management)

요청이 들어오면, identity 확인 및 권한 관리 후 요청 처리

행동할수있는 범위 지정

이메일로 로그인시 계정 : root → 계정 이용하지 마세요 (권한 제어가 안되기 때문, 여러명 공유 x)

1. 계정 생성 직후 IAM 사용자를 만들기

2. 적절하고 필요한 권한 주기

3. 루트는 곧바로 로그아웃 후 사용자로 작업하기

   특정 작업에 맞는 권한을 가진 사용자를 생성 (IAM 정책 문서, json 형태, 만들기 어려움. )

= 최소권한 원칙

익숙치 않을때는 사용자를 만들고 admin 권한을 주고 그걸로 사용

• IAM 사용자 사람/서버/어플리케이션일 쓸 수 있음. 정책 문서를 생성, 만들어진 정책 문서를 사용해도 됨. (ex. json 포멧) effect 허용/허용x, action: 어떤 요청을 허용할지 resource : 대상 (버킷)
  
• IAM 그룹 IAM 사용자의 모음 그룹 이용하면 권한 관리가 간편해짐. 구성원은 그룹에 할당된 정책을 상속함.
  
• IAM 역할 : 권한을 주는 또다른 방법 (추가가 아닌 역할 전환) 임시권한 부여 기능 제공 (시간 조건이 들어감) 사용자를 이용해서 권한을 줄 때. 서버리스 컴퓨팅에서 람다에 올려둔 코드에 권한이 필요할때 사용자가 아니고 역할을 통해서 권한을 줌.
  
• Multi-Factor Authentication 계정에 추가 보호 계층을 제공 권한 많은 사용자 MFA 걸어둬야 훨씬 더 안전함.
  

3. AWS Organizations

계정 관리를 잘해도 문제가 생길 수 있음.

Organizatons을 활용해서 여러 AWS 계정을 통합 관리 해줌

4. SCP

: 루트 계정들의 권한을 통합 관리할 수 있음.

AWS 인증 받은 부분은 중복 인증 하지 않아도 됨

5. WAF

규정 준수 서비스 Web Applicaton File, 웹 어플리케이션 방화벽은 웹 서비스와 주고 받는 HTTP 트래픽을 필터링, 모니터링 및 차단하는 특정 형태의 애플리케이션 방화벽

6. DoS DDoS 공격 방어 AWS Shield 서비스

• Shield ADvanced 무료 아님 한달에 3000달러

7. KMS (key management service)

• 암호화 할때 사용하는 키 관리
• 키에 필요한 특정 수준의 액세스 제어를 선택할 수 있음.
• 어디에 보관해야하나

8. Amazon GuardDuty

제품 및 서비스에 대한 지능형 위협 탐지 기능

모듈 07-1 모니터링 및 분석

1. Amazon CloudWatch

• 대시보드 기능 사용, 단일 위치에서 리소스의 모든 지표에 액세스

2. AWS CloudTrail (기본적으로 활성화, 요금은 안나옴)

• AWS 환경 전체에서 발생하는 모든 사용자 작업 및 API 요청을 추적할 수 있음

3. AWS Trusted Advisor

모듈 08 - 요금 및 지원

모듈 09 - 마이그레이션 및 혁신

1. Cloud adoption Framework

비즈니스 역량 + 기술 역량

• 마이그레이션 전략

1. 리호스팅 : 있는 그대로 , aws의 성능이나 비용을 이용할 수 없음.
2. 리플랫포밍 : (lift, tinker and shift) 옮긴 후 수정 (유지 , 사용중지)
3. 리팩터링 : 전체를 다 뜯어고치는 재구성. → 서버리스 컴퓨팅 !
4. 재구매 : 기존 라이선스를 SaaS로 전환.
5. 유지
6. 사용중지