K . N . H :: BLOG

AWS 자격증을 준비하면서 개념 파악을 위해 AWS Fargate와 ECS를 사용해 보고자 AWS Docs를 보면서 따라하던 중

ECR 레포지토리를 생성하고 인증 부분에서 아래와 같은 에러를 만났습니다.

  에러메시지 내용

error during connect: this error may indicate that the docker daemon is not running: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/auth": open //./pipe/docker_engine: The system cannot find the file specified.

  원인

Windows Docker Desktop이 정상적으로 실행되지 않아서 그렇습니다.

제 경우는 Hyper-V 관련 에러 메시지가 출력되면서 Docker Desktop이 정상적으로 동작하지 않고 있었습니다.

혹시 Windows Docker Desktop이 실행될 때 Hyper-V 관련 에러가 나온다면 아래 URL을 참고하면 바로 해결 가능합니다.

Powershell을 통해 명령어 한 줄 넣으니 바로 해결 되었습니다.

https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v

  해결책

Windows Docker Desktop이 아래 사진과 같이 정상적으로 실행되면 에러 원인도 해결됩니다.

[인증 성공!]

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

caul334@gmail.com

AWS EC2 인스턴스 비용에 관해 고민해보신 분이라면 RI(Reserved Instances) 또는 Savings Plans에 대해 들어보셨을 겁니다.

하지만 이 둘의 차이점을 알지 못하는 분들이 많아 특징을 간단히 정리 후 차이점을 공유드리겠습니다.

RI (Rserved Instances)

• 인스턴스 패밀리, 크기, 지역, 운영체제, 테넌시가 일치해야 함
  • 단, 크기가 다른 경우 정규화 인자만큼 적용
  • 참고) 패밀리 : (ex. t2, m5), 크기 : (ex. medium, large), 테넌시 : (전용 호스트, 전용 인스턴스)
• 사용량 종료 시 갱신되지 않으며 온디맨드 요금 부과

* 정규화 인자만큼 적용되는 개념은 복잡하기 때문에 여기서 설명드리지 않겠습니다. 궁금하신분은 아래 링크를 달아드릴테니 확인하시면 됩니다.

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/apply_ri.html#ri-normalization-factor

Savings Plans

• 인스턴스 패밀리, 크기, OS, 테넌시, 지역 상관없음
• AWS Fargate, Lambda에도 적용 가능
• Savings Plans 종류(3가지)에 따라 최대 64%~72% 절약 가능
• 사용량 종료 시 EventBridge를 통해 알림 가능

Savings Plans을 PC방에 비유하자면 정액권을 끊으면 그 금액 안에서 라면도 시켜먹고 PC방도 이용할 수 있는 개념인데 반해 RI는 PC방에 대한 사용권만 이용할 수 있는 것과 같습니다.

AWS에서는 RI보다는 Savings Plans를 더욱 권장하는 느낌입니다.

Savings Plans은 3종류로 나뉩니다.

Savings Plans 종류(3가지) 및 차이

Compute Savings Plans : 가장 유연한 요금제 - 최대 66% 할인

• 지역, 인스턴스 패밀리, 크기, 운영체제, 테넌시 관계 없이 자동 적용 가능
• Fargate 및 Lambda 사용량에 적용

EC2 Instance Savings Plans : 특정 지역의 인스턴스만 할인 - 최대 72% 할인

• 인스턴스 패밀리, 크기, 운영체제, 테넌시 관계 없이 자동 적용 가능

SageMaker Savings Plans - 최대 64% 할인

• 지역, 인스턴스 패밀리, 크기, 구성 요소(예: 노트북, 교육 등)에 관계 없이 자동 적용 가능

RI를 구매했는데 Savings Plans 구매를 고민하시는 분이라면 아래 사용량 적용 우선순위를 참고해주세요

사용량 적용 우선순위

1. RI vs Savings Plans : RI가 우선 적용
2. EC2 Instance Savings Plans vs Compute Savings Plans : EC2 Instance Savings Plans
3. 소유자 계정 Savings Plan vs 다른 계정 Savings Plan : 소유자 계정이 우선 적용

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

caul334@gmail.com

AWS를 운영하면서 Root 계정과 IAM계정의 대표적인 차이는 "결제정보를 확인할 수 있냐 없냐" 입니다.

