sehee

제로 트러스트 아키텍처

sarahee — Tue, 7 Apr 2026 13:26:12 +0900

Logical Components of Zero Trust Architecture

서브젝트(Subject)

컴퓨터 시스템에서 작동, 엔터프라이즈 리소스에 접속할 수 있는 개념

애플리케이션 또는 장치로 정의

리소스(resource)

제로 트러스트 시스템에서 보호해야 하는 기업의 애플리케이션, 데이터, 문서나 워크로드

정책 적용 지점(PEP, Policy Enforcement Point)

리소스에 접속할 수 있는 지점

정책 결정 지점(PDP, Policy Decision Point)

ID를 확인(인증)받고 ID와 콘텍스트에 따라 해당 서브젝트에 최소한의 권한만 부여하고 이것을 PEP가 실행하는 형태

References:

[1] Zero Trust Architecture, NIST Special Publication 800-207, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

[AI Engineering] RAG와 에이전트 & 파인튜닝

sarahee — Tue, 7 Apr 2026 13:25:05 +0900

RAG와 에이전트

색인화(index): 나중에 빠르게 검색할 수 있도록 데이터를 처리하는 작업

질의(query): 관련 데이터를 검색하기 위해 시스템에 요청을 전송하는 과정

청크(chunk): 문서를 더 관리하기 쉬운 분할 방법, 문서 전체를 그냥 검색하면 컨텍스트가 지나치게 길어질 수 있기 때문

의미 기반 검색(semantic retrieval): 임베딩 기반 검색기의 문서의 의미가 질의와 얼마나 가까운지를 기준으로 순위를 매기는 방식

벡터 데이터베이스(vector database): 임베딩을 저장하는 데이터베이스 (임베딩 기반 검색에서 색인화가 하는, 원본 데이터 청크를 임베딩으로 변환하여 만들어진 임베딩)

컨텍스트 정밀도(context precision): 검색된 모든 문서 중에서 실제로 질의와 관련된 문서의 비율은 얼마인가?

컨텍스트 재현율(context recall): 질의와 관련된 모든 문서 중에서 실제로 검색된 문서의 비율은 얼마인가?

7. 파인튜닝

모델 전체나 일부를 추가로 학습시켜 특정 작업에 맞게 모델을 조정하는 과정

모델의 가중치를 요청하는 방식으로 모델을 조정하는 방식으로 모델을 변화시킴

(↔ 모델에 지시, 컨텍스트, 도구를 제공해 모델을 조정하는 프롬프트 기반 방법)

7.1. 파인튜닝 개요

파인튜닝은 전이 학습(transfer learning, TL)의 한 방법인데, 전이 학습은 1976년 보지노프스키(Bozinovski)와 풀고시(Fulgosi)가 처음 제안한 개념

전이 학습: 한 작업에서 얻은 지식을 새롭지만 관련된 작업에 활용해 학습 속도를 높이는 데 중점을 둠

전이 학습은 표본 효율성(sample efficiency)을 높여 모델이 더 적은 예시로도 같은 행동을 학습할 수 있게 함

지속적 사전 학습(continued pre-training): 자기 지도 파인튜닝

- 비싼 작업별 데이터로 사전 학습 모델을 파인튜닝하기 전에, 저렴한 관련 분야 데이터로 먼저 자기 지도 학습을 적용

인필링 파인튜닝(infilling finetunning): 지도 파인튜닝을 통해 (다음 토큰을 예측하거나) 빈칸을 채우도록 모델을 파인튜닝

- 앞뒤 토큰을 모두 활용해 빈칸을 채우는 마스크 모델, 텍스트 편집 및 코드 디버깅 같은 작업에 특히 유용함

롱 컨텍스트 파인튜닝(long-context finetunning): 컨텍스트 길이를 늘리기 위해 모델을 파인튜닝

- 위치 임베딩 조정 같은 모델 구조의 수정이 필요

7.2. 파인튜닝이 필요한 경우

JSON이나 YAML 같은 특정 구조의 출력을 생성할 때, 파인튜닝이 효과적임

7.3. 메모리 병목 현상

부분 파인튜닝(partial finetuning): 모델 파라미터의 일부만 업데이트

파라미터 효율적(parameter-efficient, PEFT): 적은 파라미터를 사용하면서도 전체 파인튜닝에 가까운 성능을 달성하는 기법

- 일반적으로, 수십 배 더 적은 학습 가능한 파라미터를 사용해 전체 파인튜닝에 근접한 성능을 달성할 수 있다면 파라미터 효율적이라고 봄

랭크: 원본 가중치 행렬을 두 개의 작은 행렬로 분해할 때의 차원 크기

가중치: 뉴런 간 연결의 강도

양자화(quantization): 정밀도를 낮추는 것

- 모델 값을 표현하는 데 필요한 비트 수가 적을수록, 모델의 메모리 사용량도 줄어듦

- 100억 파라미터 모델이 32비트 형식이면 가중치에 40GB가 필요하지만, 같은 모델이 16비트 형식으로 표현하면 20GB면 충분함

선형 결합, 구면 선형 보간법

PEFT 기법들

어댑터 기반 방법(adapter-based method): 모델 가중치에 추가 모듈을 붙이는 모든 방식, 파라미터를 추가하기 때문에 부가적 방법이라고도 부름 (모델 구조에 학습 가능한 파라미터를 추가)

- 예: LoRA, BitFit, IA3, LongLoRA

소프트 프롬프트 기반 방법(soft prompt-based method): 특별한 학습 가능한 토큰을 도입해 모델이 입력을 처리하는 방식을 바꿈

- 예: 프리픽스 튜닝, P-튜닝, 프롬프트 튜닝

LoRA

로라가 쓰이는? 이유가, 풀 파인튜닝하면 파라미터가 박혀서 기존에 작업하던 것도 멍청해짐 → 그걸 재앙적 망각이라고 함

개별 가중치 행렬에 적용 가능, 특정 가중치 행렬이 주어지면 LoRA는 이 행렬을 두 개의 더 작은 행렬의 곱으로 분해하고, 이 작은 행렬들을 업데이트한 후 다시 원래 행렬로 병합하는 방식

n x m 차원의 가중치 행렬 W

1. 더 작은 행렬들의 차원을 선택, 선택된 값을 r이라고 하자.

두 개의 행렬을 구성: A(n x r 차원)와 B(r x m 차원)

두 행렬의 곱 W_{AB}는 원래 행렬 W와 동일한 차원을 가진다. (여기서 r은 LoRA 랭크라고 부름)

2. W_{AB}를 원래 가중치 행렬 W에 더해 새로운 가중치 행렬 W'를 생성. 모델에서는 W 대신 W'을 사용.

하이퍼파라미터 α를 통해 W_{AB}가 새 행렬에 얼마나 영향을 미칠지 조절할 수 있다: W' = W + α/r W_{AB}

3. 파인튜닝 과정에서는 A와 B의 파라미터만 업데이트하고, W는 변경하지 않고 그대로 유지한다.

LoRA는 오래전부터 활용되어 온 차원 축소 기법인 저랭크 분해(low-rank factorization) 개념을 토대로 만들어짐

이 방식의 핵심은 큰 행렬을 두 개의 작은 행렬 곱으로 분해해 파라미터 수를 줄여서 계산량과 메모리 요구사항을 줄여줌

예: 9 x 9 행렬은 9 x 1과 1 x 9 크기의 두 행렬 곱으로 분해

- 원래 행렬은 81개의 파라미터를 가지지만, 분해된 두 행렬은 합해서 단 18개의 파라미터만 필요함

Fine-Tuning 방법의 계층 구조: 복잡도에 따라 4단계로 구분한다.

풀 튜닝(Full Tuning) - 가장 단순하지만 비용이 많이 듦
프롬프팅(Prompting) - 중간 단계
검색 증강 생성(RAG) - 더 복잡한 방식
파라미터 효율적 튜닝(PEFT) - 가장 복잡하지만 효율적

Control Tower account

sarahee — Tue, 7 Apr 2026 13:23:38 +0900

user+management@example.com - for your management account
user+logs@example.com - for your log archive account
user+audit@example.com - for your audit account
user+sandbox@example.com - for your sandbox account, created via the Account factory

AWS CLI v2 with IAM Identity Center

From your terminal, run the following command to sign-in to IAM Identity Center.

aws configure sso

Profile name [AWSAdministratorAccess-0112xxxxxxxx]: ManagementAccount

aws sts get-caller-identity --query 'Account' --output text --profile ManagementAccount

Control catalog

SCP (Service Control Policy), RCP (Resource Control Policy)

SCP: 모든 IAM 주체(사용자, 역할)에게 영향

RCP: 리소스 레벨 (지원 리소스: S3 버킷, Lambda 함수)

Account Factory에서 Default VPC 설정 수행 시

Control Tower 관리 CloudFormation Stack 확인

- Account Baseline, Security Baseline이 기본으로 설정됨, CT 관리 계정에서 CloudFormation StackSet으로 관리됨

References:

AWS Control Tower Guide, https://catalog.workshops.aws/control-tower/en-US/prerequisites/email-addresses

AWS Control Tower Workshop

AWS Control Tower Workshop Studio

catalog.workshops.aws

AI 언어 모델

sarahee — Tue, 7 Apr 2026 13:22:49 +0900

마스크 언어 모델

누락된 토큰 전후 컨텍스트를 사용해 시퀀스의 어느 위치에서든 누락된 토큰을 예측하도록 학습

e.g., 내가 가장 좋아하는 __는 파란색이다.

자기회귀 언어 모델

이전 토큰들만 보고 시퀀스의 다음 토큰을 예측하도록 학습

e.g., 내가 가장 좋아하는 색상은 __이다.

생성형 AI (generative AI)

언어 모델의 출력에는 제한이 없다. 언어 모델은 정해진 유한한 어휘만을 사용해서 무한히 다양한 결과물을 만들어 낼 수 있다.

이처럼 정해진 답 없이 개방형 출력을 생성하는 모델을 생성 모델(generative model)이라고 부르는데, 여기에서 생성형 AI라는 용어가 유래됐다.

프롬프트 엔지니어링

원하는 제품 설명 예시와 함께 상세한 지시를 모델에 제공하는 방법

검색 증강 생성(retrieval-augmented generation, RAG)

데이터베이스를 활용해 지시를 보완하는 것, 모델을 고객 리뷰 데이터베이스에 연결하여 더 나은 설명을 생성하도록 할 수 있음

[Control Tower] sts:AssumeRoot (BreakGlassAssumeRoot)

sarahee — Mon, 16 Mar 2026 22:03:21 +0900

1. 개요

AWS Organizations 환경에서 sts:AssumeRoot는 Management Account 또는 Delegated Admin 계정에서 멤버 계정의 Root 수준 임시 세션을 획득하여, 사전 정의된 Task Policy 범위 내에서 특권 작업(Privileged Action)을 수행할 수 있는 기능입니다.

이를 통해 멤버 계정별로 Root 자격증명(비밀번호, 액세스 키, MFA)을 개별 관리하지 않고도, 중앙에서 Root 수준의 긴급 조치를 수행할 수 있습니다.

2. AssumeRoot가 필요한 케이스

2.1 S3 버킷 정책 잠금 해제

항목	내용
상황	잘못된 S3 버킷 정책 적용으로 모든 Principal의 접근이 차단됨 (본인 포함 Deny)
증상	버킷 소유자 포함 어떤 IAM 자격증명으로도 버킷 정책 수정/삭제 불가
Task Policy	S3UnlockBucketPolicy
수행 작업	잠긴 S3 버킷 정책 삭제

예시 시나리오: 버킷 정책에 "Effect": "Deny", "Principal": "*" 를 잘못 적용하여, 관리자 포함 전체 접근이 차단된 경우. 일반 IAM 권한으로는 해당 정책을 수정할 수 없으며, Root 세션으로만 정책 삭제 가능

2.2 SQS 큐 정책 잠금 해제

항목	내용
상황	잘못된 SQS 큐 리소스 정책 적용으로 큐 접근 및 정책 수정 불가
증상	메시지 송수신 및 큐 정책 변경 불가로 서비스 중단
Task Policy	SQSUnlockQueuePolicy
수행 작업	잠긴 SQS 큐 리소스 정책 삭제

예시 시나리오: SQS 큐 정책에서 모든 Principal에 대해 Deny를 적용하여, 연동된 Lambda/EC2 등 워크로드가 메시지를 처리하지 못하고 서비스 장애가 발생한 경우

2.3 멤버 계정 Root 자격증명 삭제

항목	내용
상황	멤버 계정의 Root 자격증명(비밀번호, 액세스 키, MFA)이 유출되었거나, 보안 정책상 Root 자격증명을 제거해야 하는 경우
증상	멤버 계정 Root 로그인 가능 상태가 보안 위험으로 식별됨
Task Policy	IAMDeleteRootUserCredentials
수행 작업	멤버 계정의 Root 콘솔 비밀번호, 액세스 키, 서명 인증서, MFA 디바이스 삭제

예시 시나리오: Organizations 환경에서 멤버 계정의 Root 자격증명을 중앙에서 일괄 제거하여, Root 직접 로그인을 원천 차단하고 중앙 집중식 루트 액세스만 허용하는 경우

2.4 멤버 계정 Root 비밀번호 복구

항목	내용
상황	멤버 계정에 Root로 직접 로그인이 필요하나, 비밀번호가 설정되어 있지 않거나 분실된 경우
증상	Root 이메일을 통한 비밀번호 재설정이 불가하거나 시간이 오래 소요됨
Task Policy	IAMCreateRootUserPassword
수행 작업	멤버 계정의 Root 로그인 프로필(비밀번호) 생성

예시 시나리오: 특정 멤버 계정에서 Root 수준의 콘솔 접근이 필요하나(예: 특정 서비스의 Root-only 설정 변경), Root 비밀번호가 설정되어 있지 않은 경우 임시로 비밀번호를 생성하여 접근

2.5 Root 자격증명 현황 감사

항목	내용
상황	멤버 계정의 Root 자격증명 상태(비밀번호 존재 여부, 액세스 키 활성 여부, MFA 등록 여부)를 중앙에서 확인해야 하는 경우
증상	보안 감사 또는 컴플라이언스 점검 시 각 계정별 Root 자격증명 현황 파악 필요
Task Policy	IAMAuditRootUserCredentials
수행 작업	멤버 계정의 Root 자격증명 현황 조회

예시 시나리오: 분기별 보안 감사에서 전체 멤버 계정의 Root 자격증명이 제거되었는지 일괄 확인. 자격증명이 남아있는 계정에 대해 IAMDeleteRootUserCredentials로 후속 조치

2.6 케이스 요약

Task Policy	사용 케이스
S3UnlockBucketPolicy	S3 버킷 정책 잠금으로 인한 데이터 접근 불가
SQSUnlockQueuePolicy	SQS 큐 정책 잠금으로 인한 메시지 처리 중단
IAMDeleteRootUserCredentials	Root 자격증명 유출 대응 또는 보안 정책 적용
IAMCreateRootUserPassword	Root 콘솔 접근 필요 시 비밀번호 복구
IAMAuditRootUserCredentials	Root 자격증명 현황 감사/점검

3. 사전 구성

3.1 Root access management 활성화

Management Account에서 Root Access Management를 활성화합니다.

경로: Control Tower 계정의 IAM > Access Management > Root access management > Enable

활성화 시 다음 두 가지 기능이 사용 가능합니다:

Root credentials management: 멤버 계정의 Root 자격증명을 중앙에서 관리(삭제/생성/감사)
Root sessions: 멤버 계정에 대한 Root 수준 임시 세션 획득(Take privileged action)

3.2 Delegated Admin 등록 (선택)

Management Account 외에 특정 계정(예: Audit)에서도 AssumeRoot를 수행할 수 있도록 Delegated Admin을 등록합니다. 관리자 계정 외에도, 이 회원 계정은 다른 회원 계정에 대한 중앙 집중식 루트 액세스 권한을 갖게 됩니다.

Enable 이후, Management 계정에서 Delegated Admin 등록 확인: 계정(예: Audit)이 정상적으로 등록되었는지 확인

aws organizations list-delegated-administrators --service-principal iam.amazonaws.com

참고: Delegated Admin 등록 여부는 의사결정 사항. 등록하지 않는 경우 Management Account에서만 AssumeRoot 수행 가능.

기존은 아래와 같이 호출하는 IAM 자격증명에 sts:AssumeRoot 권한이 없었으나, 위임된 계정에서 접근 가능해집니다.

Access denied to : You don't have permission to perform this action.You don't have permissions to access this resource.

3.3 Permission Set 생성

AssumeRoot를 수행할 담당자에게 할당할 Permission Set을 생성합니다.

Audit 계정에서 사용하는 IAM 역할(Permission Set)에 sts:AssumeRoot 권한이 있는지 확인

Management 계정 콘솔 > IAM Identity Center > Permission Sets

Audit 계정에 할당된 Permission Set 선택 (해당 계정에 할당된 퍼미션셋은 AWS accounts의 structure에서 확인)

3.3.1 Create permission set

항목	값
Permission set type	Custom permission set
Name	BreakGlassAssumeRoot
Description	Break Glass - sts:AssumeRoot for emergency privileged access
Session duration	1 hour (최소한으로 설정)

Step 1. Specify permission set details

Permission set type: Custom permission set

Step 2. Specify policies and permissions boundary

Inline policy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowAssumeRoot",
			"Effect": "Allow",
			"Action": "sts:AssumeRoot",
			"Resource": "*"
		},
		{
			"Sid": "AllowListAccounts",
			"Effect": "Allow",
			"Action": [
				"organizations:ListDelegatedAdministrators",
				"organizations:ListAWSServiceAccessForOrganization",
				"organizations:DescribeOrganization",
				"organizations:ListRoots",
				"organizations:ListAccountsForParent",
				"organizations:ListOrganizationalUnitsForParent",
				"ec2:DescribeRegions",
				"sso:DescribeRegisteredRegions",
				"sso:ListInstances",
				"iam:ListSTSRegionalEndpointsStatus",
				"iam:GetOutboundWebIdentityFederationInfo",
				"iam:GetAccountSummary",
				"iam:ListAccountAliases",
				"iam:ListOrganizationsFeatures",
				"account:GetAccountInformation"
			],
			"Resource": "*"
		}
	]
}

AllowListAccounts Statement는 콘솔에서 Root access management 화면의 조직 구조 조회 및 Take privileged action 대상 계정을 확인하기 위해 필요합니다. 이 권한이 없으면 콘솔에서 계정 목록 및 OU 구조를 로드할 수 없습니다.

Step 3. Specify permission set details

Permission set name: BreakGlassAssumeRoot
Description: Break Glass - sts:AssumeRoot for emergency privileged access
Session duration: 1 hour (최소한으로 설정)

3.3.2 Take privileged action 권한 추가 할당

Delete S3 bucket policy

Delete SQS queue policy

Allow password recovery

임시 루트 세션의 범위를 지정할 수 있습니다.

policy/root-task/IAMDeleteRootUserCredentials
루트 세션은 멤버 루트 자격 증명(콘솔 암호, 액세스 키, 서명 인증서 및 MFA 장치)을 삭제할 수 있도록 범위가 제한됩니다.
policy/root-task/IAMCreateRootUserPassword
루트 세션은 멤버 루트 로그인 프로필 생성을 허용하도록 범위가 지정됩니다.
policy/root-task/IAMAuditRootUserCredentials
루트 세션은 루트 자격 증명을 검토하도록 범위가 지정됩니다.
policy/root-task/S3UnlockBucketPolicy
루트 세션은 S3 버킷 정책을 삭제할 수 있도록 범위가 지정됩니다.
policy/root-task/SQSUnlockQueuePolicy
루트 세션은 SQS 큐 리소스 정책을 삭제할 수 있도록 범위가 지정됩니다.

3.3.3 Permission Set 계정 할당

생성한 Permission Set을 대상 계정(Management Account 또는 Delegated Admin 계정)에 할당합니다.

경로: IAM Identity Center → AWS accounts → 대상 계정 선택 → Assign users or groups

단계	내용
Step 1. Users and groups	Break Glass 담당자 사용자 또는 그룹 선택
Step 2. Permission sets	BreakGlassAssumeRoot 선택
Step 3. Review and submit	확인 후 Submit

Step 1 - Users and groups: Break Glass 담당자 사용자 또는 그룹 선택

Audit 계정에 로그인하는 IAM Identity Center 사용자/그룹이 실제로 sts:AssumeRoot API를 호출할 수 있도록 IAM 권한을 부여하는 것 (Audit 계정에 로그인하는 사람에게 AssumeRoot 실행 권한 부여)

Step 2 - Permission sets: BreakGlassAssumeRoot 선택

Step 3 - Review and submit: 내용 확인 후 Submit

4. 사용 절차

4.1 콘솔에서 Take Privileged Action 수행

1. Access Portal URL에 접속하여 SSO 로그인

- Access Portal URL: IAM Identity Center > Dashboard > Settings summary > AWS access portal URL (형식: https://d-xxxxxxxxxx.awsapps.com/start)

2. 대상 계정에서 BreakGlassAssumeRoot Permission Set으로 Management Console 접근

3. IAM > Access Management > Root access management > Organizational structure에서 대상 멤버 계정 선택

4. Take privileged action 클릭 후 수행할 작업 선택:

Delete S3 bucket policy
Delete SQS queue policy
Allow password recovery

4.2 CLI에서 AssumeRoot 수행 (참고)

콘솔 대신 CLI로 수행하는 경우의 절차입니다:

# 1. AssumeRoot 호출하여 임시 자격증명 획득
aws sts assume-root \\
  --target-principal <멤버-계정-ID> \\
  --task-policy-arn arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \\
  --duration-seconds 900

# 2. 발급받은 임시 자격증명 설정
export AWS_ACCESS_KEY_ID="발급받은값"
export AWS_SECRET_ACCESS_KEY="발급받은값"
export AWS_SESSION_TOKEN="발급받은값"

# 3. Root 세션으로 작업 수행 (예: S3 버킷 정책 삭제)
aws s3api delete-bucket-policy --bucket <버킷명>

# 4. 임시 자격증명 해제
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

5. 테스트 시나리오

5.1 S3 버킷 정책 잠금 해제 테스트

Step 1. S3 버킷 생성/조회 (멤버 계정)

멤버 계정에서 테스트용 S3 버킷을 생성합니다.

Step 2. 잠금 버킷 정책 적용 (멤버 계정)

모든 Principal의 접근을 차단하는 Deny 정책을 적용합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAll",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::assumeroot-saraheee",
        "arn:aws:s3:::assumeroot-saraheee/*"
      ]
    }
  ]
}

Step 3. 잠금 확인 (멤버 계정)

버킷 소유자 포함 모든 IAM 자격증명으로 접근이 차단되었는지 확인합니다:

# 버킷 정책 조회 시도 → Access Denied
aws s3api get-bucket-policy --bucket assumeroot-saraheee

# 버킷 정책 삭제 시도 → Access Denied
aws s3api delete-bucket-policy --bucket assumeroot-saraheee

# 오브젝트 목록 조회 시도 → Access Denied
aws s3 ls s3://assumeroot-saraheee

Step 4. Task Privileged Action 수행 (관리/위임 계정)

관리 계정(또는 Delegated Admin 계정)의 콘솔에서 Root access management로 이동하여 Take privileged action을 수행합니다.

CLI 사용 시에는 sts:AssumeRoot API를 직접 호출합니다. (4.2절 참고)

Step 5. S3 버킷 정책 삭제 (Root 세션)

Delete S3 bucket policy 작업을 선택하고, 잠긴 버킷을 지정하여 정책을 삭제합니다.

Step 6. 정상 접근 복구 확인 (멤버 계정)

버킷 정책 삭제 후, 멤버 계정에서 다시 정상 접근이 가능한지 확인합니다.

5.2 SQS 큐 정책 잠금 해제 테스트

Step 1. SQS 큐 생성 (멤버 계정)

멤버 계정에서 테스트용 SQS 큐를 생성합니다.

Step 2. 잠금 큐 정책 적용 (멤버 계정)

모든 Principal의 접근을 차단하는 Deny 정책을 적용합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAll",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:ap-northeast-2:xxxxxxxxxxxx:assumeroot-saraheee"
    }
  ]
}

Step 3. 잠금 확인 (멤버 계정)

메시지 송수신 및 큐 정책 변경이 차단되었는지 확인합니다:

참고: 수 분 소요

# 메시지 전송 시도
aws sqs send-message  --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --message-body "test"

# 큐 속성 조회 시도
aws sqs get-queue-attributes --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --attribute-names All

# 큐 정책 변경 시도 (빈 정책으로 삭제 시도)
aws sqs set-queue-attributes --queue-url <https://sqs.ap-northeast-2.amazonaws.com/xxxxxxxxxxxx/assumeroot-saraheee> --attributes '{"Policy": ""}'

Step 4. Take Privileged Action 수행 (관리/위임 계정)

관리 계정(또는 Delegated Admin 계정)의 콘솔에서 Root access management로 이동하여 Take privileged action을 수행합니다.

CLI 사용 시에는 sts:AssumeRoot API를 직접 호출합니다. (4.2절 참고)

Step 5. SQS 큐 정책 삭제 (Root 세션)

Delete SQS queue policy 작업을 선택하고, 잠긴 큐의 ARN을 지정하여 정책을 삭제합니다:

SQS Queue ARN: arn:aws:sqs:ap-northeast-2:xxxxxxxxxxxx:assumeroot-saraheee

Step 6. 복구 확인 (멤버 계정)

큐 정책 삭제 후, 멤버 계정에서 다시 정상 접근이 가능한지 확인합니다:

6. Task Policy 상세

Task Policy ARN	허용 작업	대상 리소스
arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy	S3 버킷 정책 삭제	대상 멤버 계정의 S3 버킷
arn:aws:iam::aws:policy/root-task/SQSUnlockQueuePolicy	SQS 큐 리소스 정책 삭제	대상 멤버 계정의 SQS 큐
arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials	Root 비밀번호, 액세스 키, 서명 인증서, MFA 삭제	대상 멤버 계정의 Root 자격증명
arn:aws:iam::aws:policy/root-task/IAMCreateRootUserPassword	Root 로그인 프로필(비밀번호) 생성	대상 멤버 계정의 Root 로그인 프로필
arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials	Root 자격증명 현황 조회	대상 멤버 계정의 Root 자격증명

Appendix

구성 시 발생 가능한 권한 부족 오류 및 해결

(참고) 권한 부족 1.

CloudTrail Event history

