중간 시험 범위 정리

⯈CC

: computing resources로 구성된 공유 pool에 접근 가능한 nw

 

⯈On-Premise

-) 자체 서버, storages, nw 장비 구매해야 함(hw 비용↑), 관리자 고용(전문지식 필요)

-) 유지보수 및 관리 필요. 급변하는 load에 적용(scaling up, down) 어려움

 

⦁ Over Provisioning

: peak load에 맞춤_서버가 적을 때 낭비, 비효율(피크타임에 사용되지 않는 자원을 할당)

 

⦁ Under Provisioning

: peak load 아래에 맞춤_서버가 많을 때 몇 명은 이용 불가

 

⯈Cloud

+) 초기 설치 비용 x on demand(쓴 만큼 돈 냄)

+) scalability(확장성)↑: load/수요에 따라 resources를 동적으로 할당(트래픽 급증에 대응)

+) Economies of scale: 대량 생산이 소량 생산을 하는 경우보다 평균비용이 더 낮은 상황

+) 하나의 계정에 multiple users accessible

+) availability↑: 오랜 시간 사용 가능. 정상적으로 동작. 필요할 때 사용 가능

+) reliability↑:　예외 상황에서 회복↑, 문제 없이 작동. 여러 개의 서버에 데이터를 저장하여 secure함

+) Backed up: 데이터 카피본이 다른 물리적 장소에 저장됨(failure 대비)

*Cloud Provider는 높은 availability를 보장할 수 있는 탄력적 IT 리소스를 제공(SLA)

 

-) security↓ potability(다른 클라우드로 이동 어려움)↓ operational governance control↓(On-Premise보다)

-) 다양한 지역에서 compliance(규정), legal issues 다름

 

⯈Cloud Infrastructure

: hw(servers, nw장비, storages)+sw

*Cluster > Rack > (nw switches, nodes/blades, storage devices)

 

⦁ server

: 클라이언트에게 서비스를 제공하는 컴퓨터(reliability, large requests services로 디자인 됨)

*모든 서버는 heterogeneous(서로 다른 internal hw로 구성됨)

 

⦁ Blade Server

: 최대한 얇게 만든 서버 컴퓨터. Rack안에 들어감

+) floor space, manageability, scalability, power, cooling

 

⦁ nw

: physical cables, switches, routers, wireless access points

*nw topology: bus, tree, ring, star

 

⦁ storage array

: 많은 양의 storage를 연결한 단순하고 강력한 컴퓨터

 

⯈Cloud Service

⦁ Software as a service(Saas)

: 클라우드 환경에서 동작하는 SW 제공

: sw 설치 x, 인터넷 연결만 있으면 됨. CSP가 모두 관리

예) 구글 독스, 구글 캘린더, 구글 드라이브, Gmail, 노션, 드랍박스, MS office 365

 

⦁ Platform ~(Paas)

: sw 개발에 필요한 플랫폼 제공

: CSP가 hw, requirements 관리/유저: application, data만 관리

예) 구글 앱 엔진, MS Azure, Heroku

 

⦁ Infrastructure ~(IaaS)

: 서버(컴퓨터 자원) 같은 인프라 제공

: virtualization 기술을 사용해 각 서버를 multiple한 고객들이 공유

예) AWS EC2, MS Azure Virtual 머신스, 구글 Cloud 컴퓨트 엔진

 

⦁ Function ~(FaaS)

: serverless 컴퓨팅. 클라우드에서 개별 함수를 서비스로 제공.

: 인프라 및 서버 관리는 클라우드 제공업체가 담당하며, 사용자는 코드(함수) 작성과 실행 트리거만 관리

예) AWS Lambda, Azure Functions

 

⯈Cloud Deployment Models

⦁ Public Cloud

: open to anyone(AWS, MS Azure, 구글 클라우드)

 

⦁ Community C

: 비슷한 기관끼리 공유(구글 Gov Cloud) 예) a회사, b회사

 

⦁ Private C

: 하나의 기관에서 공유(큰 회사의 내부 DC)

 

