AWS Lightsail로 WordPress 기술 블로그를 만들 때 제일 헷갈리는 건 인스턴스 생성보다 그다음입니다. 고정 IP는 왜 붙여야 하는지, Cloudflare 주황색 구름만 켜면 HTTPS까지 끝난 건지, 검색해서 나오는 bncert는 내 서버에서도 써도 되는지… 하나씩 보면 단순한데 문서 세대가 섞이면 갑자기 총체적난국.

결론부터 말하면 Cloudflare만 켠다고 원본 서버까지 안전해지는 건 아닙니다. Lightsail 원본에도 유효한 인증서를 설치한 뒤 Cloudflare SSL/TLS 모드를 Full (strict)로 설정해야 방문자부터 원본까지 두 구간을 제대로 암호화하고 인증서도 검증할 수 있어요.

그리고 2026년 신규 구축은 공급자가 Lightsail인 WordPress 블루프린트를 우선 선택합니다. 과거 글에 자주 등장하는 bncert는 Bitnami 패키지 전용이라 무작정 따라 하면 안 됨.

이 글은 직접 구축 성공담을 꾸민 후기가 아니라, 2026년 7월 26일 기준 AWS와 Cloudflare 공식 문서를 바탕으로 정리한 구축 가이드입니다. 실제 콘솔 화면과 요금, 블루프린트 명칭은 바뀔 수 있으니 실행 직전 공식 화면을 한 번 더 확인해주세요.

먼저 완성 구조부터 잡고 시작하기

목표 구조는 아래처럼 단순합니다.

방문자
  ↓ HTTPS
Cloudflare DNS · Proxy · TLS
  ↓ HTTPS, Full (strict)
Lightsail 고정 IP
  ↓
WordPress

여기서 역할을 섞지 않는 게 중요해요.

Lightsail은 WordPress가 실행되는 원본 서버
고정 IP는 서버를 중지했다 시작해도 DNS 연결을 안정적으로 유지하는 주소
Cloudflare는 권한 DNS이자 웹 프록시
Let’s Encrypt 인증서는 Lightsail 원본의 HTTPS와 호스트명을 증명
Full (strict)은 Cloudflare가 원본 인증서까지 엄격하게 확인하는 모드

Cloudflare의 Flexible은 방문자에서 Cloudflare까지만 HTTPS이고, Cloudflare에서 Lightsail까지는 HTTP입니다. 이름만 보면 편해 보이는데 종단 간 암호화는 아님. 게다가 원본에서 HTTP를 HTTPS로 돌려보내면 리디렉션 루프까지 생길 수 있어 최종 구성으로 잡지 않는 편이 좋습니다.

2026년에는 WordPress 블루프린트 공급자부터 확인하기

Lightsail 콘솔에서 WordPress라는 이름만 보고 선택하면 살짝 위험합니다. 공급자가 Lightsail인지 Bitnami인지 먼저 봐야 해요.

신규 설치 권장: WordPress packaged by Lightsail
기존 환경에서 계속 운영 가능: WordPress packaged by Bitnami
bncert: WordPress packaged by Bitnami 전용

AWS에 따르면 2026년 5월 19일 이후 Bitnami 패키지 블루프린트에는 새 버전이 제공되지 않으며, WordPress Bitnami 블루프린트는 2026년 11월 19일 신규 생성이 중단될 예정입니다. 기존 인스턴스는 계속 작동하지만 업데이트와 보안 패치는 운영자 책임이에요.

그러니 새로 만드는 상황에서 오래된 튜토리얼의 /opt/bitnami/... 경로나 bncert 명령을 그대로 복사하기보다, 콘솔의 blueprint vendor를 확인하고 그 공급자용 절차를 따라야 합니다. 비슷해 보여도 속이 다름.

준비물과 비용은 이렇게 계산하기

시작 전에 필요한 건 AWS 계정, 사용할 도메인, Cloudflare 계정입니다. AWS 계정에는 MFA와 비용 알림을 먼저 설정해두는 게 마음 편-안.

2026년 7월 26일 공식 번들 표 기준 Linux/Unix public IPv4 포함 번들은 다음 가격부터 시작합니다.

메모리	월 상한 요금
0.5GB	$5
1GB	$7
2GB	$12
4GB	$24

