[신한투자증권 프로 디지털 아카데미] 클라우드 환경의 이해와 클라우드 보안(1)

 

 

우선 오늘의 tmi) EC2 인스턴스 성능 비교 실험을 한 결과를 발표했다. 어제 저녁에 열심히 리드미를 다시 수정하고 질문에 대해 고민한 덕분에 무시무시한 질문은 받지 않았다. 미리 방어 성공 ! 너무나 다행인 점 우하하 사랑아호두해팀 만세 🙌

 

 

1. 클라우드 활용 기초 - 쉬어가기(이론 정리)

1. CPU 1싸이클의 구성

- CPU는 명령어를 받으면, 기계 사이클을 반복함

- 기계 사이클은 4단계로 구성 = 명령어를 메모리에서 가져오고(Fetch), 해석하고(Decode), 실행하고(Execute), 결과를 저장(Store)

- 이 과정을 거쳐 메모리 or 디스크에 저장됨

 

- 각 사이클마다 다른 연산을 넣을 수 있다

 

2. MKL

: Intel에서 제공하는 고성능 수학 연산 라이브러리, CPU 최적화를 통해 멀티코어 성능을 극대화할 수 있음, 사이클에 대해 더 디테일하게 개발한 것

• 한 사이클 안에서 동시에 계산할 수 있도록 미리 설계되어 있음
• 메모리에서 프로세스를 cpu 에 보낼 때, 어디로 보낼지 최적화를 해두었기 때문에 복잡한 연산을 빠르게 처리할 수 있음

 

3. 하이퍼스레딩(Hyper-Threading)

: 하나의 코어를 두 개로 쪼개서 사용함 = 스레드 개념

• 하나의 물리 코어를 두 개의 논리 코어처럼 동작하게 만들어서 4개의 물리 코어로도 동시에 최대 8개의 스레드 실행이 가능
• 코어 개수는 변하지 않지만 운영체제 입장에선 코어가 2배처럼 보이며 더 많은 작업을 병렬로 처리할 수 있게 됨
• 이 작업을 나누는 걸 OS 에서 스케줄링함
• cf. 하이퍼바이저 : 하나의 물리 머신에서 여러 개의 가상 머신(인스턴스)를 운영할 수 있게 해주는 가상화 관리자, EC2 인스턴스는 하이퍼바이저를 통해 물리 자원을 분할해 vCPU 를 부여받음
• cf. ARM은 하이퍼스레딩을 사용하지 않음 – 물리적 코어를 하나만 사용하는 것

- 스레드는 일하는 사람, 코어는 일할 수 있는 책상, OS 가 프로세스를 배치하는 걸 지시

- 싱글스레드일 때는 시퀀셜하게 일해야 하지만, 멀티코어가 되면서 병렬적으로 스레드를 운영할 수 있음

 

프로그램 : 디스크에 저장된 실행 가능한 파일 - 사용자가 실행하면 메모리에 올라가 하나 이상의 프로세스로 동작
CPU = 프로세서 : 프로세스를 실행하고, 각 프로세스는 하나 이상의 스레드를 가질 수 있음, 실제로 CPU가 처리하는 단위는 '스레드'

 

4. AWS vs vCPU

- CPU 가 각각 멀티 코어를 가지고 있음, 하나의 컴퓨터를 많은 사람에게 나눠주면 나눠줄 수록 비용적으로 이득

- 이걸 더 잘게 쪼개서 판다 = T 계열

- AWS T 계열 인스턴스는 하나의 물리 코어를 여러 사용자에게 쪼개서 제공하는 구조 - 기본 CPU 사용량을 제한하는 대신 버스트(터보) 모드를 통해 일시적인 성능 향상이 가능

- 터보는 성능 저하 가능성이 있음에도 AWS 를 사용하는 이유는 싸니까! wow

 

2. 클라우드 활용 기초 2 - 모듈 2. AWS 컴퓨팅

1. 서버리스

어떤 상황에서 스케일 아웃, 인을 하는지에 대한 고민을 해봐야 한다

그동안 클라우드 ec2 인스턴스를 생성하는 실습을 했었는데 서버리스를 사용하게 되면 람다에 코드를 배포만 하게 되면 사용자가 있을 때 바로 접속이 가능해지고 비용이 매우 적게 발생함

• 프로비저닝하거나 관리할 서버 없음
• 사용량에 따라 크기 조정
• 유휴 리소스에 대한 비용을 지불하지 않음
• 가용성 및 내결함성을 기본 제공

 

 

3. 모듈 3. AWS 네트워킹

1. 네트워킹

 

1. 네트워킹 정의

: 전 세계의 컴퓨터를 연결하여 서로 통신할 수 있도록 하는 방법

 

2. 네트워킹 기본 정보

: looks like 편지를 보내는 일

- 필요한 요소 : 페이로드, 보낸 사람 주소, 받는 사람 주소

- 편지가 목적지에 도착하려면 주소의 모든 부분이 필요함