⯈Computing

: CPU, RAM(메인 메모리, DRAM, 휘발성), HD(SSD), nw로 구성

*Bandwidth: 특정 시간 내에 보낼 수 있는 정보량(↑좋음)

*Latency: 하나의 데이터 패킷이 보내지는 데 소요되는 시간(↓좋음)

---

⯈EC2(Elastic Compute Cloud)

: 가상화된 서버 사용(EBS 할당)

: VM이 hypervisor로서 각 인스턴스의 OS를 full control한다.

: 인스턴스라고 불리는 VM을 제공. AMI, Instance 타입을 기반으로 함

+) Affordable costs, Global, integrated, 빠른 시작, Resizable, Elastic computing(용량 자동 증가, 감소)

+) complete control: 인스턴스에 들어오거나 나가는 트래픽 직접 제어 가능

+) 다양한 인스턴스 타입, OS, sw 패키지 선택 가능

*Region>VPC 최대 5개(추가 가능)>AZ 多>subnet 多(public/private)>security group>EC2 인스턴스 1개

 

⯈EC2 Purchasing Options

⦁ On-demand

: 초 당 계산(가격 고정), 후불

UC) 중단할 수 없는 단기간 서비스, spiky, load 예측이 어려운 서비스, 처음 개발되거나 테스트되는 애플리케이션

사전 지불이나 장기 약정 없이 Amazon EC2의 낮은 비용과 유연성을 선호하는 사용자

 

⦁ Reserved Instance

: 1년/3년 선택 후 선불(할인 o) / only EC2

UC) 장기 서비스(1년 이상), load 예측이 쉬운 서비스_flexibility가 필요 없는 서비스

 

⦁ Saving Plans Instances

: 1년/3년 선택 후 선불(할인 o) UC) 장기 서비스

 

> Compute Saving Plans

: flexibility↑(인스턴스 타입, 리전 변경 가능), 66% 할인 / EC2, Lambda, Fargate

: 인스턴스 family, 크기, AZ, 리전, OS, tenancy에 관계없이 인스턴스 사용량에만 적용

예) C4에서 M5 인스턴스로 변경/리전을 아일랜드에서 런던으로 변경하더라도 요금 계속 이용 가능

 

> EC2 Instance SP

: AZ, 크기, OS, tenancy에 관계없이 특정 리전의 개별 인스턴스 패밀리에 대한 사용량에만 적용

예) 윈도우 c5.xlarge를 Linux c5.2xlarge로 변경하더라도 기존 요금 계속 이용 가능

 

⦁ Spot Instance

: 분 당 계산, 경매 형식(on-demand보다 최대 90% 할인)

: supply>demand: discount / supply<demand: terminated

UC) 시작 및 종료 시간이 유연한 애플리케이션, 매우 낮은 컴퓨팅 가격으로만 실행 가능한 애플리케이션,

대량의 추가 용량에 대한 긴급한 컴퓨팅 요구가 있는 사용자

-) 일시적 서비스이므로 중지 대비해야 함(불안정), 대량의 추가용량에 대해 짧게 이용

 

⯈Tenancy 

: EC2 인스턴스가 어떻게 물리적 host HW에 분산되는 지 정의

 

⦁ shared tenancy

: hw에 a사용자 인스턴스랑 b사용자 인스턴스 모두 존재

: aws가 배치 및 관리, 시간이 지나도 같은 서버에 배치 불가능, 가격 ↓

 

⦁ dedicated instance

: hw에 a사용자 인스턴스가 여러개 존재. isolated

: aws가 배치 및 관리, 시간이 지나도 같은 서버에 배치 불가능, 가격 ↑

 

⦁ dedicated host

: hw에 a사용자 인스턴스가 1개 존재. isolated

: 직접 배치 및 관리, 시간이 지나도 같은 서버에 배치 가능, 개수에 따른 가격

 

⯈인스턴스 생성 과정

1. Name, Tag(key, value) 생성

⦁ tag

