T101-AWS-To-SLACK-Noti - EventBridge

이제야 블로그가 손에 잡혀서 오랜만에 글을 쓰기위해 책상앞에 앉았다. 이게다 내 게으름 때문이다.

맨날 이 뻔한 핑계를 치면서 한번 웃고야 말았다.

이번에 쓸 블로깅은 T101에서 한번 발표한 적인 있는 내용이다.

이 포스팅에선 EventBridge와 CloudTrail을 집중적으로 다룬다.

https://nyyang.tistory.com/126 이블로그를 보고 작업을 시작했다.

먼저 시작하기전에 EventBridge Bus 규칙에서 Trail에서 패턴을 감지하기위해선 이벤트버스는 무조건 Default여야한다. 다른 버스에 만들면 버스 지나간 다음 손 흔들어야 한다. 패턴을 감지할수 없다는 이야기다.

골자는 이렇다.

CloudTrail 에서 발생하는 이벤트를 EventBridge 는 특정 패턴을 감지해서 이벤트를 발생시킬수 있다.

아래 예가 그렇다.

{
  "source": ["aws.iam", "aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["iam.amazonaws.com", "ec2.amazonaws.com"],
    "eventName": ["AttachGroupPolicy", "AttachRolePolicy", "AttachUserPolicy", "ChangePassword", "CreateAccessKey", "CreateGroup", "CreatePolicy", "CreateRole", "CreateUser", "DeleteAccessKey", "DeleteGroup", "DeleteGroupPolicy", "DeletePolicy", "DeleteRole", "DeleteRolePolicy", "DeleteUser", "DeleteUserPolicy", "DetachGroupPolicy", "DetachRolePolicy", "DetachUserPolicy", "PutGroupPolicy", "PutRolePolicy", "PutUserPolicy", "AuthorizeSecurityGroupIngress", "AuthorizeSecurityGroupEgress", "RevokeSecurityGroupIngress", "RevokeSecurityGroupEgress"]
  }
}

AWS ec2와 iam에서 발생하는 특정 패턴을 감지하여 이벤트를 발생시키는것이다.

여기에서 내가 굉장히 많은시간 고민을했다. 이유는 패턴 때문이다. 내가 감지하고 싶은 패턴은 AWSConsoleLogin 이다. 이 API가 속하는 source 와 detail-type 이 정리된 곳이 없었기 때문이다. 또한 EventBridge에서 템플릿으로 제공하는 이벤트 패턴으로 테스트했을 땐 잘되지 않았다. 고민했던 부분은 총 3가지 였다.

첫번째로 이벤트 패턴을 감지하기위해서 일반적으로 source 와 detail-type 을 지정해줘야했는데 모든예제는 Source 를 무조건 사용하도록 되어있었다. EventBridge 에선 3가지 이벤트 패턴을 사용할수 있는데 그중 하나만 사용해도 문제가 없다.
source / detail-type / detail 이렇게 세가지이다.

두번째 문제는 Trail에 찍히는 로그와 EventBridge 에 전달되는 이벤트의 내용이 다르다.

