AWS Solutions Architect 교육과정 1일차 정리

본 글을 2015년 한국 AWS에서 교육받은 내용을 메모해 뒀던 글을 다시 정리하여 올린 글입니다.
2015년 교육 자료이므로 현 시점(2019년)과는 차이가 있을 수 있습니다.
용어, 한글표기 등은 시간 관계상 맞추지 않았습니다.

개요

• 클라우드 마이그레이션 고려
  • 한 번에 마이그레이션 하지 않고
  • 초기 마이그레이션 대상을 다른 아키텍처 목표를 고려하여 신중하게 결정
  • 전부 마이그레이션 불가
• 클라우드 적용 프레임워크
  • bit.ly/AWSCAF 백서 볼 수 있음
  • 7가지 관점
• AWS 모범사례
  • 장애를 고려한 설계 및 무장애
  • 느슨한 결합
  • 탄력성
  • 모든 계층의 보안
  • 제약 걱정 말자
  • 병렬
  • 다양한 스토리지 옵션
• 기술스택 대응
  • 네트워크 보안 스토리지 컴퓨팅 콘텐츠전송 데이터베이스 로드밸런싱 조정 DNS 분석 메시징 캐싱 아카이브 이메일 자격증명관리 배포 관리모니터링
• 책임분담모델
  • 아마존이 일부 책임을 진다
  • 예) 보안그룹(Security Group)을 관리하는 것은 아마존 역할, 보안규칙 수립은 사용자의 역할
• 리전
  • 리전별 지연시간, 비용, 기능, 법적규정준수가 다름
  • 중국이나 Gov의 경우 관리 콘솔을 비공개되어 있음
• 가용영역(AZ)
  • 물리적으로 격리, 그러나 전용선으로 연결되어 딜레이가 거의 없음
  • 한 리전은 최소 2AZ 보유
  • 고가용성을 위해 최소 2AZ사용을 권장
• 글로벌 서비스
  • 리전 없음
  • IAM Route53 CloudFront
• AZ 서비스
  • EC2 EBS ENI Subnet
• 리전 서비스
  • 나머지 서비스들은 모두 리전 기반
• 엣지 로케이션 : 빠른 속도를 위해 고객근처에 시스템 구축
  • CloudFront Route53
• ARN (Amazon Resource Name)
  • 자원의 고유 이름
• AWS는 API기반 서비스
  • 계정에서 생성한 모든 리소스는 해당 계정에서 소유 - 해당 계정을 삭제할 경우 소유된 리소스 모두 삭제됨
• IAM을 통해서 계정 제어
  • Root를 사용하지 않고 그룹과 사용자를 만들어 사용
  • 외부사용자(Federation)를 추가하여 외부ID로도 일부AWS 서비스를 사용가능하게 설정 가능
  • 애플리케이션의 인증용이 아니라 AWS관리용으로만 사용해야함
  • IAM 사용자/그룹 : long term credential
  • IAM Role : short term credential, 사람뿐 아니라 개체나 애플리케이션이 가질 수도 있음
  • IAM Policy : ARN으로 대상 자원 지정 가능, 명시적 거부 - 명시적 허용 - 기본적으로 거부 순으로 허용 평가
  • STS(Security Token Service): 임시적으로(지정한 기간동안) 기능을 허용해주는 일회용 접근키를 제공하는 웹서비스
• 지식 확인(발표자료 확인)
  1. a c e
  2. a c e
  3. b (run이 새로 만드는 것임, 시작은 start)
  4. c

VPC(Virtual Private Cloud)

