Merge pull request #76 from gdsc-ssu/hyeongkyu/restore

[week 20] Restoring Branch

Author: halfmoon-mind

AWS/STORAGE/img/스크린샷 2024-10-14 오후 10.19.51.png

@@ -0,0 +1,131 @@
+
+## 들어가기 전에 
+
+띵진 님의 네트워크 강의 시간에 다 공부했을 것 같은데 들어가기 전에 보안 그룹 CIDR이 무엇인지부터 알아보고 가도록 하겠습니다. (제가 네트워크가 오랜만이어서,,,,)
+
+#### CIDR
+네트워크 설계를 하면서 가장 많이 접하게 될 개념이 CIDR인데요 많이 들어보셨을 것 같습니다.
+풀네임은 Classless Inter-Domain Routing 로 클래스 없는 도메인간 라우팅 기법이라는 뜻입니다.
+
+선생님~ IP 주소 클래스 체계 배울 때는 서브넷 마스크랑 서브네팅을 배웠던 것 같은데 대체 뭔 차이인가요?
+
+서브네팅도 IP 클래스에 국한 되지않고 더욱더 IP 주소를 쪼개는 방식을 말하는 것인데 이게 바로 클래스 없는 도메인간 라우팅 기법입니다. 
+즉, 서브네팅은 CIDR의 subset이라고 볼 수 있죠
+
+#### CIDR 표기법
+
+![[스크린샷 2024-10-08 오후 4.39.06.png]]
+
+192.168.10.70/26
+서브네팅 배울 때 서브넷 마스크를 짧게 적은 prefix라고 배웠겠지만 이거시 바로 cidr이자 cidr 표기법입니다. 
+
+==단 한줄만으로 네트워크 범위를 추측 또는 측정== 할 수 있다. 
+![[스크린샷 2024-10-08 오후 4.39.47.png]]
+![[스크린샷 2024-10-08 오후 4.40.09.png]]
+
+결과 => 분리된 4개의 네트워크와 각 62개의 호스트를 가진 네트워크르 사용한다는 것을 의미하고 자신은 2번째 네트워크에 속함을 나타냅니다. 
+
+#### AWS CIDR
+그럼 이제 aws의 CIDR를 알아봅시당
+
+서브넷을 AWS에서는 CIDR 블럭이라고 합니다
+
+AWS VPC를 학습할 때 중요한 개념이기도한 CIDR은 앞선 내용과 다를게 없습니다. 
+VPC를 구성할 때 다음 CIDR값이 있다면 VPC는 16을 서브넷 값으로 하는 IP 주소 범위를 나타내는 것입다.
+
+
+## 관리형 접두사 목록
+
+> 관리형 접두사 목록은 하나 이상의 CIDR 블록 세트 입니다. 접두사 목록을 사용하면 ==보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지 관리 할 수 있습니다.== 
+**즉, 관리형 접두사 목록을 사용해서 보다 쉽게 많은 수의 IP 주소들을 관리할 수 있다는 것이죠.**
+
+![[스크린샷 2024-10-08 오후 4.40.32.png]]
+
+내가 SSH 통신을 허용해야 하는 IP 주소가 4개일 경우 이미지와 같이 4개의 IP 주소를 허용해야 합니다. 
+
+허용해야 하는 IP 주소가 많아지게 되면?? -> 관리하기가 힘들어진다....
+
+vpc -> 관리형 접두사 목록에서 접두사 목록 생성을 눌러줍니다. 
+
+![[스크린샷 2024-10-08 오후 4.40.56.png]]
+
+
+여기서 최대 항목의 경우 관리할 IP 주소의 최대 허용 수를 의미하는데, 
+
+최소 1개에서 1000개까지 허용한다. 
+
+최대 항목은 접두사 목록을 생성하고 나서 수정이 가능합니다다.
+
+![[스크린샷 2024-10-08 오후 4.41.15.png]]
+
+이제 보안 그룹에서 접두사 목록을 추가할 수 있게 되었습니다. 
+
+![[스크린샷 2024-10-08 오후 4.41.35.png]]
+
+이렇게 접두사 목록을 추가해서 깔끔하게 보안 그룹을 관리할 수 있다. 
+
+(저는 그동안 0.0.0.0/0으로 welcome 마인드로 열어놓았는데 그러면 보안 이슈 때문에 그러면 안 될 것 같습니다. 이번 기회에 바꿔야지...)
+
+임시로 테스트하기 위한 개인 컴퓨터의 IP 주소를 관리형 접두사 목록에 넣어놨다가 테스트가 끝나면 목록에서 해당 IP 주소를 삭제해주면 됩니다.
+
+왜 인스턴스에 대한 인바운드 통신을 허용하는 CIDR 블로 목록을 업데이트해야 하는 경우 보안 그룹 대신 접두사 목록을 업데이트해야 하나요?
+==오버 헤드를 줄일 수 있기 떄문!! ==
+
+
+## 교재 실습 설명
+
+![[스크린샷 2024-10-08 오후 4.41.54.png]]
+**문제 설명**
+위에서 알아봤던 점과 비슷합니다
+퍼블릭 서브넷의 인스턴스에서 특정 엑세스 요구 사항을 가진 2개의 애플리케이션을 호스팅하고 있다. 대부분 작동 시간 중에는 다른 리전의 가상 데스크톱에서 액세스하지만 테스트 기간에는 집 PC에서 접근해야 한다. 
+
+**해결 방법**
+AWS가 제공하는 IP 주소 범위 목록을 사용해 해당 리전의 WorkSpces 게이트웨이의 CIDR 범위 목록을 포함하는 관리형 접두사 목록을 각각 만들어 보안 그룹에 연결한다. 테스트를 위해서는 임시로 집의 IP 주소를 접두사 목록에 추가했다가 테스트 종료 시 IP 주소를 삭제한다. 
+
+1. aws IP 주소 범위를 가진 JSON 파일을 다운로드한다. 
+```
+curl -o ip-ranges.json https://ip-ranges.amazonaws.com/ip-ranges.json
+```
+이 파일에는 AWS 서비스가 사용하는 IP 주소 범위가 있는데요 리전 및 서비스 별로 IP 주소가 있습니다. 
+
+2. 특정 리전 및 서비스에 대한 CIDR 범위 선택
+```
+jq -r '.prefixes[] | select(.region=="us-west-2") | select(.service=="WORKSPACES_GATEWAYS") | .ip_prefix' ip-ranges.json
+```
+특정 서비스와 리전에 대한 IP 범위를 필터링하여 필요한 정보만 가져오는 것입니다.
+
+3. 접두사 목록 생성
+```
+PREFIX_LIST_ID=$(aws ec2 create-managed-prefix-list \
+--address-family IPv4 \
+--max-entries 15 \
+--prefix-list-name allowed-us-east-1-cidrs \
+--output text --query "PrefixList.PrefixListId" \
+--entries Cidr=44.234.54.0/23,Description=workspaces-us-west-2-cidr1 Cidr=5.4.244.46.0/23,Description=workspaces-us-west-2-cidr2)
+```
+새로운 관리형 접두사 목록을 생성하는 모습이고 최대 항목의 수는 15개로 지정해준 모습이네요
+
+4. 이제 내 IP 주소를 넣을 차례입니다. 
+```
+MY_IP_4=$(curl myip4.com | tr -d ' ')
+```
+이 주소는 사용자가 현재 인터넷에 연결된 IP 주소입니다. 
+
+```
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id $PREFIX_LIST_ID \
+--current-version 1 \
+--add-entries Cidr=${MY_IP_4}/32,Description=my-workstation-ip
+```
+접두사 목록 버전을 업데이트하고 새로운 IP 주소 항목을 추가하는 코드입니다. 
+
+5. 만들었으니 이제 보안 그룹 인바운드 규칙을 추가해봅시다. 
+```
+aws ec2 authorize-security-group-ingress \
+--group-id $INSTANCE_SG_1 --ip-permissions \
+IpProtocol=tcp,FromPort=80,ToPort=80,PrefixListIds="[{Description=http-from-prefix-list,PrefixListId=$PREFIX_LIST_ID}]"
+```
+보안 그룹의 인바운드 규칙에 접두사 목록을 추가해서 TCP 포트 80에 대한 접근을 허용해줍니다. 
+~~ 보안 그룹의 특정 포트에 대해서 접두사 목록에 포함된 IP주소만 접근을 허용해주는 것이죠
+
+앞에서 잠깐 보셨듯이 접두사 목록은 버전 관리 메커니즘을 제공합니다. 접두사 목록을 업데이트한 뒤 기존 기능이 중단된 경우 오류의 원인을 파악하는 동안 이전 버전으로 롤백해 이전 기능을 복원할 수 있습니다. 

