잡학다식 개발일지

ECS(Amazon Elastic Container Service)

📌 AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. Kubernetes 기반의 EKS와 비슷하게 컨테이너를 실행하고 관리할 수 있지만, ECS는 AWS에서 설계한 독점적 컨테이너 관리 서비스라는 점에서 차이가 있습니다.

ECS란?

• Amazon ECS(Amazon Elastic Container Service)는 AWS에서 제공하는 고성능 컨테이너 관리 서비스로, Docker 컨테이너를 쉽게 실행, 관리, 확장할 수 있도록 설계되었습니다.
• 쿠버네티스와 달리 AWS에 최적화된 방식으로 작동하며, AWS의 모든 서비스와 깊게 통합되어 있습니다.
• EC2와 Fargate를 기반으로 컨테이너를 실행할 수 있습니다.

ECS의 주요 특징

1. AWS 서비스와의 깊은 통합:
   • Elastic Load Balancer(ELB), CloudWatch, IAM, ECR(Container Registry) 등 AWS 서비스와 매끄럽게 통합됩니다.
2. 유연한 실행 방식:
   • EC2 모드: 컨테이너를 EC2 인스턴스에서 실행. 사용자가 EC2 클러스터를 관리해야 함.
   • Fargate 모드: 서버리스 컴퓨팅 환경에서 컨테이너 실행. 인프라 관리 없이 실행 가능.
3. 클러스터 관리:
   • ECS는 클러스터의 컨테이너를 자동으로 스케줄링하고 관리합니다.
   • 작업(Task) 단위로 컨테이너를 실행하며, 필요에 따라 서비스를 자동으로 확장합니다.
4. Task Definition:
   • 컨테이너 구성(이미지, 포트, 네트워크 설정 등)을 정의하는 템플릿입니다.
   • 각 Task는 이 정의에 따라 실행됩니다.
5. 자동 확장:
   • ECS는 필요에 따라 클러스터를 확장하거나 축소합니다.
   • Amazon Application Auto Scaling과 통합되어 트래픽 증가에 따라 자동으로 리소스를 조정.
6. 보안:
   • AWS Identity and Access Management(IAM)과 통합되어 컨테이너 및 작업(Task)에 세분화된 액세스 권한을 설정할 수 있습니다.
7. 비용 최적화:
   • Fargate 모드를 통해 사용한 만큼만 비용 지불.
   • EC2 예약 인스턴스와 스팟 인스턴스를 사용해 비용 절감 가능.

ECS의 구성 요소

1. 클러스터 (Cluster):
   • ECS에서 컨테이너를 실행하는 리소스의 논리적 그룹.
   • EC2 인스턴스 또는 Fargate 작업으로 구성.
2. 작업 정의 (Task Definition):
   • 컨테이너 애플리케이션의 사양을 정의하는 JSON 템플릿.
   • 컨테이너 이미지, 메모리, CPU, 네트워크, 로그 등을 지정.
3. 작업 (Task):
   • 작업 정의(Task Definition)에 따라 실행된 컨테이너의 인스턴스.
4. 서비스 (Service):
   • 컨테이너를 지속적으로 실행하고, 실패 시 자동 복구를 보장.
   • 원하는 수의 작업(Task)이 항상 실행되도록 유지.
5. 컨테이너 인스턴스 (Container Instance):
   • ECS 클러스터의 EC2 인스턴스 또는 Fargate 인스턴스를 말함.
   • EC2 모드에서는 사용자가 직접 관리, Fargate에서는 AWS가 관리.
6. 로드 밸런싱:
   • 컨테이너가 실행 중인 작업(Task)을 로드 밸런서(예: ALB, NLB)와 연결 가능.

ECS 사용의 이점

1. AWS 통합:
   • ECS는 AWS 서비스와 긴밀하게 통합되어 설정 및 관리가 간단.
2. 유연성:
   • EC2와 Fargate 중 적합한 실행 방식을 선택 가능.
   • EC2는 더 많은 제어권을 제공하며, Fargate는 서버리스로 간편한 관리 제공.