+)검색, 필터기능: 태그별 리소스 그룹 생성/관리(+가격 관리), automation(리소스 필터)

+) access 컨트롤(tag 정보를 기반으로 IAM 사용하여 접근 관리)

 

2. AMI 선택

: root volume을 위한 templates(OS, server, app 설정 내용 포함)

: 같은 구성이면 같은 AMI 런치/다르면 각각 다른 AMI　사용

: 한번 선택하면 바꿀 수 x(삭제 후 새로 생성해야 함)

+) Backups, Repeatability(같은 AMI로 런치된 인스턴스는 서로의 복제본)

+) Reusability, Recoverability(장애발생 시 새인스턴스를 만들어 똑같은 API를 사용하여 복제)

+) Marketplace Solutions(솔루션을 마켓에서 찾을 수 있음)

 

3. 인스턴스 타입 선택(CPU, RAM, 디스크 스페이스 및 타입, nw performance)

: 추후 변경 가능

*표기법: 패밀리+세대.+크기 예) t2.micro

 

4. Key Pairs

: EC2 인스턴스를 securely access하기 위해(SSH)

: 존재하는 키페어 사용/새로운 키페어 생성/사용x 중 선택(default 세팅 없음)

: AWS-public key, 나-secret key(절대 노출x) 각각 저장

 

5. nw 세팅

: VPC, subnet, security group 설정, public IP 사용 여부 선택

⦁ Region(physical location): 리전마다 가격/속도 다름, 여러 개의 AZ 존재

+) fault tolerance(서울 불가→도쿄 이용), stability(독립적), 가까울수록 빠름

 

6. Configure Storage

– main 솔루션: EBS

 

7. Advanced Details(IAM role, User Data, tenancy, 등)

⦁ IAM Role: specific permission policies, 역할 추가, 변경, 삭제 가능

⦁ User Data: 인스턴스가 처음 런치/스탑 후 다시 시작 시 자동으로 수행되는 스크립트

 

8. 그 외 세팅 옵션

: Spot 인스턴스 요청

: shutdown behavior(인스턴스가 중단되거나 멈춘다)

: termination protection(enable로 설정하면 terminated 막아줌)

: tenancy

 

< 분류별 정리 >

*default setting x: key pair *가격 영향 o: AMI, 인스턴스 타입, storage, advanced details, regions

*인스턴스 런치 후 수정 x: AMI, 키페어, nw 세팅(VPC, subnet), region

*인스턴스 런치 후 수정 o: name&tag, 인스턴스 타입, nw 세팅(IP주소, CIDR 블록, security group), storage, advanced detail(role 추가, user data scripts)

---

⯈Block Storage(EBS, Instance Store)

: OS나 SAN(Storage Area NW)이 관리

: 데이터를 블록 단위로 쪼개고 저장하여 각각에 unique identifier 존재

: 각각의 블록은 다양한 시스템에 저장할 수 있고 각 블록은 다양한 OS에서 작동하도록 구성할 수 있다.

+) latency↓, IOPS↑, flexibility↑, faster

-) organization↓, overhead↑

UC) high-performance db, vm file systems, ↓latency 요구 applications

 

⯈Elastic Block Store(EBS)

: virtual storage volumes를 위한 저장공간(nw에 붙어있음)

: 인스턴스를 삭제해도 남아있다. usb처럼 행동. 가격↑, 용량 제한 o

*Durability: 평균 loss 예측 예)durability가 99%면 100개 중 1개 loss

*Availability: 1년 동안 오브젝트 사용이 가능한 평균 시간

+) availability(AZ내에서 자동 복제), snapshots(백업), durable, detachable, performance↑, latency↓

 

⦁SSD-based: Provisioned IOPS(latency↓), General purpose(가격 수행 밸런스 좋음)

: flash, 전자적, 빠름, root 볼륨 가능 / UC) 자주 사용, 작은 I/O 사이즈에 이용

 

⦁HDD-based: Throughput Optimized(자주 접근), Cold(자주 접근x)

