ISFJ 개발자의 이야기

AWS EC2 비밀번호로 접속하기

ISFJ 개발자의 이야기 — Sun, 15 Feb 2026 14:25:17 +0900

이번 블로그에서는 AWS EC2를 키페어로 접속하는게 아닌 비밀번호를 설정하여 접속하는 방법에 대한 글을 작성해보겠습니다.

구축방안

우선 EC2의 접속해 아래의 명령어를 이용해 SSH 서버 설정 파일인 /etc/ssh/sshd_config 파일을 편집해서 비밀번호 인증을 허용하게 설정해줘야합니다.

sudo 권한 즉 관리자의 권한에 있다는 기반으로 설명합니다.

sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

비밀번호 인증을 허용하게 설정을 하였다면 아래의 명령어로 SSH를 재시작 해줍니다.

systemctl restart sshd

마지막으로 아래의 명령어를 이용해 비밀번호로 사용할 비밀번호를 설정해줍니다.

echo '<비밀번호>' | passwd --stdin ec2-user

Result

아래의 명령어를 이용해 EC2의 접속을 시도한다면 비밀번호를 입력하라고 하며 성공적으로 입력 시 접속이 되게 됩니다.

ssh ec2-user@<EC2PublicIP>

이것으로 AWS EC2 비밀번호로 접속하는 설정 글을 마치겠습니다. 감사합니다!

RDS IAM Authentication

ISFJ 개발자의 이야기 — Sun, 15 Feb 2026 04:33:45 +0900

이번 블로그에서는 RDS IAM Authentication을 구성하는 방법에 대해서 작성해보겠습니다.

IAM Authentication을 사용하는 이유

RDS Database에 접속할 때 암호를 사용해도 되지만, IAM 인증을 사용하기도 됩니다. IAM 인증에서는 RDS가 생성하는 인증 토큰을 사용하며 각 토큰의 수명은 15분입니다. SSL 또는 TLS를 사용하여 DB 인스턴스에 대한 연결을 암호화합니다. 즉 비밀번호 관리 필요성을 없애 보안을 강화하고, IAM 기반의 중앙집중식 권한 관리를 통해 운영 효율성을 높이며, 15분마다 만료되는 토큰을 사용하여 해킹 위협을 줄이기 위해 사용합니다.

구축 방안

우선 EC2에서 사용할 역할을 생성 및 권한을 부여해줘야합니다.

권한은 아래의 사진과 JSON을 참고하여 구성하면 됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds-db:connect"
            ],
            "Resource": [
                "arn:aws:rds-db:ap-northeast-2:<ACCOUNT_ID>:dbuser:*/*"
            ]
        }
    ]
}

아래의 사진과 같이 정책의 이름을 부여해주고 생성해줍니다.

EC2가 Bastion Server의 역할을 하기에 Admin 권한도 부여해주겠습니다.

다음으로 RDS에서 사용할 보안그룹을 아래의 사진을 참고하여 구성해줍니다.

다음으로 RDS의 서브넷 그룹을 생성해줍니다. 보안을 위해 Protected (Isolated) 서브넷을 선택해주겠습니다.

이제 RDS 생성 메뉴로 들어가 Standard create를 선택해주고 Aurora MySQL을 선택해주겠습니다.

운영을 할 목적이 아니기에 Dev/Test를 선택해주고 Cluster의 이름 및 설정을 아래의 사진을 참고하여 구성해줍니다.

인스턴스 타입은 t3.medium을 선택 해주겠습니다.

다음으로 VPC를 선택해주고 생성했던 서브넷 그룹과 보안그룹을 선택해줍니다.

다음으로 오늘의 주제인 IAM Authentication을 활성화 해줍니다.

다음으로 초기 데이터베이스 이름을 지정 및 RDS를 생성해줍니다.

다음으로 EC2 생성 메뉴에서 IAM Instanc Profile을 생성해줬던 역할을 선택 및 인스턴스를 생성해줍니다.

