기본 개념

DNS(Domain Name System) : clients 가 도메인이름 입력하면 그걸로 서버에 갈 수 있게 도와주는 것. A : Host name to IPv4 AAAA : Host name to IPv6 CNAME : hostname to hostname Alias : hostname to AWS resrouce

뭔가 카페 24에서 본듯한 것 같다. 아님 깃헙에서..
인터넷에서 찾아서 할 때 그냥 하란대로 A 레코드에 입력했던 것 같은데, 이게 호스트 이름을 IPv4로 연결해주는 거라서 그렇구나

실습

EC2 에 apache 깔고, IP뜨게한다. 다른 Region들에 Instance를 여러개 만들고 LB에 연결한다. 도메인 이름과 IPv4의 연결 테스트. 1. DNA records TTL(Time To Live) 300s(5mins) : 캐싱이 5분정도 되기 때문에 바뀐게 있어도 즉시 반영을 못한다. (실습에서 ipv4를 변경했는데도 페이지에 즉시 반영이 안됐다.)

    High TTL : less traffic on DNA
             : Record가 outdated...

    Low TTL : more traffic on DNA
            : new record

CNAME vs Alias

CNAME : hostname 에서 hostname으로 연결해준다. 단 root domain 안된다.

Alias : hostname 에서 AWS resrouce 연결해준다. : root domain/ non root domain 둘 다 가능하다. : 무료, Health check 해준다.

Route53의 Weighted Routing Policy

domain name 을 ip로 연결 시켜줄 때, 특정 ip에 더 자주/들 연결시킬 수 있게 해준다. yejip.com 과 연결된 ip가 대충 a,b,c라고 할때 내가 a는 0.7, b는 0.2, c 는 0.1 이렇게 세팅해 놓는다면 yejip.com 10번 쳤을 때 a는 7번 , b는 2번 , c는 1번 연결된다.

Latency Routing

제일 짧은 latency 에 계속 연결하게 해준다.

Health check

instance 가 건강하지 않으면 연결 안한다.

failover

primary IP가 health check 에 fail 하면, secondary IP 에 연결한다.

Geolocation Routing Policy

user의 location 에 따라 연결되는 서버가 달라진다. default policy 필요하다. 특정 나라, 특정 서버에 연결할 수 있도록 지정이 가능하다.

RDS(Relational Database Service)

RDS overview

: managed DB service (Query lang 으로 SQL 사용)

AWS 에서 DB 만들게 해준다. (postgres, MySQL, MariaDB, Oracle, Microsoft SQL server, Aurora)

RDS 의 장단점

(장): 관리되니까 편하다. (자동 provisioning, OS patching, 백업, 타임스탬프, Dashboards, Multi AZ setup, 윈도우 유지, Scaling(vertical&horizontal), storage는 EBS에 의해 back up 됨.) (단): SSH 는 못한다.

RDS backup

: 자동임. 매일 full, 5분마다 transaction log 가 backup 된다. 7일 기록이 보유되고, 최대 35일 까지 보유 가능하다.

DB Snapshot은 유저가 만들 수 있고, 이것은 내가 원하는 만큼 동안 보유 가능하다.

RDS read replica

:RDS DB 인스턴스 하나에 읽고 쓰기 한다. 그 DB인스턴스를 비동기 복제를 한다. 복제된 인스턴스는 읽기만 가능. 예를들어, 우리팀이 일하고 있는 DB가 있다. 다른 팀도 그 DB를 이용해서 뭘 하고 싶어한다. 만약 우리 DB에 직접 연결하게 하면, Instance가 overload될 수도 있다. 따라서 RDS DB를 복제한다. 비동기 복제를 하고, 복제된 DB에서 그 팀이 READ할 수 있게 해준다. insert, delete, update는 쓰기 권한이니까 당연히 못한다.

RDS read replica network cost

: 내 data가 다른 AZ로 복제된다면 Network cost 지불해야한다. 같은 AZ면 공짜. (둘다 비동기, 아마 위의 예시같이 다른 팀 사용할 때..)

RDS Multi AZ (재난 대비인 경우)

:동기 방식으로 ! Availability 상승,하나의 DNS (Automatic failover) , scaling 은 아니다.

Hands on:

