AWS 플랫폼에 네트워크 및 시스템을 자동화 및 반복 배포하는 방법에 대해 알아보기
- Amazon Virtual Private Cloud(VPC), Amazon Elastic Compute Cloud(Amazon EC2), Elastic Load Balancing(ELB), AWS Auto Scaling과 같은 표준 AWS 인프라 기능을 명령줄에서 사용합니다.
- AWS CloudFormation 및 다른 자동화 기술을 사용하여 AWS 리소스 스택 생성
- Amazon VPC를 사용하여 가상 프라이빗 네트워크를 구축
- 명령줄 호출을 통해 Amazon EC2 인스턴스를 배포하고 인스턴스에서 흔히 발생하는 문제를 해결합니다.
- Amazon EC2 인스턴스와 기타 AWS 서비스의 상태를 모니터링합니다.
- AWS 클라우드에서 자격 증명, AWS 권한 및 보안을 관리
- 태그, Amazon CloudWatch 및 AWS Trusted Advisor를 사용하여 AWS 계정의 리소스 사용을 관리
- 재사용 가능한 Amazon EC2 인스턴스를 생성하는 최적의 전략을 결정
- 단일 로드 밸런서 뒤에서 실행되는 Amazon EC2 인스턴스 집합을 구성
- 기본 AWS CloudFormation 스택 정의를 문제 해결
개요
| sysops | 시스템 운영의 노하우 |
| 서버와 인스턴스 | 서버는 애지중지, 인스턴스는 임시로 빌려서 사용 |
| 글로벌 인프라 | 리전과 가용 영역, 엣지 로케이션 - 데이터센터의 묶음이 가용영역(AZ) - 2개 이상의 가용영역을 합쳐서 리전 |
| 핵심 서비스 | 네트워크, 컴퓨팅, 스토리지, 관리 등 |
| AWS 계정 보안 | IAM(user, role) |
클라우드 기반의 시스템 운영
| 시스템 운영 | 구축 이후 배포, 모니터링, 유지보수, 테스트, 보호 |
| DevOps | 개념 : 개발자들이 운영까지도 고려 배경 : 클라우드로 인해 자동화 환경이 좋아지고, 운영 접근성 용이 |
| DevSecOps | 개발+운영에다 보안까지 고려하는 최근 트렌드 결국 클라우드 관리 비용 감소 가능 서비스 : WAF, Shield |
| 캐시 | 데이터를 가까운 곳에 가져다 두고서 필요 시 불러 쓸 수 있는 개념 |
| 엣지 로케이션 CloudFront |
엣지 로케이션에서의 서비스 CloudFront - 개념 : 웹 캐시 기능 제공 서비스 - 구성 : 전 세계 230개소에 존재 .POP영역 : 사용자가 가장 먼저 접속하는 포인트 .POP영역이 엣지 로케이션이라 볼 수 있음 - 활성화 : 엣지 로케이션에다 활성화(2번째 요청 부터 빠른 응답) |
| 리전 선택 | 데이터 거버넌스, 법적 요구사항 지연시간 사용 가능한 서비스 여부 비용 : 리전별로 다른 요금 비교 필요 |
| 시스템 운영위한 주요 서비스 | 네트워크 : 가상 네트워크, 논리적 격리, IP범위/라우팅/게이트웨이/보안설정 컴퓨팅 액세스 : 인증, 액세스, 사용자/그룹/역할/정책 |
| 서비스 범위 | 리전(VPC밖 서비스) : S3, AMI(S3에저장), CloudWatch지표, VPC, EBS스냅샷 - 완전관리형 서비스들은 리전내 서비스 임 가용영역 : EC2, EBS, RDS, Subnet 전 세계 - IAM 사용자, 그룹, 역할 - Route53 - CloudFront 배포 |
| 시나리오 배포 요구사항 |
고가용성, 필요에 따라 확장, 웹 로그 수집 및 분석 인스턴스 모니터링 및 유지관리, 보안을 고려한 설계 |
| 리소스 | 웹 서버, 데이터베이스, 오토스케일링, LB, 모니터링 및 로그 |
핵심 서비스
| 네트워그 구성 |  Route53-->인터넷게이트웨이-->Elastic Load Balancer -->웹서버( Private Subnet) |
| 배포용 패키지 |  |
| IAM | 인증(authentication) : 로그인을 의미 인가(autorization) : 로그인 상태에서 어떤 일을 할 수 있을 지 권한 제공 정책을 만들어서 사용자/그룹/역할을 생성해서 사용 가능을 인가함 |
| 인증의 방법인 '자격증명'의 유형 |
이메일 주소와 암호 : AWS계정(루트)에 연결 IAM 사용자 이름과 암호 : Management console에 액세스 - 주어진 URL로만 접근 가능 액세스 키 : CLI에서 주로 사용 멀티 팩터 인증 |
| IAM 사용자 관리 | 그룹에 사용자를 할당 사용자 액세스 키 권한 사용자에 대한 멀티 팩터 인증 관리 맞춤형 권한 제공(서비스 및 리소스별) 사용자에 태그 추가 계정 암호 정책 관리 : 암호화 수준, 길이, 암호 재설정 |
| IAM 권한 관리 | 정책을 만들고서 인가를 해 줘서 사용 가능 |
| 정책 및 권한 | 정책 유형 - 자격 증명 기반 정책 - 리소스 기반 정책 - SCP - ACL |
| 자격증명 기반 정책 | Version Statement - Effect : 권한 - Action : 활동 - Resource : 사용할 자원(ec2 등) - Condition |
| 리소스 기반 정책 | bucket policy : S3만의 |
| Policy |  Policy를 만들고 user에게 적용 가능 |
| 자격 증명 생성 예 |  확인 방법  |
| 임시 자격증명Role | Role은 임시 자격 증명임 - 제한 시간을 설정하여 보안성 확보 Role을 사용하는 4가지 방법 - web identity : 소셜 계정을 이용한 인증 - 다른 AWS계정에 대한 인증 제공 : Trust relationship 이후 롤을 부여 . switch role을 통해서 다른 AWS계정의 허용 롤의 정책을 인가 받음 - AWS service : 서비스별로 IAM role 선택 가능 - SAML : 기업간 
|
| 랩탑 접속 시 | key를 이용해서 aws 접속 가능 |
| IAM 정책 규칙 | 명시적 거부가 우선 - DENY가 있을 경우 명시적 거부가 우선 - DENY가 없을 경우 명시적 허용이 있으면 허용 묵시적 거부 : 명시적 사용을 하지 않으면 묵시적 거부 |
| IAM 역할의 기능 | 리소스에 대한 접근 권한 SSO을 위한 SAML2.0 교차 계정 접근 가능 |
| MFA | 인증 : 암호(지식), 토큰(소유) |
| 복수 계정 | 격리 : 사업부별 격리 - 하나의 계정에 하나의 VPC 사용 --> 계정관리 통합 AWS Organizations - 사업부별 Root 계정 관리 |
| SCP | SCP : OU에 SCP 할당 - OU에 AWS계정 할당 |
CLI 사용하여 AWS 서비스 제어
| Systems Manager 개요 |
시스템 관리 - AWS 인프라에 대한 가시성과 제어를 제공 |
| AWS 사용 방법 | Management Console CLI SDK |
| CLI | aws config로 설정 액세스키와 보안 액세스 키 받아서 처리 형식 aws 서비스명 작업 파라미터 옵션 예시 aws ec2 run-instances --cli-input-json file://webserver.json ;; json방식으로 저장 후 사용 |
| CLI --query 옵션 | aws ec2 describe-instances --query 'Resrvationino[0].Instances[0].State.Name' -> 의미 : 첫 번째 RI인스턴스의 상태 확인 |
| CLI --filter 옵션 | aws ec2 describe-instances --filter "Nme=instance-type, Values=t2.micro, t2.small" --query "Reservations[*].Instances[*].InstanceId" -> 의미 : 인스턴스(--filter)의 인스턴스 ID만(--query) 표시 |
| CLI --dry-run | 권한 보유 유무 확인 가능 - 필요 권한이 없을 경우 오류를 리턴함 |
| 출력형식 CLI --output table |
테이블 형태 text형태로 표시 테이블 형식 : --output table 텍스트 형식 : --output text |
| CLI 명령 레퍼런스 | 링크 https://docs.aws.amazon.com/ko_kr/cli/latest/reference/ec2/describe-instances.html |
Systems Manager
| 기능 | 소프트웨어 인벤토리 수집, OS패치, 시스템 이미지, OS관리 및 구성 - 자동화, 세션관리자, 패치관리자(종속성), RUN COMMAND(정의 명령어 등), - 유지관리 기간(스케쥴링), 상태관리자(수정발생 시 알림), 파라미터 스토어, - 인벤토리, 인사이트 대시보드 |
| 세션 관리자 | Bastion서버 필요 없이 내부에서 직접 private instance로 접근 가능 - 인바운드 포트 필요 없이 안전하게 인스턴스 접근 |
| 유지 관리 기간 | 작업 시간 예약 |
| 상태 관리자 | 일관된 구성을 유지, 변경이 발생되면 알림 제공 |
| 파라미터 스토어 | 코드에 포함하지 않고, 파라미터 스토어에 저장해 두고 코드에서는 파라미터 스토어를 이용해서 id/pwd 요청을 할 수 있게 됨 |
| 인벤토리 | 설치된 소프트웨어에 대한 정보 수집 - 애플리케이션 데이터, 파일, 네트워크 구성, 시스템 속성 등 |
| 실습) 인벤토리 RUN COMMAND 파라미터 스토어 세션 관리자 |
인벤토리 : 구성과 권한 확인 - 각 인스턴스에 SSH연결 없이 소프트웨어 구성 내역 확인 가능 RUN COMMAND : 여러 서버에서 작업을 실행 - SSH로 인스턴스에 원격 액세스 필요없이 사용자 지정 애플리케이션 설치 가능 파라미터 스토어 : 애플리케이션 설정 또는 구성을 업데이트 세션 관리자 : 인스턴스에서 명령줄에 액세스 - 인바운드 포트를 열거나 ssh키 관리 필요 없이도 안전하고 감사가능한 인스턴스 관리 가능 과제 1: 관리형 인스턴스의 인벤토리 목록 생성 과제 2: Run Command를 사용하여 사용자 지정 애플리케이션 설치 과제 3: 파라미터 스토어를 사용하여 애플리케이션 설정 관리 과제 4: 세션 관리자를 사용하여 인스턴스에 액세스 |
과제 1: 관리형 인스턴스의 인벤토리 목록 생성  |
|
과제 2: Run Command를 사용하여 사용자 지정 애플리케이션 설치  |
|
과제 3: 파라미터 스토어를 사용하여 애플리케이션 설정 관리 추가 차트 표시 : 차트가 2개에서 3개로 증가  |
|
과제 4: 세션 관리자를 사용하여 인스턴스에 액세스  
  - aws config : 권한을 가지고 있는 키값을 사전에 설정하는 과정 수행 후 인스턴스 정보 확인 가능 |