다음으로 생성한 EC2에 접속해 아래의 명령어를 이용해 MySQL을 설치해줍니다.

sudo dnf update -y
sudo dnf install -y mariadb105

다음으로 MySQL 설치를 완료 하였다면 아래의 명령어를 이용해 RDS의 Endpoint를 불러옵니다.

RDS_EP=$(aws rds describe-db-cluster-endpoints --query "DBClusterEndpoints[?EndpointType=='WRITER'].Endpoint" --output text)

다음으로 아래의 명령어로 RDS의 접근 해줍니다. (비밀번호에 맞게 작성이 필요합니다.)

mysql -h $RDS_EP -u admin -P 3306 -pSkill53##

다음으로 아래의 사진과 같이 SSL 접속 허용 및 IAM 인증 접속을 허용하는 'rds_iam'이라는 이름의 User를 생성해줍니다.

CREATE USER rds_iam IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
ALTER USER 'rds_iam'@'%' REQUIRE SSL;

다음으로 exit를 통해 RDS에서 빠져 나온 뒤 아래의 명령어를 이용해 인증토큰을 발급해줍니다.

RDSHOST=$(aws rds describe-db-instances --query "DBInstances[?DBInstanceStatus=='available'].Endpoint.Address" --output text)
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --username rds_iam)"

마지막으로 아래의 명령어를 이용해 SSL 접속을 위해 모든 리전에서 작동하는 루트 인증서를 다운로드해줍니다.

wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Result

아래의 사진과 같이 IAM 인증을 사용해 RDS에 접속해본다면 정상적으로 접근되는 모습을 확인 할 수 있습니다.

mysql --host=$RDSHOST --ssl-ca=./global-bundle.pem --enable-cleartext-plugin --user=rds_iam --password=$TOKEN

이것으로 RDS IAM Authentication 구축 글을 마치겠습니다. 감사합니다!

RDS Healthcheck Disaster Recovery

ISFJ 개발자의 이야기 — Wed, 11 Feb 2026 23:39:27 +0900

이번 블로그에서는 AWS RDS를 Multi-Region 구조로 구성하여 고가용성을 확보하는 방법에 대해 정리해보겠습니다.

단일 리전에 RDS를 구성할 경우, 해당 리전에 장애가 발생하면 데이터베이스에 접근할 수 없게 되는 치명적인 문제가 발생할 수 있습니다. 이러한 리전 단위 장애(Region Failure)에 대비하기 위해, RDS를 서로 다른 리전에 구성하고 장애 발생 시 자동으로 다른 리전의 RDS로 트래픽을 전환하는 Disaster Recovery(재해 복구) 아키텍처를 설계해보겠습니다.

구축 방안

우선 아래의 Github 링크를 통해 인프라를 테라폼을 이용해 구성해야 합니다.

https://github.com/learning-wlstmd/db-health

GitHub - learning-wlstmd/db-health

Contribute to learning-wlstmd/db-health development by creating an account on GitHub.

github.com

인프라를 모두 구성 완료 했다면 다음으로 서로 다른 리전에 있는 VPC를 Peering으로 연결해줍니다.

다음으로 Accept를 해주어 Peering을 해줍니다.

각 리전의 public, private 모든 라우팅 테이블에 피어링 규칙 생성을 해줘야 합니다.
- ap-northeast-2 VPC CIDR : 10.101.0.0/16
- us-east-1 VPC CIDR : 10.100.0.0/16

다음으로 us-esat-1 리전에 있는 EC2 서버에 접근해 아래의 명령어를 실행해줍니다.

Terraform으로 인프라 구성 시 db-health.py 파일이 자동으로 서버에 생성이 됩니다.

AP_ENDPOINT=$(aws rds describe-db-cluster-endpoints --query "DBClusterEndpoints[?EndpointType=='WRITER'].Endpoint" --region ap-northeast-2 --output text)
US_ENDPOINT=$(aws rds describe-db-cluster-endpoints --query "DBClusterEndpoints[?EndpointType=='WRITER'].Endpoint" --region us-east-1 --output text)

