CloudFront

: 전셰게 리전을 대상으로 하는 엣지 로케이션

• 정적 컨텐츠 배포시 용이
• 전세계 엣지 네트워크
• 국가 IP로 접근제한,허용 가능

사용하는 용도

S3 정적 컨텐츠(이미지, 영상) 및 동적 컨텐츠(API) 가속

HTTP/HTTPS(TCP) 기반의 웹 트래픽 처리에 최적화 (Layer 7)

Price & Price Class

(공부하면서 신기했던 포인트는 유럽,아메리카 지역보다 아시아 리전의 요금이 더 비쌈)

Price Class All

• 최상의 성능이며 모든 리전을 대상으로함

Price Class 200

• 가장 비싼 리전 제외

price Class 100

• 가장 저렴한 리전만 사용

CRR(Cross-Region-Replication)

: 전세계 대상으로 하는 엣지 로케이션이 아님 (원하는 리전 설정)

• 읽기 전용
• 전세계 리전으로 하는 대상 X
• 캐싱이 되지 않으며 실시간으로 갱신

사용하는 용도

• 일부 리전에만 배포를 할 때
• 특정 리전에서의 낮은 지연율을 의도할 때

VPC는 AWS에서 사용자가 직접 네트워크를 설계하고 제어할 수 있는 가상 사설 네트워크로, 클라우드 상에서 마치 자신의 데이터센터를 구축한 것처럼 IP 주소, 서브넷, 라우팅, 보안 설정 등을 자유롭게 구성할 수 있다.

VPC의 핵심 목적

VPC 주요 구성요소

Public Subnet vs Private Subnet 비교

VPC 보안 구성 요소 비교

VPC 고급 구성 요소

VPC 설계 시 고려사항

정리

VPC는 AWS 클라우드 환경에서의 네트워크 설계의 근간으로, 사용자가 직접 네트워크 범위, 라우팅, 서브넷, 보안 정책을 구성하여 격리된 환경 속에서 안전하고 유연한 애플리케이션 인프라를 구축할 수 있게 한다.

실제 아키텍처 설계에서는 Public/Private Subnet 구분, NAT Gateway 배치, Security Group/NACL 규칙 설정을 함께 고려해야 한다.

ReplicaSet과 Deployment 핵심 정리

쿠버네티스에서 애플리케이션을 안정적으로 운영하기 위해서는 Pod를 일정 개수로 유지하고, 무중단으로 새 버전을 배포할 수 있는 구조가 필요하다. 이 역할을 담당하는 대표적인 리소스가 바로 ReplicaSet과 Deployment다.

ReplicaSet이란

ReplicaSet은 지정된 수의 Pod를 항상 일정하게 유지하는 역할을 한다. 즉, 사용자가 원하는 개수(예: 3개)로 Pod를 정의하면, 쿠버네티스가 실제 실행 중인 Pod의 수를 지속적으로 감시하고 부족하면 새로 만들고, 초과하면 제거한다.

이때 ReplicaSet은 Pod의 이름으로 직접 관리하지 않고, label(라벨) 과 selector(선택자) 를 기준으로 Pod를 식별한다. 즉, 특정 label을 가진 Pod만 ReplicaSet의 관리 대상이 되며, 새로 생성되는 Pod에도 동일한 label이 붙어야 관리 범위 안에 포함된다.

핵심 동작 개념

• Pod가 의도한 개수보다 줄면 자동으로 새로 생성
• 반대로 너무 많으면 불필요한 Pod를 제거
• label과 selector가 일치하는 Pod만 관리 대상이 됨
• Pod의 이름은 ReplicaSet이 자동으로 생성하며, 사용자는 직접 관리하지 않는다

구조 요약

ReplicaSet은 크게 다음 세 부분으로 구성된다.

동작 원리 요약

1. 사용자가 replicas: 3 으로 정의
2. ReplicaSet이 selector 조건에 맞는 Pod를 감시
3. Pod가 2개면 → 새 Pod 1개 추가
4. 4개면 → 1개 삭제 이 과정을 지속적으로 반복해 지정된 수를 항상 유지한다.