추가 관리 도구
| powerShell용 AWS도구 | powershell명령줄에서의 스크립트 작업 가능 - 보안그룹 생성 및 구성, 인스턴스 시작 등 |
| SDK | 다양한 언어 제공 : Go, Node.js, C++, Java 등 |
컴퓨팅
| 인스턴스 프로비저닝 | AMI : 이미지 네트워크 : VPC 볼륨 스토리지 : EBS 사용자 데이터 : AMI 설치 시 실행되는 사용자 스크립트 보안그룹 키페어 : 인스턴스 접속 |
| 인스턴스 유형 | 범주 : 범용, 컴퓨팅 최적화, 스토리지 최적화, 메모리 최적화 패밀리, 유형, 변형 등 |
| AMI | 머신 이미지 구성요소 : 인스턴스 볼륨 템플릿, 시작 권한, 블로 디바이스 매핑 AMI 선택 : AWS제공, 커뮤니티, 마켓플레이스, 사용자 구축 |
| EC2 인스턴스용 블록 스토리지 | SSD : 범용 gp2 & gp3(최신으로 사용 권장) 프로비전IOPS io1& io2 HDD : 처리량 최적화 볼륨, Cold 볼륨 |
| 네트워킹 | IGW : public subnet 접속 탄력적IP 고정IP , Public IP는 일시적/동적IP ENI : virtual network interface, 모든 EC2인스턴스에 붙음 |
| 보안그룹 | ENI에 SG가 걸려 있어서 ENI를 통과할 것인지 구성 - 구성 형태 : 어디서나, 특정 컴퓨터, 보안그룹 멤버의 SSH액세스 허용 |
| 사용자 데이터 | 시작 시 실행되는 리눅스 스크립트 CloudInit : 초기 설정 스크립트 표준 cloudinit.readthedocs.io/en/latest/topics/availability.html  |
| EC2 인스턴스 메타데이터 | 인스턴스 구성 또는 관리에 사용되는 데이터 169.254.169.254 IP 주소에서 메타데이터 서비스 제공 예) http://169.254.169.254/latest/meta-data/instance-id/ |
| 키페어 | 원격 접속 |
| 자체 인스턴스 보안 설정 | 인스턴스 생성 후에 사용자 및 권한 변경 - 리눅스 : kerberos 기반 SSO, ssh-keygen을 사용하여 public/private 키페어 생성 사용자의 public 키를 ~/.ssh/authorized_keys에 추가 집합 전체 사용자 관리를 위한 전략 마련 - AMI, 구성 소프트웨어 사용 |
| 시작 후 구성 옵션 | 인스턴스 스크린샷 가져오기 종료 방지 활성화 : protect against accidental termination 인스턴스를 NAT 인스턴스, 라우터 또는 방화벽으로 사용하는 경우 |
| CLI 자동 생성 |  |
| 인스턴스 수명주기 | 실행중--> 중지됨--> 종료됨, 중지중--> 최대절전모드 실행 중 : 비용 청구 중지됨 : 청구되지 않음 종료됨 : 청구되지 않음 |
| 최대 절전 모드 | 사전 조건 : 지원되는 유형, AMI, EBS 볼륨, 온디맨드 또는 RI |
| 인스턴스 다시 시작 | 손상, OS아키텍처 또는 이미지 유형의 업그레이드, 다운그레이드, Auto Scaling, 비용절감 |
| 새 인스턴스 크기로 전환 | 인스턴스 유형 업데이트 |
| AMI 사용 중단 | 최신 AMI를 쿼리해서 사용 |
| 공동 책임 모델 | 고객의 역할 존재 |
| 취약성 검사 및 침투 테스트 | 공격 테스트 시 사전 알림을 통해서 모니터링에서 배제 관리 필요 |
| EC2 구매 옵션 | 온디맨드 인스턴스 예약 인스턴스 : 1년 또는 3년 스팟 인스턴스 : 온디맨드 요금 대비 최대90%까지 요금 절약 - 온디맨드 인스턴스 이외에 자주 안쓰는 리소스에 적용 - 1시간 또는 6시간 이내의 배치 작업 등에 적용 가능 : 짧은 시간 여러 개 분산 시 적용 - 2분전에 알림 수신 - 이용 통계 : 95% 정도는 최종 완료 전용 호스트 : 물리 장비 위치까지 고정하는 경우에 사용(CPU에 SW라이선스가 종속되는 경우) 전용 인스턴스 : 격리된 물리 장비에서 실행 i3.metal : 원하는 가상화 계층 또는 OS 실행 가능 물리 호스트 |
| 실습) | 과제 1: Management Console을 사용하여 Amazon EC2 인스턴스 시작 과제 2: Bastion 서버에 로그인 과제 3: AWS CLI를 사용하여 인스턴스 시작 도전 과제 1: Amazon EC2 인스턴스에 연결 도전 과제 2: 웹 서버 설치 수정 |
| 과제1 | 과제 1: Management Console을 사용하여 Amazon EC2 인스턴스 시작 - GUI 상으로 인스턴스 구성 및 시작 |
| 과제2 | 과제 2: Bastion 서버에 로그인 SSH 접속 가능하도록 SG에 22번 포트 인바운드에서 허용  ㅇ 인스턴스에서 Connect 클릭해서 id/pwd 없이 접속 가능  ㅇ 아래와 같이 접속 시도  |
| 과제3 |
과제 3: AWS CLI를 사용하여 인스턴스 시작 최신 AMI subnet 
 ㅇ CLI : 인스턴스 시작 명령어  |