organizations:ListDelegatedAdministrators
organizations:ListAWSServiceAccessForOrganization
sso:DescribeRegisteredRegions
organizations:DescribeOrganization
ec2:DescribeRegions

로그 에러

"errorMessage": "User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_BreakGlassAssumeRoot_xxxxxxxxxxxxxxxx/saraheee@email.com is not authorized to perform: organizations:DescribeOrganization on resource: * because no identity-based policy allows the organizations:DescribeOrganization action",

(참고) 권한 부족 2.

We couldn't load the root of the organization.

You don't have permissions to see this resource, because the management account has not granted you the permissions to view accounts.

CloudTrail Event history

로그 에러

"errorMessage": "User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_BreakGlassAssumeRoot_xxxxxxxxxxxxxxxx/saraheee@email.com is not authorized to perform: iam:GetOutboundWebIdentityFederationInfo on resource: * because no identity-based policy allows the iam:GetOutboundWebIdentityFederationInfo action",

organizations:DescribeOrganization
organizations:ListRoots
sso:ListInstances
iam:ListSTSRegionalEndpointsStatus
iam:GetOutboundWebIdentityFederationInfo

(참고) 권한 부족 3.

We couldn't load organizational units.

You don't have permissions to see this resource, because the management account has not granted you the permissions to view accounts.

CloudTrail Event history

iam:GetAccountSummary
iam:ListAccountAliases
account:GetAccountInformation
iam:ListOrganizationsFeatures
organizations:ListAccountsForParent
organizations:ListOrganizationalUnitsForParent

조회 완료

Attention is all you need

sarahee — Wed, 18 Feb 2026 17:55:05 +0900

RNN, LSTM

Transformer model

Attention

같은 문장 내에서 단어들 간의 관계

QKV (Query, Key, Value)

예: I love her 영어를 한국어로 번역하는 것

Query: '나는'이라는 주체

Key: 연관성을 찾는 대상 (I, love, her)

Value: Q와 K의 유사성을 계산하여 유사한 만큼의 값을 가져오는 것

d_k의 루트 값으로 나누어주는 이유: d_k 값이 너무 커지게 되면 행렬의 연산 값도 커지면서 softmax 함수가 극도로 작은 기울기를 갖는 영역을 가지게될 수 있음 → 0에 가까운 값으로 정규화시킴

References

[논문리뷰] Attention is All you need의 이해 - https://lcyking.tistory.com/entry/%EB%85%BC%EB%AC%B8%EB%A6%AC%EB%B7%B0-Attention-is-All-you-need%EC%9D%98-%EC%9D%B4%ED%95%B4

QLoRA 데이터 형식/변환

sarahee — Wed, 18 Feb 2026 16:55:36 +0900

(-1)^부호 x 가수 x 2^지수

가수(Mantissa, precision): 정규화된 값, 가수 비트가 많을수록 더 정밀한 값을 표현

지수(Exponent, range): 지수 비트가 많을수록 표현할 수 있는 숫자의 범위가 넓어짐

예: -12.5를 표현한다면:
- 부호: 음수 (-)
- 가수: 1.5625 (정규화된 값)

- 지수: 3 (2³ = 8을 곱함)
- 결과: -1 × 1.5625 × 8 = -12.5

Float32(FP32)

- 8 bits: 지수부(exponent)

- 23 bits: 가수부(mantissa)

- 1 bits: 부호(sign)

ML에선 FP32를 full precision(4 bytes), BF16와 FP16을 half-precision(2 bytes)라고 부름 - 기준

BF: Brain Float

C-Float8: FP8, Quarter Precision

- E4M3: 4bits range + 3bits precision

- E5M2: 5bits range + 2bits precision

UINT8: Unsigned Integer 8-bit

- 부동소수점이 아닌 정수형, 0~255

Double Quantization

QLoRA 최적화 요소 4비트 NormalFloat (FP32 -> NF4)

정규화, 역양자화, ...

References

TensorFloat-32 in the A100 GPU Accelerates AI Training, HPC up to 20x, https://blogs.nvidia.com/blog/tensorfloat-32-precision-format/

[Paper Review] QLoRA: Efficient Finetuning of Quantized LLMs - https://moomyung-lab.tistory.com/11

Enable AWS Control Tower

sarahee — Tue, 10 Feb 2026 11:39:16 +0900

관리 계정 생성

1. 공유 계정 이메일 주소 생성

관리 계정 (Account) 이메일 주소

saraheee+ctmgmt@gmail.com

saraheee: 기존에 보유하고 있는 이메일 주소
+ctmgmt: 확장 이메일 주소
+logs: log archive account
+audit: audit account
+aft: aft account

2. 계정 생성

Step 1: Choose setup preferences

AWS Control Tower console > 리전 선택 > Enable AWS Control Tower

Home Region

랜딩 존이 배포될 지역 (차후 설정 변경 불가)

- IAM Identity Center 및 통합 로깅을 위한 S3 버킷과 같은 주요 리소스가 이 지역에 배포됨

예: Asia Pacific (Seoul): ap-northeast-2

Select additional Regions for governance

거버넌스를 위한 추가 리전

예: US East (N. Virginia): us-east-1

Region deny control

랜딩 존에 대한 지역 제어 거부 설정 (차후 설정 변경 가능)

제어 적용(Enabled) 시, Control Tower에서 관리되지 않은 리전(Home Region/additional Regions for governance 외 리전)에 리소스가 있는 경우 해당 리전의 리소스에 접근할 수 없음

Automatic account enrollment (Turn on 권장)

계정이 등록된 OU로 이동할 때 AWS Control Tower에 자동으로 등록 (버전 3.1 이상의 랜딩 존에서 지원)

랜딩 존 설정 페이지 혹은 Control Tower의 CreateLandingZone/UpdateLandingZone API를 호출 시 계정을 자동으로 등록할 수 있음

계정을 OU로 이동시킬 때 Control Tower가 거버넌스 관리 대상으로 등록

해당 설정 Turn off 시 계정 레벨에서 생성되는 리소스인 Detective/Proactive Controls (AWS Config Rules, CloudFormation 리소스 배포 등)은 계정을 다른 OU로 이동해도 자동으로 업데이트되지 않음
계정을 OU 간 이동할 때마다 Detective/Proactive 컨트롤이 새로운 OU 설정에 맞게 재배포되도록 수동으로 OU Re-register 작업을 수행해야 했음
OU 계층 구조에 따라 자동으로 적용되는 Preventive Controls (SCP, RCP)는 영향 없음

자동 등록을 사용하여 계정 이동 및 등록 - https://docs.aws.amazon.com/ko_kr/controltower/latest/userguide/account-auto-enrollment.html

Step 2 - Create organizational units (OUs)

Foundational OU : Security
Additional OU : Production

Step 3 - Configure Service integrations

Default OU for service integrations

활성화된 서비스 통합과 관련된 모든 AWS 계정이 포함됨

새 계정을 배치할 조직 단위 선택: 예: Security

AWS Config for detective controls

AWS 리소스의 구성 변경 사항을 기록하고 규정 준수 상태를 모니터링하는 서비스

Enable/Disable: Control Tower가 모든 계정에서 AWS Config를 자동으로 활성화하여 리소스 구성 변경 사항을 추적

Aggregator account : saraheee+ctlog@gmail.com

Create new
Create account: saraheee+ctlog@gmail.com
Change account name : Aggregator account (Log Archive)

Audit 계정: 보안 및 컴플라이언스 팀이 모든 계정들에 대한 읽기 및 쓰기 액세스를 얻기 위한 제한된 계정

AWS CloudTrail Centralized logging

중앙 집중식 로깅, 조직 전체의 CloudTrail 로그를 중앙에서 관리할 계정을 지정

CloudTrail administrator: saraheee+ctaudit@gmail.com

Create New
Create account : saraheee+ctaudit@gmail.com
Change account name: CloudTrail administrator (Audit)

Log Archive 계정: 모든 계정들의 API 작업 및 리소스 구성에 대한 로그들을 변경불가하게 보관하는 저장소

KMS key encryption

AWS Control Tower 리소스(CloudTrail 로그, Config 로그 등)를 고객 관리형 KMS 키로 암호화

다중 리전 키는 지원되지 않음

Amazon S3 bucket preferences for logs

S3 로깅 버킷과 액세스 로깅 버킷의 수명 주기 보존 기간을 나타내는 숫자를 입력

Amazon S3 bucket retention for logging

CloudTrail 로그, Config 로그 등이 저장되는 메인 로그 버킷
기본값: 1년

Amazon S3 bucket retention for access logging

S3 버킷 자체의 액세스 로그를 저장하는 버킷 (로그 버킷에 대한 접근 기록)
기본값: 10년

AWS IAM Identity Center account access

Control Tower에 등록된 AWS 계정에 대한 액세스 관리 방법 선택

IAM Identity Center 또는 계정 액세스 관리에 대한 사용자 지정 요구 사항이 있는 경우

AWS Backup

설정 비용은 없음, 사용량에 따라 비용이 청구됨 (Don’t enable 선택 이후 활성화 가능)

Metering, costs, and billing for AWS Backup - https://docs.aws.amazon.com/aws-backup/latest/devguide/metering-and-billing.html

Configure git

sarahee — Tue, 2 Dec 2025 11:21:25 +0900

configure your Git identities:

git config --global user.name "your_full_name"
git config --global user-email "your_email"

set your default branch to be main:

git config --global init.defaultBranch main

set up auto-correct:

git config --global help.autocorrect <duration>

<duration>: ms

verify your settings:

git config --list

git init
git add .
git commit -m "initial commit"
git status

# in AWS console
git remote add origin  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/sionna
git branch -M main

git config —global credential.helper '!aws codecommit credential-helper $@'
git config —global credential.UseHttpPath true

git push -u origin main

[AWS] CloudFormation Workshop#01 - template and stack

sarahee — Thu, 20 Nov 2025 17:57:54 +0900

In the Intermediate part of the workshop, you will:

Learn how to manage multiple stacks by creating Nested Stacks and Layered Stacks
You will learn how to Package and Deploy a Nested Stack from an S3 bucket.

In the Advanced part of the workshop, you will:

Learn about the AWS CloudFormation registry
Learn how to extend CloudFormation by creating modules
Learn how to extend CloudFormation by creating resource types

AWS Cloud9 (CloudShell) Setup

Clone lab resources using git

git clone https://github.com/aws-samples/cfn101-workshop

Install the latest version of AWS CLI

cd cfn101-workshop/code/solutions/cloud9
chmod +x awscliv2.sh
source awscliv2.sh
aws --version
# aws-cli/2.31.34 Python/3.13.9 Linux/6.1.155-176.282.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023

Local Development Setup

We recommend you install the AWS CloudFormation Linter . A linter

will proactively flag basic errors in your CloudFormation templates before you deploy them.

If you are using Visual Studio Code, you should install the cfn-lint plugin.

pip install cfn-lint

Default VPC

default VPC using the Amazon VPC console

$ aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query "Vpcs[].VpcId" --region us-east-1
[
    "vpc-xxxxxxxxxxxxxaa89"
]

Basics

cd cfn101-workshop/code/workspace
aws cloudformation create-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml

template-and-stack.yaml file

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256

use the AWS CLI to create the stack - create-stack command was successfully sent, CloudFormation will return StackId

$ aws cloudformation create-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxx7753:stack/cfn-workshop-template-and-stack/xxxxxxxx-xxxx-xxxx-xxxx-0e672ed843db"
}

Challenge

객체가 삭제되거나 덮어쓰는 것을 방지하거나, 객체를 보관하여 이전 버전으로 복구할 수 있도록 S3 버킷에서 버전 관리를 활성화

- S3 리소스의 속성 섹션에 VersioningConfiguration 속성을 생성
- 상태를 enabled 설정
- 템플릿에서 변경된 내용을 반영하도록 스택을 업데이트

# add Properties
        VersioningConfiguration:
          Status: Enabled

스택 업데이트

$ aws cloudformation update-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxx7753:stack/cfn-workshop-template-and-stack/xxxxxxxx-xxxx-xxxx-xxxx-0e672ed843db"
}

Git Workshop - hugo

sarahee — Wed, 5 Nov 2025 19:02:55 +0900

Hugo is a fast, open-source static site generator that simplifies creating websites.

brew install hugo

Creating a new hugo site

hugo new site <my-site-name>

- replace <my-site-name> with my desired project name: sarah-hugo

Installing a Theme for my hugo site

- Hugo doesn’t come with a built-in default theme
- choose a theme from hugo themes that suits my project (popular: Ananke theme (for beginners))
+ Initializing a Git Repository (in <my-site-name> folder)

cd sarah-hugo
git init
git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke

Configure Hugo to use the theme by editing the hugo.toml configuration file

# vi sarah-hugo/hugo.toml
baseURL = 'https://example.org/'
languageCode = 'en-us'
title = 'My New Hugo Site'

theme = "ananke"

Creating a Simple Content File

hugo new posts/my-first-post.md

generates a new Markdown file located in the content/posts directory

open the newly created file in my preferred text editor:

nano content/posts/my-first-post.md

+++
date = '2025-11-05T17:45:09+09:00'
draft = true
title = 'My First Post'
+++

add some content below the front matter

# Welcome to My First Post! 

This is my very first post using Hugo and Git. Exciting times ahead!

in nano, CTR + 0, then Enter, and then CTRL + X to exit

Staging my changes

stage all changes in my project directory by running:

git add .

Making my first commit

git config --global user.email "my@gmail.com"
git config --global user.name "my name"

git commit -m "Add first post: My First Post"

Viewing my changes with Hugo

start the Hugo server to view the changes locally

hugo server -D

-D flag stands for Draft

open my web browser and go to ‘http://localhost:1313’

Viewing my commit history

git log

commit axxxxxxxxxxxxxxxxx0 (HEAD → main)
Author: my name <my@gmail.com>
Date: Wed Nov 5 18:17:59 2025 +0900

Add first post: My First Post

Ignoring unnecessary files with .gitignore

it’s important to recognize that not all files need to be tracked by Git
- such as logs, build artifacts, and environment configurations

inside the root of your project directory, create a file named .gitignore:

touch .gitignore

In this file, you can specify file patterns that Git should ignore. For example:

# Ignore log files
*.log

# Ignore Hugo build directory
public/

# Ignore temporary editor files
*.swp

References:

From Theory to Practice: A Git Workshop for Beginners - https://hjortberg.substack.com/p/from-theory-to-practice-a-git-workshop

AWS certificate

sarahee — Mon, 3 Nov 2025 17:05:06 +0900

25.11.03 기준

Foundational

AWS Certified Cloud Practitioner

: CLF-C02 / 719 questions

https://www.examtopics.com/exams/amazon/aws-certified-cloud-practitioner-clf-c02/

AWS Certified AI Practitioner

: AIF-C01 / 318 questions

https://www.examtopics.com/exams/amazon/aws-certified-ai-practitioner-aif-c01/

Associate

AWS Certified Solutions Architect - Associate

: SAA-C03 / 1019 questions

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/

AWS Certified Machine Learning Engineer - Associate

: MLA-C01 / 145 questions

https://www.examtopics.com/exams/amazon/aws-certified-machine-learning-engineer-associate-mla-c01/

AWS Certified Developer - Associate

: DVA-C02 / 557 questions

https://www.examtopics.com/exams/amazon/aws-certified-developer-associate-dva-c02/

AWS Certified CloudOps Engineer - Associate

: SOA-C03 / 478 questions (C02 기준)

https://www.examtopics.com/exams/amazon/aws-certified-sysops-administrator-associate/

AWS Certified Data Engineer - Associate

: DEA-C01 / 261 questions

https://www.examtopics.com/exams/amazon/aws-certified-data-engineer-associate-dea-c01/

Professional

AWS Certified Solutions Architect - Professional

: SAP-C02 / 529 questions

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-professional-sap-c02/

AWS Certified DevOps Engineer - Professional

: DOP-C02 / 390 questions

https://www.examtopics.com/exams/amazon/aws-certified-devops-engineer-professional-dop-c02/

AWS Certified Generative AI Developer - Professional[베타 시험]

: -

Specialty

AWS Certified Machine Learning - Specialty (until March 31, 2026)

: MLS-C01 / 369 questions

https://www.examtopics.com/exams/amazon/aws-certified-machine-learning-specialty/

AWS Certified Security - Specialty

: SCS-C02 / 307 questions

https://www.examtopics.com/exams/amazon/aws-certified-security-specialty-scs-c02/

AWS Certified Advanced Networking - Specialty

: ANS-C01 / 272 questions

https://www.examtopics.com/exams/amazon/aws-certified-advanced-networking-specialty-ans-c01/

References:

https://aws.amazon.com/ko/certification/

[AWS] Route53 S2S VPN

sarahee — Wed, 29 Oct 2025 14:22:00 +0900

VPN Basics

VPN allows hosts to communicate privately over an untrusted intermediary network like internet, in encrypted from

AWS 측 VPC: 10.0.0.0/16

onpremise 측 VPC: 192.168.0.0/16 (172.31.0.0/16)

VGW 생성

CGW 생성 (onprem-VPC의 EC2 인스턴스 퍼블릭 IP)

Site-to-Site VPN connection 생성 (static IP prefixes: 192.168.0.0/16)

IP Sec down

- VPN connections 우측 상단 Download configuration 버튼을 클릭하여, 각 고객 게이트웨이 디바이스 제공업체 별 configuration 파일 다운로드

- Actions > Modify VPN tunel options > 터널 1 선택하여 log group 설정(로그 기록 활성화 가능)

on-prem 라우터 설정

instance 설정 >

onprem-EC2에 strongswan 설치 및 설정

sudo yum update
sudo yum install strongswan  # Amazon Linux 2023에는 strongswan 패키지가 기본 저장소에 없음
sudo yum install libreswan -y

AWS-VPC 라우팅 테이블 설정

192.168.0.0/16 -> Virtual Private Gateway

Onprem-VPC 라우팅 테이블 설정

10.0.0.0/16 -> Local VPN instance

연결 테스트

# AWS-EC2에서

ping <onprem-EC2-private-IP>

# onprem-EC2에서

ping <AWS-EC2-private-IP>

CloudFormation Stacks > Outputs

Key	Value	Description
AppServerPrivate	192.168.2.20	Private IP of App Server
DNSServerPrivate	192.168.2.250	DNS Server IP Address on DataCenter
Router1Private	192.168.1.10	Private IP of Router1
Router1Public	3.34.31.6	Public IP of Router1

Transit gateway attachments > VPN type, IP Address: Router1Public, BGP ASN: 65016

WebRTC

sarahee — Wed, 29 Oct 2025 14:21:24 +0900

WebRTC (Web Real-Time Communication): 웹/앱에서 별다른 소프트웨어 없이 카메라/마이크 등을 사용하여 실시간 커뮤니케이션을 제공해주는 기술 [2]

Peer to Peer 통신을 하기 위해 사용자의 IP 주소를 알아야 하는데,

대부분의 사용자는 방화벽을 사용하여 STUN/TURN 서버가 필수적이다 [1].

1. STUN 서버

: Session Traversal Utilities for NAT

두 클라이언트가 같은 네트워크에 존재하고 있을 때는 해결되지 않는다.

Symmetric NAT의 경우는 애플리케이션이 달라지면 NAT의 매핑테이블이 바뀔 수 있다.

2. TURN 서버

: Traversal Using Relays around NAT

클라이언트들이 통신할 때 Public 망에 존재하는 TURN 서버를 경유하여 통신하게 된다.

ICE의 일부로 사용될 수 있도록 디자인 되었다.

3. ICE(Interactive Connectivity Establishment)

: Client가 모든 통신 가능한 주소를 식별하는 것

1) Relayed Address: TURN 서버가 패킷 릴레이를 위해 할당하는 주소

2) Server Reflexive Address: NAT가 매핑한 클라이언트의 공인망(Public IP, Port)

3) Local Address: 클라이언트의 사설 주소(Private IP, Port)

따라서 STUN 서버는 Server Reflexive Address 만을 응답하지만 TURN 서버는 Relayed Address와 Server Reflexive Address 모두 응답한다.

4. Coturn

TURN과 STUN 프로토콜을 구현한 서버 소프트웨어

STUN 서버는 Server Reflexive Address 만을 응답

TURN 서버는 Relayed Address 와 Server Reflexive Address 모두 응답

References:

[1] WebRTC란? (STUN과 TURN 서버의 이해) (2) - https://andonekwon.tistory.com/59

[2] [WebRTC] WebRTC란 무엇일까? - https://gh402.tistory.com/38

[AWS] Route53 query logging

sarahee — Thu, 7 Aug 2025 17:14:09 +0900

AWS Route 53 resolver의 CreateResolverQueryLogConfig 시

query logs의 Destination을 bucket name으로 설정할 경우,

aws route53resolver create-resolver-query-log-config --name "log-config-name" --destination-arn "arn:aws:s3:::s3-query-logging"

S3 버킷 삭제

aws s3api delete-bucket-policy --bucket s3-query-logging

Empty bucket > permanently delete

AssociateResolverQueryLogConfig API 실행

aws route53resolver associate-resolver-query-log-config --resolver-query-log-config-id "rqlc-12aaa456fxxx4519" --resource-id "vpc-0a53xxxxxxxxx2deb"

정상 생성(Active)

{
    "ResolverQueryLogConfigAssociation": {
        "Id": "rqlca-8389713dfa194521",
        "ResolverQueryLogConfigId": "rqlc-12aaa456f7394519",
        "ResourceId": "vpc-0a535fa915c062deb",
        "Status": "CREATING",
        "Error": "NONE",
        "ErrorMessage": "",
        "CreationTime": "2025-08-07T07:06:27.873745085Z"
    }
}

VPC가 타 query log config와 연결되어 있을 경우

An error occurred (InvalidRequestException) when calling the AssociateResolverQueryLogConfig operation: [RSLVR-01306] The resource is already associated with a query logging configuration that is sending query logs to the specified destination type. Trace Id: "1-689450aa-38d4c77e583b368f14ffa282"

버킷 삭제 시(Failed)

INTERNAL_SERVICE_ERROR[RSLVR-00200] Internal Service Error, trace ID: "1-6894513d-1a1dxxxxxxxxxxxxxxxx4477"

References:

[1] AssociateResolverQueryLogConfig - Errors - https://docs.aws.amazon.com/ko_kr/Route53/latest/APIReference/API_route53resolver_AssociateResolverQueryLogConfig.html#API_route53resolver_AssociateResolverQueryLogConfig_Errors

[AWS] ALB listener server response header on|off

sarahee — Mon, 19 May 2025 17:40:01 +0900

ALB는 대상 응답에 서버 헤더가 없는 경우에만 awselb/2.0 값을 갖는 서버 헤더 정보를 추가한다.

이 때 서버 헤더를 비활성화(enabled false)할 경우, 헤더 정보를 추가하지 않도록 설정하여 awselb/2.0과 같은 서버 정보가 노출되는 것을 방지할 수 있다.

→ 자동 스캐닝 도구나 공격자가 특정 서버 소프트웨어에서 발견된 취약점을 악용하는 것을 방지한다.

while true; do 
    echo "============= $(date '+%Y-%m-%d %H:%M:%S') ============="
    curl -k -I -w "time: %{time_total}s\n" https://ALB-1234567890.us-east-1.elb.amazonaws.com
    echo "====================================================="
    sleep 1
done

ALB server response header 설정(save changes) 후 적용되기까지 10초 정도 소요

- 리스너 단위 설정, Edit listener attributes

=====================================================
============= 2025-05-19 16:50:52 =============
HTTP/2 503 
server: awselb/2.0
date: Mon, 19 May 2025 07:50:53 GMT
content-type: text/html
content-length: 162

time: 0.582316s
=====================================================
============= 2025-05-19 16:50:54 =============
HTTP/2 503 
date: Mon, 19 May 2025 07:50:55 GMT
content-type: text/html
content-length: 162

time: 0.599829s
=====================================================

true: server header on

false: server header off

aws elbv2 modify-listener-attributes \
  --listener-arn ARN \
  --attributes Key="routing.http.response.server.enabled",Value=false

References:

[1] Application Load Balancer에 대한 HTTP 헤더 수정 - 헤더 비활성화 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/header-modification.html#disable-header
[2] AWS Application Load Balancer introduces header modification for enhanced traffic control and security - https://aws.amazon.com/about-aws/whats-new/2024/11/aws-application-load-balancer-header-modification-enhanced-traffic-control-security/
[3] Securing your web applications and optimizing their performance with AWS Application Load Balancer - https://aws.amazon.com/blogs/networking-and-content-delivery/securing-your-web-applications-and-optimizing-their-performance-with-aws-application-load-balancer/?nc1=h_ls

[AWS] Direct Connect 설정

sarahee — Mon, 19 May 2025 15:09:04 +0900

DX 로케이션 경유하여 AWS와 사설 네트워크를 연결

AWS Cloud -(AWS 백본)- AWS DX location - IDC

1) DX 연결

: Connections > State: ordering > Accept

- Pending → available: 계정과 물리 연결이 활성화됨

AWS Cloud - AWS DX <-> onPrem 간 호스팅 연결 활성화

2) Direct Connect Gateway(DXGW) 생성

: Direct Connect gateways > Create > dxgw1, ASN 65011

- DXGW - AWS DX

3) DXGW에 VGW(VGW1, VGW2) 연결

: 생성한 GW ID 클릭(dxgw1) > Gateway associations - Associate > Gateways: VGW1, VGW2

(Allowed prefiexs를 입력하지 않으면 자동으로 VPC1과 VPC2의 CIDR 대역이 자동으로 할당됨, DXGW는 이렇게 허용된 접두사를 온프렘(고객 라우터)으로 전파(광고)) > 5~7분 대기(State: associated로 변경됨)

- AWS Cloud 내 VPC - VGW - DXGW 연결

4) Private VIF 생성 (on DX1/DX2)

: Virtual Interfaces > Create > 인터페이스 유형 선택, dx1-pri-v157, connection/DXGW/VLAN, ASN(65000)

+ Additional settings: user/Amazon router peer IP, BGP 인증키 입력 후 생성

- AWS DX <-> onPrem connect 간 VIF 생성

5) 온프렘 라우터 설정 (VLAN 인터페이스 및 BGP Peering 설정)

# 라우터 버전 정보 확인
show version
# 설정 모드 진입
config terminal # or conf t
# 명령어 입력(exec) 모드로 나오기
end

라우터 콘솔 명령 - 인터페이스 IP 설정

- dot1Q: IEEE 802.1Q 표준, 802.1Q VLAN 태깅을 사용하여 VLAN 157에 대한 캡슐화 설정

