[하나 디지털파워온] AWS 공인교육 필기 (1)

• 클라우드 컴퓨팅 : IT 리소스를 서비스처럼 사용하여 작업을 진행

=> CSP(Cloud Service Provider): AWS / GCP / Azure / KT / Naver...

=> MSP(Managed Service Provider): MZC(교육 제공 등 csp랑 협업관계)

• 온프레미스 : IT 리소스를 직접 소유한 상태로 작업을 진행(데이터 센터나 서버실 구축 등으로 클라우드랑 반대되는 과거 개념)

<고객이 AWS로 이전하는 이유>

• 물리적 작업 신경쓸 필요가 없다
• 접근하고 싶어도 물리적으로 접근할 수 없다
• AWS가 데이터 센터 위치를 공개하지 않는다(보안상)
• 클라우드를 사용한다고 해서 무조건 비용이 절감되는 것은 아니다. 잘 써야 한다.

<AZ-Availability Zone(가용 영역)>

• 하나 이상 묶어서 관리 = AZ
• 각각 AZ 센터들은 고속의 광케이블로 빠르게 연결 가능
• AZ가 모여서 가장 큰 지역적인 거점인 region을 이루고 있다
• 가장 작은 단위 : datacenter
• region 규모에 따라서 AZ 갯수가 다르다
• 자원이 올라간 Region 정의
• AZ : 피해 발생되지 않도록 서로 떨어져 있다, 독립적인 구성, 자연재해 등으로 피해가 발생하더라도 동시 장애 발생X
• Multi - AZ(중복해서 두 개 이상 배치하는 것으로 비용증가가 됨)

<리전 선택에 영향을 주는 요소>

• 거버넌스(0순위) : 법적 문제, 고객들의 개인정보가 담겨있는 데이터 주권 문제, 처리 데이터에 문제가 없는지, 그 지역에 보관
• 지연 시간 : 최종 사용자와 가까운 지역을 선택하는 것이 중요하다, 신규 서비스가 배포된다 → 동시에 모든 리전에 일괄적X
• 서비스 가용성 : 사용자 수요가 많은 쪽으로 서비스가 넘어온다(있는 지역을 택해야 한다), 신규 서비스
• 비용 : 똑같은 서비스라 할지라도 리전마다 비용이 다르다

<엣지 로케이션>

• CDN : CloudFront, 동영상, 이미지 컨텐츠
• route 53 : DNS service(본인 근처에서 빠르게 ip를 알아올 수 있게 함)
• 넷플릭스 서버가 미국에 있다면? 모두 미국 서버에 오게 되면 멀면 멀수록 속도가 느려진다! 서버가 감당이 되지 않는다!

<AWS Local Zones 및 엣지 로케이션 기능>

• local : 작은 출장소 개념
• 엣지 로케이션 : 캐싱 역할

<AWS Architect>

• aws 환경 위 infra 구축→자가 체크 리스트 : 모범 사례 기반으로 잘 만들어진건지에 대한 진단 리스트
• 보안 : 인증, 권한 부여가 철저히 주어져야 한다, 어떤 직원이 쓸 수 있는지? 최소한의 권한만 주어져야 한다. 보안 제어가 많으면 사용이 어려워지기에!
• 비용 최적화 : 요금제 다양, 비용 관련된 서비스 체크할 수 있는 질문
• 안정성 : 고객들에게 안정적으로, 이중화 잘하고 있는지, offscaling으로 고객 몰렸을 때 서버 다운되지 않고 확장될 수 있는지
• 성능 효율성 : 데이터베이스의 광경/비광경(고급 기술의 대중화)
• 운영 우수성 : 인프라 만들 때 수동X, 자동화! 파이프라인으로 작은 단위를 빠르게 반복적으로 하고 있는지
• 지속 가능성 : 환경적 문제, 탄소배출, 재생 에너지, 클라우드를 통해서 환경 문제 고려하고 있는지 체크

백서 진단 가능 or well-architected tool로!

