내가 제시한 풀이 방식

def timeConversion(s):
    timeZone=s[-2];
    hour_str = s[:2];
    hour_int = int(hour_str);
    others = s[2:-2]

    if timeZone=='P' and hour_int<12:
        hour_int+=12;
    elif timeZone=='A' and hour_int==12:
        hour_int=0;

    return f"{hour_int:02d}{others}"

제미나이가 말한 정석적 풀이

def timeConversion(s):
    meridiem = s[-2:]  # AM 또는 PM
    hour = int(s[:2])  # 시간 숫자화
    others = s[2:-2]   # :MM:SS 부분

    if meridiem == "AM":
        if hour == 12:
            hour = 0
    else: # PM인 경우
        if hour != 12:
            hour += 12

    return f"{hour:02d}{others}"

- Run these commands in your terminal to add Homebrew to your PATH:
    echo >> /Users/yeyeong_kwak/.zprofile
    echo 'eval "$(/opt/homebrew/bin/brew shellenv zsh)"' >> /Users/yeyeong_kwak/.zprofile
    eval "$(/opt/homebrew/bin/brew shellenv zsh)"
- Run brew help to get started

// 설정 파일에 빈 줄을 하나 추가
~ % echo >> /Users/yeyeong_kwak/.zprofile

// 맥이 켜질 때마다 Homebrew를 인식하게
~ % echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/yeyeong_kwak/.zprofile

// 방금 설정한 내용을 지금 바로 현재 터미널에 적용
~ % eval "$(/opt/homebrew/bin/brew shellenv)"
~ % brew --version
Homebrew 5.0.10

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

touch ~/.zshrc

echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.zshrc
echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> ~/.zshrc
echo '[ -s "$NVM_DIR/etc/bash_completion.d/nvm" ] && \. "$NVM_DIR/etc/bash_completion.d/nvm"' >> ~/.zshrc

source ~/.zshrc


nvm install --lts

corepack enable

brew install pyenv

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc

source ~/.zshrc

pyenv install 3.13

pyenv global 3.13

아직 프론트엔드를 별도로 만들지 않고 In-memory-repository를 생성해서 CSV 파일 데이터를 읽어온 후 터미널에서 입력받는 값에 따라 주문 관리 프로그램이 동작하도록 개발해보려고 한다.

1. Nest.js 프로젝트 생성

폴더를 생성하고

nest new .

입력하면

1. npm
2. yarn
3. pnpm(?기억이 잘 안 난다) 중에 선택하라고 뜨는데 yarn을 선택했다.

✔ Which package manager would you ❤️ to use? yarn

별도로 DB를 생성하지 않고 In-memory-repository를 생성해보도록 하겠다.

NestJS에서 node dist/main.js 실행 시 NestJS 내부에서 메모리 상에 하나의 ApplicationContext(=DI 컨테이너)가 생김

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

NestFactory.create(AppModule) 이 호출되는 순간

• Nest가 AppModule을 루트로 해서

• 그 안에 선언된 모든 @Module, providers, controllers 등을 스캔하고

• DI 컨테이너(앱 컨텍스트)를 구성

// app.module.ts
@Module({
    imports: [ProductModule, OrderModule],
    providers: [OrderCliService],
})
export class AppModule implements OnModuleInit {
    constructor(private readonly productService: ProductService) {}

    async onModuleInit() {
        await this.productService.loadCSV();
    }
}

main.ts에 정의된 bootstrap() 실행후에 바로 실행되는 onModuleInit() 함수가 모듈이 초기화될 때 자동으로 실행

❓ 언제 사용할까?

• DB 연결 초기화
• WebSocket 연결
• 이벤트 리스너 설정
• 기본 데이터 로딩
• 기타 초기화 작업 수행

src/app.module.ts에서 AppModule이 ProductModule을 임포트하고, OnModuleInit 훅에서 ProductService.loadCSV()를 한 번 호출

이 호출로 애플리케이션 부팅 시점에만 CSV를 읽어 메모리에 올리기

// src/products/product.service.ts

    async loadCSV() {
        const filePath = path.join(
            process.cwd(), // node 명령어를 실행하는 루트(폴더)
            'src',
            'product-data',
            'products.csv',
        );

        const products = await this.readCsv(filePath);
        this.productRepo.loadData(products);
        this.logger.log(`Loaded ${products.length} products into memory`);
    }

    async readCsv(filePath: string): Promise<Array<ProductTypes>> {
        const rows: Array<ProductTypes> = [];
        return new Promise((resolve, reject) => {
            fs.createReadStream(filePath, { encoding: 'utf-8' })
                .pipe(
                    parse({
                      //헤더(첫 행)를 읽고 컬럼명이 결정된 이후부터 각 row가 객체로
                        columns: (header) =>
                            header.map((h) => h.replace(/\uFEFF/g, '').trim()), //눈에 보이지 않는 특정 바이트를 넣은 UTF-8 BOM 형식이라서 상품번호 컬럼이 인식되지 않아서 
                        trim: true,
                        skip_empty_lines: true,
                    }),
                )
                .on('data', (data: ProductCsvRow) => {
                    const productId = data['상품번호'];
                    const productName = data['상품명'];
                    let salePrice = data['판매가격'];
                    salePrice = salePrice.replace(/[^\d.-]/g, '');
                    const stockQuantity = data['재고수량'];

                    rows.push({
                        productId,
                        productName,
                        salePrice: Number(salePrice) ?? 0,
                        stockQuantity: Number(stockQuantity) ?? 0,
                    });
                })
                .on('end', () => {
                    resolve(rows); // 스트림 파싱이 끝났으므로 Promise를 성공(fulfilled) 상태로 완료하고 rows를 반환
                })
                .on('error', (err) => reject(err));
        });
    }

parse() 함수로 CSV를 행(record) 단위로 파싱 => columns: true 또는 columns: (header) => ... 를 쓰면, 첫 행을 헤더로 써서 각 행이 객체로 출력

//src/products/in-memory-product.repository.ts

private readonly products = new Map<string, ProductTypes>();


loadData(products: ProductTypes[]) {
        this.products.clear();

        products.forEach((product: ProductTypes) => {
            this.products.set(product.productId, { ...product });
        });

        this.logger.log(
            `Loaded ${this.products.size} into in-memory repository`,
        );
    }

products map에 담아주기

또한 터미널 창이 곧 UI 역할을 하기 때문에 서버를 실행하면 cli도 실행할 수 있게

//main.ts

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    await app.listen(process.env.PORT ?? 3030);
    console.log(
        `HTTP SERVER LISTENING ON http://localhost:${process.env.PORT}`,
    );

    const cli = app.get(OrderCliService);
    await cli.run();
}
bootstrap();

//src/cli/order-cli.service.ts

async run() {
        let hasOrdered = false; // 주문 없이 터미널 창을 빠져나갈 때랑 아닐 때 메시지를 구별하기 위한 flag
        while (true) {
            const cmd = (
                await this.ask('입력(o[order]: 주문, q[quit]: 종료) : ')
            )
                .trim()
                .toLowerCase();

            if (cmd === 'q' || cmd === 'quit') {
                if (hasOrdered) {
                    console.log(`고객님의 주문 감사합니다.`);
                } else {
                    console.log(`주문을 종료합니다.`);
                }
                this.rl.close();
                process.exit(0);
            }

            if (cmd === 'o' || cmd === 'order') {
                const ordered = await this.handleOrderFlow();
                if (ordered) {
                    hasOrdered = true;
                }
            }
        }
    }


    private ask(question: string): Promise<string> {
        return new Promise((resolve) => {
            this.rl.question(question, (answer) => {
                resolve(answer);
            });
        });
    }

터미널 창으로 o나 order라는 단어가 입력되면

handleOrderFlow() 호출

// src/cli/order-cli.service.ts

    async handleOrderFlow(): Promise<boolean> {
        const items: { productId: string; quantity: number }[] = [];
        const products = await this.productRepository.findAll();
        const requested = new Map<string, number>();

        // 최초에 전체 상품 상품번호, 상품명, 가격, 재고 출력해주기
        printProducts(products);

        try {
            while (true) {
                // 1) 입력받은 상품 ID
                const productId = (await this.ask('상품번호 : ')).trim();

                // 2) 입력받은 수량
                const qtyStr = (await this.ask('수량 : ')).trim();
                const quantity = Number(qtyStr);

                const alreadyRequested = requested.get(productId) ?? 0;
                const requestedTotal = alreadyRequested + quantity;

                try {
                    const validatedProduct =
                        await this.orderInputValidator.validateLine(
                            productId,
                            quantity,
                        );

                    if ('end' in validatedProduct && validatedProduct.end) {
                        break;
                    }

                    if (!validatedProduct.ok && 'message' in validatedProduct) {
                        this.logger.log(validatedProduct.message);
                        continue;
                    }

                    if (validatedProduct.ok) {
                        items.push({
                            productId: validatedProduct.value.productId,
                            quantity: validatedProduct.value.quantity,
                        });
                        requested.set(productId, requestedTotal);
                    }
                    return true;
                } catch (err) {
                    const msg =
                        err instanceof Error
                            ? err.message
                            : '입력 처리 중 오류가 발생했습니다.';
                    this.logger.log(`${msg}\n`);
                }
            }

            if (!items.length) {
                console.log('주문 상품이 없습니다. \n');
                return false;
            }

            const summary = await this.orderService.createOrder(items);

            printSummary(summary);

            return true;
        } catch (e) {
            if (e instanceof SoldOutException) {
                this.logger.error(e.message, e.stack, e.name);
                return false;
            }

            const message =
                e instanceof Error ? e.message : '주문 처리 중 오류';
            this.logger.error(`주문 처리 중 오류가 발생했습니다. ${message}`);
            return false;
        }
    }

 // src/order/order.service.ts
@Injectable()
export class OrderInputValidator {
    constructor(
        @Inject('ProductRepository')
        private readonly productRepository: ProductRepository,
    ) {}

    async validateLine(
        productId: string,
        qtyStr: string,
        alreadyRequested: number,
    ): Promise<ValidateResult> {
        if (!productId && !qtyStr) {
            return { ok: false, end: true };
        }

        if (!productId || !qtyStr) {
            return {
                ok: false,
                message:
                    '상품번호와 수량을 모두 입력하거나, 둘 다 space+enter 입력으로 주문을 종료해 주세요.',
            };
        }
        const quantity = Number(qtyStr);

        if (!Number.isInteger(quantity) || quantity <= 0) {
            return { ok: false, message: '수량은 1개 이상 입력해주세요.' };
        }

        const product = await this.productRepository.findById(productId);
        if (!product) {
            return { ok: false, message: '존재하지 않는 상품번호입니다.' };
        }

        const requestedTotal = alreadyRequested + quantity;
        if (requestedTotal > product.stockQuantity) {
            const available = Math.max(
                product.stockQuantity - alreadyRequested,
                0,
            );

            return {
                ok: false,
                message: `${productId}-${product.productName}의 재고가 부족합니다. 현재 재고는 ${product.stockQuantity}개이며, 이미 ${alreadyRequested}개를 요청하셨습니다. 추가로 주문 가능한 수량은 ${available}개입니다.`,
            };
        }

        return { ok: true, value: { productId, quantity, requestedTotal } };
    }
}

1. in-memory-repo에 저장된 상품정보를 모두 불러와 출력해준다

2. 입력받은 상품 Id와 수량으로 유효성 체크를 한다 validateLine(productId, quantity)

   • 동작방식
     1. 상품 ID와 수량이 모두 입력되지 않으면 2. 상품 ID를 입력했지만 수량이 1 미만일 때 3. 존재하지 않는 상품번호를 입력했을 때 4. 상품 ID와 수량 입력 후 해당 상품의 재고수량보다 희망하는 수량이 클 경우 5. 유효성 통과 시 items 배열에 추가

// src/order/order.service.ts
@Injectable()
export class OrderService {
    constructor(
        @Inject('ProductRepository')
        private readonly productRepository: ProductRepository,
    ) {}
    async createOrder(items: { productId: string; quantity: number }[]) {
        const summary: OrderSummary = {
            lines: [],
            orderAmount: 0,
            shippingFee: 0,
            paymentAmount: 0,
        };
        for (const item of items) {
            const product = await this.productRepository.findById(
                item.productId,
            );
            if (!product) {
                throw new ProductNotFoundException();
            }

            if (item.quantity > product.stockQuantity) {
                throw new SoldOutException(
                    item.productId,
                    item.quantity,
                    product.stockQuantity,
                );
            }
            summary.orderAmount += item.quantity * product.salePrice;
            summary.lines.push({
                productId: item.productId,
                productName: product.productName,
                quantity: item.quantity,
            });

            await this.productRepository.decreaseStock(
                item.productId,
                item.quantity,
            );
        }

        // 주문 금액이 5만원 이하면 배송비 2,500원 더해주기
        if (summary.orderAmount < 50000) {
            summary.shippingFee += 2500;
        }

        summary.paymentAmount += summary.orderAmount + summary.shippingFee;

        return summary;
    }
}

1. 수평 확장성 2. 수직 확장성

➡️ 수직 확장성(Vertical Scaling, Scale Up/Down)은 기존 인스턴스 자체의 성능을 높이거나 낮추는 것

Q2. EC2 인스턴스 수를 확장 및 축소하는 Auto Scaling Group에서 애플리케이션을 실행하는 것을 .....................................(이)라고 합니다.

1. 수직 확장성(Vertical Scalability) 2. 수평 확장성(Horizontal Scalability)

➡️ 수평 확장성(Horizontal Scaling) → 인스턴스 개수를 조절

Q3. ELB는 ..................................을(를) 제공합니다.

1. 애플리케이션에서 사용할 수 있는 static IPv4 2. 애플리케이션에서 사용할 수 있는 static DNS 이름 3. 애플리케이션에서 사용할 수 있는 static IPv6

