AWS

AWS-CloudWatch-Synthetics-Canary-review

드디어!!드디어!!드디어!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

AWS에도 웹모니터링 기능이 생겼다.

진짜 너무 기다려왔던 기능이다.

사용법도 간단하고 지표도 바로나오고..이거 완전 물건이다.

바로 셋팅해봤다.

블루 프린트를 사용해서 테스트를 했다.

4가지의 블루프린트를 제공하고 스크립트를 수정할수도 있으나 귀찮다.

일정은 뭐....알아서 나는 5분으로 만들고 나중에 1분으로 수정했다. 일단 나머지 파라메터를 다 기본으로 설정하고 진행했다.

생성하면 진짜 간단하게 보여준다.

핵심은 이거다. 그냥 사이트 모니터링을 해주고

지연된 URL을 체크해준다.

나같은경우엔 사이트 모니터링을

1분마다 하고 5분 평균 임계값을 1로 설정하여 상당히 예민한 모니터링 설정을 하였다. 사이트 URL 체크가 1번만 실패해도 SNS로 경보가 동작한다.

t2.micro 의 경우에는 인스턴스의 CPU가 좀 오르는게 보였으나.. 뭐 이정도는 감당할 만하다. 모니터링으로 인해 부하가 발생하는것이 불편하다면 특정 모니터링 URL만 만들어서 부하를 줄여서 모니터링 하는것이 방법일것이다.

지금 까지는 target group에 의존한 모니터링을 사용하였는데 이젠 서비스에 대한 모니터링이 가능한 순간이 와서 너무 즐겁다.

일단 블로그에 충분한 테스트 이후에 api 와 프로덕션 환경에서 사용해 봐야겠다.

포스팅을 작성하고 나중에 비용계산을 진행해 보았다.

단순계산으로

1분마다 모니터링 하면 60*24*31=44604*0.0012 USD=53.568=USD

5분마다 면....11USD 정도 이다-_-;;;

음....모니터링 치고 비싼데...????????????????ㅠㅠ

적용하기 전에 비용꼭 계산해보고 사용하자..

읽어줏셔서 감사하다!

aws-ec2-user-data-cloud-watch-metric-memory-disk

오늘 포스팅은 사용자 데이터에 대한 포스팅을 할거다.

오늘 추가하는 내용은 cloudwatch 사용자 매트릭을 이용하는것이므로 비용이발생한다.

정말 미미한 비용이지만 비용발생의 거부감이 있다면 따라하지 말것.

이전에 Cloud Watch 를 이용하여 메모리를 모니터링 하는법과 경보를 만드는 방법을 포스팅 했었다.

이건 기본매트릭엔 memory/disk 모니터링이 안되므로 스크립트로 매트릭을 Watch로 전송하는 방식이다. agent 방식도 있으나 내가 선호하는 방식이 아니다.

먼저 사용할 inline 정책이다.

필요 권한

필요한 권한
cloudwatch:PutMetricData
cloudwatch:GetMetricStatistics
cloudwatch:ListMetrics
ec2:DescribeTags

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "ec2:DescribeTags",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        }
    ]
}

일단 정책 생성누르고 json 으로 넣는다.

그리고 정책의 이름을 정해서 넣는다

사용권한

나는 ec2-monitoring-policy 로 대충 입력했다. 상황과 사용자에 따라 다르다.

이제 역할을 생성한다.

신뢰 할수있는 유형의 서비스에서 EC2를 선택한다.

미리 생성한 정책을 선택한다.

태그는 사실 대충 입력했다. 하지만 각각 사용자마다의 태그 규칙을 정하고 사용하는것이 좋다.

정상적으로 만들면 신뢰 정책 태그가 생성한 순으로 잘보일것이다.

하나라도 빠져있다면 이상한거다.

오늘의 대상이 되는 인스턴스의 OS는 ubuntu 와 amazon linux2 / contos 이다.

user data 에 사용할 스크립트다

amazon linux2 / contos7

#!/bin/bash
sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64 unzip
cd ~
curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
unzip CloudWatchMonitoringScripts-1.2.2.zip && \
rm CloudWatchMonitoringScripts-1.2.2.zip
echo "#disk metric" >> /etc/crontab
echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
systemctl restart crond

