ClouD

nlb endpoint를 이용해 private VPC EC2를 외부로 노출하기

Tue, 27 Jan 2026 16:32:49 +0900

개요

NAT, IGW가 없는 VPC의 EC2를 외부에 노출시키기 위한 작전
EC2는 Private Subnet에 있고 IGW, NAT도 없어서 인터넷에서 다운로드가 불가능하다. 이를 위해 TGW를 이용해 인터넷을 사용할 수 있게 할 수 있음
추가로 EC2에 설치된 애플리케이션인 nginx를 외부에 노출시키기 위해 A VPC에 ALB - Endpoint, B VPC에 internal NLB - EC2 이런 구조로 만드는 것이다.

준비물

NAT, IGW 없는 B VPC의 Private Subnet에 위치한 Private IP를 단 EC2

리스너는 80 포트로 ec2 대상그룹으로 전달하기

internal NLB는 B VPC의 Private Subnet에 위치한다.
보안그룹으로는 A VPC CIDR 대역을 80 포트 허용한다

교차 영역 로드 밸런싱은 꼭 켜둬야한다. 그래야 추후 ALB의 타겟그룹에서 NLB의 엔드포인트 서비스가 지정되었을 때 상태 검사 fail이 안 뜬다

엔드포인트 서비스 생성

VPC > 엔드포인트 서비스 로 접근하기
로드밸런서 유형에서 네트워크 선택하면 연결 가능한 internal NLB가 나타난다
지원 리전을 굳이 설정 안 해도 됨.

4. 생성 완료되면 서비스 이름을 기록해둔다.

5. 승인이 필요하다면 엔드포인트 서비스의 <엔드포인트 연결> 탭에서 진행하면 된다. 이미 승인해서 선택할 수 없지만, <엔드포인트 연결 요청 수락>을 선택하면 됨.

엔드포인트

엔드포인트 생성하기 에서 NLB 및 GWLB를 사용하는 엔드포인트 서비스 선택
서비스 설정에 엔드포인트 서비스 이름 복사한 거 붙여넣기

3. 서브넷은 A VPC의 Public Subnet, Private Subnet 모두 가능하다.

4. 보안그룹은 아래에서 만들 ALB의 보안그룹을 HTTP 80으로 허용 하면 된다.

5. 그리고 서브넷 연결된 IPv4 주소를 미리 적어둔다. 이제 이 IP주소가 A VPC의 ALB 타겟이 될 IP이다.

ALB 생성

이제 A VPC에 External ALB를 만들면 된다.
보안그룹은 일반적으로 하는 HTTP 80 0.0.0.0/0으로 열면 된다.

타겟그룹

사용할 포트는 nginx여서 HTTP:80으로 했고, 타겟그룹은 위에서 적어둔 IP 주소로 타겟이 되는 것이다.
대상 유형은 반드시 IP로 설정하기

결과

ALB DNS로 들어가면 웹 페이지가 정상적으로 나타난다. EC2가 있는 VPC는 IGW도 NAT도 없지만, endpoint service와 인터넷과 연결되는 외부 ALB를 통해 EC2의 nginx 애플리케이션이 외부로 노출이 가능한 것이다.

정리

ALB

NLB

Transit Gateway 이용해 중앙집중형 VPC에서 인터넷 이용하기

Fri, 9 Jan 2026 17:56:18 +0900

Transit Gateway는 클라우드용 중앙 집중식 라우터(Hub)이다

예전에는 VPC Peering을 통해서 VPC 간에 하나하나 연결을 다 했어야 했는데 이제는 Transit Gateway를 이용해서 전이적 통신이 가능해졌다.

암튼 Transit Gateway 설명은 그렇고, 얘는 VPC와 VPN, Peering, Direct Connect와 연결 가능하다.

내가 얘기하고 싶은 건 하나의 리전 안에 VPC가 두 개가 있을 때 A VPC에만 인터넷 게이트웨이와 NAT 게이트웨이가 있고 B VPC는 외부와 통신 가능한 망이 하~나도 없을 때 Transit Gateway를 이용해 어떻게 할 수 있는지다.

A VPC

- Internet Gateway 있음

- NAT Gateway 있음

- Public Subnet 있음

B VPC

- Internet Gateway 없음

- NAT Gateway 없음

- Private Subnet만 존재

이런 상황이라면 B VPC의 인스턴스에는 접근도 외부에서 뭔가 다운로드 하는 것조차도 불가능하다.

근데 상식적으로 그럴 순 없으니까 우리는 외부와 연결 가능한 A VPC를 이용해서 인터넷을 사용할 거다.

그렇게 하기 위해선 VPC Peering도 할 수 있겠지만, 여기에선 Transit Gateway를 사용하고자 한다.

Transit Gateway 아키텍처

Transit Gateway 생성하기

- VPC > Transit Gateway 페이지에서 tgw를 생성한다.