3. 확장성:
   • AWS Auto Scaling과 통합되어 애플리케이션의 확장과 축소를 자동으로 처리.
4. 보안:
   • IAM을 통해 컨테이너 단위의 세분화된 권한 관리 가능.
   • PrivateLink, Security Group 등을 사용해 네트워크를 보호.
5. 비용 절감:
   • Fargate를 사용하면 사용한 만큼만 비용 지불.
   • EC2 예약 및 스팟 인스턴스를 통해 추가적인 비용 절감 가능.

ECS vs EKS

ECS를 사용하는 이유

• AWS에 최적화된 컨테이너 관리 서비스.
• 쿠버네티스를 몰라도 컨테이너 기반 애플리케이션을 쉽게 배포 및 운영 가능.
• AWS 서비스와의 통합으로 높은 안정성과 보안 제공.
• EC2와 Fargate 중 요구사항에 따라 선택 가능.

ECS 시작하기

1. 클러스터 생성:
   • AWS Management Console, CLI, SDK를 통해 생성.
2. 작업 정의(Task Definition) 작성:
   • 컨테이너의 이미지, 리소스 요구 사항 등을 설정.
3. 서비스 생성:
   • 클러스터 내에서 컨테이너 서비스를 실행.
4. 로드 밸런서 연결:
   • ALB 또는 NLB와 연결하여 트래픽 분산.
5. 모니터링:
   • CloudWatch를 통해 작업 상태 및 로깅 확인.

사용 사례

1. 단순 컨테이너 워크로드:
   • 마이크로서비스 기반 애플리케이션을 손쉽게 관리.
2. 백엔드 프로세싱:
   • 데이터 분석, ETL 작업과 같은 배치 작업 실행.
3. 자동 확장이 필요한 애플리케이션:
   • 트래픽 변화에 따라 자동으로 확장되는 애플리케이션.
4. AWS에 특화된 컨테이너 애플리케이션:
   • AWS 생태계에서 실행되며 쿠버네티스가 필요하지 않은 워크로드.

ECS는 AWS에서 컨테이너를 실행하고 관리하는 데 최적화된 서비스로, 간단한 설정과 AWS 통합으로 인해 많은 사용자가 선호합니다. EKS처럼 쿠버네티스의 학습 곡선이 필요하지 않으므로, 간단하고 빠른 컨테이너 관리를 원하는 경우 적합한 선택입니다! 😊

쿠버네티스(Kubernetes 줄여서 K8s)

 🐳 컨테이너화된 애플리케이션을 배포, 관리, 확장하는 오픈소스 플랫폼입니다. Google이 내부에서 사용하던 컨테이너 관리 시스템인 Borg를 기반으로 개발했으며, 현재는 **Cloud Native Computing Foundation(CNCF)**에서 관리하고 있습니다.

• 컨테이너화된 애플리케이션의 배포와 관리를 자동화하고, 애플리케이션의 가용성 및 확장성을 보장하는 데 주로 사용됩니다.

[컨테이너화?]

# Python 애플리케이션 예제
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

쿠버네티스의 주요 역할

1. 컨테이너 오케스트레이션:
   • 여러 대의 서버에서 컨테이너를 자동으로 배포하고 실행합니다.
   • 다양한 노드(서버)에 컨테이너를 효율적으로 분산 배치.
2. 애플리케이션 확장:
   • 트래픽에 따라 컨테이너의 수를 동적으로 확장하거나 축소.
3. 자동 복구(Self-healing):
   • 장애가 발생한 컨테이너를 감지하고 자동으로 재시작하거나 교체.
4. 로드 밸런싱:
   • 애플리케이션에 대한 요청을 여러 컨테이너로 분산 처리.
5. 서비스 디스커버리:
   • 컨테이너 간 통신을 위한 네트워크 디스커버리와 라우팅 제공.
6. 스토리지 오케스트레이션:
   • 다양한 스토리지 솔루션(NFS, AWS EBS, GCP Persistent Disk 등)과 통합.

쿠버네티스의 주요 구성 요소

