잡학다식 개발일지

CloudFront (AWS CloudFront) 

📌 Amazon Web Services(AWS)에서 제공하는 콘텐츠 전송 네트워크(CDN) 서비스입니다.

• CloudFront는 웹 콘텐츠(이미지, 동영상, HTML 파일 등)를 전 세계 사용자에게 빠르고 안전하게 전달하기 위해 설계되었습니다.
• 말 그대로 콘텐츠 전송 네트워크(CDN) 인데 아래의 파란색 글을 참고하면 이해가 쉽다.

CloudFront의 주요 특징

1. 콘텐츠 캐싱
   • CloudFront는 사용자 가까운 위치(엣지 로케이션, Edge Location)에서 콘텐츠를 캐싱하여 전송 속도를 향상시킵니다.
   • 사용자 요청 시 콘텐츠를 캐싱 서버에서 제공하므로 원본 서버(예: S3 또는 EC2) 부하를 줄일 수 있음.
2. 글로벌 엣지 로케이션
   • CloudFront는 AWS의 글로벌 엣지 로케이션 네트워크를 활용.
     • 엣지 로케이션은 전 세계 여러 지역에 분포한 데이터센터로, 사용자와 가까운 위치에서 콘텐츠를 제공.
3. 보안 강화
   • HTTPS 지원 및 데이터 암호화를 통해 전송 중 데이터의 보안을 보장.
   • AWS WAF(웹 애플리케이션 방화벽)와 통합하여 DDoS 공격 방지.
4. 동적/정적 콘텐츠 지원
   • 정적 콘텐츠(이미지, CSS, JS 등)뿐만 아니라 동적 콘텐츠(API 응답, HTML 등)도 효율적으로 전달 가능.
5. 통합된 AWS 서비스
   • S3, EC2, Elastic Load Balancer, API Gateway와 쉽게 통합 가능.

CloudFront의 주요 구성 요소

CloudFront의 동작 방식