- 기본 라우팅 테이블 연결과 전파는 체크 해도 되고 체크 안 해도 된다. 자동으로 라우팅테이블을 만들 것이냐 아니냐의 차이여서 크게 상관없다. 어차피 우리는 라우팅만 잘 잡아주면 됨

Transit Gateway Attachment 생성하기

1. A VPC의 Transit Gateway Attachment 생성하기

1번에서 생성한 TGW 선택
VPC에서 A VPC 선택하기
Private Subnet 둘 다 선택해주기. 아무 서브넷이나 상관 없다고는 함. 나는 Private2 서브넷 선택했음

2. B VPC의 Transit Gateway Attachment 생성하기

1번에서 생성한 TGW 선택
VPC에서 B VPC 선택하기
Private Subnet 둘 다 선택해주기. 어차피 Private Subnet 뿐이라 선택의 폭이 없음

Transit Gateway Route Table 생성하기

- Transit Gateway 라우팅 테이블 생성할 때는 간단히 Transit Gateway만 지정해주면 된다.

- 만약 Transit Gateway 생성할 때 기본 라우팅 테이블을 지정했다면 자동으로 만들어져있을 것이고, 아니라면 수동으로 만들면 된다.

라우팅 테이블의 <연결>과 <전파>에 Transit Gateway Attachment를 각각 생성해준다.

그러면 자동으로 <경로>에 A와 B VPC CIDR 대역으로 향하는 TGW ID가 지정되어 있을텐데 여기에 추가로 0.0.0.0/0 인터넷으로 향하는 경우에 A VPC로의 TGW ID가 잡히도록 넣어주면 된다.

- 0.0.0.0/0 CIDR의 연결이 TGW가 되도록 설정하기

라우팅 테이블 제어하기

이젠 VPC 서브넷의 라우팅 테이블을 수정하면 된다.

1. A VPC의 Public Subnet의 라우팅테이블

0.0.0.0/0 → IGW
10.1.0.0/16(B VPC대역) → TGW
10.10.0.0/16 → local

2. B VPC의 Private Subnet의 라우팅테이블

0.0.0.0/0 → TGW
10.1.0.0/16 → local

결론

B VPC에 NAT, IGW가 없어도 A VPC의 NAT를 이용해서 B VPC의 EC2에서 인터넷이 가능하게 할 수 있다.
사진은 B VPC의 EC2 인스턴스에서 인터넷으로 ping 날린 것

Regional NAT는 왜인지 되지 않았다 왜 ? 안되는지 이유는 모르겠으나 Zonal NAT를 사용하니까 잘 됨

참고 문서

끝

CloudFront와 S3 버킷에 없는 객체 불러올 때 오류(index.html, SPA)

Thu, 18 Dec 2025 13:12:09 +0900

CloudFront에 원본으로 S3와 ALB를 지정할 수 있다.

보통 프론트엔드는 S3, 백엔드는 ALB 이런 식으로 지정하는데, 프론트엔드 첫페이지로 index.html을 사용한다

예를 들어 example.com 도메인에 접속하면 example.com/login으로 가게끔 코드단에 설정되어 있다.

근데 cloudfront 입장에서 /login이라는 객체는 s3에 없어서 403 에러가 뜸

이 403 응답을 제어하기 위해서 보통 cloudfront의 오류 페이지 기능을 사용함.

S3에 저장된 index.html 모습

CloudFront의 동작에 s3와 alb가 지정된 모습

오류 페이지 기능을 이용해서 403이 뜨면 index.html 파일로 들어가게끔 설정해둔다.

이렇게 해야만 example.com 도메인에 들어갔을 때 index.html 파일에 접근되며 프론트 페이지가 잘 보이게된다.

근데 문제

코드 단에서 403 응답이 오면 토큰 refesh 처리가 되는 기능이 있었음 ..

즉, 403을 자동으로 200 코드 뜨게 하면 이 토큰 refresh 기능이 아무 의미 없어지는 것이다

오류 페이지를 없애자니 403 에러가 뜨고, 403 에러를 해결하자니 토큰 기능을 할 수 없는 문제가 발생 ..!

그래서 할 수 있는 것 : cloudfront edge function에서 default(*)일 경우 함수를 호출하게 설정하는 것이다.

즉, 동작 중 S3와 연결된 동작에 함수를 쓸 수 있게 하는 것

함수는 cloudfront > 함수에서 만들 수 있다. 만들어서 게시, 배포하면 끝

function handler(event) {
    var request = event.request;
    var uri = request.uri;

    // 확장자가 없는 SPA 라우트 → index.html로 rewrite
    if (!uri.includes(".")) {
        request.uri = "/index.html";
    }

    return request;
}

CloudFront Edge Function을 활용하면 응답 코드와 S3에 없는 객체를 불러오는 오류 코드도 해결이 가능하다!

CloudFront의 오류 페이지 말고, Edge Function도 써보자

끗

DataSync로 S3에 데이터 이관하기

Wed, 3 Dec 2025 10:48:57 +0900

DataSync는 보통 S3에 데이터 이관할 때 사용하는 서비스이다.