Lightsail 인스턴스는 시간 단위 사용량이 월별 번들 상한까지 누적됩니다. 단, Stop만 해서는 과금이 끝나지 않고 Delete해야 인스턴스 요금 누적이 종료돼요. 테마, 플러그인, PHP 워커, 데이터베이스, 트래픽에 따라 필요한 사양이 달라지므로 최저 요금제로 항상 충분하다고 단정할 수도 없습니다.

추가로 확인할 비용도 있습니다.

연결된 고정 IP: 별도 비용 없음
인스턴스와 분리된 고정 IP: 비용 발생
자동·수동 스냅샷 저장분: $0.05/GB-month
도메인: 등록기관과 TLD에 따라 별도
데이터 전송: 번들 포함량과 리전·전송 방향·초과량에 따라 변동

가격, 무료 체험, 환율과 세금은 바뀔 수 있습니다. 발행 시점에는 Lightsail 공식 가격과 생성 화면을 다시 보는 게 안전해요.

1단계 Lightsail WordPress 인스턴스 만들기

Lightsail에서 인스턴스 생성을 열고 대상 독자와 가까운 리전을 선택합니다. 애플리케이션 블루프린트에서는 공급자가 Lightsail인 WordPress를 고르고, 예상 사용량에 맞는 public IPv4 포함 Linux 번들을 선택해요.

인스턴스 이름은 나중에 서버가 늘어나도 용도를 구분할 수 있게 정하는 편이 좋습니다. 생성 후 상태가 Running이 되면 아래 세 가지부터 확인합니다.

초기 WordPress 화면이 열리는지
Lightsail SSH 연결이 되는지
WordPress 관리자 화면에 접근할 수 있는지

아직 도메인과 HTTPS를 붙이기 전이므로 여기서는 원본 애플리케이션이 정상 실행되는지만 보는 단계입니다.

2단계 고정 IP와 방화벽 설정하기

Lightsail의 Networking에서 인스턴스와 같은 리전의 고정 IP를 만들고 곧바로 WordPress 인스턴스에 연결합니다. 기본 공인 IP는 인스턴스를 중지했다 다시 시작하면 바뀔 수 있어서, 동적 IP를 DNS에 바로 넣으면 나중에 사이트가 끊길 수 있거든요.

고정 IP 연결 후에는 방화벽도 확인합니다.

80/TCP: HTTP 접근과 일부 인증서 도메인 검증
443/TCP: 원본 HTTPS
22/TCP: SSH 관리

AWS의 설정 워크플로 중에는 22·80·443 접근이 필요할 수 있지만, 구성이 끝난 뒤 SSH 22번 포트를 전 세계에 계속 열어두지는 않는 편이 좋습니다. 관리자 IP나 필요한 소스로 제한합니다. IPv6를 켰다면 IPv4와 IPv6 방화벽이 별도라는 점도 확인해야 해요.

사용하지 않는 포트를 괜히 넓게 열 필요 없음.

3단계 Cloudflare를 권한 DNS로 연결하기

Cloudflare에 도메인을 추가하면 사용할 네임서버 두 개를 안내합니다. 도메인 등록기관에서 기존 네임서버를 이 값으로 바꾸고 Cloudflare 활성화를 기다려요. 공식 안내상 소유권 확인에 최대 24시간이 걸릴 수 있습니다.

기존에 메일을 쓰고 있었다면 자동 스캔 결과만 믿지 말고 MX, SPF, DKIM, DMARC 레코드가 빠지지 않았는지 직접 확인합니다. 이걸 놓치면 블로그는 열렸는데 메일이 안 오는 묘한 상황 발생.

Cloudflare가 권한 DNS가 된 뒤에는 DNS의 기준도 Cloudflare입니다. 같은 레코드를 Lightsail DNS 존에서 수정해봤자 인터넷 응답에는 반영되지 않아요.

네임서버 전환 여부는 아래처럼 확인할 수 있습니다.

nslookup -type=NS example.com

결과가 Cloudflare에서 지정한 네임서버를 가리키는지 확인합니다. example.com은 실제 도메인으로 바꿔주세요.

4단계 A·CNAME 레코드에 고정 IP 연결하기

기본 구성은 루트 도메인과 www를 같은 사이트로 연결하는 형태입니다.

Type	Name	Content	인증서 설정 중	최종 상태
A	`@`	Lightsail 고정 IPv4	필요 시 DNS only	Proxied
CNAME 또는 A	`www`	루트 호스트 또는 고정 IPv4	필요 시 DNS only	Proxied