sed -i "s|AP_ENDPOINT|$AP_ENDPOINT|g" db-health.py
sed -i "s|US_ENDPOINT|$US_ENDPOINT|g" db-health.py

sudo yum install python-pip -y
pip3 install flask pymysql
nohup python3 db-health.py &

다음으로 Route53 Healthcheck를 생성해줍니다.

us-esat-1 rds check (IP address 부분은 EC2의 Public IP:5000을 사용하면 됩니다.)

ap-northeast-2 rds check (IP address 부분은 EC2의 Public IP:5000을 사용하면 됩니다.)

다음으로 Route53 Private Hosted Zone을 생성해줍니다.

다음으로 생성한 Hosted Zone에 레코드를 생성해줍니다.

아래의 사진과 같이 US 리전에 있는 RDS DNS를 입력 해주고 생성한 US Healthcheck를 선택해줍니다.

마찬가지로 아래의 사진과 같이 AP 리전에 있는 RDS DNS를 입력 해주고 생성한 AP Healthcheck를 선택해줍니다.

마지막으로 아래의 사진과 같이 Failover Records가 Primary, Secondary로 올바르게 생성해줍니다.

Result

테스트를 위해 Cluster를 Stop 상태로 전환해보겠습니다.

US 리전에 있는 DB Cluster를 Stop 해보겠습니다.

아래의 명령어로 MySQL에 접속 및 상태를 확인해보겠습니다.

mysql -h db.demo.local -uadmin -pSkill53##

SELECT SERVER_ID FROM information_schema.replica_host_status;

아래의 사진과 같이 Primary RDS인 US 리전에 있는 RDS는 Unhealthy 상태이지만 RDS의 접속이 잘되는 모습을 확인 할 수 있으며 접속한 RDS를 정보를 확인 해보면 Secondary RDS인 AP 리전에 있는 RDS로 전환된 모습을 확인 할 수 있습니다.

이것으로 RDS Healthcheck Disaster Recovery 아키텍처 구성글을 마치겠습니다. 감사합니다!

AWS EC2 Fail2ban

ISFJ 개발자의 이야기 — Wed, 11 Feb 2026 16:52:34 +0900

이번 블로그에서는 리눅스에서 주로 보안을 강화하기 위해 사용되는 도구인 Fail2ban을 AWS EC2에 적용하는 글을 작성해보겠습니다.

Fail2ban 개념

Fail2ban은 리눅스에서 주로 보안을 강화하기 위해 사용되는 도구입니다. 서버에 대한 무차별 공격을 방어하기 위해 개발된 이 도구는 주로 SSH와 같은 네트워크 서비스에 적용됩니다. 로그 파일을 모니터링하여 특정 IP에서 지속적으로 실패한 로그인 시도를 감지하고, 일정한 규칙에 따라 해당 IP를 자동으로 차단하는 역할을 합니다. 또한 Fail2ban은 iptables와 연동하여 IP를 차단하고, 차단된 IP는 일정 시간이 지나면 자동으로 해제될 수 있습니다.

구축 방안

먼저 AWS EC2에 SSH로 접속해 아래의 명령어로 필요한 패키지들을 설치 및 활성화 해줍니다.

sudo dnf install rsyslog -y
sudo systemctl enable rsyslog --now
sudo cat /var/log/secure

다음으로 yum 명령어를 이용해 fail2ban을 설치 및 활성화 해줍니다.

sudo yum install fail2ban -y
sudo systemctl enable fail2ban.service

다음으로 vim 을 이용해 파일을 열어 준 뒤 아래의 내용을 작성해줍니다.

sudo vim /etc/fail2ban/jail.local

jail.local

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/secure
maxretry = 5
findtime = 300
bantime = 120

마지막으로 fail2ban을 재시작 및 상태를 확인 해줍니다.

sudo systemctl restart fail2ban.service
sudo systemctl status fail2ban.service

Result

