1주차 필기

content/ghktndyd/1주차/섹션3.md

@@ -0,0 +1,20 @@
+AWS는 리전, Availabilty Zones(가용 구역), 데이터 센터, 엣지 로케이션, 전송 지점이라는 개념이 존재
+
+리전은 전세계에 존재하고, 각각의 리전들은 네트워크로 연결되어 있다. 각각의 리전에는 AZ 라는 가용 영역이 존재한다.
+
+리전에는 이름이 있다. us-east-1 등등
+
+리전은 데이터센터의 집합
+
+리전을 선택하는 기준
+1. 법률 준수: 각 나라의 사용자 정보들은 그 나라의 리전에 있는 게 좋다.
+2. 지연 시간: 가까운 리전을 선택해야 지연 시간이 줄어든다.
+3. 리전에 서비스 존재 여부: 모든 리전이 모든 서비스를 가진 건 아니다.
+4. 요금: 각 리전은 요금이 다 다르다.
+
+가용영역은 리전 내에 존재한다. 보통은 3개 최대는 6개
+리전은 코드가 존재한다. ap-southeast-2a 등등
+각각의 가용영역은 하나 또는 두 개의 데이터센터로 구성된다
+
+전송지점 (엣지 로케이션)
+엣지 로케이션은 전세계에 많다. 즉, 세계 어디서 AWS의 서비스를 이용하든지 전송 지점이 많기에 지연시간이 줄어든다.

content/ghktndyd/1주차/섹션4.md

@@ -0,0 +1,114 @@
+## IAM
+
+- IAM: Identity and Access Management의 약자
+
+- 루트 계정은 계정 생성 당시에만 사용해야 한다.
+
+- 그룹 별로 나눠서 권한 관리를 해야 한다.
+
+- 한 사용자는 여러 그룹에 속할 수 있으며, 그룹에는 그룹을 포함할 수 없다.
+
+- IAM의 권한 정책은 JSON 문서로 정의할 수 있다.
+
+- AWS에서는 최소 권한의 원칙을 준수하며 관리해야 한다. (필요한 권한만 주자)
+
+- IAM은 글로벌 서비스 (리전 필요 X)
+
+### IAM 정책
+
+- IAM 정책은 그룹 단위로 설정 가능하고, 개인 단위로도 설정 가능하다. 개인 단위 설정을 인라인 설정이라고 한다.
+- AWS에서는 Json 문서 형태로 정의한다.
+	- IAM 정책 구조 요소는 정책 버전을 포함한다.
+	- 정책 식별 ID도 존재하지만 선택사항이다.
+	- **effect**: 특정 API에서 접근하는 것을 허용할지 안 할지를 선택한다.
+	- **principal**: 특정 정책이 적용될 사용자, 계정, 혹은 역할로 정의된다.
+	- **action**: effect 기반으로 허용 및 거부 될 api의 목록이다.
+	- **resource**: 적용될 action의 목록이다.
+	- condition: 언제 정책이 실행될지 정의한다.
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": "*",
+            "Resource": "*"
+        }
+    ]
+}
+
+%%AWS에서 "`*`" 은 모든 것을 의미%%
+%%위 권한은 모든 것을 허용한다는 의미다.%%
+```
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": [
+                "iam:GenerateCredentialReport",
+                "iam:GenerateServiceLastAccessedDetails",
+                "iam:Get*",
+                "iam:List*",
+                "iam:SimulateCustomPolicy",
+                "iam:SimulatePrincipalPolicy"
+            ],
+            "Resource": "*"
+        }
+    ]
+}
+%%`Get *`: Get Api들은 모두 허용%%
+```
+
+### IAM 방어 정책
+
+- IAM을 방어하는 첫번째 방법은 비밀번호 설정이 있다.
+- IAM 권한 유저들이 비밀번호를 변경 가능하거나 불가능하게 설정 가능하고, 비밀번호의 변경 주기, 혹은 재사용 가능 여부도 설정 가능하다.
+
+- IAM을 방어하는 두번째 MFA다.
+- MFA는 Multi Factor Authentication이다. 다중 인증
+- AWS에서는 필수이며 사용이 매우 권장된다.
+- MFA는 알고 있는 비밀번호와 보유한 장치를 같이 써서 보안을 강화한다.
+- 이점은 비밀번호를 도난 당하거나 잃어버려도 해커가 나의 물리적 장치를 소유하지 않으면 무용지물이란 것이다.
+- MFA 장치
+	- 1. **가상 MFA 장치** (여러 유저 소유 가능)
+	- 2. 유니버셜 세컨드 팩터 (여러 유저 가능)
+	- 3. 하드웨어 보안 토큰
+
+### Access Keys
+- SDK나 CLI를 써야 한다면 액세스 키를 발급 받아야 함
+- CLI = Command Line Interface
+- CLI를 쓰면 AWS 서비스에 바로 접근 가능하고, 스크립트로 일부 작업을 자동화 가능
+- 때문에 관리 콘솔을 대신하여 사용하기도 한다.
+
+### 클라우드쉘
+- 서울 리전에서는 사용 불가능, 사용하려면 도쿄에서 하자
+- 안 써도 그만
+
+### IAM Roles (역할)
+- AWS 서비스들 중 몇 가지는 우리 계정에서 실행해야 한다.
+- 마찬가지로 어떤 권한이 필요하다. 이 권한을 위해서 IAM Role이 필요하다.
+- 이것은 사람이 사용하도록 만든 게 아니고 AWS 서비스에 의해서 사용되도록 만들어졌다.
+- 예를 들어서 EC2 인스턴스에서 어떤 작업을 실행하기 위해서는 **권한**이 필요한데, 이때 **이 권한이 IAM Role**이다.
+
+### IAM 정책 보안 보고서
+- 계정에 대한 정보를 확인 가능
+- 비밀번호를 안 바꿨거나, 사용하지 않는 계정을 찾아내는데에 매우 유용
+- Access Management 에서는 내 사용자들이 AWS의 어느 서비스에 접근했는지 알 수 있다.
+
+### IAM 모범 사례
+- 루트 계정 사용하지 않기
+- AWS 유저 = 실제 사람 1명
+- 보안이 그룹 수준에서 유지되도록 하자
+- MFA 사용하기
+- AWS 서비스에 권한을 부여할 땐 IAM Role을 사용하자
+- 액세스 키는 개인만 알자
+- Credential Report로 사용하지 않는 계정이나 보안이 취약한 계정을 관리하자
+
+```
+IAM 정책은 시드, 효과, 원칙, 조치, 리소스, 조건으로 구성된다.
+버전은 IAM 정책 자체의 일부이고, 문장의 일부가 아니다.
+```