| 도전 과제 : 웹페이지 접속 불가 - user data 확인을 통해서 web서버 기동 불량 확인   |
2일차 : ELB, Auto Scaling, Route53
ELB
| 온디맨드 조정 |  |
| 인스턴스로 연결되는 과정 | user --> Route53 --> ELB(인스턴스로 분산) --> 인스턴스(Auto Scaling 그룹) |
| ELB 기능 | 여러 대상으로 트래픽 자동 분산 - 고가용성(다수 분산), 상태확인, 보안 기능(EC2 미노출) - TLS종료(사용자로부터 ELB로의 HTTPS 구간이었으나, ELB~EC2내부 구간은 HTTP로 통신) . ELB~EC2간에는 EC2의 복호화 부담(5%정도 리소스) 경감을 위해 HTTP로 통신 - 4계층/7계층 로드 밸런싱 - 운영 모니터링 가능 |
| ELB 유형 | ALB : HTTP/HTTPS 사용 NLB : TCP, UDP, SSL 사용 CLB(이전 세대로 지금은 사용하지 않음) |
| ALB 기능 | 별도 타겟 그룹 설정 기능 : EC2그룹을 서비스 제공 기능에 따라 별도로 구성 - example.com/search, example.com/user 등으로 별도의 타겟 그룹 설정 가능 --> 장애 요인 분산 효과적 대응 기능 제공 |
Auto Scaling
| 오토스케일링 | 수요에 맞게 확장하고 비용 절감하도록 축소하는 자동화 기능 |
| 기능 | 예약 기능 제공(시간 기준 예약) |
| 오토스케일링 인스턴스 상태 | 인스턴스 상태 유지 비정상 인스턴스 종료 로드밸런서를 사용하는 경우 로드밸런서의 인스턴스 확인 EC2 Healthy : 상태가 건강 - 상태값 변경 가능 : aws autoscaling set-instance-health명령 |
| 오토스케일링 종료 정책 | 종료 대상 결정 종료 순서 : 인스턴스 수가 가장 많은 영역, 복수의 정책을 나열된 순서대로 실행 종료 정책 - OldestInstance - NewestInstance - OldestLaunchConfiguration : 가장 오래된 인스턴스 종료(과금 기준 고려 시 필요) - ClosestToNextInstanceHour |
| Steady State 그룹 생성 | 최소, 최대, 원하는 값으로 설정 - desired capacity 값이 증가하면서 스케일아웃 NAT인스턴스(아웃바운드만 허락) - NAT GW는 완전관리형이나 NAT인스턴스를 사용하고자 하는 고객 있음 - NAT인스턴스는 1,1,1로 설정해 두면 장애시 다시 복구 |
| 동적 조정 | 단계 추적 조정 : 에어컨 같이 수치를 정해 놓고 자동으로 ON/OFF 하는 방식 단순 조정 : CPU사용률 등 단순 지표 단계 조정 : 축소 경보, 확장 경보 - EC2 만드는 5분정도의 시간에 유입되는 트래픽에 대응하기에 어려운 단순조정 대응 - 급격한 트래픽 증가가 있을 경우를 대비해서 설정값을 여러 개 설정 - 예) EC2 만들고 있는 중에도 필요 시 늘리는 동작 수행 |
Route53
| 기능 | 리전간 트래픽 분산 기능 도메인 이름 등록 도메인 이름을 ip주소로 분석 지연시간, 상태확인, 가중치 기준으로 요청을 라우팅 |
| 라우팅 정책 | 단순 라우팅 : 라운드 로빈 방식 지리 위치 라우팅 : 유럽의 경우에 나라에 맞는 컨텐츠를 전달 시 필요 - 유럽 나라별로 ip가 다른 상황에서 적용 용이 - 미국의 경우에는 주단위로 라우팅 제공 가능 - 리전간 로드밸런싱도 가능 가중치 기반 라우팅 : 트래픽 비율을 나누어서 전달 지연 시간 기반 라우팅(LBR) : Latency(요청-응답간의 시간)이 짧은 쪽으로 트래픽 전달 |
| 블루/그린 배포 - 무중단 배포 전략 |
가중치 기반 라우팅을 활용해서 블루/그린 배포 가능 - 기존 : 블루 - 신규 : 그린 Route53에서 가중치 기반 라우팅을 통해서 배포 블루/그린 배포 = 레드/블랙 배포(넷플릭스 용어) |
실습
| 과제 | 과제 1: Amazon EC2 Auto Scaling을 위한 새 Amazon Machine Image 생성 과제 2: Auto Scaling 환경 생성 |
| AMI 생성 | 과제 1: Amazon EC2 Auto Scaling을 위한 새 Amazon Machine Image 생성 -CLI 로 AMI 생성, Auto Scale용 이미지 생성 UserData.txt [ec2-user@ip-10-5-10-12 ~]$ cat UserData.txt #!/bin/bash yum update -y --security yum -y install httpd php stress chkconfig httpd on /etc/init.d/httpd start cd /var/www/html wget https://us-west-2-tcprod.s3.amazonaws.com/courses/ILT-TF-100-SYSOPS/v3.3.31/lab-3-scaling-linux/scripts/ec2-stress.zip unzip ec2-stress.zip echo 'UserData has been successfully executed. ' >> /home/ec2-user/result find -wholename /root/.*history -wholename /home/*/.*history -exec rm -f {} \; find / -name 'authorized_keys' -exec rm -f {} \; rm -rf /var/lib/cloud/data/scripts/* 아래의 내뇽은 보안성 위해 key값은 노출되지 않도록 합니다. find -wholename /root/.*history -wholename /home/*/.*history -exec rm -f {} \; find / -name 'authorized_keys' -exec rm -f {} \; rm -rf /var/lib/cloud/data/scripts/* AMI 으로 인스턴스 생성(UserData를 포함해서 생성) aws ec2 run-instances --key-name qwikLABS-L9016-4120667 --instance-type t3.micro --image-id ami-06cd52961ce9f0d85 --user-data file :///home/ec2-user/UserData.txt --security-group-ids sg-05440e5e4fc480196 --subnet-id subnet-0f8131bb5830d86e6 --associate-public-ip-address --tag-specificatio ns 'ResourceType=instance,Tags=[{Key=Name,Value=WebServerBaseImage}]' --output text --query 'Instances[*].InstanceId' public DNS명 쿼리 [ec2-user@ip-10-5-10-12 ~]$ aws ec2 describe-instances --instance-id i-0486417bb460e077f --query 'Reservations[0].Instances[0].NetworkInterfaces[0].Associati on.PublicDnsName' "ec2-13-112-102-222.ap-northeast-1.compute.amazonaws.com" //DNS명 결과 출력 Auto Scale용 이미지 생성 (create image) [ec2-user@ip-10-5-10-12 ~]$ aws ec2 create-image --name WebServer --instance-id i-0486417bb460e077f { "ImageId": "ami-0bab7e373d672f543" }  Congirue Load Balancer 생성    LB 생성 이후 Launch Configurations 진행   |
| Auto Scaling | 과제 2: Auto Scaling 환경 생성 - 기존에 만들어 놓은 LB를 연결 ㅇ Target 트래킹 방식  |
데이터베이스
| SQL과 NoSQL로 구분 | SQL : RDS, Aurora - RDS : MySQL, PostgreSQL, MariaD, Aurora, Oracle, SQL Server - Redshift(Data Warehouse) NoSQL : DynamoDB, Neptune(관리형 그래프), ElasticCache(메모리DB) |
| 데이터베이스엔진 목적 | 저장자료 형태 - 과거 : 행렬 위주의 표(테이블)를 만들어서 관리, 여러 테이블을 만들고 관계를 구성해서 조인 - 최근 : 다양한 테이터 형태(key:value, graph, document, 시계열) 처리 |
| 스키마 설정 | 데이터 모델링을 통해서 스키마 설정 |
| 쿼리 | SQL의 표준 문법을 활용 |
| 확장성 | Scale-Up 방식과 Scale-out 방식 적용 - NoSQL : Scale-out 방식으로 확장 |
| RDS | 관리 편리 백업 제공 |
| RDS백업 | 자동 수동 : 스냅샷 |
| Multi-AZ | 고가용성 목적 - DB 변경 시 주소를 Takeover 해서 DB서비스 제공 |
| RDS 조정 | 오토스케일링은 할 수 없으나 스케일업 가능 스토리지 용량 : 잡아 놓은 사이즈에 대한 비용이 과도할 수 있으므로 사용할 만큼만 설정 - 처음에 작게 잡아 놓고서, 자동으로 늘어 나도록 관리하여 비용 절감 - 프로비전드IOPS(SSD) : 고성능 필요시 사용 |
| Aurora | 성능 : PostgreSQL보다 3배, MySQL보다 5배 빠른 성능 호환성 : Aurora MySQL, Aurora PostgreSQL이 있어 코드 변경 없이 간편히 마이그레이션 가능 요금 : 종량제 |
| Aurora 구성 | DB클러스터 : Main1개 + 3개의 복제본 - 대부분의 경우 읽기가 90%로 복제본을 통해서 읽기 성능 향상 |
| DynamoDB | 완전관리형 : 바로 테이블을 만들어서 즉시 사용 일정 성능 : 짧은 지연시간 유연성 : 용량 확장성 제어 : 세분화된 액세스 제어(컬럼별 접근제어 가능) |
| AWS DMS | 마이그레이션 서비스 |
| DMS 이점 | 최소한의 가동 중지로 DB를 AWS로 마이그레이션 : EC2에 SW배포로 DB변경 - 간편 사용 - 최소한의 가동 중단 - 보편적인 DB 지원 - 빠르고 쉬운 설정 - 안정성 - 저렴한 비용 |
| AWS SCT | Schema Conversion Tool |
네트워킹
| VPC | 논리적 분리된 네트워크 영역 |
| 전형적인 AWS 네트워크 구조도 |  - CIDR 체계 적용 |
| CIDR | 예시) 10.0.0.0 /16 - 16은 prefix - prefix까지 고정해서 네트워크 구분 ㅇ 0.0.0.0/0 모든 ip를 의미 ㅇ IP 할당 - 서브넷별로 5개가 예약되어 있어 사용 불가 : 0,1,2,3, 255 |
| 기본 라우팅 테이블 | 10.0.0.0/16 local // local로 표시 |
| 가용 영역 분산 | 장애 시 방어를 위한 구조 |
| VPC 만들기(간단) | Your VPC> Create VPC - Name, IP CIDR block - Edit DNS hostnames를 활성화 : EC2에 DNS 명칭 부여 가능  |
| Subnet 만들기 | VPC에 종속적이라 VPC 선택 필요 VPC, Name, AZ, IP CIDR block |
| 인터넷게이트웨이 설정 | Name만 설정하여 생성 - 모든 VPC에는 1개 IGW 가능 Attach 수행해서 연결  |
| public subnet에 public IP할당 - 자동 할당 |
auto-assign IP 
|
| 고정IP Elastic IP | NAT GW와 같이 고정IP가 필요한 경우에 사용 |
| 트래픽 방향 잡아 주기 Route Table(이정표) |
private route table : default 생성분을 사용 |
| subnet associations | 정의한 라우팅 테이블에 연결 |
| Route Table 생성 | 1) 생성 2) 연결 : 정의한 라우팅 테이블에 연결  |
| Public sunet의 트래픽을 IGW로 라우팅 설정 | Destination Target // 작은 범위부터 적용되는 규칙임 10.0.0.0/16 local // 밖으로 나가지 말고 안에서 트래픽 유통 0.0.0.0/0 Lab IGW /// 나머지 전부는 Lab IGW로 나가도록 설정 - 외부로 나가야 하는 경우 - 내부에서 쓰는 IP가 아니면 외부로 나갈 수 있어야 함 |
| 보안 패치를 위해 Public sunet 접근 필요 : NAT GW |
private route table 설정 - NAT GW와 private subnet 과 연결 0.0.0.0/0 Lab NATGW 설정해서 인터넷 연결 가능 Create NAT Gateway 설정 - Name, Subnet(public subnet), Elastic IP allocation(고정IP필요하므로 할당) 0.0.0.0/0 Lab NATGW -> private subnet의 인스턴스도 인터넷 접속 가능 |
| 접속 흐름 | user --> Route53 이후 user --> IGW --> ELB --> Route Table --> NW ACL(subnet전에 무조건 거침) --> Public Subnet - NW ACL에서는 인바운드와 아웃바운드 모두 설정 필요 |
| ENI | ENI에 접속하기 위해서는 EC2의 SG을 통과해야 함 Subnet-->SG --> ENI --> EC2 |
| 보안 3단계 | NW ACL, SG, Key |
| 앱서버에 올린 이미지 | S3에 저장하는 방식(S3에 저장 시도시 인터넷 구간 발생) -과거 : 앱은 NAT GW --> IGW --> S3 저장 : 전송 비용 발생 --> 지금은 VPC Endpoint : 앱서버에서 VPC Endpoint를 통해서 내부 S3로 접근 가능 |
| Endpoint 구분 | GW Endpoint : S3와 DynamoDB만 쓸 수 있음 Interface Endpoint : 나머지 서비스 - ENI를 만들어서 다른 서비스와 VPC내에서 통신 가능 |
| GW Endpoint | 앱서버에서 VPC Endpoint를 통해서 내부 S3로 접근 가능 - private link - 이점 : 인터넷 전송 비용 미발생 |
| ENI 사용 보안성 | ENI를 사용하는 것은 SG를 쓸 수 있음 - 포트만 열어서 통신할 수 있어 보안 강화 |
| NAT GW 고가용성 | AZ별로 NAT GW 생성해서 이중화 생성 - NAT GW는 이중화 생성해도 무조건 비용이 나가는 것이 아니라 쓴 만큼만 비용 지불 |
| VPC 피어링 | VPC끼리 서로 연결 - 서로 다른 IP 대역이라야 가능 - 한 쪽 라우팅 테이블에 설정, 다른 쪽에서도 라우팅 테이블에 설정  - 피어링 생성 후 요청 설정을 해야 통신 가능 |
| AWS Transit GW | 허브 역할을 하는 트랜짓게이트웨이 - VPC 5,000개를 붙일 수 있음 - VPC 피어링으로 복잡할 경우 사용 |
| VPN 연결 | 암호화 처리를 위한 연결 - 생성 후 라우팅 테이블 설정 필요 |
| Direct Connect | VPN과 달리 인터넷을 사용하지 않고 전용선을 직접 연결(제공에는 일주일 정도 소요) |
| NAT 인스턴스와 NAT GW |
NAT인스턴스는 사용자가 직접 만들어서 관리하는 형태 NAT게이트웨이는 관리형으로 사용자의 관리 불필요(용량 대응 자동적 진행) |
| VPC엔드포인트 | 외부로 트래픽을 보내지 않고 내부망을 통해 S3 등 접근 가능하게 하는 서비스 - S3연결, DynamoDB연결 |
| PrivateLink | 내부망으로 빠른 속도 제공 |
| ENI | 한 인스턴스에 15개 네트워크 카드 네트워크 인터페이스당 최대 50개 EIP주소 |
네트워크 보안
| 계층화된 네트워크 방어 체제 |  |
| 보안 그룹 | 네트워크 인터페이스 수준에서 인바운드/아웃바운 트래픽 허용에 사용 상태 저장의 특성 : Stateful (인바운드에서 설정된 것을 기억하고 아웃바운드 허용) |
| NACL | 서브넷용 방화벽 : 서브넷 수준에서 2차 보안 계층으로 보안 강화 상태 비저장의 특성 : 트래픽이 한 방향으로 흐르도록 허용하는 경우에도 응답이 반대방향으로 흐를도록 명시적으로 허용해야 함 |
| 배스천 호스트 | 퍼블릭에 배스천 호스트를 만들어 놓고 내부의 프라이빗 인스턴스에 접근 요즘은 System Managers를 사용  |
| 네트워크 문제 해결 | 서브넷 내 인스턴스가 서로 통신하지 못하는 경우 - 네트워크ACL확인, VPC Flow logs 기능 확인, 인스턴스 문제가 아닌 지 확인  NAT 구성이 미작동 |
| VPC 실습) | VPC 생성 : Name CIDR, Action에서 Edit DNS hostnames 활성화 퍼블릭서브넷 생성 : VPC선택, Name, AZ선택, CIDR(/24로설정), public일 경우 auto ip 할당 활성화 프라이빗서브넷 생성 : VPC선택, Name, AZ선택, CIDR(/23으로설정), IGW 생성 : attch VPC 수행 필요 라우팅 테이블 구성 - public route table : subnet associate 시 0.0.0.0/0을 IGW - private route table : subnet associate 시 0.0.0.0/0을 NAT 퍼블릿 서브넷에서 Bastion서버 시작 NAT 게이트웨이 생성 : Name, public subnet설정, Allocate Elastic IP로 할당 |
| 도전 과제 |  도전 과제 
|
스토리지
| 유형 | EBS, 인스턴스 스토어, EFS, S3, SG Glacier, Snowball |
| AWS로 전송 | AWS Transfer Family : FTP서비스 AWS DataSync : 동기화 |
| 데이터 스토리지 시나리오 | 데이터 저장, 검색 및 관리 일시적인 EC2인스턴스로부터 로그 파일 저장 EC2인스턴스와 연결된 볼륨에 대한 백업 재해 복구용 온프레임스 데이터 백업 |
| EBS | 네트워크 연결 : 인스턴스간에 전용 네트워크 구성도 가능 블록 스토리지, 영구 부팅 및 데이터 볼륨이 지원됨 |
| EBS 볼륨 유형 | SSD 타입 - io1 프로비저닝된 IOPS - gp2 : 범용 SSD 하드 타입 - 처리량 최적화 볼륨 : st1 ==> 빅데이터 - 콜드HDD : sc1 |
| EBS 볼륨 생성 명령어 | aws ec2 create-volume --size 80 ... aws ec2 attach-volume --volume-id .... |
| EBS 증분 스냅샷 | 증분 백업 수행함 : FULL 백업이 아닌 증가된 것만 백업, 속도도 빠름 스냅샷은 S3에 저장 aws ec2 create-snapshot --volume-id ㅇㅇㅇ --description "ㅇㅇㅇ" 
|
| 스냅샷의 복원 | S3에 저장된 내용 복원 aws ec2 create-volume --size --availability-zone --volume type ... |
| 인스턴스 스토어(무료) | 임시 스토리지 : 휘발성 고속 제공 사용 : 버퍼, 캐시, 스크래치 데이터 저장 시 사용 |
| EFS | 공유 파일 스토리지 : 가용 영역이 다른 EC2간의 스토리지 공유 - EC2에서 마운트를 통해서 사용 - 윈도즈는 FSX를 이용해서 사용 가능 페타바이트 규모의 파일 시스템 탄력적 용량 NFS 4.0, 4.1 프로토콜 지원 모든 EC2용 리눅스 기반 AMI와 호환 EFS 는 사용량 만큼 과금 : 자동으로 용량 증대 |
| S3 | 오브젝트 = 파일 _+ 메타데이터 버킷(루트폴더) 단위로 배포 API를 통해서 요청 내구성 설계 객체당 최대 5TB 어디서든 액세스 저장 무제한 자동으로 용량 증가 |
| S3 액세스 설정 | 퍼미션 설정 가능 ACL : 간단한 경우에 적용 BUCKET POLICY로 JSON으로 설정 가능 : 복잡한 경우에 적용 |
| S3에 대한 이벤트 알림 | 호스팅 기능 활성화 가능 SQS 대기열, SNS주제(이메일 등), 람다 함수 ==> 서버리스 서비스(자동 증감) - 추가됨, 삭제됨, 덮어씀 |
| 서버리스 | 서버를 별도로 관리하지 않아도 되는 구조 |
| S3 객체 작업 | aws s3 cp/sync/rm - 복사, 동기화, 객체제거 등 작업 |
| aws s3api | create-multipart-upload put-object-acl put-bucket-policy list-objec-versions |
| S3버전관리 | Object 관리 어려움 해소 이름이 같아도 예전이름을 관리 : 복구해서 사용 가능, 지워도 지우는 마크만 함 예전 버전 관리를 하면 비용은 지불해야 함 |
| 객체 스토리지 클래스 | 범용 : S3 standard - 한번 올리고 다수가 받아가는 경우에 사용 : hot한 데이터임 S3 Intelligent-Tiering - hot 한 데이터가 아닌 경우에 standard데이터를 옮겨서 사용(20% 저렴) Infreq Access - S3 Standard-IA - S3 One Zone-IA --> 40%저럼(복제본 관리 방식 다름) 아카이브 : S3 Glacier는 80% 저렴 저장기간이 긴 경우에는 다운로드시는 standard보다 더 비쌈 - 결국 다운로드 빈도가 적은 경우에 사용 |
| Intelligent Tiering | 2가지 계층간에 저장을 AI가 진행 |
| S3 Glacier | 매우 저렴한 데이터 고객 온프레미스 및 장기 백업 가져와야 할 경우에는 비용이 발생 - 신속 : 1~5분, 전송비용이 가장 비쌈 - 표준 : 3~5시간 - 대량 : 5~12시간 |
| Storage G/W | 온프레미스에서 S3를 로컬 스토리지 처럼 사용할 수 있도록 서비스 제공 온프레미스에 파일 게이트웨이 설치 및 설정 후 S3와 연결 가능 파일 게이트웨이 : 파일 NFS 볼륨 게이트웨이 : 블록스토리지 볼륨 iSCSI 테이브 게이트웨이 : 가상테이브, 장기 백업용(S3의 VTL-iSCSI--> 장기 보관시 Glacier로) 스토리지 게이트 웨이는 온프레미스에서 S3를 로컬 스토리지 처럼 사용하기 위해 만든 서비스입니다. 파일 게이트웨이 - 클라우드에 원활하게 연결하여 애플리케이션 데이터 파일과 백업 이미지를 Amazon S3 클라우드 스토리지에 내구성 높은 객체로 저장할 수 있게 해줍니다. 테이프 게이트웨이 - 백업 워크플로를 변경하지 않아도 온프레미스에서 물리적 테이프를 AWS에서 가상 테이프로 대체할 수 있습니다. 볼륨 게이트웨이 - 온프레미스 애플리케이션에 클라우드에서 지원하는 블록 스토리지 볼륨을 제공합니다. |
| Transfer Family | SFTP엔드포인트를 사용해서 S3로 데이터 저장 |
| DataSync | 동기화, 압축, 완전관리형, 성능 우수  |
| Snowball | 대규모 고객 데이터셋을 신청해서 옮기는 방식 - 장비를 고객에게 보내서 데이터를 로드하는 방식 |
| Snow Mobile | 트럭단위의 데이터를 받아서 데이터를 로드하는 방식 |
| 실습 | 과제 1: 리소스 생성 및 구성 과제 2: 인스턴스의 스냅샷 생성 과제 3: 도전 과제: Amazon S3와 파일 동기화 |
| ㅇ 롤 부여 - EC2 인스턴스에게 S3Access 롤을 부여(키발급 없이도 S3에 접근) ㅇ 인스턴스 정보 보기 aws ec2 describe-instances --filter 'Name=tag:Name,Values=Processor' ㅇ 인스턴스 정보 필요한 내용만 보기 - 어떤 EBS와 연결되어 있는지 볼 수 있는 명령어 aws ec2 describe-instances --filter 'Name=tag:Name,Values=Processor' --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.{VolumeId:VolumeId}' ㅇ 인스턴스 중지 후 아래는 인스턴스ID 확인하는 명령어 aws ec2 describe-instances --filters 'Name=tag:Name,Values=Processor' --query 'Reservations[0].Instances[0].InstanceId' 이 후 인스턴스 중지하는 명령어 aws ec2 stop-instances --instance-ids ㅇㅇㅇ aws ec2 wait instance-stopped --instance -id ㅇㅇㅇ ㅇ 스냅샷 생성 aws ec2 create-snapshot --volume-id VOLUME-ID aws ec2 wait snapshot-completed --snapshot-id ㅇㅇㅇ  ㅇ 인스턴스 시작 aws ec2 start-instances --instance-id ㅇㅇㅇ aws ec2 wait instance-running --instance-id ㅇㅇㅇ ㅇ 크론탭 작성 echo "* * * * * aws ec2 create-snapshot --volume-id VOLUME-ID 2>&1 >> /tmp/cronlog" > cronjob - 매분마다 실행( 분 시간 일 월 요일), 스냅샷 생성, '2>&1' 은 에러 저장의 의미 crontab -l 로 크론탭 생성 확인 ㅇ 크론탭에 등록 crontab cronjob 으로 스냅샷 시 : 2개 이상  스냅샷 확인  ㅇ 삭제 후 스냅샷이 2개만 남은 상황 확인 가능 |
|
| 도전 과제 : S3와 파일 동기화 |
ㅇ 버킷 리스트 보기 aws s3 ls ㅇ 버킷에 대한 버저닝 수행 : 동일 이름에 의해 삭제되는 것을 방지 aws s3api put-bucket-versioning --bucket sample-bucket-1234 --versioning-configuration Status=Enable  - 버저닝 이후에는 기록 관리가 됨, 지우는 것도 지우는 표시만 하게 됨 aws s3 sync . s3://sample-test-1234 -- delete ㅇ 지워진 표시 리스트 확인 aws s3api list-objec-versions --bucket sample-test-1234 ㅇ s3로 업로드 aws s3 cp sample.py s3://sample-test-1234 aws s3 cp sample.py s3://sample-test-1234 - 한 번 더 업로드하면 2개 버전을 관리해 줌 ㅇ 파일 받기 aws s3api get-object --bucket sample-test-1234 --key /files/sample1.txt /files/sampl2.txt --version-id ㅇㅇㅇㅇㅇ ㅇ Objects 확인 기본적으로 Storage class 는 Standard로 올라감  - 스토리지 클래스 변경 가능  ㅇ Glacier로 변경된 수 가져오기 할 때의 첫 번째 작업은 "Initiate restore" 먼저 수행 후  ㅇ S3에서 받아간 이력 로그 확인 기능  ㅇ S3에 이벤트 발생시 람다로 전달 가능  ㅇ 대용량 시에 사용하는 옵션으로 엣지 로케이션으로 올려서 효율적으로 해당AZ 업로드  ㅇ 정적 웹사이트 호스팅 기능  |
| JMESPATH |
 |