DB freetier - mySQL, Postgres SQL AWS에 RDS 만들고, sqlelectron (DB client 프로그램)에서 접근 가능하다. DB 클라이언트 프로그램을 다운받아서 server info 에 DB 타입, Server address, end point 입력, port , user PW 넣으면 접근 가능하다.

Instance action 에서 read replica, take snapshot 가능하다.

RDS security

:Encryption (At rest, In-flight) master가 encrypted 안돼있으면 read replicas 도 안된다.

1. At rest encryption

처음 만들어질 때만 실행 가능.
AWS KMS - AES - 256 encryption으로 encrypt.
launch time 에 encrpytion 이 정의돼야 한다.
Oracle과 SQL server 에는 Trnasparent data encryption 가능.

2. In flight encryption

SSL certificates.

RDS encryption operations

unencrypt 된거 snapshot 하면 그것도 unencrypt. 근데 우리는 encrpyt 된거 원한다. 이때, Snapshot 만들어 이걸 복제하면서 encrpyt 가능하게 한다. (왜 복제해서 해야되지..?) encrpyt된 snapshot 에서 DB를 복구한다.

Network & IAM

network sec : DB는 보통 private subnet 에서 deploy 된다. ec2 처럼 security group 이용한다. Access management IAM policy (manage AWS RDS) 전통 USER NAME/PW DB에 로긴 가능. RDS MYSQL & postgres SQL 에 IAM Based auth 로긴 가능.

RDS 커넥트 w/ IAM authentication

pw 필요 없다. (15분 유효기간 있는 AUTH token 사용한다.) RDS Service서 auth token 얻고, SSL encrpyt pass auth toekn 사용해 my sql 연결(..?)

Amazon Aurora

1. 오픈 소스 아니다.
2. postgres/mysql 과 호환된다.

my sql의 5배의 효율을 자랑, postgres의 3배의 효율
storage가 10GB ~ 64TB 까지 많아진다. (점진적)
15 replicas 까지 가능
failover은 즉시, high Availability
RDS보다 20 퍼 비싸지만 효율적이다.

AURORA High Availability & READ Scaling

3 AZ에 걸쳐 6개의 카피 데이터. (4/6 : for write, 3/6 : for read) –>? self healing! 30초 내 failover shared storage volume에 master instance가 Write 한다. (read도 당연 가능) 그럼 그 shared volume에서 다른 instance가 read한다. replica 는 1~15개

Aurora security

RDS와 같은 엔진을 이용하기 때문에 security가 비슷하다. (IAM token) KMS , at resting SSL , in flight Automated back up, replica , snapshot 은 모두 보안 ㅇㅇ SSH 못한다.

Aurora serverless

실제 사용량에 따른 auto scaling을 한다. 간헐적으로 들어오고 예측 불가능한 workload에 사용하기 좋다. capacity planning 안해도 된다. (cost efficient) proxy fleet

Global Aurora

1. aurora cross region read replicas : Disaster Recovery 에 좋다.
2. aurora global DB
  하나의 주요 region (R/W)
  read only (5개) 다섯개의 secondary region..
  16개의 read replicas (region 당 16개의 read replicas)
  latency가 감소하게 도와준다.

AWS Elastic Cache

in-memory DB, low latency RDS랑 비슷, RDS for Cache write/read scaling & multi AZ

1. APPLICATION Amazon Amazon (1) Elastic (2) RDS Cache

클라이언트가 요청을 하면, (1) Cache를 찾는다.
만약 Cache가 있다면, chache hit 이라고 하고, 없으면 cache miss 라고 한다.
cachehit이면 그냥 그 정보 반환하면 되고, cache miss면 2의 경로로 가서 정보 가지고 오면 된다. 그리고 RDS 에 쓴다.캐시에도 저장하고..

1. Elastic cache - Redis vs Memcached

Redis multi AZ - auto failover Read replicas & HA AOF persistenc=t 덕에 data durability backup 과 restore feature.

Memcached multi-node for partitioning of data Non persistent no locked up/restore multi-threaded architecture

Caching implement considerations

safe? effective? design pattern?

1. Lazy loading / cached aside/ lazy population

캐쉬를 먼저 찾아보고 없으면 rds에서 가져온다.
장점 : 요청된 자료만 캐쉬된다. node failures이 그렇게 치명적이지 않다.
단점 : cache miss 일 경우 세번 신호 보내야한다. outdate된 cache 가지고 있을 수 있다.

