테마
Kiro Crew 멀티 인스턴스 · Remote Crew
선행 학습
Crew의 개념과 아키텍처는 Kiro Crew, 설치·시작은 Kiro Crew 설치 및 시작에서 먼저 확인하세요. AWS 운영 관점은 IT 자동화와도 이어집니다.
한 줄 요약
Crew는 로컬뿐 아니라 원격 하드웨어에서도 동작합니다. 클라우드 런처가 EC2 박스를 프로비저닝하면 이를 Instances 레지스트리에 등록하고, 대시보드의 Settings → Remote Crew 페이지에서 터널 열기·단기 토큰 발급·웜 유지·연결 자가 복구를 관리합니다.
로컬 Crew가 "내 노트북에서 도는 상주 에이전트"라면, Remote Crew는 "클라우드에서 항상 켜져 있고, 내 노트북을 닫아도 계속 일하는 에이전트"입니다. always-on 자동화의 전제를 하드웨어 수준에서 완성합니다.
먼저 선택할 기본 연결 방식
새 EC2 배치는 네이티브 SSM을 먼저 선택하세요. SSH 키와 인바운드 포트 없이 AWS IAM과 Session Manager로 연결할 수 있습니다. 기존 SSH 프록시 자산을 반드시 재사용해야 할 때만 레거시 SSH를 검토합니다.
연결 방식 세 가지
Instances 레지스트리는 connection_method 값으로 세 가지를 지원합니다.
connection_method | 대상 | 비고 |
|---|---|---|
ssm | EC2 박스 | 런치된 박스의 새 기본값 (네이티브 SSM 전송) |
ssh | EC2 박스 | 레거시 — SSM ProxyCommand 위의 SSH |
fargate | ECS 태스크 | 멀티 인스턴스/컨테이너 배치용 |
네이티브 SSM vs 레거시 SSH (EC2)
두 방식 모두 원격의 loopback 바인딩 게이트웨이라는 같은 지점에서 끝나지만, 거기에 도달하는 방법이 크게 다릅니다.
네이티브 SSM (connection_method="ssm") — 런치 박스 기본값
게이트웨이가 aws ssm start-session 포트 포워드(AWS-StartPortForwardingSession)를 직접 구성하고, aws ssm send-command로 대시보드 토큰을 발급합니다. 어떤 계층에도 SSH가 관여하지 않습니다.
- 원격 요구사항: SSM 에이전트(Amazon Linux에 기본 설치)와 Session Manager를 허용하는 인스턴스 역할만 있으면 됩니다.
- 클라이언트 요구사항:
awsCLI +session-manager-plugin. 터널은ssm:StartSession으로 열고, 토큰·원격 명령에는ssm:SendCommand·ssm:GetCommandInvocation이 추가로 필요합니다. kirocrew cloud iam-policy가 런처가 관리하는 리소스 범위로 제한된 정책을 출력합니다.
레거시 SSH over ProxyCommand (connection_method="ssh")
네이티브 전송이 생기기 전에는, SSM 전용 박스를 인스턴스 id를 ssh_host로 등록하고 운영자가 ~/.ssh/config에 aws ssm start-session을 감싸는 ProxyCommand를 손으로 추가해 접근했습니다. 게이트웨이는 그 프록시를 통해 일반 ssh -N -L을 실행합니다.
여전히 유효한 수동 옵션이지만, 런치 박스에서는 "한 줄 프로비저닝"이 런처가 관리하지 않는 세 가지(원격의 sshd 실행, 클라이언트 SSH 키, 올바른 ~/.ssh/config) 에 조용히 의존하게 됩니다. SSM 관리 인스턴스의 표준 하드닝(zero SSH ingress, 분산 키 없음)에서는 이 경로가 아예 연결되지 않습니다.
나란히 비교
| 항목 | 네이티브 SSM (신규) | 레거시 SSH-over-ProxyCommand |
|---|---|---|
connection_method | ssm | ssh |
| 대상 레지스트리 필드 | ssm_target (i-…/mi-…) | ssh_host (ssh config로 해석되는 인스턴스 id) |
| 박스의 인바운드 SSH 포트 | 없음 | 필요 (sshd 도달 가능해야 함) |
| 클라이언트 SSH 키 | 없음 | 필요 |
~/.ssh/config 편집 | 없음 | 필요 (수기 ProxyCommand) |
원격 sshd | 불필요 | 필요 |
| 도달성 제어 주체 | IAM(ssm:StartSession), CloudTrail 감사 | SSH 키 소유 + 로컬 ssh config |
| zero-ingress 하드닝에서 동작 | 예 | 아니오 |
| 터널·토큰 갱신·웜셋·자가복구 | 동일 | 동일 |
TL;DR — 런치된 박스는 이제 SSH 키 없이, 인바운드 포트 없이,
~/.ssh/config수정 없이 Instances로 도달할 수 있습니다. 도달성은 누군가 쥔 키로 통제되는 네트워킹 결정이 아니라,ssm:StartSession을 부여/회수하는 IAM 결정(CloudTrail 감사) 이 됩니다.
인증 경계 — 터널 + 단기 토큰
IAM은 "누가 터널을 열 수 있는가"를 통제합니다. 터널이 열린 뒤 실제 대시보드 접근은 게이트웨이가 aws ssm send-command로 발급하는 단기(short-lived) 토큰이 부여합니다. 즉 두 겹입니다: (1) ssm:StartSession 권한으로 포트 포워드를 열고, (2) 그 위에서 수명이 짧은 대시보드 토큰으로 세션을 인증합니다. 토큰이 단기이므로 유출되더라도 노출 창이 제한됩니다.
참고: 연결된 remote crew에서 작업을 시작하는 흐름(0.6)의 일부는 Preview 단계입니다. 운영 전환 전 공식 changelog로 성숙도를 확인하세요.
Fargate(ECS) 배치
컨테이너 기반 멀티 인스턴스는 ECS 태스크로 동작하며, 공개 리스너나 내장 원격 대시보드 없이 SSM 포워드로 turn API에 도달합니다. cloud 설정의 선택적 fargate 블록에서 Fargate 배치, digest로 고정된 이미지, 시크릿 참조를 구성합니다.
언제 쓰나 — 결정 가이드
| 상황 | 권장 |
|---|---|
| 혼자 쓰는 상주 에이전트, 노트북 상시 켬 | 로컬 Crew |
| 노트북을 닫아도 cron·webhook이 계속 돌아야 함 | Remote Crew (EC2 + 네이티브 SSM) |
| SSH 키/포트를 열 수 없는 하드닝 환경 | 네이티브 SSM (SSH 경로는 불가) |
| 여러 격리 인스턴스를 컨테이너로 운영 | Fargate(ECS) |
| 기존 SSH 키/프록시 자산을 재사용해야 함 | 레거시 SSH (수동 옵션) |
🚨 유의사항
- 새 배치는 네이티브 SSM을 기본으로 쓰세요. SSH 경로는 하드닝 환경에서 연결 불가하며 런처가 관리하지 않는 자산에 의존합니다.
- IAM이 도달성의 단일 통제점이므로,
ssm:StartSession권한 부여·회수를 접근 제어의 핵심으로 다루고 CloudTrail 로그를 모니터링하세요.
참고 링크
| 리소스 | URL |
|---|---|
| 공식 문서 — Multi-instance | kiro.dev/docs/crew/features/multi-instance/ |
| 소스 — SSM vs SSH 가이드 | github.com/kirodotdev/KiroCrew — docs/guides/cloud-instance-ssm-vs-ssh.md |
| 소스 — instances 모듈 스펙 | github.com/kirodotdev/KiroCrew — docs/system-specs/modules/instances.md |
✅ 핵심 요약
Remote Crew = 원격 하드웨어에서 돌아가는 Crew. EC2는 네이티브 SSM(키·포트·ssh config 불필요, IAM으로 통제)을 기본으로, ECS는 Fargate 블록으로 배치합니다. 도달성은 네트워킹이 아니라 IAM 결정입니다.
이 문서의 공식 내용은 라이선스 준수를 위해 재구성·요약되었습니다. 정확한 원문은 위 참고 링크를 확인하세요.