5번 정도 접속에 실패한 다음 모습을 확인해줍니다.

아래의 사진과 같이 정상적으로 막힌 모습을 확인 가능합니다.

이것으로 Fail2ban을 이용해 SSH 접속을 차단하는 아키텍처를 구성하는 글을 마치겠습니다. 감사합니다!

Route53 DNSSEC

ISFJ 개발자의 이야기 — Mon, 5 Jan 2026 19:43:02 +0900

이번 블로그에서는 DNS 스푸핑 등 여러가지 DNS공격을 막기위한 장치인 Route53 DNSSEC에 대한 글을 작성해보겠습니다.

공격자는 DNS 쿼리를 가로채고 인터넷 엔드포인트의 실제 IP 주소 대신 자신의 IP 주소를 DNS 해석기로 반환하여 웹 서버와 같은 인터넷 엔드포인트로 전송되는 트래픽을 가로챕니다. 그러면 사용자는 공격자가 웹 사이트를 위조하기 위해 스푸핑한 응답의 IP 주소로 라우팅됩니다.

DNS 트래픽을 보호하는 프로토콜인 DNSSEC(Domain Name System Security Extensions)를 구성하여 DNS 스푸핑 또는 메시지 가로채기(man-in-the-middle) 공격으로 알려진 이러한 유형의 공격으로부터 도메인을 보호할 수 있습니다.

구축 방안

DNS 설정은 가비아를 기준으로 설명합니다.

먼저 구매한 도메인에 대한 Public Hosted Zone을 생성 후 네임서버를 아래의 사진과 같이 등록해줘야합니다.

아래의 표시된 정보를 복사 후 입력해주면 됩니다.

아래의 사진과 같이 가비아에서 등록해주면 됩니다.

다음으로 us-east-1 리전에서 KMS 키를 생성해줘야 합니다. 아래의 사진처럼 비대칭키 > 서명 및 확인 > ECC_NIST_P256를 선택합니다.

Alias와 Name Tag를 달아 알아보기 쉽도록 작성하였습니다.

나머지는 기본값으로 두고 다음으로 계속 넘어가주면 됩니다.

마찬가지로 다음으로 넘어가줍니다.

넘어가다 보면 정책을 설정하는 부분이 있는데 아래의 코드와 같이 작성해줘야합니다.

ACCOUNT_ID는 변경이 필요합니다.

{
    "Version": "2012-10-17",
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT_ID:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow Route 53 DNSSEC Service",
            "Effect": "Allow",
            "Principal": {
                "Service": "dnssec-route53.amazonaws.com"
            },
            "Action": [
                "kms:DescribeKey",
                "kms:GetPublicKey",
                "kms:Sign"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow Route 53 DNSSEC to CreateGrant",
            "Effect": "Allow",
            "Principal": {
                "Service": "dnssec-route53.amazonaws.com"
            },
            "Action": "kms:CreateGrant",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        }
    ]
}

이제 다음으로 넘어가 KMS 키를 생성해주면 됩니다.

다시 Route53 으로 돌아와 DNSSEC signing 메뉴에서 Enable DNSSEC을 선택해줍니다.

아래의 사진처럼 Provide KSK name은 name으로 입력 후 생성했던 KMS를 선택 및 Create를 해줍니다.

Create를 해주었다면 아래의 사진과 같이 Signing으로 변화된 모습을 확인 할 수 있습니다.

이제 마지막으로 DS레코드를 생성해야합니다. 아래의 사진처럼 View DS record를 선택해 정보를 확인해줍니다.

정보를 확인 후 가비아 도메인 통합 관리툴을 선택해줍니다.

DNSSEC을 선택해주고 도메인을 선택해줍니다.

위에서 확인했던 정보를 아래의 사진과 같이 입력후 적용해줍니다.

성공적으로 설정을 했다면 아래의 사진과 같이 처리 성공이라는 문구를 확인할 수 있습니다.

이것으로 Route53 DNSSEC에 대한 글을 마치겠습니다. 감사합니다!