풀이💡

1. Static IPv4?

   ELB는 내부적으로 여러 가용 영역(AZ)의 여러 IP를 가지고 있어서 고정된 IP를 보장하지 않음

   요청이 들어올 때마다 다른 IP로 라우팅될 수 있음 → ❌

2. Static DNS 이름?

   ELB는 DNS 이름을 제공하고, 이 DNS 이름을 통해 항상 ELB에 접근할 수 있음

   ELB 뒤의 실제 IP는 변할 수 있지만, DNS 이름으로는 항상 접근 가능 → ✅

3. Static IPv6?

   IPv6도 ELB의 경우 마찬가지로 IP가 고정되지 않음 → ❌

Q4. 여러분은 ELB가 전면에 있는 10개의 EC2 인스턴스에서 웹 사이트를 실행하고 있습니다. 사용자는 웹 사이트 페이지 간에 이동할 때 웹 사이트에서 항상 재인증을 요청한다는 사실에 대해 불평하고 있습니다. 그러나 해당 웹사이트는 한 개의 EC2 인스턴스가 있는 개발 환경과 컴퓨터에서는 제대로 작동하기 때문에 의아합니다. 이 현상이 발생하는 이유는 무엇일까요?

1. ELB에 Sticky Session이 활성화되어 있지 않음. 2. 여러 EC2 인스턴스에서 호스팅할 때 웹 사이트에 문제가 있음. 3. EC2 인스턴스는 사용자가 자신의 IP 주소를 볼 수 없기 때문에 로그아웃 하는 대신 ELB IP주소를 수신.

풀이💡

1. ELB에 Sticky Session이 활성화되어 있지 않음 ✅ ELB는 기본적으로 라운드로빈 방식으로 요청을 분배합니다. 즉, 같은 사용자의 요청이라도 다른 EC2 인스턴스로 라우팅될 수 있음

   웹 애플리케이션이 세션 정보를 서버 메모리(Instance Local)에 저장하고 있다면, 다른 인스턴스로 요청이 가면 세션 정보가 없어 재인증 요청이 발생

   해결 방법: Sticky Session(세션 유지, Session Affinity) 활성화 → 사용자가 항상 같은 인스턴스로 요청이 가도록 함

2. 여러 EC2 인스턴스에서 호스팅할 때 웹 사이트에 문제가 있음. ❌

   여러 인스턴스 자체가 문제가 아니라, 세션이 인스턴스 간 공유되지 않아서 발생하는 문제입니다.

   즉, “호스팅 환경이 여러 대라서 문제”라는 표현은 정확하지 않아요.

3. EC2 인스턴스는 사용자가 자신의 IP 주소를 볼 수 없기 때문에 로그아웃 하는 대신 ELB IP주소를 수신. ❌

   사용자의 IP는 ELB를 거치면서 X-Forwarded-For 헤더로 전달 가능

   이 때문에 로그아웃이 일어나는 건 아님 → ❌

Q5. Application Load Balancer를 사용하여 EC2 인스턴스에서 호스팅되는 웹 사이트로 트래픽을 분산하고 있습니다. 웹 사이트는 실제로 Application Load Balancer의 IP 주소인 프라이빗 IPv4 주소에서 오는 트래픽만 보는 것으로 나타났습니다. 웹사이트에 연결된 클라이언트의 IP 주소를 얻으려면 어떻게 해야 할까요?

1. 사용자가 모든 요청에서 자신의 IP를 보내도록 웹사이트의 프런트엔드를 수정 2. X-Forwarded-For 헤더에서 클라이언트 IP 주소를 가져오도록 웹사이트의 백엔드를 수정 3. 웹사이트의 백엔드를 수정하여 X-Forwarded-Port 헤더에서 클라이언트 IP 주소를 가져옴 4. 웹사이트의 백엔드를 수정하여 X-Forwarded-Proto 헤더에서 클라이언트 IP 주소를 가져옴

풀이💡

1. 사용자가 모든 요청에서 자신의 IP를 보내도록 프런트엔드 수정 ❌

   사용자가 IP를 “보내도록” 하는 건 현실적으로 불가능

   HTTP 요청에는 이미 클라이언트 IP가 포함돼 있고, ALB가 이를 전달해줌 → ❌

2. X-Forwarded-For 헤더에서 클라이언트 IP 주소를 가져오도록 백엔드 수정 ✅

   ALB는 X-Forwarded-For 헤더에 실제 클라이언트 IP를 담아서 EC2로 전달

   따라서 백엔드에서 X-Forwarded-For 헤더를 읽으면 실제 클라이언트 IP 확인 가능 → ✅

3. X-Forwarded-Port 헤더에서 클라이언트 IP 가져오기 ❌

   X-Forwarded-Port는 요청이 들어온 포트 번호를 나타냄

   클라이언트 IP와는 관련 없음 → ❌

4. X-Forwarded-Proto 헤더에서 클라이언트 IP 가져오기 ❌

   X-Forwarded-Proto는 요청 프로토콜(http/https)을 나타냄

   IP와는 관련 없음 → ❌

Q6. ELB가 전면에 있는 일련의 EC2 인스턴스에서 애플리케이션을 호스팅했습니다. 일주일 후 사용자는 애플리케이션이 때때로 작동하지 않는다고 불평하기 시작합니다. 문제를 조사한 결과 일부 EC2 인스턴스가 때때로 충돌하는 것을 발견했습니다. 사용자가 충돌하는 EC2 인스턴스에 연결하지 못하도록 보호하려면 어떻게 해야 할까요?

1. ELB Stickiness 활성화 2. SSL Termination 활성화 3. ELB Health Checks 활성화 4. Cross-Zone Load Balancing 활성화

풀이💡

1. ELB Stickiness 활성화 ❌

   Sticky Session은 같은 사용자가 항상 동일한 인스턴스로 요청을 보내도록 하는 기능

   오히려 충돌한 인스턴스로 계속 연결될 수 있음 → ❌

2. SSL Termination 활성화 ❌

   SSL Termination은 SSL 암호화를 ELB에서 해제하는 기능

   트래픽 보호와는 관계 없음 → ❌

3. ELB Health Checks 활성화 ✅

   Health Check를 활성화하면 인스턴스 상태를 주기적으로 확인

   상태가 Unhealthy로 판단되면 ELB는 해당 인스턴스에 트래픽 전송을 중단

   충돌 인스턴스가 있어도 사용자는 문제 없이 다른 Healthy 인스턴스로 연결 가능 → ✅

4. Cross-Zone Load Balancing 활성화 ❌

   Cross-Zone LB는 여러 가용 영역(AZ) 간에 트래픽 분산

   충돌 인스턴스 차단과는 직접 관련 없음 → ❌

Q7. 여러분은 회사의 솔루션 아키텍트로 일하고 있으며 초당 수백만 건의 요청을 수신할 고성능, 저지연 애플리케이션을 위한 아키텍처를 설계해야 합니다. 어떤 유형의 ELB를 선택해야 할까요?

1. Application Load Balancer 2. Classic Load Balancer 3. Network Load Balancer

풀이💡

1. Application Load Balancer (ALB) ❌

   • L7 계층 (HTTP/HTTPS)

   • 기능: URL 기반 라우팅, Host 기반 라우팅, WebSocket 지원 등

   • 장점: 애플리케이션 로직 기반 라우팅

   • 단점: 초당 수백만 요청 같은 극한 성능, 저지연 처리에는 최적화 아님 → ❌

2. Classic Load Balancer (CLB) ❌

   • 초기형 ELB, L4 + L7 지원

   • 기능 제한, 성능 최적화 부족, 새로운 기능 부재

   • AWS에서는 신규 서비스 권장 아님 → ❌

3. Network Load Balancer (NLB) ✅

   • L4 계층 (TCP, UDP)

   • 특징:

   • 초고성능 (수백만 요청/초 처리 가능)

   • 극히 낮은 지연(latency)

   • 정적 IP, Elastic IP 지원

   고성능, 저지연 애플리케이션 요구사항에 최적 → ✅

Q8. Network Load Balancer의 지원에 포함되는 프로토콜은?

1. HTTP 2. HTTPS 3. WebSocket 4. Network Load Balancer

Q9. Application Load Balancer는 조건에 따라 트래픽을 다른 대상 그룹으로 라우팅할 수 있는데 그 조건이 아닌 것은?

1. 호스트 이름 2. 고객의 위치(지역) 3. 요청 URL 경로 4. 소스 IP-주소

풀이💡

1. 호스트 이름(Host Header)

   ALB에서 지원 ✅

   예: www.example.com → 대상 그룹 A, api.example.com → 대상 그룹 B

2. 고객의 위치(지역)

   ALB는 클라이언트 지역 기반 라우팅을 지원하지 않음 ❌

   위치 기반 라우팅을 하려면 Route 53 지리 위치 라우팅(Geo DNS) 사용 필요 → 정답 ✅

