정리 블로그

1. S3의 수명주기??

 -. S3의 수명주기는 무한으로 증가되는 S3 버킷 용량을 주기적으로 정리 하는데 목적이 있습니다.(S3는 용량 베이스 요금 청구)

 -. 수명주기는 각 버킷별로 생성할 수 있으며, 같은 수명주기를 가지더라도 각 버킷에서 새롭게 생성 해줘야 합니다.

2. S3 수명 주기 생성하기

보이는 것과 같이, 4개의 버킷이 있으며 수명주기는 버킷마다 생성해줘야 합니다.

위에 언급한 것처럼 네 개의 버킷 수명주기가 모두 같더라도 각 버킷에서 수명주기를 생성해줘야 합니다.

'look-at-this'라는 버킷을 기준으로 수명주기를 생성.

수명주기를 생성하고 싶은 버킷을 클릭하여, '관리'로 들어갑니다.

'관리'탭으로 가보면 위와 같이 '수명 주기 규칙'을 볼 수 있습니다.

현재 care-accesslog라는 수명 주기 규칙을 생성해두었으며, 상태가 Enable로 보아 현재 정상적으로 작동하는 수명주기 규칙입니다. 수명 주기 규칙을 만들었더라도, 상태를 Disable로 변경하면 해당 규칙은 적용되지 않으니 참고하시면 됩니다.

생성해둔 수명 주기 규칙 상세를 보면,

크게 '현재 버전 작업'과 '이전 버전 작업'으로 나눌 수 있습니다.

S3의 경우, 버저닝을 통해 관리를 할 수 있으며, 수정을 할때마다 버전 표기를 할 수 있습니다.

따라서, 현재 버전에서 버전 변경 없이 30일(수정가능)이 지날 경우 객체가 만료됩니다.

S3객체의 버저닝을 사용하지 않는 경우, 현재 버전 작업에서 객체가 만료되면 삭제가 진행됩니다.

(위를 기준으로 30일이 지난 객체는 삭제됩니다.)

S3객체의 버저닝을 사용하는 경우, 현재 버전이 만료되어 이전 버전 작업으로 이동합니다.

(위를 기준으로 30일이 지난 객체는 버전이 만료되고, 이전 버전 작업으로 가게됩니다. 이전 버전은 +1일 후 버킷 삭제 규칙이 적용되어있으므로, 31일 후 삭제됩니다. 만약, 객체 버전 작업이 30일, 이전 버전 작업이 40일로 설정되어 있다면, 실제로 버킷내에서 삭제되는 것은 30일+40일, 즉, 70일이 됩니다.)

3. 같은 버킷내 접두사 규칙 적용

같은 버킷에 생성된 객체라도 삭제 주기가 다를 수 있습니다.

ex. look-at-this 버킷이 있으며, 해당 버킷에 'AWSlogs/' 폴더가 있고, 'AWSdatas/' 폴더가 있다고 가정해봅니다.

logs 폴더만 규칙을 적용하려면 아래와 같이 진행하면 됩니다.

위와 같이 적용할 경우 AWSlogs/ 하위에 규칙이 적용됩니다.

4. 주의사항

*. 직접 S3 버킷을 정리하는 것과 마찬가지로, 수명 주기 규칙을 생성 후 삭제가 되면 복구할 수 없습니다.

따라서, 제가 작성한 정보는 참고해주시고, 실제 적용 전 한번 더 테스트 해보시는 것이 안전합니다.

(객체만료일을 1일로 하여 테스트하는 방법이 있으며, 실제 하루가 지나야합니다.)

*. 약 1년정도의 데이터가 있는 상태에서 30일 후 삭제 등의 규칙을 입력할 경우, 30일이 지난 모든 데이터(30일 초과 데이터는 모두 삭제되니 참고하세요.....)

1. Elastic Beanstalk 생성 후 S3

 Elastic Beanstalk 생성했을 때, S3 버킷도 자동으로 생성된다.

버킷을 지우려면 먼저 S3 버킷을 비워야 한다.

버킷내 내용을 삭제 후 진행하려다보니, 삭제가 정상적으로 진행되지 않았음.(아래 참고)

s3:DeleteBucket 권한이 없으므로, API 응답이 Deny로 출력됨.

Elastic Beanstalk에서 Enviroment를 삭제해도 버킷은 지워지지 않습니다!

2. S3 Bucket Policy 수정

위와 같이 일부 정책을 수정해줘야 한다.

,
        {
            "Sid": "eb-58950a8c-feb6-11e2-89e0-0800277d041b",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:DeleteBucket",
            "Resource": "arn:aws:s3:::elasticbeanstalk-ap-northeast-2-계정ID비밀임둥"
        }

