AWS Systems Manager Session Manager로 안전한 서버 접속 완벽 가이드

AWS Systems Manager의 Session Manager를 활용하여 SSH 키 없이 프라이빗 인스턴스에 안전하게 접속하는 방법을 알아봅니다. Bastion 서버 없이도 보안을 강화하고, 모든 세션을 로깅하여 감사까지 할 수 있는 현대적인 서버 접속 방식을 배워봅니다.

---

목차

1. Session Manager의 장점
2. Bastion 서버 vs Session Manager
3. IAM 역할 생성 및 인스턴스 연결
4. Session Manager로 프라이빗 인스턴스 접속
5. 세션 로그 기록 및 감사
6. Systems Manager 추가 기능 소개

---

1. Session Manager의 장점

김개발 씨는 새로 합류한 스타트업에서 첫 업무를 받았습니다. "EC2 인스턴스에 접속해서 로그 좀 확인해 주세요." 그런데 SSH 키를 받지도 않았고, 어떻게 접속해야 할지 막막했습니다.

옆자리 박시니어 씨가 웃으며 말했습니다. "우리는 SSH 안 써요.

Session Manager로 접속하면 돼요."

Session Manager는 AWS Systems Manager의 핵심 기능 중 하나로, SSH나 RDP 없이 브라우저나 AWS CLI를 통해 EC2 인스턴스에 접속할 수 있게 해주는 서비스입니다. 마치 은행 금고에 들어갈 때 열쇠 대신 생체 인식을 사용하는 것과 같습니다.

더 안전하고, 열쇠를 잃어버릴 걱정도 없습니다.

다음 코드를 살펴봅시다.

# AWS CLI로 Session Manager 접속하기
# 먼저 Session Manager 플러그인 설치가 필요합니다

# 인스턴스 목록 확인
aws ec2 describe-instances \
    --query 'Reservations[].Instances[].[InstanceId,State.Name,Tags[?Key==`Name`].Value|[0]]' \
    --output table

# Session Manager로 인스턴스 접속
aws ssm start-session \
    --target i-0123456789abcdef0

# 접속 후 쉘에서 명령어 실행 가능
# sh-4.2$ whoami
# ssm-user

김개발 씨는 이전 회사에서 SSH 키 관리 때문에 골치가 아팠던 경험이 있습니다. 팀원이 퇴사할 때마다 모든 서버의 authorized_keys 파일을 수정해야 했고, 가끔 키가 유출되어 보안 사고가 날 뻔한 적도 있었습니다.

박시니어 씨가 차분히 설명을 시작했습니다. "Session Manager의 가장 큰 장점은 SSH 키가 필요 없다는 거예요." 기존 SSH 방식에서는 개발자마다 SSH 키 쌍을 생성하고, 공개 키를 서버에 등록해야 했습니다.

키를 안전하게 보관해야 하고, 분실하면 서버에 접속할 수 없게 됩니다. 더 심각한 문제는 키가 유출되면 누구든 서버에 접속할 수 있다는 점입니다.

Session Manager는 이 모든 문제를 해결합니다. IAM 권한만 있으면 접속할 수 있습니다.

개발자가 퇴사하면 IAM 사용자만 삭제하면 됩니다. 서버마다 일일이 키를 제거할 필요가 없습니다.

두 번째 장점은 인바운드 포트를 열 필요가 없다는 것입니다. 기존에는 SSH 접속을 위해 22번 포트를 열어두어야 했습니다.

이 포트가 공격자들의 주요 타겟이 됩니다. Session Manager는 아웃바운드 HTTPS 연결만 사용하므로 인바운드 포트를 완전히 닫아둘 수 있습니다.

세 번째 장점은 모든 세션이 자동으로 로깅된다는 점입니다. 누가 언제 어떤 서버에 접속해서 무슨 명령어를 실행했는지 모두 기록됩니다.

