1. IAM
가. IAM 개괄
1) Root Account 관리
Root Account로 로그인할 때, MFA 코드를 추가적으로 입력하도록 설정할 것
•
AWS 회원가입 시 작성한 email이 root account
•
root account는 MFA 활용하여 2중화 방식으로 로그인하도록 설정하는 것이 안전
→ MFA(Multi Factor Authentication): 작은 시간 단위로 인정번호를 대체하여 보안성이 높은 인증 기술
•
Google Authenticator(Google OTP) 활용하여 스마트폰에서 MFA 코드를 받을 수 있도록 설정
•
스마트폰 교체 혹은 초기화 시, 반드시 AWS 보안자격 증명에서 MFA 설정을 제거할 것
→ 삭제하지 않는다면 새로운 폰 또는 초기화된 폰으로 MFA 코드를 받을 수 없으므로 root account로 로그인할 수 없음
→ AWS 고객지원 서비스에서 도움을 받을 수 있지만 굉장히 번거로움(영어전화)
2) Root Account에 MFA 적용하기
•
스마트폰에 Google Authenticator 앱 설치
•
AWS root account으로 로그인 후 보안자격 증명에서 MFA 활성화
→ 가상 MFA 디바이스 유형 선택
→ QR 코드를 Google Authenticator 앱으로 촬영
→ 이후 일련의 MFA 코드 2개를 추가
•
AWS root account로 로그인 시 MFA 코드 요구 받음
•
MFA 설정 제거도 root account 로그인 후 보안자격 증명에서 설정
3) Admin User란
•
Admin User 계정에도 MFA를 적용하는 것이 Best Practice
•
Admin User는 Root Account와 거의 동일한 권한 소유
→ Root Account 동일한 권한을 갖는다면 굳이 Admin User를 만들어야 하나?
→ Admin User에 대한 제어권이 탈취당한 경우 Root Account를 통해 제어권을 가져올 수 있음
→ 다시 말해, Root Account는 보안상 최후의 보루
•
Admin 권한
→ 모든 자원에 대해, 모든 액션을 허용함
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
JSON
복사
4) Admin User 추가하기
•
그룹 생성
→ admin이라는 이름으로 그룹을 생성함
→ AdministratorAccess 정책 적용
•
사용자 추가
→ AWS 자격 증명 유형 선택: AWS 관리 콘솔 액세스
→ 콘솔 비밀번호: 자동 생성
→ 비밀번호 재설정 필요: unckecked
•
admin group 해당 사용자 추가
•
태그는 Name 태그 권장
•
.csv 파일 다운로드
→ 파일의 로그인 링크 접속
→ 파일 내 User name, Password 활용해서 로그인
•
노하우) IAM 서비스의 대시보드에서 계정번호를 임의로 변경할 수 있음
→ 로그인 아이디로 일련의 숫자 대신 별칭 사용함으로써 보다 편리하게 로그인 가능
→ 오른쪽 하단, AWS 계정 - 계정 별칭 - 생성
→ BillingFullAccess를 어드민에 추가하면 서비스 이용 요금 상태를 확인할 수 있음
5) Developer User 추가하기
•
그룹 생성
→ developer이라는 이름으로 그룹을 생성함
→ PowerUserAccess 정책 적용
→ NotAction의 세 가지 분야를 제외하고 대부분의 action 허용됨
→ 단, 예외적으로 5가지 액션에 대해서는 위의 세가지 분야에 대해 allow가 됨
→ 예를 들어, developer user 자신의 비밀번호 변경 등
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
JSON
복사
•
사용자 추가 방법은 위의 'Admin User 추가하기'와 같다
6) 기타
•
IAM(Identity and Access Management): AWS 자원에 대한 접근을 안전하게 제어할 수 있는 서비스
•
AWS resources를 안전하게 관리할 수 있도록 도와주는 서비스
→ AWS는 도와주는 역할, 최종 책임은 사용자에게 있음
•
IAM은 AWS만의 고유한 서비스가 아니라 일반적인 서비스
•
클라우드트레일 서비스를 활용하면 특정 유저가 어떤 작업을 하는 지 로그로 확인할 수 있음
→ 팀원의 작업현황을 로그를 통해 확인 가능함
→ 해커가 해당 로그를 통해서 공격할 수 있음
→ 과금은 S3에 저장되는 데이터의 양에 비례하지만 텍스트 파일로 쌓이기 때문에 큰 영향은 없음
나. IAM Policy
1) IAM 키워드
IAM 서비스에서 특정 리소스에 대한 엑세스 권한을 세부적으로 조정할 수 있음
•
IAM: AWS 리소스에 대한 엑세스를 안전하게 제어하는 서비스
•
AWS 리소스: 컴퓨팅, 스토리지, 네트워크 서비스 등
•
엑세스 제어: CRUD
2) 인증과 권한 부여
•
권한 부여의 주체: IAM Policy
•
인증의 주체: User, Role
→ User에게 권한을 부여할 때, 특정 권한을 맵핑한 group에 포함시키는 방법도 존재함
→ Role에 권한을 부여하는 경우는 User가 아니라 서비스 자체에 특정 권한이 필요한 경우, ex) lambda or EC2
3) IAM 정책 종류
•
AWS 관리 정책
→ AWS에서 생성한 정책
→ 개인 프로젝트나 스타트업에서는 본 정책만으로 관리하기에 충분함
•
사용자 관리 정책
→ 사용자가 생성한 정책
→ 기존 정책으로부터 생성 및 수정 또는 직접 생성 가능
→ GUI, JSON 편집기 사용하여 생성
•
Inline 정책
→ 일회성 정책
다. IAM Role
1) IAM Role
•
일종의 권한을 부여하는 방법으로 작업이 필요한 경우에만 사용하는 임시 권한 부여 방법
2) 특징
•
작업을 하는 경우에만 특정 권한을 부여함
→ 일정 시간이 되면 해당 권한이 만료됨
→ Role은 short term 권한부여방식 vs Policy(long term)
•
사용자가 아닌 어떤 것(AWS service)에도 권한을 부여할 수 있음
→ lamba가 EC2를 사용할 때, lambda에 EC2 stop, start 관련 권한을 Role로 부여
•
남의 계정의 사용자에게 나의 계정의 특정 권한을 일시적으로 부여할 때
→ AWS 전문가에게 인프라 관련 상태를 보여주고 조언을 구할 때
→ AWS 전문가에게 admin 계정 X, admin 관련 Role을 부여함
3) 적용
•
작업 - 보안 - IAM 수정
라. Switch Role
1) Switch Role 생성
2) Switch Role 사용
마. CLI
1) CLI 설치
•
version2 설치 권장
•
설치 확인
→ aws --version
2) CLI 사용
•
IAM 보안자격 증명에서 엑세스키 생성
→ 실무에서 특정 AWS 자원을 CLI 활용할 때 관리자에게 Key ID와 Access Key 요청
•
엑세스키 사용해서 설정 작업
→ aws configure
mj@MJui-MacBookPro ~ % aws configure
AWS Access Key ID [None]: ***fgf**2232fd**
AWS Secret Access Key [None]: ***bg**bjf**
Default region name [None]: ap-northeast-2
Default output format [None]: json
JSON
복사
•
사용자 확인
→ aws iam list-users
mj@MJui-MacBookPro ~ % aws iam list-users
{
"Users": [
{
"Path": "/",
"UserName": "admin",
"UserId": "AIDA2WZEBS2WAF5D5D72U",
"Arn": "arn:aws:iam::736125621932:user/admin",
"CreateDate": "2021-04-22T05:35:25+00:00",
"PasswordLastUsed": "2021-06-05T23:05:44+00:00"
},
{
"Path": "/",
"UserName": "mj",
"UserId": "AIDA2WZEBS2WA745622CY",
"Arn": "arn:aws:iam::736125621932:user/mj",
"CreateDate": "2021-04-22T05:39:02+00:00"
}
]
}
JSON
복사
•
설정값 확인: ~/.aws 경로에서 확인
→ config: region, output format
→ credentials: access key 정보
2. S3
가. S3 개괄
1) S3란
•
S3(Amazon Simple Storage Service): 객체(또는 파일) 업로드, 다운로드, 검색 서비스
2) S3 특징
•
리전 기반 서비스이므로 복수의 AZ에 분산되므로 파일의 안전성이 높은 수준으로 보장됨
•
CDN(고속 콘텐츠 전송 네트워크)과 연동 가능
•
static web page 기능 지원
•
versioning 기능 사용 가능
→ 같은 이름의 파일을 덮어쓰면 해당 파일의 이력이 기록으로 남아서 롤백할 수 있음
3) S3 활용 케이스
•
서비스의 대용량 파일 저장소
→ 넷플릭스의 경우, S3와 CDN을 결합하여 대용량의 영상 정보를 고속으로 사용자에게 전송함
•
서비스 로그 저장 및 분석
→ EC2의 EBS의 안정성은 S3 보다 떨어짐(실제 데이터 손실 경험이 보고됨)
→ EC2의 EBS와 비교했을 때 비용면에서 효율적
→ 서비스 로그를 S3에 저장하도록 설계
→ CloudWatch Logs 서비스도 결국 로그를 S3로 저장된다는 점에서 공통점이 있음
•
서비스 사용자의 데이터 업로드 서버
4) S3 기본 사용
•
개발자 계정으로 S3 사용 가능
•
bucket 이름은 전세계적으로 유일해야 함
•
업로드된 모든 파일은 각각의 URL을 갖게 됨
→ 권한 조정 시 외부에서 URL만으로 확인 가능
•
S3에서 폴더로 보이는 것은 실제로 prefix 개념이 적용된 것
→ 파일을 특정 폴더로 복사 시 특정 버킷의 폴더명을 prefix로 지정
•
버킷 삭제 시, 버킷 내부의 모든 파일(객체)가 삭제되어야 함
→ 파일을 일일이 삭제하는 것이 번거로울 경우, '비어 있음'(버킷 비우기) 기능을 활용하여 내부 파일을 일괄 삭제할 수 있음
나. S3 권한 제어
1) 권한 제어 유형
•
ACL(Access Control List): 객체마다 ACL 지정하여 권한 제어
→ 간단한 제어에 사용
•
Bucket Policy: 버켓에 대해 정책을 부여하여 권한 제어
→ IAM Policy와 유사하게 적용됨
→ ACL 보다 세부적으로 권한 제어 시 사용됨
•
IAM: IAM 사용자에게 버킷 접근 권한을 부여
•
PresignedURL: URL을 이용하여 임시 권한 부여
→ 콘솔로 권한 제어 불가
→ 개발 시 매우 유용하게 사용 가능
2) 특정 파일 public 설정
•
버킷 권한 설정에서 모든 public 접근을 허용함
→ 버켓 생성 시 기본 옵션으로 public 접근을 제한함
•
각각의 파일에 대해 객체작업에서 퍼블릭 설정
3) ACL 설정
•
S3 내 모든 파일은 ACL을 가지고 있음
•
위 ACL을 이용하여 개별 파일에 대한 권한 제어 가능
•
특정 파일에 대한 public 설정은 개별 ACL을 활용한 것
•
pulbic 설정이란 특정 파일의 권한 설정 - ACL 설정 - 모든 유저에 대한 읽기 권한 허용
4) Bucket Policy 활용
•
특정 버킷 선택 - 권한 - 버킷 정책 - 버킷 정책 편집 - 정책 생성기
•
아래와 같은 정책 생성 후 버킷 정책으로 편집
→ mj-bucket-test4/public 이하 모든 파일에 대해 모든 사용자 읽기 권한을 허용함
{
"Version": "2012-10-17",
"Id": "Policy1622863229895",
"Statement": [
{
"Sid": "Stmt1622863151627",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mj-bucket-test4/public/*"
}
]
}
JSON
복사
다. CLI 제어
1) 기본 사용
•
버켓 이름 조회
→ aws s3 ls
•
버켓 생성
→ aws s3 mb s3://[버켓이름]
→ aws s3 mb s3://mj-bucket-test-5
→ CLI로 버켓 생성 시 접근권한이 기본적으로 public으로 설정
•
파일 업로드(로컬 → S3)
→ aws s3 cp [파일] [S3 경로]
→ aws s3 cp README.md s3://mj-bucket-test-5
•
파일 다운로드
→ aws s3 cp [S3 파일경로] [로컬경로]
→ aws s3 cp s3://mj-bucket-test-5/README.md /Users/mj/Documents/ssh-keys
•
파일 삭제
→ aws s3 rm [s3 파일경로]
2) 폴더 동기화
•
•
(다운로드) S3의 폴더를 로컬에 동기화
→ aws s3 sync [S3 경로] [로컬 경로]
→ aws s3 sync s3://mj-bucket-test-5 ./
3) ACL 수정
•
S3 API 활용하여 ACL 수정
→ aws s3api put-object-acl --bucket [버킷 이름] --key [s3 객체 경로] --acl [acl 정책]
→ aws s3api put-object-acl --bucket mj-bucket-test4 --key AboutLogin.gif --acl public-read
4) 업로드
•
CLI or SDK 활용 업로드: 업로드 API(PUT) 사용하여 최대 5GB 업로드 가능
•
관리 콘솔 활용 업로드: 최대 160GB 업로드 가능
•
Multipart 업로드: 최대 5TB까지 업로드 가능
→ CLI or SDK 활용 가능
→ 병렬방식의 업로드
→ 파일이 너무 크거나 빠른 업로드가 필요한 경우에 사용함
라. 정적 호스팅
1) 개념 및 특징
•
S3 + Cloud Front(CDN 서비스) + Route53(도메인 서비스) 활용
•
버켓 이름과 도메인 이름이 같아야 함
2) public 접근 허용
•
웹 호스팅하려는 버켓 전체가 퍼블릭 접근이 가능해야 하므로 ACL이 아니라 정책적으로 설정하는 것이 효과적
3) 정적 웹 호스팅 설정
•
버켓의 속성 중 정적 웹 호스팅 설정 - 활성화
•
index.html 지정
마. 기타
1) 스토리지 클래스
•
스토리지 클래스에 따라 가용성, 성능, 요금이 다름
•
저장 파일의 성격에 따라 스토리지 클래스를 구분해서 사용하면 요금면에서 크게 절감할 수 있음
2) 버전 관리
참고자료
3) 라이프 사이클
참고자료
3. EC2
가. EC2 개괄
1) EC2란
•
EC2(Elastic Computing Cloud): 안정적이고 확장성이 있는 컴퓨팅 클라우드 서비스
2) EC2 특징
•
사용시간에 비례해서 요금이 계산되며, 사용시간의 기준은 초(second)
•
전세계 어디에서든 온라인으로 인스턴스를 생성하고 서비스를 운영할 수 있음
•
AWS의 다양한 서비스와 연동할 수 있음
•
다양한 OS 지원
3) MultiAZ와 고가용성
•
EC2는 AZ(Availability Zone) 기반의 서비스
•
서비스의 높은 가용성을 위해 두 군데 이상의 AZ에 서버를 구축해야함
→ AZ는 일종의 물리적인 데이터센터이므로 매우 낮은 확률로 멈출 가능성이 있음
•
ELB(Elastic Load Balancer)를 활용해서 복수의 AZ에 구축된 서버를 연결해서 서비스 제공
→ 트래픽을 여러 서버로 분산
4) EC2 관련 서비스
•
VPC(Virtual Private Cloud): EC2가 연결되는 사설 네트워크망
→ 리전 기반 서비스(AZ 상위)
→ 리전 기반으로 서비스를 제공하기 때문에 Multi AZ에 구축한 EC2 서버를 연결할 수 있음
•
Subnet: VPC 하위망 서비스
→ AZ 기반 서비스로 EC2의 subnet
•
EBS(Elastic Block Storage): EC2의 블록 저장장치
→ 컴퓨터의 SSD 역할
→ AZ 기반 서비스
•
ENI(Elastic Network Interface): 가상 네트워크 인터페이스
→ 컴퓨터의 NIC(or 랜카드) 역할
→ AZ 서비스
•
Security Group: EC2의 방화벽, 포트 접근 제어 기능
•
Auto Scaling: EC2의 확장성을 위해 제공되는 서비스
→ 트래픽에 비례해서 서버의 컴퓨팅 파워가 늘어나고 줄어듬
→ 따라서 서비스 사용에 드는 비용도 트래픽에 비례하게 됨
•
EBS snapshot: EBS의 데이터를 백업할 때 사용하는 서비스
•
AMI(Amazon Machine Image): EC2의 백업 이미지
→ EC2의 인스턴스 자체를 백업하여 AMI를 이용해서 EC2 서비스 이용함
5) EC2 유형과 비용
•
범용
→ M 시리즈: 일반적인 서버로 사용되는 인스턴스
→ T 시리즈: 시간당 CPU 크래딧을 제공하는 것이 큰 차이
→ Mac: Mac mini 인스턴스 제공
→ 이용 요금 부과 기준이 하루임(하루 $25), 다른 인스턴스의 경우 초(second)단위로 부과
•
컴퓨팅 최적화, 메모리 최적화 등등
→ 최적화가 필요한 컴퓨팅 리소스에 따라 인스턴스 선택 가능
•
비용
→ 온디맨드: 시간에 따라 비용 지불
→ 스팟 인스턴스: 경매 방식으로 사용하고 있지 않은 인스턴스를 90% 저렴하게 사용할 수 있음
→ 다만, 다른 이용자가 더 높은 가격을 제시한다면 1시간 뒤에 인스턴스가 종료됨
나. 실습) EC2 인스턴스 생성 및 접속
1) 인스턴스 생성
•
단계 5) 태그 추가에서 Name은 반드시 추가할 것
→ Environment, Team 태그 등도 추가할 것을 권장
→ 태그는 여러 개의 인스턴스를 다룰 때, 각각의 인스턴스를 적절하게 분류하는데 유용함
•
단계6) 보안그룹 생성에서 소스를 아래와 같이 설정한 이유는 교육상 실습하기 위해
→ 실제로 어떻게 적용할까?
2) 인스턴스 중지와 종료
•
정지: 인스턴스의 동작을 중지함
→ 컴퓨터의 전원을 끈 상태
→ 인스턴스를 여전히 클라우드 컴퓨팅 서비스로 컴퓨팅 자원이 할당되어 있기 때문에 비용이 발생함
→ 서버 내 데이터를 보관하고 있는 것이 대표적인 예
•
종료: 인스턴스의 리소스를 반환함
→ 클라우드 컴퓨팅 서비스 이용에 따라 할당 받은 컴퓨팅 자원을 반납함
→ 더이상 비용이 발생하지 않음
3) 인스턴스 접속
•
인스턴스 접속 방법 중 직접 연결이 제일 많이 사용됨
→ 환경에 따라 안되는 경우도 있음
•
SSH 접속은 직접 연결이 안될 때 사용함
→ 과거에는 제일 많이 사용했던 방법임
→ 안정적으로 접속 가능한 방법
•
접속 순서
가) 키 파일(*.pem) 권한 변경
→ chmod 400 ec2-demo.pem
나) ssh -i pem파일.pem ec2-user@public-dns
→ OS를 ubuntu로 지정했다면 host명은 ec2-user가 아니라 ubuntu가 됨. ubuntu 외에는 ec2-user로 작성할 것
→ pem 파일은 인스턴스 생성에 따라 만들어진 파일
→ public-ip는 인스턴스 대시보드에 명시된 public dns
에러) 만약 접속이 안된다면 두 가지를 의심해 볼 것
→ 하나, public ip가 아니라 private ip로 접속을 시도했는지
→ 하나, 보안 그룹의 방화벽 인바운드 정책이 제대로 열려있는지
4) Elastic IP(고정 IP 서비스)
•
IP가 변경되는 것을 방지하고 고정 IP를 사용하기 위해 Elastic IP(or 탄력적 IP) 이용할 것
→ Elastic IP 이용하지 않은 상태에서 인스턴스 중지 후 재시작하면 IP가 변경됨
•
Elastic IP 생성 및 관리 방법
→ Elastic IP 생성 시, 탄력적 IP 주소 할당 버튼 클릭
→ 생성된 Elastic IP에 인스턴스 연결 시, 작업에서 Elastic IP 주소 연결 클릭
→ Elastic IP 생성 후, 관리를 위해 Name을 설정할 것
•
과금 정책
→ 사용 중 무료
→ 아래와 같이 사용할 경우 과금(월 4천원 정도)
가) 인스턴스와 Elastic IP를 연결하지 않았을 경우
나) 인스턴스와 Elastic IP를 연결했지만 해당 인스턴스의 상태가 중지되어 있을 경우
→ 따라서 사용하지 않는다면 바로 반납할 것(작업에서 연결해제 후 릴리즈까지 해야 함)
→ 단, Elastic IP가 릴리즈되면 동일한 IP를 재할당 받을 수 없음. 이로 인하여 각종 서비스 장애 발생할 수 있음
다. 실습) EC2 활용 기타
1) EBS 스냅샷 생성
•
EBS 스냅샷: EBS 데이터 백업 방법
→ 스냅샷은 S3에 저장됨
→ 한번 백업 된 후 데이터는 증가분에 대해서만 추가 백업이 발생하므로 스냅샷의 용량 및 비용은 효율적
→ 가급적 인스턴스 정지 후 스냅샷을 생성할 것을 권장
→ EBS는 리전 서비스이기 때문에 스냅샷을 이용해서 다른 AZ로 복사할 수 있음
•
볼륨 생성 클릭하여 다른 AZ에도 해당 스냅샷을 생성할 수 있음
2) AMI 및 인스턴스 생성
•
AMI: EC2 인스턴스에 대한 스냅샷
→ EBS 스냅샷 + 메타 데이터
→ EBS와 마찬가지로 AMI를 활용하여 EC2 인스턴스를 다른 AZ로 이동시킬 수 있음
•
인스턴스의 작업 중 이미지 및 템플릿에서 이미지 생성으로 AMI 작업 시작 가능 또는 AMI로 직접 접근하여 작업
3) ec2-meta-data
•
ec2 인스턴스에 연결하여 아래와 같은 명령을 하면 해당 ec2에 대한 여러 meta data를 확인할 수 있음(pulbic ip, IAM id 등등)
•
curl -w '\n' http://169.254.169.254/latest/meta-data
•
ex) public ipv4 확인하는 경우
→ curl -w '\n' http://169.254.169.254/latest/meta-data/public-ipv4
4) EC2 Role
5) EC2 과금 정책
•
EC2 인스턴스 정지: EC2 요금 과금 X, EBS 요금 과금 O
•
EC2 인스턴스 종료: EC2 요금 과금 X, EBS 요금 과금 X
•
EC2 인스턴스를 종료했음에도 과금이 되는 경우
→ EBS 스냅샷 또는 AMI가 남아 있는 경우(S3 요금 과금)
→ AMI를 제거해도 AMI 스냅샷이 남아 있을 수 있으므로 주의!
4. VPC
가. VPC 개괄
1) VPC 주요 개념
•
학습배경: AWS의 주요 서비스들이 VPC를 통해 네트워크에 연결됨
•
VPC(Virtual Private Cloud): AWS 사용자 전용 가상 네트워크 망, 리전 서비스
•
서브넷: VPC를 더 작은 범위로 나눈 네트워크, AZ 서비스
→ EC2도 AZ 서비스이므로 서브넷에 연결
→ lambda(serverless)도 optional하게 VPC 필요, AWS 망에서 운영할 수도 있고 VPC에 넣어서 운영할 수도 있음
→ S3의 경우 VPC가 필요 없음. AWS망에서 운영됨
•
라우팅 테이블: 네트워크 트래픽 전달 규칙 지정
•
CIDR 블록: CIDR 표기법을 통해 IP 주소 범위 지정
2) CIDR
•
CIDR 표기법: IP address/Prefix
→ IP address의 한 자리는 8bits(1byte, 2^8 = 256)
→ Prefix로 지정한 범위: 네트워크 파트(고정 부)
→ Prefix로 지정하지 않은 범위: 호스트 파트(가변 부)
→ 호스트 파트(가변 부)가 특정 네트워크 파트(고정 부분)에 대한 범위
10.2.0.0/16
// '10.2'에 해당되는 부분은 네트워크 파트
// '0.0'에 해당되는 부분은 호스트 파트
Plain Text
복사
•
CIDR IP 범위: 2 ^ (32 - prefix)
•
any address: 모든 IP Address
0.0.0.0/0
고정 비트: 0
가변 비트: 32
범위: 0.0.0.0 ~ 255.255.255.255
Plain Text
복사
•
특정 address의 범위
→ 고정 비트가 8의 배수가 아닌 경우의 범위
10.5.21.64/28
고정 비트: 28
가변 비트: 4(2^4 = 16)
범위: 10.5.21.64 ~ 10.5.21.79
-> 범위 안에 10.5.21.64도 포함됨
-> 범위 내 마지막 IP는 10.5.21.79(10.5.21.80 X)
Plain Text
복사
3) 서브넷
•
서브넷은 VPC CIDR 블록의 부분 집합의 CIDR 블록으로 표현됨
VPC의 CIDR 범위
10.5.0.0/16
Subnet의 CIDR 범위
10.5.1.0/24
10.5.11.0/24
.
.
.
Plain Text
복사
4) VPC 범위
•
VPC IP의 가장 큰 범위의 prefix: 16
•
가장 작은 범위의 prefix: 28
•
사설망에 해당하는 아이피 범위는 아래 3개 분류에 한정됨
•
아무 아이피 범위를 선택하면 안됨.
→ 사용자가 이용하는 아이피 범위는 10.0.0.0 권장
→ 내부망과 외부망의 아이피가 같아버리면 라우터에서 내부망에서 외부로 나가는 데이터를 내부망으로 돌려버림. 아이피가 같아면 내부망 아이피를 우선하여 처리
나. VPC 활용
1) VPC 생성
•
인터넷 게이이트웨이 생성 후, VPC와 연결
→ 외부에서 VPC로 접속할 때, 게이트웨이를 거쳐야 함
•
VPC 생성 시 라우팅 테이블이 자동으로 생성됨
→ 대상 local: 10.1.0.0/16 범위에 해당하는 트래픽은 VPC 안에서만 다루겠다는 의미
2) subnet 생성 및 라우팅 테이블 연결
•
VPC 생성에 따라 AZ의 수만큼 자동으로 subnet 생성
•
public subnet: 인터넷과 연결(인터넷 게이트웨이 연결)
→ Web Server, Bastion(or Jump) Server가 public subnet에 위치함
→ WAS(Web Application Service)는 개발의 편의성을 위해 주로 public subnet에 위치하지만 보안적인 부분을 강조하는 경우 private subnet에 위치하기도 함
•
private subnet: 인터넷과 연결 X
→ public subnet과 private subnet 사이의 연결은 기본으로 설정됨
•
라우팅 테이블(Destination / Target)
→ target: local인 경우, 데이터는 밖으로 나갈 수 없음
→ 서브넷 생성 시, 기본 라우팅 테이블이 각 서브넷에 생성됨
3) IGW 생성 및 VPC 연결
•
IGW(Internet Gateway): 인터넷 게이트웨이, VPC의 내부망에서 인터넷 사용 시, 인터넷과 VPC 간의 문을 생성하는 역할
→ IGW 생성하지 않으면 VPC 내부에서 인터넷 사용이 불가
•
IGW의 경우도 EC2 인스턴스 생성 시 default로 자동 생성됨
•
VPC에서 인터넷을 사용하기 위해 추가적으로 라우팅 테이블을 생성함
→ 인터넷 사용을 위한 규칙을 라우팅 테이블에 추가
→ 서브넷 중 인터넷을 사용하는 서브넷에 연결(public subnet)
4) Public Subnet 내 EC2 인스턴스 생성
•
EC2 인스턴스 생성 3단계에서 네트워크, 서브넷, public IP 할당 선택
→ 네트워크: 기본 X, 직접 생성한 VPC 선택
→ 서브넷: public subnet 선택
→ public ip 활성화: 해당 인스턴스에서 인터넷 접속하기 위해 활성화 선택
→ 인스턴스 생성 완료 후 접속 불가 현상 발생
→ 접속 불가 원인: 해당 public subnet이 인터넷과 연결이 안되어 있으므로 외부에서 해당 인스턴스로 접근 불가
•
public subnet에 IGW 설정
→ 라우팅 테이블 생성하여 트래픽에 대한 분기를 설정함
→ 라우팅 테이블 편집하여 모든 트래픽에 대해 IGW로 전달되도록 맵핑
→ 라우팅 테이블은 위에서부터 아래로 우선순위를 지님
→ 10.1.0.0/16 범위의 트래픽은 VPC 내부망으로 전달되고 밖으로 전달 X
→ 10.1.0.0/16 이외의 트래픽은 IGW로 전달됨
•
public subnet의 라우팅 테이블을 default 테이블에서 직접 생성한 것으로 변경
5) Private Subnet & NAT
•
Private Subnet 내 주로 DB가 위치함
•
Private Subnet에는 외부의 트래픽이 들어올 수 없지만 DB에 필요한 프로그램을 설치하기 위해 내부에서 외부로 접근할 필요 있음
•
내부에서 외부로 접근하는 방식에는 두 가지 존재
→ AWS NAT Gateway 활용, 월 5만원 과금
→ or EC2로 직접 NAT Instance 구축
•
이하 표에서 route table의 destination과 target이 뒤바뀜
6) VPC 실습 정리
•
VPC 생성
•
1 public subnet 생성
•
1 private subnet 생성
•
2 routing table 생성
→ 하나는 VPC 생성에 따라 자동으로 생성된 것
→ 다른 하나는 임의로 설정한 것(public subnet과 IGW 연결 목적)
•
1 IGW 생성
→ IGW 생성
•
1 Web Server 생성
→ public subnet 범위에 생성함
7) NACL vs 보안그룹(SG)
8) 고가용성 확보를 위한 VPC 구성
9) Subnet public IP 자동 할당
•
Subnet public IP 자동 할당 설정하면 해당 서브넷에서 EC2 인스턴스 생성 시 Public IP 자동 할당의 옵션이 기본값으로 활성됨
→ VPC - Subnet - 작업 - 자동 할당 IP 설정 수정 - 자동할당 IPv4
→ 해당 설정을 안하면 Public IP 자동 할당 옵션의 기본값은 비활성화
다. Private Subnet EC2 인스턴스 활용
1) private instance 접속
•
Private Subnet에 생성된 EC2 인스턴스는 public IP 미존재
→ 인터넷으로 private instance 접속 불가
→ public subnet의 인스턴스의 경우, ssh로 접속 가능하지만 private은 불가
•
public instance key에 private instance key 더하기
→ ssh-add -K {private key}
→ ssh-add -K private-instance.pem
→ private key가 public key에 정상 추가되었는 지 확인
→ ssh-add -L
•
private instance key 포함하여 public instance key로 public instance 접속
→ ssh -A -i {public key} {public instance user}@{public instance public ipv4}
•
public instance 접속한 상태에서 private instance 접속
→ ssh {private instance user}@{private instance private ipv4}
2) NAT 인스턴스 설정
•
NAT 게이트웨이 생성
→ public subnet, 탄력적 IP 할당 필요
→ 중요! NAT 게이트웨이 생성은 public subnet으로 설정!
•
라우팅 테이블 생성
→ private subnet 이하의 인스턴스에서 외부로 데이터를 받기 위한 설정
•
private subnet과 새로 생성한 라우팅 테이블 연결
•
private subnet 이하 EC2 인스턴스에서 외부로 ping test
•
private subnet에 대한 보안그룹 설정
두 가지 방법
◦
public subnet에 적용한 보안그룹을 인바운드 규칙의 소스로 지정
→ AWS를 효과적으로 사용하는 방법
◦
또는 CIDR 블록으로 범위 지정
코드스쿼드 강의
5. RDS
가. RDS 개괄
1) 소개
•
RDS(Amazon Relational Database Service): 클라우드 환경에서 관계형데이터베이스를 설정, 운영, 확장할 수 있는 서비스
2) 장점
•
백업과 복구의 편리성
•
이중화 시 고가용성 확보
•
수직, 수평 확장 시 다운타임(중단시간) 최소화
•
AWS의 다른 서비스와 통합 용이
•
높은 성능
3) 단점
•
높은 비용
→ EC2의 2배 정도 높은 비용, 이중화하면 EC2의 4배 정도
•
완벽한 최적화가 어려움
→ EC2에서 제공하는 기능만 활용 가능
나. RDS 생성
1) 준비작업
•
AWS admin 계정 사용
→ IAM 및 RDS 권한 필요
•
같은 VPC 내 다른 AZ에 각각의 private subnet 생성
→ 이중화 목적으로 두 개의 private subnet 생성(active, stanby)
→ private-standby의 경우 private-active와 통신하므로 NAT Gateway 생성 불필요
•
DB 전용 서브넷 그룹 생성
→ private subnet 두 개를 전용 그룹으로 묶는 작업 진행
•
보안 그룹 생성
→ 인바운드 규칙: pulbic 보안 그룹에 속한 인스턴스의 소스에서 3306으로 전달되는 트래픽만 허용
or WAS가 속한 subnet의 CIDR 에서 3306 포트로 들어오는 트래픽만 허용
→ 아웃바운드 규칙: 모든 트래픽 허용
2) RDS 생성
•
템플릿: 개발/테스트 선택
→ 비용은 발생하지만 다중 AZ 배포 등 학습에 필요한 옵션을 학습하기 위함
•
암호 자동 생성
•
DB 인스턴스 크기: 버스터블 클래스(가장 작은 인스턴스)
→ 비용이 ec2의 2배 정도
•
스토리지: 20G
•
스토리지 자동 조정 비활성화
→ 프로덕션에서는 유용한 기능이나 개발 단계에서는 불필요
•
다중 AZ 배포: 대기 인스턴스 생성
→ standby 인스턴스를 생성하여 이중화
•
퍼블릭 엑세스 가능: 아니오
→ 인터넷 환경에서 RDS로 접속할 계획이 없으므로 '아니오'를 선택함
→ 이미 private 서브넷 이하에 RDS를 생성하고 보안그룹에 3306 포트로만 트래픽을 허용했기 때문에 퍼블릭 엑세스를 허용해도 외부에서 접근 불가
•
VPC 보안 그룹: 기존 항목의 이미 만들어둔 보안 그룹 선택
•
추가연결구성: 3306 포트
•
데이터베이스 인증 옵션: 암호 인증
•
추가 구성
→ 백업 보존 기간: 설정한 기간에 한해서 실시간에 준하여 백업 데이터를 가져올 수 있음
→ 백업 보존 기간이 7일 설정 시, 3일 전의 09시 44분의 데이터 확인 가능
→ 백업 기간: 기본 설정 없음
→ 프로덕션 서비스의 경우, 사용자가 적은 시간대로 백업 기간을 설정하지만 개발단계에서는 기본 설정 없음으로 설정
•
암호화 비활성화: KMS 서비스를 활용해야 사용 가능하므로 현재 단계에서는 생략
→ 실무에서는 사용 권장
•
모니터링: enhanced 모니터링 활성화
→ enhanced 모니터링 활성화 시, 추가 비용 발생
→ 실무에서 많이 사용하는 서비스
•
로그 내보내기: 모든 로그 선택
→ slow query는 선택 권장
•
유지 관리: 마이너 버전 자동 업그레이드 사용
→ DB 버전이 업그레이드 되면 자동으로 맞춰서 업그레이드 되도록 설정
다. RDS 연결
1) Public EC2 인스턴스 접속
•
private subnet에 RDS 생성함에 따라 public instance를 통해서만 RDS 접속이 가능함
2) RDS 접속
•
mysql -u admin -h [RDS 엔드포인트] -p
→ mysql -u admin -h mj-private-rds.cryuxp3nt3le.ap-northeast-2.rds.amazonaws.com -p
•
패스워드 입력
→ ****1**4
라. RDS 백업 및 확장
6. Auto Scaling
가. 원리
1) ELB
•
트래픽 분산
2) Cloud Watch
•
트래픽 모니터링
3) Auto Scaling
•
트래픽 모니터링 결과에 따라 인프라 확장
나. Launch Configuration
•
ASG에 지정된 설정 값으로 필요에 따라 EC2 생성함
→ Launch Cofiguration은 필요에 따라 2개 이상 설정할 수 있음
→ 복수의 Laucn Configuration 중 선택 가능
→ 기존 Lauch Configuration으로 생성한 서버를 죽이면 ASG에서 새로운 Launch Configurationo으로 서버를 생성함
◦
Lauch Configuration은 수정 불가, 추가 생성은 가능
다. ASG 인스턴스 조정
1) 동적 조정
•
정해둔 기준에 따라 자동으로 인스턴스 생성
2) 수동 조정
•
인스턴스의 숫자를 직접 지정하여 인스턴스 생성
3) 일정 조정
다. 활용
1) HTTPS → HTTP
•
웹서버에서 HTTPS로 트래픽을 받아서 HTTP로 변환
→ 서버 부담 감소
2) 상태 검사(health check)
•
인스턴스의 동작여부를 확인하여 트래픽 전달여부를 수시로 결정
3) public subnet 생성
•
최소 2개 이상의 public subnet 생성
→ 라우팅 테이블을 확인해서 인터넷 게이트웨이로 트래픽이 전달되는 지 확인
4) 인스턴스 삭제
•
기본 옵션: 오래된 인스턴스부터 삭제
→ 하지만 최신 버전 인스턴스를 삭제하기도 함
→ 사용자가 오래된 인스턴스에 더 많기 때문에 서비스의 안정성면에서 새로운 인스턴스부터 삭제하기도 함
7. Container Service
가. ECS
1) ECS란
•
Elastic Container Service: 컨테이너 어플리케이션에 대한 오케스트레이션 서비스로 컨테이너 어플리케이션의 배포, 관리, 확장 지원
2) Container Launch Type
•
Fargate Launch Type: 서버리스 컨테이너 실행 환경
→ 각각의 컨테이너가 동일한 lifecycle을 갖는 경우, 인프라 운영 레벨이 낮은 경우
•
EC2 Lauch Type: EC2 기반 컨테이너 실행 환경
→ 각각의 컨테이너들이 각각의 lifecycle을 갖는 경우, 인프라 운영 레벨이 높은 경우
ex) 3개의 컨테이너가 각각 프런트엔드 서비스, 백엔드 서비스, 스토리지의 기능을 수행하는 경우
3) 컨테이너 관리
4) Scale In & Out
5) ECS Service 주의사항
•
ECS Service를 새로 생성할 경우, 연결된 Load Balancer의 Health Status 확인 필요
→ Health Status 부분이 확인되어야 의도한 IP Address로 요청 시 정상 응답 확인 가능
•
service 내 새로운 container 생성 시 기존
나. ECR
1) ECR이란
•
Elastic Container Registry: 컨테이너 이미지 등록 서비스
→ Docker Hub와 주요 기능 유사
2) Image Push
•
Push 명령은 레파지토리의 ‘푸시 명령 참고’ 참고
Docker Client 인증: aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 997494235799.dkr.ecr.us-east-1.amazonaws.com
Docker Push: docker push 997494235799.dkr.ecr.us-east-1.amazonaws.com/om-log-server-staging-java:latest
Plain Text
복사
다. ECS 기반 EC2 배포
1) 사전작업
•
ECR Private Repository 생성
참고) Repository 생성 이미지
•
local에서 이미지 빌드 후 private repository로 푸시
•
작업 정의 생성
참고) 작업 정의 중 컨테이너 추가 이미지
•
Application Load Balancer 생성
→ HTTP or HTTPS 트래픽 허용 설정
→ Target Group 생성 후 Load Balancer 생성
참고) Target Group 생성
참고) Load Balancer 생성 및 Target Group 연결
2) ECS Service 생성
•
로드 밸런서 생성 후 ECS 생성 필요, 로드 밸런서는 ECS 생성 시점에만 추가할 수 있음
참고) ECS Service 생성 과정에서 Load Balancer 규칙 추가 이미지
3) 작업 정의 파일 생성
4) EC2 인스턴스 Register Target in
이슈)
•
현상
•
대응
→ Load Balancer의 listener의 port를 수정(80 → 8080)하여 container의 application의 port가 8080일 경우 트래픽이 통하도록 수정
참고) port 수정 이미지
→ 작업정의에서 container port를 8080으로 수정
"containerDefinitions": [{
"portMappings": [{
"containerPort": 8080,
"protocol": "tcp"
}]
}]
Java
복사
라. ECS 기반 Fargate 배포
작업 시 workflow 내 필수 환경변수를 사전 정의하면 전체적인 작업이 수월함
1) 사전작업
•
ECR Private Repository 생성
참고) Repository 생성 이미지
•
local에서 이미지 빌드 후 private repository로 푸시
•
Application Load Balancer 생성
→ HTTP or HTTPS 트래픽 허용 설정
→ Target Group 생성 후 Load Balancer 생성
참고) Target Group 생성
참고) Load Balancer 생성 및 Target Group 연결
2) 작업정의 구성
•
작업정의 구성
•
작업 크기 및 컨테이너 정의
•
컨테이너 추가
2) ECS 구성
•
ECS 클러스터 생성
•
IAM에서 AmazonECSTaskExecutionRolePolicy 권한을 가진 역할 생성
3) ECS Service 생성
4) 로드 밸런서 구성
•
Application Load Balancer 생성
•
HTTP or HTTPS 트래픽 허용 설정
5) GitHub Actions 기반 Workflow 작성
6) 새롭게 생성한 서비스가 운영환경에서 정상 동작하는 지 임시 포트로 확인 후, 기존 트래픽에서 서비스하기 위해 로드밸런서 내 기존 포트에서 타겟그룹만 교체
•
같은 로드 밸런서 내 일시적으로 다른 트래픽으로 전달 받는 타겟 그룹 생성
임시 포트(999)로 정상 트래픽 전달 확인
•
이후 443 포트로 타겟 그룹 교체하여 작업 완료
이슈 1) DB 보안그룹 내 WAS 트래픽 미설정에 따른 DB 커넥션 실패 이슈
•
현상: WAS DB Connection 실패
•
원인
RDB의 보안그룹 인바운드 설정에 WAS의 트래픽 X
•
해결
RDB의 보안그룹 인바운드 설정에 WAS 주소 포함하여 해결
이슈 2) ECS 서비스 외 로드 밸런서 보안그룹 설정 필요
•
현상
fargate 내 서비스 정상 구동 후 도메인 연결까지 완료했지만 로컬에서 해당 도메인으로 ping 요청 시 time out 발생
서비스가 올라온 fargate 자체적인 health check도 정상이었고 이벤트나 로그를 확인해도 모두 정상이었음
•
원인
로드 밸런서 보안그룹 오설정
•
해결
ECS 서비스에 대한 보안그룹 외에도 로드 밸런서에 대한 보안그룹에 80포트에 대한 인바운드 트래픽 허용 후 정상 동작
기존 보안 그룹의 정책은 default 였는데, 소스가 anywhere가 아니라 특정 보안 그룹으로 지정되었음
이슈 4) 상태검사 실패 by Time Out
•
‘상태 검사 유예 기간’ 증가(150 → 300) 설정 후 상태검사 성공
•
‘상태 검사 유예 기간’이란 로드 밸런서의 대상그룹을 대상으로 시도하는 상태검사에 대한 제한시간 설정을 무시하고 지정된 시간 동안 서버 인스턴스를 살려두는 것
→ 상태검사 제한시간을 넘어서 서버 인스턴스가 활성화 될 경우, 해당 설정을 통해 상태검사를 성공으로 이끌 수 있음
참고) 상태 검사 유예 기간 설정 관련 이미지
→ ECS 서비스란의 세부 정보에서 확인 가능함
→ 설정은 ECS 서비스란의 업데이트를 통해 지정 가능
Reference
•
실습으로 배우는 AWS 핵심 서비스, https://www.inflearn.com/course/aws-핵심-실습/dashboard
•
Container Launch Type, https://docs.aws.amazon.com/AmazonECS/latest/developerguide/application_architecture.html
•
Register EC2 to ECS Cluster: https://stackoverflow.com/questions/37076074/register-an-instance-to-an-aws-ecs-cluster