ubuntu 14 - 18

#!/bin/bash
sudo apt-get install unzip libwww-perl libdatetime-perl
cd ~
curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
unzip CloudWatchMonitoringScripts-1.2.2.zip && \
rm CloudWatchMonitoringScripts-1.2.2.zip
echo "#disk metric" >> /etc/crontab
echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
systemctl restart crond

위의 스크립트는 UserData 에 넣어주면 된다.

현재 스크립트는 주석처리되어 삽입까지만 되고 crontab 에서는 주석처리되어 돌지 않는다. 동작시키려면

echo "#*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab
echo "*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab

변경하고 crontab 을 재시작하자.

crontab 에 삽입되며, 5분마다 memory와 disk 사용량에 대한 매트릭을 CloudWatch 로 전송한다.

인스턴스 세부정보 구성에서 아까 생성한 역할을 부여하고, 사용자 데이터에서 위에 올려둔 스크립트를 붙여넣기 한다.

[root@ip-172-31-47-207 ~]# yum history
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
ID | Command line | Date and time | Action(s) | Altered
2 | install -y perl-Switch p | 2020-04-25 00:27 | Install | 50
1 | -t -y --exclude=kernel - | 2020-04-25 00:27 | Update | 1
history list

yum history를 보면 정상적으로 패키지 설치가 된게 보이고,