• VPC의 구성요소들 별 특징
  • CIDR을 통해 IP대역 지정 : 반드시 사설 IP대역을 쓰고, bit수는 16에서 28까지 가능 (즉, 16~65536개의 IP를 가질 수 있음 = EC2가 최대 65536대까지 가능하다는 뜻)
  • VPC는 리전기반 - EC2는 AZ기반 : 그래서 VPC에 Subnet(AZ기반)을 만든 후 EC2등록
  • Subnet의 크기는 상황에 맞게 적절하게 생성 (VPC는 bit 16을 대부분/ Subnet은 20(1024대)정도가 적절)
  • Subnet에는 (Subnet CIDR개수 - 5)개만큼 EC2 생성가능 (나머지는 관리용, 255는 broadcast용)
  • Subnet은 기본적으로 외부와 차단되어 있음
  • Subnet간에는 CIDR이 중첩되어서는 안됨
  • Internet Gateway를 생성하여 Subnet에 붙여야 함
  • VPC 뿐 아니라 Subnet은 각각 기본적으로 Routing Table을 갖고 있음 (VPC의 기본 R/T덕분에 Subnet간에는 아무설정 없이 네트워크 연결이 되어있음)
  • 신규 Routing Table을 만들어 치환해주어야 함
  • VPC아래에 달려있는 Route table, Security Group등은 해당 VPC에 종속됨. 다른 VPC에서 재사용 불가
  • Subnet은 가능한 적게 사용하는게 좋고, Subnet은 모두 동일한 특성이지만, Route Table을 통해 특성이 달라짐
• 보안 관련 속성
  • 보통 엔터프라이즈VPC는 퍼블릭/프라이빗/보안 3가지 서브넷을 구성
  • 퍼블릭은 IGW를 통해 인/아웃바운드 액세스하기위한 라우트테이블 필요
  • 프라이빗은 잠재적 아웃바운드를 위해 NAT/프록시 에 대한 라우트테이블이 필요
    • 기타: 라우팅 테이블에 한 주소를 여러곳으로 매핑 불가
  • 보안은 외부 액세스 절대 불가
  • NAT는 Network Address Translation 임 : Subnet의 EC2인스턴스로 존재하기 때문에 i-0000과 같은 id 가짐
  • NAT는 보안관련이므로 SecurityGroup(SG)설정 필요 : SG는 기본 disallow이므로 allow할 것들을 CIDR또는 다른 SG를 통해 지정할 수 있음
  • 내생각 : SG는 필터역할도 하지만 내보내는 트래픽의 식별자가 되기도 하는 것 같음
  • 예상 문제 : RT, SG, IP Table설정을 다했지만, EC자체의 방화벽을 disable해줘야 함
  • 추가: S3같은 서비스는 사실 IGW밖에 있지만, 요구사항이 많아 endpoint를 내부에 둘 수 있음
  • 단일 앱의 경우 VPC내에 서브넷으로 분할해야함..멀티 VPC는 비추
  • VPC를 안전하게 보호하기 위해서는 RT,SG,NACL을 관리해주면 좋음. 보통 NACL은 안쓰던데 쓰는걸 권장
    • NACL은 상태비저장(들어가거나 나갈때 매번 체크)
    • SG는 상태저장(들어온 트래픽을 기억해서 나갈때는 패스)
    • NACL은 아무나 수정 못하게하고, 최소한으로 단순하게 유지
  • VPC Peering은 다른 계정간에도 가능하지만 같은 리전이어야 하고 IP대역이 겹치면 안됨
    • 피어링은 1:1로만 되기 때문에 간접으로 되지 않음 Star로 연결 구성해야함
    • 양쪽 계정이 허용해야 함, RT/NACL모두 가능
  • AWS와 프라이빗 네트워크 연결 가능 : 빠르고, 비용이 절감되고 보안이 높음 : Amazon Direct Connect
  • 리전이 다를 경우 ADC를 사용하기도함
  • 기본 VPC는 리전당 1개 존재하는데 삭제는 가능한데 생성은 불가하므로 가급적 삭제하지 말자
  • 계정당 VPC 5개 limit이 있는데 더 만들고 싶으면 고객센터
  • VPC에 flow log를 볼 수 있음
  • NAT는 반드시 퍼블릭 서브넷에 있어야 하고, 로드밸런서가 퍼블릭에 있으면 웹서버는 프라이빗에 있어도 됨
  • NACL은 단순하게! SG가 복잡하면 성능 저하 발생(막 200개) -> 인스턴스 자체 방화벽을 사용하는 것도 방안
    • 키포워딩 기능이 있으므로 베스쳔서버에 키페어를 보관하지 마세요

EC2