{
'version':'0',
'id':'1',
'detail-type':'AWS Console Sign In via CloudTrail',
'source':'aws.signin',
'account':'1',
'time':'2022-12-17T01:09:08Z',
'region':'ap-northeast-2',
'resources':[
],
'detail':{
'eventVersion':'1.08',
'userIdentity':{
'type':'IAMUser',
'principalId':'1',
'accountId':'1',
'accessKeyId':'',
'userName':'1'
},
'eventTime':'2022-12-17T01:09:08Z',
'eventSource':'signin.amazonaws.com',
'eventName':'CheckMfa',
'awsRegion':'ap-northeast-2',
'sourceIPAddress':'58.227.0.134',
'userAgent':'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/106.0.5249.114 Safari/537.36', 'requestParameters':None,
'responseElements':{
'CheckMfa':'Success'
},
'additionalEventData':{
'MfaType':'Virtual MFA'
},
'eventID':'1',
'readOnly':False,
'eventType':'AwsConsoleSignIn',
'managementEvent':True,
'recipientAccountId':'1',
'eventCategory':'Management',
'tlsDetails':{
'tlsVersion':'TLSv1.2',
'cipherSuite':'ECDHE-RSA-AES128-GCM-SHA256',
'clientProvidedHostHeader':'ap-northeast-2.signin.aws.amazon.com'
}
}
}
{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "1",
        "arn": "arn:aws:iam::1:",
        "accountId": "1",
        "accessKeyId": ""
    },
    "eventTime": "2022-12-17T02:29:28Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "ap-northeast-2",
    "sourceIPAddress": "58.227.0.134",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.5249.207 Safari/537.36",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Success"
    },
    "additionalEventData": {
        "LoginTo": "https://ap-northeast-2.console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&region=ap-northeast-2&state=hashArgsFromTB_ap-northeast-2_b149694953e40e5b",
        "MobileVersion": "No",
        "MFAIdentifier": "arn:aws:iam::1:mfa/root-account-mfa-device",
        "MFAUsed": "Yes"
    },
    "eventID": "1",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "recipientAccountId": "1",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "1",
        "clientProvidedHostHeader": "signin.aws.amazon.com"
    }
}

민감 정보는 지웠다. 이렇게 두가지 내용이 다르다. 처음에 Trail Log를 보고서 패턴을 작성하다가 놀랐다. 그리고 이 이벤트를 보려면 이벤트 브릿지에선 넘어온 데이터를 볼수없다. 이벤트 카운트 뿐이다.

세번째는 리전에 대한 이야기다.

우리의 Console 로그인은 리전기반이다. 이게 나를 오랜시간 고민하게 하고 괴롭혔다.

Trail은 글로벌 서비스 이벤트가 있다.

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-global-service-events

이 글로벌 서비스중 sts에 우리는 주목해야한다. 로그인할때 STS 를 호출하기 때문이다. 그럼 STS 를 설명하기 전에 Console Login 부터 알아야한다.

로그인을 시도할때 우리는 AWS Console 을 통해 그냥 로그인한다고 생각하지만, 그렇지 않다. AWS Console은 로그인 할때 이런 URL 을 가지고 있다.

https://signin.aws.amazon.com/signin?redirect_uri=https%3A%2F%2Fconsole.aws.amazon.com%2Fconsole%2Fhome%3FhashArgs%3D%2523%26isauthcode%3Dtrue%26state%3DhashArgsFromTB_ap-northeast-1_6b240714978b3994&client_id=arn%3Aaws%3Asignin%3A%3A%3Aconsole%2Fcanvas&forceMobileApp=0&code_challenge=U8A4YkTPRIIvi-8Gj7-tIx4RB_PR9IT-4fVs7diVUoc&code_challenge_method=SHA-256

이 URL로 로그인하면 Console Login log는 ap-northeast-1 로 연결된다. 그러니까 우리는 도쿄로 연결되는 로그인때문에 이것을 재대로 트래킹 할수 없다는 이야기다. 놓치는 로그인들을 해결하고 싶었다.

글로벌 서비스를 추적하면 도쿄로 연결되는 로그인을 추적할수 있을까?

정답은 "그렇다" 하지만 문제가 생길수도 있다.

슬프게도 글로벌서비스 추적이란 그냥 글로벌 엔드포인트를 이용하면 그 로그가 us-east-1 에 쌓일 뿐 모든 리전의 STS로그가 글로벌서비스 추적에 쌓이는건 아니다.

그렇기에 로그인 추적은 어렵다. 그렇다고 해서 아주 못하는것은 아니다. 로그인은 반드시 STS를 호출한다. 극단적으로 가기로 했다.

IAM > 계정설정 > 엔드포인트