| Basic expression | a.b.c.d |
| 리스트 | a.b.c[0].d[1][0] [0:5] // 5개 가져오기 |
| 복수값 가져오기 | 모든 firts 값을 가져 오는 방법의 예시 |
| 조건문 | state가 running 인 것 중에서 name을 가져오기  |
| 파이프라인 | first 중에서 0번째 것을 가져오기 즉 James가 됨 |
모니터링
| 개요 | CloudWatch(모니터링, 이벤트, 로깅) CloudTrail : 사용자가 어떤 일을 하는지 추적 Config : 상태를 저장하고, 어긋나면 알림을 제공함 GuardDuty : 보안 |
| CloudWatch | 로그수집 모니터링 이벤트에 응답 분석  |
| CloudWatch 모니터링 | 리소스 상태 및 사용률을 모니터링 Agent : EC인스턴스, 온프레미스 서버 지표 수집 이메일 통보 가능 |
| 지표 | 표준지표와 사용자 지표 |
| CloudWatch Dashboards | 위젯들을 추가해서 한 화면에서 사용 가능 |
| 모니터링 기준 | EC2 인스턴스 5분 단위 데이터를 보고(프리티어) 1분 단위 모니터링 시 추가 비용 |
| CloudWatch Metrics - 모든 데이터 확인 가능 |
  |