결국 ReplicaSet은 label과 selector를 기준으로 Pod를 그룹화하고, 그 그룹 내에서 지정된 개수를 자동으로 유지하도록 동작한다.

Deployment란

Deployment는 ReplicaSet을 기반으로 버전 관리와 롤링 업데이트 기능을 추가한 리소스다. 즉, ReplicaSet을 직접 다루지 않아도 애플리케이션의 배포·업데이트를 자동으로 처리한다.

Deployment의 역할

• 새로운 버전의 이미지를 배포할 때, 기존 Pod를 한꺼번에 삭제하지 않고 순차적으로 교체(무중단 배포).
• 이전 버전 ReplicaSet의 상태를 기억하기 때문에 문제가 생기면 언제든 이전 버전으로 롤백 가능.
• 내부적으로 ReplicaSet을 생성·관리하지만, 사용자는 Deployment 단위로만 조작한다.

Deployment의 주요 필드

Deployment의 작동 방식

1. 사용자가 Deployment를 정의하고 kubectl apply 실행
2. 쿠버네티스가 해당 정의를 바탕으로 ReplicaSet 생성
3. ReplicaSet이 필요한 수만큼 Pod를 배포
4. 이미지 버전이 바뀌면 새 ReplicaSet을 만들어 순차적으로 교체 (Rolling Update)
5. 문제가 생기면 이전 ReplicaSet을 활성화해 복구 (Rollback)

ReplicaSet vs Deployment 비교

Pod

Pod는 쿠버네티스가 컨테이너를 실행하고 관리하기 위해 만든 논리적 단위이다.

• 보통 하나의 Pod에는 컨테이너가 한 개 들어가지만, 함께 동작해야 하는 컨테이너라면 여러 개를 하나의 Pod로 묶을 수도 있다.
• Pod 내부의 컨테이너들은 같은 네트워크(IP, 포트 공간)를 공유하며, 필요에 따라 볼륨을 통해 데이터를 교환한다.
• Pod 단위로 상태 점검 또는 자동 복구 정책을 적용할 수 있다.

즉, Pod는 단순히 컨테이너를 모아놓은 묶음이 아니라 애플리케이션이 실행되기 위한 최소한의 환경이라고 볼 수 있다.

Node

Node는 Pod가 실제로 실행되는 서버를 의미한다. 물리 서버일 수도 있고, 클라우드상의 가상 머신일 수도 있다.

• 하나의 Node에는 여러 Pod가 동시에 배포될 수 있다.
• Node는 Control Plane에서 내려오는 명령에 따라 Pod를 생성하거나 삭제하며 클러스터의 일부로 동작한다.

Node의 주요 구성요소

이 세 가지가 함께 동작해야 Node가 정상적으로 Pod를 실행할 수 있다

Control Plane과 Node의 관계

쿠버네티스는 크게 두 영역으로 나뉜다.

조금 더 쉽게 접근해보면

Control Plane - 두뇌 , Data Plane - 두뇌의 명령을 실행하는 구현체

Pod와 Node의 상호작용

• 사용자가 kubectl 명령이나 API를 통해 Pod를 생성하면, Control Plane의 스케줄러가 어떤 Node에 배치할지 결정한다.
• 이후 kubelet이 해당 Node에서 Pod를 띄우고, 런타임이 컨테이너를 실행한다.
• 이런 구조 덕분에 쿠버네티스는 여러 서버(Node)에 걸쳐 애플리케이션을 유연하게 관리할 수 있다.

이 상위 리소스들은 다음 기능을 제공한다.

• Pod의 자동 생성과 삭제
• 장애 발생 시 재생성
• 여러 인스턴스 복제와 확장
• 무중단 배포(rolling update)

즉, 사용자는 Pod 자체를 직접 다루기보다, Pod를 대신 관리해주는

리소스를 통해 안정적인 운영을 하게 된다.

📘 정의