위에서 로그인 URL에 도쿄리전으로 파라미터가 들어가있는데 그 대로 로그인 해보겠다. 그전에 나의 계정에선 도쿄의 STS 엔드포인트를 비활성화하였다.

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "1",
        "principalId": "1",
        "arn": "arn:aws:iam::1:1",
        "accountId": "1",
        "accessKeyId": ""
    },
    "eventTime": "2022-12-17T04:02:18Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Success"
    },
    "additionalEventData": {
        "LoginTo": "https://console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&state=hashArgsFromTB_ap-northeast-1_6b240714978b3994",
        "MobileVersion": "No",
        "MFAIdentifier": "arn:aws:iam::1:mfa/1-account-mfa-device",
        "MFAUsed": "Yes"
    },
    "eventID": "1",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "recipientAccountId": "1",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "signin.aws.amazon.com"
    }
}

로그 보면 이렇다. LoginTo 에서는 ap-northeast-1 로 로그인했으나, 실제 리전은 us-east-1 로 연결되었다. 글로벌서비스 STS로 연결된것이다. 아마 가까운 리전엔드포인트를 제공해주는것으로 보는데 실제로는 잘모른다.

이렇게 세가지의 고민을 끝내고 Trail의 추적을 생성하였는데, 문제를 찾을수 있었다.

우리는 필연적으로 버지니아 북부와 실제사용리전에서 Trail의 추적을 생성해야하는데 이걸 콘솔에선 생성해선 안된다.

이전에는 Trail 에서는 콘솔에서 다중추적의 온오프를 옵션으로 제공했는데 이젠 그렇지 않다. 이전의 기억만 믿고 진행했다가 다중추적이 여러군데 생성되었다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/remove-duplicate-cloudtrail-events/

다중추적의 중복은 비용이 발생한다.

PaidEventsRecorded 이 지표가 증가한다면 다중추적이 여러개가 생성된거다.

그렇기에 추적을 생성할땐 주요사용리전에만 다중리전 추적을 생성하고 버지니아 북부에서는 글로벌서비스 추적만 활성화 해야한다. 그러면 비용이 추가되지 않는다.

글로벌 서비스 추적을 만들려면 AWSCLI를 이용해서 만들어야 한다.

# aws cloudtrail update-trail --name my-trail --no-include-global-service-events

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-update-trail.html#cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-examples-gses

EventBridge 와 Trail에 대한 삽질기를 이렇게 정리해둔다.

조금이나마 도움이 되길 빈다.

클라우드를 시작하는 사람을 위한 안내서

시작하는 사람을 위한 안내서를 작성하고 싶었는데, 좀 늦었다.

매번 하는 말이지만 내 게으름 때문이다.
꼭 누군가에게 도움이 되는 글을 작성하고 싶었는데 그게 바로 오늘인 듯 하다.

클라우드를 하려면 먼저 계정을 생성하여야 한다.

계정을 생성 하였는가? 축하한다. 드디어 클라우드에 입문한 셈이다.

Twitter 上的 DRX|KNEE:"일리단님의 말이 떠오르는 어제 하루였다 아직 준비가 안됐다  https://t.co/QjLPBqUo64" / Twitter

클라우드는 보통 웹 콘솔로 처음 접하게 된다.
CSP 에서 제공하는 웹사이트에 가입을 했다면 뭘 해야 할지 고민이 될 것이다.

모든 설명은 AWS를 기준으로 작성된다.

걱정 마라.

처음 가입하면 뭘해야 할지 바로 알려주겠다.

  1. MFA
  2. Budget
  3. Root 계정 봉인

3가지의 조치가 왜필요한지 이야기해 보겠다.

먼저 MFA를 하지 않아 털리게된다면 공격자는 AWS Console을 편하게 이용할 수 있다. 걸리기 전까지 컴퓨팅을 마음껏 쓸수 있는것이다. 이렇게 털린 계정은 전적으로 사용자 과실이다.

길바닥에 떨어진 지갑은 일반적인 사회라면 경찰서에 가져다주고 주인을 찾아 주겠지만, 그렇지 않은 경우도 많다. 그 길바닥에 떨어진 지갑이 바로 당신의 클라우드 계정이다. 작게는 수백 크게는 수억원까지 비용이 발생할수 있다. 이러한 대 참사를 막기위한 조치이다.