만약 온프레미스에서 아래 세 가지에 충족하지 않는다면 Site-to-Site VPN을 이용해 DataSync AMI로 EC2를 생성해 구성해야 한다.

Amazon EC2에 에이전트 배포

EC2 생성할 때 AMI에서 datasync를 검색해서 가장 최신의 AMI를 선택하기

DataSync AMI로 만든 EC2의 보안그룹
- HTTP(80)이 인바운드 허용되어 있어야함
- SSH(22)는 에이전트에 직접 접근해서 작업할 때 진행 필요

EC2 만들 때 Public IP 활성화 필수 !

Public 통신일 경우

이 /share/tmp 폴더에 있는 파일을 S3에 옮길 것이다.
이건 같은 계정에 Public IP가 달린 EC2 인스턴스이다.

Amazon EC2에 에이전트에서 활성화 키 가져오기

1. datasync agent EC2에 접속

- admin으로 접속해야함

ssh -i "hyo-key-al2023.pem" admin@ec2-13-125-156-157.ap-northeast-2.compute.amazonaws.com

2. 활성화 키를 얻기 위해 0 선택

3. region 입력하기

4. 1 (Public endpoints) 선택하면 활성화 키를 얻을 수 있음

에이전트 등록하기

datasync → 에이전트 생성
다음과 같이 입력
- 위에서 했던 방식으로도 활성화 키를 얻을 수 있고, 그게 아니라면 아래 사진처럼 datasync AMI의 Public IP를 넣어서 자동으로 가져올 수 있음

위치 생성

NFS(소스가 될 서버)의 Public 주소 입력

위치를 하나 더 생성해서 Amazon S3로 설정하여 타겟이 될 S3 버킷 설정하기

참고로 IAM Role에 들어가야할 정책은 대충 다음과 같다.

신뢰관계는 datasync로 설정하면 알아서 AWSDataSyncFullAccess와 AWSDataSyncReadOnlyAccess가 들어감

#S3에 접근하기 위해 추가로 들어가야 하는 정책
s3:GetBucketLocation
s3:ListBucket
s3:ListBucketMultipartUploads
s3:AbortMultipartUpload
s3:DeleteObject
s3:GetObject
s3:ListMultipartUploadParts
s3:PutObjectTagging
s3:GetObjectTagging
s3:PutObject

태스크 생성

소스 위치에서 NFS 서버 설정

2. 대상 위치에서 S3 선택하기

3. 나머지는 다 기본으로 설정해주기

마이그레이션 시작

시작 - 기본값으로 시작

2. 버킷에 알아서 들어와있다

3. 태스크 기록에서 얼마만에 성공했는지 볼 수 있음

보통 2TB면 33시간 ..? 정도 걸린다고 했던 것 같다.

로딩이 좀 길 뿐 금방 되긴 하는듯

EC2 인스턴스 nginx에 ACM 인증서 적용하기

Mon, 25 Aug 2025 10:53:59 +0900

원래 AWS Certificate Manager(ACM)은 API Gateway, CloudFront, ALB 등 AWS 서비스에만 사용 가능했다.

근데 내보내기 가능한 공인 인증서 기능이 업데이트 되어서 nginx에 ACM에서 발급 받은 인증서를 적용해보겠다.

대부분 블로그는 api 이용해서 인증서 다운 받은 걸 바로 적용하길래 순수 어떻게 적용하는 건지 알아보자.

ACM 공인 인증서 관련 내용은 여기로 -> https://engine.tistory.com/184

AWS Certificate Manager 공인 인증서 개념, 발급방법

ACM 공인 인증서AWS Certificate Manager 신기능, 어디서나 사용할 수 있는 공개 인증서가 출시되었다.2025년 6월 17일, AWS에서 어디에서나 사용할 수 있는 AWS Certificate Manager (ACM) 공개 인증서를 업데이트

engine.tistory.com

테스트 환경

- EC2 : Amazon Linux 2023

- 네트워크 : 인터넷 게이트웨이와 연결된 Public Subnet

테스트 방법

1. nginx 설치하기

sudo apt update && sudo apt install nginx -y

2. SSL 인증서 저장

# SSL 디렉터리 생성
sudo mkdir -p /etc/nginx/ssl

# 다운로드한 인증서/키 복사
sudo cp ~/Downloads/certificate.pem /etc/nginx/ssl/
sudo cp ~/Downloads/certificate_chain.pem /etc/nginx/ssl/
sudo cp ~/Downloads/private_key.pem /etc/nginx/ssl/

3. nginx HTTPS 설정

- site-available 폴더에 사용할 도메인 이름으로 된 파일을 생성한다

sudo mkdir /etc/nginx/site-available
sudo nano /etc/nginx/sites-available/DOMAIN.kro.kr

4. DOMAIN.kro.kr 파일에 다음 내용을 입력한다.