1. 클러스터(Cluster):
   • 쿠버네티스는 클러스터 기반으로 작동하며, 클러스터는 여러 노드(서버)로 구성됩니다.
   • **마스터 노드(Control Plane)**와 **워커 노드(Worker Node)**로 나뉩니다.

A. 컨트롤 플레인 (Control Plane)

• 클러스터의 상태를 관리하고, 작업을 스케줄링하며, 노드 간 통신을 조정합니다.

컨트롤 플레인 구성 요소:

• API 서버 (kube-apiserver):
  • 쿠버네티스의 핵심 인터페이스로, 모든 명령과 작업이 이곳을 통해 처리됩니다.
• 컨트롤러 매니저 (kube-controller-manager):
  • 클러스터 상태를 모니터링하고 필요한 작업(예: 장애 컨테이너 복구)을 수행.
• 스케줄러 (kube-scheduler):
  • 새로 생성된 컨테이너(파드)를 실행할 노드를 결정.
• ETCD:
  • 클러스터 상태 정보를 저장하는 분산 키-값 저장소.

B. 워커 노드 (Worker Node)

• 실제로 컨테이너(파드)를 실행하는 물리적/가상 서버입니다.

워커 노드 구성 요소:

• Kubelet:
  • 노드에서 실행되는 에이전트로, 컨테이너 실행 상태를 관리.
• Kube-proxy:
  • 파드 간 네트워크 통신을 관리.
• 컨테이너 런타임:
  • 컨테이너를 실행하는 데 사용되는 소프트웨어(Docker, containerd 등).

1. 파드(Pod):
   • 쿠버네티스에서 컨테이너를 실행하는 최소 단위.
   • 하나의 파드 안에 여러 컨테이너가 있을 수 있으며, 이들은 동일한 네트워크와 스토리지를 공유.
2. 디플로이먼트(Deployment):
   • 애플리케이션 배포 및 관리 템플릿.
   • 새로운 버전의 애플리케이션으로 업데이트하거나, 컨테이너를 수평적으로 확장할 때 사용.
3. 서비스(Service):
   • 네트워크를 통해 파드에 접근할 수 있는 고정 IP와 로드 밸런싱을 제공합니다.
4. 네임스페이스(Namespace):
   • 클러스터 내에서 리소스를 격리하여 여러 사용자가 동시에 사용할 수 있도록 지원.

쿠버네티스의 주요 기능

1. 자동 확장 (Auto Scaling):
   • CPU, 메모리 등 리소스 사용량에 따라 컨테이너를 동적으로 확장/축소.
2. 롤링 업데이트와 롤백:
   • 애플리케이션을 다운타임 없이 새로운 버전으로 업데이트.
   • 문제가 발생하면 롤백 가능.
3. 셀프 힐링(Self-Healing):
   • 비정상적인 컨테이너를 감지하여 자동으로 재시작하거나 교체.
4. 스토리지 관리:
   • 로컬 스토리지, 클라우드 스토리지, 네트워크 스토리지와 통합.
5. 모니터링 및 로깅:
   • 클러스터 및 애플리케이션 상태를 모니터링할 수 있는 도구와 통합 가능(Prometheus, Grafana 등).

쿠버네티스의 장점

1. 멀티 클라우드 지원:
   • AWS, GCP, Azure, 온프레미스 등 다양한 환경에서 실행 가능.
2. 높은 가용성:
   • 자동 복구 및 로드 밸런싱을 통해 항상 안정적인 애플리케이션 실행 가능.
3. 확장성:
   • 필요에 따라 컨테이너와 클러스터를 쉽게 확장.
4. 커뮤니티 지원:
   • 대규모 오픈소스 커뮤니티와 광범위한 생태계.

쿠버네티스의 단점

1. 복잡성:
   • 설치 및 운영이 비교적 어렵고, 학습 곡선이 가파름.
   • 클러스터 관리와 설정에 대한 깊은 이해 필요.
2. 리소스 소비:
   • 클러스터 자체가 많은 리소스를 요구하므로, 소규모 프로젝트에는 적합하지 않을 수 있음.