AWS/vpc/2.8 접두사 목록을 활용한 보안 그룹 CIDR 관리.md

@@ -0,0 +1,61 @@
+## Serverless 와 람다
+
+**Serverless의 특징**
+1. 오토스케일링
+	 싼 가격에 오토스케일링까지 해준다. ec2는 로드밸런서 붙여야 되는데 
+2. 패칭
+3. 빠른배포
+
+서버를 구성하는 것은 서버 하드웨어만 있는 것이 아니다. 다음과 같은 것이 있어야 서버로서의 역할을 한다. 
+- 인터넷 망
+- 서버 하드웨어
+- 서버 운영체제
+- 서버 미들웨어 
+- 서버 애플리케이션
+
+클라우드 서버를 구축하는 경우 위에 중 인터넷 망, 서버 하드웨어, 서버 운영체제 부분까지는 구축하는 노력을 안해도 된다. 클라우드 서버가 인기가 있는 이유이기도 하다. 
+
+그러나 사람들은 서버 미들웨어와 서버 어플리케이션도 노력을 안 하게 만드는 방법을 연구했고, 그 결과 서버리스 아키텍처가 등장하게 되었다. 
+
+
+>[!서버 미들웨어가 무엇일까]
+>애플리케이션과 운영체제 사이에서 중요한 역할을 하는 소프트웨어 계층이다. 주로 다음과 같은 기능을 제공한다. 
+>- 통신 관리 : 클라이언트와 서버 간의  데이터 통신을 관리한다.
+>- 데이터 관리 : 데이터베이스와의 연결을 관리하고 어플리케이션이 데이터베이스와 상호 작용할 수 있도록 지원한다. 
+>- 로드 밸런싱 : 여러 서버에 걸쳐 요청을 분산 시켜서 서버 부하를 관리하고 성능을 최적화 한다. 
+>- 보안 관리 : 인증, 권한 부여, 암호화 등을 통해 애플리케이션의 봔을 강화한다. 
+>- 서비스 통합 ; 서로 다른 애플리케이션과 서비스 간의 통합을 지원한다. 예를 들어 다양한 API를 통해 다른 시스템과 연동한다.
+- 웹 서버 : Apache, Nginx
+- 애플리케이션 서버 : Apache Tomcat
+- 메시징 미들웨어 : RabbitMQ
+- 데이터베이스 미들웨어 : Hibernate, MyBatis. 
+
+전체 시스템의 효율성을 높이고, 다양한 애플리케이션과 서비스가 원할하게 동작할 수 있도록 지원하는 중요한 역할을 한다. 
+
+"미들웨어 이런 것들은 로드밸런싱이랑 보안 이런거 꼭 들어가는 것 같다. 캐싱도 "
+
+### Lamda 
+
+매우 싸다. 
+
+**특징**
+- 람다함수의 런타임
+	- 최대 5분의 런타이만 제공한다. -> 무겁고 너무 복잡한 서비스를 돌리기는 힘들 것 같다. 
+- 람다함수 공간 제공 : 가상 디스크 제공으로 일시적으로 512MB의 공간을 사용할 수 있다. 
+- 허용 배포 패키지 
+
+
+## 로드밸런서
+
+프록시 
+가장 큰 특징 3가지 
+
+1. 캐싱
+2. 보안
+3. 로드밸런싱
+
+L4 : 싸다 
+하지만 Transfer계층에서만 다루기 때문에 패킷 수준에서 다루어지게 된다. 그렇기 때문에 할 수 있는게 많이 없다. 
+ex) 로그인된 사용자와 로그인되지 않은 사용자를 구분하고 싶다. -> L7써야되
+
+L7 : 비싸다 (어플리케이션 레벨)