server {
    listen 443 ssl;
    server_name DOMAIN.kro.kr;

    ssl_certificate /etc/nginx/ssl/certificate.pem;
    ssl_certificate_key /etc/nginx/ssl/private_key.pem;
    ssl_trusted_certificate /etc/nginx/ssl/certificate_chain.pem;

    location / {
        root /var/www/html;
        index index.html;
    }
}

server {
    listen 80;
    server_name DOMAIN.kro.kr;
    return 301 https://$host$request_uri;
}

5. nginx.conf 파일을 변경한다. 이 conf 파일에 site-enabled 폴더의 심볼링 링크를 적용할 수 있도록 해준다.

27번째 줄만 추가해줘도 괜찮다.

sudo nano /etc/nginx/nginx.conf

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}
http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*; << 추가

    server {
        listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }

6. 심볼릭 링크 생성 및 nginx 재시작 해준다.

sudo ln -s /etc/nginx/sites-available/test.kro.kr /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

만약, pem키가 필요하다고 하면 ACM 인증서 발급받을 때 설정한 비밀번호를 입력하면 된다.

만약 인증서가 암호화 되어서 nginx 적용이 불가능하다거나 하면 다음 명령을 이용해 pem 파일의 암호화를 해제한다.

이때에도 동일하게 pem 파일의 비밀번호를 입력해야한다.

* 파일이름이 바뀌면 4번에서 파일이름을 변경해주는 것 잊지말자 *

sudo openssl rsa -in /etc/nginx/ssl/private_key.pem -out /etc/nginx/ssl/private_key_decrypted.pem

7. 그러면 nginx에 도메인 적용이 되고, 암호화된 통신이 가능해진다!

ACM에서 여러 활용이 가능한 기능이 나온 것 같아 도움이 많이 될 것 같다 !

AWS CodeBuild, CodePipeline Gitlab 소스 연동 오류

Thu, 21 Aug 2025 10:46:15 +0900

요새 왜ㅐㅐ이렇게 이슈가 많은지 싶지만 언제나 감사하면서 살기

암튼 CodePipeline이나 Codebuild를 돌리기 위해서는 Source가 필요한데 보통 Github이나 Gitlab을 쓴다.

Github 같은 경우 내가 Organizations로 들어가 있다면 소스에서 내 Github 레포지토리를 선택하면 사진처럼 잘 나온다.

근데 요놈의 Gitlab은 잘 안 써서 잘 모르는데, 내가 멤버로 들어가있는 프로젝트의 레포지토리 목록이 자동으로 안 나타난다

Gitlab 레포지토리 목록이 안 나타날 때 확인할 것, 설정 해야하는 것에 대해서 알아보자.

일단 Gitlab을 소스로 연결하는 방법은 다음과 같다.

문서 참고 : https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/connections-gitlab.html

GitLab.com 연결 - AWS CodePipeline