# (config)#
interface InterfaceEthernet1.157
# (config-subif)#
encapsulation dot1Q 157
ip address 10.0.1.1 255.255.255.252
end

show ip interface brief
sh ip int br

Interface              IP-Address      OK? Method Status                Protocol
InterfaceEthernet1       unassigned      YES NVRAM  up                    up
InterfaceEthernet1.157   10.0.1.1        YES manual up                    up

AWS 라우터까지 통신 확인

#ping 10.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

Your router peer IP: 10.0.1.1/30

Amazon router peer IP: 10.0.1.2/30

라우터에서 BGP peering 설정

- AWS console의 VIF 정보를 확인하여 BGP 설정

# AS 번호는 네트워크를 식별하는 고유 번호
# 64512-65534는 프라이빗 AS 번호 범위

# (config)#
# BGP 라우팅 프로세스 시작, 65000은 자신의 AS(Autonomous System) 번호
router bgp 65000
# (config-router)#
# BGP 피어(neighbor) 설정, 10.0.1.2: peer router의 ip 주소, 65011: 피어의 AS 번호
neighbor 10.0.1.2 remote-as 65011
neighbor 10.0.1.2 password BGPauthPW123!
# BGP로 광고할 네트워크 설정, 자신의 네트워크를 다른 AS에 알림
network 172.20.0.0 mask 255.255.0.0
end

(1) show ip bgp summary

AWS BGP peer 라우터(10.0.1.2)와 Peering이 정상적으로 이루어졌는지 확인

정상인 경우 'State/PfxRcd'에 전달받은 Prefix의 개수가 표시됨

# bgp peer(neighbor) 연결 상태
show ip bgp summary
# results
BGP router identifier 172.20.57.1, local AS number 65000
BGP table version is 4, main routing table version 4
3 network entries using 744 bytes of memory
3 path entries using 408 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1752 total bytes of memory
BGP activity 3/0 prefixes, 3/0 paths, scan interval 60 secs
3 networks peaked at 18:02:26 May 14 2025 KST (4d19h ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.1.2        4        65011   14335   15133        4    0    0 4d19h           2

(2) show ip bgp

AWS 측 라우터(10.0.1.2)로부터 전달받은 Prefix를 확인

VGW1와 VGW2에 연결된 VPC1와 VPC2의 CIDR 대역(10.1.1.0/24, 10.1.2.0/24)이 온프렘 라우터로 전파된 것 확인

# bgp로 전달 받은 경로
show ip bgp

BGP table version is 4, local router ID is 172.20.57.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.1.1.0/24      10.0.1.2                               0 65011 i
 *>   10.1.2.0/24      10.0.1.2                               0 65011 i
 *>   172.20.0.0       0.0.0.0                  0         32768 i

# 라우터에서 참조하는 라우팅 경로
show ip route

on-prem과 EC2 instance 통신 확인 (ping test)

- VPC(10.1.1.0/24) 내 EC2 인스턴스 IP 주소: 10.1.1.10

[AWS] EC2 SSM Agent connection lost

sarahee — Mon, 12 May 2025 18:21:37 +0900

SSM Agent 서비스 상태 문제

SSM Agent 서비스가 중지되었거나 충돌이 발생했을 수 있음
다음 명령어로 확인/재시작 가능:

# Amazon Linux, RHEL의 경우
sudo systemctl status amazon-ssm-agent
sudo systemctl restart amazon-ssm-agent

# 로그 확인
sudo tail -f /var/log/amazon/ssm/amazon-ssm-agent.log

# Ubuntu의 경우
sudo service amazon-ssm-agent status
sudo service amazon-ssm-agent restart

인스턴스 리소스 문제

메모리 부족이나 CPU 과부하로 인해 Agent가 제대로 작동하지 않을 수 있음
시스템 리소스 사용량 확인 필요

SSM Agent 버전 문제

Agent 버전이 오래되었거나 업데이트 중 문제가 발생했을 수 있음
최신 버전으로 재설치 시도:

sudo yum install -y amazon-ssm-agent  # Amazon Linux
sudo apt-get install amazon-ssm-agent # Ubuntu

---

System Manager

VPC 엔드포인트 사용의 대체 방법은 관리형 인스턴스에서 아웃바운드 인터넷 액세스를 허용하는 것

이 경우 관리형 인스턴스는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 한다.

ssm.region.amazonaws.com
ssmmessages.region.amazonaws.com
ec2messages.region.amazonaws.com

References

[1] Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선 - https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/setup-create-vpc.html

Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선 - AWS Systems Manager

온프레미스 방화벽을 사용하고 Patch Manager를 사용하려는 경우 해당 방화벽에서 적절한 패치 기준 엔드포인트에 대한 액세스도 허용해야 합니다.

docs.aws.amazon.com

[AWS] 실험 환경 구성#1

sarahee — Wed, 23 Apr 2025 02:01:11 +0900

개념

Mininet

네트워크 토폴로지를 하나의 컴퓨터 안에서 가상으로 생성할 수 있는 네트워크 시뮬레이터

- 실제 네트워크 장비 없이도, PC 하나만으로 가상의 호스트(PC), 스위치, 링크 등을 만들어서 실제 네트워크처럼 테스트할 수 있게 해주는 도구

- h1~h8 같은 가상 장치를 만들고, 이 장치들을 SDN 스위치에 연결해서, 네트워크 트래픽을 만들어주는 역할

Ryu

Python으로 만들어진 오픈소스 SDN 컨트롤러 프레임워크로, OpenFlow 같은 프로토콜을 통해 네트워크 장비를 제어한다.

- 네트워크의 두뇌. 예전엔 스위치가 알아서 패킷을 처리했지만, SDN에선 스위치가 먼저 컨트롤러(Ryu)에 물어보고, 그에 따라 동작

- MTD 알고리즘을 실행해서 IP 주소나 포트를 무작위로 바꾸고, 네트워크 흐름을 제어해서 스위치에 명령을 내림

Open vSwitch (OVS)

리눅스에서 돌아가는 가상 스위치 소프트웨어로, SDN 환경에서 OpenFlow 프로토콜을 지원한다.

- 실제 스위치를 쓰지 않고, 소프트웨어로 만든 스위치. 물리적인 네트워크 없이도 SDN 실험을 하기 위한 방안

- 가상 호스트들을 연결해주는 스위치 역할을 하며, Ryu 컨트롤러의 명령에 따라 패킷을 전송하거나 차단

1단계: EC2 인스턴스 생성

Amazon Machine Image (AMI): Ubuntu Server 24.04 LTS (HVM), SSD Volume Type

Instance type: t3.xlarge (4 vCPU, 16 GiB Memory)

SSD (8GiB gp3 Root volume, 3000 IOPS, Not encrypted)

- security group SSH 22 my ip / ICMP All

SSH로 EC2 접속

chmod 400 your-key.pem  # 권한 변경
ssh -i "your-key.pem" ubuntu@<EC2 퍼블릭 IPv4 주소>.compute-1.amazonaws.com

2단계: 실험 환경 설치

# 1. 필수 패키지 설치
sudo apt update
sudo apt install -y git python3-pip openvswitch-switch net-tools curl

# 2. Mininet 설치
git clone https://github.com/mininet/mininet
cd mininet

# pip3 install pycodestyle
sudo ./util/install.sh -a  # 모든 패키지 설치 옵션, 시간 소요 (3분 내외) -> Enjoy Mininet!

# or
# 핵심 패키지 설치
sudo apt update
sudo apt install -y openvswitch-switch openvswitch-common openvswitch-testcontroller \
    python3-pip python3-setuptools net-tools iproute2 curl git tcpdump

# Mininet 실행 스크립트 수동 설치
sudo make install

# Mininet 정상 동작 확인
sudo mn --test pingall

# 결과 예시:
# *** Ping: testing ping reachability
# h1 -> h2 h3 h4 ...
# *** Results: 0% dropped (28/28 received)

$ sudo mn --test pingall
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Waiting for switches to connect
s1
*** Ping: testing ping reachability
h1 -> h2
h2 -> h1
*** Results: 0% dropped (2/2 received)
*** Stopping 1 controllers
c0
*** Stopping 2 links
..
*** Stopping 1 switches
s1
*** Stopping 2 hosts
h1 h2
*** Done
completed in 5.329 seconds

# 3. Ryu 설치
pip3 install ryu

# 4. 설치 확인
mn --version   # Mininet 버전 출력
# 2.3.1b4
ryu-manager --version  # Ryu 버전 출력

3단계: 네트워크 토폴로지 구성 (Mininet)

가상 호스트 및 스위치 생성

sudo mn --controller=remote --topo=tree,depth=2,fanout=2 --switch ovsk,protocols=OpenFlow13

depth = 2 (루트 스위치 + 중간 스위치)

fanout = 4 (각 중간 스위치에 4개 호스트 연결) - 16개 호스트 생성됨

1명의 컨트롤러와 2단계 트리 구조의 스위치-호스트 네트워크를 자동으로 생성

총 8개 호스트(h1h8), 3개 스위치(s1s3) 생성

Ryu 컨트롤러는 외부에서 연결됨

$ sudo mn --controller=remote --topo=tree,depth=2,fanout=2 --switch ovsk,protocols=OpenFlow13
*** Creating network
*** Adding controller
Unable to contact the remote controller at 127.0.0.1:6653
Unable to contact the remote controller at 127.0.0.1:6633
Setting remote controller to 127.0.0.1:6653
*** Adding hosts:
h1 h2 h3 h4
*** Adding switches:
s1 s2 s3
*** Adding links:
(s1, s2) (s1, s3) (s2, h1) (s2, h2) (s3, h3) (s3, h4)
*** Configuring hosts
h1 h2 h3 h4
*** Starting controller
c0
*** Starting 3 switches
s1 s2 s3 ...
*** Starting CLI:
mininet>

Ryu 컨트롤러용 기본 코드 (simple_switch_13 + MTD 기능)

/home/ubuntu/
└── ryu-apps/
    ├── mtd_controller.py
    ├── myfirewall.py
    └── other_apps.py

mtd_controller.py

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER, set_ev_cls
from ryu.ofproto import ofproto_v1_3
from ryu.lib.packet import packet, ethernet, ipv4
from ryu.controller.handler import HANDSHAKE_DISPATCHER
import random
import time
import threading

class SimpleMTD(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleMTD, self).__init__(*args, **kwargs)
        self.mac_to_port = {}
        self.ip_pool = ["10.0.0." + str(i) for i in range(1, 10)]
        self.ip_map = {}
        self.mtd_interval = 30  # 매 30초마다 IP 변경
        threading.Thread(target=self.ip_randomizer).start()

    def ip_randomizer(self):
        while True:
            time.sleep(self.mtd_interval)
            self.logger.info("MTD: 무작위 IP 재할당 시작")
            self.ip_map = {}  # 기존 맵 제거
            for host_id in range(1, 9):
                self.ip_map[f"h{host_id}"] = random.choice(self.ip_pool)
            self.logger.info(f"새로운 IP 매핑: {self.ip_map}")

    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

    def add_flow(self, datapath, priority, match, actions):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             actions)]
        mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
                                 match=match, instructions=inst)
        datapath.send_msg(mod)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        in_port = msg.match['in_port']
        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocols(ethernet.ethernet)[0]

        dst = eth.dst
        src = eth.src

        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.mac_to_port[dpid][src] = in_port
        out_port = self.mac_to_port[dpid].get(dst, ofproto.OFPP_FLOOD)

        actions = [parser.OFPActionOutput(out_port)]

        # 흐름 추가
        match = parser.OFPMatch(in_port=in_port, eth_dst=dst, eth_src=src)
        self.add_flow(datapath, 1, match, actions)

        # 패킷 전송
        out = parser.OFPPacketOut(datapath=datapath,
                                  buffer_id=msg.buffer_id,
                                  in_port=in_port,
                                  actions=actions,
                                  data=msg.data)
        datapath.send_msg(out)

기본적인 스위칭 기능을 하면서, 30초마다 호스트 IP를 무작위로 바꾸는 역할

실시간 IP 변경은 단순히 로그로 표시되고, 실제 호스트 IP를 바꾸지는 않음

4단계: Ryu 실행

ryu-manager mtd_controller.py

# eventlet 라이브러리의 ALREADY_HANDLED를 불러올 수 없을 경우에는, eventlet 버전 다운그레이드

pip install eventlet==0.30.2

# ryu를 찾을 수 없는 경우
pip install ryu "eventlet<0.31"

# 호환성 문제 (실험 환경: Python 3.8, eventlet 0.30.x)

# Python 3.8 설치
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install -y python3.8 python3.8-venv python3.8-dev

# Ryu용 가상환경 생성
python3.8 -m venv ~/ryu-env
source ~/ryu-env/bin/activate

# 필요한 패키지 설치
pip install --upgrade pip
pip install ryu==4.34 eventlet==0.30.2
# eventlet==0.30.2는 Python 3.8 환경에서 Ryu와 안정적으로 호환됨

# 가상환경 만들기
python3.8 -m venv ryu-env
source ryu-env/bin/activate
# prompt: (ryu-env) ubuntu@ip-...:~$

# (가상환경 내) Ryu, eventlet 설치
pip install --upgrade pip
pip install ryu==4.34 eventlet==0.30.2 six==1.16.0

# 안될 경우,
git clone https://github.com/faucetsdn/ryu.git
cd ryu
git checkout tags/v4.34 -b v4.34

pip install setuptools==59.5.0
pip install . --no-use-pep517

# 현재 디렉토리 등록
echo "export PYTHONPATH=." >> ~/ryu-apps/ryu-env/bin/activate

# 재실행
ryu-manager mtd_controller.py

# 버전 오류 시

# 1. pip, setuptools, wheel 다운그레이드
pip install --upgrade pip
pip install "setuptools==56.0.0" "wheel==0.36.2"

# 2. 안정적인 조합 설치
pip install "ryu==4.30" "eventlet==0.30.2"

$ python --version		# Python 3.8.20
$ pip show ryu			# Version: 4.30
$ pip show setuptools		# Version: 56.0.0
$ pip show eventlet		# Version: 0.30.2

5단계: 실험 진행

# RTT 측정
mininet> h1 ping h2

# 정찰 공격 시뮬레이션
mininet> h3 nmap -sP 10.0.0.0/24

실제 IP 변경은 iptables NAT 규칙으로 시뮬레이션 가능
실제 SCADA/PLC 장비 대신 Modbus 시뮬레이터 (ex. mbtget)로 구성 가능

mininet> h1 ping -c 10 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.059 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.053 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.053 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.060 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.054 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=0.058 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=0.052 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=0.055 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=0.053 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=0.062 ms

--- 10.0.0.2 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9205ms
rtt min/avg/max/mdev = 0.052/0.055/0.062/0.003 ms

mininet> h3 nmap -sP 10.0.0.0/24
Starting Nmap 7.80 (
https://nmap.org
) at 2025-04-22 13:52 UTC
Nmap scan report for 10.0.0.1
Host is up (0.022s latency).
MAC Address: 56:DF:00:DC:C1:17 (Unknown)
Nmap scan report for 10.0.0.2
Host is up (0.020s latency).
MAC Address: E2:2C:BE:AF:84:BD (Unknown)
Nmap scan report for 10.0.0.4
Host is up (0.014s latency).
MAC Address: 92:A7:6C:25:F8:8B (Unknown)
Nmap scan report for 10.0.0.3
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 27.95 seconds

BIND server 구성

sarahee — Thu, 17 Apr 2025 15:58:56 +0900

DNS 서버(BIND) 구축 방법

1. BIND 설치

- BIND (Berkeley Internet Name Domain)

# 설치
yum -y install bind bind-chroot bind-utils

2. 기본 설정 파일 수정 (/etc/named.conf)

# named.conf 수정
sudo vi /etc/named.conf

options {
        listen-on port 53 { any; };  # fixed
        listen-on-v6 port 53 { none; };  # or default (::1;)
        directory       "/var/named";
        dump-file      "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { any; };  # fixed
        recursion yes;
        
        dnssec-validation auto;
        auth-nxdomain no;  # fixed
};

요청한 도메인이 존재하지 않을 때 반환하는 DNS 코드 - no: RFC 표준 준수 (권장)

3. zone 파일 생성

# /var/named/example.com.zone 생성
sudo vi /var/named/example.com.zone

$TTL    86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023011001      ; Serial
                        3600            ; Refresh
                        1800            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      A       192.168.1.10
ns1     IN      A       192.168.1.10
www     IN      A       192.168.1.20

4. zone 설정을 named.conf에 추가

# /etc/named.conf에 추가
zone "example.com" IN {
        type master;
        file "example.com.zone";
        allow-update { none; };
};

5. 권한 및 소유권 설정

sudo chown root:named /var/named/example.com.zone
sudo chmod 640 /var/named/example.com.zone

6. 서비스 시작 및 자동 시작 설정

# 문법 체크
sudo named-checkconf
sudo named-checkzone example.com /var/named/example.com.zone
# - zone example.com/IN: loaded serial 2023011001
# - OK

# 서비스 시작
sudo systemctl start named
sudo systemctl enable named
# - reated symlink /etc/systemd/system/multi-user.target.wants/named.service → /usr/lib/systemd/system/named.service.
sudo systemctl status named

7. 방화벽 설정

    # firewalld 사용시
sudo firewall-cmd --permanent --add-port=53/tcp
sudo firewall-cmd --permanent --add-port=53/udp
sudo firewall-cmd --reload

# iptables 사용시
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 53 -j ACCEPT

8. 테스트

    # 로컬 테스트
dig @localhost example.com

# 특정 레코드 조회
dig www.example.com @localhost

# 결과

$ dig @localhost example.com

; <<>> DiG 9.18.33 <<>> @localhost example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45673
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a2fd5717dacbb8b201000000680b4c743807764a3f2cf3a6 (good)
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       192.168.1.10

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri Apr 25 08:48:52 UTC 2025
;; MSG SIZE  rcvd: 84

$ dig @localhost www.example.com

; <<>> DiG 9.18.33 <<>>
http://www.example.com
@localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e731811333abbe1101000000680b4ca5b60e5eccc01d1049 (good)
;; QUESTION SECTION:
;
http://www.example.com.
IN      A

;; ANSWER SECTION:
http://www.example.com.
86400   IN      A       192.168.1.20

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri Apr 25 08:49:41 UTC 2025
;; MSG SIZE  rcvd: 88

[AWS] 사설 인증서 생성 및 등록

sarahee — Wed, 16 Apr 2025 11:31:27 +0900

1. 사설 인증서 생성 (OpenSSL 사용)

# 1. 개인키(private key) 생성
openssl genrsa -out private.key 2048

# 2. CSR(Certificate Signing Request) 생성
openssl req -new -key private.key -out csr.pem

# 3. 자체 서명된 인증서 생성 (유효기간 365일)
openssl x509 -req -days 365 -in csr.pem -signkey private.key -out certificate.crt

2. AWS Certificate Manager(ACM)에 사설 인증서 가져오기

# 1. 인증서 체인 파일 생성 (certificate.crt 내용 복사)
cat certificate.crt > chain.pem

AWS Certificate Manager console 접속

Import certificate

Certificate details

Certificate body

certificate.crt 내용 붙여넣기

Certificate private key

프라이빗 키: private.key 내용 붙여넣기

Certificate chain - optionalInfo

인증서 체인: chain.pem 내용 붙여넣기

Import certificate

3. ALB에 인증서 등록

AWS Console에서:

EC2 > Load Balancers
대상 ALB 선택
"리스너" 탭 선택
HTTPS 리스너 추가 또는 수정
- 프로토콜: HTTPS
- 포트: 443
- 기본 작업: 대상 그룹 선택
- 보안 정책: ELBSecurityPolicy-2016-08 (권장)
- 인증서: 방금 가져온 사설 인증서 선택

CLI를 이용한 ALB 인증서 등록:

# 인증서 ARN 확인
aws acm list-certificates

# ALB 리스너에 인증서 추가
aws elbv2 add-listener-certificates \
    --listener-arn [리스너-ARN] \
    --certificates CertificateArn=[인증서-ARN]

# 인증서 정보 확인
openssl x509 -in certificate.crt -text -noout

# HTTPS 연결 테스트
curl -v https://saraheee.site

[AWS] Create an IPAM pool with accounts in an organization

sarahee — Thu, 10 Apr 2025 14:18:08 +0900

1. AWS Organizations structure 생성

2. Amazon VPC IP Address Manager console

- Planning > Organization settings > choose Delegate

Your IPAM is not discovering your organiziation's resources. For IPAM to discover resources in your entire organization you must delegate an account in your organization as the IPAM administrator. You cannot delegate the organization management account as the IPAM administrator.

3. IPAM 생성

4. IPAM 풀 생성

최상위 - 리전 - 사전 프로덕션 개발 풀

5. IPAM 풀 공유

- Resource Access Manager console - Settings > Enable sharing with AWS Organizations

- Amazon VPC IP Address Manager console - (Planning) Pools > choose Name (Pool ID) > Resource sharing > Create resource share

> Create resource share

> Select resource type: IPAM Pools

> Principals: Allow sharing only within your organization, select principal type: Organizational unit (OU)

References:

[1] Tutorial: Create an IPAM and pools using the console - https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-get-started-console.html

Tutorial: Create an IPAM and pools using the console - Amazon Virtual Private Cloud

For the purposes of this tutorial, the instructions will tell you to name IPAM resources in a particular way, create IPAM resources in specific Regions, and use specific IP address CIDR ranges for your pools. This is intended to streamline the choices avai

docs.aws.amazon.com

[AWS] VPC - IP Address Manager

sarahee — Tue, 11 Mar 2025 14:52:25 +0900

ALB는 수신하는 트래픽 처리를 위해 Scaling 동작을 수행하며 ALB 서비스 도메인에 대한 IP 주소가 동적으로 변경된다 [1].

1) Global Accelerator를 사용하면 고정 IP 확보는 가능하나 비용 효율적이지 않다 [2].

Global Accelerator 생성 시 기본적으로 2개의 고정 IP가 자동으로 할당된다. ALB를 엔드포인트로 추가하여 Global Accelerator의 두 고정 IP를 통해 ALB로 트래픽이 전달되도록 설정하실 수 있다.

2) ALB 앞 NLB를 사용하여 NLB의 대상으로 ALB를 연결할 수 있도록 배치하여 고정 IP를 사용하는 것과 동일한 효과를 얻을 수 있다 [3].

1), 2) 상세 내역 [4]

3) 2025-03-07 업데이트된 내역을 통해,
ALB가 IPAM과의 통합을 통해 ALB 노드에 IP 주소 할당을 위한 Public IPv4 주소 풀을 제공할 수 있게 되었다.
고객 소유의 BYOIPs (Bring Your Own IP addresses) 또는 Amazon에서 제공하는 인접한 IPv4 주소 블록으로 구성할 수 있는 공용 VPC IP Address Manager (IPAM) 풀을 구성할 수 있다.
이 때 ALB의 IP 주소는 IPAM 풀에서 소싱되며, 혹여 공용 IPAM 풀이 고갈되면 자동으로 AWS 관리형 IP 주소로 전환된다.

nslookup
> ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Server:		10.148.65.xx
Address:	10.148.65.xx#53

Non-authoritative answer:
Name:	ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Address: 18.97.9.137
Name:	ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Address: 18.97.9.177
>

참고 사항으로, ELB 서비스가 사용하는 공인 IP는 하기 링크의 ip-ranges.json 파일에서 확인 가능하다.
us-east-1 리전에 ELB가 있는 경우, 서비스=EC2, 지역=us-east-1인 IP 주소 범위를 찾아 화이트리스트에 추가해야 한다.

(하지만 서비스가 지속적으로 성장하고 확장함에 따라 ip-ranges.json 파일도 변경될 수 있다.)

https://ip-ranges.amazonaws.com/ip-ranges.json

References:

[1] Application Load Balancers - 가용 영역 서브넷 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/application-load-balancers.html#availability-zones

[2] AWS Global Accelerator 구성 요소 - https://docs.aws.amazon.com/ko_kr/global-accelerator/latest/dg/introduction-components.html

[3] Network Load Balancer의 대상으로 Application Load Balancer 사용 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/network/application-load-balancer-target.html

[4] 애플리케이션 로드 밸런서(ALB)에 고정 IP 주소 설정 및 사용하기 - https://aws.amazon.com/ko/blogs/korea/using-static-ip-addresses-for-application-load-balancers/

[5] Application Load Balancer announces integration with Amazon VPC IPAM - https://aws.amazon.com/about-aws/whats-new/2025/03/application-load-balancer-integration-vpc-ipam/

[6] Blog: VPC IPAM을 사용하여 Application Load Balancer 고정 IP 사용하기 - https://zigispace.net/1320

[AWS] ANS-C01#01. Route 53 Resolvers - Setting up VPN (1/3)

sarahee — Fri, 21 Feb 2025 23:19:15 +0900

Route53 Hybrid DNS

1. VPC 생성

- cloud: 10.0.0.0/16

- onprem: 192.168.0.0/16

- subnets, route tables, nat gateways 생성

2. 인스턴스 생성

cloud-app-server

- sg: ssh anywhere, icmp 192.168.0.0/16

onprem-app-server

- sg: ssh 192.168.0.0/16, icmp 10.0.0.0/16

onprem-vpn-server

- sg: ssh anywhere, dns (udp) 192.168.0.0/16, icmp 192.168.0.0/16

3. VPN 설정

1) Virtual private gateway (cloud-vgw)

2) Customer gateways (onprem-cgw) - onprem-vpn-server의 public IP address (Specify the IP address for your customer gateway device's external interface.)

3) VGW - attach to VPC: cloud-vpc

4) Site-to-Site VPN connections (cloud-onprem-vpn-connection)

- Routing options: Static

- Static IP prefixes: 192.168.0.0/16 (onprem-vpn range)

5) download VPN connections configurations - Platform: Openswan

4. SSH 접속

brew install putty
putty

Auth - Credentials - keypair.pem 경로

Session - Saved Sessions

IP: onprem-vpn-server's public IP

ssh -i "ap-south-1-keypair.pem" ec2-user@35.x.x.x

 % sudo su
sh-3.2# ssh -i "ap-south-1-keypair.pem" ec2-user@35.154.187.78
The authenticity of host '35.x.x.x (35.x.x.x)' can't be established.
ED25519 key fingerprint is SHA256:qOx9yHXTxD6xaC9BfiT/Y5/82Ml/mVZzr5hNXnw9FQ8.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '35.x.x.x' (ED25519) to the list of known hosts.
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-192-168-0-220 ~]$