[참고]

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/domain-configure-dnssec.html

Calico CNI

ISFJ 개발자의 이야기 — Mon, 5 Jan 2026 13:53:20 +0900

이번 블로그에서는 Kubernetes 클러스터에서 네트워크 정책과 보안을 제공하는 네트워크 플러그인 Calico에 대한 글을 작성해보겠습니다.

Calico 개념

Calico는 컨테이너와 가상 머신을 위한 네트워킹 솔루션입니다. 즉 여러 컴퓨터나 서버에서 실행되는 애플리케이션들이 서로 안전하고 효율적으로 통신할 수 있도록 도와주는 도구라고 생각하시면 될 것 같습니다.

Calico는 아래의 주요 특징을 가지고 있습니다.

다양한 환경 지원 : Kubernetes, OpenShift 등 여러 플랫폼에서 사용할 수 있습니다.
빠른 성능 : 최신 기술(eBPF)이나 기존 리눅스 네트워킹을 사용해 빠른 속도를 제공합니다.
일관된 사용 경험 : 클라우드에서든 회사 내부 서버에서든, 작은 규모에서든 큰 규모에서든 동일한 방식으로 사용할 수 있습니다.

Calico 구성요소

Calico CNI 설치시 Daemonset 으로 calico-node 파드가 생성됩니다. 이때, calico-node 파드에는 3가지(bird/felix/confd) 중요한 프로그램이 동작합니다.

파드 생성 시 Calico Datastore를 기반으로 CNI 및 IPAM 플러그인이 파드 네트워크를 설정하며, 노드 간 파드 통신은 bird가 학습한 경로 정보를 felix가 호스트의 라우팅 테이블과 iptables에 적용해 처리합니다.

Calico Datastore

Calico 동작을 위한 데이터들을 저장하는 곳으로, 쿠버네티스 API 저장소 혹은 ETCD 를 선택할 수 있습니다.

bird

BGP(Border Gateway Protocol)를 사용하여 노드 간 라우팅 정보를 교환합니다.

felix

bird로 학습한 상대방 노드의 파드 네트워크 대역을 호스트의 라우팅 테이블에 최종적으로 업데이트하는 역할을 하며, IPtables 규칙 설정 관리를 합니다. 즉, 인터페이스 관리, 라우팅 정보 관리, ACL 관리, 상태 체크를 담당합니다.

condif

BGP 설정 등으로 Calico Datastore에 변경이 발생하면, bird 설정 파일을 갱신하고 이를 bird에 적용합니다.

구축 방안

a → b 파드 통신은 허용하고, c → a 파드에서의 통신은 되지 않도록 구성해보겠습니다.

먼저 Helm을 이용해 Calico를 설치하고 curl을 이용해 Calicoctl도 설치해주겠습니다.

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update
kubectl create namespace tigera-operator
helm install calico projectcalico/tigera-operator --version v3.29.2 --namespace tigera-operator
kubectl patch installation default --type='json' -p='[{"op": "replace", "path": "/spec/cni", "value": {"type":"Calico"} }]'

다음으로 NetworkPolicy를 정의해주겠습니다. ingress는 인바운드 규칙, egress는 아웃바운드규칙입니다.

아래의 정책은 selector를 이용해 a 파드에 적용이 되며, b 파드에서 들어오는 트래픽은 허용하고 c 파드에서 들어오는 트래픽은 차단하는 정책입니다.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-communication-for-a-pod
spec:
  selector: app == 'a-pod'
  egress:
    - action: Allow
  ingress:
    - action: Allow
      source:
        selector: app == 'b-pod'
    - action: Deny
      source:
        selector: app == 'c-pod'

다음으로 통신을 테스트 할 Sample Pod(a, b, c)를 구성해주겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: a-pod
  labels:
    app: a-pod
spec:
  containers:
    - name: a-container
      image: nginx:latest

apiVersion: v1
kind: Pod
metadata:
  name: b-pod
  labels:
    app: b-pod