보안 감사가 필요할 때 매우 유용합니다. 김개발 씨가 고개를 끄덕였습니다.

"그런데 AWS 콘솔에서만 접속할 수 있나요?" 박시니어 씨가 답했습니다. "아니요, AWS CLI로도 접속할 수 있어요.

로컬 터미널에서 바로 접속할 수 있죠. 심지어 포트 포워딩도 가능해서 RDS 같은 프라이빗 리소스에도 접근할 수 있어요." Session Manager는 비용도 무료입니다.

EC2 인스턴스에 SSM Agent만 설치되어 있으면 바로 사용할 수 있습니다. Amazon Linux 2나 Ubuntu 같은 주요 AMI에는 이미 SSM Agent가 설치되어 있습니다.

실전 팁

💡 - Session Manager 플러그인을 로컬에 설치하면 AWS CLI로 편리하게 접속할 수 있습니다

• 프라이빗 서브넷의 인스턴스도 VPC 엔드포인트를 통해 접속 가능합니다
• 세션 타임아웃은 기본 20분이며, 필요에 따라 조정할 수 있습니다

---

2. Bastion 서버 vs Session Manager

다음 날, 팀 회의에서 인프라 비용 절감 방안이 논의되었습니다. 김개발 씨는 회의록을 보다가 낯선 단어를 발견했습니다.

"Bastion 서버 폐기 예정"이라고 적혀 있었습니다. 도대체 Bastion 서버가 뭐길래 폐기한다는 걸까요?

Bastion 서버는 외부에서 프라이빗 네트워크 내의 서버에 접속하기 위한 중계 서버입니다. 마치 성을 지키는 정문 초소와 같습니다.

외부인은 반드시 이 초소를 통과해야만 성 안으로 들어갈 수 있습니다. 하지만 Session Manager가 등장하면서 이 초소가 더 이상 필요 없게 되었습니다.

다음 코드를 살펴봅시다.

# 기존 Bastion 서버를 통한 접속 (복잡한 방식)
# 1단계: Bastion 서버에 SSH 접속
ssh -i bastion-key.pem ec2-user@bastion.example.com

# 2단계: Bastion에서 프라이빗 인스턴스로 다시 SSH
ssh -i private-key.pem ec2-user@10.0.1.50

# Session Manager 방식 (간단한 방식)
# 한 번에 프라이빗 인스턴스로 직접 접속
aws ssm start-session --target i-0123456789abcdef0

# 프라이빗 RDS에 포트 포워딩으로 접속하기
aws ssm start-session \
    --target i-0123456789abcdef0 \
    --document-name AWS-StartPortForwardingSessionToRemoteHost \
    --parameters '{"host":["mydb.cluster-xxx.ap-northeast-2.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작했습니다. "전통적인 아키텍처에서는 프라이빗 서브넷의 서버에 직접 접속할 수 없어요." 인터넷에서 프라이빗 서브넷으로는 직접 연결이 불가능합니다.

그래서 퍼블릭 서브넷에 Bastion 서버라는 중계 서버를 두고, 이 서버를 거쳐서 접속하는 방식을 사용했습니다. "마치 아파트 경비실을 통해 택배를 받는 것과 비슷해요.

외부인은 직접 집에 올 수 없고, 경비실을 통해야만 하죠." 하지만 Bastion 서버에는 여러 문제가 있습니다. 첫째, 운영 비용이 발생합니다.

24시간 구동되는 EC2 인스턴스이므로 월 수십 달러의 비용이 꾸준히 나갑니다. 둘째, 관리 부담이 생깁니다.

운영체제 패치, 보안 업데이트를 지속적으로 해주어야 합니다. 셋째, 가장 큰 문제는 보안 취약점입니다.

Bastion 서버 자체가 공격 대상이 됩니다. 22번 포트가 인터넷에 열려 있으므로 무차별 대입 공격의 타겟이 됩니다.

Bastion 서버가 뚫리면 내부 네트워크 전체가 위험해집니다. 김개발 씨가 물었습니다.