AWS Database 서비스는 애플리케이션 특성에 맞춘 다양한 데이터베이스를 관리형으로 제공함. 관계형, 비관계형(NoSQL), 인메모리, 분석용 등 목적별로 선택 가능하며, 백업·확장·장애 복구를 자동화하여 운영 부담을 최소화함.

⚙️ 주요 서비스

🧱 Amazon RDS (Relational Database Service)

📘 정의

RDS는 관계형 데이터베이스를 완전관리형으로 제공하는 서비스임. 백업, 패치, 장애 복구, 확장을 AWS가 자동으로 처리함.

⚙️ 주요 특징

💡 사용 예시

• 웹/앱 서비스의 메인 데이터베이스
• 트랜잭션 중심 OLTP 시스템
• 자동 백업 기반 데이터 복구 환경

⚡ Amazon Aurora

📘 정의

Aurora는 AWS가 직접 개발한 클라우드 전용 고성능 RDBMS로, MySQL 및 PostgreSQL과 호환되며 상용 DB 수준의 성능과 안정성을 제공함.

⚙️ 주요 특징

💡 사용 예시

• 대규모 트랜잭션 처리 서비스
• 글로벌 사용자 대상 시스템
• 자동 확장 기반 서버리스 DB 환경

🌍 Amazon DynamoDB

📘 정의

DynamoDB는 완전관리형 NoSQL 데이터베이스로, 키-값(Key-Value) 및 문서(Document) 구조를 지원하며 밀리초 단위 응답 속도를 보장함.

⚙️ 주요 특징

💡 사용 예시

• IoT 센서 데이터 저장
• 세션 관리, 실시간 랭킹 서비스
• 서버리스 애플리케이션의 백엔드 DB

⚙️ Amazon ElastiCache

📘 정의

ElastiCache는 인메모리 캐시 서비스로, Redis 또는 Memcached 엔진을 기반으로 초저지연 데이터 접근을 지원함.

⚙️ 주요 특징

💡 사용 예시

• RDS/DynamoDB 쿼리 결과 캐싱
• 실시간 채팅·랭킹 시스템
• 세션 및 토큰 관리

📊 Amazon Redshift

📘 정의

Redshift는 대규모 데이터 분석용 컬럼형 데이터 웨어하우스(DWH) 서비스로, 페타바이트 단위 데이터를 빠르게 질의하고 BI 분석에 활용함.

⚙️ 주요 특징

💡 사용 예시

• 로그 및 클릭스트림 분석
• 데이터 웨어하우스 및 BI 대시보드
• 대규모 ETL 처리 환경

🔄 AWS DMS (Database Migration Service)

📘 정의

DMS는 온프레미스 또는 다른 클라우드의 DB를 AWS로 손쉽게 마이그레이션하는 서비스임. 이기종 간(Oracle → Aurora 등) 이전도 지원하며 운영 중단 없이 전환 가능함.

⚙️ 주요 특징

💡 사용 예시

• Oracle → Aurora PostgreSQL 이전
• MySQL → RDS 전환
• 운영 DB → Redshift 실시간 복제

📘 서비스 비교 요약

🧾 정리

AWS Database 계열은 운영형(OLTP) → 캐시 → 분석(OLAP) → 마이그레이션으로 이어짐.

설계 시 고려 포인트:

• 트랜잭션 vs 분석 중심 (RDS/Aurora vs Redshift)

• 관계형 vs 비관계형 (RDS/Aurora vs DynamoDB)
• 캐싱으로 응답속도 향상 필요 시 (ElastiCache)
• DB 이전 및 복제 자동화 필요 시 (DMS)

정의

EC2는 가상 서버(인스턴스) 를 제공하는 AWS의 핵심 컴퓨팅 서비스임. 사용자는 CPU·메모리·스토리지·네트워크 조합을 선택하여 원하는 형태의 서버를 구성할 수 있음. 즉, 클라우드에서 자유롭게 생성·확장·종료 가능한 가상 머신.

⚙️ 주요 특징

💡 사용 예시

• 웹/애플리케이션 서버
• 데이터베이스 서버
• HPC, GPU 기반 머신러닝 연산
• Auto Scaling 그룹 내 워커 노드