Root 계정과 IAM계정의 대표적인 차이점은 아래 글에서 확인이 가능합니다. 

https://betterinvesting.tistory.com/307

일반적으로 AWS 기본 설정에서는 아래 사진과 같이 IAM 계정에서 청구서(결제)에 대한 정보 확인이 불가능합니다.

따라서 청구서 정보를 확인하기 위해서는 Root 계정에서만 확인 가능하다는 불편함이 존재합니다.

하지만 IAM 계정이라 하더라도 정책 설정을 변경하면 청구서 정보를 확인할 수 있습니다.

해당 정보는 AWS IAM(Identity and Access Management)에 관한 Docs에서 확인 하였습니다.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/tutorial_billing.html

  청구서 확인을 위한 IAM 계정 설정 변경 방법

1. Root 계정으로 로그인하여 결제 정보에 대한 IAM 사용자 엑세스를 활성화 해줍니다.

방법 : 자신의 계정명 (클릭) > 계정 > 결제 정보에 대한 IAM 사용자 및 역할 엑세스 > 편집 > IAM 엑세스 활성화 (선택) > 업데이트 (클릭)

그러면 결제 정보에 대한 IAM 사용자/역할 엑세스가 활성화되었습니다. 라는 문구를 확인할 수 있습니다.

2. (기존에 IAM 사용자가 있다는 전제) IAM 사용자에게 billing 권한을 부여

IAM 계정이 없으시다면 만드셔서 테스트 하시면 되고 있다면 아래 방법대로 그대로 따라하면 됩니다.

방법 : IAM > (청구서를 보기 위한) 사용자 또는 사용자 그룹 > 선택 > 권한 > 권한 추가 > 정책연결 > billing 검색 후 권한 추가

참고로 아래 사진은 보여드리기 위해 두 개의 권한(Billing, AWSBillingReadOnlyAccess)을 모두 추가한 상태이고 실제 사용을 위해서는 Billing 또는 AWSBillingReadOnlyAccess 두개의 권한 중 하나만 선택하시면 됩니다.

저는 안전하게 이용하기 위해 최소 권한인 AWSBillingReadOnlyAccess 권한을 추가했습니다.

3. 이제 다시 IAM 계정에 로그인 하여 청구서를 확인해 보니 아래 사진과 같이 결제 정보를 확인할 수 있습니다.

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

caul334@gmail.com

AWS CloudWatch의 경보 테스트를 하기 위해

Linux의 CPU, Memory의 과부화 테스트 도구인 Stress 툴을 설치하였습니다.

설치를 위해 설치 명령어를 검색해보니 모든 블로그들이 아래와 같은 2개의 명령어를 입력하라고 나오더라구요?

그런데 stress 툴은 알겠는데 epel이 뭐지? 라는 생각이 들어서 검색해보니 epel은 Fedora에서 따로 패키지를 제공하는 패키지 저장소입니다.

삼성 몇몇 앱들이 구글 앱 스토어에서 앱을 다운받는게 아닌 갤럭시 스토어에서 다운받는 것과 같은 개념이라고 이해하시면 될 것 같습니다.

저는 남들과는 다르게 하기 위해 조언을 따르지 않고 바로 stress 툴을 설치 시도 해봤습니다.

역시 경험자들의 조언은 무시하면 안되는 것인가...

그래서 저 역시 epel-release 패키지 설치 명령어를 입력하였습니다.

그런데 왠 걸? 오류가 뜨는데... 

오류 메시지를 확인해보니 Amazon Linux는 다른 명령어를 쳐야 되는 것이였습니다.
그래서 안내에 따라 아래의 명령어를 쳐봤습니다.

설치 성공!

Amazon Linux를 사용하시는 분들은 아래의 명령어 2줄을 입력해주시면

쉽고 빠르게 설치가 가능합니다.

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

클라우드 Managed 서비스 관련 문의 : caul334@gmail.com

온프레미스 -> 클라우드로 가야되는 상황에는 데이터 마이그레이션(Data Migration)이 반드시 필요합니다.

하지만 데이터 마이그레이션은 꼭 온프레미스 -> 클라우드 방향일 필요는 없습니다.

Data Migration은 클라우드 환경에서 서비스를 운영하다보면 OS 패치와 같은 상황에서도 필요할 때가 많이 있습니다.