sudo yum install libreswan
sudo vi /etc/sysctl.conf

1) Open /etc/sysctl.conf and ensure that its values match the following:
   net.ipv4.ip_forward = 1
   net.ipv4.conf.default.rp_filter = 0
   net.ipv4.conf.default.accept_source_route = 0

2) Apply the changes in step 1 by executing the command 'sysctl -p'

sudo sysctl -p

3) Open /etc/ipsec.conf and look for the line below. Ensure that the # in front of the line has been removed, then save and exit the file.
#include /etc/ipsec.d/*.conf

이미 제거된 상태로 저장됨

cat /etc/ipsec.conf

4) Create a new file at /etc/ipsec.d/aws.conf if doesn't already exist, and then open it. Append the following configuration to the end in the file:
#leftsubnet= is the local network behind your openswan server, and you will need to replace the <LOCAL NETWORK> below with this value (don't include the brackets). If you have multiple subnets, you can use 0.0.0.0/0 instead.
#rightsubnet= is the remote network on the other side of your VPN tunnel that you wish to have connectivity with, and you will need to replace <REMOTE NETWORK> with this value (don't include brackets).

conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=35.x.x.x
right=13.x.x.x
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=<LOCAL NETWORK>
rightsubnet=<REMOTE NETWORK>
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer

sudo vi /etc/ipsec.d/aws.conf

conn Tunnel1
        authby=secret
        auto=start
        left=%defaultroute
        leftid=35.x.x.x
        right=13.x.x.x
        type=tunnel
        ikelifetime=8h
        keylife=1h
        phase2alg=aes256-sha1;modp2048
        ike=aes256-sha1;modp2048
        keyingtries=%forever
        keyexchange=ike
        leftsubnet=192.168.0.0/16
        rightsubnet=10.0.0.0/16
        dpddelay=10
        dpdtimeout=30
        dpdaction=restart_by_peer

5) Create a new file at /etc/ipsec.d/aws.secrets if it doesn't already exist, and append this line to the file (be mindful of the spacing!):
35.x.x.x 13.x.x.x: PSK "TOC3RK--------------------IUtns"

sudo vi /etc/ipsec.d/aws.secrets

Tunnel 1 구성 완료

sudo systemctl start ipsec.service
sudo systemctl status ipsec.service

5. Route Tables 설정 (propagation)

cloud-vpc-private-rt > Route propagation > Propagation: Enable

또는 Routes 편집 (cloud-vgw)

cloud-vpc-public-rt도 동일하게 설정

6. VPN 서버의 목적지 비활성화

Instances: onprem-vpn-server > Actions - Networking - Change Source / destination check > check Stop > Save

Route tables: cloud-vpc-public-rt > 10.0.0.0/16 instance (onprem-vpn-server)

7. Cloud Instance 접속

cloud-app-server public IP

ssh -i "ap-south-1-keypair.pem" ec2-user@3.x.x.x

ping (onprem-app-server)

From Cloud EC2 instance - Ping to on-premises App server private IP

Cloud EC2 -> VGW -> VPN Tunnel 1 -> VPN server -> App server

[AWS] Route53 Domain hosted zones name server updates

sarahee — Wed, 19 Feb 2025 10:38:01 +0900

도메인 등록을 위한 DNS 서비스를 변경하고 싶은 경우 퍼블릭 호스팅 영역의 이름 서버를 가져온다.

1) Route 53 console의 Hosted zones 내비게이션 바 클릭 > Hosted zone name 클릭

2) Hosted zone details의 Name servers 4개 저장

3) Route 53 console의 Domains - Registered domains 내비게이션 바 클릭

4) Actions - Edit name servers

5) 2)에서 저장한 name servers 입력 후 저장

[1] 퍼블릭 호스팅 영역에 대한 이름 서버 가져오기 - https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/GetInfoAboutHostedZone.html

[AWS] VPC - Basic docs

sarahee — Mon, 10 Feb 2025 14:03:20 +0900

1. AWS VPC

VPC를 사용하면 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하다.

서브넷: VPC의 IP 주소 범위, 단일 가용 영역에 상주

라우팅: 라우팅 테이블을 사용해서 서브넷 또는 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정

게이트웨이 및 엔드포인트: 게이트웨이는 VPC를 다른 네트워크에 연결, 인터넷 게이트웨이를 사용하여 VPC를 인터넷에 연결

피어링 연결: VPC 피어링 연결을 사용하여 두 VPC의 리소스 간 트래픽을 라우팅

VPC 흐름 로그: VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처

2. Security in VPC

보안 그룹: 리소스 수준(예: EC2 인스턴스)에서 특정 인바운드 및 아웃바운드 트래픽을 허용, 인스턴스를 시작할 때 하나 이상의 보안 그룹과 연결할 수 있다. VPC의 각 인스턴스는 서로 다른 보안 그룹 세트에 속할 수 있다.

네트워크 액세스 제어 목록(ACL): 네트워크 ACL은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부한다.

흐름 로그: VPC의 네트워크 인터페이스에서 양방향으로 이동하는 IP 트래픽에 대한 정보를 캡처한다. VPC, 서브넷 또는 개별 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있다.

흐름 로그 데이터는 CloudWatch logs 또는 Amazon S3에 게시되며 과도하게 제한하거나 과도하게 허용하는 보안 그룹과 네트워크 ACL 규칙을 진단하는 데 도움이 된다.

트래픽 미러링: Amazon EC2 인스턴스의 탄력적 네트워크 인터페이스에서 네트워크 트래픽을 복사할 수 있다.

3. VPC Peering

VPC는 사용자의 AWS 계정 전용 가상 네트워크이다. AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다.

VPC 피어링 연결은 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워크 연결이다.

동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신할 수 있다. 사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있으며, VPC는 상이한 리전에 있을 수 있다.

VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성한다. 이는 게이트웨이도, VPN 연결도 아니며 물리적 하드웨어 각각에 의존하지 않는다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없다.

4. VPC Flowlogs

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능이다. 흐름 로그 데이터가 게시될 수 있는 위치는 Amazon CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose이다.

흐름 로그를 생성하면 구성한 로그 그룹, 버킷 또는 전송 스트림의 흐름 로그 레코드를 검색하고 볼 수 있다.

5. VPC PrivateLink

VPC에 인터넷 게이트웨이를 추가하여 인터넷 액세스를 허용하거나 VPN 연결을 추가하여 온프레미스 네트워크 액세스를 허용할 수 있다.

VPC의 클라이언트가 프라이빗 IP 주소를 사용하여 다른 VPCs의 서비스 및 리소스에 연결할 수 있도록 AWS PrivateLink 하려면 해당 서비스 및 리소스가 VPC에서 직접 호스팅된 것처럼 사용한다.

6. NAT Instance

NAT 인스턴스는 Network Address Translation(NAT)을 제공한다. NAT 인스턴스를 사용하면 프라이빗 서브넷의 리소스가 인터넷이나 온프레미스 네트워크와 같은 VPC 외부의 대상과 통신할 수 있다. 프라이빗 서브넷의 리소스는 인터넷으로 향하는 아웃바운드 IPv4 트래픽을 시작할 수 있지만 인터넷에서 시작된 인바운드 트래픽을 수신할 수는 없다.

NAT 인스턴스는 퍼블릭 인터넷에 있어야 하며, NAT 인스턴스에는 퍼블릭 IP 주소 또는 탄력적 IP 주소가 있어야 한다.

7. NAT Gateway

NAT 게이트웨이는 NAT 서비스로, 프라이빗 서브넷의 인스턴스가 VPC 외부의 서브넷에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

퍼블릭 - (기본값) 퍼블릭 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 이지만 인터넷에서 원치 않는 연결을 수신할 수 없다. 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 한다.

프라이빗 - 프라이빗 서브넷 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다.

8. IPv6 migration

IPv4만을 지원하는 기존 VPC와 서브넷에서 IPv4만을 사용하도록 구성된 리소스가 있으면 VPC 및 리소스에 대한 IPv6 지원을 추가할 수 있다.

References:

1. AWS VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html

2. Security in VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
3. VPC Peering - http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html
4. VPC Flowlogs - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html
5. VPC PrivateLink - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html
6. NAT Instance - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html
7. NAT Gateway - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html
8. IPv6 migration - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html

[Route53] name servers

sarahee — Fri, 7 Feb 2025 17:40:47 +0900

특정 도메인을 담당하는 적절한 네임 서버로 DNS 쿼리를 전달하는 과정에서 DNS 쿼리를 해결하는 데 필수적인 권한 있는 네임 서버의 이름을 확인하기 위해 NS(네임 서버) 레코드를 참조한다.
이 특정 도메인에 대한 권한은 다른 네임 서버에 위임할 때 도메인의 권한 있는 네임 서버(실제 DNS 레코드를 갖고 있는 서버)인지 확인하기 위해 필요하며,
해당 도메인이 신뢰할 수 있는지 확인하기 위해 각 도메인마다 DNS 레코드 관리를 담당하는 네임 서버가 존재한다.

예를 들어, 아래와 같이 'example.com'에서 레코드명 'sub.example.com'의 NS 레코드가 생성된 상태에서, 권한 있는 'sub.example.com' 도메인의 호스팅 영역을 찾기 위해 네임 서버가 아래와 같은 'sub.example.com' 호스팅 영역을 조회한다.

이 때, 하위 도메인 'sub.example.com'에 대한 네임 서버 변경이 가능한 경우 도메인의 고유한 권한을 확인할 수 없으므로, 상위 도메인 'example.com'의 'sub.example.com'에 대한 NS 레코드를 일치시켜야 한다.

References:

DNS에서 NS(이름 서버) 레코드의 기능은 무엇입니까? - https://ko.eitca.org/cybersecurity/eitc-is-wsa-windows-server-administration/system-administration-in-windows-server/resource-record-types/examination-review-resource-record-types/what-is-the-function-of-a-name-server-ns-record-in-dns/

DNS에서 NS(이름 서버) 레코드의 기능은 무엇입니까? - EITCA 아카데미

NS(이름 서버) 레코드는 Windows Server 관리에 사용되는 DNS(Domain Name System)의 중요한 구성 요소입니다. 이는 도메인 이름의 전반적인 관리 및 확인에서 특정 기능을 제공합니다. 이러한 맥락에서 NS

ko.eitca.org

[essential#03] Wireshark

sarahee — Fri, 7 Feb 2025 15:20:19 +0900

Capturing Traffic

$ sudo tcpdump -i eth0 -nn -s0 -v port 80

-i eth0: eth0 인터페이스에서 패킷 캡처

-nn: 호스트명, 포트 번호를 DNS 리졸빙하지 않고 숫자로 표시

-s0: 패킷의 전체 내용을 캡처 (스냅샷 길이 제한 없음)

-v: 상세 출력 모드

port 80: HTTP 트래픽(80번 포트)만 캡처

$ sudo tcpdump -i eth0 -s0 -w test.pcap

-i eth0: eth0 인터페이스에서 패킷 캡처

-s0: 패킷의 전체 내용 캡처

-w test.pcap: 캡처한 패킷을 test.pcap 파일로 저장

$ sudo tcpdump -i eth0 -w /var/tmp/rotate.pcap -W 3 -C 10 -s 150 &

-i eth0: eth0 인터페이스에서 패킷 캡처

-w /var/tmp/rotate.pcap: 캡처 파일 저장 경로

-W 3: 최대 3개의 파일로 순환 저장

-C 10: 각 캡처 파일 크기를 10MB로 제한

-s 150: 각 패킷당 캡처할 바이트 수를 150으로 제한

&: 백그라운드에서 실행

터미널에서 pcap 내용 조회

tcpdump -r test.pcap -v

Create and Applying Filters

Statistics > Conversations - DisplayFilters

필터링하고 싶은 패킷 - Prepare as Filter

A → B 클릭 시

> ip.src==10.40.7.87 && tcp.srcport==58690 && ip.dst==17.57.145.151 && tcp.dstport==5223

Advanced Feature Color Traffic

View > Coloring Rules...

Decode

패킷 우측 Decode As..: Wireshark에서 패킷을 다른 프로토콜로 강제 해석(디코딩)하도록 하는 기능

- 비표준 포트 사용 시 (예: HTTP가 기본 80 포트가 아닌 8080 포트를 사용할 때)

Expert Information

Analyze > Expert Information

네트워크 트래픽을 분석하여 잠재적인 문제나 이상 징후를 감지

- Error (빨간색): 심각한 문제, TCP 재전송, 손상된 체크섬 등

- Warning (노란색): 잠재적 문제, TCP 윈도우 크기 0, 중복 ACK 등

- Note (파란색): 비정상적이지만 문제는 아닌 상황, TCP 윈도우 업데이트, 비표준 포트 사용 등

- Chat (회색): 일반적인 정보, TCP 연결 시작/종료 등

Interpret TCP Graphs

Statistics > I/O Graphs

시간에 따른 네트워크 트래픽을 그래프로 시각화하는 도구

Statistics > TCP Stream Graphs > Throughput

TCP 연결의 처리량을 시각화하여 보여주는 도구

Window Scaling

Win=1024

[AWS] VPC DNS resolver 우선 순위

sarahee — Thu, 6 Feb 2025 16:22:04 +0900

VPC DNS resolver 우선 순위

0. DNS firewall (R53 전용 Network Firewall)

1. Route 53 Resolver 규칙
- 명시적으로 정의된 Outbound 규칙
- 도메인 기반 포워딩 규칙

2. Private Hosted Zone
- VPC와 연결된 프라이빗 호스팅 영역

$ dig example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.9 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63355
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; AUTHORITY SECTION:
saraheee.site.          900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Thu Feb 06 07:15:42 UTC 2025
;; MSG SIZE  rcvd: 129

3. Default VPC Resolver
- VPC의 기본 .2 리졸버

$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search anycompany.corp
nameserver 192.168.2.250
nameserver 192.168.0.2

4. Public DNS resolve 시도 (Route 53 Public Hosted Zone 포함)

$ dig example.com
; <<>> DiG 9.18.28 <<>> example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; ANSWER SECTION:
saraheee.site.          30      IN      A       8.8.8.8

;; Query time: 1610 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Feb 06 07:15:47 UTC 2025;; MSG SIZE  rcvd: 58

아웃바운드 엔드포인트가 구성된 Resolver 규칙이 있는 경우, 프라이빗 호스팅 영역과 동일한 VPC에 연결되어 있을 때 리졸버 규칙이 우선적으로 적용될 수 있다.

다만 Private hosted zone이 VPC 내부에서만 작동하는 DNS라, dig +trace 시 공개적인 DNS 해석 과정이 포함된 root DNS와는 독립적으로 작동한다.

규칙이 동일한 도메인 수준에 있다면, 해당 규칙의 우선 순위는 다음과 같습니다.

Resolver 규칙
프라이빗 호스팅 영역
내부 규칙

References:

[1] Route 53 프라이빗 호스팅 영역의 DNS 확인 문제를 해결하려면 어떻게 해야 하나요? - https://repost.aws/ko/knowledge-center/route-53-fix-dns-resolution-private-zone

Route 53 프라이빗 호스팅 영역 DNS 확인 문제 해결

Amazon Route 53 프라이빗 호스팅 영역의 DNS 확인 문제를 해결하고 싶습니다.

repost.aws

[essentials#02] Telnet

sarahee — Thu, 6 Feb 2025 13:50:08 +0900

# 최대 홉 수 조정

traceroute -m 255 google.com

$ traceroute -m 255 google.com         
traceroute to google.com (172.217.161.206), 255 hops max, 40 byte packets
 1  10.40.6.2 (10.40.6.2)  9.359 ms  4.503 ms  4.032 ms
 2  10.40.240.0 (10.40.240.0)  4.312 ms  7.856 ms  4.707 ms
 3  10.40.0.11 (10.40.0.11)  7.454 ms  4.417 ms  5.650 ms
 4  10.128.2.139 (10.128.2.139)  6.526 ms  4.745 ms  6.370 ms
 5  15.248.4.57 (15.248.4.57)  8.095 ms  7.118 ms  5.761 ms
 6  * * *
 7  * * *
 8  * * *
 9  99.82.179.80 (99.82.179.80)  33.133 ms  33.374 ms  33.518 ms
10  99.82.179.81 (99.82.179.81)  34.269 ms  33.815 ms
    99.82.179.83 (99.82.179.83)  30.787 ms
11  192.178.108.209 (192.178.108.209)  35.272 ms  34.049 ms
    216.239.59.149 (216.239.59.149)  27.305 ms
12  108.170.235.5 (108.170.235.5)  34.331 ms
    108.170.235.7 (108.170.235.7)  38.985 ms
    108.170.235.5 (108.170.235.5)  34.198 ms
13  kix07s03-in-f14.1e100.net (172.217.161.206)  33.920 ms  33.770 ms  33.259 ms

# 패킷 크기 조정

traceroute google.com 70

$ traceroute google.com 70
traceroute to google.com (172.217.161.206), 64 hops max, 70 byte packets
 1  10.40.6.2 (10.40.6.2)  11.566 ms  5.021 ms  5.796 ms
...

# 패킷 테스트 횟수 조정

traceroute -q1 google.com

$ traceroute -q1 google.com
traceroute to google.com (172.217.161.206), 64 hops max, 40 byte packets
 1  10.40.6.2 (10.40.6.2)  5.512 ms
...

# DNS 역방향 조회 건너뛰기

traceroute -n google.com

$  traceroute -n google.com
traceroute to google.com (172.217.161.206), 64 hops max, 40 byte packets
 1  10.40.6.2  7.717 ms  2.673 ms  3.887 ms
 2  10.40.240.0  5.463 ms  2.376 ms  3.898 ms
 3  10.40.0.11  4.332 ms  6.298 ms  4.902 ms
 4  10.128.2.139  4.251 ms  5.431 ms  3.800 ms
 5  15.248.4.57  7.327 ms  6.855 ms  5.558 ms
 6  * * *
 7  * * *
 8  * * *
 9  99.82.179.82  28.092 ms  28.069 ms
    99.82.179.80  33.980 ms
10  99.82.179.81  33.186 ms
    99.82.179.83  29.556 ms
    99.82.179.81  32.288 ms
11  192.178.108.209  36.233 ms
    216.239.59.149  27.248 ms
    192.178.110.61  27.490 ms
12  108.170.235.7  35.891 ms
    108.170.235.5  35.220 ms
    108.170.235.7  34.109 ms
13  172.217.161.206  33.306 ms  34.519 ms  32.720 ms

format:

hop_number host_name (IP_address) packet_round_trip_times

hop_number: 경유 순서

host_name: 호스트 이름 (역방향 조회 결과)

IP_address: IP 주소

packet_round_trip_times: 왕복 시간 (기본 3회 측정)

asterisks (*): 경로상 문제가 없음을 의미

Tutorial: Troubleshooting with Traceroute

https://www.youtube.com/watch?v=WL0ZTcfSvB4

How To Use Traceroute and MTR to Diagnose Network Issues

https://www.digitalocean.com/community/tutorials/how-to-use-traceroute-and-mtr-to-diagnose-network-issues

$ mtr google.com

$ mtr --report google.com

[essentials#01] Server-Client communication using Netcat

sarahee — Thu, 6 Feb 2025 11:14:37 +0900

Layer 4: https://www.youtube.com/playlist?list=PLelEzczSdJkCukp60g0DOGr7aruKyS6Rs
Layer 5:
why TLS and SSL - https://www.youtube.com/watch?v=SJJmoDZ3il8
How the negotiation works - https://www.youtube.com/watch?v=n_d1rCXNrx0
RE:Invent talk about TLS - https://www.youtube.com/watch?v=8AODa_AazY4

1. Connection

1. run in the server mode

nc -l 2389

서버가 2389 포트에서 연결 대기 시작

-l: 리스닝 모드로 실행

2. used in client mode

nc localhost 2389

클라이언트가 서버의 2389 포트로 연결 시도, localhost (or 서버IP)

서버IP 확인

# private ip
ifconfig
ip addr

# public ip
curl ifconfig.me
wget -q0- ifconfig.me
(whatismyip.com)

# ipv6
curl -6 ifconfig.me

3. 통신 테스트

# at client side
HI, server
# displayed at server side
HI, server

클라이언트가 메시지 전송, 서버 측에서 동일한 메시지 수신 확인

특징: 양방향 통신, 텍스트 기반, 간단한 소켓 통신 테스트에 유용, 실시간 메시지 전송/수신

2. File Transfer

1. initial setup

# client side - Create source file
$ echo "hello test" > testfile
$ cat testfile
hello test

# server side - Empty destination file
$ touch test

클라이언트 측 testfile이라는 파일이 있고, 내용은 hello test

서버 측 빈 test 파일이 존재

수신된 데이터를 test 파일로 리다이렉션, 서버 측의 test 파일에서는 클라이언트가 보낸 "hello test" 내용이 저장됨

3. Timeout

-w 플래그를 통해 연결 타임아웃을 설정할 수 있음

# server side
nc -l 2389

# client side
nc -w 10 localhost 2389

4. IPv6 connect

-4 또는 -6 플래그는 netcat 유틸리티가 어떤 유형의 주소를 사용해야 하는지 지정한다.

(-4 없이 IPv4 주소를 적을 경우 연결 가능)

# server side
nc -4 -l 2389

# client side
nc -4 localhost 2389

5. Disable reading from STDIN

1) -d 플래그: stdin(표준 입력)에서 읽기를 비활성화

클라이언트에서 서버로 데이터 전송을 막음

(연결 수립 이후 텍스트 입력해야 함, 마지막 hi는 -d와 관계없이 무시됨)

2) -k 플래그: (keep listening) 서버 측 옵션, 클라이언트가 연결을 종료해도 서버는 계속 실행되어 새로운 클라이언트 연결 대기 상태 유지

→ 다중 클라이언트 연결 가능, 서버 수동 종료 전까지 계속 실행

3) -q 플래그: EOF(파일이나 데이터 스트림의 끝, 데이터 전송이 완료되었음을 알리는 시그널) 수신 후 5초간 대기

→ -w 플래그로 대체됨

# server side
nc -l 2389 > received_file.txt

# client side
 date; cat file.txt | nc -w 5 localhost 2389; date

4) -u 플래그: UDP 옵션 (서버와 클라이언트 모두 설정)

$ netstat -an | grep 2389
udp4 0 0 127.0.0.1.61430 127.0.0.1.2389
udp4 0 0 127.0.0.1.2389 127.0.0.1.61430

[AWS] VPC 엔드포인트 서비스를 RDS 프록시에 연결 (cross-account)

sarahee — Tue, 10 Dec 2024 16:30:31 +0900

본인 IP 조회

curl ifconfig.me

1. 데이터베이스 계정에 RDS DB 인스턴스 및 RDS 프록시 생성

2. RDS Proxy 엔드포인트에 할당된 IP 주소 식별

- dig (proxy endpoint arn) 의 Answer section

3. 데이터베이스 계정에 PrivateLink 엔드포인트 서비스 생성

1) 데이터베이스 계정에 타겟 그룹 생성

2) 데이터베이스 계정에 Network Load Balancer 생성

3) 데이터베이스 계정에 VPC 엔드포인트 서비스 생성

4. 고객 계정에서 VPC 엔드포인트 생성

5. 연결 테스트

psql -h <db-endpoint> -p <port-number> -d <db-name> -U <username> -W

psql -h nlbdb-database-ee.cluster-c78suu4aug2x.us-east-1.rds.amazonaws.com -p 5432 -d nlbdb-database-ee -U postgres

References:

[] Connect to an AWS RDS PostgreSQL database using PSQL - https://onticdani.medium.com/connect-to-an-aws-rds-postgresql-database-using-psql-750c00b5ceb2

[] Access Amazon RDS across AWS accounts using AWS PrivateLink, Network Load Balancer, and Amazon RDS Proxy - https://aws.amazon.com/ko/blogs/database/access-amazon-rds-across-aws-accounts-using-aws-privatelink-network-load-balancer-and-amazon-rds-proxy/
[] Use Amazon RDS Proxy and AWS PrivateLink to access Amazon RDS databases across AWS Organizations at American Family Insurance Group - https://aws.amazon.com/blogs/database/use-amazon-rds-proxy-and-aws-privatelink-to-access-amazon-rds-databases-across-aws-organizations-at-american-family-insurance-group/

[AWS] SAA-C03#12: Route 53 (2)

sarahee — Wed, 7 Aug 2024 20:43:55 +0900

Route 53 - Routing Policies

라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 도움, DNS 관점(DNS는 트래픽 라우팅하지 않음, 트래픽은 DNS를 통과하지 않음)
- 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스에 라우팅하는 것과는 다름
- DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 됨
- DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 도움
Route 53이 지원하는 라우팅 정책: 단순, 가중치 기반, 장애 조치, 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접 라우팅 정책
(Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity (using Route 53 Traffic Flow feature)

Routing Policies - Simple

트래픽을 단일 리소스로 보내는 방식
클라이언트가 foo.example.com으로 가고자 한다면 Route 53이 IP 주소를 알려주는 것 (A 레코드 주소)
동일한 레코드에 여러 개의 값을 지정하는 것도 가능함. DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 됨 (e.g., 클라이언트가 foo.example.com으로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답할 때(A 레코드에 임베딩된 주소), 클라이언트가 셋 중 하나를 골라 라우팅에 적용함)
단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있음 - 그렇기 때문에 상태 확인은 불가

Hands-on#04. Simple

value IP 추가하면서 테스트

Routing Policies - Weighted

가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능
한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지, 각 레코드에 상대적으로 가중치를 할당함
이렇게 하면 DNS 레코드들은 동일한 이름과 유형을 가져야 하고 상태 확인과도 관련될 수 있음
사용되는 경우: 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때, 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우
- 가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있음
- 만약 모든 리소스 레코드 가중치의 값이 0인 경우는 모든 레코드가 다시 동일한 가중치를 갖게 됨

Hands-on#05. Weighted

Record ID: 가중치 레코드 설정에서 이 특정 레코드를 식별하기 위해 사용됨
- simple 레코드는 여러 개의 IP 주소를 가진 반면 weighted 세 개의 레코드는 각각 하나의 값을 가짐

Routing Policies - Latency-based

지연 시간이 가장 짧은, 가장 가까운 리소스로 리다이렉팅하는 정책
지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우 유용한 정책
지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정
(e.g., 유저가 독일에 있고 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국으로 리다이렉팅이 될 것)
- 두 개의 다른 리전에 애플리케이션을 배포할 때

Hands-on#06. Latency-based

별칭이 해당 IP가 어느 지역에 있는 EC2 인스턴스에서 왔다는 것을 알 수 없기 때문에,
값에 IP 주소를 입력해도 이 IP의 리전을 표시해줘야 함

Route 53 - Health Checks

상태 확인은 공용 리소스에 대한 상태를 확인하는 방법
e.g., (다중 지역 셋업) 서로 다른 두 지역에 하나씩 로드 밸런서가 있고 둘은 모두 공용 로드 밸런서임, 그리고 그 둘의 뒤에서 애플리케이션이 작동 중 - 지역 레벨에서 고가용성을 원하는 상황
- Route 53을 이용해 DNS 레코드를 만들 것
- 유저가 mydomain.com과 같은 URL을 이용해 접속하면 해당 유저는 가장 가까운 로드 밸런서로 연결됨 (지연 시간 기반 레코드)
만약 한 지역이 사용 불가능 상태면 유저를 보내고 싶지 않기 때문에 Route 53에서 상태 확인을 생성해야 함
- 두 지역의 상태 확인을 Route 53의 레코드와 연결할 수 있음 (DNS의 장애 조치를 자동화하기 위한 작업)
세 가지의 상태 확인(Health Check)이 가능함
- 각 상태 확인은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인 가능
1) 공용 엔드 포인트를 모니터링하는 상태 확인
- 애플리케이션, 서버, 다른 AWS 리소스
2) 다른 상태 확인을 모니터링하는 상태 확인 (계산된 상태 확인)
3) CloudWatch 경보의 상태를 모니터링하는 상태 확인
- 제어가 쉽고 개인 리소스들에 유용함

