행위

AWS 클라우드 서비스 이해와 활용

라이언의 꿀팁백과

1 1일차[편집 | 원본 편집]

NDS는 AWS와 네이버 클라우드(Naver Cloud Platform)를 통해 서비스를 제공함


1.1 책임공유모델[편집 | 원본 편집]

Amazon Web Services 와 Customer 사이의 책임공유모델(Shared Responsibility Model)이 있음


Shared Responsibility Model.png

1.2 IAM 나는 😊[편집 | 원본 편집]

Identity and Access Management. AWS에 대한 리소스를 안전하게 제어할 수 있는 서비스.


1.2.1 계정 구성[편집 | 원본 편집]

Root user 와 IAM user 로 나누어짐


1.2.2 IAM 그룹[편집 | 원본 편집]

필요한 권한 그룹을 만들어서 사용자에게 부여함


IAM Group.png

1.2.3 IAM Policy[편집 | 원본 편집]

IAM 정책은 아래와 같은 목록으로 정의가 되어있음


IAM Policy.png

1.2.4 IAM Policy 구조[편집 | 원본 편집]

아래와 같이 Key-Value 형태로 되어있음


IAM Policy 구조.png

1.3 Region[편집 | 원본 편집]

1개의 Region은 2~3개의 Availability Zone(AZ)으로 구성하며 AZ간 트래픽은 모두 암호화�가 됨. 서비스 가용성 확보를 위해서는 동일 AZ에 서비스를 올리면 안됨.

1.4 Region Code[편집 | 원본 편집]

CLI 및 SDK 이용시 코드를 사용함 (예: us-west-1)

Region Code.png

1.5 VPC[편집 | 원본 편집]

Virtual Private Cloud. AWS에서 네트워크를 제공하는 서비스로 가상 네트워크 존을 설정하는 것이라고 생각하면 됨

VPC 아키텍처.png

1.5.1 VPC 구성요소[편집 | 원본 편집]

VPC의 주요 구성요소는 아래와 같음

  • Region (=IP 대역 결정)
  • Subnet
  • Routing
  • Security 정책 (=Traffic 통제)

1.5.2 CIDR[편집 | 원본 편집]

Classesless Inter-Domain Routing. 네트워크를 원하는 대로 슬라이싱하는 기술. 네트워크를 서브 네트워크로 나누는 기술. VPC 생성 후 CIDR 변경이 불가하므로 여유있게 설정 필요.


CIDR.png

1.6 Subnet 서브넷[편집 | 원본 편집]

VPC 생성 후, Subnet 으로 네트워크를 나눔. Subnet을 사용하는 이유는 네트워크 주소를 목적에 맞게 분할함으로써 보안성, 서비스 가용성, 유지관리성을 높이기 위함임. 또한, 트래픽을 원하는 대로 제어하기 위해 사용하기도 함.


Subnet.png


Subnet IP 설정.png


서브넷 아키텍처.png

1.6.1 VPC와 Subnet[편집 | 원본 편집]

Region 생성 후 VPC를 만들고, 해당하는 AZ에 Subnet을 만듦. 참고로 VPC에는 1개의 Internet Gateway를 갖을 수 있음.


VPC와 Subnet.png


Subnet 생성.png


1.6.2 Public Subnet[편집 | 원본 편집]

인터넷 게이트웨이로 향하는 경로가 있는 라우팅 테이블과 연결되어 있는 서브넷. Public IP와 Private IP 모두 할당.


1.6.3 Private Subnet[편집 | 원본 편집]

인터넷 게이트웨이로 향하는 경로가 없는 라우팅 테이블과 연결되어 있는 서브넷. Private IP 만 할당.


1.7 인터넷 게이트웨이[편집 | 원본 편집]

VPC와 인터넷 간에 통신을 위한 리소스. 사용자가 콘솔에서 직접 생성 후, 대상 VPC와 1:1 연결을 해야 함.


Internet Gateway.png

1.8 라우팅 테이블[편집 | 원본 편집]

라우팅 테이블을 라우터에 설정 필요. 고속도로를 설치하는 거라고 보면 됨.


라우팅 테이블.png

1.9 Security Group[편집 | 원본 편집]

보안 그룹. 서버 앞에 위치하여 방화벽 역할을 함


Security Group.png

Firewall.png

1.10 액세스 제어[편집 | 원본 편집]

Network Access Control List(NACL) 또는 Security Group(보안그룹)으로 접근 제어를 할 수 있음.


NACL은 서브넷 단위 방화벽. Security Group은 인스턴스 단위 방화벽. Security Group은 Stateful(상태 저장)이기 때문에 Inbound 정책으로 들어온 트래픽에 대해 자동으로 Outbound 트래픽을 전달할 수 있음. 반면에 NACL은 Inbound 및 Outbound 정책을 각각 설정해야 함. 또한, NACL은 Prioirty(정책 우선순위)를 숫자로 설정을 하는데 Security Group은 정책 우선순위 자체가 없음.


Access Control.png NACL 트래픽 제어.png


Security Group Rule.png


참고로 NACL은 최대 40개 Rules(Inbound 및 Outbound 각 20개) 설정이 가능. VPC 생성 시 자동으로 Default NACL 이 생성되며 기본 정책은 내/외부 통신 전체 허용이며 Rule Set은 낮은 번호가 높은 우선순위를 갖음.

1.11 네트워크 트래픽 통제 (요약)[편집 | 원본 편집]

Routing Table은 Subnet 단위. NACL도 Subnet 단위이며 Rule Set 설정 가능. Security Group은 Instance 단위이며 Inbound 및 Outbound Rule 설정 가능.