이 기능은 아시아 태평양(홍콩), 아시아 태평양(하이데라바드), 아시아 태평양(자카르타), 아시아 태평양(멜버른), 아시아 태평양(오사카), 아프리카(케이프타운), 중동(바레인), 중동(UAE), 유럽(스

docs.aws.amazon.com

위 문서 참고해서 connection 연결하면 다음 사진처럼 "나의" 레포지토리는 잘 나온다.

하지만 나는 내가 멤버로 들어가있는 프로젝트의 레포지토리를 보고싶단 말이지!

그래서 리포지토리 칸에 프로젝트 URL을 입력해봤다.

https://gitlab.com/PROJECT/REPOSITORY

이렇게 했는데도 안 된단 말이지? CodeConnection에서 찾을 수 없다나 모라나 ..

Failed to transform source location to CodeConnections location. A connection arn is required for CodeConnections sources

그래서 AWS 콘솔에서 개발자도구 > 설정 > 생성한 CodeConnection을 삭제했다.

그리고 나의 Gitlab 계정에 가서 Settings > Applications > Authorized applications에 있는 연결을 Revoke 시켰다.

그리고 다시 ... CodeConnection에서 Gitlab 연결 > 소스의 리포지토리에 프로젝트 URL 입력 했는데 이번엔 다른 에러가 나왔다.

웹훅 만드는데 기대하지 못 한 에러가 있다나 뭐라나...

그래서 사례를 찾아봤는데 웹훅 생성은 최대 20개까지 되고, 어떤 사람은 웹훅 만드는데 4시간 걸렸다길래 이상했지만 일단 기다렸다.

근데 이상한 게 저 위에 에러난건 백엔드 리포지토리이고, 그 전에 code connection 삭제->생성 후 data 리포지토리는 에러 없이 잘 됐단 말이지 ...?

왜 data 리포지토리만 Codebuild에 소스가 잘 연결됐는지 이해가 안되서 더 찾아봤다..

Gitlab이 연결 안 되면 가장 대표적인 이슈는 <권한>일 수 있다고 하더라

차이점을 알고보니 리포지토리 권한이 Developer와 Maintainer로 달랐던 것이다 ...

Codebuild든 Codepipeline이든 Webhook으로 트리거 되는 거여서 Webhook에 대한 권한이 있어야 하는데 Developer에겐 권한이 없어서 나타나는 오류였다.

Gitlab 공식 페이지에선 다음처럼 권한이 부여되어 있다고 나와있다.

https://docs.gitlab.com/user/permissions/

사실 aws docs에는 Gitlab 리포지토리에 Owner 권한이 필요하다고 해서 권한을 Owner로 승격해야하나 고민하고 있었는데 업데이트가 안 된건지.. Maintainer 권한으로 잘 된다.

https://docs.aws.amazon.com/codebuild/latest/userguide/access-tokens-gitlab-overview.html

<정리>

Gitlab 레포지토리가 Codebuild와 Codepipeline 소스에서 보이지 않는다면

1. CodeConnection을 삭제하고, Gitlab Applications 설정에서 revoke 한다.

그래도 안 된다면

2. Gitlab 레포지토리에 접근가능한 나의 역할이 Maintainer 또는 Owner인지 확인하고, 변경한다.

끝

AWS Certificate Manager 공인 인증서 개념, 발급방법

Wed, 20 Aug 2025 16:37:21 +0900

ACM 공인 인증서

AWS Certificate Manager 신기능, 어디서나 사용할 수 있는 공개 인증서가 출시되었다.

2025년 6월 17일, AWS에서 어디에서나 사용할 수 있는 AWS Certificate Manager (ACM) 공개 인증서를 업데이트했다.

기존엔 CloudFront, ALB 등 AWS 서비스에만 국한되어 사용할 수 있던 SSL 인증서를 온프레미스, EC2 인스턴스에서 사용할 수 있게 되었다는 소식!

https://aws.amazon.com/about-aws/whats-new/2025/06/aws-certificate-manager-public-certificates-use-anywhere/?nc1=h_ls

AWS Certificate Manager, 어디서나 사용할 수 있는 공인 인증서 도입 - AWS

AWS Certificate Manager(ACM)는 AWS 내부 또는 외부에서 공인 TLS 인증서가 필요한 모든 워크로드에서 사용할 수 있는 내보내기 가능한 공인 인증서를 발표했습니다. 이번 릴리스를 통해 인증서의 프라이

aws.amazon.com

이 업데이트를 통해 사용자는 내보내기 가능한 공개 인증서를 발급받고 프라이빗 키에 접근하여 모든 컴퓨팅 워크로드에서 TLS 트래픽을 안전하게 종료할 수 있게 되었다

가령 EC2의 nginx나 apache, 컨테이너의 애플리케이션에 직접 인증서를 설치해 TLS 트래픽을 처리하던 워크플로나 CloudFront 외 서드파티 CDN 서비스를 쓴다면 유용한 업데이트가 될 수 있다.

보통 TLS 인증서 가격은 400달러쯤 한다는데 ACM 인증서는 FQDN당 15달러, 와일드카드 당 149달러니까 엄청 싸게 느껴진다.

다만 지금까지 발표된 인증서 유효 기간은 다음과 같다.

2026년 3월 11일까지 발급된 TLS 인증서의 최대 수명은 398일입니다.
2026년 3월 1일부터 발급된 TLS 인증서의 최대 유효 기간은 200일입니다.
2027년 3월 1일부터 발급된 TLS 인증서의 최대 유효 기간은 100일입니다.
2029년 3월 1일부터 발급된 TLS 인증서의 최대 수명은 47일입니다.

참고: FQDN은 www.test.co.kr, sample.ac.kr 등이고 와일드카드는 *.test.co.kr, *.sample.ac.kr 등을 의미한다

ACM 공개 인증서 발급 방법

1. AWS 콘솔 > AWS Certificate Manager(ACM) 접근 > 인증서 요청에서 공개 인증서 발급 선택

2. 도메인 이름 입력하고 내보내기를 활성화 선택한다

3. 그렇게 하면 <검증 대기 중>인 상태로 CNAME 값이 뜬다

4. 요 CNAME 이름과 CNAME 값을 도메인 DNS 설정에 입력해주면 된다.

- 아래는 한국 도메인에서 도메인 설정으로, 가비아나 후이즈는 다를 수 있지만, CNAME 칸에 입력해주면 된다.

- CNAME 값의 마지막 .(점)은 삭제하고 입력해준다.

5. 몇 분 지나면 상태가 <발급됨>으로 변경된다. 이제 오른쪽 상단의 [내보내기]를 선택한다.

6. 프라이빗 키를 암호화 해야해서 암호를 입력해준다.

7. 그러면 짜자잔~ 어디서든 사용할 수 있는 TLS 인증서가 발급 완료된다!

- 모두 다운로드 버튼을 누르면 한 번에 다운받을 수 있음

다음엔 EC2 nginx에 acm 인증서 다운받은 걸 적용해보는 테스트를 해봐야지

Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain 이슈

Wed, 16 Jul 2025 10:39:28 +0900

AWS에는 다양한 자격증명 방법이 있는데 보통 Access key랑 Secret key를 이용한 임시 자격 증명과 EC2 IAM Role 자격증명 등이 있다.

EC2에 Access key랑 Secret Key를 입력해두고, EC2에서 S3로의 Get, Put 등 작업을 해야하는데 이런 이슈가 나타났다.

이슈 전문

 [ERROR] c.h.o.e.exception.ExceptionAdvice - ExceptionAdvice(handleRunTimeException) => ErrorResultRes(success=false, data=null, error=ErrorRes(errorCode=E0002, errorMsg=RuntimeException)) [Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(credentialsProviders=[SystemPropertyCredentialsProvider(), EnvironmentVariableCredentialsProvider(), WebIdentityTokenCredentialsProvider(), ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])), ContainerCredentialsProvider(), InstanceProfileCredentialsProvider()]) : [SystemPropertyCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., EnvironmentVariableCredentialsProvider(): 
Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., WebIdentityTokenCredentialsProvider(): Either the environment variable AWS_WEB_IDENTITY_TOKEN_FILE or the javaproperty aws.webIdentityTokenFile must be set., ProfileCredentialsProvider(profileName=default, 
profileFile=ProfileFile(sections=[])): Profile file contained no credentials for profile 'default': ProfileFile(sections=[]), ContainerCredentialsProvider(): Cannot fetch credentials from container - neither AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variables are set., InstanceProfileCredentialsProvider(): Failed to load credentials from IMDS.]]