: 마그네틱, 물리적, 느림, root 볼륨 불가능 / UC) 높은 처리량을 요구하는 large streaming work load

 

*선택 옵션: volume 타입&크기, 인스턴스 종료 시 볼륨 자동 삭제 여부, 암호화 여부(키 사용 여부)

 

⯈Instance Store

: temporary 블록 레벨 스토리지(피지컬 서버에 붙어있음), root 볼륨 가능

-) ★인스턴스 중단 시 데이터 모두 삭제, 인스턴스 시작 후, instance store 볼륨 추가 생성 불가능

-) 특정 AMI, 인스턴스 타입의 조합만 가능, 볼륨 제거 불가능, not configurable

 

⯈File Storage(EFS)

: 파일/디렉토리의 계층적 구조, 파일에 데이터 저장(메타데이터로 관리)

: 파일 시스템 프로토콜(NFS, SMB)에 의해 접근

: 여러 개의 인스턴스의 데이터들을 공유된 파일 시스템 안에서 사용, root 볼륨 불가능 / -) flexibility↓

: 파일 추가 및 삭제 시 자동으로 볼륨 조절(관리 필요 x)/NFS, SMB로 접근

+) available↑, durable↑, elastic, scalable, encryption, organization↑

+) simpilicity↑, sharing 촉진, 다른 OS와 앱에 넓게 서포트, fully managed(모든 관리 해줌)

UC) 미디어 processing workflows, shared and home directories, db backups, 개발자 및 앱 도구, 빅데이터 분석, 공유 파일 리포지토리, 컨텐츠 관리 시스템

---

⯈Object Storage(S3)

: 오브젝트로 저장.

 

*오브젝트: 데이터(real file)+메타데이터+오브젝트 키(unique identifier)

: object는 버켓에 저장(flat address storage), 수평적 분배(flat)

: unique ID를 이용하여 HTTP APIs로 접근(GET, PUT 등)

: 버킷안에 폴더 생성 가능(계층x, 오브젝트안에 폴더를 붙임) 디렉토리는 실제로 존재하는 물리적 폴더 x

: 객체 이름에 경로를 포함시켜 디렉토리처럼 보이도록 하는 논리적인 구조

UC) cloud storage service, backup and archival solutions,

storing large amounts of unstructured data 예)drop box

*박스 예시) 박스=오브젝트, QR=unique ID, 데이터 양에 따라 박스 크기 조절 가능

- 생성: 박스에 데이터 넣고 박스마다 QR코드 부착.

- 읽기/삭제: QR 스캔 후 박스 찾아서 데이터 확인 후 읽기/삭제

 

⯈S3(Simple Storage Service)

: 웹 objects를 위한 저장공간

: 파일 업로드 시 최소 3개의 AZ에 오브젝트가 자동 복제됨–한 AZ에서 장애 발생하면 같은 리전의 다른 AZ 이용 가능

+) durability↑(loss), availability↑, scalability↑, security(encryption), 무제한

+) 풍부한 메타데이터로 구성해 검색이 용이함, 합리적 가격, (-slower)

+) 모든 파일타입 가능(5TB 이하), flexibility↑, fault tolerance

 

⦁ Active Storage: 항상 사용 or 덜 접근하지만 중요해서 접근 시 빨라야 하는 것

예) files for static website(html)

 

 ⦁Archive S: 잘 접근 안하는 데이터 예) data for compliance, video archive

 

⯈S3 Costs

: Storage 클래스와 특징에 따라 (월별 GB),

 

⦁유료: 다른 리전/인터넷으로 데이터 전송, PUT, COPY, POST, LIST, GET request

 

⦁무료: S3로 데이터 전송/업로드(transfer in), 동일 지역 내의 S3 버킷 간 전송, 동일 지역 내의 EC2로부터 전송, 동일 지역 내의 CloudFront로부터 전송(transfer out), DELETE 및 CANCEL 요청

 

*Free tier: 12개월 동안 5GB 받기/20,000 GET 요청, 2000 PUT, COPY, POST, LIST 요청/100GB 전송하기

 