웹 트래픽 레코드를 최종적으로 Proxied, 그러니까 주황색 구름으로 두면 외부 DNS 조회에는 원본 고정 IP 대신 Cloudflare Anycast IP가 반환됩니다. Cloudflare의 보호·캐시·분석 기능도 이때 적용돼요.

다만 메일과 도메인 소유권 확인 레코드는 서비스 요구에 따라 DNS only로 둡니다. 같은 원본 IP를 가리키는 불필요한 DNS-only 호스트가 남아 있으면 공격자가 그 레코드로 원본 IP를 알아낼 수 있으니 정리해야 합니다.

5단계 Lightsail 원본에 HTTPS 인증서 설치하기

신규 Lightsail 패키지 WordPress의 기본 경로는 AWS 공식 WordPress 설정 워크플로입니다. 이 과정에서 등록 도메인, 제3자 DNS, 고정 IP, Let’s Encrypt 인증서 생성과 설치를 함께 구성해요.

Cloudflare를 DNS 운영자로 쓰므로 Use third-party DNS 경로를 선택합니다. 인증서에는 실제로 서비스할 루트 도메인과 www 등 모든 호스트를 넣어야 해요. example.com만 인증서에 넣고 www.example.com도 서비스하면 나중에 호스트명 불일치가 생길 수 있습니다.

도메인이 Lightsail 인스턴스로 정상 연결된 뒤 인증서 생성을 진행하고, 작업 중에는 인스턴스를 중지하거나 변경하지 않습니다. AWS는 설정에 최대 15분이 걸릴 수 있다고 안내하며, 설치된 Let’s Encrypt 인증서는 60~90일마다 자동 갱신됩니다.

Cloudflare Proxied 상태에서도 검증이 성공할 수 있으므로 “인증서 발급 때 무조건 프록시를 꺼야 한다”고 단정할 필요는 없습니다. 다만 발급이 실패한다면 루트와 www를 잠시 DNS only로 바꿔 실제 고정 IP로 직접 도달하는지 확인한 다음 다시 시도하는 방식이 안전합니다. 발급과 원본 HTTPS 검증이 끝나면 Proxied로 되돌립니다.

기존 Bitnami라면 경로가 다릅니다

기존 WordPress packaged by Bitnami 인스턴스에서만 AWS의 bncert 안내를 따릅니다. bncert는 도메인 인증서를 요청하고 HTTP→HTTPS 리디렉션과 자동 갱신 경로를 구성하지만, 신규 Lightsail 패키지에 있다고 가정하면 안 돼요.

Cloudflare Origin CA 인증서도 Full (strict)과 호환되지만, Cloudflare를 거치지 않고 원본에 직접 접속하면 일반 브라우저가 공개 인증기관 인증서처럼 신뢰하지 않습니다. Cloudflare는 Origin CA 만료 알림도 제공하지 않아요. 이 글에서는 직접 검증하기 쉬운 공개 신뢰 Let’s Encrypt를 기본 경로로 잡습니다.

6단계 Cloudflare를 Full (strict)으로 바꾸기

원본 인증서를 먼저 설치하고 확인한 다음 Cloudflare SSL/TLS 모드를 Full (strict)로 설정합니다.

통과 조건은 네 가지입니다.

원본 443 포트가 열려 있음
원본 인증서가 유효 기간 안에 있음
공개 신뢰 CA 또는 Cloudflare Origin CA가 발급함
인증서 CN 또는 SAN이 요청한 호스트명과 일치함

이 조건이 맞지 않으면 Cloudflare 526 오류가 날 수 있습니다. 이때 Flexible로 낮춰서 얼렁뚱땅 끝내기보다 인증서 만료, 호스트명, 443 응답부터 바로잡는 게 맞아요.

HTTP가 HTTPS로 한 번만 이동하는지도 확인합니다.

curl -I http://example.com
curl -I https://example.com

첫 번째 응답은 의도한 단일 HTTPS 정규 URL로 이동하고, 두 번째는 정상 응답을 반환해야 합니다. 루트와 www가 서로 계속 돌려보내거나 HTTP와 HTTPS가 반복되면 Cloudflare Redirect Rule, 원본 리디렉션, WordPress 주소가 충돌하지 않는지 봅니다.

7단계 WordPress 운영 설정과 백업 챙기기

HTTPS 접속이 끝났다고 운영 준비까지 끝난 건 아닙니다. 관리자 계정의 초기 비밀번호를 강한 고유 비밀번호로 바꾸고, 가능하면 다중 인증을 적용합니다.

운영 전에는 아래 항목을 확인해요.