루트계정의 MFA를 설정하여 접근을 막고, 예산을 설정하여 비용이 초과되면 알럿을 받고, 루트계정을 사용하지 않는 방법과 역할 전환을 이용하여 계정의 보안을 강화하는 방법이 가장 적절한 방법인것이다. 여기에 리소스가 생성되면 알림을 받는것도 좋고, 사용하지 않는 태그를 기반으로 리소스가 생성되면 자동으로 삭제하는 방식도 좋다. 이런 여러가지 방식들이 있지만 가장 기본적인 방법이 위에서 제시한 세가지의 방법이다. 그럼 바로 시작하겠다.

MFA

라온클님 역작

MFA를 생성하기 전에 먼저 물어볼것이 있다. 혹시 메일주소가 다른 계정이나, 패스워드가 겹치진 않는가?
이건 굉장히 중요한 문제다. 계정이 다른 아이디 나 패스워드가 겹친다면 삭제하고 처음부터 다시 만들자. 자주사용하는 아이디와 패스워드는 유출될 확률이 높다. 물론 MFA를 사용하면 안전하다. 하지만 언제나 방심하는 순간 문제가 발생한다. 그러니, 콘솔용 메일주소는 별도로 사용하는것이 좋다.

이제 그럼 MFA를 걸어보자.

IAM 서비스로 이동한다 Root 계정의 MFA도 IAM에서 설정할수 있다.

MFA는 사용하지 않으면 IAM 대시보드에 바로 경고가 떠있다. MFA 를 생성하자.

가상 MFA 디바이스를 선택한다.

MFA는 여러 어플이 있는데 나는 MS에서 만든 어플을 선호한다. 온라인백업 기능을 지원한다. QR코드 표시 누르고 그이미지를 백업해두어도 나중에 MFA를 다시추가 가능하다. 하지만 보안이 매우 좋지않음으로 추천하지 않는 방법이다. 보관하려면 압축후 비밀번호를 걸어서 보관하라.

연속된 MFA를 입력하라는건 6자리를 두번 입력해야한다.

두번 입력하면 MFA 설정이 완료된다.

이 쉬운 과정이 일단 그대의 콘솔이 털리는걸 막아주는거다. 로그인이 불편하더라도 꼭 사용하길 바란다.

Budget

Budget 설정은 결제 대시보드에 있다.

예산은 설정하면 알럿이 온다. 예산을 작성하도록 하자.

예산 관련 옵션 들은 FinOps를 위한 여러가지 기능을 제공하는데 우리는 그냥 비용 예산을 작성하면 된다.

일별로 변경후 5$를 설정한다 프리티어에서 하루 5$를 넘으면 대참사다. 한번 만들고 알럿이 귀찮으면 서서히 조정하자.

이메일 수신자에 받고싶은 이메일을 넣어도 되고 SNS 에 주제와, 구독을 생성하여 SMS등으로 받을수도 있으며, Chatbot Alerts를 이용하여 슬랙등 여러 Bot으로 알럿을 받을수 있다. 이메일은 무료고 뒤의 두가지는 비용이 발생할수 있으므로 메일로 받고 관리해야하는 서비스라면 봇이나 SNS를 이용하길 바란다.

이후 예산을 작성하면 이제 일정이상 비용이 넘으면 알럿이 발생한다.

벌써 두가지의 조치를 했다. 남은 두가지만 하면된다.

Root 계정 봉인

Root 계정은 많은 참사를 불러 온다. 이 대 참사를 막기위한 방법이 있다. Root 계정에 MFA를 걸어서 안전하다고 생각할지 모르나, 문제는 언제 어디서 발생할지 모른다. 그렇기에, Root 계정을 봉인하는것을 추천한다.

Root 계정을 사용하지 않고 어떻게 AWS를 안전하게 사용하는지 알려주겠다.

이 방법에는 두가지가 필요하다.

  1. IAM User
  2. IAM Role

먼저 로그인 통로가 될 User를 생성한다. IAM에서 사용자를 추가하면 된다.