3. 운영 비용:
   • 직접 쿠버네티스를 관리하려면 높은 수준의 DevOps 전문성이 필요.

쿠버네티스 사용 사례

1. 마이크로서비스 아키텍처:
   • 컨테이너화된 마이크로서비스를 배포 및 관리.
2. CI/CD 파이프라인:
   • 지속적 통합 및 배포를 자동화.
3. 멀티 클라우드 애플리케이션:
   • 다양한 클라우드 제공업체 간 클러스터를 통합 관리.
4. AI/ML 작업:
   • 머신러닝 워크로드 관리와 확장.

쿠버네티스 시작하기

1. 클러스터 생성:
   • 온프레미스(예: kubeadm, kind), 클라우드(EKS, GKE, AKS)에서 클러스터 생성.
2. kubectl 설정:
   • 클러스터와 상호작용하기 위해 kubectl CLI 사용.
3. 애플리케이션 배포:
   • Deployment, Service, Ingress 등을 설정하여 컨테이너 배포.
4. 모니터링 및 관리:
   • Prometheus, Grafana 등을 사용해 클러스터 상태 모니터링.

쿠버네티스는 컨테이너화된 애플리케이션의 배포와 관리를 표준화한 도구로, 클라우드 네이티브 환경에서 필수적인 기술로 자리 잡았습니다. 이를 활용하면 대규모 애플리케이션을 효율적으로 관리하고 확장할 수 있습니다. 😊

쿠버네티스 VS 젠킨스

젠킨스(Jenkins)의 역할

Jenkins는 CI/CD(지속적 통합 및 지속적 배포) 파이프라인을 구축하고 자동화하는 도구입니다. 즉, 소스 코드 변경 사항을 빌드하고, 테스트하며, 애플리케이션을 배포하는 과정의 일부를 자동화합니다.

젠킨스의 주요 역할

1. 지속적 통합(CI):
   • 소스 코드 변경 사항을 자동으로 빌드하고 테스트.
   • 코드 품질 보장을 위해 정적 분석 및 테스트 실행.
2. 지속적 배포(CD):
   • 코드 변경 사항을 스테이징 또는 프로덕션 환경에 자동 배포.
   • 쿠버네티스 클러스터에 새 애플리케이션 버전 배포도 가능.
3. 파이프라인 관리:
   • Jenkins 파이프라인을 사용해 빌드, 테스트, 배포 단계를 정의.
   • 다양한 플러그인을 통해 Docker 빌드, Helm 배포 등 작업 통합 가능.

쿠버네티스(Kubernetes)의 역할

쿠버네티스는 애플리케이션이 컨테이너화된 상태로 배포된 후, 이를 실행하고 관리하는 역할을 합니다. 즉, Jenkins와 같은 도구가 배포 작업을 완료한 이후의 운영 관리를 담당합니다.

쿠버네티스의 주요 역할

1. 배포 관리:
   • 컨테이너화된 애플리케이션을 클러스터에 배포.
   • 롤링 업데이트를 통해 애플리케이션을 중단 없이 새 버전으로 교체.
2. 확장성 제공:
   • 트래픽 증가에 따라 컨테이너 수를 자동으로 확장(스케일링).
   • 필요 시 리소스를 줄여 비용 최적화.
3. 장애 복구:
   • 장애가 발생한 컨테이너를 자동으로 감지하고 교체(셀프 힐링).
4. 로드 밸런싱:
   • 클러스터 내 여러 컨테이너에 요청을 분산 처리.
5. 환경 격리:
   • 네임스페이스를 사용해 여러 환경(예: 개발, 테스트, 프로덕션)을 단일 클러스터에서 분리.

Jenkins와 Kubernetes의 차이점

젠킨스와 쿠버네티스를 함께 사용하는 이유

1. 젠킨스의 역할: 배포까지 자동화
   • Jenkins는 코드를 빌드하고, Docker 이미지를 생성하며, 이를 컨테이너 레지스트리(예: Docker Hub, AWS ECR)에 푸시합니다.
   • 그런 다음, Kubernetes 클러스터에 새 버전의 애플리케이션을 배포하도록 트리거합니다.