⯈Large 데이터 옮기기

⦁ S3 Transfer Acceleration

: 수백개의 CloudFront edge locations를 사용하여 client와 S3사이의 거리를 줄임

 

⦁ AWS Snowcone

: portable, rugged, secure device for edge computing and 데이터 전송(물리적 장치)

 

⦁ AWS Snowball

: S3와 onsite 데이터 스토리지 간에 많은 양의 데이터를 옮김(물리적 장치)

 

⦁ ASW Snowmobile

: AWS로 많은 양의 데이터를 옮김(물리적 장치)

 

⯈Bucket 생성 과정

1. 버켓 이름 짓기: global unique

 

2. 버켓 생성

: 오브젝트를 버켓에 저장하면 이름, 키, 버전 ID의 조합으로 unique URL을 만들어 오브젝트를 식별한다.

예) https://s3.ap-northeast-2.amazons.com/bucketname/key 

 

3. 리전 선택

 

4. 오브젝트 ownership and access

: ACL(access control list)에 의해 오브젝트 ownership, access 컨트롤 가능

 

5. Versioning

: 모든 오브젝트를 versioning 후 unique 버전 ID를 부여한다.(보존, 검색, 복원이 용이)

: 한번 버전 설정하면 버전 만들기 전 상태로 돌아갈 수 없지만 버전 중단은 가능

 

6. 버켓에 tag 추가(key-unique, value 설정)

 

⯈Uploading object

*하나의 버킷에는 무제한으로 데이터 저장 가능, 하나의 오브젝트에는 5TB이하로 저장 가능

1. storage class 선택: 기본은 S3 Standard, 업로드 후 언제든지 변경 가능

2. multipart upload: 하나의 오브젝트를 여러 부분으로 나누어 버켓에 업로드(속도↑). 나중에 S3가 다시 합침

 

⯈Working with object

⦁Copy

: copy(복사본) 생성 → 복사본 이름 변경 → 오브젝트 옮기기 →오브젝트 메타데이터 수정

 

⦁Life Cycle rules

: S3가 오브젝트 그룹에 할 행동을 정의한 rules

 

>Transition actions: 오브젝트가 다른 스토리지 클래스로 바뀔 때

 

>Expiration actions:　오브젝트가 만료되어 삭제될 때

 

⦁Replication rules

: 계정, 버킷, 지역을 선택해 자동으로 카피

+) 여러 리전, 스토리지 클래스, ownership에서 유용하게 copy를 유지 관리하게 도움

 

> cross-region: 사용자의 지리적 위치에 가깝게 하여 latency↓, 재난 복구를 위해

: 서로 다른 AWS 계정 간 데이터 복제도 가능하므로, 다중 계정 아키텍처에서 데이터를 보호하고 관리할 때 유용함

UC) 규정/내부 체제 관리에 따라 데이터를 다른 리전에 복제해야 하는 경우,

여러 리전에서 서비스에 접근하는 경우, 데이터를 해당 리전으로 복제하여 latency↓

 

> same-region: 리전 내에서의 데이터 가용성↑ 특정 워크로드를 분리하거나 개발 및 운영 환경 간의 데이터를 동기화할 때 

UC) 여러 S3 버킷에서 생성된 로그 파일을 하나의 중앙 버킷으로 복제하여 통합 관리하는 경우.

개발 환경과 운영 환경 간의 실시간 데이터 복제가 필요한 경우.

 

⯈Bucket Security

: 버킷에 IAM policy를 적용하여 권한을 줄 수 있다.

: 버킷 policy(Json)를 이용하여 AWS 계정, 유저에게 오브젝트 접근 권한을 줄 수 있다.

 

⯈EC2 Life Cycle (Running, Rebooting만 billed, 나머지는 not billed)

 

---

⯈Scaling

⦁ Vertical

: 인스턴스 스탑→인스턴스의 사이즈/타입 변경→인스턴스 시작

-) manual process(자동 x 수동으로 스스로 해야함). multiple instances를 관리해야 할 때 어려움.

