AWS - Cloud Basic Theory, VPC

클라우드란?

IT 서비스를 인터넷을 통해 접근해서 사용하는 데에 On-Demand 방식(원하는 만큼 그때그때 필요할때마다 가져감)을 사용한다!

Public Cloud	모두와 공유해서 사용
Private Cloud	내부망, 이해관계자들끼리만 사용 (범위 ↓ ), 사내 안에 클라우드 올려서 ERP를 가동 등
Hybrid Cloud	전용선, VPN 등 이용하여 외부에 공개하기 어렵지만 외부와 내부를 섞어서 사용할 때
Multi Cloud	여러가지 여러 서비스를 연동할 필요성 (AWS 쓰다가 구글에 있는 서비스 사용하고 싶을 때)

-AWS Region

1. AWS 서비스 제공되는 물리적 위치

2. 전세계적으로 36개의 region으로 분리+구성

3. 리전마다 서비스를 구분하기 위해 고유 코드(식별 번호) 존재

- 코드: 지역+지리적 위치+순번

ex) ap-northeast-2 // ap: asia pacific

-AWS Availability Zones (가용 영역, AZ)

1. Region에 배치된 하나 이상의 데이터센터 그룹

2. 1개의 Region에는 최소 3개 이상의 AZ 구성

3. 1개의 AZ에는 1개 이상의 데이터 센터로 구성

4. 각 가용 영역은 상호 100 km 내외의 거리를 이격하여 구성 -> 재해, 재난에 방지하기위한 목적!!

- 가용영역 간 네트워크는 전용선으로 연결

5. 가용영역 구분을 위한 고유코드 존재

-코드: 지역+지리적 위치+순번+가용영역 코드

ex) ap-northeast-2a

-ARN (Amazon Resource Name): 서비스를 고유하게 식별하기 위해서 부여하는 네이밍 컨벤션

Partition - Service - Region(Region code) - Account_id - Resource_type - Resource_id

만약에 region이 서울(내가 사는 곳)이 아니라면?미국 시민들을 대상으로 했을 때 접근 용이성을 위해 미국을 region으로 설정하기도 (+이중화 목적도 있음)

-시스템 개발환경 분류

Code → → → → →
Local : 개발자 한 명 한명의 환경	Dev : 동료들이 만든 코드를 확인(테스트)하기위해 만든 환경	Staging : 운영환경(Production)이랑 99% 동일하게 만들어 놓음 // 1%는 데이터가 다름!!	QA : 품질 점검, 권한/로그/명령어 들을 확인	Production : 고객들이 실질적으로 접근할 환경, DEV와 달리 보안이 중요시 됨
← ← ← ← ← Data

*IAM (Identity and Access Management, AWS에서 매우 복잡한 것...)

: 누가 특정 서비스에서 접근할 수 있는가/없는가를 관리해줌

누가 (Identity - 보안주체/Principal)

- Root User (디폴트로 만들어지는 유저): 모든 권한 있음, 초기 설정 후 사용하지 않는 걸 권장 (계정 탈취당하면 애써 만든게 다 사라지기 때문+과금), 이메일 정보가 id값이 됨

- IAM User: 루트 유저로 생성됨. 생성 -> ID와 PASSWORD 발급되고 이걸 통해 접근, 장기자격증명(id와 password 자체가 장기적으로 바뀌지 X -> IAM Role과 구별됨)