1. 사용자 요청
   • 사용자가 CloudFront 배포의 URL(예: https://d123abc.cloudfront.net/image.jpg)에 콘텐츠를 요청.
2. 엣지 로케이션 확인
   • 요청이 가장 가까운 **엣지 로케이션(Edge Location)**으로 라우팅.
3. 캐시 확인
   • 엣지 로케이션에 요청한 콘텐츠가 캐싱되어 있다면, 캐시에서 즉시 제공.
   • 캐싱되지 않았다면, CloudFront가 원본 서버(예: S3, EC2)에서 콘텐츠를 가져옴.
4. 콘텐츠 제공 및 캐싱
   • 가져온 콘텐츠를 사용자에게 제공하고, 엣지 로케이션에 캐싱하여 이후 요청 시 빠르게 제공.

CloudFront의 주요 사용 사례

1. 웹사이트 콘텐츠 배포
   • 정적 파일(이미지, CSS, JavaScript 등)과 동적 콘텐츠(API 응답, HTML)을 빠르게 제공.
   • 예: S3에 저장된 정적 웹사이트 콘텐츠를 전 세계 사용자에게 빠르게 배포.
2. 비디오 스트리밍
   • 대용량 비디오 파일을 전 세계적으로 스트리밍.
   • 예: MP4 비디오 또는 HLS(MPEG-DASH)로 실시간 스트리밍 제공.
3. 애플리케이션 콘텐츠 가속
   • API 응답, 데이터베이스 결과 등의 동적 콘텐츠 전송을 가속화.
   • 예: RESTful API 또는 GraphQL API 가속.
4. 보안 강화
   • HTTPS를 통한 데이터 암호화 및 AWS WAF를 사용하여 DDoS 공격 방지.
   • 예: EC2 서버나 S3 버킷 앞에 CloudFront를 배치해 직접 접근 차단.
5. 소프트웨어 배포
   • 소프트웨어 설치 파일, 업데이트 파일 등을 효율적으로 전 세계에 배포.

CloudFront의 TTL(Time To Live)

• TTL은 콘텐츠가 엣지 로케이션에 얼마나 오래 캐싱되는지 정의.
• 짧은 TTL: 원본 서버의 변경 사항을 빠르게 반영.
• 긴 TTL: 원본 서버 부하 감소, 빠른 응답 시간 제공.

CloudFront와 S3의 차이점

CloudFront의 장단점

CloudFront를 쉽게 이해하기

CloudFront는 **"AWS에서 제공하는 글로벌 CDN"**입니다.

• 사용자가 요청한 콘텐츠(이미지, 동영상 등)를 **가장 가까운 서버(엣지 로케이션)**에서 빠르게 제공.
• 캐싱을 통해 콘텐츠 제공 속도를 높이고 원본 서버의 부하를 줄입니다.
• 보안 기능을 통해 안전한 콘텐츠 전송을 보장합니다.

Content Delivery Network

 🐳 전 세계 여러 지역에 분산된 서버 네트워크를 통해 사용자에게 콘텐츠(웹페이지, 이미지, 동영상 등)를 더 빠르고 안정적으로 전달하는 기술입니다.

• CDN은 사용자와 가까운 서버에서 콘텐츠를 제공함으로써 지연(latency)을 줄이고, 속도를 높이며, 서버의 부하를 분산시킵니다.

CDN의 동작 방식

1. 사용자 요청
   • 사용자가 웹사이트에 접속하거나 콘텐츠를 요청(예: 이미지를 다운로드, 동영상을 스트리밍).
2. 가장 가까운 CDN 서버로 라우팅
   • 요청은 **사용자와 물리적으로 가까운 CDN 서버(엣지 서버)**로 라우팅됩니다.
   • 이 과정은 DNS와 CDN 제공업체의 라우팅 시스템을 통해 처리.
3. 캐싱된 콘텐츠 제공
   • 요청한 콘텐츠가 CDN 서버(엣지 서버)에 캐싱되어 있다면, 이 서버에서 바로 사용자에게 전달.
   • 캐시된 콘텐츠가 없으면 원본 서버에서 콘텐츠를 가져와 사용자에게 제공하고, 동시에 CDN 서버에 캐싱.
4. 캐시 유지 및 만료
   • 콘텐츠는 일정 기간 동안 CDN 서버에 저장(캐싱)되며, 만료된 콘텐츠는 갱신.

CDN의 주요 구성 요소

CDN의 주요 기능

1. 콘텐츠 캐싱
   • 정적 콘텐츠(이미지, CSS, JS, 동영상 등)를 캐싱하여 빠르게 제공.
2. 지리적 분산
   • 전 세계 사용자에게 콘텐츠를 빠르게 전달하기 위해 엣지 서버를 지리적으로 분산.
3. 속도 향상
   • 사용자와 가까운 서버에서 콘텐츠를 제공함으로써 네트워크 지연(latency) 최소화.
4. 서버 부하 분산
   • 원본 서버의 요청 수를 줄여 부하를 분산시키고 안정성을 높임.
5. 보안 강화
   • HTTPS 지원, DDoS 공격 방지, 방화벽(WAF)과 통합 가능.
6. 애플리케이션 가속
   • 동적 콘텐츠(API 응답 등)도 최적화된 경로로 전송하여 속도 개선.

CDN의 주요 사용 사례

1. 정적 웹사이트 호스팅
   • 이미지, 동영상, HTML, CSS, JavaScript 등 정적 콘텐츠를 사용자에게 빠르게 제공.
2. 비디오 스트리밍
   • Netflix, YouTube 같은 서비스에서 대규모 동영상을 스트리밍할 때 사용.
3. API 및 동적 콘텐츠 가속
   • REST API, GraphQL API 등과 같은 동적 데이터 응답 속도를 최적화.
4. 전자상거래
   • 제품 이미지, 웹페이지 로딩 속도를 개선하여 사용자 경험 향상.
5. 소프트웨어 배포
   • 애플리케이션 업데이트 파일, 소프트웨어 설치 파일 등을 전 세계 사용자에게 신속히 배포.

CDN의 장점

CDN의 단점

AWS CloudFront와의 관계

AWS의 CloudFront는 대표적인 CDN 서비스로, 다음과 같은 기능을 제공합니다:

1. S3, EC2와 통합: AWS 서비스와의 원활한 연동.
2. 엣지 로케이션 제공: 전 세계적으로 분산된 엣지 서버를 통해 빠른 콘텐츠 제공.
3. 보안 옵션: HTTPS, WAF, DDoS 방지 지원.

쉽게 이해하기

• **CDN은 "전 세계에 퍼져 있는 콘텐츠 배달 네트워크"**입니다.
  • 사용자와 가까운 위치에서 콘텐츠를 전달하므로 빠르고 안정적인 서비스를 제공합니다.
  • 예: 사용자가 미국에 있고, 원본 서버가 한국에 있다면, CDN은 미국에 있는 서버에서 콘텐츠를 제공하여 로딩 시간을 줄입니다.

Invalidation(인밸리데이)

 🐳 엣지 로케이션(캐시 서버)에 저장된 콘텐츠를 무효화(삭제)하여, 원본 서버에서 최신 콘텐츠를 가져오도록 만드는 작업입니다.

[ 그래서 뭔말인가? ]

왜 Invalidation이 필요한가?

CDN은 콘텐츠를 캐싱하여 제공하므로, 원본 서버에서 콘텐츠가 변경되어도 엣지 로케이션(캐시 서버)에 저장된 데이터는 자동으로 갱신되지 않습니다.
따라서, 캐시된 데이터와 원본 데이터가 달라질 수 있는 상황에서 Invalidation을 수행하여 최신 데이터를 제공할 수 있습니다.

Invalidation의 동작 방식

1. 사용자가 특정 객체 또는 경로에 대해 Invalidation 요청을 수행.
2. CloudFront는 지정된 객체(캐시된 콘텐츠)를 무효화(삭제).
3. 다음 요청이 들어오면, CloudFront는 원본 서버에서 최신 콘텐츠를 가져와 캐싱하고 사용자에게 제공.

Invalidation의 주요 특징

1. 대상 지정
   • 특정 파일(예: image.jpg)이나 전체 경로(예: /images/*)에 대해 Invalidation 수행 가능.
2. TTL(Time-To-Live)와 관계 없음
   • Invalidation은 캐시의 TTL 설정과 상관없이 즉시 무효화 작업을 실행.
3. 비용 발생
   • 매월 1,000개의 요청은 무료.
   • 이후 추가 요청은 비용 발생(1,000개당 약 $0.005).
4. 빠른 반영
   • Invalidation 요청은 대부분 몇 초에서 몇 분 내에 처리.

Invalidation 요청 방법

1. CloudFront 콘솔에서 수행
   AWS Management Console에서 CloudFront 배포를 선택 후, Invalidation 요청을 생성.
2. AWS CLI 사용
   예:
3. aws cloudfront create-invalidation --distribution-id EXAMPLE123 --paths "/images/*"
4. API 호출
   AWS SDK 또는 HTTP API를 사용해 Invalidation 요청을 생성.

Invalidation 요청의 예

1. 특정 파일 무효화

/image1.jpg

• 엣지 로케이션에 캐시된 image1.jpg를 삭제하고 최신 버전을 가져오도록 설정.

2. 특정 경로의 모든 파일 무효화

/images/*

• /images/ 디렉토리에 있는 모든 파일을 삭제.

3. 전체 캐시 무효화

/*

• CloudFront 배포에 캐시된 모든 콘텐츠를 삭제(비용이 높을 수 있음).

Invalidation vs TTL

Invalidation의 주요 사용 사례

1. 콘텐츠 변경 후 즉시 반영
   • 웹사이트의 CSS, JS, 이미지가 업데이트된 경우 캐시를 무효화하여 최신 파일 제공.
2. 긴 TTL 설정으로 캐시가 오래 유지되는 경우
   • 캐시 TTL이 길게 설정되었지만, 원본 서버의 콘텐츠가 변경된 경우.
3. 긴급 콘텐츠 변경
   • 중요한 정보나 이미지를 긴급하게 업데이트해야 할 때.
4. 동적 콘텐츠 제공
   • 특정 콘텐츠가 자주 업데이트되어 캐시를 수동으로 관리해야 하는 경우.

Invalidation 요청을 최소화하는 방법

1. 파일 이름 버전 관리
   • 파일 이름에 버전을 포함하여 변경 시 새 이름을 사용.
   • 예: style-v1.css → style-v2.css.
   • 이 방법은 Invalidation 요청 없이도 새 파일을 캐시하도록 강제.
2. 적절한 TTL 설정
   • 캐시 만료 주기를 적절히 설정하여 Invalidation 빈도를 줄임.
3. 부분 Invalidation 사용
   • 전체 경로나 모든 파일을 무효화하는 대신, 필요한 파일만 지정.

쉽게 이해하기

• Invalidation은 "CDN 캐시를 강제로 갱신"하는 작업입니다.
• 예: CloudFront에 저장된 오래된 이미지 파일을 최신 파일로 교체하려면, 해당 파일을 Invalidation 요청하여 새 버전이 제공되도록 설정.

ACL (Access Control List) 

📌 네트워크 리소스나 데이터에 대한 접근 권한을 제어하는 규칙의 목록입니다.

• AWS에서 ACL은 S3와 VPC를 중심으로 사용되며, 각각 다른 역할을 수행합니다.

AWS에서의 ACL 종류

1. S3 ACL
   • S3 버킷 및 객체에 대한 접근 권한을 설정.
   • 리소스 수준에서 권한을 제어.
2. 네트워크 ACL (NACL, Network ACL)
   • VPC 내 서브넷의 네트워크 트래픽을 허용하거나 거부하는 규칙.

S3 ACL (Access Control List)

S3 ACL의 역할

• S3 버킷이나 객체(파일)에 대한 읽기/쓰기 권한을 설정.
• 특정 사용자나 그룹(예: AWS 계정, 익명 사용자)에게 권한 부여.

S3 ACL의 주요 특징

1. 리소스 수준에서 동작
   • ACL은 S3 버킷 전체 또는 개별 객체에 대해 설정 가능.
2. 권한 부여 대상 (Grantee)
   • 특정 AWS 계정.
   • 익명 사용자(인터넷에 공개).
   • AWS 서비스 (예: CloudFront).
3. 권한 유형
   • READ: 읽기 권한 (예: 객체 다운로드).
   • WRITE: 쓰기 권한 (예: 객체 업로드).
   • FULL_CONTROL: 전체 권한.

예시

• S3 버킷의 모든 객체를 익명 사용자에게 읽기 권한 부여:

  {
    "Grantee": {
      "Type": "Group",
      "URI": "http://acs.amazonaws.com/groups/global/AllUsers"
    },
    "Permission": "READ"
  }
  

S3 ACL과 버킷 정책의 비교

네트워크 ACL (NACL)

NACL의 역할

• VPC 내 서브넷에 출입하는 **네트워크 트래픽(인바운드/아웃바운드)**을 제어.
• 허용/거부 규칙을 설정하여 특정 트래픽을 차단하거나 허용.

NACL의 주요 특징

1. 서브넷 수준에서 동작
   • NACL은 VPC 내에서 특정 서브넷에 대해 트래픽 제어를 수행.
2. 규칙 번호에 따른 순서
   • 각 규칙은 번호로 정의되며, 번호가 낮은 규칙부터 우선 적용.
3. 기본 동작
   • 새로 생성된 NACL은 모든 트래픽을 명시적으로 차단.
4. 스테이트리스(Stateless)
   • 스테이트리스: 요청 트래픽과 응답 트래픽을 개별적으로 처리.
   • 예: 인바운드 규칙에 허용하더라도, 아웃바운드 규칙에 허용하지 않으면 응답이 차단됨.

NACL 규칙 구성 요소

예시

• 모든 IP 주소에서 서브넷으로 오는 HTTP(포트 80) 트래픽 허용:

  Rule #100 | Protocol: TCP | Port Range: 80 | Source: 0.0.0.0/0 | Action: ALLOW
  

NACL과 보안 그룹의 비교

ACL의 주요 사용 사례

1. S3 ACL
   • 정적 웹사이트 호스팅: 특정 버킷의 모든 객체를 공개하여 읽기 가능하도록 설정.
   • 버킷 내 특정 객체 보호: 특정 사용자만 읽거나 쓸 수 있도록 제한.
2. 네트워크 ACL
   • 서브넷 보호: 서브넷으로 들어오는 비정상적인 트래픽 차단.
   • IP 차단: 특정 IP 주소나 범위에서의 접근을 거부.

쉽게 이해하기

• S3 ACL:
  S3에 저장된 파일에 대해 누가 읽고, 쓸 수 있는지를 정하는 권한 설정.
  예: 특정 사용자는 파일 읽기만 가능, 다른 사용자는 파일 수정 가능.
• 네트워크 ACL:
  네트워크를 출입하는 트래픽을 통과시킬지, 차단할지를 정하는 규칙.
  예: 서브넷에 특정 IP에서만 접근 허용, 나머지는 차단.

ARN (Amazon Resource Name)

📌 AWS 리소스를 고유하게 식별하기 위한 이름 규칙입니다.

• AWS의 모든 서비스와 리소스는 ARN을 사용하여 참조되며, 이를 통해 특정 리소스를 정확히 지정할 수 있습니다.

[AWS의 리소스란]

ARN의 구조

ARN은 다음과 같은 구조적 형식을 따릅니다:

arn:partition:service:region:account-id:resource

구성 요소 설명

             - 일반적으로 "aws" 사용.  
             - 다른 옵션: `aws-cn`(중국 리전), `aws-us-gov`(AWS GovCloud). |

| service | 리소스가 속한 AWS 서비스 이름. 예: s3, ec2, dynamodb. | | region | 리소스가 속한 AWS 리전. 예: us-east-1, ap-northeast-2. | | account-id | AWS 계정 ID(12자리 숫자). 특정 리소스가 AWS 계정에 속해 있는 경우 사용. | | resource | 리소스의 고유 식별자. 서비스에 따라 형식이 다름. |

ARN 예시

1. S3 버킷

arn:aws:s3:::my-bucket

• partition: aws (글로벌 S3 리소스).
• service: s3.
• region: 비워둠(S3 버킷은 리전과 무관).
• account-id: 비워둠(S3는 계정 ID 필요 없음).
• resource: my-bucket.

2. S3 객체

arn:aws:s3:::my-bucket/my-object.txt

• resource: 버킷 이름과 객체 이름.

3. EC2 인스턴스

arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0123456789abcdef0

• service: ec2.
• region: ap-northeast-2 (서울 리전).
• account-id: 123456789012.
• resource: EC2 인스턴스 ID(i-0123456789abcdef0).

4. Lambda 함수

arn:aws:lambda:us-east-1:123456789012:function:my-function

• service: lambda.
• region: us-east-1.
• account-id: 123456789012.
• resource: 함수 이름(my-function).

ARN 사용 사례

1. IAM 정책에서 리소스 지정
   • 특정 IAM 사용자가 특정 리소스에 접근할 수 있도록 ARN을 사용.
   • 예:

     {
       "Effect": "Allow",
       "Action": "s3:GetObject",
       "Resource": "arn:aws:s3:::my-bucket/my-object.txt"
     }
     

2. 리소스 공유
   • 다른 AWS 계정과 리소스를 공유할 때 ARN을 사용해 특정 리소스를 참조.
3. 로깅 및 모니터링
   • AWS CloudTrail 및 CloudWatch에서 ARN을 통해 이벤트 또는 리소스를 추적.
4. 리소스 태그링
   • 태그와 ARN을 결합해 특정 리소스를 효율적으로 관리.

ARN의 주요 특징

• 고유성: AWS 내에서 특정 리소스를 고유하게 식별.
• 서비스 의존적: 서비스에 따라 리소스 형식과 세부 사항이 다름.
• 글로벌 및 지역 리소스:
  • S3 버킷처럼 글로벌 리소스인 경우 region 필드가 비어 있음.
  • EC2 인스턴스처럼 지역 리소스는 region 필드가 필수.

ARN과 AWS 리소스 관계

ARN을 쉽게 이해하기

1. 리소스의 고유 주소:
   • ARN은 AWS 리소스의 "고유 주소"로, AWS 내부에서 리소스를 정확히 지정하기 위한 방법입니다.
   • 예: "서울의 한 아파트 101호"라는 주소가 특정 집을 가리키듯, ARN은 특정 AWS 리소스를 가리킴.
2. 구조적인 이름 규칙:
   • "AWS 리소스에 대한 체계적인 이름 붙이기"라고 생각하면 됩니다.

추가로 알아두면 좋은 점

• ARN과 리전: 일부 글로벌 서비스(S3, IAM 등)는 리전을 사용하지 않지만, 대부분의 리소스는 리전이 필수.
• ARN의 중요성: IAM 정책, CloudFormation, 로깅 등 AWS 전반에서 널리 사용됨.
• 서비스마다 리소스 형식이 다름: 서비스마다 ARN의 마지막 resource 부분 형식이 다르므로, 공식 문서를 참고하는 것이 중요.

Buckets (버킷)

📌 Amazon S3에서 데이터를 저장하는 기본 단위(컨테이너)**입니다.

• S3에서 모든 객체(Object)는 반드시 하나의 버킷에 속하며, 버킷은 데이터를 정리하고 관리하기 위한 최상위 디렉토리 역할을 합니다.

버킷의 주요 특징

1. 데이터 저장소
   • S3에 저장되는 모든 객체(파일)는 반드시 버킷에 포함되어야 합니다.
   • 하나의 AWS 계정에서 최대 100개의 버킷을 생성 가능(기본 설정, 요청 시 한도 증가 가능).
2. 고유 이름
   • 버킷 이름은 전 세계적으로 고유해야 함.
     (인터넷 도메인 이름처럼 중복된 이름을 사용할 수 없음).
3. 접근 제어
   • 버킷 정책, ACL(Access Control List), IAM(Identity and Access Management) 등을 사용해 세부적인 접근 권한 관리 가능.
4. 버전 관리
   • 동일한 파일 이름으로 여러 버전을 저장할 수 있도록 버전 관리(Versioning) 지원.
5. 객체 저장 및 호출
   • 버킷에 저장된 파일(객체)은 HTTP(S)를 통해 접근 가능하며, URL 형태로 접근.

버킷 이름 규칙

• 글로벌 고유 이름: AWS 전체에서 다른 사용자가 동일한 이름을 사용할 수 없음.
• 소문자만 사용: 버킷 이름에는 대문자를 사용할 수 없음.
• 길이 제한: 3~63자 이내.
• 특수문자 제한: a-z, 0-9, .(점), -(하이픈)만 사용 가능.
• IP 형식 금지: 이름이 192.168.1.1 같은 IP 주소 형식이면 안 됨.

버킷을 설정할 때 고려 사항

1. 리전 선택
   • 데이터를 저장할 AWS 리전을 선택해야 함.
   • 리전을 선택하면 데이터가 해당 리전에 저장되며, 데이터 접근 속도와 비용에 영향을 미침.
   • 예: 미국 리전에 저장된 데이터를 한국에서 접근할 경우, 지연 시간이 더 길어질 수 있음.
2. 스토리지 클래스
   • 버킷에 저장된 데이터를 스토리지 클래스에 따라 관리 가능.
   • 예: S3 Standard, S3 Glacier 등.
3. 접근 정책
   • 버킷에 대한 접근 권한을 설정하여 공개 또는 비공개 여부를 결정.
   • 기본적으로 버킷은 비공개이며, 명시적으로 접근 권한을 부여해야 함.
4. 수명 주기(Lifecycle Policy)
   • 버킷에 저장된 데이터를 일정 시간 후 자동으로 **아카이브(S3 Glacier)**하거나 삭제하도록 설정 가능.
5. 버킷 로깅
   • 버킷 활동(데이터 업로드, 다운로드 등)을 추적하는 로깅 기능 제공.

버킷의 주요 사용 사례

1. 정적 웹사이트 호스팅
   • S3 버킷을 사용해 HTML, CSS, JavaScript 파일을 저장하고 정적 웹사이트를 호스팅.
2. 데이터 백업 및 복원
   • 중요한 파일, 데이터베이스 백업을 버킷에 저장.
3. 미디어 저장 및 제공
   • 이미지를 업로드하고 URL로 제공하거나 동영상을 스트리밍.
4. 로그 저장소
   • 애플리케이션 또는 시스템 로그를 저장하여 분석.
5. 대량 데이터 처리
   • S3에 데이터를 저장하고, 분석 도구(예: Athena, EMR)와 연계.

S3 버킷과 객체의 구조

• 버킷은 파일을 저장하는 최상위 디렉토리.
  • 예: my-bucket
• **객체(Object)**는 버킷에 저장되는 데이터 단위(파일).
  • 예: image.png, docs/report.pdf
• 경로 예시:
  • 버킷: my-bucket
  • 객체: folder1/image.png
  • URL: https://my-bucket.s3.ap-northeast-2.amazonaws.com/folder1/image.png
• https://<bucket-name>.s3.<region>.amazonaws.com/<object-key>

S3 버킷의 주요 장점

1. 글로벌 접근성
   • 전 세계 어디서든 URL을 통해 버킷에 저장된 데이터를 접근 가능.
2. 고가용성과 내구성
   • 버킷에 저장된 데이터는 기본적으로 AWS 내에서 여러 가용 영역(AZ)에 복제.
3. 유연한 데이터 관리
   • 버킷 정책, ACL, 수명 주기 정책 등을 통해 데이터를 효율적으로 관리 가능.
4. 무제한 확장성
   • 버킷 내 저장 용량에 제한이 없음.

S3 버킷과 관련된 용어

쉽게 이해하기

• **버킷은 "S3에서 사용하는 클라우드 폴더"**입니다.
• 버킷 안에 파일(객체)을 저장하며, 각각의 파일은 고유한 이름(키)을 가집니다.
• 파일을 업로드하면 URL이 생성되며, 이를 통해 어디서든 파일에 접근할 수 있습니다.

버킷 정책(Bucket Policy) 

📌 AWS S3 버킷에 대한 접근 제어를 JSON 형식으로 정의하는 문서입니다.

• 이를 통해 특정 사용자, 그룹, 또는 서비스가 버킷과 객체에 대해 어떤 작업을 할 수 있는지를 설정할 수 있습니다.

버킷 정책의 주요 특징

1. JSON 형식
   • 버킷 정책은 AWS 정책 언어를 사용하며, JSON 형식으로 작성.
2. 버킷 수준에서 작동
   • 개별 객체가 아닌, 버킷 전체에 대해 적용.
3. 권한 제어
   • IAM 사용자, AWS 서비스, 또는 익명 사용자에 대해 허용(Allow) 또는 거부(Deny) 권한을 설정.
4. 세부적 제어 가능
   • IP 주소, VPC, 시간 조건, HTTP 메서드 등 다양한 조건에 따라 접근을 허용하거나 거부.
5. IAM 정책과 병행 사용
   • IAM 정책과 함께 사용 가능하지만, 버킷 정책은 버킷과 관련된 모든 요청에 직접 적용.

버킷 정책의 주요 요소

버킷 정책의 기본 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PolicyStatementID",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

• Version: 정책 버전 (일반적으로 "2012-10-17" 사용).
• Statement: 정책의 규칙(여러 Statement를 배열로 포함 가능).
  • Effect: 허용(Allow) 또는 거부(Deny).
  • Principal: 정책을 적용할 대상. *은 모든 사용자.
  • Action: 수행할 수 있는 작업.
  • Resource: 정책이 적용되는 S3 리소스(버킷 또는 객체).
• Condition: 조건에 따라 정책 적용 여부 결정(선택적).

버킷 정책 예제

1. 모든 사용자에게 읽기 권한 부여 (버킷 공개)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

• Principal: "*" → 모든 사용자(익명 사용자 포함).
• Action: "s3:GetObject" → 객체를 읽는 작업 허용.
• Resource: "arn:aws:s3:::my-bucket-name/*" → 버킷 내 모든 객체에 적용.

2. 특정 AWS 계정에 전체 권한 부여

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantFullAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

• Principal: 특정 AWS 계정(123456789012)에 권한 부여.
• Action: "s3:*" → 모든 S3 작업 허용.
• Resource: 버킷 내 모든 객체에 적용.

3. 특정 IP 주소에서만 액세스 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificIP",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.1/32"
        }
      }
    }
  ]
}

• Condition: aws:SourceIp 조건을 사용해 특정 IP에서만 접근 허용.
• 192.168.1.1/32 → 지정된 단일 IP에서만 접근 가능.

4. 모든 사용자의 업로드 차단 (쓰기 금지)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

• Effect: Deny → 업로드 작업 거부.
• Action: "s3:PutObject" → 객체 업로드 작업 차단.

버킷 정책 vs IAM 정책

버킷 정책의 장단점

쉽게 이해하기

• 버킷 정책은 "S3 버킷에 출입 규칙을 정하는 보안 문서"라고 생각하면 됩니다.
  • 누구(Principal)가, 어떤 작업(Action)을, 어디(Resource)에 대해, 어떤 조건(Condition)으로 할 수 있는지 정의.
• 예를 들어:
  • 특정 IP에서만 읽기 허용.
  • 모든 사용자에게 읽기는 허용하되 쓰기는 차단.

S3 (Amazon Simple Storage Service)

📌 AWS에서 제공하는 확장 가능하고 안정적인 객체 스토리지 서비스입니다.

• S3는 데이터를 인터넷에 저장하고 필요할 때 불러올 수 있도록 설계된 서비스로, 사진, 동영상, 문서, 로그 파일, 백업 데이터 등 다양한 데이터를 저장하고 관리할 수 있습니다.
• EC2의 경우 서버와 같이 컴퓨터 리소스를 제공하는 것, S3는 파일/데이터의 저장소 역할, 둘이 완전 다르다.

S3의 주요 특징

1. 객체 스토리지(Object Storage)
   • S3는 데이터를 객체(object) 단위로 저장.
   • 객체 = 데이터 + 메타데이터 + 고유 키(Key).
   • 폴더/디렉토리 개념 없이 **버킷(Bucket)**에 객체를 저장.
2. 무제한 확장성
   • 저장 용량 제한 없음. 필요에 따라 데이터를 무제한으로 저장 가능.
3. 고가용성 및 내구성
   • 데이터 내구성: 99.999999999% (11 9s).
   • 가용성: 99.99% (서비스 지속 가능성).
4. 유연한 데이터 관리
   • 버전 관리(Versioning): 객체의 여러 버전을 저장.
   • 수명 주기 관리(Lifecycle): 데이터를 자동으로 아카이빙하거나 삭제.
5. 안전한 데이터 보호
   • 데이터 암호화 제공(전송 중 및 저장 중 암호화).
   • IAM 정책, 버킷 정책, ACL을 통해 세부적인 접근 제어 가능.
6. 다양한 스토리지 클래스 지원
   • 데이터 접근 빈도와 사용 목적에 따라 다양한 비용 최적화 옵션 제공.

S3의 주요 구성 요소

S3의 스토리지 클래스

1. S3 Standard
   • 기본 스토리지 클래스.
   • 고빈도 데이터 접근에 적합.
   • 높은 가용성과 내구성 제공.
2. S3 Intelligent-Tiering
   • 데이터 액세스 패턴에 따라 자동으로 비용 효율적인 스토리지 클래스를 선택.
   • 비용 절감을 위한 옵션.
3. S3 Standard-IA (Infrequent Access)
   • 덜 자주 접근하지만 즉시 액세스가 필요한 데이터에 적합.
   • 낮은 비용과 높은 가용성 제공.
4. S3 One Zone-IA
   • 한 가용 영역(AZ)에만 데이터를 저장하여 비용 절감.
   • 내구성은 낮지만 비용 효율적.
5. S3 Glacier
   • 데이터 아카이빙용으로 설계된 스토리지 클래스.
   • 매우 저렴하지만, 데이터 복원에 시간이 걸림(분~시간 단위).
6. S3 Glacier Deep Archive
   • 장기 보관 데이터를 위한 가장 저렴한 옵션.
   • 데이터 복원에 수 시간이 걸림.

S3의 주요 기능

1. 데이터 업로드 및 다운로드
   • RESTful API, AWS CLI, AWS SDK 또는 AWS Management Console을 통해 데이터 업로드/다운로드.
2. 액세스 제어
   • IAM 정책: 사용자 및 역할 기반으로 액세스 제어.
   • 버킷 정책: 버킷 수준에서 권한 정의.
   • ACL: 객체 및 버킷의 세부 권한 설정.
3. 버전 관리 (Versioning)
   • 동일한 키를 가진 객체의 여러 버전을 저장.
4. 수명 주기 정책 (Lifecycle Policy)
   • 데이터를 자동으로 아카이빙하거나 삭제하여 비용을 절감.
5. S3 이벤트 알림
   • 데이터 업로드/삭제 시 AWS Lambda, SQS, SNS로 이벤트 전송.

S3의 장단점

S3의 주요 사용 사례

1. 웹사이트 호스팅
   • S3 버킷을 사용해 정적 웹사이트 호스팅 가능(HTML, CSS, JS).
2. 백업 및 복구
   • 데이터를 안전하게 저장하고 장애 시 복원 가능.
3. 데이터 분석
   • 대규모 데이터셋을 저장하고 AWS 분석 도구(Athena, EMR 등)와 연계.
4. 아카이빙
   • 장기 보관 데이터를 S3 Glacier로 저장.
5. 애플리케이션 데이터 저장소
   • 애플리케이션에서 생성되는 파일, 로그, 이미지 등을 저장.

왜 S3가 필요한가?

1. 확장성
   • 데이터가 많아도 추가 설정 없이 저장 공간이 자동으로 확장.
2. 내구성과 안정성
   • 데이터를 여러 가용 영역(AZ)에 복제하여 높은 내구성 보장.
3. 비용 최적화
   • 사용량과 데이터 액세스 패턴에 따라 다양한 스토리지 옵션 제공.
4. 다양한 통합 가능성
   • AWS의 다른 서비스(EC2, Lambda, CloudFront 등)와 원활하게 통합.
5. 글로벌 접근성
   • 전 세계 어디서나 데이터를 빠르게 업로드 및 다운로드 가능.

쉽게 이해하기

**S3는 AWS에서 제공하는 "클라우드 드라이브"**라고 생각하면 됩니다.

• 저장 공간은 무제한이며, 파일을 안전하게 저장하고 필요할 때 언제든 다운로드 가능합니다.
• 비용 최적화를 위해 사용 패턴에 따라 다양한 옵션을 제공하며, AWS의 다른 서비스와 완벽하게 연동됩니다.

[ EBS와 S3의 차이점 ]

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

[ 분홍색이 메인입니다. 파란색 게시글은 알면 VPC를 이해하기 쉽습니다. ]

VPC (Virtual Private Cloud) 

📌 VPC (Virtual Private Cloud)는 AWS에서 제공하는 가상 네트워크 환경으로, 사용자가 AWS 리소스를 안전하게 배포하고 관리할 수 있는 독립된 네트워크 공간입니다.

• AWS 리소스(예: EC2 인스턴스, RDS 데이터베이스 등)가 공개 네트워크(인터넷)와 격리된 환경에서 운영될 수 있도록 설계되었습니다.

VPC의 주요 특징

1. 네트워크 격리
   • VPC는 사용자가 소유한 독립된 네트워크 공간을 제공하여, 다른 사용자의 리소스와 네트워크를 분리.
2. 사용자 정의 네트워크 설정
   • IP 주소 범위 지정(CIDR 블록).
   • 서브넷 생성 및 구분(공용, 프라이빗).
   • 인터넷 게이트웨이, NAT 게이트웨이 설정.
3. 보안 제어
   • 보안 그룹(SG)과 네트워크 ACL(NACL)을 사용해 인바운드/아웃바운드 트래픽을 세부적으로 제어.
4. 하이브리드 클라우드 지원
   • 온프레미스 네트워크와 AWS를 연결하여 하이브리드 네트워크 구현 가능(VPN, Direct Connect).
5. 인터넷 연결 가능성 제어
   • VPC 내 리소스를 인터넷에 연결하거나, 인터넷과 완전히 격리된 상태로 운영 가능.

VPC의 주요 구성 요소

VPC가 필요한 이유

1. 네트워크 격리와 보안 강화

• 공유 네트워크에서 독립된 환경 제공:
  • AWS는 기본적으로 모든 사용자의 리소스를 공유 네트워크에서 운영.
  • VPC는 이러한 공유 네트워크에서 격리된 자신만의 네트워크 공간을 제공하여, 네트워크 충돌 및 보안 문제를 방지.
• 트래픽 제어:
  • 보안 그룹과 NACL로 리소스 간 트래픽을 세부적으로 관리.
  • 예: 데이터베이스는 프라이빗 서브넷에 배치하고, 인터넷과 완전히 격리 가능.

2. 온프레미스와 통합된 하이브리드 클라우드 구현

• 기업의 기존 네트워크(온프레미스)와 AWS를 연결하여 하이브리드 환경을 구축할 수 있음.
• AWS 리소스를 기존 데이터센터와 통합해 유연하게 리소스를 확장.

3. 유연한 네트워크 구성

• IP 주소 범위 지정: VPC의 CIDR 블록을 원하는 대로 설정.
• 서브넷 분리: 공용 서브넷과 프라이빗 서브넷을 나누어 리소스를 효율적으로 배치.
• 라우팅 제어: 라우트 테이블로 네트워크 트래픽 흐름을 자유롭게 정의.

4. 확장성과 관리 용이성

• VPC 내에서 리소스를 쉽게 추가하거나 제거할 수 있어 확장성이 뛰어남.
• 필요에 따라 서브넷, 라우트 테이블, 보안 정책을 쉽게 변경 가능.

VPC의 주요 사용 사례

1. 보안이 중요한 애플리케이션 운영
   • 프라이빗 서브넷에 데이터베이스를 배치하고, 인터넷에 노출된 웹 서버만 공용 서브넷에 배치.
2. 하이브리드 클라우드 구성
   • 온프레미스 네트워크와 AWS VPC를 VPN 또는 Direct Connect로 연결.
3. 분리된 테스트 및 개발 환경
   • 서로 독립적인 네트워크 환경에서 테스트와 운영 리소스를 격리.
4. 데이터 분석 및 대규모 워크로드
   • 고성능 분석 작업을 위해 전용 네트워크에서 실행.

VPC의 장단점

쉽게 이해하기

**VPC는 AWS에서 제공하는 "내 것만 사용하는 네트워크 공간"**입니다.

• 예를 들어, 아파트 단지가 공유 네트워크라면, VPC는 개인 주택처럼 독립된 네트워크를 제공합니다.
• 이를 통해 AWS 리소스를 안전하게 보호하고, 원하는 대로 네트워크를 설계할 수 있습니다.

서브넷(Subnet)

🐳 서브넷(Subnet)은 VPC의 IP 주소 범위를 더 작은 네트워크 단위로 나누는 것을 의미합니다.

• AWS에서 서브넷은 VPC 내에서 리소스(예: EC2 인스턴스, 데이터베이스 등)가 공용 또는 프라이빗 네트워크에서 작동하도록 구성할 수 있는 네트워크 단위입니다.
• 각 서브넷에는 하나의 라우팅 테이블이 존재한다. 이 라우팅 데이블이 목적지 IP 주소와 대상 게이트웨이 또는 NAT 게이트웨이와 같은 대상을 매핑한다.
• 라우팅 테이블은 보통 여러개의 라우팅 규칙을 가지며, 이를 사용하여 서브넷에서 트래픽을 전달하는 방법을 제어한다.

서브넷의 주요 특징

1. VPC의 하위 네트워크
   • 서브넷은 VPC의 IP 주소 범위(CIDR 블록)를 더 작은 네트워크 단위로 나눕니다.
   • 예: VPC의 CIDR 블록이 10.0.0.0/16인 경우, 이를 여러 서브넷으로 나눌 수 있음.
     • 서브넷 A: 10.0.0.0/24
     • 서브넷 B: 10.0.1.0/24
2. 가용 영역(AZ) 내에 존재
   • 서브넷은 **VPC 내 특정 가용 영역(AZ)**에 속하며, 하나의 서브넷은 하나의 AZ에만 존재할 수 있습니다.
   • 가용 영역별로 서브넷을 나누어 고가용성을 확보할 수 있습니다.
3. 공용/프라이빗 서브넷
   • 공용 서브넷(Public Subnet):
     • 인터넷 게이트웨이를 통해 인터넷에 연결되는 서브넷.
   • 프라이빗 서브넷(Private Subnet):
     • 인터넷에 직접 연결되지 않고 내부 네트워크에서만 작동.
4. 라우트 테이블과 연계
   • 서브넷의 트래픽 흐름은 라우트 테이블에 의해 결정됩니다.
   • 예: 공용 서브넷은 인터넷 게이트웨이로 트래픽을 라우팅.

서브넷의 구성 요소

공용 서브넷 vs 프라이빗 서브넷

서브넷을 사용하는 이유

1. 리소스 분리 및 보안 강화
   • 웹 서버는 공용 서브넷, 데이터베이스는 프라이빗 서브넷에 배치하여 보안 강화.
2. 고가용성 및 장애 대응
   • 여러 가용 영역(AZ)에 서브넷을 배치하여 장애 시에도 서비스 지속 가능.
3. 트래픽 관리
   • 라우트 테이블을 사용해 서브넷 간 또는 외부와의 트래픽 흐름을 세부적으로 제어.
4. 유연한 네트워크 설계
   • VPC 내에서 IP 주소를 효율적으로 할당하고 관리 가능.

서브넷 구성 예시

VPC 설정

• VPC CIDR 블록: 10.0.0.0/16

서브넷 설정

서브넷의 주요 사용 사례

1. 웹 애플리케이션 배포
   • 공용 서브넷에 웹 서버 배치.
   • 프라이빗 서브넷에 데이터베이스 배치.
2. 고가용성 설계
   • 가용 영역(AZ) 간 서브넷을 배치하여 서비스 중단을 최소화.
3. 하이브리드 클라우드
   • 프라이빗 서브넷을 사용해 온프레미스 네트워크와 연결.
4. 민감 데이터 보호
   • 프라이빗 서브넷에 민감 정보를 저장하고, 외부로부터의 접근 차단.

쉽게 이해하기

• 서브넷은 VPC라는 큰 네트워크를 "방"으로 나누는 것이라고 생각하면 됩니다.
• 예를 들어:
  • 공용 서브넷은 인터넷에 연결되는 방(예: 거실).
  • 프라이빗 서브넷은 외부와 차단된 방(예: 금고 방).

게이트웨이(Gateway)

🐳 게이트웨이(Gateway)는 네트워크에서 다른 네트워크로 트래픽을 전달하는 출입구 역할을 합니다.

• AWS에서는 VPC 내에서 외부 네트워크(예: 인터넷) 또는 다른 네트워크(예: 온프레미스 네트워크)와 연결할 때 주로 사용됩니다.

게이트웨이의 역할

1. 네트워크 간 트래픽 전달
   • 하나의 네트워크에서 다른 네트워크로 데이터를 라우팅(전달).
   • 예: VPC 내부의 서브넷과 인터넷을 연결하거나 온프레미스 네트워크와 연결.
2. 트래픽 제어 및 보안
   • 외부 네트워크와의 연결을 제어하거나 특정 경로를 통해 데이터 흐름을 관리.
3. 프로토콜 변환
   • 서로 다른 네트워크 프로토콜을 사용하는 네트워크 간 통신을 가능하게 함.

AWS에서 제공하는 주요 게이트웨이 종류

1. 인터넷 게이트웨이 (Internet Gateway, IGW)
   • VPC를 인터넷에 연결하기 위한 게이트웨이.
   • VPC 내 공용 서브넷의 리소스(예: EC2)가 인터넷과 양방향 통신 가능.
   • 특징:
     • VPC에 하나의 인터넷 게이트웨이만 연결 가능.
     • 공용 IP 또는 탄력적 IP가 있는 리소스만 인터넷 연결 가능.
   • 사용 사례:
     • 공용 웹 서버나 로드 밸런서를 인터넷에 노출할 때.
2. NAT 게이트웨이 (Network Address Translation Gateway)
   • 프라이빗 서브넷의 리소스가 인터넷에 액세스하도록 지원하되, 외부에서 리소스에 직접 접근하지 못하도록 함.
   • 특징:
     • 프라이빗 IP 주소를 공용 IP 주소로 변환하여 인터넷 액세스.
     • 단방향 통신(프라이빗 서브넷 → 인터넷) 지원.
   • 사용 사례:
     • 프라이빗 서브넷의 데이터베이스 서버가 소프트웨어 업데이트를 위해 인터넷에 연결될 때.
3. VPN 게이트웨이 (Virtual Private Gateway)
   • 온프레미스 네트워크와 AWS VPC를 **VPN(가상 사설망)**을 통해 연결.
   • 특징:
     • AWS와 온프레미스 간의 안전한 네트워크 통신 제공.
   • 사용 사례:
     • 하이브리드 클라우드 구성.
4. 프라이빗 링크 (PrivateLink)
   • VPC 간 또는 VPC와 AWS 서비스 간의 안전한 프라이빗 연결.
   • 특징:
     • 네트워크 트래픽이 인터넷을 통해 전달되지 않고 AWS 네트워크 내에서 처리.
   • 사용 사례:
     • AWS 서비스에 민감 데이터를 전송할 때.
5. Direct Connect 게이트웨이 (Direct Connect Gateway)
   • AWS Direct Connect를 사용해 온프레미스 네트워크와 AWS VPC를 전용 회선으로 연결.
   • 특징:
     • 인터넷을 우회하여 고속, 저지연 연결 제공.
   • 사용 사례:
     • 대규모 데이터 전송이나 민감한 데이터를 다룰 때.
6. Transit Gateway
   • 여러 VPC, 온프레미스 네트워크, AWS 서비스 간의 허브 역할을 하는 중앙 게이트웨이.
   • 특징:
     • 복잡한 네트워크 아키텍처를 단순화.
   • 사용 사례:
     • 여러 VPC와 온프레미스 네트워크를 효율적으로 연결.

게이트웨이 간 비교

왜 게이트웨이가 필요한가?

1. 네트워크 연결 필수 요소
   • AWS VPC는 기본적으로 인터넷이나 다른 네트워크와 격리되어 있습니다.
     게이트웨이가 있어야 외부 네트워크와 통신이 가능합니다.
2. 보안 강화
   • NAT 게이트웨이와 VPN 게이트웨이는 네트워크 보안을 강화하며, 필요한 리소스만 적절하게 노출.
3. 하이브리드 클라우드 지원
   • 온프레미스 네트워크와 AWS 리소스를 연결하여 유연한 네트워크 아키텍처를 구축 가능.
4. 효율적 트래픽 관리
   • Transit Gateway를 사용하면 복잡한 VPC와 네트워크 연결을 중앙에서 효율적으로 관리.

쉽게 이해하기

게이트웨이는 "네트워크 간의 다리" 역할을 합니다.

• 인터넷 게이트웨이: VPC를 인터넷과 연결하는 출입구.
• NAT 게이트웨이: 프라이빗 리소스가 인터넷에 접속할 수 있도록 중개.
• VPN 게이트웨이: 온프레미스 네트워크와 AWS 간 안전한 연결.
• Transit Gateway: 여러 네트워크를 하나의 허브로 연결해 효율적으로 관리.

NAT (Network Address Translation)

🐳 NAT (Network Address Translation)는 네트워크에서 사설 IP 주소를 공인 IP 주소로 변환하거나, 그 반대로 변환하는 기술입니다.

• 이를 통해 사설 네트워크의 장치들이 인터넷과 통신할 수 있게 하면서도, 외부에서 직접적으로 접근하지 못하도록 보호합니다.

NAT의 주요 역할

1. IP 주소 절약
   • 사설 네트워크 내 여러 기기가 하나의 공인 IP 주소를 공유하여 인터넷에 접속.
   • 공인 IP 주소를 최소화하면서 사설 IP 주소를 무제한으로 사용할 수 있음.
2. 보안 강화
   • 외부에서는 사설 네트워크의 IP 주소를 알 수 없으므로, 내부 기기에 직접 접근하기 어려움.
   • NAT가 인터넷과 사설 네트워크 간의 중개자 역할을 수행.
3. 사설 네트워크와 외부 네트워크 간 통신
   • 사설 네트워크의 기기가 인터넷(공용 네트워크)과 데이터 송수신 가능.

NAT 동작 방식

1. 데이터 요청 (사설 → 공인)

• 사설 네트워크의 장치가 인터넷에 요청을 보냄.
• NAT는 사설 IP 주소를 공인 IP 주소로 변환한 뒤 데이터를 외부로 전송.

2. 데이터 응답 (공인 → 사설)

• 외부 서버가 NAT 장치의 공인 IP로 응답을 보냄.
• NAT는 해당 응답을 다시 사설 IP 주소로 변환해 내부 장치로 전달.

NAT의 유형

1. Static NAT (정적 NAT)
   • 하나의 사설 IP 주소를 하나의 공인 IP 주소에 매핑.
   • 사용 사례: 내부 서버가 외부에서 항상 동일한 IP로 접근되도록 설정.
2. Dynamic NAT (동적 NAT)
   • 사설 네트워크의 IP 주소를 공인 IP 주소 풀에서 동적으로 할당.
   • 사용 사례: 공인 IP 주소가 제한된 경우.
3. PAT (Port Address Translation)
   • 여러 사설 IP 주소가 하나의 공인 IP 주소를 공유.
   • 포트 번호를 기반으로 트래픽을 구분.
   • 사용 사례: 가정용 라우터에서 흔히 사용.
     • 예: 여러 기기가 하나의 공인 IP를 통해 인터넷에 연결.

AWS에서 NAT의 역할

AWS에서는 NAT를 통해 프라이빗 서브넷의 리소스가 인터넷에 접속할 수 있도록 지원합니다.

1. NAT 게이트웨이 (NAT Gateway)
   • AWS에서 제공하는 관리형 NAT 서비스.
   • 인터넷 액세스가 필요한 프라이빗 서브넷 리소스를 위해 사용.
   • 안정성과 성능이 높으며, AWS가 관리하므로 사용자 개입이 적음.
2. NAT 인스턴스 (NAT Instance)
   • 사용자가 직접 EC2 인스턴스를 설정하여 NAT 역할을 수행.
   • 설정 및 관리는 사용자가 직접 해야 하므로 NAT 게이트웨이보다 복잡.

NAT 게이트웨이와 NAT 인스턴스 비교

NAT 게이트웨이 사용 사례

1. 프라이빗 서브넷 리소스의 인터넷 액세스
   • 프라이빗 서브넷에 배치된 EC2 인스턴스가 소프트웨어 업데이트 또는 외부 데이터 다운로드.
2. 외부로의 데이터 전송만 필요한 경우
   • 외부에서 프라이빗 서브넷 리소스로의 직접적인 접근이 필요 없는 경우.
3. 보안 강화
   • 프라이빗 서브넷 리소스를 인터넷과 완전히 격리하면서도, 필요한 경우에만 인터넷에 접근 가능.

NAT와 보안 그룹, 라우트 테이블의 관계

1. 보안 그룹(Security Group)
   • NAT 게이트웨이나 NAT 인스턴스의 인바운드/아웃바운드 트래픽 제어.
2. 라우트 테이블
   • 프라이빗 서브넷의 라우트 테이블에 NAT 게이트웨이를 경유하는 경로를 추가.
   • 예:

     0.0.0.0/0 → NAT 게이트웨이
     

NAT의 장단점

장점 단점

쉽게 이해하기

**NAT는 "인터넷과 사설 네트워크를 이어주는 다리"**입니다.

• 사설 네트워크 내부의 기기들은 NAT를 통해 인터넷에 접근할 수 있습니다.
• 하지만 NAT는 내부 기기를 외부에서 직접적으로 보이지 않게 하여 보안을 강화합니다.

네트워크

🧩흔히 말하는 네트워크는 컴퓨터, 서버, 장치(기기) 간 데이터를 주고받는 연결 시스템을 의미합니다.

네트워크란?

네트워크는 두 개 이상의 기기가 서로 연결되어 데이터(정보)를 주고받는 구조를 의미합니다.
네트워크에는 여러 가지 요소가 포함되며, 서버는 그 중 일부입니다.

네트워크와 서버의 차이

네트워크 구성 요소

1. 서버(Server)
   • 네트워크 내에서 서비스를 제공하는 역할을 하는 기기 또는 소프트웨어.
   • 예: 웹 서버(웹 페이지 제공), 데이터베이스 서버(데이터 관리).
2. 클라이언트(Client)
   • 네트워크를 통해 서버에 요청을 보내는 기기.
   • 예: 사용자가 인터넷 브라우저를 통해 웹 페이지를 요청.
3. 라우터(Router)
   • 네트워크 간 데이터를 전달하는 장치.
   • 예: 가정에서 사용하는 인터넷 공유기.
4. 스위치(Switch)
   • 네트워크 내에서 데이터 패킷을 올바른 기기로 전달하는 역할.
   • 예: 회사의 사내 네트워크 장비.
5. 네트워크 프로토콜
   • 네트워크 상에서 데이터를 주고받는 규칙.
   • 예: HTTP, FTP, TCP/IP, DNS 등.

서버와 네트워크의 관계

서버는 네트워크의 구성 요소 중 하나로, 데이터를 저장하거나 서비스(웹 페이지, 파일, 데이터베이스 등)를 제공하는 역할을 합니다.
네트워크는 이러한 서버와 클라이언트를 연결하여 데이터를 주고받게 하는 통신 환경입니다.

쉽게 이해하기

• 네트워크: "도로 시스템"
  • 도로가 네트워크라면, 차량은 데이터를 운반합니다.
  • 도로 위에 있는 주유소(서버)는 특정 서비스를 제공합니다.
  • 주유소가 서버라면, 주유소를 이용하는 차량은 클라이언트.

결론

• 네트워크는 단순히 서버만을 말하는 것이 아니라, 서버, 클라이언트, 라우터, 스위치 등이 연결된 데이터 통신 시스템입니다.
• 서버는 네트워크 내에서 특정한 역할(예: 데이터 제공, 웹 페이지 제공)을 수행하는 기기 또는 소프트웨어입니다.

[ DNS는 AWS에 해당하는 내용은 아니지만 같이 보면 이해가 편해서 추가했습니다. ]

DNS (Domain Name System) 

 🐳 DNS (Domain Name System)는 사람들이 쉽게 기억할 수 있는 도메인 이름(예: www.google.com)을 IP 주소(예: 172.217.18.36)로 변환하는 인터넷 주소록 같은 시스템입니다.

• DNS를 통해 사용자는 복잡한 IP 주소를 입력할 필요 없이 도메인 이름만으로 웹사이트나 서비스를 이용할 수 있습니다.
• 실제 인터넷 주소는 172.217.18.36의 형태이지만, 사람이 보기 힘드어서 www.google.com과 같은 형태로 별명을 만들어준다는 것

DNS의 주요 역할

1. 도메인 이름을 IP 주소로 변환
   • 사용자가 도메인 이름을 입력하면 DNS가 이를 서버가 이해할 수 있는 IP 주소로 변환.
2. 인터넷 서비스 연결 지원
   • 웹사이트 접속, 이메일 송수신 등 다양한 인터넷 서비스에 사용.
3. 분산형 데이터베이스 시스템
   • 전 세계적으로 분산되어 있는 서버들이 협력하여 DNS 요청을 처리.

DNS의 주요 구성 요소

1. DNS Records (DNS 레코드)
   • 도메인과 IP 주소를 연결하는 데이터.
   • 주요 레코드 유형:
     • A 레코드: 도메인 이름을 IPv4 주소에 매핑.
     • AAAA 레코드: 도메인 이름을 IPv6 주소에 매핑.
     • CNAME 레코드: 도메인 별칭(alias)을 설정.
     • NS 레코드: 네임 서버 정보를 저장.
     • MX 레코드: 이메일 서버를 지정.
2. DNS 계층 구조
   DNS는 계층 구조로 작동하며, 아래와 같이 구성:
   • Root DNS Server: 최상위 계층. 모든 DNS 요청의 출발점.
     
     
   • TLD (Top-Level Domain) DNS Server: .com, .org, .kr 등 최상위 도메인을 관리.
     + 도메인의 종류나 목적, 지역을 나타낸다. COM은 원랜 상업 사이트를 위해, ORG는 비영리단체 등등 인터넷 관리기관에서 정한 기준에 따라 사용되는 최상위 도메인이다.
     
     
   • SLD (Second-Level Domain) DNS Server: 사용자 정의 도메인을 관리.
     예: google은 google.com에서 SLD.  =  google이 SLD에 해당한다. 즉, 별명
     
     
     
3. 네임 서버 (Name Server)
   • 도메인 이름에 대한 정보를 저장하고 요청에 응답하는 서버.
4. Zone File
   • 도메인에 대한 DNS 레코드 정보를 저장한 파일.

DNS 작동 원리

1. 사용자가 브라우저에 www.google.com 입력.
2. 요청이 ISP(인터넷 서비스 제공업체)의 DNS 서버로 전달.
3. ISP의 DNS 서버가:
   • Root DNS Server에 요청하여 TLD 서버 정보 확인.
   • TLD DNS Server에서 SLD 서버 정보 확인.
   • SLD DNS Server에서 최종 IP 주소 반환.
4. 반환된 IP 주소를 통해 사용자가 요청한 웹사이트에 연결.

DNS 관련 용어

1. 도메인 구성 요소
   • Top-Level Domain (TLD): .com, .org, .net과 같은 최상위 도메인.
   • Second-Level Domain (SLD): TLD 앞에 오는 사용자 정의 이름(예: google).
   • Subdomain: SLD 앞에 붙는 추가 구분자(예: mail.google.com).
2. Registrar
   • 도메인 이름을 등록할 수 있는 서비스.
   • 예: AWS Route53, GoDaddy.
3. ISP (Internet Service Provider)
   • 인터넷 연결을 제공하는 회사(예: KT, SK Broadband, LG U+).
4. DNS 캐싱
   • DNS 요청 결과를 브라우저, 로컬 컴퓨터 또는 ISP에서 임시로 저장하여 속도 향상.

DNS와 HTTP/HTTPS의 관계

• DNS는 도메인 이름을 IP 주소로 변환하는 역할을 하고, HTTP/HTTPS는 해당 IP 주소를 통해 서버와 통신하는 프로토콜.
• 예: 사용자가 https://www.google.com에 접속하면:
  1. DNS: www.google.com → 172.217.18.36로 변환.
  2. HTTPS: 암호화된 연결을 통해 해당 서버에 요청.

DNS의 장단점

추가적인 DNS 서비스

1. AWS Route 53
   • AWS에서 제공하는 관리형 DNS 서비스로, 도메인 등록, 레코드 관리, 헬스 체크 기능 지원.
2. DNS 공격 방어
   • DNS 스푸핑: 악의적으로 잘못된 IP 주소로 연결.
   • DNS DDoS 공격: DNS 서버를 과부하 상태로 만들어 서비스 중단.
   • 방어 방법: DNSSEC(DNS Security Extensions) 사용.

쉽게 이해하기

DNS는 인터넷의 전화번호부입니다.

• 도메인 이름을 IP 주소로 바꿔 웹사이트에 연결해 주는 역할을 합니다.
• 예를 들어, www.google.com은 사람이 읽기 쉬운 주소고, DNS가 이를 컴퓨터가 이해하는 172.217.18.36로 변환합니다.

라우팅(Routing)

 🐳라우팅(Routing)은 네트워크 트래픽(사용자의 요청)을 특정한 목적지(서버, 서비스 등)로 올바르게 전달하는 과정입니다.

• DNS에서 라우팅은 도메인 이름에 대해 적절한 IP 주소나 리소스를 찾아주는 작업을 의미합니다. AWS Route 53에서는 다양한 라우팅 정책을 사용해 트래픽을 효율적으로 관리할 수 있습니다.

라우팅의 목적

1. 사용자 요청 처리: 사용자가 웹 브라우저에서 특정 도메인 이름을 입력하면 요청이 올바른 서버로 전달되도록 설정.
2. 트래픽 분산: 여러 서버가 요청을 처리하도록 트래픽을 분산.
3. 최적 경로 제공: 사용자와 가장 가까운 서버로 연결해 지연 시간을 줄이고 성능을 향상.
4. 장애 복구: 특정 서버가 다운되었을 때 다른 서버로 트래픽을 자동 전환.

AWS Route 53의 라우팅 정책

Route 53은 트래픽을 목적지로 전달할 때 다양한 라우팅 정책을 제공합니다. 주요 라우팅 정책은 아래와 같습니다:

1. 단순 라우팅 (Simple Routing)

• 하나의 도메인 이름에 대해 하나의 IP 주소 또는 리소스를 연결.
• 사용 사례: 트래픽을 단일 서버로만 보내야 할 때.
  • example.com → 192.0.2.1
• 예시:

2. 가중치 라우팅 (Weighted Routing)

• 여러 서버 또는 리소스 간에 트래픽을 **비율(가중치)**에 따라 분산.
• 사용 사례:
  • 새 애플리케이션을 점진적으로 배포할 때.
  • 두 서버 간 트래픽 비율을 조정하여 성능 테스트.
  예시:
  • 서버 A (가중치 70) → 트래픽의 70%
  • 서버 B (가중치 30) → 트래픽의 30%

3. 지연 시간 라우팅 (Latency Routing)

• 사용자와 서버 간 지연 시간이 가장 짧은 서버로 트래픽을 라우팅.
• 사용 사례:
  • 글로벌 사용자 기반을 가진 애플리케이션.
  • 서버가 여러 리전에 배포된 경우.
  예시:
  • 미국 사용자 → 미국 서버
  • 한국 사용자 → 한국 서버

4. 지리적 위치 라우팅 (Geolocation Routing)

• 사용자의 **물리적 위치(국가, 대륙 등)**를 기반으로 트래픽을 라우팅.
• 사용 사례:
  • 지역별 맞춤 콘텐츠 제공.
  • 각 국가별 데이터 규제 준수.
  예시:
  • 일본 사용자 → 일본 서버
  • 한국 사용자 → 한국 서버

5. 지리적 근접성 라우팅 (Geoproximity Routing)

• 사용자의 위치와 서버의 위치를 기준으로 가장 가까운 서버로 트래픽을 라우팅.
• 추가 기능: 리소스 간 거리 기반 비율을 조정해 특정 서버로 트래픽을 더 많이 보낼 수 있음.

6. 다중값 응답 라우팅 (Multivalue Answer Routing)

• 여러 IP 주소를 반환하고, DNS 헬스 체크를 통해 정상적인 서버로만 연결.
• 사용 사례:
  • 단순한 고가용성 구현.

7. 장애 복구 라우팅 (Failover Routing)

• 기본 서버가 장애가 발생하면 백업 서버로 자동 전환.
• 사용 사례:
  • 주(primary) 서버와 보조(secondary) 서버를 설정해 서비스 중단 방지.
  예시:
  • 기본 서버 다운 → 백업 서버로 트래픽 전환.

라우팅 동작 과정

1. 사용자 요청: 사용자가 브라우저에 example.com을 입력.
2. DNS 조회: 요청이 ISP의 DNS 서버와 Route 53으로 전달.
3. 라우팅 정책 적용: Route 53이 설정된 정책(예: 가중치, 지연 시간 등)을 기반으로 적절한 서버로 트래픽 라우팅.
4. 응답 반환: 사용자는 올바른 서버로 연결되고 요청이 처리됨.

왜 Route 53에서 라우팅이 중요한가?

• 유연한 트래픽 제어:
  • 다양한 정책을 통해 트래픽을 효율적으로 분산하고 최적화.
• 서비스 중단 방지:
  • 장애 발생 시 헬스 체크와 장애 복구 라우팅으로 다운타임 최소화.
• 글로벌 사용자 지원:
  • 지연 시간이나 지리적 위치 기반 라우팅을 통해 글로벌 사용자를 대상으로 최적의 성능 제공.

쉽게 이해하기

**라우팅은 "인터넷의 네비게이션 시스템"**입니다.
Route 53은 사용자의 요청을 가장 빠르고 안전한 길로 안내하는 역할을 하며, 다양한 정책을 통해 트래픽 분산, 성능 향상, 장애 복구 등을 지원합니다.

Route 53

📌 Route 53은 AWS에서 제공하는 클라우드 기반 DNS 관리 서비스입니다.

• 도메인 이름 등록, 트래픽 라우팅, 헬스 체크 등을 관리하며, 웹 애플리케이션에 안정적이고 확장 가능한 DNS 서비스를 제공합니다.
• 왜 도메인 관리 회사를 이용해 도메인을 관리하지 않고 이걸 사용할까?

53의 의미

• "53"은 DNS에서 사용되는 포트 번호를 나타냅니다.
• DNS는 TCP 포트 53과 UDP 포트 53을 사용해 클라이언트 요청과 응답을 처리합니다.
  • UDP 53: 짧은 쿼리(예: IP 주소 조회) 처리에 사용.
  • TCP 53: 대용량 데이터 전송 및 안정적 연결이 필요한 상황에서 사용.
• AWS의 DNS 서비스가 DNS와 깊은 연관이 있음을 나타내기 위해 **"Route 53"**이라는 이름이 붙었습니다.

DNS와 53번 포트

1. TCP와 UDP 사용 이유
   • UDP 53: 속도가 빠르고 오버헤드가 적어 DNS 요청과 응답에 적합.
   • TCP 53: 데이터 크기가 큰 경우(예: 존 전송)와 안정적인 연결이 필요한 상황에서 사용.
2. DNS의 53번 포트 표준화
   • 인터넷 프로토콜 표준(특히 IANA, Internet Assigned Numbers Authority)에 의해 DNS의 기본 포트로 지정.

Route 53의 주요 기능

1. 도메인 이름 등록
   • Route 53을 통해 도메인 이름을 쉽게 등록 및 관리 가능.
2. 트래픽 라우팅
   • 사용자 요청을 적절한 서버 또는 리소스로 라우팅.
   • 라우팅 정책:
     • 단순 라우팅(Simple Routing)
     • 지리적 라우팅(Geolocation Routing)
     • 가중치 라우팅(Weighted Routing)
     • 헬스 체크 기반 라우팅(Health Check)
3. DNS 관리
   • A, AAAA, CNAME, MX, NS 등 다양한 DNS 레코드 관리 가능.
4. 헬스 체크
   • 서버 상태를 모니터링하고, 비정상 서버를 라우팅에서 제외.

왜 Route 53인가?

• Route 53의 이름은 인터넷의 "길(Route)"을 정하는 역할과 DNS에서 사용되는 53번 포트를 결합한 것입니다.
• AWS의 네이밍 센스로 DNS의 본질을 쉽게 표현.

정리

Route 53의 이름은 DNS에서 사용되는 표준 포트 번호인 53번에서 유래했습니다.
DNS가 인터넷의 "주소록" 역할을 하듯, Route 53은 웹 애플리케이션 트래픽을 적절히 라우팅하여 인터넷 사용자와 리소스를 연결하는 "길잡이" 역할을 합니다.

[추가학습]

레코드

🧩DNS 레코드(DNS Record)는 도메인 이름과 관련된 정보를 저장하는 데이터의 단위입니다.

• 레코드는 도메인 이름과 연결된 IP 주소, 메일 서버 정보, 다른 도메인과의 관계 등을 정의하는 역할을 합니다.
  쉽게 말해, DNS 레코드는 "도메인에 대한 설정 정보를 저장하는 명령서"라고 할 수 있습니다.
• 추가로 현재 도메인을 전송 도메인 OR IP등에 매핑하는 기능이 있다.( CNAME 레코드와 Alias 레코드 ) 여기서 매핑은 트래픽을 어디로 보낼지 결정하는 것을 말한다. 다만, 어디로 보낼지 배송지만 적고 실제 전송은 안한다.

레코드의 역할

1. 도메인과 IP 주소 매핑:
   • 사용자가 입력한 도메인 이름을 올바른 IP 주소로 변환.
2. 도메인의 메일 서버 정보 정의:
   • 이메일이 어떤 서버로 전달될지 지정.
3. 도메인 별칭 설정:
   • 하나의 도메인 이름을 다른 도메인으로 연결.

주요 DNS 레코드 유형

아래는 DNS에서 자주 사용하는 주요 레코드 타입과 그 역할입니다:

[ IPv4 vs IPv6 ]

주요 레코드의 동작 방식

1. A 레코드 (Address Record)
   • 사용자가 도메인 이름을 입력하면, 해당 이름이 IPv4 주소로 변환되어 요청이 처리됩니다.
   • 예: www.google.com → 142.250.190.14
2. CNAME 레코드 (Canonical Name Record)
   • 별칭을 설정해, 여러 도메인이 동일한 리소스를 가리키도록 설정.
   • 예: www.example.com → example.com
3. MX 레코드 (Mail Exchange Record)
   • 이메일이 특정 서버로 전달되도록 설정.
   • 예: Gmail 메일을 사용할 경우, example.com → aspmx.l.google.com
4. TXT 레코드
   • 추가 텍스트 정보를 저장. 주로 인증 정보를 설정하는 데 사용.
   • 예: SPF(Sender Policy Framework), DKIM, 도메인 인증.
5. NS 레코드 (Name Server Record)
   • 해당 도메인을 관리하는 네임 서버를 지정.
   • 예: example.com → ns1.example.com

레코드가 저장되는 곳

1. DNS 서버
   • 레코드는 네임 서버에 저장되며, 클라이언트 요청 시 DNS 서버가 이를 조회하여 응답.
2. 존 파일(Zone File)
   • 도메인과 관련된 모든 레코드 정보를 저장한 파일.

레코드와 TTL (Time To Live)

• 각 DNS 레코드는 TTL(Time To Live) 값을 가지며, 이는 레코드가 DNS 캐시에 저장되는 시간을 결정.
• TTL이 짧으면 변경 사항이 빠르게 반영되지만, 더 많은 조회 요청이 발생.
• TTL이 길면 DNS 서버의 부하가 줄어들지만, 변경 사항 반영이 느려질 수 있음.

쉽게 이해하기

DNS 레코드는 "도메인에 대한 설정 데이터"입니다.
도메인이 어떤 서버와 연결되는지(IP 주소), 이메일을 어디로 보낼지, 추가 인증 정보는 무엇인지 등을 결정하는 중요한 정보가 들어 있습니다.

CNAME vs Alias

🧩CNAME (Canonical Name Record)와 Alias는 DNS 설정에서 도메인을 다른 도메인으로 매핑하는 데 사용됩니다.
둘 다 비슷한 역할을 하지만, 사용 사례와 동작 방식에서 차이가 있습니다.

• 둘다 레코드 유형이다.

CNAME (Canonical Name Record)

1. 정의
   • CNAME 레코드는 도메인의 별칭(Alias) 역할을 합니다.
   • 하나의 도메인을 다른 도메인 이름으로 매핑.
2. 주요 특징
   • 도메인 이름만 가리킬 수 있음.
     (예: www.example.com → example.com)
   • A 레코드나 IP 주소를 직접 가리킬 수 없음.
   • 요청 시, DNS가 먼저 CNAME의 대상 도메인을 조회한 후 해당 도메인의 A 레코드를 찾아 최종 IP 주소를 반환.
   • 도메인 이름이 변경되어도 대상 도메인에만 변경 사항을 적용하면 됨.
3. 사용 사례
   • 하위 도메인 연결:
     • 예: www.example.com을 example.com으로 연결.
     • 사용자 요청: www.example.com → example.com → IP 주소.
   • 도메인 간 리디렉션:
     • myapp.example.com → app.example2.com.
4. 예시
5. www.example.com CNAME example.com

Alias (Alias Record)

1. 정의
   • Alias 레코드는 도메인을 다른 도메인 이름이나 AWS 리소스로 매핑하는 특별한 유형의 레코드입니다.
2. 주요 특징
   • **A 레코드(IP 주소)**처럼 동작하지만, 실제로는 도메인 이름을 가리킴.
   • AWS Route 53에서만 사용 가능.
   • DNS 요청 시 IP 주소로 직접 변환하여 반환(추가 쿼리 없음).
   • ELB, S3 버킷, CloudFront와 같은 AWS 리소스에 연결 가능.
3. 사용 사례
   • AWS 리소스 연결:
     • 도메인을 Elastic Load Balancer(ELB), S3 버킷, CloudFront 배포 등으로 매핑.
   • 루트 도메인 연결(예: example.com → S3 버킷):
     • CNAME은 루트 도메인(example.com)에 사용할 수 없지만, Alias는 가능.
4. 예시
5. example.com ALIAS my-load-balancer.amazonaws.com

CNAME과 Alias의 주요 차이점

사용 시 주의점

1. CNAME:
   • 루트 도메인(예: example.com)에서는 사용할 수 없음.
   • 대신 하위 도메인(예: www.example.com)에서 사용 가능.
2. Alias:
   • Route 53 전용 기능으로 AWS 리소스와의 연결에 최적화.
   • 루트 도메인에서도 사용 가능.

쉽게 이해하기

• CNAME: "도메인의 별칭 설정" → 다른 도메인 이름을 가리킴.
  예: www.example.com → example.com
• Alias: "AWS 리소스를 위한 특수한 연결" → IP 주소처럼 동작하며, AWS 리소스와 직접 매핑 가능.
  예: example.com → ELB, S3 버킷 등.

TTL (Time To Live)

🧩TTL (Time To Live)는 DNS 레코드가 캐시(저장)되는 유효 시간을 나타냅니다.

• 이 값은 초 단위로 설정되며, DNS 서버가 특정 레코드(A, CNAME 등)를 캐시하여 얼마 동안 유지할지를 결정합니다.
  TTL 값이 만료되면, DNS 서버는 해당 레코드를 다시 조회(새로 가져오기)합니다.

TTL의 주요 역할

1. DNS 조회 성능 향상
   • TTL 동안 캐시된 데이터를 사용하므로, 동일한 요청에 대해 DNS 서버에 반복적으로 쿼리하지 않아도 됩니다.
2. 네트워크 부하 감소
   • 요청이 줄어들어 DNS 서버와 네트워크의 트래픽을 줄이는 데 기여합니다.
3. 변경 반영 속도 조절
   • TTL 값이 짧으면 도메인 변경 사항이 빠르게 반영됩니다.
   • TTL 값이 길면 변경 사항 반영이 느려질 수 있지만 캐싱 효율이 높아집니다.

TTL 동작 방식

1. 사용자가 example.com을 요청.
2. 로컬 DNS 서버는 해당 도메인의 레코드를 캐시에 보관(TTL 시간 동안).
3. 사용자가 동일한 도메인을 요청하면, TTL 만료 전까지는 캐시에 저장된 데이터를 반환.
4. TTL이 만료되면, DNS 서버는 새 레코드를 조회하여 캐시에 저장.

TTL 설정 예시

TTL의 장단점

TTL 값 설정 가이드

1. 변경이 적은 도메인:
   • 긴 TTL(예: 1시간 이상)을 설정해 네트워크 부하를 줄이고 성능을 최적화.
   • 예: 정적 콘텐츠 웹사이트, 안정적인 리소스.
2. 변경이 빈번한 도메인:
   • 짧은 TTL(예: 5분)을 설정해 변경 사항을 빠르게 반영.
   • 예: 로드 밸런싱, 리소스가 자주 변경되는 환경.
3. 마이그레이션이나 테스트:
   • 매우 짧은 TTL(예: 30초~5분)을 설정해 IP 변경이 신속히 반영되도록 조치.
   • 예: 서버 마이그레이션, DNS 구성 변경 시.

TTL의 실제 사용 사례

1. 도메인 변경 반영
   • 예: 서버 IP 변경 시 TTL을 짧게 설정하여 새로운 IP로 빠르게 연결.
2. 로드 밸런싱
   • TTL을 적절히 설정하여 클라이언트가 최신 트래픽 라우팅 정보를 빠르게 가져오도록 조정.
3. DNS 캐싱 최적화
   • TTL 값을 늘려 네트워크 트래픽 감소 및 응답 시간 개선.

쉽게 이해하기

**TTL은 "DNS 정보가 얼마나 오래 유효할지 결정하는 유통기한"**입니다.

• TTL 값이 크면 네트워크 부하가 줄고 성능이 좋아지지만, 변경 사항 반영이 느려질 수 있습니다.
• 반대로 TTL 값이 작으면 변경 사항이 빠르게 반영되지만, 네트워크와 서버의 부하가 증가합니다.

Amazon RDS (Relational Database Service)

📌 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스입니다.

• 서버 관리, 백업, 복구, 성능 최적화와 같은 데이터베이스 운영 작업을 자동화하여 사용자가 데이터베이스 설계와 애플리케이션 개발에 집중할 수 있도록 돕습니다.

RDS의 주요 특징

1. 지원하는 데이터베이스 엔진
   • Amazon RDS는 다음과 같은 여러 관계형 데이터베이스 엔진을 지원합니다:
     • Amazon Aurora
     • MySQL
     • PostgreSQL
     • MariaDB
     • Oracle
     • Microsoft SQL Server
2. 자동화된 관리
   • 백업, 소프트웨어 업데이트, 복구, 스토리지 관리 등의 운영 작업을 자동으로 처리.
3. 고가용성 및 장애 복구
   • Multi-AZ 배포: 장애 발생 시 자동으로 대기 인스턴스로 전환.
   • 리드 리플리카(Read Replica): 읽기 작업을 분산하여 성능 향상.
4. 확장성
   • 데이터베이스 스토리지를 손쉽게 확장 가능(최대 128TiB).
   • 수직 확장을 통해 더 높은 사양의 인스턴스로 업그레이드 가능.
5. 보안
   • 데이터 암호화(AWS KMS 사용).
   • VPC 내에서 데이터베이스 실행으로 네트워크 보안 강화.
   • IAM과 통합하여 접근 제어 가능.

RDS의 주요 사용 사례

1. 웹 애플리케이션 백엔드
   • 사용자 데이터를 저장하고 검색하는 온라인 상거래, 소셜 네트워크, 콘텐츠 관리 시스템 등.
2. 데이터 분석
   • 비즈니스 데이터 분석 및 통계 처리.
3. 재무 및 ERP 시스템
   • 기업의 재무 및 운영 데이터를 안정적으로 저장.
4. 읽기 전용 워크로드
   • 리드 리플리카를 활용하여 대규모 읽기 작업 처리.

RDS의 주요 구성 요소

1. DB 인스턴스
   • 데이터베이스가 실행되는 가상 서버.
2. DB 스냅샷 및 백업
   • 데이터베이스를 주기적으로 백업하며, 특정 시점으로 복원 가능.
3. Multi-AZ 배포
   • 고가용성을 위해 데이터베이스를 기본(AZ1) 및 대기(AZ2) 인스턴스에 복제.
4. 리드 리플리카
   • 읽기 작업을 처리하는 복제본을 생성하여 읽기 성능을 향상.

RDS의 장단점

RDS와 자체 데이터베이스 관리의 차이

RDS와 Aurora 비교

쉽게 이해하기

• RDS는 AWS에서 관리해주는 데이터베이스 서버라고 보면 됩니다.
• 백업, 복구, 소프트웨어 업데이트를 AWS가 자동으로 처리하므로, 사용자는 데이터베이스 설계와 운영에만 집중할 수 있습니다.
• 웹 애플리케이션이나 분석 작업에 적합하며, 높은 가용성과 확장성이 필요한 환경에 최적화되어 있습니다.

Storage Auto Scaling

📌 Storage Auto Scaling은 Amazon RDS와 Amazon Aurora에서 데이터베이스 스토리지 용량을 자동으로 확장하는 기능입니다.

• 사용량이 증가해 스토리지 용량이 부족할 위험이 발생하면, 자동으로 스토리지를 확장하여 애플리케이션 가용성을 유지합니다.

Storage Auto Scaling의 주요 특징

1. 자동 확장
   • 스토리지가 한계치에 도달하기 전에 용량을 자동으로 확장.
   • 확장이 필요할 때 스토리지를 동적으로 추가하여 중단 없는 서비스 제공.
2. 최소/최대 용량 설정
   • 사용자는 스토리지 확장 범위의 최소 및 최대 용량을 설정할 수 있음.
   • 예를 들어, 최소 100GiB, 최대 1000GiB로 범위를 지정.
3. 무중단 확장
   • 스토리지 확장 작업이 데이터베이스 운영에 영향을 주지 않음.
   • 실시간으로 용량이 증가하여 성능 저하 없이 데이터베이스를 계속 사용할 수 있음.
4. 비용 효율성
   • 실제 필요할 때만 스토리지를 확장하므로 불필요한 과도한 용량 할당을 방지.
5. 지원되는 엔진
   • Amazon RDS: MySQL, MariaDB, PostgreSQL, Oracle, SQL Server.
   • Amazon Aurora: MySQL, PostgreSQL.

Storage Auto Scaling의 동작 방식

1. 초기 스토리지 설정
   • 데이터베이스 생성 시 초기 스토리지 크기 및 최대 확장 크기를 설정.
2. 사용량 모니터링
   • RDS는 현재 사용량을 모니터링하여 스토리지 한계에 도달할 것으로 예상될 경우 자동으로 확장.
3. 자동 확장
   • 스토리지가 임계값에 가까워지면 자동으로 확장 작업을 수행.
   • 확장 작업이 완료된 후, 데이터베이스는 확장된 용량을 사용.

Storage Auto Scaling의 주요 사용 사례

1. 예기치 않은 트래픽 증가
   • 쇼핑몰이나 이벤트 웹사이트에서 트래픽 폭증 시 데이터를 안정적으로 저장.
2. 장기적인 데이터 증가
   • 데이터가 지속적으로 축적되는 애플리케이션(예: 로그 데이터, 분석 데이터).
3. 비용 효율적인 스토리지 관리
   • 처음부터 과도한 용량을 할당하지 않고, 필요할 때만 확장.

Storage Auto Scaling의 장단점

설정 방법

1. RDS 콘솔에서 설정
   • 데이터베이스 생성 또는 수정 시 Storage Auto Scaling 활성화.
   • 최소 스토리지 크기, 최대 스토리지 크기, 확장 임계값을 지정.
2. CLI를 통한 설정
   • AWS CLI를 사용하여 Auto Scaling 활성화:

     aws rds modify-db-instance \
       --db-instance-identifier mydbinstance \
       --allocated-storage 200 \
       --max-allocated-storage 1000
     

Storage Auto Scaling과 Auto Scaling의 차이

항목 Storage Auto Scaling Auto Scaling (EC2)

쉽게 이해하기

Storage Auto Scaling은 데이터베이스에 필요한 "저장 공간"을 자동으로 늘려주는 기능입니다.
예를 들어, 클라우드의 하드디스크 공간이 부족해질 때 자동으로 더 큰 하드디스크를 추가해 주는 것과 같습니다.

Read Replicas

📌 Read Replica는 AWS에서 제공하는 기능으로, 관계형 데이터베이스의 읽기 성능을 향상시키기 위해 데이터베이스의 읽기 전용 복제본을 만드는 기술입니다.

• 이 복제본은 **원본 데이터베이스(Primary DB)**를 복제하며, 읽기 작업(Read-only)만 수행할 수 있습니다.
  이를 통해 원본 데이터베이스의 부하를 줄이고, 읽기 성능을 개선할 수 있습니다.
• INSERT, UPDATE, DELETE는 불가능!

Read Replica의 주요 특징

1. 읽기 전용 복제본
   • 복제본에서는 데이터를 읽는 작업만 가능하며, 쓰기 작업은 불가능.
   • 원본 데이터베이스에서 변경된 데이터를 비동기적으로 복제.
2. 비동기적 복제
   • 데이터는 실시간으로 복제되지 않고, 약간의 지연이 있을 수 있음(Lag 발생 가능).
   • 읽기 작업은 최신 데이터가 아닌 복제된 데이터 기준으로 수행.
3. 복제본 확장 가능
   • 다중 Read Replica 생성 가능(최대 5개).
   • 각 리드 리플리카는 별도의 읽기 엔드포인트(Endpoint)를 가짐.
4. 다른 리전으로 복제 가능 (Cross-Region Read Replica)
   • 원본 데이터베이스를 다른 리전으로 복제하여 지리적 거리로 인한 응답 지연을 최소화.
   • 데이터 리전 분산으로 장애 복구(Disaster Recovery) 준비 가능.
5. 자동 장애 복구는 지원하지 않음
   • Read Replica는 기본적으로 읽기 작업을 위한 것이며, 자동 장애 복구 기능은 없음.

Read Replica의 주요 사용 사례

1. 읽기 성능 향상
   • 읽기 트래픽이 많은 애플리케이션(예: 대규모 웹사이트, 분석 작업)의 부하 분산.
2. 데이터 분석
   • 실시간 데이터베이스에 영향을 주지 않고 복제본을 사용해 데이터 분석 수행.
3. 글로벌 애플리케이션 지원
   • Cross-Region Read Replica를 통해 전 세계적으로 빠른 읽기 성능 제공.
4. 데이터베이스 복구
   • 장애 발생 시 Read Replica를 수동으로 승격(Promotion)하여 새로운 Primary DB로 사용 가능.

Read Replica의 작동 방식

1. Primary DB에서 데이터 생성 및 변경
   • 쓰기 작업은 Primary DB에서만 가능.
2. 비동기 복제
   • 변경된 데이터가 Read Replica로 복제.
3. 읽기 작업 분산
   • 애플리케이션에서 읽기 작업을 Read Replica로 라우팅하여 Primary DB 부하를 줄임.

Read Replica와 Multi-AZ의 차이

Read Replica 설정 방법

1. AWS Management Console에서 설정
   • Primary DB를 선택 후, "Create Read Replica" 옵션 선택.
   • 엔드포인트를 생성하여 애플리케이션의 읽기 작업 연결.
2. CLI를 사용한 설정
3. aws rds create-db-instance-read-replica \ --db-instance-identifier my-read-replica \ --source-db-instance-identifier my-primary-db
4. Cross-Region Read Replica
   • 복제본을 생성할 때 다른 리전을 선택하여 복제본을 생성.

Read Replica의 장단점

쉽게 이해하기

**Read Replica는 "읽기 전용 복사본 서버"**입니다.
Primary DB가 처리하기 벅찬 읽기 요청을 대신 처리하여 성능을 높이고 부하를 줄이는 역할을 합니다.
예를 들어, Primary DB가 대출 업무를 처리하는 은행이라면, Read Replica는 대출 기록을 조회하는 고객 서비스 센터와 비슷한 역할입니다.

Multi AZ

📌 Multi-AZ (Multi-Availability Zone)는 Amazon RDS의 고가용성(High Availability) 기능으로, 데이터베이스를 여러 가용 영역(AZ)에 복제하여 장애 상황에서도 데이터베이스를 안정적으로 운영할 수 있도록 지원하는 기능입니다.

• 주 데이터베이스(Primary DB)가 장애를 일으키면, **자동으로 대기 인스턴스(Standby DB)**로 전환(Failover)되어 서비스 중단 시간을 최소화합니다.
• 데이터 서버가 터지면 데이터 복사해둔 예비서버가 대타출동한다.
• 당연히 위와 다르게 읽기 쓰기 다 적용된다.

Multi-AZ의 주요 특징

1. 자동 장애 복구 (Failover)
   • Primary DB에 장애가 발생하면 Standby DB가 자동으로 Primary 역할을 수행.
   • 사용자는 Failover를 수동으로 처리하지 않아도 됨.
2. 동기 복제 (Synchronous Replication)
   • Primary DB의 모든 데이터가 Standby DB에 동기적으로 복제되어 데이터 무결성 보장.
3. 읽기 요청 불가
   • Standby DB는 대기 상태에서만 작동하며 읽기 작업을 처리하지 않음.
4. 가용 영역 분산
   • Primary DB와 Standby DB는 **다른 가용 영역(AZ)**에 위치하여 자연재해나 네트워크 장애 같은 지역적 문제에도 대비 가능.
5. 자동 백업
   • RDS의 백업 작업은 Standby DB에서 수행되므로 Primary DB의 성능에 영향을 주지 않음.

Multi-AZ의 주요 사용 사례

1. 고가용성이 중요한 애플리케이션
   • 금융, 의료, 전자상거래 등 서비스 중단이 치명적인 애플리케이션.
2. 데이터 무결성이 중요한 워크로드
   • 데이터 손실을 허용할 수 없는 트랜잭션 기반 애플리케이션.
3. 자연재해 및 장애 대비
   • 데이터센터 장애, 네트워크 단절, 하드웨어 고장 등에 대비.

Multi-AZ의 작동 방식

1. Primary DB와 Standby DB 생성
   • RDS에서 데이터베이스를 생성할 때 Multi-AZ 옵션을 활성화하면, Primary DB와 Standby DB가 서로 다른 AZ에 자동으로 배포.
2. 동기 복제
   • Primary DB에서 변경된 데이터가 실시간으로 Standby DB에 복제.
3. 자동 장애 복구
   • Primary DB에 장애가 발생하면:
     • Standby DB가 Primary 역할을 수행.
     • 기존 Primary는 복구 후 Standby DB로 전환.
4. 사용자는 하나의 엔드포인트로 연결
   • 데이터베이스 접속 시 하나의 엔드포인트를 사용하며, 장애 복구 시에도 엔드포인트는 변경되지 않음.

Multi-AZ의 장단점

설정 방법

1. AWS Management Console
   • RDS 인스턴스 생성 시 Multi-AZ 배포 옵션 활성화.
2. CLI를 사용한 설정
   • 기존 DB를 Multi-AZ로 전환:

     aws rds modify-db-instance \
       --db-instance-identifier mydbinstance \
       --multi-az \
       --apply-immediately
     

Multi-AZ와 비용

• Multi-AZ 설정 시 Standby DB와 동기 복제 비용이 추가로 발생.
• 예를 들어, Primary DB에 사용한 만큼의 리소스 비용이 Standby DB에도 동일하게 청구됨.

쉽게 이해하기

**Multi-AZ는 "백업 서버를 항상 준비해 두는 시스템"**입니다.
Primary DB가 고장 나더라도 Standby DB가 자동으로 역할을 대신하므로, 서비스가 중단되지 않고 안정적으로 운영됩니다.
예를 들어, 주전 선수가 부상을 당하면 바로 교체 선수가 투입되는 상황과 비슷합니다.

[ 엄밀히 말하면 AWS에만 해당하는 내용은 아닙니다 ]

SSL (Secure Sockets Layer)

📌 클라이언트(웹 브라우저)와 서버 간의 데이터를 암호화하여 전송하는 보안 프로토콜입니다.

• 이를 통해 전송 중인 데이터가 도청, 위조, 변조되는 것을 방지합니다. 현재 SSL은 발전된 형태인 **TLS (Transport Layer Security)**로 대체되었지만, 여전히 SSL이라는 용어가 널리 사용되고 있습니다.

SSL의 주요 특징

1. 데이터 암호화
   • 클라이언트와 서버 간에 주고받는 데이터가 암호화되어, 도청 및 데이터 유출을 방지.
2. 인증
   • SSL 인증서를 통해 서버의 신뢰성을 검증.
   • 브라우저는 SSL 인증서를 확인하고, 클라이언트와 안전한 연결을 설정.
3. 데이터 무결성
   • 전송 중 데이터가 변조되지 않았는지 확인.

SSL의 동작 방식

1. SSL 핸드셰이크:
   클라이언트와 서버 간 안전한 연결을 설정하는 초기 과정.
   • 클라이언트가 서버에 연결 요청을 보냄.
   • 서버가 SSL 인증서를 클라이언트에 전달.
   • 클라이언트가 인증서를 검증 후 대칭 키를 생성.
   • 이후 암호화된 데이터 전송 시작.
2. 데이터 암호화:
   • SSL은 대칭 키 암호화(빠르고 효율적)를 사용해 데이터를 암호화.
   • 핸드셰이크 과정에서는 공개 키 암호화(비대칭 키)를 사용.

SSL의 주요 사용 사례

1. 웹사이트 보안 (HTTPS)
   • HTTPS는 HTTP에 SSL/TLS를 추가하여 데이터를 암호화.
   • 브라우저 주소창에 자물쇠 아이콘과 "https://"로 표시.
2. 전자 상거래 사이트
   • 온라인 결제 정보(신용카드, 개인정보) 보호.
3. 이메일 및 채팅 서비스
   • 이메일 전송 및 실시간 채팅의 보안 강화.
4. VPN 및 데이터 전송
   • 원격 서버와의 안전한 연결 및 데이터 전송.

SSL 인증서

1. SSL 인증서란?
   • 서버가 신뢰할 수 있는 기관(CA, 인증 기관)에서 발급받는 디지털 인증서.
   • 클라이언트는 이 인증서를 통해 서버의 신원을 확인하고, 안전한 연결을 설정.
2. SSL 인증서의 유형
   • 도메인 검증(DV): 도메인의 소유권만 인증.
   • 조직 검증(OV): 도메인 소유권과 조직 정보를 인증.
   • 확장 검증(EV): 엄격한 검증 과정을 거쳐 발급되며, 주소창에 회사 이름이 표시됨.

SSL과 TLS의 차이

SSL의 장단점

쉽게 이해하기

**SSL은 웹사이트와 사용자 간의 "비밀 통로"**를 만드는 기술입니다.
이 통로를 통해 데이터를 주고받을 때, 도청이나 해킹 걱정 없이 안전하게 사용할 수 있습니다.

추가 정보

1. HTTPS의 중요성
   • HTTPS를 적용하면 사용자의 개인정보(로그인 정보, 결제 정보 등)를 안전하게 보호.
   • Google은 HTTPS를 사용하는 웹사이트에 대해 SEO 순위를 높게 평가.
2. SSL 인증서 설치 과정
   • 도메인 구매 → 인증서 신청 → 인증서 설치 → 브라우저와 안전한 연결 설정.

[ SSL 과 SSH의 연관성 ]

TLS (Transport Layer Security)

📌 클라이언트와 서버 간의 데이터를 암호화하여 안전하게 전송하기 위한 보안 프로토콜입니다.

• SSL(Secure Sockets Layer)의 후속 버전으로, 더 높은 보안성과 성능을 제공합니다.
  오늘날 대부분의 HTTPS 트래픽과 보안 네트워크 연결에 TLS가 사용됩니다.

TLS의 주요 특징

1. 데이터 암호화
   • 클라이언트와 서버 간 전송되는 데이터를 암호화하여 도청을 방지.
2. 인증
   • TLS 인증서를 사용해 서버 또는 클라이언트의 신원을 검증하여 신뢰성을 보장.
3. 데이터 무결성
   • 데이터가 전송 중에 변경되거나 변조되지 않았음을 확인.
4. SSL 대비 향상된 보안
   • 보다 강력한 암호화 알고리즘과 키 교환 방식을 지원.

TLS의 주요 사용 사례

1. HTTPS
   • HTTP와 TLS를 결합한 HTTPS는 웹 브라우저와 서버 간 안전한 통신을 제공.
2. 이메일 보안
   • IMAP, POP3, SMTP 프로토콜과 함께 TLS를 사용해 이메일 데이터 암호화.
3. VPN 및 원격 액세스
   • TLS를 활용하여 원격 서버와 안전하게 연결.
4. 애플리케이션 보안
   • 금융 서비스, 전자 상거래, 메신저 등에서 데이터 전송 보호.

TLS의 동작 방식

1. TLS 핸드셰이크 과정
   클라이언트와 서버 간 보안 연결 설정을 위한 초기 과정.
   • 클라이언트가 서버에 연결 요청.
   • 서버가 TLS 인증서를 전달.
   • 클라이언트가 인증서를 검증.
   • 암호화 키를 교환하여 안전한 세션 시작.
2. 암호화 방식
   • 대칭 암호화: 세션 데이터 암호화(빠른 데이터 처리).
   • 비대칭 암호화: 핸드셰이크 과정에서 암호화 키 교환.

TLS의 주요 버전

1. TLS 1.0 (1999)
   • SSL 3.0의 후속 버전으로 출시.
   • 현재는 보안상의 이유로 사용 권장되지 않음.
2. TLS 1.1 (2006)
   • 보안 개선 및 프로토콜 안정화.
   • 2020년 이후 지원 종료.
3. TLS 1.2 (2008)
   • 강력한 암호화 및 HMAC 해싱 지원.
   • 현재 대부분의 HTTPS 트래픽에서 사용.
4. TLS 1.3 (2018)
   • 최신 버전으로, 보안 강화와 성능 최적화.
   • 불필요한 핸드셰이크 과정 제거로 빠른 연결 설정.

TLS의 장단점

쉽게 이해하기

• **TLS는 인터넷 통신의 "비밀 통로"**입니다.
• 서버와 클라이언트 간에 전송되는 데이터를 암호화하고, 통신이 안전하게 이루어지도록 보장합니다.
• 현재 HTTPS는 TLS를 사용하여 웹사이트의 보안을 강화하고 있습니다.

TLS 인증서

• TLS 인증서는 서버가 신뢰할 수 있는 기관(CA, Certificate Authority)에서 발급받아 사용.
• 클라이언트는 인증서를 통해 서버의 신원을 확인하고, 안전한 연결을 설정.

추가 정보

1. TLS 1.3의 주요 개선점
   • 불필요한 핸드셰이크 제거로 더 빠른 연결 속도.
   • 오래된 암호화 알고리즘 제거로 보안 강화.
2. HTTPS를 통한 SEO 향상
   • HTTPS를 적용하면 구글과 같은 검색엔진에서 웹사이트 순위를 높게 평가.

TLS와 관련된 추가 질문이 있다면 언제든 말씀해주세요! 😊

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

분산 시스템의 기본 Scalability vs Availability

[1] Scalability (확장성)

Scalability는 시스템이 사용자 수, 데이터 양, 처리량이 증가하거나 감소할 때, 성능과 처리 능력을 유지하거나 향상시키는 능력을 말합니다.
즉, **"얼마나 잘 확장할 수 있는가?"**를 측정하는 지표입니다.

Scalability의 주요 특징

1. 확장 방식
   • 수평 확장 (Horizontal Scaling):
     더 많은 서버나 인스턴스를 추가하여 확장.
     예: EC2 인스턴스를 추가하여 부하 분산.
   • 수직 확장 (Vertical Scaling):
     기존 서버의 리소스(CPU, RAM 등)를 업그레이드.
     예: 더 높은 사양의 EC2 인스턴스로 교체.
2. 목표
   • 높은 처리량과 성능 유지.
   • 사용자 증가, 데이터 처리량 증가에 따라 유연하게 대처.
3. 중요한 설계 요소
   • 무중단 확장 지원.
   • 부하 분산(Load Balancer)과 자동 확장(Auto Scaling) 설정.

예시

• Scalability가 뛰어난 시스템:
  전자상거래 사이트가 트래픽 급증(블랙프라이데이 등)에도 서버를 추가해 안정적으로 작동.
• AWS 서비스: Auto Scaling, DynamoDB의 확장성 등.

[2] Availability (가용성)

Availability는 시스템이 항상 정상적으로 작동하며, 사용 가능한 상태를 유지하는 능력을 의미합니다.
즉, **"서비스가 항상 사용 가능하게 유지되는가?"**를 측정하는 지표입니다.

Availability의 주요 특징

1. 주요 목표
   • 서비스가 중단되지 않고 사용 가능한 상태를 유지.
   • 사용자 요청에 대해 항상 응답 가능.
2. 중요한 설계 요소
   • 장애 복구(Recovery): 장애 발생 시 빠르게 복구.
     예: 장애가 난 인스턴스를 자동으로 교체.
   • 중복 구성(Redundancy): 중요한 시스템은 여러 복사본을 유지.
     예: 여러 AZ(가용 영역)에서 서버 실행.
   • 무중단 배포: 서비스 중단 없이 업데이트 적용.
3. Availability의 측정
   • **Uptime(가동 시간)**으로 측정.
     예: 99.9% 가용성은 1년 동안 약 8시간 45분의 다운타임 허용.

예시

• Availability가 높은 시스템:
  금융 서비스가 24/7로 항상 거래 가능.
• AWS 서비스: Multi-AZ RDS, ELB(Elastic Load Balancer)로 부하 분산.

Scalability와 Availability의 차이점

Scalability와 Availability의 관계

• Scalability는 Availability를 지원:
  트래픽 증가에 대응하지 못하면 서비스가 중단될 수 있으므로 확장성이 가용성을 높이는 데 도움.
• Availability는 Scalability를 필요로 함:
  가용성을 유지하려면 트래픽 증가 시 확장이 가능해야 함.

추가적인 고려 사항

1. Trade-off
   • Scalability와 Availability를 동시에 극대화하기 어렵기 때문에 우선순위를 설정해야 함.
     예: 초기에 가용성보다는 확장성에 초점을 맞출 수 있음.
2. AWS에서의 구현
   • Scalability:
     • Auto Scaling으로 EC2 인스턴스 수 조절.
     • DynamoDB의 읽기/쓰기 용량 자동 조정.
   • Availability:
     • ELB로 다중 인스턴스에 부하 분산.
     • Multi-AZ RDS로 장애 복구 및 중단 방지.
3. 실제 사례
   • Netflix:
     • Scalability: 글로벌 사용자 증가에 맞춰 서버를 확장.
     • Availability: 장애 발생 시에도 스트리밍 서비스가 끊기지 않도록 설계.

쉽게 이해하기

• Scalability는 "더 많은 손님을 받을 수 있는 큰 식당"을 만드는 것.
• Availability는 "식당이 항상 열려 있고 손님이 들어올 수 있는 상태"를 유지하는 것.

ELB (Elastic Load Balancer)

📌  **ELB (Elastic Load Balancer)**는 AWS에서 제공하는 트래픽 분산 서비스로, 애플리케이션의 가용성과 확장성을 높이는 역할을 합니다.

• ELB는 들어오는 요청(HTTP, HTTPS, TCP 등)을 여러 EC2 인스턴스나 컨테이너로 자동으로 균등하게 분배합니다.
  쉽게 말해, 서버 앞에서 교통 정리를 해주는 신호등 같은 역할을 합니다. 🚦

ELB의 주요 특징

1. 트래픽 분산
   • 사용자 요청을 여러 서버로 분산하여 트래픽 부하를 줄이고 성능을 최적화.
2. 고가용성 지원
   • 서버 중 일부가 다운되더라도 정상 작동하는 서버로 트래픽을 전달하여 서비스 중단 방지.
3. 확장성
   • 서버 수가 늘어나거나 줄어드는 상황에서도 자동으로 적응 가능.
4. 자동 상태 검사
   • 연결된 인스턴스(서버)의 상태를 지속적으로 모니터링하여 정상적인 인스턴스에만 트래픽 전달.
5. HTTPS/TLS 지원
   • 암호화된 트래픽(HTTPS)을 처리하여 보안을 강화.

ELB의 유형

AWS에서는 애플리케이션과 트래픽 유형에 따라 4가지 ELB 유형을 제공합니다.

ELB의 주요 사용 사례

1. 트래픽 부하 분산
   • 웹 서버 또는 애플리케이션 서버 간 요청을 분산하여 성능 최적화.
2. 서비스 중단 방지
   • 서버 장애 발생 시 정상 상태의 서버로 트래픽을 자동 전달.
3. HTTPS 지원
   • SSL/TLS 인증서를 로드 밸런서에 설치해 보안 트래픽 처리.
4. 자동 확장(Auto Scaling)과 결합
   • 서버가 추가되거나 삭제될 때 자동으로 인스턴스를 로드 밸런서에 등록.

ELB의 주요 구성 요소

1. 리스너 (Listener)
   • 로드 밸런서가 들어오는 요청을 수신하는 구성 요소.
   • 프로토콜과 포트 번호(예: HTTP:80, HTTPS:443)를 설정.
2. 대상 그룹 (Target Group)
   • 트래픽이 분배될 EC2 인스턴스, 컨테이너, 또는 IP 주소의 집합.
3. 상태 검사 (Health Check)
   • 대상의 상태를 주기적으로 확인하여, 정상 상태인 대상에만 트래픽 전달.

ELB의 장단점

ELB의 동작 과정

1. 클라이언트 요청이 ELB에 도달.
2. 리스너가 요청을 수신.
3. ELB는 요청을 **상태가 양호한 대상 그룹(Target Group)**의 인스턴스에 분배.
4. 인스턴스가 요청을 처리한 뒤, 클라이언트에 응답.

ELB와 Auto Scaling의 관계

• ELB는 트래픽을 분산하여 서버의 부하를 줄이고,
• Auto Scaling은 트래픽 증가/감소에 따라 서버를 자동으로 추가하거나 제거.
  이 둘을 결합하면 높은 가용성과 확장성을 동시에 확보할 수 있습니다.

쉽게 이해하기

• **ELB는 "트래픽 신호등"**입니다.
  클라이언트 요청이 서버로 몰리지 않도록 여러 서버로 교통정리를 해줍니다.
  고장 난 서버를 자동으로 제외하고, 정상 작동 중인 서버로만 트래픽을 보내줍니다.

Application Loadbalancer 사용해보기

#!/bin/bash
# 스크립트가 Bash 쉘에서 실행되도록 지정하는 선언.

apt-get update
# 패키지 관리자(Apt)를 통해 패키지 목록을 업데이트하여 최신 정보를 가져옴.

apt-get install -y nginx
# Nginx 웹 서버를 설치. "-y"는 설치 중 사용자 입력을 자동으로 승인.

cat <<EOF > /var/www/html/index.html
# "cat" 명령을 사용하여 HTML 파일을 작성.
# "<<"와 "EOF"를 사용하여 여러 줄의 텍스트를 하나의 파일로 입력.
# 이 텍스트는 "/var/www/html/index.html" 파일에 저장됨.
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Nginx</title>
</head>
<body>
<h1>Hello World!</h1>
<p>AWS deployed by Me!</p>
<p>private ip is $(hostname -f)</p>
</body>
</html>
EOF
# HTML 파일 작성 완료.
# $(hostname -f)는 현재 인스턴스의 호스트 이름(프라이빗 IP 포함)을 출력하여 HTML 페이지에 포함.

sudo systemctl start nginx
# Nginx 서비스를 시작.
# "sudo"를 사용하여 관리자 권한으로 실행.