3. 요청 URL 경로(Path)

   ALB에서 지원 ✅

   예: /images/* → 대상 그룹 A, /api/* → 대상 그룹 B

4. 소스 IP 주소

   ALB는 IP 주소 기반 라우팅을 지원하지 않음 ❌

   IP 기반 제어는 Security Group, NACL, WAF 사용

   근데 왜 정답이지..?😢 => 라우팅 조건으로 직접 쓸 수 없지만, WAF나 Security Group에서는 제어 가능해서(좀 애매따리하다..)

Q10. Application Load Balancer의 대상 그룹에 등록된 대상이 아닌 것은?

1. Network Load Balancer 2. Lambda 함수 3. 비공개 IP 주소 4. EC2 인스턴스

풀이💡

1. Network Load Balancer (NLB) ✅

   대상 그룹에 NLB를 등록할 수 없음

   ALB → EC2, Lambda, IP 주소만 라우팅 가능

   NLB는 다른 ELB, 즉 서로 다른 계층의 로드밸런서이므로 등록 대상 아님

2. Lambda 함수

   ALB는 Lambda 함수를 대상으로 직접 호출 가능 ✅

3. 비공개 IP 주소(Private IP)

   ALB 대상 그룹에는 EC2 인스턴스의 IP나 VPC 내 Private IP 등록 가능 ✅

4. EC2 인스턴스

   가장 일반적인 대상 ✅

Q11. 규정 준수를 위해 최종 사용자에게 고정 static IP 주소를 노출하여 규제 기관에서 승인한 안정적인 방화벽 규칙 작성 시 어떤 유형의 ELB를 선택하시겠습니까?

1. Elastic IP가 연결된 Application Load Balancer 2. Network Load Balancer 3. Classic Load Balancer

Q12. Application Load Balancer에서 사용자 지정 애플리케이션 기반 쿠키를 생성하려고 합니다. 다음 중 쿠키 이름으로 사용할 수 있는 것은 무엇일까요?

1. AWSALBAPP 2. AWSALBTG 3. APPUSERC 4. AWSALB

Q13. us-east-1의 몇몇 EC2 인스턴스에 트래픽을 분산하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 EC2 인스턴스와 us-east-1e AZ에 5개의 EC2 인스턴스가 있습니다. us-east-1b AZ의 EC2 인스턴스에서 CPU 사용률이 더 높다는 것을 확인했습니다. 추가 조사 후 트래픽이 두 AZ에 균등하게 분산되어 있음을 알 수 있습니다. 이 문제를 어떻게 해결하시겠습니까?

1. Sticky Session 활성화 2. Cross-Zone Load Balancing 활성화 3. ELB Health Checkes 활성화 4. SSL 종료 활성화

로드밸런서가 AZ(가용영역) 단위로 먼저 트래픽을 똑같이 나눈다 = 트래픽이 두 AZ에 균등하게 분산되어 있음

풀이💡

1. Sticky Session 활성화

   NLB는 세션 기반 서비스가 아니고, 세션 스티키와 무관

2. Cross-Zone Load Balancing 활성화

   트래픽을 전체 인스턴스 기준으로 균등 분산해 CPU 불균형 해결

3. ELB Health Check 활성화

   문제는 “건강 상태”가 아니라 부하 불균형이므로 오답

4. SSL 종료 활성화

   트래픽 분산과 무관. NLB는 대부분 L4 TCP/UDP 로드밸런서라 SSL 종료도 일반적이지 않음.

Q14. Application Load Balancer와 Network Load Balancer의 어떤 기능을 통해 하나의 리스너에 여러 SSL 인증서를 로드할 수 있습니까?

1. 서버 이름 표시(SNI, Server Name Indication) 2. TLS 종료 3. 호스트 헤더 4. SSL 보안 정책

Q15. 다음 호스트 이름을 기반으로 트래픽을 3개의 대상 그룹으로 리디렉션하도록 구성된 Application Load Balancer가 있습니다: users.example.com, api.external.example.com 및 checkout.example.com. 이러한 각 호스트 이름에 대해 HTTPS를 구성하려고 합니다. 이 작업을 수행하려면 ALB를 어떻게 구성해야 할까요?

풀이💡

1. HTTP에서 HTTPS로의 리디렉션 규칙 사용 2. 보안 그룹 SSL 인증서 사용 3. SNI 사용

호스트 이름별(Host header) 로 트래픽을 서로 다른 대상 그룹으로 라우팅하려고 하고, 각 호스트에 대해 HTTPS(각기 다른 TLS 인증서) 를 적용하려고 함

Application Load Balancer(ALB)는 하나의 HTTPS 리스너(포트 443)에 여러 TLS 인증서를 연결할 수 있고, 클라이언트가 TLS 핸드쉐이크 시 서버명(Host)을 제시하면 ALB가 해당 호스트에 맞는 인증서를 선택해 응답. 이 방식이 SNI(Server Name Indication)

Q16. 목표 용량과 최대 용량을 모두 3으로 구성한 Auto Scaling Group에서 관리하는 EC2 인스턴스 집합에 호스팅되는 애플리케이션이 있습니다. 또한, CPU 사용율이 60%에 도달하면 ASG를 확장하도록 구성된 CloudWatch Alarm도 생성되어 있습니다. 이 애플리케이션이 갑자기 많은 트래픽을 수신하여 CPU 사용율이 80%라면 어떤 현상이 발생할까요?

1. 목표 용량은 4까지 올라가고 최대 용량은 3으로 유지된다. 2. 아무 일도 일어나지 않는다. 3. 목표 용량은 4까지 올라가고 최대 용량은 4으로 유지된다.

풀이💡

스케일 아웃(인스턴스 확장)은 최대 용량을 초과할 수 없음

Q17. ApplicationLoad Balancer가 전면에 있는 Auto Scaling Group (ASG)이 있습니다. ALB Health Checks을 사용하도록 ASG를 구성했는데 하나의 EC2 인스턴스가 비정상으로 보고되었습니다. EC2 인스턴스는 어떻게 될까요?

1. ASG는 인스턴스를 계속 실행하고 애플리케이션을 다시 시작합니다. 2. ASG는 EC2 인스턴스를 분리하고 계속 실행합니다. 3. ASG는 EC2 인스턴스를 종료합니다.

풀이💡

1. ASG는 인스턴스를 계속 실행하고 애플리케이션을 다시 시작 → ❌

   ASG는 Health Check 결과를 기준으로 인스턴스를 교체하는 구조

   단순히 애플리케이션 재시작은 하지 않음

2. ASG는 EC2를 분리하고 계속 실행 → ❌

   ‘분리’라 함은 트래픽에서 제거하는 것을 의미할 수 있음

   하지만 ASG 정책상 Unhealthy 인스턴스는 종료 후 새 인스턴스로 교체

3. ASG는 EC2 인스턴스를 종료 → ✅

   정확한 동작:

   ALB Health Check 실패 → ASG가 인스턴스를 Unhealthy로 판단

   트래픽에서 제거 → 종료 → 새로운 Healthy 인스턴스 생성

Q18. 여러분의 상사가 애플리케이션이 데이터베이스에 전송하는 분당 요청 수를 기반으로 ASG을 스케일링하도록 요청했습니다. 어떻게 해야 할까요?

1. 정중하게 불가능하다고 말한다. 2. CloudWatch 사용자 지정 지표를 생성한 다음 이 지표에 대한 CloudWatch 경보를 생성하여 ASG 확장. 3. 세부 모니터링을 활성화한 다음 CloudWatch 경보 생성해 ASG 확장.

풀이💡

• 2️⃣ CloudWatch 사용자 지정 지표 생성 후 경보를 만들어 ASG 확장 ✅

  정확한 방법:

  애플리케이션에서 DB 요청 수를 CloudWatch Custom Metric으로 전송

  해당 지표에 CloudWatch Alarm 설정

  Alarm 기준으로 ASG Scaling Policy 적용

  이 방법이면 요청 수 기준으로 자동으로 Scale Out/In 가능

• 3️⃣ 세부 모니터링(Enhanced Monitoring) 활성화 후 경보 생성 → ❌

  세부 모니터링은 EC2 인스턴스 자체 CPU, 네트워크, 디스크 등 기본 지표 해상도 향상

  DB 요청 수 같은 애플리케이션 레벨 지표는 제공하지 않음

  따라서 세부 모니터링만 활성화한다고 원하는 기준으로 스케일링 불가

Q19. 애플리케이션은 Application Load Balancer 및 ASG과 함께 배포됩니다. 현재 ASG를 수동으로 확장하고 EC2 인스턴스에 대한 평균 연결 수가 약 1000개인지 확인하는 확장 정책을 정의하려고 합니다. 어떤 스케일링 정책을 사용해야 할까요?

1. 단순 스케일링 정책 2. 단계 스케일링 정책 3. 스케줄 스케일링 정책 4. 대상 추적 정책

풀이💡

1. 단순 스케일링 정책(Simple Scaling) → ❌

   단일 CloudWatch Alarm에 따라 정해진 수만큼 인스턴스 증감

   문제: 연결 수가 목표치와 달라도 인스턴스 증감량이 고정 → 목표 달성 어려움

2. 단계 스케일링 정책(Step Scaling) → ❌

   특정 지표 범위(Step)에 따라 인스턴스 증감량을 조정

   연결 수가 약간 변동해도 대응 가능

   문제: 목표치를 정확히 맞추는 정책은 아님 → 조정 필요

3. 스케줄 스케일링 정책(Scheduled Scaling) → ❌

   특정 시간/요일에 자동 증감

   연결 수 기반은 아님 → 이번 시나리오와 무관

4. 대상 추적 정책(Target Tracking Scaling) ✅

   특정 지표(Target Value)를 기준으로 ASG 자동 조정

   예: Average ALB Connections = 1000 → ASG가 인스턴스 수를 자동으로 조정

   목표치를 정확히 유지하려는 경우 가장 적합

Q20. Auto Scaling Group에서 관리하는 EC2 인스턴스에서 호스팅되는 애플리케이션이 갑자기 급증한 트래픽을 수신하여 ASG가 확장되고 새 EC2 인스턴스가 시작되었습니다. 트래픽은 지속적으로 증가하지만 ASG는 새 EC2 인스턴스를 즉시 시작하지 않고 5분 후에 시작합니다. 이 동작의 가능한 원인은 무엇일까요?

1. 쿨다운 기간 2. 수명 주기 후크 3. 대상 추적 정책 4. 템플릿 시작

실제 웹 사이트나 애플리케이션은 시간이 지남에 따라 로드가 변한다

• 로드❓

  • 요청량(RPS, requests per second): 초당 들어오는 HTTP 요청 수
  • 동시 연결/동시 사용자(concurrent users): 동시에 처리해야 하는 세션 수
  • 리소스 사용량: 인스턴스의 CPU 사용률, 메모리 사용, 네트워크 대역폭, 디스크 I/O
  • 지연시간(latency)과 에러율(5xx 등): 로드가 높아지면 응답 시간이 길어지고 에러가 늘어날 수 있음

aws에서는 ec2 인스턴스 생성 api 호출로 아주 빠르게 서버를 생성하고 제거할 수 있다

➡️ 이를 자동화 하기 위해서 ASG(Auto Scaling Group)을 쓰는 것

ASG의 특징

1. 늘어난 로드에 맞춰 Scale Out(인스턴스 추가)

2. 줄어든 로드에 맞춰 Scale in(인스턴스 제거)

3. 전체적으로 매개변수를 정의해서 ASG에서 언제든 실행할 수 있는 최소 및 최대 EC2 인스턴스 수를 정할 수 있음

4. ASG와 로드 밸런서를 연결하면 ASG에 포함된 EC2 인스턴스가 로드 밸런서에 연결

5. 어떤 인스턴스가 비정상이라고 여겨지면 이것을 종료하고 새 인스턴스를 만들어 대체

6. ASG는 무료이지만 그 아래 생성되는 EC2와 같은 리소스들에 대해서만 비용을 지불하면 됨

ASG의 동작 방식

• Minimum Capacity => ASG에 필요한 최소 인스턴스 수 설정
• Desired Capacity => 희망 인스턴스 수
• Maximum Capacity => ASG에 필요한 최대 인스턴스 수

로드밸런서 + ASG의 동작방식

ASG에 등록된 인스턴스가 4개면 ELB가 즉시 모든 인스턴스에 트래픽을 분산 => 사용자는 로드 밸런서 웹 사이트에 접속 가능

ELB 상태 확인 기능을 활용해서 EC2 인스턴스 상태도 점검 가능 => 상태 확인 결과는 ASG에 전달될 수 있음

➡️ 로드 밸런서가 EC2 인스턴스를 비정상이라고 여기면 ASG가 인스턴스를 종료할 수 있음

스케일 아웃(인스턴스 추가)을 하면 ELB가 마찬가지로 추가된 인스턴스에도 트래픽을 보내 부하를 분산시킴

ASG 속성 및 구성요소

• Launch Template(옛 버전: Launch Configurations) ➡️ ASG에서 EC2 인스턴스를 시작하는 방법에 관한 정보가 있음

  • AMI
  • 인스턴스 타입(유형)
  • EC2 사용자 데이터
  • EBS 볼륨
  • 보안 그룹
  • IAM 역할
  • SSH 키페어
  • 네트워크와 서브넷 정보
  • 로드 밸런서 정보 등

• 최소 크기 / 최대 크키 / 초기 용량

• 스케일링 정책 정의해야 함

CloudWatch Alarms & Scaling

CloudWatch 경보를 기반으로 ASG에서 스케일 인, 스케일 아웃할 수 있음

클라우드 워치에서 평균 CPU를 관찰하거나, 사용자가 지정해준 지표를 검사하는 방식으로 임계점을 넘기면 알림을 울려 스케일 인, 아웃을 진행할 수 있다

ASG 실습

생성된 MyDemoTemplate 잘 출력되는 것 확인

기존에 만들어놓은 로드밸런서와도 연결

ASG가 EC2 인스턴스를 생성하기로 결정하면 작업 히스토리에 표시됨

Instance management 탭에서도 확인 가능

인스턴스 2개가 생긴 것 확인 가능

ASG 스케일링 정책

1. 동적 스케일링(Dynamic Scaling)

   • 목표 추적 스케일링(Target Tracking Scaling) ➡️ 설정이 매우 간단함 ex) CPU 사용률과 같은 ASG에 대한 메트릭을 정의하고 40%와 같은 목표값 정의

   • 단순(Simple) / 단계(Step) 스케일링 ➡️ CloudWatch Alarm이 반드시 필요 ex) CPU > 70% → 인스턴스 2개 추가

2. 예약 스케일링(Scheduled Scaling) ➡️ 알려진 사용 패턴을 기반으로 스케일링을 예상 ex) 금요일 오후 5시에 매번 새로운 사용자가 발생 => 최소 용량을 10으로 증가

3. 예측 스케일링(Predictive Scaling) ➡️ AWS 머신러닝이 지속적으로 트래픽 패턴을 예측해 자동으로 스케일링 반복되는 패턴이 있을 때 좋음 ex) 쇼핑몰, 월말 배치 작업 등

ASG Metrics

1. CPU 사용률(CPU Utilization) ➡️ 인스턴스가 요청을 받을 때마다 일반적으로 일종의 계산을 수행 모든 인스턴스의 평균 CPU 사용률을 살펴본 후 이 비율이 높아지면 인스턴스의 활용도가 더 높다는 의미

2. 요청 수(Request Count) ➡️ 인스턴스 별 요청 count에 따라 스케일링을 진행하는 방식

3. 네트워크 트래픽(Network In / Out) ➡️ 인스턴스가 보내거나 받는 데이터량을 기준으로 스케일링 ex) 업로드와 다운로드가 너무 많아 EC2 인스턴스에 병목현상이 발생될 것이라 예상된다면, 평균 네트워크 사용량을 기준으로 스케일링을 설정하는 것이 좋다

4. 사용자 정의 지표(Custom Metrics) ➡️ CloudWatch에 직접 지표를 만들어서 ASG 스케일링 기준으로 쓸 수 있음 ex) 큐 길이(SQS 메시지 수), 애플리케이션 처리율, DB 연결 수 등

Scaling Cooldowns

➡️ ASG에서 인스턴스를 추가하거나 제거한 후 일정 시간 동안 추가 스케일링을 막는 시간 / 서버를 늘렸는데 바로 다시 늘리는 상황을 막기 위한 “안정화 시간” 같은 개념 ➡️ 기본적으로 5분의 쿨다운 시간이 적용됨

💡 서버를 바로 띄울 수 있는 AMI를 쓰면, 서버 세팅 시간을 줄여서 요청을 더 빨리 처리할 수 있고, ASG의 cooldown 시간도 줄일 수 있다

WHY❓ ➡️ ASG가 새 EC2를 추가할 때 서버가 준비되는 시간이 길면 cooldown 동안 충분히 효과를 발휘하지 못할 수 있음 이미 설정이 끝난 AMI를 사용하면 서버가 바로 준비되기 때문에

1. 사용자 요청을 빨리 처리 가능
2. ASG가 다음 스케일링을 판단할 때 cooldown 시간도 최소화 가능

Instance Refresh(인스턴스 새로고침)

➡️ ASG 안에 있는 기존 EC2 인스턴스를 순차적으로 종료하고 새 인스턴스로 교체하는 기능 ➡️ 새 AMI로 업데이트하거나 설정 변경 후, 모든 인스턴스를 최신 상태로 맞추고 싶을 때 사용 ➡️ 새로 생성된 EC2 인스턴스가 실제 트래픽을 처리할 준비가 되는 시간인 Warm-up Time 지정 가능

• 사용 목적

1. AMI 업데이트 반영 기존 인스턴스는 오래된 AMI로 만들어져 있을 수 있음 새 AMI로 교체하여 보안 패치, 소프트웨어 버전 업데이트 등 적용 가능

2. 구성 변경 반영

   Launch Template이나 Launch Configuration 변경 후, ASG 내 모든 인스턴스를 새 설정으로 맞추고 싶을 때

3. 건강한 상태 유지

   일부 인스턴스가 오래되거나 문제 있을 때, 점진적으로 교체하면서 서비스 중단 최소화

• 주요 옵션

  옵션	설명
  MinHealthyPercentage	교체 진행 시 최소 몇 % 인스턴스가 정상이어야 하는지 설정
  Instance Warm-up	새 인스턴스가 준비되는 시간(Helth 체크까지 대기)
  Auto Scaling group selection	특정 ASG만 새로고침 가능

인스턴스(또는 타깃)를 서비스에서 빼거나(스케일 인, 교체, 종료) 헬스체크 실패로 제거할 때, 기존에 열린 연결(요청)을 일정 시간 동안 유지해 처리 완료되도록 하고 새로운 연결은 그 인스턴스로 보내지 않게 하는 기능 => 트래픽을 “부드럽게 끊는” 장치

Classic ELB vs ALB/NLB(=ELBv2) 용어 차이

• Classic ELB: 용어로 Connection Draining이라 부름(콘솔/CLI 옵션 있음)

• ALB / NLB (ELBv2 Target Group): Deregistration delay 라고 부름 (초 단위로 설정) 동일한 개념: 제거 시 기존 연결을 일정 시간 허용

필요한 이유?

• 요청 중단 방지: 사용자의 요청(특히 긴 요청, 업로드/다운로드, WebSocket 등)이 중간에 끊기는 걸 막음

• 무중단 배포: 인스턴스 교체(Auto Scaling, 배포) 시 서비스 가용성 유지

• 데이터 무결성: 트랜잭션/세션이 중단되는 사고를 줄임

동작 원리

1. 인스턴스/타깃을 Deregister(또는 ELB가 인스턴스 종료를 감지) 요청을 받음

2. ELB/Target Group은 그 인스턴스로의 새 연결(요청)을 중단시킴

3. 기존에 이미 맺어진 연결이나 이미 전달된 요청(인플라이트 requests)은 지정된 대기 시간(드레이닝 시간) 동안 계속 처리되도록 허용

4. 드레이닝 시간 내에 처리 완료되면 정상적으로 연결 종료

5. 시간이 지나도 연결/요청이 남아있다면 강제 종료(컷오프) 후 완전 제거

설정(AWS 관점)

• Target Group (ALB/NLB): deregistration_delay.timeout_seconds (최대 3600초(1시간) 가능)

  예: 기본 300초(5분)인 경우가 많음(계정/설정에 따라 다름)

• Classic ELB: Connection Draining 설정에서 Enabled + Timeout(초) 설정 가능

• ALB&NLB CLI 예시

  aws elbv2 modify-target-group-attributes \
  --target-group-arn <tg-arn> \
  --attributes Key=deregistration_delay.timeout_seconds,Value=300
  

* CLB CLI 예시
```bash
aws elb modify-load-balancer-attributes \
  --load-balancer-name my-elb \
  --load-balancer-attributes '{"ConnectionDraining":{"Enabled":true,"Timeout":300}}'

세부 동작 / 주의 포인트

• 새 연결은 차단되지만 기존 연결(keep-alive, WebSocket, TCP 연결 등) 은 유지됨

• ALB의 경우, HTTP 요청이 이미 백엔드에 도달한 상태라면 그 요청은 처리되도록 허용

• 긴 시간 걸리는 요청(대용량 업로드 등)이 있으면 드레이닝 시간을 충분히 길게 잡아야 함

• 강제 종료 조건: 드레이닝 시간이 끝나면 남은 연결은 강제로 닫힘 — 그러므로 처리시간보다 드레이닝 시간을 길게 잡아야 안전

• Health checks: 인스턴스가 헬스체크 실패 상태로 바뀌면 드레이닝이 트리거됨(제거 절차 시작)

• Sticky session 영향: 쿠키 기반 세션이 있어도, 드레이닝 중엔 해당 인스턴스로 새 요청을 보내지 않으니 세션 유실 가능성 고려 필요(세션 공유 권장)

‼️ 헬스체크가 즉시 드레이닝을 트리거하진 않고, 헬스체크의 판정(연속 실패 수)이 나와야 드레이닝(제거 절차)이 시작된다 => 헬스체크가 설정한 unhealthy threshold 만큼 연속 실패하면 그 타깃을 언헬시로 표시하고, 그 시점에 deregistration(제거) 절차/드레이닝이 시작

요약 정리

• 헬스체크가 ‘실패했다 → 바로 드레이닝’이 아니다: 실패는 연속 실패 수로 판정되므로 즉시 트리거 되지 않음(설정에 따라 지연 있음)

• 드레이닝 중에도 헬스체크는 계속 수행된다

• 드레이닝 시작 후 타깃이 다시 정상(헬시) 판정을 받으면, ALB는 드레이닝을 중단하고 해당 타깃을 다시 서비스에 포함시킬 수 있다

• 즉, 일시적 장애(네트워크 일시 오류 등)였고 빠르게 회복되면 제거가 취소될 수 있음

• 인스턴스가 즉시 죽거나 프로세스가 강제 종료된 경우에는 '드레이닝 대기'가 의미가 없고 이미 맺어진 연결도 끊김 → 사용자 요청 실패

SSL/TLS => 클라이언트와 서버(또는 로드밸런서) 사이의 통신을 암호화해서 중간에서 패킷을 도청하거나 변조하는 걸 막아줌(in-flight encryption)

• SSL(Secure Sockets Layer) => 연결을 암호화할 때 사용

• TLS(Transport Layer Security) => SSL의 새 버전 / 전송 계층 보안을 의미

SSL과 TLS 모두 전송 계층과 애플리케이션 계층 사이에서 동작하고 자체 포맷(X.509)은 동일하게 쓰이지만 1. 프로토콜 문법(핸드셰이크 방법) 2. 허용하는 암호화 알고리즘(암호 스위트) 3. 보안 약점 제거 여부 등 기술적 세부사항들이 다르다

퍼블릭 SSL 인증서는 인증 기관에서 발행 ex) Comodo, GoDayy, GlobalSign, DigiCert, Letsencrypt, ..etc

인증서가 적용된 것

SSL 인증서는 사용자가 정한 만료 날짜가 존재 & 인증서의 진위 확인을 위해 주기적으로 갱신해야 함

• 로드밸런서는 X.509 인증서를 사용하며, 이것을 SSL 또는 TLS 서버 인증서라고 부른다
• ACM → AWS 인증서 관리자로 인증서를 등록하고 관리할 수 있다
• HTTP 리스너를 설정할 때는 기본 인증서를 지정 & 인증서 목록을 추가해 여러 도메인 지원 가능
• 클라이언트는 SIN(Server Name Indication: 서버 이름 표기)를 활용해 도달하려는 호스트 이름 지정 가능
• HTTPS에 특정 보안 정책을 설정해서 레거시 클라이언트라고 불리는 SSL / TLS 구버전 지원 가능

SNI(Server Name Indiciation)

하나의 IP/포트(보통 :443)에서 여러 도메인의 TLS(HTTPS) 사이트를 호스팅할 수 있게 클라이언트가 TLS 연결 초기에 접속하려는 호스트명(도메인)을 서버에 알려주는 확장

즉, 같은 IP에 siteA.com과 siteB.com이 있어도 각각 다른 인증서를 쓸 수 있게 해준다

클라이언트가 대상 서버의 호스트 이름을 지정하도록 해야한다

• 최초 SSL Handshake 단계에 이루어진다
• 클라이언트가 '이 웹 사이트에 연결하고 싶다'라고 접속할 웹 사이트를 알려줌으로써 서버는 어떤 인증서를 로드해야 하는지 알 수 있음
• 모든 클라이언트가 지원하지 않는다

ALB & NLB, CloudFront에서만 지원 로드밸런서에 여러 SSL 인증서가 표시되면 ALB나 NLB 떠올리기!

ALB & NLB vs CLB

ALB & NLB

• 여러 개의 SSL인증서 통해 웹 서비스를 여러 개 둘 수 있다
• SNI를 지원하기 때문에 가능

CLB

• 하나의 인증서만 지원
• 만약 여러 호스트를 지원하려면 그에 맞는 클래식 로드밸런서 갯수가 필요함

SSL 실습

AWS 로드밸런서(ALB, NLB, CLB)가 여러 AZ(Availability Zone) 에 배포된 상태에서 각 로드밸런서 노드가 모든 AZ의 인스턴스들에 균등하게 트래픽을 분산시키는 기능

1) 기본 모드(비활성화 시) → 각 AZ의 로드밸런서 노드는 자기 AZ 안에 있는 인스턴스에게만 트래픽을 전달함.

예시)

AZ A: 로드밸런서 노드 1개 + 인스턴스 2개 => 25%씩 AZ B: 로드밸런서 노드 1개 + 인스턴스 3개 => 6.25%씩

➡️ 트래픽 분배 결과

• A => 25%씩
  • B => 6.25%씩

2) Cross-Zone LB 활성화 시 → 각 AZ의 로드밸런서 노드가 모든 AZ의 인스턴스들에게 트래픽을 골고루 분배함

➡️ 트래픽 분배 결과 => 각 인스턴스에 트래픽이 10%씩 균등 분배됨

ALB의 경우 기본적으로 Cross-Zone Load Balancing이 활성화 되어있음 비활성화는 대상 그룹(Target Group) 레벨에서 가능 데이터가 가용 영역으로 넘어가도 요금이 부과되지 않음(보통은 AZ를 넘어가면 과금)

NLB, GWLB의 Cross-Zone Load Balancing은 비활성화 => 활성화 시 과금 데이터가 가용 영역으로 넘어가서 과금 되기 때문

CLB Cross-Zone Load Balancing은 비활성화 되어있지만 데이터가 가용 영역으로 넘어가도 요금이 부과되지 않음

클라이언트가 로드 밸런서에 두 번의 요청을 할 때 백엔드에서 동일한 인스턴스가 요청에 응답하도록 하는 것 => 여러 대의 서버가 있어도, 특정 사용자의 요청을 계속 같은 서버로 보내주는 기능

CLB, ALB, NLB에서 활성화 할 수 있음

• 동작 방식

클라이언트가 로드 밸런서로 요청을 보낼 때 쿠키(스티키니스 + 만료날짜 포함된)가 함께 전송

=> 이 쿠키가 만료되면 클라이언트가 다른 EC2 인스턴스로 리다이렉션 될 수 있음

• ALB에서 sticky session의 동작

  1) 쿠키 기반 세션 고정

  ALB는 쿠키(cookie) 를 사용해서 세션을 고정

  • 사용자가 ALB에 요청을 보냄

  • ALB가 자기 마음대로(정책에 따라) EC2 하나를 골라서 보냄 (예: EC2 #2)

  • 그리고 응답할 때 특별한 쿠키를 내려 줌: 예: AWSALB, AWSALBTG 같은 이름

  이 쿠키 안에는:

  • “이 사용자 → 어떤 Target Group/Target으로 붙었는지”에 대한 정보가 들어 있음

  그 다음 요청부터는:

  1. 브라우저가 ALB에 요청을 할 때 그 쿠키를 같이 보냄

  2. ALB는 쿠키를 보고:

  “아 이 유저는 예전에 EC2 #2에 붙어 있던 애네?” → 다시 EC2 #2로 고정해서 보냄

  2) 세션 지속 시간(만료 시간) ALB의 sticky session은 “타임아웃(지속 시간)”을 설정할 수 있음

  예: 300초(5분), 3600초(1시간) 등

  즉, 그 시간 동안은 → 같은 Target으로 고정

  시간이 지나면:

  쿠키가 만료 → 다시 로드 밸런서 정책(라운드 로빈 등)에 따라 다른 서버로 갈 수도 있음

• Sticky Session의 Use-case

  1. 세션을 서버 메모리에 저장하는 레거시 애플리케이션

  2. 서버가 사용자 상태를 메모리에 들고 있을 때

     • 시험 시스템(남은 시간/문제 상태가 메모리에 저장)
     • 실시간 설문/게임 룸 상태

  3. WebSocket / Long Polling 기반 서비스

     • WebSocket 핸드셰이크나 Long Polling 요청은 서버와 계속 이어지는게 안정 적

  4. 큰 파일 업로드

     • 대용량 업로드 과정에서 서버가 "현재 몇 MB 전송됨" 같은 상태를 메모리에 보유

• Sticky Session의 단점

  1. 트래픽 분산이 불균형해질 수 있음(특정 서버에 트래픽 몰림)

  2. 서버가 죽으면 그 유저의 세션도 바로 날아감

  3. Auto Scaling 시 새 서버로 교체되면 sticky가 무용지물될 수 있음

  4. Stateless 아키텍처의 장점을 못 가져감

Sticky Session을 위한 쿠키의 종류

1. 애플리케이션 기반 쿠키

   • 커스텀 쿠키(Custom Cookie)

     • 애플리케이션 자체(target group?)에서 생성하는 사용자 정의 쿠키
       • 애플리케이션에서 필요로 하는 모든 사용자 정의 속성 포함 가능
       • 쿠키 이름은 각 타켓 그룹마다 개별적으로 지정
       • AWSALB, AWSALBAPP, AWSALBTG와 같은 이름들은 사용해선 안 됨!! => 예약어

   • 애플리케이션 쿠키(Application Cookie)

     • 로드 밸런서 자체에서 생성
     • 쿠키 이름 = AWSALBAPP

2. 지속 시간 기반 쿠키

   • 로드 밸런서에서 생성
   • 쿠키이름: ALB => AWSALB / CLB => AWSELB
   • 특정 시간에 따라 만료되며 지속 시간은 로드 밸런서 자체에서 생성
   • 애플리케이션 기반 쿠키가 있을 때는 지속 시간을 애플리케이션 자체에서 지정 가능

Sticky Session 설정 실습

대상그룹(Target Group) => 속성 변경(Edit Attributes) => Stickiness 옵션

새로고침 후 DNS Name 주소로 접근하면

방화벽, IDS/IPS, DPI(Deep Packet Inspection) 같은 “네트워크 보안/트래픽 분석 장비”를 AWS에서 대규모로, 자동 스케일링 / 로드밸런싱 / 장애조치까지 묶어서 제공하는 L3 로드 밸런서

• 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용

• IDPS(Intrusion Detection & Prevention System: 침입 탐지/차단 시스템), 심층 패킷 분석 시스템(DPI: Deep Packet Inspection / 패킷의 헤더뿐 아니라 내용(payload) 까지 들여다보는 시스템) 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다

  ❔일부 페이로드 수정?

  • 악성 코드가 포함된 일부 내용을 지우거나 바꾸거나

  • 민감한 정보(예: 카드 번호)가 평문으로 갈 때 마스킹하거나 암호화 하거나

  • HTTP 헤더를 삽입/수정해서 보안 정책을 적용하는 것

• 6081번 포트의 GENEVE 프로토콜을 사용한다

• 투명 네트워크 게이트웨이처럼 동작 => 클라이언트 & 서버 입장에선 중간에 뭐가 끼어있는지 모름

ALB & NLB vs GWLB

ALB/NLB는 “서비스(HTTP/TCP)를 여러 서버에 분산”이라면, GWLB는 “네트워크 장비 역할(방화벽 같은 것)을 여러 인스턴스에 분산”

GWLB의 흐름

큰 구조: GWLB + GWLBe + 어플라이언스

1. Gateway Load Balancer (GWLB)

   • L3 로드밸런서

   • 트래픽을 “어플라이언스”로 분산해줌

2. Gateway Load Balancer Endpoint (GWLBe)

   • 각 VPC/Subnet에서 GWLB로 향하는 “문” 역할

   • 사용자는 라우팅 테이블에서 목적지 → GWLBe 로 보내도록 설정

3. 어플라이언스(네트워크 가상 장비)

   • EC2 위에 돌아가는 방화벽/IDS/보안 솔루션

   • Target Group에 IP로 등록 (타입: ip)

   흐름

   [VPC/Subnet 라우팅] → GWLBe (Gateway Load Balancer Endpoint)

   → GWLB
      → 어플라이언스(방화벽/IDS 등) Target Group
      → 다시 GWLB/GWLBe를 통해 원래 목적지로 복귀

GWLB의 타겟

1. EC2 인스턴스

2. IP 주소 => 사설 IP

한 줄 정리

GWLB의 주요 기능은 네트워크 트래픽 분석이며 L3 (네트워크 계층)에서 이루어지며 GWLB를 두는 순간 라우트 테이블은 업데이트 되어 이후 트래픽이 GWLB를 거친다

L4(TCP/UDP) 레벨에서, 엄청 높은 성능과 아주 낮은 지연시간으로 트래픽을 분산해주는 로드 밸런서

초당 수백만 요청, 고성능, 소스 IP 보존, TCP, UDP가 키워드

ALB와 다르게 NLB는 각 AZ마다 하나의 정적 IP 주소를 갖고 있음

각 가용 영역에 탄력적 IP 할당 가능 => IP를 Elastic IP로 고정할 수도 있고, 아니면 AWS가 주는 고정 IP를 쓸 수도 있음

❓고정 IP의 장점?

1. NLB가 중단되거나 교체될 때마다 IP 주소를 변경할 필요가 ❌ IP 주소가 고정되어 있기 때문에 클라이언트는 항상 동일한 IP 주소를 통해 액세스 가능

2. DNS(Domain Name System) 구성을 간소화

3. NLB에는 SSL/TLS 인증서를 적용할 수 있음. 고정 IP를 사용하면 인증서를 한 번만 구매하고 설치한 후에도 IP 주소 변경 없이 계속 사용할 수 있음

4. 방화벽 또는 보안 그룹과 같은 보안 정책을 쉽게 적용할 수 있음. IP 주소가 변경되지 않기 때문에 정책을 설정하거나 업데이트할 때마다 변경 작업이 필요하지 않음

5. 고정 IP를 사용하면 다른 서비스와의 통합 및 구성 관리도 단순화

NLB의 동작방식

1. DNS → NLB IP 선택

2. 클라이언트 → NLB 연결 맺기

3. NLB가 타깃(EC2/IP) 선택

4. NLB ↔ 타깃(EC2) 간 트래픽 전달

• 대상그룹

1. EC2 인스턴스

2. IP 주소 → 하드코딩된 IP주소 혹은 프라이빗 IP (인스턴스와 자체 서버를 로드밸런서 타겟 그룹으로 등록한다면 )

3. ALB 앞에 배치 가능

NLB를 통해 고정 IP 주소를 얻을 수 있고 이후 ALB로 HTTP 유형의 트래픽을 처리하는 모든 규칙들 사용 가능

• NLB가 지원하는 상태 체크(Health Check)

  1. TCP => 네트워크/포트 레벨 살아있음”만 보는 가장 기초적인 체크

  2. HTTP

  3. HTTPS

백엔드 애플리케이션이 HTTP/HTTPS로 응답할 수 있다면, TCP보다 HTTP/HTTPS 헬스 체크로 더 정확한 상태 확인이 가능

ALB 실습

AZ마다 AWS에서 고정 IP 주소 할당 / EIP(Elastic IP)가 있으면 EIP 할당 가능

NLB를 위한 SG(Secuirty Group) 만들기

새로 생성한 SG 그룹 적용해주기

새로운 대상 그룹(Target Group) 만들어주기

다시 NLB 생성화면으로 돌아오기

생성 완료!

생성된 NLB의 DNS Name으로 접속해보니 타임아웃 발생

인스턴스의 SG 설정을 살펴보니 HTTP가 앞전에 설정해둔 ALB 보안그룹만 허용되어 있다

NLB 보안그룹도 추가해주자!

❓WHY ? => 네트워크 로드 밸런서에서는 밸런서의 보안 그룹을 정의하지 않는다 => 네트워크 로드 밸런서로 들어온 모든 트래픽이 곧장 EC2 인스턴스로 들어간다 => 들어온 트래픽을 허용할지 말지는 EC2 인스턴스 보안그룹이 정한다

다시 대상그룹(Target Group)을 살펴보면 Healthy라고 출력되는 것 확인 가능!

DNS Name 주소로 접근하면

잘 연결됨을 확인할 수 있다!!

URL, Host, 헤더, 메서드 같은 “HTTP 내용”을 보고 어떤 Target으로 보낼지 세밀하게 골라주는 L7 HTTP 전용 로드 밸런서

클라이언트 ←→ ALB(공개 IP/도메인) ←→ Target Group(EC2, ECS, Lambda, IP 등)

• WebSocket, HTTP/2 지원

  BUT HTTP/2 위에서 WebSocket를 돌리는게 아님

  ALB에서 HTTP/2는 클라이언트 ↔ ALB 구간에서만 지원

  [브라우저] -- HTTP/2 --> [ALB] -- HTTP/1.1 --> [EC2/ECS 등]

  ALB는 평범한 HTTP 요청에 대해선 HTTP/2를 지원하고, 별도로 WebSocket 연결도 지원

• 리다이렉트(클라이언트에게 다른 URL로 가라고 응답) 지원

  ALB Listener Rule의 Action(동작) 중 하나

동작 방식:

1. ALB가 요청을 받음

2. Rule 조건(Host, Path 등)에 매치됨

3. Target Group으로 안 보내고, 브라우저한테 3xx 응답 + Location 헤더를 돌려줌

4. 브라우저가 그 Location으로 다시 요청을 보냄

예시)

• 경로 라우팅 지원

  URL의 “경로(Path)”를 보고 어떤 Target Group으로 보낼지 결정하는 기능

  

  

  호스트 이름에 기반한 라우팅도 가능

• 쿼리 문자열 & 헤더 기반한 라우팅 지원

ALB는 마이크로서비스와 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서 ‼️

포트 매핑 기능이 있어서 EC2 인스턴스의 동적 포트로의 리다이렉션을 가능하게 함

ALB의 타겟 그룹

1. EC2 인스턴스(오토 스케일링 그룹으로 관리될 수 있음)
2. ECS 작업
3. Lambda 함수
4. IP 주소 => 사설 IP 주소여야만 함

ALB는 여러 대상 그룹으로 라우팅 할 수 있으며

Health Check(상태 확인)은 대상 그룹 레벨에서 이루어짐

ALB 실습

• ALB 생성 HTTP, HTTPS가 허용된 SG를 적용한 인스턴스 2개를 생성해준다

  

  

  얼마나 되는 가용 영역에 로드밸런서를 배포할지 정해야 함

  Security groups를 설정할 차례인데 HTTP 트래픽만 허용하는 SG 그룹 생성

  다음 버튼을 클릭하면

  

  Include as pending below 클릭

  다시 ALB 생성 화면으로 넘어오면

  

  80 포트에 있는 로드 밸런스의 리스너와 연결

  생성하고 ALB가 active된 상태가 되면 DNS name이 부여되는데

  새로고침시마다 ALB에서 리다이렉션 해주는 인스턴스가 다름을 확인할 수 있다

• EC2 인스턴스에 로드밸런서를 통해서만 액세스하게 하는 법

  

  EC2 인스턴스에 연결된 SG로 가서 Edit Inbound rules 클릭

  

  ELB의 SG 접근만 허용하도록 선택

  적용 후 EC2 Public Address로 접근하려고 하면 타임아웃 발생

  

  하지만 로드밸런서의 DNS Name 주소로 접근하면

  

  정상작동

  
  

• 애플리케이션 밸런서 규칙

  

  모든 요청이 demo-tg-alb로 보내지게 되어있음 Add Rule 버튼을 클릭해서 더 복잡하게 설정 가능

  Conditions => 무엇을 요청의 필터로 사용할 것인지 선택

  우선 난 Path로 선택하고 /error일 때 요청이 보내지도록 Rule 추가

  그 다음으로는 조건이 맞는다면 어떤 액션을 취할지 정의해야 함 난 여기서 Return fixed response => 404 => Not Found, custom error!를 지정하겠다

  규칙이 여러개일 수 있기 때문에 우선순위를 정해줘야 함! 1이 가장 높은 우선순위!!

  규칙을 적용하고 나서 다시 DNS name값을 복사하고 끝에 "/error"를 붙여주면

  

<span style="font-weight:bold">고가용성</span>

로드 밸런싱(Load Balancing)

❓ 로드 밸런서

❔ 로드 밸런서(Load Balancer)가 하는 일

“트래픽 분배기 + 보안관 + 건강검진기” 역할을 함

1. 트래픽 분배

   • 사용자의 요청(HTTP, HTTPS, TCP 등)을 받아서

   뒤에 있는 여러 EC2 인스턴스(= Target/Backend)에게 나눠줌

2. Health Check (헬스 체크)

   • 인스턴스 상태를 주기적으로 체크

   • 죽어 있으면 그 서버로는 더 이상 트래픽 안 보냄 => 한 서버가 죽어도 서비스는 계속 동작 (고가용성)

3. 스케일링과 궁합

   • Auto Scaling Group이 인스턴스를 늘리거나 줄이면,

   • 로드 밸런서가 그 인스턴스들을 자동으로 붙였다 떼었다 하면서 트래픽 분배

4. 단일 진입점 (Single Point of Access)

   • 사용자는 로드 밸런서의 DNS 이름 하나만 알고 접속 => 사용자는 본인이 어떤 인스턴스에 연결되었는지 알 수 ❌

   • 그 뒤에 서버가 몇 대든, 어떤 AZ에 있든 상관 없음 → IP 바뀌는 개별 EC2 대신, 고정된 접점이 되어 줌

5. 보안/암호화 처리 역할 → SSL 종료

   클라이언트와 HTTPS 연결을 로드 밸런서에서 종료

   = SSL/TLS Termination / Offloading

   • 인증서를 로드 밸런서에서 관리하고, 백엔드에는 HTTP로 넘기거나 다시 HTTPS로 재암호화해서 넘김

   • 효과:

   개별 서버에서 TLS 설정/인증서 관리 안 해도 됨

   암복호화 부담을 LB가 떠안아서 백엔드 부담↓

   필요하다면 end-to-end 암호화도 구성 가능 (LB ↔ 백엔드도 HTTPS)

   
   

❔ 로드 밸런서가 필요한 이유

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해

• 하나의 액세스 포인트를 노출하기 위해

• 다운스트림 인스턴스의 오류를 핸들링하기 위해 & 헬스체크

• SSL 종료를 제공

• 쿠키로 고정도 강화

  고정도(affinity / stickiness) => 같은 클라이언트(브라우저)에서 오는 요청을 계속 같은 백엔드 인스턴스로 보내 주는 정도

고정도를 만드는 방법은 여러 가지인데, 대표적으로:

1. IP 기반: 같은 클라이언트 IP면 같은 서버로 보내기

2. 쿠키 기반: 브라우저에 심어둔 쿠키 값으로 같은 서버로 보내기
=> “쿠키로 고정도를 강화할 수 있다”는 말은

→ IP만 믿지 말고, 쿠키를 사용해서 더 안정적으로 “같은 서버로 묶어라” 라는 의미

Why❓

➡️ IP는 바뀔 수 있음
모바일, 4G/5G, 회사 프록시, NAT 뒤에 있을 때

여러 사용자가 같은 공인 IP를 공유하기도 함

반면 쿠키는 브라우저 단위로 저장됨

그 브라우저에서 오는 요청엔 항상 같은 쿠키가 딸려옴 → 훨씬 “누가 누군지”를 안정적으로 구분 가능

“고정도(affinity)를 강화한다 = 한 사용자를 더 정확하게 같은 서버에 붙여준다”

---

Example)

예를 들어 ALB + EC2 구조에서:

사용자가 브라우저로 https://example.com 접속

로드 밸런서(ALB) 가 첫 요청을 서버 A로 보냄

이때 ALB가 특정 쿠키(예: AWSALB, AWSALBTG 같은 LB 쿠키) 를 응답에 실어 브라우저에 내려줄 수 있어

이후 요청에서 브라우저는 항상 그 쿠키를 붙여서 요청함

ALB는 쿠키를 보고 “아, 이 쿠키는 서버 A로 붙어 있던 애네?” 하고

→ 계속 서버 A로 라우팅

• 영역에 걸친 고가용성을 가짐
• 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리 가능

ELB를 사용하는 이유?

1. 운영 부담 줄어드는 AWS 관리형 서비스

   직접 로드 밸런서(Nginx, HAProxy, keepalived 등)를 구축하면:

   설치, 설정, 패치, 모니터링, 장애 대응, 스케일링까지 전부 내가 해야 함

   ELB는 fully managed:

   OS, 소프트웨어 패치, 스케일링, 고가용성 설계 등을 AWS가 맡음 → 운영(운영 인력·시간) 비용이 줄어든다 → 시험 키워드: “undifferentiated heavy lifting을 AWS가 대신해준다”

2. ELB가 다른 AWS 서비스들이랑 붙어서 ‘세트로’ 동작하도록 설계돼 있다
   • EC2, EC2 Auto Scaling Groups, Amazon ECS
   • AWS Certificate Mananger(ACM), CloudWatch
   • Route 53, AWS WAF, AWS Global Accelerator

ELB의 Health Check

실제 애플리케이션 레벨로 두드려 보는 것

1. 포트

   타겟 인스턴스(EC2 등)에서 어느 포트로 요청을 보낼 건지

   • EC2가 80포트에서 웹 서버 실행 중이면

   => Health Check Port = 80

• 앱 서버가 8080포트에서만 떠 있으면

  => Health Check Port = 8080

* traffic port 로 하면

=> Target Group에 설정된 포트(예: 80, 443 등)를 그대로 따라감

그래서 “포트로 Health Check를 한다” =

“ELB가 각 타겟의 지정된 포트에 직접 접속해서 확인한다”는 뜻

2. 라우트

   특정 URL 경로(라우트)”로 GET을 날려 보고 응답 코드로 판별

   예시:

   • Health check path: /

• Health check path: /health

  • Health check path: /status

  • Health check path: /actuator/health (Spring Boot 같은 거)

http://타겟IP:포트/health

  http://10.0.1.23:8080/health

응답값이 200~399 → Healthy / 500, 타임아웃 등 → Unhealthy

AWS의 관리형 로드 밸런서 종류

1. CLB(2009) - v1
   • HTTP, HTTPS, TCP, SSL, secure TCP 지원

2. ALB(2016) -v2

   • HTTP, HTTPS, WebSocket 프로토콜 지원

3. NLB(2017) - v2

   • TCP, TLS(secure TCP), UDP 프로토콜 지원

4. GWLB(Gateway Load Banlancer: 2020)

   • 3계층(네트워크 레이어에서 동작) - IP 프로토콜에서 작동

Load Balancer Security Groups

EC2의 Security Groups Rule은 포트 80 HTTP 트래픽 & 소스는 IP 범위가 아닌 LB의 SG가 된다.

→ EC2 인스턴스는 Load Balancer에서 온 트래픽만을 허용하게 되는 강화된 보안 메커니즘이 되는 것

• 한번에 하나의 인스턴스만 연결할 수 있다(multi-attach(다중 연결)가 되는 io1/io2 제외)

• AZ(Availability Zone)에 고정됨

• EBS의 gp2 볼륨은 디스크 크기가 증가해야 IO가 증가 BUT gp3, io1 볼륨 유형은 디스크 크기와 무관하게 IO 증가 가능

• EBS에서 AZ간에 볼륨을 옮기려면 스냅샷을 이용해야 함 => 스냅샷을 생성 후 다른 AZ에 복원하기

• EBS 볼륨 백업이 IO를 사용하므로 애플리케이션이 많은 트래픽을 처리하고 있을 경우에는 실행하면 안 됨 => 성능에 영향을 줄 수 있기 때문

• EC2 인스턴스가 종료되면 기본적으로 인스턴스의 EBS 루트 볼륨도 종료됨 => 이는 설정에서 비활성화 가능

EFS

• 서로 다른 가용 영역의 수백 개의 인스턴스에 연결 가능 => 하나의 EFS 파일 시스템으로 다른 여러 mount(탑재) 대상을 가질 수 있다 => 여러 인스턴스가 하나의 파일 시스템을 공유할 수 있다

• WordPress 사용시 매우 유용하고 리눅스 인스턴스에서만 사용 가능

  • 가격 EFS가 EBS보다 비싼 편이지만 비용 절감을 위해 EFS-IA 활용 가능

인스턴스 스토어

물리적으로 EC2 인스턴스에 연결 => 인스턴스가 없어지면 스토리지 또한 잃음

EBS vs EFS vs EC2 인스턴스 스토어 표로 정리

오답노트

Q. 여러분은 기본 저장소에 대해 310,000의 IOPS를 요구하는 고성능 데이터베이스가 있습니다. 다음 중 무엇을 추천해야 할까요?

2. EBS gp2 드라이브 사용

3. EBS io1 드라이브 사용

4. EBS io2 Block Express 드라이브 사용

내가 고른 답: 4 정답: 1

1번을 고르지 않은 이유: DB처럼 중요한 데이터를 인스턴스를 종료하면 날아가는 인스턴스 스토어에 사용한다고? 라고 생각함

DB 같은 “중요 데이터” → EBS(io1/io2)
Instance Store → 캐시/임시 데이터
“아니 DB를 인스턴스 스토어에 올리라고??” 라는 의문

근데 이 문제는 “내구성”보다 “IOPS”라는 성능 조건에만 꽂혀 있는 문제

같은 리전 내 여러 AZ에 배치된 EC2/ECS/EKS/Lambda가 NFS(2049)로 동시에 마운트하는 공유 파일시스템 / 다른 리전에서 직접 마운트는 불가

EC2는 서로 다른 AZ에 흩어져 있어도 된다

EFS는 “같은 리전” 안이라면 그 여러 AZ의 EC2들이 하나의 EFS를 함께(동시에) 마운트해 쓸 수 있다

=> 즉, 리전(Region) = 서울/도쿄 같은 “큰 구역”, AZ = 그 안의 서로 떨어진 데이터센터 묶음 EFS는 “서울 리전”에 만들면 서울 리전의 AZ들(예: ap-northeast-2a, 2b, 2c) 어디에 있는 EC2든 같은 EFS 폴더를 공유할 수 있음

• 특징
  • 가용성이 높다
  • 확장성이 뛰어나다(자동으로 확장됨)
  • 비싸다(EBS의 gp2 볼륨의 약 3배)
  • 사용량에 따라 비용을 지불(프로비저닝 할 필요가 없음)

다른 AZ에 위치한 인스턴스들을 EFS를 통해 동일한 네트워크 파일 시스템에 동시에 연결 가능

Use Case

• 콘텐츠 관리
• 웹 서빙
• 데이터 공유
• Wordpress

EFS에 대한 액세스를 제어하려면 보안 그룹을 설정해야 함

💡 EFS는 윈도우가 아닌 Linux 기반 AMI와만 호환된다 ‼️

보안

• EFS는 저장되는 파일·메타데이터를 ‘미사용 상태(at rest)’에서 KMS 키로 자동 암호화할 수 있다 => 즉, 디스크에 얹힐 때는 암호문, EC2/ECS/EKS/Lambda가 읽을 땐 평문으로 보인다(자동 복호화)

EFS 퍼포먼스

EFS는 수천 개의 NFS 클라이언트가 동시에 붙을 수 있고, 처리량도 10 GiB/s를 넘길 수 있으며, 저장 용량은 자동으로 페타바이트(PB) 규모까지 확장

EFS 성능은 크게 두 축으로 스케일 됨

1. Performance mode (파일시스템 생성 시 결정)

   • General Purpose: 대부분 워크로드, 낮은 지연(ex: 웹 서버, CMS)
   • Max I/O: 아주 많은 파일/클라이언트가 동시에 접근하는 대규모 분산 워크로드에서 총 처리량 극대화(지연 다소↑ 가능) (ex: 빅데이터, 미디어 처리)
   • 암기: “동시성·파일 수가 엄청 많다” → Max I/O.

2. Throughput mode (운영 중 변경 가능)

   • Bursting(기본(1TB)): 저장 용량에 비례해 기본 처리량 + 버스트 크레딧 제공.

     • 데이터가 작은데 지속 고처리량이 필요하면 크레딧이 바닥날 수 있음

   • Provisioned Throughput: 저장 용량과 무관하게 처리량을 고정 예약

     • “작은 용량 + 지속 고성능”에 적합.

   • Elastic Throughput: 워크로드 변동을 자동 추적해 처리량을 탄력 적용(운영 단순화, 사용량 기반 과금) => 워크로드를 예측하기 어려울 때 유용

• 결정법

  1) 평균적/보통 패턴 → Bursting(저렴·간편)

  2) 작은 데이터 + 상시 고부하 → Provisioned

  3) 예측 불가한 변동 → Elastic

3. IOPS는 처리량에 종속

   EFS는 블록 스토리지(EBS)처럼 “고정 IOPS”를 잡는 모델이 아님

   작은 IO가 많으면 IOPS 수요가 커지고, 큰 IO는 처리량(Throughput) 한도에 더 민감

   필요 시 Provisioned/Elastic로 처리량을 확보하고, 클라이언트 측 NFS 파라미터(rsize/wsize), 병렬성, 워커 수로 실효 IOPS를 끌어올림

EFS 스토리지 클래스

? Storage tiers

=> 파일 접근 빈도에 따라 다른 등급(클래스)로 자동 이동시키는 기능을 말하고, 며칠(정책) 후 IA/Archive로 내리거나, 접근 시 다시 Standard로 올리는 것까지 설정

1. 가용성(위치) 축 — “어디에 저장하느냐”

   • Standard (Regional):

   • 자주 액세스하는 파일을 위한 계층

   • 다중 AZ 설정이 있는 경우 내구성·가용성 측면에서 볼 때 사용하는 것이 좋음

   • One Zone:

   • 단일 AZ에 저장 → 더 저렴/낮은 지연 가능하지만 AZ 장애 리스크↑ (백업 필수 권장: 백업은 기본적으로 활성화하도록 설정되어 있음)

   • 액세스 빈도가 낮은 스토리지 계층과 호환됨

2. 접근 빈도(Access) 축 — “얼마나 자주 읽히느냐”

   • Frequent Access: 자주 접근하는 데이터에 맞춘 등급(기본)

   • IA (Infrequent Access): 드물게 접근하는 파일용 요청/조회 비용(파일 검색) 비용이 발생하지만 저장하면 비용이 감소함 최소 보관 기간 요금(예: ~30일)이 적용될 수 있음

• Archive: 거의 액세스하지 않는 데이터용(1년에 몇 번 정도) 50% 정도 저렴

전반적으로 올바른 EFS 스토리지 클래스를 사용하면 최대 90%의 비용 절감 가능

EFS 실습

VPC는 default로 진행하되 Customize로 옵션을 살펴보겠다

Regional을 선택하면 다중 AZ가 지원된다

하지만 One Zone을 선택하면 AZ를 하나 특정해야 함

백업은 활성화된 채로 유지하는 것이 좋음

IA나 아카이브로 전환했다가 다시 스탠다드로 전환 가능

ex) 30일동안 파일에 액세스 하지 않으면 IA로 이동 / 90일동안 액세스하지 않으면 아카이브로 이동

Enhanced => elastic과 Provisioned을 그룹화하는 카테고리에 불과함

• Elastic: 트래픽에 맞춰 자동으로 처리량을 확장/과금(스파이크/예측 어려운 워크로드에 적합)

• Provisioned: 용량과 무관하게 처리량을 고정 예약(지속 고처리량, 예측 가능한 워크로드)

• Bursting: 파일시스템 크기와 버스트 크레딧에 비례해 처리량 제공(기본값, 단 단발성 피크 중심)

us-ease-? 존에 대한 EFS 네트워크 설정

EFS를 위한 SG(Security Group) 만들어주기

그 다음 단계들은 선택 사항이라서 건너뛰고 Create File system 클릭

잘 생성된 것 확인 가능

EC2 인스턴스에 EFS를 연결해볼건데 Instance 생성시

우측 하단 부 "Edit" 버튼 클릭

네트워크 설정에서 Subnet을 설정해줘야 EFS 연동 가능

Instance A로 이름을 지어서 us-east-1a를 선택했다

Add shared file system 클릭

Automatically mount shared file system by attaching required user data script

=> EC2를 띄울 때 “유저 데이터(User data) 스크립트”를 자동으로 붙여서 EFS를 부팅 시점에 알아서 마운트해 주는 옵션

유저 데이터 스크립트가 EC2 첫 부팅 때 자동 실행되어 아래 작업 실시

1. 필요 패키지 설치

   amazon-efs-utils(또는 NFS 클라이언트) 설치

2. 마운트 지점 준비

   예: mkdir -p /mnt/efs

3. 마운트 수행(보통 TLS 포함)

   예: mount -t efs -o tls fs-XXXX:/ /mnt/efs

   Access Point를 쓰면 fs-XXXX:AP-YYYY:/ 형태로 마운트

   /etc/fstab 등록(부팅 시 자동 마운트)

4. 재부팅해도 자동으로 붙도록 엔트리를 추가

   예: fs-XXXX:/ /mnt/efs efs _netdev,tls 0 0

즉, 인스턴스를 만들자마자 사람이 SSH로 들어가서 설치/마운트 설정을 하지 않아도 되도록 자동화해 주는 “부팅 초기화 스크립트”

EFS를 붙여서 확실히 인스턴스 생성하는데 시간이 걸린다

같은 방식으로 Instance B를 만들어 같은 EFS를 연결

EFS의 네트워크 탭으로 가면

각 가용 영역에 여러 보안 그룹이 존재하는 것 확인 가능 => 우리가 연결한 efs-demo 말고도 EC2 콘솔이 대신 생성해 EFS 파일 시스템에 연결

EFS에서 “보안(시큐리티) 자동 설정” 체크 + 여러 AZ 선택 ⇒ 선택한 각 AZ의 서브넷마다 “마운트 타깃(ENI)”을 만들고, 그 ENI에 지정한 SG가 붙음

EC2 인스턴스를 us-east-1a/1b에만 띄웠더라도, EFS를 us-east-1의 다른 AZ(1c/1d …)까지 선택했다면 그 AZ들에도 마운트 타깃이 생성되고 동일/지정 SG들이 붙어 보이는 게 정상

efs-sg-2 SG 그룹 상세 > Inbout rules를 확인하면 NFS 프로토콜 유형과 2049 포트 허용하는 것 확인 가능

Instance A Connect & Instance B Connect

Instance A로 Connect된 터미널 창에 다음과 같은 명령어 입력

EC2 인스턴스로부터 EFS 파일 시스템에 파일 생성 & 가용 영역 us-east-1a

Instance B로 이동해서 아래와 같은 명령어를 입력하면 Instance A에서 생성한 파일을 찾을 수 있다

두 EC2 인스턴스 모두 EFS 파일 시스템이 네트워크 드라이브로 마운트 된 것

1. gp3 (General Purpose SSD)

• 용도: 웹/앱 서버, 중소형 DB 등 대부분의 일반 워크로드

• 특징:

  • 비용 효율 최고, 새 프로젝트의 사실상 기본값 / 부팅 가능(SSD)
  • IOPS와 처리량을 독립적으로 설정 가능
  • 주의: 인스턴스의 EBS 대역폭 한도도 병목이 될 수 있음(인스턴스 스펙 고려)

2. gp2 (General Purpose SSD, 레거시)

• 용도: 기존 레거시 워크로드 호환 / 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에 사용

• 특징:

  • gp2는 레거시 취급이라 새로 선택하진 않음(점진적 gp3 전환 권장) / SSD 타입은 EC2의 루트 볼륨로 쓸 수 있음

  • 비용 효율적인 스토리지이면서 낮은 대기시간을 제공

  • IOPS와 처리량이 서로 연결되어 있다

3. io1 (Provisioned IOPS SSD)

• 용도: 지연 민감·트랜잭션성 DB(OLTP), I/O 집약 워크로드

• 특징: Multi-Attach 지원(io1/io2 전용) → 같은 AZ의 여러 인스턴스에 동시 연결(특수 파일시스템/클러스터링 전제) / 일부 리전 제약 있음

• 주의: 비용 높음. 부팅 가능(SSD)

4. io2 (Provisioned IOPS SSD)

• 용도: 미션 크리티컬 DB, 높은 내구성과 일관 I/O 필요

• 파생: io2 Block Express(초대형/초고성능 볼륨) 옵션

• 특징: 비용 높음, 부팅 가능(SSD)

5. st1 (Throughput Optimized HDD)

• 용도: 대용량 순차 I/O(로그 처리, 빅데이터, ETL 등) => 큰 파일을 길게/연속으로 읽고 쓰는 작업

• 특징: 부팅 불가(HDD), 랜덤 I/O/저지연에는 부적합 / 저비용 대용량 볼륨

6. sc1 (Cold HDD)

• 용도: 아주 드물게 접근하는 대용량 데이터(콜드/아카이브 성향)

• 특징: 부팅 불가(HDD), 최저 비용/최저 성능

HDD vs SDD

EBS 볼륨 타입

EBS 볼륨중에 루트 볼륨(os가 부팅되는 곳)이 되는게 SSD 계열

EBS 다중 연결

EBS 볼륨 중 io1 및 io2 제품군에서만 사용할 수 있음

각 인스턴스는 고성능 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖게 됨 ex) 인스턴스 A, B, C 모두가 동시에 그 하나의 블록 디바이스에 읽기/쓰기를 할 수 있음

⚠️ 중요한 주의점

일관성/락은 AWS가 보장하지 않음 → 클러스터 파일시스템(GFS2, OCFS2) 또는 애플리케이션 락을 반드시 사용해야 함

Use case

1. 클러스터화된 linux 애플리케이션
2. 애플리케이션에서 동시 쓰기 작업을 관리하는 경우

다중 연결의 제한

1. 지정된 가용 영역 내에서만 사용 가능
2. 하나의 볼륨은 한 번에 최대 16개의 EC2 인스턴스에 부착할 수 있다

다중 연결이 동작하려면 클러스터를 인식할 수 있는 파일 시스템을 사용해야 함 => 일반 ext4/xfs 같은 단일 호스트용 FS를 그대로 공유하면 100% 데이터 손상

why❓ 여러 대가 동시에 같은 디스크에 쓰면 서로 누가 먼저/어디에 썼는지 조율이 안 돼서 메타데이터가 꼬이고(저널 충돌),각자 메모리에 들고 있던 캐시 내용이 서로 모순이 되고, 결국 파일시스템이 손상

여러 노드가 동시에 접근하려면, OS/파일시스템 레벨에서 분산 잠금(DLM), 저널 공유/조율, 캐시 무효화 규칙, 펜싱(fencing) 등을 갖춘 “클러스터 인식 파일시스템”이 꼭 필요함 대표 예: GFS2, OCFS2 (여러 노드가 같은 블록 장치를 안전하게 공유하도록 설계됨)

❓왜 “네트워크 드라이브 + 제한된 성능”이라고 할까?

• 네트워크 경유: EBS는 인스턴스 바깥의 스토리지 장비에 저장되고, 전용 네트워크로 블록 I/O를 주고받아요. 로컬 장치가 아니라서 추가 지연(latency)이 발생

• 볼륨 자체 한도: 각 볼륨 타입(gp3, io2, st1 등)은 IOPS/Throughput 상한이 있음 (원하는 만큼 무한히 늘지 않음)

• 인스턴스 한도: 인스턴스 타입별로 EBS 대역폭(GB/s)과 총 IOPS에 상한이 있어음 => 볼륨이 빨라도, 인스턴스가 허용하는 총량을 넘을 수 없음

• 버스트/크레딧 모델: 일부 타입은 버스트 크레딧이 있어 짧게는 빠르지만 지속 부하는 떨어질 수 있음

• 멀티테넌시: 동일 AZ 내 여러 사용자가 공유하는 인프라 위에서 돌아가므로, 일부 상황에서 변동성이 있을 수 있음(요즘은 꽤 안정적이지만 개념적으로 존재)

💡 하드웨어적인 고성능이 필요하면 EC2 인스턴스 스토어를 사용❗️

EC2 vs EC2 Instance vs EC2 Instance Store vs EBS

• EC2: 컴퓨트 서비스 이름(플랫폼)

• EC2 인스턴스: 그 서비스 위에서 실행되는 가상 머신(네가 띄우는 서버)

• EC2 Instance Store: 인스턴스가 올라가는 물리 호스트에 붙은 로컬 NVMe 디스크(옵션) / 인스턴스 타입에 따라 있을 수도, 없을 수도 있음 보통 …d, i3/i4 같은 일부 인스턴스 타입이 그 로컬 디스크를 탑재

• EBS: 네트워크로 붙는 영속 블록 스토리지(같은 AZ에 있어야 attach 가능)

EC2 Instance Store를 쓰는 이유?

• 더 나은 I/O(저장장치에 읽고/쓰는 속도와 반응성) performance를 위해

  I/O Performance

  1. 지연시간(Latency)

“한 번 읽기/쓰기 요청을 처리하는 데 걸리는 시간”(ms, µs)
낮을수록 즉각 반응. 데이터베이스 트랜잭션처럼 작고 랜덤한 작업에 중요.

2. IOPS (Input/Output Operations Per Second)

   "1초에 읽기 /쓰기를 몇 번 처리하나" (보통 작은 블록, 랜덤 I/O 가정)

   수치가 높을수록 작은 요청을 많이 동시에 처리 가능. 키–값 저장소, OLTP DB 등에 핵심.

3. 처리량/스루풋(Throughput)

   “초당 몇 MB/GB를 연속으로 옮기나” (MB/s, GB/s).

   큰 파일을 순차적으로 이동/처리하는 작업(ETL, 로그 압축, 영상 처리)에 중요.

• 왜 EC2 Instance Store가 I/O에 유리하냐?

로컬 NVMe라서 네트워크를 안 타고 바로 호스트 디스크에 접근 → 지연시간이 매우 낮고, IOPS/처리량이 크게 나옴

단, 휘발성이라 중지/종료/호스트 이슈 시 데이터가 사라짐 → 캐시/임시/버퍼/스크래치 용도에 적합 => 필요에 따라 백업이나 복제를 해두는 것이 좋다

Instance Store vs EBS

=> 커스터마이징된 인스턴스로부터 만들어진 이미지(템플릿) => OS/소프트웨어/설정을 캡처한 부팅 이미지 => 부팅에 필요한 디스크 스냅샷(루트 볼륨), 블록 디바이스 매핑, 권한 정보를 정적인 묶음으로 가진 설계도

AWS에서 생성한 AMI를 사용하거나 사용자 지정 AMI를 만들 수 있다

자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축됨

-> EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징 되기 때문

AMI ID는 해당 리전에서만 유효. 다른 리전에서 쓰려면 AMI 복사 필요(새 ID 생성)

AMI 유형

• Amazon 제공

• 내 프라이빗

  • AMI를 만든 소유 계정만 볼 수 있고, 그 계정만 인스턴스를 띄울 수 있음
  • 복사: 같은 계정 내 리전 간 복사 가능(복사하면 새 AMI ID)
  • 요금: 스냅샷/스토리지는 소유 계정이 부담

• 공유(계정 대상)

  • 특정 다른 AWS 계정 ID에 ‘런치 권한’을 부여해 그 계정이 이 AMI로 인스턴스를 띄울 수 있게 한 상태

  • 주의(암호화 시 3종 세트)

    • AMI 런치 권한 공유
      • (암호화된) 스냅샷 공유
      • KMS 키 사용 권한 부여 이 셋이 모두 되어야 상대 계정에서 실제로 사용/복사 가능

* 복사/소유권: 공유받은 계정이 **자기 계정으로 AMI를 ‘복사’**하면, 그 복사본은 공유받은 계정 소유가 됨(권장 패턴)
* 요금: 원본 보관 비용은 원본 소유 계정이 부담(공유만 했을 뿐). 상대가 복사하면 복사본 비용은 상대 계정 부담
* 용도: 멀티계정(Prod/Dev/보안계정) 간 표준 이미지 배포, 파트너/자회사 제공

• 퍼블릭

  • 누구나 검색/사용 가능(전체 공개)
  • 조건: AMI와 해당 스냅샷도 퍼블릭이어야 함
  • 제한: 암호화된 AMI는 퍼블릭 불가, Marketplace AMI도 퍼블릭 전환 불가
  • 용도: 커뮤니티 배포(예: 교육용 베이스 이미지), 오픈 샘플

• Marketplace

  • 다른 사람이 생성한 AMI(잠재적으로 팔 수 있는?)

표로 한눈에 정리

AMI Process

1. EC2를 시작하고 사용자 지정으로 바꾼다(customize)
2. 인스턴스를 중지시켜 데이터 무결성을 확보(선택 사항) 콘솔에서 No reboot 체크를 해제(재부팅 허용)하면 파일시스템 일관성이 더 좋음 윈도우는 Sysprep, 리눅스는 서비스 중지/fsfreeze/sync 같은 방법도 좋음
3. AMI 구축 => AMI 생성 시 블록 디바이스 매핑에 포함된 모든 EBS 볼륨의 스냅샷이 같이 만들어짐
4. 생성된 해당 AMI를 사용해 인스턴스를 실행

AMI 생성해보기(내 프라이빗 ver.)

먼저 인스턴스를 새로 생성하고

생성된 인스턴스 => 우클릭 => Image and Templates => Create Image 클릭🖱️❇️

생성된 AMI로 인스턴스 생성 가능

My AMIs에 보면 직전에 내가 생성했던 AMI가 목록에 나타나는 것을 확인할 수 있다

User Data에 생성한 AMI에 이미 설치 명령어가 다 입력되어 있어서

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

새로 생성한 인스턴스에는 아래 항목만 입력해주고 AMI를 연결했다

# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
#!/bin/bash
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

Public IP 주소로 접근하면 페이지가 정상 출력되는 것을 확인할 수 있다!

=> 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브(실제 물리적인 연결이 있는 것은 아님)

EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터 지속 가능 => 인스턴스를 재성성하고 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있음

AZ 단위 리소스라서, EC2와 같은 AZ에 있어야 붙일 수 있음 ex) EBS 볼륨이 us-east-1a에서 생성 => us-east-1b 인스턴스에 붙일 수 ❌

하지만 스냅샷을 이용하면 다른 가용영역(AZ)로도 옮길 수 있음

CCP 레벨: 하나의 EBS는 하나의 인스턴스에만 마운트 가능 BUT 하나의 인스턴스는 여러개의 EBS를 가질 수 있다‼️

Associate 레벨: 일부 EBS 타입에 한해 여러 EC2 동시 부착 가능

EBS 볼륨이 인스턴스와 통신하기 위해서는 네트워크가 필요 => 컴포터가 다른 서버에 도달할 때 지연이 발생할 수 있음

EBS 볼륨은 네트워크 드라이브기 때문에 인스턴스에 빠르게 붙기도 떨어지기도 함

용량을 미리 결정해야 함(size: GB, IOPS(단위 초당 전송 수)) why?

1. 블록 주소 공간 고정 필요

   • OS는 디스크를 “0번 블록~N번 블록”처럼 연속된 주소 범위로 인식 => 이 범위를 초기에 선언해야 파티션/파일시스템을 안정적으로 만들 수 있음 (중간에 맘대로 줄였다 늘리면 데이터 맵이 깨짐)

2. 예측 가능한 성능·격리

   • EBS는 멀티 테넌트 스토리지 위에 프로비저닝(예약)된 논리 디스크를 만들어 주는 구조
   • 크기와 타입에 따른 성능/내구성 보장(특히 io1/io2의 IOPS 보장)을 위해 자원을 미리 예약해야 함
   • gp3는 IOPS/처리량을 용량과 분리해 설정할 수 있지만, 기본이 되는 블록 공간(GB)은 여전히 정의해야 해야 함

3. 과금 모델과 리소스 관리

   • EBS는 GB-월 단위로 과금(스냅샷/프로비저닝 IOPS/Throughput은 별도) => 미리 크기를 정하면 AWS 입장에서도 용량 계획·파편화 관리가 가능하고, 사용자 입장에서도 비용 예측이 쉽다

4. 스냅샷/복구·마이그레이션의 일관성

   • 스냅샷은 증분 백업이지만, 복구 시엔 동일한 블록 주소 범위로 복원
   • 주소 공간이 고정되어 있어야 스냅샷 → 볼륨 재생성/리전 복사/FSR 같은 기능이 안전하게 동작

ec2 인스턴스를 통해 ebs 볼륨을 생성하는 경우 "종료 시 삭제" 속성이 존재

기본적으로 root EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정

EBS 볼륨 만들어보기

EC2 Instance에서 인스턴스 클릭 후 Storage 탭을 클릭하면 Block devices에서 지금 사용중인 EBS가 보인다

대부분의 경우 (= EBS-backed AMI사용) EC2를 생성하면 루트 EBS 볼륨이 자동으로 함께 생성·붙음

Create volume 버튼 클릭

EC2> Instances에 Networking 탭에서 Availability zone 확인 가능

인스턴스를 선택하고 볼륨을 연결한다

다시 Instances의 내 인스턴스에서 Storage 탭을 클릭해서 스크롤한 다음 Block devices를 확인하면 방금 연결한 볼륨이 목록에 뜨는 것을 확인할 수 있다

인스턴스를 종료하면 EBS 볼륨은 어떻게 될까?

최상단의 EBS 볼륨을 보면 Delete on termiation에 Yes 표시가 되어있는데

이는 Instance를 생성할 때 우리가 Delete on termination에 Yes로 체크했기 때문이다

실제로 내가 Instance를 종료하고 다시 EBS 볼륨 목록을 조회하면

첫번째 EBS 볼륨이 사라진 것을 확인할 수 있다

EBS 스냅샷

EBS 볼륨의 특정 시점에서의 백업 /EBS의 데이터 저장 상태에 대해 사진(백업본)을 찍어둔 개념

EBS 스냅샷을 다른 가용 영역 또는 다른 리전에 복사 가능

EBS 볼륨을 한 인스턴스에서 다른 인스턴스로 전송하는 방법이라고도 할 수 있다

특징

1. 증분 백업: 첫 스냅샷은 사용 중 블록 전체, 이후엔 변경 블록만 저장 → 비용/시간 절감

   

   맨 왼쪽부터 스냅샷이 생성된 순서에 따라 "Snapshots A-> B-> C"로 표현하고 있으며, 볼륨에 대한 데이터가 변경될 때마다 스냅샷을 생성하는 순서를 "State"로 표현하고 있다.

   State 1 부터 살펴보면, 15GiB 용량을 가진 EBS 볼륨에서 10GiB의 데이터를 가지고 있고, 해당 볼륨에 대한 첫번째 스냅샷을 생성한다면 스냅샷 A가 가진 용량은 10GiB가 됨

   State 2 에서는 기존 EBS 볼륨의 10GiB 데이터에서 4GiB의 데이터가 변경(changed)되었는데, 해당 시점에서 두번째 스냅샷을 생성한다면 스냅샷 B는 변경된 4GiB의 데이터를 가지며, 변경되지 않은 6GiB에 대해서는 스냅샷 A의 부분을 참조(referenced)

   (❕이 시점에서 10GiB 데이터를 가진 볼륨에 대한 스냅샷이 2개 생성되었지만 실제로 스냅샷이 가진 데이터의 크기는 A -> 10GiB + B -> 4 GiB으로 14GiB가 됨)

   State 3 에서는 기존 10GiB 데이터를 가지고 있는 볼륨에 2GiB 크기의 새로운 데이터가 추가(added)되었으며, 해당 시점에서 세번째 스냅샷을 생성한다면 스냅샷 C는 새로 추가된 2GiB의 데이터를 가지며, 스냅샷 A의 6GiB, 스냅샷 B의 4GiB의 데이터를 참조(referenced)

   정리하자면,

   Snapshot A : 10GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 10GiB) Snapshot B : 4GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 기존의 6GiB + 변경된 4GiB) Snapshot C : 2GiB 데이터를 가짐 (EBS 볼륨이 가지고 있는 데이터 용량 : 기존의 10GIB + 추가된 2GIB 으로 12GiB) Snapshot A + B + C 저장에 필요한 S3의 용량은 10 + 4 + 2 로 16GiB이 된다. 따라서 사용자는 16GiB에 대한 스냅샷 비용을 지불하면 됨

   (❕ 스냅샷은 EBS의 데이터를 S3에 백업하는 방식으로 생성)

2. 복원 성능: 스냅샷에서 만든 볼륨은 지연 로딩(lazy loading) → 초기 읽기 지연

   • 해결: Fast Snapshot Restore(FSR) 활성화(특정 AZ 예열) 또는 수동 프리리드
     • FSR(Fast Snapshot Restore)? => 스냅샷을 처음 사용할 때 대기 시간이 없도록 스냅샷을 완전히 초기화하는 것 => 스냅샷이 매우 클 때 EBS 볼륨을 초기화하거나 빠르게 인스턴스화해야하는 경우에 유리 => 하지만 비용이 많이 든다

3. 비용/보존: GB-월로 과금(증분 기준) + API 호출

   • Snapshot Archive: 장기보관용 저렴, 대신 복원에 몇 시간

     • 스냅샷을 최대 75%% 더 저렴한 아카이브 티어로 옮길 수 있는 기능
     • 스냅샷을 아카이브 티어로 옮기면 아카이브를 복원하는 데 24시간에서 72시간 정도 걸림

   • Recycle Bin: 삭제 보호(보존 규칙)

     • EBS 스냅샷을 영구적으로 삭제하는 대신 휴지통에 보관 => 실수로 삭제한 경우 복구가 가능
     • 보관 기간은 하루에서 1년까지 설정 가능!

EBS 스냅샷 만들기

생성된 스냅샷의 복제본을 다른 리전에 만들 수 있다

또 다르게 스냅샷을 만든 다음 그것으로 볼륨을 생성할 수도 있다

AZ를 일부러 다른 곳을 선택해보겠다

생성 후 Volumes 탭에 들어가면 2개의 볼륨이 있는 것을 확인할 수 있는데 하나는 Snapshot ID가 명시되어 있어 스냅샷으로 만든 것을 확인할 수 있다

Snapshot 메뉴 우측 상단에 Recycle bin이라는 버튼이 있다

Rule 이름, 복구하려는 리소스 타입, 보존 기간 등을 설정할 수 있다

다시 스냅샷 영역으로 가서 삭제를 진행해준다

하지만 Recycle Bin의 Resources에 들어가보면 방금 내가 삭제했던 EBS snapshot이 목록에 나타나는 것을 확인할 수 있다

여기서 Recover 가능‼️

자격 증명을 위해 aws configure 명령을 통해서 IAM의 Access Key, Secret Access Key 등을 입력하는 건 권장하지 않음

1. 장기 키(Static Key) 노출 위험

키가 로컬 디스크 ~/.aws/credentials에 저장되어서 노트북 분실·멀웨어·로그/스크립트 유출·깃에 실수로 커밋 등으로 유출되면 장기간 악용될 수 있음 EC2 내부에 aws configure로 키를 저장해두면: 그 인스턴스에 SSH/RDP/SSM/Instance Connect로 OS 접근 가능한 사람은 cat ~/.aws/credentials로 바로 읽을 수 있음

2. 로테이션/폐기 번거로움

사람이 쓰는 장기 키는 주기적 교체가 귀찮고, 여러 장비에 퍼지면 정리/폐기 난이도↑ (Credential sprawl)

3. MFA/세션 보안이 약함

장기 키는 기본적으로 MFA가 강제되지 않음. 탈취되면 바로 API 호출 가능 반면 임시 자격증명(STS) 는 만료시간이 있어 피해를 줄임

이를 대신해 IAM Role(역할)을 사용할 수 있다

지금은 실행중인 인스턴스에 IAM Role이 비어있다

Actions > Security > Modify IAM role로 진입

aws iam list-users 명령어가 정상 실행되는 이유는 DemoRoleForEC2라는 Role에 IAMReadOnlyAccess 권한이 있기 때문이다

EC2 인스턴스 구매 옵션

1) 온디맨드(On-Demand)

• 과금: 초/시간 단위로 사용한 만큼만!

• 장점: 최대로 유연(즉시 생성/종료, 약정 없음)

• 단점: 장기 사용 시 단가가 가장 비쌈

• 적합: 개발/테스트, 트래픽 예측 어려운 초반 운영 / 연속적인 단기 워크로드

  • 과금 단위

    • 초 단위(최소 60초): Linux, Windows(및 Windows + SQL 버전들), 주요 리눅스 배포판들(예: Amazon Linux, Ubuntu, RHEL 등)

    • 시간당 과금: 그 외 OS 타입

2) 세이빙스 플랜(Savings Plans)

• 개념: “시간당 일정 금액(ex: 시간당 $0.50) 커밋(1년/3년)”을 약속하면 그 범위 내 사용에 할인 요금 적용

• 종류

  • Compute Savings Plans: 가장 유연. 리전 내 모든 인스턴스 패밀리/사이즈/OS/테넌시 및 Fargate/Lambda까지 할인

  • EC2 Instance Savings Plans: 특정 패밀리(예:m7i) 기준으로 할인(리전 내 사이즈/OS 변경은 허용)

• 지불 방식: All Upfront / Partial / No Upfront (선결제 클수록 할인↑).

• 장점: 예약 인스턴스보다 변경 유연성↑, 할인폭 큼

• 단점: 커밋 금액 미사용분도 비용 발생

• 적합: 상시 안정적 사용량이 있고, 인스턴스 다양성/이동이 잦을 때

• ❓실제 사용이 커밋보다 많으면??(예: $0.80)

  • $0.50 구간은 SP 할인, 초과 $0.30은 온디맨드 요율로 과금

3) 예약 인스턴스(Reserved Instances)

• 개념: 특정 조건(리전·플랫폼·패밀리 등)에 1년/3년 약정으로 할인

• 종류

  • Standard Reserved Instances: 예측 가능한 장기 워크로드(1년/3년 상시 가동) 에 쓰는 옵션/ 할인 최대(약정 조건 변경 거의 불가)

  • Convertible Reserved Instances: 조건 변경 가능(동등/상위 가치로 교환), 할인은 Standard보다 낮음

• 영역

  • Regional RI: 리전 단위 할인(자동 적용)
  • Zonal RI: 특정 AZ 고정 + 용량 보장(Capacity Reservation 포함).

• 지불 방식: All(전체 선결제)/Partial(부분 선결제)/No Upfront(선결제 x)

• 장점: 예측 가능한 장기 워크로드에 높은 할인

• 단점: 유연성 낮음, 초과/미달 사용 시 최적화 필요

• 적합: 고정적으로 켜져 있는 백엔드, DB 등

💡 마켓 플레이스에서 사고 팔 수 있다..!

4) 스팟 인스턴스(Spot)

• 개념: 미사용 EC2 용량을 최대 90% 저렴하게 사용, 중단(회수) 가능성 존재

• 특징: 회수 전 2분 알림, 중단 시 종료/정지/하이버네이트 동작 선택 가능(유형/지원에 따라) / 단기 워크로드에 적합

• 장점: 대폭 저렴

• 단점: 언제든 회수 가능, 상태 저장/세션형 서비스엔 부적합

• 적합: 배치/ETL, 데이터 분석, 이미지 처리, 컨테이너 워커, 분산 빌드/테스트

• 팁: 다중 인스턴스 패밀리+AZ 혼합, “용량-최적” 할당전략, 체크포인트/재시도 설계.

5) 전용 호스트(Dedicated Host)

• 개념: 물리적 서버 전체를 예약 / 물리 서버 자체를 소유한 듯 배정받아 라이선스·배치까지 세밀 제어

• 과금 : 호스트 단위 과금(on-demand(초/시간당 과금) / reserved(1 또는 3년))

• 장점:

  • BYOL((Bring Your Own License)(Windows/SQL Server/Oracle 등) 소켓/코어 기반 라이선스 규칙을 지키기 쉬움
  • 감사/규제에 필요한 서버 식별·배치 제어 가능
  • 인스턴스 배치/고정성을 세밀하게 관리.

• 단점:

  • 비용 높고 유연성 낮음(호스트 고정 비용)
  • 호스트 용량 계획 필요(과소/과대 배치 리스크)

• 시험 keyword:

  • 물리적 코어
  • 기본 네트워크 소켓 가시성을 기반으로 비용을 청구
    

6) 전용 인스턴스(Dedicated Host/Instances)

• 개념:

  • 단일 테넌트 하드웨어에서 가상 인스턴스를 쓰는 방식
  • 다른 고객의 인스턴스가 같은 물리 서버에 같이 올라오지 않도록 보장하지만, 그 물리 서버(호스트)에 대한 식별·제어권은 없음. 과금도 인스턴스 단위

• 장점:

  • 설정이 비교적 간단(테넌시를 Dedicated로 지정)
  • 물리적 격리가 필요하지만 서버 소켓/코어 단위 라이선스 관리가 필요 없을 때 적합

7) 온디맨드 용량 예약(ODCR, On-Demand Capacity Reservations)

• 개념: 특정 AZ/타입 용량을 미리 확보(비용은 인스턴스를 켜든 안 켜든 온디맨드 요율)

  시간 약정이 없어서 할인도 없다..!

• 조합: 세이빙스 플랜 또는 RI와 결합하면 예약된 용량에도 할인율 적용 가능

• 적합: 이벤트/출시일 등 용량 보장이 중요한 경우

  인스턴스 실행 여부와 상관없이 과금