Health Checks - Monitor an Endpoint

ALB에 대한 특정 지역의 상태 확인을 한다고 하면, 전 세계로부터 15개 정도의 AWS 상태 확인이 옴
→ 우리가 루트를 설정한 공용 엔드 포인트로 모두 요청을 보냄
→ 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정함 (200 OK 코드 또는 우리가 정의한 코드를 받으면 리소스는 정상으로 간주됨)
- 간격: 30초마다 정기적으로 확인 혹은 10초마다(더 높은 비용)
- 지원 프로토콜: HTTP, HTTPS, TCP
- 18% 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주함
- 상태 확인에 사용될 위치 선택 가능
- 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 됨
텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 byte를 확인함 (응답 자체에 해당 텍스트가 있는지 보기 위해)
상태 확인의 작동이 가능하려면 상태 확인이 ALB나 엔드 포인트에 접근이 가능해야 함
Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 함 (주소 범위는 https://ip-ranges.amazonaws.com/ip-ranges.json 참고)

Route 53 - Calculated Health Checks

여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
- 조건: OR, AND, NOT
하위 상태 확인을 256개까지 모니터링할 수 있고 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있음
→ 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 유지 관리하도록 하는 경우

Health Checks - Private Hosted Zones

개인의 리소스를 모니터링하는 것은 어려울 수 있음
Route 53 상태 확인이 공용 웹에 있기 때문에 health checkers는 VPC 외부에 있음
개인 엔드 포인트에 접근 불가능 (개인 VPC나 온프레미스 리소스)
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있음
→ CloudWatch 경보를 상태 확인에 할당할 수 있음 (CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링하는 것)
메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 되고, 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 됨
→ 개인 리소스에 대한 상태 확인 완료

Hands-on#07. Health Check

1) 엔드 포인트가 될 region 인스턴스의 상태 확인을 생성 (세 리전 모두)
path: /health (엔드 포인트 자체의 상태에 대한 응답)
Advanced configuration: String matching - 첫 5120 바이트 문자열을 비교할지 여부를 선택
2) 특정 region에 있는 한 인스턴스의 보안 그룹에서 80번 포트를 차단하고 security groups의 HTTP 관련 rule을 삭제 (상태 확인 장애를 발생시킴)
3) create health check - name: calculated / status of other health checks (calculated health check)
4) create health check - state of CloudWatch alarm
- 개인 EC2 인스턴스의 상태를 모니터링할 수 있음
- 개인 리소스의 상태 확인을 Route 53 상태 확인에 연결하는 것

Routing Policies - Failover (Active-Passive)

장애 조치에 관한 것
Route 53에 대해 하나는 기본 EC2 인스턴스, 하나는 보조 EC2 인스턴스(재해 복구 EC2 인스턴스)일 때
상태 확인과 기본 레코드를 연결하는데 필수적
상태 확인이 비정상이면 자동으로 Route 53은 두번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작함
보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있음
→ 클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻음

Hands-on#08. Failover

상태 확인을 통해 장애 조치 레코드를 생성 (호스팅 영역에서 레코드를 생성)
보안 그룹 수정하여 장애 조치가 실행되는 위치를 확인

Routing Policies - Geolocation

사용자의 실제 위치를 기반으로 함 (지연 시간 기반의 정책과는 다르게)
사용자가 특정 대륙이나 국가 또는 어떤 주에 있는지 지정하는 것이며, 가장 정확한 위치가 선택되어 그 IP로 라우팅되는 것
일치하는 위치가 없는 경우는 기본 레코드를 생성해야 함
사용 사례: 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화
- 상태 확인과 연결할 수 있음
e.g., 유럽의 지도에서, 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있음, 프랑스는 프랑스어의 버전의 앱을 가진 IP로 가야 함, 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 함

Hands-on#09. Geolocation

Location이 다른 IP에 대해 테스트

Geoproximity Routing Policy

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅함
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것
→ 지리적 위치를 변경하려면 편향값을 지정해야 함, 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 됨, 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됨
리소스는 AWS의 리소스로 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나, AWS 리소스가 아닌 온프레미스 데이터 센터의 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 함
기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용함
- 편향이 없다면, 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것
- 편향으로 인해 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있음, 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생함 (편향이 높을 경우)
예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됨
- 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것

Routing Policies - IP-based Routing

클라이언트 IP 주소를 기반으로 라우팅을 정의함 → Route 53에서 CIDR 목록을 정의함 (클라이언트 IP 범위) → CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지를 정함
- 이것을 사용하면 성능을 최적화할 수 있음, IP를 미리 알고 있기 때문
- 네트워크 비용을 절감할 수 있음, IP가 어디에서 오는지 알기 때문
예를 들어 특정 ISP가 특정 IP 주소 셋을 사용하는걸 안다면 특정 엔드포인트로 라우팅할 수 있음
e.g., Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의함 (location-1: 203.x.x.x/24, location-2: 200.x.x.x/24)
→ 로케이션을 레코드에 연결 (record name: example.com / value: 1.2.3.4 and 5.6.7.8 / IP-based: location1 and location2)
- 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타냄
→ 사용자 A가 location-1 CIDR blocks에 속하는 특정 IP로 들어오면 첫번째 EC2 인스턴스인 IP 1.2.3.4로 보내짐
+ 사용자 B가 location-2에 속하는 IP 주소로 들어오면 리디렉션되어 IP 5.6.7.8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 됨

Routing Policies - Multi-Value

- 트래픽을 다중 리소스로 라우팅할 때 사용함, 그래서 Route 53은 다중 값과 리소스를 반환함
- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있음
- 각 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
- ELB와 유사해 보이지만 ELB를 대체할 수는 없음 (클라이언트 측면의 로드 밸런싱)
e.g., example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결함
클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택함, 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있음
그래서 클라이언트는 안전한 쿼리를 가질 수 있음
e.g., 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있음, 이것이 다중 값이 조금 더 강력한 레코드 유형인 이유

Hands-on#10. Multi-Value

세 리전에 대한 multi
Health checks에서 Invert health check status 체크하여 정상에서 비정상으로 변경

Domain Registar vs. DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있음, 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공함, 그래서 Amazon 호스트 이름으로 DNS 이름을 등록했다면 DNS 레코드 관리를 위한 Route 53 호스팅 존을 가짐
도메인 이름을 등록하면 네임 서버 옵션이 생기는데 사용자 정의 이름 서버를 지정할 수 있음 (Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 우측 네임 서버를 구매한 사이트(GoDaddy 등)에서 변경해야 함)
GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 네임 서버가 Amazon의 Route 53 이름 서버를 가리키고 그렇게 Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리함
- 정리: 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53을 사용 가능한데, 사용하려면 Route 53에서 공용 호스팅 영역을 생성한 뒤 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 됨
→ 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스가 다름

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

[AWS] SAA-C03#11: Route 53 (1)

sarahee — Wed, 7 Aug 2024 16:29:16 +0900

DNS: Domain Name System which translates the human friendly hostnames into the machine IP addresses

DNS Terminologies (관련 용어)

Domain Registrar(도메인 이름 등록하는 곳): Amazon Route 53, GoDaddy, ...

DNS Records: A, AAAA, CNAME, NS, ...

Zone File: contains DNS records

Name Server: resolves DNS queries

1) Web Browser가 example.com에 접근하기 위해서는 Local DNS server에 물어볼 것
* Local DNS Server: 보통 회사에 의해 할당되고 관리되거나 ISP에 동적으로 할당됨
2) Local DNS Server가 이 쿼리를 본 적이 없다면 먼저 ICANN에 관리된 Root DNS Server에 물어볼 것
→ .com은 알고 있음 (.com NS 1.2.3.4) 반환
3) 1.2.3.4에 있는 .com 도메인 서버에게 쿼리의 답을 요청 (TLD DNS Server, Managed by IANA, Branch of ICANN)
→ DNS 서버는 example.com을 모르지만 example.com 이라는 서버는 알고 있음 (example.com NS 5.6.7.8)
4) 로컬 DNS 서버(서브도메인의 DNS 서버)에 질의: 도메인 네임 레지스트라(Route 53 등)에 의해 관리되는 서버, 최종 서버
→ example.com에 대해 알고 있음. example.com은 A 레코드이고 이것의 결과로 IP 9.10.11.12를 얻음

Route 53

a highly, available, scalable, fully managed and authoritative DNS, DNS 레코드를 업데이트할 수 있음
DNS 레코드를 아마존 Route 53의 호스팅 존에 쓰려고 함, 클라이언트가 example.com을 요청하면 Route 53 서비스가 IP 54.22.33.44를 찾고 있다고 응답함 → 클라이언트는 바로 EC2 인스턴스에 접근함, Route 53도 도메인 이름 레지스트라로 도메인 이름을 example.com으로 등록함
Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의함
각 레코드는 도메인이나 example.com과 같은 서브도메인 이름과 같은 정보를 포함함
* TTL: DNS 리졸버에서 레코드가 캐싱되는 시간

Route 53 - Record Types

A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
- 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있음
- Route 53에서 DNS namespace 또는 Zone Apex의 상위 노드에 대한 CNAME을 생성할 수 없음
(e.g., example.com에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME 레코드는 만들 수 있음)
NS - Name Servers for the Hosted Zone
- 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있음
- 트래픽이 도메인으로 라우팅되는 방식을 제어함

Route 53 - Hosted Zones

a container for records, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
Public Hosted Zones - 쿼리에 도메인 이름 application1.mypublicdomain.com의 IP가 무엇인지 알 수 없음
Private Hosted Zones - 공개되지 않은 도메인 이름을 지원, 가상 프라이빗 클라우드(VPC)만이 URL을 resolve할 수 있음(e.g., application1.company.internal)

Route 53 - Public vs. Private Hosted Zones

Public Hosted Zones: 공개된 클라이언트로부터 온 쿼리에 응답할 수 있음, 웹 브라우저에서 example.com을 요청하면 IP를 반환함
- 퍼블릭 레코드를 위한 호스팅 존
Private Hosted Zones: 해당 VPC에만 동작, 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있음
- 프라이빗 리소스, 예컨대, VPC에서만 쿼리할 수 있음

EC2 인스턴스가 1개 있고, webapp.example.internal을 식별하고자 함
또 다른 EC2 인스턴스에서는 api.example.internal을 식별하기 원하고 데이터베이스에서는 db.example.internal을 식별하고자 함
private hosted zone에 등록하고자 하는데, 첫번째 EC2 인스턴스가 api.example.internal을 요청하는 경우 프라이빗 호스팅 존은 프라이빗 IP 10.0.0.10이라는 답을 갖고 있음. EC2 인스턴스는 데이터베이스에 연결이 필요할 수도 있는 두번째 EC2 인스턴스에 연결하여 db.example.internal이 무엇인지 물어보면 프라이빗 호스팅 존은 프라이빗 IP를 알려줌

Hands-on#01. Route 53 setting up

1) Registered domains
2) Hosted zones - Create record A
3) cloudshell

sudo yum install -y bind-utils
nslookup domain.com
dig domain.com

4) Create EC2 Instances
- 서로 다른 리전에 세 인스턴스 생성(e.g., NRT, ICN, KIX - Tokyo, Seoul, Osaka)
- proceed without a key pair
- allow HTTP traffic from the internet

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/meta-data/placement/availability-zone)
echo “<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>” > /var/www/html/index.html

- Hello World 뒤에 인스턴스 정보를 출력할 것, 인스턴스가 시작되는 가용 영역도 포함시키는 과정에서 환경 변수 $EC2_AVAIL_ZONE을 사용
5) Create Load Balancer (DemoRoute53ALB)
- create TG
6) open addresses & LB에서 DNS name이 프로비저닝 되었는지 확인
ap-northeast-1(Tokyo): 54.199.162.15x
ap-northeast-2(Seoul): 43.201.64.18x
ap-northeast-3(Osaka): 13.208.191.12x

Route 53 - Records TTL (Time To Live)

클라이언트가 DNS Route 53와 웹 서버에 접속한다고 할 때,
myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받음 (회신 내용: A 레코드, IP 주소, TTL(300초 정도))
TTL은 클라이언트에게 이 결과를 캐시하도록 요청함 (클라이언트는 300초 동안 결과를 캐시함)
→ 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 답변을 캐시에 저장해서 답을 알기 때문에 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미
하지만 캐시에도 시간이 소요되어 캐시 TTL이 발생, DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않기 때문
저장된 답변을 이용함으로써 웹 서버에 접속이 가능하고 HTTP 요청 및 회신을 보낼 수 있음
1) High TTL - e.g., 24 hr
TTL을 24시간으로 높게 설정하면 결과가 24시간 동안 캐시되므로 Route 53의 트래픽은 현저히 적음 (클라이언트가 요청을 적게 보냄)
-> 클라이언트가 오래된 레코드를 받을 가능성이 있음 (레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻)
2) Low TTL - e.g., 60 sec.
TTL을 60초 정도로 짧게 설정한다면 DNS에는 트래픽 양의 많아져서 비용이 많이 듦 (Route 53에 들어오는 요청의 양에 따라 요금이 책정되기 때문)
오래된 레코드의 보관 시간은 짧아짐 -> 레코드 변경이 빨라짐

Hands-on#02. TTL

1) Create A record - IP region
2) record name으로 사이트 접속 혹은 cloudshell nslookup or dig
3) edit Record value
- 레코드 캐시가 만료될 때까지 확인

CNAME vs Alias

AWS 리소스(로드밸런서나 CloudFrond 등)를 사용하는 경우 호스트 이름이 노출됨, 그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수 있음
myapp.mydomain.com에 로드 밸런서를 매핑하는 경우 두 가지 옵션이 있는데,
1) CNAME 레코드로 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.anything.com)
- 루트 도메인 이름이 아닌 경우에만 가능 (aka. something.mydomain.com)
2) Alias: Route 53에 한정하여, 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.amazonaws.com)
- 루트 도메인과 비루트 도메인 모두에 작동함 (aka. mydomain.com, mydomain.com을 별칭으로 사용해 AWS 리소스로 향하도록 할 수 있음)
- 무료, 자체적으로 상태 확인 가능

Route 53 - Alias Records

AWS 리소스에만 매핑이 되어 있음
예를 들어 Route 53에서 example.com을 A 레코드의 별칭 레코드로 하고 그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 해보자.

기반이 되는 ALB에서 IP가 바뀌면 별칭 레코드는 바로 인식함
CNAME과 달리 별칭 레코드는 Zone Apex라는 DNS 네임 스페이스의 상위 노드로 사용될 수 있음
AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA (리소스는 IPv4나 IPv6 중 하나)
별칭 레코드를 사용하면 TTL을 설정할 수 없음 (Route 53에 의해 자동으로 설정됨)

Route 53 - Alias Records Targets

별칭 레코드의 대상은? ELB, CloudFront 배포, API Gateway, Elastic Beanstalk environments, S3 Websites(S3 버킷은 안됨, 버킷들이 웹사이트로 활성화될 시 S3 웹사이트는 가능), VPC Interface Endpoints, Global Accelerator accelerator, Route 53 record in the same hosted zone
- EC2의 DNS 이름은 별칭 레코드의 대상이 될 수 없음

Hands-on#03. CNAME vs. Alias

1) create CNAME record
- value: ALB DNS name
2) create A record
- Alias > Route traffic to ALB
- 별칭 레코드이기 때문에 Evaluate target health는 자동으로 Yes 체크되어 있음
3) create A record without subdomain

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

[AWS] setting up Nginx SSL

sarahee — Tue, 30 Jul 2024 20:04:02 +0900

0. Connecting to an Instance

AWS CLI를 사용하여 인스턴스의 Linux OS 플랫폼 및 버전 정보 확인

uname
cat /proc/version

Linux version ~ ... ~ (Red Hat 11.4.1-2), ~ ...

Redhat 계열(centOS) - yum
Debian, Ubuntu - apt-get

1. Installing Nginx

nginx directory 생성
Nginx: 정적 컨텐츠를 제공해주는 프록시 서버

sudo yum install nginx
cd /etc && ls | grep nginx // check settings

sudo mkdir /etc/nginx/sites-available
sudo mkdir /etc/nginx/sites-enabled

2. Setting up config

1) nginx.conf 수정
: nginx 관련 설정을 블록 단위로 설정, sites-enable에 존재하는 파일 불러옴