🌀 Amazon EC2 Auto Scaling

정의

Auto Scaling은 트래픽 변화에 따라 EC2 인스턴스를 자동으로 추가·제거하는 기능임. 가용성과 비용 효율을 동시에 확보함.

⚙️ 주요 구성요소

💡 사용 예시

• CPU 사용률 기반 자동 확장
• 트래픽 급증 대응
• 장애 복구 자동화

☁️ AWS Lambda

정의

Lambda는 서버 관리 없이 코드를 실행하는 서버리스 컴퓨팅 서비스임. 이벤트 기반으로 실행되며 사용량만큼 과금됨.

⚙️ 주요 특징

💡 사용 예시

• 고객이 S3 업로드 시 자동 처리
• 주문 내역이 DynamoDB에 새로 추가될 때마다 결제 처리 자동 수행
• API Gateway 백엔드 함수
• 서버리스 데이터 파이프라인
• 백엔드 작업 자동화 스크립트

🚀 AWS Elastic Beanstalk

정의

Elastic Beanstalk은 코드만 업로드하면 AWS가 자동으로 인프라를 구성·운영하는 PaaS 서비스임. EC2, Auto Scaling, ALB, CloudWatch를 자동으로 통합 관리함.

⚙️ 주요 특징

💡 사용 예시

• 웹 애플리케이션 자동 배포
• 테스트/스테이징 환경 구성
• 인프라 지식이 없는 개발자용 플랫폼

🐳 Amazon ECS (Elastic Container Service)

정의

ECS는 Docker 컨테이너를 실행·관리하는 AWS 전용 오케스트레이션 서비스 EC2 또는 서버리스 Fargate 런타임을 선택할 수 있음.

⚙️ 주요 특징

💡 사용 예시

• 마이크로서비스 아키텍처 운영
• CI/CD 파이프라인 배포
• 서버리스 컨테이너 (Fargate 기반)

☸️ Amazon EKS (Elastic Kubernetes Service)

정의

EKS는 Kubernetes를 완전관리형으로 제공하는 서비스로, 제어 플레인(Control Plane)을 AWS가 자동으로 관리함.

⚙️ 주요 특징

💡 사용 예시

• 쿠버네티스 기반 애플리케이션 관리
• 온프레미스 + AWS 하이브리드 클러스터
• Pod 단위 MSA 아키텍처

📘 서비스 비교 요약

🧾 정리

AWS Compute 계열은 IaaS → PaaS → Serverless → Container

설계 시 고려 포인트

• 인프라 제어 수준 (EC2 vs Lambda)
• 컨테이너 관리 복잡도 (ECS vs EKS)
• 자동화 및 확장 정책 (Auto Scaling / Beanstalk)
• 비용 최적화 전략 (Fargate, Spot, Savings Plan)

정의

EBS는 EC2 인스턴스 전용 블록 스토리지 서비스로, 가상 하드디스크처럼 동작함. 운영체제(OS), 데이터베이스, 애플리케이션 데이터 등 고성능·지속 저장이 필요한 데이터에 사용됨.

⚙️ 주요 특징

💡 사용 예시

• EC2 루트 볼륨
• 데이터베이스 스토리지 (MySQL, PostgreSQL 등)
• 지속성이 필요한 로그/트랜잭션 저장소

🗂️ Amazon EFS (Elastic File System)

정의

EFS는 NFS(Network File System) 기반의 공유 파일 스토리지임. 여러 EC2 인스턴스에서 동시에 접근 가능함.

⚙️ 주요 특징

💡 사용 예시

• 웹서버 간 공유 파일 저장소 (예: 이미지, 로그)
• 머신러닝 학습 데이터 공유 디렉터리
• 컨테이너 기반 워크로드의 공용 파일 저장

💽 Amazon FSx

정의

FSx는 특정 파일시스템을 완전관리형으로 제공하는 서비스임. Windows, Lustre, NetApp 등 특정 워크로드에 특화된 파일 시스템 제공함.