이슈 해석

- SystemPropertyCredentialsProvider(): 시스템 속성(aws.accessKeyId, aws.secretAccessKey)에서 자격 증명을 찾지 못했습니다.

- EnvironmentVariableCredentialsProvider(): 환경 변수(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)에서 자격 증명을 찾지 못했습니다.
- WebIdentityTokenCredentialsProvider(): 웹 ID 토큰 (IAM Roles for Service Accounts 등)을 찾지 못했습니다.
- ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])): ~/.aws/credentials 파일의 default 프로필에서 자격 증명을 찾지 못했습니다.
- ContainerCredentialsProvider(): ECS/EKS 컨테이너 환경에서 사용하는 컨테이너 자격 증명을 찾지 못했습니다.
- InstanceProfileCredentialsProvider(): EC2 인스턴스 프로파일 (IAM Role)에서 자격 증명을 찾지 못했습니다.

이슈 결론

: 너 자격증명 없는데?

근데 EC2에 접속해서 들어가보면 .aws/credential 파일에 acess key와 secret key 모두 잘 들어가 있고

심지어 aws s3 ls 명령도 잘 됐다 ㅠ

aws configure list 해보니까 잘 되어있음 ..

근데도 ec2에 올라간 spring 애플리케이션에서 s3 접속이 불가능하다고 하니.. 이상했다.

우선 IAM User Credential에 적용된 정책도 확인해보았으나 별 이상이 없었다.

그러던 중 누군가 이전에 동일한 이슈가 발생했었다고, 해서 들어보니..

aws configure로 credential 자체는 ec2-user 사용자로 설정이 되어있는데, 배포 하다보면 이 credential 정보를 ec2-user가 아닌 root로 하여금 찾게된다는 것이다.

aws sdk(java를 사용)는 로그에서 봤던 것처럼 credential 정보를 알아서 찾을 수 있는데 root로 하면 aws access key를 하던, ec2 IAM Role을 보던 제대로 된 권한을 가지고 있는 자격증명을 찾을 수 없어서 발생하는 이슈였다..

그래서 배포하여 서비스 시작할 때 -Daws.sharedCredentialsFile=/home/ec2-user/.aws/credentials 이 옵션을 추가하면 정상적으로 경로를 잘 찾아가게 된다는 것이다 ...

sudo nohup java -Dspring.profiles.active=dev -Daws.sharedCredentialsFile=/home/ec2-user/.aws/credentials -jar /home/ec2-user/deploy/test.jar \
      > /home/ec2-user/deploy/start.log" 2>&1 &

그렇게 했더니 잘 되었다!

여러 ec2에서 하나의 access key를 사용하는 건 상관 없었고,

EC2에 IAM Role과 Access key가 모두 들어가 있어서 문제였나? 싶었는데 문서를 확인해보니 credential 파일이 선순위고 ec2 iam role은 후순위였다

<자격 증명 설정 검색 순서>

Java 시스템 속성
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, 및 AWS_SESSION_TOKEN 환경 변수
웹 ID 토큰 및 IAM 역할 ARN
공유 credentials및 config파일
Amazon ECS 컨테이너 자격 증명
Amazon EC2 인스턴스 IAM 역할 제공 자격 증명
SDK가 위에 나열된 모든 단계를 거쳐도 필요한 구성 설정을 찾을 수 없는 경우, 다음과 유사한 출력과 함께 예외가 발생합니다.

문서 참고 : https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/credentials-chain.html#credentials-default

Default credentials provider chain in the AWS SDK for Java 2.x - AWS SDK for Java 2.x