spec:
  containers:
    - name: b-container
      image: nginx:latest

apiVersion: v1
kind: Pod
metadata:
  name: c-pod
  labels:
    app: c-pod
spec:
  containers:
    - name: c-container
      image: nginx:latest

kubectl apply -f a-pod.yaml && kubectl apply -f b-pod.yaml && kubectl apply -f c-pod.yaml

Result

kubectl exec -it a-pod -- curl <b-pod-ip>
kubectl exec -it c-pod -- curl <a-pod-ip>

위 설정을 올바르게 했다면 아래의 사진과 같이 a → b 파드로는 통신이 되는것을 확인 할 수 있으며 c → a 파드에서의 통신은 안되는 것을 볼 수있습니다.

이것으로 Calico CNI에 대한 글을 마치겠습니다. 감사합니다!

[참고]

https://lakescript.net/entry/KANS-Calico-CNI

EKS with KEDA for Event Driven AutoScaling

ISFJ 개발자의 이야기 — Sun, 4 Jan 2026 00:44:02 +0900

이번 블로그에서는 KEDA의 개념과 Event Driven AutoScaling을 구현하는 글을 작성해보겠습니다.

KEDA의 개요

Kubernetes 기본 오토스케일링인 HPA(Horizontal Pod Autoscaler)는 CPU/메모리 기반 스케일링에는 최적이지만, 다음과 같은 한계를 가지고 있습니다.

Scale-to-Zero 적용에 어려움을 겪습니다. 즉 Pod를 0개로 줄일 수 없으며 비용 최적화에 불리합니다.
지표가 실제 서비스 부하 원인과 간접적입니다. 즉 HPA는 부하가 생긴 결과로써 대응을 하기 때문에 트래픽 처리에 대한 대응이 늦을 수 있습니다.
외부 이벤트 소스(메시지 큐, 스트림 등)를 스케일링 기준으로 삼기 복잡합니다.

그러므로 이런 문제를 해결하기 위해 등장하게 된 것이 바로 KEDA입니다.

KEDA는 Kafka, RabbitMQ, SQS, HTTP 요청 등 여러 이벤트 소스를 직접 스케일링 트리거로 사용할 수 있습니다.

동작 원리

사용자가 KEDA에 관리를 요청하기 위한 ScaledObject자원을 생성하면 admission에 의해서 검수 되고, 유효한 자원일 경우 SclaedObject와 KEDA가 관리하는 HPA 자원이 자동으로 생성됩니다.

여기서 자동으로 생성된 HPA 자원의 지표 참조는 쿠버네티스의 메트릭 서버가 아닌 keda-metrics-apiserver를 참조 하도록 되어 습니다. 즉 KEDA는 애플리케이션 Pod들의 개수를 조절하는 스케일링 작업을 직접 수행하지 않습니다.

KEDA는 쿠버네티스 Horizontal Pod Autoscaler를 대체할 목적이 아닌 확장/보조를 목표로 개발되었습니다.

구축 방안

먼저 아래의 명령어를 이용해 SQS Queue를 생성해줍니다.

aws sqs create-queue --queue-name order-queue

다음으로 EKS 위에서 KEDA를 구성할 것이기에 아래의 Manifest를 이용해 Cluster를 생성해줍니다.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: order-cluster
  version: "1.31"
  region: ap-northeast-2

cloudWatch:
  clusterLogging:
    enableTypes: ["*"]

iam:
  withOIDC: true
  serviceAccounts:
    - metadata:
        name: aws-load-balancer-controller
        namespace: kube-system
      wellKnownPolicies:
        awsLoadBalancerController: true
    - metadata:
        name: cert-manager
        namespace: cert-manager
      wellKnownPolicies:
        certManager: true

vpc:
  subnets:
    public:
      ap-northeast-2a: { id: public_a }
      ap-northeast-2b: { id: public_b }
    private:
      ap-northeast-2a: { id: private_a }
      ap-northeast-2b: { id: private_b }