2. Write through

app에서 write 하면 RDS와 cache에 write 한다.
장점 : data가 신선하다. write 하는 건 2번 call 한다. (lazy loading 은 cache miss 때 3번 read해야됐다.)
단점 : DB 에 write 하기 전까지 데이터 없다. 그래서 1, 2 같이 사용

3. cache eviction & Time to live (TTL)

유통기한 지난 애 지우기
메모리 꽉차면, LRU (Least Recently Used) 최근에 사용 안된거 지우기
time to live 설정하기.

EC2 에서 데이터 저장해 놓고, 갑자기 종료되면 데이터도 다 날라간다. 이를 방지하기 위해서 ebs에 따로 저장한다. (Network drive임)

EBS (Elastic Block Store)

: AZ에 한정되어 있다.

Provision capacity 로 돈을 낸다.

Volume type - size, throughtput, IOPS(I/O operations per sec) 에 맞춰 고른다.)

1. GP2(SSD) : 일반적으로 사용됨.
2. IO1(SSD) : 퍼포먼스가 가장 좋다. (low latency, high throughput)
3. ST1(HDD) : 저렴, intensive workloads에 적합하다.
4. SC1(HDD) : 가장저렴. less frequently accessed workload.

EC2 만들 때 , Add storage 에서 추가 가능하다.

EBS를 EC2 폴더에 mount 하기. lsblk : Attached drive 보여준다. sudo file -s /dev/xvd_ –> data 라고 뜨면, file system 없는거라 만들어야 한다. (아니 기억이 안나 여기 확인 하기) sudo mkfs -t ext4 /dev/xvdb sudo mkdir /data sudo mount /dev/xvdb/data 이 코드 다시 확인해라

GP2

대부분의 workload에 추천.
system boot volume 임.
1 GiB - 16 TiB
low latency(지연 최소화)
small gp2 volumes는 3000 IOPS 까지 burst 가능.
1GB 당 3 IOPS 가능. <= 16,000 iops. (5,334GB에 맥스다.)

IO1

중요한 비지니스 앱(16,000 IOPS per volume 보다 더 사용하는 앱, iops퍼포먼스가 유지되어야하는 앱)에 적합. (성능이 제일 좋아서 그런가부다)
IOPS 맨첨에 제공된다. MIN 100 - MAX 64,000 (Nitro instances) , MAX 32,000 (other instances)
provisioned IOPS : 요청된 Volume size (in GiB) =  50:1
4 GiB - 16 TiB

ST1

저렴한 가격에 일관되고 빠른 throughput 이 필요할 때
시스템 부트 볼륨 불가.
500 GiB - 16 TiB
Max IOPS 는 500

SC1

자주는 사용하지 않지만 큰 볼륨을 위한 Throughput oriented storage.
시스템 부트 볼륨 불가. (GP2, IO1만 부트 볼륨 가능)
500 GiB - 16 TiB
Max IOPS 는 250 (확실히 ST1 보다 느리다.)

EBS 와 Instance Store

Instance store
  물리적으로 장비에 붙어있다.
  장점 : I/O performance가 ebs보다 낫다. (당연..), 리부트해도 데이타 안 지워진다.
  단점 : stop/termination 시 삭제된다. resize 불가하고 backup 본인이 해야한다.

EFS(Elastic File System)

:멀티 AZ 가능. cf) EBS는 한 AZ 안에서만.. :NFSv4.1 프로토콜 사용. (std way to mount) :window 에서는 mount 안됨. Linux 만.. :POSIX file system (linux)

:EFS scale 1000s of concurrent NFS Clients 자동으로 petabyte scale까지 간다.

:Performance mode general purpose : latency sensitive use case (web server) max I/O : higher latency,highly parallel (big data, media processing.)

:storage tiers (move file after N days) std : 자주 접근되는 파일에 Infrequent access (EFS-1A) : 파일 불러올 때 돈냄.

EFS는 NFS 인데, 다른 AZ에서도 EC2 Instance 접근 가능하게 해준다. life cycle에서 며칠동안 접근 안하면 inf access로 바꾸게 하는 옵션 있다.