content/ghktndyd/1주차/섹션5.md

@@ -0,0 +1,128 @@
+### 예산 설정
+- 돈이 너무 많이 나오지 않도록 설정
+### EC2
+- Elastic Compute Cloud의 약자
+- AWS의 Infrastructure as Service (IAAS) - 이아스라고 발음
+- EC2는 하나의 서비스가 아니다. 여러 개의 서비스를 포함하고 있다.
+- 가상머신을 EC2에서 임대하면 그게 **EC2 인스턴스**
+- 데이터를 **EBS**에 보관 가능
+- **ELB**로 로드밸런서 역할 가능
+- **ASG**로 오토 스케일링 가능
+- Linux가 제일 인기 많음
+- 원하는대로 컴퓨팅 사양을 설정하여 EC2 대여 가능
+- EC2 부팅할 때 자동화 하는 작업 = 부트스트래핑 (설치, 실행 등)
+- **여기서 스크립트는 시작할 때 한 번만 실행**
+- EC2 스크립트의 모든 명령문은 sudo로 실행 (루트 계정)
+
+### EC2 인스턴스 유형
+- 7가지가 있음
+	- 범용 (general purpose)
+	- 컴퓨팅 최적화 (compute optimized)
+	- 메모리 최적화 (memory optimized)
+	- 가속화된 컴퓨팅 (accelerated computing)
+	- 스토리지 최적화 (storage optimized)
+	- HPC 최적화 (HPC optimized)
+	- 인스턴스 기능 (instance features)
+	- 인스턴스 성능 측정 (measuring instance performance)
+
+```
+m5.2xlarge
+- m은 인스턴스 클래스 (m이라면 범용)
+- 5는 세대 (5세대)
+- 2xlarge (인스턴스 크기)
+```
+
+#### 범용
+- 웬만해서는 다 잘 어울림
+- 클래스 코드: `t`, `m`
+
+#### 컴퓨팅 최적화
+- 배치 처리와 같은 일괄 처리
+- 미디어 트랜스 코딩, 고성능 웹서버, HPC, 머신러닝, 게임 서버
+- 클래스 코드: `c`
+
+#### 메모리 최적화
+- 대규모 데이터셋 처리할 때
+- 고성능이 필요한 관계형 DB, 비관계형 DB 서버, 분산 웹 스케일 캐시 저장소로
+
+#### 스토리지 최적화
+- 로컬 스토리지에서 대규모 데이터셋 처리시
+- Redis 같은 메모리 DB의 캐시나 데이터 웨어하우징과 같은 분산 파일 시스템
+
+### 보안 그룹
+- EC2 인스턴스 안팎으로 트래픽이 허용되는 방식을 제어
+- 허용 규칙만 포함
+- IP를 기준으로 설정
+- 보안그룹은 서로 참조 가능
+- 보안그룹은 **EC2의 방화벽**
+- 보안그룹은
+	1. 포트의 허용을 규제함
+	2. 승인된 IP 범위를 보여줌 (IPv4인가 IPv6인가)
+	3. 인바운드 네트워크 제어 (외부에서 인스턴스로)
+	4. 아웃바운드 네트워크 제어 (인스턴스에서 외부로)
+
+- 기본적으로 모든 아웃바운드는 열려있다.
+- 하지만 인바운드는 보안그룹에서 허용하는 IP와 포트로 요청이 들어와야 한다.
+- 하나의 인스턴스는 여러 개의 보안그룹을 가질 수 있다.
+- 보안그룹은 리전과 VPC로 통제된다. 이 말은 리전 변경시 새로운 보안그룹을 생성해야 하거나 VPC를 생성해야 한다.
+- 보안그룹은 EC2 외부에 있다.
+- SSH 액세스를 위한 보안그룹은 따로 유지하는 것이 좋다.
+- **만약 타임아웃으로 애플리케이션에 접근이 안 된다면 보안그룹 문제일 가능성이 높다.**
+- 하지만 연결이 거부됐다는 응답은 보안그룹을 통과했지만 애플리케이션에 문제가 발생했을 가능성이 높다는 뜻
+
+### 클래식 포트
+- 22: SSH
+- 21: FTP
+- 22 SFTP
+- 80: HTTP
+- 43: HTTPS
+- 3389: RDP
+
+### EC2 인스턴스 옵션
+- 그 동안은 AWS의 온디멘드 인스턴스를 썼다.
+- 만약 오래 쓸 거라면 Reserved 인스턴스가 있다. 기간은 1년 또는 3년이다.
+- Convertible Reserved Instance도 있다. 쓰다가 전환하고 싶으면 이걸 쓰자.
+- Savings Plans는 달러 단위로 특정 사용량을 정의해서 쓴다.
+- Spot Instance는 짧게 쓸 때 쓰자.
+- Dedicated는 전용 인스턴스가 필요할 때
+
+#### 온디멘드
+- 온디멘드는 1시간 이후에 초단위로 비용 발생
+- 돈 많이 듦.
+
+#### 예약 (Reserved)
+- 온디멘드에 비해서 72% 할인
+- 특정한 인스턴스 타입을 예약한다.
+- 부분 선결제, 전부 선결제, 선결제 없음 중 선택 가능
+- 데이터베이스 같은 거 할 때
+- 전환형 예약 인스턴스도 있음
+
+#### 절약 (Saving)
+- 온디멘드에 비해 70% 할인 가능
+- 시간당 10달러
+- 1년, 3년 택
+- 사용량을 초과하면 온디멘드로 바뀜
+
+#### 스팟 (Spot)
+- 온디멘드에 비해 90% 할인
+- 최대 가격 지정하고, 그 가격이 넘어간다면 인스턴스가 초기화 됨..
+- 배치 작업, 데이터 분석, 이미지 처리 등에 사용
+- 중요한 작업을 쓰는 인스턴스로 쓰지 말 것
+
+#### EC2 Dedicated Hosts (EC2 전용 호스트)
+- 실제 데이터센터 내의 물리적 서버 하나 임대
+- 전용 호스트 사용시 준수 요건을 쉽게 달성하고, 서버 결합 소프트웨어 라이센스의 사용이 가능
+- 3년 계약
+- 제일 비쌈
+
+#### EC2 Dedicated Instances (전용 인스턴스)
+- 전용 하드웨어에서 실행되는 EC2 인스턴스
+- 같은 계정의 다른 인스턴스와 하드웨어 공유
+- 인스턴스 배치에 통제권 없음
+- 전용 인스턴스는 나만의 인스턴스를 나만의 하드웨어에 갖는다.
+- 전용 호스트는 하드웨어 서버 하나를 다 갖는다.
+
+#### EC2 용량 예약
+- 용량을 예약하는 게 유일한 목적
+- 용량을 예약하면 실행 안 해도 요금 청구
+- 단기적인 워크로드를 갖고, 특정 AZ에 있는 작업에 유용