AWS/vpc/img/스크린샷 2024-10-08 오후 4.39.06.png

@@ -0,0 +1,24 @@
+# CIDR
+
+### CIDR 개요
+CIDR은 IP 주소를 네트워크 클래스에 의존하지 않고 더 유연하게 나누는 기법으로, 서브네팅의 확장된 개념이다. IP 주소 클래스 시스템에서 벗어나 더욱 세밀하게 IP 주소를 분할하고 관리할 수 있다. 
+
+###### CIDR 표기법 
+CIDR 표기법은 IP 주소/프리픽스 길이 형식으로 표현이 된다 
+
+**Aws 에서 CIDR**
+AWS에서는 vpc 설계 시 CIDR을 사용하여 IP 주소 범위를 설정한다. AWS VPC를 구성할 때 CIDR 블록을 사용해 네트워크를 정의하며, AWS 내 보안 그룹과 라우팅 테이블에서 관리형 접두사 목록을 활용하여 보다 쉽게 IP 주소를 관리할 수 있다. 
+
+### 관리형 접두사 목록
+
+관리형 접두사 목록은 여러 개의 CIDR 블록 세트이다. 보안 그룹 또는 라우팅 테이블을 관리할 때, 접두사 목록을 사용하면 많은 수의 IP 주소를 보다 효율적으로 관리할 수 있다. 예를 들어, 여러개의 IP 주소를 허용해야 하는 상황에서, 각각을 개별적으로 추가 하는 대신 접두사 목록을 생성해 보안 그룹에서 해당 목록을 참조하는 방식으로 관리가 가능하다. 
+
+
+> [!note]
+> 관리형 접두사 목록을 업데이트함으로써 보안 그룹의 규칙을 변경하지 않고도 허용할 IP 범위를 쉽게 변경할 수 있으며, 이를 통해 관리의 오버헤드를 줄일 수 있다.
+
+
+**접두사 목록의 이점**  
+• **효율적 관리**: 많은 IP 주소를 간편하게 관리할 수 있다.  
+• **버전 관리 가능**: 접두사 목록은 버전 관리 기능을 제공하여 업데이트 후 문제가 발생할 경우 이전 버전으로 롤백할 수 있다.
+