⚙️ 주요 유형

💡 사용 예시

• 사내 파일서버 클라우드 이전
• 대규모 AI/ML 트레이닝용 데이터 처리
• NetApp 환경을 AWS로 마이그레이션

🧱 AWS Storage Gateway

정의

Storage Gateway는 온프레미스 환경과 AWS 스토리지를 연결하는 하이브리드 서비스임. 로컬 서버에서 AWS S3, EBS, Glacier 등을 사용하는 것처럼 동작함.

⚙️ 주요 모드

💡 사용 예시

• 온프레미스 NAS → S3 전송
• 하이브리드 백업 환경 구성

🧊 AWS Backup

정의

AWS Backup은 EBS, RDS, DynamoDB, EFS, FSx 등 다양한 서비스의 백업을 통합 관리함.

⚙️ 주요 특징

💡 사용 예시

• EBS, RDS, DynamoDB 백업 관리
• 규제 준수용 장기 보존 정책 구성
• 다계정 DR 아키텍처 구성

📘 서비스 비교 요약

🧾 정리

AWS Storage 계열 서비스는 단순 저장소를 넘어 운영 환경(EC2), 협업(파일 공유), 분석(HPC), 백업/DR 등 다양한 목적에 맞게 활용됨.

설계 시 고려해야 할 포인트

• EC2 연동 여부 (EBS vs EFS)
• 온프레미스 연계 여부 (Storage Gateway)
• 백업/복구 정책 (AWS Backup)
• 규제/보존 요구사항 (FSx, Glacier, Object Lock 등)

정의 : S3는 AWS에서 제공하는 객체 스토리지 서비스로, 데이터를 파일 단위(Object 단위)로 저장하고 인터넷을 통해 접근할 수 있다. EC2가 ‘가상 서버’라면, S3는 ‘무한히 확장 가능한 클라우드 저장소’라고 이해할 수 있다.

S3의 핵심 목적

⚙️ S3 주요 구성요소

S3와 IAM의 관계

• S3 리소스 접근은 IAM 정책 또는 버킷 정책으로 제어됨
• EC2나 Lambda가 S3에 접근할 때는 IAM Role을 부여해 Access Key 없이 안전하게 API 호출 가능

📌 예시: EC2 → IAM Role 부여 → S3 버킷 접근 (s3:GetObject, s3:PutObject)

🧊 S3 저장 클래스 비교

💰 S3 비용 구조

S3 비용 = 저장 용량 + 전송량

비용 절감 팁

• 자주 접근하지 않는 데이터는 Glacier/IA로 이동
• S3 Intelligent-Tiering으로 자동 전환
• CloudFront를 이용해 트래픽 절감

🗂️ S3 버전 관리 & 백업

🔏 S3 보안 관리

⚙️ S3 관리 포인트

S3 활용 예시

🧾 정리

S3는 AWS의 대표적인 객체 스토리지 서비스로, 높은 내구성과 확장성을 제공하며 다양한 스토리지 클래스와 연계 서비스(CloudFront, Glacier, Lambda 등)를 통해 데이터 백업, 분석, 웹 호스팅 등 다양한 용도로 활용 가능하다.

실제 시스템 설계에서는 접근 패턴, 암호화 정책, Lifecycle 관리, 비용 구조를 함께 고려해야 효율적이고 안전한 스토리지 구성이 가능하다.

EC2는 클라우드에서 가상 서버(Instance)를 제공하는 서비스로, 사용자는 필요한 컴퓨팅 자원을 유연하게 생성하고 관리할 수 있으며 AWS에서 사용하는 가상의 컴퓨터라고 이해할 수 있다.

EC2의 핵심 목적

EC2 주요 구성요소

EC2와 IAM의 관계

EC2 인스턴스에서도 다른 AWS 리소스(S3, DynamoDB 등)에 접근할 수 있다. 이를 위해 IAM Role을 EC2에 연결하면, 인스턴스 내부 애플리케이션이 Access Key 없이 안전하게 AWS API를 호출할 수 있다.