, 도 확실히 삭제해줘야 오류가 안남!!!!!!!

3. S3 버킷 삭제된 모습

Delete Deny 정책이 들어가있기 때문에 정책만 수정해주면 삭제 가능! 끝!!

1. VPC 피어링

 -. 두 개의 VPC가 피어링 연결을 하여, 서로 다른 VPC가 Private 통신을 할 수 있도록 함.

 -. VPC 피어링 연결이 되어있지 않으면, Public망을 통해서만 통신이 가능하다.

2. VPC 피어링 방법

AWS Service 중 VPC 선택했을 때, 위의 두 개의 VPC를 연결할 예정

(Denns-Default-KOR-VPC <> QA-Denns-Default-KOR-VPC)

1. AWS VPC SERVICE 중 피어링 연결을 클릭.

2. VPC 피어링 설정

 -. 피어링할 로컬 VPC(상대 VPC와 연결할 VPC). 다른 계정의 VPC와도 연결이 가능하며, 현재 진행하는 테스트는 1계정 2VPC임. 1계정이라 하더라도 다른 리전에 위치해 있다면 다른 리전을 선택해야함.

3. 피어링 연결

 -. 피어링 연결 설정을 완료하면 위와 같이 나옴.

4. 수락자 VPC

 -. 피어링을 요청했으면, 반대편 수락자 VPC에서도 요청 수락을 해줘야함. 해당 테스트의 경우, 동일 계정에서 테스트하기때문에 바로 요청수락을 할 수 있음.

5. 피어링 완료 상태

 -. 요청자와 수락자 계정이 동일한 소유.

3. 라우팅 테이블 추가

 -. 피어링을 맺었으면 라우팅을 추가해줘야 한다. 추가해주지 않으면 통신 불가.

Default는 라우팅 테이블이 없음.

VPC -> 라우팅 테이블에서 모든 Subnet의 라우팅을 추가해줘야 함.

Denns-public-subnet // Denns-Private-Subnet-a // QA-Denns-private-subnet // QA-Denns-public-subnet (4개)

Denns VPC 서브넷(2개)에는 QA-Denns의 IP대역을 추가,

QA-Denns VPC 서브넷(2개)에는 Denns의 IP대역을 추가해줘야 한다.(아래 참고)

** 한 개의 VPC에서만 해줄 경우, 단방향 통신만 가능.

바로 위에서 설명한 것과 같이, QA-Denns VPC대역(20.100.0.0/16)에서는 Denns VPC대역(10.100.0.0/16)으로 라우팅 입력하며, 대상은 조금 전 맺은 피어링(pcx-0~!@jqek12312938u0)를 선택한다. 마찬가지로 Denns VPC대역(10.100.0.0/16)서브넷의 라우팅에는 QA-Denns VPC 대역 입력!!

**라우팅을 추가하는 이유는 작성자 입장에서 쉽게 생각해보자면, 내 서버가 현재 QA-Denns VPC에서 x라는 서버를 만들었으며(서버 IP : 20.100.0.1), 해당 서버에서 Denns VPC에 있는 서버(10.100.0.0/16 사이에 위치한 서버)와 통신을 할 때, pcx-0d475bc~~~~ 이곳으로 가라는 뜻임.(위의 테이블에는 연습용으로 만들어서, igw 혹은 nat-gateway로 가는 0.0.0.0/0의 라우팅이 빠져있습니다. 참고해주세요)

1. 도메인 구매

무료 도메인 Freenom 이용하여 도메인 구매(무료임)

‘taek.gq’ 도메인을 구매하였으며, 해당 도메인을 Route53에 등록하는 과정을 기록할 예정. 업체의 경우, 원하는 도메인을 아이네임즈와 같은 호스팅업체를 통해 도메인 구입 후  사용하면 되며, 도메인은 어느 곳에서 구입하던 상관없음.

2. Route53에 구매한 도메인 등록하기

Route53에 이미 만들었기 때문에 만드는 방식을 다시 한번 정리하여 작성할 예정.

Route53 서비스로 접근하여 ‘Create hosted zone’을 통해 생성한다.

‘Domain name’ : 구매한 도메인 이름을 작성한다. 저의 경우, Freenom을 통해 ‘taek.gq’를 구매하였기 때문에 해당 이름을 작성.

‘Description-optional’ : 위의 화면에서도 보이는 것 처럼 해당 도메인 Hosted zone에 대한 설명을 쓴다. Freenom에서 구매한 도메인 정도로 작성해줬음.

Type : 해당 DNS를 Private용도로 사용할 지, Public용도로 사용할 지 선택하며, 저의 경우 여러 테스트를 위해 Public으로 생성하였음.