2. 쿠버네티스의 역할: 운영 관리
   • 쿠버네티스는 Jenkins가 배포한 애플리케이션을 클러스터 내에서 실행, 확장, 복구, 모니터링합니다.

젠킨스와 쿠버네티스를 통합한 CI/CD 파이프라인 예시

1. 코드 푸시:
   • 개발자가 코드를 GitHub, GitLab 등 소스 코드 저장소에 푸시.
2. 빌드 및 테스트 (Jenkins):
   • Jenkins가 코드를 감지하고 빌드, 테스트 실행.
   • Docker 이미지를 생성하여 컨테이너 레지스트리에 푸시.
3. 배포 (Jenkins):
   • Jenkins가 Helm 또는 kubectl 명령을 사용해 쿠버네티스에 애플리케이션 배포.
   • 새로운 버전으로 애플리케이션을 업데이트.
4. 운영 및 확장 (Kubernetes):
   • 쿠버네티스가 애플리케이션 상태를 모니터링하고, 장애가 발생한 컨테이너를 복구.
   • 사용량 증가에 따라 컨테이너를 자동으로 확장.

예시: Jenkins 파이프라인

pipeline {
    agent any

    stages {
        stage('Clone') {
            steps {
                git 'https://github.com/example/repo.git'
            }
        }

        stage('Build') {
            steps {
                sh 'docker build -t my-app:${BUILD_NUMBER} .'
            }
        }

        stage('Push') {
            steps {
                sh 'docker push my-app:${BUILD_NUMBER}'
            }
        }

        stage('Deploy') {
            steps {
                sh 'kubectl apply -f deployment.yaml'
            }
        }
    }
}

쿠버네티스와 Jenkins를 함께 사용할 때의 장점

1. 자동화:
   • Jenkins는 CI/CD를 자동화하고, Kubernetes는 운영 관리를 자동화합니다.
2. 확장성:
   • Kubernetes는 컨테이너를 스케일링하고, Jenkins는 테스트와 빌드를 병렬로 실행할 수 있습니다.
3. 효율성:
   • Jenkins는 코드 변경 사항을 빠르게 배포하고, Kubernetes는 배포된 애플리케이션을 안정적으로 실행합니다.

쿠버네티스 단독 사용과 비교

쿠버네티스는 CI/CD를 처리하지 않으므로 Jenkins나 GitLab CI/CD 같은 별도의 도구가 필요합니다. 두 도구를 통합하면 코드 변경부터 배포, 운영 관리까지 엔드 투 엔드 자동화가 가능해집니다.

결론적으로 Jenkins는 CI/CD를 담당하고, Kubernetes는 배포 후 애플리케이션의 실행과 관리를 담당합니다. 이 둘을 통합하면 현대적이고 강력한 클라우드 네이티브 배포 파이프라인을 구축할 수 있습니다. 😊

EKS(Amazon Elastic Kubernetes Service)

📌 AWS에서 제공하는 쿠버네티스(Kubernetes) 관리 서비스입니다. EKS를 사용하면 AWS 클라우드 환경에서 컨테이너화된 애플리케이션을 손쉽게 배포, 관리, 확장할 수 있습니다.

EKS란?

• **Amazon Elastic Kubernetes Service (EKS)**는 쿠버네티스 관리형 서비스로, 사용자가 직접 Kubernetes 클러스터를 설정하거나 관리할 필요 없이, AWS가 이를 대신 관리합니다.
• 쿠버네티스의 컨테이너 오케스트레이션 기능을 그대로 사용할 수 있으며, AWS와의 통합으로 네트워킹, 보안, 확장성이 강화됩니다.

EKS의 주요 특징

1. 관리형 컨트롤 플레인:
   • EKS는 **쿠버네티스 컨트롤 플레인(Control Plane)**을 AWS에서 관리합니다.
   • 컨트롤 플레인의 고가용성을 자동으로 보장하며, 백업 및 복구 기능도 제공합니다.