| CloudWatch Alarms | 알람 임계치 설정 SNS토픽으로 보내기 : 이메일로 보내기 등 가능 |
| CloudWatch Logs | 별도의 아파치서버로그 수집을 위해서는 CloudWatch Agent를 설치해서 가능 flow log : ENI 로그 필터를 걸어서 수집 가능 - https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html - 소스포트, 소스주소, ENI 등 확인 가능 |
| CloudWatch Logs Insight | 로그에 대한 쿼리 가능  |
| CloudWatch Events | 룰 생성 ㅇ 이벤트 패턴으로 설정 가능 : 통보 기능도 설정 가능  |
| AWS CloudTrail | 계정 활동의 모든 내용 기록 - 인스턴스 종료, 보안그룹 구성 변경 - 로그 제공 가능  |
| AWS Config | ㅇ 상태 관리자 - EC2인스턴스 내부의 바뀌면 안되는 셋팅에 대한 관리 필요 - 상태 관리자가 모니터링하고 있다가 변경이 되면 알려 주 ㅁ ㅇ Config - 서비스의 상태를 관리 - 예시) bucket을 만들 때, public하게 못 만들게 설정 가능 - public으로 bucket을 만들 때 경고 메일을 보내게 할 수 있음 . 현재 시스템 상태 및 서비스 모니터링 . 리소스 인벤토리 검색, ㅇ Config 규칙 예 EBS볼륨 암호화, 승인된AMI사용, Elastic IP가 인스턴스에 연결됨 적절한 태그가 EC2에 지정 ㅇ Config 및 CloudTrail CloudTrail에 모든 Config 변경 사항 기록  ㅇ S3 퍼블릭에 노출 여부 관리  ㅇ EBS 암호화 여부 관리  |
| 보안 서비스 |  WAF : XSS 막기 등(OWASP Top10 막기)  |
| 실습 | 과제 1: CloudWatch 에이전트 설치 과제 2: CloudWatch Logs를 사용하여 애플리케이션 로그 모니터링 과제 3: CloudWatch를 사용하여 인스턴스 지표 모니터링 과제 4: 실시간 알림 생성 과제 5: 인프라 규정 준수 모니터링 |
| 에이전트 설치 | 과제 1: CloudWatch 에이전트 설치 1) 파라미터 스토어의 Value에 감시할 항목 등록 - CloudWagtch Agent가 시작할 때 참조될 파라미터 Value { "logs": { "logs_collected": { "files": { "collect_list": [ { "log_group_name": "HttpAccessLog", "file_path": "/var/log/httpd/access_log", "log_stream_name": "{instance_id}", "timestamp_format": "%b %d %H:%M:%S" }, { "log_group_name": "HttpErrorLog", "file_path": "/var/log/httpd/error_log", "log_stream_name": "{instance_id}", "timestamp_format": "%b %d %H:%M:%S" } ] } } }, "metrics": { "metrics_collected": { "cpu": { "measurement": [ "cpu_usage_idle", "cpu_usage_iowait", "cpu_usage_user", "cpu_usage_system" ], "metrics_collection_interval": 10, "totalcpu": false }, "disk": { "measurement": [ "used_percent", "inodes_free" ], "metrics_collection_interval": 10, "resources": [ "*" ] }, "diskio": { "measurement": [ "io_time" ], "metrics_collection_interval": 10, "resources": [ "*" ] }, "mem": { "measurement": [ "mem_used_percent" ], "metrics_collection_interval": 10 }, "swap": { "measurement": [ "swap_used_percent" ], "metrics_collection_interval": 10 } } } }  참고 : CloudWatch 구성 파일 문법 2) CloudWatch 실행 
 |