-) 확장성 한계 o. 변화 불가능한 인스턴스가 존재할 수도 있음

UC) 인스턴스 크기가 너무 약하면 horizontal scaling이 소용 없음 → vertical scaling

 

⦁ Horizontal

: Auto Scaling(health check: 인스턴스/ELB 체크 후 unhealthy면 대체)

+) fault tolerance, availability↑ 가격↓ 중단시간(downtime) x. 여러 AZ에 걸쳐 인스턴스 생성 가능

UC) CPU 사용량은 낮은데 너무 많은 요청이 오면 vertical scaling이 소용 없음 → horizontal scaling

 

⯈Auto Scaling

⦁ASG(Auto Scaling Group)

: minimum, maximum, desired capacity(현재 로드에서 default) 선택

 

⦁Auto Scaling Llifecycle

: Launch(scaling/health check 시작), Running, Scale-In(수요 적을 시 terminated), Terminate(unhealthy / 과잉의 인스턴스는 종료 후 대체)

 

⦁Scaling Policies

>Scheduled

: 일정한 날짜와 시간에 1회/정기적인 일정에 따라 scaling

 

>Dynamic

: 실시간 성능에 따라 후조치(target tracking scaling)

 

>Predicted

: ML을 사용해 과거 성능을 바탕으로 예측하여 선조치

---

⯈NW

: 모든 장치를 연결해주는 connecting device(router)가 존재

: server, 라우터, Hub 및 스위치, ISP(Internet Service Provider), Cloud, nw nodes(client)로 구성

*switch는 IP 주소x, 라우터는 IP 주소o

 

⯈OSI 계층

1. physical>data link>nw>transport>session>presentation>7. application

 

⯈ELB(Elastic Load Balancer) 

: incoming 트래픽을 multiple 타켓에 분배

*가장 좋은 배치: 인스턴스를 여러 AZ에서 런치 후 ELB 이용해 incoming traffic 분배

*Health Check: 서버 상태 주기적 확인. unhealthy면 라우팅 멈추고 다른 곳으로 라우팅

*Crosszone load balancing: 여러 AZ에 분배(availability↑ fault tolerance)

*Auto Scaling integration: auto scaling 되면 그에 따라 자동으로 분배

 

⦁Application Load Balancer(ALB)

: HTTP(S)의 메타데이터 보고 라우팅. 속도↓ Layer7(App L)

UC) micro 서비스, container based application

 

⦁Network LB(NLB)

: TCP, UDP, TLS. Layer4(Transport L)

UC) performance↑, latency↓, real-time, throughput↑한 서비스

 

⦁Gateway LB(GLB)

: Layer3(Network L)

UC) third-party virtual appliances(firewalls, intrusion detection 시스템, deep packet inspection 시스템)

---

⯈VPC(Virtual Private Cloud)

: 자체 dc에서 운영하는 기존 nw와 가장 유사한 독립된 nw

: resource placement, connectivity, security를 제공하는 virtual nw 환경

: EC2 instance가 선택한 VPC에서 시작됨. 각 VPC는 다른 환경을 서포트 함

UC) to host multi-tier web application

 

⦁Presentation tier

: Web site 유저가 웹/앱에서 상호작용하는 곳

예) 인스타그램 사진 업로드(public subnet>EC2 instance)→Application tier로 전송

 

⦁Logic tier(Application tier)

: Application 컴퓨팅 프로세스가 발생하는 곳

예) 업로드한 사진 처리(private subnet>EC2 instance)→Data tier로 전송

 

⦁Data tier

: Database 데이터가 저장되는 곳 보통 프라이빗 서브넷으로 보호됨

예) 사진 db에 저장(private subnet>RDS instance)

 

⯈default VPC

: AWS 계정 생성 시 자동으로 리전에 제공됨(삭제하거나 사용하지 않는 것 추천)

: 모든 AZ에 public subnet이 각각 들어있음

: default VPC 내부에 추가 public subnets 생성 가능. 리전 안에 customized VPC 추가 가능

 