content/ghktndyd/1주차/섹션6.md

@@ -0,0 +1,63 @@
+### 공용 IP (Public) vs 사설 IP (Private)
+
+- 네트워크는 IPv4, IPv6로 나눠짐
+- IPv4는 온라인에서 많이 쓰임, IPv6는 사물 인터넷에서 많이 쓰임
+- 공용 IP는 서로의 공용 IP로 통신할 수 있다.
+- 사설 네트워크는 사설 IP로 통신하는데 사설 IP는 범위가 존재한다.
+- 사설 네트워크 내의 모든 컴퓨터들은 사설 IP로 통신한다.
+- 공용 게이트웨이인 인터넷 게이트웨이를 쓴다면 사설 네트워크의 컴퓨터들도 다른 서버들과 통신 가능하다.
+- **공용 IP가 있다면 모든 인터넷 통신 가능하고, 사설 IP로는 사설 네트워크 내에서만 액세스할 수 있다.**
+
+- 공용 IP는 인터넷 상에서 유일해야 한다.
+- 사설 IP는 오직 사설 네트워크 안에서만 유일하면 된다.
+- 두 개의 사설 네트워크는 두 개의 똑같은 사설 IP가 있을 수 있다.
+- 사설 IP가 외부로 통신하려면 인터넷 게이트웨이 같은 장치가 필요하다.
+- **인스턴스의 고정 IP를 쓰려면 탄력적 IP가 필요하다.**
+- 계정당 탄력적 IP는 5개까지 쓸 수 있다.
+- 탄력적 IP는 사용하지 않는 게 권장된다.
+- 대신 공용 IP를 써서 DNS 이름으로 통신하는 게 좋다. (Route53에서 가능)
+- 나중에는 로드밸런서로 공용 IP를 아예 사용하지 않을 수도 있다.
+
+- EC2 기기에 SSH를 할 땐 공용 IP만 사용 가능
+- EC2를 껐다가 키면 IP가 변경될 수 있다.
+
+### 배치 그룹 (Placement Groups)
+
+- EC2 인스턴스가 AWS 인스턴스에 배치되는 전략을 설정
+- 세 가지 전략이 존재
+    - **클러스터 배치 그룹:** 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화
+    - **분산 배치 그룹:** 인스턴스가 다른 하드웨어에 분산 (Critical Applcations)
+    - **분할 배치 그룹:** 인스턴스를 분할하는 것과 유용하게 파티션을 분리함.
+
+#### 클러스터 배치 그룹
+
+- **모든 EC2 인스턴스가 같은 가용 영역**
+- 모든 인스턴스 간에 초당 10Gb의 대역폭 확보
+- 이 말은 즉 성능이 좋음
+- 하지만 가용 영역에 장애 발생시 모든 EC2 인스턴스가 장애가 발생
+- 빅데이터 작업 등 지연시간이 매우 짧아야 하는 작업
+
+#### 분산 배치 그룹
+
+- 실패 위험 최소화
+- 모든 EC2 인스턴스가 각기 다른 하드웨어
+- 장점은 여러 가용 영역에 걸쳐 있기에 동시 실패 위험이 적음
+- 단점은 배치 그룹의 가용 영역당 7개의 인스턴스로 제한된다.
+- 가용성을 극대화하고, 위험하지 않아야 하는 애플리케이션에서 사용
+- **배치그룹 당 가용 영역의 인스턴스 수는 7개임을 기억**
+
+#### 분할 배치 그룹
+
+- 여러 가용 영역의 파티션에 인스턴스를 분리
+- 가용 영역당 최대 7개의 파티션
+- 각 파티션에는 EC2 인스턴스가 존재할 수 있음
+- 각 파티션은 AWS의 랙인데, 파티션이 많으면 인스턴스가 랙 실패로부터 안전하다.
+- 각 파티션을 실패로부터 격리된다. 즉 파티션 하나가 다운되더라도 다른 파티션은 정상
+
+### Elastic Netword Interfaces (ENI)
+
+- VPC의 논리적 구성 요소이자 가상 네트워크 카드
+- ENI가 EC2 인스턴스에 접근하도록 해줌
+- ENI는 주요 사설 IPv4와 보조 사설 IPv4를 가질 수 있다.
+- EC2에 얼마든지 보조 IPv4를 추가 가능
+- ENI에 하나 이상의 보안그룹 설정 가능