2. 노드 관리:
   • 관리형 노드 그룹을 통해 워커 노드(Worker Node)를 쉽게 관리 가능.
   • AWS가 제공하는 EC2 인스턴스 또는 자체적으로 관리하는 온프레미스 노드에서 클러스터를 실행할 수 있습니다.
3. Fargate 지원:
   • 서버리스 컴퓨팅 환경인 AWS Fargate와 통합하여, 워커 노드를 관리하지 않고도 애플리케이션 실행 가능.
   • 작은 워크로드 또는 서버리스 환경에 적합.
4. 보안 통합:
   • IAM(AWS Identity and Access Management)을 통해 클러스터 및 워크로드에 대한 세분화된 액세스 권한 관리.
   • AWS PrivateLink를 통해 VPC 내에서 안전하게 클러스터 접근 가능.
5. 하이브리드 및 멀티 클라우드:
   • AWS Outposts 또는 EKS Anywhere를 사용하면 하이브리드 환경(온프레미스 및 클라우드)에서 클러스터 관리 가능.
   • EKS Anywhere: 온프레미스 환경에서 쿠버네티스를 실행하도록 지원.
6. 자동 확장:
   • EKS 클러스터는 필요에 따라 자동으로 워크로드를 확장할 수 있습니다.
   • Kubernetes의 Horizontal Pod Autoscaler(HPA) 및 Cluster Autoscaler(CA)를 지원.
7. AWS 서비스 통합:
   • EKS는 Elastic Load Balancer(ELB), CloudWatch, Amazon ECR(Container Registry) 등 AWS 서비스와 원활하게 통합됩니다.

EKS 사용의 이점

• 간소화된 관리: 쿠버네티스 컨트롤 플레인과 클러스터 인프라를 AWS가 관리.
• 높은 확장성: 필요에 따라 애플리케이션 및 클러스터를 자동으로 확장 가능.
• 보안 강화: AWS의 보안 서비스와 통합하여 안전한 쿠버네티스 운영.
• 비용 절감: Fargate를 통해 서버리스 방식으로 리소스 최적화.
• 멀티 리전 지원: AWS 글로벌 인프라를 기반으로 다양한 리전에서 클러스터 배포 가능.

EKS의 구성 요소

1. 컨트롤 플레인 (Control Plane):
   • Kubernetes API 서버와 관련된 모든 클러스터 관리 작업을 담당.
   • AWS에서 관리되며, 고가용성과 백업이 기본 제공됩니다.
2. 노드 그룹 (Node Groups):
   • 워커 노드가 실행되는 AWS EC2 인스턴스의 그룹.
   • 관리형 노드 그룹과 자체 관리 노드 그룹으로 나뉨.
3. Fargate:
   • 쿠버네티스 워크로드를 서버리스 방식으로 실행.
   • 노드 관리를 하지 않아도 되는 간편한 옵션.
4. IAM 및 역할:
   • EKS 클러스터와 워크로드에 대한 권한을 IAM으로 관리.
   • 사용자별 세분화된 권한 설정 가능.

EKS vs Kubernetes

EKS 사용 사례

1. 클라우드 네이티브 애플리케이션 개발:
   • 컨테이너화된 애플리케이션을 AWS에서 빠르게 배포하고 관리.
2. 하이브리드 클라우드:
   • 온프레미스와 AWS 클라우드 간 하이브리드 쿠버네티스 클러스터 운영.
3. 자동 확장이 필요한 서비스:
   • 트래픽 증가에 따라 빠르게 확장해야 하는 마이크로서비스 아키텍처.
4. DevOps:
   • CI/CD 파이프라인에 컨테이너 기반 워크로드를 쉽게 통합.

EKS 시작하기

1. AWS 콘솔에서 EKS 클러스터 생성.
2. 워커 노드 그룹 설정(EC2 또는 Fargate 선택).
3. kubectl을 통해 클러스터에 액세스.
4. 애플리케이션을 컨테이너로 패키징 후 클러스터에 배포.