AWS 서비스를 이용한 데이터 마이그레이션 방법은 추후 포스팅으로 소개해드리겠습니다.

  Linux Data Migration (데이터 마이그레이션)

  Linux 명령어

nohup은 없어도 되는 명령어이지만 세션이 끊어져도 계속 마이그레이션을 원한다면 붙이는게 좋습니다.

  실습

1) 2번(Destination) 서버에 /var/www 경로를 봐보면 현재 html 폴더가 없습니다.

2) 1번(Source) 서버에서 데이터 마이그레이션으로 /var/www/html 폴더 전체를 복사 하겠습니다.

* rsync 명령어를 사용하기 위해선 1번에서 2번 서버로 SSH 접속이 허용되어야 합니다.

3) 2번(Destination) 서버에 /var/www 경로를 확인하보면 html 폴더가 생성 되어 있으며 내부 파일 또한 동일하여 Migration이 정상적으로 되었음을 확인할 수 있습니다.

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

클라우드 Managed 서비스 관련 문의 : caul334@gmail.com

AWS 계정 관리에 대한 IAM Root 계정에 대한 Best Practice 찾아 보면 Root 계정을 만들면 MFA 2단계 인증을 설정한 후 Root 계정을 사용하지 말고 IAM 계정에 Admin 권한을 부여하여 IAM 계정을 사용하라고 합니다.

Root 사용자에 대한 더욱 상세한 Best Practice는 아래 URL에서 확인 가능합니다.

https://docs.aws.amazon.com/ko_kr/accounts/latest/reference/best-practices-root-user.html

AWS를 처음 접하는 분이시라면 같은 Admin 같은데 무슨 차이가 있지? 라는 생각이 듭니다.

아래 그림과 같이 권한 정책만 봐도 모든 Resource에 대해 허용 되어 있는데 말이죠

하지만 IAM에서 생성한 Administator권한의 계정과 Root 계정은 분명히 차이가 있습니다.

Root 계정에서만 수행 할 수 있는 일은 다음과 같습니다.

• AWS 계정 설정 변경 (계정 이름/이메일 주소/Root 사용자 패스워드 변경/Root 사용자 Access Key 설정)
• Billing and Cost Management 콘솔 접근
• AWS 계정 정지

Admin 기능을 부여한 IAM 사용자로도 위 작업은 불가능합니다. 위 작업을 수행해야 할 때는 반드시 루트 사용자로 로그인해서 설정 변경이나 신청을 해야 합니다.

계정 설정 변경이나 계정 정지를 할 일은 별로 없기에 청구서(Billing) 정보를 확인할 수 없는게 가장 클 것 같네요.

Root 계정만 수행할 수 있는 작업에 대해 더욱 상세히 알고싶은 분들은 아래 링크에서 확인 가능합니다.

https://docs.aws.amazon.com/ko_kr/accounts/latest/reference/root-user-tasks.html

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

클라우드 Managed 서비스 관련 문의 : caul334@gmail.com

AWS tool for PowerShell을 설치하는 방법 공유 드립니다.

Step 1. 가장 먼저 관리자 권한으로 powershell을 실행해야 합니다

Step 2. 백신이 실행중이라면 실시간 검사 모드를 꺼야합니다

저 같은 경우 노트북에서 진행한 결과 백신에서 설치 파일을 차단하여 정상 설치가 되지 않았습니다

Step 3. 설치 명령어 입력

PS> Install-Module -Name AWSPowerShell

설치 시간은 생각보다 오래걸립니다. 약 10~20분 정도의 여유를 가지고 기다리시면 설치가 완료됩니다.

Step 4. 설치 확인 명령어 입력

PS> Get-AWSPowerShellVersion

설치가 완료되면 버전확인가 같은 명령어로 설치 확인을 진행할 수 있습니다.

아래 이미지와 같이 버전 정보가 잘 나타나면 정상 설치가 된것입니다.

더욱 자세한 사항 또는 다른 설치 방법은 아래 AWS Tools for PowerShell 페이지에 나와있습니다.

URL : https://docs.aws.amazon.com/ko_kr/powershell/latest/userguide/pstools-getting-set-up-windows.html

내용이 유용하셨다면 좋아요&댓글 부탁드립니다.
이 블로그를 이끌어갈 수 있는 강력한 힘입니다!

caul334@gmail.com