테스트를 위해 loool.qja를 만들었으며, 실제로 사용할 수는 없겠지만 생성이 완료되면 NameServer와 SOA 필드가 만들어지며, NameServer의 경우, 호스팅업체의 네임서버를 사용해도 되지만 특별하지 않으면 AWS 네임서버 사용하는 것도 무방.

3. 도메인 구매한 사이트에서 NameServer 변경

Freenom에서 구매하였으므로 해당 사이트에서 변경하는 방법을 기록하지만, 대부분의 사이트는 같은 형식으로 되어있을 것이다.

-. Services(상단탭) -> My Domains(상단탭) -> Manage Domain -> Management Tools -> Nameservers 경로를 따라 들어가면 Nameserver를 변경할 수 있는 위와 같은 화면이 나온다.(프리놈을 사용하는데 못찾겠으면 컨트롤+F에서 검색하여 찾을 것)

-. Custom Nameserver로 설정하여, Nameserver 1~5를 순서대로 입력해줄 것. AWS 네임서버는 4개가 있으며, 위에 Hosted Zone을 생성하면 확인이 가능하다. NS 레코드의 Value 입력(아래 참고).

4. Route53 사용하기

Route53에 도메인 등록이 완료되었으며, 해당 도메인을 사용하면 된다. 하위 도메인은 필요에 따라 레코드를 생성하여 사용할 것.

(하위 도메인인이란, ‘taek.gq’를 볼 때, ‘www.taek.gq’, ‘test.taek.gq’ 와 같이 taek.gq에서 파생된 도메인을 말한다.)

추후 ACM에서 SSL 인증서 발급받는 방법을 작성할 예정.

1. Launch Template과 Launch Configuration의 차이

두 가지 모두 Auto Scaling을 위해 생성해야 하는 서비스지만, Template은 배포할 소스의 버전이 올라가도 해당 템플릿 업데이트를 통해 버전관리가 가능하다. Launch Configuration의 경우, 배포할 소스의 버전이 올라가면 Launch Configuration을 매번 새로 만들어줘야한다.

2. Launch configuration 설정 방법

Launch configuratio의 이름 및 생성하고자 하는 AMI, 인스턴스 타입을 선택한다.

Spot 인스턴스(요금이 비교적 저렴하지만, 사용이 불가능할 때가 있음) 사용 여부 체크, IAM Role, CloudWatch 모니터링 여부 및 스토리지 타입, 용량 선택을 선택한다.

Security Group을 선택.

ScaleOut 발생 후 서버 접속 시, 사용할 Key pair 선택.

3. Launch Template 설정 방법

Template name : 템플릿 버전이 바뀌어도 계속 남아있는 이름이기 때문에 서비스에 대한 이름을 명명하는 것이 좋을 것 같음.

Template version description : 템플릿 버전에 대한 설명을 하면 나중에 버전 선택 시, 알아보기 편함

Auto Scaling guidance : 체크 시, Launch template을 만들면서 AMI까지 바로 지정.

(Optional) Source Template : 해당 부분을 클릭하면 기존에 생성하였던 시작 템플릿을 활용하여 나머지 세팅이 진행됨

AMI : 기존에 생성한 AMI를 선택하여 시작 템플릿을 구성

인스턴스 타입을 설정하여 ASG 발생 시, 어떤 타입으로 진행할 지 설정.

Key pair name : 로그인 시, 사용할 키페어 선택

Networking Platform : VPC 또는 EC2-classic 중 어떤 인스턴스를 시작할 지 여부를 선택하지만, EC2 Auto Scaling의 경우, AutoScaling 그룹 설정이 우선하기때문에 해당 설정이 무시됨.(공식 가이드 참고)

Security Group은 시작 템플릿 생성 중 신규 생성이 안되기 때문에 기존에 만들어 두거나, 다른 탭에서 생성 후 새로고침하여 선택.

Storage : 스토리지의 경우, AMI를 선택하면 해당 AMI 생성 시 만들어진 디스크 용량으로 자동으로 설정됨.

리소스 태그 : Scale Out이 발생하면 해당 인스턴스 및 볼륨에 태깅과 동시에 진행할 수 있음. 해당 값을 설정하면 나중에 스케일아웃 된 값을 찾기 쉽다.

Network Interface : 생성되는 인스턴스에 특정 Private IP를 지정할 수 없지만, 퍼블릭IP 자동할당 등을 지정할 수 있음.

1. AWS에서 25번 포트(SMTP)를 제한하는 이유

 -. 인스턴스에서 아웃바운드 통신정책 중 25번 포트가 오픈되어있더라도, 사용이 제한된다.(정확히는 통신이 정상과 비정상을 왔다갔다 함)

 -. 무분별한 스팸메일 발송을 제한하기 위해 필요한 목적 기재.