Default credentials provider chain in the AWS SDK for Java 2.x The default credentials provider chain in the AWS SDK for Java 2.x automatically searches for AWS credentials in a predefined sequence of locations, allowing applications to authenticate with A

docs.aws.amazon.com

실제로 root로 전환해서 확인해보니 ec2-user와 다른 자격증명이 설정되어 있는 것을 볼 수 있었다.

심지어 .aws/credential 폴더와 파일조차도 없었음

여기에서 Type이 iam-role이라고 설정되어 있었는데 이게 바로 ec2에 부착된 iam role을 의미하는 거였다.. (iam role에는 s3 관련 권한이 존재하지 않았음 -> 당연히 S3 접근도 안되고 오류가 날 수 밖에 없었던 것)

ec2-user의 aws configure list에서 type 중 shared-credentials-file은 access key와 secret key를 의미하는 것이었다..

결론

: credential 이슈가 난다면

1. ~/.aws/credential 폴더에 [default]로 access key와 secret key가 있는지 확인

2. root와 ec2-user의 aws configure list 명령으로 어떤 credential 정보가 입력되어 있는지 확인

3. 애플리케이션 실행할 때 root인지 ec2-user인지 확인하기

가장 좋은 방법은 ec2 iam role을 쓰는 거지만.. 어쩔 수 없이 access key를 써야한다면 꼭 확인해보자

Amazon Connect 콜백 번호 검증(Callback number validation)

Tue, 17 Jun 2025 17:15:20 +0900

요즘은 Amazon Connect를 하고 있는데 ... 그때 발견한 콜백 기능에 대해서 써보겠다..

보통 전화 가능한 상담원이 다 차서 전화가 불가능할 때 <콜백>이라는 기능을 쓴다.

이 콜백은 홈쇼핑 해피콜 처럼 사용자가 전화번호를 남기면 상담원이 통화 가능할 때 전화를 하거나,

굳이 상담원이 전화번호를 입력하여 전화하지 않고도 자동으로 전화가 가는 오토콜백이 있다.

Amazon Connect는 오토콜백(auto-callback)을 지원하기 때문에 유익하다.

하지만, Amazon Connect가 외국 서비스이다보니, +82와 같은 국가번호가 붙지 않으면 전화가 되질 않는다.

또한 flow의 <콜백 번호 설정(Set callback number)> 블록에서 +82가 붙어야만 검증이 가능하고, 콜백 기능이 유효하다.

하지만, 사람이 전화번호를 남길 때, 0101234~~ 이렇게 남기지 +82101234~~ 이렇게 남기진 않는단 말이다..

그래서 이걸 해결할 수 있는 방안에 대해서 설명하겠다.

(참고로 Lambda를 개발해서 쓰면 더 좋겠지만, Lambda 호출 비용과 제한 시간(8초)이 있으므로 이 방법은 배제하겠다)

전체 플로우

콜백 플로우는 무조건 Customer queue(고객 대기열) 타입으로 설정해야한다.

잘 안 보이면 확대해서 보기

세부 설정

1. Store Customer Input

- 입력할 번호의 최대 값을 지정해주기
- Phone number로 하면 010~~으로 입력해도 값 자체가 +8210으로 자동 변환된다.

2. Get Customer Input