sudo vi /etc/nginx/nginx.conf

    include /etc/nginx/sites-enabled/*.conf;

#    server {
#        listen       80;
#        listen       [::]:80;
#        server_name  _;
#        root         /usr/share/nginx/html;
#
#        # Load configuration files for the default server block.
#        include /etc/nginx/default.d/*.conf;
#
#        error_page 404 /404.html;
#        location = /404.html {
#        }
#
#        error_page 500 502 503 504 /50x.html;
#        location = /50x.html {
#        }
#    }

2) server 설정
: nginx 최신 버전을 따로 설치하지 않고 기본 설정된 repository에 있는 버전을 install nginx로 바로 설치한 경우에는 nginx 환경 설정 파일 위치가 /etc/nginx/sites-available/default로 설정됨,
최신 버전을 설치했을 경우 /etc/nginx/conf.d/default.conf [5]

sudo vi /etc/nginx/sites-available/default.conf

    server {
        listen 80;
        location / {
                root /project/nginx-project;  // path to deploy
                index index.html index.htm;
                try-files $url $url/ /index.html;
        }       
    }

3) symbolic link 설정
: sites-enabled directory에 default.conf 바로가기 생성
sites-available에 존재하는 설정 파일들 중, 사용하는 설정 파일만 link해서 사용할 수 있도록 하는 디렉터리

cd /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/default.conf
ls -l

total 0
lrwxrwxrwx. 1 root root 39 Jul 30 04:42 default.conf → /etc/nginx/sites-available/default.conf
4) 웹서버 html 설정

sudo vi /project/nginx-project/index.html

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Nginx!</title>
</head>
<body>
    <h1>Welcome to Nginx!</h1>
    <p>If you see this page, the Nginx web server is successfully installed and working.</p>
    <p>Further configuration is required.</p>
</body>
</html>

3. Run the server

sudo systemctl start nginx

오류 시
status : Failed to start nginx.service - The nginx HTTP and reverse proxy server

sudo systemctl start nginx

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.

: 80번 포트에 수신 대기중인 프로세스 삭제

fuser -k 80/tcp

4. Prepare SSL/TLS Certificate

- Generate a self-signed certificate or obtain a certificate from a Certificate Authority (CA)
1) Ensure that OpenSSL is installed on your operating system

openssl version

nginx가 ssl 적용이 가능한 모듈이 있는지 확인 (--with-http_ssl_module)

nginx -V

nginx version: nginx/1.24.0
built with OpenSSL 3.0.8 7 Feb 2023
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-openssl-opt=enable-ktls --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -ftree-vectorize -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' —with-ld-opt='-Wl,-z,relro -Wl,—as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,—build-id=sha1 -Wl,-dT,/builddir/build/BUILD/nginx-1.24.0/.package_note-nginx-1.24.0-1.amzn2023.0.2.x86_64.ld -Wl,-E’

2) 인증서 작업할 폴더 생성 (/usr/local/ssl)
3) Generate the Private Key
- Use the following OpenSSL command to generate the private key:

openssl genrsa -des3 -out server.key 2048

Enter PEM pass phrase:
> server.key 생성

4) Create a Certificate Signing Request (CSR)
- Use the following OpenSSL command to generate the certificate signing request (CSR) file:

openssl req -new -key server.key -out server.csr

- During this process, you will be prompted to enter information such as country, state, city, company name, and domain name

5) Generate the Self-Signed Certificate
- Use the following OpenSSL command to generate the self-signed certificate:

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

- -days 3650: 3650일짜리(10년) 인증서
- -in server.csr -signkey server.key: 개인 키와 서버 요청서를 가지고 인증서 server.crt 생성

5. Configure the Nginx configuration file

- Add the following HTTPS-related settings inside the server block:
- Use the listen directive to specify port 443
- Use the ssl_certificate and ssl_certificate_key directives to specify the paths to the certificate files

> cd /etc/nginx/conf.d/
> sudo cp www.example.com.conf www.example.com.conf.bak
> sudo mkdir /etc/nginx/ssl
> sudo chmod 700 /etc/nginx/ssl
> sudo nano www.example.com.conf

server {
    listen       443 ssl;
    server_name  www.example.com;

    ssl_certificate /usr/local/ssl/server.crt;
    ssl_certificate_key /usr/local/ssl/server.key;
    
    ## omitted below
}

+ 공인 인증기관에서 발급하지 않은 인증서는 윈도우에서 host 파일을 수정하여 접근할 것
(참고)

vi /etc/nginx/conf.d/default.conf
vi /etc/nginx/sites-available/default.conf

    server {
            listen      443 ssl;
            server_name nginx-ssl-test.com;
            
            ssl_certificate     /usr/local/ssl/server.crt;
            ssl_certificate_key /usr/local/ssl/server.key;
            ssl_session_timeout 5m;
            ssl_protocols       SSLv2 SSLv3 TLSv1;
            ssl_ciphers         HIGH:!aNULL:!MD5;
            ssl_prefer_server_ciphers   on;
            
            location / {
                    root        /home/espeniel;
                    index       index.html index.htm;
            }       
    }

6. Set up HTTP to HTTPS redirection

- Configure the server block to redirect HTTP (port 80) requests to HTTPS
- Use the return 301 directive to achieve the redirection

vi /etc/nginx/sites-available/default.conf

server {
    listen       80 default_server;
    server_name  nginx-ssl-test.com;
    return 301 https://$host$request_uri;
}

- nginx 서비스 확인

ps -ef | grep nginx

systemctl restart nginx

오류 시
(1) /usr/local/ssl/server.key 파일의 권한과 소유자 확인

sudo chmod 644 server.key
sudo chown nginx:nginx server.key

(2) openssl rsa -check -in /usr/local/ssl/server.key
(3) 로그 확인

sudo journalctl -u nginx

Jul 30 08:59:35 ip-172-31-39-33.ec2.internal nginx[3006]: nginx: [emerg] cannot load certificate key "/usr/local/ssl/server.key": PEM_read_bio_PrivateKey() failed (SSL: error:1400006B:UI routines::processing error:while reading strings error:0480006D:PEM routin>
Jul 30 08:59:35 ip-172-31-39-33.ec2.internal nginx[3006]: nginx: configuration file /etc/nginx/nginx.conf test failed

→ The private key has a passphrase requirement but nginx is not configured to use a passphrase.

7. delete key passphrase

1) Rename the existing server.key filename to server_pass.key

mv server.key server_pass.key

2) Create a new key without a passphrase requirement. It is assumed that the RSA key in use, otherwise adjust the command accordingly. When prompted, type the passphrase and press enter

openssl rsa -in server_pass.key -out server.key

3) Stop, start nginx service and check that no error message are displayed

8. local test
- www.example.com은 공인된 도메인이 아니라 사내에서 사용할 가상 도메인이므로 클라이언트 측 도메인에 대한 hosts 파일을 등록해야 함

9. (optional) Additional SSL/TLS-related Settings
- Use the ssl_session_cache and ssl_session_timeout directives to configure the SSL session cache
- Use the ssl_prefer_server_ciphers direcactive to prefer the server's cipher suites
- Use the add_header directive to add security-related headers

10. Test Configuration and Restart Nginx
- Use the nginx -t command to check the syntax of the configuration file
- Use the systemctl restart nginx command to restart the Nginx service

sudo nginx -t
sudo nginx -s reload

References:

[1] [AWS] EC2 인스턴스에 Nginx 적용하기
[2] [AWS] EC2 NGINX 설치하고 Config설정 및 배포하기
[3] OpenSSL로 개인키 발급 및 SSL 인증서 생성#1
[4] Nginx https 적용하기 openssl 사용, http https로 리다이렉트
[5] Ubuntu에서 Nginx SSL 인증서 설정하는 방법
[6] DPSearch - Nginx service fails to start after installing new SSL certificate

[AWS] ANS-C01#02: VPC fundamentals

sarahee — Wed, 24 Jul 2024 19:14:13 +0900

Topics

What is VPC?

AWS Service scope with respect to Region, AZ and VPC

AWS Services inside and outside of VPC

VPC Addressing (CIDR)

VPC Subnets and Route Tables (Public/Private)

IP Addresses (IPv4, IPv6, Private/Public/Elastic)

Security Groups and Network ACL

NAT gateway and NAT instance

Transit Gateway: 2018년 출시한 네트워킹 라우터

VPC의 서브넷: 개별 LAN 네트워크, VPC로부터의 작은 주소 범위

서브넷이 사용자 지정 route table을 생성하여 Main Route Table을 따르지 않으면, 두 다른 AZ의 서브넷이 Local Router를 통해 연결할 수 없음

VPC의 모든 서브넷이 같은 종류의 네트워크 연결을 원할 경우 메인 루트 테이블 수정

Amazon에서 제공하는 IPv6 DNS가 없음

Security groups are stateful

Network Access Control List(NACL):

1) works at Subnet level

2) Stateless(inbound/outbound 별도)

3) contains both Allow and Deny rules

4) 규칙 번호 순서대로 평가

5) default NACL allows all inbound and outbound traffic
6) NACL are a great way of blooking a specific IP at the subnet level

Hands-on#01

1) create VPC public

2) create Internet Gateways > Attach to VPC

3) create subnet > modify auto-assign IP settings

4) create Route Table > routes 0.0.0.0/0 IGW

VPC 내 고립된 라우트 테이블

5) create VPC private

VPC secondary CIDR blocks

ENI: IP 주소 제공, 네트워크 통신 가능하게 하는 VPC의 논리적 구성 요소, 가상 네트워크 카드

IP주소는 EC2 인스턴스를 실행할 때 AWS가 만드는 ENI를 이용해 할당됨

Bring Your Own IP

Hands-on#02

EC2 인스턴스 2개 - app / DB server

Domain-name = corp.internal

Steps

1) Create a VPC with Public & Private subnet

2) (Optional) Create DHCP Option set with domain as corp.internal and associate with your VPC

- Domain name: corp.internal / Domain name servers: AmazonProvidedDNS

- Edit VPC settings: option set - corp.internal

3) Launch one EC2 instance in Public subnet (say app) and one instance in Private subnet (say db).

- Allow SSH (source type: My IP) and ICMP IPv4 (source type: 10.0.0.0/16) in the security group

4) Create Route 53 Private hosted zone and associate with the VPC

- NS, SOA + app (10.10.0.206), db (10.10.1.173)

5) Create A records for ec2 instances pointing to their Private IPs

6) SSH into Public EC2 instance and ping to other instance using it's DNS name

- cat /etc/resolv.conf : nameserver

- ping db.corp.internal or ping db

VPC DNS with custom DNS server

Step - Setup a VPC and launch instances

- Create a VPC with public and private subnets

- Launch DNS server ec2 instance: Security group to allow UDP 53 from VPC CIDR, SSH (22)

- Launch an app server & db server ec2 instances: Security group to allow SSH (22), ICMP IPv4 All (ping)

----------------------------------------------
Step 4a – Configure on-premise DNS server
----------------------------------------------
1. Login to on-premise DNS server (via SSH into VPN server first)
2. Install DNS server packages

sudo su
yum update –y
# DNS를 위한 패키지 설치, util을 binding
yum install bind bind-utils –y

3. Create file /var/named/corp.internal.zone

$TTL 86400
@ IN  SOA     ns1.corp.internal. root.corp.internal. (
  2013042201  ;Serial
  3600        ;Refresh
  1800        ;Retry
  604800      ;Expire
  86400       ;Minimum TTL
)
; Specify our two nameservers
IN  NS    dnsA.corp.internal.
IN  NS    dnsB.corp.internal.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
dnsA IN  A   1.1.1.1
dnsB IN  A   8.8.8.8
; Define hostname -> IP pairs which you wish to resolve
@ IN  A   10.0.11.191
app IN A   10.0.11.191
db IN A   10.0.0.221

# APP 10.0.11.191
# DB 10.0.0.221

4. Create file /etc/named.conf [Replace X.X with your DNS server IP]

options {
  directory "/var/named";
  dump-file "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
  allow-transfer { localhost; 10.0.11.191; };
  recursion yes;
  forward first;
  forwarders {
    10.0.0.2;
  };
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside auto;
  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";
  managed-keys-directory "/var/named/dynamic";
};
zone "corp.internal" IN {
    type master;
    file "corp.internal.zone";
    allow-update { none; };
};

# DNS 10.0.11.191

5. Restart named service

service named restart
chkconfig named on

+ create DHCP Option sets

+ edit VPC DHCP option set

+ reboot App, DNS, DB server

----------------------------------------------
Step 5b – Configure on-premise DNS server
----------------------------------------------
1. Add following to /etc/named.conf. Replace ENDPOINT IPs with Route53 inbound resolver IPs.

zone "cloud.com" {
  type forward;
  forward only;
  forwarders { INBOUND_ENDPOINT_IP1; INBOUND_ENDPOINT_IP2; };
};

2. Restart named service
sudo service named restart

VPC DNS & DHCP exam essentials

- VPC has a default DNS server AmazonProvidedDNS

References

Udemy, AWS Certified Advanced Networking Specialty, Section 3

[AWS] ANS-C01#01: ELB

sarahee — Fri, 19 Jul 2024 19:29:07 +0900

ALB는 여러 Listener를 가지며, 한 listener 당 한 가지 이상의 rule이 존재

e.g., Listener 1이 target group에 트래픽을 보내는 한 가지 규칙이 있을 때

target group은 여러 target을 갖고 있음 EC2 인스턴스나 health check 등

ALB는 TG에 등록된 target으로 요청을 라우팅하기 전에 사용자를 인증할 수 있음

ALB에 SSL, TLS, SSL 인증서를 로드할 수 있음

NLB는 두 AZ 사이에 있고, 클라이언트는 NLB에 연결되어 있음

NLB는 고정된 IP 주소가 있어서 고정 IP로 ENI에 연결됨

NLB는 AZ당 고정 IP가 하나 있어서 elastic IP를 할당할 수 있음

EC2 instance가 NLB의 다른 VPC에 있다면, 이 인스턴스를 NLB에 ID로 등록할 수 없음

ID로 인스턴스를 등록하거나 ECS 작업 내에서 자동으로 클라이언트의 IP는 보존되고 EC2 인스턴스는 클라이언트로부터 직접 발생하는 트래픽을 봄

NLB가 3개의 AZ로 활성화되어 있고 NLB DNS 이름에 대한 DNS 쿼리를 하면 3개의 IP를 갖게 됨, 활성화되어 있는 3개의 AZ와 부합함

NLB는 각 노드에 대해 DNS 이름을 갖고, 사용 가능한 AZ에 기반해 DNS name을 써서 IP 주소 하나만 확인할 수 있음

Connection Idle Timeout

client-ELB connection & ELB-target connection

NLB works without cookies

SSL - Server Name Indication (SNI): 다중 SSL 인증서를 하나의 웹 서버에 로딩하는 문제를 해결함 (다중 웹사이트와 도메인을 지원하는 서버)

Hands-on#01: ALB X-Forwarded Headers

1) create instance

instance user data

#!/bin/bash
# Use this for your user data (script without newlines)
# Installs httpd (Linux 2 version)
yum update -y
yum install -y httpd.x86_64
systemctl start httpd
systemctl enable httpd
echo "Hello World from $(hostname -f)" > /var/www/html/index.html

2) create ALB

- create TG

3) connect ssh

4) Edit the file httpd.conf, edit the LogFormat section with the following

sudo nano /etc/httpd/conf/httpd.conf

# The following ... a CustomLog directive (see below).

>> LogFormat "%{X-Forwarded-For}i %{X-Forwarded-Proto}i %{X-Forwarded-Port}i ...

5) Reload Apache

sudo systemctl reload httpd

6) Run the following command to watch your Apache Access Logs

sudo tail -f /var/log/httpd/access_log

172.31.x.x - - [19/Jul/2024:09:26:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
172.31.y.y - - [19/Jul/2024:09:27:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
...
- - - 172.31.x.x - - [19/Jul/2024:09:28:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
- - - 172.31.y.y - - [19/Jul/2024:09:29:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
15.248.a.a http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
15.248.b.b http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- 기존에는 X-Forwarded 헤더가 없지만, ALB DNS name으로 접속(새로고침) 시 IP, protocol, port 정보 확인

Hands-on#02: NLB Proxy Protocol

1) create instance (same user data)

2) create NLB

- create TG

- choose type IP addresses

- VPC subnet: EC2 instance private addresses

3) repeat #01 6)

# public IP
15.248.a.a - - [19/Jul/2024:10:02:22 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
# NLB DNS
172.31.x.x - - [19/Jul/2024:10:02:28 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

4) edit TG attributes

- Traffic configuration: enable Proxy protocol v2, Preserve client IP addresses

5) Verify the module mod_remoteip loaded successfully

sudo /usr/sbin/httpd -M | grep -i remoteip

You'll have the following output

> remoteip_module (shared) - 원격 IP 모듈이 응답으로 공유되었다면 모듈이 성공적으로 로드됐다는 의미

6) edit the file

sudo nano /etc/httpd/conf/httpd.conf

Add this line to enable Proxy Protocol - Listen 80 다음 줄에 삽입

>> RemoteIPProxyProtocol On

7) repeat #01 5), 6)

# NLB DNS
15.248.a.a - - [19/Jul/2024:10:12:26 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- NLB와 EC2 instance 사이에 proxy protocol이 작동한다는 것을 증명

References

Udemy, Pass the AWS Certified Advanced Networking Specialty Certification ANS-C01. Taught by an AWS Networking and VPC Expert!, Section 18: Elastic Load Balancers

AWS products

sarahee — Wed, 10 Jul 2024 16:34:20 +0900

CloudFront: 뛰어난 성능, 보안 및 개발자 편의를 위해 구축된 콘텐츠 전송 네트워크(CDN) 서비스
CloudWatch: 온프레미스 및 기타 클라우드에서 리소스 및 애플리케이션을 관측하고 모니터링
CloudTrail: AWS와 하이브리드 및 멀티클라우드 환경에서 사용자 활동과 API 사용량 추적
Snowball: 페타바이트 규모의 데이터를 AWS로 마이그레이션
Aurora: 기본 제공 보안, 연속적인 백업, 서버리스 컴퓨팅, 최대 15개의 읽기 전용 복제본, 자동 다중 리전 복제 및 다른 AWS 서비스와의 통합을 제공
Redshift: SQL을 사용하여 여러 데이터 웨어하우스, 운영 데이터베이스 및 데이터 레이크에서 정형 데이터 및 반정형 데이터를 분석하고 AWS가 설계한 하드웨어 및 기계 학습을 사용해 어떤 규모에서든 최고의 가격 대비 성능을 지원
Kinesis: 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리하고 분석하는 완전관리형 서비스
Glacier: 최저 비용과 밀리초 단위의 액세스로 데이터를 보관할 수 있는 안전하며 내구성 있는 장기 스토리지 클래스
Macie: 데이터 보안 및 데이터 프라이버시 서비스로서, 기계 학습(ML) 및 패턴 일치를 활용하여 민감한 데이터를 검색하고 보호
Inspector: 규모에 맞는 지속적인 자동 취약성 관리, Amazon EC2 인스턴스, 컨테이너 및 Lambda 함수와 같은 워크로드를 자동으로 검색하고 소프트웨어 취약성과 의도하지 않은 네트워크 노출이 있는지 스캔
Athena: 오픈소스 프레임워크에 구축된 서버리스 대화형 분석 서비스로 개방형 테이블과 파일 형식을 지원, 페타바이트 규모의 데이터를 상주 위치에서 분석하는 간소화되고 유연한 방식을 제공
FSx for Windows File Server: Windows Server에 구축된 완전관리형 공유 스토리지와 함께 다양한 데이터 액세스, 데이터 관리 기능을 제공
FSx for Lustre: 널리 사용되는 Lustre 파일 시스템의 확장성과 성능을 가진 완전관리형 공유 스토리지를 제공
Rekognition: 기계 학습을 통해 이미지 인식 및 비디오 분석을 자동화하고 비용을 절감
SageMaker: 완전관리형 인프라, 도구 및 워크플로를 활용하여 모든 사용 사례에 적합한 기계 학습(ML) 모델을 구축, 훈련 및 배포
Fargate: 컨테이너에 적합한 서버리스 컴퓨팅
Secrets Manager: 보안 암호의 수명 주기를 중앙에서 관리
Comprehend: 기계 학습을 사용하여 텍스트에서 유용한 인사이트 및 관계를 찾아내는 자연어 처리(NLP) 서비스
Glue: 분석, 기계 학습(ML) 및 애플리케이션 개발을 위해 여러 소스에서 데이터를 쉽게 탐색, 준비, 이동 및 통합할 수 있도록 하는 확장 가능한 서버리스 데이터 통합 서비스
Fargate: 컨테이너에 적합한 서버리스 컴퓨팅

port 1433 is the default port for SQL Server communication

API Gateway + Lambda
CloudFront + ALB + ASG
CloudFront + S3
ALB + ASG with Multi-AZ

[AWS] SAA-C03#10: VPC lab(3)

sarahee — Tue, 2 Jul 2024 18:24:40 +0900

VPC Components Diagram

AWS Site-to-Site VPN

기업 데이터 센터를 AWS와 비공개로 연결하기 위해 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 함
공용 인터넷을 통해 사설 Site-to-Site VPN 연결

Site-to-Site VPN Connection

고객 게이트웨이가 있는 기업 데이터 센터와 가상 프라이빗 게이트웨이를 갖춘 VPC가 있음
온프레미스 고객에게 게이트웨이를 어떻게 구축해야 할까?

-> 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있음

고객 게이트웨이의 공용 IP를 사용해서 VGW와 CGW를 연결하면 됨

-> 고객 게이트웨이를 비공개로 남겨 사설 IP를 갖는 경우, 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있음
NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용해야 함

+ 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동함

+ 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 함(그렇지 않으면 연결되지 않음)

AWS VPN CloudHub

VGW를 갖춘 VPC가 있고, 고객 네트워크와 데이터 센터마다 고객 게이트웨이가 마련된 상황

Hands-on#0n - Site-to-Site VPN

1) create customer gateways

- Site-to-Site VPN 연결을 구성하기 위해서는 온프레미스 호스팅이 된 고객 게이트웨이가 필요하므로

- create Site-to-Site VPN connections ...

Direct Connect (DX)

원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 뜻함
DX를 사용할 때는 전용 연결을 생성해야 하고, AWS DX 로케이션을 사용함

VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능

설치 기간이 한 달보다 길어질 때도 있음

Direct Connect Gateway

다른 리전에 있는 하나 이상의 VPC와 연결할 경우

Direct Connect - Resiliency

복원력, 아키텍처 모드

핵심 워크로드의 복원력을 높이기 위해서는 여러 DX를 설치하는 것이 좋음
기업 데이터 센터가 2개이고 DX location도 둘일 때 중복이 발생 - 프라이빗 VIF가 하나 있는데 다른 곳에 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 DX 하나가 망가져도 다른 하나가 예비로 남아있기 때문에 복원력이 강해짐

핵심 워크로드 복원력을 최대로 끌어올리고 싶다면, (Maximum Resiliency for Critical Workloads)

각 DX location에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있음

Transit Gateway

네트워크 토폴로지 복잡성 문제로 만듦

IP Multicast할 때 사용

Transit Gateway: Site-to-Site VPN ECMP

Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리는 경우

- ECMP: Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략

Transit Gateway: throughput with ECMP

VPN을 Transit Gateway로 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성됨 (동일한 Transit Gateway에 모두 전이적으로 연결되기 때문)

VPC - Traffic Mirroring

사례: 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결

IPv6 Troubleshooting

IPv4는 VPC 및 서브넷에서 비활성화될 수 없음
IPv6가 활성화된 VPC가 있을 때, 서브넷에서 EC2 인스턴스를 실행할 수 없다고 하면 인스턴스가 IPv6를 받지 못해서가 아님 (실제로 공간이 크고 EC2 인스턴스를 위한 IPv6도 충분하기 때문)

-> 진짜 원인은 서브넷이나 VPC에 이용 가능한 IPv4가 없기 때문

-> solution: 서브넷에 IPv4 CIDR를 생성하는 것 (create a new IPv4 CIDR in your subnet)

Hands-on#0n -

1) VPC Edit CIDRs - Amazon-provided IPv6 CIDR block

2) Subnet - edit IPv6 CIDRs > subnet CIDR block

3) Subnet - edit subnet settings > auto-assign IP settings: Enable auto-assign IPv6 address

4) Instance (BastionHost) - networking: Manage IP addresses > eth0: IPv6 addresses Auto-assign

5) 해당 instance security group edit inbound rules - add SSH IPv6

Test your IPv6

6) Route tables - Public routes > IPv6 target: local로 설정되어 있음

Egress-only Internet Gateway

송신 전용 인터넷 게이트웨이, NAT Gateway와 비슷하지만 IPv6 전용

Hands-on#0n - Egress only internet gateway

1) create egress only internet gateway (DemoEIGW)

2) private route tables edit routes - ::/0, eggress only internet gateway

-> 사설 서브넷의 EC2 인스턴스가 IPv6로 인터넷에 액세스하지만 인터넷에는 도달하지 못함

VPC Section Summary

01. CIDR: IP Range

02. VPC: virtual private cloud, IPv4와 IPv6를 위해 작동함

03. Subnets: CIDR를 정의하는 AZ에 연결됨, public/private

04. Internet Gateway: at the VPC level, public subnet은 인터넷 게이트웨이 연결시키고, 퍼블릭 서브넷에서부터 인터넷 게이트웨이로 경로 생성

05. Route Tables: 네트워크가 VPC 내에서 흐르도록 하는 키, 수정됨, 인터넷 게이트웨이 경로들, VPC Peering connections, VPC Endpoints 등 포함

06. Bastion Host: SSH에 들어갈 수 있는 public EC2 instance, 비공개 서브넷의 다른 EC2 인스턴스들과 SSH 연결

07. NAT Instances: 퍼블릭 서브넷에 배포된 EC2 인스턴스, 프라이빗 서브넷의 EC2 인스턴스에게 인터넷 접근을 제공, 오래되었고 사용이 권장되지 않고 있기 때문에 소스 / 대상 확인 플래그를 비활성화해야 함 (그렇게 해야 작동을 할 것이고 보안 그룹 규칙을 수정할 수 있음)

08. NAT Gateway: 프라이빗 EC2 인스턴스에 확장 가능한 인터넷 접근을 제공하고, 요청의 타켓이 IPv4 주소일 때 사용

09. NACL: 네트워크 ACL, 서브넷 레벨에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙, stateless 상태라 인바운드와 아웃바운드 규칙은 항상 평가되고 있음

10. Security Groups: Stateful 상태 - 인바운드가 허용되었을 경우 아웃바운드도 자동적으로 허용되고 그 반대도 마찬가지, 보안 그룹 규칙은 EC2 인스턴스 레벨에 적용됨

11. VPC Peering: 두 개의 VPC를 연결, 겹치지 않는 CIDR을 가지는 경우에 해당, VPC 피어링 연결은 비전이적 (따라서 세 개의 VPC를 연결하고자 한다면 세 개의 VPC 피어링 연결이 필요함)

12. VPC Endpoints: 프라이빗 접근을 허용 - VPC 내의 AWS 서비스라면 Amazon S3, DynamoDB, CloudFormation, SSM 등 무엇이든 가능 (Amazon S3와 DynamoDB에는 게이트웨이 엔드포인트가 있는 것도 보았고 나머지는 모두 인터페이스 엔드포인트)

13. VPC Flow Logs: VPC 내의 모든 패킷에 관련된 로그 레벨의 메타데이터를 갖는 데 가장 좋은 방법, 허용과 비허용 트래픽과 관련된 정보도 조금 있음, VPC 서브넷이나 ENA 레벨에서 생성 (Amazon S3로 전송되어 분석되고 Athena에서 분석될 수 있었으며, CloudWatchLogs로 전송되어 CloudWatchLog Insights를 통해 분석될 수도 있었음)

VPC를 데이터 센터로 연결하기 위한 두 가지 방법

14. 1) Site-to-Site VPN: 공공 인터넷을 통한 VPN 연결이기 때문에 AWS에 버추얼 비공개 게이트웨이를 생성해야 하고 데이터 센터에 고객 게이트웨이를 생성하고 그 후에 VPN 연결을 설립, 여러개의 VPN 연결을 설립할 때 같은 virtual private gateway를 사용하면 VPN CloudHub를 사용해서 hub-and-spoke VPN모델을 만들어 사이트들을 연결할 수 있기도 함

15. 2) Direct Connect: 연결이 완전히 프라이빗 상태, 공공 인터넷을 통하지 않지만 설립하는 데에 시간이 소요됨, 데이터 센터를 Direct Connect 위치로 연결해야 작동함 (더 복잡하지만 더 보안적으로 안전함, 연결도 안정적)

16. Direct Connect Gateway: 다른 AWS 리전의 많은 VPC와 Direct Connect를 만들기 위한 것

17. AWS PrivateLink / VPC Endpoint Services: 고객 VPC에 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결하기 위한 것, 좋은 점은 VPC 피어링이나 공공 인터넷이나 NAT 게이트웨이나 라우팅 테이블을 요구하지 않음, 주로 Network Load Balancer와 ENI와만 사용됨 - VPC 내의 서비스를 네트워크를 노출시키지 않고 수백, 수천개의 고객 VPC에게 노출시킬 수 있도록 함

18. ClassicLink: EC2-Classic 인스턴스를 VPC로 비공개로 연결하기 위한 것, 사용이 권장되지 않음

19. Transit Gateway: VPC, VPN, 그리고 Direct Connect를 위한 전송 피어링 연결

20. Traffic Mirroring: 네트워크 트래픽을 ENI에서 복사하여 분석을 하는 것

21. Egress-only Internet Gateway: NAT Gateway와 비슷하지만 IPv6 트래픽이 인터넷 밖으로 가는 것을 위한 것

Networking Costs in AWS per GB - Simplified

첫번째 AZ에 EC2 인스턴스가 있을 경우 EC2 인스턴스로 향하는 트래픽은 무료

같은 가용영역 내 두 EC2 인스턴스 간 트래픽은 사설 IP로 통신할 시 무료

같은 리전 내 다른 두 AZ에 있는 EC2 인스턴스 두 개가 소통하기 위해 공용 IP나 탄력적 IP를 사용하는 경우, 청구 비용은 GB당 2센트(사설 IP를 사용할 경우 반으로 절감)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

[AWS] SAA-C03#09: VPC lab(2)

sarahee — Tue, 2 Jul 2024 15:43:47 +0900

VPC Components Diagram

VPC Peering

다양한 리전과 계정에서 VPC를 생성할 수 있는데, AWS 네트워크를 통해 연결하고 싶을 때 사용
왜 필요한가? VPC가 모두 같은 네트워크에서 작동하도록 만들기 위해

서로 다른 VPC가 통신하려면 VPC 피어링을 활성화해야 함

A-B, B-C가 연결되어 있더라도 A와 C의 VPC 피어링 연결을 활성화해야 그 둘이 통신할 수 있음

VPC Peering - Good to know

다른 계정 간에도 가능 - 계정 A에서 계정 B로 VPC 연결이 가능
리전 간 연결도 가능

Hands-on#05 - VPC Peering

1) edit default VPC name: DefaultVPC

2) launch Instance (DefaultVPCInstance)
- private IPv4 address: 172.31.0.0/16 (PrivateInstance: 10.0.0.0/16, 다른 VPC)
- BastionHost IP(10.x.x.x)로 DefaultVPCInstance ssh에서 curl 명령시 연결되지 않음

3) create Peering connections
- VPC ID (Requester): DemoVPC, 10.0.0.0/16
- VPC ID (Accepter): DefaultVPC, 172.31.0.0/16

+ Actions: Accept request

4) edit default Route tables name: DefaultVPCMainRouteTable
5) public route table - add Routes > peering connection
- DefaultVPC IPv4 CIDR(172.31.0.0/16)

6) default route table - add Routes > peering connection - 10.0.0.0/16

(The destination CIDR block 10.0.0.0/16 is equal to or more specific than one of this VPC's CIDR blocks. This route can target only an interface or an instance.)

VPC Endpoints (AWS PrivateLink)

프라이빗 서브넷의 EC2 인스턴스를 VPC 엔드포인트를 거쳐 직접 Amazon SNS 서비스에 연결할 수 있음, 이 때 네트워크가 AWS 내에서만 이루어짐

VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 프라이빗으로 액세스하므로 AWS에 있는 모든 서비스에 액세스할 때 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용할 수 있음

Types of Endpoints

1. Interface Endpoints (powered by PrivateLink)

인터페이스 엔드포인트는 ENI를 프로비저닝하는데 ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트임

ENI가 있으면 반드시 보안 그룹을 연결해야 함, 대부분의 AWS 서비스를 지원함

2. Gateway Endpoints

게이트웨이를 프로비저닝, 게이트웨이는 라우팅 테이블의 대상이 되어야 함

IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐임

게이트웨이 엔드포인트 대상: Amazon S3, DynamoDB

Gateway or Interface Endpoint for S3?

Amazon S3에 액세스하는 방법 중 게이트웨이를 선택하는 편이 대부분 유리함 - 라우팅 테이블만 수정하면 되기 때문

인터페이스 엔드포인트가 권장되는 경우: 온프레미스에서 액세스해야 할 필요가 있을 때, 다른 VPC에 연결할 때

Hands-on#05 - VPC Endpoints

7) PrivateInstance > Security - Modify IAM role > role 생성 후 추가

- create role: AWS service, EC2, policies-AmazonS3ReadOnlyAccess

8) BastionHost > PrivateInstance ssh connect + 명령 입력

aws s3 ls
curl google.com

9) Private Route Table의 NAT Gateway로 인터넷에 연결하는 라우트 0.0.0.0/0 삭제

- 이 인스턴스가 인터넷에 접속하지 못하게 하도록

- 8번 동일 명령 실행되지 않음

-> VPC 엔드포인트를 통해 Amazon S3에 프라이빗 접속이 가능해짐

10) VPC Endpoints create (DemoVPC) - 아래 둘 중 Gateway endpoints로 생성

Interface

- service name: 맨 상단(aws.sagemaker.ap-northeast-2.notebook)

- subnets: Private subnet A, B 지정

Gateway

- service name: com.amazonaws.ap-northeast-2.s3

- Route tables: PrivateRouteTable

-> PrivateRouteTable routes edit 시 NAT Gateway 생성되어 있음

11) 이후 PrivateInstance ssh connect 후 명령 실행

- CLI 리전은 기본적으로 us-east-1으로 설정됨

# 해당하는 리전으로 입력
aws s3 ls --region ap-northeast-2

VPC Flow Logs

인터페이스로 들어오는 IP 트래픽에서 정보를 포착할 수 있음

Hands-on#06 - VPC Flow Logs

1) DemoVPC create flow log (DemoS3FlowLog)

- send to an Amazon S3 bucket
- 2)의 buckets properties ARN(Amazon Resource Name) 붙여넣기

2) create S3 (demo-(alias) vpc-flow-logs-v2)

3) DemoVPC create flow log 2nd (DemoFlowLogCWLogs)
- send to CloudWatch Logs

- 4)에서 생성한 flowlogsRole

4) create IAM role
- type: custom trust policy

"Principal": {
"Service": "vpc-flow-logs.amazonaws.com"
},

- CloudWatchLogsFullAccess

- role name: flowlogsRole

5) CloudWatch create Log groups (VPCFlowLogs)

6) S3 Buckets / CloudWatch Log groups 확인

- BastionHost network interface ID에 해당하는 CloudWatch log streams: EC2 인스턴스에서 일어나고 있는 트래픽

7) Amazon Athena를 사용해서 S3 버킷에 들어가는 데이터 쿼리 연습
(1) query editor - settings - S3에서 생성한 bucket 추가

- S3에서 create bucket (demo-athena-(alias)-v2)

search > aws vpc logs athena query 붙여넣기

CREATE EXTERNAL TABLE IF NOT EXISTS `vpc_flow_logs` (
  version int,
  account_id string,
  interface_id string,
  srcaddr string,
  dstaddr string,
  srcport int,
  dstport int,
  protocol bigint,
  packets bigint,
  bytes bigint,
  start bigint,
  `end` bigint,
  action string,
  log_status string,
  vpc_id string,
  subnet_id string,
  instance_id string,
  tcp_flags int,
  type string,
  pkt_srcaddr string,
  pkt_dstaddr string,
  region string,
  az_id string,
  sublocation_type string,
  sublocation_id string,
  pkt_src_aws_service string,
  pkt_dst_aws_service string,
  flow_direction string,
  traffic_path int
)
PARTITIONED BY (`date` date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/'
TBLPROPERTIES ("skip.header.line.count"="1");

- query LOCATION에 - S3 region url 대체 (demo-(alias) vpc-flow-logs-v2)

(2) query 변경

ALTER TABLE vpc_flow_logs
ADD PARTITION (`date`='YYYY-MM-dd')
LOCATION 's3://DOC-EXAMPLE-BUCKET/prefix/AWSLogs/{account_id}/vpcflowlogs/{region_code}/YYYY/MM/dd';

- S3 일자까지 클릭 후 properties S3 URL 붙여넣기

- query results: 테이블에 파티션 하나 추가

(3) 데이터 쿼리

SELECT day_of_week(date) AS
  day,
  date,
  interface_id,
  srcaddr,
  action,
  protocol
FROM vpc_flow_logs
WHERE action = 'REJECT' AND protocol = 6
LIMIT 100;

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

[AWS] SAA-C03#08: VPC lab(1)

sarahee — Fri, 28 Jun 2024 18:56:32 +0900

VPC Components Diagram

Understanding CIDR - IPv4

클래스 없는 도메인 간 라우팅: Classless Inter-Domain Routing

IP address range
1) ww.xx.yy.zz/32 : one IP
2) 0.0.0.0/0 : all IPs
3) we can define 192.168.0.0/26 : 192.168.0.0 - 192.168.0.63 (64 IP addresses)

octets: 1st . 2nd . 3rd . 4th
/32: no octet can change, /24: last octet can change

https://www.ipaddressguide.com/cidr

Public vs. Private IP (IPv4)

10.0.0.0 - 10.255.255.255 (10.0.0.0/8) <- in big networks
172.16.0.0 - 172.31.255.255 (172.16.0.0/12) <- AWS default VPC in that range
192.168.0.0 - 192.168.255.255 (192.168.0.0/16) <- e.g., home networks

Default VPC Walkthrough

새로운 AWS 계정은 모두 기본 VPC가 있음, 새로운 EC2 인스턴스는 서브넷을 지정하지 않으면 기본 VPC에 실행됨

VPC in AWS - IPv4

단일 AWS 리전에 여러 VPC를 둘 수 있음, 리전 당 최대 5개까지 가능(늘릴 수 있음), VPC마다 할당된 CIDR는 다섯 개
각 CIDR의 최소 크기는 /28, IP 주소는 최소 16개(2^4), 최대 크기는 /16, IP 주소는 최대 65,536개
VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용됨
VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의할 것

VPC - Subnet (IPv4)

서브넷이란: VPC 내부에 있는 IPv4 주소의 부분 범위
범위 내 AWS가 IP 주소 다섯 개를 예약함

Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are:
.0: network address
.1: reserved by AWS for the VPC router
.2: reserved by AWS for mapping to Amazon-provided DNS
.3: reserved by AWS for future use
.255: network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved

EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때, /27 서브넷은 사용할 수 없음 (32 - 5 = 27 < 29)

Hands-on#01 - Adding Subnets

1) VPC 생성
2) Public/Private Subnet 생성

Internet Gateway (IGW)

인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 하는 EC2 인스턴스나 람다 함수 등
수평 확장, VPC와 별개로 생성해야 함
VPC는 인터넷 Gateway 하나에만 연결됨
VPC에 인터넷 Gateway를 만드는 정도로는 서브넷에 인터넷 액세스를 제공하지 못함, 라우팅 테이블도 수정해야 함

∴ 공용 서브넷에 공용 EC2 인스턴스 만들기 -> 라우팅 테이블을 수정 -> EC2 인스턴스를 라우터에 연결 -> 인터넷 Gateway에 연결

Hands-on#02 - Adding Internet Gateway & Editing Route Tables

1) launch instance (BastionHost)
- 퍼블릭 서브넷을 위한 자동 할당 퍼블릭 IPv4 주소 활성화 시 Network settings에서 Auto-assign public IP 활성화(enable)된 상태
2) Internet gateways 생성 및 attach to VPC
- VPC에 인터넷 액세스 제공
3) public/private route table 생성
- subnet associations 추가
- routes 0.0.0.0/0 target Internet GW 추가

4) Instance connect

Bastion Hosts

사용자가 프라이빗 서브넷에 없는 EC2 인스턴스에 액세스하고자 함, 이 때 배스천 호스트를 통해 프라이빗 EC2 인스턴스에 SSH로 액세스할 수 있으며 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 함

배스천 호스트를 위해서는,
- 보안 그룹이 반드시 인터넷 액세스를 허용해야 함(기업의 퍼블릭 CIDR 액세스, 사용자 인터넷 액세스만 허용하는 등 EC2 보안 그룹을 제한하여 인프라 보안상 위험 방지)
- 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 함(포트 22번이 배스천호스트의 프라이빗 IP가 되거나 배스천 호스트의 보안 그룹이 되는 셈)

Hands-on#03 - NAT Instance

1) launch instance (PrivateInstance)
- private, network settings - Inbound Security Group Rules custom (Allow SSH from the Bastion Host)

- 프라이빗 서브넷에 위치하므로 EC2 인스턴스로 연결할 수 없음 (∵ 인터넷 게이트웨이 라우팅 테이블을 수정하면 이 서브넷이 공개되기 때문)

2) public instance 실행 후 SSH

# copy + paste
vi EC2KeyPair.pem

chmod 0400 EC2KeyPair.pem
ssh ec2-user@(private IP) -i EC2KeyPair.pem

# doesn't work
ping google.com

- private subnet의 Amazon Linux 2 AMI에 SSH 액세스 실행

NAT Instance (outddated, but still at the exam)

NAT: 네트워크 주소 변환, 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용함
NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 함

NAT 인스턴스의 작동 방식: 공용 서브넷에 NAT 인스턴스를 생성하고, 거기에 탄력적 IP를 연결, 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 함

Hands-on#03 - NAT Instance

3) launch instance (NAT Instance)

- Community AMIs - architectures: x86_64bit, vpc-nat

- Security group name: nat-instance-sg
- Security group rule: add HTTP, HTTPS
4) Change source/destination check
- Stop to allow your instance to send and receive traffic when the source or destination is not itself.

- NAT 인스턴스 자체가 소스 및 목적지가 아니라면 트래픽을 송수신할 수 있어야 함

5) private Route Table 인터넷 통신하기 위한 인스턴스 추가
- routes: 0.0.0.0/0 NAT Instance
6) NAT Instance 포트 추가
- All ICMP
7) PrivateInstance ping google.com
- BistionHost SSH connect > ssh Private

NAT Gateway

AWS-managed NAT, 높은 대역폭, 가용성이 높고 관리할 필요가 없음

특정 AZ에서 생성되고 탄력적 IP를 이어 받음

NAT Gateway with High Availabiltiy

AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있음

Hands-on#04 - NAT Gateway

1) create NAT gateway
- subnet: public subnet A
- Elastic IP allocation

2) edit private routes
- 기존 NAT Instance stop/terminal 시 status: Blackhole로 변경됨
- NAT Instance network interface -> NAT Gateway로 변경

Security Groups & NACLs

NACL: 요청이 EC2 인스턴스 내부로 이동하는 것

Network Access Control List (NACL)

서브넷을 오가는 트래픽을 제어하는 방화벽
서브넷마다 하나의 NACL이 있고, 새로운 서브넷에는 기본 NACL이 할당됨

1-32766번 (우선순위가 제일 높은 것은 1)
newly created NACLs will deny everything

Default NACL

연결된 서브넷을 가지고 inbound/outbound의 모든 요청을 허용하는 특수성을 가짐
기본 NACL을 수정하지 않는 것을 추천
기본적으로 NACL이 서브넷과 연결된다면 모든 것이 드나들도록 허용된다는 뜻

Ephemeral Ports

클라이언트와 서버가 연결되면 포트를 사용해야 함

Create NACL rules for each target subnets CIDR

다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함, CIDR 사용 시 서브넷이 고유의 CIDR를 갖기 때문

NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야 함

Hands-on#04 - NACLs

3) BastionHost ssh 연결

sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd
echo "hello world" > /var/www/html/index.html
# 이전 명령을 sudo로 실행
sudo !!

# if permission denied
sudo su
echo "hello world" > /var/www/html/index.html

4) add security group HTTP

- public IP 접속 허용

5) edit Network ACLs inbound/outbound rules (for test)

- inbound rule: 80, type: http, source: 0.0.0.0/0, Deny
or outbound rules 100 Deny

- public IP 접속 차단

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27

[AWS] SAA-C03#07: ELB & ASG

sarahee — Tue, 25 Jun 2024 19:18:51 +0900

Vertical Scalability

수직 확장성, 인스턴스의 크기를 확장

Horizental Scalability

수평 확장, 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법, 분배 시스템

High Availability

수직 확장, 적어도 2 데이터 센터(AZ)에서 애플리케이션을 구동시키는 것

High Availability & Scalability For EC2

scale out / in

What is load balancing?

서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 instances 또는 서버들로 전달하는 역할
EC2 인스턴스가 3개, 인스턴스 앞에는 Load Balancer, 사용자는 ELB로 바로 연결됨

Why use a load balancer?

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

Why use an Elastic Load Balancer?

a managed load balancer

다른 서비스들과 통합 가능

Health Checks

EC2 인스턴스가 잘 동작하는지 상태 확인, 포트와 라우트에서 이루어짐
e.g., protocol: HTTP, port: 4567, endpoint: /health -> 인스턴스 응답 200(OK)이 아니라면 unhealthy하다고 판단

Types of load balancer on AWS

Classic load balancer: HTTP, HTTPS, TCP, SSL (secure TCP), 현재는 AWS에서 지원하지 않음

Application Load Balancer(ALB): HTTP, HTTPS, WebSocket
Network Load Balancer(NLB): TCP, TLS (secure TCP), UDP
Gateway Load Balancer(GLB): Operates at layer 3 (Network layer)

Application Load Balancer (v2)

HTTP/2와 WebSocket이 가능
URL 대상 경로에 의한 라우팅이 가능함

Application Load Balancer (v2) Target Groups

EC2 인스턴스가 대상 그룹, ECS tasks, Lambda functions

Network Load Balancer (v2)

가용 영역별로 하나의 고정 IP를 갖는다는 점

Network Load Balancer - Target Groups

NLB를 ALB 앞에 배치하는 경우

NLB: 고정 IP 주소를 얻음, ALB: HTTP 유형의 트래픽을 처리하는 규칙을 얻음

Gateway Load Balancer

모든 로드밸런서보다 낮은 계층에서 동작

Users - GWLB - Target Group - GWLB - Application

uses the GENEVE protocol on port 6081

Sticky Sessions (Session Affinity)

고정성, 고정 세션을 실행, 1번째 클라이언트가 요청을 생성해 EC2에서 첫번째 인스턴스로 이동한다면, 새로운 요청을 했을 때에도 동일한 인스턴스로 이동하도록 함

Sticky Sessions - Cookie Names

고정 세션에는 2가지 유형의 쿠키가 있음, 애플리케이션 기반, 기간 기반 쿠키

Application-based Cookies

Logging IP traffic using Flow Logs

Target Group attributes stickiness 활성 시

Cross-Zone Load Balancing

EC2 인스턴스 2개짜리 로드 밸런서

Without Cross Zone Load Balancing: 각 가용영역 안에서 부하 분산됨

ALB의 Cross-zone LB는 항상 켜져 있음

SSL/TLS - Basics

SSL 인증서: 클라이언트와 로드 밸런서 사이 트래픽이 이동하는 동안 암호화, 전송 중(in-flight) 암호화

송신자-수신자 측에서만 복호화 가능

SSL: 보안 소켓 계층을 의미, 연결을 암호화하는데 사용
TLS: 새로운 버전의 SSL, 전송 계층 보안

퍼블릭 인증서는 인증 기관(CA)에서 발급, 인증 기관에는 Comodo, Symantec, GoDaddy, ...

Load Balancer - SSL Certificates

ACM: AWS Certificate Manager

SSL - Server Name Indication

SNI: 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트에 지원할 수 있게 해줌

What's an Auto Scaling Group?

자동화

ASG(Auto Scaling Group)의 목표: scale out - 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나, scale in - 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것

로드 밸런싱과 페어링하는 경우

Auto Scaling - CloudWatch Alarms & Scaling

CloudWatch 기반으로 ASG를 스케일 인 및 아웃할 수 있음

지표(metric), ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스가 필요 -> 지표에 따라 경보가 울림 -> 경보가 ASG의 스케일링 활동을 유발함 -> 오토 스케일링 그룹이라고 불림 (경보에 의해 내부에서 자동적인 스케일링이 이루어짐)

Auto Scaling Groups - Dynamic Scaling Policies

세 가지 유형

Target Tracking Scaling(대상 추적 스케일링): 기본 기준선을 기준으로 상시 사용이 가능하도록
Simple / Step Scaling: CloudWatch 알람으로 CPU 사용률에 따라 유닛 하나를 추가/제거하는 설정 가능
Scheduled Actions

Auto Scaling Groups - Predictive Scaling

CPU 사용량, 인스턴스 요청이 갈 때마다 연산이 수행되어야 하므로
EC2 인스턴스를 갖는 오토스케일링 그룹, e.g., 요청 수 지표는 3
애플리케이션이 네트워크에 연결된 경우 평균 네트워크 입출력량을 기반으로 스케일링을 수행해서 임계값에 도달할 때 스케일링ㅇ을 수행하도록 설정
직접 CloudWatch에서 애플리케이션 별 지표를 설정하고 이를 기반으로 스케일링 정책을 변경

Auto Scaling Groups - Scaling Cooldowns

EC2 인스턴스 구성 시간을 단축하고 요청을 속히

search > install stress amazon linux 2

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

stress -c 4

[Quiz#05]

1) EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것은 수직 확장성

2) EC2 인스턴스 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 수평 확장성

3) ELB는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함
- AWS 기반 인프라가 변경되어도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유

4) Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요? - ELB가 고정 세션을 활성화하지 않은 것
- ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줌.(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줌

5) ALB
- X-Forwarded-Port: 클라이언트의 요청 포트를 가져오기 위해 사용
- X-Forwarded-Proto: 클라이언트의 요청 프로토콜을 가져오기 위해 사용

- X-Forwarded-For: (웹사이트로 연결된) 클라이언트의 IP 주소를 포함하는 헤더

6) Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?

- ELB 상태 확인 활성화 -> ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됨

7) NLB: 가장 높은 성능, 가장 낮은 지연 시간

8) ALB 지원 프로토콜: HTTP, HTTPS, WebSocket / NLB: TCP, UDP

9) ALB는 트래픽을 다른 대상 그룹으로 라우팅할 수 있음 - 기반: 요청 URL 경로, 호스트 이름, HTTP 헤더, 쿼리 문자열, 소스 IP 주소

10) ALB 대상 그룹에 등록된 대상: EC2 인스턴스, 사설 IP 주소, Lambda 함수 등 (NLB는 등록된 대상이 될 수 없음)

11) ALB에 탄력적 IP를 연결할 수 없음, NLB는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있음. ALB와 CLB를 정적 DNS 이름으로 사용할 수 있음

12) ELB가 선점하고 있는 쿠키 이름: AWSALB, AWSALBAPP, AWSALBTG

13) 영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됨

14) ALB 기능 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 기능: 서버 이름 표식(SNI)

15) 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 ALB에서 각 호스트 이름에 HTTPS를 구성하려고 할 때 ALB에 서버 이름 표식(SNI)을 사용함

16) 오토 스케일링 그룹은 스케일 아웃 시, 구성된 최대 용량을 넘어설 수 없음

17) Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?
- 오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있음. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행함

18) 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링할 때: 백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않기에 CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성 해야 함
- CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일링하기 위한 CloudWatch 경보를 생성

19) ALB의 크기를 수동으로 조정해 EC2 인스턴스의 평균 연결 개수를 약 1,000개가 되도록 조정 정책을 정의하려고 할 때, 대상 추적 조정 정책을 수행함
- ALB만이 EC2 인스턴스로 액세스할 수 있게 하는 가장 안전한 방법임. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙⭐️

20) 한 웹 사이트가 애플리케이션 로드 밸런서 뒤에 있는 오토 스케일링 그룹의 EC2 인스턴스에서 호스팅되고 있습니다. 현재 HTTP로 서비스 중인 웹 사이트를 HTTPS로 바꾸는 작업을 진행하고 있습니다. ACM 인증서를 발급받아 애플리케이션 로드 밸런서에 적용한 상태입니다. 사용자들이 HTTP가 아닌 HTTPS를 사용해 웹 사이트에 접속하게 하려면 어떻게 해야 합니까?
- 애플리케이션 로드 밸런서가 HTTP를 HTTPS로 리디렉션하도록 설정함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 8

[AWS] SAA-C03#06: EC2 instance storage

sarahee — Fri, 21 Jun 2024 10:16:31 +0900

What's an EBS Volume?

EBS(Elastic Block Store): 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브

특정 가용 영역에서만 가능(us-east-1a에서 생성한 경우 us-east-1b에서는 생성 불가)

네트워크 USB stick

EBS Volume

네트워크 드라이브, 특정한 AZ에 위치해서 us-east-1a 볼륨이 us-east-1b로 연결 불가(스냅샷을 이용하면 가능)

EBS - Delete on Termination attribute

Delete on Termination 기능이 root 볼륨에는 설정되어 있으며, 새로운 EBS 볼륨에는 체크되어 있지 않다.
- root에서는 인스턴스 종료와 함께 EBS 볼륨이 삭제된다.

이 옵션으로 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있다.

Use case: 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우(데이터를 저장할 경우), 루트 볼륨 삭제 속성을 비활성화 한다.

hands-on

+ search > format EBS volume attach EC2

EBS 볼륨의 가용 영역을 인스턴스와 맞춰줘야 한다.

EBS Snapshots Features

최대 75%까지 저렴한 archive tier, 스냅샷을 옮길 수 있는 기능
아카이브를 복원하는 데 24시간에서 최대 72시간이 걸린다.

EBS 휴지통: 스냅샷 삭제 시 recycle bin으로 이동(보관 기간: 1일 ~ 1년)
FSR(빠른 스냅샷 복원): 지연시간 없애는 기능

AMI Overview

아마존 머신 이미지, EC2 인스턴스를 통해 만든 이미지를 통칭

EC2 Instance Store

EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 연결되어 있다.
장기적으로 데이터를 저장할 스토리지는 될 수 없다.(장기 스토리지: EBS)

EBS Volume Types

gp2/gp3 (SSD): 범용 SSD 그룹, 절충안

io1/io2 (SSD): 최고 성능, 지연 시간이 낮음

st1 (HDD): 저비용

sc1 (HDD): 가장 비용이 적게 드는 볼륨

EBS Volume Types Use cases General Purpose SSD

범용 gp2, IOPS 프로비저닝

gp2: 짧은 지연 시간, 효율적인 비용의 스토리지

시스템 부팅 볼륨에서 크기는 1GiB - 16TiB

gp2/gp3가 비용 효과적인 스토리지

gp3에서는 IOPS 처리량을 독자적으로 설정할 수 있음

EBS Volume Types Use cases

데이터베이스 워크로드에 적합(스토리지를 이용하는 경우)

EBS Multi-Attach - io1/io2 family

하나의 EBS 볼륨을 같은 가용 영역에 있는 여러 EC2 인스턴스에 연결할 수 있도록 한다.

각 인스턴스는 고성능 볼륨에 대한 high-performance volume을 갖는다.

해당 가용 영역 내에서만 EBS 볼륨 연결 가능

한 번에 16개의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다.

EBS Encryption

저장 데이터가 볼륨 내부에 암호화된다
암호화가 동시다발적으로 일어난다.

암호화는 지연 시간에는 거의 영향이 없다.

KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 갖는다.

스냅샷을 복사해 암호화를 푼걸 다시 암호화 활성화한다.

Encryption: encrypt an unencrypted EBS volume

EBS 볼륨 암호화 및 암호화 풀기

볼륨의 EBS 스냅샷을 생성하고, 복사 기능을 통해 EBS 스냅샷을 암호화한다.
-> 스냅샷을 이용해 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화된다.
-> 암호화된 볼륨을 인스턴스 원본에 연결한다.

Amazon EFS - Elastic File System

EFS: 관리형 NFS, 네트워크 파일 시스템

네트워크 파일 시스템이므로 많은 EC2 인스턴스에 마운트될 수 있다.

EC2 인스턴스는 서로 다른 가용성 영역에 있을 수 있다.

가용성이 높고 확장성이 뛰어나며 가격이 비싸다.

Amazon EFS - Elastic File System

사용 사례: 콘텐츠 관리, 웹 서빙, 데이터 공유, wordpress

내부적으로 NFS 프로토콜을 사용한다.

윈도우가 아닌 Linux 기반 AMI와만 호환된다.

EFS - Storage Classes

언제 EFS를 사용해야 하는지, 네트워크 파일 시스템에 어떤 옵션을 설정해야 하는지 - 요구사항을 준수하고 검증

EBS vs EFS - Elastic Block Storage

EBS 볼륨과 EFS 파일 시스템의 차이

EBS 볼륨

1)한 번에 하나의 인스턴스에 첨부된다. (io1, io2 유형 볼륨의 다중 첨부 기능을 사용하는 경우 제외)

2) AZ 수준에서 잠긴다.

...

EFS는 EBS보다 가격대가 높다.

[Quiz#04]

1) us-east-1a에서의 EC2 인스턴스를 종료하여, 이 인스턴스에 연결된 EBS 볼륨을 사용할 수 있게 되었다. 팀원이 us-east-1b의 EC2 인스턴스에 이 볼륨을 연결하려 했으나, 연결이 불가능한 상태이다. 이 경우, EBS 볼륨은 가용 영역으로 제한되어 있으므로(특정 AZ에 맞춰 생성되므로) 스냅샷을 활용하여 다른 AZ 간의 이전을 가능하게 한다.

2) AMI는 특정 AWS 리전에 국한되고, 각 AWS 리전에는 고유한 AMI가 있다.

3) EC2 인스턴스를 생성할 때 부팅 볼륨으로는 gp2, gp3, io1, io2, Magnetic(표준) EBS 볼륨 유형만을 사용할 수 있다.

4) EBS 다중 연결이란? 동일한 EBS 볼륨을 동일한 AZ에 있는 다수의 EC2 인스턴스에 연결할 수 있다.

5) EFS는 네트워크 파일 시스템(NFS)으로 여러 AZ 상에 있는 EC2 인스턴스에 동일한 파일 시스템을 마운트할 수 있게 해준다.

6) EC2 인스턴스 스토어는 최적의 디스크 I/O 성능을 제공한다.(EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황)

7) 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행할 경우, 이는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 한다.

- EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실이라는 문제가 있다 (문제 없이 다시 시작할 수 있음). 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있다는 것다. 또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있다.

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 7

[AWS] SAA-C03#05: EC2 - solution architect associate level

sarahee — Wed, 19 Jun 2024 20:21:02 +0900

Placements Groups

Cluster, Spread(분산, 각 EC2 인스턴스가 여러 AZ에 걸쳐 서로 다른 물리적 하드웨어(랙)에 배치), Partition(분할)

hands-on

EC2- Network & security > Placement Groups

Launch an instance > Advanced details - Placement group에서 설정

Elastic Network Interfaces (ENI)

VPC의 논리적 구성 요소, 가상 네트워크 카드
EC2 인스턴스가 네트워크에 액세스할 수 있게 해준다.

https://aws.amazon.com/blogs/aws/new-elastic-network-interfaces-in-the-virtual-private-cloud/

EC2 Hibernate

절전 모드, 인스턴스 부팅이 빨라진다.

백그라운드에서 RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록된다.

인스턴스를 종료하면 RAM은 삭제되지만, EBS 볼륨에는 여전히 RAM이 덤프된 게 있으니 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.

hands--on

Launch an instance > Advanced details - Stop-Hibernate behavior: Enable

루트 볼륨에 RAM을 저장할 수 있는 공간, 즉 EC2 인스턴스를 저장할 공간이 충분한지 확인 루트 EBS 볼륨이 암호화되었는지 확인

-> Configure storage - Advanced 설정

EC2 Instance connect 시 최근 재시작부터 가동된 시간

uptime

[Quiz#03]

탄력적 네트워크 인터페이스(ENI)는 다른 AZ에 있는 EC2 인스턴스와 연결될 수 없다.(특정 AZ로 국한된다.)

EC2 인스턴스 RAM은 150GB 미만이어야 함, 절전 모드를 활성화하기 위해서는 EC2 인스턴스 루트 볼륨 유형은 EBS 볼륨이어야 함
EC2 절전 모드는 온디맨드 및 예약 인스턴스를 지원함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

[AWS] SAA-C03#04: EC2

sarahee — Tue, 18 Jun 2024 20:14:49 +0900

Amazon EC2

EC2: Elastic compute cloud, AWS에서 제공하는 서비스형 infrastructure

EC2 sizing & configuration options

AWS에서 임대하는 가상 서버인 EC2에서 어떤 것을 선택? EC2 인스턴스 운영체제로 어떤 것을 선택?

OS: Linux, Windows, Mac OS

CPU(compute power & cores), RAM(random-access memory), 부트스트랩 스크립트 등

EC2 User Data

bootstrapping: 머신이 작동될 때 명령을 시작하는 것, 스크립트는 처음 실행할 때 시작

사용자 데이터 스크립트에 작업을 추가할수록 부팅 시 인스턴스가 할 일이 늘어난다.

모든 명령문은 sudo로 실행된다.

EC2 instance types: example

네트워크 성능은 낮음에서 중간 사이

t2 제품군에서 large로 변환하면, 네트워크 성능은 중간, c5d.4xlarge는 CPU, memory, storage 등 달라진다.

t2.micro가 AWS 프리티어

Hands-On: Launching an EC2 Instance running Linux

EC2 인스턴스에서 웹 서버 생성

User data

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

인스턴스 수명 주기 중 단 한번만 실행, 몇 가지를 업데이트하고 HTTP 코드

EC2 Instance Types - Overview

https://aws.amazon.com/ec2/instance-types

컴퓨팅 - Amazon EC2 인스턴스 유형 - AWS

aws.amazon.com

AWS naming convention: example - m5.2xlarge

m: instance class
5: generation
2xlarge: 더 많은 메모리와 사이즈

EC2 Instance Types

compute-intensive tasks
ec2instances.info

Introduction to Security Groups

보안 그룹, 허용 규칙만 포함된다. 보안 그룹끼리 참조할 수도 있다.

EC2 인스턴스에 액세스하려고 할 경우 인스턴스 주변 보안 그룹을 생성해야 한다.(방화벽 생성) -> 보안 그룹은 규칙을 가지게 된다. 그 규칙은 인바운드 트래픽의 여부인데, 외부에서 EC2 인스턴스로 들어오는 것이 허용되면 아웃바운드 트래픽도 수행할 수 있다. 현재 위치에서 인터넷으로 들어오는 것.

Security Groups Deeper Dive

보안 그룹은 EC2 인스턴스의 방화벽이다. 포트로의 액세스를 통제하며 인증된 IP 주소의 범위를 확인해 IPv4인지 IPv6인지 확인한다.

인바운드 네트워크/아웃바운드 네트워크를 통제한다.

Security Groups Good to know

여러 인스턴스에 연결할 수 있다.
보안 그룹과 인스턴스 간의 일대일 관계는 없다.

여러 보안 그룹을 연결할 수 있다.

지역을 전환하면 새 보안 그룹을 생성하거나 다른 VPC를 생성해야 한다.

보안 그룹은 EC2 외부에 있다. -> 트래픽이 차단되면 EC2 인스턴스로는 확인할 수 없다. (EC2 외부의 방화벽이므로)

SSH 액세스를 위해 하나의 별도 보안 그룹을 유지하는 것이 좋다.

time out으로 애플리케이션에 접근할 수 없으면, 보안 그룹의 문제이다.

연결 거부 오류(connection refused)이면 트래픽은 통과했지만, 애플리케이션 문제이거나 실행되지 않는 등 문제이다.

기본적으로 인바운드 트래픽은 blocked, 아웃바운드 트래픽은 authorised

Referencing other security groups Diagram

인바운드 큐칙은 보안 그룹 1의 인바운드를 보안 그룹 2에 허용하는 것
로드 밸런서에서도 나온다.

Classic Ports to know

22: SSH(리눅스 인스턴스 로그인 시)

21: FTP / 22: SFTP / 80: HTTP / 443: HTTPS

3389: RDP(Remote Desktop Protocol, 윈도우 인스턴스에 로그인 시 사용)

HTTP, SSH 등 어떤 것을 시도할 때 time out이 되면, 100% EC2 보안 그룹 때문이다.(EC2 > Security Groups)

How to SSH into your EC2 Instance

ssh ec2-user@(public ipv4 address)
ssh -i EC2Tutorial.pem ec2-user@(public ipv4 address)
chmod 0400 EC2Tutorial.pem (소유자의 읽기 권한)

aws iam list-users 안되는 경우, 자격증명을 찾을 수 없어 aws configure 실행

개인 정보를 입력해두면 이 계정 상의 누구라도 다시 EC2 인스턴스 커넥트 등을 통해 EC2 인스턴스에 접근해서 자격 증명 정보를 실행할 수 있음 -> IAM API key 입력하지 말 것

그 대신 IAM role 이용: 역할을 EC2 인스턴스에 연결해서 자격 증명을 제공

Instances > Actions > Security - Modify IAM role

EC2 Spot Instances

Not suitable for critical jobs or databases

EC2 Dedicated Instances

전용 인스턴스란 자신만의 인스턴스를 자신만의 하드웨어에 갖는다는 것인 반면,

전용 호스트는 물리적 서버 자체에 대한 접근권을 갖고 낮은 수준의 하드웨어에 대한 가시성을 제공해준다.

Which purchasing option is right for me?

On demand - Reserved - Saving Plans - Spot instances - Dedicated Hosts - Capacity Reservations

How to terminate Spot Instances?

원하는 인스턴스 수, 최대 가격, 시작 사양 등 정의 (AMI 등), 언제부터 언제까지 유효한지 등
일회성 요청 or 영구 인스턴스 요청
일회성 요청: 스팟 요청 시 인스턴스 생성 및 스팟 요청은 사라짐
영구 요청: 스팟 요청이 유효한 기간 동안 인스턴스 수도 유효함, 인스턴스가 중지되거나 스팟 가격 기준으로 종료되는 경우

스팟 요청을 취소하고 -> 스팟 인스턴스를 종료

Spot Fleets

스팟 플릿에 스팟 인스턴스를 할당하는 전략을 정의해야 한다.

1) lowestPrice(최저 가격): 스팟 플릿은 가장 낮은 가격인 풀에서 인스턴스를 시작하기 때문에 비용이 최적화된다. 워크로드가 매우 짧은 경우 좋은 옵션

2) diversified: 스팟 인스턴스는 내가 정의한 모든 풀에 분산된다. 가용성과 긴 워크로드에 적합하다.(한 풀이 사라져도 다른 풀은 여전히 활성화되어 있기 때문)

3) capacityOptimized(용량 최적화): 원하는 인스턴스 수에 맞는 최적의 용량을 가진 풀을 갖게 된다.

4) priceCapacityOptimized(recommended)(가격 용량 최적화): 사용 가능한 용량이 가장 큰 풀을 선택하고 그 중 가격이 가장 낮은 풀을 선택, 대부분의 워크로드에 가장 적합한 선택

Spot Fleets: 사용하면 여러 개의 런치 풀과 여러 인스턴스 유형을 정의할 수 있다. 원시 전력만 신경쓰면 된다. 자동으로 가장 낮은 가격으로 스팟 인스턴스 풀을 선택해 추가 비용 절감 가능

- 간단한 스팟 인스턴스 요청을 하는 경우: 원하는 인스턴스 유형과 AZ(Availability Zone)를 정확히 알고 있는 경우
- 스팟 플릿을 요청하는 경우: 조건을 만족하는 모든 인스턴스 유형과 모든 AZ를 선택하라는 것(조건 예: 낮은 가격)

[Quiz#02]

1. 스팟 인스턴스는 단기적인 워크로드에 적합하고, 가장 저렴한 EC2 구매 옵션, EC2 인스턴스를 손실할 우려가 있기 때문에 신뢰도가 떨어진다.(데이터베이스 혹은 중요 업무에는 적합하지 않다.)

2. EC2 인스턴스 내/외의 트래픽을 제어하기 위해 보안 그룹을 사용한다.

3. EC2 예약 인스턴스는 1년 혹은 3년의 기간으로만 예약이 가능하다.

4. 컴퓨팅 최적화 EC2 인스턴스는 고성능 프로세서(배치 처리, 미디어 트랜스코딩, 고성능 컴퓨팅, 과학적 모델링 및 머신 러닝, 전용 게이밍 서버 등)가 필요한 집중 컴퓨팅 워크로드에 적합하다. (고성능 컴퓨팅: HPC)

5. 온디맨드 인스턴스는 가격 예측이 가능한 짧은 경우에 적합, 예약 인스턴스는 장기적인 워크로드에 적합하다.(1년 혹은 3년의 기간)

6. 메모리 최적화 EC2 인스턴스는 메모리에 대규모 데이터 세트가 필요한 워크로드에 적합하다.

7. 스토리지 최적화 EC2 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대해 높은 수준의, 그리고 순차적인 읽기/쓰기 액세스 권한이 필요한 워크로드에 적합하다.

8. 전용 호스트는 높은 수준의 규정 준수가 필요한 기업, 혹은 복잡한 라이선스 모델을 가진 소프트웨어에 적합하다. 가장 비싼 EC2 구매 옵션, 물리적 코어 및 기반 네트워크 소켓 가시성을 기반으로 비용을 책정할 때, 가시성을 확보하기 좋은 구매 옵션

9. 스팟 플릿은 스팟 인스턴스의 집합이고, 선택적으로 온디맨드 인스턴스이다. 스팟 플릿은 가장 낮은 가격으로 스팟 인스턴스를 자동으로 요청할 수 있게 해준다.

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

[AWS] SAA-C03#03: IAM, CLI/CloudShell

sarahee — Tue, 18 Jun 2024 13:52:20 +0900

How can users access AWS?

three options: AWS Management Console, Command Line Interface(CLI), Software Developer Kit(SDK)

don't share your access keys

What's the AWS CLI?

AWS 서비스들과 상호작용할 수 있도록 도와주는 도구 (e.g., aws s3 cp)

What's the AWS SDK?

프로그래밍을 위한 액세스가 가능하도록 하는 것, 코딩을 통해 애플리케이션 내 자체적으로 지원, 프로그래밍 언어

search > aws cli install macos

aws --version

aws-cli/2.16.10 Python/3.11.8 Darwin/23.5.0 exe/x86_64

IAM > Users > (account) > Create access key

region: ap-northeast-2

aws iam list-users

AWS에 액세스하기 위해서는 관리 콘솔을 사용하거나 액세스 키와 비밀 액세스 키를 구성하여 CLI을 구성할 수 있다.

AWS CloudShell는 다음의 AWS 리전에서 사용할 수 있다.

US East (Ohio)
US East (N. Virginia)
US West (N. California)
US West (Oregon)
Asia Pacific (Mumbai)
Asia Pacific (Osaka)
Asia Pacific (Seoul)
Asia Pacific (Sydney)
Asia Pacific (Singapore)
Asia Pacific (Tokyo)
Canada (Central)
Europe (Frankfurt)
Europe (Ireland)
Europe (London)
Europe (Paris)
Europe (Stockholm)
South America (São Paulo)

CloudShell: AWS 클라우드에서 무료로 사용 가능한 터미널

IAM Roles for Services

EC2 인스턴스: 가상 서버, AWS에서 어떤 작업을 수행하려고 할 때 권한을 부여하기 위해 IAM Role을 만들어 이들을 하나의 개체로 만든다. EC2 인스턴스가 AWS에 있는 어떤 정보에 접근(액세스)하려고 할 때 IAM Role을 사용한다.

Common roles: EC2 instance roles, Lambda function roles, roles for CloudFormation

IAM Security Tools

IAM Credentials Reports (account-level)
IAM Accesss Advisor (user-level)

IAM Guidelines & Best Practices

one physical user = one AWS user

never share IAM users & access keys

IAM Section - Summary

Users, Group, Policies, Roles, Security, AWS CLI, AWS SDK, Access Keys, Audit

[Quiz#01]

IAM 사용자 그룹은 다른 사용자 그룹에 속할 수 없다. IAM 사용자만을 포함할 수 있다.

IAM 정책의 문장은 시드, 효과, 원칙, 조치, 리소스, 조건으로 구성된다. (버전은 IAM 정책 자체의 일부이며, 문장의 일부가 아니다.)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

[AWS] SAA-C03#02: IAM

sarahee — Mon, 17 Jun 2024 18:02:39 +0900

Route 53

리전이 필요하지 않음: Global

ref: aws global infrastructure > AWS regional services 제공 서비스 및 가용성 확인

IAM: Users & Groups

Identity and Access Management, Global service
사용자 생성, 그룹에 배치하기 때문에 글로벌 서비스에 해당
Root account created by default + Users
- Groups은 사용자만 배치할 수 있음
- 그룹에 포함되지 않은 사용자가 있을 수 있음(비추천)

- 한 사용자가 다수의 그룹에 속할 수 있음

사용자와 그룹을 구성하는 이유

IAM: Permissions

사용자, 그룹에게 JSON 문서를 지정할 수 있음

최소 권한의 원칙(least privilege principle) 부여

IAM은 글로벌 서비스라 선택할 리전이 없음, 즉 IAM에서 사용자를 생성하면 어디에서나 사용할 수 있음

root를 사용하는 것은 바람직하지 않음, 사용자 생성 필요

IAM Policies Structure

Consists of

1) Version: 2012-10-17 - 정책 언어 버전

2) Id: 정책 식별(optional)

3) Statement

Ststement consists of

(1) Sid: 문장 ID, 문장 식별자(optional)

(2) Effect: 문장이 특정 API에 접근하는걸 허용할 지 거부할 지(Allow/Deny)

(3) Principal: 특정 정책이 적용될 사용자, 계정, 역할

(4) Action: API 호출 목록

(5) Resource: 적용될 action의 리소스 목록

[Troubleshooting#01]

Access denied

You don't have permission to iam:ListUsers. To request access, copy the following text and send it to your AWS administrator. Learn more about troubleshooting access denied errors.

root 계정 IAM > Users > 계정 Permissions policies (0) > Add permissions > Attach policies directly - IAMReadOnlyAccess

User group was not created.
User: arn:aws:iam::058264561455:user/saraheee is not authorized to perform: iam:CreateGroup on resource: arn:aws:iam::058264561455:group/dev because no identity-based policy allows the iam:CreateGroup action

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

[AWS] SAA-C03#01: basic

sarahee — Fri, 14 Jun 2024 13:46:54 +0900

AWS is a Cloud Provider
use on demand and scale easily

Services

AWS Regions

all around the world, names can be us-east-1, eu-west-3

a region is a cluster of data centers

How to choose an AWS Region?

1) Compliance(법률 준수): with data governance and legal requirements

2) Proximity(접근성) to customers: reduced latency

3) Available services within a Region

4) Pricing(요금): pricing varies region to region and is transparent in the service pricing page

AWS Availability Zones

Each region has many availability zones

(usually 3, min is 3, max is 6)

example: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c

- they're separate from each other

- they're connected with high bandwidth, ultra-low latency networking

Tour of the AWS Console

Identity and Access Management (IAM)
Route 53 (DNS service)

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03

[#2 메커니즘] 프라이버시 보호 메커니즘

sarahee — Sat, 18 May 2024 06:00:03 +0900

SGD (Stochastic Gradient Descent)

Laplace Mechanism
Gaussian Mechanism
Exponential Mechanism
Local Sensitivity Sampling (LSS)
Multiplicative Weights Exponential Mechanism (MWEM)
High-Dimensional Matrix Mechanism (HDMM)
Multiplicative Weights Update (MWU)
Projected Gradient Descent (PGD)
PrivBayes
DualQuery

1. 경사 하강법(Stochastic Gradient Descent, SGD)

장점
연속적인 최적화: SGD는 연속적인 최적화를 통해 합성 데이터를 생성할 수 있어, 쿼리 결과에 대한 차이가 최소화된다.
확장성: 대규모 데이터셋에서도 효과적으로 작동한다.

유연성: 다양한 데이터셋과 쿼리 유형에 적용할 수 있다.
단점
수렴 문제: 학습률(lr)과 같은 하이퍼파라미터에 민감하며, 잘못 설정된 경우 수렴하지 않을 수 있다.
비선형 관계: 데이터의 비선형 관계를 다루는 데 한계가 있을 수 있다.

2. Multiplicative Weights Update (MWU) Mechanism

MWU 메커니즘은 적응적으로 쿼리를 선택하고, 각 쿼리의 응답을 업데이트하는 방법이다. 이 방법은 데이터의 각 레코드에 가중치를 할당하고, 각 쿼리 응답에 따라 가중치를 업데이트한다.
장점
적응적 쿼리 선택: 가장 정보가 많은 쿼리를 선택하여 효율성을 높인다.
프라이버시 보호: 프라이버시 예산을 효율적으로 사용한다.
단점
복잡성: 구현이 복잡하고, 계산 비용이 높을 수 있다.
적용 범위 제한: 일부 특정 쿼리 유형에만 효과적일 수 있다.

3. High-Dimensional Matrix Mechanism (HDMM)

HDMM은 고차원 데이터에 대해 최적화된 방식으로 쿼리를 처리하는 메커니즘이다. 쿼리 집합에 대한 응답을 선형 결합으로 표현하고, 이를 통해 최적의 노이즈 추가 방법을 찾아낸다.
장점
고차원 데이터 처리: 고차원 데이터셋에 대해 효과적으로 작동한다.
최적화된 노이즈 추가: 노이즈 추가를 최적화하여 정확도를 높인다.
단점
계산 복잡성: 계산 비용이 높아 대규모 데이터셋에 적용하기 어려울 수 있다.
제한된 쿼리 유형: 일부 쿼리 유형에 제한적일 수 있다.

4. Projected Gradient Descent (PGD)

PGD는 경사 하강법을 사용하는 투영 메커니즘 중 하나로, 최적화 과정에서 정규화 제약 조건을 적용한다. 이는 주어진 제약 조건 내에서 최적의 해를 찾는 데 효과적이다.
장점
정확도: 제약 조건 내에서 최적화하므로, 정확한 결과를 얻을 수 있다.
제약 조건 적용: 다양한 제약 조건을 쉽게 적용할 수 있다.
단점
수렴 문제: 학습률과 같은 하이퍼파라미터에 민감하며, 잘못 설정된 경우 수렴하지 않을 수 있다.
복잡성: 구현이 복잡할 수 있다.

5. Local Sensitivity Sampling (LSS)

주요 개념

국소 민감도 (Local Sensitivity): 특정 데이터셋에서 특정 쿼리에 대한 민감도를 계산한다. 이는 데이터셋의 특정 부분에서 쿼리 결과의 변동성을 측정한다.
노이즈 추가: 민감도에 따라 적절한 노이즈를 추가하여 프라이버시를 보호한다.
장점
효율적 노이즈 추가: 국소 민감도를 사용하여 보다 효율적으로 노이즈를 추가할 수 있다.
높은 정확도: 민감도에 맞춰 노이즈를 추가함으로써 데이터의 유용성을 유지한다.
단점
복잡성: 민감도를 계산하는 과정이 복잡할 수 있다.
특정 쿼리에 맞춤: 특정 쿼리에 대해 민감도를 계산하므로, 모든 유형의 쿼리에 적용하기 어려울 수 있다.

6. Private Gaussian Mechanism (PGM)

PGM은 Gaussian 노이즈를 추가하여 차등 프라이버시를 보장하는 메커니즘이다. Gaussian 노이즈는 데이터의 평균을 중심으로 정규 분포를 따르는 노이즈를 추가한다.
주요 개념
글로벌 민감도 (Global Sensitivity): 데이터셋 전체에서 특정 쿼리에 대한 민감도를 계산한다. 이는 데이터셋에서 최악의 경우에 쿼리 결과가 얼마나 변할 수 있는지를 측정한다.
Gaussian 노이즈: 정규 분포를 따르는 노이즈를 추가하여 프라이버시를 보호한다.
장점
프라이버시 강화: Gaussian 노이즈를 사용하여 데이터의 민감한 정보를 효과적으로 보호할 수 있다.
적용 범위: 다양한 유형의 데이터셋과 쿼리에 적용할 수 있다.
단점
노이즈 크기: 글로벌 민감도를 기준으로 노이즈를 추가하므로, 데이터셋의 크기와 민감도에 따라 노이즈가 커질 수 있다.
데이터 유용성: 노이즈가 커질수록 데이터의 유용성이 떨어질 수 있다.

7. PrivBayes

PrivBayes는 차등 프라이버시를 보장하는 베이지안 네트워크 기반의 합성 데이터 생성 기법이다. 원본 데이터의 분포를 학습하고, 그 분포를 기반으로 합성 데이터를 생성한다.
장점
정확한 데이터 생성: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있다.
유용성: 다양한 데이터 분석 및 머신러닝 모델 학습에 사용할 수 있다.
단점
복잡성: 베이지안 네트워크 학습과 파라미터 추정 과정이 복잡하고 계산 비용이 높을 수 있다.
스케일링 문제: 매우 큰 데이터셋에 적용하기 어려울 수 있다.

8. DualQuery

DualQuery는 차등 프라이버시를 보장하는 데이터 쿼리 응답 기법이다. 이 방법은 데이터의 중요한 통계적 쿼리에 대한 정확한 응답을 제공하기 위해 노이즈를 적응적으로 조절한다.

장점
높은 정확도: 적응적 노이즈 조절을 통해 정확한 쿼리 응답을 제공할 수 있다.
적응성: 중요도가 높은 쿼리에 더 적합한 노이즈 수준을 선택할 수 있다.
단점
복잡성: 적응적 노이즈 조절 및 쿼리 선택 과정이 복잡하고 계산 비용이 높을 수 있다.
제한된 쿼리 응답: 특정 유형의 쿼리에 대해서만 적용할 수 있다.

9. MWEM (Multiplicative Weights Exponential Mechanism)

MWEM은 차등 프라이버시를 보장하면서 데이터의 분포를 추정하기 위한 기법이다. 이 방법은 데이터의 가중치를 반복적으로 업데이트하여 실제 데이터 분포에 가까운 분포를 생성한다.

주요 개념
Multiplicative Weights: 데이터의 각 레코드에 가중치를 할당하고, 반복적으로 업데이트한다.
Exponential Mechanism: 쿼리 응답에 노이즈를 추가하여 차등 프라이버시를 보장한다.
장점
정확한 분포 추정: 반복적인 업데이트를 통해 실제 데이터 분포에 가까운 분포를 생성할 수 있다.
적응성: 다양한 쿼리 유형에 대해 적용할 수 있다.
단점
계산 비용: 반복적인 가중치 업데이트 과정이 복잡하고 계산 비용이 높을 수 있다.
수렴 문제: 반복 과정에서 수렴하지 않을 위험이 있다.

상황별추천

대규모 데이터셋:

SGD: 확장성이 좋고, 대규모 데이터셋에서 효과적으로 작동한다.
PGD: 제약 조건이 있는 최적화 문제에 효과적이다.

고차원 데이터셋:

HDMM: 고차원 데이터에 최적화된 방식으로 쿼리를 처리한다.

적응적 쿼리 응답:

MWU: 적응적 노이즈 조절로 높은 정확도를 유지할 수 있다.
DualQuery: 중요한 쿼리에 대한 높은 정확도를 유지할 수 있다.

프라이버시 보호와 데이터 유용성:

MWEM: 반복적인 업데이트를 통한 정확한 분포 추정이 가능한다.
PrivBayes: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있다.

복잡한 조건부 의존성 처리:

PrivBayes: 베이지안 네트워크를 사용하여 복잡한 조건부 의존성을 처리할 수 있다.

PrivBayes: 원본 데이터의 통계적 특성을 잘 반영한 합성 데이터를 생성할 수 있지만, 계산 비용이 높다.
DualQuery: 적응적 노이즈 조절을 통해 높은 정확도의 쿼리 응답을 제공하지만, 구현이 복잡할 수 있다.
MWEM: 다양한 쿼리 유형에 적용할 수 있으며, 반복적인 업데이트를 통해 정확한 분포를 추정할 수 있지만, 계산 비용이 높을 수 있다.

상위호환 관계

1. SGD < PGD

제약 조건을 추가하여 최적화 문제를 해결할 수 있다.

- PGD: 제약 조건을 적용한 경사 하강법, 데이터의 특정 조건을 만족해야 하는 최적화 문제에 적합하다.

2. Laplace < Gaussian Mechanism

고차원 데이터에 적합, 델타 파라미터 사용하여 노이즈를 추가한다.

3. MWU < MWEM

쿼리 응답과 데이터 분포 추정에 대해 더 복잡하고 정밀한 업데이트를 수행한다.

4. LSS < PGM

국소 민감도를 사용하여 노이즈 추가하는 방식에서, 글로벌 민감도를 기반으로 Gaussian 노이즈를 추가한다.

High-Dimensional Matrix Mechanism (HDMM)
PrivBayes
DualQuery

[#1 인코딩] 범주형 데이터 처리

sarahee — Sat, 18 May 2024 01:15:41 +0900

1. 원핫 인코딩 (One-Hot Encoding)

설명: 각 범주를 이진 벡터로 변환한다. 각 벡터는 하나의 1과 나머지 0으로 구성된다.
장점: 단순하고 직관적, 범주 간 순서나 크기를 가정하지 않음
단점: 차원이 높아질 수 있음, 범주가 많을 경우 메모리 사용량이 증가함
적합성: 많은 노이즈를 추가해야 하는 경우가 많아질 수 있으며, 고차원 데이터는 계산 복잡도를 증가시킬 수 있다.

2. 레이블 인코딩 (Label Encoding)

설명: 각 범주를 고유한 정수로 매핑한다.
장점: 단순하고 메모리 효율적, 차원이 증가하지 않음
단점: 범주 간 순서나 크기를 가정하게 되어 모델이 이를 잘못 해석할 수 있음
적합성: 범주 간의 순서나 크기 정보가 노출될 수 있어 적합하지 않을 수 있다.

3. 순서 인코딩 (Ordinal Encoding)

설명: 범주형 데이터를 순서가 있는 정수로 변환한다.
장점: 순서가 있는 데이터를 잘 표현할 수 있음, 메모리 효율적
단점: 범주 간의 거리를 동일하게 가정, 범주 간 순서가 중요하지 않은 경우 부적절할 수 있음
적합성: 순서가 중요한 경우 유용하지만, 범주 간 순서 정보가 노출될 수 있어 적합하지 않을 수 있다.

4. 바이너리 인코딩 (Binary Encoding)

설명: 각 범주를 고유한 숫자로 매핑하고, 이 숫자를 이진수로 변환한다.
장점: 차원이 원핫 인코딩보다 낮음, 원핫 인코딩과 레이블 인코딩의 중간 정도의 복잡도와 메모리 사용량을 가짐
단점: 복잡도가 증가할 수 있음, 일부 정보가 손실될 수 있음
적합성: 차원이 적당히 낮고, 범주 간의 순서 정보가 직접적으로 노출되지 않아 적합하다.

바이너리 인코딩은,
차원 감소: 원핫 인코딩보다 낮은 차원을 가지므로 계산 복잡도가 줄어든다.
정보 노출 최소화: 범주 간의 순서나 크기 정보가 직접적으로 노출되지 않는다.
프라이버시 보호: 적당한 수준의 노이즈를 추가하여 프라이버시를 보호할 수 있다.