managedNodeGroups:
  - name: order-app-nodegroup
    instanceName: order-app-node
    instanceType: c5.large
    desiredCapacity: 2
    minSize: 2
    maxSize: 4
    privateNetworking: true

아래의 명령어를 이용해 Cluster를 생성해주면 됩니다.

eksctl create cluster -f cluster.yaml

다음으로 아래의 명령어들을 통해 IAM 정책을 생성하고 IRSA를 통해 파드가 생성될 Namespace에 권한을 줍니다.

CLUSTER_NAME=order-cluster
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

cat << EOF > iam_policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetQueueAttributes",
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueAttributes",
                "sqs:ReceiveMessage",
                "sqs:GetQueueUrl",
                "sqs:ListQueues",
                "sqs:deletemessage"
            ],
            "Resource": "*"
        }
    ]
}
EOF

aws iam create-policy \
    --policy-name SqsPolicy \
    --policy-document file://iam_policy.json

eksctl create iamserviceaccount \
  --cluster=$CLUSTER_NAME \
  --namespace=order \
  --name=keda-operator \
  --role-name=keda-operator-role \
  --attach-policy-arn=arn:aws:iam::$AWS_ACCOUNT_ID:policy/SqsPolicy \
  --approve

이제 HELM 명령을 통해 KEDA를 설치해줍니다.

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda \
  -n order \
  --set serviceAccount.operator.create=false \
  --set serviceAccount.operator.name=keda-operator

다음으로 아래의 Manifest를 통해 AutoScaling이 이루어질 Deployment를 생성해주겠습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-processor
  namespace: order
  labels:
    app: order-processor
spec:
  replicas: 1
  selector:
    matchLabels:
      app: order-processor
  template:
    metadata:
      labels:
        app: order-processor
    spec:
      serviceAccountName: keda-operator
      containers:
        - name: order-processor
          image: <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/order-app:v1
          env:
            - name: QUEUE_URL
              value: "https://sqs.ap-northeast-2.amazonaws.com/<AWS_ACCOUNT_ID>/order-queue"
            - name: REGION_NAME
              value: ap-northeast-2
          ports:
            - containerPort: 8080

마지막으로 ScaledObject를 구성해주면 됩니다. 오토스케일링의 기준은 queueLength: "5"로 설정하였기에 SQS 큐에 메시지가 5개 이상일 때 Pod를 추가로 스케일링하게 됩니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  namespace: order
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 1
  maxReplicaCount: 10
  pollingInterval: 10
  cooldownPeriod:  60
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 30   
          policies:
            - type: Percent
              value: 100                    
              periodSeconds: 15          
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.ap-northeast-2.amazonaws.com/<AWS_ACCOUNT_ID>/order-queue
      activationQueueLength: "0"
      queueLength: "5"
      awsRegion: ap-northeast-2
      identityOwner: operator

이것으로 KEDA의 개념과 Event Driven AutoScaling을 구현하는 글을 마치겠습니다. 감사합니다!

Route53 DNS Query Logging

ISFJ 개발자의 이야기 — Sat, 3 Jan 2026 20:57:00 +0900

이번 블로그에서는 Route53 DNS Query Logging에 대한 글을 작성해보겠습니다.

DNS Query Log란?

내가 소유한 DNS에 누군가가 보안침해 시도를 할때에 DNS 쿼리 로그를 검출하여 분석하고 파악할 때 사용 되는 로그입니다.

로그 정보

Route53 DNS 쿼리 로그에서 아래의 정보를 확인할 수 있습니다.

요청한 도메인 또는 하위 도메인
요청 날짜 및 시간
DNS 레코드 유형(A, AAAA 등)
DNS 쿼리에 응답하는 Route 53 엣지 위치
DNS 응답 코드

구축 방안

Route53 DNS Query Logging은 Public Domain으로만 생성할 수 있습니다.

먼저 Route53의 Public Hosted Zone을 생성해줍니다.

다음으로 Configure query logging을 선택해줍니다.