- 편지(메시지) 전달을 처리하는 것 : 라우팅

 

 

2. Amazon Virtual Private Cloud

 

1. VPC(Virtual Private Cloud)

내 자원을 안전하게 관리하기 위해 격리된 네트워크 환경이 필요한데 그게 VPC - 누구끼리 소통할지 결정을 해야 함

각각의 주소는 독립적이면서 유일해야 함

 

• IP 주소 범위 선택 (CIDR 블록 설정)
  → 내 VPC에서 사용할 내부 네트워크 주소 대역 설정 (예: 10.0.0.0/16)
• 가용 영역(AZ)별 서브넷 설정
  → 퍼블릭/프라이빗 서브넷 나눠서 구성 (각기 다른 가용 영역에 분산 가능)
• 인터넷 경로(Route) 설정
  → 인터넷 게이트웨이 연결 + 라우팅 테이블에 경로 추가 (0.0.0.0/0 → IGW)
• 보안 그룹 설정 (트래픽 제어)
  → 인바운드/아웃바운드 규칙으로 VPC 내부와 외부 간 통신 제어

 

1) IP 주소 범위 선택 - CIDR

• Private IP (사설 IP)
  • 인터넷에서는 직접 사용되지 않고, 내부 네트워크에서만 사용하는 IP 주소
  • 대표적인 범위(대역)는 아래 3가지로 정해져 있음 → RFC 1918에 의해 규정됨

대역 이름	IP 범위
Class A	10.0.0.0 ~ 10.255.255.255
Class B	172.16.0.0 ~ 172.31.255.255
Class C	192.168.0.0 ~ 192.168.255.255

Q. 어떤 경우에는 중복되게 사용할 수 있도록 하자 – 왜?

IP 주소 낭비 방지! - 전 세계에서 고유하게 쓸 수 있는 공인 IP 주소는 한정적인데 회사나 가정 등 내부 네트워크에 있는 장치들까지 전부 공인 IP를 쓴다면 IP가 금방 고갈되기 때문

네트워크가 분리되어 있으면 충돌 안 나기 때문에 이렇게 사용이 가능한 것임

 

cf. 보완 기술 : NAT(Network Address Translation) - 내부에서 중복된 프라이빗 IP로 통신하다가 인터넷으로 나갈 땐 공인 IP로 변환 (NAT 사용)

 2) 서브넷

- /24 는 IP주소의 3자리를 고정하겠다는 의미, 이걸 벗어나게 서브넷을 생성하게 되면 오류 발생

- 만약 a 를 /16 으로 하면 나머지 b를 만들 수 없음 – 왜냐면 가능한 ip 영역을 a 에서 다 가져가버리기 때문, 그래서 172.31.0.0/16 보다 작은 영역으로 생성해야 함 - 만약 서브넷을 한 개만 쓸 거라면 /16 으로 생성해도 상관 없음

 

3) 인터넷 경로

어떤 서브넷에서는 인터넷과 통신할 수 있고, 어떤 서브넷에서는 불가한 서브넷을 만들 수 있음

 

4) VPC의 네트워크 보안 : Network ACLs / Security Groups

- Network ACLs : VPC 내의 서브넷 전체에 적용되는 방화벽 규칙, 보안 그룹(SG)과는 다르게 서브넷 수준에서 동작

Stateless 로 동작함

• Stateless (비상태적) 동작 : 트래픽의 상태를 기억하지 않으므로 들어오는 트래픽과 나가는 트래픽을 각각 따로 허용해야 함

Security group : EC2 인스턴스 단위로 동작, Stateful 로 동작

기본적으로 모든 트래픽을 차단하는 허용 기반 정책

• 인바운드: 명시적으로 허용하지 않으면 무조건 차단
• 아웃바운드: 기본은 모두 허용, 그러나 변경 가능

→ 처음에는 EC2에 들어오는 요청은 아무것도 못 들어오고, 허용 규칙을 지정해야만 통신이 가능

 

---

 

✅ AWS EC2 인스턴스 보안에서의 적용

🔒 Security Group = Stateful

• 자동 응답 허용
  → 인바운드에서 허용된 요청은 자동으로 아웃바운드 응답도 허용됨.
• 예시: 포트 22(SSH) 인바운드 허용 시, 그 세션의 응답은 자동으로 나감.
• 설정이 간단하고, 애플리케이션 단위 보호에 적합

📌 왜 stateful인가?
→ Connection 상태(세션)를 기억하므로, 들어온 요청에 대한 응답 트래픽은 별도 허용 필요 없음.

 

🔐 Network ACL = Stateless

• 인바운드/아웃바운드를 별도로 명시적으로 허용해야 함
• 예시: 포트 80 인바운드 허용 시, 포트 80 아웃바운드도 따로 허용해야 정상적인 통신 가능
• 서브넷 단위 제어에 적합 (보통 보조 보안 계층으로 사용)

📌 왜 stateless인가?
→ 각각의 패킷은 독립적으로 처리되므로, 응답도 새 요청처럼 취급되기 때문.