IAM 서비스로 이동하고 사용자탭으로 이동해서 사용자 추가를 누른다.

액세스키 방식이 아닌 AWS 관리 콘솔 액세스를 선택한다.

이 계정엔 아무 권한도 주지 않을 것이다.

이렇게 나와야한다. 계정을 생성 완료 했다면 계정의 요약에서 보안 자격 증명을 눌러보자.

콘솔 로그인 링크로 로그인하기 전에 먼저해야할 것이 있다.

MFA다.(궁서체다 매우진지하므로 추가해라.)

MFA는 최대한 활용한다.

이상태가 되면된다. 이제 요약에서 보여주는 콘솔링크로 AWS를 이용한다. 한번 로그인해보시라.

이 아무 권한도 없는 계정은 이제 방파제가 되어 로그인을 제어해줄것이다. 권한이 없는 계정으로 뭘하는지 궁금할것이다. 이때 필요한것이 역할 전환이다. 그럼 IAM Role을 생성하자.

IAM에서 역할탭으로 이동한다. 역할 만들기를 누르자.

다음과 같이 체크해준다.

권한은 여기서 최대 권한을 주지만, 사용자에 맞게 권한을 주는것이 더 적절하다.

역할을 생성하고 이 역할을 사용할수 있도록 수정을 해야한다.

여기서 "arn:aws:iam::00000000000:root" 를 수정해야한다. 수정할 값은 아까만든 계정의 ARN이다. 사용자탭으로 이동해서 계정을 눌러보면

다음과 같이 ARN을 확인할수 있다. 하지만 ARN은 규칙이 있어서 보지않고 그냥 수정해도 된다. 다시 역할로 돌아와서

신뢰관계를 수정하면 이제 생성했던 계정이 이 역할을 사용할수있다. 덤으로 MFA가 활성화 되어야지 만 이 역할을 사용할수 있다.

그럼이제 이 역할을 사용하는 방법은 바로전에 생성한 계정으로 로그인하고, 생성한 역할의 요약 탭에서 보여주는 역할전환 링크를 통해 역할을 전환한다.

다음메뉴에서 역할의 세션지속기간을 설정할수 있다. 역할전환 링크로 이동하면

다음과 같은 화면을 마주하게 되고, 역할 전환을 누르면 이제 IAM 사용자가 역할전환을 이용하여 AdministratorAccess 권한을 승계받은거다. 이제 해커는 MFA를 획득 하더라도 역할전환을 하지 못하면 어떠한 행위도 할 수 없다.

일반적으로 이 방식은 타 계정에서 어카운트를 생성하지 않고 로그인할때 사용하는 방식이다. 혹시 관리계정이 있다면 그관리계정에서 역할전환을 하는것이 더욱 권장되는 방식이다.

이외에도

https://aws.amazon.com/ko/premiumsupport/knowledge-center/config-email-resource-created/

AWS Config 서비스를 이용한 리소스 생성시 추적기능이 있다. 이 부분은 나중에 자세하게 다루어 볼까한다.

SNS EventBridge Config 등의 서비스를 사용하기때문이다.

이 글을 적게된 이유는 최근 여러 커뮤니티를 달군 3억 과금 때문이다. 해킹을 막기 위해선 불편함을 감수해야한다.

편하려다 피눈물 날테니 조심하자.

AWS-apple-MAC-instance

오오오오오오!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

macOS Catalina 10.15.7 버전을 쓸수있다.

뜨든... 인스턴스 유형은 베어 메탈뿐.. 그렇다고 해서 내가 안만들순없지 가즈아!!!!!

-_-;

전용 호스트가 필요하다....근데 전용 호스트 갯수는 not support 상태다 service quotas를 늘려야한다.

일단 바로 요청 근데 금방 안되나? 아마 지금 전세계에서 생성 중일거다..증가가 되면 바로 더 진행해 보겠다.

Maximum number of running dedicated mac1 hosts.

보류에서 할당량이 요청됨으로 변경됬다.