Route53은 글로벌 서비스 임으로 Cloud WatchLogs 로그 그룹은 버지니아 북부에 있는 것을 사용해야합니다.

마지막으로 권한부여를 해준 뒤 생성해주면 로깅 설정을 끝 마칠 수 있습니다.

Result

위 설정을 성공적으로 끝 마쳤다면 아래의 사진과 같이 로그가 남는 모습을 확인 할 수 있습니다.

이것으로 Route53 DNS Query Logging 글을 마치겠습니다. 감사합니다!

EC2 Connect Endpoint

ISFJ 개발자의 이야기 — Wed, 31 Dec 2025 22:59:17 +0900

이번 블로그에서는 EC2 Connect Endpoint에 대한 개념 및 구축방법을 소개하는 글을 작성해보겠습니다.

EC2 Connect Endpoint 개념

EC2 Instance Connect Endpoint는 결국 VPC Endpoint입니다. 이를 생성하게 되면 VPC 내부에 ENI가 생기게 되며 해당 ENI를 통해 Private Subnet에 22(SSH) 접속을 하게되는 원리입니다.

EC2 Connect Endpoint의 제한사항

EC2 Connect Endpoint는 다음과 같은 제한사항을 가지고 있습니다.

포트는 22 및 3389 포트만 지원됩니다.
Ipv6주소를 지원하는 인스턴스 연결을 지원하지 않습니다.
클라이언트 Ip 보존이 활성화되면 연결할 인스턴스는 EC2 Connect Endpoint와 동일한 VPC에 있어야합니다.
트래픽이 TGW를 통해 라우팅 되면 클라이언트 IP 보존이 지원되지 않습니다.

구축 방안

간단히 Public Subnet이 없는 VPC를 생성해줍니다.

생성했던 VPC의 Private Subnet에 EC2를 생성해줍니다.

다음으로 VPC의 Endpoint 메뉴에서 아래의 사진과 같이 EC2 Connect Endpoint를 생성해줍니다.

서브넷은 Private Subnet을 선택해줍니다.

이제 다시 EC2로 돌아와 EC2 Instance Connect Endpoint로 EC2접속을 시도합니다.

Result

성공적으로 되었다면 아래의 사진과 같이 접속이 잘되는 모습을 확인 할 수 있습니다.

이것으로 EC2 Connect Endpoint에 대한 개념 및 구축방법을 소개하는 글을 마치겠습니다. 감사합니다!

NodeLocalDNS

ISFJ 개발자의 이야기 — Mon, 27 Oct 2025 10:02:07 +0900

NodeLocal DNSCache는 클러스터 노드에서 DaemonSet으로 DNS 캐싱 에이전트를 실행하여 클러스터 DNS 성능을 향상시키는 역할을 합니다.

Install NodeLocalDNS

wget https://github.com/kubernetes/kubernetes/raw/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml

kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
domain='cluster.local'    ## default 값
localdns='169.254.20.10'  ## default 값

sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml

kubectl apply -f nodelocaldns.yaml

ISFJ 개발자의 이야기

AWS EC2 비밀번호로 접속하기

구축방안

Result

RDS IAM Authentication

IAM Authentication을 사용하는 이유

구축 방안

Result

RDS Healthcheck Disaster Recovery

구축 방안

Result

AWS EC2 Fail2ban

Fail2ban 개념

구축 방안

Result

Route53 DNSSEC

DNSSEC의 필요성

구축 방안

Calico CNI

Calico 개념

Calico 구성요소

Calico Datastore

bird

felix

condif

구축 방안

Result

EKS with KEDA for Event Driven AutoScaling

KEDA의 개요

동작 원리

구축 방안

Route53 DNS Query Logging

DNS Query Log란?

로그 정보

구축 방안

Result

EC2 Connect Endpoint

EC2 Connect Endpoint 개념

EC2 Connect Endpoint의 제한사항

구축 방안

Result

NodeLocalDNS

Install NodeLocalDNS