"그럼 Session Manager는 어떻게 이 문제들을 해결하나요?" Session Manager는 추가 인프라가 필요 없습니다. Bastion 서버를 운영할 필요가 없으니 비용도, 관리 부담도 사라집니다.

인바운드 포트를 열지 않아도 되니 공격 표면이 대폭 줄어듭니다. 작동 원리는 이렇습니다.

EC2 인스턴스에 설치된 SSM Agent가 아웃바운드 HTTPS 연결을 통해 AWS Systems Manager 서비스와 통신합니다. 사용자가 세션을 요청하면, 이 채널을 통해 안전하게 연결이 수립됩니다.

박시니어 씨가 비교표를 보여주었습니다. "Bastion은 SSH 키 관리가 필요하지만, Session Manager는 IAM으로 관리해요.

Bastion은 로그를 별도로 설정해야 하지만, Session Manager는 자동으로 로깅되죠." 회사에서 Bastion 서버를 폐기하기로 한 이유가 명확해졌습니다. Session Manager가 모든 면에서 더 나은 선택이었던 것입니다.

실전 팁

💡 - 기존 Bastion 서버가 있다면 점진적으로 Session Manager로 마이그레이션하세요

• VPC 엔드포인트를 사용하면 인터넷 게이트웨이 없이도 Session Manager를 사용할 수 있습니다
• 포트 포워딩 기능으로 RDS, ElastiCache 등 프라이빗 리소스에도 접근 가능합니다

---

3. IAM 역할 생성 및 인스턴스 연결

이제 김개발 씨는 직접 Session Manager를 설정해 보기로 했습니다. 하지만 막상 시작하려니 어디서부터 해야 할지 막막했습니다.

박시니어 씨가 다가와 말했습니다. "Session Manager를 쓰려면 먼저 IAM 역할을 만들어야 해요.

EC2가 AWS 서비스와 통신할 수 있는 권한을 줘야 하거든요."

Session Manager가 작동하려면 EC2 인스턴스에 IAM 역할이 연결되어 있어야 합니다. 이 역할은 인스턴스가 Systems Manager 서비스와 통신할 수 있는 권한을 부여합니다.

마치 회사 직원이 건물에 출입하려면 사원증이 필요한 것처럼, EC2도 AWS 서비스와 소통하려면 IAM 역할이라는 신분증이 필요합니다.

다음 코드를 살펴봅시다.

# EC2용 IAM 역할 생성을 위한 신뢰 정책 (trust-policy.json)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

# AWS CLI로 역할 생성
aws iam create-role \
    --role-name EC2-SSM-Role \
    --assume-role-policy-document file://trust-policy.json

# SSM 관리형 정책 연결
aws iam attach-role-policy \
    --role-name EC2-SSM-Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

# 인스턴스 프로파일 생성 및 역할 추가
aws iam create-instance-profile --instance-profile-name EC2-SSM-Profile
aws iam add-role-to-instance-profile \
    --instance-profile-name EC2-SSM-Profile \
    --role-name EC2-SSM-Role

박시니어 씨가 노트북을 열며 말했습니다. "IAM 역할 설정은 처음엔 복잡해 보이지만, 한 번 이해하면 간단해요." 먼저 IAM 역할이 무엇인지 알아야 합니다.

IAM 역할은 AWS 리소스에 부여하는 권한 집합입니다. 사람이 아닌 AWS 서비스나 리소스가 다른 AWS 서비스에 접근할 때 사용합니다.

"EC2 인스턴스가 Systems Manager와 통신하려면, 그 권한이 있다는 걸 증명해야 해요. 그게 바로 IAM 역할이에요." 역할을 만들 때는 두 가지를 정해야 합니다.

첫째는 신뢰 정책입니다. 누가 이 역할을 사용할 수 있는지 정의합니다.