그리고 오늘 (12월2일) 요청은 허락되지 않고 기본 제공량이 3으로 변경됬다.

일단 전용호스트를 만들고, 인스턴스를 생성했다.

한방에 인스턴스가 전용호스트를 다 차지한다.

ssh -i linuxer.pem ec2-user@IP

.

ssh는 동일하게 ec2-user 계정으로 접근한다.

SSM을 이용한접근도 가능하다.

먼저 vnc 로 접근하는게 목적이므로brew로 vnc server 를 셋팅해야한다.

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -allUsers -privs -all
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvnclegacy -vnclegacy yes 
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvncpw -vncpw supersecret
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate

https://gist.github.com/nateware/3915757

귀찮아서 이페이지 복붙했다. 위 명령어를 치면 vnc 가활성화 된다.

sudo dscl . -passwd /Users/ec2-user

.

명령어로 ec2-user의 패스워드를 설정한다.

그리고 VNC viewer 로 접속한다.

길고긴 여정을 지나 드디어.. 접속했다.

북미라 너무 느리다..-_-; VNC로 접속하기를 마무리한다.

AWS-managed-MQ-RabbitMQ-VPC-review

관리형 RabbitMQ가 나왔다.

짤방백업봇 on Twitter: "놀라울 만큼, 그 누구도 관심을 주지 않았다.… "

놀랄만큼 아무도 관심을 가지지 않았다. 안타깝....

그래서 내가 관심을 주기로 했다.

RabbitMQ VPC 설정을 확인해 보자!

생성모드는 단일과 클러스터 두가지가 있다. 단일구성부터 보자

퍼블릭엑세스는 VPC 내에 속하며 서브넷을 선택할수 있다.

프라이빗 엑세스를 선택해야 보안그룹를 선택할수 있다. 이게 가장 큰 차이점.
그리고 한번 퍼블릭으로 생성한 MQ는 영원히 퍼블릭이다. 프라이빗은 영원히 프라이빗..

그리고 이 포스팅을 시작하게 된 가장 큰 계기..

클러스터 모드에서 퍼블릭 엑세스를 사용한 RabbitMQ 는 VPC 외부에 만들어진다.

그냥 VPC 컨트롤하는 설정이 없다.

프라이빗으로 설정하면 VPC에 생성...

같은 RabbitMQ임에도 VPC 내부 / 외부 / 보안그룹 유 /무 접근제어 방식이 다른것이 인상적이었다. RDS와 같이 VPC 내부에 만들어져서 편리하게 전환할 수 있는 방식이 아니기에 생성 초기부터 명확하게 아키텍처를 구상해야 하는 것이다.

RabbitMQ의 VPC 설정은 변경이 불가능하다!!

읽어주셔서 감사합니다!

AWS-Certified-SysOps-Administrator-Associate-review

aws sysops 시험을 봤다. 내가 본 시험유형은 SOA-C01유형이다.

사실 Associate 시험이라 연습시험도 안봤고 그냥 걱정이 크게 없었다.
그런데 시험이 다가올수록 걱정이 점점 커졌다.

SA같은 경우에는 설계를 중시하는데 SOA같은 경우에는 운영과 관리자의 입장에서 바라본 AWS의 사용법을 물어보기에 중점적인 부분은 SAA보다 깊이가 깊었다. 특히 내가 어려웠던 부분은 cloudformation 이라던가 잘사용하지 않았던 chef 같은 부분이었다.

그 이외에는 사실 현재 가지고 있던 지식으로 해볼만하다 생각이 들었다.

-시험시작 후 내가 좀 공부가 부족했다는 생각을 많이했다.

SOA는 깊다. 어떤 문제는 PRO에 가까이 걸쳐있는 부분도 있다고 생각되는 문제들이 한두 문제 있었다. 실무자의 입장에서 도움되는 내용이 많았다.

기본공부는 역시

jayendrapatil 아저씨의 블로그를 시작으로 공부했다.

아저씨 최고...

AWS Certified SysOps Administrator – Associate

이 다음 시험은 Developer 다. 모두의 건승을!