EBS/EFS 정리

EBS

1. 한번에 하나의 instance 에 붙는다.
2. AZ level 에 국한된다.
3. gp2 : disk 사이즈 증가시 , io 증가한다.
4. io1 l IO를 독립적으로 증가시킬 수 있다
5. EBS 볼륨을 다른 AZ로 옮길 시, Snapshot 가져와서 다른 AZ에 복구시킨다.

EFS

1. 100~1000…개 Instance 가능하다.
2. LINUX에서 돌아간다.
3. Multi AZ!

종이에 글씨 좀 잘쓰자!

Background Knowledge

1. Scalability
vertical   : Instance의 크기를 , 성능을 증가시키는 의미. ex) t2.micro --> t2.large
horizontal : Instace의 수를 증가시키는 것, Distributed system. 요즘 app 에서 흔하게 사용한다.

2. High Availability
: 보통 horizontal scalability와 연관.
: Data center loss 에 살아남기 위해서..

EC2에서는?

Vertical scaling : instance의 크기 증가시킨다. --> RDS와 Elastic Cache 
Horizontal scaling : instance의 수 증가시킨다. --> Autoscaling group, Load balancer.
High availability : multi AZ 에서 같은 app을 가동 시킨다.--> RDS multi AZ는 passive, Horizontal scaling 은 active.

Load Blancing

Internet 트래픽을 여러개의 서버로 보내주는 서버 여러 유저가 EC2 instance로 바로 접근하는게 아니라, 하나의 통로인 ‘load balancer’로 접근한다. load balancer는 여러개의 EC2 instance에 연결되어 있고, user를 instance에 보내준다.

load balancer의 장점 load를 downstream 서버에 분산시켜준다. single point access(DNS)를 제공한다. (각각의 서버가 아니라 load balancer로 가면 됨) failures를 잘 핸들한다.

​ instance health check를 정기적으로 한다. ​ SSL termination 을 제공한다.

ELB 전반적인 내용 아마존 제공 LB

​ 아마존에서 관리하기 때문에 편리하고, 직접 관리하는 것 보다 훨씬 낫다.

​ 내가 직접 load balancer 하는게 더 저렴하지만, 복잡하다.

AWS에 있는 Load Balancer의 타입.

1. Classic Load Balancer (HTTP/S,TCP)
2. Application Load Balancer (HTTP/S, websocket) --> layer7
3. Network Load Balancer (TCP, TLS, UDP) --> layer4
4. Internal/external Load Balancer

load balancer security groups
  : application 의 security group 의 source 가 된다. (참조해서)

LB Errors
  4xx errors : client induced errors.
  5xx errors : application induced errors.
  503 errors : capacity /no registered target
  time out, can't connect to my application : check your security groups.

Health check
  ping protocol : HTTP
       port : 80
       path : /

  건강하다면, 200 (ok) 보낸다.
  이 신호 안오면 안 건강한 걸로 간주되고, load balancer 이 여기로는 traffic 안 보낸다.


Load Balancer과 instance 연결하는 법
  일단 laod balancer 만들고, 그 과정에서 instance 만들었었다.
  거기서, application security group의 Instance source에 0.0.0.0/0 (어디에서나) 에서 load balancer 로 바꾼다.
  그러면 load balancer 거쳐서 instance에 들어온다.  

EC2 Load Balancer

1.CLB(Classic Load Balancer)

fixed host name, layer4/7 , TCP/HTTP 를 기반으로 한 Health check

Anywhere 에서 EC2 instance에 직접 접근할 수 없게하고, EC2 instances 들은 Load balancer에서 오는 트래픽만 받을 수 있게 만든다. (Security group 설정으로) 따라서 load balancer을 통해서만 ec2에 접근 가능하게 된다.

load balancer에 ec2 직접 추가 가능

2. ALB(Application Load Balancer)

layer7, url의 path, hostname, query,string,header 에 기반해 route해준다. micro service 나 container based app 에 적합하다. port mapping feature 있다. ALB는 multiple target group으로 이끌어준다. target group의 타입 EC2 instance, EC2 tasks, Lambda function, IP address(must be private) Health check는 target group level 에서 진행된다. fixed host hostname client 의 IP를 직접적으로 못본다. true IP 는 HTTP에 있는 header X-forwarded port에 있다. porto.. Listener 에서 rule edit, path, host 등등에 따라 target group 지정이 가능하다.