⦁default VPC-default subnet

: 자동으로 public IP enable 세팅. disable 선택 가능

 

⦁default VPC-custom public subnet, custom VPC-custom subnet

: 자동으로 public IP disable 세팅. enable 선택 가능

 

*VPC 생성 시 실행되는 모든 내부 인스턴스는 프라이빗 IP 자동 부여: 퍼블릭 IP 요청가능

*VPC는 하나의 리전에 국한되고 여러 개의 리전에 span 할 수 없다.

*VPC의 CIDR Block은 subnet IP CIDR Block의 범위보다 커야한다.

 

⯈VPC 패턴

⦁Single VPC pattern

: 한 명/한 팀이 관리. 높은 performance 컴퓨팅

 

⦁Multi-VPC p

: 한 팀/한 기관이 관리. managed 서비스 providers

⦁Multi-account p

: 큰 조직/여러 개의 IT팀을 가진 기관. 접근 관리, standards 복잡

 

⯈VPC 구성요소

: 메인 라우트 테이블, nw access control list, security 그룹으로 구성

⦁VPC ID: VPC를 생성하면 자동부여. 수정불가. 랜덤 숫자, 문자로 구성

 

⦁tags: ID를 기억하기 어려워서 태그를 줌 예)vpc-134jh3j43(Testing VPC)

 

⯈VPC 삭제

⦁먼저 삭제할 요소

: EC2/RDS 인스턴스, ELB, NAT, transit gateway, VPC 엔드포인트

 

⦁자동 삭제 요소

: subnets, IG, Egress-only internet gateways, 라우트 테이블, security 그룹, NW ACL, DHCP options, Gateway endpoints

 

⯈Subnet

: VPC 안의 더 작은 nw.

: 특정 AZ 1개에 매핑(fault tolerance).

: AZ 1개에 subnet 여러개 가능

*IP 주소 5개는 사용 x: nw 주소, VPC 로컬 라우터, DNS resuolution, future use, nw broadcast address

*subnet은 nw내의 nw이므로 CIDR block address를 가진다.

*subnet의 CIDR는 nw의 CIDR 범위 이내에 있어야 하고(같으면 x) subnet의 CIDR은 겹치면 안된다.

*subnet ID: VPC ID처럼 자동 생성 예) subnet-djf2jf442f

 

⦁public subnet

: 인터넷 연결 o, 인스턴스 재시작 시 변경 o

 

⦁private subnet

: 인터넷 연결 x, 인스턴스 재시작 시 변경 x

 

⦁Elastic IP(static public IPv4) ↔ dynamic IP(퍼블릭 IP): 변경 o

: for dynamic cc. 리전 레벨. 인터넷 연결 o, instance 하나와 연관, 변경 x, 스턴스에서 detached 되거나 사용되지 않을 때 cost

 

⯈NW Gateway

⦁internet gateway(VPC간 통신/VPC와 인터넷 간 통신),

⦁virtual private gateway(VPN connector로 VPC와 온프레미스 간 통신)

 

⯈Route Tables

: 각각의 라우트가 (target, destination)을 지정

*서브넷을 만들면 VPC안의 각각의 서브넷은 메인 라우트 테이블과 연결됨(must)

*서브넷:라우트 테이블=N:1 하나의 서브넷은 하나의 라우트 테이블만 가능

---

⯈EC2 Security group

: ssh 접근(key pair), 인스턴스 바깥에 존재하는 AWS 자체 제공 virtual 방화벽

*OS 내부에도 자체적인 방화벽이 존재함 예) OS-allow, sg-deny: 트래픽 받지 못함

: incoming/outcoming traffic control (nw access 컨트롤)

: (타입, 프로토콜, port 범위, source)로 rule 설정

 

⦁inbound rule

: incoming 기본이 deny이므로 allow rule 설정

 

⦁outbound rule

: outcoming 기본이 allow이므로 deny rule 설정

 

*인스턴스:Security 그룹:N:N. AZ에 span 가능