WordPress 주소와 사이트 주소가 최종 https:// 도메인인지
고유주소 구조가 확정됐는지
사용하지 않는 테마와 플러그인을 삭제했는지
코어·테마·플러그인 업데이트 계획이 있는지
편집자와 관리자를 최소 권한으로 분리했는지
REST API Application Password가 일반 로그인 비밀번호와 분리됐는지
인증 정보가 저장소, 글, 스크린샷, 로그에 노출되지 않았는지
/wp-admin, 로그인, 미리보기, REST API 쓰기 요청이 무분별하게 캐시되지 않는지

Lightsail WordPress는 관리형 SaaS라기보다 운영자가 서버와 애플리케이션을 돌보는 VPS에 가깝습니다. 업데이트와 보안 패치까지 알아서 다 해줄 거라 기대하면 곤란함.

백업은 Linux/Unix 자동 스냅샷을 켜면 하루 한 번 생성되고 최근 7개가 유지됩니다. 하지만 원본 리소스를 삭제하면 자동 스냅샷도 함께 삭제돼요. 장기 보존 시점은 수동 스냅샷으로 복사하고, WordPress DB·업로드 파일의 애플리케이션 수준 백업도 별도로 고려합니다.

백업 파일이 있다는 사실보다 실제 복원이 되는지가 중요합니다. 한 번은 복원 시험까지 해봐야 진짜 백업.

구축 완료 후 이 순서로 검증하기

설정 화면에서 초록불이 보이는 것과 실제 서비스가 정상인 건 조금 다른 이야기입니다. DNS부터 WordPress까지 순서대로 확인해요.

DNS

권한 NS가 Cloudflare 네임서버인지
루트와 www가 원하는 구성으로 응답하는지
Proxied 상태에서 A 조회가 원본 IP가 아닌 Cloudflare IP를 반환하는지
원본 IP를 노출하는 불필요한 DNS-only 레코드가 없는지
기존 메일 레코드가 유지됐는지

HTTPS

HTTP가 의도한 HTTPS URL로 한 번만 이동하는지
루트와 www 인증서 이름이 모두 일치하는지
브라우저 인증서 경고가 없는지
Cloudflare가 Full (strict)인지
CSS, JavaScript, 이미지에 HTTP URL이 남아 있지 않은지
/wp-admin과 REST API가 HTTPS에서 정상인지

WordPress와 복구

관리자 로그인과 Draft 생성, 이미지 업로드가 정상인지
고유주소와 canonical 호스트가 일관적인지
캐시를 비운 뒤 새 글과 수정 사항이 보이는지
모바일과 데스크톱에서 첫 화면과 코드 블록이 정상인지
SSH 22번 포트가 필요한 소스로 제한됐는지
자동 스냅샷이 실제 생성됐는지
비용 알림과 장애 복구 절차가 준비됐는지

자주 막히는 오류는 여기부터 보기

Cloudflare 526 오류

Full (strict)이 원본 인증서를 신뢰하지 못하는 상황입니다. 원본 인증서 만료, 자체 서명 인증서, 호스트명 불일치, 443 미응답을 확인합니다. Flexible로 내려서 숨기지 말고 원본부터 수정.

ERR_TOO_MANY_REDIRECTS

Flexible과 원본 HTTPS 강제 전환이 충돌하거나, Cloudflare와 원본이 서로 반대 방향으로 리디렉션하거나, WordPress URL이 다를 때 생길 수 있습니다. 원본 HTTPS를 정상화하고 Full (strict)을 사용한 뒤 중복 규칙을 하나씩 걷어냅니다.

인증서 발급 실패

인증서에 넣은 모든 호스트가 해당 인스턴스로 도달하는지, 80·443이 열려 있는지 확인합니다. Proxied 경로 때문에 진단이 어렵다면 일시적으로 DNS only로 바꿔 고정 IP 직접 연결부터 검사해요.

Mixed Content

주소창은 HTTPS인데 일부 이미지나 스크립트가 차단된다면 과거 콘텐츠나 테마 설정에 http:// 절대 URL이 남은 경우가 많습니다. 브라우저 개발자 도구에서 차단 URL을 찾고 원본 데이터와 테마 설정을 수정합니다. Cloudflare 자동 재작성만으로 숨겨놓으면 나중에 또 만남.

재시작 뒤 사이트 단절

DNS에 동적 공인 IP를 넣었을 가능성이 있습니다. 고정 IP를 붙이고 Cloudflare A 레코드도 그 주소로 갱신합니다.

