AWS 13 IoT — IoT Core·Greengrass·SiteWise·Device Defender
냉장 창고 백 곳에 온도 센서를 열 개씩 달았다고 해 봅니다. 센서 천 개가 1분마다 온도를 보내고, 서버는 문이 열린 창고의 냉각기를 원격으로 켜야 합니다. 평소 하던 대로 HTTP API 를 하나 열어 받으면 될 것 같지만 금방 걸립니다. 서버가 센서에게 먼저 말을 걸 길이 없고, 센서마다 비밀번호를 어떻게 나눠 줄지 정해야 하며, 창고 인터넷이 끊긴 동안의 값은 사라집니다.
이 편은 기기를 클라우드에 붙일 때 AWS 가 맡아 주는 서비스 넷을 봅니다. 입구인 IoT Core, 현장 컴퓨터를 관리하는 Greengrass V2, 설비 값을 묶어 쌓는 IoT SiteWise, 인증서·권한 설정을 점검하는 IoT Device Defender Audit 입니다. 요금과 한도는 전부 2026-11-13 서울(ap-northeast-2) 기준입니다. 서울 단가는 각 서비스 요금 페이지가 쓰는 AWS 가격 목록(Price List)에서 확인했습니다.
지도
flowchart TD
DEV["센서·기기<br/>인터넷이 되는 곳"] -->|"MQTT · 인증서"| CORE["IoT Core<br/>기기 연결 입구"]
LOCAL["현장 센서<br/>공장 설비"] --> GG["Greengrass V2<br/>현장 게이트웨이"]
GG -->|"거르고 모아서"| CORE
GG -->|"설비 값"| SW["IoT SiteWise<br/>설비 데이터"]
CORE -->|"메시지 넘기기"| DEST["S3 · DynamoDB · Lambda<br/>Firehose · SiteWise"]
DD["Device Defender Audit"] -.->|"인증서 · 정책 점검"| CORE
기기가 인터넷에 바로 닿는다면 IoT Core 에 붙습니다. 현장에 기기가 많거나 인터넷이 자주 끊기면 그 안에 Greengrass 를 깐 컴퓨터를 하나 두고, 그 컴퓨터가 모아서 올립니다. 공장 설비처럼 「어느 라인의 어느 모터」라는 구조가 중요한 값은 SiteWise 로 보내고, Device Defender Audit 은 이 길 옆에서 설정을 점검합니다. IoT Core 가 데이터를 넘기는 곳인 Firehose·Kinesis 는 07-3편에서, 센서 값을 쌓는 시계열 DB 는 03-3편에서 봤습니다.
1. IoT Core — 기기가 붙는 입구
기기 1만 대가 하루 종일 붙어 있으려면 서버는 무엇을 해 줘야 할까요? 웹 요청은 클라이언트가 묻고 서버가 답하면 끝나지만, 기기는 연결을 열어 둔 채 값을 올리고 서버가 보내는 명령도 그 연결로 받아야 합니다. 이 일에 널리 쓰는 규약이 MQTT 입니다. 기기는 warehouse/12/temp 같은 토픽(메시지에 붙이는 주소)에 메시지를 게시하고, 받고 싶은 쪽은 그 토픽을 구독합니다. 07-1편의 SNS 와 같은 게시·구독인데, 작은 기기가 오래 붙어 있도록 가볍게 만든 규약입니다.
IoT Core 는 이 MQTT 를 받는 메시지 브로커를 관리형으로 내줍니다. MQTT 3.1.1 과 5 를 받고, 브라우저처럼 웹소켓만 되는 곳은 MQTT over WSS(WebSocket Secure, TLS 위의 웹소켓)로, 게시만 하면 되는 기기는 HTTPS 로 붙습니다. 메시지 배달 보장 수준(QoS)은 0(한 번 보내고 끝)과 1(받았다는 응답이 올 때까지 다시 보냄)만 되고, MQTT 규격의 2(정확히 한 번)는 지원하지 않습니다(MQTT). 메시지 하나는 128 KB 를 넘을 수 없어서, 사진이나 로그 묶음 같은 큰 파일은 S3 로 올립니다(AWS IoT Core endpoints and quotas).
기기마다 인증서를 준다
기기가 붙으려면 먼저 IoT Core 가 그 기기를 알아야 합니다. 기기 하나를 사물(thing)로 등록하면 기기 목록과 속성을 두는 레지스트리에 올라갑니다.
붙을 때는 보통 X.509 인증서로 자기가 누구인지 밝힙니다. 사물에 인증서를 붙여 두면 기기는 연결할 때 그 인증서를 내밀고, IoT Core 는 어느 사물인지 압니다. 모바일 앱은 Cognito 신원으로, 서버 쪽 프로그램은 IAM 으로 붙을 수도 있습니다(Client authentication). 비밀번호를 기기에 심어 두는 대신 기기마다 하나씩 끊을 수 있는 신원을 주는 셈입니다.
인증서로 붙은 기기가 무엇을 할 수 있는지는 IoT 정책이 정합니다. 정책은 IAM 정책과 비슷한 JSON 문서로, 이 인증서가 어느 클라이언트 ID 로 붙고 어느 토픽에 게시·구독할 수 있는지 적습니다. 클라이언트 ID 는 연결 하나를 가리키는 이름이라, 같은 ID 로 다른 기기가 붙으면 먼저 붙어 있던 연결이 끊깁니다(MQTT).
꺼져 있는 기기에 명령을 남긴다
냉각기가 잠깐 꺼져 있을 때 「켜라」는 명령을 보내면 받을 쪽이 없습니다. 디바이스 섀도(Device Shadow)는 사물마다 클라우드에 두는 상태 문서(JSON)입니다. 애플리케이션이 섀도에 「원하는 상태: 켜짐」을 적어 두면, 기기가 다시 붙을 때 그 차이를 받아 맞추고 「지금 상태: 켜짐」을 보고합니다. 애플리케이션은 기기가 붙어 있든 아니든 섀도만 읽고 씁니다(AWS IoT Device Shadow service).
섀도 없이도 기기가 지속 세션으로 붙어 있었다면, 끊긴 동안 브로커가 그 기기가 구독한 메시지를 대신 들고 있다가 다시 붙을 때 넘깁니다. 다만 기본 1시간이 지나면 버리므로, 오래 꺼져 있을 수 있는 기기에 남길 명령은 섀도에 둡니다(AWS IoT Core endpoints and quotas).
들어온 메시지를 AWS 서비스로 넘긴다
브로커에 들어온 메시지를 저장하거나 처리하려면 누군가 구독해서 꺼내야 합니다. 그 일을 코드 없이 하는 것이 규칙 엔진입니다. 규칙은 SELECT temp FROM 'warehouse/+/temp' WHERE temp > 8 처럼 SQL 비슷한 문장으로 토픽과 조건을 고르고, 걸린 메시지를 액션으로 넘깁니다. 액션으로 S3·DynamoDB·Lambda·SQS·SNS·Kinesis·Firehose·SiteWise·Step Functions·HTTP 주소·Kafka 등을 걸 수 있습니다(Rules for AWS IoT).
메시지를 다른 기기가 구독할 일이 없고 규칙으로만 넘기면 된다면 Basic Ingest 를 씁니다. 토픽 앞에 $aws/rules/규칙이름 을 붙여 게시하면 브로커를 건너뛰고 규칙으로 바로 가며, 메시지 요금이 붙지 않습니다. 대신 그 토픽은 누구도 구독할 수 없습니다(Reducing messaging costs with Basic Ingest).
요금
IoT Core 는 붙어 있는 시간, 오간 메시지, 섀도·레지스트리 조작, 규칙 실행을 각각 셉니다. 메시지는 기기가 보낸 것과 구독자가 받은 것을 각각 한 건으로 칩니다(AWS IoT Core pricing).
IoT Core · 서울 · 2026-11-13
연결 100만 분당 $0.096 (1분 단위)
메시지 100만 건당 $1.20 (달마다 첫 10억 건)
다음 40억 건 $0.96 · 그 위 $0.84
5 KB 마다 한 건 (8 KB 짜리 = 2건)
섀도·레지스트리 조작 100만 건당 $1.50 (1 KB 단위)
규칙 실행 100만 건당 $0.18
규칙 액션 100만 건당 $0.18
무료 2025-07-15 이전 가입 계정만, 첫 12개월 매달
연결 225만 분 · 메시지 50만 건 · 섀도·레지스트리 22.5만 건
· 규칙 실행·액션 각 25만 건
(그 뒤 가입 계정은 대신 최대 $200 프리 티어 크레딧)
이 단가로 창고 예를 키워 봅니다. 센서 1만 대가 늘 붙어 있고 1분마다 5 KB 이하 메시지를 하나씩 보내며, 규칙 하나가 그것을 액션 하나로 넘긴다고 둡니다. 무료 한도는 뺍니다.
IoT Core · 서울 · 30일 · 센서 1만 대
1분마다 한 건 30 × 24 × 60 = 43,200건/대
전체 1만 × 43,200 = 4억 3,200만 (분·건) = 432 × 100만
연결 432 × $0.096 = $41.47
메시지 432 × $1.20 = $518.40
규칙 432 × ($0.18 + $0.18) = $155.52
합계 $715.39 (대당 약 $0.072)
Basic Ingest 로 보내면 메시지 요금이 빠진다
연결 + 규칙 $196.99 (대당 약 $0.020)
청구서의 대부분은 메시지 요금입니다. 다른 기기가 구독할 일이 없는 원격 측정이라면 Basic Ingest 하나로 요금이 4분의 1 남짓으로 줄어듭니다. IoT Core 가 맞는지는 기기가 연결을 열어 둔 채 명령까지 받아야 하느냐로 정해집니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 기기 수천~수십만 대가 연결을 열어 두고 서버 명령도 받아야 한다 | 기기 몇 대가 가끔 HTTP 로 값을 올릴 뿐이다(→ API Gateway) | 인증서 발급·교체와 IoT 정책을 기기 수만큼 관리한다 |
| 기기 데이터를 S3·DynamoDB·Lambda 로 갈라 보낸다(규칙) | 기기가 사진·로그 묶음 같은 큰 파일을 올린다(→ S3 로 올린다) | 메시지 128 KB 상한, 메시지·규칙 실행·액션이 각각 청구된다 |
| MQTT 는 쓰되 브로커 서버는 운영하고 싶지 않다 | QoS 2 나 특정 브로커 플러그인이 꼭 필요하다(→ 브로커를 직접 띄운다) | AWS 방식의 토픽 규칙·정책·한도에 맞춰야 한다 |
이미 ActiveMQ 의 MQTT 로 붙어 돌던 시스템이라면 07-1편의 Amazon MQ 로 옮기는 길도 있습니다. MQTT 브로커를 EC2 에 직접 띄우는 구성과 IoT Core 를 끝에서 끝까지 견주는 일은 조합 편 27(IoT 데이터 수집)에서 합니다.
2. Greengrass V2 — 현장에서 모으고 거른다
창고 인터넷이 하루에 몇 번씩 끊긴다면, 또는 센서 백 개가 각자 클라우드에 붙는 것이 아깝다면 어떻게 할까요? 현장에 작은 리눅스 컴퓨터를 하나 두고 센서는 그 컴퓨터에 붙게 하면 됩니다. 그 컴퓨터가 값을 거르고 모아 클라우드로 올리고, 끊긴 동안에는 쌓아 둡니다. 문제는 현장 수백 곳에 흩어진 그 컴퓨터들의 프로그램을 어떻게 깔고 고치느냐입니다.
Greengrass 는 이 현장 컴퓨터에 까는 오픈소스 런타임과, 그 런타임을 원격으로 관리하는 클라우드 서비스입니다. 리눅스(라즈베리 파이 OS 포함)와 윈도우, Arm 과 x86 에서 돌고, 런타임을 깐 기기를 코어 기기(core device)라고 부릅니다. 코어 기기도 IoT Core 의 사물이라 1절의 인증서로 붙습니다(How AWS IoT Greengrass works).
코어 기기에서 도는 프로그램은 전부 컴포넌트로 만듭니다. 컴포넌트는 무엇을 어떻게 실행할지 적은 레시피(JSON·YAML)와 실제 코드·바이너리인 아티팩트로 이뤄집니다. 안에 든 것은 Lambda 함수(리눅스 코어 기기만), Docker 컨테이너, 일반 OS 프로세스 무엇이든 됩니다(Greengrass feature compatibility). MQTT 브리지, 스트림 매니저처럼 AWS 가 미리 만들어 둔 공개 컴포넌트도 있습니다.
컴포넌트를 기기에 내려보내는 일이 배포입니다. 클라우드에서 컴포넌트와 설정을 고르고 대상을 정하면 각 기기가 받아 깝니다. 대상은 기기 하나일 수도, 사물을 묶어 한 번에 다루는 단위인 사물 그룹일 수도 있습니다. 그룹에 배포해 두면 이후 바꾼 내용도 그 그룹에 계속 반영됩니다.
끊겨도 잃지 않는다
현장 센서는 클라이언트 기기로 코어 기기에 MQTT 로 붙습니다. 코어 기기는 그 메시지를 컴포넌트로 거르고 묶은 뒤 IoT Core 로 중계합니다.
많은 양을 올릴 때는 스트림 매니저 컴포넌트가 데이터를 기기 안에 쌓아 두었다가, 연결이 살아 있을 때 Kinesis Data Streams·SiteWise·S3 로 내보냅니다. 보관 크기와 기간, 쓸 대역폭, 무엇을 먼저 올릴지를 스트림마다 정합니다(Manage data streams on Greengrass core devices).
코어 기기에서 컴포넌트를 받아 띄우고 관리하는 본체 프로그램을 nucleus 라고 부릅니다. 자바로 짠 원래 판은 JRE(Java Runtime Environment) 위에서 돌고 메모리가 100 MB 안팎 필요합니다(Greengrass nucleus). C 로 짠 nucleus lite 는 메모리가 수십 MB 뿐인 리눅스 기기에서도 돕니다(Greengrass nucleus lite). 다만 lite 는 Lambda 컴포넌트와, 현장 센서를 클라이언트 기기로 받는 기능을 아직 지원하지 않습니다. 센서를 모으는 게이트웨이로 쓰려면 자바 판을 깝니다.
V1 은 2026-10-07 완전 종료되어 API 와 리소스가 남아 있지 않습니다. 지금 Greengrass 라고 하면 V2 입니다(AWS Lifecycle Changes · 완전 종료).
요금
Greengrass 는 그달에 AWS 에 인증하며 붙은 코어 기기 수로 받습니다. 현장 센서가 코어 기기에 붙는 것에는 요금이 없지만, 코어 기기가 IoT Core 로 올리는 연결·메시지에는 1절 요금이 붙습니다(AWS IoT Greengrass pricing).
Greengrass · 서울 · 2026-11-13
코어 기기 그달 붙은 기기 하나에 $0.18
현장 센서 코어 기기에 붙는 것은 0원
무료 매달 코어 기기 3대, 1년
(2025-07-15 이전 가입 계정의 프리 티어)
1절의 센서 1만 대를 창고 100곳에 100대씩 나눠, 창고마다 코어 기기 하나가 센서 값을 1분마다 5 KB 이하 요약 하나로 묶어 올린다고 해 봅니다. 규칙은 1절과 같이 하나, 액션도 하나입니다.
Greengrass 경유 · 서울 · 30일 · 코어 기기 100대
올리는 메시지 100 × 43,200 = 432만 건 = 4.32 × 100만
(연결도 432만 분)
Greengrass 100 × $0.18 = $18.00
연결 4.32 × $0.096 = $0.41
메시지 4.32 × $1.20 = $5.18
규칙 4.32 × ($0.18 + $0.18) = $1.56
합계 $25.15
센서마다 IoT Core 에 붙을 때의 $715.39 와 견주면 AWS 청구서는 28분의 1 정도입니다. 다만 이 요금에는 현장 컴퓨터 100대의 하드웨어와 설치·고장 대응이 빠져 있습니다. 클라우드에서 센서 하나하나의 값을 보지 못하게 되는 것도 치르는 몫입니다. 현장 컴퓨터 100대를 사서 돌볼 수 있느냐가 남은 물음입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 현장 인터넷이 자주 끊겨도 데이터를 잃으면 안 된다 | 기기마다 인터넷이 늘 되고 각자 IoT Core 에 붙으면 된다 | 현장 컴퓨터를 사서 깔고 고장 나면 갈아야 한다 |
| 센서 값을 현장에서 거르고 모아 메시지 수를 줄인다 | 클라우드에서 센서 하나하나의 원본 값이 필요하다 | 거른 만큼 원본이 클라우드에 남지 않는다 |
| 현장 수백 곳의 프로그램을 한 번에 배포·갱신한다 | 현장 기기가 한두 대라 손으로 관리해도 된다 | 컴포넌트·레시피라는 Greengrass 방식으로 프로그램을 싸야 한다 |
| 메모리 수십 MB 짜리 작은 리눅스 기기에서 돌린다(lite) | 그 작은 기기가 센서를 MQTT 로 받아야 한다 | lite 는 클라이언트 기기와 Lambda 컴포넌트를 아직 받지 않는다 |
기기가 몇 대뿐이고 인터넷이 늘 된다면 Greengrass 없이 AWS IoT Device SDK 로 IoT Core 에 바로 붙으면 됩니다.
3. IoT SiteWise — 공장 설비를 모델로 묶는다
공장 데이터는 창고 온도와 무엇이 다를까요? 값 하나가 「2공장 3라인 포장기 모터의 회전수」처럼 설비의 층 구조 안에 있고, 보고 싶은 것도 원시 값보다 가동률이나 고장 사이 평균 시간 같은 설비 지표입니다. IoT Core 로 받아 시계열 DB 에 쌓으면 이 구조와 지표 계산을 내가 다 짜야 합니다.
IoT SiteWise 는 산업 설비의 데이터를 모아 설비 단위로 정리하고 쌓는 관리형 서비스입니다. 먼저 자산 모델(asset model)을 정의합니다. 「포장기에는 회전수·온도 측정값이 있고, 분당 생산량은 이렇게 계산한다」 같은 설비 종류의 틀입니다. 그 모델로 실제 설비마다 자산(asset)을 만들어 공장 → 라인 → 설비로 엮습니다.
계산도 모델에 적습니다. 들어오는 값마다 바로 하는 계산(변환)과 정해 둔 주기마다 하는 계산(지표)을 적어 두면 SiteWise 가 계산합니다. 평균·합계·개수 같은 집계도 기간별로 알아서 만듭니다(What is AWS IoT SiteWise?).
값은 세 길로 들어옵니다. 공장 안에서는 Greengrass V2 위에 까는 SiteWise Edge 게이트웨이가 설비의 OPC UA(Open Platform Communications Unified Architecture) 서버에서 값을 읽습니다. OPC UA 는 공장 설비가 값을 내주는 표준 규격이고, 게이트웨이 하나가 OPC UA 서버를 100개까지 받습니다. 인터넷으로 붙는 기기는 IoT Core 규칙의 SiteWise 액션으로 넣습니다. 애플리케이션은 SiteWise API 로 넣습니다.
공장 설비가 값을 내주는 규격은 OPC UA 말고도 Modbus 등이 있습니다. 그쪽은 AWS 파트너가 만든 Greengrass 컴포넌트를 게이트웨이의 데이터 원본으로 붙여 받습니다(Data processing pack availability change).
게이트웨이가 하는 일은 둘로 나뉩니다. 값을 모아 클라우드로 올리는 수집 기능(데이터 수집 팩)과, 현장에서 변환·지표를 계산하고 쌓아 두는 처리 기능(데이터 처리 팩)입니다. 지금 새로 만드는 게이트웨이는 모은 값을 MQTT 로 넘기는 V3 게이트웨이이고, 계산은 클라우드 쪽 SiteWise 가 합니다(MQTT-enabled, V3 gateways).
쌓인 값은 세 층에 둡니다. 최근 값을 빨리 읽는 핫 층, 분석용으로 싸게 두는 웜 층, 그리고 내 S3 버킷에 6시간마다 복제해 두는 콜드 층입니다. 핫 층에 보존 기간을 정해 두면 지난 값이 웜이나 콜드로 내려갑니다(Manage data storage in AWS IoT SiteWise).
접히는 기능 둘
지금 SiteWise 를 새로 시작하면 무엇을 못 쓸까요? 두 기능이 2025-10-07 에 유지보수 단계로 넘어갔습니다. 지금 새 고객은 쓸 수 없습니다(Services in Maintenance).
하나는 공장 사람들이 보는 웹 대시보드를 만들던 SiteWise Monitor 입니다. AWS 는 Managed Grafana 의 SiteWise 플러그인으로 옮기라고 권합니다(AWS IoT SiteWise Monitor availability change). 다른 하나는 앞에서 본 게이트웨이의 처리 기능, 데이터 처리 팩입니다. 수집 팩과 SiteWise 자체는 계속 쓸 수 있습니다(Data processing pack availability change). 새로 시작한다면 SiteWise 는 「모으고, 모델로 묶고, 계산해 쌓는」 서비스로 보면 됩니다. 화면은 Grafana 로 붙입니다.
요금
SiteWise 는 넣고 읽은 메시지, 계산 횟수, 층별 저장량, 쿼리가 훑은 양으로 요금을 받습니다. 실시간 적재는 1 KB 또는 데이터 점 10개마다 메시지 한 건으로 셉니다. 웜 층에서 읽을 때는 한 번 읽을 때마다 측정값 하나(데이터 스트림)에 최소 메시지 10건(200 KB)으로 셉니다(AWS IoT SiteWise pricing).
IoT SiteWise · 서울 · 2026-11-13
메시지(적재·조회) 100만 건당 $1.30
계산(변환·지표·집계) 100만 건당 $0.65
핫 층 저장 GB-일 $0.013 (30일이면 GB당 $0.39)
웜 층 저장 GB-일 $0.0013 (30일이면 GB당 $0.039)
콜드 층 내 S3 요금 + 내보내기 객체 1,000개당 $0.0065
쿼리 훑은 GB당 $0.26
Edge 수집 팩 0원 (Greengrass 요금만 붙는다)
AWS 요금 페이지의 예시처럼 설비 10대가 1초에 값 하나씩 보내고, 값마다 한 건으로 적재되며 자동 집계가 값마다 한 번 돈다고 해 봅니다. 핫 층에는 한 달 내내 1 GB 를 둔다고 둡니다.
IoT SiteWise · 서울 · 30일 · 설비 10대
1초마다 값 하나 10 × 86,400 × 30 = 2,592만 건 = 25.92 × 100만
적재 25.92 × $1.30 = $33.70
계산 25.92 × $0.65 = $16.85
핫 층 1 GB × $0.39 = $0.39
합계 $50.94
적재와 계산은 설비 수와 보내는 빈도에 비례해 늘어납니다. 이 요금을 치를 만한지는 데이터에 설비의 층 구조가 있느냐에 달렸습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 공장·발전소처럼 설비가 층 구조로 엮이고 설비 지표를 봐야 한다 | 창고 온도처럼 구조 없는 값을 쌓아 그래프만 그린다(→ Timestream for InfluxDB) | 자산 모델을 먼저 설계하고 설비마다 자산을 만들어야 한다 |
| 공장 설비가 이미 OPC UA 로 값을 내준다 | 설비가 Modbus 같은 다른 규격뿐이다 | Modbus 등은 파트너 컴포넌트를 거쳐야 한다 |
| 최근 값은 빨리, 오래된 값은 싸게 둬야 한다(핫·웜·콜드) | 몇 년치 원본을 자주 다시 읽는다 | 웜 층은 한 번 읽을 때마다 측정값 하나에 최소 메시지 10건으로 센다 |
| 설비 담당자가 볼 화면은 다른 도구로 붙여도 된다 | SiteWise 안에서 대시보드까지 끝내고 싶다 | Monitor 가 막혀 Managed Grafana 를 더 붙인다 |
설비 구조가 필요 없는 센서 값이라면 IoT Core 규칙으로 S3 나 시계열 DB 에 바로 쌓는 쪽이 덜 들고 덜 복잡합니다.
4. Device Defender Audit — 설정이 느슨해지지 않았나
기기가 1만 대가 되면 누가 어떤 인증서를 쓰는지 사람이 다 볼 수 없습니다. 시험할 때 쓴 iot:* 정책이 운영 기기에 붙어 있거나, 공장에서 인증서 하나를 여러 기기에 복사해 넣었거나, 폐기한 인증서가 아직 활성으로 남아 있어도 아무도 모릅니다. 이런 설정에서는 기기 하나가 털리면 그 권한으로 다른 기기의 토픽까지 읽힙니다.
IoT Device Defender 의 Audit 은 계정과 기기 쪽 설정을 정해진 점검 항목으로 훑어 이런 틈을 찾습니다. 점검 항목에는 너무 넓은 IoT 정책, 여러 기기가 같이 쓰는 인증서, 만료가 다가오거나 폐기됐는데 활성인 인증서, 같은 클라이언트 ID 로 붙어 서로 연결을 끊어 내는 기기, 꺼져 있는 로깅 등이 있습니다. 결과는 위험도(Critical·High·Medium·Low)로 나옵니다(Audit). 필요할 때 손으로 돌리거나, 매일·매주·격주·매달 일정으로 걸어 둡니다.
찾은 문제에는 완화 작업을 붙일 수 있습니다. 인증서를 비활성으로 바꾸기, 해당 기기를 격리용 사물 그룹에 넣기, 정책에 빈 버전을 넣어 권한 막기 같은 것입니다(Mitigation actions).
Device Defender 에는 기기 행동(보낸 메시지 수, 연결 시도 같은 지표)이 평소와 다른지 보는 Detect 도 있었지만, 2026-08-31 부터 새 고객을 받지 않는 유지보수 단계입니다. AWS 가 대안으로 내놓은 것은 관리형 서비스가 아니라 내 계정에 까는 오픈소스 예제 파이프라인입니다(AWS IoT Device Defender detect feature availability change). 그래서 지금 새로 쓸 수 있는 것은 계속 정식으로 제공되는 Audit 입니다.
요금
Audit 은 그달에 활성이었던 주체(principal) 수로 받습니다. 인증서는 그달에 만들거나 바꾸거나 연결에 쓴 것이, 그 밖의 신원은 연결에 쓴 것이 활성입니다(AWS IoT Device Defender pricing).
Device Defender Audit · 서울 · 2026-11-13
활성 주체 10만 개까지 하나에 월 $0.00149
10만 개를 넘는 몫 하나에 월 $0.00135
처음 한 달 기기 전부 무료 (새 고객)
1절의 센서 1만 대라면 월 $14.90 으로, IoT Core 청구서의 2% 남짓입니다. 요금보다 먼저 정할 것은 발견을 받아 처리할 사람입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 기기·인증서가 많아 정책과 인증서 상태를 사람이 다 못 본다 | 기기가 몇 대라 콘솔에서 눈으로 확인된다 | 발견을 받아 처리할 사람이나 완화 작업을 정해 둬야 한다 |
| 공장에서 인증서를 심는 과정이 복잡해 복사·재사용이 걱정된다 | 기기가 이상하게 행동하는지 실시간으로 잡고 싶다 | Audit 은 설정만 본다. 행동 감시는 Detect 가 막혀 직접 짜야 한다 |
| IoT 쪽 설정을 정기 점검 보고서로 남겨야 한다 | 계정 전체의 보안 설정을 한 화면에서 보고 싶다 | IoT 리소스만 본다. 계정 전체 보안 점검은 다른 서비스(09편) 몫이다 |
계정 전체의 위협 탐지는 GuardDuty 가, 여러 보안 점검 결과를 한곳에 모아 보는 일은 Security Hub 가 맡습니다. 둘은 09편(보안 감시)에서 봅니다.
이럴 땐 무엇
기기가 인터넷에 바로 닿는지, 현장에 컴퓨터를 둘 수 있는지, 데이터에 설비 구조가 있는지로 세 서비스가 나뉩니다. Audit 은 어느 쪽이든 옆에 붙습니다.
| 상황 | 서비스 | 이유 |
|---|---|---|
| 기기 수천 대가 값을 올리고 원격 명령도 받는다 | IoT Core | 기기마다 끊을 수 있는 인증서로 붙이고 브로커 운영은 AWS 가 맡는다(1만 대 1분 간격 월 $715.39) |
| 다른 기기가 구독할 일 없는 원격 측정을 S3·DynamoDB 로 쌓는다 | IoT Core 규칙 + Basic Ingest | 브로커를 건너뛰어 메시지 요금이 빠진다(같은 조건 월 $196.99) |
| 꺼졌다 켜지는 기기의 설정값을 맞춘다 | IoT Core 디바이스 섀도 | 애플리케이션은 섀도만 쓰고, 기기는 붙을 때 차이를 받는다 |
| 현장 인터넷이 끊겨도 데이터를 쌓았다 올린다 | Greengrass V2 + 스트림 매니저 | 끊긴 동안 기기 안에 쌓고, 붙으면 Kinesis·S3·SiteWise 로 올린다 |
| 현장 수백 곳의 게이트웨이 프로그램을 한 번에 갱신한다 | Greengrass V2 | 컴포넌트를 사물 그룹에 배포하면 그룹 전체가 받는다(기기당 월 $0.18) |
| OPC UA 설비의 값을 설비 구조째 모아 가동률을 본다 | IoT SiteWise + SiteWise Edge | 설비 구조를 자산 모델로 두고 지표를 계산해 준다. 화면은 Managed Grafana |
| 인증서 공유·과한 정책을 정기 점검한다 | Device Defender Audit | 사람이 못 보는 설정의 틈을 정해진 점검 항목으로 잡는다(1만 대 월 $14.90) |
자주 붙는 서비스는 S3·Data Firehose(적재), DynamoDB(기기별 최신 값), Lambda(규칙 뒤 처리), Timestream for InfluxDB(시계열 저장), Managed Grafana(SiteWise 화면), CloudWatch(IoT 로그·지표), IAM(규칙이 쓰는 역할)입니다. 엮이는 방식은 조합 편 27(IoT 데이터 수집)에서 봅니다.
한 장 요약
기기를 붙이는 입구는 IoT Core 입니다. 인증서와 정책으로 기기마다 신원을 주고, 요금은 주로 메시지 수로 나갑니다. 현장에 컴퓨터를 둘 수 있으면 Greengrass 로 모아 올려 메시지와 끊김을 줄이고, 공장 설비처럼 구조가 있는 값은 SiteWise 에 모델로 쌓습니다. SiteWise Monitor 와 Device Defender Detect 는 새 고객을 받지 않으니, 화면은 Managed Grafana 로 붙이고 보안 점검은 Audit 으로 시작합니다.
관련 항목
기기를 클라우드에 잇는 AWS IoT 서비스
AWS IoT Core · AWS IoT Greengrass · AWS IoT SiteWise · AWS IoT Device Defender · AWS IoT Device Management · AWS IoT Events · AWS IoT FleetWise
IoT Core 를 이루는 장치
MQTT · MQTT 토픽 · QoS · 메시지 브로커 · 디바이스 섀도 · AWS IoT 규칙 엔진 · Basic Ingest · 지속 세션
기기 신원과 권한
X.509 인증서 · AWS IoT 정책 · 사물 레지스트리 · TLS · Amazon Cognito · IAM 역할
현장에서 도는 쪽
엣지 컴퓨팅 · Greengrass 컴포넌트 · Greengrass nucleus · 스트림 매니저 · AWS IoT Device SDK · 게이트웨이
공장 데이터를 다루는 말
OPC UA · Modbus · 자산 모델 · 설비 종합 효율 · 시계열 데이터 · 산업용 IoT
규칙이 데이터를 넘기는 곳
Amazon S3 · Amazon DynamoDB · AWS Lambda · Amazon Data Firehose · Amazon Kinesis Data Streams · Amazon Timestream · Amazon Managed Grafana
같은 시리즈에서 이어지는 편
AWS 07-1 큐와 알림 — SQS·SNS·SES·Amazon MQ · AWS 07-3 쉬지 않고 흐르는 데이터 — Kinesis Data Streams·Data Firehose·MSK · AWS 03-3 특수 목적 DB — Neptune·Timestream · AWS 05-1 누가 무엇을 할 수 있나 — IAM·IAM Identity Center·Cognito·Verified Permissions