2. 25 포트(SMTP) 사용 신청 방법

aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

로 접속하여, 사용 신청 필요.

1) Email address는 25번포트 제한 해제 요청 후 처리 결과를 받을 수 있는 주소를 입력.

2) 
  -. 인스턴스에서 포트를 사용하고자 하는 이유 및 목적을 상세하게 입력.(스팸 발송용 방지)
     => 가급적 명확하고 자세하게 작성
  -. 사용하고자 하는 인스턴스의 리전 기재 필수
     => 한국의 경우, ap-northeast-2 

3) Elastic IP address : 해당 부분은 Optional로 기록되어있으나, 필수 기재할 것.

EIP가 있는 경우, EIP를 기재하고, Private 인스턴스인 경우, 외부와 통신할 때 사용되는 IP를 적어줄 것(ex. NAT 인스턴스 IP 등)

1. AWS 콘솔의 스토리지 용량 증설

 -. AWS 콘솔창에서 증설하고자 하는 EC2의 Volume을 선택.

 -. 해당 볼륨을 선택 후 'Modify Volume'을 선택. EC2를 생성하면서 별도로 Volume에도 태그를 달지 않으면 나중에 헷갈릴 수 있음

 -. 원하는 사이즈로 조정 후 'Modify' 버튼 클릭.

 -. 해당 작업을 진행하면서 인스턴스가 재부팅되지는 않지만, 서버가 약간 느려질 가능성이 있음.

 -. 해당 작업 전, cmd 창을 열어 'ping 8.8.8.8 -t' 를 입력하여 끊어짐을 확인하였으나, 끊어짐 없었음.

2. 인스턴스내에서 볼륨 확인

 * 경로 : 서버 관리자 -> 좌측탭 제일 하단 -> Volumes -> Disks

 -. 변경 전에는 30.0GB를 나타내고 있음.

 -. 변경 후에 Capa는 '45.0GB'로 증가하였으나, 아래 Volume 탭을 보면 변경 전 30GB를 나타냄.

 -. AWS 콘솔에서 Volume 증설 후 추가 작업이 필요.

 -. 서버관리자 하단에 기존의 30.0GB를 나타내고 있는 부분을 우클릭하면 'Extend Volume...' 클릭

 -. 클릭 후 원하는 용량을 증설할 수 있음(물론 사용가능한 용량(Maximum)까지만 가능)

 -. 'OK'를 누르면 금방 변경됨(완료)

 -. 해당 작업은 'Root Volume'으로 진행 및 테스트하였으며, Sub Volume도 같은 방식으로 작업 가능

1. IGW가 설정되어야 구성한 VPC가 외부와 인터넷 통신이 가능. 만약 인터넷을 쓰지 않으려면 IGW가 없어도 됨. 단, VPC로 연결하려면 VPN과 VPC를 연결하는 IPSec-VPN을 연결하거나, Custom Gateway 등의 구성을 해야 VPC 내부로 접속이 가능하다. 보통의 경우, NAT-Gateway나 Bastion Host를 통해 VPC 내부와 통신하기 때문에 IGW가 필요함.

2. WEB 서버일지라도 Public Subnet보다는 Private Subnet에 위치시키고, Internet-facing LB를 통해 WEB용도의 인스턴스에 접속되게 하는 것이 보안상 안전.

3. NAT 인스턴스의 역할은 VPC내 생성된 인스턴스를 터미널(linux계열) 혹은 원격데스크톱(윈도우 계열)을 통해 접속하기 위해 필요함. 또한, Private Subnet에 위치한 인스턴스가 인터넷을 사용할 수 있게 해주는 역할도 할 수 있다.

4. AZ는 이중화를 하여 구성할 것을 추천. 단일 AZ를 사용할 경우, LB를 통해 무중단을 위한 구성에 제약이 있음.(사용 가능한 AZ 개수는 리전마다 다름)

5. Subnet은 기본적으로 6개의 구성(Public Subnet 2EA, Private Subnet 4EA)을 하고, 특별한 이유가 있지 않다면 Private Subnet에 인스턴스를 구성하여 외부에 노출되지 않도록 한다. 각각의 subnet은 필요에 따라 라우팅을 달리하여 용도에 따라 통신경로를 지정해줄 수 있다.

6. LB는 Internet-facing을 통해 대외 서비스를 할 수 있도록 한다. 대내 서비스의 경우, Internal 구성을 하도록 하자.

*위 구성도에서 DevOps User도 IGW를 통해 VPC 내부로 접속하는게 맞음.