- IAM Role: 부여된 권한만 행사, 임시자격증명(API 던졌을 때 응답받은 ID와 PASSWORD가 매번 바뀜, expire time이 지나서 바뀜 // 토큰 개념)

세션 - 서버 중심의 인증 방식, 클라이언트가 값을 받으면 서버에서 관리토큰 - 클라우드 중심의 인증 방식, 마패 같은 개

+ 추가적으로 IAM User는 1:1 매칭, IAM Role은 1:N 매칭

그리고 AWS API 통해 접근하는데 이 API는 신원 정보 증명이 된 사람들이 정보를 줌.

근데 내 계정으로 만든 ROLE에는 접근할 수 있으나 다른 사람 계정으로 만든 ROLE에 접근할 순 없음!!

- AWS Service

: 사용자 대신 작업 수행 -> 근데 권한이 없으면 EC2 같은 서비스가 내 계정으로 만든 버킷을 다른데로 푸쉬할 수 있음!!

따라서 권한 부여 필요!!

Secret Key: 텍스트로 된 키값을 api 방식으로 리소스를 관리

-IAM은 json 구조의 정책(Policy) 문서를 기반으로 사용자의 권한을 관리한다.

-Root User MFA 설정, Password Policy 설정, 대체 연락처 설정, Admin User 생성 이런건 Root User가 하고 나머지 작업들은 IAM USER가 할 것!!

-실습

AWS IAM 콘솔에서 사용자 생성 (이메일로 넣으면 이메일로 접속되나 root 계정일지는 모름)

AdministratorAccess 로 정책 연결

사용자 생성

액세스 키 생성 (태그값 굳이 할 필요 X, 그리고 키 값은 따로 적어놓거나 CSV 파일 받아놓기)

그리고 cmd 창에서 aws configure 통해

액세스 키 및 비밀 액세스 키 집어넣고

지역: ap-northeast-2 (서울)

output format: json

aws s3 ls 했을 때 명령어가 먹힌다. (버킷이 없으니 null값이 뜨는 거임)

access denied 뜨는 경우 있는데 -> 이건 권한 정책 (AdministratorAccess 설정안해서 뜨는 거임!!)

aws iam user 리스트 테이블 보여주기 및 iam-user-2 생성

-Network Baseline

네트워크 3가지 포인트

1. Segmentation - 네트워크를 어떻게 분리할 것인가: CIDR, Public&Private

2. Connectivity - 서비스를 어떻게 연결/연동할 것인가: IGW, Nat Gateway(내부->외부), VPN, Peering, Endpoint ...

3. Security - 보안그룹, Network-ACL , VPN ...

IP Address: 인터넷에 연결된 장치를 식별 가능하게 해주는 고유 주소

Classful 할당 방식보다 IP주소를 더 효율적으로 사용하기 위해 CIDR 통해 네트워크 주소와 호스트 주소 구분

사설 IP대역 (충돌 x)

10.0.0.0 ~ 10.255.255.255

172.16.0.0 ~ 172.31.255.255

192.168.0.0 ~ 192.168.0.0

공인 ip주소의 경우 ip 충돌일어남

-VPC (Virtual Private Cloud): 나의 네트워크를 만드는 서비스

1. 외부와 격리된 가상의 사설 네트워크

2. CIDR 최소 /28 ~ 최대 /16

3. 최대 5개 생성 가능

4. 한 번 설정한 VPC CIDR 수정 불가능

5. Secondary CIDR Block 통해 네트워크 확장 -> 최대 5개

Internet Gateway	NAT Gateway
내-외부 통신	내부 -> 외부 통신 O & 외부 -> 내부 통신 X (단방)
1개	여러 개 생성 가능

-VPC (Virtual Private Cloud) 실습

VPC , 서브넷 그리고 라우팅 테이블 생성

서브넷의 경우,

01은 ap-northeast-a

02는 ap-northeast-b로 연결

퍼블릭 서브넷에 인터넷 게이트웨이 연결 (VPC에 연결하지 않으면 인터넷 게이트웨이 눌렀을 때 안 )

NAT 게이트웨이는 퍼블릭 서브넷에 생성해야만 한다!! (이건 주의)

프라이빗1 라우팅 테이블에 NAT 게이트웨이 연결

다시 한 번 작성하지만 *NAT 게이트웨이 경우

퍼블릭 서브넷에서 생성하여 프라이빗 라우팅에서 nat게이트웨이를 연결해야 한다!!

그리고 순서도 중요하다. 인터넷 게이트웨이 생성안 된 상태에서 NAT 게이트웨이 생성하면

계속 pending상태가 나서 에러날 수 있다. (IGW 생성한 후 NAT GW 생성하기!!)

=> IGW가 생성되어있고 라우팅 테이블에 퍼블릭 서브넷이 잘 되어있어야 프라이빗 넷 안에 있는 리소스들에게 IP를 잘 할당할 수 있다!!

-NACL (Network Access Control List)

:일종의 방화벽

적용대상은 서브넷

	NACL	보안그룹 (Security Group)
적용 대상	서브넷	EC2가 갖고 있는 네트워크 인스페이스 카드 (ENI)
	인/아웃바운드 트래픽을 allow/deny(기본)	기본 정책은 all deny (모두 차단)
	Stateless -> 인/아웃 바운드 트래픽을 정책을 통해 들어오고나서 내보냄	Statefull -> 인/아웃 바운드 트래픽을 정책을 통해 들어오면 저장해놓음