EC2 인스턴스가 사용할 것이므로 ec2.amazonaws.com을 Principal로 지정합니다. 둘째는 권한 정책입니다.

이 역할로 무엇을 할 수 있는지 정의합니다. Session Manager를 위해서는 AmazonSSMManagedInstanceCore라는 AWS 관리형 정책을 연결합니다.

이 정책에는 SSM Agent가 Systems Manager와 통신하는 데 필요한 모든 권한이 포함되어 있습니다. 김개발 씨가 물었습니다.

"인스턴스 프로파일은 뭔가요? 역할이랑 다른 건가요?" "좋은 질문이에요.

인스턴스 프로파일은 IAM 역할을 EC2 인스턴스에 연결하기 위한 컨테이너예요. 역할을 직접 인스턴스에 붙일 수 없거든요.

인스턴스 프로파일이라는 포장지에 넣어서 붙이는 거죠." AWS 콘솔에서 역할을 만들면 인스턴스 프로파일이 자동으로 생성되지만, CLI를 사용할 때는 별도로 만들어야 합니다. 이미 실행 중인 인스턴스에도 역할을 연결할 수 있습니다.

EC2 콘솔에서 인스턴스를 선택하고, 작업 메뉴에서 "IAM 역할 수정"을 클릭하면 됩니다. 역할이 연결되면 SSM Agent가 자동으로 Systems Manager에 등록됩니다.

박시니어 씨가 덧붙였습니다. "역할을 연결한 후 몇 분 정도 기다려야 해요.

SSM Agent가 시작되고 등록되는 시간이 필요하거든요. 그 후에 Session Manager에서 인스턴스가 보일 거예요."

실전 팁

💡 - AmazonSSMManagedInstanceCore는 Session Manager 사용에 필요한 최소 권한입니다

• S3에 로그를 저장하려면 추가로 S3 쓰기 권한이 필요합니다
• 이미 실행 중인 인스턴스에도 IAM 역할을 연결할 수 있습니다

---

4. Session Manager로 프라이빗 인스턴스 접속

모든 준비가 끝났습니다. 김개발 씨는 드디어 Session Manager로 첫 접속을 시도합니다.

프라이빗 서브넷에 있는 인스턴스인데, 정말 접속이 될까요? 두근거리는 마음으로 AWS 콘솔을 열었습니다.

Session Manager를 통한 접속은 AWS 콘솔과 AWS CLI 두 가지 방법으로 가능합니다. 콘솔에서는 클릭 몇 번으로 브라우저에서 바로 터미널을 사용할 수 있고, CLI에서는 로컬 터미널에서 직접 접속할 수 있습니다.

프라이빗 서브넷의 인스턴스도 VPC 엔드포인트나 NAT Gateway만 있으면 접속이 가능합니다.

다음 코드를 살펴봅시다.

# AWS CLI로 Session Manager 접속
aws ssm start-session --target i-0123456789abcdef0

# 특정 리전의 인스턴스에 접속
aws ssm start-session \
    --target i-0123456789abcdef0 \
    --region ap-northeast-2

# 접속 가능한 인스턴스 목록 확인
aws ssm describe-instance-information \
    --query 'InstanceInformationList[*].[InstanceId,PingStatus,PlatformName]' \
    --output table

# 프라이빗 RDS에 포트 포워딩으로 로컬 접속
aws ssm start-session \
    --target i-0123456789abcdef0 \
    --document-name AWS-StartPortForwardingSessionToRemoteHost \
    --parameters '{"host":["mydb.xxx.rds.amazonaws.com"],"portNumber":["3306"],"localPortNumber":["3306"]}'

# 로컬에서 MySQL 클라이언트로 접속 (다른 터미널에서)
mysql -h 127.0.0.1 -P 3306 -u admin -p

박시니어 씨가 AWS 콘솔을 열어 보여주었습니다. "가장 쉬운 방법은 콘솔에서 직접 접속하는 거예요." EC2 콘솔에서 인스턴스를 선택하고 "연결" 버튼을 클릭합니다.