| 로그 모니터링 | 과제 2: CloudWatch Logs를 사용하여 애플리케이션 로그 모니터링 - 각 개별서버에 로그인 하지 않고도 로그 데이터에 액세스 가능  1) Log groups  2) alarm 
 3) 알람 발생 시 noti. : 토픽을 만들어서 이메일로 통보 가능 
|
| 지표 모니터링 | 과제 3: CloudWatch를 사용하여 인스턴스 지표 모니터링 1) Monitoring 탭 
 |
| 알림 | 과제 4: 실시간 알림 생성 1) create rules  2) event와 topic 설정  3) 토픽  |
| 컴플라이언스 | 과제 5: 인프라 규정 준수 모니터링 1) Settings  2) Set up AWS Config  rule type : AWS Managed Rules  3) 점검 : Compliant/ Noncompliant  |
리소스 사용 관리
| 개요 | 태그 지정 클라우드에서 비용 절감 기회 비용 모니터링 및 결제 경보 AWS Trusted Advisor |
| 태그 | 환경, 애플리케이션, 소유자 , 부서, 비용센터, 목적, 스택 |
| 태그 지정 | required-tags를 통해서 관리형 규칙 지정 가능(AWS Config에서 지정) |
| 태그 생성 | aws ec2 create-tags ... |
| 비용 관리 전략 | 태그를 이용하여 인스턴스를 동시에 시작과 종료 - 테스트 서버 태그를 주말에 동시에 off 하고 월요일에 동시에 ON해서 비용 절감 - 클라우드의 비용적 이점 활용 필요 |
| 비용 관리 도구 | 전반적 사용량 비용 감시 월별 청구서에 액세스 도구 : Cost Explorer |
| 비용 절감을 고려한 설계 | 인스턴스의 적정크리 RI : 장기 실행 인스턴스 그룹에 적용(1~3년까지 계약 가능) 배치 : 병렬 실행, 작업 완료 시 종료, 스팟 인스턴스 활용, AWS Lambda 고려 - 람다는 코드만 올려 두고 사용할 때만 비용 지불 가능 버스트 워크로드 : T2인스턴스 (burst 기능 활용 가능) 비용 최적화 지침 제공 : AWS Trusted Advisor의 도움 받기 |
| Cost Explorer | 1) 일단위 비용 제공, 예상치도 제공 2) 서비스별 비용도 확인 가능 : EC2, VPC, ... 3) 리전별 비용 확인 4) 다양한 필터 : 인스턴스 타입, Cost Category 태그 활용 필요 |
| AWS Budget | 버짓을 정해 놓고 알람 통보 처리 가능 |
| CloudWatch Billing | 빌링 알람 생성 가능 - 버지니아 리전에서 알람을 생성해야 볼 수 있음  |
| 서버리스 Stopinator | 태그를 통해서 ec2인스턴스를 정지와 시작을 자동화 |
| 결제 대시보드 | Cost Explorer 에서 확인 |
| AWS Trusted Advisor | 비용최적화 성능 보안 내결함성 서비스한도 에 대한 알람 가시화 |
| 실습 | 과제 1: 태그를 사용하여 리소스 관리 과제 2: 태그 기준으로 인스턴스 중지 및 시작 과제 3: 도전 과제: 규정 미준수 인스턴스 종료  |
| development 인스턴스 관리 | 과제 1: 태그를 사용하여 리소스 관리 development 인스턴스 관리 1) 찾기 명령어 : aws ec2 describe-instances --filter "Name=tag:Project,Values=ERPSystem" --query 옵션 사용 aws ec2 describe-instances --filter "Name=tag:Project,Values=ERPSystem" --query 'Reservations[*].Instances[*].InstanceId' 2) 출력에 다수 필드 포함 aws ec2 describe-instances --filter "Name=tag:Project,Values=ERPSystem" --query 'Reservations[*].Instances[*].{ID:InstanceId,AZ:Placement.AvailabilityZone}' - 인스턴스와 가용영역 정보 동시 표시  3) 프로젝트의 태그 포함하여 출력 aws ec2 describe-instances --filter "Name=tag:Project,Values=ERPSystem" --query 'Reservations[*].Instances[*].{ID:InstanceId,AZ:Placement.AvailabilityZone,Project:Tags[?Key==`Project`] | [0].Value}' 
 5) Project 중에 development 환경에 있는 건만 표시 
 |