*언제든지 수정 가능 – 실시간 변경 / 한 인스턴스에 대해 여러 개 적용 가능(동시 평가)

*Stateful: inbound에 대한 outbound 응답은 rule이 deny이더라도 생성(반대도 마찬가지)

*서브넷 레벨 x 인스턴스 레벨 o → 같은 서브넷에 있는 인스턴스라도 다른 sg에 할당 가능

*모든 EC2, RDS 인스턴스는 시큐리티 그룹이 필요하다

 

⯈NW ACL(Access Control List)

: VPC를 보호하기 위한 방화벽(서브넷 레벨)

: 모든 서브넷은 NW ACL과 연결이 필요하다 (명시 안하면 자동으로 default ACL 연결)

 

⦁Default N-ACL

: 모든 inbound, outbound default는 allow

 

⦁Custom N-ACL

: 모든 inbound, outbound default는 deny(allow, deny 룰)

 

*서브넷:ACL=N:1 하나의 서브넷은 하나의 ACL만 가능. AZ에 span 불가능

*stateless: 인바운드가 가능한데 아웃바운드가 deny면 응답 불가(반대도)

*세분화(타입, 프로토콜, port 범위, source, 특정 IP 주소), 작은→큰 숫자 우선순위(나중에 추가 가능)

*SecurityG, ACL은 함께 VPC를 보호함(바깥쪽이 ACL, 안쪽이 SG) → 충돌 시 SG 승리

---

⯈NAT Gateway

: 프라이빗 서브넷으로 인터넷 연결/다른 AWS 서비스 이용 가능.

: 상주할 퍼블릭 서브넷 있어야 함

: 프라이빗 서브넷이 외부에서 요청되는 인바운드는 필요 없더라도 인스턴스의 펌웨어나 혹은 주기적인 업데이트가 필요하여 아웃바운드 트래픽만 허용되야 할 경우, 프라이빗 서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 IG와 연결

: NAT을 생성하기 위해선 NAT가 상주하는 public subnet과 Elastic IP 지정해야 함.

: 생성 후 NAT와 연결 될 라우트테이블 업데이트해야 함(이 라우트테이블로 IG연결)

 

⯈VPN

: Virtual Private NW. public망을 private망처럼 이용하게 해줌

 

⯈Direct connect

: 전용선을 사용하여 on-premise와 AWS VPC를 연결(비용↑)

 

⯈VPC Endpoints

: VPC와 supported services를 연결(같은 리전 내에서만)

: IG, NAT, VPN, Direct connect 사용 x → VPC가 public 인터넷에 노출 x

⦁AWS Private link: VPC, AWS 서비스, on-premise nw간에 private한 연결을 제공

 

⦁Gateway Endpoint: S3, DynamoDB에 프라이빗하게 연결

 

⯈VPC Peering

: 라우트 트레픽을 이용하여 privately하게 2개의 VPC들을 연결

: IP 주소(CIDR)가 overlap되면 안된다. transitive peering x(a,b,c 거치는 거 안됨)

+) 다른 계정, 다른 리전에 있어도 가능 / 양쪽에서 라우트 테이블 구성해야 함(peering connection으로 향하게)

 

⯈Transit Gateway

: 여러개의 VPC를 오직 하나의 connection(hub)으로 동시에 연결

*연결 대상: VPC/on-Premise(Direct Connect)/VPN/다른 Transit Gateway

---

⯈다른 NW services

⦁Route 53

: 도메인 주소를 IP 주소로 변환(DNS 서비스화) available, scalable

 

⦁CloudFront

: 캐시 가능한 정적 컨텐츠(웹사이트, 비디오, 앱, APIs)를 빠르게 전송

전 세계의 유저에게 콘텐츠(웹, 앱, 비디오, APIs)를 안정적이고 빠르게 전송 가능한 CDN

(Content Delivery Network)서비스

 

⦁API Gateway

: API 생성, 출시, 유지, 모니터링, 보안을 관리하는 서비스

예)FE에서 BE(API server)로 통신 할 때, 중간에서 관리(API가 지나가는 통로)