[root@ip-172-31-47-207 ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
#disk metric
*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --disk-space-util --disk-path=/ --from-cron

정상적으로 crontab에 스크립트도 들어간게 보인다.

그래서 CloudWatch 에서 모두 > linux 시스템 이라는 이름으로 사용자 매트릭이 생성된것이 보일것이다.

여기까지 되면 이제 인스턴스의 메모리와 디스크 모니터링이 가능해졌다.

aws 에서는 기본 매트릭으로 여러가지 모니터링 환경을 제공하는데 memory 와 disk 는 모니터링이 되지 않아 불편한 부분이 있었다.

-_-; 이 포스팅이 도움이 되길 바란다.!

aws-rds-readreplica-general_log

https://www.facebook.com/groups/awskrug/permalink/2404835746285102/

다음과 같은 질문이 올라왔다.
바로 생각난건 general_log.. 그래서 Master와 Readreplica 가 각각 다른 Parameter Group(이하 PG)를 가질수 있는지 확인해보기로 했다.

먼저 Readreplica 생성했다.

실제로 읽기복제본을 만들때는 파라메터 그룹을 수정할수 없다.

Master 의 PG를 그대로 사용한다.

이렇게 모두 생성된 Readreplica 를 수정을 눌러보면

데이터베이스 옵션에서 파라메터 그룹을 볼수있다.
그래서 나는 따로 PG를 만들어주고..general_log 도 켜줬다.

dynamic / static 으로 나뉘는데 적용유형이 dynamic이면 PG가 적용된상태에서 라이브로 적용된다. 디비의 재시작이 필요없다.

물론..PG를 변경하게 되면 RDS의 재시작이 필요하다.

그럼 1차 결론으로 마스터와 슬레이브는 생성시엔 같은 PG를 사용한다. PG는 마스터와 슬레이브는 다르게 사용하려면 수정해야한다.

현재구성은 마스터는 general_log를 사용하지 않고, 슬레이브만 사용한다. 그럼 슬레이브에서 제네럴 로그를 쌓는지 확인해 보자.

이상하게 적용이 안되서 보니..

보류중이면 말하지;

재시작 시켜서 적용해주고~

잘쌓인다..타임존이 이상하네? 그건 넘어가고..

마스터는 안쌓이는거 확인했고~

질문의 답은 확인할수 없지만..general_log 가 마스터와 슬레이브가 별개로 쌓이는 설정이 가능하고 슬레이브의 용량이 서비스에 영향을 미칠수있다.

정도로 결론 내리겠다.

급한 테스트였지만 결론을 내린다!

aws-sns-kms-cmk

aws 관리형키를 사용할 경우 sns 암호화를 하면 cloudwatch 에서 호출이 안된다....

작업 arn:aws:sns:ap-northeast-2:userid:sns_topic을(를) 실행하지 못했습니다. 수신 오류: 'null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 60c4ef-f3bb-4c89-98c8-67317fc18a)'

이런 에러가 발생한다. 이경우 CMK 를 이용해서 SNS 암호화를 해야한다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/cloudwatch-receive-sns-for-alarm-trigger/

다음 링크를 참조했다.

위와 같은 구성으로 생성하고 정책을 적용한다.

{
"Version": "2012-10-17",
"Id": "EMR-System-KeyPolicy",
"Statement": [
{
"Sid": "Allow access for Root User",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::userid:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrator",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::userid:root"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow access for Key User (SNS IAM User)",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::userid:root"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "Allow access for Key User (SNS Service Principal)",
"Effect": "Allow",
"Principal": {
"Service": [
"sns.amazonaws.com",
"cloudwatch.amazonaws.com"
]
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
}
]
}

userid 부분만 수정해주면 잘작동한다.

aws-s3-delete-mfa-enable

오늘은 s3 delete 를 mfa 로 제한하는 방법에 대해서 포스팅 해보겠다.

aws 에서 s3 버킷에 대한 삭제 제한을 해야 할때가 있다.

이경우에 root access key를 생성하여야 한다.

iam 대시보드에서 mfa 와 루트 엑세스키를 생성할수 있다.

보안자격증명 관리로 이동해서 진행한다. 과정은 간단하고 쉬우니 URL을 참고하자.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa.html - MFA 활성화

https://docs.aws.amazon.com/ko_kr/general/latest/gr/managing-aws-access-keys.html -access key 생성

생성한 키로 aws cli 를 사용가능하도록 설정한다

/root/.aws/credentials 다음 위치다.

access key를 넣고 mfa 를 확인해보자

root@ip-10-0-0-12 ~]# aws iam list-virtual-mfa-devices
An error occurred (AccessDenied) when calling the ListVirtualMFADevices operation: User: arn:aws:sts:: usernumber :assumed-role/AmazonEC2RoleForSSM/i-052ebb4fb1eade551 is not authorized to perform: iam:ListVirtualMFADevices on resource: arn:aws:iam:: usernumber :mfa/

루트권한이 아닐경우 위와같은 에러가 난다 administrator 계정일경우 ListVirtualMFADevices 정책이 부여되어있어 에러가 발생하지 않을것이다. 하지만 mfa는 사용할수 없을것이라 root key여야 한다.

명령어가 정상적으로 작동하면 아래와 같이 반환된다.

{
"VirtualMFADevices": [
{
"SerialNumber": "arn:aws:iam:: usernumber :mfa/root-account-mfa-device",
"EnableDate": "2019-10-28T01:06:07Z",
"User": {
"PasswordLastUsed": "2020-03-18T00:27:36Z",
"CreateDate": "2019-07-29T13:23:03Z",
"UserId": "1",
"Arn": "arn:aws:iam:: usernumber :root"
}
}
]
}

나는 root 계정에만 mfa 를 활성화 하였기에 루트 계정에서 사용하는 mfa 만 뜬것이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning --bucket linuxer-data --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam::usernumber:mfa/root-account-mfa-device <016432>"
An error occurred (InvalidRequest) when calling the PutBucketVersioning operation: DevPay and Mfa are mutually exclusive authorization methods.

linuxer-data 라는 버킷을 versioning 을 켜고 MFADelete 를 활성화 한다는 명령어인데 에러가 발생한것이다. 이때 root 계정이 아니라서 발생한 에러이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning --bucket linuxer-data --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam:: usernumber:mfa/root-account-mfa-device 926220"

정상적으로 root access key일 경우에는 그냥 명령어가 떨어진다.

root@ip-10-0-0-12 ~]# aws s3api get-bucket-versioning --bucket linuxer-data
{
"Status": "Enabled",
"MFADelete": "Enabled"
}

이후에 다음과 같이 aws s3api get-bucket-versioning --bucket linuxer-data 명령어로 정상적으로 설정이 됬는지 확인이 가능하다.