`bncert` 명령을 찾을 수 없음

신규 Lightsail 패키지에 Bitnami 전용 절차를 적용했는지 확인합니다. blueprint vendor가 Lightsail이라면 Lightsail의 WordPress 설정 워크플로를 사용합니다.

결국 핵심은 원본 HTTPS와 공급자 구분

AWS Lightsail로 WordPress 기술 블로그를 만드는 작업 자체는 어렵지 않습니다. 다만 고정 IP → Cloudflare 권한 DNS → 원본 Let’s Encrypt HTTPS → Full (strict) 순서를 뒤섞지 않는 게 핵심이에요.

신규 구축은 Lightsail 패키지 블루프린트를 우선하고, 기존 Bitnami 문서는 별도 경로로 구분합니다. Cloudflare는 원본 HTTPS를 대신하는 마법 버튼이 아니고, 스냅샷 역시 복원 시험을 안 하면 마음의 위안에 가까움.

공식 문서 기반으로 처음 구축하는 분이라면 이 순서대로 하나씩 검증해볼 만합니다. 저는 실제 환경에서 성공했다고 꾸미기보다, 다음 단계에서 HuntLab 환경의 DNS·인증서·Draft 발행까지 검증 결과를 따로 남겨볼 생각이에요.

참고한 공식 문서

AWSLightsail #워드프레스 #WordPress #Cloudflare #HTTPS #기술블로그 #서버구축

AWS Lightsail로 WordPress 기술 블로그 구축하기 Cloudflare HTTPS 설정

먼저 완성 구조부터 잡고 시작하기

2026년에는 WordPress 블루프린트 공급자부터 확인하기

준비물과 비용은 이렇게 계산하기

1단계 Lightsail WordPress 인스턴스 만들기

2단계 고정 IP와 방화벽 설정하기

3단계 Cloudflare를 권한 DNS로 연결하기

4단계 A·CNAME 레코드에 고정 IP 연결하기

5단계 Lightsail 원본에 HTTPS 인증서 설치하기

기존 Bitnami라면 경로가 다릅니다

6단계 Cloudflare를 Full (strict)으로 바꾸기

7단계 WordPress 운영 설정과 백업 챙기기

구축 완료 후 이 순서로 검증하기

DNS

HTTPS

WordPress와 복구

자주 막히는 오류는 여기부터 보기

Cloudflare 526 오류

ERR_TOO_MANY_REDIRECTS

인증서 발급 실패

Mixed Content

재시작 뒤 사이트 단절

`bncert` 명령을 찾을 수 없음

결국 핵심은 원본 HTTPS와 공급자 구분

참고한 공식 문서

AWSLightsail #워드프레스 #WordPress #Cloudflare #HTTPS #기술블로그 #서버구축

WordPress REST API 재시도에서 429와 5xx만 구분한 이유

Cloudflare Workers 메모리 지표로 배포 후 메모리 회귀와 Exceeded Memory 오류 찾기

Cloudflare Agents SDK를 AI SDK v7로 업그레이드하고 스트리밍·도구 호출 회귀 테스트하기

답글 남기기 응답 취소

먼저 완성 구조부터 잡고 시작하기

2026년에는 WordPress 블루프린트 공급자부터 확인하기

준비물과 비용은 이렇게 계산하기

1단계 Lightsail WordPress 인스턴스 만들기

2단계 고정 IP와 방화벽 설정하기

3단계 Cloudflare를 권한 DNS로 연결하기

4단계 A·CNAME 레코드에 고정 IP 연결하기

5단계 Lightsail 원본에 HTTPS 인증서 설치하기

기존 Bitnami라면 경로가 다릅니다

6단계 Cloudflare를 Full (strict)으로 바꾸기

7단계 WordPress 운영 설정과 백업 챙기기

구축 완료 후 이 순서로 검증하기

DNS

HTTPS

WordPress와 복구

자주 막히는 오류는 여기부터 보기

Cloudflare 526 오류

ERR_TOO_MANY_REDIRECTS

인증서 발급 실패

Mixed Content

재시작 뒤 사이트 단절

bncert 명령을 찾을 수 없음

결국 핵심은 원본 HTTPS와 공급자 구분

참고한 공식 문서

AWSLightsail #워드프레스 #WordPress #Cloudflare #HTTPS #기술블로그 #서버구축

Similar Posts

답글 남기기 응답 취소

`bncert` 명령을 찾을 수 없음