예시: EC2 → IAM Role 부여 → S3 버킷 접근 (s3:GetObject)

EC2 요금 유형 비교

EC2 수명 주기

1. Launch : AMI, Instance Type, Key, Security Group 설정 후 시작
2. Running : SSH 또는 RDP로 접속 및 사용
3. Stop : 일시 중지 (EBS는 유지됨)
4. Terminate : 인스턴스 및 EBS 삭제 (복구 불가)

EC2 관리 포인트

정리

EC2는 AWS 클라우드에서 제공하는 가상 서버 서비스로 필요한 컴퓨팅 자원을 유연하게 사용할 수 있으며, Auto Scaling, ELB, IAM Role 등과 연계하여 확장성과 보안성을 동시에 확보할 수 있다.

실제 시스템 설계에서는 EC2의 요금제, IAM Role 설정,현재 상황 및 Auto Scaling 구조를 함께 고려하는 것이 중요하다.

IAM 정의

IAM (Identity and Access Management) 은 AWS 리소스(예: EC2, S3, RDS 등)에 접근할 수 있는 사용자와 권한을 관리하는 서비스다.

쉽게 말하면 “누가(AWS User, Role, Principal)가 무엇(Resource)에 어떤 방식으로(Action) 접근할 수 있는가”를 정의하는 시스템이다.

IAM의 핵심 목적

1. 인증(Authentication)

   • 누가 로그인했는지를 식별
   • 예: 사용자, 애플리케이션, 외부 ID 제공자 등

2. 인가(Authorization)

   • 인증된 사용자가 어떤 행동을 할 수 있는지 결정
   • 정책(Policy)을 통해 서비스별로 세밀하게 제어

3. 보안 관리(Security Control)

   • MFA(다단계 인증), 임시 자격 증명(STS Token), 최소 권한 원칙(Least Privilege Principle) 등을 통해 계정 보안 강화
   • 사용자의 접근 권한 주기적 검토, 비활성 계정 관리, Access Key 회전(rotate)을 통해 용이한 유지보수

IAM 주요 구성요소

IAM Policy 구조 예시

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket"
    }
  ]
}

• Effect: Allow 또는 Deny
• Action: 허용할 작업 (예: s3:GetObject)
• Resource: 적용 대상 리소스
• Condition: 특정 조건(IP, 시간대 등)

IAM의 역할 요약

정리

IAM은 필요에 의해 “누가, 무엇에, 어떻게 접근할 수 있는가”를 정의하는 AWS의 권한 관리 시스템이다.

모든 AWS 서비스는 IAM 위에서 동작하며, 보안 설계의 첫 단계는 항상 IAM 구조를 올바르게 잡는 것이다.

시작하기 전에

실습 전 리전이 왜 글로벌로 되어있을까? 라는 의문이 있었지만

AWS 자체에서 설정한 값이라 하기에 넘어가기로 했다.

실습순서

AWS Route53 검색 -> 도메인 등록 -> 사용할 도메인 찾기

필자의 경우는 실습용도라 가장 값이 저렴한 .click 도메인을 선택

도메인의 주소 선택하기 -> 결제진행

필자의 경우 해당 도메인은 실습용이라 자동 갱신을 비활성화 했다.

(만약 도메인을 장기적으로 사용하실 분은 기간을 넓게 설정하면 됩니다!)

도메인을 결제할 이용자의 결제 정보를 입력하면 된다.

한가지 주의할 점은 이메일의 경우 구매한 도메인이 잘 작동하는지

확인하는 메일이 발송되기 때문에 기입하는 과정에서 주의를 해야한다.

위와같은 메일을 받았다면 성공!

서칭을 해보니 도메인이 보통 빠르면 1~2시간 길면 반나절 정도 지난 후,

상태가 진행 중'에서 '성공' 바뀐다고 한다. (필자는 30분정도 걸렸습니다)

이후 ELB를 생성하여 연결하면 끝!

현재는 HTTP로만 통신을 하는데 추후에 EKS 다루면서 HTTPS로 마이그레이션도

해볼 계획이다.