```
# AWS CLI를 사용한 Amazon ECS Service Connect 구성
AWS CLI를 통해 Service Connect를 사용하는 Fargate 태스크에 대한 Amazon ECS 서비스를 생성할 수 있습니다.
**참고**
듀얼 스택 서비스 엔드포인트를 사용하면 AWS CLI, SDK 및 Amazon ECS API에서 IPv4 및 IPv6 모두를 통해 Amazon ECS와 상호 작용할 수 있습니다. 자세한 내용은 [Amazon ECS 듀얼 스택 엔드포인트 사용](dual-stack-endpoint.md) 섹션을 참조하세요.
## 사전 조건
다음은 Service Connect의 사전 조건입니다.
+ 최신 버전의 AWS CLI가 설치되고 구성되어 있는지 확인합니다. 자세한 내용은 [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
+ IAM 사용자는 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 정책 예제에 지정된 필수 권한을 가집니다.
+ 사용할 VPC, 서브넷, 라우팅 테이블 및 보안 그룹이 생성되었습니다. 자세한 내용은 [Virtual Private Cloud 생성](get-set-up-for-amazon-ecs.md#create-a-vpc) 섹션을 참조하세요.
+ 이름이 `ecsTaskExecutionRole`인 작업 실행 역할이 있고 `AmazonECSTaskExecutionRolePolicy` 관리형 정책이 역할에 연결되어 있습니다. 이 역할을 통해 Fargate는 NGINX 애플리케이션 로그와 Service Connect 프록시 로그를 Amazon CloudWatch Logs에 쓸 수 있습니다. 자세한 내용은 [작업 실행 역할 생성](task_execution_IAM_role.md#create-task-execution-role) 섹션을 참조하세요.
## 1단계: 클러스터 생성
다음 단계에 따라 Amazon ECS 클러스터 및 네임스페이스를 생성합니다.
**Amazon ECS 클러스터와 AWS Cloud Map 네임스페이스 생성**
1. 사용할 `tutorial`이라는 Amazon ECS 클러스터를 생성합니다. 파라미터 `--service-connect-defaults`는 클러스터의 기본 네임스페이스를 설정합니다. 예제 출력에서는 이름이 `service-connect`인 AWS Cloud Map 네임스페이스가 이 계정과 AWS 리전에 존재하지 않으므로 Amazon ECS에서 네임스페이스를 생성합니다. 네임스페이스는 계정의 AWS Cloud Map에서 생성되고, 다른 모든 네임스페이스에서 볼 수 있으므로 용도를 나타내는 이름을 사용합니다.
```
aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
```
출력:
```
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
"clusterName": "tutorial",
"serviceConnectDefaults": {
"namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
},
"status": "PROVISIONING",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [
{
"name": "containerInsights",
"value": "disabled"
}
],
"capacityProviders": [],
"defaultCapacityProviderStrategy": [],
"attachments": [
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"type": "sc",
"status": "ATTACHING",
"details": []
}
],
"attachmentsStatus": "UPDATE_IN_PROGRESS"
}
}
}
```
1. 클러스터가 생성되었는지 확인합니다.
```
aws ecs describe-clusters --clusters tutorial
```
출력:
```
{
"clusters": [
{
"clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
"clusterName": "tutorial",
"serviceConnectDefaults": {
"namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
}
],
"failures": []
}
```
1. (선택 사항) AWS Cloud Map에서 네임스페이스가 생성되었는지 확인합니다. AWS Cloud Map에서 생성되었으므로 AWS Management Console 또는 일반 AWS CLI 구성을 사용할 수 있습니다.
예를 들어 AWS CLI를 사용합니다.
```
aws servicediscovery get-namespace --id ns-EXAMPLE
```
출력:
```
{
"Namespace": {
"Id": "ns-EXAMPLE",
"Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
"Name": "service-connect",
"Type": "HTTP",
"Properties": {
"DnsProperties": {
"SOA": {}
},
"HttpProperties": {
"HttpName": "service-connect"
}
},
"CreateDate": 1661749852.422,
"CreatorRequestId": "service-connect"
}
}
```
## 2단계: 서버용 서비스 생성
Service Connect 기능은 Amazon ECS에서 여러 애플리케이션을 상호 연결하는 데 사용됩니다. 이러한 애플리케이션 중 하나 이상은 연결할 웹 서비스를 제공해야 합니다. 이 단계에서는 다음을 생성합니다.
+ 수정되지 않은 공식 NGINX 컨테이너 이미지를 사용하고 Service Connect 구성을 포함하는 작업 정의.
+ 이 서비스에 대한 트래픽에 대해 서비스 검색 및 서비스 메시 프록시를 제공하도록 Service Connect를 구성하는 Amazon ECS 서비스 정의입니다. 구성은 클러스터 구성의 기본 네임스페이스를 재사용하여 각 서비스에 대한 서비스 구성의 양을 줄입니다.
+ Amazon ECS 서비스입니다. 작업 정의를 사용하여 하나의 작업을 실행하고, Service Connect 프록시에 대한 추가 컨테이너를 삽입합니다. 프록시는 작업 정의의 컨테이너 포트 매핑에 지정된 포트에서 수신을 대기합니다. Amazon ECS에서 실행되는 클라이언트 애플리케이션에서 클라이언트 작업의 프록시는 작업 정의 포트 이름, 서비스 검색 이름 또는 서비스 클라이언트 별칭 이름, 클라이언트 별칭의 포트 번호에 대한 아웃바운드 연결을 수신 대기합니다.
**Service Connect를 사용하여 웹 서비스를 생성하려면**
1. Fargate와 호환되며 `awsvpc` 네트워크 모드를 사용하는 태스크 정의를 등록합니다. 다음 단계를 따릅니다.
1. 다음과 같은 태스크 정의의 내용으로 이름이 `service-connect-nginx.json`인 파일을 생성합니다.
이 작업 정의는 포트 매핑에 `name` 및 `appProtocol` 파라미터를 추가하여 Service Connect를 구성합니다. 포트 이름을 사용하면 여러 포트가 사용될 때 서비스 구성에서 이 포트를 더욱 쉽게 식별할 수 있습니다. 포트 이름은 기본적으로 네임스페이스의 다른 애플리케이션에서 사용할 검색 가능한 이름으로도 사용됩니다.
서비스에서 ECS Exec이 활성화되어 있으므로 작업 정의에 작업 IAM 역할이 포함됩니다.
**중요**
이 작업 정의는 `logConfiguration`을 사용하여 `stdout` 및 `stderr`의 nginx 출력을 Amazon CloudWatch Logs로 전송합니다. 이 작업 실행 역할에는 CloudWatch Logs 로그 그룹을 만드는 데 필요한 추가 권한이 없습니다. AWS Management Console 또는 AWS CLI를 사용하여 CloudWatch Logs에서 로그 그룹을 생성합니다. nginx 로그를 CloudWatch Logs로 전송하지 않으려면 `logConfiguration`을 제거합니다.
태스크 실행 역할의 AWS 계정 ID를 사용자의 AWS 계정 ID로 바꿉니다.
```
{
"family": "service-connect-nginx",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "webserver",
"image": "public.ecr.aws/docker/library/nginx:latest",
"cpu": 100,
"portMappings": [
{
"name": "nginx",
"containerPort": 80,
"protocol": "tcp",
"appProtocol": "http"
}
],
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/service-connect-nginx",
"awslogs-region": "region",
"awslogs-stream-prefix": "nginx"
}
}
}
],
"cpu": "256",
"memory": "512"
}
```
1. `service-connect-nginx.json` 파일을 사용하여 작업 정의를 등록합니다.
```
aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
```
1. 서비스 생성:
1. 생성하려는 Amazon ECS 서비스의 내용으로 이름이 `service-connect-nginx-service.json`인 파일을 생성합니다. 이 예에서는 이전 단계에서 생성된 태스크 정의를 사용합니다. 예제 태스크 정의에서 `awsvpcConfiguration` 네트워크 모드가 사용되기 때문에 `awsvpc`이 필요합니다.
ECS 서비스를 생성하는 경우 Fargate를 지정하고 Service Connect를 지원하는 `LATEST` 플랫폼 버전을 지정합니다. `securityGroups`와 `subnets`는 Amazon ECS 사용에 대한 요구 사항을 갖춘 VPC에 속해야 합니다. Amazon VPC 콘솔에서 보안 그룹 및 서브넷 ID를 얻을 수 있습니다.
이 서비스는 `serviceConnectConfiguration` 파라미터를 추가하여 Service Connect를 구성합니다. 클러스터에는 기본 네임스페이스가 구성되어 있으므로 네임스페이스는 필요하지 않습니다. 네임스페이스의 ECS에서 실행되는 클라이언트 애플리케이션은 `portName` 및 `clientAliases`의 포트를 사용하여 이 서비스에 연결합니다. 예를 들어, nginx는 루트 위치 `/`에 시작 페이지를 제공하므로 `http://nginx:80/`을 사용하여 이 서비스에 연결할 수 있습니다. Amazon ECS에서 실행되지 않거나 동일한 네임스페이스에 있지 않은 외부 애플리케이션은 작업의 IP 주소와 작업 정의의 포트 번호를 사용하여 Service Connect 프록시를 통해 이 애플리케이션에 연결할 수 있습니다. `tls` 구성을 위해 `awsPcaAuthorityArn`, `kmsKey`, IAM 역할의 `roleArn`에 대한 인증서 `arn`을 추가합니다.
이 서비스는 `logConfiguration`을 사용하여 `stdout` 및 `stderr`의 서비스 연결 프록시 출력을 Amazon CloudWatch Logs로 전송합니다. 이 작업 실행 역할에는 CloudWatch Logs 로그 그룹을 만드는 데 필요한 추가 권한이 없습니다. AWS Management Console 또는 AWS CLI를 사용하여 CloudWatch Logs에서 로그 그룹을 생성합니다. 이 로그 그룹을 생성하고 CloudWatch Logs에 프록시 로그를 저장하는 것이 좋습니다. 프록시 로그를 CloudWatch Logs로 전송하지 않으려면 `logConfiguration`을 제거합니다.
```
{
"cluster": "tutorial",
"deploymentConfiguration": {
"maximumPercent": 200,
"minimumHealthyPercent": 0
},
"deploymentController": {
"type": "ECS"
},
"desiredCount": 1,
"enableECSManagedTags": true,
"enableExecuteCommand": true,
"launchType": "FARGATE",
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [
"sg-EXAMPLE"
],
"subnets": [
"subnet-EXAMPLE",
"subnet-EXAMPLE",
"subnet-EXAMPLE"
]
}
},
"platformVersion": "LATEST",
"propagateTags": "SERVICE",
"serviceName": "service-connect-nginx-service",
"serviceConnectConfiguration": {
"enabled": true,
"services": [
{
"portName": "nginx",
"clientAliases": [
{
"port": 80
}
],
"tls": {
"issuerCertificateAuthority": {
"awsPcaAuthorityArn": "certificateArn"
},
"kmsKey": "kmsKey",
"roleArn": "iamRoleArn"
}
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/service-connect-proxy",
"awslogs-region": "region",
"awslogs-stream-prefix": "service-connect-proxy"
}
}
},
"taskDefinition": "service-connect-nginx"
}
```
1. `service-connect-nginx-service.json` 파일을 사용하여 서비스 생성:
```
aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
```
출력:
```
{
"service": {
"serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
"serviceName": "service-connect-nginx-service",
"clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
"loadBalancers": [],
"serviceRegistries": [],
"status": "ACTIVE",
"desiredCount": 1,
"runningCount": 0,
"pendingCount": 0,
"launchType": "FARGATE",
"platformVersion": "LATEST",
"platformFamily": "Linux",
"taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
"deploymentConfiguration": {
"deploymentCircuitBreaker": {
"enable": false,
"rollback": false
},
"maximumPercent": 200,
"minimumHealthyPercent": 0
},
"deployments": [
{
"id": "ecs-svc/3763308422771520962",
"status": "PRIMARY",
"taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
"desiredCount": 1,
"pendingCount": 0,
"runningCount": 0,
"failedTasks": 0,
"createdAt": 1661210032.602,
"updatedAt": 1661210032.602,
"launchType": "FARGATE",
"platformVersion": "1.4.0",
"platformFamily": "Linux",
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [
"sg-EXAMPLE"
],
"subnets": [
"subnet-EXAMPLEf",
"subnet-EXAMPLE",
"subnet-EXAMPLE"
]
}
},
"rolloutState": "IN_PROGRESS",
"rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
"failedLaunchTaskCount": 0,
"replacedTaskCount": 0,
"serviceConnectConfiguration": {
"enabled": true,
"namespace": "service-connect",
"services": [
{
"portName": "nginx",
"clientAliases": [
{
"port": 80
}
]
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/service-connect-proxy",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "service-connect-proxy"
},
"secretOptions": []
}
},
"serviceConnectResources": [
{
"discoveryName": "nginx",
"discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
}
]
}
],
"roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
"version": 0,
"events": [],
"createdAt": 1661210032.602,
"placementConstraints": [],
"placementStrategy": [],
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [
"sg-EXAMPLE"
],
"subnets": [
"subnet-EXAMPLE",
"subnet-EXAMPLE",
"subnet-EXAMPLE"
]
}
},
"schedulingStrategy": "REPLICA",
"enableECSManagedTags": true,
"propagateTags": "SERVICE",
"enableExecuteCommand": true
}
}
```
제공한 `serviceConnectConfiguration`이 출력의 첫 번째 deployment** 내부에 표시됩니다. 작업을 변경해야 하는 방식으로 ECS 서비스를 변경하면 Amazon ECS에서 새 배포를 생성합니다.
## 3단계: 연결할 수 있는지 확인
Service Connect의 구성 및 작동 여부를 확인하려면 다음 단계를 따라 외부 애플리케이션에서 웹 서비스에 연결합니다. 그런 다음 Service Connect 프록시가 생성하는 CloudWatch의 추가 지표를 참조하세요.
**외부 애플리케이션에서 웹 서비스에 연결**
+ 작업 IP 주소와 작업 IP 주소를 사용하는 컨테이너 포트에 연결
AWS CLI를 사용하여 `aws ecs list-tasks --cluster tutorial`로 작업 ID를 가져옵니다.
서브넷과 보안 그룹이 작업 정의의 포트에서 퍼블릭 인터넷의 트래픽을 허용하는 경우 컴퓨터에서 퍼블릭 IP에 연결할 수 있습니다. 하지만 퍼블릭 IP는 'describe-tasks'에서 제공되지 않으므로 단계 중 Amazon EC2 AWS Management Console 또는 AWS CLI로 이동하여 탄력적 네트워크 인터페이스의 세부 정보를 가져오는 작업이 포함됩니다.
이 예시에서는 동일한 VPC의 Amazon EC2 인스턴스가 작업의 프라이빗 IP를 사용합니다. 애플리케이션은 nginx지만 `server: envoy` 헤더는 Service Connect 프록시가 사용됨을 보여줍니다. Service Connect 프록시는 작업 정의의 컨테이너 포트에서 수신 대기합니다.
```
$ curl -v 10.0.19.50:80/
* Trying 10.0.19.50:80...
* Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.0.19.50
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Tue, 23 Aug 2022 03:53:06 GMT
< content-type: text/html
< content-length: 612
< last-modified: Tue, 16 Apr 2019 13:08:19 GMT
< etag: "5cb5d3c3-264"
< accept-ranges: bytes
< x-envoy-upstream-service-time: 0
<
Welcome to nginx!
Welcome to nginx!
If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.
For online documentation and support please refer to
nginx.org.
Commercial support is available at
nginx.com.
Thank you for using nginx.
```
**Service Connect 지표 보기**
Service Connect 프록시는 CloudWatch 지표에 애플리케이션(HTTP, HTTP2, gRPC 또는 TCP 연결) 지표를 생성합니다. CloudWatch 콘솔을 사용하는 경우 Amazon ECS 네임스페이스에서 **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**), **TargetDiscoveryName**, (**TargetDiscoveryName, ServiceName, ClusterName**)의 추가 지표 차원을 확인합니다. 이러한 지표 및 차원에 대한 자세한 내용은 Amazon CloudWatch Logs 사용 설명서의 [View Available Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)를 참조하세요.
# 서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결
Amazon ECS 서비스는 Amazon ECS 서비스 검색을 사용하도록 구성할 수도 있습니다. 서비스 검색은 AWS Cloud Map API 태스크를 사용하여 Amazon ECS 서비스에 대한 HTTP 및 DNS 네임스페이스를 관리합니다. 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [AWS Cloud Map란 무엇입니까?](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html)를 참조하세요.
서비스 검색은 다음 AWS 리전에서 사용할 수 있습니다.
| 리전 이름 | 리전 |
| --- | --- |
| 미국 동부(버지니아 북부) | us-east-1 |
| 미국 동부(오하이오) | us-east-2 |
| 미국 서부(캘리포니아 북부) | us-west-1 |
| 미국 서부(오리건) | us-west-2 |
| 아프리카(케이프타운) | af-south-1 |
| 아시아 태평양(홍콩) | ap-east-1 |
| 아시아 태평양(타이베이) | ap-east-2 |
| 아시아 태평양(뭄바이) | ap-south-1 |
| 아시아 태평양(하이데라바드) | ap-south-2 |
| 아시아 태평양(도쿄) | ap-northeast-1 |
| 아시아 태평양(서울) | ap-northeast-2 |
| 아시아 태평양(오사카) | ap-northeast-3 |
| 아시아 태평양(싱가포르) | ap-southeast-1 |
| 아시아 태평양(시드니) | ap-southeast-2 |
| 아시아 태평양(자카르타) | ap-southeast-3 |
| 아시아 태평양(멜버른) | ap-southeast-4 |
| 아시아 태평양(말레이시아) | ap-southeast-5 |
| 아시아 태평양(뉴질랜드) | ap-southeast-6 |
| 아시아 태평양(태국) | ap-southeast-7 |
| 캐나다(중부) | ca-central-1 |
| 캐나다 서부(캘거리) | ca-west-1 |
| 중국(베이징) | cn-north-1 |
| 중국(닝샤) | cn-northwest-1 |
| 유럽(프랑크푸르트) | eu-central-1 |
| 유럽(취리히) | eu-central-2 |
| 유럽(아일랜드) | eu-west-1 |
| 유럽(런던) | eu-west-2 |
| 유럽(파리) | eu-west-3 |
| 유럽(밀라노) | eu-south-1 |
| 유럽(스톡홀름) | eu-north-1 |
| 이스라엘(텔아비브) | il-central-1 |
| 유럽(스페인) | eu-south-2 |
| 중동(UAE) | me-central-1 |
| 멕시코(중부) | mx-central-1 |
| 중동(바레인) | me-south-1 |
| 남아메리카(상파울루) | sa-east-1 |
| AWS GovCloud(미국 동부) | us-gov-east-1 |
| AWS GovCloud(미국 서부) | us-gov-west-1 |
## 서비스 검색 개념
서비스 검색은 다음과 같은 구성 요소로 이루어집니다.
+ **서비스 검색 네임스페이스**: 트래픽을 라우팅할 동일한 도메인 이름(예: `example.com`)을 공유하는 서비스 검색 서비스의 논리적 그룹입니다. `aws servicediscovery create-private-dns-namespace` 명령을 직접 호출하거나 Amazon ECS 콘솔을 사용하여 네임스페이스를 생성할 수 있습니다. `aws servicediscovery list-namespaces` 명령을 사용하여 현재 계정에서 생성한 네임스페이스에 대한 요약 정보를 볼 수 있습니다. 서비스 검색 명령에 대한 자세한 정보는 *AWS Cloud Map(서비스 검색) AWS CLI 참조 가이드*의 `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` 및 `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)`를 참조하세요.
+ **서비스 검색 서비스**: 서비스 검색 네임스페이스 내에 존재하며 네임스페이스에 대한 서비스 이름과 DNS 구성으로 구성되어 있습니다. 핵심 구성 요소는 다음과 같습니다.
+ **서비스 레지스트리**: DNS 또는 AWS Cloud Map API 태스크를 통해 서비스를 검색하고 서비스 연결에 사용할 수 있는 하나 이상의 가용 엔드포인트를 가져올 수 있도록 허용합니다.
+ **서비스 검색 인스턴스**: 서비스 검색 서비스 내에 존재하며 서비스 디렉터리의 각 Amazon ECS 서비스와 연결된 속성들로 구성됩니다.
+ **인스턴스 속성**: 다음 메타데이터는 서비스 검색을 사용하도록 구성된 각 Amazon ECS 서비스에 대한 사용자 지정 속성으로 추가됩니다.
+ **`AWS_INSTANCE_IPV4`** – `A` 레코드의 경우, DNS 쿼리 및 AWS Cloud Map에 응답하여 Route 53이 반환하는 IPv4 주소는 인스턴스 세부 정보(예: `192.0.2.44`)를 검색할 때 반환됩니다.
+ **`AWS_INSTANCE_IPV6`** – `AAAA` 레코드의 경우 DNS 쿼리 및 AWS Cloud Map에 응답하여 Route 53이 반환하는 IPv6 주소는 인스턴스 세부 정보(예: ` 2001:0db8:85a3:0000:0000:abcd:0001:2345`)를 검색할 때 반환됩니다. Amazon ECS 듀얼 스택 서비스에 대해 `AWS_INSTANCE_IPv4` 및 `AWS_INSTANCE_IPv6`가 모두 추가됩니다. Amazon ECS IPv6 전용 서비스에 대해서는 `AWS_INSTANCE_IPv6`만 추가됩니다.
+ **`AWS_INSTANCE_PORT`** – 서비스 검색 서비스와 연계된 포트 값입니다.
+ **`AVAILABILITY_ZONE`** – 작업이 시작된 가용 영역입니다. EC2를 사용하는 태스크의 경우 이는 컨테이너 인스턴스가 존재하는 가용 영역입니다. Fargate를 사용하는 태스크의 경우 이는 탄력적 네트워크 인터페이스가 존재하는 가용 영역입니다.
+ **`REGION`** – 작업이 존재하는 리전입니다.
+ **`ECS_SERVICE_NAME`** – 작업이 속한 Amazon ECS 서비스의 이름입니다.
+ **`ECS_CLUSTER_NAME`** – 작업이 속한 Amazon ECS 클러스터의 이름입니다.
+ **`EC2_INSTANCE_ID`** – 작업이 배치된 컨테이너 인스턴스의 ID입니다. 태스크에서 Fargate를 사용하는 경우 이 사용자 지정 속성은 추가되지 않습니다.
+ **`ECS_TASK_DEFINITION_FAMILY`** – 작업에서 사용하는 태스크 정의 패밀리입니다.
+ **`ECS_TASK_SET_EXTERNAL_ID`** – 작업 세트가 외부 배포를 위해 생성되고 서비스 검색 레지스트리와 연관되는 경우 `ECS_TASK_SET_EXTERNAL_ID` 속성에는 작업 세트의 외부 ID가 포함됩니다.
+ **Amazon ECS 상태 확인**: Amazon ECS는 컨테이너 수준의 상태 확인을 정기적으로 수행합니다. 상태 확인을 전달하지 않는 엔드포인트는 DNS 라우팅에서 제거되고 비정상으로 상태가 표시됩니다.
## 서비스 검색 고려 사항
서비스 검색을 사용할 때는 다음 사항을 고려해야 합니다.
+ 플랫폼 버전 v1.1.0 이상을 사용 중인 Fargate의 작업에 대해 서비스 검색이 지원됩니다. 자세한 내용은 [Amazon ECS에 대한 Fargate 플랫폼 버전](platform-fargate.md) 섹션을 참조하세요.
+ 서비스 검색을 사용하도록 구성된 서비스는 서비스당 작업 수가 1,000개로 제한됩니다. 이는 Route 53 서비스 할당량 때문입니다.
+ Amazon ECS 콘솔의 서비스 생성 워크플로는 서비스를 프라이빗 DNS 네임스페이스에 등록하는 것만 지원합니다. AWS Cloud Map 프라이빗 DNS 네임스페이스가 생성되면 Route 53 프라이빗 호스팅 영역이 자동으로 생성됩니다.
+ DNS 확인에 성공하려면 VPC DNS 속성을 구성해야 합니다. 속성을 구성하는 방법에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [VPC에서 DNS 지원](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)을 참조하세요.
+ Amazon ECS는 공유 AWS Cloud Map 네임스페이스에 서비스 등록을 지원하지 않습니다.
+ 서비스 검색 서비스용으로 생성된 DNS 레코드는 퍼블릭 네임스페이스가 사용될 때도 퍼블릭 IP 주소 대신 항상 작업의 프라이빗 IP 주소로 등록합니다.
+ 서비스 검색을 위해서는 작업에서 `awsvpc`, `bridge` 또는 `host` 네트워크 모드(`none`는 지원되지 않음)를 지정해야 합니다.
+ 서비스 태스크 정의가 `awsvpc` 네트워크 모드를 사용하는 경우 각 서비스 태스크에 대해 `SRV` 또는 `A` 레코드를 임의로 조합해 생성할 수 있습니다. `SRV` 레코드를 사용하는 경우 포트가 필요합니다. 서비스가 듀얼 스택 서브넷을 사용하는 경우 `AAAA` 레코드를 추가로 생성할 수 있습니다. 서비스가 IPv6 전용 서브넷을 사용하는 경우 `A` 레코드를 생성할 수 없습니다.
+ 서비스 태스크 정의에서 `bridge` 또는 `host` 네트워크 모드를 사용하는 경우 SRV 레코드는 유일하게 지원되는 DNS 레코드 유형입니다. 각 서비스 태스크에 대한 SRV 레코드를 생성합니다. SRV 레코드는 태스크 정의로부터 컨테이너 이름과 컨테이너 포트 조합을 지정해야 합니다.
+ 서비스 검색 서비스를 위한 DNS 레코드는 VPC 내에서 쿼리가 가능합니다. 이들은 `.` 형식을 사용합니다.
+ 서비스 이름에 대해 DNS 쿼리를 수행할 때 `A` 및 `AAAA` 레코드는 태스크에 해당하는 IP 주소 세트를 반환합니다. `SRV` 레코드는 각 태스크에 대한 IP 주소 및 포트 세트를 반환합니다.
+ 정상 레코드가 8개 이하일 경우 Route 53은 모든 DNS 쿼리에 모든 정상 레코드로 응답합니다.
+ 모든 레코드가 비정상일 경우 Route 53는 최대 8개의 비정상 레코드로 DNS 쿼리에 응답합니다.
+ 로드 밸런서를 사용하는 서비스에 대한 서비스 검색을 구성할 수 있지만, 서비스 검색 트래픽은 항상 로드 밸런서가 아닌 태스크로 라우팅됩니다.
+ 서비스 검색은 Classic Load Balancer의 사용을 지원하지 않습니다.
+ 서비스 검색 서비스에 대해 Amazon ECS가 관리하는 컨테이너 수준의 상태 확인을 사용하는 것이 좋습니다.
+ **HealthCheckCustomConfig**—Amazon ECS가 사용자를 대신하여 상태 확인을 관리합니다. Amazon ECS는 컨테이너와 상태 확인, 태스크 상태의 정보를 사용하여 AWS Cloud Map을 통해 상태를 업데이트합니다. 서비스 검색 서비스를 생성할 때 `--health-check-custom-config` 파라미터를 사용하여 이를 지정합니다. 자세한 정보는 *AWS Cloud Map API 참조*의 [HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html)를 참조하세요.
+ 서비스 검색이 사용될 때 생성되는 AWS Cloud Map 리소스는 수동으로 정리해야 합니다.
+ 작업과 인스턴스는 컨테이너 상태 확인이 값을 반환할 때까지 `UNHEALTHY`로 등록됩니다. 상태 확인을 통과하면 상태가 `HEALTHY`로 업데이트됩니다. 컨테이너 상태 확인이 실패하면 서비스 검색 인스턴스의 등록이 취소됩니다.
## 서비스 검색 가격
Amazon ECS 서비스 검색을 사용하는 고객들에게는 Route 53 리소스 및 AWS Cloud Map 검색 API 작업에 대해 요금이 부과됩니다. 여기에는 서비스 레지스트리에 대한 Route 53 호스팅 영역 및 쿼리 생성을 위한 비용이 포함됩니다. 자세한 정보는 *AWS Cloud Map 개발자 안내서*의 [AWS Cloud Map 요금](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html)을 참조하세요.
Amazon ECS는 컨테이너 수준의 상태 확인을 수행하고 이를 AWS Cloud Map 사용자 지정 상태 확인 API 작업에 공개합니다. 고객들은 추가 비용 없이 이를 사용할 수 있습니다. 공개된 태스크에 대해 추가적인 네트워크 상태 확인을 구성하는 경우에는 이러한 상태 확인에 대해 요금이 부과됩니다.
# 서비스 검색을 사용하는 새 Amazon ECS 서비스 생성
AWS CLI를 사용하여 서비스 검색을 사용하는 Fargate 태스크가 포함된 서비스를 생성하는 방법을 알아보세요.
서비스 검색을 지원하는 AWS 리전 목록은 [서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결](service-discovery.md) 섹션을 참조하세요.
Fargate가 지원되는 리전에 대한 자세한 정보는 [AWS Fargate의 Amazon ECS에 대해 지원되는 리전](AWS_Fargate-Regions.md) 섹션을 참조하세요.
**참고**
듀얼 스택 서비스 엔드포인트를 사용하면 AWS CLI, SDK 및 Amazon ECS API에서 IPv4 및 IPv6 모두를 통해 Amazon ECS와 상호 작용할 수 있습니다. 자세한 내용은 [Amazon ECS 듀얼 스택 엔드포인트 사용](dual-stack-endpoint.md) 섹션을 참조하세요.
## 사전 조건
이 자습서를 시작하기 전에 다음 사전 조건을 충족하는지 확인하세요.
+ 최신 버전의 AWS CLI가 설치 및 구성됩니다. 자세한 내용은 [AWS CLI 최신 버전 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
+ [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md) 섹션에 설명된 단계를 완료했습니다.
+ IAM 사용자는 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 정책 예제에 지정된 필수 권한을 가집니다.
+ 하나 이상의 VPC 및 보안 그룹을 생성했습니다. 자세한 내용은 [Virtual Private Cloud 생성](get-set-up-for-amazon-ecs.md#create-a-vpc) 섹션을 참조하세요.
## 1단계: AWS Cloud Map에서 서비스 검색 리소스 생성
이 단계에 따라 서비스 검색 네임스페이스 및 서비스 검색 서비스를 생성합니다.
1. 프라이빗 Cloud Map 서비스 검색 네임스페이스를 생성합니다. 이 예에서는 이름이 `tutorial`인 네임스페이스를 생성합니다. *vpc-abcd1234*를 기존 VPC 중 하나의 ID로 교체합니다.
```
aws servicediscovery create-private-dns-namespace \
--name tutorial \
--vpc vpc-abcd1234
```
이 명령의 출력은 다음과 같습니다.
```
{
"OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
}
```
1. 이전 단계의 출력에서 `OperationId`를 사용하여 프라이빗 네임스페이스가 성공적으로 생성되었는지 확인합니다. 후속 명령에서 이를 사용하기 때문에 네임스페이스 ID를 기록해 둡니다.
```
aws servicediscovery get-operation \
--operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
```
출력값은 다음과 같습니다.
```
{
"Operation": {
"Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
"Type": "CREATE_NAMESPACE",
"Status": "SUCCESS",
"CreateDate": 1519777852.502,
"UpdateDate": 1519777856.086,
"Targets": {
"NAMESPACE": "ns-uejictsjen2i4eeg"
}
}
}
```
1. 이전 단계의 출력에서 `NAMESPACE` ID를 사용하여 서비스 검색 서비스를 생성합니다. 이 예제에서는 `myapplication`라는 서비스를 생성합니다. 후속 명령에서 이를 사용하기 때문에 서비스 ID 및 ARN을 기록해 둡니다.
```
aws servicediscovery create-service \
--name myapplication \
--dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
--health-check-custom-config FailureThreshold=1
```
출력값은 다음과 같습니다.
```
{
"Service": {
"Id": "srv-utcrh6wavdkggqtk",
"Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
"Name": "myapplication",
"DnsConfig": {
"NamespaceId": "ns-uejictsjen2i4eeg",
"DnsRecords": [
{
"Type": "A",
"TTL": 300
}
]
},
"HealthCheckCustomConfig": {
"FailureThreshold": 1
},
"CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
}
}
```
## 2단계: Amazon ECS 리소스 생성
이 단계에 따라 Amazon ECS 클러스터, 태스크 정의, 서비스를 생성합니다.
1. Amazon ECS 클러스터를 생성합니다. 이 예에서는 이름이 `tutorial`인 클러스터를 생성합니다.
```
aws ecs create-cluster \
--cluster-name tutorial
```
1. Fargate와 호환되며 `awsvpc` 네트워크 모드를 사용하는 태스크 정의를 등록합니다. 다음 단계를 따릅니다.
1. 다음과 같은 태스크 정의의 내용으로 이름이 `fargate-task.json`인 파일을 생성합니다.
```
{
"family": "tutorial-task-def",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "sample-app",
"image": "public.ecr.aws/docker/library/httpd:2.4",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"essential": true,
"entryPoint": [
"sh",
"-c"
],
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512"
}
```
1. `fargate-task.json` 파일을 사용하여 태스크 정의를 등록합니다.
```
aws ecs register-task-definition \
--cli-input-json file://fargate-task.json
```
1. 다음 단계에 따라 ECS 서비스를 생성합니다.
1. 생성하려는 ECS 서비스의 내용으로 이름이 `ecs-service-discovery.json`인 파일을 생성합니다. 이 예에서는 이전 단계에서 생성된 태스크 정의를 사용합니다. 예제 태스크 정의에서 `awsvpcConfiguration` 네트워크 모드가 사용되기 때문에 `awsvpc`이 필요합니다.
ECS 서비스를 생성하는 경우 Fargate를 지정하고 서비스 검색을 지원하는 `LATEST` 플랫폼 버전을 지정합니다. 서비스 검색 서비스를 AWS Cloud Map에서 생성할 때 `registryArn`은 반환된 ARN입니다. `securityGroups` 및 `subnets`은 반드시 Cloud Map 네임스페이스를 생성하는 데 사용되는 VPC에 속해야 합니다. Amazon VPC 콘솔에서 보안 그룹 및 서브넷 ID를 얻을 수 있습니다.
```
{
"cluster": "tutorial",
"serviceName": "ecs-service-discovery",
"taskDefinition": "tutorial-task-def",
"serviceRegistries": [
{
"registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
}
],
"launchType": "FARGATE",
"platformVersion": "LATEST",
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-abcd1234" ],
"subnets": [ "subnet-abcd1234" ]
}
},
"desiredCount": 1
}
```
1. `ecs-service-discovery.json`를 사용하여 ECS 서비스를 생성합니다.
```
aws ecs create-service \
--cli-input-json file://ecs-service-discovery.json
```
## 3단계: AWS Cloud Map에서 서비스 검색 확인
서비스 검색 정보를 쿼리하면 모든 것이 적절하게 생성되었는지 확인할 수 있습니다. 서비스 검색이 구성된 후, AWS Cloud Map API 작업을 사용하거나 VPC 내의 인스턴스로부터 `dig`를 호출할 수 있습니다. 다음 단계를 따릅니다.
1. 서비스 검색 서비스 ID를 사용하여 서비스 검색 인스턴스를 나열합니다. 리소스 정리를 위해 인스턴스 ID(굵게 표시됨)를 기록해 둡니다.
```
aws servicediscovery list-instances \
--service-id srv-utcrh6wavdkggqtk
```
출력값은 다음과 같습니다.
```
{
"Instances": [
{
"Id": "16becc26-8558-4af1-9fbd-f81be062a266",
"Attributes": {
"AWS_INSTANCE_IPV4": "172.31.87.2"
"AWS_INSTANCE_PORT": "80",
"AVAILABILITY_ZONE": "us-east-1a",
"REGION": "us-east-1",
"ECS_SERVICE_NAME": "ecs-service-discovery",
"ECS_CLUSTER_NAME": "tutorial",
"ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
}
}
]
}
```
1. 서비스 검색 네임스페이스 및 서비스, ECS 클러스터 이름과 같은 추가 파라미터를 사용하여 서비스 검색 인스턴스에 대한 세부 정보를 쿼리합니다.
```
aws servicediscovery discover-instances \
--namespace-name tutorial \
--service-name myapplication \
--query-parameters ECS_CLUSTER_NAME=tutorial
```
1. 다음 AWS CLI 명령을 사용하면 서비스 검색 서비스의 Route 53 호스팅 영역에서 생성된 DNS 레코드를 쿼리할 수 있습니다.
1. 네임스페이스 ID를 사용하여 Route 53 호스팅 영역 ID가 포함된 네임스페이스에 대한 정보를 가져옵니다.
```
aws servicediscovery \
get-namespace --id ns-uejictsjen2i4eeg
```
출력값은 다음과 같습니다.
```
{
"Namespace": {
"Id": "ns-uejictsjen2i4eeg",
"Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
"Name": "tutorial",
"Type": "DNS_PRIVATE",
"Properties": {
"DnsProperties": {
"HostedZoneId": "Z35JQ4ZFDRYPLV"
}
},
"CreateDate": 1519777852.502,
"CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
}
}
```
1. 이전 단계에서 Route 53 호스팅 영역 ID를 사용하여(굵게 표시된 텍스트 참조) 해당 호스팅 영역에 대한 리소스 레코드 세트를 가져옵니다.
```
aws route53 list-resource-record-sets \
--hosted-zone-id Z35JQ4ZFDRYPLV
```
1. `dig`를 사용하여 VPC 내의 인스턴스에서 DNS를 쿼리할 수 있습니다.
```
dig +short myapplication.tutorial
```
## 4단계: 정리
이 자습서를 완료한 후에 사용하지 않는 리소스에 대한 요금이 발생하는 것을 방지하기 위해 연결된 리소스를 정리합니다. 다음 단계를 따릅니다.
1. 이전에 기록한 서비스 ID 및 인스턴스 ID를 사용하여 서비스 검색 서비스 인스턴스의 등록을 취소합니다.
```
aws servicediscovery deregister-instance \
--service-id srv-utcrh6wavdkggqtk \
--instance-id 16becc26-8558-4af1-9fbd-f81be062a266
```
출력값은 다음과 같습니다.
```
{
"OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
}
```
1. 이전 단계의 출력에서 `OperationId`를 사용하여 서비스 검색 서비스 인스턴스의 등록이 성공적으로 취소되었는지 확인합니다.
```
aws servicediscovery get-operation \
--operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
```
```
{
"Operation": {
"Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
"Type": "DEREGISTER_INSTANCE",
"Status": "SUCCESS",
"CreateDate": 1525984073.707,
"UpdateDate": 1525984076.426,
"Targets": {
"INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
"ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
"SERVICE": "srv-utcrh6wavdkggqtk"
}
}
}
```
1. 서비스 ID를 사용하여 서비스 검색 서비스를 삭제합니다.
```
aws servicediscovery delete-service \
--id srv-utcrh6wavdkggqtk
```
1. 네임스페이스 ID를 사용하여 서비스 검색 네임스페이스를 삭제합니다.
```
aws servicediscovery delete-namespace \
--id ns-uejictsjen2i4eeg
```
출력값은 다음과 같습니다.
```
{
"OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
}
```
1. 이전 단계의 출력에서 `OperationId`를 사용하여 서비스 검색 네임스페이스가 성공적으로 삭제되었는지 확인합니다.
```
aws servicediscovery get-operation \
--operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
```
출력값은 다음과 같습니다.
```
{
"Operation": {
"Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
"Type": "DELETE_NAMESPACE",
"Status": "SUCCESS",
"CreateDate": 1525984602.211,
"UpdateDate": 1525984602.558,
"Targets": {
"NAMESPACE": "ns-rymlehshst7hhukh",
"ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
}
}
}
```
1. Amazon ECS 서비스에 대해 원하는 개수를 `0`으로 업데이트합니다. 다음 단계에서 서비스를 삭제하려면 이를 반드시 수행해야 합니다.
```
aws ecs update-service \
--cluster tutorial \
--service ecs-service-discovery \
--desired-count 0
```
1. Amazon ECS 서비스를 삭제합니다.
```
aws ecs delete-service \
--cluster tutorial \
--service ecs-service-discovery
```
1. Amazon ECS 클러스터를 삭제합니다.
```
aws ecs delete-cluster \
--cluster tutorial
```
# Amazon VPC Lattice를 사용하여 Amazon ECS 서비스 연결, 관찰 및 보안 유지
Amazon VPC Lattice는 Amazon ECS 고객이 코드를 변경하지 않고도 여러 AWS 컴퓨팅 서비스, VPC, 계정에 빌드된 애플리케이션을 관찰, 보안 및 모니터링하도록 지원하는 완전관리형 애플리케이션 네트워킹 서비스입니다.
VPC Lattice에서는 컴퓨팅 리소스 모음인 대상 그룹을 사용합니다. 이러한 대상은 애플리케이션 또는 서비스를 실행하며, Amazon EC2 인스턴스, IP 주소, Lambda 함수 및 Application Load Balancer일 수 있습니다. 이제는 고객이 Amazon ECS 서비스를 VPC Lattice 대상 그룹과 연결하여 Amazon ECS 작업을 VPC Lattice의 IP 대상으로 활성화할 수 있습니다. Amazon ECS에서는 등록된 서비스에 대한 태스크가 시작될 때 VPC Lattice 대상 그룹에 태스크를 자동으로 등록합니다.
**참고**
5개 VPC Lattice 구성을 사용하면 구성을 더 적게 사용할 때보다 배포 시간이 약간 더 길어질 수 있습니다.
리스너 규칙은 조건이 충족될 때 지정된 대상 그룹에 트래픽을 전달하는 데 사용됩니다. 리스너에서는 사용자가 구성한 포트의 프로토콜을 사용하여 연결 요청을 확인합니다. 서비스는 사용자가 리스너를 구성할 때 정의한 규칙에 따라 등록된 대상으로 요청을 라우팅합니다.
또한 Amazon ECS에서는 VPC Lattice 상태 확인에 따라 비정상이 되는 경우 태스크를 자동으로 바꿉니다. VPC Lattice와 연결되면 Amazon ECS 고객이 클러스터, VPC 및 AWS Resource Access Manager가 있는 계정 전체의 서비스에 연결, 권한 부여 및 인증을 위한 IAM 통합과 고급 트래픽 관리 특성과 같은 VPC Lattice의 다른 여러 컴퓨팅 간 연결, 보안 및 관찰성 특성도 활용할 수 있습니다.
Amazon ECS 고객이 다음과 같은 방법으로 VPC Lattice의 이점을 누릴 수 있습니다.
+ 증가하는 개발자 생산성 - VPC Lattice는 사용자가 특성 구축에 집중할 수 있도록 하여 개발자 생산성을 높이는 한편, VPC Lattice는 모든 컴퓨팅 플랫폼에서 네트워킹, 보안 및 관찰성 과제를 균일한 방법으로 처리합니다.
+ 좋아지는 보안 태세 - VPC Lattice를 사용하면 개발자가 애플리케이션 및 컴퓨팅 플랫폼 간의 통신을 쉽게 인증하고 보호하며, 전송 중 암호화를 적용하고, VPC Lattice 인증 정책을 통해 세부적인 액세스 제어를 적용할 수 있습니다. 이에 따라 업계를 선도하는 규제 및 규정 준수 요구 사항을 충족하는 더 강력한 보안 태세를 채택할 수 있습니다.
+ 향상되는 애플리케이션 확장성 및 복원력 - VPC Lattice를 사용하면 경로, 헤더 및 메서드 기반 라우팅, 인증, 권한 부여 및 모니터링과 같은 특성을 사용하여 배포된 애플리케이션의 네트워크를 생성할 수 있습니다. 이러한 이점은 워크로드에 대한 리소스 오버헤드 없이 제공되며 상당한 지연 시간 추가 없이 초당 수백만 개의 요청을 생성하는 다중 클러스터 배포를 지원할 수 있습니다.
+ 이기종 인프라를 통한 배포 유연성 - VPC Lattice에서는 Amazon ECS, Fargate, Amazon EC2, Amazon EKS 및 Lambda와 같은 모든 컴퓨팅 서비스에 걸쳐 일관된 특성이 제공되며, 조직에서 각 애플리케이션에 적합한 인프라를 선택할 수 있는 유연성이 허용됩니다.
## VPC Lattice가 다른 Amazon ECS 서비스와 연동하는 방식
VPC Lattice와 Amazon ECS를 함께 사용하면 다른 Amazon ECS 서비스를 사용하는 방식이 변경될 수 있지만 다른 서비스는 동일하게 유지됩니다.
**Application Load Balancers**
더는 VPC Lattice에서 Application Load Balancer 대상 그룹 유형과 함께 사용하여 Amazon ECS 서비스에 연결하는 특정 Application Load Balancer를 생성할 필요가 없습니다. 그 대신에 VPC Lattice 대상 그룹으로 Amazon ECS 서비스만 구성하면 됩니다. 또한 Application Load Balancer를 Amazon ECS와 동시에 사용하도록 선택할 수도 있습니다.
**Amazon ECS 롤링 배포**
Amazon ECS 롤링 배포만 VPC Lattice와 연동하며, Amazon ECS에서는 배포 중 태스크를 안전하게 가져오고 서비스에서 제거합니다. 코드 배포 및 블루/그린 배포는 지원되지 않습니다.
VPC Lattice에 대한 자세한 내용은 [Amazon VPC Lattice 사용 설명서](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)를 참조하세요.
# VPC Lattice를 사용하는 서비스 생성
AWS Management Console 또는 AWS CLI를 사용하여 VPC Lattice로 서비스를 생성할 수 있습니다.
## 사전 조건
이 자습서를 시작하기 전에 다음 사전 조건을 충족하는지 확인하세요.
+ 최신 버전의 AWS CLI가 설치 및 구성됩니다. 자세한 정보는 [AWS Command Line Interface 설치](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) 섹션을 참조하세요.
**참고**
듀얼 스택 서비스 엔드포인트를 사용하면 AWS CLI, SDK 및 Amazon ECS API에서 IPv4 및 IPv6 모두를 통해 Amazon ECS와 상호 작용할 수 있습니다. 자세한 내용은 [Amazon ECS 듀얼 스택 엔드포인트 사용](dual-stack-endpoint.md) 섹션을 참조하세요.
+ [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md) 섹션에 설명된 단계를 완료했습니다.
+ IAM 사용자는 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 정책 예제에 지정된 필수 권한을 가집니다.
## AWS Management Console에서 VPC Lattice를 사용하는 서비스 생성
다음과 같은 단계에 따라 AWS Management Console을 사용하여 VPC Lattice로 서비스를 생성합니다.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 페이지에서 **Clusters**(클러스터)를 선택합니다.
1. **클러스터** 페이지에서 서비스를 생성할 클러스터를 선택합니다.
1. **Services**(서비스) 탭에서 **Create**(생성)를 선택합니다.
이전에 서비스를 생성한 적이 없는 경우 [콘솔을 사용하여 Amazon ECS 서비스 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)에서 찾을 수 있는 단계를 따른 다음에 VPC Lattice 섹션에 도달하면 다음과 같은 단계를 계속 진행합니다.
1. 버튼을 선택하여 **VPC Lattice 활성화**를 선택합니다.
1. **Amazon ECS에 대한 ECS 인프라 역할**에 대해 기존 역할을 사용하려면 VPC Lattice 대상 그룹을 생성할 때 이미 생성하여 사용하는 역할을 사용합니다. 새 역할을 생성하려면 **ECS 인프라 역할을 생성**합니다.
1. **VPC**를 선택합니다.
**VPC**는 태스크 정의를 등록할 때 선택한 네트워킹 모드에 따라 달라집니다. EC2에서 `host` 또는 `network` 모드를 사용하는 경우 VPC를 선택하세요.
`awsvpc` 모드의 경우 **네트워킹**에서 선택한 VPC를 기반으로 VPC가 자동으로 선택되며 변경할 수 없습니다.
1. **대상 그룹**에서 대상 그룹 또는 그룹을 선택합니다. 대상 그룹을 하나 이상 선택해야 하며 최대 5개를 선택할 수 있습니다. 대상 그룹을 더 추가하려면 **대상 그룹 추가**를 선택합니다. 선택한 각 대상 그룹의 **포트 이름**, **프로토콜** 및 **포트**를 선택합니다. 대상 그룹을 삭제하려면 **제거**를 선택합니다.
**참고**
기존 대상 그룹을 추가하려면 AWS CLI를 사용해야 합니다. AWS CLI를 사용하여 대상 그룹을 추가하는 방법에 대한 지침은 *AWS Command Line Interface 참조*의 [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)를 참조하세요.
VPC Lattice 서비스에는 여러 대상 그룹이 있을 수 있지만, 각 대상 그룹은 하나의 서비스에만 추가할 수 있습니다.
IPv6 전용 구성으로 서비스를 생성하려면 IP 주소 유형이 `IPv6`인 대상 그룹을 선택합니다.
1. 이제 VPC Lattice 콘솔로 이동하여 설정을 계속합니다. 여기에서는 리스너 기본 작업 또는 기존 VPC Lattice 서비스의 규칙에 새 대상 그룹을 포함합니다.
자세한 내용은 [VPC Lattice 서비스를 위한 리스너 규칙](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)을 참조하세요.
**중요**
보안 그룹 또는 태스크에 대한 인바운드 규칙 `vpc-lattice` 접두사를 허용해야 하며, 상태 확인에 실패할 수 있습니다.
## AWS CLI에서 VPC Lattice를 사용하는 서비스 생성
AWS CLI를 사용하여 VPC Lattice로 서비스를 생성합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
1. 대상 그룹 구성 파일을 생성합니다. 다음은 `tg-config.json`이라는 예제입니다.
```
{
"ipAddressType": "IPV4",
"port": 443,
"protocol": "HTTPS",
"protocolVersion": "HTTP1",
"vpcIdentifier": "vpc-f1663d9868EXAMPLE"
}
```
1. 다음과 같은 명령을 사용하여 VPC Lattice 대상 그룹을 생성합니다.
```
aws vpc-lattice create-target-group \
--name my-lattice-target-group-ip \
--type IP \
--config file://tg-config.json
```
**참고**
IPv6 전용 구성으로 서비스를 생성하려면 IP 주소 유형이 `IPv6`인 대상 그룹을 생성합니다. 자세한 내용은 *AWS CLI 명령 참조*의 [create-log-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html)을 참조하세요.
출력 예시:
```
{
"arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
"config": {
"healthCheck": {
"enabled": true,
"healthCheckIntervalSeconds": 30,
"healthCheckTimeoutSeconds": 5,
"healthyThresholdCount": 5,
"matcher": {
"httpCode": "200"
},
"path": "/",
"protocol": "HTTPS",
"protocolVersion": "HTTP1",
"unhealthyThresholdCount": 2
},
"ipAddressType": "IPV4",
"port": 443,
"protocol": "HTTPS",
"protocolVersion": "HTTP1",
"vpcIdentifier": "vpc-f1663d9868EXAMPLE"
},
"id": "tg-0eaa4b9ab4EXAMPLE",
"name": "my-lattice-target-group-ip",
"status": "CREATE_IN_PROGRESS",
"type": "IP"
}
```
1. *ecs-service-vpc-lattice.json*이라는 다음과 같은 JSON 파일은 Amazon ECS 서비스를 VPC Lattice 대상 그룹에 연결하는 데 사용하는 예제입니다. 아래 예제의 `portName`은 태스크 정의의 `portMappings` 속성의 `name` 필드에 정의한 것과 동일합니다.
```
{
"serviceName": "ecs-service-vpc-lattice",
"taskDefinition": "ecs-task-def",
"vpcLatticeConfigurations": [
{
"targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
"portName": "testvpclattice",
"roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
}
],
"desiredCount": 5,
"role": "ecsServiceRole"
}
```
다음과 같은 명령을 사용하여 Amazon ECS 서비스를 생성하고 위의 json 예제를 사용하여 VPC Lattice 대상 그룹에 연결합니다.
```
aws ecs create-service \
--cluster clusterName \
--serviceName ecs-service-vpc-lattice \
--cli-input-json file://ecs-service-vpc-lattice.json
```
**참고**
VPC Lattice는 Amazon ECS Anywhere에서 지원되지 않습니다.