네트워크 트래픽 통제.png

1.12 기타 참고사항[편집 | 원본 편집]

  • 리전당/계정당 VPC는 최대 5개 생성 가능 (단, AWS Support Center를 통해 Service Limit Increase 요청 가능)
  • NACL + Security Group을 함께 사용하는 게 가장 강력하지만... 복잡성 증가, Troubleshooting 어려움, 운영 Cost 증가의 단점이 있음


1.13 NAT 게이트웨이[편집 | 원본 편집]

Network Address Translation. 공인 IP 와 사설 IP 를 맵핑하는 기술. 즉, 네트워크 주소의 멀티플렉서 및 디멀티플렉서라고 봐도 됨.


NAT 게이트웨이 사용 예시.png


퍼블릭 서브넷은 라우터와 IGW를 통해 인터넷에 접근을 함. 반면에 프라이빗 서브넷은 라우터와 NAT 게이트웨이를 거친 후, 다시 라우터와 IGW를 거쳐서 인터넷에 접근을 함

1.14 Elastic IP[편집 | 원본 편집]

EC 인스턴스에 할당하는 공인 IP. EIP를 할당하지 않는 경우, 서버 재기동 시마다 새로운 IP가 할당이 됨. 인스턴스, 네트워크 인터페이스, NAT Gateway 등에 연결하여 사용.


---


Lunch Time 🌭


---

1.15 실습[편집 | 원본 편집]

https://catalog.workshops.aws/general-immersionday/ko-KR/basic-modules


VPC 실습 1.png


VPC 생성 ➡️ Subnet 생성 ➡️ Routing Table 설정 ➡️ Security Group 생성

1.16 EC2[편집 | 원본 편집]

쉽게 생각하면 Virtual Machine 임

1.16.1 EC2 유형[편집 | 원본 편집]

가장 범용적인 t 및 m 시리즈 사용하는 경우가 많음


EC2 유형.png

1.16.2 EC2 구매옵션[편집 | 원본 편집]

On-Demand, Reserved Instances(RI), Savings Plans, Spot Instances 로 나뉘어짐


EC2 구매옵션.png

1.16.3 EC2 구조[편집 | 원본 편집]

기본적으로 VM에는 Ephemeral 한 스토어(=Instnace Store)가 있음. 매우 빠르지만 휘발성 데이터임. 따라서 영구적으로 저장하는 데이터는 EBS 같은 공간에 저장 필요.


EC2 구조.png

1.16.4 EC2 인스턴스 생명 주기[편집 | 원본 편집]

EBS 볼륨을 root로 사용하는 인스턴스만 정지를 할 수 있음


EC2 인스턴스 생명 주기.png

1.16.5 EC2 사용자 데이터[편집 | 원본 편집]

인스턴스 생성과 함께 전달 가능한 최대 16KB 크기의 텍스트 데이터. 최초 부트 시 실행하는 Bootstrap 역할.

1.17 Load Balancer[편집 | 원본 편집]

서비스 부하를 분배하는 AWS의 서비스는 Elastic Load Balancer. 헬스 체크를 통해 정상적인 서버에만 트래픽을 보내서 서비스 장애를 막는 역할도 함.


Elastic Load Balancer.png

1.17.1 ELB 아키텍처[편집 | 원본 편집]

크게 외부 및 내부 로드 밸런서로 나누어서 구성함. ELB는 xxx.us-east-1.elb.amazoneaws.com 형식의 도메인을 갖으며 이 도메인은 Route 53 에서 관리함.


ELB 아키텍처.png

1.17.2 리스너(Listner)[편집 | 원본 편집]

Load Balancing 규칙을 정의하는 구성 요소. 트래픽을 등록한 대상 그룹으로 라우팅 함.


ELB Listener.png

1.17.3 ELB 유형[편집 | 원본 편집]

ELB에는 세 가지 유형이 있음. {Application, Network, Gateway} Load Balancer 임.


- Application : HTTP 헤더 내용 기준 (L7 같이...)

- Network : IP, PORT 기준 (L4 같이...)

- Gateway Load Balancer : Third Party ?


ELB Types.png

1.17.3.1 ALB vs. NLB[편집 | 원본 편집]

참고로 NLB도 Security Groups 기능이 지원됨 (Link)


ALB vs. NLB.png

1.17.4 컨텐츠(가중치) 기반 라우팅[편집 | 원본 편집]

여기서 말하는 컨텐츠 기반이라는 의미는 URL 을 의미하며 ALB에서만 사용 가능. 가중치 기반 라우팅은 ALB, NLB 모두 사용 가능.


컨텐츠(가중치) 기반 라우팅.png

1.18 오토 스케일링(Auto-Scaling)[편집 | 원본 편집]

사전에 정의한 지표에 기반하여 서버 개수를 동적으로 변경하는 기능. 수평 확장 O. 수직 확장 X. 즉, scale-in, scale-out 이 일어남. Auto-Scaling은 CloudWatch 라는 서비스와 함께 사용함. 이 서비스는 모니터링 및 알림을 제공하는 서비스.


Auto Scaling on AWS.png

Auto Scaling and CloudWatch.png

1.18.1 Auto Scaling 구성요소[편집 | 원본 편집]

Auto Scaling 구성요소.png

1.18.2 Auto Scaling Launch Template[편집 | 원본 편집]

인스턴스를 배포하기 위한 정보들의 묶음

Auto Scaling Launching Template.png

1.18.3 Auto Scaling �Group[편집 | 원본 편집]

정책에 따른 �Auto Scaling 을 적용하기 위한 기능


Auto Scaling Group.png