여러 연결 옵션 중 "Session Manager" 탭을 선택하면 됩니다. "연결" 버튼을 누르면 브라우저에서 바로 터미널이 열립니다.

김개발 씨가 화면을 보며 감탄했습니다. "정말 간단하네요.

SSH 클라이언트도 필요 없고, 키도 필요 없고..." 하지만 실무에서는 CLI 접속이 더 편리한 경우가 많습니다. 로컬 터미널에서 직접 작업할 수 있고, 스크립트로 자동화하기도 쉽습니다.

CLI로 접속하려면 먼저 Session Manager 플러그인을 설치해야 합니다. AWS CLI만으로는 부족하고, 별도의 플러그인이 필요합니다.

설치 후 aws ssm start-session 명령으로 접속할 수 있습니다. 박시니어 씨가 중요한 기능을 알려주었습니다.

"Session Manager의 숨은 보석은 포트 포워딩이에요." 포트 포워딩을 사용하면 프라이빗 서브넷의 RDS, ElastiCache, OpenSearch 등에 로컬에서 직접 접속할 수 있습니다. 로컬의 특정 포트를 원격 리소스의 포트로 연결해 주는 것입니다.

예를 들어, 프라이빗 RDS에 접속하고 싶다면 EC2 인스턴스를 경유해서 포트 포워딩을 설정합니다. 로컬의 3306 포트가 RDS의 3306 포트로 연결되어, MySQL Workbench 같은 도구로 바로 접속할 수 있습니다.

프라이빗 서브넷의 인스턴스가 Session Manager를 사용하려면 아웃바운드 연결이 필요합니다. NAT Gateway가 있거나, VPC 엔드포인트를 설정해야 합니다.

VPC 엔드포인트를 사용하면 인터넷을 거치지 않고 AWS 백본 네트워크를 통해 직접 연결됩니다. 김개발 씨가 성공적으로 프라이빗 인스턴스에 접속했습니다.

"와, 정말 되네요. 이 인스턴스는 퍼블릭 IP도 없고, 보안 그룹에 22번 포트도 안 열려 있는데..."

실전 팁

💡 - Session Manager 플러그인은 AWS 공식 문서에서 운영체제별로 다운로드할 수 있습니다

• VPC 엔드포인트는 ssm, ssmmessages, ec2messages 세 개가 필요합니다
• 포트 포워딩 세션은 유휴 상태가 20분 지속되면 자동으로 종료됩니다

---

5. 세션 로그 기록 및 감사

어느 날, 보안팀에서 연락이 왔습니다. "지난주에 프로덕션 서버에서 누가 어떤 작업을 했는지 확인해 주세요." 예전 같았으면 당황했을 김개발 씨지만, 이제는 자신 있게 대답했습니다.

"Session Manager 로그 확인해 드릴게요."

Session Manager의 강력한 기능 중 하나는 세션 로깅입니다. 모든 세션 활동을 S3 버킷이나 CloudWatch Logs에 자동으로 기록할 수 있습니다.

누가 언제 접속했는지, 어떤 명령어를 실행했는지 모두 남습니다. 보안 감사나 컴플라이언스 요구사항을 충족하는 데 필수적인 기능입니다.

다음 코드를 살펴봅시다.

# Session Manager 로깅 설정 (AWS CLI)
# 먼저 S3 버킷 생성
aws s3 mb s3://my-ssm-session-logs-bucket

# 버킷 정책 설정 (bucket-policy.json)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"Service": "ssm.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::my-ssm-session-logs-bucket/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                }
            }
        }
    ]
}

# CloudWatch Logs 그룹 생성
aws logs create-log-group \
    --log-group-name /aws/ssm/session-logs