<AWS 서비스에 연결>

• 반복적인 작업을 처리하는 명령어로 스크립트 작성
• 파이썬, 자바 등이 요청을 해야 한다. 사람이 만든 application 코드를 이용해서 작업
• 사람이 아닌 해당 코드가 요청을 해서 aws cloud이용할 수 있도록(주로 개발자들이)
• (실습 1) 엉뚱한 리전을 선택하면 안되고 맞는 리전을 꼭 선택해야 함

<계정 보안>

• 계정은 목적에 따라 여러 개 만들 수 있음 규모가 클수록 더 많이
• 루트 사용자 = AW Account : 처음 가입할 때 나오는, 보안이 좋지 않음
• IAM 사용자 : 제한된 작업만 할 수 있도록 권한 부여, 본인 부여 권한만으로만!(직원들마다 다 따로 만드는 게 더 좋음)
• AWS Identity and Access Management (IAM)
  • authentication
  • authorization
• 사용자마다 고유한 아이디와 패스워드가 존재 (or key), 사용자마다 권한 부여
• IAM 사용자 이용해서 접근 통제
• 사용자 자격증 : hard coding 권장X →대체할 수 있는 것 IAM role
• AWS계정 루트 사용자 : 보안상 위험하다 → 루트 사용자 아래에 IAM 계정 주기
• 관리 콘솔로 클릭 or 프로그래밍 방식으로
• 키가 노출되지 않는 게 중요
• IAM 정책을 사용하여 권한 설정 : 감사자는 권한 선택적 부여, 업무에 맞는! 최소 권한만 준다 그러나 업무가 힘들다 보안을 위해서 감수를 해야 한다
• IAM 사용자 그룹 : 사용자를 그룹으로 묶어서 권한 부여, 사용자에게 따로 권한 부여하지 않아도 된다, 사용자 한 명이 여러 그룹에 포함될 수 있음
• IAM 역할 : 사용자에게 부여된 정책 고정되어 있음. 고정된 권한 아니라 잠깐동안만! 분석 관련 권한+개발 관련 업무(역할 만들고 개발 관련 권한 부여, 역할을 쓰게 되면 원래 없던 권한을 잠깐 쓸 수 있다), 고정된 권한+일시적 권한 부여(모자(=IAM ROLE)쓰기)
•  

• access key / secret access key
• 패더레이션 사용자 : AWS가 아닌 별도 인증 체계, 별도 인증 서버 인증하지 않아도 쓸수 있게 할 수 있다
•  

• 위 그림은 자격 증명 기반 정책
• 우리가 허락하는 범위 안에서만 우리 자원을 쓸 수 있다 - 교차 계정
• 필요할 때마다 역할을 수임해서 작업 가능하게 할 수 있다!
• 관리자 권한 주고 싶으면 권한 부여 하고 필요할 때마다 사용
• 정책(policy)
  • 권한 부여
    • IAM 자격 증명 기반 정책(누군지에 따라 권한 부여)
    • IAM 리소스 기반 정책 : 정책을 서비스 자원 자체에 ‘누구만 할 수 있어’라고 부여(특정 서비스와 자원) ; 리소스 기반 정책이 사용 가능한 자원이 몇 개 있다 (다되는거 아님)
  • 최대 권한 설정 : 통제 가능
    • IAM 권한 경계
    • AWS Organizations 서비스 제어 정책(SCP)
  •  자격 증명 기반 정책 예제
    • Version : 문법이 정해진 날짜
    • effect: 허락할지 거부할지(허락 = allow, 거부 = deny) (언급조차 안하면→ 암시적 거부) (허락 거부 둘다→거부)
    • resource : 어떤 자원을 대상으로? 그 인스턴스만 키거나 끄게할 수 있다
    • condition : 조건문, owner=사용자 이름

심층 방어

• 정책들이 중간 중간에 걸려 있으면 한 번에 다 모아놓고 같은 수평선에서 명시적 거부X, 나머지 허용된 것은 하면 된다