3. NLB(Network Load Balancer)

layer4(TCP , UDP traffic) 초당 백만개의 요청 수행한다. 반응속도 빠름. (100ms, cf. ALB : 400ms) 하나의 static IP NLB security group은 좀 다르게, CLB에서는 LB에서 오는 트래픽, EC2에서 받았다면 NLB에서는 외부 traffic을 Target Group에 전달해주기 때문에 IP가 NLB IP 가 아니라 외부 IP라서 Security group rule 에 80 HTTP 0.0.0.0/0 추가해줘야한다. (아니근데 애초에 HTTP안 받는거아님?? 뭐지)

Load Blanacer Stickiness

같은 client 는 항상 같은 instance로 direct되게 하는 것. 쿠키 통해 가능하다. user가 session data 를 잃지 않게 해준다. stickiness 기간 지정 가능.

Crosszone LB

다른 존에 있는 instance와 연결가능하다. CLB는 기본설정으로 사용 안하고, 사용해도 돈 안나감

ALB는 항상 사용, inter AZ간에는 무료, 비활성화 할 수 가 없다.

NLB는 기본설정은 안사용하는데 돈 내면 inter AZ간 가능…

SSL/TLS

SSL : Secure Sockets Layer TLS : Transport Layer Security

• TLS가 SSL 보다 새버전이다. 보통 TLS 사용된다.

• SSL 는 clients와 load balancer의 트래픽을 암호화 시킨다. (in-flight encryption)

• SSL 인증서는 만료일이 있어서 갱신되어야한다.
• load balancer는 X.509사용한다.
• ACM(AWS Certificate Manager) 이용해 인증서를 관리할 수 있다.
• HTTPS listener :
  • specify a default certificate
  • add an optional list of certs to support multiple domain
  • Clients can use SNI

SNI(Server Name Indication)

• 여러개의 SSL certificate를 한 웹 서버에서 로딩할 수 있게한다.

• 클라이언트가 호스트 네임을 지명해야한다.

• 서버가 알맞은 cert를 찾아준다.

• ALB/NLB/Cloudfront 에서 동작.

• ALB 는 여러개의 SSL certificate에 대해 여러개의 Listner 를 제공한다. NLB 도 여러개의 Listner제공.

  cf) CLB 는 하나의 SSL cert 만 가능

ELB (Connection draining - CLB), (Deregistration Delay - ALB, NLB)

Instance 가 ok 한 상태가 아닐 때, 정상 instance 에 request 보내는 것.

Autoscaling group

• scale in : removing , scale out : adding according to load.
• min.max 를 정할 수 있다.

• LB에 자동으로 등록된다.

• cloud watch alarm에 scale out, in 조건을 설정해놓으면 알아서 조절한다.
• 다음과 같은 속성
  • A launch configuration(AMI+Instance type, EC2 user data, EBS bolumes, SG, SSH key pair)
  • Min,max size, Initial Capacity
  • Network + Subnets Information
  • Load balancer info
  • scaling policy

ASG scaling policy

1. target tracking scaling : 40% ~
2. simple/step scaling : cloud watch alarm 이 울리면 2 unit 늘려라.
3. scheduled actions : 5pm on fridays, increase min capacity.

한 region에 최소 2개에서 6개 까지 존재한다. (평균적으로는 세개) 예를들어, Sydney:ap-southesast-2 라는 region 을 선택한다면, 이 지역에는 하나 이상(최소 2개에서 6개)의 데이터 센터가 존재하는 것이다. 이 데이터 센터는 물리적으로 떨어져 있다. 그치만, high bandwith ultra-low latency network 로 연결되어 있다.

Regional 과 Global service

지역 선택 해야하는 서비스가 있고, 그렇지 않은 서비스가 있다. 왜지? ec2는 regional service의 예시, IAM 은 global 서비스의 예시.

IAM (Identity and Access Management)

는 무엇인고 하니,,, ‘AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스’ 라고 나와있다. 여기에는

users : 사람

group : 팀

roles : 기계

가 존재한다. 그리고 JSON 파일로 정책 주어진다.