# Session Manager 설정 문서 생성 (preferences.json)
{
    "schemaVersion": "1.0",
    "description": "Session Manager Preferences",
    "sessionType": "Standard_Stream",
    "inputs": {
        "s3BucketName": "my-ssm-session-logs-bucket",
        "s3KeyPrefix": "logs",
        "cloudWatchLogGroupName": "/aws/ssm/session-logs",
        "cloudWatchEncryptionEnabled": true
    }
}

박시니어 씨가 보안팀의 요청에 대해 설명해 주었습니다. "Session Manager의 로깅 기능이 바로 이럴 때 빛을 발해요." 기존 SSH 방식에서는 서버 접속 기록을 남기려면 별도의 로깅 시스템을 구축해야 했습니다.

각 서버에 감사 로그를 설정하고, 중앙 서버로 수집하는 복잡한 과정이 필요했습니다. 그리고 터미널에서 입력한 명령어까지 기록하려면 더 많은 설정이 필요했습니다.

Session Manager는 이 모든 것을 기본 기능으로 제공합니다. 세션 로그는 두 곳에 저장할 수 있습니다.

첫째는 S3 버킷입니다. 장기 보관에 적합하고, 비용이 저렴합니다.

둘째는 CloudWatch Logs입니다. 실시간 모니터링과 검색에 유리합니다.

두 곳 모두에 동시에 저장하는 것도 가능합니다. 로그에는 무엇이 기록될까요?

세션 시작 시간과 종료 시간, 접속한 IAM 사용자 정보, 대상 인스턴스 정보가 기록됩니다. 그리고 가장 중요한 터미널 출력 전체가 기록됩니다.

사용자가 입력한 명령어와 그 결과가 모두 남습니다. 김개발 씨가 물었습니다.

"그럼 비밀번호 같은 민감한 정보도 다 남나요?" 박시니어 씨가 고개를 끄덕였습니다. "네, 그래서 주의가 필요해요.

세션에서 비밀번호를 입력하면 로그에 남을 수 있어요. 가능하면 환경 변수나 AWS Secrets Manager를 사용하는 게 좋습니다." 로그 보존 기간도 설정할 수 있습니다.

CloudWatch Logs의 경우 보존 기간을 1일부터 영구 보관까지 설정할 수 있습니다. S3는 수명 주기 정책을 통해 오래된 로그를 Glacier로 이동하거나 삭제할 수 있습니다.

AWS 콘솔의 Session Manager 설정에서 로깅을 활성화할 수 있습니다. Systems Manager 콘솔에서 "Session Manager" 메뉴를 찾아 "기본 설정" 탭에서 S3 버킷이나 CloudWatch 로그 그룹을 지정하면 됩니다.

보안팀의 요청에 김개발 씨는 CloudWatch Logs Insights에서 간단한 쿼리로 지난주 세션 기록을 조회했습니다. 누가 언제 접속해서 어떤 명령어를 실행했는지 한눈에 파악할 수 있었습니다.

실전 팁

💡 - 민감한 정보가 로그에 남지 않도록 비밀번호는 환경 변수나 Secrets Manager를 사용하세요

• CloudWatch Logs Insights로 세션 로그를 쉽게 검색하고 분석할 수 있습니다
• KMS 키로 로그를 암호화하면 보안이 더욱 강화됩니다

---

6. Systems Manager 추가 기능 소개

Session Manager를 능숙하게 사용하게 된 김개발 씨에게 박시니어 씨가 말했습니다. "Session Manager는 Systems Manager의 일부일 뿐이에요.

다른 기능들도 알면 인프라 관리가 훨씬 쉬워질 거예요." 김개발 씨의 눈이 반짝였습니다. 또 어떤 편리한 기능들이 있을까요?

AWS Systems Manager는 EC2 인스턴스와 온프레미스 서버를 관리하기 위한 통합 서비스입니다. Session Manager 외에도 Run Command, Patch Manager, Parameter Store 등 다양한 기능을 제공합니다.

마치 만능 스위스 아미 나이프처럼, 서버 관리에 필요한 거의 모든 도구가 들어 있습니다.

