일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 채팅
- NeXT
- crud
- merge
- async
- 튜플
- docker
- Vue
- 중급파이썬
- MongoDB
- AWS
- TypeScript
- dict
- RDS
- SSA
- node
- S3
- socket io
- Class
- 파이썬
- react
- Props
- flask
- pandas
- wetube
- git
- EC2
- SAA
- lambda
- 카톡
- Today
- Total
목록AWS (35)
초보 개발자
Snapshot Storage snapshot에 관한 자료를 보던 중, snapshot storage의 산정방식이 흥미로워 정리해보려고한다. 위의 자료에 의하면, 같은 볼륨에 대한 스냅샷이 여러개 존재하며 각 볼륨의 콘텐츠와 크기가 변했을 경우에 최대한 상위 스냅샷의 데이터를 참조하여 효율적으로 사용하도록한다. 먼저 Snap A에서 10 GIB가 사용이 되었고, 이후 볼륨에서 삭제와 생성을 통해서 4GIB가 변경된 후 스냅샷을 생성한 경우, Snap A(상위 스냅샷)과 겹치는 부분 6GIB는 Snap A에서 참조하고 4GIB만 Snap B에서 새롭게 생성이 된다. 마찬가지로 Snap C를 생성한 경우, Snap B와 비교했을 때 새로운 데이터가 2GIB추가만 되었을 뿐이므로, 기존 6GIB는 Snap A..
Compute optimizer란 AWS에서 Cloud watch에서 수집한 metric을 바탕으로 현재 사용량을 분석하여 과다 혹은 과소 프로비져닝 된 것을 확인해주며, 적합한 인스턴스 유형까지 추천해주는 아주 유용한 서비스이다. EC2 인스턴스뿐만 아니라, Auto Scaling그룹, EBS볼륨, Lambda함수, Fargate까지 추천해준다. 사용해보자 사용중인 EC2의 아이디를 클릭하면, 위와 같은 화면이 나온다. 3가지의 추천 항목이 나오는데, 각각 성능의 차이가 조금 있으며, 확인 후 결정해야한다. 여기서 중요한 사실이 하나 있는데, EC2를 실행시키면 기본적으로 Cloud watch agent라는 것이 설치가 되어있지 않다. 이는 Cloud watch에서 더욱 많은 Metric을 수집할 수 ..
RTO, RPO RPO와 RTO는 이름이 비슷하고, 둘다 복구에 걸리는 시간에 관련되어있어 헷갈린다. 그 때마다 찾아보면서 다시 이해를 하지만, 시간이 지나면 다시금 헷갈린다.따라서 이번 기회에 확실하게 정리를 해보려 한다. RTO : Recovery Time Objective (복구 시간 목표) RPO : Recovert Poine Objective ( 복구 지점 목표 ) 이름만 봐서는 전혀 감이 오지 않는다. 아래의 상황을 통해 익혀보자. 상황 EBS의 스냅샷을 매일 아침 6시에 백업해둔다고하자. 오후 2시쯔음, 회사에서 누군가 실수로 대량의 데이터를 삭제해버렸고, 복구를 해달라는 요청이 있었다. 부랴부랴 복구용 ec2를 생성, 스냅샷으로 볼륨 생성, ec2에 붙여 생성하는데 까지 30분 정도가 걸려..
Spanned EBS Volume 하나의 EBS 볼륨을 사용하다 부족해지면 추가로 EBS를 추가해야하는 경우가 올 것이다. 기존의 볼륨을 Extend 하여 빈 상태의 새 볼륨을 추가하면 Spanned Volume으로 바뀐다. 두개의 볼륨이 하나의 볼륨으로 바뀌게 된 것이다. 만약 이 2개의 볼륨에서 하나의 볼륨만 복원 시키면 파일이 온전히 복원될까 ? 아니다. 하드 디스크에 파일이 저장될 때 여러 요인에 의해서 순차적으로 저장이 되지 않는다. 여러 개로 쪼개져서 이곳 저곳에 흩어져서 저장이 된다. ( 단편화 라고 함 ).단편화가 발생한 파일을 읽기 위해서 흩어진 모든 조각을 찾아야하고, 디스크 조각 모음이라는 것이 단편화된 파일을 한 덩어리로 모아준다. 따라서 하나의 볼륨만 가지고 복원하면 아마도 예상컨..
AWS를 사용할 때 가장 신경이 쓰이는 부분이 요금이라고 생각한다. 어느정도 예상을 할 때도 있지만, 예상치 못한 부분에서 과금이 일어나기도 한다. 이러한 부분을 AWS Budgets을 사용하면 사전에 방지할 수 있다. AWS Budgets은 만능이 아니기에, 하나만으로는 부족하다. 따라서 이를 보조해줄 수 있는 다른 서비스를 조합해서 사용해야한다. 사용하는 유저의 규모가 어느정도 있어서 AWS Organization을 사용한다면, 과금이 될만한 요소에 접근하는 것을 막는 SCP를 생성하여 Account나 OU에 부착해주자. SCP는 Account에 부착하는 것이 가능 AWS Organization을 사용하지 않는다면 SCP를 사용할 수 없기에 과금이 될만한 요소에 접근하는 것을 막는 IAM policy..
AWS 아키텍처 위의 아키텍쳐는 AWS 공식 사이트에서 제공하는 이미지이다. 준비물 먼저 필요한 것은 다음과 같다. 1. S3 2. IAM 3. CLI 과정 앞으로 Source Account는 복사되는, Destination Account는 복사하는 으로 설명하겠다. 먼저 복사되는 S3버켓에 복사하는 계정이 버켓, 버켓안에 있는 객체를 읽을 수 있는 Policy를 생성하여 부착하자. Create a bucket policy to allow a user in the destination account to list the source bucket’s contents and read the source bucket’s objects. Attach the bucket policy to the source bu..
VPC prefix lists란? 복수의 VPC CIDR range를 하나의 리스트로 관리할 수 있도록 하는 것이다. 만드는 방법 VPC-> Managed prefix lists에 들어가서 우측 상단의 Create prefix list를 클릭해주자. 1. Prefix list name : 이름 설정 2. Max entries : VPC CIDR의 개수 설정 ( 나중에 수정 가능 ) 3. Prefix list entries : CIDR range를 적어준다. Create prefix list 버튼을 클릭하면 이걸로 완성 사용법 시큐리티 그룹에 가서 IP적는 곳에서 아래로 내리면 prefix lists라는 것이 있는데 이걸 선택하면 앞서 우리가 설정한 CIDR blocks를 사용할 수 있다. 이렇게 간편하게..
A라는 계정에 있는 S3에 B라는 계정이 접근할 수 있을까 ? 일반적으로는 불가능하다. 하지만 두 가지의 policy를 적용해주면 가능해진다. 1. A계정의 S3의 Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB:user/AccountBUserName" }, "Action": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::AccountABucketName/*" ] } ] } 2. B계정의 IAM의 Policy { "Version": "2012-10-..