AWS/vpc/img/스크린샷 2024-10-08 오후 4.39.47.png

@@ -0,0 +1,57 @@
+
+#### S3 수명 주기 정책을 사용한 스토리지 비용 절감
+
+자주 사용하지 않는 객체를 비용 효율적인 스토리지 계층으로 자동 전환하여 운영 오버헤드를 줄이고자 하는 것이 목표이다. 
+
+비용 절감 : 자주 사용되지 않는 데이터를 저렴한 스토리지로 자동 이동해 비용을 줄일 수 있다. 
+
+자동 정리 : 설정한 기간 이후 오래된 데이터를 자동으로 삭제해 저장 공간을 효율적으로 관리한다. 
+데이터 관리 관소화 : 수동 관리 없이 데이터 저장 및 삭제를 자동화한다. 
+
+해결 방법으로 30일 이후에 S3 IA 스토리지 클래스로 전환하는 수명 주기 정책을 생성하고 S3 버킷에 적용한다. 
+
+#### Storage class  종류 
+
+![[스크린샷 2024-10-14 오후 10.19.51.png]]
+
+**1. S3 Standard**
+• **특징**: 자주 접근되는 데이터를 저장하는 기본 클래스
+• **사용 사례**: 빈번하게 접근해야 하거나 높은 내구성과 성능이 요구되는 데이터
+• **비용**: 가장 높은 비용, 높은 내구성(99.999999999%)과 가용성(99.99%)
+• **복구 시간**: 즉시 접근 가능
+
+**2. S3 Intelligent-Tiering**
+• **특징**: 액세스 패턴에 따라 자동으로 데이터를 Frequent Access와 Infrequent Access 티어로 이동
+• **사용 사례**: 액세스 패턴이 예측 불가능하거나 일정하지 않은 데이터
+• **비용**: 액세스 빈도에 따라 비용 최적화, 모니터링 비용 있음
+• **복구 시간**: 즉시 접근 가능 (Frequent/IA 티어 모두)
+
+**3. S3 Standard-IA (Infrequent Access)**
+• **특징**: 자주 접근하지 않지만 필요할 때 빠르게 접근해야 하는 데이터
+• **사용 사례**: 백업, 재해 복구, 자주 사용하지 않는 중요한 데이터
+• **비용**: 저장 비용이 낮지만 데이터 액세스 시 추가 요금 발생
+• **복구 시간**: 즉시 접근 가능
+
+**4. S3 One Zone-IA**
+• **특징**: 단일 가용 영역(Availability Zone)에만 저장, 비용 절감
+• **사용 사례**: 재해 복구 대비가 필요 없고, 덜 중요한 데이터를 저장할 때
+• **비용**: S3 Standard-IA보다 저렴하지만 내구성이 낮음
+• **복구 시간**: 즉시 접근 가능
+
+**5. S3 Glacier**
+• **특징**: 장기 보관용 저비용 아카이브 스토리지
+• **사용 사례**: 자주 접근하지 않지만 장기적으로 저장해야 하는 데이터 (예: 규정 준수를 위한 데이터 보관)
+• **비용**: 매우 저렴하지만, 데이터 복구 요청 시 추가 비용 발생
+• **복구 시간**: 몇 분에서 몇 시간 (고속 검색 옵션으로 몇 분 내 복구 가능)
+
+**6. S3 Glacier Deep Archive**
+• **특징**: 가장 저렴한 스토리지, 매우 장기적인 데이터 보관용
+• **사용 사례**: 극히 드물게 액세스하지만, 법적 요구 등으로 장기간 보관이 필요한 데이터
+• **비용**: S3 스토리지 클래스 중 가장 저렴
+• **복구 시간**: 수 시간에서 최대 12시간
+
+**7. S3 Outposts**
+• **특징**: 온프레미스에서 S3 스토리지를 사용하는 경우에 적합
+• **사용 사례**: 로컬 환경에서 데이터 저장 및 처리 필요 시
+• **비용**: 온프레미스 설치 비용과 사용 비용 발생
+• **복구 시간**: 즉시 접근 가능