MFA(Multi Factor Authentication) 이 가능하다. (한가지가 아니라 여러가지 관문을 거쳐야만 인증이 완료 되는 것. 보안 강화)

Root account 는 inital setup 하고 사용하지 않는다. 대신 추후에는 IAM user access 키 이용해서 접속하도록 한다. 한 명의 IAM user — credentials (공유하면 안된다) 하나의 IAM role — 하나의 application

EC2

EC2와 관련된 개념 네가지를 정리하도록 하겠다.

1. EC2 : 가상 머신 빌랴줌
2. EBS : 가상 드라이브에 데이터 저장
3. ELB : Distributing load across machines
4. ASG : 오토 스케일링 그룹

일단 요기 튜토리얼에서는 EC2 instance를 만들었다. (AMI AMAZON LINUX2, free tier) 이렇게 EC2 instance를 만들었으면 이제 우리 컴퓨터에서 접속을 해봐야한다. SSH 로 한다. SSH 의 포트는 보통 22인가보다. EC2 만들 때 Security group 에서 이미 SSH port 22 규칙이 디폴트로 있었다. 그래서 따로 규칙 추가 안하고 연결 진행하면 된다.

일단 cmd에서 SSH 가능한 OS는 mac, linux, window >=10 이다. 윈도우 10이하면 putty 사용해야한다. 나는 윈도10이지만 모르고 푸티를 사용해서 여지껏 하고 있었다. 배움이란 역시 슬프고 즐겁다..

접속은 이렇게 한다. 커맨드 라인에, ssh -i key.pem ec2-user@ip주소 (key 는 ec2 만들 때 내려받을 수 있다.) 그.러.나.! 일케 하면 오류뜬다. ‘permission error. Unprotected private key file ‘ 왜냐면, key file을 프로텍트 해줘야한다. 그것은 바로 chmod 0400 key.pem 명령어를 통해 할 수 있다. 일케 해주면 소유자만 읽을 수 있게 되나보다.

AMI AMAZON LINUX2, free tier에서 간편하게 브라우저로 연결하는 방법이 생겼다. CONNECT가서 클릭하면 된다. 굉장히 편한 매력이 있다. TERMINAL 과 KEY는 필요없지만 쨌든 이 방법도 SSH를 사용하기 때문에 SSH 포트22 룰이 필요하다.

Security Groups

Ec2 머신에서 어떻게 트래픽이 허용될 것인지 정해준다. firewall 처럼 작용한다. ports, authorize IP(IPv4, IPv6),Inbound/outbound… region에 국한되어 만들어진다. 따라서 새로운 region 이면 새로 security groups 만들어야 한다. Application 이 TIME OUT –> Security group issue Connection refused –> application error.

Default : Inbound 는 block, outbound 는 Authroize.

Public vs Private vs Elastic IP

Public IP : www로 접근 가능 : 특별한 주소가 필요하다. 같은 IP는 안된다.

Private IP : private network에서만 접근 가능 : private 내부에서는 ip 가 다 달라야하지만, 다른 private network 의 ip와는 겹칠 수 있다. : internet 에 접속하려면 NAT + internet gateway 를 사용해야한다. : specified range 만 private IP 로 사용가능하다.

Elastic IP : instance를 start/stop 하면 IP가 바뀌는데 그것을 해결하기 위한 방안 같은 것. (Fixed IP 필요할 때) : IPv4 : 계정 당 max 5개 가질 수 있다. :그치만 추천은 하지 않는다. 그냥 DNS name을 등록하래

EC2는 internal AWS network 에선 private IP 사용한다. 그러나 SSH 시에는 public만 사용 가능. private IP 는 stop 해도 변하지 않고, public은 변한다. 그래서 Elastic IP 사용

서버 시작 Command

sudo su : root로, 권한 문제 없이 모든 command 다 칠 수 있다.
yum update -y
tum install -y httpd.x86-64
systemCH? start httpd.service
          enable
curl localhost:80 (Apache server는 port 80)
echo "Hello world" > var/www/html/index.html

EC2 USER DATA

: Bootstrapping : 머신이 시작될 때의 launching commands 이다. 컴터 시작할 때 마다 자동으로 커맨드 수행되는 것.
: EC2 만들 때, advanced details 에 user data 있다.
여기에 명령어 (앞에 sudo 꼭) 적어놓으면 된다.

