30. AWS 예산 설정
루트 계정 -> 계정
결제 정보의 접근을 위한 IAM 사용자와 역활
IAM 액세스 활성화하면 IAM 사용자로 청구 알람을 받을 수 있다.
이제 iam 계정으로도 bill 에서 청구서를 볼 수 있다.
31. EC2 기초
Elastic Computer Cloud
서비스형 인프라스트럭처, 다양한 기능들을 포함
- EC2 인스턴스
- EBS 볼륨
- 일래스틱 로드 밸런서
- 오토 스케일링 그룹, 서비스 확장
1. 운영체제
- 리눅스, 윈도우, 맥
2. 컴퓨팅 성능(CPU/RAM)
3. Storage
- EBS, EFS
- 하드웨어 붙이기
4. 네트워크(IP 등)
5. 보안 그룹(방화벽)
6. 부트스트랩 스크립트
- 처음에 설정하는 EC2 사용자 데이터
부트스트래핑 : 머신이 작동할 때 명령을 시작하는 것. 처음 시작할 때 한 번만 실행된다.
부팅 작업을 자동화 한 것이 부트스트래핑
- 작업 : 업데이트, 소프트웨어 다운로드, 인터넷으로부터 파일 다운로드
- sudo, 관리자 권한으로 실행
t2.micro가 AWS의 프리 티어로 한 달에 750 시간까지 사용할 수 있다.
인스턴스를 한 달 동안 실행해도 되는 수준이다.
Amazon EC2 Instance Comparison (vantage.sh)
Amazon EC2 Instance Comparison
instances.vantage.sh
32. EC2 인스턴스 생성
#!/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
처음에 실행되는 스크립트이다.
종료시 삭제는 반드시 YES로 해놓자
네트워크는 SSH와 HTTP만 뚫어놓자
생성된 인스턴스의 퍼블릭 ip로 접근해보자
위와같이 현재 서버의 위치를 볼 수 있다.
이제 인스턴스를 중지시켜보자
인스턴트 종료(삭제)까지 해보자
33. EC2 인스턴스 유형 기본 사항
Amazon EC2 인스턴스 유형 – Amazon Web Services⠀
Amazon EC2 인스턴스 유형 – Amazon Web Services
aws.amazon.com
m5.2xlarge 의미
m : 인스턴스 크래스(m = general)
5 : 세대(5세대)
2xlarge : 인스턴스 크기(크기에 따라 메모리와 CPU 크기가 다르다)
시험 중요
범용의 인스턴스는 웹 ㅅ버나 코드 저장소등 다양한 작업
- 컴퓨팅, 메모리, 네트워킹 간의 균형이 맞음
최적의 인스턴스(고성능 프로세서)
집약적인 작업에 최적화된 인스턴스
일부 데이터의 일관 처리, 미디어 트랜스코딩, 고성능 웹 서버, HPC, 머신 러닝, 전용 게임 서버
C로 시작하는 이름
메모리 최적화
메모리에서 대규모 데이터셋을 처리하는 유형에 빠른 성능
- 메모리 데이터베이스(관계 비관계형 데이터베이스)
- 일래스틱 캐시, 분산 웹스케일 캐시 저장소
- 비즈니스 인텔리전스
- 대규모 비정형 데이터의 실시간 처리 애플리케이션
스토리지 최적화 인스턴스
로컬 스토리지에서 대규모의 데이터셋에 액세스할 떄 적합
- 고주파 온라인 트랜잭션 처리 OLTP 시스템
- 관계형, 비관계형 NoSQL 데이터베이스
- 레디스 같은 메모리 데이터베이스의 캐시나
- 데이터 웨어하우징 애플리케이션
- 분산 파일 시스템
Ec2 인스턴스 주변의 방화벽
보안 그룹은 AWS 클라우드에서 네트워크 보안을 실행하는데 핵심이 된다.
EC2에 들어오는 트래픽 제어
보안 그룹은 허용 규칙만 포함
IP 주소로 보안 그룹 생성가능
다른 보안그룹 참조도 가능
EC2 주변에 보안 그룹을 생성(방화벽) 이때 규칙을 생성하는데
인바운드 트래픽의 여부이다.
외부에서 EC2 들어오면 인바운드 나가면 아웃바운드
EC2 보안 그룹 = 방화벽
포트로서 액세스 제어
인증된 IP 주소의 범위를 확인 IPv4, IPv6 확인
인바운드, 아웃바운드 네트워크 제어
보안 그룹 제어는 프로토콜, 포트 범위, IP 소스 범위
EC2 인스턴스에 인바운드와 아웃바운드의 보안 그룹이 존재한다.
22번 포트를 허용할때 트래픽은 컴퓨터에서 EC2로 이동할 수 있지만
다른 컴퓨터는 IP가 달라서 들어오는 것을 막는다.
EC2 인스턴스는 아웃바운드에 기본적으로 웹사이트 접속은 허용한다. 이는 보안 그룹에서 허용하는 것이다.
시험
보안 그룹과 인스턴스 간에 일대일 관계는 없다.
인스턴스에도 여러 보안 그룹을 연결할 수 있다.
보안 그룹은 지역과 VPC 결합으로 통제되어 있다.
지역을 전환하면 새 보안 그룹을 생성하거나 다른 VPC를 생성해야 한다.
보안 그룹은 EC2 외부에 있다 트래픽이 차단되면 EC2 인스턴스는 확인 불가능하다.
SSH 액세스를 위해 하나의 별도 보안 그룹을 유지하는 것이 좋다.
타임아웃으로 애플리케이션에 접근 못하면 보안 그룹문제이다.
거부 오류문제는 보안 그룹은 통과했지만 애플리케이션쪽 문제이다.
모든 인바운드는 막혀있고 아웃바운드는 뚫려있다
보안 그룹의 다른 보안 그룹을 참조하는 방법
EC2 인스턴스가 있고 보안 그룹1이라는 보안 그룹이 있다.
인바운드 규칙은 보안 그룹1의 인바운드를 보안 그룹2에 허용하는 것이다.
첫 번째 EC2 인스턴스가 정한 포트를 통해서 EC2 인스턴스가 바로 연결되도록 허용한다.
보안 그룹 1에 연결된 다른 EC2 가 있다면 이 인스턴스도 우리의 인스턴스와 바로 통신하도록 허용
EC2 인스턴스의 IP와는 상관없는 일이다. 올바른 보안 그룹에 연결되어 있기 떄문에 다른 인스턴스를 통해 바로 통신할 수 있다.
또 다른 EC2는 보안 그룹 3에 연결되는데 보안 그룹 1의 인바운드 규칙으로 보안 그룹 3과 연결되어 있지 않아서 접근이 거부된다.
시험
포트
SSH(22)
FTP(21) - 파일 공유 시스템
SFTP(22) - SSH를 통해서 업로드, 보안된다.
HTTP(80) - 보안이 되지 않는 인터넷
HTTPS(443) - 보안 사이트에 접근
RDP(3389) - 원격 데스크톱 프로토콜
35. 보안 그룹 실습
launch-wizard-4 : EC2 생성시 생긴 보안 그룹
default : 기본
만약 HTTP 규칙을 지우면 현재 생성된 EC2로는 접근이 불가능하다.
유지 보수나 조치를 취하기 위해 서버 내부와 연결하는 것은 까다롭다.
그래서 SSH를 사용하게 된다.
운영체제에 따라 방법은 다양하다.
MAC, LINUX
대충 위와같이 mobaXterm으로 연결해주면 된다.
aws iam list-users 를 입력했는데 configure이 안되었다는 메세지가 뜬다. 이걸 설정하기 위해 aws configure 를 사용하는 것은 좋지 않은 생각이다. 이 계정 상의 누구라도 다시 EC2 인스턴스에 접속해서 자격 증명 정보를 회수할 수 있기 때문이다. 그래서 IAM API키를 절대로 입력하면 안된다. EC2 인스턴ㅅ흐에 액세스 키 ID와 비밀 액세스 키를 입력하는 것은 최악의 방법이다.
IAM 역활을 대신 사용하자
우리 인스턴스에 IAM role 이 없는 것을 볼 수 있다.
iam으로 가보면 DemoRoleForEC2 라는 것을 만들어 놓은 적이 있는데 이건 IAMReadOnlyAccess만 허용되어 있는 역활이다. 이걸 EC2에 적용해주자
IAM role을 붙여주자
iam 역활을 붙여주기만 했는데도 유저 정보를 볼 수 있다.
만약에 역활을 지워버렸다면 이렇게 보는 것이 불가능해진다.
43. EC2 인스턴스 시작
예측 가능한 워크스테이션이다.
오랜 시간 사용시 조심해야 하는 인스턴트들이 있어서 이것들을 막기 위한 알림 옵션이 존재한다.
시험
1. 예약 인스턴스 -> 최소 1년 사용
- 예약 인스턴스 : 데이터베이스, 장기 워크로드
- 전환형 예약 인스턴스 : 시간이 지난 후 다른 형태의 인스턴스로 바꿀 수 있다.
- 정기 예약 인스턴스 : 특정 날짜 특정 시간에만 가동된다.
2. 스팟 인스턴스 : 단기 워크로드용, 손실 위험이 있다.
3. 전용 호스트 : 물리적 서버 전체를 예약, 인스턴스 배치를 제어
시험
1. EC2 온-디멘드 : 사용한만큼 지불
- 리눅스 : 비용이 초당 청구, EC2 가 실행된 1분 후
- 그 외의 것들 : 시간당 청구
2. 가격은 높지만, 선결제난 정기 약정이 없어서 중간에 멈추어도 된다.
온-디멘드 방식은 애플리케이션 작동 방식을 예측할 수 없는 연속적인 단기 워크로드에 적합
예약 인스턴스
온-디맨드와 비교해서 75% 절약 가능
1, 3년중 대여하는 것이다.
구매 옵션
- 전체 선결제는 오늘 바로 결제 -> 더 많이 할인
예약 인스턴스이기 때문에 특정 인스턴스 선택하기
그래서 DB가 들어가는 인스턴스는 좋은 걸로 오래 예약하는 것이 좋다
---
예약 인스턴스 종류
- 전환형 예약 인스턴스 : 시간이 지나면 EC2 인스턴스를 바꿀 수 있다. 할인율이 줄어든다. 54%까지 할인
- 정기 예약 인스턴스 : 예약한 특정한 시간대에 EC2 인스턴스를 시작해야 하는 경우 하루, 한 주, 혹은 한 달의 일부만 이용하는 방식.
스팟 인스턴스
할인율이 가장 좋다. 최대 90%까지 할인된다
특정 조건이 필요한데 우리가 지불하고자 하는 가격이 현재 스팟 인스턴스 가격보다 적다면 언제든 중지될 수 있다.
AWS에서 가장 비용 효율적이지만 서비스 중단에도 복구가 쉬워서 워크로드에서만 사용한다.
- 단발성 데이터 분석인 배치 로드
- 이미지 프로세싱
- 분산된 워크로드
- 시작 및 종료시점에 탄력적인 워크로드인 경우에도 스팟 인스턴스가 좋다.
데이터베이스에는 절때로 사용하면 안된다.
전용 호스트
EC2 인스턴스를 갖춘 유저 중심의 물리적 서버이다.
AWS 데이터 센터 내 하나의 서버 전체를 대여
전용 호슽ㅡ를 사용하면 준수 요건의 처리가 쉽고
서버 결합 소프트웨어 라이센스의 사용이 가능하기 때문에 비용을 절감할 수 있다.
규정 준수 요건과 서버 결합 소프트웨어 라이센스, 두 개는 시험에 나올 수도 있다.
이러한 전용 호스트가 3년의 예약 기간 동안 계정에 할당된다. 따라서 이러한 계약 사항을 이행해야하고 전체 서버를 독자적으로 이용하게 되니 비용은 올라가게된다.
만약 복잡한 라이센스 모델의 소프트웨어를 만들거나 자가 라이센스를 가진 경우, 혹은 강력한 규제나 규정 준수 요건이 있을 때도 상당한 도움을 준다.
가끔은 규제나 규정 준수때문에 우리들만의 서버를 원할 때 사용한다.
전용 인스턴스
전용 하드웨어에서 실행되는 EC2 인스턴스, 같은 계정의 다른 인스턴스와 하드웨어를 공유하며 언제 어떻게 배치될지에 대해서는 우리가 간선합 수 없다. 전용 하드웨어가 있어도 해당 하드웨어의 근본에 접근 불가. 전용 호스트의 약한 버전.
표를 보면서 확인해보자. 두 개 옵션모두 전용 물리적 서버를 사용하지만
전용 호스트는 호스트당, 전용 인스턴스는 인스턴스당 비용이 청구
또 전용 호스트는 하드웨어 근본에 접근 권한이 많다. 그래서 전용 호스트웨어 사용 가능한 다양한 서버 결합 라이센스를 받을 수 있다. 소켓, 코어 그리고 호스트 ID 접근 권한이 있다. 반면 전용인스턴스가 제공하는 것은 딱 하나로 자동 인스턴스 배치이다.
전용 호스트가 관여도가 더 높기 때문에 서버 결합 라이센스가 있다면 더 적합. 전용 인스턴스의경우 높은 수준의 규제 준수가 필요해 하드웨어를 타인과 공유하고 싶지 않을 때 사용
문제가 이걸로 많이 출제되지는 않는다.
알겠지만 텍스트가 없으면 반드시 중요하게 볼 필요가 없다.
44. 스팟 인스턴스 및 스팟 집합
스팟 인스턴스를 사용하면 높은 할인을 받을 수 있다.어떤 스팟 인스턴스에 대해 지불할 의향이 있는 스팟 최고가를 정의한 후 인스턴스 비용이 지불 의향 있는 그 최고가보다 낮은 한 계속 사용하게 된다.
만약 현재 스팟 가격이 정의된 최고 가격보다 높아지는 경우
1. 2분의 유예 시간으로 시간을 벌거나
2. 인스터스를 중단하거나 -> 나중에 재시작
3. 아예 종료 -> 나중에 새시작
또 다른 전략은 스팟 블록을 사용하는 것이다. 스팟 인스턴스를 회수당할 일이 없도록 만드는 것이다. 특정 기간 동안 인스턴스를 차단하는 기능이다. ex. 1pm to 6pm 동안 걸어놓으면 아무 방해 없이 차단이 가능하다. 삭제될 기능이지만 시험에 나올 수는 있다.
스팟 인스턴스는
- 배치 작업
- 데이터 분석
- 복원력이 있는 워크로드
- DB에는 부적합
스팟의 가격은 가용 영역에 따라 다양하게 적용. 삼 개월 ㄷ동안 가격의 변동이 제법 있었는데 우리가 정의한 사용자 최고 가격을 검은 점심이라고 하면 노란선은 검은 점선보다 높아졌기 때문에 스팟 인스턴스를 잃을 수 있어서 중지하거나 종료해야 한다.
스팟 요청의 원리(시험)
1. 원하는 인스턴스의 개수, 인스턴스 최고 가격 AMI 등 요구되는 사양, 유효 요청의 유효 기간, 요청의 유형
- 일회성 요청 : 스팟 요청이 이행되는 즉시 인스턴스가 실행 -> 스팟 요청이 사라진다. 즉 스팟이 사라져도 괜찮은 경우에 사용한다.
- 사후 인스턴스(지속적인 요청) : Valid from부터 Valid until 까지 유효 기간 동안 우리가 요청한 개수의 인스턴스들이 계속 유효하게 된다. 즉 어떤 잉로 인스턴스가 중단되거나 스팟 가격 상승을 이유로 방해를 받은 경우에는 스팟 요청이 다시 전단되어 요청이 검증되고 나면 스팟 인스터느가 재시작. 즉 이 경우에는 스팟 요청이 계속 남게 된다. 이때 스팟 요청이 중지하기 위해서는 open, active, disabled 상태여야 한다. failed나 cancelled 혹은 closed 가 아니어야 한다.
스팟 요청을 취소하려는 경우 기존에 실행했던 인스턴스는 종료되지 않는다.
그래서 이 것들을 영구 종료하는 일은 우리의 책임이기 때문에 먼저 스팟 요청을 취소한 뒤 해당 요청과 연결된 스팟 인스턴스를 종료해야 한다.
만약 스팟 인스턴스를 종료하면 무한으로 다시 시작해주기 떄문이다.
스팟 플릭(시험)
한 세트의 스팟 인스턴스에다가 선택적으로 온디맨드 인스턴스를 조합해 사용하는 방식 그래서 집합의 뜻인 플릿(Fleet)이 붙었다. 그리고 스팟 플릿은 정의된 비용 제한 내에서 대상 용량을 맞추려 노력한다. 사용 가능한 런치풀(Launch Pool)을 통해서 실행이 되는데 다양한 인스턴스 유형, 다양한 OS 그리고 다양한 가용 영역을 가질 수 있다.
여러 개의 런치풀과 여러 개의 인스턴스 크기 등 여러 가지의 것들을 정의하게 된다. 그리고나 가장 최적의 플릿을 선택해 준다. 사전에 선택한 비용에 도달하면 인스턴스는 자동으로 멈춘다.
스팟 플릿에 스팟 인스턴스를 정의 할때 규칙(시험)
- lowerPrice : 스팟 플릿이 가장 적은 비용을 가진 풀에서부터 인스턴스를 실행해준다. 아주 짧은 워크로드가 있을 때 비용 절감 효과를 볼 수 있다.
- diversified : 우리가 정의한 모든 풀에 걸쳐 분산되어 인스턴스가 생성된다. 긴 워크로드에 적합
- capacityOptimized : 인스턴스의 개수에 따라서 최적 용량으로 실행, 적절한 풀을 찾아 주는 옵션
45.EC2 인스턴스 lauch type 실습
![](https://blog.kakaocdn.net/dn/bpBVyK/btrOYIj4pBm/p8Xv5mkJWbsKOr2LQ7qaEk/img.png)
요금 내역을 먼저 보자
![](https://blog.kakaocdn.net/dn/bkcjkc/btrO0pcKvUk/FJJjM6fGoH1i0eutvGplEK/img.png)
그러면 위와같이 요금 내역을 볼 수 있고
위쪽 검은색은 온디멘드 가격이다.
각 가용 영역의 가격이 나와 있다.
여기에서는 비용이 69~70프로 정도 비용을 절감한다는 것을 알 수 있다.
이제 스팟 인스턴스 요청을 눌러보자
![](https://blog.kakaocdn.net/dn/uN1f7/btrO1whWrYX/KhUZAWSjPoFUBSIjnG4Gwk/img.png)
![](https://blog.kakaocdn.net/dn/CprtK/btrO2oYdLKR/ZkK8jGrMP5HFO3DCFZnCe1/img.png)
비용을 위와같이 지정할 수 있다.
![](https://blog.kakaocdn.net/dn/r0XPP/btrOY9oc0dX/c4OdBO2PtwFBESImHNHKH1/img.png)
![](https://blog.kakaocdn.net/dn/D2cSc/btrO00p03gY/Ixgnd96Ye8pkJtDTuR3jB1/img.png)
![](https://blog.kakaocdn.net/dn/FIhIA/btrOZatSnW2/emCwWypKT7EvYgmDZF8sw1/img.png)
위와 같이 우리가 원하는 유형으로 인스턴스를 생성할 수 있게 된다.
![](https://blog.kakaocdn.net/dn/cVoAyo/btrO1xnz9ie/4kGtAiUPaOder9T1k3By3K/img.png)
위와 같이 용량 방식도 지정할 수 있다.
![](https://blog.kakaocdn.net/dn/cYFpjF/btrOZbfdJaL/Om8znIj4kG6FydJJ3sIPr1/img.png)
대충 위와같이 나왔는데 72%의 절감 효과를 볼 수 있다.
![](https://blog.kakaocdn.net/dn/oNygx/btrOZanbeQn/4VqY4GSluEZQ9soUbZhXp1/img.png)
혹은 그냥 인스턴스 생성에서 위와같이 스팟 인스턴스 요청을 할 수도 있다.
![](https://blog.kakaocdn.net/dn/QXmge/btrO1xunPlQ/GOZzbhzni0ZdqalfROoVnk/img.png)
예약 인스턴스라는 것도 존재한다.
![](https://blog.kakaocdn.net/dn/bZeZDv/btrO1w93LN9/wXTlKZtqEGmBHiTbjdm8fk/img.png)
그러면 위와같이 선결제 요금과 시간당 요금들을 볼 수 있다.
![](https://blog.kakaocdn.net/dn/bqOpoy/btrOZ8oNwRu/fVZBJLtKbAjUu9QD9nPfZ0/img.png)
하지만 요즘 AWS는 예약 인스턴스 보다는 Savings Plans를 추천하기도 한다. 1~3년 계약기간동안 정해진 액수의 시간당 금액을 지속적으로 지불해 인스턴스 실행 방식을 유동적으로 지정가능.
![](https://blog.kakaocdn.net/dn/Qrw1o/btrOZ9uuf6C/doNKMRF8empR25NbMICbtk/img.png)
전용 호스트(Dedicated Hosts)는 낮은 수준의 하드웨어로 액세스할 수 있는 호스트를 실행할 수 있는 옵션으로 라이센싱 가격이 좋아진다는 장점이 생긴다.
위의 시작하기 버튼을 눌러보자
![](https://blog.kakaocdn.net/dn/dLsP7Q/btrOY9hrSN6/KXyxjgEh5qIlsCN7deGNe0/img.png)
그러면 호스트의 관점이 아니라 라이센스의 관점에서 고려를 하게 된다. 그리고 이런 식으로 전용 호스트의 관리가 간편화된다.
![](https://blog.kakaocdn.net/dn/CdesC/btrO1wPJUIo/tEJyms2z4K6kMjmJzFOgLk/img.png)
UI에서 직접 전용 호스트를 싱행시키려면 '전용 호스트 할당'을 눌러 이름과 인스턴스 패밀리를 지정해야 한다.
![](https://blog.kakaocdn.net/dn/vd9J3/btrOZIX9ROC/3SIXO35MhY2cGoXk0SJlJ1/img.png)
마지막으로 용량 예약이라는 것도 존재한다. EC2 인스턴스의 실행에서 용량의 사용 가능 여부를 확실하게 하고자 할 때 사용한다.
![](https://blog.kakaocdn.net/dn/bpL7EC/btrO1wPJUFc/t5hGG2oGJAxdJiL9csZPBK/img.png)
![](https://blog.kakaocdn.net/dn/wE9V2/btrO0Y6See8/TdkIXaJa1WI3neFTskoWAk/img.png)
![](https://blog.kakaocdn.net/dn/bEeHo4/btrOYIxAB8e/Blxq9PNdspqYomD1N83zSk/img.png)
![](https://blog.kakaocdn.net/dn/dhUrsV/btrOQBXsrFL/mcbBUkdC5i6EyEKoQrnvwk/img.png)
![](https://blog.kakaocdn.net/dn/b5SJgR/btrOZ8vwCzn/Oz7VrKQ7eKm2NJ9k4DZByk/img.png)
![](https://blog.kakaocdn.net/dn/bLMR24/btrOZ9Vybxc/xq9Is15VSZVDZv1VzF1TU1/img.png)
![](https://blog.kakaocdn.net/dn/dkz9I0/btrOYGT5AzO/Pz8fm98pkaKotSlCZRAiyK/img.png)
![](https://blog.kakaocdn.net/dn/clHNI9/btrO0IpyGOe/wkbiLjsVQ87xEbuIhW9sq0/img.png)
![](https://blog.kakaocdn.net/dn/RYLsG/btrO0n0kbf8/EeUImQ5MvWVNRRHkJfugkK/img.png)
![](https://blog.kakaocdn.net/dn/wnBeZ/btrOZJW5vFT/YF8pynMBPbcWNpQHf3BCUK/img.png)
![](https://blog.kakaocdn.net/dn/zGfo4/btrO2WNWtlA/tKkLS0uv0ht2YYQkCZXuRk/img.jpg)
'자격증들 > 22) AWS Certified SAA' 카테고리의 다른 글
AWS Certified Soultions Architect Associate Day 07(EBS) (0) | 2022.10.19 |
---|---|
AWS Certified Soultions Architect Associate Day 06(EC2-SAA) (0) | 2022.10.19 |
AWS Certified Soultions Architect Associate Day 03(IAM) (0) | 2022.09.27 |
AWS Certified Soultions Architect Associate Day 02 (0) | 2022.09.16 |
AWS Certified Soultions Architect Associate Day 01 (0) | 2022.08.29 |