| 과제 2: 태그 기준으로 인스턴스 중지 및 시작 php용 AWS SDK를 사용하여 인스턴스를 중지하고 다시 시작 가능 - stopinator.php스크립트를 이용해서 development 환경 서버를 종료하고 다음날 아침 시작 중지명령 예시) ./stopinator.php -t"Project=ERPSystem;Environment=development"  시작명령 예시) ./stopinator.php -t"Project=ERPSystem;Environment=development" -s  |
|
| 과제 3: 도전 과제: 규정 미준수 인스턴스 종료 |
배포 자동화
| 개요 | 클라우드에서의 구성 관리 AMI 생성 및 전략 구축 구성 소프트웨어 사용 AWS CloudFormation |
| 구성관리 필요성 | 새로운 리소스를 신속하게 시작 : 재해복구 등 히스토리 관리 자동화 및 반복 가능한 구성을 새엉 |
| 인스턴스 구성 기술 | userdata AMI OpsWorks CloudFormation |
| AMI | 기본 구성으로서의 사용자 정의 AM - AMI의 인스턴스 사용자 데이터 사용 |
| AMI를 다른 리전에 복사 | aws ec2 copy-image --source-image-id ... |
| 구성 서버 사용 | 인스턴스에 사용자 데이터를 제공하여 구성 - chef |
| CloudFormation 장점 | 코드로 인프라 관리 : IaC(Infrastructure as Code0 지리적 위치 전반에 롤아웃 롤백 관리 편리 배포 디버기 종속성 관리 : 시스템 및 하위 서비스에 대한 종속성 모든 변경 사항을 문서화 반복 가능 및 동일한 환경을 배포 |
| 자동화 배포 기술 | 사용자 스크립트 CloudFormation : 인프라 구성에 활용 편리 OpsWorks : 내부 SW설치에 활용 편리 |
| CloudFormation | 선언형 프로그래밍 언어 리소스 집합을 단일 스택으로 지정 가능 |
| CloudFormation 구성 요소 | 템플릿 : 생성할 리소스의 기본 정의 스택 : 리소스들의 집합 |
| CloudFormation template 구조 |  Parameters:   생성과정 
 
 |
| CloudFormation 작성 quick start |
템플릿 활용해서 구성 가능 https://aws.amazon.com/ko/quickstart/?solutions-all.sort-by=item.additionalFields.sortDate&solutions-all.sort-order=desc |
| 템플릿 편집 툴 | vscode 등 |
| AWS CloudFormation Designer 툴 | aws 툴 : drag & drop 툴 - 코드가 자동으로 생성    |
| 스택 시작 및 삭제 | 종속성 중요 - S3의 버킷명의 유일성 준수 : 미준수시 롤백 - VPC를 만들고 서브넷 생성 |
| parameter: 문법 | 유형 제한, 기본값, 최소/최대 길이 정규 표현식 제약 조건 지원 파라미터 참조 : "Ref" 가상 파라미터 : "AWS::Region" |
| 매핑 문법 | Fn::FindInMap : 찾기 내장함수 |
| Resources:문접 | 종속성 : "DependsOn" |
| CloudFormation::Init | 사용자 데이터 반영 방법의 대안으로 적용 가능 - 실행 시 자동 롤백 |
| Outputs:문법 | 최종 동작 후 결과 리턴 스택의 리소스에 대한 선택적 정보 제공 |
| 스택 시작 추가 옵션 | 롤백 방지 : DO NOTHING 스택 정책을 설정하여 스택 업데이트 제어 파라미터 전달 |
| CloudFormation모범사례 | 소유권 기준 템플릿 재사용(Quick Start 활용) 모든 리소스 유형의 제한을 확인 : EC2인스턴스 20개 제한 등 템플릿 생성 - 자격증명을 내장하지 않음 - 고유 파라미터 유형 이용 - 파라미터 제약 조건 사용 - 배포하기 전에 템플릿 확인 : dry-run 옵션으로 확인 스택관리 - 모든 스택 리소스를 관리 - 변경 사항 집합을 만들어 관리(업데이트 전에) - 스택 정책 사용 |
| CloudFormation문제해결 |   https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/troubleshooting.html |
| 실습) | 과제 1: CloudFormation 스택 배포 과제 2: 스택에 Amazon S3 버킷 추가 과제 3: 스택에 Amazon EC2 인스턴스 추가 |
| 스택 배포 | 과제 1: CloudFormation 스택 배포 1) template 파일 이용 스택 생성  2) 생성 후 진행 과정  |
| S3 버킷 추가 | 과제 2: 스택에 Amazon S3 버킷 추가 1) update를 통해서 버킷 추가 시작  2) 업데이트 과정 진행  3) 생성 확인  |
| EC2추가 | 과제 3: 스택에 Amazon EC2 인스턴스 추가 1) EC2 배포를 위해 스택의 리전에 해당하는 최신 AMI 지정 - 다른 리전에 배포하기 위해 필요 설정임 Parameter: 섹션에 추가  2) 인스턴스 속성 편집  InstanceType : 
 4) 진행 사항 확인  ec2 생성 확인  |