EKS는 AWS에서 Kubernetes를 손쉽게 사용할 수 있도록 지원하며, AWS의 다양한 서비스와 긴밀하게 통합되어 있어 클라우드 네이티브 환경에서의 운영 효율성을 극대화합니다. 쿠버네티스에 익숙하다면 EKS를 통해 더욱 간편하게 컨테이너화된 애플리케이션을 관리할 수 있습니다. 😊

Elastic Beanstalk

📌 AWS Elastic Beanstalk는 애플리케이션 배포 및 관리 플랫폼으로, 애플리케이션 실행 환경을 손쉽게 설정, 배포, 관리할 수 있도록 도와줍니다.

• Elastic Beanstalk은 사용자가 애플리케이션 코드를 업로드하면, 자동으로 서버, 네트워크, 스토리지, 로드 밸런싱 등 인프라를 설정하고 관리해줍니다.

Elastic Beanstalk의 주요 특징

1. 자동화된 배포 및 관리
   • 사용자가 코드만 업로드하면, Elastic Beanstalk이 필요한 모든 인프라(EC2, S3, RDS, Load Balancer 등)를 자동으로 생성 및 구성.
2. 애플리케이션 관리
   • 애플리케이션 상태 모니터링, 로그 확인, 환경 업데이트를 손쉽게 수행.
3. 다양한 언어 및 플랫폼 지원
   • Java, Python, Ruby, .NET, Node.js, PHP, Go, Docker 등 다양한 언어와 플랫폼 지원.
4. 커스터마이징 가능
   • 기본 자동 설정 외에도, 사용자가 직접 세부 설정(인스턴스 유형, 네트워크 구성 등)을 수정 가능.
5. 스케일링 기능
   • 트래픽 변화에 따라 EC2 인스턴스를 자동으로 추가하거나 제거(수평 확장).
6. 통합된 AWS 서비스
   • CloudWatch, CloudTrail, S3, RDS 등 AWS 서비스와 원활하게 연동.

Elastic Beanstalk의 동작 원리

1. 코드 업로드
   • 사용자가 애플리케이션 코드를 업로드(예: ZIP 파일, Git 등).
   • AWS Management Console, CLI 또는 SDK를 통해 가능.
2. 환경 생성
   • Elastic Beanstalk은 업로드된 코드를 실행하기 위해 **환경(Environment)**을 생성.
     • 예: EC2 인스턴스, Auto Scaling 그룹, Load Balancer, RDS 데이터베이스 등.
3. 애플리케이션 배포
   • 코드가 실행 환경에 배포되고, 애플리케이션이 실행.
4. 모니터링 및 관리
   • Elastic Beanstalk은 애플리케이션 상태를 모니터링하고, 문제 발생 시 경고.

Elastic Beanstalk의 주요 구성 요소

Elastic Beanstalk의 주요 사용 사례

1. 웹 애플리케이션 배포
   • Python/Django, Java/Spring, Node.js 기반 웹 애플리케이션을 빠르게 배포.
2. API 서버 실행
   • RESTful API, GraphQL API 서버 배포 및 관리.
3. 백엔드 처리
   • 백엔드 작업(데이터 처리, 비즈니스 로직 실행)을 자동화된 환경에서 실행.
4. 개발 및 테스트
   • 개발자가 코드를 쉽게 배포하고 테스트할 수 있는 환경 제공.

Elastic Beanstalk의 장점

Elastic Beanstalk의 단점

Elastic Beanstalk vs EC2

Elastic Beanstalk를 쉽게 이해하기

• **Elastic Beanstalk는 "자동화된 애플리케이션 배포 도구"**입니다.
• 예를 들어:
  • 사용자가 Python Flask 애플리케이션을 작성했다면, 코드를 Elastic Beanstalk에 업로드.
  • Elastic Beanstalk은 EC2 인스턴스, 로드 밸런서, 데이터베이스 등을 자동으로 설정하여 실행 환경을 만듦.
• 사용자는 코드 개발에 집중할 수 있고, 인프라 관리는 AWS가 처리.

