끄적이는 보송

이 번 포스팅은 Private Subnet에 위치하는 EC2 인스턴스가 외부 인터넷과 통신하는 방법에 대해서 다룰까 한다. 방법이야 여러 가지지만 그중에서 NAT gateway 서비스를 사용하는 방법을 다룰까 한다. 그리고 NAT gateway 없이 Bastion Host를 NAT로도 이용하는 방법을 포스팅하려 한다. NAT Gateway 서비스란 우리가 알고 있는 NAT와 동일하다. AWS에서 제공하는 서비스일 뿐. NAT 게이트웨이 서비스는 Private Subnet의 인스턴스가 VPC 외부(인터넷)의 서비스를 연결할 수 있도록 하지만 외부의 연결을 막는 역할을 한다. 실제 예로 이것을 언제 사용할까? Public Sunet은 인터넷과 연결되어 있고 Priavte Subnet은 내부망이다. 만약 Pr..

AWS는 기본적으로 모든 것을 Deny를 하는 정책을 가지고 있다. AWS 방화벽 기능에는 크게 두 가지가 있다. Network ACls (stateless firewalls), Security Groups(stateful firewalls)가 되겠다. 1. NACL (stateless firewalls) - NACL은 서브넷 단위로 적용 (서브넷 안에 EC가 100개 있으면 모두 해당 NACL의 영향을 받는다) - NACL은 여러 Subnet에 적용 가능하며 Subnet은 하나의 NACL만 적용 - VPC 하나당 최대 200개까지 생성 가능 - NACL은 Ibound Rule 20개, Outbound Rule 20개 등록 가능 - Stateless 성질로 요청 정보를 저장하지 않으므로 응답 트래픽 제어..

클라우드 사용하는 목적이 무엇이 됐건 VPC(Virtual Private Cloud)를 생성하는 것이 가장 기본이 아닌가 싶다. VPC를 만들고자 한다면 크게 다음 4가지를 거쳐야 한다. VPC라는 가상의 데이터센터를 생성하기 위해서는 내부적으로 사용할 수 있는 Private IP주소를 결정해야 하고, IP 대역을 작은 단위로 Subnet을 이용해 Boundary를 만들고, 인터넷과 연결될 수 있는 라우팅 테이블을 만들고, 길을 만들어 놨으면 목적에 맞게 방화벽 설정을 거쳐야 한다. 1. IP 주소 범위 선택 2. 가용 영역(AZ) 별 서브넷 설정 3. 인터넷으로 향하는 경로(route) 만들기 4. VPC 로부터의 트래픽 설정 1. IP주소 범위 선택 VPC를 생성할 때 가장 먼저 고려해야 하는 사항이..

AWS CloudShell 이란 AWS CloudShell은 브라우저 기반 가상 쉘이다. OS 환경 Amazon Linux 2 기반이며 공통 개발 및 운영 도구가 사전에 설치되어 있어 별도의 구성이나 로컬 설치는 필요하지 않다. CloudShell을 이용해 AWS CLI로 스크립트를 빠르게 실행하는 등 간단하고 접근 편하게 테스팅하기 좋아 보인다. 나아가 Cloudshell 자체는 무료다. CloudShell을 통해서 사용하는 별도의 AWS 서비스만 과금된다. CloudShell 사용 정보는 CloudTrail에 기록된다. 포스팅 기준 날짜로 CloudShell을 지원하는 지역은 옆의 이미지와 같다. 생각보다 지원되는 리전은 적지만 앞으로도 추가적인 지원이 될 예정이라고 한다. AWS CloudShell..

자격 증명 없이 EC2 인스턴스가 직접 S3에 액세스 할 수 있도록 구성해보려 한다. 누군가의 부주의로 Key가 유출되는 경우가 종종 있어 아예 EC2 직접 S3권한을 부여하면 문제가 조금은 해소되지 않을까 싶어 시작했으며 이참에 겸사겸사 기록해본다. 준비물 1. 기본적인 클라우드 환경 2. EC2 3. S3 4. EC2에서 S3로 붙기위한 IAM Role 1. S3 생성 S3 버킷의 이름은 고유해야 하며 2개를 생성했다. 이 중 하나만 EC2가 접근할 수 있도록 구성해볼 생각이다. Role 정상적이라면 나머지 다른 하나에 대한 접근 권한을 없을 것이다. 2. EC2 생성 EC2 인스턴스 아무런 AWS 자격증명 정보를 입력하지 않았으며 어떠한 Role도 부여받지 않은 모습이다. 필자는 원래 돌리고 있던 ..

Terraform을 이용해 AWS의 대표 저장소인 S3를 생성하고 CLI 환경에서 간단한 동작을 해보려 한다. 물론 이 모든 건 AWS configure 자격 증명이 되어있어야 한다. 1. 우선 S3 생성을 위한 테라폼 파일을 생성한다. 물론 S3 버킷의 이름은 고유해야 한다. #provider.tf provider "aws" { region = "ap-northeast-2" } #s3.tf resource "aws_s3_bucket" "s3" { bucket = "boesterraformbucket" } 2. Terraform init > Terraform plan > 콘솔에서 버킷 생성 확인 3. S3에 파일 업로드 더미 파일을 만들어 S3에 파일 업로드를 한다. S3 관련 CLI 명령어는 공식 사이..

AWS는 CLI, SDK, CDK 등 다양한 API를 제공한다. AWS의 모든 리소스는 API를 통해 생성할 수 있으며 이는 즉, 정해진 API 인터페이스에 맞게 요청을 보내면 AWS 측에서도 해당 요청대로 명령을 수행한다는 뜻이다. API는 응용프로그램에서 사용할 수 있도록 만든 하나의 인터페이스 그리고 AWS는 사용자 구분을 위해 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY 를 요구한다. 해당 키들은 사용자의 권한도 포함하고 있으며 유출되면 안되는 것들이다. 한 번 구성해보자. 1 . IAM 유저 생성 프로그래밍 방식 액세스 -> Access Key 와 Secret Key를 사용할 것인가? AWS Management Console 액세스 -> 콘솔환경에서 엑세스 할 것이냐..

옛날에 만들어 둔 AWS 계정의 Free Tier 가 유효한지 알고 싶어졌다. 하지만 내 예상과 달리 언제까지 무료 기간 입니다! 하고 친절하게 설명되어 있지 않는 AWS 였다. 그렇다면 기억을 더듬는 방법 밖에 없을까? 그렇지 않다. 1. 콘솔화면 우측 상단 자신의 계정을 클릭하여 '내 결제 대시보드' 를 클릭한다. 2. 청구서 클릭 > 청구서의 날짜 필자의 경우 처음 청구서가 발행된 날은 2020년 7월이다. 2021년 7월까지 유효하다는 것을 유추할 수 있다. 3. 대금 및 비용 관리 대시보드 대시보드에 접속하면 위와 같이 프리 티어 서비스를 어느정도 사용하고 있었는지 보인다. 이런게 보인다면 적어도 프리 티어는 아직 유효하다는 의미다. 만료될 때까지 뽕 뽑자.