• EC2 인스턴스 관련 기본 정보
  • AMI : 사전 정의된 OS 설치된 구성
  • 인스턴스
    • T2 1credit(1분) : (T2.micro의 경우 12점, 하루 2시간 burst가능) credit이 0일경우 적립 크레딧 만큼의 %로 CPU를 사용함 T2.micro의 경우 12/60 이므로 20%
    • 조언 : 쓸데없이 사용량을 예측해서 사이즈를 결정하지 마라, 걍 작게 쓰다가 필요해지면 키우면 됨 (EC2 일시 stop후 업그레이드 하고 start)
    • T2일경우 다른 level일때 CPU갯수만 다를뿐 성능은 동일
    • M4 : 가장 일반적
    • C4 : 계산 전용
    • X1 : 특수용 SAP등… 신청후 사용
    • R3 : 메모리 특화
    • G2 : 고성능 그래픽카드 내장 : 랜더링, 인코딩 등..
    • I2 : 스토리지 최적화 : 하둡 용
  • EC2 하이퍼바이저
    • 인스턴스 스토어 : EC2껏다켜면 인스턴스가 바뀜(데이터 날아감), EC2내부에서 reboot할 경우에는 괜찮음(인스턴스가 안바뀌니깐)
    • 인스턴스는 완전히 격리됨
• EC2에 연결된 자원들
  • 스토리지
    • 인스턴스 스토리지(로컬 스토리지)는 보통은 없고 비싼데 붙어있음, 인스턴스 내부에 존재
    • EBS는 인스턴스와 별도 구성(네트워크IO로 연결됨)
      • 조심할 것 : 인스턴스 중지-시작 과 종료는 다름. 즉, 종료시엔 EBS가 삭제될 수 있지만(설정), 중지한다고 EBS가 삭제되진 않음, (단 중지-시작 시 인스턴스 스토리지는 삭제됨(RAM같은느낌,휘발성))
      • 기본 설정으로 EC2종료시 EBS도 삭제하게끔 설정되어 있으므로 이 설정을 꺼야 EBS를 유지할 수 있음
    • EC2와 EBS는 같은 AZ에서만 가능. EC2가 다른 AZ의 EBS를 볼 순 없음(EBS를 공유하기 위해선 다른 우회책을 사용해야함 ex)S3 동기화 또는 EFS사용)
    • EBS를 AZ간 이동도 불가(이동하려면 snapshot을 S3에 받은 후 복사해서 옮겨야함)
    • 가격이 S3 *3 = EBS, EBS *3 = EFS
  • EC2를 AZ간 옮기려면 AMI로 만든 후 옮겨야함. 리전간 옮기려면 AMI를 만든 후 S3로 복사 후 이동
  • GET http://169.254.169.254 인스턴스 정보를 확인할 수 있음 : 자체적으로 볼 수 있는건 별로 없음 (하이퍼바이저에게 정보를 요청하는 것임)
  • ENI : 랜카드라고 보면 됨 eth0이 기본
    • ENI당 MAC이 하나가 할당됨 : 보통 라이선스 때문에 MAC이 여러개 필요할 경우 사용
    • ENI당 여러 IP할당 가능(고정(EIP)/유동 관계없음)
    • ENI를 서브넷 간에 공유가능(왠지는 모른다고함) 그러나 같은 AZ여야함, AZ간 공유 불가
      • 마찬가지로 VPC간 공유 불가 (참고 VPC는 리전서비스, 서브넷은 AZ서비스)
    • SG설정 가능
• EC2 활용 방법
  • EC2끼리 트래픽이 많다면 Placement Group이란걸 쓰세요.
  • 보안상의 문제일때만 dedicated구성(가상화지만 다른 고객이 끼어들지 않음)을 쓰세요. 성능은 차이없음
  • EC2호스팅 전용 서비스 진짜로 물리적으로 독립 구성 (그러나 베어메탈은 아님)
  • AMI
    • Fully Baked Image : AMI에 풀 세팅 해둠 빠르지만 바꿀때마다 생성해야함
    • Partially Baked Image : 부트스트랩으로 설정됨
  • 인스턴스 내부 방화벽도 적절히 활용(iptables)