다음 코드를 살펴봅시다.

# Run Command: 여러 인스턴스에 동시에 명령 실행
aws ssm send-command \
    --document-name "AWS-RunShellScript" \
    --targets "Key=tag:Environment,Values=Production" \
    --parameters 'commands=["sudo yum update -y"]'

# Parameter Store: 설정값 안전하게 저장 및 조회
aws ssm put-parameter \
    --name "/myapp/database/password" \
    --value "supersecretpassword" \
    --type "SecureString"

# 파라미터 조회
aws ssm get-parameter \
    --name "/myapp/database/password" \
    --with-decryption

# Patch Manager: 패치 상태 확인
aws ssm describe-instance-patch-states \
    --instance-ids i-0123456789abcdef0

# 인벤토리: 인스턴스 소프트웨어 정보 수집
aws ssm list-inventory-entries \
    --instance-id i-0123456789abcdef0 \
    --type-name "AWS:Application"

박시니어 씨가 Systems Manager의 다양한 기능을 소개하기 시작했습니다. "하나씩 알아볼까요?" 첫 번째는 Run Command입니다.

여러 서버에 동시에 명령어를 실행할 수 있습니다. 예를 들어, 프로덕션 환경의 모든 서버에 보안 패치를 적용하고 싶다면, 일일이 접속할 필요 없이 한 번의 명령으로 처리할 수 있습니다.

"서버가 10대, 100대라면 어떨까요? 일일이 접속해서 명령어 치는 건 악몽이죠." Run Command는 태그를 기준으로 대상을 선택할 수 있습니다.

Environment가 Production인 모든 인스턴스, 또는 Application이 WebServer인 인스턴스처럼 유연하게 지정 가능합니다. 두 번째는 Parameter Store입니다.

설정값이나 비밀 정보를 안전하게 저장하고 관리할 수 있습니다. 데이터베이스 비밀번호, API 키, 설정 파일의 값들을 여기에 저장하면 됩니다.

김개발 씨가 물었습니다. "Secrets Manager랑 뭐가 다른가요?" "Parameter Store는 무료 티어가 있고, 간단한 설정값 저장에 적합해요.

Secrets Manager는 자동 비밀번호 로테이션 같은 고급 기능이 있지만 유료예요. 상황에 맞게 선택하면 됩니다." 세 번째는 Patch Manager입니다.

운영체제와 애플리케이션의 패치를 자동으로 관리합니다. 패치 기준선을 정의하고, 유지 관리 기간을 설정하면 자동으로 패치가 적용됩니다.

보안 취약점을 빠르게 해결할 수 있습니다. 네 번째는 State Manager입니다.

인스턴스의 원하는 상태를 정의하고, 그 상태를 지속적으로 유지합니다. 예를 들어, 특정 에이전트가 항상 실행 중이어야 한다는 정책을 설정할 수 있습니다.

다섯 번째는 Inventory입니다. 모든 인스턴스에 설치된 소프트웨어, 네트워크 설정, Windows 역할 등의 정보를 수집합니다.

어떤 서버에 어떤 버전의 소프트웨어가 설치되어 있는지 한눈에 파악할 수 있습니다. 박시니어 씨가 정리했습니다.

"이 모든 기능이 SSM Agent 하나로 동작해요. Session Manager를 위해 설정한 인프라가 다른 기능에도 그대로 활용됩니다." 김개발 씨는 고개를 끄덕였습니다.

처음에는 그저 서버 접속 도구라고 생각했던 Systems Manager가 사실은 인프라 관리의 핵심 도구였던 것입니다.

실전 팁

💡 - Run Command의 실행 결과는 S3나 CloudWatch Logs에 저장할 수 있습니다

• Parameter Store의 SecureString 타입은 KMS로 자동 암호화됩니다
• Patch Manager는 유지 관리 기간을 설정하여 업무 시간 외에 패치를 적용할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!