Elastic Beanstalk와 EBS의 관련성

Elastic Beanstalk(EB)는 AWS에서 애플리케이션을 배포하고 관리하기 위한 PaaS(Platform as a Service) 솔루션입니다.

반면, **EBS(Elastic Block Store)**는 AWS에서 제공하는 스토리지 서비스로, EC2 인스턴스에 연결할 수 있는 블록 스토리지를 제공합니다.

두 서비스는 직접적인 관계는 없지만, Elastic Beanstalk이 내부적으로 EBS를 활용하여 애플리케이션을 실행하고 관리하는 데 도움을 줍니다.

Elastic Beanstalk에서 EBS의 역할

1. EC2 인스턴스의 스토리지 제공
   • Elastic Beanstalk은 애플리케이션 실행을 위해 EC2 인스턴스를 생성하며,
     이 EC2 인스턴스에는 기본적으로 EBS 볼륨이 연결되어 있습니다.
   • EBS는 EC2 인스턴스의 운영 체제 및 애플리케이션 데이터를 저장합니다.
2. 애플리케이션 데이터 관리
   • 애플리케이션 실행 중 생성되는 로그 파일, 캐시 데이터, 임시 파일 등은 EBS 볼륨에 저장.
   • 필요에 따라 추가적인 EBS 볼륨을 Elastic Beanstalk 환경에 연결할 수도 있습니다.
3. 환경의 데이터 지속성 보장
   • Elastic Beanstalk 환경을 종료하거나 EC2 인스턴스를 중지하더라도,
     EBS 볼륨은 데이터를 유지하므로 데이터를 백업하거나 복구할 수 있습니다.
4. 커스터마이징 가능
   • Elastic Beanstalk 환경 설정에서 EC2 인스턴스에 연결되는 EBS 볼륨의 크기, 유형(IOPS 등)을 조정할 수 있습니다.
     이를 통해 애플리케이션의 스토리지 요구 사항을 충족.

Elastic Beanstalk과 EBS의 간접적 연결

Elastic Beanstalk은 애플리케이션 배포와 관리의 자동화를 제공하며,
이 과정에서 필요한 스토리지 서비스는 EBS를 기본적으로 사용합니다.

Elastic Beanstalk 환경에서 EBS 활용 사례

1. 로그 관리
   • Elastic Beanstalk 환경에서 생성된 애플리케이션 로그는 EBS에 저장됩니다.
   • 이를 통해 로그 데이터를 CloudWatch에 업로드하거나, 나중에 분석할 수 있습니다.
2. 애플리케이션 상태 복구
   • 애플리케이션 실행 중 장애가 발생한 경우, EBS 볼륨에 저장된 데이터로 애플리케이션 환경을 복구 가능.
3. 스토리지 확장
   • 애플리케이션이 더 많은 데이터를 저장해야 하는 경우, EBS 볼륨 크기를 조정하거나 추가 볼륨을 연결.

Elastic Beanstalk와 EBS의 관계를 쉽게 이해하기

• Elastic Beanstalk는 애플리케이션을 실행하고 관리하는 플랫폼이고,
  EBS는 Elastic Beanstalk이 애플리케이션 실행에 필요한 스토리지를 제공하는 기반 인프라입니다.
• Elastic Beanstalk은 EBS를 직접 관리하지 않지만,
  EBS는 Elastic Beanstalk이 사용하는 EC2 인스턴스의 스토리지로 항상 존재합니다.

추가적으로 알아야 할 점

• EBS 외의 스토리지 통합: Elastic Beanstalk은 EBS 외에도 S3(정적 데이터 저장), RDS(데이터베이스)와 같은 다양한 AWS 스토리지 서비스를 활용합니다.
• EBS 설정 변경 가능: Elastic Beanstalk의 커스터마이징 기능을 통해 EBS의 크기, 성능(Provisioned IOPS 등)을 설정할 수 있습니다.

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 값이 작으면 변경 사항이 빠르게 반영되지만, 네트워크와 서버의 부하가 증가합니다.