예시)
  #!/bin/bash (이거 첫줄에 써야함. 중요 뽀인또)
  #install httpd (Linux2 버전)
  sudo yum update -y

user data에 있는 커맨드는, intance가 새로 만들어질 때 마다 수행된다.
  ==> 내 홈페이지의 경우, EC2 톰캣 서버 깔기?를 USER DATA 에 넣을 수 있을 것같다. 그러나 JSP 파일은 내가 직접 넣어야할듯..

EC2 Instance Launch Types:

총 다섯가지 있다.

1. on demand instance
  : 사용한 만큼 낸다.
  : 가장 비싸지만, no long term commitment. (오래 계약 안해도 된다.)

  : elastic workload 에 적합하다.

2. Reserved Instances
  : 75프로 저렴(on demand 기준)
  : 대신 1년 이상 사용해야한다.
  : 특정 instance type를 예약해야한다.
  : 꾸준한 사용이 필요한 일에 적합하다.

3. EC2 Spot Instances
  : 90프로 저렴(on demand 기준)
  : 현재 사용 예산 > 정해놓은 limit --> instance 사라진다.
  : batch job, data analysis, image porecssing 등에 적합.

4. Dedicated Hosts
  : EC2 instance placement 의 full control 가능.  --> 정확히 이해를 못했다. 그치만 물리적으로..?
  : 복잡한 licensing model 이 있는 SW에 적합함. (왜?)
  : 강한 규제나 제약이 있는 회사.

5. EC2 dedicated Instances
  : 하드웨어가 내꺼
  : 다른 Instance와 하드웨어 공유 가능하지만, 너의 계정에 있는 것들만 가능.
  : No control over Instance placement.

EC2 Network Interfaces (ENI)

  : VPC: Virtual Private Cloud
  : ENI는 VPC의 logical component, virtual network card 대표.
  : EC2를 네트워크에 연결해준다.
  : Primart private IPv4,
  : 하나 이상의 IPv4 ENI 만들기 가능 for failover.
  : ENI 만들고, EC2에 Attach 하면, 한 instance에 두개의 instance가 붙는다. 그리고 ENI 는 옮길 수 있다.

EC2 pricing

  : 시간 당 붙는다.
  : region, type of ec2, os 에 따라 가격이 다르다.
  : billed by the second. 6 초나 60초나 비용이 같다. 0.023/60 달러
  : Instance 가 스탑되면, 그 후 돈이 청구되지 않는다.

Custom AMI

PROS
  : 필요한 패키지를 미리 깔 수 있다.
  : 부트 타임 빠름.
  : network 안 머신 조종.
  : 유지 보수, 장저밍 많다.

AMI ARE NOT BUILT FOR A SPECIFIC AWS REGION.

Burstable Instances

  t2 machines
    : 보통은 그럭저럭 괜찮은 cpu이다. 처리할게 갑자기 많아지면, Burst 하면서 처리. Good CPU.
    : Credit을 burst 하면서 동작한다. credit이 다 사라지면, cpu 성능이 나빠진다.
    : 기계가 burst 멈추면, credit 이 시간을 거치며 축적된다.

T2 unlimited

  : unlimited burst credit balance.

이 단원에서 EXAM CHECK LIST!

1. ec2에 ssh로 접속하는 방법.
2. .pem permission & 에러
3. security group의 적합한 사용.
4. private, public, elastic IP 의 기본적 차이점.
5. user data 이용하는 법과 customize 하는 법.
6. OS 향상 시키기 위해 custom AMI 하는 법...?
7. EC2 는 seconds 에 의해 청구된다.  ?
      'AWS 리전에 따라 시간 또는 초 단위로 계산됩니다.',
      '1시간 미만의 각 인스턴스 시간은 Linux 인스턴스의 경우 초당 요금으로 청구되고 다른 모든 인스턴스 유형의 경우 1시간으로 청구됩니다.'
      '인스턴스가 초 단위로 요금이 청구되는 경우 새 인스턴스가 시작될 때마다, 즉 인스턴스가 실행 상태로 전환될 때마다 최소 60초의 요금이 청구됩니다.'

Content based filtering

1. Structured data (schema first)

Clustering

ID3 algorithm

Forward propagation: Vectorized implementation