AWS Resource관리(TAG/AWS 비용 관리 도구)

우리가 AWS를 사용하다 보면 정말 다양한 Resource를 관리하고 운용해야한다. 분산되어있는 자원들을 어떻게하면 조금 더 손쉽게 관리할 수 있을까?

다양한 방법이 있겠지만 가장 손쉽고 빠르게 관리할 수 있는 것은 다름아닌 TAG일 것이다.

 

TAG는 AWS에 만들어진 리소스에 누가, 왜, 어떤 목적으로, 어떤 작업을 하는가? 를 리소스 내부에 들어가지 않더라도 충분히 확인할 수 있게 도와준다. 즉 TAG란 AWS 리소스에 연결된 서술용 메타데이터(data에 대한 data) 라고 할 수 있다. 일부 태그는 기본적으로 제공되며, 제거가 불가능한 경우도 있다. 콘솔환경과 cli 환경 둘 다 사용할 수 있다.

 

TAG를 활용해서 환경, 애플리케이션, 소유자, 부서, 비용센터, 목적, 스텍, 자동화된 환경 등 각종 환경에 도움을 줄 수 있다. 이렇게 분류를 한다면, 작업을 할 때마다 테그를 중심으로 필터링을 할 수 있으며, 이런 분류를 통해 능율을 조금 더 높일 수 있다.특히 특정 태그를 사용해 인스턴스를 동시에 시작/종료를 할 수 도 있다. 혹은 특정 계정, 팀, 자원 등에 대해서도 동시에 관리할 수 있다. 

 

또한 AWS Config(required-tags 관리형 규칙)를 통해서도 태그지정 및 제어를 할 수 있다.  필수tag를 붙여야 한다는 조건을 명시하게 된다면, 이 조건에 따라서 규정상으로 붙여야 하는 리소스를 확인 및 공지를 할 수 있도록 도와준다. 이때 tag를 이용해서 관리되지 않는 리소스를 확인한 후, 규합하여 일괄적으로 필요없는 더미 데이터를 지울 수 도 있으며 이것은 자원관리에 대한 효율성을 증가 시킬 수 있다.

 

CLI 예시

export TIMESTAMP = 'date'
aws ec2 create-tags --resources a-123qwer --tags "Key=TimeCheck, Valus = $TIMESTAMP"
==> ec2의 인스턴스에 tag key(테그의 이름)을 TimeCheck로 두었으며 Valus는 date라는 날자를 입력받도록 설정되어 있다.

aws ec2 describe-instances --filters "Name=tag-key, Values=TimeCheck" --query "Reservations[].Instances[].[InstanceId,Tags[?Key=='timeCheck'].Value]"
==> TimeCheck라는 tag가 있는 인스턴스의 값을 보여라.

 

특정tag를 반드시 붙여서 만들어라. 라는 내용의 파일

{  "Effect" : "Allow",
   "Action" : "ec2:CreateVolume",
==> 볼륨생성할 권한을 주겠다.
   "Resource" : "arn:aws:ec2:ap-northeast-2:123456:volume/*",
==> 생성할 수 있는 위치는 서울(ap-northeast-2)의 볼륨 전부(*)
   "Condition":
==> 조건을 부여한다.
     {  "StringEquals:
        {  "aws:RequestTag/costcenter" : "TagCostCenter",
==> costcenter라는 태그를 붙여야한다. 이때 TagConstCenter라는 값이 있어야한다.
           "aws:RequestTag/stack" : "prod"
==> stack이라는 태그를 붙여야하는데, 이때 prod라는 값를 붙여야 한다.
        },
        "ForAllValues:StringEquals":
        {  "aws:TagKeys": ["costcenter", "stack"]
        }
     }
}

 

Lamdb와 같은 환경은 상관없겠지만,  계속해서 비용이 발생되는 환경(EC2 등)과 같은 경우 이런 방식을 등을 통해서 비용절감을 할 수 있다. 

 

특히 Pilot light전략을 바탕으로한 재해복구(DX)와 같은 경우 재해 상황이 아니라면, 평상시의 필요없는 리소스를 최소한으로 유지한다. 재해가 발생할 경우 테그를 확인하여(특정 리전에 있는 리소스를 확인한 후) 복구를 위한 자동화 환경을 실행할 수 도 있다.

*  Pilot light(파일럿 라이트) (분 단위 RPO, 시간 단위 RTO): 시스템의 가장 중요한 핵심 요소를 항상 실행하는 최소 버전의 환경을 DR 리전에 유지합니다. 복구 시기가 되면 중요한 핵심 요소를 중심으로 전체 프로덕션 환경을 신속하게 프로비저닝할 수 있습니다.

 

이것 외에도 AWS 비용 관리 도구 를 활용해서 자원을 관리할 수 있다.

계정을 소유하고 있다거나, 청구서 확인을 할 수 있는 계정이 있다면, 주기적으로 전반적인 비용 및 사용량 상태를 확인할 수 있으며, 월별 청구서에 엑세스하여 비용을 확인할 수 있다. 사용자 정의 비용 및 사용 예산을 설정할 수 잇으며, 종합적 데이터 및 보고서에 엑세스 할 수 있다.

 

자원을 관리하는데 처음부터 비용최적화를 하기에는 굉장히 어렵다. 그렇기에 처음에는 비용이 조금 더 나오거나, 온프레미스환경과 비슷한 비용이 나타날 것이다. 그렇기에 비용 절감을 고려하여 약 1달에 1번정도의 지속적인검토가 필요하다. 또한 인스턴스의 '적정 크기(자원에 대한)'를 결정해야 한다. CPU코어가 1개에 렘이1gb면 되는데 t2.micro가 아닌 m5.와 같은 거대한 용량을 쓸 이유가 없지 않는가? 또한 이러한 것과 더해서 전체 코어성능을 판단하여 설정할 수 있어야한다. 1년 이상의 장기 실행 중인 인스턴스와 같은 경우 예약 인스턴스(RI)와 같은 것으로 변환을 할 필요도 있다. 병렬로 실행되며 단기적으로 사용할 인스턴스와 같은 경우 spot 인스턴스 혹은 AWS Lamdba(15분 이하)를 고려할 수 도 있다.

 비용을 지불한 후(업데이트) 사용가능한 서비스인 AWS Trusted Advisor와 같은 기능을 활용한다면, 비용최적화 등에 대해 실시간으로 대략적으로 지침을 받을 수 도 있다.

중요한 이벤트는 적색, 권고를 표시하는 노란색, 아무런 이상이 없다는 의미인 녹색과 제외항목인 회색으로 구분지을 수 있다.

AWS Cloudwatch와 Cost Explorer를 활용해 낭비되는 요인을 찾고 분석하여 제거할 수 도 있다. AWS Lamdba 혹은 Amazon CloudWatch Events(EventBridge)를 활용해 Serverless Stopinator를 활용할 수 도 있다. 지정된 리소스를 켜고 끄고, 삭제하는 등의 역할을 하는 코드를 의미한다. 서버 프로비저닝 할 필요가 없이 코드를 실행할 수 있으며, CloudWatch Events를 활용하여 스케쥴링에 따라서 주기적으로 API이벤트(Lamdba)를 실행할 수 있다. 이렇게 된다면 Stopinator용 서버를 개설해두고 사용하는것(인스턴스를 이용하게 된다면 EC2 볼륨 비용 등) 보다 훨씬 더 비용 절감을 할 수 있다. 

 

* 결제 대시보드를 통해서 비용을 확인할 수 있으며, CloudWatch를 통해 설정값 이상의 비용이 발생된다면 알람을 통해서 확인할 수 도 있다.