- $.StoredCustomerInput으로 1번 단계의 블록을 가져올 수 있다 (https://docs.aws.amazon.com/connect/latest/adminguide/connect-attrib-list.html)

3. Set contact attributes
- 콜백 번호 검증에 통과하기 위해 +82를 붙인 변수값이 필요하다.
- 사용자 정의 변수로 +82$.StoredCustomerInput를 지정
- +82010, +82042, +82070이든 유효하게 사용 가능하다.

4. Set callback number
- 번호에 +82가 붙었기 때문에 유효성 검사가 통과한다.
- 3번에서 선언한 변수를 사용할 변수로 지정해주면 된다.

이렇게 하면 CloudWatch Log group에서도 잘 동작했다는 로그를 확인할 수 있다.

{
    "Results": "Success",
    "ContactId": "CONTACT_ID",
    "ContactFlowId": "arn:aws:connect:ap-northeast-2:ACCOUNT:instance/INSTANCE_ID",
    "ContactFlowName": "3.callback_flow",
    "ContactFlowModuleType": "CreateCallback",
    "Timestamp": "2025-06-12T08:12:25.759Z",
    "Parameters": {
        "InitialDelaySeconds": "10",
        "CustomerPhoneNumber": "+8210612345678",
        "MaxRetryAttempts": "1",
        "RetryDelaySeconds": "600"
    }
}

즉 해석하자면

사용자가 01012345678# 이라고 번호를 입력해도, 변수 설정 블록 덕분에 +8201012345678 이라고 번호가 저장되는 것이며 이는 콜백 번호 검증에 통과되는 번호여서 콜백이 동작한다는 의미이다.

이는 서울리전(ap-northeast-2) 한정으로만 동작하며 다른 리전(내가 테스트한 건 도쿄리전 뿐이지만)에선 동작하지 않았다..

번호 형태	서울 리전 지원 여부	서울 리전 외 지원 여부
+82010	O	X
+8210	O	O
+82070	O	X
+8202	O	X

꼭 알아두기...

그럼 이만 !

AWS IoT SiteWise Portal 삭제 이슈 해결방법

Thu, 17 Apr 2025 18:39:53 +0900

AWS IoT SiteWise엔 데이터를 대시보드화 하기 쉽도록 Portal 기능이 있다.

해당 기능을 이용하면 그래프를 통해 SiteWise에 저장/전달된 데이터를 쉽게 시각화 할 수 있다는 장점이 있다.

https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html

Get started with AWS IoT SiteWise Monitor (Classic) - AWS IoT SiteWise

When adding users or administrators to the portal, avoid creating AWS Identity and Access Management (IAM) policies that restrict user permissions, such as limited IP. Any attached policies with restricted permissions will not be able to connect to the AWS

docs.aws.amazon.com

하지만.. 이 portal은 외부 페이지로 디렉션되는 구조라 권한이나 사용자별 관리나 제어가 필요하다.

그 과정에서 .. 어떤 이슈로 인해 Portal이 삭제되지 않았는데 .. 그 이슈와 해결방안에 대해 풀어보고자 한다.

이슈 상황

AWS IoT SiteWise의 Portal 페이지에서 [삭제]를 선택했는데 다음 오류가 나타났다.

띠로리

에러를 확인하면 portal에 연결된 policies와 projects가 있어서 삭제가 불가능하다고 한다.

Projects 삭제

프로젝트를 삭제하려면 프로젝트 내에 설정된 프로젝트 뷰어와 프로젝트 소유자를 제거해야만 한다!

다음 링크를 참고해서 삭제하면 된다! https://docs.aws.amazon.com/iot-sitewise/latest/appguide/delete-projects.html

Delete projects in AWS IoT SiteWise Monitor - AWS IoT SiteWise Monitor

Delete projects in AWS IoT SiteWise Monitor As a portal administrator, you can delete any project that you don't need. To delete a project, you must first delete or remove all dashboards, associated assets, project owners, and project viewers. To delete a

docs.aws.amazon.com

Policies 삭제

Access Policy는 IAM identity Center User / Group 또는 IAM 사용자에게 지정된 AWS IoT SiteWise Monitor Portal이나 Project 리소스에 대한 액세스 권한을 부여하도록 정책을 만든다.

policies는 어디에서 삭제하는 건지.. 도저히 모르겠어서 AWS re:post에 도움을 요청했다.

친절한 AWS 사람이 cli로 해보라고 해서 도저언.!

1. Cloudshell에 접속한다.

2. Portal ID를 확인하기 위해 다음 cli를 입력한다.

aws iotsitewise list-portals

그러면 다음 형태의 출력이 나타난다. 여기에서 id 부분을 따로 메모해두자.

{
    "portalSummaries": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
            "name": "MySiteWisePortal",
            "description": "Example portal",
            ...
        }
    ]
}

3. list-access-policies CLI로 어떤 정책이 있는지 확인해보자.

aws iotsitewise list-access-policies --resource-type PORTAL \
	--resource-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

그러면 다음과 같은 access policy가 나타난다. (이런 걸 설정하지 않았음에도 있는 거 보면 사용자 제어 하다가 자동으로 생긴 것 같다 ..)

4. 이제 access policy를 지우면 된다!

aws iotsitewise delete-access-policy --access-policy-id ACCESS-POLICY-ID-aaaaa-YYYYYY

아무 출력이 없으면 삭제가 완료된 것이다.

5. 마지막으로 SiteWise portal 페이지에서 다시 [삭제]를 누르면 완전히 삭제된다

access policy가 예전엔 없었는데 생긴 걸 보면 삭제하는 과정에서 뭐가 꼬여서 설정이 누락되었거나, 또는 업데이트 되는 과정에서 자동으로 삭제되지 않아서 그런 것 같다 ..

IoT SiteWise Portal은 사용자 당 비용 과금이여서 사용자가 없으면 상관 없을테지만 혹시모를 비용을 위해 언제나 리소스 삭제하는 건 꼭 필요하다

참고 문서

list-access-policies : https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotsitewise/list-access-policies.html

list-access-policies — AWS CLI 2.26.3 Command Reference

The total number of items to return in the command’s output. If the total number of items available is more than the value specified, a NextToken is provided in the command’s output. To resume pagination, provide the NextToken value in the starting-tok

awscli.amazonaws.com

delete-access-policy : https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotsitewise/delete-access-policy.html

delete-access-policy — AWS CLI 2.26.3 Command Reference

Note To use the following examples, you must have the AWS CLI installed and configured. See the Getting started guide in the AWS CLI User Guide for more information. Unless otherwise stated, all examples have unix-like quotation rules. These examples will

awscli.amazonaws.com

그럼 끗