| 스택 삭제 | delete |
CloudFormation용 yaml 파일(샘플)
AWSTemplateFormatVersion: 2010-09-09
Description: Lab template
# Lab VPC with public subnet and Internet Gateway
Parameters:
LabVpcCidr:
Type: String
AllowedPattern: '^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|[1-2][0-9]|3[0-2]))$'
Default: 10.0.0.0/20
PublicSubnetCidr:
Type: String
AllowedPattern: '^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|[1-2][0-9]|3[0-2]))$'
Default: 10.0.0.0/24
AmazonLinuxAMIID:
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
Default: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2
Resources:
Bucket:
Type: AWS::S3::Bucket
Instance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
ImageId: !Ref AmazonLinuxAMIID
SubnetId: !Ref PublicSubnet
SecurityGroupIds:
- !Ref AppSecurityGroup
IamInstanceProfile: !Ref InstanceProfile
Tags:
- Key: Name
Value: App Server
###########
# VPC with Internet Gateway
###########
LabVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: !Ref LabVpcCidr
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: Lab VPC
IGW:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: Lab IGW
VPCtoIGWConnection:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
InternetGatewayId: !Ref IGW
VpcId: !Ref LabVPC
###########
# Public Route Table
###########
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref LabVPC
Tags:
- Key: Name
Value: Public Route Table
PublicRoute:
Type: AWS::EC2::Route
Properties:
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref IGW
RouteTableId: !Ref PublicRouteTable
###########
# Public Subnet
###########
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref LabVPC
MapPublicIpOnLaunch: true
CidrBlock: !Ref PublicSubnetCidr
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
Tags:
- Key: Name
Value: Public Subnet
PublicRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref PublicRouteTable
SubnetId: !Ref PublicSubnet
###########
# IAM Role for Instance
###########
InstanceProfile:
Type: AWS::IAM::InstanceProfile
Properties:
Path: /
Roles: [!Ref AppRole]
InstanceProfileName: App-Role
AppRole:
Type: AWS::IAM::Role
Properties:
RoleName: App-Role
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- ec2.amazonaws.com
Action:
- sts:AssumeRole
Path: /
###########
# App Security Group
###########
AppSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: App
GroupDescription: Enable access to App
VpcId: !Ref LabVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
Tags:
- Key: Name
Value: App
###########
# Outputs
###########
Outputs:
LabVPCDefaultSecurityGroup:
Value: !Sub ${LabVPC.DefaultSecurityGroup}
'ITPE metacog > Cloud metacog' 카테고리의 다른 글
| [AWS SAP] 비용효과적인 ECS 애플리케이션 클러스터와 RDS 사용 (0) | 2021.04.19 |
|---|---|
| [AWS SAP] KMS 암호화 AMI의 CloudFormation 배포 (0) | 2021.04.19 |
| [AWS SAP] HPC 클러스터 최대 성능 달성 (0) | 2021.04.13 |
| [AWS SAP] S3에 동시 업로드 실패 대응과 비용 관리 (0) | 2021.04.13 |
| AWS 기초(Technical Essentials) (0) | 2021.04.12 |