기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 컴퓨팅
<a name="compute-pattern-list"></a>

**Topics**
+ [컨테이너 및 마이크로서비스](containersandmicroservices-pattern-list.md)
+ [서버리스](serverless-pattern-list.md)
+ [네트워킹](networking-pattern-list.md)
+ [콘텐츠 전송](contentdelivery-pattern-list.md)

# 컨테이너 및 마이크로서비스
<a name="containersandmicroservices-pattern-list"></a>

**Topics**
+ [Amazon EKS 컨테이너에서 Amazon Neptune 데이터베이스 액세스](access-amazon-neptune-database-from-amazon-eks-container.md)
+ [AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md)
+ [AWS Fargate, AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md)
+ [AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon EKS에서 컨테이너 애플리케이션에 비공개로 액세스](access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer.md)
+ [AWS Batch를 사용하여 Amazon RDS for PostgreSQL DB 인스턴스 백업 자동화](automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch.md)
+ [CI/CD 파이프라인을 사용하여 Amazon EKS에서 노드 종료 핸들러 배포 자동화](automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.md)
+ [CI/CD 파이프라인을 사용하여 Amazon EKS에 Java 애플리케이션 자동 구축 및 배포](automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.md)
+ [AWS 계정 및 간에 Amazon ECR 컨테이너 이미지 복사 AWS 리전](copy-ecr-container-images-across-accounts-regions.md)
+ [Amazon ECS 작업 정의를 생성하고 Amazon EFS를 사용하여 EC2 인스턴스에 파일 시스템을 마운트](create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.md)
+ [컨테이너 이미지로 Lambda 함수 배포](deploy-lambda-functions-with-container-images.md)
+ [Fargate를 사용하여 Amazon ECS에 Java 마이크로서비스 배포](deploy-java-microservices-on-amazon-ecs-using-aws-fargate.md)
+ [Amazon EKS와 Amazon S3의 차트 Helm 리포지토리를 사용하여 Kubernetes 리소스 및 패키지 배포](deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3.md)
+ [Terraform을 사용하여 Amazon EKS에 CockroachDB 클러스터 배포](deploy-cockroachdb-on-eks-using-terraform.md)
+ [Amazon EKS에 샘플 Java 마이크로서비스를 배포하고 Application Load Balancer를 사용하여 마이크로서비스 노출하기](deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.md)
+ [Amazon EKS 클러스터에 gRPC 기반 애플리케이션을 배포하고 Application Load Balancer를 사용하여 액세스하기](deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.md)
+ [Docker 컨테이너로 AWS IoT Greengrass V2 실행 중인에 컨테이너화된 애플리케이션 배포](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md)
+ [Elastic Beanstalk를 사용하여 컨테이너 배포](deploy-containers-by-using-elastic-beanstalk.md)
+ [Lambda 함수, Amazon VPC 및 서버리스 아키텍처를 사용하여 정적 아웃바운드 IP 주소 생성](generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.md)
+ [Amazon ECR 리포지토리로 마이그레이션할 때 중복 컨테이너 이미지 자동 식별](identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.md)
+ [Kubernetes DaemonSet을 사용하여 Amazon EKS 워커 노드에 SSM 에이전트 설치](install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset.md)
+ [preBootstrapCommands를 사용하여 Amazon EKS 워커 노드에 SSM 에이전트 및 CloudWatch 에이전트를 설치합니다](install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.md)
+ [Amazon EKS Auto Mode를 활성화할 때 NGINX 수신 컨트롤러 마이그레이션](migrate-nginx-ingress-controller-eks-auto-mode.md)
+ [컨테이너 워크로드를 Azure Red Hat OpenShift(ARO)에서 Red Hat OpenShift Service on AWS (ROSA)로 마이그레이션](migrate-container-workloads-from-aro-to-rosa.md)
+ [Amazon ECS Anywhere를 사용하여 Amazon WorkSpaces에서 Amazon ECS 작업 실행](run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere.md)
+ [Amazon EC2 리눅스 인스턴스에서 ASP.NET 코어 웹 API Docker 컨테이너 실행](run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.md)
+ [AWS Fargate와 함께 Amazon EKS에서 Amazon EFS를 사용하여 영구 데이터 스토리지로 스테이트풀 워크로드 실행](run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate.md)
+ [Amazon EKS Pod Identity 및 KEDA를 사용하여 Amazon EKS에서 이벤트 기반 Auto Scaling 설정](event-driven-auto-scaling-with-eks-pod-identity-and-keda.md)
+ [PGO를 사용하여 Amazon EKS에서 PostgreSQL 배포 간소화](streamline-postgresql-deployments-amazon-eks-pgo.md)
+ [Application Load Balancer를 사용하여 Amazon ECS에서 상호 TLS로 애플리케이션 인증 간소화](simplify-application-authentication-with-mutual-tls-in-amazon-ecs.md)
+ [패턴 더 보기](containersandmicroservices-more-patterns-pattern-list.md)

# Amazon EKS 컨테이너에서 Amazon Neptune 데이터베이스 액세스
<a name="access-amazon-neptune-database-from-amazon-eks-container"></a>

*Ramakrishnan Palaninathan, Amazon Web Services*

## 요약
<a name="access-amazon-neptune-database-from-amazon-eks-container-summary"></a>

이 패턴은 Neptune 데이터베이스에 액세스하기 위해 완전관리형 그래프 데이터베이스인 Amazon Neptune과 컨테이너 오케스트레이션 서비스인 Amazon Elastic Kubernetes Service(Amazon EKS) 간에 연결을 설정합니다. Neptune DB 클러스터는 AWS의 가상 프라이빗 클라우드(VPC) 내에서 제한됩니다. 이러한 이유로 Neptune에 액세스하려면 연결을 활성화하도록 VPC를 신중하게 구성해야 합니다.

PostgreSQL용 Amazon Relational Database Service(Amazon RDS)와 달리 Neptune은 일반적인 데이터베이스 액세스 자격 증명에 의존하지 않습니다. 대신 인증에 AWS Identity and Access Management (IAM) 역할을 사용합니다. 따라서 Amazon EKS에서 Neptune에 연결하려면 Neptune에 액세스하는 데 필요한 권한이 있는 IAM 역할을 설정해야 합니다.

또한 Neptune 엔드포인트는 클러스터가 있는 VPC 내에서만 액세스할 수 있습니다. 따라서 Amazon EKS와 Neptune 간의 통신이 용이하도록 네트워크 설정을 구성해야 합니다. 특정 요구 사항 및 네트워킹 기본 설정에 따라 Neptune과 Amazon EKS 간의 원활한 연결을 위해 [VPC를 구성하는 다양한 방식](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-vpc.html)이 있습니다. 각 방법마다 고유한 장점과 고려 사항을 제공하므로 애플리케이션의 니즈에 따라 데이터베이스 아키텍처를 유연하게 설계할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="access-amazon-neptune-database-from-amazon-eks-container-prereqs"></a>

**사전 조건**
+ 최신 버전의 **kubectl**을 설치합니다([지침](https://kubernetes.io/docs/tasks/tools/#kubectl) 참조). 버전을 확인하려면 다음을 실행합니다.

  ```
  kubectl version --short
  ```
+ 최신 버전의 **eksctl**을 설치합니다([지침](https://eksctl.io/installation/) 참조). 버전을 확인하려면 다음을 실행합니다.

  ```
  eksctl info
  ```
+  AWS Command Line Interface (AWS CLI) 버전 2의 최신 버전을 설치합니다([지침](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 참조). 버전을 확인하려면 다음을 실행합니다.

  ```
  aws --version
  ```
+ Neptune DB 클러스터를 생성합니다([지침](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-cfn-create.html) 참조). [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) 또는 다른 방법을 통해 클러스터의 VPC와 Amazon EKS 간에 통신을 설정해야 합니다. 또한 클러스터의 상태가 ‘사용 가능’이고 보안 그룹에 대한 포트 8182에 인바운드 규칙이 있는지 확인합니다.
+ 기존 Amazon EKS 클러스터에서 IAM OpenID Connect(OIDC) 공급자를 구성합니다([지침](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) 참조).

**제품 버전**
+ [Amazon EKS 1.27](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)
+ [Amazon Neptune 엔진 버전 1.3.0.0(2023년 11월 15일)](https://docs.aws.amazon.com/neptune/latest/userguide/engine-releases-1.3.0.0.html)

## 아키텍처
<a name="access-amazon-neptune-database-from-amazon-eks-container-architecture"></a>

다음 다이어그램은 Neptune 데이터베이스에 대한 액세스를 제공하기 위한 Amazon EKS 클러스터의 Kubernetes 포드와 Neptune 간의 연결을 보여줍니다.

![\[Amazon Neptune을 사용하여 Kubernetes 노드의 포드 연결.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/2fcf9e00-1664-462a-825e-b0fdd962f478/images/86da67e5-340e-4b29-acc6-2da416ce57eb.png)


**자동화 및 규모 조정**

Amazon EKS [Horizontal Pod Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)를 사용하여 이 솔루션을 규모 조정할 수 있습니다.

## 도구
<a name="access-amazon-neptune-database-from-amazon-eks-container-tools"></a>

**서비스**
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html)은 고도로 연결된 데이터 세트를 사용하는 애플리케이션을 빌드하고 실행하기 위한 그래프 데이터베이스 서비스입니다.

## 모범 사례
<a name="access-amazon-neptune-database-from-amazon-eks-container-best-practices"></a>

모범 사례는 *Amazon EKS 모범 사례 가이드*의 [ID 및 액세스 관리](https://aws.github.io/aws-eks-best-practices/security/docs/iam/)를 참조하세요. 

## 에픽
<a name="access-amazon-neptune-database-from-amazon-eks-container-epics"></a>

### 환경 변수 설정
<a name="set-environment-variables"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 클러스터 컨텍스트를 확인합니다. | Helm 또는 기타 명령줄 도구를 사용하여 Amazon EKS 클러스터와 상호 작용하기 전에 클러스터의 세부 정보를 캡슐화하는 환경 변수를 정의해야 합니다. 이러한 변수는 후속 명령에서 올바른 클러스터 및 리소스를 대상으로 지정하는 데 사용됩니다.먼저 올바른 클러스터 컨텍스트 내에서 작동하는지 확인합니다. 이렇게 하면 후속 명령이 의도한 Kubernetes 클러스터로 전송됩니다. 현재 컨텍스트를 확인하려면 다음 SQL 명령을 실행합니다.<pre>kubectl config current-context</pre> | AWS 관리자, 클라우드 관리자 | 
| `CLUSTER_NAME` 변수를 정의합니다. | Amazon EKS 클러스터에 대한 `CLUSTER_NAME` 환경 변수를 정의합니다. 다음 명령에서 샘플 값을 클러스터`us-west-2`의 AWS 리전 올바른 값으로 바꿉니다. 샘플 값 `eks-workshop`을 기존 클러스터 이름으로 바꿉니다.<pre>export CLUSTER_NAME=$(aws eks describe-cluster --region us-west-2 --name eks-workshop --query "cluster.name" --output text)</pre> | AWS 관리자, 클라우드 관리자 | 
| 출력을 검증합니다. | 변수가 제대로 설정되었는지 검증하려면 다음 명령을 실행합니다.<pre>echo $CLUSTER_NAME</pre>이 명령의 출력이 이전 단계에서 지정한 입력과 일치하는지 확인합니다. | AWS 관리자, 클라우드 관리자 | 

### IAM 역할을 생성하고 Kubernetes에 연결
<a name="create-iam-role-and-associate-it-with-kubernetes"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  서비스 계정을 생성합니다. | [서비스 계정에 IAM 역할](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html?sc_channel=el&sc_campaign=appswave&sc_content=eks-integrate-secrets-manager&sc_geo=mult&sc_country=mult&sc_outcome=acq)을 사용하여 Kubernetes 서비스 계정을 IAM 역할에 매핑하고 Amazon EKS에서 실행되는 애플리케이션에 대한 세분화된 권한 관리를 활성화합니다. [eksctl](https://eksctl.io/)을 사용하여 IAM 역할을 생성하고 Amazon EKS 클러스터 내의 특정 Kubernetes 서비스 계정과 연결할 수 있습니다. AWS 관리형 정책은 지정된 Neptune 클러스터에 대한 쓰기 및 읽기 액세스를 `NeptuneFullAccess` 허용합니다.이 명령을 실행하려면 클러스터와 연결된 [OIDC 엔드포인트](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html?sc_channel=el&sc_campaign=appswave&sc_content=eks-integrate-secrets-manager&sc_geo=mult&sc_country=mult&sc_outcome=acq)가 있어야 합니다.라는 AWS 관리형 정책과 연결할 서비스 계정을 생성합니다`NeptuneFullAccess`.<pre>eksctl create iamserviceaccount --name eks-neptune-sa --namespace default --cluster $CLUSTER_NAME --attach-policy-arn arn:aws:iam::aws:policy/NeptuneFullAccess --approve --override-existing-serviceaccounts</pre>여기서 `eks-neptune-sa `는 생성하려는 서비스 계정의 이름입니다.완료되면 이 명령은 다음 응답을 표시합니다.<pre>2024-02-07 01:12:39 [ℹ] created serviceaccount "default/eks-neptune-sa"</pre> | AWS 관리자, 클라우드 관리자 | 
| 계정이 올바르게 설정되었는지 확인합니다. | 클러스터의 기본 네임스페이스에 `eks-neptune-sa` 서비스 계정이 올바르게 설정되어 있는지 확인합니다.<pre>kubectl get sa eks-neptune-sa -o yaml</pre>출력은 다음과 같아야 합니다.<pre>apiVersion: v1<br />kind: ServiceAccount<br />metadata:<br />  annotations:<br />    eks.amazonaws.com/role-arn: arn:aws:iam::123456789123:role/eksctl-eks-workshop-addon-iamserviceaccount-d-Role1-Q35yKgdQOlmM<br />  creationTimestamp: "2024-02-07T01:12:39Z"<br />  labels:<br />    app.kubernetes.io/managed-by: eksctl<br />  name: eks-neptune-sa<br />  namespace: default<br />  resourceVersion: "5174750"<br />  uid: cd6ba2f7-a0f5-40e1-a6f4-4081e0042316</pre> | AWS 관리자, 클라우드 관리자 | 
| 연결을 확인합니다. | `pod-util`이라는 샘플 포드를 배포하고 Neptune과의 연결을 확인합니다.<pre>apiVersion: v1<br />kind: Pod<br />metadata:<br />  name: pod-util<br />  namespace: default<br />spec:<br />  serviceAccountName: eks-neptune-sa<br />  containers:<br />  - name: pod-util<br />    image: public.ecr.aws/patrickc/troubleshoot-util<br />    command:<br />      - sleep<br />      - "3600"<br />    imagePullPolicy: IfNotPresent</pre><pre>kubectl apply -f pod-util.yaml</pre><pre>kubectl exec --stdin --tty pod-util -- /bin/bash<br />bash-5.1# curl -X POST -d '{"gremlin":"g.V().limit(1)"}' https://db-neptune-1.cluster-xxxxxxxxxxxx.us-west-2.neptune.amazonaws.com:8182/gremlin<br />{"requestId":"a4964f2d-12b1-4ed3-8a14-eff511431a0e","status":{"message":"","code":200,"attributes":{"@type":"g:Map","@value":[]}},"result":{"data":{"@type":"g:List","@value":[]},"meta":{"@type":"g:Map","@value":[]}}}<br />bash-5.1# exit<br />exit</pre> | AWS 관리자, 클라우드 관리자 | 

### 연결 작업 검증
<a name="validate-connection-activity"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| IAM 데이터베이스 인증을 활성화합니다. | 기본적으로 Neptune DB 클러스터를 생성하면 IAM 데이터베이스 인증이 비활성화됩니다. AWS Management Console을 사용하여 IAM 데이터베이스 인증을 활성화 또는 비활성화할 수 있습니다. AWS 설명서의 단계에 따라 [Neptune에서 IAM 데이터베이스 인증을 활성화합니다](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-enable.html). | AWS 관리자, 클라우드 관리자 | 
| 연결을 확인합니다. | 이 단계에서는 이미 실행 중인 `pod-util` 컨테이너와 상호 작용하여 **awscurl**을 설치하고 연결을 확인합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-amazon-neptune-database-from-amazon-eks-container.html) | AWS 관리자, 클라우드 관리자 | 

## 문제 해결
<a name="access-amazon-neptune-database-from-amazon-eks-container-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| Neptune 데이터베이스에 액세스할 수 없습니다. | 서비스 계정에 연결된 IAM 정책을 검토합니다. 실행하려는 작업에 필요한 작업(예: `neptune:Connec,neptune:DescribeDBInstances`)을 허용하는지 확인합니다. | 

## 관련 리소스
<a name="access-amazon-neptune-database-from-amazon-eks-container-resources"></a>
+ [Kubernetes 서비스 계정을 AWS 사용하여 Kubernetes 워크로드에에 대한 액세스 권한 부여](https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html)(Amazon EKS 설명서)
+ [서비스 계정에 대한 IAM 역할](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)(Amazon EKS 설명서)
+ [새 Neptune DB 클러스터 생성](https://docs.aws.amazon.com/neptune/latest/userguide/get-started-create-cluster.html)(Amazon Neptune 설명서)

# AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer"></a>

*Kirankumar Chandrashekar, Amazon Web Services*

## 요약
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-summary"></a>

이 패턴은 Network Load Balancer 뿐만 아니라 Amazon Elastic Container Service(Amazon ECS)에서 Docker 컨테이너 애플리케이션을 비공개로 호스팅하고 AWS PrivateLink를 사용하여 애플리케이션에 액세스하는 방법을 설명합니다. 그런 다음 프라이빗 네트워크를 사용하여 Amazon Web Services(AWS) 클라우드의 서비스에 안전하게 액세스할 수 있습니다. Amazon Relational Database Service(RDS)는 고가용성(HA)을 통해 Amazon ECS에서 실행되는 애플리케이션용 관계형 데이터베이스를 호스팅합니다. Amazon Elastic File System(Amazon EFS)은 애플리케이션에 영구적인 스토리지가 필요한 경우 사용됩니다.

프런트 엔드에 Network Load Balancer가 있는 Docker 애플리케이션을 실행하는 Amazon ECS 서비스를 Virtual Private Cloud(VPC) 엔드포인트와 연결하여 AWS PrivateLink를 통해 액세스할 수 있습니다. 그리고 나서 이 VPC 엔드포인트 서비스의 VPC 엔드포인트를 사용하여 다른 VPC와 공유할 수 있습니다.

Amazon EC2 Auto Scaling 그룹 대신 [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)도 사용할 수 있습니다. 자세한 내용은 [AWS Fargate, AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 비공개로 컨테이너 애플리케이션에 액세스](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html?did=pg_card)를 참조하세요.

## 사전 조건 및 제한 사항
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ [AWS Command Line Interface(AWS CLI) 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), Linux, macOS, 또는 Windows에 설치 및 구성됨
+ [Docker](https://www.docker.com/), Linux, macOS, 또는 Windows에 설치 및 구성됨
+ Docker에서 실행되는 애플리케이션

## 아키텍처
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-architecture"></a>

![\[AWS PrivateLink를 사용하여 Network Load Balancer를 통해 연결된 Amazon ECS에서 컨테이너 앱에 액세스합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/a316bf46-24db-4514-957d-abc60f8f6962/images/573951ed-74bb-4023-9d9c-43e77e4f8eda.png)


 

**기술 스택**
+ Amazon CloudWatch()
+ Amazon Elastic Compute Cloud(Amazon EC2)
+ Amazon EC2 오토 스케일링
+ Amazon Elastic Container Registry (Amazon ECR)
+ Amazon ECS
+ Amazon RDS
+ Amazon Simple Storage Service(Amazon S3)
+ AWS Lambda
+ AWS PrivateLink
+ AWS Secrets Manager
+ Application Load Balancer
+ Network Load Balancer
+ VPC

*자동화 및 규모 조정*
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)을 사용하면 [코드형 인프라](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)를 사용하여 이 패턴을 생성할 수 있습니다.

## 도구
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-tools"></a>
+ [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) – Amazon Elastic Compute Cloud(Amazon EC2)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다.
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) – Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 유지할 수 있습니다.
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service(Amazon ECS)는 클러스터에서 컨테이너를 손쉽게 실행, 중지 및 관리할 수 있게 하는 컨테이너 관리 서비스로서 확장성과 속도가 뛰어납니다.
+ [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) – Amazon Elastic Container Registry(Amazon ECR)는 안전하고 확장 가능하고 신뢰할 수 있는 AWS 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) – Amazon Elastic File System(Amazon EFS)은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능하며 완전 관리형 탄력적인 NFS 파일 시스템을 제공합니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) - Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다.
+ [Amazon RDS](https://docs.aws.amazon.com/rds/) - Amazon Relational Database Service(RDS)는 AWS 클라우드의 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있게 하는 웹 서비스입니다.
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) – Amazon Simple Storage Service(S3)는 인터넷에 대한 스토리지입니다. 이 서비스는 개발자가 더 쉽게 웹 규모 컴퓨팅 작업을 수행할 수 있도록 설계되었습니다.
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) – Secrets Manager는 코드의 암호를 포함해 하드 코딩된 보안 인증 정보를 Secrets Manager에서 프로그래밍 방식으로 보안 암호를 검색하도록 하는 API 직접 호출로 바꿀 수 있습니다.
+ [Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) – Amazon Virtual Private Cloud(VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다.
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) – Elastic Load Balancing은 여러 가용 영역에 있는 Amazon EC2 인스턴스, 컨테이너, IP 주소와 같은 여러 대상에 걸쳐 수신되는 애플리케이션 또는 네트워크 트래픽을 분산합니다.
+ [Docker](https://www.docker.com/) - Docker를 사용하면 개발자가 모든 애플리케이션을 가볍고 휴대가 간편하며 자급자족할 수 있는 컨테이너로 포장, 배송 및 실행할 수 있습니다.

## 에픽
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-epics"></a>

### 네트워킹 구성 요소 생성
<a name="create-networking-components"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### 로드 밸런서 생성
<a name="create-the-load-balancers"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Network Load Balancer를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| Application Load Balancer을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### Amazon EFS 파일 시스템 생성
<a name="create-an-amazon-efs-file-system"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EFS 파일 시스템을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 서브넷의 대상을 마운트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 서브넷이 대상으로 마운트되었는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### S3 버킷 생성
<a name="create-an-s3-bucket"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| S3 버킷을 생성합니다. | 필요한 경우 Amazon S3 콘솔을 열고 S3 버킷을 생성하여 애플리케이션의 고정 자산을 저장합니다. | 클라우드 관리자 | 

### Secrets Manager 보안 암호 생성
<a name="create-a-secrets-manager-secret"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Secrets Manager의 보안 암호를 암호화하기 위해 AWS KMS 키를 생성합니다. | AWS Key Management Service(AWS KMS) 콘솔을 열고 KMS 키를 생성합니다. | 클라우드 관리자 | 
|  Amazon RDS 암호를 보관하기 위한 Secrets Manager 보안 암호를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자  | 

### Amazon RDS 인스턴스 생성
<a name="create-an-amazon-rds-instance"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DB 서브넷 그룹을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| Amazon RDS 인스턴스를 생성합니다. | 프라이빗 서브넷 내에서 Amazon RDS 인스턴스를 생성하고 구성합니다. 고가용성(HA)을 위해 **다중 AZ**가 켜져 있는지 확인하세요. | 클라우드 관리자 | 
| Amazon RDS 인스턴스로 데이터를 로드합니다. | 애플리케이션에 필요한 관계형 데이터를 Amazon RDS 인스턴스로 로드합니다. 이 프로세스는 애플리케이션의 요구 사항과 데이터베이스 체계의 정의 및 설계 방식에 따라 달라집니다. | 클라우드 관리자, DBA | 

### Amazon ECS 구성 요소 생성
<a name="create-the-amazon-ecs-components"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| ECS 클러스터를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 도커 이미지를 생성합니다. | *관련 리소스* 섹션의 지침에 따라 도커 이미지를 생성합니다. | 클라우드 관리자 | 
| Amazon ECR 리포지토리를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자, DevOps 엔지니어 | 
| Docker 클라이언트를 Amazon ECR 리포지토리를 인증합니다. | Amazon ECR 리포지토리의 Docker 클라이언트를 인증하려면 AWS CLI에서 `aws ecr get-login-password` 명령을 실행합니다. | 클라우드 관리자 | 
| Amazon ECR 리포지토리에 도커 이미지를 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| Amazon ECS 작업 정의를 생성합니다. | Amazon ECS에서 Docker 컨테이너를 실행하려면 작업 정의가 필요합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html)작업 정의를 설정하는 데 도움이 필요하면 *관련 리소스* 섹션의 ‘작업 정의 생성’을 참조하세요. Amazon ECR에 푸시한 도커 이미지를 제공하는지 확인합니다. | 클라우드 관리자 | 
| Amazon ECS 서비스를 생성합니다. | 이전에 생성한 ECS 클러스터를 사용하여 Amazon ECS 서비스를 생성합니다. Amazon EC2를 시작 유형으로 선택하고, 이전 단계에서 생성한 작업 정의와 Application Load Balancer의 대상 그룹을 선택해야 합니다. | 클라우드 관리자 | 

### Amazon EC2 Auto Scaling 그룹을 생성
<a name="create-an-amazon-ec2-auto-scaling-group"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 시작 구성을 생성합니다. | Amazon EC2 콘솔을 열고 시작 구성을 생성합니다. 사용자 데이터에 EC2 인스턴스가 원하는 ECS 클러스터에 조인하도록 허용하는 코드가 있는지 확인하세요. 필요한 코드의 예는 *관련 리소스* 섹션을 참조하세요. | 클라우드 관리자 | 
| Amazon EC2 Auto Scaling 그룹을 생성합니다. | Amazon EC2 콘솔로 돌아가서 **Auto Scaling**에서 **오토 스케일링**을 선택합니다. Amazon EC2 Auto Scaling 그룹을 설정합니다. 프라이빗 서브넷을 선택하고 이전에 생성한 구성을 시작했는지 확인하세요. | 클라우드 관리자 | 

### AWS PrivateLink 설정
<a name="set-up-aws-privatelink"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS PrivateLink 엔드포인트를 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html)자세한 내용은 *관련 리소스* 섹션을 참조하세요. | 클라우드 관리자 | 

### VPC 엔드포인트 생성
<a name="create-a-vpc-endpoint"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC 엔드포인트를 생성합니다. | 이전에 생성한 AWS PrivateLink 엔드포인트에 대한 VPC 엔드포인트를 생성합니다. VPC 엔드포인트 정규화된 도메인 이름(FQDN)은 AWS PrivateLink 엔드포인트 FQDN을 가리킬 것입니다. 그러면 DNS 엔드포인트가 액세스할 수 있는 VPC 엔드포인트 서비스에 대한 탄력적 네트워크 인터페이스가 생성됩니다. | 클라우드 관리자 | 

### Lambda 함수 생성
<a name="create-the-lambda-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda 함수를 생성합니다. | AWS Lambda 콘솔에서 Lambda 함수를 생성하여 Application Load Balancer IP 주소를 Network Load Balancer의 대상으로 업데이트하세요. 이에 대한 자세한 내용은 [Using AWS Lambda to enable static IP addresses for Application Load Balancers](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-lambda-to-enable-static-ip-addresses-for-application-load-balancers/) 블로그 게시물을 참조하세요. | 앱 개발자 | 

## 관련 리소스
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer-resources"></a>

**로드 밸런서 생성:**
+ [Amazon ECS용 Network Load Balancer 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/nlb.html)
+ [Network Load Balancer 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)
+ [Amazon ECS용 Application Load Balancer 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html)
+ [Application Load Balancer 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)

**Amazon EFS 파일 시스템 생성:**
+ [Amazon EFS 파일 시스템 생성](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html)
+ [Amazon EFS에서 마운트 대상 생성](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)

**S3 버킷 생성:**
+ [S3 버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)

**Secrets Manager 보안 암호 생성:**
+ [AWS KMS에서 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
+ [AWS Secrets Manager에서 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)

**Amazon RDS 인스턴스 생성:**
+ [Amazon RDS DB 인스턴스 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)

**Amazon ECS 구성 요소 생성:**
+ [Amazon ECS 클러스터를 생성 ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-ec2-cluster-console-v2.html)
+ [도커 이미지를 생성 ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)
+ [Amazon ECR 리포지토리를 생성 ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)
+ [Amazon ECR 리포지토리로 Docker 인증](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)
+ [Amazon ECR 리포지토리에 이미지를 푸시](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)
+ [Amazon ECS 작업 정의 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)
+ [Amazon ECS 서비스를 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)

**Amazon EC2 Auto Scaling 그룹을 생성:**
+ [시작 구성을 생성](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-config.html)
+ [시작 구성을 사용하여 Auto Scaling 그룹 생성](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg.html)
+ [Amazon EC2 사용자 데이터를 사용하여 컨테이너 인스턴스 부트스트래핑](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html)

**AWS PrivateLink 설정:**
+ [VPC 엔드포인트 서비스(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html)

**VPC 엔드포인트 생성:**
+ [인터페이스 VPC 엔드포인트(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)

**Lambda 함수 생성:**
+ [Lambda 함수 생성](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)

**기타 리소스:**
+ [Application Load Balancer에 고정 IP 주소 사용](https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/)
+ [AWS PrivateLink를 통해 안전하게 서비스 액세스](https://d1.awsstatic.com/whitepapers/aws-privatelink.pdf)

# AWS Fargate, AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer"></a>

*Kirankumar Chandrashekar, Amazon Web Services*

## 요약
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-summary"></a>

이 패턴은 Network Load Balancer 뿐만 아니라 AWS Fargate 시작 유형과 함께 Amazon Elastic Container Service(Amazon ECS)를 사용하여 Amazon Web Services(AWS) 클라우드에 Docker 컨테이너 애플리케이션을 비공개로 호스팅하고, AWS PrivateLink를 사용하여 애플리케이션에 액세스하는 방법을 설명합니다. Amazon Relational Database Service(RDS)는 고가용성(HA)을 통해 Amazon ECS에서 실행되는 애플리케이션용 관계형 데이터베이스를 호스팅합니다. 애플리케이션에 영구적인 스토리지가 필요한 경우 Amazon Elastic File System(Amazon EFS)을 사용할 수 있습니다.

이 패턴은 Docker 애플리케이션을 실행하는 Amazon ECS 서비스에 [Fargate 시작 유형](https://docs.aws.amazon.com/AmazonECS/latest/userguide/launch_types.html)을 사용하며 프런트 엔드에 Network Load Balancer가 있습니다. 그리고 Virtual Private Cloud(VPC) 엔드포인트와 연결하여 AWS PrivateLink를 통해 액세스할 수 있습니다. 그리고 나서 이 VPC 엔드포인트 서비스의 VPC 엔드포인트를 사용하여 다른 VPC와 공유할 수 있습니다.

Amazon ECS와 함께 Fargate를 사용하면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 서버나 클러스터를 관리할 필요 없이 컨테이너를 실행할 수 있습니다. Fargate 대신 Amazon EC2 Auto Scaling 그룹도 사용할 수 있습니다. 자세한 내용은 [AWS Fargate, AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 비공개로 컨테이너 애플리케이션에 액세스](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.html?did=pg_card&trk=pg_card)를 참조하세요.

## 사전 조건 및 제한 사항
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ [AWS Command Line Interface(AWS CLI) 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), Linux, macOS, 또는 Windows에 설치 및 구성됨
+ [Docker](https://www.docker.com/), Linux, macOS, 또는 Windows에 설치 및 구성됨
+ Docker에서 실행되는 애플리케이션

## 아키텍처
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-architecture"></a>

![\[PrivateLink를 사용하여 AWS Fargate 시작 유형으로 Amazon ECS의 컨테이너 앱에 액세스합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/31cca5e2-8d8b-45ec-b872-a06b0dd97007/images/57cc9995-45f4-4039-a0bf-2d2b3d6a05de.png)


**기술 스택**
+ Amazon CloudWatch()
+ Amazon Elastic Container Registry (Amazon ECR)
+ Amazon ECS
+ Amazon EFS
+ Amazon RDS
+ Amazon Simple Storage Service(Amazon S3)
+ AWS Fargate
+ AWS PrivateLink
+ AWS Secrets Manager
+ Application Load Balancer
+ Network Load Balancer
+ VPC

**자동화 및 규모 조정**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)을 사용하면 [코드형 인프라](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)를 사용하여 이 패턴을 생성할 수 있습니다.

## 도구
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-tools"></a>

**AWS 서비스**
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장 가능하고 신뢰할 수 있는 AWS 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon Elastic Container Service(Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)는 클러스터에서 컨테이너를 손쉽게 실행, 중지 및 관리할 수 있게 하는 컨테이너 관리 서비스로서 확장성과 속도가 뛰어납니다.
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능하며 완전 관리형 탄력적인 NFS 파일 시스템을 제공합니다.
+ [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)는 Amazon EC2 인스턴스의 서버 또는 클러스터를 관리할 필요 없이 Amazon ECS에서 컨테이너를 실행하는 데 사용할 수 있는 기술입니다.
+ [Amazon Relational Database Service(Amazon RDS)](https://docs.aws.amazon.com/rds/index.html)는 AWS 클라우드에서 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스입니다.
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 인터넷 스토리지 서비스입니다. 이 서비스는 개발자가 더 쉽게 웹 규모 컴퓨팅 작업을 수행할 수 있도록 설계되었습니다.
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/)를 이용하면 코드의 시크릿을 포함해 하드 코딩된 보안 인증을 Secrets Manager에서 프로그래밍 방식으로 시크릿을 검색하도록 하는 API 호출로 바꿀 수 있습니다.
+ [Amazon Virtual Private Cloud(VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 여러 가용 영역에 있는 EC2 인스턴스, 컨테이너, IP 주소와 같은 여러 대상에 걸쳐 수신되는 애플리케이션 또는 네트워크 트래픽을 분산합니다.

**기타 도구**
+ [Docker](https://www.docker.com/)를 사용하면 개발자가 모든 애플리케이션을 가볍고 휴대가 간편하며 자급자족할 수 있는 컨테이너로 포장, 배송 및 실행할 수 있습니다.

## 에픽
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-epics"></a>

### 네트워킹 구성 요소 생성
<a name="create-networking-components"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### 로드 밸런서 생성
<a name="create-the-load-balancers"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Network Load Balancer를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)이 이야기와 다른 이야기에 대한 도움이 필요하면 *관련 리소스* 섹션을 참조하십시오. | 클라우드 관리자 | 
| Application Load Balancer을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### Amazon EFS 파일 시스템 생성
<a name="create-an-amazon-efs-file-system"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EFS 파일 시스템을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 서브넷의 대상을 마운트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 서브넷이 대상으로 마운트되었는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### S3 버킷 생성
<a name="create-an-s3-bucket"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| S3 버킷을 생성합니다. | 필요한 경우 Amazon S3 콘솔을 열고 [S3 버킷을 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)하여 애플리케이션의 고정 자산을 저장합니다. | 클라우드 관리자 | 

### Secrets Manager 보안 암호 생성
<a name="create-a-secrets-manager-secret"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  Secrets Manager의 보안 암호를 암호화하기 위해 AWS KMS 키를 생성합니다. | AWS Key Management Service(AWS KMS) 콘솔을 열고 KMS 키를 생성합니다. | 클라우드 관리자 | 
|  Amazon RDS 암호를 보관하기 위한 Secrets Manager 보안 암호를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### Amazon RDS 인스턴스 생성
<a name="create-an-amazon-rds-instance"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DB 서브넷 그룹을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| Amazon RDS 인스턴스를 생성합니다. | 프라이빗 서브넷 내에서 Amazon RDS 인스턴스를 생성하고 구성합니다. 고가용성(HA)을 위해 **다중 AZ**가 켜져 있는지 확인하세요. | 클라우드 관리자 | 
| Amazon RDS 인스턴스로 데이터를 로드합니다. | 애플리케이션에 필요한 관계형 데이터를 Amazon RDS 인스턴스로 로드합니다. 이 프로세스는 애플리케이션의 요구 사항과 데이터베이스 체계의 정의 및 설계 방식에 따라 달라집니다. | DBA | 

### Amazon ECS 구성 요소 생성
<a name="create-the-amazon-ecs-components"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| ECS 클러스터를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| 도커 이미지를 생성합니다. | [AWS 설명서](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)의 지침에 따라 Docker 이미지를 생성합니다. | 클라우드 관리자 | 
| Amazon ECR 리포지토리를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자, DevOps 엔지니어 | 
| Amazon ECR 리포지토리에 도커 이미지를 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 
| Amazon ECS 작업 정의를 생성합니다. | Amazon ECS에서 Docker 컨테이너를 실행하려면 작업 정의가 필요합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)작업 정의를 설정하는 데 도움이 필요하면 *관련 리소스* 섹션의 ‘작업 정의 생성’을 참조하세요. Amazon ECR에 푸시한 도커 이미지를 제공하는지 확인합니다. | 클라우드 관리자 | 
| ECS 서비스를 생성하고 Fargate를 시작 유형으로 선택합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### AWS PrivateLink 설정
<a name="set-up-aws-privatelink"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS PrivateLink 엔드포인트를 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) | 클라우드 관리자 | 

### VPC 엔드포인트 생성
<a name="create-a-vpc-endpoint"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC 엔드포인트를 생성합니다. | 이전에 생성한 AWS PrivateLink 엔드포인트에 대한 [VPC 엔드포인트를 생성](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)합니다. VPC 엔드포인트 정규화된 도메인 이름(FQDN)은 AWS PrivateLink 엔드포인트 FQDN을 가리킬 것입니다. 그러면 도메인 이름 서비스 엔드포인트가 액세스할 수 있는 VPC 엔드포인트 서비스에 대한 탄력적인 네트워크 인터페이스가 생성됩니다. | 클라우드 관리자 | 

### 대상 설정
<a name="set-the-target"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Application Load Balancer를 대상으로 추가 | Application Load Balancer를 Network Load Balancer의 대상으로 추가하려면 [AWS 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/application-load-balancer-target.html)의 지침을 따르세요. | 앱 개발자 | 

## 관련 리소스
<a name="access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer-resources"></a>

**로드 밸런서 생성:**
+ [Amazon ECS용 Network Load Balancer 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/nlb.html)
+ [Network Load Balancer 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)
+ [Amazon ECS용 Application Load Balancer 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html)
+ [Application Load Balancer 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)

**Amazon EFS 파일 시스템 생성:**
+ [Amazon EFS 파일 시스템 생성](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html)
+ [Amazon EFS에서 마운트 대상 생성](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)

**Secrets Manager 보안 암호 생성:**
+ [AWS KMS에서 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
+ [AWS Secrets Manager에서 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)

**Amazon RDS 인스턴스 생성:**
+ [Amazon RDS DB 인스턴스 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)

**Amazon ECS 구성 요소 생성**
+ [Amazon ECR 리포지토리를 생성 ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)
+ [Amazon ECR 리포지토리로 Docker 인증](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)
+ [Amazon ECR 리포지토리에 이미지를 푸시](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)
+ [Amazon ECS 작업 정의 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)
+ [Amazon ECS 서비스를 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)

**기타 리소스:**
+ [AWS PrivateLink를 통해 안전하게 서비스 액세스](https://d1.awsstatic.com/whitepapers/aws-privatelink.pdf)

# AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon EKS에서 컨테이너 애플리케이션에 비공개로 액세스
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer"></a>

*Kirankumar Chandrashekar, Amazon Web Services*

## 요약
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-summary"></a>

이 패턴은 Network Load Balancer 뿐만 아니라 Amazon Elastic Kubernetes Service(Amazon EKS)에서 Docker 컨테이너 애플리케이션을 비공개로 호스팅하고 AWS PrivateLink를 사용하여 애플리케이션에 액세스하는 방법을 설명합니다. 그런 다음 프라이빗 네트워크를 사용하여 Amazon Web Services(AWS) 클라우드의 서비스에 안전하게 액세스할 수 있습니다. 

프런트 엔드에 Network Load Balancer가 있는 Docker 애플리케이션을 실행하는 Amazon EKS 클러스터를 Virtual Private Cloud(VPC) 엔드포인트와 연결하여 AWS PrivateLink를 통해 액세스할 수 있습니다. 그리고 나서 이 VPC 엔드포인트 서비스의 VPC 엔드포인트를 사용하여 다른 VPC와 공유할 수 있습니다.

이 패턴에서 설명하는 설정은 VPC와 AWS 계정 간에 애플리케이션 액세스를 공유하는 안전한 방법입니다. 소비자와 공급자 계정 간의 연결은 글로벌 AWS 백본에 있고 퍼블릭 인터넷을 통과하지 않기 때문에 특별한 연결 또는 라우팅 구성이 필요하지 않습니다.

## 사전 조건 및 제한 사항
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-prereqs"></a>

**사전 조건 **
+ [Docker](https://www.docker.com/), Linux, macOS 또는 Windows에 설치 및 구성됨.
+ Docker에서 실행되는 애플리케이션.
+ 활성 상태의 AWS 계정.
+ [AWS Command Line Interface(AWS CLI) 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html), Linux, macOS 또는 Windows에 설치 및 구성됨.
+ 태그가 지정된 프라이빗 서브넷이 있고 애플리케이션을 호스팅하도록 구성된 기존 Amazon EKS 클러스터. 자세한 내용은 Amazon EKS 설명서의 [서브넷 태깅](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html#vpc-subnet-tagging)을 참조하십시오. 
+ Kubectl, Amazon EKS 클러스터의 리소스에 액세스하도록 설치 및 구성됨. 자세한 내용은 Amazon EKS 설명서의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)를 참조하세요. 

## 아키텍처
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-architecture"></a>

![\[PrivateLink 및 Network Load Balancer를 사용하여 Amazon EKS 컨테이너의 애플리케이션에 액세스합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/ce977924-012c-4fb6-8e51-94d6e5c829a6/images/378456a3-f4d1-4a57-bb36-879c240cabfb.png)


**기술 스택**
+ Amazon EKS
+ AWS PrivateLink
+ Network Load Balancer

**자동화 및 규모 조정**
+ Kubernetes 매니페스트는 Git 기반 리포지토리에서 추적 및 관리하고, AWS CodePipeline의 지속적 통합 및 지속적 전달(CI/CD)을 사용하여 배포할 수 있습니다. 
+ AWS CloudFormation을 사용하면 코드형 인프라(IaC)를 사용하여 이 패턴을 생성할 수 있습니다.

## 도구
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-tools"></a>
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) – AWS Command Line Interface(AWS CLI)는 명령줄 쉘에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다.
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) - Elastic Load Balancing은 하나 이상의 가용 영역에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 애플리케이션 또는 네트워크 트래픽을 분산합니다.
+ [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) – Amazon Elastic Kubernetes Service(Amazon EKS)는 Kubernetes 컨트롤 플레인 또는 노드를 설치, 작동 및 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 관리형 서비스입니다.
+ [Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) – Amazon Virtual Private Cloud(VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다.
+ [Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) – Kubectl은 Kubernetes 클러스터에 대해 명령을 실행하기 위한 명령줄 유틸리티입니다.

## 에픽
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-epics"></a>

### Kubernetes 배포 및 서비스 매니페스트 파일 배포
<a name="deploy-the-kubernetes-deployment-and-service-manifest-files"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  Kubernetes 배포 매니페스트 파일을 생성합니다. | 필요에 따라 다음 샘플 파일을 수정하여 배포 매니페스트 파일을 생성하세요.<pre>apiVersion: apps/v1<br />kind: Deployment<br />metadata:<br />  name: sample-app<br />spec:<br />  replicas: 3<br />  selector:<br />    matchLabels:<br />      app: nginx<br />  template:<br />    metadata:<br />      labels:<br />        app: nginx<br />    spec:<br />      containers:<br />        - name: nginx<br />          image: public.ecr.aws/z9d2n7e1/nginx:1.19.5<br />          ports:<br />            - name: http<br />              containerPort: 80</pre>이것은 NGINX 도커 이미지를 사용하여 배포되는 NGINX 샘플 구성 파일입니다. 자세한 내용은 Docker 설명서의 [공식 NGINX 도커 이미지를 사용하는 방법](https://www.docker.com/blog/how-to-use-the-official-nginx-docker-image/)을 참조하세요. | DevOps 엔지니어 | 
| Kubernetes 배포 매니페스트 파일을 배포합니다. | 다음 명령을 실행하여 Amazon EKS 클러스터에 배포 매니페스트 파일을 적용합니다.`kubectl apply –f <your_deployment_file_name> ` | DevOps 엔지니어 | 
|  Kubernetes 서비스 매니페스트 파일을 생성합니다. | 필요에 따라 다음 샘플 파일을 수정하여 서비스 매니페스트 파일을 생성하세요.<pre>apiVersion: v1<br />kind: Service<br />metadata:<br />  name: sample-service<br />  annotations:<br />    service.beta.kubernetes.io/aws-load-balancer-type: nlb<br />    service.beta.kubernetes.io/aws-load-balancer-internal: "true"<br />spec:<br />  ports:<br />    - port: 80<br />      targetPort: 80<br />      protocol: TCP<br />  type: LoadBalancer<br />  selector:<br />    app: nginx</pre>내부 Network Load Balancer를 정의할 때 다음 을(를) 포함했는지 확인하세요.<pre>service.beta.kubernetes.io/aws-load-balancer-type: nlb<br />service.beta.kubernetes.io/aws-load-balancer-internal: "true"</pre> | DevOps 엔지니어 | 
| Kubernetes 서비스 매니페스트 파일을 배포합니다. | 다음 명령을 실행하여 Amazon EKS 클러스터에 서비스 매니페스트 파일을 적용합니다.`kubectl apply -f <your_service_file_name>` | DevOps 엔지니어 | 

### 엔드포인트 생성
<a name="create-the-endpoints"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Network Load Balancer의 이름을 기록해 둡니다. | 다음 명령을 실행하여 Network Load Balancer 이름을 검색합니다.`kubectl get svc sample-service -o wide`AWS PrivateLink 엔드포인트를 생성하는 데 필요한 Network Load Balancer의 이름을 기록해 둡니다. | DevOps 엔지니어 | 
| AWS PrivateLink 엔드포인트를 생성합니다. | AWS Management Console에 로그인한 다음, Amazon VPC 콘솔을 열고 AWS PrivateLink 엔드포인트를 생성합니다. 이 엔드포인트를 Network Load Balancer와 연결하면 고객이 애플리케이션을 비공개로 사용할 수 있습니다. 자세한 내용은 Amazon VPC 사용 설명서에서 [VPC 엔드포인트(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)을 참조하세요.소비자 계정에 애플리케이션 액세스가 필요한 경우, 소비자 계정의 [AWS 계정 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)를 AWS PrivateLink 엔드포인트 구성의 허용된 보안 주체 목록에 추가해야 합니다. 자세한 내용은 Amazon VPC 설명서의 [엔드포인트 서비스 권한 추가 및 권한 제거](https://docs.aws.amazon.com/vpc/latest/userguide/add-endpoint-service-permissions.html)를 참조하세요. | 클라우드 관리자  | 
| VPC 엔드포인트를 생성합니다. | Amazon VPC 콘솔에서 **엔드포인트 서비스**를 선택하고 **엔드포인트 서비스 생성**을 선택합니다. AWS PrivateLink 엔드포인트에 대한 VPC 엔드포인트를 생성합니다.VPC 엔드포인트의 정규화된 도메인 이름(FQDN)은 AWS PrivateLink 엔드포인트의 FQDN을 가리킵니다. 그러면 DNS 엔드포인트가 액세스할 수 있는 VPC 엔드포인트 서비스에 대한 탄력적 네트워크 인터페이스가 생성됩니다.  | 클라우드 관리자 | 

## 관련 리소스
<a name="access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer-resources"></a>
+ [공식 NGINX 도커 이미지 사용](https://www.docker.com/blog/how-to-use-the-official-nginx-docker-image/)
+ [Amazon EKS의 네트워크 로드 밸런싱](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html) 
+ [VPC 엔드포인트 서비스(AWS PrivateLink) 생성](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 
+ [엔드포인트 서비스에 대한 권한 추가 및 제거](https://docs.aws.amazon.com/vpc/latest/userguide/add-endpoint-service-permissions.html)

# AWS Batch를 사용하여 Amazon RDS for PostgreSQL DB 인스턴스 백업 자동화
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch"></a>

*Kirankumar Chandrashekar, Amazon Web Services*

## 요약
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-summary"></a>

PostgreSQL 데이터베이스를 백업하는 것은 중요한 작업이며, 보통 기본적으로 COPY 명령을 사용하여 PostgreSQL 데이터베이스의 스키마 및 데이터 덤프를 생성하는 [pg\$1dump 유틸리티](https://www.postgresql.org/docs/current/app-pgdump.html)를 사용하여 완료할 수 있습니다. 하지만 여러 PostgreSQL 데이터베이스를 정기적으로 백업해야 하는 경우 이 프로세스가 반복될 수 있습니다. PostgreSQL 데이터베이스가 클라우드에서 호스팅되는 경우, PostgreSQL용 Amazon Relational Database Service(Amazon RDS)에서 제공하는 [자동 백업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 기능도 활용할 수 있습니다. 이 패턴은 pg\$1dump 유틸리티를 사용하여 Amazon RDS for PostgreSQL DB 인스턴스 정기 백업을 자동화하는 방법을 설명합니다.

참고: 이 지침에서는 Amazon RDS를 사용하고 있다고 가정합니다. 하지만 Amazon RDS 외부에서 호스팅되는 PostgreSQL 데이터베이스에도 이 접근 방식을 사용할 수 있습니다. 백업을 수행하려면 AWS Lambda 함수가 데이터베이스에 액세스할 수 있어야 합니다.

시간 기반 Amazon CloudWatch Events 이벤트는 Amazon RDS에 있는 PostgreSQL DB [인스턴스의 메타데이터에 적용된 특정 백업 태그](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)를 검색하는 Lambda 함수를 시작합니다. PostgreSQL DB 인스턴스에 **BKP:AutomatedDbdump = Active** 태그와 기타 필수 백업 태그가 있는 경우, Lambda 함수는 각 데이터베이스 백업에 대한 개별 작업을 AWS Batch에 제출합니다. 

AWS Batch는 이러한 작업을 처리하고 백업 데이터를 Amazon Simple Storage Service(Amazon S3) 버킷에 업로드합니다. 이 패턴은 Dockerfile과 entrypoint.sh 파일을 사용하여 AWS Batch 작업에서 백업을 만드는 데 사용되는 Docker 컨테이너 이미지를 빌드합니다. 백업 프로세스가 완료되면 AWS Batch는 Amazon DynamoDB의 인벤토리 테이블에 백업 세부 정보를 기록합니다. 추가 보호 조치로, CloudWatch Events 이벤트는 AWS Batch 작업이 실패할 경우 Amazon Simple Notification Service(Amazon SNS) 알림을 시작합니다. 

## 사전 조건 및 제한 사항
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정.
+ 기존의 관리형 또는 비관리형 컴퓨팅 환경입니다. 자세한 내용은 AWS Batch 설명서의 [관리형 및 비관리형 컴퓨팅 환경](https://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html) 참조하세요. 
+ [AWS 명령줄 인터페이스(CLI) 버전 2 도커 이미지](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html), 설치 및 구성됨.
+ 기존 Amazon RDS for PostgreSQL DB 인스턴스입니다. 
+ 기존 S3 버킷입니다. 
+ [Docker](https://www.docker.com/), Linux, macOS 또는 Windows에 설치 및 구성되었습니다.
+ Lambda에서의 코딩에 익숙합니다. 

## 아키텍처
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-architecture"></a>

![\[pg_dump 유틸리티를 사용하여 Amazon RDS for PostgreSQL DB 인스턴스를 백업하는 아키텍처.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/3283f739-980b-43d4-aca0-9d77a2ce3b85/images/352e2eab-1b7d-44ec-840a-a772a175e873.png)


 

**기술 스택  **
+ Amazon CloudWatch Events
+ Amazon DynamoDB
+ Amazon Elastic Container Registry (Amazon ECR)
+ Amazon RDS
+ Amazon SNS
+ Amazon S3
+ AWS Batch
+ AWS Key Management Service (AWS KMS)
+ AWS Lambda
+ AWS Secrets Manager
+ Docker

## 도구
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-tools"></a>
+ [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) - CloudWatch Events는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트의 스트림을 거의 실시간으로 제공합니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) - DynamoDB는 완전 관리형 NoSQL 데이터베이스 서비스로, 원활한 확장성과 함께 빠르고 예측 가능한 성능을 제공합니다.
+ [Amazon ECR](https://docs.aws.amazon.com/ecr/index.html) - Amazon Elastic Container Registry(Amazon ECR)는 안전하고 확장 가능하고 신뢰할 수 있는 관리형 AWS 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon RDS](https://docs.aws.amazon.com/rds/index.html) - Amazon Relational Database Service(RDS)는 AWS 클라우드의 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있게 하는 웹 서비스입니다.
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) – Amazon Simple Notification Service(Amazon SNS)는 게시자에서 구독자로 메시지를 전송하는 관리형 서비스입니다.
+ [Amazon S3](https://docs.aws.amazon.com/s3/index.html) – Amazon Simple Storage Service(S3)는 인터넷에 대한 스토리지입니다.
+ [AWS Batch](https://docs.aws.amazon.com/batch/index.html) - AWS Batch는 AWS 클라우드에서 배치 컴퓨팅 워크로드를 실행할 수 있도록 도와줍니다.
+ [AWS KMS](https://docs.aws.amazon.com/kms/index.html) - AWS Key Management Service(AWS KMS)는 데이터 암호화에 사용하는 암호화 키를 쉽게 생성하고 제어할 수 있게 해주는 관리형 서비스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/index.html) - Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다.
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/index.html) - Secrets Manager는 코드의 암호를 포함해 하드코딩된 보안 인증 정보를 Secrets Manager에서 프로그래밍 방식으로 보안 암호를 검색하도록 하는 API 호출로 바꿀 수 있습니다.
+ [Docker](https://www.docker.com/) - Docker를 사용하면 개발자가 모든 애플리케이션을 가볍고 휴대가 가능하며 자급자족할 수 있는 컨테이너로 쉽게 포장, 배송 및 실행할 수 있습니다.

Amazon RDS의 PostgreSQL DB 인스턴스에는 [메타데이터에 태그가 적용](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)되어 있어야 합니다. Lambda 함수는 태그를 검색하여 백업해야 하는 DB 인스턴스를 식별하며, 일반적으로 다음과 같은 태그가 사용됩니다.


| 
| 
| 태그 | 설명 | 
| --- |--- |
| kp:AutomatedDBDump = Active | Amazon RDS DB 인스턴스를 백업 대상으로 식별합니다. | 
| bkp:AutomatedBackupSecret = <secret\$1name > | Amazon RDS 로그인 보안 인증 정보가 포함된 Secrets Manager 암호를 식별합니다. | 
| bkp:AutomatedDBDumpS3Bucket = <s3\$1bucket\$1name> | 백업을 전송할 S3 버킷을 식별합니다. | 
| bkp:AutomatedDBDumpFrequencybkp:AutomatedDBDumpTime | 데이터베이스를 백업해야 하는 빈도와 시간을 확인합니다.  | 
| bkp:pgdumpcommand = <pgdump\$1command> | 백업을 수행해야 하는 데이터베이스를 식별합니다. | 

## 에픽
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-epics"></a>

### DynamoDB에 인벤토리 테이블 생성
<a name="create-an-inventory-table-in-dynamodb"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DynamoDB에서 테이블을 생성합니다. | AWS Management Console에 로그인한 다음 Amazon DynamoDB 콘솔을 열고 테이블을 생성합니다. 이 이야기와 다른 이야기에 대한 도움이 필요하면 *관련 리소스* 섹션을 참조하십시오. | 클라우드 관리자, 데이터베이스 관리자 | 
| 테이블이 생성되었는지 확인합니다. | `aws dynamodb describe-table --table-name <table-name> \| grep TableStatus` 명령을 실행합니다. 테이블이 존재하면 명령이 `"TableStatus": "ACTIVE",` 결과를 반환합니다. | 클라우드 관리자, 데이터베이스 관리자 | 

### AWS Batch에서 작업 실패 이벤트에 대한 SNS 주제 생성
<a name="create-an-sns-topic-for-failed-job-events-in-aws-batch"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| SNS 주제를 생성합니다. | Amazon SNS 콘솔을 열고 **주제**를 선택한 다음 `JobFailedAlert` 이름을 사용하여 SNS 주제를 생성합니다. 주제에 대해 활성 이메일 주소를 구독하고, 이메일 수신함을 확인하여 AWS 알림의 SNS 구독 이메일을 확인합니다. | 클라우드 관리자 | 
| AWS Batch에 대한 작업 실패 이벤트 규칙을 생성합니다. | Amazon CloudWatch 콘솔을 열고, **이벤트**를 선택하고 **규칙 생성**을 선택합니다. **고급 옵션 보기**를 선택하고 **편집**을 선택합니다. **대상이 처리할 이벤트를 선택하는 패턴 빌드**의 경우, 기존 텍스트를 *추가 정보* 섹션의 ‘Failed job event’ 코드로 대체합니다. 이 코드는 AWS Batch에 `Failed` 이벤트가 있을 때 시작되는 CloudWatch 이벤트 규칙을 정의합니다. | 클라우드 관리자 | 
| 이벤트 규칙 대상을 추가합니다. | **대상**에서 **대상 추가**를 선택하고 `JobFailedAlert` SNS 주제를 선택합니다. 나머지 세부 정보를 구성하고 Cloudwatch 이벤트 규칙을 생성합니다. | 클라우드 관리자 | 

### 도커 이미지를 빌드하고 Amazon ECR 리포지토리에 푸시하기
<a name="build-a-docker-image-and-push-it-to-an-amazon-ecr-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECR 리포지토리를 생성합니다. | Amazon ECR 콘솔을 열고 리포지토리를 만들 AWS 리전을 선택합니다. **리포지토리**를 선택하고 **리포지토리 생성**을 선택합니다. 요구 사항에 따라 리포지토리를 구성합니다. | 클라우드 관리자 | 
| Dockerfile을 씁니다. | Docker에 로그인하고 *추가 정보* 섹션의 ‘Sample Dockerfile’ 및 ‘Sample entrypoint.sh file’을 사용하여 Dockerfile을 빌드합니다. | DevOps 엔지니어 | 
| 도커 이미지를 생성하여 Amazon ECR 리포지토리로 푸시합니다. | Dockerfile을 도커 이미지로 빌드하고 Amazon ECR 리포지토리로 푸시합니다. 이 사례에 대한 도움이 필요하면 *관련 리소스* 섹션을 참조하세요. | DevOps 엔지니어 | 

### AWS Batch 구성 요소 생성
<a name="create-the-aws-batch-components"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS Batch 작업 정의를 생성합니다. | AWS Batch 콘솔을 열고 Amazon ECR 리포지토리의 URI(Uniform Resource Identifier)를 속성 `Image`(으)로 포함하는 작업 정의를 생성합니다. | 클라우드 관리자 | 
| AWS Batch 작업 대기열을 구성합니다. | AWS Batch 콘솔에서 **작업 대기열**을 선택한 다음 **대기열 생성**을 선택합니다. AWS Batch가 컴퓨팅 환경 내의 리소스에서 작업을 실행할 때까지 작업을 저장할 작업 대기열을 생성합니다. 중요: DynamoDB 인벤토리 테이블에 백업 세부 정보를 기록하는 로직을 AWS Batch에 작성해야 합니다. | 클라우드 관리자 | 

### Lambda 함수 생성 및 예약
<a name="create-and-schedule-a-lambda-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda 함수를 생성하여 태그를 검색합니다. | PostgreSQL DB 인스턴스에서 태그를 검색하고 백업 후보를 식별하는 Lambda 함수를 생성합니다. Lambda 함수가 `bkp:AutomatedDBDump = Active` 태그 및 기타 모든 필수 태그를 식별할 수 있는지 확인하세요. 중요: 또한 Lambda 함수가 AWS Batch 작업 대기열에도 작업을 추가할 수 있어야 합니다. | DevOps 엔지니어 | 
| 시간 기반 CloudWatch Events 이벤트를 생성합니다. | Amazon CloudWatch 콘솔을 열고 cron 표현식을 사용하여 Lambda 함수를 정기적으로 실행하는 CloudWatch Events 이벤트를 생성합니다. 중요: 예정된 이벤트는 모두 UTC 시간대를 사용합니다. | 클라우드 관리자 | 

### 백업 자동화 테스트
<a name="test-the-backup-automation"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon KMS 키를 생성합니다. | Amazon KMS 콘솔을 열고 AWS Secrets Manager에 저장된 Amazon RDS 보안 인증을 암호화하는 데 사용할 수 있는 KMS 키를 생성합니다. | 클라우드 관리자 | 
| AWS Secrets Manager 보안 암호를 생성합니다. | AWS Secrets Manager 콘솔을 열고 Amazon RDS for PostgreSQL 데이터베이스 보안 인증을 암호로 저장합니다. | 클라우드 관리자 | 
| PostgreSQL DB 인스턴스에 필요한 태그를 추가합니다. | Amazon RDS 콘솔을 열고 자동으로 백업하려는 PostgreSQL DB 인스턴스에 태그를 추가합니다. *도구* 섹션의 테이블에 있는 태그를 사용할 수 있습니다. 동일한 Amazon RDS 인스턴스 내에 있는 여러 PostgreSQL 데이터베이스의 백업이 필요한 경우, `-d test:-d test1` 태그에 대한 값으로 `test1`을(를) 사용합니다. `bkp:pgdumpcommand`와 `test`는 데이터베이스 이름입니다. 콜론 (:) 뒤에 공백이 없는지 확인하세요. | 클라우드 관리자 | 
| 백업 자동화를 확인합니다. | 백업 자동화를 확인하려면 Lambda 함수를 호출하거나 백업 일정이 시작될 때까지 기다릴 수 있습니다. 백업 프로세스가 완료되면 DynamoDB 인벤토리 테이블에 PostgreSQL DB 인스턴스에 대한 유효한 백업 항목이 있는지 확인합니다. 두 값이 일치하면 백업 자동화 프로세스가 성공한 것입니다. | 클라우드 관리자 | 

## 관련 리소스
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-resources"></a>

**DynamoDB에 인벤토리 테이블 생성**
+ [Amazon DynamoDB 테이블 생성](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html)

 

**AWS Batch에서 작업 실패 이벤트에 대한 SNS 주제 생성**
+ [Amazon SNS 주제 생성](https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-create-topic.html)
+ [AWS Batch에서 작업 실패 이벤트에 대한 SNS 알림 전송](https://docs.aws.amazon.com/batch/latest/userguide/batch_sns_tutorial.html)

 

**도커 이미지를 빌드하고 Amazon ECR 리포지토리에 푸시하기**
+ [Amazon ECR 리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)    
+ [Dockerfile을 작성하고, 도커 이미지를 생성하여 Amazon ECR로 푸시](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html)

 

**AWS Batch 구성 요소 생성 **
+ [AWS Batch 작업 정의 생성](https://docs.aws.amazon.com/batch/latest/userguide/Batch_GetStarted.html#first-run-step-1)    
+ [컴퓨팅 환경 및 AWS Batch 작업 대기열 구성](https://docs.aws.amazon.com/batch/latest/userguide/Batch_GetStarted.html#first-run-step-2)   
+ [AWS Batch에서 작업 대기열을 생성](https://docs.aws.amazon.com/batch/latest/userguide/create-job-queue.html)

 

**Lambda 함수 생성**
+ [Lambda 함수 생성 및 코드 작성](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html)
+ [DynamoDB와 함께 Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html)

 

**CloudWatch Events 이벤트 생성**
+ [시간 기반 CloudWatch Events 이벤트 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Scheduled-Rule.html)   
+ [Cloudwatch Events에서 cron 표현식 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html)

 

**백업 자동화 테스트**
+ [Amazon KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)    
+ [Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)
+ [Amazon RDS 인스턴스에 태그 추가](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html)

## 추가 정보
<a name="automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch-additional"></a>

**작업 실패 이벤트:**

```
{
  "detail-type": [
    "Batch Job State Change"
  ],
  "source": [
    "aws.batch"
  ],
  "detail": {
    "status": [
      "FAILED"
    ]
  }
}
```

**샘플 Dockerfile:**

```
FROM alpine:latest
RUN apk --update add py-pip postgresql-client jq bash && \
pip install awscli && \
rm -rf /var/cache/apk/*
ADD entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
```

**샘플 entrypoint.sh file:**

```
 #!/bin/bash
set -e
DATETIME=`date +"%Y-%m-%d_%H_%M"`
FILENAME=RDS_PostGres_dump_${RDS_INSTANCE_NAME}
FILE=${FILENAME}_${DATETIME}

aws configure --profile new-profile set role_arn arn:aws:iam::${TargetAccountId}:role/${TargetAccountRoleName}
aws configure --profile new-profile set credential_source EcsContainer

echo "Central Account access provider IAM role is: "
aws sts get-caller-identity

echo "Target Customer Account access provider IAM role is: "
aws sts get-caller-identity --profile new-profile

securestring=$(aws secretsmanager get-secret-value --secret-id $SECRETID --output json --query 'SecretString' --region=$REGION --profile new-profile)

if [[ ${securestring} ]]; then
    echo "successfully accessed secrets manager and got the credentials"
    export PGPASSWORD=$(echo $securestring | jq --raw-output | jq -r '.DB_PASSWORD')
    PGSQL_USER=$(echo $securestring | jq --raw-output | jq -r '.DB_USERNAME')
    echo "Executing pg_dump for the PostGres endpoint ${PGSQL_HOST}"
    # pg_dump -h $PGSQL_HOST -U $PGSQL_USER -n dms_sample | gzip -9 -c  | aws s3 cp - --region=$REGION  --profile new-profile s3://$BUCKET/$FILE
    # in="-n public:-n private"
    IFS=':' list=($EXECUTE_COMMAND);
    for command in "${list[@]}";
      do
        echo $command;
        pg_dump -h $PGSQL_HOST -U $PGSQL_USER ${command} | gzip -9 -c  | aws s3 cp - --region=$REGION --profile new-profile s3://${BUCKET}/${FILE}-${command}".sql.gz"
        echo $?;
        if  [[ $? -ne 0 ]]; then
            echo "Error occurred in database backup process. Exiting now....."
            exit 1
        else
            echo "Postgresql dump was successfully taken for the RDS endpoint ${PGSQL_HOST} and is uploaded to the following S3 location s3://${BUCKET}/${FILE}-${command}.sql.gz"
            #write the details into the inventory table in central account
            echo "Writing to DynamoDB inventory table"
            aws dynamodb put-item --table-name ${RDS_POSTGRES_DUMP_INVENTORY_TABLE} --region=$REGION --item '{ "accountId": { "S": "'"${TargetAccountId}"'" }, "dumpFileUrl": {"S": "'"s3://${BUCKET}/${FILE}-${command}.sql.gz"'" }, "DumpAvailableTime": {"S": "'"`date +"%Y-%m-%d::%H::%M::%S"` UTC"'"}}'
            echo $?
            if  [[ $? -ne 0 ]]; then
                echo "Error occurred while putting item to DynamoDb Inventory Table. Exiting now....."
                exit 1
            else
                echo "Successfully written to DynamoDb Inventory Table ${RDS_POSTGRES_DUMP_INVENTORY_TABLE}"
            fi
        fi
      done;
else
    echo "Something went wrong {$?}"
    exit 1
fi

exec "$@"
```

# CI/CD 파이프라인을 사용하여 Amazon EKS에서 노드 종료 핸들러 배포 자동화
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline"></a>

*Sandip Gangapadhyay, Sandeep Gawande, Viyoma Sachdeva, Pragtideep Singh, John Vargas, Amazon Web Services*

## 요약
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-summary"></a>

**알림**: AWS CodeCommit은 더 이상 신규 고객이 사용할 수 없습니다. AWS CodeCommit의 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. [자세히 알아보기](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)

Amazon Web Services(AWS) 클라우드에서 오픈 소스 프로젝트인 [AWS Node Termination Handler](https://github.com/aws/aws-node-termination-handler)를 사용하여 Kubernetes 내에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 종료를 적절하게 처리할 수 있습니다. AWS Node Termination Handler는 EC2 인스턴스를 사용할 수 없게 만들 수 있는 이벤트에 Kubernetes 컨트롤 플레인이 적절하게 응답하도록 도와줍니다. 이러한 이벤트에는 다음이 포함됩니다.
+ [EC2 인스턴스 유지 관리 일정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)
+ [Amazon EC2 스팟 인스턴스 중단](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html)
+ [Auto Scaling 그룹 스케일 인](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html#as-lifecycle-scale-in)
+ 가용 영역 전반에 걸친 [Auto Scaling 그룹 리밸런싱](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)
+ API 또는 AWS Management Console을 통한 EC2 인스턴스 종료

이벤트가 처리되지 않으면 애플리케이션 코드가 적절하게 중지되지 않을 수 있습니다. 또한 전체 가용성을 복구하는 데 시간이 더 오래 걸리거나 다운되는 노드에 실수로 작업을 예약할 수도 있습니다. `aws-node-termination-handler` (NTH)는 인스턴스 메타데이터 서비스(IMDS)또는 대기열 프로세서라는 두 가지 모드로 작동할 수 있습니다. 두 모드에 대한 자세한 내용은 [Readme 파일](https://github.com/aws/aws-node-termination-handler#readme)을 참조하세요.

이 패턴은를 사용하며 AWS CodeCommit지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 통해 대기열 프로세서를 사용하여 NTH 배포를 자동화합니다.

**참고**  
[EKS 관리형 노드 그룹](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)을 사용하는 경우에는 `aws-node-termination-handler`가 필요하지 않습니다.

## 사전 조건 및 제한 사항
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정.
+ AWS Management Console에서 사용할 수 있도록 지원되는 웹 브라우저. [지원되는 브라우저 목록](https://aws.amazon.com/premiumsupport/knowledge-center/browsers-management-console/)을 참조하세요.
+ AWS Cloud Development Kit(AWS CDK)가 [설치됨](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install).
+ `kubectl`, Kubernetes 명령줄 도구가 [설치됨](https://kubernetes.io/docs/tasks/tools/).
+ `eksctl`, Amazon Elastic Kubernetes Service(Amazon EKS)를 위한 AWS Command Line Interface(AWS CLI)가 [설치됨](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html).
+ 버전 1.20 이상으로 실행 중인 EKS 클러스터
+ EKS 클러스터에 연결된 자체 관리형 노드 그룹입니다. 자체 관리형 노드 그룹이 있는 Amazon EKS 클러스터를 생성하려면 다음 명령을 실행합니다.

  ```
  eksctl create cluster --managed=false --region <region> --name <cluster_name>
  ```

  `eksctl`에 관한 자세한 내용은 [eksctl 설명서](https://eksctl.io/usage/creating-and-managing-clusters/)를 참조하세요.
+ 클러스터에 대한 AWS Identity and Access Management(IAM) OpenID Connect(OIDC) 공급자입니다. 자세한 내용은 [클러스터에 대한 IAM OIDC 공급자 생성](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)을 참조하세요.

**제한 사항 **
+ Amazon EKS 서비스를 지원하는 AWS 리전을 사용해야 합니다.

**제품 버전**
+ Kubernetes 버전 1.20 이상
+ `eksctl` 버전 0.107.0 이상
+ AWS CDK 버전 2.27.0 이상

## 아키텍처
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-architecture"></a>

**대상 기술 스택  **
+ Virtual Private Cloud(VPC)
+ EKS 클러스터
+ Amazon Simple Queue Service(Amazon SQS)
+ IAM
+ Kubernetes

**대상 아키텍처**** **

다음 다이어그램은 노드 종료가 시작될 때의 엔드-투-엔드의 개괄적인 뷰를 보여줍니다.

![\[Auto Scaling 그룹을 사용한 VPC, 노드 종료 핸들러를 사용한 EKS 클러스터 및 SQS 대기열.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/970dfb73-9526-4942-a974-e8eef6416596/images/9e0125ae-d55b-49dd-ae70-ccaedf03832a.png)


다이어그램에 표시된 워크플로우는 다음과 같은 개괄적인 단계로 구성되어 있습니다.

1. 자동 조정 EC2 인스턴스 종료 이벤트는 SQS 대기열로 전송됩니다.

1. NTH 포드는 SQS 대기열의 새 메시지를 모니터링합니다.

1. NTH 포드는 새 메시지를 수신하고 다음을 수행합니다.
   + 새 포드가 노드에서 실행되지 않도록 노드를 차단합니다.
   + 노드를 빼서 기존 포드를 비우도록 합니다.
   + 노드를 종료할 수 있도록 Auto Scaling 그룹에 수명 주기 후크 신호를 전송합니다.

**자동화 및 규모 조정**
+ 코드는 AWS CDK에서 관리하고 배포하며, AWS CloudFormation 중첩 스택의 지원을 받습니다.
+ [Amazon EKS 컨트롤 플레인](https://docs.aws.amazon.com/eks/latest/userguide/disaster-recovery-resiliency.html)은 여러 가용 영역에 걸쳐 실행되어 고가용성을 보장합니다.
+ [자동 조정](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html)을 위해 Amazon EKS는 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) 및 [Karpenter](https://karpenter.sh/)를 지원합니다.

## 도구
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-tools"></a>

**서비스**
+ [AWS Cloud Development Kit(AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)는 AWS 클라우드 인프라를 코드로 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)는 소스 코드를 컴파일하고 유닛 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 완전 관리형 빌드 서비스입니다.
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)은 나만의 소스 제어 시스템을 관리할 필요 없이 Git 리포지토리를 비공개로 저장하고 관리할 수 있는 버전 제어 서비스입니다.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)은 소프트웨어 릴리스의 여러 단계를 신속하게 모델링하고 구성하고 소프트웨어 변경 내용을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다.
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)는 자체 Kubernetes 컨트롤 플레인이나 노드를 설치하거나 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행할 수 있도록 도와줍니다.
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)을 사용하면 애플리케이션 가용성을 유지하고 정의된 조건에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있습니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다.

**기타 도구**
+ [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/)은 Kubernetes 클러스터에 대해 명령을 실행하기 위한 Kubernetes 명령줄 도구입니다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고, 로그를 볼 수 있습니다.

**코드**

이 패턴의 코드는 GitHub.com의 [deploy-nth-to-eks](https://github.com/aws-samples/deploy-nth-to-eks) 리포지토리에서 확인할 수 있습니다. 코드 리포지토리에는 다음 파일 및 폴더가 포함되어 있습니다.
+ `nth folder` - 노드 종료 핸들러용 AWS CloudFormation 템플릿을 스캔하고 배포하기 위한 차트 Helm, 값 파일 및 스크립트입니다.
+ `config/config.json` - 애플리케이션의 구성 파라미터 파일입니다. 이 파일에는 CDK를 배포하는 데 필요한 모든 파라미터가 포함되어 있습니다.
+ `cdk` - AWS CDK 소스 코드입니다.
+ `setup.sh` - 필수 CI/CD 파이프라인 및 기타 필수 리소스를 생성하기 위해 AWS CDK 애플리케이션을 배포하는 데 사용되는 스크립트입니다.
+ `uninstall.sh` - 리소스를 정리하는 데 사용되는 스크립트입니다.

샘플 코드를 사용하려면 *에픽* 섹션의 지침을 따르십시오.

## 모범 사례
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-best-practices"></a>

AWS 노드 종료 핸들러를 자동화하는 모범 사례는 다음을 참조하세요.
+ [EKS 모범 사례 가이드](https://aws.github.io/aws-eks-best-practices/)
+ [노드 종료 핸들러 - 구성](https://github.com/aws/aws-node-termination-handler/tree/main/config/helm/aws-node-termination-handler)

## 에픽
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-epics"></a>

### 환경을 설정합니다
<a name="set-up-your-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | SSH(보안 셸)를 사용하여 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone git@github.com:aws-samples/deploy-nth-to-eks.git</pre>HTTPS를 사용하여 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/deploy-nth-to-eks.git</pre>리포지토리를 복제하면 `deploy-nth-to-eks`(이)라는 이름의 폴더가 생성됩니다.해당 디렉터리로 변경합니다.<pre>cd deploy-nth-to-eks</pre> | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 
| kubeconfig 파일을 설정합니다. | 터미널에 AWS 보안 인증을 설정하고 클러스터 역할을 맡을 권한이 있는지 확인합니다. 다음 예제 코드를 사용할 수 있습니다.<pre>aws eks update-kubeconfig --name <Cluster_Name> --region <region>--role-arn <Role_ARN></pre> | AWS DevOps, DevOps 엔지니어, 앱 개발자 | 

### CI/CD 파이프라인 배포
<a name="deploy-the-ci-cd-pipeline"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 파라미터를 설정합니다. | `config/config.json` 파일에서 다음과 같은 필수 파라미터를 설정합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html) | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 
| CI/CD 파이프라인을 생성하여 NTH를 배포합니다. | setup.sh 스크립트를 실행합니다.<pre>./setup.sh</pre>스크립트는 `config/config.json` 파일의 사용자 입력 파라미터를 기반으로 예제 코드, 파이프라인, CodeBuild 프로젝트가 포함된 CodeCommit 리포지토리를 생성하는 AWS CDK 애플리케이션을 배포합니다.이 스크립트는 sudo 명령으로 npm 패키지를 설치할 때 암호를 묻습니다. | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 
| CI/CD 파이프라인을 검토합니다. | AWS Management Console을 열고 스택에 생성된 다음 리소스를 검토하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html)파이프라인이 성공적으로 실행되면 EKS 클러스터에 Helm 릴리스 `aws-node-termination-handler`(이)가 설치됩니다. 또한 클러스터의 `kube-system` 네임스페이스에서 `aws-node-termination-handler` 이름의 포드가 실행 중입니다. | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 

### NTH 배포 테스트
<a name="test-nth-deployment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Auto Scaling 그룹 스케일 인 이벤트를 시뮬레이션합니다. | 자동 조정 스케일 인 이벤트를 시뮬레이션하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.html) |  | 
| 로그를 검토합니다. | 스케일 인 이벤트 중에 NTH Pod는 해당 워커 노드(스케일 인 이벤트의 일부로 종료될 EC2 인스턴스)를 차단하고 드레이닝합니다. 로그를 확인하려면 *추가 정보* 섹션의 코드를 사용합니다. | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 모든 AWS 리소스를 정리합니다. | 이 패턴으로 생성된 리소스를 정리하려면 다음 명령을 실행합니다.<pre>./uninstall.sh</pre>그러면 CloudFormation 스택이 삭제되어 이 패턴으로 생성된 모든 리소스가 정리됩니다. | DevOps 엔지니어 | 

## 문제 해결
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| npm 레지스트리가 올바르게 설정되지 않았습니다. | 이 솔루션을 설치하는 동안 스크립트는 npm install을 설치하여 필수 패키지를 모두 다운로드합니다. 설치 중에 “모듈을 찾을 수 없습니다”라는 메시지가 표시되면 npm 레지스트리가 올바르게 설정되지 않은 것일 수 있습니다. 현재 레지스트리 설정을 확인하려면 다음 명령을 실행합니다.<pre>npm config get registry</pre>`https://registry.npmjs.org/`(으)로 레지스트리를 설정하려면 다음 명령을 실행합니다.<pre>npm config set registry https://registry.npmjs.org</pre> | 
| SQS 메시지 전송을 지연합니다. | 문제 해결의 일환으로, NTH 포드로 SQS 메시지 전송을 지연하려는 경우 SQS 전송 지연 파라미터를 조정할 수 있습니다. 자세한 내용은 [Amazon SQS 지연 대기열](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html)을 참조하세요. | 

## 관련 리소스
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-resources"></a>
+ [AWS 노드 종료 핸들러 소스 코드](https://github.com/aws/aws-node-termination-handler)
+ [EC2 워크숍](https://ec2spotworkshops.com/using_ec2_spot_instances_with_eks/070_selfmanagednodegroupswithspot/deployhandler.html)
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://aws.amazon.com/eks/)
+ [AWS Cloud Development Kit](https://aws.amazon.com/cdk/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)

## 추가 정보
<a name="automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline-additional"></a>

1. NTH 포드 이름을 찾습니다.

```
kubectl get pods -n kube-system |grep aws-node-termination-handler
aws-node-termination-handler-65445555-kbqc7   1/1     Running   0          26m
kubectl get pods -n kube-system |grep aws-node-termination-handler
aws-node-termination-handler-65445555-kbqc7   1/1     Running   0          26m
```

2. 로그를 확인합니다. 예제 로그는 다음과 같습니다. Auto Scaling 그룹 수명 주기 후크 완료 신호를 보내기 전에 노드가 차단되고 드레이닝되었음을 보여줍니다.

```
kubectl -n kube-system logs aws-node-termination-handler-65445555-kbqc7
022/07/17 20:20:43 INF Adding new event to the event store event={"AutoScalingGroupName":"eksctl-my-cluster-target-nodegroup-ng-10d99c89-NodeGroup-ZME36IGAP7O1","Description":"ASG Lifecycle Termination event received. Instance will be interrupted at 2022-07-17 20:20:42.702 +0000 UTC \n","EndTime":"0001-01-01T00:00:00Z","EventID":"asg-lifecycle-term-33383831316538382d353564362d343332362d613931352d383430666165636334333564","InProgress":false,"InstanceID":"i-0409f2a9d3085b80e","IsManaged":true,"Kind":"SQS_TERMINATE","NodeLabels":null,"NodeName":"ip-192-168-75-60.us-east-2.compute.internal","NodeProcessed":false,"Pods":null,"ProviderID":"aws:///us-east-2c/i-0409f2a9d3085b80e","StartTime":"2022-07-17T20:20:42.702Z","State":""}
2022/07/17 20:20:44 INF Requesting instance drain event-id=asg-lifecycle-term-33383831316538382d353564362d343332362d613931352d383430666165636334333564 instance-id=i-0409f2a9d3085b80e kind=SQS_TERMINATE node-name=ip-192-168-75-60.us-east-2.compute.internal provider-id=aws:///us-east-2c/i-0409f2a9d3085b80e
2022/07/17 20:20:44 INF Pods on node node_name=ip-192-168-75-60.us-east-2.compute.internal pod_names=["aws-node-qchsw","aws-node-termination-handler-65445555-kbqc7","kube-proxy-mz5x5"]
2022/07/17 20:20:44 INF Draining the node
2022/07/17 20:20:44 ??? WARNING: ignoring DaemonSet-managed Pods: kube-system/aws-node-qchsw, kube-system/kube-proxy-mz5x5
2022/07/17 20:20:44 INF Node successfully cordoned and drained node_name=ip-192-168-75-60.us-east-2.compute.internal reason="ASG Lifecycle Termination event received. Instance will be interrupted at 2022-07-17 20:20:42.702 +0000 UTC \n"
2022/07/17 20:20:44 INF Completed ASG Lifecycle Hook (NTH-K8S-TERM-HOOK) for instance i-0409f2a9d3085b80e
```

# CI/CD 파이프라인을 사용하여 Amazon EKS에 Java 애플리케이션 자동 구축 및 배포
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline"></a>

*MAHESH RAGHUNANDANAN, Jomcy Pappachen 및 James Radtke, Amazon Web Services*

## 요약
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-summary"></a>

이 패턴은 권장 DevSecOps 사례에 따라 Java 애플리케이션을 자동으로 빌드하고 AWS 클라우드의 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에 배포하는 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 만드는 방법을 설명합니다. 이 패턴은 Spring Boot Java 프레임워크로 개발되고 Apache Maven을 사용하는 인사말 애플리케이션을 사용합니다.

이 패턴의 접근 방식을 사용하여 Java 애플리케이션용 코드를 빌드하고, 애플리케이션 아티팩트를 도커 이미지로 패키징하고, 이미지를 보안 스캔하고, 이미지를 Amazon EKS의 워크로드 컨테이너로 업로드할 수 있습니다. 이 패턴의 접근 방식은 긴밀하게 연결된 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 마이그레이션하려는 경우에 유용합니다. 또한 이 접근 방식은 Java 애플리케이션의 전체 라이프사이클을 모니터링하고 관리하는 데 도움이 되므로 자동화 수준을 높이고 오류나 버그를 방지하는 데 도움이 됩니다.

## 사전 조건 및 제한 사항
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-prereqs"></a>

**사전 조건 **
+ 활성. AWS 계정
+ AWS Command Line Interface (AWS CLI) 버전 2, 설치 및 구성됨. 이에 대한 자세한 내용은 AWS CLI 설명서에서 [의 최신 버전 설치 또는 업데이트를 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) 참조하세요.

  AWS CLI 버전 2는 Amazon EKS 클러스터를 생성하는 것과 동일한 AWS Identity and Access Management (IAM) 역할로 구성해야 합니다. 해당 역할만 `aws-auth`에 다른 IAM 역할을 추가할 권한이 있기 때문입니다`ConfigMap`. 구성에 대한 자세한 내용과 단계는 AWS CLI 설명서의 [설정 구성을](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) AWS CLI참조하세요.
+ 전체 액세스 권한이 있는 IAM 역할 및 권한 AWS CloudFormation. 이에 대한 자세한 내용은 CloudFormation 설명서의 [IAM으로 액세스 제어를](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) 참조하세요.
+ EKS 클러스터에 있는 워커 노드의 IAM 역할 이름 및 IAM 역할의 Amazon 리소스 이름(ARN)에 대한 세부 정보가 포함된 기존 Amazon EKS 클러스터.
+ Amazon EKS 클러스터에 설치 및 구성된 Kubernetes Cluster Autoscaler. 자세한 내용은 Amazon EKS 설명서에서 [Karpenter 및 Cluster Autoscaler를 사용하여 클러스터 컴퓨팅 자동 규모 조정](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html)을 참조하세요. 
+ GitHub 리포지토리의 코드에 액세스할 수 있습니다.

**중요**  
AWS Security Hub CSPM 는이 패턴의 코드에 포함된 CloudFormation 템플릿의 일부로 활성화됩니다. 기본적으로 Security Hub CSPM이 활성화되면 30일 무료 평가판이 제공됩니다. 평가판을 사용한 후에는이와 관련된 비용이 발생합니다 AWS 서비스. 요금에 대한 자세한 내용은 [AWS Security Hub CSPM 요금](https://aws.amazon.com/security-hub/pricing/)을 참조하세요.

**제품 버전**
+ Helm 버전 3.4.2 이상
+ Apache Maven 버전 3.6.3 이상
+ BridgeCurw Checkov 버전 2.2 이상
+ Aqua Security Trivy 버전 0.37 이상

## 아키텍처
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-architecture"></a>

**기술 스택**
+ AWS CodeBuild
+ AWS CodeCommit
+ Amazon CodeGuru
+ AWS CodePipeline
+ Amazon Elastic Container Registry (Amazon ECR)
+ Amazon EKS
+ Amazon EventBridge
+ AWS Security Hub CSPM
+ Amazon Simple Notification Service(Amazon SNS)

**대상 아키텍처**

![\[Amazon EKS에 Java 애플리케이션을 배포하기 위한 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/95a5b5c2-d7fb-41eb-9089-455318c0d585/images/4f5fd8c2-2b6d-4945-aa64-fcf317521711.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. 개발자는 CodeCommit 리포지토리의 기본 브랜치에서 Java 애플리케이션 코드를 업데이트하여 풀 리퀘스트(PR)를 생성합니다.

1. Amazon CodeGuru Reviewer는 PR이 제출되는 즉시 코드를 자동으로 검토하고 Java 모범 사례를 기반으로 코드를 분석하고 개발자에게 권장 사항을 제공합니다.

1. PR이 기본 브랜치에 병합되면 Amazon EventBridge 이벤트가 생성됩니다.

1. EventBridge 이벤트는 CodePipeline 파이프라인을 시작하고 파이프라인이 시작됩니다.

1. CodePipeline은 코드 보안 스캔 단계(연속 보안)를 실행합니다.

1. AWS CodeBuild 는 Checkov를 사용하여 Dockerfile 및 Kubernetes 배포 Helm 파일을 스캔하고 증분 코드 변경에 따라 애플리케이션 소스 코드를 스캔하는 보안 스캔 프로세스를 시작합니다. 애플리케이션 소스 코드 스캔은 [CodeGuru Reviewer 명령줄 인터페이스(CLI)](https://github.com/aws/aws-codeguru-cli) 래퍼에 의해 수행됩니다.
**참고**  
2025년 11월 7일부터 Amazon CodeGuru Reviewer에서 새 리포지토리 연결을 생성할 수 없습니다. CodeGuru Reviewer와 유사한 기능을 갖춘 서비스에 대한 자세한 내용은 [ CodeGuru Reviewer 설명서의 Amazon CodeGuru Reviewer 가용성 변경을](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html) 참조하세요. CodeGuru 

1. 보안 스캔 단계가 성공하면 빌드 단계(지속적 통합)가 시작됩니다.

1. 빌드 단계에서 CodeBuild는 아티팩트를 빌드하고, 아티팩트를 도커 이미지에 패키징하고, Aqua Security Trivy를 사용하여 이미지의 보안 취약성을 스캔하고, 이미지를 Amazon ECR에 저장합니다.

1. 8단계에서 탐지된 취약성은 개발자 또는 엔지니어의 추가 분석을 위해 Security Hub CSPM에 업로드됩니다. Security Hub CSPM은 취약성을 해결하기 위한 개요와 권장 사항을 제공합니다.

1. CodePipeline 파이프라인 내의 순차적 단계에 대한 이메일 알림이 Amazon SNS를 통해 전송됩니다.

1. 지속적 통합 단계가 완료되면 CodePipeline은 배포 단계(지속적 전달)에 들어갑니다.

1. 도커 이미지는 차트 Helm을 사용하여 Amazon EKS에 컨테이너 워크로드(포드)로 배포됩니다.

1. 애플리케이션 포드는 Amazon CodeGuru Profiler 에이전트로 구성되어 있습니다. 이 에이전트는 애플리케이션의 프로파일링 데이터(CPU, 힙 사용량, 지연 시간)를 Amazon CodeGuru Profiler로 전송하여 개발자가 애플리케이션의 동작을 이해하는 데 도움이 됩니다.

## 도구
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-tools"></a>

**AWS 서비스**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 리전의 수명 주기 동안 리소스를 관리할 수 있습니다.
+  [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)는 소스 코드를 컴파일하고 유닛 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 완전 관리형 빌드 서비스입니다.
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)은 나만의 소스 제어 시스템을 관리할 필요 없이 Git 리포지토리를 비공개로 저장하고 관리할 수 있는 버전 제어 서비스입니다.
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)는 라이브 애플리케이션에서 런타임 성능 데이터를 수집하고 애플리케이션 성능을 미세 조정하는 데 도움이 되는 권장 사항을 제공합니다.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)은 소프트웨어 릴리스의 여러 단계를 신속하게 모델링하고 구성하고 소프트웨어 변경 내용을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장성이 있고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 AWS Lambda 함수, API 대상을 사용하는 HTTP 호출 엔드포인트 또는 다른의 이벤트 버스를 비롯한 다양한 소스의 실시간 데이터와 연결하는 데 도움이 되는 서버리스 이벤트 버스 서비스입니다 AWS 계정.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)는의 보안 상태에 대한 포괄적인 보기를 제공합니다 AWS. 또한 보안 업계 표준 및 모범 사례를 기준으로 AWS 환경을 확인하는 데 도움이 됩니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.

**기타 서비스**
+ [Helm](https://helm.sh/docs/)은 Kubernetes용 오픈소스 패키지 관리자입니다.
+ [Apache Maven](https://maven.apache.org/)은 소프트웨어 프로젝트 관리 및 이해 도구입니다.
+ [BridgeCrew Checkov](https://www.checkov.io/1.Welcome/What%20is%20Checkov.html)는 코드형 인프라(IaC) 파일을 스캔하여 보안 또는 규정 준수 문제로 이어질 수 있는 구성 오류를 찾기 위한 정적 코드 분석 도구입니다.
+ [Aqua Security Trivy](https://github.com/aquasecurity/trivy)는 구성 문제 외에도 컨테이너 이미지, 파일 시스템 및 Git 리포지토리의 취약성에 대한 포괄적인 스캐너입니다.

**코드**

이 패턴의 코드는 GitHub [aws-codepipeline-devsecops-amazoneks](https://github.com/aws-samples/aws-codepipeline-devsecops-amazoneks) 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-best-practices"></a>
+ 이 패턴은 [IAM 보안 모범 사례를](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 따라 솔루션의 모든 단계에서 IAM 엔터티에 대한 최소 권한 원칙을 적용합니다. 추가 AWS 서비스 또는 타사 도구로 솔루션을 확장하려면 IAM 설명서의 [최소 권한 적용](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 섹션을 검토하는 것이 좋습니다.
+ Java 애플리케이션이 여러 개 있는 경우 각 애플리케이션에 대해 별도의 CI/CD 파이프라인을 생성하는 것이 좋습니다.
+ 모놀리식 애플리케이션을 사용하는 경우 애플리케이션을 최대한 마이크로서비스로 분할하는 것이 좋습니다. 마이크로서비스는 더 유연하고 애플리케이션을 컨테이너로 쉽게 배포할 수 있으며 애플리케이션의 전체 빌드 및 배포에 대한 가시성을 높여줍니다.

## 에픽
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-epics"></a>

### 환경 설정
<a name="set-up-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| GitHub 리포지토리를 복제합니다. | 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/aws-codepipeline-devsecops-amazoneks</pre> | 앱 개발자, DevOps 엔지니어 | 
| S3 버킷을 생성하고 코드를 업로드합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps, 클라우드 관리자, DevOps 엔지니어 | 
|  CloudFormation 스택을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps, DevOps 엔지니어 | 
| CloudFormation 스택 배포를 검증합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS DevOps, DevOps 엔지니어 | 
| S3 버킷을 삭제합니다. | 이전에 생성한 S3 버킷을 비우고 삭제합니다. 자세한 내용은 Amazon S3 설명서의 [버킷 삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하십시오. | AWS DevOps, DevOps 엔지니어 | 

### 차트 Helm 구성
<a name="configure-the-helm-charts"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Java 애플리케이션의 차트 Helm을 구성하십시오. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps 엔지니어 | 
| 차트 Helm에 구문 오류가 있는지 검증하십시오. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps 엔지니어 | 

### Java CI/CD 파이프라인 설정
<a name="set-up-the-java-ci-cd-pipeline"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CI/CD 파이프라인을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps | 

### Security Hub CSPM과 Aqua Security 간의 통합 활성화
<a name="activate-integration-between-ash-and-aqua-security"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Aqua Security 통합을 켜십시오. | 이 단계는 Trivy가 보고한 Docker 이미지 취약성 조사 결과를 Security Hub CSPM에 업로드하는 데 필요합니다. CloudFormation 는 Security Hub CSPM 통합을 지원하지 않으므로이 프로세스는 수동으로 수행해야 합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | AWS 관리자, DevOps 엔지니어 | 

### Helm 또는 kubectl 명령을 실행하도록 CodeBuild를 설정합니다.
<a name="configure-acb-to-run-helm-or-kubectl-commands"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CodeBuild가 Amazon EKS 클러스터에서 Helm 또는 kubectl 명령을 실행하도록 허용합니다. | CodeBuild가 Amazon EKS 클러스터에서 Helm 또는 `kubectl` 명령을 사용하도록 인증하려면 IAM 역할을 `aws-auth` `ConfigMap`에 추가해야 합니다. 이 경우 CodeBuild 서비스가 Amazon EKS 클러스터에 액세스하고 클러스터에 워크로드를 배포할 수 있도록 생성된 IAM 역할인 IAM 역할 `EksCodeBuildkubeRoleARN`의 ARN을 추가합니다. 이는 일회성 작업입니다.CodePipeline의 배포 승인 단계 전에 다음 절차를 완료해야 합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html)`aws_auth` `ConfigMap`가 구성되고 액세스 권한이 부여됩니다. | DevOps | 

### CI/CD 파이프라인을 검증합니다.
<a name="validate-the-ci-cd-pipeline"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CI/CD 파이프라인이 자동으로 시작되는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html)CodePipeline을 사용하여 파이프라인을 시작하는 방법에 대한 자세한 내용은 CodePipeline 설명서의 CodePipeline에서 [파이프라인 시작](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-about-starting.html), [수동으로 파이프라인 시작](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-rerun-manually.html), [일정에 따라 파이프라인 시작](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-trigger-source-schedule.html)을 참조하세요. | DevOps | 
| 배포를 승인하십시오. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.html) | DevOps | 
| 애플리케이션 프로파일링 검증. | 배포가 완료되고 애플리케이션 포드가 Amazon EKS에 배포되면, 애플리케이션에 구성된 Amazon CodeGuru Profiler 에이전트는 애플리케이션의 프로파일링 데이터(CPU, 힙 요약, 지연 시간, 병목 현상)를 CodeGuru Profiler로 전송하려고 시도합니다.애플리케이션을 처음 배포할 때 CodeGuru Profiler는 프로파일링 데이터를 시각화하는 데 약 15분이 걸립니다. | DevOps | 

## 관련 리소스
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-resources"></a>
+ [AWS CodePipeline 설명서](https://docs.aws.amazon.com/codepipeline/index.html)
+ (AWS 블로그 게시물)[에서 Trivy로 이미지 스캔 AWS CodePipeline](https://aws.amazon.com/blogs/containers/scanning-images-with-trivy-in-an-aws-codepipeline/) 
+ [Amazon CodeGuru Profiler를 사용하여 Java 애플리케이션 개선](https://aws.amazon.com/blogs/devops/improving-your-java-applications-using-amazon-codeguru-profiler)(AWS 블로그 게시물)
+ [AWS Security Finding Format(ASFF) 구문](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format-syntax.html)
+ [Amazon EventBridge 이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [Helm 업그레이드](https://helm.sh/docs/helm/helm_upgrade/)

## 추가 정보
<a name="automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline-additional"></a>
+ CodeGuru Profiler는 기능 측면에서 AWS X-Ray 서비스와 혼동해서는 안 됩니다. 병목 현상이나 보안 문제를 일으킬 수 있는 가장 비용이 많이 드는 코드 라인을 식별하고 잠재적 위험이 되기 전에 수정하는 데 CodeGuru Profiler를 사용하는 것이 좋습니다. X-Ray 서비스는 애플리케이션 성능 모니터링을 위한 서비스입니다.
+ 이 패턴에서 이벤트 규칙은 기본 이벤트 버스와 연결됩니다. 필요한 경우 패턴을 확장하여 사용자 지정 이벤트 버스를 사용할 수 있습니다.
+ 이 패턴은 CodeGuru Reviewer를 애플리케이션 코드에 대한 정적 애플리케이션 보안 테스트 (SAST) 도구로 사용합니다. 이 파이프라인을 SonarQube 또는 Checkmarx와 같은 다른 도구에도 사용할 수 있습니다. 이러한 도구의 스캔 설정 지침을에 추가하여 CodeGuru 스캔 지침을 대체`buildspec/buildspec_secscan.yaml`할 수 있습니다.
**참고**  
2025년 11월 7일부터 Amazon CodeGuru Reviewer에서 새 리포지토리 연결을 생성할 수 없습니다. CodeGuru Reviewer와 유사한 기능을 갖춘 서비스에 대한 자세한 내용은 [ CodeGuru Reviewer 설명서의 Amazon CodeGuru Reviewer 가용성 변경을](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html) 참조하세요. CodeGuru 

# AWS 계정 및 간에 Amazon ECR 컨테이너 이미지 복사 AWS 리전
<a name="copy-ecr-container-images-across-accounts-regions"></a>

*Faisal Shahdad, Amazon Web Services*

## 요약
<a name="copy-ecr-container-images-across-accounts-regions-summary"></a>

이 패턴은 서버리스 접근 방식을 사용하여 기존 Amazon Elastic Container Registry(Amazon ECR) 리포지토리에서 태그가 지정된 이미지를 다른 AWS 계정 및 로 복제하는 방법을 보여줍니다 AWS 리전. 이 솔루션은 AWS Step Functions 를 사용하여 복제 워크플로와 AWS Lambda 함수를 관리하여 대용량 컨테이너 이미지를 복사합니다.

Amazon ECR은 [리전](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-examples.html#registry-settings-examples-crr-single) 및 [계정 간에 컨테이너 이미지를 복제하는 네이티브 리전 간 및 계정 간](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-examples.html#registry-settings-examples-crossaccount) 복제 기능을 사용합니다. 그러나 이러한 기능은 복제가 켜져 있는 순간에만 이미지를 복제합니다. 다른 리전 및 계정의 기존 이미지를 복제하는 메커니즘은 없습니다.

이 패턴은 인공 지능(AI) 팀이 컨테이너화된 기계 학습(ML) 모델, 프레임워크(예: PyTorch, TensorFlow 및 Hugging Face) 및 종속성을 다른 계정 및 리전에 배포하는 데 도움이 됩니다. 이를 통해 서비스 제한을 극복하고 GPU 컴퓨팅 리소스를 최적화할 수 있습니다. 특정 소스 계정 및 리전에서 Amazon ECR 리포지토리를 선택적으로 복제할 수도 있습니다. (자세한 내용은 [Amazon ECR의 교차 리전 복제가 도입된](https://aws.amazon.com/blogs/containers/cross-region-replication-in-amazon-ecr-has-landed/) AWS Blog 게시물을 참조하십시오.)

## 사전 조건 및 제한 사항
<a name="copy-ecr-container-images-across-accounts-regions-prereqs"></a>

**사전 조건 **
+ 둘 이상의 활성 AWS 계정 (소스 계정 하나와 대상 계정 하나, 최소)
+ 모든 계정의 적절한 AWS Identity and Access Management (IAM) 권한
+ Lambda 컨테이너 이미지를 빌드하기 위한 Docker
+ AWS Command Line Interface 모든 계정에 대해 구성된 (AWS CLI)

**제한 사항 **
+ **태그가 지정되지 않은 이미지 제외 -** 솔루션은 명시적 태그가 있는 컨테이너 이미지만 복사합니다. 다이`SHA256`제스트와 함께 존재하는 태그가 지정되지 않은 이미지는 건너뜁니다.
+ **Lambda 실행 제한 시간 –** AWS Lambda 최대 15분의 실행 제한 시간으로 제한되며, 이는 대용량 컨테이너 이미지 또는 리포지토리를 복사하는 데 충분하지 않을 수 있습니다.
+ **수동 컨테이너 이미지 관리 -** `crane-app.py` Python 코드를 사용하려면 Lambda 컨테이너 이미지를 다시 빌드하고 재배포해야 합니다.
+ **제한된 병렬 처리 용량 -** `MaxConcurrency` 상태 설정은 동시에 복사할 수 있는 리포지토리 수를 제한합니다. 그러나 소스 계정의 AWS CloudFormation 템플릿에서이 설정을 수정할 수 있습니다. 동시성 값이 높을수록 서비스 속도 제한 및 계정 수준 Lambda 실행 할당량을 초과할 수 있습니다.

## 아키텍처
<a name="copy-ecr-container-images-across-accounts-regions-architecture"></a>

**대상 스택**

패턴에는 네 가지 주요 구성 요소가 있습니다.
+ **소스 계정 인프라 -** 오케스트레이션 구성 요소를 생성하는 CloudFormation 템플릿
+ **대상 계정 인프라 **- 교차 계정 액세스 역할을 생성하는 CloudFormation 템플릿
+ **Lambda 함수 **- 효율적인 이미지 복사를 위해 Crane을 사용하는 Python 기반 함수
+ **컨테이너 이미지 -** 필요한 도구로 Lambda 함수를 패키징하는 Docker 컨테이너

**대상 아키텍처 **

![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/787185e7-664b-4ed8-b30f-1d9507f13377/images/cc7d9823-3dc8-4090-a203-910b1ac4447c.png)


**Step Functions 워크플로우**

Step Functions 상태 시스템은 다음 다이어그램과 같이 다음을 오케스트레이션합니다.
+ `PopulateRepositoryList`** -** Amazon ECR 리포지토리를 스캔하고 Amazon DynamoDB를 채웁니다.
+ `GetRepositoryList`** -** DynamoDB에서 고유한 리포지토리 목록을 검색합니다.
+ `DeduplicateRepositories`** -** 중복 처리가 없는지 확인합니다.
+ `CopyRepositories`** -** 리포지토리의 병렬 복사를 처리합니다.
+ `NotifySuccess`/`NotifyFailure`** -** 실행 결과를 기반으로 하는 Amazon Simple Notification Service(Amazon SNS) 알림

![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/787185e7-664b-4ed8-b30f-1d9507f13377/images/1b740084-ba2b-4956-aa12-ebbf52be5e7d.png)


## 도구
<a name="copy-ecr-container-images-across-accounts-regions-tools"></a>

**Amazon 도구**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)를 사용하면 AWS 리소스 및에서 실행되는 애플리케이션의 지표를 실시간으로 모니터링할 AWS 수 있습니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 Lambda 함수 및 기타를 결합하여 비즈니스 크리티컬 애플리케이션을 구축하는 AWS 서비스 데 도움이 되는 서버리스 오케스트레이션 서비스입니다.

**기타 도구**
+ [Crane](https://michaelsauter.github.io/crane/index.html)은 Docker 오케스트레이션 도구입니다. Docker Compose와 비슷하지만 추가 기능이 있습니다.
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.

**코드 리포지토리**
+ 이 패턴의 코드는 GitHub [aws-config-rules](https://github.com/aws-samples/sample-ecr-copy) 리포지토리에서 사용할 수 있습니다. 리포지토리의 CloudFormation 템플릿을 사용하여 기본 리소스를 생성할 수 있습니다.

## 모범 사례
<a name="copy-ecr-container-images-across-accounts-regions-best-practices"></a>

최소 권한 원칙을 따르고 작업을 수행하는 데 필요한 최소 권한을 부여하세요. 자세한 내용은 IAM 설명서의 [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv) 및 [보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.

## 에픽
<a name="copy-ecr-container-images-across-accounts-regions-epics"></a>

### 환경 준비
<a name="prepare-your-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS CLI 프로필을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, 데이터 엔지니어, ML 엔지니어 | 
| 필수 정보 수집 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, 데이터 엔지니어, ML 엔지니어 | 
| 리포지토리를 복제합니다. | 프로젝트의 리포지토리를 로컬 워크스테이션에 복제합니다.<pre>git clone https://github.com/aws-samples/sample-ecr-copy</pre> | DevOps 엔지니어, 데이터 엔지니어, ML 엔지니어 | 

### 대상 계정에 대한 인프라 배포
<a name="deploy-infrastructure-for-the-destination-account"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 템플릿 확인 | CloudFormation 템플릿 생성<pre>aws cloudformation validate-template \<br />  --template-body file://"Destination Account cf_template.yml" \<br />  --profile destination-account</pre> | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 대상 인프라를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 배포를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 

### 컨테이너 이미지 빌드 및 배포
<a name="build-and-deploy-the-lam-container-image"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 컨테이너 빌드를 준비합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 를 사용하여 컨테이너 이미지를 빌드합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 리포지토리 생성 및 이미지 업로드 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 이미지를 확인하세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 

### 소스 계정 인프라 배포
<a name="deploy-the-source-account-infrastructure"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 배포 파라미터 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 소스 템플릿을 검증합니다. | 소스 CloudFormation 템플릿을 검증합니다.<pre>aws cloudformation validate-template \<br />  --template-body file://"Source Account Cf template.yml" \<br />  --profile source-account</pre> | 데이터 엔지니어, DevOps 엔지니어 | 
| 인프라를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 
| 배포를 확인하고 출력을 수집합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 이메일 구독을 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 데이터 엔지니어, DevOps 엔지니어 | 

### 복사 프로세스 실행 및 모니터링
<a name="run-and-monitor-the-copy-process"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 복사 프로세스를 실행하고 모니터링합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 단계 함수를 실행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 진행률 모니터링 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 결과를 확인합니다. | 프로세스가 완료될 때까지 기다립니다(30초마다 업데이트됨).<pre>while true; do<br />  STATUS=$(aws stepfunctions describe-execution \<br />    --execution-arn $EXECUTION_ARN \<br />    --profile source-account \<br />    --region $SOURCE_REGION \<br />    --query 'status' \<br />    --output text)<br />  <br />  echo "Current status: $STATUS"<br />  <br />  if [[ "$STATUS" == "SUCCEEDED" || "$STATUS" == "FAILED" || "$STATUS" == "TIMED_OUT" || "$STATUS" == "ABORTED" ]]; then<br />    break<br />  fi<br />  <br />  sleep 30<br />done<br /><br />echo "Final execution status: $STATUS"</pre> | DevOps 엔지니어, ML 엔지니어, 데이터 엔지니어 | 
| 이미지를 확인하세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | DevOps 엔지니어, 데이터 엔지니어, ML 엔지니어 | 

## 문제 해결
<a name="copy-ecr-container-images-across-accounts-regions-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 단계 함수가 실행되지 않습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-ecr-container-images-across-accounts-regions.html) | 

## 관련 리소스
<a name="copy-ecr-container-images-across-accounts-regions-resources"></a>
+ [크레인 설명서](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md)
+ [Amazon Elastic Container Registry란 무엇입니까?](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)
+ [란 무엇입니까 AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)

## 추가 정보
<a name="copy-ecr-container-images-across-accounts-regions-additional"></a>

**구성 파라미터**


| 
| 
| 파라미터 | 설명 | 예제 | 
| --- |--- |--- |
| `SourceAccountId` | 소스 AWS 계정 ID | `11111111111` | 
| `DestinationAccountId` | 대상 AWS 계정 ID | `22222222222` | 
| `DestinationRegion` | 대상 AWS 리전 | `us-east-2` | 
| `SourceRegion` | 소스 AWS 리전 | `us-east-1` | 
| `NotificationEmail` | 이메일 알림 | `abc@xyz.com` | 
| `RepositoryList` | 복사할 리포지토리 | `repo1,repo2,repo3` | 
| `LambdaImageUri` | Lambda 컨테이너 이미지 | `${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com/ecr-copy-lambda:latest` | 

# Amazon ECS 작업 정의를 생성하고 Amazon EFS를 사용하여 EC2 인스턴스에 파일 시스템을 마운트
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs"></a>

*Durga Prasad Cheepuri, Amazon Web Services*

## 요약
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-summary"></a>

이 패턴은 Amazon Elastic File System(Amazon EFS)을 사용하여 해당 EC2 인스턴스에 파일 시스템을 마운트하면서 Amazon Web Services(AWS) 클라우드의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되는 Amazon Elastic Container Service(Amazon ECS) 작업 정의를 생성하는 코드 샘플 및 단계를 제공합니다. Amazon EFS를 사용하는 Amazon ECS 작업은 작업 정의에서 지정한 파일 시스템을 자동으로 마운트하고 AWS 리전의 모든 가용 영역에 있는 작업 컨테이너에서 이러한 파일 시스템을 사용할 수 있도록 합니다.

영구 스토리지 및 공유 스토리지 요구 사항을 충족하기 위해 Amazon ECS와 Amazon EFS를 함께 사용할 수 있습니다. 예를 들어, 고가용성을 위해 서로 다른 가용 영역에서 실행 중인 활성 및 대기 ECS 컨테이너 페어가 있는 애플리케이션의 영구 사용자 데이터와 애플리케이션 데이터를 저장하는 데 Amazon EFS를 사용할 수 있습니다. 또한 Amazon EFS를 사용하여 ECS 컨테이너와 분산 작업 워크로드에서 병렬로 액세스할 수 있는 공유 데이터를 저장할 수 있습니다.

Amazon EFS를 Amazon ECS와 함께 사용하려면 작업 정의에 하나 이상의 볼륨 정의를 추가할 수 있습니다. 볼륨 정의에는 Amazon EFS 파일 시스템 ID, 액세스 포인트 ID, 그리고 전송 중 AWS Identity and Access Management(IAM) 인증 또는 전송 계층 보안(TLS) 암호화를 위한 구성이 포함됩니다. 작업 정의 내에서 컨테이너 정의를 사용하여 컨테이너가 실행될 때 마운트되는 작업 정의 볼륨을 지정할 수 있습니다. Amazon EFS 파일 시스템을 사용하는 작업이 실행되면 Amazon ECS는 파일 시스템이 마운트되어 액세스가 필요한 컨테이너에서 사용할 수 있도록 합니다.

## 사전 조건 및 제한 사항
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ 가상 프라이빗 네트워크(VPN) 엔드포인트 또는 라우터가 있는 Virtual Private Cloud(VPC)
+ (권장) Amazon EFS 액세스 포인트 및 IAM 인증 기능과의 호환성을 위한 [Amazon ECS 컨테이너 에이전트 1.38.0 이상](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-versions.html)(자세한 내용은 AWS Blog의 [Amazon EFS 새 소식 – IAM 인증 및 액세스 포인트](https://aws.amazon.com/blogs/aws/new-for-amazon-efs-iam-authorization-and-access-points/) 포스트를 참조하세요.)

**제한 사항 **
+ 1.35.0 이전의 Amazon ECS 컨테이너 에이전트 버전은 EC2 시작 유형을 사용하는 작업의 Amazon EFS 파일 시스템을 지원하지 않습니다.

## 아키텍처
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-architecture"></a>

다음 다이어그램은 Amazon ECS를 사용하여 작업 정의를 생성하고 ECS 컨테이너의 EC2 인스턴스에 Amazon EFS 파일 시스템을 마운트하는 애플리케이션의 예를 보여줍니다.

![\[Amazon ECS architecture with task definition, ECS service, containers, and EFS file system integration.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/090a3f03-a4c6-47e3-b1ae-b0eb5c5b269c/images/343e0f1d-44ee-4ec2-8392-aeddc0e48b83.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. Amazon EFS 파일 시스템을 생성합니다.

1. 컨테이너로 작업 정의를 생성합니다.

1. Amazon EFS 파일 시스템을 마운트하도록 컨테이너 인스턴스를 구성합니다. 작업 정의는 볼륨 마운트를 참조하여, 컨테이너 인스턴스가 Amazon EFS 파일 시스템을 사용할 수 있습니다. ECS 작업은 해당 작업이 생성된 컨테이너 인스턴스와 상관없이 동일한 Amazon EFS 파일 시스템에 액세스할 수 있습니다.

1. 작업 정의의 인스턴스 3개를 사용하여 Amazon ECS 서비스를 생성합니다.

**기술 스택**
+ Amazon EC2
+ Amazon ECS
+ Amazon EFS

## 도구
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-tools"></a>
+ [Amazon EC2](https://docs.aws.amazon.com/ec2/?id=docs_gateway) – Amazon Elastic Compute Cloud(Amazon EC2)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. Amazon EC2를 사용하여 필요에 따라 많거나 적은 수의 가상 서버를 시작하고 스케일 아웃 또는 스케일 인할 수 있습니다.
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service(Amazon ECS)는 클러스터에서 컨테이너를 실행, 중지 및 관리하기 위한 컨테이너 관리 서비스로서 확장성과 속도가 뛰어납니다. AWS Fargate에서 관리하는 서버리스 인프라에서 작업 및 서비스를 실행할 수 있습니다. 또는 인프라에 대한 더 세부적인 제어를 위해 관리하는 EC2 인스턴스의 클러스터에서 작업과 서비스를 실행할 수 있습니다.
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) – Amazon Elastic File System(Amazon EFS)은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능하며 완전 관리형 탄력적인 NFS 파일 시스템을 제공합니다.
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) – AWS Command Line Interface(AWS CLI)는 명령줄 쉘에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다. 최소한의 구성으로 AWS CLI 명령을 사용하여 터미널 프로그램에 있는 명령 프롬프트에서 브라우저 기반 AWS Management Console에서 제공되는 것과 동일한 기능을 구현하는 명령을 실행할 수 있습니다.

## 에픽
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-epics"></a>

### Amazon EFS 파일 시스템 생성
<a name="create-an-amazon-efs-file-system"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS Management Console을 사용하여 Amazon EFS 파일 시스템을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | AWS DevOps | 

### Amazon EFS 파일 시스템 또는 AWS CLI를 사용하여 Amazon ECS 작업 정의를 생성
<a name="create-an-amazon-ecs-task-definition-by-using-either-an-amazon-efs-file-system-or-the-aws-cli"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EFS 파일 시스템을 사용하여 작업 정의를 생성합니다. | [새로운 Amazon ECS 콘솔](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html) 또는 다음과 같은 구성의 [클래식 Amazon ECS 콘솔](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition-classic.html)을 사용하여 작업 정의를 생성합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | AWS DevOps | 
| AWS CLI를 사용하여 작업 정의를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.html) | DevOps | 

## 관련 리소스
<a name="create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs-resources"></a>
+ [Amazon ECS 작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)
+ [Amazon EFS 볼륨](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/efs-volumes.html)

## 첨부
<a name="attachments-090a3f03-a4c6-47e3-b1ae-b0eb5c5b269c"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/090a3f03-a4c6-47e3-b1ae-b0eb5c5b269c/attachments/attachment.zip) 파일의 압축을 풉니다.

# 컨테이너 이미지로 Lambda 함수 배포
<a name="deploy-lambda-functions-with-container-images"></a>

*Ram Kandaswamy, Amazon Web Services*

## 요약
<a name="deploy-lambda-functions-with-container-images-summary"></a>

AWS Lambda 는 컨테이너 이미지를 배포 모델로 지원합니다. 이 패턴은 컨테이너 이미지를 통해 Lambda 함수를 배포하는 방법을 보여줍니다. 

Lambda는 서버를 프로비저닝하거나 관리하지 않고도 사실상 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 실행할 수 있는 서버리스 이벤트 기반 컴퓨팅 서비스입니다. Lambda 함수에 대한 컨테이너 이미지 지원을 통해 애플리케이션 아티팩트에 최대 10GB의 스토리지와 친숙한 컨테이너 이미지 개발 도구를 사용할 수 있는 이점을 얻을 수 있습니다.

이 패턴의 예제에서는 Python을 기본 프로그래밍 언어로 사용하지만 Java, Node.js, Go와 같은 다른 언어를 사용할 수 있습니다. 소스의 경우 GitHub, GitLab, Bitbucket 등의 Git 기반 시스템을 고려하거나 Amazon Simple Storage Service(Amazon S3 사용합니다.

## 사전 조건 및 제한 사항
<a name="deploy-lambda-functions-with-container-images-prereqs"></a>

**사전 조건 **
+ Amazon Elastic Container Registry(Amazon ECR) 활성화됨
+ 애플리케이션 코드
+ 런타임 인터페이스 클라이언트와 최신 버전의 Python이 포함된 Docker 이미지
+ Git에 대한 실무 지식

**제한 사항 **
+ 지원되는 최대 이미지 크기는 10GB입니다.
+ Lambda 기반 컨테이너 배포의 최대 런타임은 15분입니다.

## 아키텍처
<a name="deploy-lambda-functions-with-container-images-architecture"></a>

**대상 아키텍처**

![\[Lambda 함수를 생성하는 4단계 프로세스.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e421cc58-d33e-493d-b0bb-c3ffe39c2eb9/images/7f36d3d8-d161-497a-b036-26d886a16c69.png)


 

1. Git 리포지토리를 생성하고 애플리케이션 코드를 리포지토리에 커밋합니다.

1. 커밋 변경으로 인해 AWS CodeBuild 프로젝트가 트리거됩니다.

1. CodeBuild 프로젝트는 도커 이미지를 생성하고 빌드된 이미지를 Amazon ECR에 게시합니다.

1. Amazon ECR에서 이미지를 사용하여 Lambda 함수를 생성합니다.

**자동화 및 규모 조정**

이 패턴은 SDK에서 AWS CloudFormation AWS Cloud Development Kit (AWS CDK)또는 API 작업을 사용하여 자동화할 수 있습니다. Lambda는 요청 수에 따라 자동으로 규모를 조정할 수 있으며, 동시성 파라미터를 사용하여 Lambda를 조정할 수 있습니다. 자세한 내용은 [Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html).를 참조하세요.

## 도구
<a name="deploy-lambda-functions-with-container-images-tools"></a>

**서비스**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) AWS CloudFormationhelps 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 전체 수명 주기 동안 관리할 수 있습니다 AWS 리전. 이 패턴은 CloudFormation 템플릿을 시각적으로 보고 편집하는 데 도움이 되는 [AWS CloudFormation Application Composer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/app-composer-for-cloudformation.html)를 사용합니다.
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)는 소스 코드를 컴파일하고 유닛 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 완전 관리형 빌드 서비스입니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장성이 있고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.

**기타 도구**
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.
+ [GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories), [GitLab](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html) 및 [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-git/)은 소스 코드 변경 사항을 추적하는 데 일반적으로 사용되는 Git 기반 소스 제어 시스템입니다.

## 모범 사례
<a name="deploy-lambda-functions-with-container-images-best-practices"></a>
+ 함수를 최대한 효율적이고 작게 만들어 불필요한 파일이 로드되지 않도록 하십시오.
+ Docker 파일 목록에서 정적 계층은 위쪽에 배치하고 자주 변경되는 계층은 아래쪽에 배치하십시오. 이렇게 하면 캐싱이 개선되어 성능이 향상됩니다.
+ 이미지 업데이트 및 패치 적용은 이미지 소유자가 담당합니다. 운영 프로세스에 해당 업데이트 케이던스를 추가합니다. 자세한 내용은 [AWS Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-code)를 참조하세요.

## 에픽
<a name="deploy-lambda-functions-with-container-images-epics"></a>

### CodeBuild에서 프로젝트 생성
<a name="create-a-project-in-codebuild"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Git 리포지토리를 생성합니다. | 애플리케이션 소스 코드, Dockerfile 및 `buildspec.yaml` 파일을 포함할 Git 리포지토리를 생성합니다. | 개발자 | 
| CodeBuild 프로젝트를 생성합니다. | CodeBuild 프로젝트를 사용하여 사용자 지정 Lambda 이미지를 생성하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html) | 개발자 | 
| Dockerfile을 편집합니다. | Dockerfile은 애플리케이션을 개발하는 최상위 디렉터리에 있어야 합니다. Python 코드는 `src` 폴더에 있어야 합니다.이미지를 생성할 때는 [Lambda 지원 공식 이미지](https://gallery.ecr.aws/lambda?page=1)를 사용하십시오. 그렇지 않으면 부트스트랩 오류가 발생하여 패킹 프로세스가 더 어려워집니다.자세한 내용은 [추가 정보](#deploy-lambda-functions-with-container-images-additional) 섹션을 참조하세요. | 개발자 | 
| Amazon ECR 리포지토리를 생성합니다. | Amazon ECR에 컨테이너 리포지토리를 생성합니다. 다음 예제 명령에서 생성된 리포지토리의 이름은 `cf-demo`입니다.<pre>aws ecr create-repository --cf-demo </pre>리포지토리는 `buildspec.yaml` 파일에서 참조됩니다. | AWS 관리자, 개발자 | 
| 이미지를 Amazon ECR로 푸시합니다. | CodeBuild를 사용하여 이미지 빌드 프로세스를 수행할 수 있습니다. CodeBuild는 Amazon ECR과 상호 작용하고 S3를 사용할 수 있는 권한이 필요합니다. 프로세스의 일부로 Docker 이미지가 빌드되어 Amazon ECR 레지스트리로 푸시됩니다. 템플릿과 코드에 대한 자세한 내용은 [추가 정보](#deploy-lambda-functions-with-container-images-additional) 섹션을 참조하세요. | 개발자 | 
| 이미지가 리포지토리에 있는지 확인하십시오. | 이미지가 리포지토리에 있는지 확인하려면 Amazon ECR 콘솔에서 **리포지토리**를 선택합니다. Amazon ECR 설정에서 해당 기능이 켜져 있는 경우 취약성 스캔 보고서 결과와 함께 이미지가 태그 및 함께 나열되어야 합니다.  자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/cli/latest/reference/ecr/put-registry-scanning-configuration.html)를 참조하세요. | 개발자 | 

### Lambda 함수를 생성하고 이미지를 배포합니다.
<a name="create-the-lambda-function-to-run-the-image"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda 함수를 생성합니다. | Lambda 콘솔에서 **함수 생성**을 선택한 다음 **컨테이너 이미지**를 선택합니다. Amazon ECR 리포지토리에 있는 이미지의 URI와 함수 이름을 입력한 다음 **함수 생성**을 선택합니다. 자세한 내용은 [AWS Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/API_CreateFunction.html)를 참조하세요. | 앱 개발자 | 
| Lambda 함수를 테스트합니다. | 함수를 간접 호출하고 테스트하려면 **테스트**를 선택합니다. 자세한 내용은 [AWS Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html)를 참조하세요. | 앱 개발자 | 

## 문제 해결
<a name="deploy-lambda-functions-with-container-images-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 빌드가 성공하지 못했습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html) | 

## 관련 리소스
<a name="deploy-lambda-functions-with-container-images-resources"></a>
+ [Lambda용 기본 이미지](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-images.html)
+ [CodeBuild용 Docker 샘플](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-docker.html)
+ [임시 보안 인증 전달](https://aws.amazon.com/premiumsupport/knowledge-center/codebuild-temporary-credentials-docker/)

## 추가 정보
<a name="deploy-lambda-functions-with-container-images-additional"></a>

**Dockerfile 편집**

다음 코드는 Dockerfile에서 편집하는 명령을 보여줍니다.

```
FROM public.ecr.aws/lambda/python:3.xx

# Copy function code
COPY app.py ${LAMBDA_TASK_ROOT} 
COPY requirements.txt  ${LAMBDA_TASK_ROOT} 

# install dependencies
RUN pip3 install --user -r requirements.txt

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.lambda_handler" ]
```

`FROM` 명령에서 Lambda에서 지원하는 Python 버전에 적절한 값을 사용합니다(예: `3.12`). 이는 퍼블릭 Amazon ECR 이미지 리포지토리에서 사용할 수 있는 기본 이미지입니다. 

이 `COPY app.py ${LAMBDA_TASK_ROOT}` 명령은 Lambda 함수가 사용할 작업 루트 디렉터리에 코드를 복사합니다. 이 명령은 환경 변수를 사용하므로 실제 경로에 대해 걱정할 필요가 없습니다. 실행할 함수는 `CMD [ "app.lambda_handler" ]` 명령에 인수로 전달됩니다.

이 `COPY requirements.txt` 명령은 코드에 필요한 종속성을 캡처합니다. 

이 `RUN pip install --user -r requirements.txt` 명령은 로컬 사용자 디렉터리에 종속성을 설치합니다. 

이미지를 빌드하려면 다음 명령을 실행합니다.

```
docker build -t <image name> .
```

**Amazon ECR에 이미지를 추가합니다.**

다음 코드에서 `aws_account_id`를 계정 번호로 바꾸고, 다른 리전을 사용하는 경우 `us-east-1`을 바꾸십시오. 이 `buildspec` 파일은 CodeBuild 빌드 번호를 사용하여 이미지 버전을 태그 값으로 고유하게 식별합니다. 이를 요구 사항에 맞게 변경할 수 있습니다.

*빌드스펙 사용자 지정 코드*

```
phases:
  install:
    runtime-versions:
       python: 3.xx
  pre_build:
    commands:
      - python3 --version
      - pip3 install --upgrade pip
      - pip3 install --upgrade awscli
      - sudo docker info
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - ls
      - cd app
      - docker build -t cf-demo:$CODEBUILD_BUILD_NUMBER .
      - docker container ls
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.us-east-1.amazonaws.com
      - docker tag cf-demo:$CODEBUILD_BUILD_NUMBER aws_account_id.dkr.ecr.us-east-1.amazonaws.com/cf-demo:$CODEBUILD_BUILD_NUMBER
      - docker push aws_account_id.dkr.ecr.us-east-1.amazonaws.com/cf-demo:$CODEBUILD_BUILD_NUMBER
```

# Fargate를 사용하여 Amazon ECS에 Java 마이크로서비스 배포
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate"></a>

*Vijay Thompson, Sandeep Bondugula, Amazon Web Services*

## 요약
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-summary"></a>

이 패턴은 Fargate를 사용하여 Amazon Elastic Container Service(Amazon ECS)에 컨테이너식 Java 마이크로서비스를 배포하기 위한 지침을 제공합니다. 이 패턴은 컨테이너 관리에 Amazon Elastic Container Registry(Amazon ECR)를 사용하지 않으며, 그 대신에 Docker 허브에서 Docker 이미지를 가져옵니다.

## 사전 조건 및 제한 사항
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-prereqs"></a>

**사전 조건 **
+ Docker 허브의 기존 Java 마이크로서비스 애플리케이션
+ 퍼블릭 Docker 리포지토리
+ 활성 상태의 AWS 계정
+ Amazon ECS 및 Fargate를 포함한 서비스에 대한 지식
+ Docker, Java 및 Spring Boot 프레임워크
+ Amazon Relational Database Service(Amazon RDS) 가동 및 실행 중(선택 사항)
+ 애플리케이션에 Amazon RDS(선택 사항)가 필요한 경우 Virtual Private Cloud(VPC)

## 아키텍처
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-architecture"></a>

**소스 기술 스택**
+ Java 마이크로서비스(예: Spring Boot에 구현됨) 및 Docker에 배포됨

**소스 아키텍처**

![\[Docker에 배포된 Java 마이크로서비스의 소스 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/65185957-2b8b-43a6-964c-95ce0a45ba17/images/0a946ca8-fe37-4ede-85cb-a80a1c36105d.png)


**대상 기술 스택**
+ Fargate를 사용하여 각 마이크로서비스를 호스팅하는 Amazon ECS 클러스터
+ Amazon ECS 클러스터 및 관련 보안 그룹을 호스팅하는 VPC 네트워크 
+ Fargate를 사용하여 컨테이너를 구동하는 각 마이크로서비스에 대한 클러스터/태스크 정의

**대상 아키텍처**

![\[Amazon ECS의 Java 마이크로서비스에 대한 대상 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/65185957-2b8b-43a6-964c-95ce0a45ba17/images/b21349ea-21fc-4688-b76a-1bde479858aa.png)


## 도구
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-tools"></a>

**도구**
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)를 사용하면 자체 컨테이너 오케스트레이션 소프트웨어를 설치 및 운영하거나, 가상 시스템 클러스터를 관리 및 확장하거나, 가상 시스템에서 컨테이너를 예약할 필요가 없습니다. 
+ [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html)를 사용하면 서버 또는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 관리할 필요 없이 컨테이너를 실행할 수 있습니다. Amazon Elastic Container Service(Amazon ECS)와 함께 사용합니다.
+ [Docker](https://www.docker.com/)는 애플리케이션을 신속하게 구축, 테스트 및 배포하기 위한 소프트웨어 플랫폼입니다. Docker는 소프트웨어를 컨테이너라는 표준화된 단위로 패키징합니다. *컨테이너*에는 라이브러리, 시스템 도구, 코드 및 런타임을 포함하여 소프트웨어 실행에 필요한 모든 것이 들어 있습니다. 

**Docker 코드**

다음 Dockerfile은 사용되는 Java Development Kit(JDK) 버전, Java Archive(JAR) 파일이 있는 위치, 노출되는 포트 번호, 애플리케이션의 진입점을 지정합니다.

```
FROM openjdk:11
ADD target/Spring-docker.jar Spring-docker.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","Spring-docker.jar"]
```

## 에픽
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-epics"></a>

### 새 태스크 정의 생성
<a name="create-new-task-definitions"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 작업 정의를 생성합니다. | Amazon ECS에서 Docker 컨테이너를 실행하려면 태스크 정의가 필요합니다. [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)에서 Amazon ECS 콘솔을 열고 **태스크 정의**를 선택한 다음 새 태스크 정의를 생성합니다. 자세한 내용은 [Amazon ECS 설명서](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)를 참조하세요. | 시스템 관리자, 앱 개발자 | 
| 시작 유형을 선택합니다. | **Fargate**를 시작 유형으로 선택합니다. | 시스템 관리자, 앱 개발자 | 
| 태스크를 구성합니다. | 태스크 이름을 정의하고 적절한 양의 태스크 메모리와 CPU로 애플리케이션을 구성합니다. | 시스템 관리자, 앱 개발자 | 
| 컨테이너를 정의합니다. | 컨테이너 이름을 지정합니다. 이미지의 경우 Docker 사이트 이름, 리포지토리 이름 및 Docker 이미지(`docker.io/sample-repo/sample-application:sample-tag-name`)의 태그 이름을 입력합니다. 애플리케이션의 메모리 제한을 설정하고 허용된 포트에 포트 매핑(`8080, 80`)을 설정합니다. | 시스템 관리자, 앱 개발자 | 
| 태스크을 생성합니다. | 태스크 및 컨테이너 구성이 준비되면 태스크을 생성합니다. 세부적인 지침은 *관련 리소스* 섹션의 링크를 참조하세요. | 시스템 관리자, 앱 개발자 | 

### 클러스터 구성
<a name="configure-the-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 클러스터를 생성하고 구성합니다. | **네트워킹 전용**을 클러스터 유형으로 선택하고 이름을 구성한 다음 클러스터를 생성하거나 이용할 수 있다면 기존 클러스터를 사용합니다. 자세한 내용은 [Amazon ECS 설명서](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)를 참조하세요. | 시스템 관리자, 앱 개발자 | 

### 태스크 구성
<a name="configure-task"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  작업을 생성합니다. | 클러스터 내에서 **새 태스크 실행**을 선택합니다. | 시스템 관리자, 앱 개발자 | 
| 시작 유형을 선택합니다. | **Fargate**를 시작 유형으로 선택합니다. | 시스템 관리자, 앱 개발자 | 
| 태스크 정의, 수정, 플랫폼 버전을 선택합니다. | 실행하려는 태스크, 태스크 정의의 수정, 플랫폼 버전을 선택합니다. | 시스템 관리자, 앱 개발자 | 
| 클러스터를 선택합니다. | 태스크를 실행하려는 해당 클러스터를 선택합니다. | 시스템 관리자, 앱 개발자 | 
| 태스크 수를 지정합니다. | 실행해야 하는 태스크 수를 구성합니다. 두 개 이상의 태스크으로 시작하는 경우 태스크 간에 트래픽을 분산하기 위한 로드 밸런서가 필요합니다. | 시스템 관리자, 앱 개발자 | 
| 태스크 그룹을 지정합니다. | (선택 사항) 관련된 태스크 집합을 태스크 그룹으로 식별할 수 있도록 태스크 그룹 이름을 지정합니다. | 시스템 관리자, 앱 개발자 | 
| 클러스터 VPC, 서브넷 및 보안 그룹 구성합니다. | 애플리케이션을 배포하고자 하는 클러스터 VPC와 서브넷을 구성합니다. 인바운드 및 아웃바운드 연결에 대한 액세스를 제공할 수 있도록 보안 그룹(HTTP, HTTPS, 포트 8080)을 생성하거나 업데이트합니다. | 시스템 관리자, 앱 개발자 | 
| 퍼블릭 IP 설정을 구성합니다. | Fargate 태스크에 퍼블릭 IP 주소를 사용할지 여부에 따라 퍼블릭 IP를 활성화하거나 비활성화합니다. **활성화**가 기본값이며 권장 옵션입니다. | 시스템 관리자, 앱 개발자 | 
| 설정 검토 및 태스크 생성 | 설정을 검토한 다음, **태스크 실행**을 선택합니다. | 시스템 관리자, 앱 개발자 | 

### 전환
<a name="cut-over"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션 URL을 복사합니다. | 태스크 상태가 *실행 중*으로 업데이트되면 태스크을 선택합니다. 네트워킹 섹션에서 퍼블릭 IP를 복사합니다. | 시스템 관리자, 앱 개발자 | 
| 애플리케이션을 테스트합니다. | 브라우저에서 애플리케이션을 테스트할 수 있도록 퍼블릭 IP를 입력합니다. | 시스템 관리자, 앱 개발자 | 

## 관련 리소스
<a name="deploy-java-microservices-on-amazon-ecs-using-aws-fargate-resources"></a>
+ [Amazon ECS를 위한 Docker 기본 사항](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html)(Amazon ECS 설명서)
+ [Fargate의 Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)(Amazon ECS 설명서)
+ [태스크 정의 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)(Amazon ECS 설명서)
+ [클러스터 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)(Amazon ECS 설명서)
+ [기본 서비스 파라미터 구성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/basic-service-params.html)(Amazon ECS 설명서)
+ [네트워크 구성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-configure-network.html)(Amazon ECS 설명서)
+ [Amazon ECS에 Java 마이크로서비스 배포](https://aws.amazon.com/blogs/compute/deploying-java-microservices-on-amazon-ec2-container-service/)(블로그 게시물)

# Amazon EKS와 Amazon S3의 차트 Helm 리포지토리를 사용하여 Kubernetes 리소스 및 패키지 배포
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3"></a>

*Sagar Panigrahi, Amazon Web Services*

## 요약
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-summary"></a>

이 패턴은 복잡성과 관계없이 Kubernetes 애플리케이션을 효율적으로 관리하는 데 도움이 됩니다. 이 패턴은 Helm을 기존의 지속적 통합 및 지속적 전달(CI/CD) 파이프라인에 통합하여 Kubernetes 클러스터에 애플리케이션을 배포합니다. Helm은 Kubernetes 애플리케이션을 관리하는데 도움이 되는 Kubernetes 패키지 관리자입니다. 차트 Helm은 복잡한 Kubernetes 애플리케이션을 정의, 설치 및 업그레이드하는 데 도움이 됩니다. 차트를 버전화하여 Helm 리포지토리에 저장할 수 있어 정전 시 평균 복원 시간(MTTR)을 개선할 수 있습니다. 

이 패턴은 Kubernetes 클러스터에 대해 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용합니다. Amazon Simple Storage Service(S3)를 차트 Helm 리포지토리로 사용하므로, 조직 전체의 개발자가 차트를 중앙에서 관리하고 액세스할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-prereqs"></a>

**사전 조건 **
+ Virtual Private Cloud(VPC)가 있는 활성 Amazon Web Services(AWS) 계정
+ Amazon EKS 클러스터 
+ Amazon EKS 클러스터 내에 설정되고 워크로드를 처리할 준비가 된 작업자 노드
+ 클라이언트 머신의 대상 클러스터에 대해 Amazon EKS kubeconfig 파일을 구성하기 위한 Kubectl
+ S3 버킷을 생성하기 위한 AWS Identity and Access Management(IAM) 액세스
+ 클라이언트 머신에서 Amazon S3에 대한 IAM(프로그래밍 방식 또는 역할) 액세스
+ 소스 코드 관리 및 CI/CD 파이프라인

**제한 사항 **
+ 현재 사용자 지정 리소스 정의(CRD)의 업그레이드, 삭제 또는 관리는 지원되지 않습니다.
+ CRD를 참조하는 리소스를 사용하는 경우 CRD를 별도로(차트 외부에) 설치해야 합니다.

**제품 버전**
+ Helm v3.6.3

## 아키텍처
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-architecture"></a>

**대상 기술 스택**
+ Amazon EKS
+ Amazon VPC
+ Amazon S3
+ 소스 코드 관리
+ Helm
+ Kubectl

**대상 아키텍처 **

![\[Client Helm 및 Kubectl은 Amazon S3 for Amazon EKS 클러스터에 Helm 차트 리포지토리를 배포합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/d3f993e6-4d96-4cb9-a075-c4debe431fd7/images/2f09f7bb-440a-4c4b-b29f-08d136d1ada4.png)


 

**자동화 및 규모 조정**
+ AWS CloudFormation을 사용하면 클라우드 인프라 생성을 자동화할 수 있습니다. 자세한 내용은 Amazon EKS 설명서의 [AWS CloudFormation을 사용하여 Amazon EKS 리소스 생성](https://docs.aws.amazon.com/eks/latest/userguide/creating-resources-with-cloudformation.html)을 참조하세요.
+ Helm을 기존 CI/CD 자동화 도구에 통합하여 차트 Helm의 패키징 및 버전 관리를 자동화할 예정입니다(이 패턴의 범위를 벗어남).
+ GitVersion 또는 Jenkins 빌드 번호를 사용하여 차트 버전 관리를 자동화할 수 있습니다.

## 도구
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-tools"></a>

**도구**
+ [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) – Amazon Elastic Kubernetes Service(Amazon EKS)는 자체 Kubernetes 컨트롤 플레인을 구축하거나 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행하기 위한 관리형 서비스입니다. Kubernetes는 컨테이너화된 애플리케이션의 배포, 조정 및 관리 자동화를 위한 오픈 소스 시스템입니다.
+ [Helm](https://helm.sh/docs/) - Helm은 Kubernetes 클러스터에 애플리케이션을 설치하고 관리하는 데 도움이 되는 Kubernetes용 패키지 관리자입니다.
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html) – Amazon Simple Storage Service(S3)는 인터넷에 대한 스토리지입니다. Amazon S3를 사용하면 인터넷을 통해 언제 어디서든 원하는 양의 데이터를 저장하고 검색할 수 있습니다.
+ [Kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) - Kubectl은 Kubernetes 클러스터에 대해 명령을 실행하기 위한 명령줄 유틸리티입니다.

**코드**

예제 코드가 첨부되어 있습니다.

## 에픽
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-epics"></a>

### Helm 구성 및 초기화
<a name="configure-and-initialize-helm"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Helm 클라이언트를 설치합니다. | 로컬 시스템에 Helm 클라이언트를 다운로드하고 설치하려면 다음 명령을 사용하십시오. <pre>sudo curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash</pre> | DevOps 엔지니어 | 
| Helm 설치를 검사합니다. | Helm이 Amazon EKS 클러스터 내의 Kubernetes API 서버와 통신할 수 있는지 확인하려면 `helm version`을 실행하십시오. | DevOps 엔지니어 | 

### Amazon EKS 클러스터에 차트 Helm 생성 및 설치
<a name="create-and-install-a-helm-chart-in-the-amazon-eks-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| NGINX용 차트 Helm을 만드십시오. | 클라이언트 머신에 이름이 `my-nginx`로 지정된 차트 Helm을 만들려면 `helm create my-nginx`를 실행하십시오. | DevOps 엔지니어 | 
| 차트의 구조를 검토하십시오. | 차트의 구조를 검토하려면 `tree my-nginx/` 명령을 실행합니다. | DevOps 엔지니어 | 
| 차트에서 서비스 계정 생성을 비활성화합니다. | `values.yaml`의 `serviceAccount` 섹션 아래에서 `create` 키를 `false`로 설정합니다. 이 패턴에 대한 서비스 계정을 만들 필요가 없으므로 이 기능은 꺼져 있습니다. | DevOps 엔지니어 | 
| 수정된 차트에 구문 오류가 있는지 검증(린트)합니다. | 대상 클러스터에 차트를 설치하기 전에 차트에 구문 오류가 있는지 확인하려면 `helm lint my-nginx/`를 실행하십시오. | DevOps 엔지니어 | 
| 차트를 설치하여 Kubernetes 리소스를 배포합니다. | 다음 명령을 사용하여 차트 Helm 설치 관리자를 실행합니다. <pre>helm install --name my-nginx-release --debug my-nginx/ --namespace helm-space </pre>선택적 `debug` 플래그는 설치 중에 모든 디버그 메시지를 출력합니다. `namespace` 플래그는 이 차트의 리소스 부분이 생성될 네임스페이스를 지정합니다. | DevOps 엔지니어 | 
| Amazon EKS 클러스터에서 리소스를 검토하십시오. | `helm-space` 네임스페이스에서 차트 Helm의 일부로 생성된 리소스를 검토하려면 다음 명령을 사용하십시오. <pre>kubectl get all -n helm-space</pre> | DevOps 엔지니어 | 

### 이전 버전의 Kubernetes 애플리케이션으로 롤백
<a name="roll-back-to-a-previous-version-of-a-kubernetes-application"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 릴리스를 수정하고 업그레이드하십시오. | `values.yaml`의 차트를 수정하려면 `replicaCount` 값을 `2`로 변경합니다. 그런 다음 다음 명령을 실행하여 이미 설치된 릴리스를 업그레이드합니다.<pre>helm upgrade my-nginx-release my-nginx/ --namespace helm-space</pre> | DevOps 엔지니어 | 
| Helm 릴리스 기록을 검토하십시오. | Helm을 사용하여 설치한 특정 릴리스의 모든 수정 버전을 나열하려면 다음 명령을 실행하십시오. <pre>helm history my-nginx-release</pre> | DevOps 엔지니어 | 
| 특정 개정에 대한 세부 정보를 검토합니다. | 작동 버전으로 전환하거나 롤백하기 전에 그리고 수정 버전을 설치하기 전에 추가 검증 단계를 수행하려면 다음 명령을 사용하여 각 수정 버전에 전달된 값을 확인하십시오.<pre>helm get --revision=2 my-nginx-release</pre> | DevOps 엔지니어 | 
| 이전 버전으로 롤백합니다. | 이전 버전으로 롤백하려면 다음 명령을 사용합니다. <pre>helm rollback my-nginx-release 1 </pre>이 예제는 개정 번호 1로 롤백하는 것입니다. | DevOps 엔지니어 | 

### S3 버킷을 Helm 리포지토리로 초기화합니다.
<a name="initialize-an-s3-bucket-as-a-helm-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 차트 Helm을 위한 S3 버킷을 생성합니다. | 고유한 S3 버킷을 생성합니다. 버킷에서 이름이 `charts`인 폴더를 생성합니다. 이 패턴의 예시는 `s3://my-helm-charts/charts`를 대상 차트 리포지토리로 사용합니다. | 클라우드 관리자 | 
| Amazon S3용 Helm 플러그인을 설치합니다. | Helm-s3 플러그인을 클라이언트 머신에 설치하려면 다음 명령을 사용합니다. <pre>helm plugin install https://github.com/hypnoglow/helm-s3.git --version 0.10.0</pre>참고: Helm V3 지원은 플러그인 버전 0.9.0 이상에서 사용할 수 있습니다. | DevOps 엔지니어 | 
| Amazon S3 Helm 리포지토리를 초기화합니다. | 대상 폴더를 Helm 리포지토리로 초기화하려면 다음 명령을 사용합니다. <pre>helm S3 init s3://my-helm-charts/charts </pre>이 명령은 대상에 `index.yaml` 파일을 생성하여 해당 위치에 저장된 모든 차트 정보를 추적합니다. | DevOps 엔지니어 | 
| Amazon S3 리포지토리를 Helm에 추가합니다. | 클라이언트 머신에서 리포지토리를 추가하려면 다음 명령을 사용합니다.<pre>helm repo add my-helm-charts s3://my-helm-charts/charts </pre>이 명령은 Helm 클라이언트 컴퓨터의 대상 리포지토리에 별칭을 추가합니다. | DevOps 엔지니어 | 
| 리포지토리 목록을 검토하십시오. | Helm 클라이언트 컴퓨터의 리포지토리 목록을 보려면 `helm repo list`를 실행하십시오. | DevOps 엔지니어 | 

### Amazon S3 Helm 리포지토리에 차트를 패키징하고 저장합니다.
<a name="package-and-store-charts-in-the-amazon-s3-helm-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 차트를 패키징합니다. | 생성한 `my-nginx` 차트를 패키징하려면 `helm package ./my-nginx/`를 실행하십시오. 이 명령은 `my-nginx` 차트 폴더의 모든 내용을 아카이브 파일로 패키징하며, 아카이브 파일은 `Chart.yaml` 파일에 언급된 버전 번호를 사용하여 이름이 지정됩니다. | DevOps 엔지니어 | 
| Amazon S3 Helm 리포지토리에 패키지를 저장합니다. | Amazon S3의 Helm 리포지토리에 패키지를 업로드하려면 올바른 `.tgz` 파일 이름을 사용하여 다음 명령을 실행합니다.<pre>helm s3 push ./my-nginx-0.1.0.tgz my-helm-charts</pre> | DevOps 엔지니어 | 
| 차트 Helm을 검색하십시오. | 차트를 로컬에서 표시하고 Amazon S3의 Helm 리포지토리에서 모두 표시되는지 확인하려면 다음 명령을 실행합니다.<pre>helm search repo my-nginx</pre> | DevOps 엔지니어 | 

### 차트 수정, 버전 지정, 패키징
<a name="modify-version-and-package-a-chart"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 차트를 수정하고 패키징합니다. | `values.yaml`에서 `replicaCount`값을 `1`로 설정합니다. 그런 다음 `helm package ./my-nginx/`를 실행하여 차트를 패키징하며, 이번에는 `Chart.yaml`의 버전을 `0.1.1`로 변경합니다. 버전 관리는 CI/CD 파이프라인의 GitVersion 또는 Jenkins 빌드 번호와 같은 도구를 사용한 자동화를 통해 이상적으로 업데이트됩니다. 버전 번호 자동화는 이 패턴의 범위를 벗어납니다. | DevOps 엔지니어 | 
| Amazon S3의 Helm 리포지토리에 새 버전을 푸시합니다. | 0.1.1 버전의 새 패키지를 Amazon S3의 `my-helm-charts` Helm 리포지토리로 푸시하려면 다음 명령을 실행합니다.<pre>helm s3 push ./my-nginx-0.1.1.tgz my-helm-charts</pre> | DevOps 엔지니어 | 

### Amazon S3 Helm 리포지토리에서 차트 검색 및 설치
<a name="search-for-and-install-a-chart-from-the-amazon-s3-helm-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| my-nginx 차트의 모든 버전을 검색하십시오. | 사용 가능한 차트 버전을 모두 보려면 `--versions` 플래그를 사용하여 다음 명령을 실행합니다.<pre>helm search repo my-nginx --versions</pre>플래그가 없는 경우 Helm은 기본적으로 가장 최근에 업로드된 차트 버전을 표시합니다. | DevOps 엔지니어 | 
| Amazon S3 Helm 리포지토리에서 차트를 설치하십시오. | 이전 작업의 검색 결과에는 `my-nginx` 차트의 여러 버전이 표시됩니다. Amazon S3 Helm 리포지토리에서 새 버전(0.1.1)을 설치하려면 다음 명령을 사용합니다.<pre>helm upgrade my-nginx-release my-helm-charts/my-nginx --version 0.1.1 --namespace helm-space</pre> | DevOps 엔지니어 | 

## 관련 리소스
<a name="deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3-resources"></a>
+ [HELM 설명서](https://helm.sh/docs/)
+ [helm-s3 플러그인(MIT 라이선스)](https://github.com/hypnoglow/helm-s3.git)
+ [Helm 클라이언트 바이너리](https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3)
+ [Amazon EKS 설명서](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)

## 첨부
<a name="attachments-d3f993e6-4d96-4cb9-a075-c4debe431fd7"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/d3f993e6-4d96-4cb9-a075-c4debe431fd7/attachments/attachment.zip) 파일의 압축을 풉니다.

# Terraform을 사용하여 Amazon EKS에 CockroachDB 클러스터 배포
<a name="deploy-cockroachdb-on-eks-using-terraform"></a>

*Sandip Gangapadhyay 및 Kalyan Senthilnathan, Amazon Web Services*

## 요약
<a name="deploy-cockroachdb-on-eks-using-terraform-summary"></a>

이 패턴은 [CockroachDB](https://www.cockroachlabs.com/docs/stable/) [연산자를 사용하여 Amazon Elastic Kubernetes Service(Amazon EKS)에 다중 노드 CockroachDB ](https://www.cockroachlabs.com/docs/v25.4/cockroachdb-operator-overview)클러스터를 배포하기 위한 HashiCorp Terraform 모듈을 제공합니다. CockroachDB는 지리적으로 분산된 클러스터에서 자동 수평 샤딩, 고가용성 및 일관된 성능을 제공하는 분산 SQL 데이터베이스입니다. 이 패턴은 Amazon EKS를 관리형 Kubernetes 플랫폼으로 사용하고 TLS 보안 노드 통신을 위한 [cert-manager](https://cert-manager.io/docs/)를 구현합니다. 또한 트래픽 분산에 [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)를 사용하고 내결함성 및 성능을 위해 데이터를 자동으로 복제하는 포드가 있는 CockroachDB [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)를 생성합니다.

**수강 대상**

이 패턴을 구현하려면 다음 사항을 숙지하는 것이 좋습니다.
+ HashiCorp Terraform 개념 및 코드형 인프라(IaC) 관행
+ AWS 서비스, 특히 Amazon EKS
+ StatefulSets, 연산자 및 서비스 구성을 포함한 Kubernetes 기본 사항
+ 분산 SQL 데이터베이스
+ TLS 인증서 관리와 같은 보안 개념.
+ DevOps 사례, CI/CD 워크플로 및 인프라 자동화

## 사전 조건 및 제한 사항
<a name="deploy-cockroachdb-on-eks-using-terraform-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ Amazon EKS 클러스터에 리소스를 배포할 수 있는 권한
+ 노드 레이블이 지정된 Amazon EKS 클러스터 버전 v1.23 이상 `node=cockroachdb`
+ [Amazon EKS 클러스터에 설치된 Amazon Elastic Block Store 컨테이너 스토리지 인터페이스(CSI) 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 버전 1.19.0 이상
+ Terraform CLI 버전 1.0.0 이상, [설치](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)됨
+ kubectl, [설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)됨
+ Git, [설치됨](https://git-scm.com/install/)
+ AWS Command Line Interface (AWS CLI) 버전 2.9.18 이상, [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)됨

**제한 사항 **
+ CockroachDB Kubernetes 운영자는 다중 리전 배포를 위해 여러 Kubernetes 클러스터를 지원하지 않습니다. 자세한 제한 사항은 [여러 Kubernetes 클러스터에서 CockroachDB 오케스트레이션](https://www.cockroachlabs.com/docs/stable/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html#eks)(CockroachDB 설명서) 및 [CockroachDB Kubernetes 연산자](https://github.com/cockroachdb/cockroach-operator)(GitHub)를 참조하세요.
+ 영구 볼륨 클레임(PVCs)의 자동 정리는 현재 기본적으로 비활성화되어 있습니다. 즉, 노드를 폐기하고 제거한 후 운영자는 포드에 마운트된 영구 볼륨을 제거하지 않습니다. 자세한 내용은 CockroachDB 설명서의 [자동 PVC 정리](https://www.cockroachlabs.com/docs/stable/scale-cockroachdb-kubernetes.html#automatic-pvc-pruning)를 참조하세요.

**제품 버전**
+ CockroachDB 버전 22.2.2

## 아키텍처
<a name="deploy-cockroachdb-on-eks-using-terraform-architecture"></a>

**대상 아키텍처**

다음 다이어그램은 Virtual Private Cloud(VPC) 내의 세 AWS 가용 영역에 대한 가용성이 높은 CockroachDB 배포를 보여줍니다. CockroachDB 포드는 Amazon EKS를 통해 관리됩니다. 아키텍처는 사용자가 CockroachDB 포드에 트래픽을 분산하는 Network Load Balancer를 통해 데이터베이스에 액세스하는 방법을 보여줍니다. 포드는 복원력과 내결함성을 제공하는 각 가용 영역의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행됩니다.

![\[VPC 내 세 AWS 가용 영역에 고가용성 CockroachDB 배포.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e22d81ab-b85c-4709-8579-4c9cdb4afdb6/images/4b163abf-6fdc-4310-840c-bda621ab25dd.png)


**생성된 리소스**

이 패턴에 사용되는 Terraform 모듈을 배포하면 다음과 같은 리소스가 생성됩니다.

1. **Network Load Balancer** -이 리소스는 클라이언트 요청의 진입점 역할을 하며 CockroachDB 인스턴스 간에 트래픽을 균등하게 분산합니다.

1. **CockroachDB StatefulSet** - StatefulSet는 Amazon EKS 클러스터 내에서 CockroachDB 배포의 원하는 상태를 정의합니다. CockroachDB 포드의 정렬된 배포, 조정 및 업데이트를 관리합니다.

1. **CockroachDB 포드 **- 이러한 포드는 Kubernetes 포드 내에서 컨테이너로 실행되는 CockroachDB의 인스턴스입니다. 이러한 포드는 분산 클러스터 전체에서 데이터를 저장하고 관리합니다.

1. **CockroachDB 데이터베이스** - 여러 포드에 걸쳐 CockroachDB에서 관리하는 분산 데이터베이스입니다. 고가용성, 내결함성 및 성능을 위해 데이터를 복제합니다.

## 도구
<a name="deploy-cockroachdb-on-eks-using-terraform-tools"></a>

**AWS 서비스**
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.

**기타 도구**
+ [HashiCorp Terraform](https://www.terraform.io/docs)은 코드를 사용하여 클라우드 인프라 및 리소스를 프로비저닝하고 관리하는 데 도움이 되는 코드형 인프라(IaC) 도구입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/)는 Kubernetes 클러스터에 대해 명령의 실행을 돕는 명령줄 인터페이스입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub Terraform [리포지토리를 사용하여 Amazon EKS에 CockroachDB 클러스터 배포에서](https://github.com/aws-samples/crdb-cluster-eks-terraform) 사용할 수 있습니다. 코드 리포지토리에는 Terraform에 대한 다음 파일과 폴더가 포함되어 있습니다.
+ `modules` 폴더 -이 폴더에는 CockroachDB용 Terraform 모듈이 포함되어 있습니다.
+ `main` 폴더 -이 폴더에는 CockroachDB 하위 모듈을 호출하여 CockroachDB 데이터베이스 클러스터를 생성하는 루트 모듈이 포함되어 있습니다.

## 모범 사례
<a name="deploy-cockroachdb-on-eks-using-terraform-best-practices"></a>
+ 노드를 3개 미만으로 축소하지 마십시오. 이는 CockroachDB에서 안티 패턴으로 간주되며 오류를 일으킬 수 있습니다. 자세한 내용은 CockroachDB 설명서의 [Cluster Scaling](https://www.cockroachlabs.com/docs/stable/scale-cockroachdb-kubernetes.html)을 참조하세요.
+ Karpernter 또는 Cluster Autoscaler를 사용하여 Amazon EKS Autoscaling을 구현합니다. 이렇게 하면 CockroachDB 클러스터가 수평적으로 확장되고 새 노드가 자동으로 확장됩니다. 자세한 내용은 Amazon EKS 설명서에서 [Karpenter 및 Cluster Autoscaler를 사용하여 클러스터 컴퓨팅 자동 규모 조정](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html)을 참조하세요.
**참고**  
`podAntiAffinity` Kubernetes 예약 규칙으로 인해 하나의 Amazon EKS 노드에서 하나의 CockroachDB 포드만 예약할 수 있습니다.
+ Amazon EKS 보안 모범 사례는 Amazon EKS 설명서의 [보안 모범 사례를](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) 참조하세요.
+ CockroachDB에 대한 SQL 성능 모범 사례는 CockroachDB 설명서의 [SQL 성능 모범 사례를](https://www.cockroachlabs.com/docs/stable/performance-best-practices-overview.html) 참조하세요.
+ Terraform 상태 파일을 위한 Amazon Simple Storage Service(Amazon S3) 원격 백엔드 설정에 대한 자세한 내용은 Terraform 설명서의 [Amazon S3](https://developer.hashicorp.com/terraform/language/backend/s3)를 참조하세요.

## 에픽
<a name="deploy-cockroachdb-on-eks-using-terraform-epics"></a>

### 환경을 설정합니다
<a name="set-up-your-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 코드 리포지토리를 복제합니다. | 다음 명령을 입력하여 리포지토리를 복제합니다.<pre>git clone https://github.com/aws-samples/crdb-cluster-eks-terraform.git</pre> | DevOps 엔지니어, Git | 
| Terraform 변수를 업데이트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps 엔지니어, Terraform | 

### 리소스 배포
<a name="deploy-the-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인프라를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps 엔지니어, Terraform | 

### 배포 확인
<a name="verify-the-deployment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리소스 생성을 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps 엔지니어 | 
| (선택 사항) 스케일 업 또는 스케일 다운. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | DevOps 엔지니어, Terraform | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인프라를 삭제합니다. | 노드를 로 확장`0`하면 컴퓨팅 비용이 절감됩니다. 그러나이 모듈에서 생성된 영구 Amazon EBS 볼륨에 대해서는 여전히 요금이 부과됩니다. 스토리지 비용을 제거하려면 다음 단계에 따라 모든 볼륨을 삭제합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | Terraform | 

## 문제 해결
<a name="deploy-cockroachdb-on-eks-using-terraform-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 공급자 보안 인증을 검증하는 중 오류가 발생했습니다. | Terraform `apply` 또는 `destroy` 명령을 실행하면 다음 오류가 발생할 수 있습니다.`Error: configuring Terraform AWS Provider: error validating provider  credentials: error calling sts:GetCallerIdentity: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: The security token included in the request is invalid.`이 오류는 로컬 시스템 구성에 사용된 보안 인증 정보의 보안 토큰이 만료되어 발생합니다. 오류를 해결하는 방법에 대한 지침은 AWS CLI 설명서의 [구성 설정 및 보기를](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods) 참조하세요. | 
| 보류 중인 상태의 CockroachDB 포드 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-cockroachdb-on-eks-using-terraform.html) | 

## 관련 리소스
<a name="deploy-cockroachdb-on-eks-using-terraform-resources"></a>
+ [단일 Kubernetes 클러스터에 CockroachDB 배포](https://www.cockroachlabs.com/docs/dev/deploy-cockroachdb-with-kubernetes.html)(CockroachDB 설명서)
+ [여러 Kubernetes 클러스터에서 CockroachDB 오케스트레이션](https://www.cockroachlabs.com/docs/dev/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html)(CockroachDB 설명서)
+ [AWS 공급자](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)(Terraform 설명서)

## 첨부
<a name="attachments-e22d81ab-b85c-4709-8579-4c9cdb4afdb6"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/e22d81ab-b85c-4709-8579-4c9cdb4afdb6/attachments/attachment.zip) 파일의 압축을 풉니다.

# Amazon EKS에 샘플 Java 마이크로서비스를 배포하고 Application Load Balancer를 사용하여 마이크로서비스 노출하기
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer"></a>

*Vijay Thompson과 Akkamahadevi hiremath, Amazon Web Services*

## 요약
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-summary"></a>

이 패턴은 `eksctl` 명령줄 유틸리티와 Amazon Elastic Container Registry(Amazon ECR)를 사용하여 샘플 Java 마이크로서비스를 Amazon Elastic Kubernetes Service(Amazon EKS)에 컨테이너화된 애플리케이션으로 배포하는 방법을 설명합니다. Application Load Balancer을 사용하여 애플리케이션 트래픽을 로드 밸런싱할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ macOS, Linux 또는 Windows에 설치 및 구성된 AWS Command Line Interface(AWS CLI) 버전 1.7 이상
+ 실행 중인 [Docker 대몬(daemon)](https://docs.docker.com/config/daemon/)
+ MacOS, Linux 또는 Windows에 설치 및 구성된 `eksctl` 명령줄 유틸리티(자세한 내용은 Amazon EKS 설명서의 [Amazon EKS - eksctl 시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) 참조)
+ MacOS, Linux 또는 Windows에 설치 및 구성된 `kubectl` 명령줄 유틸리티(자세한 내용은 Amazon EKS 설명서의 [kubectl 설치 또는 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) 참조)

**제한 사항 **
+ 이 패턴은 Application Load Balancer의 SSL 인증서 설치에는 적용되지 않습니다.

## 아키텍처
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-architecture"></a>

**대상 기술 스택**
+ Amazon ECR
+ Amazon EKS
+ Elastic Load Balancing

**대상 아키텍처**

다음 다이어그램은 Amazon EKS에서 Java 마이크로서비스를 컨테이너화하기 위한 아키텍처를 보여줍니다.

![\[Amazon EKS에서 컨테이너화된 애플리케이션으로 배포된 Java 마이크로서비스.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e1dd8ab0-9e1e-4d2b-b7af-89d3e583e57c/images/aaca4fd9-5aaa-4df5-aebd-02a2ed881c3b.png)


## 도구
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-tools"></a>
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장 가능하고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)는 자체 Kubernetes 컨트롤 플레인이나 노드를 설치하거나 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행할 수 있도록 도와줍니다.
+ [AWS Command Line Interface(AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 쉘에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다.
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 하나 이상의 가용 영역에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산합니다.
+ [eksctl](https://eksctl.io/)은 Amazon EKS에서 클러스터를 생성하는 데 도움이 됩니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)를 사용하면 쿠버네티스 클러스터에 대해 명령을 실행할 수 있습니다.
+ [Docker](https://www.docker.com/)는 컨테이너라는 패키지로 애플리케이션을 빌드, 테스트 및 제공할 수 있도록 도와줍니다.

## 에픽
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-epics"></a>

### eksctl을 사용하여 Amazon EKS 클러스터 생성
<a name="create-an-amazon-eks-cluster-by-using-eksctl"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EKS 클러스터를 생성합니다. | 두 개의 t2.small Amazon EC2 인스턴스를 노드로 사용하는 Amazon EKS 클러스터를 생성하려면 다음 명령을 실행합니다.<pre>eksctl create cluster --name <your-cluster-name> --version <version-number> --nodes=1 --node-type=t2.small</pre>이 프로세스는 15분에서 20분 정도 걸릴 수 있습니다. 클러스터가 생성되고 나면 적절한 Kubernetes 구성이 [kubeconfig 파일](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html)에 추가됩니다. 이후 단계에서 `kubectl`** **와(과) 함께 `kubeconfig` 파일을 사용하여 애플리케이션을 배포할 수 있습니다. | 개발자, 시스템 관리자 | 
| Amazon EKS 클러스터를 확인합니다. | 클러스터가 생성되었고 클러스터에 연결할 수 있는지 확인하려면 `kubectl get nodes` 명령을 실행합니다. | 개발자, 시스템 관리자 | 

### Amazon ECR 리포지토리를 생성하고 도커 이미지를 푸시합니다.
<a name="create-an-amazon-ecr-repository-and-push-the-docker-image"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECR 리포지토리를 생성합니다. | Amazon ECR 설명서의 [프라이빗 리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)의 지침을 따르세요. | 개발자, 시스템 관리자 | 
| POM XML 파일을 생성합니다. | 이 패턴의 [추가 정보](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional) 섹션에 있는 *예제 POM 파일* 코드를 기반으로 파일 `pom.xml`을(를) 생성합니다. | 개발자, 시스템 관리자 | 
| 소스 파일을 생성합니다. | 다음 예제를 기반으로 `src/main/java/eksExample` 경로에서 `HelloWorld.java`라는 소스 파일을 생성합니다.<pre>package eksExample;<br />import static spark.Spark.get;<br /><br />public class HelloWorld {<br />    public static void main(String[] args) {<br />        get("/", (req, res) -> {<br />            return "Hello World!";<br />        });<br />    }<br />}</pre>다음과 같은 디렉터리 구조를 사용하도록 합니다.<pre>├── Dockerfile<br />├── deployment.yaml<br />├── ingress.yaml<br />├── pom.xml<br />├── service.yaml<br />└── src<br />    └── main<br />        └── java<br />            └── eksExample<br />                └── HelloWorld.java</pre> |  | 
| Dockerfile을 생성합니다. | 이 패턴의 [추가 정보](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional) 섹션에 있는 *예제 Dockerfile* 코드를 기반으로 `Dockerfile`을(를) 생성합니다. | 개발자, 시스템 관리자 | 
| 도커 이미지를 빌드하고 푸시합니다. | `Dockerfile`이(가) 이미지를 빌드하고 태그를 지정하고 Amazon ECR로 푸시하도록 하려는 디렉터리에서 다음 명령을 실행합니다.<pre>aws ecr get-login-password --region <region>| docker login --username <username> --password-stdin <account_number>.dkr.ecr.<region>.amazonaws.com<br />docker buildx build --platform linux/amd64 -t hello-world-java:v1 .<br />docker tag hello-world-java:v1 <account_number>.dkr.ecr.<region>.amazonaws.com/<repository_name>:v1<br />docker push <account_number>.dkr.ecr.<region>.amazonaws.com/<repository_name>:v1</pre>이전 명령에서 AWS 리전, 계정 번호, 리포지토리 세부 정보를 수정합니다. 나중에 사용할 수 있도록 이미지 URL을 기록하세요.M1 칩이 장착된 macOS 시스템에서는 AMD64 플랫폼에서 실행되는 Amazon EKS와 호환되는 이미지를 구축하는 데 문제가 있습니다. 이 문제를 해결하려면 [docker buildx](https://docs.docker.com/engine/reference/commandline/buildx/)를 사용하여 Amazon EKS에서 작동하는 도커 이미지 빌드하세요. |  | 

### Java 마이크로서비스 배포
<a name="deploy-the-java-microservices"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 배포 파일을 생성합니다. | 이 패턴의 [추가 정보](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional) 섹션에 있는 *예제 배포 파일* 코드를 기반으로 `deployment.yaml`라는 YAML 파일을 생성합니다.이전에 복사한 이미지 URL을 Amazon ECR 리포지토리의 이미지 파일의 경로로 사용합니다. | 개발자, 시스템 관리자 | 
| Amazon EKS 클러스터에 Java 마이크로서비스를 배포합니다. | Amazon EKS 클러스터에 배포를 생성하려면 `kubectl apply -f deployment.yaml` 명령을 실행합니다. | 개발자, 시스템 관리자 | 
| 포드의 상태를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 개발자, 시스템 관리자 | 
| 서비스를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 개발자, 시스템 관리자 | 
| AWS Load Balancer Controller 추가 기능을 설치합니다. | Amazon EKS 설명서의 [AWS Load Balancer Controller 추가 기능 설치](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) 지침을 따르세요.Kubernetes 서비스를 위한 Application Load Balancer 또는 Network Load Balancer를 생성하려면 추가 기능을 설치해야 합니다. | 개발자, 시스템 관리자 | 
| 인그레스 리소스를 생성합니다. | 이 패턴의 [추가 정보](#deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional) 섹션에 있는 *예제 인그레스 리소스 파일* 코드를 기반으로 `ingress.yaml`라는 YAML 파일을 생성합니다. | 개발자, 시스템 관리자 | 
| Application Load Balancer을 생성합니다. | 인그레스 리소스를 배포하고 Application Load Balancer를 생성하려면 `kubectl apply -f ingress.yaml` 명령을 실행합니다. | 개발자, 시스템 관리자 | 

### 애플리케이션 테스트
<a name="test-the-application"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션을 테스트하고 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer.html) | 개발자, 시스템 관리자 | 

## 관련 리소스
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-resources"></a>
+ [프라이빗 리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html) (Amazon ECR 설명서)
+ [도커 이미지 푸시](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)(Amazon ECR 설명서)
+ [인그레스 컨트롤러](https://www.eksworkshop.com/beginner/130_exposing-service/ingress_controller_alb/) (Amazon EKS Workshop)
+ [Docker buildx](https://docs.docker.com/engine/reference/commandline/buildx/) (Docker Docs)

## 추가 정보
<a name="deploy-a-sample-java-microservice-on-amazon-eks-and-expose-the-microservice-using-an-application-load-balancer-additional"></a>

**예제 POM 파일**

```
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>


  <groupId>helloWorld</groupId>
  <artifactId>helloWorld</artifactId>
  <version>1.0-SNAPSHOT</version>


  <dependencies>
    <dependency>
      <groupId>com.sparkjava</groupId><artifactId>spark-core</artifactId><version>2.0.0</version>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId><artifactId>maven-jar-plugin</artifactId><version>2.4</version>
        <configuration><finalName>eksExample</finalName><archive><manifest>
              <addClasspath>true</addClasspath><mainClass>eksExample.HelloWorld</mainClass><classpathPrefix>dependency-jars/</classpathPrefix>
            </manifest></archive>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>3.1</version>
        <configuration><source>1.8</source><target>1.8</target></configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId><artifactId>maven-assembly-plugin</artifactId>
        <executions>
          <execution>
            <goals><goal>attached</goal></goals><phase>package</phase>
            <configuration>
              <finalName>eksExample</finalName>
              <descriptorRefs><descriptorRef>jar-with-dependencies</descriptorRef></descriptorRefs>
              <archive><manifest><mainClass>eksExample.HelloWorld</mainClass></manifest></archive>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>
```

**예제 Dockerfile**

```
FROM bellsoft/liberica-openjdk-alpine-musl:17

RUN apk add maven
WORKDIR /code

# Prepare by downloading dependencies
ADD pom.xml /code/pom.xml
RUN ["mvn", "dependency:resolve"]
RUN ["mvn", "verify"]

# Adding source, compile and package into a fat jar
ADD src /code/src
RUN ["mvn", "package"]

EXPOSE 4567
CMD ["java", "-jar", "target/eksExample-jar-with-dependencies.jar"]
```

**예제 배포 파일**

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: java-microservice
  template:
    metadata:
      labels:
        app.kubernetes.io/name: java-microservice
    spec:
      containers:
      - name: java-microservice-container
        image: .dkr.ecr.amazonaws.com/:
        ports:
        - containerPort: 4567
```

**예제 서비스 파일**

```
apiVersion: v1
kind: Service
metadata:
  name: "service-java-microservice"
spec:
  ports:
    - port: 80
      targetPort: 4567
      protocol: TCP
  type: NodePort
  selector:
    app.kubernetes.io/name: java-microservice
```

**예제 인그레스 리소스 파일**

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "java-microservice-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/load-balancer-name: apg2
    alb.ingress.kubernetes.io/target-type: ip
  labels:
    app: java-microservice
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: "service-java-microservice"
                port:
                  number: 80
```

# Amazon EKS 클러스터에 gRPC 기반 애플리케이션을 배포하고 Application Load Balancer를 사용하여 액세스하기
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer"></a>

*Kirankumar Chandrashekar 및 Huy Nguyen, Amazon Web Services*

## 요약
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-summary"></a>

이 패턴은 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에서 gRPC 기반 애플리케이션을 호스팅하고 Application Load Balancer를 통해 안전하게 액세스하는 방법을 설명합니다.

[gRPC는](https://grpc.io/) 모든 환경에서 실행할 수 있는 오픈 소스 원격 프로시져 호출(RPC) 프레임워크입니다. 마이크로서비스 통합 및 클라이언트 서버 통신에 사용할 수 있습니다. gRPC에 대한 자세한 내용은 Amazon Web Services(AWS) 블로그의 [엔드 투 엔드 HTTP/2 및 gRPC에 대한 Application Load Balancer 지원](https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/) AWS Blog 게시물을 참조하세요.

이 패턴은 Amazon EKS에서 Kubernetes 포드로 실행되는 gRPC 기반 애플리케이션을 호스팅하는 방법을 보여줍니다. gRPC 클라이언트는 SSL/TLS(Secure Sockets Layer/Transport Layer Security)로 암호화된 연결을 사용하는 HTTP/2 프로토콜을 통해 Application Load Balancer에 연결합니다. Application Load Balancer는 Amazon EKS 포드에서 실행되는 gRPC 애플리케이션으로 트래픽을 전달합니다. [Kubernetes Horizontal Pod Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)를 사용하여 gRPC 포드의 수를 트래픽에 따라 자동으로 조정할 수 있습니다. Application Load Balancer의 대상 그룹은 Amazon EKS 노드에서 상태 확인을 수행하고 대상이 정상인지 평가한 후 정상 노드에만 트래픽을 전달합니다.

## 사전 조건 및 제한 사항
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정.
+ [Docker](https://www.docker.com/), Linux, macOS 또는 Windows에 설치 및 구성되었습니다.
+ [AWS Command Line Interface(AWS CLI) 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html), Linux, macOS 또는 Windows에 설치 및 구성됨.
+ [Docker](https://github.com/eksctl-io/eksctl#installation), Linux, macOS 또는 Windows에 설치 및 구성되었습니다.
+ `kubectl`, Amazon EKS 클러스터의 리소스에 액세스하도록 설치 및 구성됨. 자세한 내용은 Amazon EKS 설명서의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)를 참조하세요. 
+ [gRPCURL](https://github.com/fullstorydev/grpcurl), 설치 및 구성됨
+ 기존 이상 Amazon EKS 클러스터. 자세한 내용은 [Amazon S3 시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) 섹션을 참조하세요.
+ Amazon EKS 클러스터에 액세스하도록 구성된 컴퓨터 터미널입니다. 자세한 내용은 Amazon EKS 설명서의 [클러스터와 통신하도록 컴퓨터 구성을 참조하세요](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl).
+ [AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html), Amazon EKS 클러스터에서 프로비저닝됨.
+ 유효한 SSL 또는 SSL/TLS 인증서를 사용하는 기존 도메인 이름 시스템(DNS) 호스트 이름입니다. AWS Certificate Manager(ACM)를 사용하거나 기존 인증서를 ACM에 업로드하여 도메인에 대한 인증서를 받을 수 있습니다. 이 두 가지 옵션에 대한 자세한 내용은 ACM 설명서의 [공인 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) 및 [AWS Certificate Manager로 인증서 가져오기](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)를 참조하세요.

## 아키텍처
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-architecture"></a>

다음 다이어그램은 이 패턴이 구축하는 아키텍처를 보여줍니다.

![\[Amazon EKS의 gRPC 기반 애플리케이션을 위한 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/abf727c1-ff8b-43a7-923f-bce825d1b459/images/281936fa-bc43-4b4e-a343-ba1eab97df38.png)


 

다음 다이어그램은 Application Load Balancer로 오프로드되는 gRPC 클라이언트에서 SSL/TLS 트래픽을 수신하는 워크플로우를 보여줍니다. 트래픽은 Virtual Private Cloud(VPC)에서 오기 때문에 gRPC 서버에 일반 텍스트로 전달됩니다.

![\[SSL/TLS 트래픽을 gRPC 서버로 전송하는 워크플로\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/abf727c1-ff8b-43a7-923f-bce825d1b459/images/09e0c3f6-0c39-40b7-908f-8c4c693a5f02.png)


## 도구
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-tools"></a>

**서비스**
+ [Command Line Interface(CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 쉘에서 명령을 사용하여 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 예를 들어 하나 이상의 가용 영역에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 전반에 걸쳐 트래픽을 분산할 수 있습니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장 가능하고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다. 
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)는 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 없이 Kubernetes를 실행하는 데 도움이 됩니다. 

**도구**
+ [eksctl](https://eksctl.io/)은 Amazon EKS에 클러스터를 생성하기 위한 간단한 CLI 도구입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)은 Kubernetes 클러스터에 대해 명령을 실행하기 위한 명령줄 유틸리티입니다.
+ [AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)는 Kubernetes 클러스터의 AWS Elastic Load Balancer를 관리하는 데 유용합니다.
+ [gRPCurl](https://github.com/fullstorydev/grpcurl)은 gRPC 서비스와 상호 작용하는 데 도움이 되는 명령줄 도구입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub.com의 [grpc-traffic-on-alb-to-eks](https://github.com/aws-samples/grpc-traffic-on-alb-to-eks.git) 리포지토리에서 확인할 수 있습니다.

## 에픽
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-epics"></a>

### gRPC 서버의 도커 이미지를 빌드하여 Amazon ECR로 푸시합니다.
<a name="build-and-push-the-grpc-serverrsquor-s-docker-image-to-amazon-ecr"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECR 리포지토리를 생성합니다. | AWS Management Console에 로그인한 다음 [Amazon ECR 콘솔](https://console.aws.amazon.com/ecr/)을 열고 Amazon ECR 리포지토리를 생성합니다. 자세한 내용은 Amazon ECR 설명서의 [리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)을 참조하세요. Amazon ECR 리포지토리의 URL을 기록하세요.다음 명령을 실행하여 AWS CLI를 사용하여 Amazon ECR 리포지토리를 생성할 수도 있습니다.<pre>aws ecr create-repository --repository-name helloworld-grpc</pre> | 클라우드 관리자 | 
| Docker 이미지를 구축합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps 엔지니어 | 
| 도커 이미지를 Amazon ECR로 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps 엔지니어 | 

### Kubernetes 매니페스트를 Amazon EKS 클러스터에 배포합니다.
<a name="deploy-the-kubernetes-manifests-to-the-amazon-eks-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Kubernetes 매니페스트 파일의 값을 수정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps 엔지니어 | 
| Kubernetes 매니페스트 파일을 배포합니다. | 다음 `kubectl` 명령을 실행하여 `grpc-sample.yaml` 파일을 Amazon EKS 클러스터에 배포합니다. <pre>kubectl apply -f ./kubernetes/grpc-sample.yaml</pre> | DevOps 엔지니어 | 

### Application Load Balancer의 FQDN에 대한 DNS 레코드 생성
<a name="create-the-dns-record-for-the-application-load-balancerapos-s-fqdn"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Application Load Balancer에 대한 FQDN을 기록합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.html) | DevOps 엔지니어 | 

### 솔루션 테스트
<a name="test-the-solution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| gRPC 서버를 테스트합니다. | 다음 명령을 실행하여 gRPCurl을 사용하여 엔드포인트를 테스트합니다.<pre>grpcurl grpc.example.com:443 list <br />grpc.reflection.v1alpha.ServerReflection<br />helloworld.helloworld</pre>`grpc.example.com`을 사용자 이름으로 바꿉니다. | DevOps 엔지니어 | 
| gRPC 클라이언트를 사용하여 gRPC 서버를 테스트합니다. | `helloworld_client_ssl.py`샘플 gRPC 클라이언트에서 의 호스트 이름을 gRPC 서버에 사용되는 호스트 이름으로 바꿉니다. 다음 코드 샘플은 클라이언트 요청에 대한 gRPC 서버의 응답을 보여줍니다.<pre>python ./app/helloworld_client_ssl.py<br />message: "Hello to gRPC server from Client"<br /><br />message: "Thanks for talking to gRPC server!! Welcome to hello world. Received message is \"Hello to gRPC server from Client\""<br />received: true</pre>이는 클라이언트가 서버와 통신할 수 있고 연결에 성공했음을 보여줍니다. | DevOps 엔지니어 | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DNS 레코드를 제거합니다. | 이전에 생성한 Application Load Balancer의 FQDN을 가리키는 DNS 레코드를 제거합니다. | 클라우드 관리자 | 
| 로드 밸런서를 제거합니다. | [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/)에서 **로드 밸런서를** 선택한 다음 Kubernetes 컨트롤러가 수신 리소스에 대해 생성한 로드 밸런서를 제거합니다. | 클라우드 관리자 | 
| Amazon EKS 클러스터를 생성합니다. | 를 사용하여 Amazon EKS 클러스터를 삭제합니다`eksctl`.<pre>eksctl delete cluster -f ./eks.yaml</pre> | DevOps | 

## 관련 리소스
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-resources"></a>
+ [Amazon EKS의 네트워크 로드 밸런싱](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html)
+ [Application Load Balancer 대상 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-group-protocol-version)

## 추가 정보
<a name="deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer-additional"></a>

**샘플 인그레스 리소스:**

```
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/backend-protocol-version: "GRPC"
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:<AWS-Region>:<AccountId>:certificate/<certificate_ID>
  labels:
    app: grpcserver
    environment: dev
  name: grpcserver
  namespace: grpcserver
spec:
  ingressClassName: alb
  rules:
  - host: grpc.example.com # <----- replace this as per your host name for which the SSL certtficate is available in ACM
    http:
      paths:
      - backend:
          service:
            name: grpcserver
            port:
              number: 9000
        path: /
        pathType: Prefix
```

**샘플 배포 리소스:**

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grpcserver
  namespace: grpcserver
spec:
  selector:
    matchLabels:
      app: grpcserver
  replicas: 1
  template:
    metadata:
      labels:
        app: grpcserver
    spec:
      containers:
      - name: grpc-demo
        image: <your_aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/helloworld-grpc:1.0   #<------- Change to the URI that the Docker image is pushed to
        imagePullPolicy: Always
        ports:
        - name: grpc-api
          containerPort: 9000
        env:
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
      restartPolicy: Always
```

**샘플 출력:**

```
NAME             CLASS           HOSTS                          Address                PORTS          AGE
 grpcserver      <none>      <DNS-HostName>                  <ELB-address>              80            27d
```

# Docker 컨테이너로 AWS IoT Greengrass V2 실행 중인에 컨테이너화된 애플리케이션 배포
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container"></a>

*Salih Bakir, Giuseppe Di Bella, Gustav Svalander, Amazon Web Services*

## 요약
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-summary"></a>

AWS IoT Greengrass Version 2는 Docker 컨테이너로 배포될 때 기본적으로 Docker 애플리케이션 컨테이너 실행을 지원하지 않습니다. 이 패턴은 DinD(DockerDocker-in-Docker) 기능을 활성화 AWS IoT Greengrass V2 하는 최신 버전의를 기반으로 사용자 지정 컨테이너 이미지를 생성하는 방법을 보여줍니다. DinD를 사용하면 AWS IoT Greengrass V2 환경 내에서 컨테이너화된 애플리케이션을 실행할 수 있습니다.

이 패턴을 독립형 솔루션으로 배포하거나 Amazon ECS Anywhere와 같은 컨테이너 오케스트레이션 플랫폼과 통합할 수 있습니다. 두 배포 모델에서는 확장 가능한 컨테이너 기반 배포를 활성화하면서 AWS IoT SiteWise 엣지 처리 기능을 포함한 전체 AWS IoT Greengrass V2 기능을 유지합니다.

## 사전 조건 및 제한 사항
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-prereqs"></a>

**사전 조건 **
+ 활성. AWS 계정
+ 일반적인 AWS IoT Greengrass Version 2 사전 조건은 AWS IoT Greengrass Version 2 설명서의 [사전 조건을 참조하세요](https://docs.aws.amazon.com/greengrass/v2/developerguide/getting-started-prerequisites.html).
+ Linux, macOS 또는 Windows에 설치 및 구성된 Docker Engine.
+ Docker Compose(Docker Compose 명령줄 인터페이스(CLI)를 사용하여 Docker 이미지를 실행하는 경우).
+ Linux 운영 체제.
+ 가상화를 지원하는 호스트 서버가 있는 하이퍼바이저입니다.
+ 시스템 요구 사항:
  + RAM 2GB(최소)
  + 사용 가능한 디스크 공간 5GB(최소)
  +  AWS IoT SiteWise Edge의 경우 16GB의 RAM과 50GB의 사용 가능한 디스크 공간이 있는 x86\$164 쿼드 코어 CPU입니다. AWS IoT SiteWise 데이터 처리에 대한 자세한 내용은 AWS IoT SiteWise 설명서의 [데이터 처리 팩 요구 사항을](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/configure-gateway-ggv2.html#w2aac17c19c13b7) 참조하세요.

**제품 버전**
+ AWS IoT Greengrass Version 2 버전 2.5.3 이상
+ Docker-in-Docker 버전 1.0.0 이상
+ Docker Compose 버전 1.22 이상
+ Docker Engine 버전 20.10.12 이상

**제한 사항 **
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전별 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)을 참조하고 서비스 링크를 선택합니다.

## 아키텍처
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-architecture"></a>

**대상 기술 스택**
+ **데이터 소스** - 처리를 위해 데이터를 생성하는 IoT 디바이스, 센서 또는 산업 장비
+ **AWS IoT Greengrass V2** - 엣지 인프라에 배포된 D-in-D 기능이 있는 Docker 컨테이너로 실행
+ **컨테이너화된 애플리케이션** - AWS IoT Greengrass V2 환경 내에서 중첩된 Docker 컨테이너로 실행되는 사용자 지정 애플리케이션
+ **(선택 사항) Amazon ECS Anywhere** – 컨테이너 배포를 관리하는 AWS IoT Greengrass V2 컨테이너 오케스트레이션
+ **기타 AWS 서비스** - 데이터 처리 및 관리를 AWS 서비스 위한 AWS IoT Core AWS IoT SiteWise및 기타

**대상 아키텍처 **

다음 다이어그램은 컨테이너 관리 도구인 Amazon ECS Anywhere를 사용하는 대상 배포 아키텍처의 예를 보여줍니다.

![\[Amazon ECS Anywhere를 사용하는 배포 아키텍처.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/2ecf5354-40e0-4fd9-9798-086719059784/images/5ed2652e-9604-4809-8962-b167e1991658.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

**1: 컨테이너 이미지 스토리지** - Amazon ECR은 엣지 처리에 필요한 AWS IoT Greengrass 컨테이너 이미지와 사용자 지정 애플리케이션 컨테이너를 저장합니다.

**2 **및** 3: 컨테이너 배포** - Amazon ECS Anywhere는 AWS IoT Greengrass Amazon ECR에서 엣지 로케이션으로 컨테이너 이미지를 배포하여 컨테이너 수명 주기 및 배포 프로세스를 관리합니다.

**4: 구성 요소 배포** - 배포된 AWS IoT Greengrass 코어는 구성에 따라 관련 구성 요소를 자동으로 배포합니다. 구성 요소에는 컨테이너화된 환경 내의 AWS IoT SiteWise 엣지 및 기타 필요한 엣지 처리 구성 요소가 포함됩니다.

**5: 데이터 수집 **- 완전히 구성된 후 엣지 로케이션의 다양한 IoT 데이터 소스에서 원격 측정 및 센서 데이터를 수집하기 AWS IoT Greengrass 시작합니다.

**6: 데이터 처리 및 클라우드 통합** - 컨테이너화된 AWS IoT Greengrass 코어는 배포된 구성 요소(산업 데이터용 AWS IoT SiteWise Edge 포함)를 사용하여 로컬에서 데이터를 처리합니다. 그런 다음 추가 분석 및 저장을 위해 처리된 데이터를 AWS 클라우드 서비스로 전송합니다.

## 도구
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-tools"></a>

**AWS 서비스**
+ [Amazon ECS Anywhere](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch-type-external.html)는 자체 인프라에서 Amazon ECS 작업 및 서비스를 배포, 사용 및 관리하는 데 도움이 됩니다.
+ [Amazon Elastic Compute Cloud(Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 필요한 만큼 가상 서버를 시작하고 빠르게 스케일 업하거나 스케일 다운할 수 있습니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장성이 있고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html)는 디바이스에서 IoT 애플리케이션을 구축, 배포 및 관리하는 데 도움이 되는 오픈 소스 사물 인터넷(IoT) 엣지 런타임 및 클라우드 서비스입니다.
+ AWS IoT SiteWise를 사용하면 대규모로 산업 장비 데이터를 수집, 구성 및 분석할 수 있습니다.

**기타 도구**
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.
+ Docker Compose는 멀티컨테이너 Docker 애플리케이션을 정의하고 실행하는 도구입니다.
+ [Docker Engine](https://docs.docker.com/engine/)은 애플리케이션을 구축하고 컨테이너화하기 위한 오픈 소스 컨테이너화 기술입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [AWS IoT Greengrass v2 Docker-in-Docker](https://github.com/aws-samples/aws-iot-greengrass-docker-in-docker) 리포지토리에서 사용할 수 있습니다.

## 에픽
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-epics"></a>

### AWS IoT Greengrass V2 Docker-in-Docker 이미지 빌드
<a name="build-the-gg2-docker-in-docker-image"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 를 복제하고 리포지토리로 이동합니다. | 리포지토리를 복제하려면 다음 명령을 사용합니다.`git clone https://github.com/aws-samples/aws-iot-greengrass-v2-docker-in-docker.git``docker` 디렉터리로 이동하려면 다음 명령을 사용합니다.`cd aws-iot-greengrass-v2-docker-in-docker/docker` | DevOps 엔지니어, AWS DevOps | 
| Docker 이미지를 구축합니다. | 기본(최신) 버전으로 Docker 이미지를 빌드하려면 다음 명령을 실행합니다.`docker build -t x86_64/aws-iot-greengrass:latest .`또는 특정 버전으로 Docker 이미지를 빌드하려면 다음 명령을 실행합니다.`docker build --build-arg GREENGRASS_RELEASE_VERSION=2.12.0 -t x86_64/aws-iot-greengrass:2.12.0 .`빌드를 확인하려면 다음 명령을 실행합니다.`docker images \| grep aws-iot-greengrass`  | AWS DevOps, DevOps 엔지니어, 앱 개발자 | 
| (선택 사항) Amazon ECR로 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 앱 개발자, AWS DevOps, DevOps 엔지니어 | 

### AWS 자격 증명 구성
<a name="configure-aws-credentials"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인증 방법을 선택합니다. | 다음 옵션 중 하나를 선택하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 관리자 | 
| 인증 방법을 구성합니다. | 선택한 인증 방법의 경우 다음 구성 지침을 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 관리자 | 

### Docker Compose로 실행
<a name="run-with-docker-compose"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| `docker-compose.yml`를 구성합니다. | 다음과 같이 환경 변수로 `docker-compose.yml` 파일을 업데이트합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps 엔지니어 | 
| 컨테이너를 시작하고 확인합니다. | 포그라운드에서 시작하려면 다음 명령을 실행합니다.`docker-compose up --build`또는 백그라운드에서 시작하려면 다음 명령을 실행합니다.`docker-compose up --build -d`상태를 확인하려면 다음 명령을 실행합니다.`docker-compose ps`로그를 모니터링하려면 다음 명령을 실행합니다.`docker-compose logs -f` | DevOps 엔지니어 | 

### Docker CLI로 실행
<a name="run-with-docker-cli"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Docker CLI를 사용하여 컨테이너를 실행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps 엔지니어 | 
| 컨테이너를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps 엔지니어 | 

### 컨테이너화된 애플리케이션 관리
<a name="manage-containerized-applications"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션을 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 앱 개발자 | 
| Docker-in-Docker에 액세스하고 테스트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps 엔지니어 | 

### (선택 사항) Amazon ECS Anywhere와 통합
<a name="optional-integrate-with-ecs-anywhere"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECS 클러스터를 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 관리자 | 
| Amazon ECS 작업을 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 관리자 | 

### 중지 및 정리
<a name="stop-and-cleanup"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 컨테이너를 중지합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | DevOps 엔지니어 | 

## 문제 해결
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 컨테이너가 권한 오류로 시작되지 않습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)`--privileged`는 컨테이너에 확장 권한을 부여합니다. | 
| 자격 증명 오류와 함께 프로비저닝이 실패합니다. | 자격 증명이 올바르게 구성되었는지 확인하려면 다음 단계를 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)IAM 권한에 `iot:CreateThing`, , `iot:CreatePolicy`, `iot:AttachPolicy`및 `iam:CreateRole`가 포함되어 있는지 확인합니다`iam:AttachRolePolicy`. | 
| 컨테이너 내부의 Docker 데몬에 연결할 수 없습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 
| 컨테이너에 디스크 공간이 부족합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)최소 디스크 공간 보장: 기본 작업의 경우 5GB, AWS IoT SiteWise Edge의 경우 50GB | 
| 빌드 문제. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html) | 
| 네트워크 연결 문제. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)방화벽이 아웃바운드 HTTPS(443) 및 MQTT(8883) 트래픽을 허용하는지 확인합니다. | 
| Greengrass 구성 요소가 배포되지 않습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)`/greengrass/v2/logs/` 디렉터리에서 구성 요소별 로그를 확인합니다. | 
| 컨테이너는 시작 후 즉시 종료됩니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.html)인 경우 필요한 모든 환경 변수가 올바르게 설정되었는지 확인합니다`PROVISION=true`. 컨테이너를 시작할 때 `--init` 플래그가 사용되는지 확인합니다. | 

## 관련 리소스
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-resources"></a>

**AWS resources**
+ [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)
+ [AWS IoT SiteWise 모델 및 자산에 대한 엣지 데이터 처리 구성](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/edge-processing.html)
+ [정의 AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html)

**기타 리소스**
+ [Docker 설명서](https://docs.docker.com/)

## 추가 정보
<a name="deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container-additional"></a>
+  AWS IoT SiteWise 엣지 데이터 처리의 경우 AWS IoT Greengrass 환경 내에서 Docker를 사용할 수 있어야 합니다.
+ 중첩 컨테이너를 실행하려면 관리자 수준 자격 증명으로 AWS IoT Greengrass 컨테이너를 실행해야 합니다.

# Elastic Beanstalk를 사용하여 컨테이너 배포
<a name="deploy-containers-by-using-elastic-beanstalk"></a>

*Thomas Scott, Jean-Baptiste Guillois, Amazon Web Services*

## 요약
<a name="deploy-containers-by-using-elastic-beanstalk-summary"></a>

Amazon Web Services(AWS) 클라우드에서 AWS Elastic Beanstalk는 Docker를 사용 가능한 플랫폼으로 지원하므로, 생성된 환경에서 컨테이너를 실행할 수 있습니다. 이 패턴은 Elastic Beanstalk 서비스를 사용하여 컨테이너를 배포하는 방법을 보여줍니다. 이 패턴을 배포할 때는 Docker 플랫폼 기반 웹 서버 환경을 사용합니다.

Elastic Beanstalk를 사용하여 웹 애플리케이션과 서비스를 배포하고 확장하려는 경우, 코드를 업로드하면 배포가 자동으로 처리됩니다. 용량 프로비저닝, 로드 밸런싱, 자동 조정 및 애플리케이션 상태 모니터링도 포함됩니다. Elastic Beanstalk를 사용하면 사용자 대신 Elastic Beanstalk에서 생성하는 AWS 리소스를 완전히 제어할 수 있습니다. Elastic Beanstalk에 대한 추가 비용은 없습니다. 애플리케이션을 저장하고 실행하는 데 사용된 AWS 리소스에 대한 비용만 지불하면 됩니다.

이 패턴에는 [AWS Elastic Beanstalk Command Line Interface(EB CLI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-advanced.html) 및 AWS Management Console을 사용하여 배포하기 위한 지침이 포함되어 있습니다.

**사용 사례**

Elastic Beanstalk의 사용 사례는 다음과 같습니다. 
+ 프로토타입 환경을 배포하여 프런트엔드 애플리케이션을 시연하십시오. (이 패턴은 Dockerfile을 ** ** 예로 사용합니다.)
+ API를 배포하여 지정된 도메인에 대한 API 요청을 처리하십시오.
+ Docker-Compose(이 패턴의 실제 예제에서는 `docker-compose.yml`이 사용되지 않음)를 사용하여 오케스트레이션 솔루션을 배포합니다.** ** 

## 사전 조건 및 제한 사항
<a name="deploy-containers-by-using-elastic-beanstalk-prereqs"></a>

**사전 조건 **
+ AWS 계정
+ AWS EB CLI가 로컬에 설치됨
+ Docker가 로컬 머신에 설치됨

**제한 사항 **
+ 무료 요금제에서는 IP 주소당 6시간당 100회의 풀로 Docker 풀 제한이 있습니다.

## 아키텍처
<a name="deploy-containers-by-using-elastic-beanstalk-architecture"></a>

**대상 기술 스택 **
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스
+ 보안 그룹
+ Application Load Balancer
+ Auto Scaling 그룹

**대상 아키텍처 **

![\[Elastic Beanstalk를 사용하여 컨테이너를 배포하기 위한 아키텍처.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/dfabcdc2-747f-40e2-a603-08ea31ba71d3/images/1d17ff09-1aea-4c72-adb5-eaf741601428.png)


**자동화 및 규모 조정**

AWS Elastic Beanstalk는 요청의 수에 따라 자동으로 규모가 조정됩니다. 환경에 대해 생성된 AWS 리소스에는 Application Load Balancer, Auto Scaling 그룹, 하나 이상의 Amazon EC2 인스턴스가 포함됩니다. 

로드 밸런서는 Auto Scaling 그룹의 일부인 Amazon EC2 인스턴스의 앞에 위치합니다. Amazon EC2 Auto Scaling은 추가 Amazon EC2 인스턴스를 자동으로 시작하여 애플리케이션의 증가하는 로드를 처리합니다. 애플리케이션의 로드가 감소하면 Amazon EC2 Auto Scaling은 인스턴스를 중지하지만 최소 한 개의 인스턴스는 실행 상태로 유지합니다.

**자동 크기 조정 트리거**

Elastic Beanstalk 환경의 Auto Scaling 그룹은 두 가지 Amazon CloudWatch 경보를 사용하여 조정 작업을 시작합니다. 기본 트리거는 각 인스턴스의 평균 아웃바운드 네트워크 트래픽이 5분 이상 6MB보다 높거나 2MB보다 낮은 경우 규모 조정을 트리거합니다. Amazon EC2 Auto Scaling을 효과적으로 사용하려면 애플리케이션, 인스턴스 유형 및 서비스 요구 사항에 적절한 트리거를 구성합니다. 지연 시간, 디스크 I/O, CPU 사용률 및 요청 수 등 여러 통계를 기준으로 규모를 조정할 수 있습니다. 자세한 정보는 [ Auto Scaling 트리거](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-autoscaling-triggers.html)를 참조하십시오.

## 도구
<a name="deploy-containers-by-using-elastic-beanstalk-tools"></a>

**서비스**
+ [AWS Command Line Interface(AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 쉘에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다.
+ [AWS EB Command Line Interface(EB CLI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html)는 Elastic Beanstalk 환경을 생성, 구성 및 관리하는 데 사용할 수 있는 명령줄 클라이언트입니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 예를 들어 하나 이상의 가용 영역에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 전반에 걸쳐 트래픽을 분산할 수 있습니다.

**기타 서비스**
+ [Docker](https://www.docker.com/)는 소프트웨어를 라이브러리, 시스템 도구, 코드 및 런타임을 포함하는 컨테이너라는 표준화된 유닛으로 패키징합니다.

**코드**

이 패턴의 코드는 GitHub [클러스터 샘플 애플리케이션](https://github.com/aws-samples/cluster-sample-app) 리포지토리에서 제공됩니다.

## 에픽
<a name="deploy-containers-by-using-elastic-beanstalk-epics"></a>

### Dockerfile을 사용하여 구축
<a name="build-with-a-dockerfile"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 원격 리포지토리를 복제합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| Elastic Beanstalk Docker 프로젝트를 초기화합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| 프로젝트를 로컬에서 테스트하십시오. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | 앱 개발자, AWS 관리자, AWS DevOps | 

### EB CLI를 사용하여 배포
<a name="deploy-using-eb-cli"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 배포 명령 실행 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| 배포된 버전에 액세스하십시오. | 배포 명령이 완료되면 `eb open` 명령어를 사용하여 프로젝트에 액세스합니다. | 앱 개발자, AWS 관리자, AWS DevOps | 

### 콘솔을 사용하여 배포
<a name="deploy-using-the-console"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 브라우저를 사용하여 애플리케이션을 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-containers-by-using-elastic-beanstalk.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| 배포된 버전에 액세스하십시오. | 배포 후 배포된 애플리케이션에 액세스하고 제공된 URL을 선택합니다. | 앱 개발자, AWS 관리자, AWS DevOps | 

## 관련 리소스
<a name="deploy-containers-by-using-elastic-beanstalk-resources"></a>
+ [웹 서버 환경](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-webserver.html)
+ [macOS에 EB CLI 설치](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-osx.html)
+ [수동으로 EB CLI 설치](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install-advanced.html)

## 추가 정보
<a name="deploy-containers-by-using-elastic-beanstalk-additional"></a>

**Elastic Beanstalk 사용의 이점**
+ 자동 인프라 프로비저닝
+ 기본 플랫폼의 자동 관리
+ 애플리케이션 지원을 위한 자동 패치 및 업데이트
+ 애플리케이션 자동 조정
+ 노드 수를 사용자 지정하는 기능
+ 필요한 경우 인프라 구성 요소에 액세스하는 기능
+ 다른 컨테이너 배포 솔루션 대비 쉬운 배포

# Lambda 함수, Amazon VPC 및 서버리스 아키텍처를 사용하여 정적 아웃바운드 IP 주소 생성
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture"></a>

*Thomas Scott, Amazon Web Services*

## 요약
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-summary"></a>

이 패턴은 서버리스 아키텍처로 Amazon Web Services(AWS) 클라우드에서 고정 아웃바운드 IP 주소를 생성하는 방법을 설명합니다. 조직에서 Secure File Transfer Protocol(SFTP)을 사용하여 별도의 사업체에 파일을 보내려는 경우 이 접근 방식을 활용할 수 있습니다. 즉, 비즈니스 엔터티는 방화벽을 통해 파일을 허용하는 IP 주소에 액세스할 수 있어야 합니다. 

이 패턴의 접근 방식은 [Elastic IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 아웃바운드 IP 주소로 사용하는 AWS Lambda 함수를 생성하는 데 도움이 됩니다. 이 패턴의 단계를 따르면 고정 IP 주소를 사용하는 인터넷 게이트웨이를 통해 아웃바운드 트래픽을 라우팅하는 Lambda 함수와 Virtual Private Cloud(VPC)를 생성할 수 있습니다. 고정 IP 주소를 사용하려면 Lambda 함수를 VPC와 서브넷에 연결합니다. 

## 사전 조건 및 제한 사항
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정. 
+ Lambda 함수를 생성 및 배포하고 VPC 및 서브넷을 생성할 수 있는 AWS Identity and Access(IAM) 권한. 이에 대한 자세한 내용은 AWS Lambda 설명서의 [실행 역할 및 사용자 권한](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-permissions)을 참조하십시오.
+ 코드형 인프라(IaC)를 사용하여 이 패턴의 접근 방식을 구현하려면 AWS Cloud9와 같은 통합 개발 환경(IDE)이 필요합니다. 이에 대한 자세한 내용은 AWS Cloud9 설명서의 [AWS Cloud9란 무엇인가요?](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)를 참조하세요.

## 아키텍처
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-architecture"></a>

다음 다이어그램은 이 패턴의 서버리스 아키텍처입니다.

![\[AWS 클라우드 VPC architecture with two availability zones, public and private subnets, NAT gateways, and a Lambda function.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/eb1d0b05-df33-45ae-b27e-36090055b300/images/c15cc6da-ce4e-4ea0-9feb-de1c845d3ce8.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. 아웃바운드 트래픽은 `NAT gateway 1`를 `Public subnet 1`에 남깁니다.

1. 아웃바운드 트래픽은 `NAT gateway 2`를 `Public subnet 2`에 남깁니다.

1. Lambda 함수는 `Private subnet 1` 또는 `Private subnet 2`에서 실행할 수 있습니다.

1. `Private subnet 1` 및 `Private subnet 2`는 퍼블릭 서브넷의 NAT 게이트웨이로 트래픽을 라우팅합니다.

1. NAT 게이트웨이는 퍼블릭 서브넷에서 인터넷 게이트웨이로 아웃바운드 트래픽을 전송합니다.

1. 아웃바운드 데이터는 인터넷 게이트웨이에서 외부 서버로 전송됩니다.



**기술 스택  **
+ Lambda
+ Amazon Virtual Private Cloud(Amazon VPC)

 

**자동화 및 규모 조정**

서로 다른 가용 영역에서 두 개의 퍼블릭 서브넷과 두 개의 프라이빗 서브넷을 사용하여 고가용성(HA)을 보장할 수 있습니다. 하나의 가용 영역을 사용할 수 없게 되더라도 패턴의 솔루션은 계속 작동합니다.

## 도구
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-tools"></a>
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) - AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다. Lambda는 필요 시에만 코드를 실행하며, 일일 몇 개의 요청에서 초당 수천 개의 요청까지 자동으로 규모를 조정합니다. 사용한 컴퓨팅 시간만큼만 비용을 지불하고, 코드가 실행되지 않을 때는 요금이 부과되지 않습니다.
+ [Amazon VPC](https://docs.aws.amazon.com/vpc/) – Amazon Virtual Private Cloud(VPC)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있도록 클라우드의 논리적으로 격리된 섹션을 프로비저닝할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

## 에픽
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-epics"></a>

### 새 VPC 생성
<a name="create-a-new-vpc"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 새 VPC를 생성합니다. | AWS Management Console에 로그인하고 Amazon VPC 콘솔을 연 다음 IPv4 CIDR 범위로 `10.0.0.0/25`****를 가진 `Lambda VPC` 이름의 VPC를 생성합니다.VPC 생성에 대한 자세한 내용은 Amazon VPC 설명서의 [Amazon VPC 시작하기](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html#getting-started-create-vpc)를 참조하십시오.  | AWS 관리자 | 

### 퍼블릭 서브넷 2개 생성
<a name="create-two-public-subnets"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 첫 번째 퍼블릭 서브넷을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 두 번째 퍼블릭 서브넷을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 

### 프라이빗 서브넷 2개 생성
<a name="create-two-private-subnets"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 첫 번째 프라이빗 서브넷을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 두 번째 프라이빗 서브넷을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 

### NAT 게이트웨이에 대한 Elastic IP 주소 2개 생성
<a name="create-two-elastic-ip-addresses-for-your-nat-gateways"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  첫 번째 Elastic IP 주소를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html)이 Elastic IP 주소는 첫 번째 NAT 게이트웨이에 사용됩니다.  | 관리자 | 
| 두 번째 Elastic IP 주소를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html)이 Elastic IP 주소는 두 번째 NAT 게이트웨이에 사용됩니다. | 관리자 | 

### 인터넷 게이트웨이 생성
<a name="create-an-internet-gateway"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인터넷 게이트웨이를 만듭니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 인터넷 게이트웨이를 VPC에 연결합니다. | 방금 생성한 인터넷 게이트웨이를 선택한 후 **Actions, Attach to VPC(작업, VPC에 연결)**을 선택합니다. | AWS 관리자 | 

### NAT 게이트웨이 2개 생성
<a name="create-two-nat-gateways"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 첫 번째 NAT 게이트웨이를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 두 번째 NAT 게이트웨이를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 

### 퍼블릭 및 프라이빗 서브넷을 위한 라우팅 테이블을 생성합니다.
<a name="create-route-tables-for-your-public-and-private-subnets"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 퍼블릭 1 서브넷의 라우팅 테이블을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 퍼블릭 2 서브넷의 라우팅 테이블을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 프라이빗 1 서브넷의 라우팅 테이블을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 프라이빗 2 서브넷의 라우팅 테이블을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 

### Lambda 함수를 생성하고, VPC에 추가하며, 솔루션을 테스트합니다.
<a name="create-the-lambda-function-add-it-to-the-vpc-and-test-the-solution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 새 Lambda 함수를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| Lambda 함수를 VPC에 추가합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | AWS 관리자 | 
| 외부 서비스를 직접적으로 호출하기 위한 코드를 작성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html) | 관리자 | 

## 관련 리소스
<a name="generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture-resources"></a>
+ [VPC에서 리소스에 액세스하도록 Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html)

# Amazon ECR 리포지토리로 마이그레이션할 때 중복 컨테이너 이미지 자동 식별
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository"></a>

*Rishabh Yadav 및 Rishi Singla, Amazon Web Services*

## 요약
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-summary"></a>

이 패턴은 서로 다른 컨테이너 리포지토리에 저장된 이미지가 중복되는지 여부를 식별하는 자동화된 솔루션을 제공합니다. 이 검사는 다른 컨테이너 리포지토리의 이미지를 Amazon Elastic Container Registry(Amazon ECR)로 마이그레이션하려는 경우에 유용합니다.

기본 정보의 경우 패턴은 이미지 다이제스트, 매니페스트 및 태그와 같은 컨테이너 이미지의 구성 요소도 설명합니다. Amazon ECR로의 마이그레이션을 계획할 때 이미지 다이제스트를 비교하여 컨테이너 레지스트리 간에 컨테이너 이미지를 동기화하기로 결정할 수 있습니다. 컨테이너 이미지를 마이그레이션하기 전에 중복을 방지하기 위해 이러한 이미지가 Amazon ECR 리포지토리에 이미 존재하는지 확인해야 합니다. 그러나 이미지 다이제스트를 비교하여 중복을 감지하기 어려울 수 있으며, 이로 인해 초기 마이그레이션 단계에서 문제가 발생할 수 있습니다.  이 패턴은 서로 다른 컨테이너 레지스트리에 저장된 두 개의 유사한 이미지의 다이제스트를 비교하고 다이제스트가 다른 이유를 설명하여 이미지를 정확하게 비교하는 데 도움이 됩니다.

## 사전 조건 및 제한 사항
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-prereqs"></a>
+ 활성 AWS 계정
+ [Amazon ECR 퍼블릭 레지스트리](https://gallery.ecr.aws/)에 대한 액세스
+  AWS 서비스다음에 대한 지식:
  + [AWS CodeCommit](https://aws.amazon.com/codecommit/)
  + [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
  + [AWS CodeBuild](https://aws.amazon.com/codebuild/)
  + [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/)
  + [Amazon Simple Storage Service(Amazon S3)](https://aws.amazon.com/s3/)
+ 구성된 CodeCommit 자격 증명([지침](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) 참조)

## 아키텍처
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-architecture"></a>

**컨테이너 이미지 구성 요소**

다음 다이어그램은 컨테이너 이미지의 일부 구성 요소를 보여줍니다. 이러한 구성 요소는 다이어그램 뒤에 설명되어 있습니다.

![\[매니페스트, 구성, 파일 시스템 계층 및 다이제스트.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/7db5020c-6f5b-4e91-b91a-5b8ae844be1b/images/71b99c67-a934-4f94-8af8-2a8431fb91f5.png)


**용어 및 정의**

다음 용어는 [Open Container Initiative(OCI) 이미지 사양](https://github.com/opencontainers/image-spec/blob/main/spec.md)에 정의되어 있습니다.
+ **레지스트리:** 이미지 저장 및 관리를 위한 서비스입니다.
+ **클라이언트:** 레지스트리와 통신하고 로컬 이미지와 작동하는 도구입니다.
+ **푸시:** 레지스트리에 이미지를 업로드하는 프로세스입니다.
+ **풀:** 레지스트리에서 이미지를 다운로드하는 프로세스입니다.
+ **Blob:** 레지스트리에 저장되고 다이제스트에 의해 처리될 수 있는 콘텐츠의 이진 형식입니다.
+ **인덱스:** 다양한 컴퓨터 플랫폼(예: x86-64 또는 ARM 64비트) 또는 미디어 유형에 대한 여러 이미지 매니페스트를 식별하는 구문입니다. 자세한 내용은 [OCI 이미지 인덱스 사양](https://github.com/opencontainers/image-spec/blob/main/image-index.md)을 참조하세요.
+ **매니페스트:** 매니페스트의 엔드포인트를 통해 업로드되는 이미지 또는 아티팩트를 정의하는 JSON 문서입니다. 매니페스트는 설명자를 사용하여 리포지토리의 다른 BLOB을 참조할 수 있습니다. 자세한 내용은 [OCI 이미지 매니페스트 사양](https://github.com/opencontainers/image-spec/blob/main/manifest.md)을 참조하세요.
+ **파일 시스템 계층:** 이미지에 대한 시스템 라이브러리 및 기타 종속성입니다.
+ **구성:** 아티팩트 메타데이터를 포함하고 매니페스트에서 참조되는 BLOB입니다. 자세한 내용은 [OCI 이미지 구성 사양](https://github.com/opencontainers/image-spec/blob/main/config.md)을 참조하세요.
+ **객체 또는 아티팩트:** Blob으로 저장되고 구성과 함께 제공되는 매니페스트와 연결된 개념적 콘텐츠 항목입니다.
+ **다이제스트:** 매니페스트 콘텐츠의 암호화 해시에서 생성되는 고유 식별자입니다. 이미지 다이제스트는 변경 불가능한 컨테이너 이미지를 고유하게 식별하는 데 도움이 됩니다. 다이제스트를 사용하여 이미지를 가져오면 모든 운영 체제 또는 아키텍처에서 매번 동일한 이미지를 다운로드합니다. 자세한 내용은 [OCI 이미지 사양](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests)을 참조하세요.
+ **태그:** 사람이 읽을 수 있는 매니페스트 식별자입니다. 변경 불가능한 이미지 다이제스트와 비교하여 태그는 동적입니다. 기본 이미지 다이제스트는 동일하게 유지되지만 이미지를 가리키는 태그는 한 이미지에서 다른 이미지로 변경되고 이동할 수 있습니다.

**대상 아키텍처 **

다음 다이어그램은 Amazon ECR과 프라이빗 리포지토리에 저장된 이미지를 비교하여 중복 컨테이너 이미지를 식별하기 위해이 패턴에서 제공하는 솔루션의 상위 수준 아키텍처를 보여줍니다.

![\[CodePipeline 및 CodeBuild를 사용하여 중복을 자동으로 감지합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/7db5020c-6f5b-4e91-b91a-5b8ae844be1b/images/5ee62bc8-db8d-48a3-9e79-f3392b6e9bf7.png)


## 도구
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-tools"></a>

**AWS 서비스**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 리전의 수명 주기 동안 리소스를 관리할 수 있습니다.
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)는 소스 코드를 컴파일하고 유닛 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 완전관리형 빌드 서비스입니다.
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)은 나만의 소스 제어 시스템을 관리할 필요 없이 Git 리포지토리를 비공개로 저장하고 관리할 수 있는 버전 제어 서비스입니다.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)은 소프트웨어 릴리스의 여러 단계를 신속하게 모델링하고 구성하고 소프트웨어 변경 내용을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장성이 있고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.

**코드 **

이 패턴의 코드는 GitHub 리포지토리** **[자동 솔루션에서 리포지토리 간에 중복 컨테이너 이미지를 식별할 수 있습니다](https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories/).

## 모범 사례
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-best-practices"></a>
+ [CloudFormation  ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) 모범 사례
+ [AWS CodePipeline  ](https://docs.aws.amazon.com/codepipeline/latest/userguide/best-practices.html) 모범 사례

## 에픽
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-epics"></a>

### Amazon ECR 퍼블릭 및 프라이빗 리포지토리에서 컨테이너 이미지를 풀링합니다.
<a name="pull-container-images-from-ecr-public-and-private-repositories"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECR 퍼블릭 리포지토리에서 이미지를 풀링합니다. | 터미널에서 다음 명령을 실행하여 Amazon ECR 퍼블릭 리포지토리`amazonlinux`에서 이미지를 가져옵니다.<pre>$~ % docker pull public.ecr.aws/amazonlinux/amazonlinux:2018.03 </pre>이미지를 로컬 시스템으로 가져오면 이미지 인덱스를 나타내는 다음과 같은 풀 다이제스트가 표시됩니다.<pre>2018.03: Pulling from amazonlinux/amazonlinux<br />4ddc0f8d367f: Pull complete <br /><br />Digest: sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5<br /><br />Status: Downloaded newer image for public.ecr.aws/amazonlinux/amazonlinux:2018.03<br />public.ecr.aws/amazonlinux/amazonlinux:2018.03</pre> | 앱 개발자, AWS DevOps, AWS 관리자 | 
| Amazon ECR 프라이빗 리포지토리에 이미지를 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 관리자, AWS DevOps, 앱 개발자 | 
| Amazon ECR 프라이빗 리포지토리에서 동일한 이미지를 가져옵니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | 앱 개발자, AWS DevOps, AWS 관리자 | 

### 이미지 매니페스트 비교
<a name="compare-the-image-manifests"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECR 퍼블릭 리포지토리에 저장된 이미지의 매니페스트를 찾습니다. | 터미널에서 다음 명령을 실행하여 Amazon ECR 퍼블릭 리포지토리`public.ecr.aws/amazonlinux/amazonlinux:2018.03`에서 이미지 매니페스트를 가져옵니다.<pre>$~ % docker manifest inspect public.ecr.aws/amazonlinux/amazonlinux:2018.03<br />{<br />   "schemaVersion": 2,<br />   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",<br />   "manifests": [<br />      {<br />         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",<br />         "size": 529,<br />         "digest": "sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02",<br />         "platform": {<br />            "architecture": "amd64",<br />            "os": "linux"<br />         }<br />      }<br />   ]<br />}</pre> | AWS 관리자, AWS DevOps, 앱 개발자 | 
| Amazon ECR 프라이빗 리포지토리에 저장된 이미지의 매니페스트를 찾습니다. | 터미널에서 다음 명령을 실행하여 Amazon ECR 프라이빗 리포지토리`<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest`에서 이미지 매니페스트를 가져옵니다.<pre>$~ % docker manifest inspect <account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest                                          <br />{<br />	"schemaVersion": 2,<br />	"mediaType": "application/vnd.docker.distribution.manifest.v2+json",<br />	"config": {<br />		"mediaType": "application/vnd.docker.container.image.v1+json",<br />		"size": 1477,<br />		"digest": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68"<br />	},<br />	"layers": [<br />		{<br />			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",<br />			"size": 62267075,<br />			"digest": "sha256:4ddc0f8d367f424871a060e2067749f32bd36a91085e714dcb159952f2d71453"<br />		}<br />	]<br />}</pre> | AWS DevOps, AWS 시스템 관리자, 앱 개발자 | 
| Docker에서 가져온 다이제스트를 Amazon ECR 프라이빗 리포지토리의 이미지에 대한 매니페스트 다이제스트와 비교합니다. | 또 다른 질문은 **Docker pull** 명령에서 제공하는 다이제스트가 이미지에 대한 매니페스트 다이제스트와 다른 이유입니다`<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest`.**Docker 풀**에 사용되는 다이제스트는 레지스트리에 저장된 이미지 매니페스트의 다이제스트를 나타냅니다. 매니페스트에는 다운로드하여 Docker로 가져올 콘텐츠의 해시가 포함되어 있으므로이 다이제스트는 해시 체인의 루트로 간주됩니다.Docker 내에서 사용되는 이미지 ID는이 매니페스트에서 로 찾을 수 있습니다`config.digest`. 이는 Docker가 사용하는 이미지 구성을 나타냅니다. 따라서 매니페스트가 봉투이고 이미지가 봉투의 내용이라고 말할 수 있습니다. 매니페스트 다이제스트는 항상 이미지 ID와 다릅니다. 그러나 특정 매니페스트는 항상 동일한 이미지 ID를 생성해야 합니다. 매니페스트 다이제스트는 해시 체인이므로 지정된 이미지 ID에 대해 항상 동일하다고 보장할 수 없습니다. Docker는 이를 보장할 수 없지만 대부분의 경우 동일한 다이제스트를 생성합니다. 매니페스트 다이제스트의 가능한 차이는 Docker가 로컬에 gzip으로 압축된 blob을 저장하지 않기 때문입니다. 따라서 계층을 내보내면 압축되지 않은 콘텐츠는 동일하게 유지되지만 다른 다이제스트가 생성될 수 있습니다. 이미지 ID는 압축되지 않은 콘텐츠가 동일한지 확인합니다. 즉, 이미지 ID는 이제 콘텐츠 주소 지정 식별자()입니다`chainID`.이 정보를 확인하려면 Amazon ECR 퍼블릭 및 프라이빗 리포지토리에서 **docker inspect** 명령의 출력을 비교할 수 있습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)결과는 두 이미지의 이미지 ID 다이제스트와 계층 다이제스트가 동일한지 확인합니다.ID: `f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68`계층: `d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2`또한 다이제스트는 로컬에서 관리되는 객체의 바이트(로컬 파일은 컨테이너 이미지 계층의 tar) 또는 레지스트리 서버로 푸시되는 blob을 기반으로 합니다. 그러나 Blob을 레지스트리로 푸시하면 tar가 압축되고 다이제스트는 압축된 tar 파일에서 계산됩니다. 따라서 **Docker pull** 다이제스트 값의 차이는 레지스트리(Amazon ECR 프라이빗 또는 퍼블릭) 수준에서 적용되는 압축으로 인해 발생합니다.이 설명은 Docker 클라이언트 사용에 고유합니다. **nerdctl** 또는 **Finch**와 같은 다른 클라이언트에서는 푸시 및 풀 작업 중에 이미지를 자동으로 압축하지 않으므로 이러한 동작이 표시되지 않습니다. | AWS DevOps, AWS 시스템 관리자, 앱 개발자 | 

### Amazon ECR 퍼블릭 리포지토리와 프라이빗 리포지토리 간의 중복 이미지 자동 식별
<a name="automatically-identify-duplicate-images-between-ecr-public-and-private-repositories"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 이 패턴의 Github 리포지토리를 로컬 폴더로 복제합니다.<pre>$git clone https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories</pre> | AWS 관리자, AWS DevOps | 
| CI/CD 파이프라인을 설정합니다. | GitHub 리포지토리에는 파이프라인을 설정할 CloudFormation 스택을 생성하는 `.yaml` 파일이 포함되어 있습니다 AWS CodePipeline.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)파이프라인은 퍼블릭 리포지토리에도 존재하는 프라이빗 리포지토리의 이미지를 식별하기 위해 두 단계( 아키텍처 다이어그램에 표시된 대로 CodeCommit 및 CodeBuild)로 설정됩니다. 파이프라인은 다음 리소스로 구성됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 관리자, AWS DevOps | 
| CodeCommit 리포지토리를 채웁니다. | CodeCommit 리포지토리를 채우려면 다음 단계를 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | AWS 관리자, AWS DevOps | 
| 정리 | 향후 요금이 발생하지 않도록 하려면 다음 단계에 따라 리소스를 삭제합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | 관리자 | 

## 문제 해결
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 터미널이나 명령줄에서 CodeCommit 리포지토리에 대해 푸시하거나 풀하거나 상호 작용하려 할 때, 사용자 이름과 암호를 입력하라는 메시지가 표시되며 IAM 사용자의 Git 보안 인증 정보를 제공해야 합니다. | 이 오류의 가장 일반적인 원인은 다음과 같습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html)운영 체제 및 로컬 환경에 따라 사용자는 보안 인증 정보 관리자를 설치하거나, 운영 체제에 포함된 보안 인증 정보 관리자를 구성하거나, 보안 인증 정보 스토리지를 사용하도록 로컬 환경을 사용자 지정해야 할 수 있습니다. 예를 들어, 컴퓨터에서 macOS를 실행하는 경우에는 Keychain Access 유틸리티를 사용하여 보안 인증 정보를 저장할 수 있습니다. 컴퓨터에서 Windows를 실행하는 경우에는 Windows용 Git과 함께 설치된 Git 보안 인증 정보 관리자를 사용할 수 있습니다. 자세한 내용은 CodeCommit 설명서의 [Git 자격 증명을 사용한 HTTPS 사용자 설정](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) 및 Git 설명서의 [자격 증명 스토리지](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage)를 참조하세요. | 
| 이미지를 Amazon ECR 리포지토리로 푸시할 때 HTTP 403 또는 "기본 인증 자격 증명 없음" 오류가 발생합니다. | **aws ecr get-login-password** 명령을 사용하여 Docker에 성공적으로 인증한 경우에도 **docker push** 또는 **docker pull** 명령에서 이러한 오류 메시지가 발생할 수 있습니다. 알려진 원인은 다음과 같습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.html) | 

## 관련 리소스
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-resources"></a>
+ [리포지토리 간 중복 컨테이너 이미지를 식별하는 자동화된 솔루션](https://github.com/aws-samples/automated-solution-to-identify-duplicate-container-images-between-repositories/)(GitHub 리포지토리)
+ [Amazon ECR 퍼블릭 갤러리](https://gallery.ecr.aws/)
+ [Amazon ECR의 프라이빗 이미지](https://docs.aws.amazon.com/AmazonECR/latest/userguide/images.html)(Amazon ECR 설명서)
+ [AWS::CodePipeline::Pipeline 리소스](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-pipeline.html)(CloudFormation 문서)
+ [OCI 이미지 형식 사양](https://github.com/opencontainers/image-spec/blob/main/spec.md)

## 추가 정보
<a name="identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository-additional"></a>

**Amazon ECR 퍼블릭 리포지토리의 이미지에 대한 Docker 검사 출력**

```
[
    {
        "Id": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68",
        "RepoTags": [
            "<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest",
            "public.ecr.aws/amazonlinux/amazonlinux:2018.03"
        ],
        "RepoDigests": [
            "<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository@sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02",
            "public.ecr.aws/amazonlinux/amazonlinux@sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2023-02-23T06:20:11.575053226Z",
        "Container": "ec7f2fc7d2b6a382384061247ef603e7d647d65f5cd4fa397a3ccbba9278367c",
        "ContainerConfig": {
            "Hostname": "ec7f2fc7d2b6",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"/bin/bash\"]"
            ],
            "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
        "DockerVersion": "20.10.17",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/bash"
            ],
            "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 167436755,
        "VirtualSize": 167436755,
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/merged",
                "UpperDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/diff",
                "WorkDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2"
            ]
        },
        "Metadata": {
            "LastTagTime": "2023-03-02T10:28:47.142155987Z"
        }
    }
]
```

**Amazon ECR 프라이빗 리포지토리의 이미지에 대한 Docker 검사 출력**

```
[
    {
        "Id": "sha256:f7cee5e1af28ad4e147589c474d399b12d9b551ef4c3e11e02d982fce5eebc68",
        "RepoTags": [
            "<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository:latest",
            "public.ecr.aws/amazonlinux/amazonlinux:2018.03"
        ],
        "RepoDigests": [
            "<account-id>.dkr.ecr.us-east-1.amazonaws.com/test_ecr_repository@sha256:52db9000073d93b9bdee6a7246a68c35a741aaade05a8f4febba0bf795cdac02",
            "public.ecr.aws/amazonlinux/amazonlinux@sha256:f972d24199508c52de7ad37a298bda35d8a1bd7df158149b381c03f6c6e363b5"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2023-02-23T06:20:11.575053226Z",
        "Container": "ec7f2fc7d2b6a382384061247ef603e7d647d65f5cd4fa397a3ccbba9278367c",
        "ContainerConfig": {
            "Hostname": "ec7f2fc7d2b6",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"/bin/bash\"]"
            ],
            "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
        "DockerVersion": "20.10.17",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/bash"
            ],
            "Image": "sha256:c1bced1b5a65681e1e0e52d0a6ad17aaf76606149492ca0bf519a466ecb21e51",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 167436755,
        "VirtualSize": 167436755,
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/merged",
                "UpperDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/diff",
                "WorkDir": "/var/lib/docker/overlay2/c2c2351a82b26cbdf7782507500e5adb5c2b3a2875bdbba79788a4b27cd6a913/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:d5655967c2c4e8d68f8ec7cf753218938669e6c16ac1324303c073c736a2e2a2"
            ]
        },
        "Metadata": {
            "LastTagTime": "2023-03-02T10:28:47.142155987Z"
        }
    }
]
```

# Kubernetes DaemonSet을 사용하여 Amazon EKS 워커 노드에 SSM 에이전트 설치
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset"></a>

*Mahendra Revanasiddappa, Amazon Web Services*

## 요약
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-summary"></a>

**참고, 2021년 9월:** 최신 Amazon EKS 최적화 AMI는 SSM 에이전트를 자동으로 설치합니다. 자세한 내용은 2021년 6월 AMI [릴리스 정보](https://github.com/awslabs/amazon-eks-ami/releases/tag/v20210621)를 참조하세요..

Amazon Elastic Kubernetes Service(Amazon EKS)에서는 보안 지침으로 인해 워커 노드에 Secure Shell(SSH) 키 페어가 연결되어 있지 않습니다. 이 패턴은 수동으로 설치하거나 노드의 Amazon Machine Image(AMI)를 교체하는 대신 Kubernetes DaemonSet 리소스 유형을 사용하여 모든 워커 노드에 AWS Systems Manager Agent(SSM Agent)를 설치하는 방법을 보여줍니다. DaemonSet은 워커 노드의 크론 작업을 사용하여 SSM 에이전트 설치를 예약합니다. 이 패턴을 사용하여 워커 노드에 다른 패키지를 설치할 수도 있습니다.

클러스터에서 문제를 해결할 때 필요에 따라 SSM 에이전트를 설치하면 SSH 키 페어 없이 워커 노드와 SSH 세션을 설정하거나, 로그를 수집하거나, 인스턴스 구성을 살펴볼 수 있습니다.

## 사전 조건 및 제한 사항
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-prereqs"></a>

**사전 조건 **
+ Amazon Elastic Compute Cloud(Amazon EC2) 워커 노드가 있는 기존 Amazon EKS 클러스터입니다.
+ 컨테이너 인스턴스는 SSM 서비스와 통신하는 데 필요한 권한을 가져야 합니다. AWS Identity 및 Access Management(IAM) 관리형 역할인 **AmazonSSMManagedInstanceCore**는 EC2 인스턴스에서 SSM 에이전트를 실행하는 데 필요한 권한을 제공합니다. 자세한 내용은 [AWS Systems Manager 설명서](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html)를 참조하세요.

**제한 사항 **
+ DaemonSet은 Fargate 플랫폼에서 지원되지 않기 때문에 이 패턴은 AWS Fargate에는 적용할 수 없습니다.
+ 이 패턴은 Linux 기반 워커 노드에만 적용됩니다.
+ DaemonSet 포드는 권한 모드에서 실행됩니다. Amazon EKS 클러스터에 권한 모드에서 포드를 차단하는 웹후크가 있는 경우 SSM 에이전트는 설치되지 않습니다.

## 아키텍처
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-architecture"></a>

다음 사항은 이 패턴에 대한 아키텍처를 나타낸 다이어그램입니다.

![\[Kubernetes DaemonSet을 사용하여 Amazon EKS 워커 노드에 SSM 에이전트 설치\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/016d53f3-45c1-4913-b542-67124e1462b8/images/3a6dfd00-e54b-44d5-843a-4c26ce9826c9.png)


## 도구
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-tools"></a>

**도구**
+ [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)은 Amazon EKS 클러스터와 상호 작용하는 데 사용하는 명령줄 유틸리티입니다. 이 패턴은 `kubectl`이 Amazon EKS 클러스터에 DaemonSet을 배포하는 데 사용됩니다. 그러면 모든 워커 노드에 SSM 에이전트가 설치됩니다.
+ [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 사용하면 자체 Kubernetes 컨트롤 플레인이나 노드를 설치, 운영 및 유지 관리할 필요 없이 AWS에서 Kubernetes를 쉽게 실행할 수 있습니다. Kubernetes는 컨테이너화된 애플리케이션의 배포, 조정 및 관리 자동화를 위한 오픈 소스 시스템입니다.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)를 사용하면 대화형, 원클릭, 브라우저 기반 쉘 또는 AWS Command Line Interface(AWS CLI)를 통해 EC2 인스턴스, 온프레미스 인스턴스 및 가상 머신(VM)을 관리할 수 있습니다.

**코드**

다음 코드를 사용하여 Amazon EKS 클러스터에 SSM 에이전트를 설치하는 데몬셋 구성 파일을 생성합니다. [에픽](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-epics) 섹션의 지침을 따르세요.

```
cat << EOF > ssm_daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: ssm-installer
  name: ssm-installer
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: ssm-installer
  template:
    metadata:
      labels:
        k8s-app: ssm-installer
    spec:
      containers:
      - name: sleeper
        image: busybox
        command: ['sh', '-c', 'echo I keep things running! && sleep 3600']
      initContainers:
      - image: amazonlinux
        imagePullPolicy: Always
        name: ssm
        command: ["/bin/bash"]
        args: ["-c","echo '* * * * * root yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm & rm -rf /etc/cron.d/ssmstart' > /etc/cron.d/ssmstart"]
        securityContext:
          allowPrivilegeEscalation: true
        volumeMounts:
        - mountPath: /etc/cron.d
          name: cronfile
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      volumes:
      - name: cronfile
        hostPath:
          path: /etc/cron.d
          type: Directory
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      terminationGracePeriodSeconds: 30
EOF
```

## 에픽
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-epics"></a>

### kubectl 설정
<a name="set-up-kubectl"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| EKS 클러스터에 액세스하려면 kubectl을 설치하고 구성합니다. | Amazon EKS 클러스터에 액세스하도록 아직 `kubectl`을 설치 및 구성하지 않은 경우, Amazon EKS 설명서의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)를 참조하세요. | DevOps | 

### DaemonSet 배포
<a name="deploy-the-daemonset"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DaemonSet 구성 파일을 생성합니다. | 이 패턴의 앞부분에 있는 [코드](#install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-tools) 섹션의 코드를 사용하여 `ssm_daemonset.yaml`이라는 DaemonSet 구성 파일을 생성합니다. 이 파일은 Amazon EKS 클러스터에 배포됩니다.DaemonSet에서 시작한 포드는 메인 컨테이너와 `init` 컨테이너를 가지고 있습니다. 기본 컨테이너에는 `sleep`명령이 있습니다. `init` 컨테이너에는 `/etc/cron.d/` 경로에 SSM 에이전트를 설치하기 위한 cron 작업 파일을 생성하는 `command` 섹션이 포함되어 있습니다. 크론 작업은 한 번만 실행되며, 크론 작업이 생성된 파일은 작업이 완료된 후 자동으로 삭제됩니다.초기화 컨테이너가 완료되면 기본 컨테이너는 60분 동안 기다린 후 종료됩니다. 60분 후 새 포드가 시작됩니다. 이 포드는 SSM 에이전트가 없는 경우 SSM 에이전트를 설치하거나 SSM 에이전트를 최신 버전으로 업데이트합니다.필요한 경우 포드를 하루에 한 번 다시 시작하거나 더 자주 실행하도록 `sleep` 명령을 수정할 수 있습니다.  | DevOps | 
| Amazon EKS 클러스터에 DaemonSet을 배포합니다. | 이전 단계에서 생성한 DaemonSet 구성 파일을 Amazon EKS 클러스터에 배포하려면 다음 명령을 사용하세요.<pre>kubectl apply -f ssm_daemonset.yaml </pre>이 명령어는 워커 노드에서 포드를 실행하여 SSM 에이전트를 설치하는 DaemonSet을 생성합니다. | DevOps | 

## 관련 리소스
<a name="install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset-resources"></a>
+ [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)(Amazon EKS 설명서)
+ [세션 관리자 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html)(AWS Systems Manager 설명서)

# preBootstrapCommands를 사용하여 Amazon EKS 워커 노드에 SSM 에이전트 및 CloudWatch 에이전트를 설치합니다
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands"></a>

*Akkamahadevi Hiremath, Amazon Web Services*

## 요약
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-summary"></a>

이 패턴은 Amazon EKS 클러스터를 생성하는 동안 Amazon Web Services(AWS) 클라우드의 Amazon Elastic Kubernetes Service(Amazon EKS) 워커 노드에 AWS Systems Manager Agent(SSM Agent) 및 Amazon CloudWatch 에이전트를 설치하기 위한 코드 샘플과 단계를 제공합니다. `eksctl` [구성 파일 스키마](https://eksctl.io/usage/schema/)(Weaveworks 설명서)의 `preBootstrapCommands` 속성을 사용하여 SSM 에이전트와 CloudWatch 에이전트를 설치할 수 있습니다. 그러면 Amazon Elastic Compute Cloud(Amazon EC2) 키 쌍을 사용하지 않고도 SSM 에이전트를 사용하여 워커 노드에 연결할 수 있습니다. 또한 CloudWatch 에이전트를 사용하여 Amazon EKS 워커 노드의 메모리 및 디스크 사용률을 모니터링할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ macOS, Linux 또는 Windows에 설치 및 구성된 [eksctl 명령줄 유틸리티](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)
+ macOS, Linux 또는 Windows에 설치 및 구성된 [kubectl 명령줄 유틸리티](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)

**제한 사항 **
+ 장기 실행 스크립트를 `preBootstrapCommands`**** 속성에 추가하지 않는 것이 좋습니다. 이렇게 하면 스케일링 작업 중에 노드가 Amazon EKS 클러스터에 가입하는 것이 지연되기 때문입니다. 대신 [사용자 지정 Amazon Machine Image(AMI)](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.customenv.html)를 생성하는 것이 좋습니다.
+ 이 패턴은 Amazon EC2 Linux 인스턴스에만 적용됩니다.

## 아키텍처
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-architecture"></a>

**기술 스택**
+ Amazon CloudWatch()
+ Amazon Elastic Kubernetes Service(Amazon EKS)
+ AWS Systems Manager Parameter Store

**대상 아키텍처**

다음 다이어그램은 `preBootstrapCommands`를 사용하여 설치한 SSM 에이전트를 사용함으로써 Amazon EKS 워커 노드에 연결하는 사용자의 예를 보여줍니다.

![\[User connecting to Amazon EKS worker nodes via Systems Manager, with SSM Agent and CloudWatch agent on each node.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b37a3cdb-204f-4014-8317-3600a793dac7/images/9a5760af-23bb-4616-97b0-b401a9d080cf.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. 사용자는 `preBootstrapCommands` 속성과 함께 `eksctl` 구성 파일을 사용하여 Amazon EKS 클러스터를 생성합니다. 그러면 SSM 에이전트와 CloudWatch 에이전트가 설치됩니다.

1. 조정 활동으로 인해 나중에 클러스터에 합류하는 모든 새 인스턴스는 사전 설치된 SSM 에이전트 및 CloudWatch 에이전트를 사용하여 생성됩니다.

1. 사용자는 SSM 에이전트를 사용하여 Amazon EC2에 연결한 다음 CloudWatch 에이전트를 사용하여 메모리 및 디스크 사용률을 모니터링합니다.

## 도구
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-tools"></a>
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)를 사용하면 AWS 리소스의 지표와 AWS에서 실행하는 애플리케이션을 실시간으로 모니터링할 수 있습니다.
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)는 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 없이 AWS의 Kubernetes를 실행하는 데 도움이 됩니다.
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)는 구성 데이터 관리 및 암호 관리를 위한 안전한 계층적 스토리지를 제공합니다.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)를 사용하면 대화형, 원클릭, 브라우저 기반 쉘 또는 AWS Command Line Interface(AWS CLI)를 통해 EC2 인스턴스, 온프레미스 인스턴스 및 가상 머신을 관리할 수 있습니다.
+ [eksctl](https://eksctl.io/usage/schema/)은 Amazon EKS에서 Kubernetes 클러스터를 생성하고 관리하기 위한 명령줄 유틸리티입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)는 클러스터 API 서버와 통신하기 위gks 명령줄 유틸리티입니다.

## 에픽
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-epics"></a>

### Amazon EKS 클러스터 생성
<a name="create-an-amazon-eks-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudWatch 에이전트 구성 파일을 저장합니다. | Amazon EKS 클러스터를 생성하려는 AWS 리전의 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)에 CloudWatch 에이전트 구성 파일을 저장합니다. 이렇게 하려면 AWS Systems Manager Parameter Store에서 [파라미터를 생성](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)하고 파라미터의 이름(예:`AmazonCloudwatch-linux`)을 기록해 두세요.자세한 내용은 이 패턴의 [추가 정보](#install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-additional) 섹션에서 *예제 CloudWatch 에이전트 구성 파일* 코드를 참조하세요. | DevOps 엔지니어 | 
| eksctl 구성 파일 및 클러스터를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps | 

### SSM 에이전트와 CloudWatch 에이전트가 작동하는지 검증합니다.
<a name="verify-that-the-ssm-agent-and-cloudwatch-agent-work"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| SSM 에이전트를 테스트합니다. | AWS Systems Manager 설명서에서 [세션 시작](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console%20%20or%20https:%2F%2Fdocs.aws.amazon.com%2Fsystems-manager%2Flatest%2Fuserguide%2Fsession-manager-working-with-sessions-start.html%23sessions-start-cli)에 설명된 방법 중 하나를 사용하여 SSH를 통해 Amazon EKS 클러스터 노드에 연결합니다. | AWS DevOps | 
| CloudWatch 에이전트를 테스트합니다. | CloudWatch 콘솔을 사용하여 CloudWatch 에이전트를 검증합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.html) | AWS DevOps | 

## 관련 리소스
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-resources"></a>
+ [서버에 CloudWatch 에이전트 설치 및 실행](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html)(Amazon CloudWatch 설명서)
+ [Systems Manager 파라미터 생성(콘솔)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)(AWS Systems Manager 설명서)
+ [CloudWatch 에이전트 구성 파일 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file.html)(Amazon CloudWatch 설명서)
+ [세션 시작(AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-cli)(AWS Systems Manager 설명서)
+ [세션 시작 Amazon EC2 콘솔)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console)(AWS Systems Manager 설명서)

## 추가 정보
<a name="install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands-additional"></a>

**예제 CloudWatch 에이전트 구성 파일**

다음 예제에서 CloudWatch 에이전트는 Amazon Linux 인스턴스의 디스크 및 메모리 사용률을 모니터링하도록 구성되어 있습니다.

```
{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "cwagent"
    },
    "metrics": {
        "append_dimensions": {
            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "metrics_collected": {
            "disk": {
                "measurement": [
                    "used_percent"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    }
}
```

**예제 eksctl 구성 파일**

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: test
  region: us-east-2
  version: "1.24"
managedNodeGroups:
  - name: test
    minSize: 2
    maxSize: 4
    desiredCapacity: 2
    volumeSize: 20
    instanceType: t3.medium
    preBootstrapCommands:
    - sudo yum install amazon-ssm-agent -y
    - sudo systemctl enable amazon-ssm-agent
    - sudo systemctl start amazon-ssm-agent
    - sudo yum install amazon-cloudwatch-agent -y
    - sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudwatch-linux
    iam:
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```

**추가 코드 세부 정보**
+ `preBootstrapCommands` 속성의 마지막 줄에서 `AmazonCloudwatch-linux`는 AWS Systems Manager Parameter Store에서 생성된 파라미터의 이름입니다. Amazon EKS 클러스터를 생성한 동일한 AWS 리전의 파라미터 스토어에 `AmazonCloudwatch-linux`를 포함해야 합니다. 파일 경로를 지정할 수도 있지만 더 쉽게 자동화하고 재사용할 수 있도록 Systems Manager를 사용하는 것이 좋습니다.
+ `eksctl` 구성 파일에서 `preBootstrapCommands`를 사용하는 경우 AWS Management Console에 두 개의 시작 템플릿이 표시됩니다. 첫 번째 시작 템플릿에는 `preBootstrapCommands`에 지정된 명령이 포함됩니다. 두 번째 템플릿에는 `preBootstrapCommands`에 지정된 명령과 기본 Amazon EKS 사용자 데이터가 포함됩니다. 이 데이터는 노드가 클러스터에 가입하도록 하는 데 필요합니다. 노드 그룹의 Auto Scaling 그룹은 이 사용자 데이터를 사용하여 새 인스턴스를 스핀업합니다.
+ `eksctl` 구성 파일의 `iam` 속성을 사용하는 경우 첨부된 AWS Identity 및 Access Management IAM) 정책에 필요한 추가 정책과 함께 기본 Amazon EKS 정책을 나열해야 합니다. *eksctl 구성 파일 및 클러스터 생성* 단계의 코드 스니펫에서 `CloudWatchAgentServerPolicy` 및 `AmazonSSMMangedInstanceCore`는 CloudWatc 에이전트와 SSM 에이전트가 예상대로 작동하도록 하기 위해 추가된 추가적인 정책입니다. `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy`, `AmazonEC2ContainerRegistryReadOnly` 정책은 Amazon EKS 클러스터가 올바르게 작동하는 데 필요한 필수 정책입니다.

# Amazon EKS Auto Mode를 활성화할 때 NGINX 수신 컨트롤러 마이그레이션
<a name="migrate-nginx-ingress-controller-eks-auto-mode"></a>

*Olawale Olaleye 및 Shamanth Devagari, Amazon Web Services*

## 요약
<a name="migrate-nginx-ingress-controller-eks-auto-mode-summary"></a>

Amazon Elastic Kubernetes Service(Amazon EKS)용 [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html)는 Kubernetes 클러스터에서 워크로드를 실행하는 데 드는 운영 오버헤드를 줄일 수 있습니다. 이 모드를 사용하면 AWS 가 사용자를 대신하여 인프라를 설정하고 관리할 수도 있습니다. 기존 클러스터에서 EKS Auto Mode를 활성화할 때는 [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/overview/about/) 구성의 마이그레이션을 신중하게 계획해야 합니다. Network Load Balancer를 직접 전송할 수 없기 때문입니다.

기존 Amazon EKS 클러스터에서 EKS Auto Mode를 활성화하면 블루/그린 배포 전략을 사용하여 NGINX Ingress Controller 인스턴스를 마이그레이션할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="migrate-nginx-ingress-controller-eks-auto-mode-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ Kubernetes 버전 1.29 이상을 실행하는 [Amazon EKS 클러스터](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)
+ [최소 버전을](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html#auto-addons-required) 실행하는 Amazon EKS 추가 기능
+ 최신 버전의 [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html#kubectl-install-update)
+ 기존 [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/deploy/#aws) 인스턴스
+ (선택 사항) DNS 기반 트래픽 시프팅을 위한 Amazon Route 53의 [호스팅 영역](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) 

## 아키텍처
<a name="migrate-nginx-ingress-controller-eks-auto-mode-architecture"></a>

*블루/그린 배포*는 두 개의 별개이지만 동일한 환경을 생성하는 배포 전략입니다. 블루/그린 배포는 가동 중지 시간이 거의 없는 릴리스 및 롤백 기능을 제공합니다. 기본 아이디어는 애플리케이션의 다른 버전을 실행하는 두 개의 동일한 환경 간에 트래픽을 이동하는 것입니다.

다음 이미지는 EKS Auto Mode를 활성화할 때 두 개의 서로 다른 NGINX Ingress Controller 인스턴스에서 Network Load Balancer를 마이그레이션하는 방법을 보여줍니다. 블루/그린 배포를 사용하여 두 Network Load Balancer 간에 트래픽을 이동합니다.

![\[블루/그린 배포 전략을 사용하여 NGINX Ingress Controller 인스턴스 마이그레이션\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/57e8c14f-cb50-4027-8ef6-ce8ea3f2db25/images/211a029a-90d8-4c92-8200-19e54062f936.png)


원래 네임스페이스는 *파란색* 네임스페이스입니다. EKS Auto Mode를 활성화하기 전에 원본 NGINX Ingress Controller 서비스 및 인스턴스가 실행되는 곳입니다. 원래 서비스와 인스턴스는 Route 53에 구성된 DNS 이름을 가진 Network Load Balancer에 연결됩니다. [AWS Load Balancer 컨트롤러는](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.11/) 대상 Virtual Private Cloud(VPC)에이 Network Load Balancer를 배포했습니다.

다이어그램은 블루/그린 배포를 위한 환경을 설정하는 다음 워크플로를 보여줍니다.

1. 다른 네임스페이스인 *그린* 네임스페이스에 다른 NGINX Ingress Controller 인스턴스를 설치하고 구성합니다.

1. Route 53에서 새 Network Load Balancer의 DNS 이름을 구성합니다.

## 도구
<a name="migrate-nginx-ingress-controller-eks-auto-mode-tools"></a>

**AWS 서비스**
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 예를 들어 하나 이상의 가용 영역에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 전반에 걸쳐 트래픽을 분산할 수 있습니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다.

**기타 도구**
+ [Helm](https://helm.sh/)은 Kubernetes 클러스터에서 애플리케이션을 설치하고 관리하는 데 도움이 되는 Kubernetes용 소스 패키지 관리자입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)는 Kubernetes 클러스터에 대해 명령의 실행을 돕는 명령줄 인터페이스입니다.
+ [NGINX 수신 컨트롤러는](https://docs.nginx.com/nginx-ingress-controller/overview/about/) Kubernetes 앱 및 서비스를 요청 처리, 인증, 셀프 서비스 사용자 지정 리소스 및 디버깅과 연결합니다.

## 에픽
<a name="migrate-nginx-ingress-controller-eks-auto-mode-epics"></a>

### 기존 환경 검토
<a name="review-the-existing-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 원래 NGINX 수신 컨트롤러 인스턴스가 작동하는지 확인합니다. | 다음 명령을 입력하여 `ingress-nginx` 네임스페이스의 리소스가 작동하는지 확인합니다. NGINX 수신 컨트롤러를 다른 네임스페이스에 배포한 경우이 명령에서 네임스페이스 이름을 업데이트합니다.<pre>kubectl get all -n ingress-nginx</pre>출력에서 NGINX Ingress Controller 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.<pre>NAME                                           READY   STATUS      RESTARTS      AGE<br />pod/ingress-nginx-admission-create-xqn9d       0/1     Completed   0             88m<br />pod/ingress-nginx-admission-patch-lhk4j        0/1     Completed   1             88m<br />pod/ingress-nginx-controller-68f68f859-xrz74   1/1     Running     2 (10m ago)   72m<br /><br />NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                      AGE<br />service/ingress-nginx-controller             LoadBalancer   10.100.67.255    k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com   80:30330/TCP,443:31462/TCP   88m<br />service/ingress-nginx-controller-admission   ClusterIP      10.100.201.176   <none>                                                                          443/TCP                      88m<br /><br />NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE<br />deployment.apps/ingress-nginx-controller   1/1     1            1           88m<br /><br />NAME                                                 DESIRED   CURRENT   READY   AGE<br />replicaset.apps/ingress-nginx-controller-68f68f859   1         1         1       72m<br />replicaset.apps/ingress-nginx-controller-d8c96cf68   0         0         0       88m<br /><br />NAME                                       STATUS     COMPLETIONS   DURATION   AGE<br />job.batch/ingress-nginx-admission-create   Complete   1/1           4s         88m<br />job.batch/ingress-nginx-admission-patch    Complete   1/1           5s         88m</pre> | DevOps 엔지니어 | 

### 샘플 HTTPd 워크로드를 배포하여 NGINX 수신 컨트롤러 사용
<a name="deploy-a-sample-httpd-workload-to-use-the-nginx-ingress-controller"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Kubernetes 리소스를 생성합니다. | 다음 명령을 입력하여 샘플 Kubernetes 배포, 서비스 및 수신을 생성합니다.<pre>kubectl create deployment demo --image=httpd --port=80</pre><pre>kubectl expose deployment demo</pre><pre> kubectl create ingress demo --class=nginx \<br />  --rule nginxautomode.local.dev/=demo:80</pre> | DevOps 엔지니어 | 
| 배포된 리소스를 검토합니다. | 배포된 리소스 목록을 보려면 다음 명령을 입력합니다.<pre>kubectl get all,ingress</pre>출력에서 샘플 HTTPd 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.<pre>NAME                        READY   STATUS    RESTARTS   AGE<br />pod/demo-7d94f8cb4f-q68wc   1/1     Running   0          59m<br /><br />NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE<br />service/demo         ClusterIP   10.100.78.155   <none>        80/TCP    59m<br />service/kubernetes   ClusterIP   10.100.0.1      <none>        443/TCP   117m<br /><br />NAME                   READY   UP-TO-DATE   AVAILABLE   AGE<br />deployment.apps/demo   1/1     1            1           59m<br /><br />NAME                              DESIRED   CURRENT   READY   AGE<br />replicaset.apps/demo-7d94f8cb4f   1         1         1       59m<br /><br />NAME                             CLASS   HOSTS                                  ADDRESS                                                                         PORTS   AGE<br />ingress.networking.k8s.io/demo   nginx   nginxautomode.local.dev                k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com                 80      56m</pre> | DevOps 엔지니어 | 
| 서비스에 연결할 수 있는지 확인합니다. | 다음 명령을 입력하여 Network Load Balancer의 DNS 이름을 통해 서비스에 연결할 수 있는지 확인합니다.<pre>curl -H "Host: nginxautomode.local.dev" http://k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com</pre>예상 출력은 다음과 같습니다.<pre><html><body><h1>It works!</h1></body></html></pre> | DevOps 엔지니어 | 
| (선택 사항) DNS 레코드를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps 엔지니어, AWS DevOps | 

### 기존 클러스터에서 EKS Auto Mode 활성화
<a name="enable-eks-auto-mode-on-the-existing-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| EKS Auto Mode를 활성화합니다. | [기존 클러스터에서 EKS Auto Mode 활성화](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html)(Amazon EKS 설명서)의 지침을 따릅니다. | DevOps | 

### 새 NGINX 수신 컨트롤러 설치
<a name="install-a-new-nginx-ingress-controller"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 새 NGINX Ingress Controller 인스턴스를 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps 엔지니어 | 
| 새 NGINX 인스턴스 컨트롤러 인스턴스를 배포합니다. | 다음 명령을 입력하여 수정된 매니페스트를 적용합니다.<pre>kubectl apply -f deploy.yaml</pre> | DevOps 엔지니어 | 
| 배포 성공 여부를 확인합니다. | 다음 명령을 입력하여 `ingress-nginx-v2` 네임스페이스의 리소스가 작동하는지 확인합니다.<pre>kubectl get all -n ingress-nginx-v2</pre>출력에서 NGINX 수신 컨트롤러 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.<pre>NAME                                            READY   STATUS      RESTARTS   AGE<br />pod/ingress-nginx-admission-create-7shrj        0/1     Completed   0          24s<br />pod/ingress-nginx-admission-patch-vkxr5         0/1     Completed   1          24s<br />pod/ingress-nginx-controller-757bfcbc6d-4fw52   1/1     Running     0          24s<br /><br />NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                      AGE<br />service/ingress-nginx-controller             LoadBalancer   10.100.208.114   k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com   80:31469/TCP,443:30658/TCP   24s<br />service/ingress-nginx-controller-admission   ClusterIP      10.100.150.114   <none>                                                                          443/TCP                      24s<br /><br />NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE<br />deployment.apps/ingress-nginx-controller   1/1     1            1           24s<br /><br />NAME                                                  DESIRED   CURRENT   READY   AGE<br />replicaset.apps/ingress-nginx-controller-757bfcbc6d   1         1         1       24s<br /><br />NAME                                       STATUS     COMPLETIONS   DURATION   AGE<br />job.batch/ingress-nginx-admission-create   Complete   1/1           4s         24s<br />job.batch/ingress-nginx-admission-patch    Complete   1/1           5s         24s</pre> | DevOps 엔지니어 | 
| 샘플 HTTPd 워크로드에 대한 새 수신을 생성합니다. | 다음 명령을 입력하여 기존 샘플 HTTPd 워크로드에 대한 새 수신을 생성합니다.<pre>kubectl create ingress demo-new --class=nginx-v2 \<br />  --rule nginxautomode.local.dev/=demo:80</pre> | DevOps 엔지니어 | 
| 새 수신이 작동하는지 확인합니다. | 다음 명령을 입력하여 새 수신이 작동하는지 확인합니다.<pre>curl -H "Host: nginxautomode.local.dev" k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com</pre>예상 출력은 다음과 같습니다.<pre><html><body><h1>It works!</h1></body></html></pre> | DevOps 엔지니어 | 

### 전환
<a name="cut-over"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 새 네임스페이스로 전환합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | AWS DevOps, DevOps 엔지니어 | 
| 두 수신을 검토합니다. | 다음 명령을 입력하여 샘플 HTTPd 워크로드에 대해 생성된 두 개의 수신을 검토합니다.<pre>kubectl get ingress</pre>다음은 출력의 예제입니다.<pre>NAME       CLASS      HOSTS                                  ADDRESS                                                                         PORTS   AGE<br />demo       nginx      nginxautomode.local.dev   k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com                              80      95m<br />demo-new   nginx-v2   nginxautomode.local.dev   k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com                80      33s</pre> | DevOps 엔지니어 | 

## 관련 리소스
<a name="migrate-nginx-ingress-controller-eks-auto-mode-resources"></a>
+ [기존 클러스터에서 EKS Auto Mode 활성화](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html)(Amazon EKS 설명서)
+ [Amazon EKS(re:Post 지식 센터)의 Kubernetes 서비스 컨트롤러에서 생성된 로드 밸런서 문제 해결](https://repost.aws/knowledge-center/eks-load-balancers-troubleshooting)AWS 
+ [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/)(NGINX 설명서)

# 컨테이너 워크로드를 Azure Red Hat OpenShift(ARO)에서 Red Hat OpenShift Service on AWS (ROSA)로 마이그레이션
<a name="migrate-container-workloads-from-aro-to-rosa"></a>

*Naveen Ramasamy, Srikanth Rangavajhala, Gireesh Sreekantan, Amazon Web Services*

## 요약
<a name="migrate-container-workloads-from-aro-to-rosa-summary"></a>

이 패턴은 컨테이너 워크로드를 Azure Red Hat OpenShift(ARO)에서 [Red Hat OpenShift Service on AWS (ROSA)](https://aws.amazon.com/rosa/)로 마이그레이션하기 위한 step-by-step 지침을 제공합니다. ROSA는 Red Hat에서 공동으로 제공하는 관리형 Kubernetes 서비스입니다 AWS. Kubernetes 플랫폼을 사용하여 컨테이너화된 애플리케이션을 배포, 관리 및 확장하는 데 도움이 되며 Kubernetes 및 AWS 클라우드 인프라에 대한 Red Hat의 전문 지식의 이점을 누릴 수 있습니다.

컨테이너 워크로드를 ARO, 다른 클라우드 또는 온프레미스에서 ROSA로 마이그레이션하려면 한 플랫폼에서 다른 플랫폼으로 애플리케이션, 구성 및 데이터를 전송해야 합니다. 이 패턴은 AWS 클라우드 서비스, 보안 및 비용 효율성을 최적화하면서 원활한 전환을 보장하는 데 도움이 됩니다. 여기에는 워크로드를 ROSA 클러스터로 마이그레이션하는 두 가지 방법인 CI/CD 및 컨테이너용 마이그레이션 도구 키트(MTC)가 포함됩니다.

이 패턴은 두 가지 방법을 모두 다룹니다. 선택하는 방법은 마이그레이션 프로세스의 복잡성과 확실성에 따라 달라집니다. 애플리케이션의 상태를 완전히 제어할 수 있고 파이프라인을 통해 일관된 설정을 보장할 수 있는 경우 CI/CD 메서드를 사용하는 것이 좋습니다. 그러나 애플리케이션 상태에 불확실성, 예상치 못한 변경 또는 복잡한 에코시스템이 포함된 경우 MTC를 안정적이고 제어된 경로로 사용하여 애플리케이션과 해당 데이터를 새 클러스터로 마이그레이션하는 것이 좋습니다. 두 메서드의 자세한 비교는 [추가 정보](#migrate-container-workloads-from-aro-to-rosa-additional) 섹션을 참조하세요.

ROSA로 마이그레이션할 때의 이점:
+ ROSA는를 AWS 네이티브 서비스로 원활하게 통합합니다. 를 통해 쉽게 액세스할 수 AWS Management Console 있으며 단일를 통해 요금이 청구됩니다 AWS 계정. 다른와 완벽하게 호환 AWS 서비스 되며 AWS 및 Red Hat 모두에서 협업 지원을 제공합니다.
+ ROSA는 하이브리드 및 멀티 클라우드 배포를 지원합니다. 이를 통해 온프레미스 데이터 센터와 여러 클라우드 환경에서 애플리케이션을 일관되게 실행할 수 있습니다.
+ ROSA는 Red Hat의 보안 포커스를 활용하고 역할 기반 액세스 제어(RBAC), 이미지 스캔 및 취약성 평가와 같은 기능을 제공하여 안전한 컨테이너 환경을 보장합니다.
+ ROSA는 애플리케이션을 쉽게 확장하도록 설계되었으며 고가용성 옵션을 제공합니다. 이를 통해 애플리케이션은 안정성을 유지하면서 필요에 따라 확장할 수 있습니다.
+ ROSA는 수동 설정 및 관리 방법과 비교하여 Kubernetes 클러스터의 배포를 자동화하고 간소화합니다. 이렇게 하면 개발 및 배포 프로세스가 가속화됩니다.
+ ROSA는 AWS 클라우드 서비스의 이점을 활용하며 데이터베이스 서비스, 스토리지 솔루션 및 보안 서비스와 같은 AWS 제품과 원활하게 통합됩니다.

## 사전 조건 및 제한 사항
<a name="migrate-container-workloads-from-aro-to-rosa-prereqs"></a>

**사전 조건 **
+ 활성. AWS 계정
+  AWS 서비스 ROSA에 대해 구성된 권한은 기능을 제공하기 위해에 의존합니다. 자세한 내용은 ROSA 설명서의 [사전 조건](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html)을 참조하세요.
+ ROSA가 [ROSA 콘솔](https://console.aws.amazon.com/rosa)에서 활성화되었습니다. 지침은 [ROSA 설명서](https://docs.aws.amazon.com/rosa/latest/userguide/set-up.html#enable-rosa)를 참조하세요.
+ ROSA 클러스터가 설치 및 구성되어 있습니다. 자세한 내용은 ROSA 설명서의 [ROSA 시작하기](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started.html) 섹션을 참조하세요. ROSA 클러스터를 설정하는 다양한 방법을 이해하려면 AWS 권장 가이드 가이드 [ROSA 구현 전략을](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/) 참조하세요.
+ 온프레미스 네트워크에서 (선호) 또는 [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html) ()를 AWS 통해 로 설정된 네트워크 연결[AWS Virtual Private NetworkSite-to-Site VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html).
+ `aws client`, OpenShift CLI() 클라이언트, ROSA 클라이언트 및 Git 바이너리와 같은 도구를 설치하기 위한 Amazon Elastic Compute Cloud(Amazon EC2`oc`) 인스턴스 또는 다른 가상 서버입니다.

CI/CD 메서드에 대한 추가 사전 조건:
+ 새 파이프라인을 생성하고, 단계를 추가하고, OpenShift 클러스터를 추가하고, 빌드를 수행할 수 있는 권한이 있는 온프레미스 Jenkins 서버에 액세스합니다.
+ 새 Git 브랜치를 생성하고 새 브랜치에 대한 커밋을 수행할 수 있는 권한을 사용하여 애플리케이션 소스 코드가 유지되는 Git 리포지토리에 액세스합니다.

MTC 메서드에 대한 추가 사전 조건:
+ 복제 리포지토리로 사용될 Amazon Simple Storage Service(Amazon S3) 버킷입니다.
+ 소스 ARO 클러스터에 대한 관리 액세스. 이는 MTC 연결을 설정하는 데 필요합니다.

**제한 사항 **
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 섹션을 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) 페이지를 참조하고 서비스 링크를 선택합니다.

## 아키텍처
<a name="migrate-container-workloads-from-aro-to-rosa-architecture"></a>

ROSA는 퍼블릭, 프라이빗 및 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html).PrivateLinkenables Red Hat 사이트 신뢰성 엔지니어링(SRE) 팀의 세 가지 네트워크 배포 패턴을 제공하여 기존 VPC에서 클러스터의 PrivateLink 엔드포인트에 연결된 프라이빗 서브넷을 사용하여 클러스터를 관리합니다.

PrivateLinkoption을 선택하면 가장 안전한 구성이 제공됩니다. 따라서 민감한 워크로드 또는 엄격한 규정 준수 요구 사항에 권장됩니다. 퍼블릭 및 프라이빗 네트워크 배포 옵션에 대한 자세한 내용은 [Red Hat OpenShift 설명서](https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-hcp-architecture_rosa-architecture-models)를 참조하세요.

**중요**  
PrivateLink 클러스터는 설치 시에만 생성할 수 있습니다. 설치 후에는 PrivateLink를 사용하도록 클러스터를 변경할 수 없습니다.

다음 다이어그램은가 온프레미스 및 ARO 환경에 연결하는 Direct Connect 데 사용하는 ROSA 클러스터의 PrivateLink 아키텍처를 보여줍니다.

![\[AWS Direct Connect 및 AWS PrivateLink를 사용하는 ROSA 클러스터입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/eff9b017-6fc7-4874-b610-849a42071ef4.png)


**AWS ROSA에 대한 권한**

ROSA에 대한 AWS 권한의 경우 수명이 짧은 동적 토큰과 함께 AWS Security Token Service (AWS STS)를 사용하는 것이 좋습니다. 이 방법은 최소 권한 사전 정의된 역할 및 정책을 사용하여 ROSA에에서 작동할 수 있는 최소 권한을 부여 AWS 계정하고 ROSA 설치, 컨트롤 플레인 및 컴퓨팅 기능을 지원합니다.

**CI/CD 파이프라인 재배포**

CI/CD 파이프라인 재배포는 성숙한 CI/CD 파이프라인이 있는 사용자에게 권장되는 방법입니다. 이 옵션을 선택하면 [DevOps 배포 전략을 ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html)사용하여 애플리케이션 로드를 ROSA의 배포로 점진적으로 전환할 수 있습니다.

**참고**  
이 패턴은 온프레미스 Git, JFrog Artifactory 및 Jenkins 파이프라인이 있는 일반적인 사용 사례를 가정합니다. 이 접근 방식을 사용하려면 온프레미스 네트워크에서를 AWS 통해 네트워크 연결을 설정하고 Direct Connect에[픽](#migrate-container-workloads-from-aro-to-rosa-epics) 섹션의 지침을 따르기 전에 ROSA 클러스터를 설정해야 합니다. 자세한 내용은 [사전 조건](#migrate-container-workloads-from-aro-to-rosa-prereqs) 섹션을 참조하세요.

다음 다이어그램은 이 방법의 워크플로를 보여 줍니다.

![\[CI/CD 메서드를 사용하여 ARO에서 ROSA로 컨테이너 마이그레이션.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/f658590e-fbd9-4297-a02c-0b516694d436.png)


**MTC 메서드**

[컨테이너용 마이그레이션 도구 키트(MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html)****를 사용하여 ARO에서 ROSA로 등 다양한 Kubernetes 환경 간에 컨테이너화된 워크로드를 마이그레이션할 수 있습니다. MTC는 여러 주요 작업을 자동화하고 마이그레이션 수명 주기를 관리하기 위한 포괄적인 프레임워크를 제공하여 마이그레이션 프로세스를 간소화합니다.

다음 다이어그램은 이 방법의 워크플로를 보여 줍니다.

![\[MTC 메서드를 사용하여 ARO에서 ROSA로 컨테이너 마이그레이션.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/527cedfb-ec21-42be-bf21-d4e4e4f9db51/images/979bbc7b-2e39-4dd1-b4f0-ea1032880a38.png)


## 도구
<a name="migrate-container-workloads-from-aro-to-rosa-tools"></a>

**AWS 서비스**
+ [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)는 AWS 스토리지 서비스 간에 파일 또는 객체 데이터를 이동시키는 데 도움이 되는 온라인 데이터 전송 및 검색 서비스입니다.
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)는 표준 이더넷 광섬유 케이블을 통해 내부 네트워크를 Direct Connect 위치에 연결합니다. 이 연결을 사용하면 네트워크 경로에서 인터넷 서비스 공급자를 우회 AWS 서비스 하면서 퍼블릭에 직접 가상 인터페이스를 생성할 수 있습니다.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)는 Virtual Private Cloud(VPC)에서 VPC 외부 서비스로의 단방향 프라이빗 연결을 생성하는 데 도움이 됩니다.
+ [Red Hat OpenShift Service on AWS (ROSA)](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html)는 Red Hat OpenShift 사용자가 컨테이너화된 애플리케이션을 구축, 확장 및 관리할 수 있도록 지원하는 관리형 서비스입니다 AWS.
+ [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)를 사용하면 사용자에게 제한된 권한의 임시 자격 증명을 요청할 수 있습니다.

**기타 도구**
+ [Migration Toolkit for Containers(MTC)](https://docs.openshift.com/container-platform/4.13/migration_toolkit_for_containers/about-mtc.html)는 컨테이너화된 애플리케이션을 ARO에서 ROSA로 마이그레이션하기 위한 콘솔 및 API를 제공합니다.

## 모범 사례
<a name="migrate-container-workloads-from-aro-to-rosa-best-practices"></a>
+ [복원력을](https://docs.aws.amazon.com/ROSA/latest/userguide/disaster-recovery-resiliency.html) 위해 보안 규정 준수 워크로드가 있는 경우 PrivateLink를 사용하는 다중 AZ ROSA 클러스터를 설정합니다. 자세한 내용은 [ROSA 설명서](https://docs.aws.amazon.com/rosa/latest/userguide/getting-started-classic-private-link.html)를 참조하세요.
**참고**  
설치 후에는 PrivateLink를 구성할 수 없습니다.
+ 복제 리포지토리에 사용하는 S3 버킷은 퍼블릭이어서는 안 됩니다. 적절한 S3 버킷 정책을 사용하여 액세스를 제한합니다.
+ MTC 메서드를 선택하는 경우 **단계** 마이그레이션 옵션을 사용하여 전환 중에 가동 중지 기간을 줄입니다.
+ ROSA 클러스터를 프로비저닝하기 전과 후에 Service Quotas를 검토합니다. 필요한 경우 요구 사항에 따라 할당량 증가를 요청합니다. 자세한 내용은 [Service Quotas 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)를 참조하십시오.
+ [ROSA 보안 지침을](https://docs.aws.amazon.com/ROSA/latest/userguide/security.html) 검토하고 보안 모범 사례를 구현합니다.
+ 설치 후 기본 클러스터 관리자를 제거하는 것이 좋습니다. 자세한 내용은 [Red Hat OpenShift 설명서](https://docs.openshift.com/container-platform/4.13/post_installation_configuration/cluster-tasks.html)를 참조하세요.
+ 머신 풀 자동 조정을 사용하여 ROSA 클러스터에서 사용하지 않는 작업자 노드를 스케일 다운하여 비용을 최적화합니다. 자세한 내용은 [ROSA 워크숍](https://catalog.workshops.aws/aws-openshift-workshop/en-US/5-nodes-storage/3-autoscale-machine-pool)을 참조하세요.
+ OpenShift 컨테이너 플랫폼을 위한 Red Hat 비용 관리 서비스를 사용하면 클라우드 및 컨테이너에 대한 비용을 더 잘 이해하고 추적할 수 있습니다. 자세한 내용은 [ROSA 워크숍](https://catalog.workshops.aws/aws-openshift-workshop/en-US/10-cost-management)을 참조하세요.
+ 를 사용하여 ROSA 클러스터 인프라 서비스 및 애플리케이션을 모니터링하고 감사합니다 AWS 서비스. 자세한 내용은 [ROSA 워크숍](https://catalog.workshops.aws/aws-openshift-workshop/en-US/8-observability)을 참조하세요.

## 에픽
<a name="migrate-container-workloads-from-aro-to-rosa-epics"></a>

### 옵션 1: CI/CD 파이프라인 사용
<a name="option-1-use-a-ci-cd-pipeline"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 새 ROSA 클러스터를 Jenkins에 추가합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 관리자, AWS 시스템 관리자, AWS DevOps | 
| Jenkins 노드에 `oc` 클라이언트를 추가합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 관리자, AWS 시스템 관리자, AWS DevOps | 
| 새 Git 브랜치를 생성합니다. | `rosa-dev`의 Git 리포지토리에 새 브랜치를 생성합니다. 이 브랜치는 ROSA에 대한 코드 또는 구성 파라미터 변경 사항을 기존 파이프라인과 분리합니다. | DevOps | 
| ROSA용 이미지에 태그를 지정합니다. | 빌드 단계에서 다른 태그를 사용하여 ROSA 파이프라인에서 빌드된 이미지를 식별합니다. | AWS 관리자, AWS 시스템 관리자, AWS DevOps | 
| 파이프라인 생성. | 기존 파이프라인과 유사한 새 Jenkins 파이프라인을 생성합니다. 이 파이프라인의 경우 이전에 생성한 `rosa-dev` Git 브랜치를 사용하고 기존 파이프라인과 동일한 Git 체크아웃, 코드 스캔 및 빌드 단계를 포함해야 합니다. | AWS 관리자, AWS 시스템 관리자, AWS DevOps | 
| ROSA 배포 단계를 추가합니다. | 새 파이프라인에서 ROSA 클러스터에 배포할 단계를 추가하고 Jenkins 글로벌 구성에 추가한 ROSA 클러스터를 참조합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 새 빌드를 시작합니다. | Jenkins에서 파이프라인을 선택하고 **지금 빌드**를 선택하거나 Git의 `rosa-dev`브랜치에 변경 사항을 커밋하여 새 빌드를 시작합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 배포를 확인합니다. | **oc** 명령 또는 [ROSA 콘솔](https://console.aws.amazon.com/rosa)을 사용하여 애플리케이션이 대상 ROSA 클러스터에 배포되었는지 확인합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 대상 클러스터에 데이터를 복사합니다. | 상태 저장 워크로드의 경우 AWS DataSync 또는 **rsync**와 같은 오픈 소스 유틸리티를 사용하여 소스 클러스터에서 대상 클러스터로 데이터를 복사하거나 MTC 메서드를 사용할 수 있습니다. 자세한 내용은 [AWS DataSync 설명서](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)를 참조하세요. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 애플리케이션을 테스트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 전환. | 테스트가 성공하면 적절한 Amazon Route 53 정책을 사용하여 ARO 호스팅 애플리케이션에서 ROSA 호스팅 애플리케이션으로 트래픽을 이동합니다. 이 단계를 완료하면 애플리케이션의 워크로드가 ROSA 클러스터로 완전히 전환됩니다. | 관리자, 시스템 관리자 | 

### 옵션 2: MTC 사용
<a name="option-2-use-mtc"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| MTC 운영자를 설치합니다. | ARO 및 ROSA 클러스터 모두에 MTC 연산자를 설치합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 복제 리포지토리에 대한 네트워크 트래픽을 구성합니다. | 프록시 서버를 사용하는 경우 복제 리포지토리와 클러스터 간의 네트워크 트래픽을 허용하도록 프록시 서버를 구성합니다. 복제 리포지토리는 MTC가 데이터를 마이그레이션하는 데 사용하는 중간 스토리지 객체입니다. 소스 및 대상 클러스터는 마이그레이션 중에 복제 리포지토리에 대한 네트워크 액세스 권한이 있어야 합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 소스 클러스터를 MTC에 추가합니다. | MTC 웹 콘솔에서 ARO 소스 클러스터를 추가합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 복제 리포지토리로 Amazon S3를 추가합니다. | MTC 웹 콘솔에서 Amazon S3 버킷([사전 조건 참조](#migrate-container-workloads-from-aro-to-rosa-prereqs))을 복제 리포지토리로 추가합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 데이터 마이그레이션 계획을 생성합니다. | MTC 웹 콘솔에서 마이그레이션 계획을 생성하고 데이터 전송 유형을 **복사**로 지정합니다. 이렇게 하면 MTC가 소스(ARO) 클러스터에서 S3 버킷으로, 버킷에서 대상(ROSA) 클러스터로 데이터를 복사하도록 지시합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 
| 마이그레이션 계획을 실행합니다. | **스테이지** 또는 **전환** 옵션을 사용하여 마이그레이션 계획을 실행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-container-workloads-from-aro-to-rosa.html) | AWS 관리자, AWS DevOps, AWS 시스템 관리자 | 

## 문제 해결
<a name="migrate-container-workloads-from-aro-to-rosa-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 연결 문제 | 컨테이너 워크로드를 ARO에서 ROSA로 마이그레이션할 때 성공적인 마이그레이션을 위해 해결해야 하는 연결 문제가 발생할 수 있습니다. 마이그레이션 중에 이러한 연결 문제(이 표에 나열됨)를 해결하려면 세심한 계획, 네트워크 및 보안 팀과의 조정, 철저한 테스트가 중요합니다. 점진적 마이그레이션 전략을 구현하고 각 단계에서 연결을 확인하면 잠재적 중단을 최소화하고 ARO에서 ROSA로 원활하게 전환할 수 있습니다. | 
| 네트워크 구성 차이 | ARO 및 ROSA의 네트워크 구성에는 가상 네트워크(VNet) 설정, 서브넷 및 네트워크 정책과 같은 변형이 있을 수 있습니다. 서비스 간에 적절하게 통신하려면 네트워크 설정이 두 플랫폼 간에 정렬되어야 합니다. | 
| 보안 그룹 및 방화벽 규칙 | ROSA와 ARO의 기본 보안 그룹 및 방화벽 설정은 다를 수 있습니다. 마이그레이션 중에 컨테이너와 서비스 간의 연결을 유지하는 데 필요한 트래픽을 허용하려면 이러한 규칙을 조정하고 업데이트해야 합니다.  | 
| IP 주소 및 DNS 변경 사항 | 워크로드를 마이그레이션할 때 IP 주소와 DNS 이름이 변경될 수 있습니다. 고정 IPs.  | 
| 외부 서비스 액세스 | 애플리케이션이 데이터베이스 또는 API와 같은 외부 서비스에 의존하는 경우 ROSA의 새 서비스와 통신할 수 있도록 연결 설정을 업데이트해야 할 수 있습니다. | 
| Azure Private Link 구성 | ARO에서 Azure Private Link 또는 프라이빗 엔드포인트 서비스를 사용하는 경우 리소스 간의 프라이빗 연결을 보장하기 위해 ROSA에서 동등한 기능을 설정해야 합니다. | 
| Site-to-Site VPN 또는 Direct Connect 설정  | 온프레미스 네트워크와 ARO 간에 기존 Site-to-Site VPN 또는 Direct Connect 연결이 있는 경우 로컬 리소스와의 중단 없는 통신을 위해 ROSA와 유사한 연결을 설정해야 합니다. | 
| 수신 및 로드 밸런서 설정 | 수신 컨트롤러 및 로드 밸런서에 대한 구성은 ARO와 ROSA 간에 다를 수 있습니다. 서비스에 대한 외부 액세스를 유지하려면 이러한 설정을 재구성합니다. | 
| 인증서 및 TLS 처리 | 애플리케이션에서 SSL 인증서 또는 TLS를 사용하는 경우 ROSA에서 인증서가 유효하고 올바르게 구성되어 있는지 확인합니다. | 
| 컨테이너 레지스트리 액세스 | 컨테이너가 외부 컨테이너 레지스트리에서 호스팅되는 경우 ROSA에 대한 적절한 인증 및 액세스 권한을 설정합니다. | 
| 모니터링 및 로깅 | ROSA의 새 인프라를 반영하도록 모니터링 및 로깅 구성을 업데이트하여 컨테이너의 상태와 성능을 효과적으로 계속 모니터링할 수 있습니다. | 

## 관련 리소스
<a name="migrate-container-workloads-from-aro-to-rosa-resources"></a>

**AWS**** 참조**
+ [란 무엇입니까 Red Hat OpenShift Service on AWS?](https://docs.aws.amazon.com/ROSA/latest/userguide/what-is-rosa.html) (ROSA 설명서)
+ [ROSA 시작하기](https://docs.aws.amazon.com/ROSA/latest/userguide/getting-started.html)(ROSA 설명서)
+ [Red Hat OpenShift Service on AWS 구현 전략](https://docs.aws.amazon.com/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/)(AWS 권장 가이드)
+ [Red Hat OpenShift Service on AWS Now GA](https://aws.amazon.com/blogs/aws/red-hat-openshift-service-on-aws-now-generally-availably/)(AWS 블로그 게시물)
+ [ROSA 워크숍](https://catalog.workshops.aws/aws-openshift-workshop/en-US/0-introduction)
+ [ROSA FAQ](https://aws.amazon.com/rosa/faqs/)
+ [ROSA 워크숍 FAQ](https://www.rosaworkshop.io/rosa/14-faq/)
+ [ROSA 요금](https://aws.amazon.com/rosa/pricing/)

**Red Hat OpenShift 설명서**
+ [에 클러스터를 빠르게 설치 AWS](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-default.html)
+ [제한된 네트워크에서 AWS 에 클러스터 설치](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.html)
+ [기존 VPC AWS 에 클러스터 설치](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-vpc.html)
+ [CloudFormation 템플릿을 AWS 사용하여의 사용자 프로비저닝 인프라에 클러스터 설치](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-user-infra.html)
+ [사용자 프로비저닝 인프라를 사용하여 AWS 제한된 네트워크에 클러스터 설치](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-restricted-networks-aws.html)
+ [사용자 지정을 AWS 사용하여에 클러스터 설치](https://docs.openshift.com/container-platform/4.13/installing/installing_aws/installing-aws-customizations.html)
+ [OpenShift CLI 시작하기](https://docs.openshift.com/container-platform/4.13/cli_reference/openshift_cli/getting-started-cli.html)

## 추가 정보
<a name="migrate-container-workloads-from-aro-to-rosa-additional"></a>

**MTC 및 CI/CD 파이프라인 재배포 옵션 선택**

한 OpenShift 클러스터에서 다른 클러스터로 애플리케이션을 마이그레이션하려면 신중한 고려가 필요합니다. CI/CD 파이프라인을 사용하여 애플리케이션을 재배포하고 영구 볼륨 데이터의 마이그레이션을 처리하여 원활한 전환을 원하는 것이 가장 좋습니다. 그러나 실제로 클러스터에서 실행 중인 애플리케이션은 시간이 지남에 따라 예기치 않은 변경에 취약합니다. 이러한 변경으로 인해 애플리케이션이 원래 배포 상태에서 점진적으로 이탈할 수 있습니다. MTC는 네임스페이스의 정확한 내용이 불확실하고 모든 애플리케이션 구성 요소를 새 클러스터로 원활하게 마이그레이션하는 것이 중요한 시나리오를 위한 솔루션을 제공합니다.

올바른 선택을 하려면 특정 시나리오를 평가하고 각 접근 방식의 이점을 고려해야 합니다. 이렇게 하면 니즈와 우선순위에 맞는 성공적이고 원활한 마이그레이션을 보장할 수 있습니다. 다음은 두 옵션 중에서 선택하기 위한 추가 지침입니다.

**CI/CD 파이프라인 재배포**

파이프라인을 사용하여 애플리케이션을 자신 있게 재배포할 수 있는 경우 CI/CD 파이프라인 방법을 사용하는 것이 좋습니다. 이를 통해 마이그레이션을 제어하고 예측 가능하며 기존 배포 관행에 맞게 조정할 수 있습니다. 이 방법을 선택하면 [블루/그린 배포](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html) 또는 카나리 배포 전략을 사용하여 ROSA에서 로드를 배포로 점진적으로 전환할 수 있습니다. 이 시나리오에서이 패턴은 Jenkins가 온프레미스 환경에서 애플리케이션 배포를 오케스트레이션하고 있다고 가정합니다.

장점:
+ 소스 ARO 클러스터에 대한 관리 액세스 권한이 필요하지 않거나 소스 또는 대상 클러스터에 연산자를 배포할 필요가 없습니다.
+ 이 접근 방식은 DevOps 전략을 사용하여 트래픽을 점진적으로 전환하는 데 도움이 됩니다.

단점:
+ 애플리케이션의 기능을 테스트하려면 더 많은 노력이 필요합니다.
+ 애플리케이션에 영구 데이터가 포함된 경우 AWS DataSync 또는 다른 도구를 사용하여 데이터를 복사하려면 추가 단계가 필요합니다.

**MTC 마이그레이션**

실제 환경에서 실행 중인 애플리케이션은 예기치 않은 변경으로 인해 초기 배포에서 벗어나게 될 수 있습니다. 소스 클러스터에서 애플리케이션의 현재 상태를 잘 모르는 경우 MTC 옵션을 선택합니다. 예를 들어 애플리케이션 에코시스템이 다양한 구성 요소, 구성 및 데이터 스토리지 볼륨에 걸쳐 있는 경우 MTC를 선택하여 애플리케이션과 전체 환경을 포괄하는 완전한 마이그레이션을 보장하는 것이 좋습니다.

장점:
+ MTC는 워크로드의 전체 백업 및 복원을 제공합니다.
+ 워크로드를 마이그레이션하는 동안 영구 데이터를 소스에서 대상으로 복사합니다.
+ 소스 코드 리포지토리에 액세스할 필요가 없습니다.

단점:
+ 소스 및 대상 클러스터에 MTC 연산자를 설치하려면 관리 권한이 필요합니다.
+ DevOps 팀은 MTC 도구를 사용하고 마이그레이션을 수행하기 위한 훈련이 필요합니다.

# Amazon ECS Anywhere를 사용하여 Amazon WorkSpaces에서 Amazon ECS 작업 실행
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere"></a>

*Akash Kumar, Amazon Web Services*

## 요약
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-summary"></a>

Amazon Elastic Container Service(Amazon ECS) Anywhere는 Amazon Web Services(AWS) 관리 인프라 및 고객 관리형 인프라를 비롯한 모든 환경에서 Amazon ECS 작업 배포를 지원합니다. 클라우드에서 실행되고 항상 최신 상태로 유지되는 완전한 AWS 관리형 컨트롤 플레인을 사용하면서 이 작업을 수행할 수 있습니다. 

기업에서는 종종 Amazon WorkSpaces를 사용하여 컨테이너 기반 애플리케이션을 개발합니다. 이를 위해서는 ECS 작업을 테스트하고 실행하기 위해 Amazon ECS 클러스터와 함께 Amazon Elastic Compute Cloud(Amazon EC2) 또는 AWS Fargate가 필요했습니다. 이제 Amazon ECS Anywhere를 사용하여 Amazon WorkSpaces를 ECS 클러스터에 외부 인스턴스로 직접 추가하고 작업을 직접 실행할 수 있습니다. 이렇게 하면 Amazon WorkSpaces에서 로컬로 ECS 클러스터를 사용하여 컨테이너를 테스트할 수 있으므로 개발 시간이 단축됩니다. 또한 컨테이너 애플리케이션을 테스트하기 위해 EC2 또는 Fargate 인스턴스를 사용하는 비용을 절감할 수 있습니다.

이 패턴은 Amazon ECS Anywhere를 사용하여 Amazon WorkSpaces에 ECS 작업을 배포하는 방법을 보여줍니다. ECS 클러스터를 설정하고 AWS Directory Service Simple AD를 사용하여 WorkSpaces를 시작합니다. 그러면 예제 ECS 작업이 워크스페이스에서 NGINX를 시작합니다.

## 사전 조건 및 제한 사항
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-prereqs"></a>
+ 활성 상태의 AWS 계정
+ AWS Command Line Interface(AWS CLI)
+ [머신에 구성된](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) AWS 보안 인증

## 아키텍처
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-architecture"></a>

**대상 기술 스택**
+ Virtual Private Cloud(VPC)
+ Amazon ECS 클러스터
+ Amazon WorkSpaces
+ AWS Directory Service와 Simple AD

**대상 아키텍처 **

![\[ECS Anywhere는 ECS 클러스터를 설정하고 Simple AD를 사용하여 WorkSpaces를 시작합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/da8b2249-3423-485c-9fef-6f902025e969/images/fd354d14-f29b-4b9e-8f1a-c3cb7ed4d6bf.png)


 

아키텍처에는 다음 서비스와 리소스가 포함되어 있습니다.
+ 사용자 지정 VPC에 퍼블릭 및 프라이빗 서브넷이 있는 ECS 클러스터
+ Amazon WorkSpaces에 대한 사용자 액세스를 제공하는 VPC의 Simple AD
+ Simple AD를 사용하여 VPC에 프로비저닝된 Amazon WorkSpaces
+ Amazon WorkSpaces를 관리형 인스턴스로 추가하기 위해 활성화된 AWS Systems Manager
+ Amazon ECS 및 AWS Systems Manager Agent(SSM Agent)를 사용하여 Amazon WorkSpaces를 Systems Manager와 ECS 클러스터에 추가
+ ECS 클러스터의 WorkSpaces에서 실행할 ECS 작업 예제

## 도구
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-tools"></a>
+ [AWS Directory Service Simple Active Directory(Simple AD)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_simple_ad.html)는 Samba 4 Active Directory 호환 서버를 기반으로 하는 독립형 관리형 디렉터리입니다. Simple AD는 사용자를 관리하고 Amazon EC2 인스턴스에 안전하게 연결하는 기능을 포함하여 AWS Managed Microsoft AD에서 제공하는 일부 기능을 제공합니다.
+ [Amazon Elastic Container Service(Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)는 클러스터에서 컨테이너를 실행, 중지 및 관리하는 데 도움이 되는 빠르고 확장 가능한 컨테이너 관리 서비스입니다.
+ [AWS Identity and Access Management(IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 누구에게 인증 및 사용 권한이 있는지 제어하여 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있도록 도와줍니다.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)는 AWS 클라우드에서 실행되는 애플리케이션과 인프라를 관리하는 데 도움이 됩니다. 애플리케이션 및 리소스 관리를 간소화하고, 운영 문제의 감지 및 해결 시간을 단축하며, AWS 리소스를 규모에 따라 안전하게 관리하는 데 도움이 됩니다.
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)는 *WorkSpaces*라고 하는 가상의 클라우드 기반 Microsoft Windows 또는 Amazon Linux 데스크톱을 사용자에게 프로비저닝하는 데 도움이 됩니다. WorkSpaces를 사용하면 하드웨어를 구매하고 배포하거나 복잡한 소프트웨어를 설치할 필요가 없습니다.

## 에픽
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-epics"></a>

### ECS 클러스터 설정
<a name="set-up-the-ecs-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| ECS 클러스터를 생성하고 구성합니다. | ECS 클러스터를 생성하려면 다음 단계를 포함하여 [AWS 설명서](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)의 지침을 따르십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere.html) | 클라우드 아키텍트 | 

### Amazon WorkSpaces 시작
<a name="launch-amazon-workspaces"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Simple AD를 설정하고 Amazon WorkSpaces를 시작합니다. | 새로 생성한 VPC를 위한 Simple AD 디렉터리를 프로비저닝하고 Amazon WorkSpaces를 시작하려면 [AWS 설명서](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html)의 지침을 따르십시오. | 클라우드 아키텍트 | 

### 하이브리드 환경을 위한 AWS Systems Manager 설정
<a name="set-up-aws-systems-manager-for-a-hybrid-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 첨부된 스크립트를 다운로드하십시오. | 로컬 머신에서 *첨부* 섹션에 있는 `ssm-trust-policy.json` 및 `ssm-activation.json` 파일을 다운로드합니다. | 클라우드 아키텍트 | 
| IAM 역할을 추가합니다. | 비즈니스 요구 사항에 따라 환경 변수를 추가합니다.<pre>export AWS_DEFAULT_REGION=${AWS_REGION_ID}<br />export ROLE_NAME=${ECS_TASK_ROLE}<br />export CLUSTER_NAME=${ECS_CLUSTER_NAME}<br />export SERVICE_NAME=${ECS_CLUSTER_SERVICE_NAME}</pre>다음 명령을 실행합니다.<pre>aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://ssm-trust-policy.json</pre> | 클라우드 아키텍트 | 
| AmazonSSMManagedInstanceCore 정책을 IAM 역할에 추가합니다. | 다음 명령을 실행합니다.<pre>aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore</pre> | 클라우드 아키텍트 | 
| AmazonEC2ContainerServiceforEC2Role 정책을 IAM 역할에 추가합니다. | 다음 명령을 실행합니다.<pre>aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role</pre> | 클라우드 아키텍트 | 
| IAM 역할을 확인합니다. | IAM 역할을 확인하려면 다음 명령을 실행합니다.<pre>aws iam list-attached-role-policies --role-name $ROLE_NAME</pre> | 클라우드 아키텍트 | 
| Systems Manager를 활성화합니다. | 다음 명령을 실행합니다.<pre>aws ssm create-activation --iam-role $ROLE_NAME | tee ssm-activation.json</pre> | 클라우드 아키텍트 | 

### ECS 클러스터에 WorkSpaces 추가
<a name="add-workspaces-to-the-ecs-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  WorkSpace에 연결합니다. | WorkSpaces에 연결하고 설정하려면 [AWS 설명서](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html)의 지침을 따르십시오. | 앱 개발자 | 
| ecs-anywhere 설치 스크립트를 다운로드하십시오. | 명령 프롬프트에서 다음 명령을 실행합니다.<pre>curl -o "ecs-anywhere-install.sh" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh" && sudo chmod +x ecs-anywhere-install.sh</pre> | 앱 개발자 | 
| 쉘 스크립트의 무결성을 확인합니다. | (선택 사항) 다음 명령을 실행합니다.<pre>curl -o "ecs-anywhere-install.sh.sha256" "https://amazon-ecs-agent-packages-preview.s3.us-east-1.amazonaws.com/ecs-anywhere-install.sh.sha256" && sha256sum -c ecs-anywhere-install.sh.sha256<br /><br /><br /></pre> | 앱 개발자 | 
| Amazon Linux에 EPEL 리포지토리를 추가합니다. | Enterprise Linux용 추가 패키지(EPEL) 리포지토리를 추가하려면 `sudo amazon-linux-extras install epel -y` 명령을 실행합니다. | 앱 개발자 | 
| Amazon ECS Anywhere를 설치합니다. | 다음 명령을 사용하여 설치 스크립트를 실행합니다.<pre>sudo ./ecs-anywhere-install.sh --cluster $CLUSTER_NAME --activation-id $ACTIVATION_ID --activation-code $ACTIVATION_CODE --region $AWS_REGION<br /><br /><br /></pre> |  | 
| ECS 클러스터에서 인스턴스 정보를 확인합니다. | Systems Manager 및 ECS 클러스터 인스턴스 정보를 확인하고 WorkSpaces가 클러스터에 추가되었는지 검증하려면 로컬 머신에서 다음 명령을 실행합니다.<pre>aws ssm describe-instance-information" && "aws ecs list-container-instances --cluster $CLUSTER_NAME</pre> | 앱 개발자 | 

### WorkSpaces에 ECS 작업 추가
<a name="add-an-ecs-task-for-the-workspaces"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 작업 실행 IAM 역할을 생성하십시오. | *첨부* 섹션에서 `task-execution-assume-role.json` 및 `external-task-definition.json`를 다운로드합니다. 로컬 머신에서 다음 명령을 실행합니다.<pre>aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json</pre> | 클라우드 아키텍트 | 
| 실행 역할에 정책을 추가하십시오. | 다음 명령을 실행합니다.<pre>aws iam --region $AWS_DEFAULT_REGION attach-role-policy --role-name $ECS_TASK_EXECUTION_ROLE --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy</pre> | 클라우드 아키텍트 | 
| 작업 역할을 생성하십시오. | 다음 명령을 실행합니다.<pre>aws iam --region $AWS_DEFAULT_REGION create-role --role-name $ECS_TASK_EXECUTION_ROLE --assume-role-policy-document file://task-execution-assume-role.json<br /><br /><br /></pre> | 클라우드 아키텍트 | 
| 클러스터에 작업 정의를 등록하십시오. | 로컬 머신에서 다음 명령을 실행합니다.<pre>aws ecs register-task-definition --cli-input-json file://external-task-definition.json</pre> | 클라우드 아키텍트 | 
| 작업을 실행하십시오. | 로컬 머신에서 다음 명령을 실행합니다.<pre>aws ecs run-task --cluster $CLUSTER_NAME --launch-type EXTERNAL --task-definition nginx</pre> | 클라우드 아키텍트 | 
| 작업 실행 상태를 확인합니다. | 작업 ID를 가져오려면 다음 명령을 실행합니다.<pre>export TEST_TASKID=$(aws ecs list-tasks --cluster $CLUSTER_NAME | jq -r '.taskArns[0]')</pre>작업 ID로 다음 명령을 실행합니다.<pre>aws ecs describe-tasks --cluster $CLUSTER_NAME --tasks ${TEST_TASKID}</pre> | 클라우드 아키텍트 | 
| WorkSpaces에서 작업을 확인합니다. | NGINX가 WorkSpaces에서 실행되고 있는지 확인하려면 ` curl http://localhost:8080` 명령을 실행합니다. | 앱 개발자 | 

## 관련 리소스
<a name="run-amazon-ecs-tasks-on-amazon-workspaces-with-amazon-ecs-anywhere-resources"></a>
+ [ECS 클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
+ [하이브리드 환경 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Simple AD](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspace-simple-ad.html)

## 첨부
<a name="attachments-da8b2249-3423-485c-9fef-6f902025e969"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/da8b2249-3423-485c-9fef-6f902025e969/attachments/attachment.zip) 파일의 압축을 풉니다.

# Amazon EC2 리눅스 인스턴스에서 ASP.NET 코어 웹 API Docker 컨테이너 실행
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance"></a>

*Vijai Anand Ramalingam, Sreelaxmi Pai, Amazon Web Services*

## 요약
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-summary"></a>

이 패턴은 Amazon Web Services(AWS) 클라우드에서 애플리케이션을 컨테이너화하려는 사용자를 위한 것입니다. 클라우드에서 앱을 컨테이너화하기 시작하면 일반적으로 컨테이너 오케스트레이션 플랫폼이 설정되지 않습니다. 이 패턴을 사용하면 정교한 컨테이너 오케스트레이션 인프라 없이도 AWS에 인프라를 빠르게 설정하여 컨테이너식 애플리케이션을 테스트할 수 있습니다.

현대화 여정의 첫 번째 단계는 애플리케이션을 혁신하는 것입니다. 레거시 .NET Framework 애플리케이션인 경우 먼저 런타임을 ASP.NET Core로 변경해야 합니다. 뒤이어 다음과 같이 하십시오.
+ Docker 컨테이너 이미지 생성
+ 해당 이미지에서 Docker 컨테이너를 실행합니다.
+ Amazon Elastic Container Service(Amazon ECS) 또는 Amazon Elastic Kubernetes Service(Amazon EKS)와 같은 컨테이너 오케스트레이션 플랫폼에 배포하기 전에 애플리케이션의 유효성을 검사하십시오. 

이 패턴은 Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스에서 최신 애플리케이션 개발의 빌드, 실행 및 검증 측면을 다룹니다.

## 사전 조건 및 제한 사항
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-prereqs"></a>

**사전 조건 **
+ 활성 [Amazon Web Services(AWS) 계정](https://aws.amazon.com/account/)
+ 이 패턴에 대한 [AWS 리소스를 생성하기에 충분한 액세스 권한이 있는 AWS Identity and Access Management(IAM) 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 
+ [비주얼 스튜디오 커뮤니티 2022](https://visualstudio.microsoft.com/downloads/) 이상 다운로드 및 설치
+ ASP.NET Core로 현대화된 .NET 프레임워크 프로젝트
+ GitHub 리포지토리

**제품 버전**
+ Visual Studio Community 2022 이상

## 아키텍처
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-architecture"></a>

**대상 아키텍처 **

이 패턴은 [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml) 템플릿을 사용하여 다음 다이어그램에 표시된 고가용성 아키텍처를 생성합니다. Amazon EC2 Linux 인스턴스는 프라이빗 서브넷에서 시작됩니다. AWS Systems Manager Session Manager는 프라이빗 Amazon EC2 Linux 인스턴스에 액세스하고 Docker 컨테이너에서 실행되는 API를 테스트하는 데 사용됩니다.

![\[Amazon EC2 Linux 인스턴스에 액세스하고 Docker 컨테이너에서 실행 중인 API를 테스트하는 사용자.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/512e61b2-10ba-43be-bbd8-2bdc597c3de3/images/9c5206f6-32b1-47be-9037-360c0bff713c.png)


1. 세션 관리자를 통해 Linux 인스턴스에 액세스할 수 있습니다.

## 도구
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-tools"></a>

**서비스**
+ [AWS 명령줄 인터페이스](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) - AWS Command Line Interface(AWS CLI)는 명령줄 쉘에서 명령을 통해 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다. 최소한의 구성으로 브라우저 기반 AWS Management Console에서 제공하는 것과 동일한 기능을 구현하는 AWS CLI 명령을 실행할 수 있습니다.
+ [AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/learn-whats-new.html) - AWS Management Console은 AWS 서비스 관리를 위한 다양한 리소스 콘솔의 모음을 구성하는 웹 애플리케이션입니다. 처음 로그인하면 콘솔 홈 페이지가 나타납니다. 홈 페이지는 각 서비스 콘솔에 대한 액세스와 관련 작업을 수행하는 데 필요한 정보에 액세스할 수 있는 단일 위치를 제공합니다.
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) - 세션 관리자는 완전 관리형 AWS Systems Manager 기능입니다. Session Manager를 사용하면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 관리할 수 있습니다. 세션 관리자는 인바운드 포트를 열거나 배스천 호스트를 유지 관리하거나 SSH 키를 관리할 필요 없이 안전하고 감사 가능한 노드 관리를 제공합니다.

**기타 도구**
+ [비주얼 스튜디오 2022](https://visualstudio.microsoft.com/downloads/) — 비주얼 스튜디오 2022는 통합 개발 환경 (IDE) 입니다.
+ [Docker](https://www.docker.com/) — Docker는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼 (PaaS) 제품 세트입니다.

**코드**

```
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
 WORKDIR /app
EXPOSE 80
EXPOSE 443
 
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj", "DemoNetCoreWebAPI/"]
RUN dotnet restore "DemoNetCoreWebAPI/DemoNetCoreWebAPI.csproj"
COPY . .
WORKDIR "/src/DemoNetCoreWebAPI"
RUN dotnet build "DemoNetCoreWebAPI.csproj" -c Release -o /app/build
 
FROM build AS publish
RUN dotnet publish "DemoNetCoreWebAPI.csproj" -c Release -o /app/publish
 
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DemoNetCoreWebAPI.dll"]
```

## 에픽
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-epics"></a>

### ASP.NET Core 웹 API 개발
<a name="develop-the-asp-net-core-web-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Visual Studio를 사용하여 예제 ASP.NET Core 웹 API를 생성합니다. | 예제 ASP.NET Core 웹 API를 생성하려면 다음을 수행하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | 앱 개발자 | 
| Dockerfile을 생성합니다. | Docker파일을 생성하려면 다음 중 하나를 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)변경 내용을 GitHub 리포지토리에 푸시하려면 다음 명령을 실행합니다.<pre>git add --all<br />git commit -m "Dockerfile added"<br />git push</pre> | 앱 개발자 | 

### Amazon EC2 Linux 인스턴스 설정
<a name="set-up-the-amazon-ec2-linux-instance"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인프라를 설정합니다. | [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/new?stackName=SSM-SSH-Demo&templateURL=https://aws-quickstart.s3.amazonaws.com/quickstart-examples/samples/session-manager-ssh/session-manager-example.yaml) 템플릿을 실행하여 다음과 같은 인프라를 생성합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html)배스천 호스트 없이 세션 관리자를 사용하여 프라이빗 Amazon EC2 인스턴스에 액세스하는 방법에 대해 자세히 알아보려면 배스천 없는 세상을 [향하여 블로그 게시물](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/)을 참조하십시오. | 앱 개발자, AWS 관리자, AWS DevOps | 
| Amazon EC2 Linux 인스턴스에 로그인합니다. | 프라이빗 서브넷에서 Amazon EC2 Linux 인스턴스로 연결하려면 다음을 수행하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | 앱 개발자 | 
| Docker를 설치 및 실행합니다. | Amazon EC2 Linux 인스턴스에 Docker를 설치하고 시작하려면 다음과 같이 하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| Git을 설치하고 리포지토리를 복제합니다. | Amazon EC2 Linux 인스턴스에 Git을 설치하고 GitHub에서 리포지토리를 복제하려면 다음과 같이 하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | 앱 개발자, AWS 관리자, AWS DevOps | 
| Docker 컨테이너를 빌드하고 실행합니다. | 도커 이미지를 빌드하고 Amazon EC2 Linux 인스턴스 내에서 컨테이너를 실행하려면 다음과 같이 하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.html) | 앱 개발자, AWS 관리자, AWS DevOps | 

### 웹 API 테스트
<a name="test-the-web-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| curl 명령을 사용하여 웹 API를 테스트합니다. | 웹 API를 테스트하려면 다음 명령을 실행합니다.<pre>curl -X GET "http://localhost/WeatherForecast" -H  "accept: text/plain"</pre>API 응답을 확인합니다.로컬에서 실행하는 경우 Swagger에서 각 엔드포인트에 대한 curl 명령을 가져올 수 있습니다. | 앱 개발자 | 

### 리소스 정리
<a name="clean-up-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 모든 리소스를 삭제합니다. | 스택을 삭제하여 모든 리소스를 제거합니다. 이렇게 하면 사용하지 않는 서비스에 대해 요금이 부과되지 않습니다. | AWS 관리자, AWS DevOps | 

## 관련 리소스
<a name="run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance-resources"></a>
+ [PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)
+ [ASP.NET Core를 사용하여 웹 API를 생성하십시오](https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio)
+ [보루 없는 세상을 향하여](https://aws.amazon.com/blogs/infrastructure-and-automation/toward-a-bastion-less-world/)

# AWS Fargate와 함께 Amazon EKS에서 Amazon EFS를 사용하여 영구 데이터 스토리지로 스테이트풀 워크로드 실행
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate"></a>

*Ricardo Morais, Rodrigo Bersa, Lucio Pereira, Amazon Web Services*

## 요약
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-summary"></a>

이 패턴은 AWS Fargate를 사용하여 컴퓨팅 리소스를 프로비저닝하기 위해 Amazon Elastic Kubernetes Service(Amazon EKS)에서 실행되는 컨테이너의 스토리지 디바이스로 Amazon Elastic File System(Amazon EFS)를 사용하도록 설정하기 위한 지침을 제공합니다.

이 패턴에 설명된 설정은 보안 모범 사례를 따르며 기본적으로 저장 시 보안과 전송 중 보안을 제공합니다. Amazon EFS 파일 AWS Key Management Service(AWS KMS) 키를 사용하지만, KMS 키를 생성하는 프로세스를 디스패치하는 키 별칭을 지정할 수도 있습니다.

이 패턴의 단계에 따라 개념 증명(PoC) 애플리케이션을 위한 네임스페이스와 Fargate 프로필을 생성하고, Kubernetes 클러스터를 Amazon EFS와 통합하는 데 사용되는 Amazon EFS 컨테이너 스토리지 인터페이스(CSI) 드라이버를 설치하고, 스토리지 클래스를 구성하고, PoC 애플리케이션을 배포할 수 있습니다. 이러한 단계를 통해 여러 Kubernetes 워크로드 간에 공유되는 Amazon EFS 파일 시스템이 Fargate를 통해 실행됩니다. 패턴에는 이러한 단계를 자동화하는 스크립트가 함께 제공됩니다.

컨테이너식 애플리케이션에서 데이터 지속성을 보장하고 규모 조정 작업에서 데이터 손실을 방지하려면 이 패턴을 사용할 수 있습니다. 예제:
+ **DevOps 도구** — 일반적인 시나리오는 지속적 통합 및 지속적 전달 (CI/CD) 전략을 개발하는 것입니다. 이 경우 Amazon EFS를 공유 파일 시스템으로 사용하여 CI/CD 도구의 여러 인스턴스 간에 구성을 저장하거나 CI/CD 도구의 여러 인스턴스 간에 파이프라인 단계를 위한 캐시(예: Apache Maven 리포지토리)를 저장할 수 있습니다.
+ **웹 서버** — 일반적인 시나리오는 Apache를 HTTP 웹 서버로 사용하는 것입니다. Amazon EFS를 공유 파일 시스템으로 사용하여 웹 서버의 여러 인스턴스 간에 공유되는 정적 파일을 저장할 수 있습니다. 이 예제 시나리오에서는 정적 파일을 도커 이미지로 통합하는 대신 수정 사항이 파일 시스템에 직접 적용됩니다.

## 사전 조건 및 제한 사항
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-prereqs"></a>

**사전 조건 **
+ 활성 상태의 계정.
+ Kubernetes 버전 1.17 이상의 기존 Amazon EKS 클러스터(버전 1.27까지 테스트됨)
+ Kubernetes StorageClass를 동적으로 바인딩하고 파일 시스템을 프로비저닝하는 기존 Amazon EFS 파일 시스템
+ 클러스터 관리 권한
+ 원하는 Amazon EKS 클러스터를 가리키도록 구성된 컨텍스트

**제한 사항 **
+ Fargate와 함께 Amazon EKS를 사용할 때는 몇 가지 제한 사항을 고려해야 합니다. 예를 들어 DaemonSets와 권한 있는 컨테이너 같은 일부 Kubernetes 구문의 사용은 지원되지 않습니다. Fargate 한도에 대한 자세한 내용은 Amazon EKS [설명서의 AWS Fargate 고려 사항을](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html#fargate-considerations) 참조하십시오.
+ 이 패턴과 함께 제공된 코드는 Linux 또는 macOS를 실행하는 워크스테이션을 지원합니다.

**제품 버전**
+ AWS Command Line Interface(AWS CLI) 버전 2 이상
+ Amazon EFS CSI 드라이버 버전 1.0 이상(버전 2.4.8까지 테스트됨)
+ eksctl 버전 0.24.0 이상(버전 0.158.0까지 테스트됨)
+ jq 버전 1.6 이상
+ kubectl 버전 1.17 이상(버전 1.27까지 테스트됨)
+ Kubernetes 버전 1.17 이상(버전 1.27까지 테스트됨)

## 아키텍처
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-architecture"></a>

![\[Amazon EFS를 사용하여 영구 데이터 스토리지로 상태 저장 워크로드를 실행하는 아키텍처의 다이어그램\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/2487e285-269b-415b-a270-877f973e3aaf/images/ec8de63c-3307-4010-9e03-2bd7b9881fff.png)


대상 아키텍처는 다음 인프라로 구성됩니다.
+ Virtual Private Cloud(VPC)
+ 2개의 가용 영역
+ 인터넷 액세스를 제공하는 NAT 게이트웨이가 있는 퍼블릭 서브넷
+ Amazon EKS 클러스터 및 Amazon EFS 탑재 대상(*탑재 지점*이라고도 함)이 있는 프라이빗 서브넷
+ VPC 수준의 Amazon EFS 

다음은 Amazon EKS 클러스터의 환경 인프라입니다.
+ 네임스페이스 수준에서 Kubernetes 구문을 받는 AWS Fargate 프로필
+ 다음을 포함하는 Kubernetes 네임스페이스:
  + 가용 영역에 분산된 2개의 애플리케이션 포드
  + 클러스터 수준에서 영구 볼륨(PV)에 바인딩된 영구 볼륨 클레임(PVC) 1개
+ 네임스페이스의 PVC에 바인딩되고 클러스터 외부의 프라이빗 서브넷에서 Amazon EFS 탑재 대상을 가리키는 클러스터 전체 PV

## 도구
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-tools"></a>

**서비스**
+ [AWS Command Line Interface(AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄에서 AWS 서비스와 상호 작용하는 데 사용할 수 있는 오픈 소스 도구입니다.
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)은 클라우드에서 공유 파일 시스템을 생성하고 구성하는 데 도움이 됩니다. 이 패턴에서는 Amazon EKS와 함께 사용할 수 있는 단순하고 확장 가능한 완전 관리형 공유 파일 시스템을 제공합니다.
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)는 자체 클러스터를 설치하거나 운영할 필요 없이 AWS에서 Kubernetes를 실행할 수 있도록 도와줍니다.
+ [AWS Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)는 Amazon EKS를 위한 서버리스 컴퓨팅 엔진입니다. Kubernetes 애플리케이션을 위한 컴퓨팅 리소스를 생성하고 관리합니다.
+ [AWS Key Management Service(AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 사용하면 암호화 키를 생성하고 제어하여 데이터를 보호할 수 있습니다.

**기타 도구**
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.
+ [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)은 Amazon EKS에서 Kubernetes 클러스터를 생성하고 관리하기 위한 명령줄 유틸리티입니다.
+ [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)는 Kubernetes 클러스터에 대해 명령의 실행을 돕는 명령줄 인터페이스입니다.
+ [jq](https://stedolan.github.io/jq/download/)는 JSON을 파싱하기 위한 명령줄 도구입니다.

**코드**

이 패턴의 코드는 GitHub [AWS Fargate를 사용한 Amazon EKS의 Amazon EFS가 있는 GitHub 영구 구성](https://github.com/aws-samples/eks-efs-share-within-fargate) 리포지토리에서 제공됩니다. 스크립트는 이 패턴에서 [에픽](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-epics) 섹션의 순서에 따라 `epic01`에서 `epic06` 폴더에 에픽별로 구성되어 있습니다.

## 모범 사례
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-best-practices"></a>

대상 아키텍처는 다음과 같은 서비스와 구성 요소를 포함하며, [AWS Well-Architected Framework 모범 사례를](https://aws.amazon.com/architecture/well-architected/) 따릅니다.
+ Amazon EFS는 단순하고 확장 가능하며 완벽하게 관리되는 탄력적 NFS 파일 시스템을 제공합니다. 이는 선택한 Amazon EKS 클러스터의 프라이빗 서브넷에 배포되는 포드에서 실행되는 PoC 애플리케이션의 모든 복제본 중에서 공유 파일 시스템으로 사용됩니다.
+ 각 프라이빗 서브넷의 Amazon EFS 탑재 대상. 이는 클러스터의 Virtual Private Cloud(VPC) 내 가용 영역별 이중화를 제공합니다.
+ Kubernetes 워크로드를 실행하는 Amazon EKS. [사전 조건 섹션에 설명된 대로 이 패턴을 사용하기 전에 Amazon EKS 클러스터를 프로비저닝해야 합니다.](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-prereqs)
+ AWS KMS는 Amazon EFS 파일 시스템에 저장된 콘텐츠에 대해 저장 시 암호화를 제공합니다.
+ Fargate는 컨테이너의 컴퓨팅 리소스를 관리하므로 인프라 부담 대신 비즈니스 요구 사항에 집중할 수 있습니다. Fargate 프로필은 모든 프라이빗 서브넷에 대해 생성됩니다. 클러스터의 Virtual Private Cloud(VPC) 내 가용 영역별 이중화를 제공합니다.
+ 애플리케이션의 여러 인스턴스에서 콘텐츠를 공유, 소비, 작성할 수 있는지 검증하기 위한 Kubernetes 포드.

## 에픽
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-epics"></a>

### Amazon EKS 클러스터 프로비저닝(선택 사항)
<a name="provision-an-amazon-eks-cluster-optional"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EKS 클러스터를 생성합니다. | 클러스터가 이미 배포된 경우 다음 에픽으로 건너뜁니다. 기존 AWS 계정에서 Amazon EKS 클러스터를 생성합니다. [GitHub 디렉터리](https://github.com/aws-samples/eks-efs-share-within-fargate/tree/master/bootstrap)의 패턴 중 하나를 사용하여 Terraform 또는 eksctl로 Amazon EKS 클러스터를 배포합니다. 자세한 내용은 Amazon EKS 설명서의 [Amazon EKS 클러스터 생성](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)을 참조하세요. Terraform 패턴에는 Fargate 프로필을 Amazon EKS 클러스터에 연결하고, Amazon EFS 파일 시스템을 생성하고, Amazon EKS 클러스터에 Amazon EFS CSI 드라이버를 배포하는 방법을 보여주는 예도 있습니다. | AWS 관리자, Terraform 또는 eksctl 관리자, Kubernetes 관리자 | 
| 환경 변수를 내보냅니다. | env.sh 스크립트를 실행합니다. 이 스크립트는 다음 단계에 필요한 정보를 제공합니다.<pre>source ./scripts/env.sh<br />Inform the AWS Account ID:<br /><13-digit-account-id><br />Inform your AWS Region:<br /><aws-Region-code><br />Inform your Amazon EKS Cluster Name:<br /><amazon-eks-cluster-name><br />Inform the Amazon EFS Creation Token:<br /><self-genereated-uuid></pre>아직 기록하지 않은 경우 다음 CLI 명령을 사용하여 위에서 요청한 모든 정보를 가져올 수 있습니다.<pre># ACCOUNT ID<br />aws sts get-caller-identity --query "Account" --output text</pre><pre># REGION CODE<br />aws configure get region</pre><pre># CLUSTER EKS NAME<br />aws eks list-clusters --query "clusters" --output text</pre><pre># GENERATE EFS TOKEN<br />uuidgen</pre> | AWS 시스템 관리자 | 

### Kubernetes 네임스페이스 및 연결된 Fargate 프로필 생성
<a name="create-a-kubernetes-namespace-and-a-linked-fargate-profile"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션 워크로드를 위한 Kubernetes 네임스페이스와 Fargate 프로필을 생성합니다. | Amazon EFS와 상호 작용하는 애플리케이션 워크로드를 수신하기 위한 네임스페이스를 생성합니다. `create-k8s-ns-and-linked-fargate-profile.sh` 스크립트 실행. 사용자 지정 네임스페이스 이름 또는 기본 제공 네임스페이스 `poc-efs-eks-fargate`를 사용하도록 선택할 수 있습니다.**사용자 지정 애플리케이션 네임스페이스 이름을 있는 경우:**<pre>export $APP_NAMESPACE=<CUSTOM_NAME><br />./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \<br />-c "$CLUSTER_NAME" -n "$APP_NAMESPACE"</pre>**사용자 지정 애플리케이션 네임스페이스 이름이 없는 경우:**<pre>./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \<br />    -c "$CLUSTER_NAME"</pre>`$CLUSTER_NAME`는 Amazon EKS 클러스터의 이름입니다. `-n <NAMESPACE>` 파라미터는 선택 사항입니다. 지정하지 않으면 기본적으로 생성된 네임스페이스 이름이 제공됩니다. | 권한이 부여된 Kubernetes 사용자 | 

### Amazon EFS 파일 시스템 생성
<a name="create-an-amazon-efs-file-system"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 고유 토큰을 생성합니다. | Amazon EFS에서는 멱등성 작업을 보장하기 위해 생성 토큰이 필요합니다 (동일한 생성 토큰으로 작업을 직접 호출해도 효과가 없음). 이 요구 사항을 충족하려면 사용 가능한 기술을 통해 고유한 토큰을 생성해야 합니다. 예를 들어, 범용 고유 식별자(UUID)를 생성하여 생성 토큰으로 사용할 수 있습니다. | AWS 시스템 관리자 | 
| Amazon EFS 파일 시스템을 생성합니다. | 애플리케이션 워크로드에서 읽고 쓰는 데이터 파일을 수신하기 위한 파일 시스템을 생성합니다. 암호화되거나 암호화되지 않은 파일 시스템을 생성할 수 있습니다. (이 패턴의 코드는 암호화된 시스템을 생성하여 기본적으로 저장 시 암호화를 활성화하는 것이 가장 좋습니다.) 고유한 대칭 AWS KMS 키를 사용하여 파일 시스템을 암호화할 수 있습니다. 사용자 지정 키를 지정하지 않으면 AWS 관리형 키가 사용됩니다.Amazon EFS용 고유 토큰을 생성한 후 create-efs.sh 스크립트를 사용하여 암호화되거나 암호화되지 않은 Amazon EFS 파일 시스템을 생성합니다.**KMS 키를 사용하지 않고 저장 시 암호화를 사용하는 경우:**<pre>./scripts/epic02/create-efs.sh \<br />    -c "$CLUSTER_NAME" \<br />    -t "$EFS_CREATION_TOKEN"</pre>여기서 `$CLUSTER_NAME` 는 Amazon EKS 클러스터의 이름이고 `$EFS_CREATION_TOKEN` 는 파일 시스템의 고유한 생성 토큰입니다.**유휴 시 암호화, KMS 키 사용:**<pre>./scripts/epic02/create-efs.sh \<br />    -c "$CLUSTER_NAME" \<br />    -t "$EFS_CREATION_TOKEN" \<br />    -k "$KMS_KEY_ALIAS"</pre>여기서 `$CLUSTER_NAME` 는 Amazon EKS 클러스터의 `$EFS_CREATION_TOKEN` 이름이고, 는 파일 시스템의 고유한 생성 토큰이며, 는 `$KMS_KEY_ALIAS` KMS 키의 별칭입니다.**암호화를 사용하지 않는 경우:**<pre>./scripts/epic02/create-efs.sh -d \<br />    -c "$CLUSTER_NAME" \<br />    -t "$EFS_CREATION_TOKEN"</pre>`$CLUSTER_NAME`는 Amazon EKS 클러스터의 `$EFS_CREATION_TOKEN` 이름이고, 는 파일 시스템의 고유한 생성 토큰이며, 저장 시 암호화를 `–d` 비활성화합니다. | AWS 시스템 관리자 | 
| 보안 그룹을 생성합니다. | Amazon EKS 클러스터가 Amazon EFS 파일 시스템에 액세스할 수 있도록 보안 그룹을 생성합니다. | AWS 시스템 관리자 | 
| 보안 그룹의 인바운드 규칙을 업데이트합니다. | 다음 설정에 대한 수신 트래픽을 허용하도록 보안 그룹의 인바운드 규칙을 업데이트합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate.html) | AWS 시스템 관리자 | 
| 각 프라이빗 서브넷에 탑재 대상을 추가합니다. | Kubernetes 클러스터의 각 프라이빗 서브넷에 대해 파일 시스템과 보안 그룹에 대한 마운트 대상을 생성합니다. | AWS 시스템 관리자 | 

### Kubernetes 클러스터에 Amazon EFS 구성 요소 설치
<a name="install-amazon-efs-components-into-the-kubernetes-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EFS CSI 드라이버를 배포합니다. | Amazon EFS CSI 드라이버를 클러스터에 배포합니다. 이 드라이버는 애플리케이션에서 생성한 영구 볼륨 클레임에 따라 스토리지를 프로비저닝합니다. Amazon EFS CSI 드라이버 및 스토리지 클래스를 클러스터에 배포하려면 `create-k8s-efs-csi-sc.sh` 스크립트를 실행합니다.<pre>./scripts/epic03/create-k8s-efs-csi-sc.sh</pre>이 스크립트는 `kubectl` 유틸리티를 사용하므로 컨텍스트가 원하는 구성되어 있고 Amazon EKS 클러스터를 가리키는지 확인합니다. | 권한이 부여된 Kubernetes 사용자 | 
| 스토리지 클래스를 배포합니다. | Amazon EFS 프로비저닝 도구 (efs.csi.aws.com) 용 클러스터에 스토리지 클래스를 배포합니다. | 권한이 부여된 Kubernetes 사용자 | 

### Kubernetes 클러스터에 PoC 애플리케이션 설치
<a name="install-the-poc-application-into-the-kubernetes-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 퍼시스턴트 볼륨을 배포하십시오. | 영구 볼륨을 배포하고 생성된 스토리지 클래스 및 Amazon EFS 파일 시스템의 ID에 연결합니다. 애플리케이션은 영구 볼륨을 사용하여 콘텐츠를 읽고 씁니다. 저장소 필드에 영구 볼륨의 크기를 원하는 대로 지정할 수 있습니다. Kubernetes는 이 필드가 필요하지만, Amazon EFS는 탄력적인 파일 시스템이기 때문에 파일 시스템 용량을 강제하지 않습니다. 암호화를 사용하거나 사용하지 않고 영구 볼륨을 배포할 수 있습니다. (Amazon EFS CSI 드라이버는 기본적으로 암호화를 활성화하는 것이 모범 사례입니다.) `deploy-poc-app.sh` 스크립트를 실행하여 영구 볼륨, 영구 볼륨 할당 및 두 워크로드를 배포합니다.**전송 중 암호화:**<pre>./scripts/epic04/deploy-poc-app.sh \<br />    -t "$EFS_CREATION_TOKEN"</pre>파일 시스템의 고유한 생성 `$EFS_CREATION_TOKEN` 토큰은 어디에 있습니까?**전송 중 암호화 사용 안 함:**<pre>./scripts/epic04/deploy-poc-app.sh -d \<br />    -t "$EFS_CREATION_TOKEN"</pre>`$EFS_CREATION_TOKEN`는 파일 시스템의 고유한 생성 토큰이며 전송 중 암호화를 `–d` 비활성화합니다. | 권한이 부여된 Kubernetes 사용자 | 
| 애플리케이션에서 요청한 영구 볼륨 클레임을 배포하십시오. | 애플리케이션에서 요청한 영구 볼륨 클레임을 배포하고 스토리지 클래스에 연결합니다. 이전에 생성한 퍼시스턴트 볼륨과 동일한 액세스 모드를 사용하십시오. 스토리지 필드에 영구 볼륨 클레임의 크기를 지정할 수 있습니다. Kubernetes는 이 필드가 필요하지만, Amazon EFS는 탄력적인 파일 시스템이기 때문에 파일 시스템 용량을 강제하지 않습니다. | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 배포 1. | 애플리케이션의 워크로드 1을 나타내는 포드를 배포합니다. 이 워크로드는 `/data/out1.txt` 파일에 콘텐츠를 씁니다. | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 배포 2. | 애플리케이션의 워크로드 2을 나타내는 포드를 배포합니다. 이 워크로드는 `/data/out2.txt` 파일에 콘텐츠를 씁니다. | 권한이 부여된 Kubernetes 사용자 | 

### 파일 시스템 지속성, 내구성 및 공유 가능성 검증
<a name="validate-file-system-persistence-durability-and-shareability"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| `PersistentVolume`의 상태를 확인합니다. | 다음 명령을 입력하여 `PersistentVolume`의 상태를 확인합니다.<pre>kubectl get pv</pre>출력 예를 보려면 [추가 정보](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional) 섹션을 참조하세요. | 권한이 부여된 Kubernetes 사용자 | 
| `PersistentVolumeClaim`의 상태를 확인합니다. | 다음 명령을 입력하여 `PersistentVolumeClaim`의 상태를 확인합니다.<pre>kubectl -n poc-efs-eks-fargate get pvc</pre>출력 예를 보려면 [추가 정보](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional) 섹션을 참조하세요. | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 1가 파일 시스템에 쓸 수 있는지 확인합니다. | 다음 명령을 입력하여 워크로드 1이 `/data/out1.txt`에 쓰고 있는지 확인합니다.<pre>kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -f /data/out1.txt</pre>결과는 다음과 비슷합니다.<pre>...<br />Thu Sep  3 15:25:07 UTC 2023 - PoC APP 1<br />Thu Sep  3 15:25:12 UTC 2023 - PoC APP 1<br />Thu Sep  3 15:25:17 UTC 2023 - PoC APP 1<br />...</pre> | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 2가 파일 시스템에 쓸 수 있는지 확인합니다. | 다음 명령을 입력하여 워크로드 2가 `/data/out2.txt`에 쓰고 있는지 확인합니다.<pre>kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -f /data/out2.txt</pre>결과는 다음과 비슷합니다.<pre>...<br />Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2<br />Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2<br />Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2<br />...</pre> | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 1이 워크로드 2에서 작성한 파일을 읽을 수 있는지 확인합니다. | 다음 명령을 입력하여 워크로드 1이 워크로드 2가 작성한 `/data/out2.txt` 파일을 읽을 수 있는지 검증합니다.<pre>kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -n 3 /data/out2.txt</pre>결과는 다음과 비슷합니다.<pre>...<br />Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2<br />Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2<br />Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2<br />...</pre> | 권한이 부여된 Kubernetes 사용자 | 
| 워크로드 2이 워크로드 1에서 작성한 파일을 읽을 수 있는지 확인합니다. | 다음 명령을 입력하여 워크로드 1이 워크로드 2가 작성한 `/data/out1.txt` 파일을 읽을 수 있는지 검증합니다.<pre>kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -n 3 /data/out1.txt</pre>결과는 다음과 비슷합니다.<pre>...<br />Thu Sep  3 15:29:22 UTC 2023 - PoC APP 1<br />Thu Sep  3 15:29:27 UTC 2023 - PoC APP 1<br />Thu Sep  3 15:29:32 UTC 2023 - PoC APP 1<br />...</pre> | 권한이 부여된 Kubernetes 사용자 | 
| 애플리케이션 구성 요소를 제거한 후 파일이 유지되는지 확인하십시오. | 그런 다음 스크립트를 사용하여 애플리케이션 구성 요소(영구 볼륨, 영구 볼륨 클레임 및 포드)를 제거하고 `/data/out1.txt` 및 `/data/out2.txt` 파일이 파일 시스템에 보관되어 있는지 확인합니다. 다음 명령을 사용하여 `validate-efs-content.sh` 스크립트를 실행합니다.<pre>./scripts/epic05/validate-efs-content.sh \<br />    -t "$EFS_CREATION_TOKEN"</pre>파일 시스템의 고유한 생성 `$EFS_CREATION_TOKEN` 토큰은 어디에 있습니까?결과는 다음과 비슷합니다.<pre>pod/poc-app-validation created<br />Waiting for pod get Running state...<br />Waiting for pod get Running state...<br />Waiting for pod get Running state...<br />Results from execution of 'find /data' on validation process pod:<br />/data<br />/data/out2.txt<br />/data/out1.txt</pre> | 권한이 부여된 Kubernetes 사용자, 시스템 관리자 | 

### 운영 모니터링
<a name="monitor-operations"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션 로그를 모니터링합니다. | 2일 차 작업의 일환으로 모니터링을 위해 애플리케이션 로그를 Amazon CloudWatch로 전송합니다. | AWS 시스템 관리자, 권한이 부여된 Kubernetes 사용자 | 
| Container Insights로 Amazon EKS 및 Kubernetes 컨테이너를 모니터링합니다. | 2일 차 작업의 일환으로 Amazon CloudWatch Container Insights를 사용하여 Amazon EKS 및 Kubernetes 시스템을 모니터링합니다. 이 도구는 다양한 수준 및 차원에서 컨테이너식 애플리케이션의 지표를 수집하고 종합하며 요약합니다. 자세한 내용은 [관련 리소스](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources) 섹션을 참조하세요. | AWS 시스템 관리자, 권한이 부여된 Kubernetes 사용자 | 
| CloudWatch로 Amazon EFS를 모니터링합니다. | 2일차 작업의 일환으로 Amazon EFS에서 원시 데이터를 수집하여 읽기 가능하며 실시간에 가까운 지표로 처리하는 Amazon CloudWatch를 사용해 파일 시스템을 모니터링합니다. 자세한 내용은 [관련 리소스](#run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources) 섹션을 참조하세요. | AWS 시스템 관리자 | 

### 리소스 정리
<a name="clean-up-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 생성된 모든 리소스를 패턴에 대해 정리합니다. | 이 패턴을 완료한 후에는 모든 리소스를 정리하여 AWS 요금이 발생하지 않도록 하십시오. PoC 애플리케이션 사용을 마친 후 `clean-up-resources.sh` 스크립트를 실행하여 모든 리소스를 제거합니다. 다음 옵션 중 하나를 수행합니다.**유휴 시 암호화, KMS 키 사용:**<pre>./scripts/epic06/clean-up-resources.sh \<br />    -c "$CLUSTER_NAME" \<br />    -t "$EFS_CREATION_TOKEN" \<br />    -k "$KMS_KEY_ALIAS"</pre>여기서 `$CLUSTER_NAME` 는 Amazon EKS 클러스터의 이름, `$EFS_CREATION_TOKEN` 는 파일 시스템의 생성 토큰, 는 KMS 키의 `$KMS_KEY_ALIAS` 별칭입니다.**유휴 상태의 암호화를 사용하지 않는 경우:**<pre>./scripts/epic06/clean-up-resources.sh \<br />    -c "$CLUSTER_NAME" \<br />    -t "$EFS_CREATION_TOKEN"</pre>여기서 `$CLUSTER_NAME` 는 Amazon EKS 클러스터의 이름과 파일 시스템의 생성 `$EFS_CREATION_TOKEN` 토큰입니다. | 권한이 부여된 Kubernetes 사용자, 시스템 관리자 | 

## 관련 리소스
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-resources"></a>

**참조**
+ [AWS Fargate for Amazon EKS가 이제 Amazon EF를 지원합니다](https://aws.amazon.com/blogs/aws/new-aws-fargate-for-amazon-eks-now-supports-amazon-efs/)(발표)
+ [AWS Fargate에서 Amazon EKS를 사용할 때 애플리케이션 로그를 캡처하는 방법](https://aws.amazon.com/blogs/containers/how-to-capture-application-logs-when-using-amazon-eks-on-aws-fargate/) (블로그 게시물)
+ [컨테이너 인사이트 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)(Amazon CloudWatch 설명서)
+ [Amazon EKS 및 Kubernetes에서 Container Insights 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html)(Amazon CloudWatch 설명서)
+ [Amazon EKS 및 Kubernetes Container Insights 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html)(Amazon CloudWatch 설명서)
+ [Amazon CloudWatch를 통한 Amazon EFS 모니터링](https://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html)(Amazon EFS 설명서)

**GitHub 튜토리얼 및 예제**
+ [정적 프로비저닝](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md)
+ [전송 중 데이터 암호화](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/encryption_in_transit/README.md)
+ [여러 포드에서 파일 시스템에 액세스](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/multiple_pods/README.md)
+ [StatefulSets에서 Amazon EFS 사용](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/statefulset/README.md)
+ [서브패스 마운팅](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/volume_path/README.md)
+ [Amazon EFS 액세스 포인트 사용](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/access_points/README.md)
+ [Terraform용 Amazon EKS 블루프린트](https://aws-ia.github.io/terraform-aws-eks-blueprints/)

**필수 도구**
+ [AWS CLI 버전 2 설치](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
+ [eksctl 설치](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)
+ [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
+ [jq 설치](https://stedolan.github.io/jq/download/)

## 추가 정보
<a name="run-stateful-workloads-with-persistent-data-storage-by-using-amazon-efs-on-amazon-eks-with-aws-fargate-additional"></a>

다음은 `kubectl get pv` 명령의 출력 예입니다.

```
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                             STORAGECLASS   REASON   AGE
poc-app-pv   1Mi        RWX            Retain           Bound    poc-efs-eks-fargate/poc-app-pvc   efs-sc                  3m56s
```

다음은 `kubectl -n poc-efs-eks-fargate get pvc` 명령의 출력 예입니다.

```
NAME          STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
poc-app-pvc   Bound    poc-app-pv   1Mi        RWX            efs-sc         4m34s
```

# Amazon EKS Pod Identity 및 KEDA를 사용하여 Amazon EKS에서 이벤트 기반 Auto Scaling 설정
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda"></a>

*Dipen Desai, Abhay Diwan, Kamal Joshi, Mahendra Revanasiddappa, Amazon Web Services*

## 요약
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-summary"></a>

[Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)와 같은 오케스트레이션 플랫폼은 컨테이너 기반 애플리케이션의 수명 주기 관리를 간소화했습니다. 이를 통해 조직은 컨테이너 기반 애플리케이션을 구축, 보안, 운영 및 유지 관리하는 데 집중할 수 있습니다. 이벤트 기반 배포가 더 일반화됨에 따라 조직은 다양한 이벤트 소스를 기반으로 Kubernetes 배포를 더 자주 확장하고 있습니다. 이 방법을 Auto Scaling과 결합하면 온디맨드 컴퓨팅 리소스를 제공하고 애플리케이션 로직에 맞게 조정하여 비용을 크게 절감할 수 있습니다.

[KEDA](https://keda.sh/)는 Kubernetes 기반 이벤트 기반 오토스케일러입니다. KEDA를 사용하면 처리해야 하는 이벤트 수에 따라 Kubernetes의 모든 컨테이너를 조정할 수 있습니다. 가볍고 모든 Kubernetes 클러스터와 통합됩니다. 또한 [Horizontal Pod Autoscaling(HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)과 같은 표준 Kubernetes 구성 요소와 함께 작동합니다. KEDA는 인증을 위임하는 데 도움이 되는 기능인 [TriggerAuthentication](https://keda.sh/docs/2.14/concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)도 제공합니다. 이를 통해 ScaledObject 및 배포 컨테이너와 별도의 인증 파라미터를 설명할 수 있습니다.

AWS 는 Amazon EKS, Amazon EKS Anywhere(ROSA), Amazon Elastic Compute Cloud Red Hat OpenShift Service on AWS (Amazon EC2)의 자체 관리형 Kubernetes 클러스터 등 다양한 Kubernetes 배포 옵션을 지원하는 ( AWS Identity and Access Management IAM) 역할을 제공합니다. 이러한 역할은 OpenID Connect(OIDC) 자격 증명 공급자 및 IAM 신뢰 정책과 같은 IAM 구문을 사용하여 Amazon EKS 서비스 또는 API에 직접 의존하지 않고 다양한 환경에서 작동합니다. 자세한 내용은 Amazon EKS 사용 설명서의 [서비스 계정에 대한 IAM 역할](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) 섹션을 참조하세요.

[Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)는 Kubernetes 서비스 계정이 OIDC 공급자 없이 IAM 역할을 수임하는 프로세스를 간소화합니다. 애플리케이션의 자격 증명을 관리할 수 있는 기능을 제공합니다. 자격 AWS 증명을 생성하여 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신 IAM 역할을 Kubernetes 서비스 계정과 연결하고 서비스 계정을 사용하도록 포드를 구성합니다. 이렇게 하면 여러 클러스터에서 IAM 역할을 사용하고 IAM 역할 간에 권한 정책을 재사용할 수 있으므로 정책 관리를 간소화할 수 있습니다.

Amazon EKS Pod Identity를 사용하여 KEDA를 구현하면 기업은 효율적인 이벤트 기반 오토 스케일링과 간소화된 자격 증명 관리를 달성할 수 있습니다. 애플리케이션은 수요에 따라 확장되므로 리소스 사용률을 최적화하고 비용을 절감할 수 있습니다.

이 패턴은 Amazon EKS Pod Identity를 KEDA와 통합하는 데 도움이 됩니다. 서비스 `keda-operator` 계정을 사용하고에서 인증을 위임하는 방법을 보여줍니다`TriggerAuthentication`. 또한 KEDA 연산자의 IAM 역할과 애플리케이션의 IAM 역할 간에 신뢰 관계를 설정하는 방법도 설명합니다. 이 신뢰 관계를 통해 KEDA는 이벤트 대기열의 메시지를 모니터링하고 대상 Kubernetes 객체에 대한 조정을 조정할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-prereqs"></a>

**사전 조건 **
+ AWS Command Line Interface (AWS CLI) 버전 2.13.17 이상, [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)됨
+ Python 버전 3.11.5 이상 [설치](https://www.python.org/downloads/)
+ AWS SDK for Python (Boto3) 버전 1.34.135 이상, [설치](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html)됨
+ Helm 버전 3.12.3 이상 [설치](https://helm.sh/docs/intro/install/)
+ kubectl 버전 1.25.1 이상 [설치](https://kubernetes.io/docs/tasks/tools/)
+ Docker Engine 버전 26.1.1 이상 [설치](https://docs.docker.com/engine/install/)
+ Amazon EKS 클러스터(버전 1.24 이상)
+ Amazon EKS Pod Identity 에이전트를 생성하기 위한 사전 조건 [충족](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create)

**제한 사항 **
+ 역할과 `keda-operator` 역할 간에 신뢰 관계를 설정해야 합니다`keda-identity`. 지침은이 패턴의 [에픽](#event-driven-auto-scaling-with-eks-pod-identity-and-keda-epics) 섹션에 나와 있습니다.

## 아키텍처
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-architecture"></a>

이 패턴에서는 다음 AWS 리소스를 생성합니다.
+ **Amazon Elastic Container Registry(Amazon ECR) 리포지토리** -이 패턴에서는이 리포지토리의 이름이 입니다`keda-pod-identity-registry`. 이 프라이빗 리포지토리는 샘플 애플리케이션의 Docker 이미지를 저장하는 데 사용됩니다.
+ **Amazon Simple Queue Service(Amazon SQS) 대기열** -이 패턴에서이 대기열의 이름은 입니다`event-messages-queue`. 대기열은 수신 메시지를 수집하고 저장하는 메시지 버퍼 역할을 합니다. KEDA는 메시지 수 또는 대기열 길이와 같은 대기열 지표를 모니터링하고 이러한 지표를 기반으로 애플리케이션을 자동으로 조정합니다.
+ **애플리케이션에 대한 IAM 역할** -이 패턴에서이 역할의 이름은 입니다`keda-identity`. 이 `keda-operator` 역할은이 역할을 수임합니다. Amazon SQS 대기열에 대한 액세스를 허용하는 IAM 역할입니다.
+ **KEDA 연산자에 대한 IAM 역할 **-이 패턴에서이 역할의 이름은 입니다`keda-operator`. KEDA 연산자는이 역할을 사용하여 필요한 AWS API 호출을 수행합니다. 이렇게 하면 역할을 수임할 `keda-identity` 권한이 부여됩니다. `keda-operator`와 `keda-identity` 역할 간의 신뢰 관계로 인해 `keda-operator` 역할에는 Amazon SQS 권한이 있습니다.

`TriggerAuthentication` 및 `ScaledObject`Kubernetes 사용자 지정 리소스를 통해 운영자는 `keda-identity` 역할을 사용하여 Amazon SQS 대기열에 연결합니다. 대기열 크기에 따라 KEDA는 애플리케이션 배포를 자동으로 조정합니다. 대기열에서 읽지 않은 메시지 5개마다 포드 1개를 추가합니다. 기본 구성에서 Amazon SQS 대기열에 읽지 않은 메시지가 없는 경우 애플리케이션은 포드를 0개로 축소합니다. KEDA 연산자는 지정한 간격으로 대기열을 모니터링합니다.

 

다음 이미지는 Amazon EKS Pod Identity를 사용하여 `keda-operator` 역할에 Amazon SQS 대기열에 대한 보안 액세스를 제공하는 방법을 보여줍니다.

![\[KEDA 및 Amazon EKS Pod Identity를 사용하여 Kubernetes 기반 애플리케이션을 자동으로 확장합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/56f7506d-e8d3-43e5-bec6-42267fedd0ae/images/05bdbd09-9eb8-4c0b-8c0d-efe38aecb683.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. Amazon EKS 클러스터에 Amazon EKS Pod Identity 에이전트를 설치합니다.

1. Amazon EKS 클러스터의 KEDA 네임스페이스에 KEDA 연산자를 배포합니다.

1. 대상에 `keda-operator` 및 `keda-identity` IAM 역할을 생성합니다 AWS 계정.

1. 와 IAM 역할 사이에 신뢰 관계를 구축합니다.

1. `security` 네임스페이스에 애플리케이션을 배포합니다.

1. KEDA 연산자는 Amazon SQS 대기열에서 메시지를 폴링합니다.

1. KEDA는 대기열 크기에 따라 애플리케이션을 자동으로 조정하는 HPA를 시작합니다.

## 도구
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-tools"></a>

**AWS 서비스**
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장 가능하고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다.

**기타 도구**
+ [KEDA](https://keda.sh/)는 Kubernetes 기반 이벤트 기반 오토스케일러입니다.

**코드 리포지토리**

이 패턴의 코드는 EKS Pod Identity 및 KEDA 리포지토리를 사용하는 GitHub 이벤트 기반 오토 스케일링에서 사용할 수 있습니다. [https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main) 

## 모범 사례
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-best-practices"></a>

다음 모범 사례를 따르는 것이 좋습니다.
+ [Amazon SNS 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html)
+ [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Amazon SQS 모범 사례](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-best-practices.html)

## 에픽
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-epics"></a>

### AWS 리소스 생성
<a name="create-aws-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| KEDA 연산자에 대한 IAM 역할을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | 관리자 | 
|  애플리케이션 및 에 대한 IAM 역할 생성 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | 관리자 | 
| Amazon SQS 대기열을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | 일반 AWS | 
| Amazon ECR 리포지토리를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | 일반 AWS | 

### Amazon EKS 클러스터 설정
<a name="set-up-the-eks-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EKS Pod Identity 에이전트를 배포합니다. | 대상 Amazon EKS 클러스터의 경우 Amazon EKS Pod Identity 에이전트를 설정합니다. [Amazon EKS 설명서의 Amazon EKS Pod Identity Agent 설정](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html#pod-id-agent-add-on-create)의 지침을 따릅니다. | DevOps | 
| KEDA를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 
| Kubernetes 서비스 계정에 IAM 역할 할당 | Amazon EKS 설명서의 [Kubernetes 서비스 계정에 IAM 역할 할당](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html)의 지침을 따릅니다. 다음 값을 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps | 
| 네임스페이스를 생성합니다. | 다음 명령을 입력하여 대상 Amazon EKS 클러스터에 `security` 네임스페이스를 생성합니다.<pre>kubectl create ns security</pre> | DevOps 엔지니어 | 

### 샘플 애플리케이션 배포
<a name="deploy-the-sample-application"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션 파일을 복제합니다. | 다음 명령을 입력하여 GitHub의 [EKS Pod Identity 및 KEDA 리포지토리를 사용하여 이벤트 기반 Auto Scaling](https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda/tree/main)을 복제합니다.<pre>git clone https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda.git</pre> | DevOps 엔지니어 | 
| Docker 이미지를 구축합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 
| 도커 이미지를 Amazon ECR로 푸시합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)Amazon ECR 리포지토리 페이지로 이동한 다음 푸시 명령 **보기를 선택하여 푸시 명령을** 찾을 수 있습니다. | DevOps 엔지니어 | 
| 샘플 애플리케이션을 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 
| 애플리케이션 서비스 계정에 IAM 역할을 할당합니다. | 다음 중 하나를 수행하여 `keda-identity` IAM 역할을 샘플 애플리케이션의 서비스 계정과 연결합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 
| `ScaledObject` 및를 배포합니다`TriggerAuthentication`. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 

### Auto Scaling 테스트
<a name="test-auto-scaling"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon SQS 대기열로 테스트 메시지를 전송합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 
| 애플리케이션 포드를 모니터링합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | DevOps 엔지니어 | 

## 문제 해결
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| KEDA 연산자는 애플리케이션을 조정할 수 없습니다. | 다음 명령을 입력하여 `keda-operator` IAM 역할의 로그를 확인합니다.<pre>kubectl logs -n keda -l app=keda-operator -c keda-operator</pre> `HTTP 403` 응답 코드가 있는 경우 애플리케이션과 KEDA 스케일러에 Amazon SQS 대기열에 액세스할 수 있는 충분한 권한이 없습니다. 다음 단계를 완료합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html)`Assume-Role` 오류가 발생하면 [Amazon EKS 노드 IAM 역할](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)이에 정의된 IAM 역할을 수임할 수 없습니다`TriggerAuthentication`. 다음 단계를 완료합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/event-driven-auto-scaling-with-eks-pod-identity-and-keda.html) | 

## 관련 리소스
<a name="event-driven-auto-scaling-with-eks-pod-identity-and-keda-resources"></a>
+ [Amazon EKS Pod Identity Agent 설정](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)(Amazon EKS 설명서)
+ [KEDA 배포](https://keda.sh/docs/2.14/deploy/)(KEDA 설명서)
+ [ScaledObject 사양](https://keda.sh/docs/2.16/reference/scaledobject-spec/)(KEDA 설명서)
+ [TriggerAuthentication을 사용한 인증](https://keda.sh/docs/2.14/concepts/authentication/)(KEDA 설명서)

# PGO를 사용하여 Amazon EKS에서 PostgreSQL 배포 간소화
<a name="streamline-postgresql-deployments-amazon-eks-pgo"></a>

*Shalaka Dengale, Amazon Web Services*

## 요약
<a name="streamline-postgresql-deployments-amazon-eks-pgo-summary"></a>

이 패턴은 Crunchy Data(PGO)의 Postgres 연산자를 Amazon Elastic Kubernetes Service(Amazon EKS)와 통합하여 클라우드 네이티브 환경에서 PostgreSQL 배포를 간소화합니다. PGO는 Kubernetes에서 PostgreSQL 데이터베이스를 관리하기 위한 자동화 및 확장성을 제공합니다. PGO를 Amazon EKS와 결합하면 PostgreSQL 데이터베이스를 효율적으로 배포, 관리 및 확장할 수 있는 강력한 플랫폼이 형성됩니다.

이 통합은 다음을 제공합니다.
+ 자동 배포: PostgreSQL 클러스터 배포 및 관리를 간소화합니다.
+ 사용자 지정 리소스 정의(CRDs): PostgreSQL 관리에 Kubernetes 프리미티브를** **사용합니다.
+ 고가용성: 자동 장애 조치 및 동기식 복제를 지원합니다.
+ 자동 백업 및 복원: 백업 및 복원 프로세스를** **간소화합니다.
+ 수평 조정: PostgreSQL 클러스터의 동적 조정을** **활성화합니다.
+ 버전 업그레이드: 가동 중지 시간을 최소화하면서 롤링 업그레이드를 용이하게 합니다.
+ 보안: 암호화, 액세스 제어 및 인증 메커니즘을 적용합니다.

## 사전 조건 및 제한 사항
<a name="streamline-postgresql-deployments-amazon-eks-pgo-prereqs"></a>

**사전 조건 **
+ 활성. AWS 계정
+ [AWS Command Line Interface(AWS CLI) 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html), Linux, macOS 또는 Windows에 설치 및 구성됨.
+ [AWS CLI Config](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html): 명령줄에서 AWS 리소스를 연결합니다.
+ [Docker](https://github.com/eksctl-io/eksctl#installation), Linux, macOS 또는 Windows에 설치 및 구성되었습니다.
+ `kubectl`, Amazon EKS 클러스터의 리소스에 액세스하도록 설치 및 구성됨. 자세한 내용은 Amazon EKS 설명서의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)를 참조하세요. 
+ Amazon EKS 클러스터에 액세스하도록 구성된 컴퓨터 터미널입니다. 자세한 내용은 Amazon EKS 설명서의 [클러스터와 통신하도록 컴퓨터 구성을 참조하세요](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-configure-kubectl).

**제품 버전**
+ Kubernetes 버전 1.21\$11.24 이상([PGO 설명서](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/) 참조).
+ PostgreSQL 버전 9.4 이상. 이 패턴은 PostgreSQL 버전 16을 사용합니다.

**제한 사항 **
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 섹션을 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) 페이지를 참조하고 서비스 링크를 선택합니다.

## 아키텍처
<a name="streamline-postgresql-deployments-amazon-eks-pgo-architecture"></a>

**대상 기술 스택 **
+ Amazon EKS
+ Amazon Virtual Private Cloud(Amazon VPC)
+ Amazon Elastic Compute Cloud(Amazon EC2)

**대상 아키텍처·**

![\[3개의 가용 영역과 2개의 복제본, 즉 PgBouncer 및 PGO 연산자와 함께 PGO를 사용하기 위한 아키텍처입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/4c164012-7527-4ebe-b6a7-c129600328d6/images/26a5572b-405b-4634-b96a-91254c3ea2c1.png)


이 패턴은 노드가 3개인 Amazon EKS 클러스터가 포함된 아키텍처를 구축합니다. 각 노드는 백엔드의 EC2 인스턴스 세트에서 실행됩니다. 이 PostgreSQL 설정은 읽기 작업이 많은 사용 사례에 특히 효과적인 기본 복제본 아키텍처를 따릅니다. 아키텍처에는 다음 구성 요소가 포함되어 있습니다.
+ **기본 데이터베이스 컨테이너(pg-primary)**는 모든 쓰기 작업이 전달되는 기본 PostgreSQL 인스턴스를 호스팅합니다.
+ **보조 복제본 컨테이너(pg-replica)**는 기본 데이터베이스에서 데이터를 복제하고 읽기 작업을 처리하는 PostgreSQL 인스턴스를 호스팅합니다.
+ **PgBouncer**는 PGO에 포함된 PostgreSQL 데이터베이스용 경량 연결 풀러입니다. 클라이언트와 PostgreSQL 서버 사이에 있으며 데이터베이스 연결을 위한 중개자 역할을 합니다.
+ **PGO**는이 Kubernetes 환경에서 PostgreSQL 클러스터의 배포 및 관리를 자동화합니다.
+ **Patroni**는 PostgreSQL의 고가용성 구성을 관리하고 자동화하는 오픈 소스 도구입니다. PGO에 포함되어 있습니다. Kubernetes에서 PGO와 함께 Patroni를 사용하면 PostgreSQL 클러스터의 복원력과 내결함성을 보장하는 데 중요한 역할을 합니다. 자세한 내용은 [Packer 설명서](https://patroni.readthedocs.io/en/latest/)를 참조하세요.

워크플로에는 다음 단계가 포함됩니다.
+ 연산자 배포 Amazon EKS에서 실행되는 Kubernetes 클러스터에 PGO 연산자를 배포합니다. 이는 Kubernetes 매니페스트 또는 차트 Helm을 사용하여 수행할 수 있습니다. 이 패턴은 Kubernetes 매니페스트를 사용합니다.
+ **PostgreSQL 인스턴스를 정의합니다**. 연산자가 실행 중일 때 사용자 지정 리소스(CRs)를 생성하여 PostgreSQL 인스턴스의 원하는 상태를 지정합니다. 여기에는 스토리지, 복제 및 고가용성 설정과 같은 구성이 포함됩니다.
+ **연산자 관리**. PostgreSQL 인스턴스를 생성, 업데이트 또는 삭제하기 위해 CRs과 같은 Kubernetes API 객체를 통해 연산자와 상호 작용합니다.
+ **모니터링 및 유지 관리**. Amazon EKS에서 실행되는 PostgreSQL 인스턴스의 상태와 성능을 모니터링할 수 있습니다. 연산자는 모니터링 목적으로 지표와 로깅을 제공하는 경우가 많습니다. 필요에 따라 업그레이드 및 패치 적용과 같은 일상적인 유지 관리 작업을 수행할 수 있습니다. 자세한 내용은 Amazon EKS 설명서의 [클러스터 성능 모니터링 및 로그 보기를 참조하세요](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html).
+ **조정 및 백업**: 운영자가 제공하는 기능을 사용하여 PostgreSQL 인스턴스를 조정하고 백업을 관리할 수 있습니다.

이 패턴은 모니터링, 유지 관리 및 백업 작업을 다루지 않습니다.

**자동화 및 규모 조정**
+  CloudFormation 를 사용하여 인프라 생성을 자동화할 수 있습니다. 자세한 내용은 [Amazon EKS 설명서의를 사용하여 Amazon EKS 리소스 생성을 CloudFormation](https://docs.aws.amazon.com/eks/latest/userguide/creating-resources-with-cloudformation.html) 참조하세요.
+ GitVersion 또는 Jenkins 빌드 번호를 사용하여 데이터베이스 인스턴스 배포를 자동화할 수 있습니다.

## 도구
<a name="streamline-postgresql-deployments-amazon-eks-pgo-tools"></a>

**AWS 서비스**
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다. 
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.

**기타 도구**
+ 은 Amazon EKS에 클러스터를 생성하기 위한 간단한 CLI 도구입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)은 Kubernetes 클러스터에 대해 명령을 실행하기 위한 명령줄 유틸리티입니다.
+ [PGO](https://github.com/CrunchyData/postgres-operator)는 Kubernetes에서 PostgreSQL 데이터베이스 관리를 자동화하고 확장합니다.

## 모범 사례
<a name="streamline-postgresql-deployments-amazon-eks-pgo-best-practices"></a>

다음 모범 사례를 따라 원활하고 효율적인 배포를 보장합니다.
+ **EKS 클러스터를 보호합니다**. 서비스 계정(IRSA)에 대한 AWS Identity and Access Management (IAM) 역할 사용, 네트워크 정책 및 VPC 보안 그룹과 같은 EKS 클러스터의 보안 모범 사례를 구현합니다. EKS 클러스터 API 서버에 대한 액세스를 제한하고 TLS를 사용하여 노드와 API 서버 간의 통신을 암호화합니다.
+ Amazon EKS에서 실행되는 PGO와 Kubernetes 간의 **버전 호환성을 보장합니다**. 일부 PGO 기능에는 특정 Kubernetes 버전이 필요하거나 호환성 제한이 발생할 수 있습니다. 자세한 내용은 PGO 설명서의 [구성 요소 및 호환성](https://access.crunchydata.com/documentation/postgres-operator/5.2.5/references/components/)을 참조하세요.
+ CPU, 메모리 및 스토리지를 포함하여 PGO 배포에 대한 **리소스 할당을 계획**합니다. PGO와 PGO가 관리하는 PostgreSQL 인스턴스의 리소스 요구 사항을 모두 고려합니다. 리소스 사용량을 모니터링하고 필요에 따라 리소스를 확장합니다.
+ **고가용성을 위한 설계**. 가동 중지 시간을 최소화하고 신뢰성을 보장하기 위해 고가용성을 위한 PGO 배포를 설계합니다. 내결함성을 위해 여러 가용 영역에 여러 PGO 복제본을 배포합니다.
+ PGO가 관리하는 PostgreSQL 데이터베이스에 대한 **백업 및 복원 절차를 구현**합니다. Kubernetes 및 Amazon EKS와 호환되는 PGO 또는 서드 파티 백업 솔루션에서 제공하는 기능을 사용합니다.
+ PGO 배포에 대한 **모니터링 및 로깅을 설정**하여 성능, 상태 및 이벤트를 추적합니다. Prometheus와 같은 도구를 사용하여 지표를 모니터링하고 Grafana를 사용하여 시각화합니다. 문제 해결 및 감사를 위해 PGO 로그를 캡처하도록 로깅을 구성합니다.
+ PGO, PostgreSQL 인스턴스 및 Kubernetes 클러스터의 기타 서비스 간의 통신을 허용하도록 **네트워킹을 올바르게 구성합니다**. 네트워크 정책 적용 및 트래픽 격리를 위해 Calico 또는 Amazon VPC [CNI와 같은 Amazon VPC](https://github.com/aws/amazon-vpc-cni-k8s) 네트워킹 기능과 Kubernetes 네트워킹 플러그인을 사용합니다.
+ 성능, 내구성 및 확장성과 같은 요소를 고려하여 PostgreSQL 데이터베이스에 **적합한 스토리지 옵션을 선택합니다**. 영구 스토리지에 Amazon Elastic Block Store(Amazon EBS) 볼륨 또는 AWS 관리형 스토리지 서비스를 사용합니다. 자세한 내용은 [Amazon EKS 설명서의 Amazon EBS로 Kubernetes 볼륨 저장](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)을 참조하세요.
+ 와 같은 **코드형 인프라(IaC) 도구를 사용하여** Amazon EKS에서 PGO의 배포 및 구성을 자동화 CloudFormation 합니다. 일관성, 반복성 및 버전 관리를 위한 코드로 EKS 클러스터, 네트워킹 및 PGO 리소스를 포함한 인프라 구성 요소를 정의합니다.

## 에픽
<a name="streamline-postgresql-deployments-amazon-eks-pgo-epics"></a>

### IAM 역할 생성
<a name="create-an-iam-role"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| IAM 역할을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | 관리자 | 

### Amazon EKS 클러스터 생성
<a name="create-an-eks-cluster"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon EKS 클러스터를 생성합니다. | 클러스터를 이미 배포한 경우이 단계를 건너뜁니다. 그렇지 않으면 , `eksctl`Terraform 또는를 사용하여 현재에 Amazon EKS 클러스터 AWS 계정 를 배포합니다 CloudFormation. 이 패턴은 클러스터 배포`eksctl`에를 사용합니다.이 패턴은 Amazon EC2를 Amazon EKS의 노드 그룹으로 사용합니다. 를 사용하려면 [eksctl 설명서](https://eksctl.io/usage/schema/#managedNodeGroups)의 `managedNodeGroups` 구성을 AWS Fargate참조하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS 관리자, Terraform 또는 eksctl 관리자, Kubernetes 관리자 | 
| 클러스터의 상태입니다. | 다음 명령을 실행하여 클러스터 상태를 확인합니다.<pre>kubectl get nodes</pre>오류가 발생하는 경우 [문제 해결](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html) 섹션을 참조하세요. | AWS 관리자, Terraform 또는 eksctl 관리자, Kubernetes 관리자 | 

### OIDC 자격 증명 공급자를 생성하는 방법()
<a name="create-an-oidc-identity-provider"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| IAM OIDC 공급자를 활성화합니다. | Amazon EBS 컨테이너 스토리지 인터페이스(CSI) 드라이버의 사전 조건으로 클러스터에 대한 기존 IAM OpenID Connect(OIDC) 공급자가 있어야 합니다.다음 명령을 사용하여 IAM ID 제공업체를 만듭니다.<pre>eksctl utils associate-iam-oidc-provider --region={region} --cluster={YourClusterNameHere} --approve</pre>이에 대한 자세한 내용은 Amazon EKS 설명서의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)를 참조하세요. | 관리자 | 
| Amazon EBS CSI 드라이버 IAM 역할 생성 | 그러고 나서 다음 명령을 사용하여 IAM 역할을 만듭니다.<pre>eksctl create iamserviceaccount \<br />  --region {RegionName} \<br />  --name ebs-csi-controller-sa \<br />  --namespace kube-system \<br />  --cluster {YourClusterNameHere} \<br />  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \<br />  --approve \<br />  --role-only \<br />  --role-name AmazonEKS_EBS_CSI_DriverRole</pre>암호화된 Amazon EBS 드라이브를 사용하는 경우 정책을 추가로 구성해야 합니다. 자세한 지침은 [Amazon EC2 설명서](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#installation-1)를 참조하십시오. | 관리자 | 
| Amazon EBS CSI 드라이버 추가 기능 받기 | 다음 명령에 따라 Amazon EBS CSI 드라이버를 생성합니다.<pre>eksctl create addon \<br />  --name aws-ebs-csi-driver \<br />  --cluster <YourClusterName> service-account-role-arn arn:aws:iam::$(aws sts get-caller-identity \<br />  --query Account \<br />  --output text):role/AmazonEKS_EBS_CSI_DriverRole \<br />  --force</pre> | 관리자 | 

### PHP를 설치합니다.
<a name="install-pgo"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | GitHub 리포지토리를 복제합니다.<pre>git clone https://github.com/CrunchyData/postgres-operator-examples.git </pre> | DevOps | 
| 서비스 계정 생성을 위한 역할 세부 정보를 제공합니다. | Amazon EKS 클러스터에 필요한 AWS 리소스에 대한 액세스 권한을 부여하려면 `service_account.yaml` 파일에서 앞서 생성한 OIDC 역할의 Amazon 리소스 이름(ARN)을 지정합니다. 이 파일은 인 이름으로 지정되어 있으며 GitHub 리포지토리의 docker 폴더에 있습니다.<pre>cd postgres-operator-examples</pre><pre>---<br />metadata:<br />  annotations:<br />    eks.amazonaws.com/role-arn: arn:aws:iam::<accountId>:role/<role_name> # Update the OIDC role ARN created earlier</pre> | AWS 관리자, Kubernetes 관리자 | 
| 네임스페이스 및 PGO 사전 조건을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | Kunernetes 관리자 | 
| 포드 생성을 확인합니다. | 네임스페이스와 기본 구성이 생성되었는지 확인합니다.<pre>kubectl get pods -n postgres-operator</pre> | AWS 관리자, Kubernetes 관리자 | 
| PVCs 확인합니다. | 다음 명령을 사용하여 영구 볼륨 클레임(PVCs<pre>kubectl describe pvc -n postgres-operator</pre> | AWS 관리자, Kubernetes 관리자 | 

### 연산자 생성 및 배포
<a name="create-and-deploy-an-operator"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CREATE OPERATOR | 다음과 `/kustomize/postgres/postgres.yaml` 일치하도록에 있는 파일의 내용을 수정합니다.<pre>spec:<br />  instances:<br />    - name: pg-1<br />      replicas: 3<br />  patroni:<br />    dynamicConfiguration:<br />      postgresql:<br />      pg_hba:<br />        - "host all all 0.0.0.0/0 trust" # this line enabled logical replication with programmatic access<br />        - "host all postgres 127.0.0.1/32 md5"<br />      synchronous_mode: true<br />  users:<br />  - name: replicator<br />    databases:<br />      - testdb<br />    options: "REPLICATION"</pre>이러한 업데이트는 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | AWS 관리자, DBA, Kubernetes 관리자 | 
| 연산자 배포 | PGO 연산자를 배포하여 Kubernetes 환경에서 PostgreSQL 데이터베이스의 간소화된 관리 및 운영을 활성화합니다.<pre>kubectl apply -k kustomize/postgres</pre> | AWS 관리자, DBA, Kubernetes 관리자 | 
| 배포를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html)명령 출력에서 기본 복제본(`primary_pod_name`)과 읽기 전용 복제본()을 기록해 둡니다`read_pod_name`. 다음 단계에서 이 항목을 편집합니다. | AWS 관리자, DBA, Kubernetes 관리자 | 

### 스트리밍 복제 확인
<a name="verify-streaming-replication"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 기본 복제본에 데이터를 씁니다. | 다음 명령을 사용하여 PostgreSQL 기본 복제본에 연결하고 데이터베이스에 데이터를 씁니다.<pre>kubectl exec -it <primary_pod_name> bash -n postgres-operator</pre><pre>psql</pre><pre>CREATE TABLE customers (firstname text, customer_id serial, date_created timestamp);<br />\dt</pre> | AWS 관리자, Kubernetes 관리자 | 
| 읽기 전용 복제본의 데이터가 동일한지 확인합니다. | PostgreSQL 읽기 전용 복제본에 연결하고 스트리밍 복제가 올바르게 작동하는지 확인합니다.<pre>kubectl exec -it {read_pod_name} bash -n postgres-operator</pre><pre>psql</pre><pre>\dt</pre>읽기 전용 복제본에는 이전 단계의 기본 복제본에서 생성한 테이블이 있어야 합니다. | AWS 관리자, Kubernetes 관리자 | 

## 문제 해결
<a name="streamline-postgresql-deployments-amazon-eks-pgo-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 포드가 시작되지 않습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | 
| 복제본은 기본 데이터베이스보다 훨씬 뒤쳐져 있습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | 
| PostgreSQL 클러스터의 성능과 상태를 볼 수 없습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | 
| 복제가 작동하지 않습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/streamline-postgresql-deployments-amazon-eks-pgo.html) | 

## 관련 리소스
<a name="streamline-postgresql-deployments-amazon-eks-pgo-resources"></a>
+ [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html)(*AWS 백서의 배포 옵션 개요*)
+  [CloudFormation](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/aws-cloudformation.html) (*AWS 백서의 배포 옵션 개요*)
+ [Amazon EKS 시작하기 – eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)(*Amazon EKS 사용 설명서*)
+ [kubectl 및 eksctl 설정](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)(*Amazon EKS 사용 설명서*)
+ [OpenID Connect 페더레이션을 위한 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)(*IAM 사용 설명서*)
+ (*AWS CLI 사용 설명서*)[에 대한 설정 구성 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) 
+ [Kubernetes용 Crunchy Postgres 설명서](https://access.crunchydata.com/documentation/postgres-operator/latest)
+ [Crunch & Learn: Kubernetes 5.0용 Crunchy Postgres](https://www.youtube-nocookie.com/embed/IIf9WZO3K50)(비디오)

# Application Load Balancer를 사용하여 Amazon ECS에서 상호 TLS로 애플리케이션 인증 간소화
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs"></a>

*Olawale Olaleye 및 Shamanth Devagari, Amazon Web Services*

## 요약
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-summary"></a>

이 패턴을 사용하면 Application [Application Load Balancer(ALB](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html))를 사용하여 Amazon Elastic Container Service(Amazon ECS)에서 상호 TLS로 애플리케이션 인증을 간소화하고 보안 부담을 덜 수 있습니다. ALB를 사용하면에서 X.509 클라이언트 인증서를 인증할 수 있습니다 AWS Private Certificate Authority. 이 강력한 조합은 서비스 간에 안전한 통신을 달성하여 애플리케이션 내에서 복잡한 인증 메커니즘의 필요성을 줄이는 데 도움이 됩니다. 또한이 패턴은 Amazon Elastic Container Registry(Amazon ECR)를 사용하여 컨테이너 이미지를 저장합니다.

이 패턴의 예에서는 퍼블릭 갤러리의 Docker 이미지를 사용하여 처음에 샘플 워크로드를 생성합니다. 이후 새 Docker 이미지는 Amazon ECR에 저장되도록 빌드됩니다. 소스의 경우 GitHub, GitLab GitLab 기반 시스템을 고려하거나 Amazon Simple Storage Service Amazon S3(Amazon S3)를 사용합니다. Docker 이미지를 빌드하려면 후속 이미지 AWS CodeBuild 에를 사용하는 것이 좋습니다.

## 사전 조건 및 제한 사항
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-prereqs"></a>

**사전 조건 **
+  AWS CloudFormation 스택을 배포할 수 있는 액세스 권한이 AWS 계정 있는 활성 . CloudFormation을 배포할 수 있는 AWS Identity and Access Management (IAM) [사용자 또는 역할 권한이](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/control-access-with-iam.html) 있는지 확인합니다.
+ AWS Command Line Interface (AWS CLI)가 [설치되었습니다](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). 를 사용하거나 `~/.aws/credentials` 파일에서 환경 변수를 설정하여 로컬 시스템 AWS CLI 또는 환경에서 AWS 자격 증명을 [구성합니다](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).
+ OpenSSL [설치](https://www.openssl.org/)
+ Docker [설치](https://www.docker.com/get-started/)
+ [도구](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-tools)에 AWS 서비스 설명된에 익숙합니다.
+ Docker 및 NGINX에 대한 지식.

**제한 사항 **
+ Application Load Balancer용 상호 TLS는 X.509v3 클라이언트 인증서만 지원합니다. X.509v1 클라이언트 인증서는 지원되지 않습니다.
+ 이 패턴의 코드 리포지토리에 제공된 CloudFormation 템플릿에는 스택의 일부로 CodeBuild 프로젝트를 프로비저닝하는 작업이 포함되지 않습니다.
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전별 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)을 참조하고 서비스 링크를 선택합니다.

**제품 버전**
+ Docker, 버전 27.3.1 이상
+ AWS CLI 버전 2.14.5 이상

## 아키텍처
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-architecture"></a>

다음 다이어그램은 이 패턴의 구성 요소를 보여 줍니다.

![\[Application Load Balancer를 사용한 상호 TLS 인증 워크플로\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/a343fa4e-097f-416b-9c83-01a28eb57dc3/images/e1371297-b987-4487-9b13-8120933c921f.png)


 이 다이어그램은 다음 워크플로를 보여줍니다.

1. Git 리포지토리를 생성하고 애플리케이션 코드를 리포지토리에 커밋합니다.

1. 에서 사설 인증 기관(CA)을 생성합니다 AWS Private CA.

1. CodeBuild 프로젝트를 생성합니다. CodeBuildproject는 커밋 변경에 의해 트리거되고 Docker 이미지를 생성하고 빌드된 이미지를 Amazon ECR에 게시합니다.

1. CA에서 인증서 체인과 인증서 본문을 복사하고 인증서 번들을 Amazon S3에 업로드합니다.

1. Amazon S3에 업로드한 CA 번들로 트러스트 스토어를 생성합니다. 트러스트 스토어를 Application Load Balancer(ALB)의 상호 TLS 리스너와 연결합니다.

1. 프라이빗 CA를 사용하여 컨테이너 워크로드에 대한 클라이언트 인증서를 발급합니다. 또한를 사용하여 프라이빗 TLS 인증서를 생성합니다 AWS Private CA.

1. 프라이빗 TLS 인증서를 AWS Certificate Manager (ACM)로 가져와 ALB와 함께 사용합니다.

1. 의 컨테이너 워크로드는의 컨테이너 워크로드와 통신할 때 발급된 클라이언트 인증서를 `ServiceTwo` 사용하여 ALB로 인증합니다`ServiceOne`.

1. 의 컨테이너 워크로드는의 컨테이너 워크로드와 통신할 때 발급된 클라이언트 인증서를 `ServiceOne` 사용하여 ALB로 인증합니다`ServiceTwo`.

**자동화 및 규모 조정**

이 패턴은 CloudFormation AWS Cloud Development Kit (AWS CDK) 을 사용하거나 SDK의 API 작업을 사용하여 AWS 리소스를 프로비저닝하여 완전히 자동화할 수 있습니다.

CodeBuild를 사용하여 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 AWS CodePipeline 구현하여 컨테이너 이미지 빌드 프로세스를 자동화하고 Amazon ECS 클러스터 서비스에 새 릴리스를 배포할 수 있습니다.

## 도구
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-tools"></a>

**AWS 서비스 **
+ [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)을 사용하면 웹 AWS 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 생성, 저장 및 갱신할 수 있습니다.
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)는 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 전체 수명 주기 동안 리소스를 관리할 수 있도록 지원합니다 AWS 리전.
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)는 소스 코드를 컴파일하고 유닛 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 완전 관리형 빌드 서비스입니다.
+ [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)는 안전하고 확장성이 있고 신뢰할 수 있는 관리형 컨테이너 이미지 레지스트리 서비스입니다.
+ [Amazon Elastic Container Service(Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)는 클러스터에서 컨테이너를 실행, 중지 및 관리하기 위한 컨테이너 관리 서비스로서 확장성과 속도가 뛰어납니다. 에서 관리하는 서버리스 인프라에서 태스크와 서비스를 실행할 수 있습니다 AWS Fargate. 또는 인프라에 대한 더 세부적인 제어를 위해, 관리하는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 클러스터에서 작업과 서비스를 실행할 수 있습니다.
+ [Amazon ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html)을 사용하면 먼저 호스트 컨테이너 운영 체제와 상호 작용하거나 인바운드 포트를 열거나 SSH 키를 관리할 필요 없이 컨테이너와 직접 상호 작용할 수 있습니다. ECS Exec을 사용하여 명령을 실행하거나 Amazon EC2 인스턴스 또는 AWS Fargate에서 실행하는 컨테이너에 셸을 가져올 수 있습니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 예를 들어 하나 이상의 가용 영역에 있는 Amazon EC2 인스턴스, 컨테이너, IP 주소 전반적으로 트래픽을 분산할 수 있습니다. ELB는 등록된 대상의 상태를 모니터링하면서 상태가 양호한 대상으로만 트래픽을 라우팅합니다. ELB는 수신 트래픽이 시간이 지남에 따라 변경됨에 따라 로드 밸런서를 확장합니다. 대다수의 워크로드에 맞게 자동으로 조정할 수 있습니다.
+ [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html)를 사용하면 서버 또는 Amazon EC2 인스턴스를 관리할 필요 없이 컨테이너를 실행할 수 있습니다. Fargate는 Amazon ECS 및 Amazon Elastic Kubernetes Service(Amazon EKS) 모두와 호환됩니다. Fargate 시작 유형 또는 Fargate 용량 공급자를 사용하여 Amazon ECS 태스크 및 서비스를 실행할 수 있습니다. 그렇게 하려면 애플리케이션을 컨테이너에 패키징하고, CPU 및 메모리 요구 사항을 지정하고, 네트워킹 및 IAM 정책을 정의하고, 애플리케이션을 실행합니다. 각 Fargate 작업에는 자체 격리 경계가 있으며 다른 작업과 기본 커널, CPU 리소스, 메모리 리소스 또는 탄력적 네트워크 인터페이스를 공유하지 않습니다.
+ [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)를 사용하면 온프레미스 CA를 운영하는 데 드는 투자 및 유지 관리 비용 없이 루트 및 하위 CA를 비롯한 사설 CA 계층을 생성할 수 있습니다.

**기타 도구**** **
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.
+ [GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories), [GitLab](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html) 및 [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-git/)은 소스 코드 변경 사항을 추적하는 데 일반적으로 사용되는 Git 기반 소스 제어 시스템 중 하나입니다.
+ [NGINX 오픈 소스](https://nginx.org/en/docs/?_ga=2.187509224.1322712425.1699399865-405102969.1699399865)는 오픈 소스 로드 밸런서, 콘텐츠 캐시 및 웹 서버입니다. 이 패턴은 이를 웹 서버로 사용합니다.
+ [OpenSSL](https://www.openssl.org/)은 TLS 및 CMS의 OpenSSL 구현에서 사용하는 서비스를 제공하는 오픈 소스 라이브러리입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [mTLS-with-Application-Load-Balancer-in-Amazon-ECS](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS) 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-best-practices"></a>
+ Amazon ECS Exec을 사용하여 명령을 실행하거나 Fargate에서 실행되는 컨테이너로 셸을 가져옵니다. 또한 ECS Exec을 사용하여 디버깅을 위한 진단 정보를 수집할 수 있습니다.
+ 보안 그룹 및 네트워크 액세스 제어 목록(ACLs)을 사용하여 서비스 간의 인바운드 및 아웃바운드 트래픽을 제어합니다. Fargate 작업은 가상 프라이빗 클라우드(VPC)에 구성된 서브넷에서 IP 주소를 받습니다.

## 에픽
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-epics"></a>

### 리포지토리 생성
<a name="create-the-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 소스 코드를 다운로드합니다. | 이 패턴의 소스 코드를 다운로드하려면 GitHub [mTLS-with-Application-Load-Balancer-in-Amazon-ECS](https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS) 리포지토리를 포크하거나 복제합니다. | DevOps 엔지니어 | 
| Git 리포지토리를 생성합니다. | Dockerfile 및 `buildspec.yaml` 파일을 포함하는 Git 리포지토리를 생성하려면 다음 단계를 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`git clone https://github.com/aws-samples/mTLS-with-Application-Load-Balancer-in-Amazon-ECS.git` | DevOps 엔지니어 | 

### CA 생성 및 인증서 생성
<a name="create-ca-and-generate-certificates"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 에서 프라이빗 CA를 생성합니다 AWS Private CA. | 프라이빗 인증 기관을 생성하려면 터미널에서 다음 명령을 실행합니다. 예시 변수의 값을 자신의 값으로 바꿉니다.<pre>export AWS_DEFAULT_REGION="us-west-2"<br />export SERVICES_DOMAIN="www.example.com"<br /><br />export ROOT_CA_ARN=`aws acm-pca create-certificate-authority \<br />    --certificate-authority-type ROOT \<br />    --certificate-authority-configuration \<br />    "KeyAlgorithm=RSA_2048,<br />    SigningAlgorithm=SHA256WITHRSA,<br />    Subject={<br />        Country=US,<br />        State=WA,<br />        Locality=Seattle,<br />        Organization=Build on AWS,<br />        OrganizationalUnit=mTLS Amazon ECS and ALB Example,<br />        CommonName=${SERVICES_DOMAIN}}" \<br />        --query CertificateAuthorityArn --output text`</pre>자세한 내용은 AWS 설명서의 [에서 프라이빗 CA 생성을 AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html) 참조하세요. | DevOps 엔지니어, AWS DevOps | 
| 프라이빗 CA 인증서를 생성하고 설치합니다. | 프라이빗 루트 CA에 대한 인증서를 생성하고 설치하려면 터미널에서 다음 명령을 실행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS DevOps, DevOps 엔지니어 | 
| 관리형 인증서를 요청합니다. | 에서 프라이빗 ALB AWS Certificate Manager 와 함께 사용할 프라이빗 인증서를 요청하려면 다음 명령을 사용합니다.<pre>export TLS_CERTIFICATE_ARN=`aws acm request-certificate \<br />    --domain-name "*.${DOMAIN_DOMAIN}" \<br />    --certificate-authority-arn ${ROOT_CA_ARN} \<br />    --query CertificateArn --output text`</pre> | DevOps 엔지니어, AWS DevOps | 
| 프라이빗 CA를 사용하여 클라이언트 인증서를 발급합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)`openssl req -out client_csr1.pem -new -newkey rsa:2048 -nodes -keyout client_private-key1.pem``openssl req -out client_csr2.pem -new -newkey rsa:2048 -nodes -keyout client_private-key2.pem`이 명령은 두 서비스의 CSR과 프라이빗 키를 반환합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)<pre>SERVICE_ONE_CERT_ARN=`aws acm-pca issue-certificate \<br />    --certificate-authority-arn ${ROOT_CA_ARN} \<br />    --csr fileb://client_csr1.pem \<br />    --signing-algorithm "SHA256WITHRSA" \<br />    --validity Value=5,Type="YEARS" --query CertificateArn --output text` <br /><br />echo "SERVICE_ONE_CERT_ARN: ${SERVICE_ONE_CERT_ARN}"<br /><br />aws acm-pca get-certificate \<br />    --certificate-authority-arn ${ROOT_CA_ARN} \<br />    --certificate-arn ${SERVICE_ONE_CERT_ARN} \<br />     | jq -r '.Certificate' > client_cert1.cert<br /><br />SERVICE_TWO_CERT_ARN=`aws acm-pca issue-certificate \<br />    --certificate-authority-arn ${ROOT_CA_ARN} \<br />    --csr fileb://client_csr2.pem \<br />    --signing-algorithm "SHA256WITHRSA" \<br />    --validity Value=5,Type="YEARS" --query CertificateArn --output text` <br /><br />echo "SERVICE_TWO_CERT_ARN: ${SERVICE_TWO_CERT_ARN}"<br /><br />aws acm-pca get-certificate \<br />    --certificate-authority-arn ${ROOT_CA_ARN} \<br />    --certificate-arn ${SERVICE_TWO_CERT_ARN} \<br />     | jq -r '.Certificate' > client_cert2.cert</pre>자세한 내용은 AWS 설명서의 [프라이빗 최종 엔터티 인증서 발급](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html)을 참조하세요. | DevOps 엔지니어, AWS DevOps | 

### AWS 서비스 프로비저닝
<a name="provision-aws-services"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudFormation 템플릿 AWS 서비스 으로 프로비저닝합니다. | Virtual Private Cloud(VPC), Amazon ECS 클러스터, Amazon ECS 서비스, Application Load Balancer 및 Amazon Elastic Container Registry(Amazon ECR)를 프로비저닝하려면 CloudFormation 템플릿을 사용합니다. | DevOps 엔지니어 | 
| 변수를 가져옵니다. | 두 서비스가 실행 중인 Amazon ECS 클러스터가 있는지 확인합니다. 리소스 세부 정보를 검색하여 변수로 저장하려면 다음 명령을 사용합니다.<pre><br />export LoadBalancerDNS=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`LoadBalancerDNS`].OutputValue')<br /><br />export ECRRepositoryUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryUri`].OutputValue')<br /><br />export ECRRepositoryServiceOneUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceOneUri`].OutputValue')<br /><br />export ECRRepositoryServiceTwoUri=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`ECRRepositoryServiceTwoUri`].OutputValue')<br /><br />export ClusterName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`ClusterName`].OutputValue')<br /><br />export BucketName=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue')<br /><br />export Service1ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`Service1ListenerArn`].OutputValue')<br /><br />export Service2ListenerArn=$(aws cloudformation describe-stacks --stack-name ecs-mtls \<br />--output text \<br />--query 'Stacks[0].Outputs[?OutputKey==`Service2ListenerArn`].OutputValue')</pre> | DevOps 엔지니어 | 
| CodeBuild 프로젝트를 생성합니다. | CodeBuild 프로젝트를 사용하여 Amazon ECS 서비스에 대한 Docker 이미지를 생성하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)자세한 내용은 AWS 설명서의 [에서 빌드 프로젝트 생성을 AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html) 참조하세요. | AWS DevOps, DevOps 엔지니어 | 
| Docker 이미지를 빌드합니다. | CodeBuild를 사용하여 이미지 빌드 프로세스를 수행할 수 있습니다. CodeBuild는 Amazon ECR과 상호 작용하고 Amazon S3를 사용할 수 있는 권한이 필요합니다.프로세스의 일부로 Docker 이미지가 빌드되어 Amazon ECR 레지스트리로 푸시됩니다. 템플릿과 코드에 대한 자세한 내용은 [추가 정보](#simplify-application-authentication-with-mutual-tls-in-amazon-ecs-additional)를 참조하세요.(선택 사항) 테스트 목적으로 로컬에서 빌드하려면 다음 명령을 사용합니다.<pre># login to ECR<br />aws ecr get-login-password | docker login --username AWS --password-stdin $ECRRepositoryUri<br /><br /># build image for service one<br />cd /service1<br />aws s3 cp s3://$BucketName/serviceone/ service1/ --recursive<br />docker build -t $ECRRepositoryServiceOneUri .<br />docker push $ECRRepositoryServiceOneUri<br /><br /># build image for service two<br />cd ../service2<br />aws s3 cp s3://$BucketName/servicetwo/ service2/ --recursive<br />docker build -t $ECRRepositoryServiceTwoUri .<br />docker push $ECRRepositoryServiceTwoUri</pre> | DevOps 엔지니어 | 

### 상호 TLS 활성화
<a name="enable-mutual-tls"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CA 인증서를 Amazon S3에 업로드합니다. | Amazon S3 버킷에 CA 인증서를 업로드하려면 다음 예시 명령을 사용합니다.`aws s3 cp ca-cert.pem s3://$BucketName/acm-trust-store/ ` | AWS DevOps, DevOps 엔지니어 | 
| 신뢰 저장소를 생성합니다. | 신뢰 저장소를 생성하려면 다음 예시 명령을 사용합니다.<pre>TrustStoreArn=`aws elbv2 create-trust-store --name acm-pca-trust-certs \<br />    --ca-certificates-bundle-s3-bucket $BucketName \<br />    --ca-certificates-bundle-s3-key acm-trust-store/ca-cert.pem --query 'TrustStores[].TrustStoreArn' --output text`</pre> | AWS DevOps, DevOps 엔지니어 | 
| 클라이언트 인증서를 업로드합니다. | Amazon S3 for Docker 이미지에 클라이언트 인증서를 업로드하려면 다음 예시 명령을 사용합니다.<pre># for service one<br />aws s3 cp client_cert1.cert s3://$BucketName/serviceone/<br />aws s3 cp client_private-key1.pem s3://$BucketName/serviceone/<br /><br /># for service two<br />aws s3 cp client_cert2.cert s3://$BucketName/servicetwo/<br />aws s3 cp client_private-key2.pem s3://$BucketName/servicetwo/</pre> | AWS DevOps, DevOps 엔지니어 | 
| 리스너를 수정합니다. | ALB에서 상호 TLS를 활성화하려면 다음 명령을 사용하여 HTTPS 리스너를 수정합니다.<pre>aws elbv2 modify-listener \<br />    --listener-arn $Service1ListenerArn \<br />    --certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \<br />    --ssl-policy ELBSecurityPolicy-2016-08 \<br />    --protocol HTTPS \<br />    --port 8080 \<br />    --mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false<br /><br />aws elbv2 modify-listener \<br />    --listener-arn $Service2ListenerArn \<br />    --certificates CertificateArn=$TLS_CERTIFICATE_ARN_TWO \<br />    --ssl-policy ELBSecurityPolicy-2016-08 \<br />    --protocol HTTPS \<br />    --port 8090 \<br />    --mutual-authentication Mode=verify,TrustStoreArn=$TrustStoreArn,IgnoreClientCertificateExpiry=false<br /></pre>자세한 내용은 AWS 설명서의 [ Application Load Balancer에서 상호 TLS 구성을](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/configuring-mtls-with-elb.html) 참조하세요. | AWS DevOps, DevOps 엔지니어 | 

### 서비스 업데이트
<a name="update-the-services"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon ECS 태스크 정의를 업데이트합니다. | Amazon ECS 작업 정의를 업데이트하려면 새 개정에서 `image` 파라미터를 수정합니다.각 서비스의 값을 가져오려면 이전 단계에서 구축한 새 Docker 이미지 Uri로 작업 정의를 업데이트합니다. `echo $ECRRepositoryServiceOneUri` 또는 `echo $ECRRepositoryServiceTwoUri`<pre><br />    "containerDefinitions": [<br />        {<br />            "name": "nginx",<br />            "image": "public.ecr.aws/nginx/nginx:latest",   # <----- change to new Uri<br />            "cpu": 0,</pre>자세한 내용은 AWS 설명서의 콘솔[을 사용하여 Amazon ECS 태스크 정의 업데이트를](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) 참조하세요. | AWS DevOps, DevOps 엔지니어 | 
| Amazon ECS 서비스를 업데이트합니다. | 최신 태스크 정의로 서비스를 업데이트합니다. 이 작업 정의는 새로 빌드된 Docker 이미지의 청사진이며 상호 TLS 인증에 필요한 클라이언트 인증서를 포함합니다. 서비스를 업데이트하려면 다음 절차를 사용합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html)다른 서비스에 대해 단계를 반복합니다. | AWS 관리자, AWS DevOps, DevOps 엔지니어 | 

### 애플리케이션에 액세스
<a name="access-the-application"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 애플리케이션 URL을 복사합니다. | Amazon ECS 콘솔을 사용하여 작업을 봅니다. 태스크 상태가 **실행 중**으로 업데이트되면 태스크을 선택합니다. **작업 **섹션에서 작업 ID를 복사합니다. | AWS 관리자, AWS DevOps | 
| 애플리케이션을 테스트합니다. | 애플리케이션을 테스트하려면 ECS Exec을 사용하여 작업에 액세스합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/simplify-application-authentication-with-mutual-tls-in-amazon-ecs.html) | AWS 관리자, AWS DevOps | 

## 관련 리소스
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-resources"></a>

**Amazon ECS 설명서**
+ [콘솔을 사용하여 Amazon ECS 태스크 정의 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)
+ [Amazon ECS에서 사용할 컨테이너 이미지 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html)
+ [Amazon ECS 클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
+ [용 Amazon ECS AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html#create-container-image-next-steps)
+ [Amazon ECS 네트워킹 모범 사례](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/networking-best-practices.html)
+ [Amazon ECS 서비스 정의 파라미터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)

**기타 AWS 리소스**
+ [AWS 프라이빗 CA를 사용하여 Application Load Balancer에서 mTLS를 구성하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/elb-alb-configure-private-ca-mtls) (AWS re:Post)

## 추가 정보
<a name="simplify-application-authentication-with-mutual-tls-in-amazon-ecs-additional"></a>

**Dockerfile 편집**** **

다음 코드는 서비스 1의 Dockerfile에서 편집하는 명령을 보여줍니다.

```
FROM public.ecr.aws/nginx/nginx:latest
WORKDIR /usr/share/nginx/html
RUN echo "Returning response from Service 1: Ok" > /usr/share/nginx/html/index.html
ADD client_cert1.cert client_private-key1.pem /usr/local/share/ca-certificates/
RUN chmod -R 400 /usr/local/share/ca-certificates/
```

다음 코드는 서비스 2의 Dockerfile에서 편집하는 명령을 보여줍니다.

```
FROM public.ecr.aws/nginx/nginx:latest
WORKDIR /usr/share/nginx/html
RUN echo "Returning response from Service 2: Ok" > /usr/share/nginx/html/index.html
ADD client_cert2.cert client_private-key2.pem /usr/local/share/ca-certificates/
RUN chmod -R 400 /usr/local/share/ca-certificates/
```

CodeBuild를 사용하여 도커 이미지를 빌드하는 경우 `buildspec` 파일은 CodeBuild 빌드 번호를 사용하여 이미지 버전을 태그 값으로 고유하게 식별합니다. 다음 `buildspec `사용자 지정 코드와 같이 요구 사항에 맞게 `buildspec` 파일을 변경할 수 있습니다.

```
version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build:
    commands:
        # change the S3 path depending on the service
      - aws s3 cp s3://$YOUR_S3_BUCKET_NAME/serviceone/ $CodeBuild_SRC_DIR/ --recursive 
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $ECR_REPOSITORY_URI:latest .
      - docker tag $ECR_REPOSITORY_URI:latest $ECR_REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push $ECR_REPOSITORY_URI:latest
      - docker push $ECR_REPOSITORY_URI:$IMAGE_TAG
      - echo Writing image definitions file...
      # for ECS deployment reference
      - printf '[{"name":"%s","imageUri":"%s"}]' $CONTAINER_NAME $ECR_REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json   

artifacts:
  files:
    - imagedefinitions.json
```

# 패턴 더 보기
<a name="containersandmicroservices-more-patterns-pattern-list"></a>

**Topics**
+ [AWS CloudFormation 스택 및 관련 리소스의 삭제 자동화](automate-deletion-cloudformation-stacks-associated-resources.md)
+ [AWS Service Catalog 및를 사용하여 Gitflow 환경에 핫픽스 솔루션을 배포하기 위한 동적 파이프라인 관리 자동화 AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.md)
+ [AWS CDK를 사용하여 마이크로서비스용 CI/CD 파이프라인 및 Amazon ECS 클러스터 자동으로 구축](automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.md)
+ [GitHub Actions 및 Terraform을 사용하여 Docker 이미지를 빌드하고 Amazon ECR에 푸시](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md)
+ [Blu Age로 현대화된 메인프레임 워크로드 컨테이너화](containerize-mainframe-workloads-that-have-been-modernized-by-blu-age.md)
+ [Firelens 로그 라우터를 사용하여 Amazon ECS용 사용자 지정 로그 구문 분석기를 생성](create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.md)
+ [Terraform을 사용하여 CrewAI 프레임워크를 사용하여 Amazon Bedrock에 에이전트 시스템 배포](deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.md)
+ [Terraform을 사용하여 컨테이너화된 Blu Age 애플리케이션을 위한 환경 배포](deploy-an-environment-for-containerized-blu-age-applications-by-using-terraform.md)
+ [Amazon SageMaker의 추론 파이프라인을 사용하여 단일 엔드포인트의 ML 모델에 사전 처리 로직 배포](deploy-preprocessing-logic-into-an-ml-model-in-a-single-endpoint-using-an-inference-pipeline-in-amazon-sagemaker.md)
+ [Azure DevOps 파이프라인에서 프라이빗 Amazon EKS 클러스터로 워크로드 배포](deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.md)
+ [K8sGPT 및 Amazon Bedrock 통합을 사용하여 AI 기반 Kubernetes 진단 및 문제 해결 구현](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md)
+ [AWS 코드 서비스 및 AWS KMS 다중 리전 키를 사용하여 여러 계정 및 리전에 대한 마이크로서비스의 블루/그린 배포를 관리](manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.md)
+ [AWS CDK로 Amazon ECS Anywhere를 설정하여 온프레미스 컨테이너 애플리케이션을 관리](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md)
+ [Amazon ECS에서 Oracle WebLogic으로부터 Apache Tomcat(TomEE)으로 마이그레이션](migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs.md)
+ [조직 간에 데이터를 공유하기 위한 실행 가능한 최소 데이터 공간 설정](minimum-viable-data-space-share-data-organizations.md)
+ [AWS에서 ASP.NET Web Forms 애플리케이션 현대화](modernize-asp-net-web-forms-applications-on-aws.md)
+ [AWS CloudFormation과 AWS Config를 사용하여 Amazon ECR 리포지토리에서 와일드카드 권한 모니터링](monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.md)
+ [CloudWatch Logs Insights를 사용하여 애플리케이션 활동 모니터링](monitor-application-activity-by-using-cloudwatch-logs-insights.md)
+ [AWS CDK 및 GitLab을 사용하여 Amazon ECS Anywhere에서 하이브리드 워크로드를 위한 CI/CD 파이프라인 설정하기](set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.md)
+ [cert-manager 및 Let's Encrypt를 사용하여 Amazon EKS의 애플리케이션에 대한 종단 간 암호화 설정](set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.md)
+ [Flux를 사용하여 Amazon EKS 멀티 테넌트 애플리케이션 배포 간소화](simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.md)
+ [SageMaker AI 및 Hydra를 사용하여 로컬 개발에서 확장 가능한 실험으로 기계 학습 워크플로 간소화](streamline-machine-learning-workflows-by-using-amazon-sagemaker.md)
+ [AWS Lambda를 사용하여 육각형 아키텍처로 Python 프로젝트 구조화](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md)
+ [LocalStack 및 Terraform Tests를 사용하여 AWS 인프라 테스트](test-aws-infra-localstack-terraform.md)
+ [AWS Fargate WaitCondition 후크 구성을 사용하여 리소스 종속성과 작업 실행을 조정합니다.](use-the-aws-fargate-waitcondition-hook-construct.md)
+ [Amazon Bedrock 에이전트를 사용하여 텍스트 기반 프롬프트를 통해 Amazon EKS에서 액세스 항목 제어 생성 자동화](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md)

# 서버리스
<a name="serverless-pattern-list"></a>

**Topics**
+ [Amplify를 사용하여 서버리스 React Native 모바일 앱 구축](build-a-serverless-react-native-mobile-app-by-using-aws-amplify.md)
+ [단일 컨트롤 플레인에서 여러 SaaS 제품의 테넌트 관리](manage-tenants-across-multiple-saas-products-on-a-single-control-plane.md)
+ [정적 IP 주소와 연결된 엔드포인트를 사용하여 Amazon S3 미리 서명된 URL 생성 및 객체 다운로드 통합](consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.md)
+ [조직에서 교차 계정 Amazon EventBridge 연결 생성](create-cross-account-amazon-eventbridge-connection-organization.md)
+ [에서 Kinesis Data Streams 및 Firehose를 사용하여 Amazon S3에 DynamoDB 레코드 전송 AWS CDK](deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.md)
+ [Amazon API Gateway 버전 관리 구현](implement-path-based-api-versioning-by-using-custom-domains.md)
+ [PostgreSQL 데이터베이스와 상호 작용 AWS Lambda 하기 위해 로 psycopg2 라이브러리 가져오기](import-psycopg2-library-lambda.md)
+ [Amazon API Gateway를 Amazon SQS와 통합하여 비동기 REST API 처리](integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.md)
+ [Amazon API Gateway 및 AWS Lambda와 비동기적으로 이벤트 처리](process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.md)
+ [Amazon API Gateway 및 Amazon DynamoDB Streams와 비동기적으로 이벤트 처리](processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.md)
+ [Amazon API Gateway, Amazon SQS 및 AWS Fargate와 비동기적으로 이벤트 처리](process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.md)
+ [AWS Step Functions에서 AWS Systems Manager Automation 작업을 동기적으로 실행](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.md)
+ [AWS Lambda 함수에서 Python을 사용하여 S3 객체의 병렬 읽기 실행](run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.md)
+ [실시간 분석 및 시각화 AWS Lambda 를 위해에서 OpenSearch로 원격 측정 데이터 전송](send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.md)
+ [셀 기반 아키텍처를 위한 서버리스 셀 라우터 설정](serverless-cell-router-architecture.md)
+ [VPC 엔드포인트를 통해 Amazon S3 버킷에 대한 프라이빗 액세스 설정](set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.md)
+ [Amazon Bedrock AWS Step Functions 을 사용하여의 상태 문제 해결](troubleshooting-states-in-aws-step-functions.md)
+ [패턴 더 보기](serverless-more-patterns-pattern-list.md)

# Amplify를 사용하여 서버리스 React Native 모바일 앱 구축
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify"></a>

*Deekshitulu Pentakota, Amazon Web Services*

## 요약
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-summary"></a>

이 패턴은 Amplify 및 다음 서비스를 사용하여 React Native 모바일 앱을 위한 서버리스 백엔드를 생성하는 방법을 보여줍니다.
+ AppSync
+ Amazon Cognito
+ Amazon DynamoDB

Amplify를 사용하여 앱의 백엔드를 구성하고 배포한 후 Amazon Cognito는 앱 사용자를 인증하고 앱 액세스를 승인합니다. 그러면 AppSync가 프런트엔드 앱 및 백엔드 DynamoDB 테이블과 상호 작용하여 데이터를 생성하고 가져옵니다.

**참고**  
이 패턴은 간단한 “TodoList” 앱을 예로 사용하지만 비슷한 절차를 사용하여 모든 React Native 모바일 앱을 만들 수 있습니다.

## 사전 조건 및 제한 사항
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-prereqs"></a>

**사전 조건 **
+ 활성 상태의 계정
+ [Amplify 명령줄 인터페이스(Amplify CLI](https://docs.amplify.aws/cli/start/install/)), 설치 및 구성
+ XCode(모든 버전)
+ Microsoft Visual Studio(모든 버전, 모든 코드 편집기, 모든 텍스트 편집기)
+ Amplify에 대한 지식
+ Amazon Cognito에 대한 지식
+ AppSync에 대한 지식
+ DynamoDB에 대한 지식
+ Node.js에 대한 지식
+ npm에 대한 지식
+ React 및 React Native에 대한 지식
+ JavaScript 및 ECMAScript 6(ES6) 에 대한 지식
+ GraphQL에 대한 지식

## 아키텍처
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-architecture"></a>

다음 다이어그램은 클라우드에서 React Native 모바일 앱의 백엔드를 실행하기 위한 예제 아키텍처를 보여줍니다.

![\[AWS 서비스로 React Native 모바일 앱을 실행하기 위한 워크플로.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/c95e0150-5762-4c90-946c-efa3a22913e4/images/5beff5f9-9d14-49dc-a046-b74e5bfbd13f.png)


다이어그램은 다음 아키텍처를 보여줍니다:

1. Amazon Cognito는 앱 사용자를 인증하고 앱 액세스를 승인합니다.

1. 데이터를 생성하고 가져오기 위해 AppSync는 GraphQL API를 사용하여 프런트엔드 앱 및 백엔드 DynamoDB 테이블과 상호 작용합니다.

## 도구
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-tools"></a>

**서비스**
+ [Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html)는 프런트엔드 웹 및 모바일 개발자가 에서 풀스택 애플리케이션을 빠르고 쉽게 구축할 수 있도록 특별히 제작된 도구 및 기능 세트입니다.
+ [AppSync](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html)는 애플리케이션 개발자가 Amazon DynamoDB, Lambda, HTTP API를 비롯한 여러 소스의 데이터를 결합할 수 있도록 확장 가능한 GraphQL 인터페이스를 제공합니다.
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공합니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.

**코드**

이 패턴에 사용되는 샘플 애플리케이션의 코드는 GitHub [aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) 리포지토리에서 확인할 수 있습니다. 샘플 파일을 사용하려면 이 패턴의 **에픽** 섹션에 있는 지침을 따르십시오.

## 에픽
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-epics"></a>

### React Native 앱 생성 및 실행
<a name="create-and-run-your-react-native-app"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| React Native 개발 환경을 설정합니다. | 자세한 지침은 React Native 문서의 [개발 환경 설정](https://reactnative.dev/docs/next/environment-setup)을 참조하십시오. | 앱 개발자 | 
| iOS 시뮬레이터에서 TodoList React Native 모바일 앱을 만들고 실행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | 앱 개발자 | 

### 앱의 새 백엔드 환경을 초기화합니다.
<a name="initialize-a-new-backend-environment-for-the-app"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amplify에서 앱을 지원하는 데 필요한 백엔드 서비스를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)이 패턴에서 사용되는 TodoList 앱 설정의 경우 다음 예제 구성을 적용하십시오.**React Native Amplify 앱 구성 설정 예시**<pre>? Name: ToDoListAmplify<br /><br />? Environment: dev<br /><br />? Default editor: Visual Studio Code<br /><br />? App type: javascript<br /><br />? Javascript framework: react-native<br /><br />? Source Directory Path: src<br /><br />? Distribution Directory Path: /<br /><br />? Build Command: npm run-script build<br /><br />? Start Command: npm run-script start<br /><br />? Select the authentication method you want to use: AWS profile<br /><br />? Please choose the profile you want to use: default</pre>자세한 내용은 Amplify 개발 센터 설명서에서 [새 Amplify 백엔드 만들기](https://docs.amplify.aws/lib/project-setup/create-application/q/platform/js/#create-a-new-amplify-backend)를 참조하십시오.`amplify init` 명령은 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)을 사용하여 다음 리소스를 프로비저닝합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | 앱 개발자 | 

### Amplify React Native 앱에 Amazon Cognito 인증 추가
<a name="add-amazon-cognito-authentication-to-your-amplify-react-native-app"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon Cognito 인증 서비스를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)이 패턴에서 사용되는 TodoList 앱 설정의 경우 다음 예제 구성을 적용하십시오.**인증 서비스 구성 설정 예시**<pre>? Do you want to use the default authentication and security configuration? \ <br />Default configuration<br /> <br />? How do you want users to be able to sign in? \ <br />Username <br /><br />? Do you want to configure advanced settings? \ <br />No, I am done</pre>`amplify add auth` 명령은 프로젝트의 루트 디렉터리 내 로컬 폴더(**amplify**)에 필요한 폴더, 파일 및 종속성 파일을 만듭니다. 이 패턴에서 사용되는 TodoList 앱 설정의 경우 이 용도로 **aws-exports.js** 파일이 생성됩니다. | 앱 개발자 | 
| Amazon Cognito 서비스를 클라우드에 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)프로젝트에 배포된 서비스를 보려면 다음 명령을 실행하여 Amplify 콘솔로 이동합니다.`amplify console` | 앱 개발자 | 
| React Native에 필요한 Amplify 라이브러리와 iOS용 CocoaPods 종속 프로그램을 설치합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | 앱 개발자 | 
| Amplify 서비스를 가져오고 구성합니다. | 앱의 진입점 파일(예: ** App.js**)에서 다음 코드 줄을 입력하여 Amplify 서비스의 구성 파일을 가져오고 로드합니다.<pre>import Amplify from 'aws-amplify'<br />import config from './src/aws-exports'<br />Amplify.configure(config)</pre>앱의 진입점 파일에서 Amplify 서비스를 가져온 후 오류가 발생하면 앱을 중지하십시오. 그런 다음 XCode를 열고 프로젝트의 iOS 폴더에서 **ToDoListAmplify.xcworkspace** 작업 영역을 선택하고 앱을 실행합니다. | 앱 개발자 | 
| withAuthenticator 고차 구성 요소(HOC)를 사용하도록 앱의 진입점 파일을 업데이트하십시오. | `withAuthenticator` HOC는 단 몇 줄의 코드만으로 앱의 로그인, 가입 및 비밀번호 분실 워크플로를 제공합니다. 자세한 내용은 Amplify Dev 센터의 [옵션 1: 사전 빌드 UI 구성 요소 사용](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#option-1-use-pre-built-ui-components)을 참조하십시오. 또한 React 설명서에 있는 [고차 컴포넌트](https://reactjs.org/docs/higher-order-components.html)도 있습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)**withAuthenticator HOC 코드 예제**<pre>import Amplify from 'aws-amplify'<br />import config from './src/aws-exports'<br />Amplify.configure(config)<br />import { withAuthenticator } from 'aws-amplify-react-native';<br /><br /><br />const App = () => {<br />  return null;<br />};<br /><br /><br />export default withAuthenticator(App);</pre>iOS 시뮬레이터에서 앱은 Amazon Cognito 서비스에서 제공하는 로그인 화면을 표시합니다. | 앱 개발자 | 
| 인증 서비스 설정을 테스트하십시오. | iOS 시뮬레이터에서 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)[Amazon Cognito 콘솔](https://console.aws.amazon.com/cognito/)을 열고 **ID 풀**에 새 사용자가 생성되었는지 여부를 확인할 수도 있습니다. | 앱 개발자 | 

### AppSync API와 DynamoDB 데이터베이스를 앱에 연결
<a name="connect-an-aws-appsync-api-and-dynamodb-database-to-the-app"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AppSync API 및 DynamoDB 데이터베이스를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)이 패턴에서 사용되는 TodoList 앱 설정의 경우 다음 예제 구성을 적용하십시오.**API 및 데이터베이스 구성 설정 예시**<pre>? Please select from one of the below mentioned services: \ <br />GraphQL <br /><br />? Provide API name: todolistamplify<br /><br />? Choose the default authorization type for the API \ <br />Amazon Cognito User Pool<br /><br />Do you want to use the default authentication and security configuration<br /><br />? Default configuration How do you want users to be able to sign in? \ <br />Username<br /><br />Do you want to configure advanced settings? \ <br />No, I am done.<br /><br />? Do you want to configure advanced settings for the GraphQL API \ <br />No, I am done.<br /><br />? Do you have an annotated GraphQL schema? \ <br />No<br /><br />? Choose a schema template: \ <br />Single object with fields (e.g., "Todo" with ID, name, description)<br /><br />? Do you want to edit the schema now? \ <br />Yes</pre>**예제 GraphQL 스키마**<pre> type Todo @model {<br />   id: ID!<br />   name: String!<br />   description: String<br />}</pre> | 앱 개발자 | 
| AppSync API를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html)이 패턴에서 사용되는 TodoList 앱 설정의 경우 다음 예제 구성을 적용하십시오.**AppSync API 구성 설정의 예**다음 구성은 AppSync에 GraphQL API를 생성하고 Dynamo DB에 **Todo** 테이블을 생성합니다.<pre> ? Are you sure you want to continue? Yes<br />? Do you want to generate code for your newly created GraphQL API Yes<br />? Choose the code generation language target javascript<br />? Enter the file name pattern of graphql queries, mutations and subscriptions src/graphql/**/*.js<br />? Do you want to generate/update all possible GraphQL operations - \ <br />queries, mutations and subscriptions Yes<br />? Enter maximum statement depth \<br />[increase from default if your schema is deeply nested] 2</pre> | 앱 개발자 | 
| 앱의 프론트엔드를 AppSync API에 연결합니다. | 이 패턴으로 제공된 예제 TodoList 앱을 사용하려면 [aws-amplify-react-native-ios-todo-app](https://github.com/aws-samples/aws-amplify-react-native-ios-todo-app) GitHub 리포지토리의 **App.js** 파일에서 코드를 복사하십시오. 그런 다음 예제 코드를 로컬 환경에 통합하십시오.리포지토리의 **App.js** 파일에 제공된 예제 코드는 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/build-a-serverless-react-native-mobile-app-by-using-aws-amplify.html) | 앱 개발자 | 

## 관련 리소스
<a name="build-a-serverless-react-native-mobile-app-by-using-aws-amplify-resources"></a>
+ [Amplify](https://aws.amazon.com/amplify/)
+ [Amazon Cognito](https://aws.amazon.com/cognito/)
+ [AppSync](https://aws.amazon.com/appsync/)
+ [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)
+ [React](https://reactjs.org/) (React 문서) 

# 단일 컨트롤 플레인에서 여러 SaaS 제품의 테넌트 관리
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane"></a>

*Ramanna Avancha, Kishan Kavala, Anusha Mandava, Jenifer Pascal, Amazon Web Services*

## 요약
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-summary"></a>

이 패턴은 AWS 클라우드의 단일 컨트롤 플레인에서 여러 서비스형 소프트웨어(SaaS) 제품의 테넌트 수명 주기를 관리하는 방법을 보여줍니다. 제공된 참조 아키텍처는 조직이 개별 SaaS 제품에서 중복 및 공유된 기능의 구현을 줄이고 규모에 맞는 거버넌스 효율성을 제공하는 데 도움이 될 수 있습니다.

대기업은 대체로 다양한 사업부에서 여러 SaaS 제품을 보유합니다. 이러한 제품은 외부 테넌트가 다양한 구독 수준에서 사용할 수 있도록 프로비저닝해야 하는 경우가 많습니다. 공통 테넌트 솔루션이 없으면 IT 관리자는 핵심 제품 기능 개발에 집중하는 대신 여러 SaaS API에서 차별화되지 않은 기능을 관리하는 데 시간을 할애해야 합니다.

이 패턴으로 제공되는 공통 테넌트 솔루션은 다음을 포함하여 조직의 여러 공유 SaaS 제품 기능을 중앙 집중식으로 관리하는 데 도움이 될 수 있습니다.
+ 보안
+ 테넌트 프로비저닝
+ 테넌트 데이터 스토리지
+ 테넌트 커뮤니케이션
+ 제품 관리
+ 지표 로깅 및 모니터링

## 사전 조건 및 제한 사항
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정
+ Amazon Cognito 또는 타사 ID 제공업체(IdP)에 대한 지식
+ Amazon API Gateway에 대한 지식
+ AWS Lambda에 대한 지식
+ Amazon DynamoDB에 대한 지식
+ AWS Identity and Access Management(IAM)에 대한 지식
+ AWS Step Functions에 대한 지식
+ AWS CloudTrail 및 Amazon CloudWatch에 대한 지식
+ Python 라이브러리 및 코드에 대한 지식
+ 다양한 유형의 사용자(조직, 테넌트, 관리자, 애플리케이션 사용자), 구독 모델, 테넌트 격리 모델을 비롯한 SaaS API에 대한 지식
+ 조직의 다중 제품 SaaS 요구 사항 및 멀티테넌트 구독에 대한 지식

**제한 사항 **
+ 공통 테넌트 솔루션과 개별 SaaS 제품 간의 통합은 이 패턴에서 다루지 않습니다.
+ 이 패턴은 Amazon Cognito 서비스를 단일 AWS 리전에만 배포합니다.

## 아키텍처
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-architecture"></a>

**대상 기술 스택  **
+ Amazon API Gateway
+ Amazon Cognito
+ AWS CloudTrail
+ Amazon CloudWatch
+ Amazon DynamoDB
+ IAM
+ AWS Lambda
+ Amazon Simple Storage Service (S3)
+ Amazon Simple Notification Service(SNS)
+ AWS Step Functions

**대상 아키텍처 **

다음 다이어그램은 AWS 클라우드의 단일 컨트롤 플레인에서 여러 SaaS 제품의 테넌트 수명 주기를 관리하는 워크플로 예제를 보여줍니다.

![\[단일 컨트롤 플레인에서 테넌트 수명 주기를 관리하기 위한 워크플로.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/4306bc76-22a7-45ca-a107-43df6c6f7ac8/images/700faf4d-c28f-4814-96aa-2d895cdcb518.png)


 이 다이어그램은 다음 워크플로를 보여줍니다.

1. AWS 사용자는 API Gateway 엔드포인트를 직접적으로 호출하여 테넌트 프로비저닝, 제품 프로비저닝 또는 관리 관련 작업을 시작합니다.

1. 이 사용자는 Amazon Cognito 사용자 풀 또는 다른 IdP에서 검색된 액세스 토큰으로 인증됩니다.

1. 개별 프로비저닝 또는 관리 작업은 API Gateway API 엔드포인트와 통합된 Lambda 함수에 의해 실행됩니다.

1. 일반 테넌트 솔루션용(테넌트, 제품 및 사용자용) 관리 API는 필요한 입력 파라미터, 헤더 및 토큰을 모두 수집합니다. 그런 다음 관리 API가 관련 Lambda 함수를 간접적으로 호출합니다.

1. 관리 API와 Lambda 함수 모두에 대한 IAM 권한은 IAM 서비스에 의해 검증됩니다.

1. Lambda 함수는 DynamoDB 및 Amazon S3의 카탈로그(테넌트, 제품 및 사용자용)를 저장하고 데이터를 검색합니다.

1. 권한이 검증되면 AWS Step Functions 워크플로가 간접적으로 호출되어 특정 업무를 수행합니다. 다이어그램의 예제는 테넌트 프로비저닝 워크플로를 보여줍니다.

1. 개별 AWS Step Functions 워크플로 업무는 미리 정해진 워크플로(상태 머신)에서 실행됩니다.

1. 각 워크플로 업무와 관련된 Lambda 함수를 실행하는 데 필요한 모든 필수 데이터는 DynamoDB 또는 Amazon S3에서 검색됩니다. 다른 AWS 리소스는 AWS CloudFormation 템플릿을 사용하여 프로비저닝되어야 할 수 있습니다.

1. 필요한 경우 워크플로는 특정 SaaS 제품에 대한 추가 AWS 리소스를 해당 제품의 AWS 계정에 프로비저닝하라는 요청을 보냅니다.

1. 이 요청이 성공하거나 실패하면 워크플로는 상태 업데이트를 Amazon SNS 주제에 메시지로 게시합니다.

1. Amazon SNS는 Step Functions 워크플로의 Amazon SNS 주제를 구독하고 있습니다.

1. 그러면 Amazon SNS에서는 AWS 사용자에게 워크플로 상태 업데이트를 다시 보냅니다.

1. API 직접 호출의 감사 추적을 포함하여 각 AWS 서비스의 작업 로그가 CloudWatch로 전송됩니다. CloudWatch에서 각 사용 사례에 대한 특정 규칙 및 경보를 구성할 수 있습니다.

1. 로그는 감사 목적으로 Amazon S3 버킷에 보관됩니다.

**자동화 및 규모 조정**

이 패턴은 공통 테넌트 솔루션의 배포를 자동화하기 위하여 CloudFormation 템플릿을 사용합니다. 또한 템플릿을 사용하면 관련 리소스를 빠르게 확장하거나 축소할 수 있습니다.

자세한 내용은 *AWS CloudFormation 사용 설명서*의 [AWS CloudFormation 템플릿 사용](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)을 참조하세요.

## 도구
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-tools"></a>

**서비스**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)는 규모와 관계없이 REST, HTTP 및 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호하는 것을 지원합니다.
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공합니다.
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)은 AWS 계정 의 거버넌스, 규정 준수, 운영 위험을 감사하는 데 도움이 됩니다.
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)는 AWS 리소스의 지표와 AWS에서 실시간으로 실행되는 애플리케이션을 모니터링합니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ [AWS Identity and Access Management(IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)를 사용하면 사용자에 대해 인증 및 권한 부여를 제어함으로써 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있습니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Storage Service(Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 AWS Lambda 함수와 기타 AWS 서비스를 결합할 수 있는 서버리스 오케스트레이션 서비스로, 비즈니스 크리티컬 애플리케이션을 구축합니다.

## 모범 사례
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-best-practices"></a>

이 패턴의 솔루션은 단일 컨트롤 플레인을 사용하여 여러 테넌트의 온보딩을 관리하고, 여러 SaaS 제품에 대한 액세스를 프로비저닝합니다. 컨트롤 플레인은 관리 사용자가 다음 네 가지 기능별 영역을 관리하는 데 도움이 됩니다.
+ 보안 영역
+ 워크플로 영역
+ 통신 영역
+ 로깅 및 모니터링 영역

## 에픽
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-epics"></a>

### 보안 플레인 구성
<a name="configure-the-security-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 멀티테넌트 SaaS 플랫폼에 대한 요구 사항을 설정합니다. | 다음에 대한 세부 요구 사항을 설정하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | 클라우드 아키텍트, AWS 시스템 관리자 | 
| Amazon Cognito 서비스를 설정합니다. | *Amazon Cognito 개발자 안내서*의 [Amazon Cognito 시작하기](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-getting-started.html)에 나와 있는 지침을 따르세요. | 클라우드 아키텍트 | 
| 필수 IAM 정책을 구성합니다. | 사용 사례에 필요한 IAM 정책을 생성합니다. 그런 다음 정책을 Amazon Cognito의 IAM 역할에 매핑합니다.자세한 내용은 *Amazon Cognito 개발자 안내서*의 [정책을 사용한 액세스 관리](https://docs.aws.amazon.com/cognito/latest/developerguide/security-iam.html#security_iam_access-manage)와 [역할 기반 액세스 제어](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)를 참조하세요. | 클라우드 관리자, 클라우드 아키텍트, AWS IAM 보안 | 
| 필요한 API 권한을 구성합니다. | IAM 역할 및 정책, Lambda 권한 부여자를 사용하여 API Gateway 액세스 권한을 설정합니다.지침은 *Amazon API Gateway 개발자 안내서*의 다음 섹션을 참조하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | 클라우드 관리자, 클라우드 아키텍트 | 

### 데이터 영역 구성
<a name="configure-the-data-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 필요한 데이터 카탈로그를 만드세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)자세한 내용을 알아보려면 *Amazon DynamoDB 개발자 안내서*의 [DynamoDB란 무엇인가요?](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SettingUp.html)를 참조하세요. | DBA | 

### 컨트롤 플레인 설정
<a name="configure-the-control-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda 함수 및 API Gateway API를 생성하여 필요한 컨트롤 플레인 작업을 실행합니다. | 별도의 Lambda 함수와 API Gateway API를 생성하여 다음을 추가, 삭제 및 관리합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)자세한 내용은* AWS Lambda 개발자 안내서*의 [Amazon RDS와 함께 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html)을 참조하세요. | 앱 개발자 | 

### 워크플로 영역 구성
<a name="configure-the-workflow-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS Step Functions 워크플로에서 실행해야 할 작업을 파악합니다. | 다음에 대한 AWS Step Functions 워크플로 요구 사항을 상세하게 파악하고 문서화하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)주요 이해 관계자가 요구 사항을 승인했는지 확인하세요. | 앱 소유자 | 
| 필요한 AWS Step Functions 워크플로를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html) | 앱 개발자, 빌드 리더 | 

### 통신 영역 구성
<a name="configure-the-communication-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Amazon SNS 주제를 생성합니다. | Amazon SNS 주제를 생성하여 다음에 대한 알림을 받아봅니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)자세한 정보는 *Amazon SNS 개발자 안내서*의 [SNS 주제 생성](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html)을 참조하세요. | 앱 소유자, 클라우드 아키텍트 | 
| 각 Amazon SNS 주제에 엔드포인트 구독을 선택합니다. | Amazon SNS 주제에 게시된 메시지를 수신하려면 엔드포인트에서 해당 주제를 구독해야 합니다.자세한 정보는 *Amazon SNS 개발자 안내서*에서 [Amazon SNS 주제 구독](https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html)을 참조하세요. | 앱 개발자, 클라우드 아키텍트 | 

### 로깅 및 모니터링 영역 구성
<a name="configure-the-logging-and-monitoring-plane"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 공통 테넌트 솔루션의 각 구성 요소에 대한 로깅을 활성화합니다. | 생성한 공통 테넌트 솔루션의 각 리소스에 대해 구성 요소 수준에서 로깅을 활성화합니다.지침은 다음을 참조하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)IAM 정책을 사용하여 각 리소스의 로그를 중앙 집중식 로깅 계정으로 통합할 수 있습니다. 자세한 내용은 [중앙 집중식 로깅 및 다중 계정 보안 가드레일](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/centralized-logging-and-multiple-account-security-guardrails.html)을 참조하세요. | AWS 시스템 관리자, 클라우드 관리자, DevOps 엔지니어 | 

### 공통 테넌트 솔루션 프로비저닝 및 배포
<a name="provision-and-deploy-the-common-tenant-solution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudFormation 템플릿을 생성합니다. | CloudFormation 템플릿을 사용하여 전체 공통 테넌트 솔루션과 모든 구성 요소의 배포 및 유지 관리를 자동화합니다.자세한 내용은 [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)를 참조하세요. | 앱 개발자, DevOps 엔지니어, CloudFormation 개발자 | 

## 관련 리소스
<a name="manage-tenants-across-multiple-saas-products-on-a-single-control-plane-resources"></a>
+ [Amazon Cognito 사용자 풀을 권한 부여자로 사용하여 REST API에 대한 액세스 제어](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)(*API Gateway 개발자 가이드*)
+ [API Gateway Lambda 권한 부여자 사용](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)(*Amazon API Gateway 개발자 가이드*)
+ [Amazon Cognito 사용자 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)(*Amazon Cognito 개발자 안내서*)
+ [교차 계정 교차 리전 CloudWatch 콘솔](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)(*Amazon CloudWatch 사용 설명서*)

# 정적 IP 주소와 연결된 엔드포인트를 사용하여 Amazon S3 미리 서명된 URL 생성 및 객체 다운로드 통합
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses"></a>

*Amazon Web Services의 송진, 조은혜, 이준성*

## 요약
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-summary"></a>

이 패턴은 객체 다운로드를 위해 안전한 사용자 지정 미리 서명된 URL을 생성하여 Amazon Simple Storage Service(Amazon S3)에 대한 액세스를 간소화합니다. 솔루션은 고유한 도메인과 고정 IP 주소가 있는 단일 엔드포인트를 제공합니다. 정적 IP 주소가 있는 통합 도메인에서 API 및 Amazon S3 엔드포인트를 통합해야 하는 고객을 위해 조정되었습니다. 사용 사례에는 IP 및 도메인 허용 목록 방화벽 정책을 따르는 사용자가 포함되며, API 액세스를 특정 도메인 및 IP 주소로 제한합니다.

아키텍처는 Amazon API Gateway AWS Global Accelerator, AWS Lambda Application Load Balancer AWS PrivateLink및 Amazon S3를 AWS 서비스포함한 키를 사용합니다. 이 설계는 미리 서명된 URL과 정적 IP 주소 2개가 있는 액셀러레이터에 연결된 단일 도메인에서 Amazon S3 엔드포인트를 중앙 집중화합니다. 따라서 사용자는 미리 서명된 URL을 손쉽게 요청하고 정적 IP 주소가 있는 통합 도메인 엔드포인트를 통해 Amazon S3 객체를 다운로드할 수 있습니다.

이 아키텍처는 퍼블릭, 의료 및 금융 부문과 같은 엄격한 정책 또는 규정 준수 요구 사항이 있는 고객에게 특히 유용합니다.

## 사전 조건 및 제한 사항
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ 사용자 지정 도메인의 퍼블릭 호스팅 영역 삭제
+  AWS 리전 선택한의 AWS Certificate Manager (ACM)에서 가져온 도메인

**제한 사항 **
+ 레코드의 이름은 Amazon S3 버킷의 이름과 일치해야 합니다. 이 요구 사항은 Amazon S3 엔드포인트가 단일 API 엔드포인트를 통해 제공될 수 있도록 하기 위한 것입니다.
+ API Gateway에 사용되는 사용자 지정 도메인 이름은 단일 API 엔드포인트의 도메인 이름과 일치해야 합니다.
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전별 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)을 참조하고 서비스 링크를 선택합니다.

## 아키텍처
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-architecture"></a>

다음 다이어그램은 이 패턴의 워크플로 및 구성 요소를 보여 줍니다.

![\[미리 서명된 URL 생성 및 객체 다운로드를 위한 구성 요소 및 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e19ebcb5-2138-481e-952e-3cfee9ad9e97/images/effd197c-d4d7-4990-8b66-3eb1c64aab4c.png)


다이어그램은 다음 워크플로를 보여줍니다:

1. 사용자는 사용자 지정 도메인 이름 및 연결된 IP 주소를 사용하여 서비스되는 사용자 지정 엔드포인트를 AWS Global Accelerator사용하여 미리 서명된 URL을 생성하라는 요청을 시작합니다.

1. Lambda 함수는 사용자 지정 엔드포인트를 가리키는 미리 서명된 URL을 생성합니다. 미리 서명된 URL이 포함된 301 리디렉션으로 응답합니다. 미리 서명된 리디렉션 URL을 통해 사용자는 Global Accelerator를 통해 제공되는 사용자 지정 엔드포인트를 사용하여 객체를 자동으로 다운로드합니다.

미리 서명된 URL 생성 및 객체 다운로드 워크플로를 위한 전체 아키텍처의 구성 요소는 다음과 같습니다.
+ Global Accelerator에 의한 고정 IP 주소 프로비저닝.
+ 사용자 지정 도메인 이름을 사용하여 Amazon Route 53 퍼블릭 호스팅 영역에 액셀러레이터의 별칭을 A 레코드로 등록합니다.
+ 등록된 사용자 지정 도메인 이름과 일치하는 버킷 이름으로 Amazon S3 버킷 생성.
+ API Gateway 및 Amazon S3 서비스를 위한 VPC 엔드포인트 생성.
+ Global Accelerator에 연결하기 위한 내부 Application Load Balancer의 구성입니다.
+ ACM 인증서가 연결된 API Gateway에 대한 사용자 지정 도메인 이름 할당.
+ Lambda 함수와 통합된 프라이빗 API Gateway 배포.
+ Lambda 함수에는 AWS Identity and Access Management (IAM) 역할이 연결되어 있습니다([GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) 권한 있음).

## 도구
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-tools"></a>

**AWS 서비스**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)는 규모와 관계없이 REST, HTTP 및 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호하는 것을 지원합니다.
+ [Application Load Balance](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)는 여러 가용 영역에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 같은 여러 대상에 수신 애플리케이션 트래픽을 분산합니다.
+ [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)을 사용하면 웹 AWS 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 생성, 저장 및 갱신할 수 있습니다.
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)는 코드로 AWS 클라우드 인프라를 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ Global Accelerator는 여러 의 엔드포인트를 지원하는 글로벌 서비스입니다. AWS 글로벌 네트워크를 통해 트래픽을 최적의 엔드포인트로 보내는 액셀러레이터를 생성할 수 있습니다. 이렇게 하면 전 세계 사용자가 이용하는 인터넷 애플리케이션의 가용성과 성능이 향상됩니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)는 Virtual Private Cloud(VPC)에서 VPC 외부 서비스로의 단방향 프라이빗 연결을 생성하는 데 도움이 됩니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.

**기타 도구**
+ [Terraform](https://www.terraform.io/)은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

**코드 리포지토리**

기본 설정에 따라 AWS CDK 또는 Terraform을 사용하여이 패턴을 배포할 수 있습니다. [에픽](#consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-epics) 섹션에는 두 배포 방법에 대한 지침이 포함되어 있습니다. 이 패턴의 코드는 GitHub unloaddb2 리포지토리에서 확인할 수 있습니다.
+ **AWS CDK** – [s3-presignedurl-staticips-endpoint-with-cdk](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-cdk)
+ **Terraform** – [s3-presignedurl-staticips-endpoint-with-terraform](https://github.com/aws-samples/s3-presignedurl-staticips-endpoint-with-terraform)

## 모범 사례
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-best-practices"></a>
+ 프로덕션 환경에서 보안을 강화하려면 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)와 같은 권한 부여 메커니즘을 구현하여 `PresignedUrl` 생성 API에 대한 액세스를 제한하는 것이 중요합니다.
+ 최소 권한 원칙을 따르고 작업을 수행하는 데 필요한 최소 권한을 부여하세요. 자세한 내용은 IAM 설명서의 [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv) 및 [보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.

## 에픽
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-epics"></a>

### 환경 준비
<a name="prepare-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 도메인 이름을 결정합니다. | 통합 Amazon S3 엔드포인트의 퍼블릭 도메인 이름을 결정합니다. 도메인 이름은 Amazon S3 버킷 이름으로도 사용됩니다. | AWS 시스템 관리자, 네트워크 관리자 | 
| 퍼블릭 호스팅 영역을 만듭니다. | Route 53에서 퍼블릭 호스팅 영역을 생성합니다. 도메인 이름은 API Gateway에서 사용되는 도메인 이름과 일치해야 합니다. | AWS 시스템 관리자, 네트워크 관리자 | 
| SSL 인증서를 준비합니다. |  AWS Certificate Manager (ACM)을 사용하여 웹 애플리케이션 도메인에 대한 SSL 인증서를 [요청](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html)하거나 [가져옵니다](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html). | AWS 시스템 관리자, 네트워크 관리자 | 

### Terraform을 사용하여 패턴 배포
<a name="deploy-the-pattern-with-terraform"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| .NET 개발 환경 설정 | 개발 환경을 설정하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 관리자, 클라우드 관리자 | 
| `.tfvars` 및 ** **`provider.tf` 파일을 수정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html)**다음을 참조하세요.**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 관리자, 클라우드 관리자 | 
| 네트워크 리소스를 프로비저닝합니다. | 네트워크 리소스를 프로비저닝하려면 다음 명령을 실행합니다.<pre>cd ./2.vpc_alb_ga<br />terraform init<br />terraform plan --var-file=apg.tfvars<br />terraform apply --var-file=apg.tfvars</pre>`apply `명령을 실행하는 동안 메시지가 표시되면 **yes**를 입력합니다. | AWS 관리자, 클라우드 관리자 | 
| API Gateway, Amazon S3 및 Lambda를 프로비저닝합니다. | 네트워크 리소스를 프로비저닝하려면 다음 명령을 사용합니다.<pre>cd ./2.apigw_s3_lambda<br />terraform init<br />terraform plan --var-file=apg.tfvars<br />terraform apply --var-file=apg.tfvars</pre> | AWS 관리자, 클라우드 관리자 | 

### 를 사용하여 패턴 배포 AWS CDK
<a name="deploy-the-pattern-with-cdk"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS CDK 개발 환경을 설정합니다. | 개발 환경을 설정하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 관리자, 클라우드 관리자 | 
| `config/index.ts` 파일에서 도메인 설정을 구성합니다. | 상수 변수의 옵션을 편집하려면 다음 명령을 사용합니다.<pre>export const options = {<br />    certificateArn: '{arn of the acm which created before}',<br />    dnsAttr: {<br />        zoneName: '{public hosted zone name}',<br />        hostedZoneId: 'hosted zone Id',<br />    },<br />    domainNamePrefix: '{Prefix for the domain}',<br />    presignPath: 'presign',<br />    objectsPath: 'objects',<br />};</pre>다음 예시에서 각 자리 표시자를 자신의 정보로 바꿉니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.html) | AWS 관리자, 클라우드 관리자 | 
| 스택을 배포합니다. | Virtual Private Cloud(VPC)용 스택과 애플리케이션용 스택의 두 스택을 배포하려면 다음 명령을 사용합니다.<pre>$ npm install <br />$ cdk synth <br />$ cdk deploy --all</pre> | AWS 관리자, 클라우드 관리자 | 

### 패턴 테스트
<a name="test-the-pattern"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 서버 엔드포인트의 IP 주소입니다. | 이 패턴의 도메인에 고정 IP 주소가 있는지 확인하려면 다음 명령을 사용합니다.<pre>nslookup ${s3-bucket-prefix}.${domain}</pre> | 네트워크 관리자 | 
| 나중에 다운로드할 수 있는 테스트 파일을 업로드합니다. | Amazon S3 버킷의 `'/objects'` 폴더에 테스트 파일을 업로드합니다. | AWS 관리자, 클라우드 관리자 | 
| 을 사용하여 미리 서명된 URL을 생성하려면 | 미리 서명된 URL을 생성하려면 다음 형식을 사용하여 브라우저 또는 API 클라이언트(예: [Postman](https://www.postman.com/product/what-is-postman/))에서 URL을 직접적으로 호출합니다.<pre>https://${s3-bucket-prefix}.${domain}/presign/objects/${uploaded-filename}</pre>`${s3-bucket-prefix}` 및의 자리 표시자 값을 이전 단계에서 설정한 `${domain}` 값으로 바꿉니다. | 앱 소유자 | 
| 결과를 확인합니다. | 예상되는 결과는 301(영구 이동됨) 리디렉션 상태 코드를 받아야 한다는 것입니다. 이 응답에는 테스트 파일 다운로드를 자동으로 시작하는 미리 서명된 URL이 포함됩니다. | 테스트 엔지니어 | 

### Terraform으로 정리
<a name="clean-up-with-terraform"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| API Gateway, Amazon S3 및 Lambda 리소스를 폐기합니다. | 다음 명령을 사용하여 리소스를 삭제합니다.<pre>cd ./2.apigw_s3_lambda<br />terraform init<br />terraform plan --destroy --var-file=apg.tfvars<br />terraform destroy --var-file=apg.tfvars<br /></pre> | AWS 관리자, 클라우드 관리자 | 
| 네트워크 리소스를 폐기합니다. | 다음 명령을 사용하여 리소스를 삭제합니다.<pre>cd ./1.vpc_alb_ga<br />terraform init<br />terraform plan --destroy --var-file=apg.tfvars<br />terraform destroy --var-file=apg.tfvars<br /></pre> | AWS 관리자, 클라우드 관리자 | 

### 를 사용하여 정리 AWS CDK
<a name="clean-up-with-cdk"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 스택을 폐기합니다. | VPC 스택과 애플리케이션 스택을 모두 삭제하려면 다음 명령을 사용합니다.<pre>$ cdk destroy --all</pre> | AWS 관리자, 클라우드 관리자 | 
| Amazon S3 버킷을 비우고 삭제하려면 | 기본적으로 [삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)되지 않은 객체 Amazon S3 버킷과 로그 Amazon S3 버킷을 [비우](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)고 삭제합니다.Amazon S3 버킷 이름은 `${s3-bucket-prefix}.${domain}` 및 입니다`${s3-bucket-prefix}.${domain}-logs`.[AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)를 사용하여 버킷을 삭제하려면 다음 명령을 사용합니다.<pre>$ aws s3 rm s3://${s3-bucket-prefix}.${domain} --recursive<br />$ aws s3 rb s3://${s3-bucket-prefix}.${domain} --force<br />$ aws s3 rm s3://${s3-bucket-prefix}.${domain}-logs --recursive<br />$ aws s3 rb s3://${s3-bucket-prefix}.${domain}-logs --force</pre>`${s3-bucket-prefix}` 및 `${domain}`를 이전 단계에서 반환된 값으로 바꿉니다. | AWS 관리자, 클라우드 관리자 | 

## 관련 리소스
<a name="consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses-resources"></a>

**AWS 블로그**
+ [에서 제공하는 고정 IP 주소를 통해 Amazon API Gateway에 액세스 AWS Global Accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/accessing-an-aws-api-gateway-via-static-ip-addresses-provided-by-aws-global-accelerator/) 
+ [JavaScript AWS CDK 용 모듈식으로 미리 서명된 URL 생성](https://aws.amazon.com/blogs/developer/generate-presigned-url-modular-aws-sdk-javascript/) 
+ [ALB, S3 및 PrivateLink를 사용하여 내부 HTTPS 정적 웹 사이트 호스팅](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/) 

# 조직에서 교차 계정 Amazon EventBridge 연결 생성
<a name="create-cross-account-amazon-eventbridge-connection-organization"></a>

*Sam Wilson과 Robert Stone, Amazon Web Services*

## 요약
<a name="create-cross-account-amazon-eventbridge-connection-organization-summary"></a>

대규모 분산 시스템은 Amazon EventBridge를 사용하여 AWS Organizations 조직의 다양한 Amazon Web Services(AWS) 계정 간에 상태 변경을 전달합니다. 그러나 EventBridge는 일반적으로 동일한의 엔드포인트 또는 소비자만 대상으로 지정할 수 있습니다 AWS 계정. 다른 계정의 이벤트 버스는 예외입니다. 해당 이벤트 버스는 유효한 대상입니다. 다른 계정의 이벤트 버스에서 이벤트를 사용하려면 이벤트를 소스 계정의 이벤트 버스에서 대상 계정의 이벤트 버스로 푸시해야 합니다. 여러 내의 애플리케이션에서 중요한 이벤트를 관리할 때 발생하는 문제를 방지하려면이 패턴에 제시된 권장 접근 방식을 AWS 계정사용합니다.

이 패턴은 AWS Organizations 조직의 여러를 포함하는 EventBridge를 사용하여 이벤트 기반 아키텍처 AWS 계정 를 구현하는 방법을 보여줍니다. 패턴은 AWS Cloud Development Kit (AWS CDK) Toolkit 및를 사용합니다 AWS CloudFormation.

EventBridge는 이벤트를 수신, 필터링, 변환, 라우팅 및 전송하는 데 도움이 되는 서버리스 이벤트 버스를 제공합니다. 이벤트 기반 아키텍처의 중요한 구성 요소인 EventBridge는 메시지 생산자와 해당 메시지 소비자 간의 분리를 지원합니다. 단일 계정에서 이는 간단합니다. 다중 계정 구조를 사용하려면 한 계정의 이벤트 버스에서 이벤트를 동일한 조직 내의 다른 계정에서 사용하기 위한 추가 고려 사항이 필요합니다.

생산자 및 소비자의 계정별 고려 사항에 대한 자세한 내용은 [추가 정보](#create-cross-account-amazon-eventbridge-connection-organization-additional) 섹션을 참조하세요.

## 사전 조건 및 제한 사항
<a name="create-cross-account-amazon-eventbridge-connection-organization-prereqs"></a>

**사전 조건 **
+ 둘 이상의 연결된 AWS Organizations 조직이 있는 경우 AWS 계정
+ 를 AWS 계정 사용하여 두에서 인프라를 프로비저닝할 수 AWS 계정 있는 ( AWS Identity and Access Management IAM) 역할 AWS CloudFormation
+ [로컬에 설치된](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) Git
+ AWS Command Line Interface [로컬에 설치된](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (AWS CLI)
+ AWS CDK [로컬에 설치](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)되고 둘 다에 [부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto)됨 AWS 계정

**제품 버전**

이 패턴은 다음 도구 및 버전을 사용하여 구축 및 테스트되었습니다.
+ AWS CDK 도구 키트 2.126.0
+ Node.js 18.19.0
+ npm 10.2.3
+ Python 3.12

이 패턴은 모든 버전의 AWS CDK v2 또는 npm에서 작동해야 합니다. 참고로 Node.js 버전 13.0.0부터 13.6.0까지는 AWS CDK와 호환되지 않습니다.

## 아키텍처
<a name="create-cross-account-amazon-eventbridge-connection-organization-architecture"></a>

**대상 아키텍처**

다음 다이어그램은 한 계정에서 이벤트를 푸시하고 다른 계정에서 사용하기 위한 아키텍처 워크플로를 보여줍니다.

![\[소스 생산자 계정과 대상 소비자 계정을 연결하는 3단계 프로세스입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/34a5f3ae-511d-4636-999f-c73396770117/images/ccc4878a-6281-4a77-a483-4e6f299d7807.png)


워크플로우는 다음 단계로 구성됩니다.

1. 소스 계정의 생산자 AWS Lambda 함수는 계정의 EventBridge 이벤트 버스에 이벤트를 배치합니다.

1. 교차 계정 EventBridge 규칙은 대상 계정의 EventBridge 이벤트 버스로 이벤트를 라우팅합니다.

1. 대상 계정의 EventBridge 이벤트 버스에는 소비자 Lambda 함수를 간접적으로 호출하는 대상 Lambda 규칙이 있습니다.

소비자 Lambda 함수의 실패한 간접 호출을 처리하기 위해 [DLQ(Dead Letter Queue)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)를 사용하는 것이 가장 좋습니다. 그러나 명확성을 위해 DLQ가이 솔루션에서 생략되었습니다. 워크플로에서 DLQ를 구현하고 실패로부터 복구하는 워크플로의 기능을 개선하는 방법에 대해 자세히 알아보려면 [AWS Lambda 오류 처리 패턴 구현](https://aws.amazon.com/blogs/compute/implementing-aws-lambda-error-handling-patterns/) 블로그 게시물을 참조하세요.

**자동화 및 규모 조정**

AWS CDK 는 필요한 아키텍처를 자동으로 프로비저닝합니다. EventBridge는에 따라 초당 수천 개의 레코드로 확장할 수 있습니다 AWS 리전. 자세한 내용은 [Amazon EventBridge 문서](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html)를 참조하십시오.

## 도구
<a name="create-cross-account-amazon-eventbridge-connection-organization-tools"></a>

**AWS 서비스**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)는 코드로 AWS 클라우드 인프라를 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다. 이 패턴은 AWS CDK 앱과 상호 작용하는 데 도움이 되는 명령줄 클라우드 개발 키트인 [AWS CDK 도구](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) 키트를 사용합니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 다양한 소스의 실시간 데이터와 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. 예를 들어 AWS Lambda 함수, API 대상을 사용하는 HTTP 호출 엔드포인트 또는 다른의 이벤트 버스 등이 있습니다 AWS 계정.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)는 여러을 생성하여 중앙에서 관리하는 조직 AWS 계정 으로 통합하는 데 도움이 되는 계정 관리 서비스입니다.

**기타 도구**
+ [Node.js](https://nodejs.org/en/docs/)는 확장 가능한 네트워크 애플리케이션 구축을 위해 설계된 이벤트 기반 JavaScript 런타임 환경입니다.
+ [npm](https://docs.npmjs.com/about-npm)은 Node.js 환경에서 실행되는 소프트웨어 레지스트리로, 패키지를 공유 또는 대여하고 개인 패키지의 배포를 관리하는 데 사용됩니다.
+ [Python](https://www.python.org/)은 범용 컴퓨터 프로그래밍 언어입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [cross-account-eventbridge-in-organization](https://github.com/aws-samples/aws-cdk-examples/tree/main/python/cross-account-eventbridge-in-organization) 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="create-cross-account-amazon-eventbridge-connection-organization-best-practices"></a>

EventBridge 작업의 모범 사례는 다음 리소스를 참조하세요.
+ [Amazon EventBridge 이벤트 패턴 모범 사례](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-patterns-best-practices.html)
+ [Amazon EventBridge에서 규칙을 정의하는 모범 사례](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules-best-practices.html)

## 에픽
<a name="create-cross-account-amazon-eventbridge-connection-organization-epics"></a>

### 로컬 AWS CDK 배포 환경 준비
<a name="prepare-your-local-cdk-deployment-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 소스 계정 및 대상 계정에 대한 로컬 자격 증명을 구성합니다. | [새 구성 및 자격 증명 설정을](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new) 검토하고 환경에 가장 적합한 인증 및 자격 증명 방법을 사용합니다.소스 계정 및 대상 계정 인증 모두에 AWS CLI 대해를 구성해야 합니다.이 지침에서는 `sourceAccount` 및 라는 두 개의 AWS 프로파일을 로컬로 구성했다고 가정합니다`destinationAccount`. | 앱 개발자 | 
| 둘 다 부트스트랩합니다 AWS 계정. | 계정을 부트스트랩하려면 다음 명령을 실행합니다.<pre>cdk bootstrap --profile sourceAccount<br />cdk bootstrap --profile destinationAccount</pre> | 앱 개발자 | 
| 패턴 코드를 복제합니다. | 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone git@github.com:aws-samples/aws-cdk-examples.git</pre>그런 다음 디렉터리를 새로 복제된 프로젝트 폴더로 변경합니다.<pre>cd aws-cdk-examples/python/cross-account-eventbridge-in-organization</pre> | 앱 개발자 | 

### 소스 계정에 ProducerStack 배포
<a name="deploy-producerstack-to-the-source-account"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS Organizations 및 계정 세부 정보로 `cdk.json`를 수정합니다. | 프로젝트의 루트 폴더에서를 `cdk.json`다음과 같이 변경합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 앱 개발자 | 
| ProducerStack 리소스를 배포합니다. | 프로젝트의 루트 디렉터리에서 다음 Amplify CLI 명령을 실행합니다.<pre>cdk deploy ProducerStack --profile sourceAccount</pre>메시지가 표시되면를 통해 생성된 새 IAM 역할 및 기타 보안 관련 권한을 수락합니다 AWS CloudFormation. | 앱 개발자 | 
| ProducerStack 리소스가 배포되었는지 확인합니다. | 리소스를 확인하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 앱 개발자 | 

### 대상 계정에 ConsumerStack 배포
<a name="deploy-consumerstack-to-the-destination-account"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| ConsumerStack 리소스를 배포합니다. | 프로젝트의 루트 디렉터리에서 다음 Amplify CLI 명령을 실행합니다.<pre>cdk deploy ConsumerStack --profile destinationAccount</pre>메시지가 표시되면를 통해 생성된 새 IAM 역할 및 기타 보안 관련 권한을 수락합니다 CloudFormation. | 앱 개발자 | 
| ConsumerStack 리소스가 배포되었는지 확인 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 앱 개발자 | 

### 이벤트 생성 및 소비
<a name="produce-and-consume-events"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 생산자 Lambda 함수를 간접적으로 호출합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 앱 개발자 | 
| 이벤트가 수신되었는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 앱 개발자 | 

### 정리
<a name="cleanup"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| ConsumerStack 리소스를 폐기합니다. | 이 패턴을 테스트로 사용하는 경우 추가 비용이 발생하지 않도록 배포된 리소스를 정리합니다.프로젝트의 루트 디렉터리에서 다음 Amplify CLI 명령을 실행합니다.<pre>cdk destroy ConsumerStack --profile destinationAccount</pre>삭제를 확인하는 메시지가 표시됩니다. | 앱 개발자 | 
| ProducerStack 리소스를 폐기합니다. | 프로젝트의 루트 디렉터리에서 다음 Amplify CLI 명령을 실행합니다.<pre>cdk destroy ProducerStack --profile sourceAccount</pre>삭제를 확인하는 메시지가 표시됩니다. | 앱 개발자 | 

## 문제 해결
<a name="create-cross-account-amazon-eventbridge-connection-organization-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 대상 계정에서 수신된 이벤트가 없습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html) | 
| 콘솔에서 Lambda 함수를 간접적으로 호출하면 다음 오류가 반환됩니다.`User: arn:aws:iam::123456789012:user/XXXXX is not authorized to perform: lambda:Invoke` | `ProducerStack-ProducerLambdaXXXX` Lambda 함수에 대한 적절한 `lambda:Invoke` 작업 권한을 받으려면 AWS 계정 관리자에게 문의하세요. | 

## 관련 리소스
<a name="create-cross-account-amazon-eventbridge-connection-organization-resources"></a>

**참조**
+ [AWS Organizations 사용 설명서](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)
+ [Amazon EventBridge 이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [Amazon EventBridge의 규칙](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)

**자습서 및 동영상**
+ [자습서: 조직 생성 및 구성](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html)
+ [AWS re:Invent 2023 - Amazon EventBridge(COM301-R)를 사용한 고급 이벤트 기반 패턴](https://www.youtube.com/watch?v=6X4lSPkn4ps)

## 추가 정보
<a name="create-cross-account-amazon-eventbridge-connection-organization-additional"></a>

**생산자 규칙**

소스 계정에서 생산자의 메시지를 수락하도록 EventBridge 이벤트 버스가 생성됩니다( *아키텍처* 섹션에 표시됨). 이 이벤트 버스에는 IAM 권한이 포함된 규칙이 생성됩니다. 규칙은 다음 `cdk.json` 구조를 기반으로 대상 계정의 EventBridge 이벤트 버스를 대상으로 합니다.

```
"rules": [
  {
    "id": "CrossAccount",
    "sources": ["Producer"],
    "detail_types": ["TestType"],
    "targets": [
      {
        "id": "ConsumerEventBus",
        "arn": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount"
      }
    ]
  }
]
```

각 소비 이벤트 버스에 대해 이벤트 패턴과 대상 이벤트 버스가 포함되어야 합니다.

*이벤트 패턴*

[이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)은이 규칙이 적용될 이벤트를 필터링합니다. 이 예에서 이벤트 소스와 `detail_types` 레코드는 소스 계정의 이벤트 버스에서 대상 계정의 이벤트 버스로 전송할 이벤트를 식별합니다.

*대상 이벤트 버스*

이 규칙은 다른 계정에 있는 이벤트 버스를 대상으로 합니다. 대상 이벤트 버스를 고유하게 식별하려면 전체 `arn` (Amazon 리소스 이름)이 필요하며 `id`는에서 사용하는 [논리적 ID](https://docs.aws.amazon.com/cdk/v2/guide/identifiers.html#identifiers_logical_ids)입니다 AWS CloudFormation. 대상 규칙 생성 시 대상 이벤트 버스가 실제로 존재할 필요는 없습니다.

**대상 계정별 고려 사항**

대상 계정에서 EventBridge 이벤트 버스는 소스 계정의 이벤트 버스로부터 메시지를 수신하도록 생성됩니다. 소스 계정에서 이벤트를 게시하려면 [리소스 기반 정책을](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) 생성해야 합니다.

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [{
    "Sid": "AllowOrgToPutEvents",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-2:012345678901:event-bus/CrossAccount",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-XXXXXXXXX"
      }
    }
  }]
}
```

동일한 조직의 다른 계정이이 이벤트 버스에 이벤트를 게시할 수 있도록 `events:PutEvents` 권한을 부여하는 것이 특히 중요합니다. 를 조직 ID`aws:PrincipalOrgId`로 설정하면 필요한 권한이 부여됩니다.

**이벤트 패턴**

포함된 이벤트 패턴을 사용 사례에 맞게 수정할 수 있습니다.

```
rule = events.Rule(
    self,
    self.id + 'Rule' + rule_definition['id'],
    event_bus=event_bus,
    event_pattern=events.EventPattern(
        source=rule_definition['sources'],
        detail_type=rule_definition['detail_types'],
    )
)
```

불필요한 처리를 줄이기 위해 이벤트 패턴은 대상 계정에서 처리할 이벤트만 대상 계정의 이벤트 버스로 전송되도록 지정해야 합니다.

*리소스 기반 정책*

이 예에서는 조직 ID를 사용하여 대상 계정의 이벤트 버스에 이벤트를 넣을 수 있는 계정을 제어합니다. 소스 계정 지정과 같은 보다 제한적인 정책을 사용하는 것이 좋습니다.

*EventBridge 할당량*

다음 사항에 유의하세요.
+ 이벤트 버스당 300개의 규칙이 기본 할당량입니다. 필요한 경우 확장할 수 있지만 대부분의 사용 사례에 적합해야 합니다.
+ 규칙당 최대 5개의 대상이 허용됩니다. 이벤트 패턴에 대한 세분화된 제어를 지원하려면 애플리케이션 아키텍트가 각 대상 계정에 대해 고유한 규칙을 사용하는 것이 좋습니다.

# 에서 Kinesis Data Streams 및 Firehose를 사용하여 Amazon S3에 DynamoDB 레코드 전송 AWS CDK
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk"></a>

*Shashank Shrivastava와 Daniel Matuki da Cunha, Amazon Web Services*

## 요약
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-summary"></a>

이 패턴은 Amazon Kinesis Data Streams와 Amazon Kinesis Data Firehose를 사용하여 Amazon DynamoDB에서 Amazon Simple Storage Service(Amazon S3)로 레코드를 전송하기 위한 샘플 코드 및 애플리케이션을 제공합니다. 패턴의 접근 방식은 [AWS Cloud Development Kit (AWS CDK) L3 구문을](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html) 사용하며 데이터가 Amazon Web Services(AWS) 클라우드의 대상 S3 버킷으로 전송 AWS Lambda 되기 전에를 사용하여 데이터 변환을 수행하는 방법의 예를 포함합니다.

Kinesis Data Streams는 DynamoDB 테이블에서 항목 수준 수정 사항을 기록하여 필수 Kinesis 데이터 스트림에 복제합니다. 애플리케이션에서는 Kinesis 데이터 스트림에 액세스하고 항목 수준 변경 사항을 거의 실시간으로 볼 수 있습니다. 또한 Kinesis Data Streams를 사용하면 Amazon Kinesis Data Firehose 및 Amazon Managed Service for Apache Flink와 같은 다른 Kinesis 서비스에 액세스할 수도 있습니다. 즉, 실시간 대시보드를 제공하고, 알림을 생성하고, 동적 요금 및 광고를 구현하고, 정교한 데이터 분석을 수행하는 애플리케이션을 빌드할 수 있습니다.

이 패턴을 데이터 통합 사용 사례에 사용할 수 있습니다. 예를 들어, 운송 차량 또는 산업용 장비가 대량의 데이터를 DynamoDB 테이블로 전송할 수 있습니다. 그런 다음 이 데이터를 변환하여 Amazon S3에 호스팅된 데이터 레이크에 저장할 수 있습니다. 그런 다음 Amazon Athena, Amazon Redshift Spectrum, Amazon Rekognition 및 AWS Glue와 같은 서버리스 서비스를 사용하여 데이터를 쿼리 및 처리하고 잠재적 결함을 예측할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-prereqs"></a>

*사전 조건 *
+ 활성. AWS 계정
+ AWS Command Line Interface (AWS CLI), 설치 및 구성됨. 자세한 내용은 AWS CLI 설명서[의 시작하기 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)를 참조하세요.
+ Node.js(18.x\$1) 및 npm, 설치 및 구성됨. 자세한 내용은 `npm` 설명서의 [Node.js 및 npm 다운로드 및 설치](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)를 참조하세요.
+ aws-cdk(2.x\$1) 설치 및 구성 자세한 내용은 AWS CDK 설명서[의 시작하기 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)를 참조하세요.
+ GitHub [aws-dynamodb-kinesisfirehose-s3-ingestion](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/) 리포지토리는 로컬 머신에 복제 및 구성됩니다.
+ DynamoDB 테이블의 기존 샘플 데이터입니다. 데이터는 `{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}` 형식을 사용해야 합니다.

## 아키텍처
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-architecture"></a>

다음 다이어그램은 Kinesis Data Streams와 Kinesis Data Firehose를 사용하여 DynamoDB에서 Amazon S3로 레코드를 전송하는 예제 워크플로우를 보여줍니다.

![\[다음 다이어그램은 Kinesis Data Streams와 Kinesis Data Firehose를 사용하여 DynamoDB에서 Amazon S3로 레코드를 전송하는 예제 워크플로우를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e2a9c412-312e-4900-9774-19a281c578e4/images/6e6df998-e6c2-4eaf-b263-ace752194689.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. Amazon API Gateway를 사용하여 DynamoDB용 프록시로 데이터를 수집합니다. 다른 소스를 사용하여 DynamoDB로 데이터를 수집할 수도 있습니다. 

1. 항목 수준 변경은 Kinesis Data Streams에서 거의 실시간으로 생성되어 Amazon S3로 전송됩니다.

1. Kinesis Data Streams는 변환 및 제공을 위해 Kinesis Data Firehose에 레코드를 전송합니다. 

1. Lambda 함수는 DynamoDB 레코드 형식의 레코드를 레코드 항목 속성 이름 및 값만 포함하는 JSON 형식으로 변환합니다.

## 도구
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-tools"></a>

*AWS 서비스*
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)는 AWS 클라우드 인프라를 코드로 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [AWS CDK 도구 키트](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)는 AWS CDK 앱과 상호 작용하는 데 도움이 되는 명령줄 클라우드 개발 키트입니다.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및의 수명 주기 동안 리소스를 관리할 수 있습니다 AWS 리전.

*코드 리포지토리*

이 패턴의 코드는 GitHub [aws-dynamodb-kinesisfirehose-s3-ingestion](https://github.com/aws-samples/aws-dynamodb-kinesisfirehose-s3-ingestion/) 리포지토리에서 사용할 수 있습니다.

## 에픽
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-epics"></a>

### 샘플 코드 설정 및 구성
<a name="set-up-and-configure-the-sample-code"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 종속성을 설치합니다. | 로컬 시스템에서 다음 명령을 실행하여 `pattern/aws-dynamodb-kinesisstreams-s3` 및 `sample-application` 디렉터리의 `package.json` 파일에서 종속성을 설치합니다.<pre>cd <project_root>/pattern/aws-dynamodb-kinesisstreams-s3 </pre><pre>npm install && npm run build</pre><pre>cd <project_root>/sample-application/</pre><pre>npm install && npm run build</pre>  | 앱 개발자, 일반 AWS | 
| CloudFormation 템플릿을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | 앱 개발자, 일반 AWS, AWS DevOps | 

### 리소스 배포
<a name="deploy-the-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리소스를 확인하고 배포하세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.html) | 앱 개발자, 일반 AWS, AWS DevOps | 

### DynamoDB 테이블로 데이터를 수집하여 솔루션 테스트
<a name="ingest-data-into-the-dynamodb-table-to-test-the-solution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 샘플 데이터를 DynamoDB 테이블로 수집합니다. |  AWS CLI다음 명령을 실행하여 DynamoDB 테이블에 요청을 보냅니다.`aws dynamodb put-item --table-name <your_table_name> --item '{"<table_partition_key>": {"S": "<partition_key_ID>"},"MessageData":{"S": "<data>"}}'`예:`aws dynamodb put-item --table-name SourceData_table --item '{"SourceDataId": {"S": "123"},"MessageData":{"S": "Hello World"}}'`기본적으로 `put-item`은(는) 작업이 성공해도 출력으로 어떤 값도 반환하지 않습니다. 작업이 실패하면 오류가 반환됩니다. 데이터는 DynamoDB에 저장된 다음 Kinesis Data Streams 및 Kinesis Data Firehose로 전송됩니다. 참고: DynamoDB 테이블에 데이터를 추가할 때는 다양한 접근 방식을 사용합니다. 자세한 내용은 Amazon DynamoDB 설명서의 [테이블에 데이터 로드](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SampleData.LoadData.html)를 참조하세요. | 앱 개발자 | 
| S3 버킷에 새 객체가 생성되었는지 확인합니다. | 에 로그인 AWS Management Console 하고 S3 버킷을 모니터링하여 전송한 데이터로 새 객체가 생성되었는지 확인합니다. 자세한 내용은 Amazon S3 설명서의 [객체 업로드](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html)를 참조하십시오. | 앱 개발자, 일반 AWS | 

### 리소스 정리
<a name="clean-up-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리소스를 정리합니다. | `cdk destroy` 명령을 실행하여 이 패턴에 사용되는 모든 리소스를 삭제합니다. | 앱 개발자, 일반 AWS | 

## 관련 리소스
<a name="deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk-resources"></a>
+ [s3-static-site-stack.ts](https://github.com/awslabs/aws-solutions-constructs/blob/main/source/use_cases/aws-s3-static-website/lib/s3-static-site-stack.ts#L25) (GitHub 리포지토리)
+ [aws-apigateway-dynamodb module](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-apigateway-dynamodb) (GitHub 리포지토리)
+ [aws-kinesisstreams-kinesisfirehose-s3 module](https://github.com/awslabs/aws-solutions-constructs/tree/main/source/patterns/%40aws-solutions-constructs/aws-kinesisstreams-kinesisfirehose-s3) (GitHub 리포지토리)
+ [DynamoDB Streams에 대한 변경 데이터 캡처](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) (Amazon DynamoDB 설명서)
+ [Kinesis Data Streams을 사용하여 DynamoDB에 대한 변경 사항 캡처](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html) (Amazon DynamoDB 설명서)

# Amazon API Gateway 버전 관리 구현
<a name="implement-path-based-api-versioning-by-using-custom-domains"></a>

*Corey Schnedl, Marcelo Barbosa, Mario Lopez Martinez, Anbazhagan Ponnuswamy, Gaurav Samudra, Abhilash Vinod, Amazon Web Services*

## 요약
<a name="implement-path-based-api-versioning-by-using-custom-domains-summary"></a>

이 패턴은 [사용자 지정 도메인](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html)의 [API 매핑](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html) 기능을 사용하여 Amazon API Gateway용 경로 기반 API 버전 관리 솔루션을 구현하는 방법을 보여줍니다.

Amazon API Gateway는 어떤 규모에서든 API를 생성, 게시, 유지 관리, 모니터링 및 보호하기 위해 사용할 수 있는 완전관리형 서비스입니다. 서비스의 사용자 지정 도메인 기능을 사용하면 API 사용자에게 제공할 수 있는 보다 직관적인 URL을 사용하여 더 간단한 사용자 지정 도메인 이름을 생성할 수 있습니다. API 매핑을 사용하여 API 스테이지를 사용자 지정 도메인 이름에 연결할 수 있습니다. 도메인 이름을 생성하고 DNS 레코드를 구성한 후에는 API 매핑을 사용하여 사용자 지정 도메인 이름을 통해 API로 트래픽을 보냅니다.

API를 공개적으로 사용할 수 있게 되면 소비자는 API를 사용합니다. 퍼블릭 API가 발전함에 따라 서비스 계약도 새로운 기능을 반영하도록 발전합니다. 그러나 기존 기능을 변경하거나 제거하는 것은 현명하지 않습니다. 중단된 변경 사항은 소비자의 애플리케이션에 영향을 미치고 런타임에 중단될 수 있습니다. API 버전 관리는 이전 버전과의 호환성과 계약 위반을 방지하는 데 중요합니다.

소비자가 이를 채택할 수 있도록 API 버전 관리를 위한 명확한 전략이 필요합니다. 경로 기반 URL API를 사용한 버전 관리는 가장 간단하고 일반적으로 사용되는 접근 방식입니다. 이 유형의 버전 관리에서는 버전이 API URIs의 일부로 명시적으로 정의됩니다. 다음 예시 URL은 소비자가 URI를 사용하여 요청에 대한 API 버전을 지정하는 방법을 보여줍니다.

`https://api.example.com/api/v1/orders `

`https://api.example.com/api/v2/orders `

`https://api.example.com/api/vX/orders`

이 패턴은 AWS Cloud Development Kit (AWS CDK) 를 사용하여 API에 대한 확장 가능한 경로 기반 버전 관리 솔루션의 샘플 구현을 빌드, 배포 및 테스트합니다. AWS CDK 는 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링하고 프로비저닝하는 오픈 소스 소프트웨어 개발 프레임워크입니다.

## 사전 조건 및 제한 사항
<a name="implement-path-based-api-versioning-by-using-custom-domains-prereqs"></a>

**사전 조건**
+ 활성. AWS 계정
+ 이 패턴의 샘플 리포지토리를 사용하고 Amazon API Gateway 사용자 지정 도메인 기능을 사용하려면 도메인 소유권이 필요합니다. Amazon Route 53를 사용하여 조직의 도메인을 생성하고 관리할 수 있습니다. Route 53에 도메인을 등록하거나 이전하는 방법에 대한 자세한 내용은 Route 53 설명서의 [새 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register-update.html)을 참조하세요.
+ API에 대한 사용자 지정 도메인 이름을 설정하기 전에 에서 [SSL/TLS 인증서](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-specify-certificate-for-custom-domain-name.html)를 준비해야 합니다.
+ DNS 공급자의 리소스 레코드를 생성하거나 업데이트하여 API 엔드포인트에 매핑해야 합니다. 이렇게 매핑하지 않으면 사용자 지정 도메인 이름이 목적지인 API 요청은 API Gateway에 도달할 수 없습니다.

**제한 사항**
+ 사용자 지정 도메인 이름은 AWS 리전 전체 내에서 고유해야 합니다 AWS 계정.
+ 여러 수준으로 API 매핑을 구성하려면 리전 사용자 지정 도메인 이름과 TLS 1.2 보안 정책을 사용해야 합니다.
+ API 매핑에서 사용자 지정 도메인 이름과 매핑된 API는 동일한 AWS 계정에 있어야 합니다.
+ API 매핑에는 문자, 숫자 및 문자 `$-_.+!*'()/`만 포함해야 합니다.
+ API 매핑에서 경로의 최대 길이는 300자입니다.
+ 각 도메인 이름에 대해 여러 수준의 API 매핑이 200개 있을 수 있습니다.
+ TLS 1.2 보안 정책을 사용하여 HTTP API를 리전별 사용자 지정 도메인 이름에만 매핑할 수 있습니다.
+ WebSocket API를 HTTP API 또는 REST API와 동일한 사용자 지정 도메인 이름에 매핑할 수 없습니다.
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전별 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)을 참조하고 서비스 링크를 선택합니다.

**제품 버전**
+ 이 샘플 구현은 [AWS CDK TypeScript 버전 2.149.0에서](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html)를 사용합니다.

## 아키텍처
<a name="implement-path-based-api-versioning-by-using-custom-domains-architecture"></a>

다음 다이어그램은 이 아키텍처 워크플로를 보여줍니다.

![\[API 매핑 및 사용자 지정 도메인을 사용하여 경로 기반 API 버전 관리 솔루션을 구현하는 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e1b32d2b-410f-4ace-967e-f0b8aaf0304c/images/fa9f04f1-efa6-4fb1-a541-ae3da4076b00.png)


다이어그램은 다음을 보여 줍니다.

1. API 사용자는 사용자 지정 도메인 이름을 사용하여 Amazon API Gateway에 요청을 보냅니다.

1. API Gateway는 요청의 URL에 표시된 경로를 기반으로 사용자의 요청을 API Gateway의 적절한 인스턴스 및 단계로 동적으로 라우팅합니다. 다음 표는 다양한 URL 기반 경로를 다양한 API Gateway 인스턴스의 특정 단계로 라우팅하는 방법의 예를 보여줍니다.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/implement-path-based-api-versioning-by-using-custom-domains.html)

1. 대상 API Gateway 인스턴스는 요청을 처리하고 결과를 사용자에게 반환합니다.

**자동화 및 규모 조정**

API의 각 버전에 대해 별도의 AWS CloudFormation 스택을 사용하는 것이 좋습니다. 이 접근 방식을 사용하면 사용자 지정 도메인 API 매핑 기능을 통해 라우팅할 수 있는 백엔드 API를 완전히 격리할 수 있습니다. 이 접근 방식의 장점은 다른 API를 수정할 리스크를 초래하지 않고 API의 여러 버전을 독립적으로 배포하거나 제거할 수 있다는 것입니다. 이 접근 방식은 CloudFormation 스택의 격리를 통해 복원력을 높입니다. 또한 HTTP 엔드포인트 AWS Lambda AWS Fargate및 작업과 같은 API에 대한 다양한 백엔드 옵션을 제공합니다 AWS 서비스.

[Gitflow와 같은 Git](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/gitflow-branching-strategy.html) 분기 전략을 격리된 CloudFormation 스택과 함께 사용하여 API의 다른 버전에 배포된 소스 코드를 관리할 수 있습니다. 이 옵션을 사용하면 새 버전의 소스 코드를 복제할 필요 없이 다양한 버전의 API를 유지할 수 있습니다. Gitflow를 사용하면 릴리스가 수행될 때 git 리포지토리 내의 커밋에 태그를 추가할 수 있습니다. 따라서 특정 릴리스와 관련된 소스 코드의 전체 스냅샷이 생성됩니다. 업데이트를 수행해야 하므로 특정 릴리스의 코드를 확인하고 업데이트한 다음 해당 메이저 버전과 일치하는 CloudFormation 스택에 업데이트된 소스 코드를 배포할 수 있습니다. 이 접근 방식은 각 API 버전에 격리된 소스 코드가 있고 별도의 CloudFormation 스택에 배포되므로 다른 API 버전이 중단될 리스크를 줄입니다.

## 도구
<a name="implement-path-based-api-versioning-by-using-custom-domains-tools"></a>

**AWS 서비스**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)는 규모와 관계없이 REST, HTTP 및 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호하는 것을 지원합니다.
+ [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)을 사용하면 웹 AWS 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 생성, 저장 및 갱신할 수 있습니다.
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)는 코드로 클라우드 인프라를 정의하고 이를 프로비저닝하기 위한 오픈 소스 소프트웨어 개발 프레임워크입니다 CloudFormation. 이 패턴의 샘플 구현은 [AWS CDK TypeScript에서](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html)를 사용합니다. TypeScript AWS CDK 에서를 사용하려면 Microsoft TypeScript 컴파일러(`tsc`), [Node.js](https://nodejs.org/) 및 노드 패키지 관리자()를 비롯한 친숙한 도구를 사용합니다`npm`. 원하는 경우 [Yarn](https://yarnpkg.com/)을 사용할 수 있지만 이 패턴의 예에서는 `npm`를 사용합니다.AWS Construct Library를 구성하는 모듈은 `npm ` 리포지토리인 [npmjs.org](https://docs.npmjs.com/)를 통해 배포됩니다.
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및의 수명 주기 동안 리소스를 관리할 수 있습니다 AWS 리전.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)는 보호되는 웹 애플리케이션 리소스로 전달되는 HTTP 및 HTTPS 요청을 모니터링할 수 있게 해주는 웹 애플리케이션 방화벽입니다.

**기타 도구**
+ [Bruno](https://www.usebruno.com/)는 git 친화적인 오픈 소스 API 테스트 클라이언트입니다.
+ [cdk-nag](https://github.com/cdklabs/cdk-nag)는 규칙 팩을 사용하여 AWS CDK 애플리케이션의 모범 사례를 확인하는 오픈 소스 유틸리티입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [path-based-versioning-with-api-gateway](https://github.com/aws-samples/path-based-versioning-with-api-gateway) 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="implement-path-based-api-versioning-by-using-custom-domains-best-practices"></a>
+ 강력한 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 사용하여 로 구축된 CloudFormation 스택의 테스트 및 배포를 자동화합니다 AWS CDK. 이 권장 사항과 관련된 자세한 내용은 [AWS Well-Architected DevOps 지침](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)을 참조하세요.
+ AWS WAF 는 Amazon API Gateway와 같은 서비스와 쉽게 통합되는 관리형 방화벽입니다. 이 버전 관리 패턴이 작동하는 데 AWS WAF 필요한 구성 요소는 아니지만 AWS WAF API Gateway에를 포함하는 보안 모범 사례로를 사용하는 것이 좋습니다.
+ API의 이전 버전을 더 이상 사용하지 않고 효율적으로 제거할 수 있도록 API 소비자가 API의 최신 버전으로 정기적으로 업그레이드하도록 장려합니다.
+ 프로덕션 설정에서이 접근 방식을 사용하기 전에 API에 대한 방화벽 및 권한 부여 전략을 구현합니다.
+ 최소 권한 액세스 모델을 AWS 계정 사용하여의 AWS 리소스 관리에 대한 액세스를 구현합니다. [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+ 로 빌드된 애플리케이션에 모범 사례 및 보안 권장 사항을 적용하려면 [cdk-nag 유틸리티](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/check-aws-cdk-applications-or-cloudformation-templates-for-best-practices-by-using-cdk-nag-rule-packs.html)를 사용하는 AWS CDK것이 좋습니다.

## 에픽
<a name="implement-path-based-api-versioning-by-using-custom-domains-epics"></a>

### 로컬 환경 준비
<a name="prepare-your-local-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 샘플 애플리케이션의 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/path-based-versioning-with-api-gateway</pre> | 앱 개발자 | 
| 복제된 리포지토리로 이동합니다. | 복제된 리포지토리 폴더 위치로 이동하려면 다음 명령을 입력합니다.<pre>cd api-gateway-custom-domain-versioning</pre> | 앱 개발자 | 
| 필요한 종속 항목을 설치합니다. | 필요한 종속성을 설치하려면 다음 명령을 실행합니다.<pre>npm install </pre> | 앱 개발자 | 

### CloudFormation 라우팅 스택을 배포합니다.
<a name="deploy-the-cfnshort-routing-stack"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 라우팅 스택의 배포를 시작합니다. | CloudFormation 라우팅 스택의 배포를 시작하려면 다음 명령을 `CustomDomainRouterStack`실행하여 `example.com`를 소유한 도메인의 이름으로 바꿉니다.<pre>npx cdk deploy CustomDomainRouterStack --parameters PrerequisiteDomainName=example.com</pre>스택 배포는 다음 도메인 DNS 검증 작업이 성공적으로 수행될 때까지 성공하지 못합니다. | 앱 개발자 | 

### 도메인 소유권 확인
<a name="verify-domain-ownership"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 도메인의 소유권을 확인합니다. | 인증서는 연결된 도메인의 소유권을 증명할 때까지 **검증 보류** 중 상태로 유지됩니다.소유권을 증명하려면 도메인과 연결된 호스팅 영역에 CNAME 레코드를 추가합니다. 자세한 내용은 AWS Certificate Manager 설명서의 [DNS 검증](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)을 참조하세요.적절한 레코드를 추가하면 `CustomDomainRouterStack` 배포가 성공할 수 있습니다. | 앱 개발자, AWS 시스템 관리자, 네트워크 관리자 | 
| API Gateway 사용자 지정 도메인을 가리키는 별칭 레코드를 생성합니다. | 인증서가 성공적으로 발급되고 검증되면 Amazon API Gateway 사용자 지정 도메인 URL을 가리키는 [DNS 레코드를 생성합니다](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-regional-api-custom-domain-create.html#apigateway-regional-api-custom-domain-dns-record).사용자 지정 도메인 URL은 사용자 지정 도메인의 프로비저닝에 의해 고유하게 생성되며 CloudFormation 출력 파라미터로 지정됩니다. 다음은 [레코드의 예](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html)입니다.**라우팅 정책**:단순 라우팅**레코드 이름**: `demo.api-gateway-custom-domain-versioning.example.com`**별칭**]: 예**레코드 유형**: AWS 리소스를 가리키는 "A" 유형의 DNS 레코드**값**: `d-xxxxxxxxxx.execute-api.xx-xxxx-x.amazonaws.com`**TTL(초)**: 300 | 앱 개발자, AWS 시스템 관리자, 네트워크 관리자 | 

### CloudFormation 스택 배포 및 API 간접 호출
<a name="deploy-cfnshort-stacks-and-invoke-the-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| `ApiStackV1` 스택을 배포합니다. | `ApiStackV1` 스택을 배포하려면 다음 명령을 사용합니다.<pre>npm run deploy-v1</pre>다음 CDK 코드는 API 매핑을 추가합니다.<pre>var apiMapping = new CfnApiMapping(this, "ApiMapping", {<br />      apiId: this.lambdaRestApi.restApiId,<br />      domainName: props.customDomainName.domainName,<br />      stage: "api",<br />      apiMappingKey: "api/v1",<br />    });</pre> | 앱 개발자 | 
| `ApiStackV2` 스택을 배포합니다. | `ApiStackV2` 스택을 배포하려면 다음 명령을 사용합니다.<pre>npm run deploy-v2</pre> | 앱 개발자 | 
|  API를 호출합니다. | API를 간접적으로 호출하고 Bruno를 사용하여 API 엔드포인트를 테스트하려면 [추가 정보](#implement-path-based-api-versioning-by-using-custom-domains-additional)의 지침을 참조하세요. | 앱 개발자 | 

### 리소스 정리
<a name="clean-up-resources"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리소스를 정리하십시오. | 이 샘플 애플리케이션과 연결된 리소스를 삭제하려면 다음 명령을 사용합니다.<pre>npx cdk destroy --all</pre>도메인 소유권 확인 프로세스를 위해 수동으로 추가된 Route 53 DNS 레코드를 모두 정리해야 합니다. | 앱 개발자 | 

## 문제 해결
<a name="implement-path-based-api-versioning-by-using-custom-domains-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 인증서를 검증할 수 없기 때문에 배포 시간이 `CustomDomainRouterStack` 초과되었습니다. | 이전 작업에서 설명한 대로 적절한 DNS 검증 CNAME 레코드를 추가했는지 확인합니다. DNS 검증 레코드를 추가한 후 새 인증서의 상태가 최대 30분 동안 계속 **검증 보류 중**으로 표시될 수 있습니다. 자세한 내용은 AWS Certificate Manager 설명서의 [DNS 검증](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)을 참조하세요. | 

## 관련 리소스
<a name="implement-path-based-api-versioning-by-using-custom-domains-resources"></a>
+ [Amazon CloudFront를 사용한 헤더 기반 API Gateway 버전 관리 구현](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/) -이 AWS 컴퓨팅 블로그 게시물은이 패턴에 설명된 경로 기반 버전 관리 전략의 대안으로 헤더 기반 버전 관리 전략을 제공합니다.
+ [AWS CDK 워크숍](https://cdkworkshop.com/20-typescript.html) -이 입문 워크숍은 AWS 를 사용하여에서 애플리케이션을 구축하고 배포하는 데 중점을 둡니다 AWS Cloud Development Kit (AWS CDK). 이 워크숍은 Go, Python 및 TypeScript를 지원합니다.

## 추가 정보
<a name="implement-path-based-api-versioning-by-using-custom-domains-additional"></a>

**Bruno로 API 테스트**

샘플 애플리케이션에 경로 기반 라우팅이 제대로 작동하는지 확인하려면 오픈 소스 API 테스트 도구인 [Bruno](https://www.usebruno.com/)를 사용하는 것이 좋습니다. 이 패턴은 샘플 API를 쉽게 테스트할 수 있는 샘플 컬렉션을 제공합니다.

API를 간접적으로 호출하고 테스트하려면 다음 명령을 사용합니다.

1. [Bruno를 설치합니다.](https://www.usebruno.com/downloads)

1. Bruno를 엽니다.

1. 이 패턴의 [코드 리포지토리](https://github.com/aws-samples/path-based-versioning-with-api-gateway)에서 **Bruno/Sample-API-Gateway-Custom-Domain-Versioning**을 선택하고 컬렉션을 엽니다.

1. 사용자 인터페이스(UI) 오른쪽 상단의 **환경** 드롭다운을 보려면 컬렉션에서 요청을 선택합니다.

1. **환경** 드롭다운에서 **구성을** 선택합니다.

1. `REPLACE_ME_WITH_YOUR_DOMAIN` 값을 사용자 지정 도메인으로 바꿉니다.

1. **저장**을 선택한 다음 **구성** 섹션을 닫습니다.

1. **샌드박스 환경에서** **활성** 옵션이 선택되어 있는지** **확인합니다.

1. 선택한 요청에 대해 **->** 버튼을 사용하여 API를 간접적으로 호출합니다.

1. V2와 비교하여 V1에서 검증(숫자가 아닌 값 전달)이 처리되는 방식에 유의하세요. V2

예시 API 호출 및 V1 및 V2 검증 비교의 스크린샷을 보려면 이 패턴의 [코드 리포지토리](https://github.com/aws-samples/path-based-versioning-with-api-gateway)에 있는 `README.md` 파일에서 **샘플 API 테스트**를 참조하세요.

# PostgreSQL 데이터베이스와 상호 작용 AWS Lambda 하기 위해 로 psycopg2 라이브러리 가져오기
<a name="import-psycopg2-library-lambda"></a>

*Louis Hourcade, Amazon Web Services*

## 요약
<a name="import-psycopg2-library-lambda-summary"></a>

[Psycopg](https://www.psycopg.org/docs/)는 Python용 PostgresSQL 데이터베이스 어댑터입니다. 개발자는 `psycopg2` 라이브러리를 사용하여 PostgreSQL 데이터베이스와 상호 작용하는 Python 애플리케이션을 작성합니다.

Amazon Web Services(AWS)에서 개발자는 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)를 사용하여 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행합니다. Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 서버리스 이벤트 기반 컴퓨팅 서비스입니다.

기본적으로 [Lambda에서 지원하는 Python 런타임](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)을 사용하는 새 함수를 생성하면에서 제공하는 Lambda[용 기본 이미지에서 Lambda](https://github.com/aws/aws-lambda-base-images) 런타임 환경이 생성됩니다 AWS. `pandas` 또는와 같은 라이브러리`psycopg2`는 기본 이미지에 포함되지 않습니다. 라이브러리를 사용하려면 사용자 지정 패키지에 번들링하여 Lambda에 연결해야 합니다.

라이브러리를 번들링하고 연결하는 방법은 다음과 같이 여러 가지가 있습니다.
+ [.zip 파일 아카이브](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html)에서 Lambda 함수를 배포합니다.
+ 사용자 지정 컨테이너 이미지에서 Lambda 함수를 배포합니다.
+ [Lambda 계층](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html#lambda-layer-versions)을 생성하여 Lambda 함수에 연결합니다.

이 패턴은 처음 두 가지 옵션을 보여줍니다.

.zip 배포 패키지를 사용하면 `pandas` 라이브러리를 Lambda 함수에 추가하는 것이 비교적 간단합니다. Linux 시스템에서 폴더를 생성하고, `pandas` 라이브러리 및 라이브러리의 종속성과 함께 Lambda 스크립트를 폴더에 추가하고, 폴더를 압축하고, Lambda 함수의 소스로 제공합니다.

.zip 배포 패키지를 사용하는 것은 일반적인 방법이지만 `psycopg2` 라이브러리에서는 이러한 접근 방식이 작동하지 않습니다. 이 패턴은 먼저 .zip 배포 패키지를 사용하여 `psycopg2` 라이브러리를 Lambda 함수에 추가하는 경우 발생하는 오류를 보여줍니다. 그런 다음이 패턴은 Dockerfile에서 Lambda를 배포하고 `psycopg2` 라이브러리가 작동하도록 Lambda 이미지를 편집하는 방법을 보여줍니다.

패턴이 배포하는 세 가지 리소스에 대한 자세한 내용은 [추가 정보](#import-psycopg2-library-lambda-additional) 섹션을 참조하세요.

## 사전 조건 및 제한 사항
<a name="import-psycopg2-library-lambda-prereqs"></a>

**사전 조건**
+ 이 패턴에서 사용하는 AWS 리소스를 배포할 수 있는 충분한 권한이 AWS 계정 있는 활성
+ AWS Cloud Development Kit (AWS CDK) 를 실행하여 전역적으로 설치됨 `npm install -g aws-cdk`
+ Git 클라이언트.
+ Python
+ Docker

**제한 사항**
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 [리전별AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 섹션을 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) 페이지를 참조하고 서비스 링크를 선택합니다.

**제품 버전**
+ [Lambda에서 지원하는](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) Python 런타임 버전
+ Psycopg2 버전 2.9.3
+ Pandas 버전 1.5.2

## 아키텍처
<a name="import-psycopg2-library-lambda-architecture"></a>

**솔루션 개요**

Lambda에서 `psycopg2` 라이브러리를 사용할 때 직면할 수 있는 문제를 설명하기 위해 패턴은 두 개의 Lambda 함수를 배포합니다.
+ .zip 파일에서 생성된 Python 런타임이 있는 Lambda 함수 1개. `psycopg2` 및 `pandas` 라이브러리는 [pip](https://pypi.org/project/pip/)를 사용하여이 .zip 배포 패키지에 설치됩니다.
+ Dockerfile에서 생성된 Python 런타임이 있는 Lambda 함수 1개. Dockerfile은 Lambda 컨테이너 이미지에 `psycopg2` 및 `pandas` 라이브러리를 설치합니다.

첫 번째 Lambda 함수는 .zip 파일에 `pandas` 라이브러리와 해당 종속성을 설치하고 Lambda는 해당 라이브러리를 사용할 수 있습니다.

두 번째 Lambda 함수는 Lambda 함수에 대한 컨테이너 이미지를 빌드하여 Lambda에서 및 `psycopg2` 라이브러리를`pandas` 실행할 수 있음을 보여줍니다.

## 도구
<a name="import-psycopg2-library-lambda-tools"></a>

**AWS 서비스**
+ AWS Cloud Development Kit(AWS CDK)는 AWS 클라우드 인프라를 코드로 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.

**기타 도구**
+ [Docker](https://www.docker.com/)는 운영 체제 수준의 가상화를 사용하여 컨테이너에 소프트웨어를 제공하는 서비스형 플랫폼(PaaS) 제품 세트입니다.
+ [pandas](https://pandas.pydata.org/)는 데이터 분석 및 조작을 위한 Python 기반 오픈 소스 도구입니다.
+ [Psycopg](https://www.psycopg.org/docs/)는 다중 스레드 애플리케이션용으로 설계된 Python 언어용 PostgreSQL 데이터베이스 어댑터입니다. 이 패턴은 Psycopg 2를 사용합니다.
+ [Python](https://www.python.org/)은 범용 컴퓨터 프로그래밍 언어입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub의 [import-psycopg2-in-lambda-to-interact-with-postgres-database](https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database) 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="import-psycopg2-library-lambda-best-practices"></a>

이 패턴은를 사용하여 Dockerfile에서 Lambda 함수를 AWS CDK 생성하는 작업 예제를 제공합니다. 애플리케이션에서이 코드를 재사용하는 경우 배포된 리소스가 모든 보안 요구 사항을 충족하는지 확인합니다. 인프라를 배포하기 전에 클라우드 인프라 구성을 스캔하여 잘못된 구성을 찾는 [Checkov](https://www.checkov.io/)와 같은 도구를 사용합니다.

## 에픽
<a name="import-psycopg2-library-lambda-epics"></a>

### 리포지토리 복제 및 배포 구성
<a name="clone-the-repository-and-configure-the-deployment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 다음 명령을 실행하여 GitHub 리포지토리를 복제합니다.<pre>git clone https://github.com/aws-samples/import-psycopg2-in-lambda-to-interact-with-postgres-database.git<br />cd AWS-lambda-psycopg2</pre> | 일반 AWS | 
| 배포를 구성합니다. |  AWS 계정다음에 대한 정보로 `app.py` 파일을 편집합니다.<pre>aws_acccount = "AWS_ACCOUNT_ID"<br />region = "AWS_REGION"<br /># Select the CPU architecture you are using to build the image (ARM or X86)<br />architecture = "ARM"</pre> | 일반 AWS | 

### AWS 계정 부트스트랩 및 애플리케이션 배포
<a name="bootstrap-your-aws-account-and-deploy-the-application"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 를 부트스트랩합니다 AWS 계정. | [AWS 환경을 아직 부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)하지 않은 경우 AWS 계정의 AWS 자격 증명으로 다음 명령을 실행합니다.<pre>cdk bootstrap aws://<tooling-account-id>/<aws-region></pre> | 일반 AWS | 
| 모델 배포 |  AWS CDK 애플리케이션을 배포하려면 다음 명령을 실행합니다.<pre>cdk deploy AWSLambdaPyscopg2</pre> | 일반 AWS | 

### AWS Management Console에서 Lambda 함수 테스트
<a name="test-the-lambda-functions-from-the-aws-management-console"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| .zip 파일에서 생성된 Lambda 함수를 테스트합니다. | .zip 파일에서 생성된 Lambda 함수를 테스트하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)Lambda는 기본 이미지에서 필요한 PostgreSQL 라이브러리를 찾지 못하므로 `psycopg2` 라이브러리를 사용할 수 없습니다. | 일반 AWS | 
| Dockerfile에서 생성된 Lambda 함수를 테스트합니다. | Lambda 함수 내에서 `psycopg2` 라이브러리를 사용하려면 Lambda Amazon Machine Image(AMI)를 편집해야 합니다.Dockerfile에서 생성된 Lambda 함수를 테스트하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/import-psycopg2-library-lambda.html)다음 코드는 AWS CDK 템플릿이 생성하는 Dockerfile을 보여줍니다.<pre># Start from lambda Python3.13 image<br />FROM public.ecr.aws/lambda/python:3.13<br /><br /># Copy the lambda code, together with its requirements<br />COPY lambda/requirements.txt ${LAMBDA_TASK_ROOT}<br />COPY lambda/lambda_code.py ${LAMBDA_TASK_ROOT}<br /><br /># Install postgresql-devel in your image<br />RUN yum install -y gcc postgresql-devel<br /><br /># install the requirements for the Lambda code<br />RUN pip3 install -r requirements.txt --target "${LAMBDA_TASK_ROOT}"<br /><br /># Command can be overwritten by providing a different command in the template directly.<br />CMD ["lambda_code.handler"]</pre>Dockerfile은 Python 런타임을 위해 AWS 제공된 Lambda 이미지를 가져와 [PostgreSQL 관리 서버와 직접 상호 작용하는 애플리케이션을 컴파일하는 데 필요한 라이브러리가 포함된 postgresql-devel](https://yum-info.contradodigital.com/view-package/updates/postgresql-devel/)을 설치합니다. PostgreSQL Dockerfile은 `requirements.txt` 파일에 표시된 `pandas` 및 `psycopg2` 라이브러리도 설치합니다. | 일반 AWS | 

## 관련 리소스
<a name="import-psycopg2-library-lambda-resources"></a>
+ [AWS CDK 설명서](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
+ [AWS Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)

## 추가 정보
<a name="import-psycopg2-library-lambda-additional"></a>

이 패턴에서 AWS CDK 템플릿은 다음 세 가지 리소스가 있는 AWS 스택을 제공합니다.
+ Lambda 변환 함수를 위한 IAM 역할
+ Python 런타임이 있는 Lambda 함수입니다. 함수는 배포 패키지에서 `Constructs/lambda/lambda_deploy.zip` 배포됩니다.
+ Python 런타임이 있는 Lambda 함수입니다. 함수는 `Constructs` 폴더 아래의 Dockerfile에서 배포됩니다.

두 Lambda 함수의 스크립트는 `pandas` 및 `psycopg2` 라이브러리를 성공적으로 가져오는지 확인합니다.

```
import pandas
print("pandas successfully imported")

import psycopg2
print("psycopg2 successfully imported")

def handler(event, context):
    """Function that checks whether psycopg2  and pandas are successfully imported or not"""
    return {"Status": "psycopg2 and pandas successfully imported"}
```

`lambda_deploy.zip` 배포 패키지는 `Constructs/lambda/build.sh` bash 스크립트로 빌드됩니다. 이 스크립트는 폴더를 생성하고, Lambda 스크립트를 복사하고, `pandas` 및 `psycopg2` 라이브러리를 설치하고, .zip 파일을 생성합니다. .zip 파일을 직접 생성하려면이 bash 스크립트를 실행하고 AWS CDK 스택을 재배포합니다.

Dockerfile은 Python 런타임이 있는 Lambda에 대해 AWS 제공된 기본 이미지로 시작합니다. Dockerfile은 기본 이미지 위에 `pandas` 및 `psycopg2` 라이브러리를 설치합니다.

# Amazon API Gateway를 Amazon SQS와 통합하여 비동기 REST API 처리
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis"></a>

*Natalia Colantonio Favero 및 Gustavo Martim, Amazon Web Services*

## 요약
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-summary"></a>

REST API를 배포할 때 클라이언트 애플리케이션이 게시할 수 있는 메시지 대기열을 공개해야 하는 경우가 있습니다. 예를 들어, 서드 파티 API의 지연이나 응답 지연 문제가 있을 수 있으며, 데이터베이스 쿼리의 응답 시간 문제를 방지하기를 원하거나, 대량의 동시 API 요청이 있을 때 서버 확장을 피하고 싶은 경우가 있습니다. 이러한 시나리오에서 대기열에 게시하는 클라이언트 애플리케이션은 API가 데이터를 수신했음을 알기만 하면 됩니다. 데이터가 수신된 후에는 어떤 일이 발생하는지 알 수 없습니다.

이 패턴은 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 엔드포인트를 생성합니다. [Amazon SQS](https://aws.amazon.com/sqs/) SQS 대기열에 직접 액세스하지 못하도록 두 서비스 간에 easy-to-implement 통합을 생성합니다.

## 사전 조건 및 제한 사항
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-prereqs"></a>
+ [활성 AWS 계정](https://portal.aws.amazon.com/billing/signup/iam)

## 아키텍처
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-architecture"></a>

![\[API Gateway를 Amazon SQS와 통합하기 위한 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/70984dee-e49f-4446-9d52-49ce826c3909/images/737ba0b2-da8f-4478-8c54-0a4835fd69f9.png)


이 다이어그램은 다음 단계들을 보여줍니다.

1. Postman, 다른 API 또는 기타 기술과 같은 도구를 사용하여 POST REST API 엔드포인트를 요청합니다.

1. API Gateway는 요청 본문에서 수신된 메시지를 대기열에 게시합니다.

1. Amazon SQS는 메시지를 수신하고 성공 또는 실패 코드와 함께 API Gateway에 답변을 보냅니다.

## 도구
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-tools"></a>
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)는 규모와 관계없이 REST, HTTP 및 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호하는 것을 지원합니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)는 분산 소프트웨어 시스템과 구성 요소를 통합하고 분리하는 데 도움이 되는 안전하고 내구성이 뛰어나며 가용성이 높은 호스팅 대기열을 제공합니다.  

## 에픽
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-epics"></a>

### SQS 대기열 생성
<a name="create-an-sqs-queue"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 대기열을 생성합니다. | REST API에서 메시지를 수신하는 SQS 대기열을 생성하려면[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 

### Amazon SQS에 대한 액세스 권한 제공
<a name="provide-access-to-sqs"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| IAM 역할을 생성합니다. | 이 IAM 역할은 API Gateway 리소스에 Amazon SQS에 대한 모든 액세스 권한을 부여합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자, AWS 관리자 | 

### REST API를 생성
<a name="create-a-rest-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| REST API를 생성합니다. | HTTP 요청이 전송되는 REST API입니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 
| API Gateway를 Amazon SQS에 연결합니다. | 이 단계를 통해 메시지는 HTTP 요청 본문 내에서 Amazon SQS로 흐를 수 있습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 

### REST API 테스트
<a name="test-the-rest-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| REST API를 테스트합니다. | 테스트를 실행하여 구성 누락 여부를 확인합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 
| API 통합을 변경하여 Amazon SQS에 요청을 올바르게 전달합니다. | 구성을 완료하여 통합 오류를 수정합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 
| Amazon SQS에서 메시지를 테스트하고 검증합니다. | 테스트를 실행하여 테스트가 성공적으로 완료되었는지 확인합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 
| 특수 문자로 API Gateway를 테스트합니다. | 메시지에서 허용되지 않는 특수 문자(예: &)가 포함된 테스트를 실행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)이는 메시지 본문에서 기본적으로 특수 문자가 지원되지 않기 때문입니다. 다음 단계에서는 특수 문자를 지원하도록 API Gateway를 구성합니다. 콘텐츠 유형 변환에 대한 자세한 내용은 [API Gateway 설명서를](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html) 참조하세요. | 앱 개발자 | 
| 특수 문자를 지원하도록 API 구성을 변경합니다. | 메시지에 특수 문자를 허용하도록 구성을 조정합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html)새 메시지에는 특수 문자가 포함되어야 합니다. | 앱 개발자 | 

### REST API 배포
<a name="deploy-the-rest-api"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| API를 배포합니다. |  REST API를 배포하려면:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 
| 외부 도구를 사용하여 테스트합니다. | 외부 도구를 사용하여 테스트를 실행하여 메시지가 성공적으로 수신되었는지 확인합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.html) | 앱 개발자 | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| API를 삭제합니다. | [API Gateway 콘솔](https://console.aws.amazon.com/apigateway/)에서 생성한 API를 선택한 다음 **삭제**를 선택합니다. | 앱 개발자 | 
| IAM 역할을 삭제합니다. | [IAM 콘솔](https://console.aws.amazon.com/iam/)의 **역할** 창에서 **AWSGatewayRoleForSQS**를 선택한 다음 **삭제**를 선택합니다. | 앱 개발자 | 
| SQS 대기열을 삭제합니다. | [Amazon SQS 콘솔](https://console.aws.amazon.com/sqs/)의 **대기열** 창에서 생성한 SQS 대기열을 선택한 다음 **삭제**를 선택합니다. | 앱 개발자 | 

## 관련 리소스
<a name="integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis-resources"></a>
+ [SQS-SendMessage](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services-reference.html#SQS-SendMessage)(API Gateway 설명서)
+ [API Gateway의 콘텐츠 유형 변환](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html)(API Gateway 설명서)
+ [\$1util 변수](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#util-template-reference)(API Gateway 설명서)
+ [API Gateway REST API를 Amazon SQS와 통합하고 일반적인 오류를 해결하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/api-gateway-rest-api-sqs-errors)(AWS re:Post 문서)

# Amazon API Gateway 및 AWS Lambda와 비동기적으로 이벤트 처리
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda"></a>

*Andrea Meroni, Mariem Kthiri, Nadim Majed, Michael Wallner, Amazon Web Services*

## 요약
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-summary"></a>

Amazon API Gateway는 개발자가 어떤 규모에서든 API를 생성, 게시, 유지 관리, 모니터링 및 보호하기 위해 사용할 수 있는 완전 관리형 서비스입니다. API Gateway는 최대 수십만 개의 동시 API 호출 허용 및 처리에 관련된 모든 작업을 다룹니다.

API Gateway의 중요한 Service Quotas는 통합 제한 시간입니다. 제한 시간은 REST API가 오류를 반환하기 전에 백엔드 서비스가 응답을 반환해야 하는 최대 시간입니다. 동기식 워크로드에는 일반적으로 29초의 하드 제한이 허용됩니다. 그러나이 제한은 API Gateway를 비동기 워크로드와 함께 사용하려는 개발자에게 어려운 점을 나타냅니다.

이 패턴은 API Gateway 및를 사용하여 이벤트를 비동기적으로 처리하는 예제 아키텍처를 보여줍니다 AWS Lambda. 아키텍처는 최대 15분의 기간 동안 처리 작업 실행을 지원하며 기본 REST API를 인터페이스로 사용합니다.

[Projen](https://pypi.org/project/projen/)은 로컬 개발 환경을 설정하고 [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) AWS 계정, [Docker](https://docs.docker.com/get-docker/) 및 [Node.js](https://nodejs.org/en/download/)와 함께 예제 아키텍처를 대상에 배포하는 데 사용됩니다. Projen은 [사전 커밋](https://pre-commit.com/)과 코드 품질 보증, 보안 스캔 및 단위 테스트에 사용되는 도구를 사용하여 [Python](https://www.python.org/downloads/) 가상 환경을 자동으로 설정합니다. 자세한 정보는 [의 ](#process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-tools) 섹션을 참조하세요.

## 사전 조건 및 제한 사항
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-prereqs"></a>

**사전 조건**
+ 활성 AWS 계정
+ 워크스테이션에 설치된 도구는 다음과 같습니다.
  + [AWS Cloud Development Kit (AWS CDK) 도구 키트](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) 버전 2.85.0
  + [Docker](https://docs.docker.com/get-docker/) 버전 20.10.21
  + [Node.js](https://nodejs.org/en/download/) 버전 18.13.0
  + [Projen](https://pypi.org/project/projen/) 버전 0.71.111
  + [Python](https://www.python.org/downloads/) 버전 3.9.16

**제한 사항**
+ 작업의 최대 런타임은 Lambda 함수의 최대 런타임(15분)으로 제한됩니다.
+ 동시 작업 요청의 최대 수는 Lambda 함수의 예약된 동시성에 의해 제한됩니다.

## 아키텍처
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-architecture"></a>

다음 다이어그램은 작업 API와 이벤트 처리 및 오류 처리 Lambda 함수와 Amazon EventBridge 이벤트 아카이브에 저장된 이벤트의 상호 작용을 보여줍니다.

![\[AWS 클라우드 architecture showing user interaction with jobs API, Lambda functions, and EventBridge.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e027130c-44c1-41ab-bbe9-f196a49bd9ac/images/3c437b65-48e3-477d-aeea-6ff938cc3285.png)


일반적인 워크플로에는 다음 단계가 포함됩니다.

1.  AWS Identity and Access Management (IAM)에 대해 인증하고 보안 자격 증명을 얻습니다.

1. `/jobs` 작업 API 엔드포인트에 HTTP `POST` 요청을 전송하여 요청 본문에 작업 파라미터를 지정합니다.

1. API Gateway REST API인 작업 API는 작업 식별자가 포함된 HTTP 응답을 반환합니다.

1. 작업 API는 이벤트 처리 Lambda 함수를 비동기적으로 간접 호출합니다.

1. 이벤트 처리 함수는 이벤트를 처리한 다음 작업 결과를 Amazon DynamoDB 테이블에 넣습니다.

1. 3단계의 `/jobs/{jobId}` 작업 식별자를 로 사용하여 작업 API 엔드포인트에 HTTP `GET` 요청을 보냅니다`{jobId}`.

1. 작업 API는 `jobs` DynamoDB 테이블을 쿼리하여 작업 결과를 검색합니다.

1. 작업 API는 작업 결과가 포함된 HTTP 응답을 반환합니다.

1. 이벤트 처리가 실패하면 이벤트 처리 함수는 이벤트를 오류 처리 함수로 보냅니다.

1. 오류 처리 함수는 `jobs` DynamoDB 테이블에 작업 파라미터를 넣습니다.

1. 작업 API 엔드포인트에 HTTP `GET` 요청을 전송하여 `/jobs/{jobId}` 작업 파라미터를 검색할 수 있습니다.

1. 오류 처리가 실패하면 오류 처리 함수는 이벤트를 EventBridge 이벤트 아카이브로 보냅니다.

   EventBridge를 사용하여 아카이브된 이벤트를 재생할 수 있습니다.

## 도구
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-tools"></a>

**서비스**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)는 코드로 AWS 클라우드 인프라를 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 통해 AWS 서비스와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 다양한 소스의 실시간 데이터와 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. 예를 들어 함수, API 대상을 사용하는 HTTP 호출 엔드포인트, 다른 의 이벤트 버스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.

**기타 도구**
+ [autopep8](https://github.com/hhatto/autopep8)은 Python 개선 제안(PEP) 8 스타일 가이드를 기반으로 Python 코드의 형식을 자동으로 지정합니다.
+ [Bandit](https://bandit.readthedocs.io/en/latest/)은 Python 코드를 스캔하여 일반적인 보안 문제를 찾습니다.
+ [커미티브](https://commitizen-tools.github.io/commitizen/)는 Git 커밋 검사기 및 `CHANGELOG` 생성기입니다.
+ [cfn-lint](https://github.com/aws-cloudformation/cfn-lint)는 AWS CloudFormation 린터입니다.
+ [BridgeCrew Checkov](https://github.com/bridgecrewio/checkov)는 코드형 인프라(IaC) 파일을 스캔하여 보안 또는 규정 준수 문제로 이어질 수 있는 구성 오류를 찾기 위한 정적 코드 분석 도구입니다.
+ [jq](https://stedolan.github.io/jq/download/)는 JSON을 파싱하기 위한 명령줄 도구입니다.
+ [Postman](https://www.postman.com/)은 API 플랫폼입니다.
+ [사전 커밋](https://pre-commit.com/)은 Git 후크 관리자입니다.
+ [Projen](https://github.com/projen/projen)은 프로젝트 생성기입니다.
+ [pytest](https://docs.pytest.org/en/7.2.x/index.html)는 작고 읽기 쉬운 테스트를 작성하기 위한 Python 프레임워크입니다.

**코드 리포지토리**

이 예시 아키텍처 코드는 [API Gateway 및 Lambda 리포지토리를 사용한 GitHub 비동기 이벤트 처리](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk)에서 확인할 수 있습니다.

## 모범 사례
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-best-practices"></a>
+ 이 예시 아키텍처에는 배포된 인프라에 대한 모니터링이 포함되지 않습니다. 사용 사례에 모니터링이 필요한 경우 [CDK Monitoring Constructs](https://constructs.dev/packages/cdk-monitoring-constructs) 또는 다른 모니터링 솔루션 추가를 평가합니다.
+ 이 예시 아키텍처는 [IAM 권한](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)을 사용하여 작업 API에 대한 액세스를 제어합니다. `JobsAPIInvokeRole`를 수임할 권한이 있는 사람은 누구나 작업 API를 간접적으로 호출할 수 있습니다. 따라서 액세스 제어 메커니즘은 바이너리입니다. 사용 사례에 더 복잡한 권한 부여 모델이 필요한 경우 다른 [액세스 제어 메커니즘](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)을 사용하여를 평가합니다.
+ 사용자가 `/jobs` 작업 API 엔드포인트에 HTTP `POST` 요청을 보내면 입력 데이터가 두 가지 수준에서 검증됩니다.
  + Amazon API Gateway는 첫 번째 [요청 검증](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)을 담당합니다.
  + 이벤트 처리 함수는 두 번째 요청을 수행합니다.

    사용자가 `/jobs/{jobId}` 작업 API 엔드포인트에 대한 HTTP `GET` 요청을 수행할 때는 검증이 수행되지 않습니다. 사용 사례에 추가 입력 검증과 보안 강화가 필요한 경우 [AWS WAF를 사용하여 API를 보호](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)하는 방안을 평가합니다.

## 에픽
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-epics"></a>

### 환경 설정
<a name="set-up-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-lambda-cdk.git</pre> | DevOps 엔지니어 | 
| 프로젝트를 설정합니다. | 디렉터리를 리포지토리 루트로 변경하고 [Projen](https://github.com/projen/projen)을 사용하여 Python 가상 환경과 모든 도구를 설정합니다.<pre>cd asynchronous-event-processing-api-gateway-api-gateway-lambda-cdk<br />npx projen</pre> | DevOps 엔지니어 | 
| 커밋 전 후크를 설치합니다. | 커밋 전 후크를 설치하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | DevOps 엔지니어 | 

### 예시 아키텍처 배포
<a name="deploy-the-example-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 부트스트랩 AWS CDK. |  AWS CDK 에서 부트스트랩하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap</pre> | DevOps | 
| 예시 아키텍처를 배포합니다. | 에 예제 아키텍처를 배포하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy</pre> | DevOps | 

### 아키텍처 테스트
<a name="test-the-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 사전 조건을 설치합니다. | 워크스테이션에 [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), [Postman](https://www.postman.com/downloads/) 및 [jq](https://jqlang.github.io/jq/)를 설치합니다.[Postman](https://www.postman.com/downloads/)을 사용하여 이 예시 아키텍처를 테스트하는 것이 좋지만 필수는 아닙니다. 대체 API 테스트 도구를 선택하는 경우 [AWS 서명 버전 4 인증을](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html) 지원하는지 확인하고 [REST API를 내보내 검사할 수 있는 노출된 API 엔드포인트를](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) 참조하세요. | DevOps 엔지니어 | 
| 를 가정합니다`JobsAPIInvokeRole`. | 배포 명령에서 출력으로 `JobsAPIInvokeRole` 인쇄된를 [가정](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)합니다.<pre>CREDENTIALS=$(AWS_PROFILE=$<YOUR_AWS_PROFILE> aws sts assume-role \<br />--no-cli-pager \<br />--role-arn $<JOBS_API_INVOKE_ROLE_ARN> \<br />--role-session-name JobsAPIInvoke)<br />export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)<br />export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)<br />export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)</pre> | DevOps | 
| Postman을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | DevOps | 
| 예시 아키텍처를 테스트합니다. | 예시 아키텍처를 테스트하려면 작업 API로 요청을 보냅니다. 자세한 내용은 [Python 설명서](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)를 참조하세요. | DevOps 엔지니어 | 

## 문제 해결
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| [Amazon CloudWatch Logs 로그 그룹](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs`가 이미 존재하므로 예제 아키텍처의 폐기 및 후속 재배포가 실패합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda.html) | 

## 관련 리소스
<a name="process-events-asynchronously-with-amazon-api-gateway-and-aws-lambda-resources"></a>
+ [API Gateway 매핑 템플릿 및 액세스 로깅 변수 참조](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html)
+ [백엔드 Lambda 함수의 비동기 호출 설정](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-integration-async.html)

# Amazon API Gateway 및 Amazon DynamoDB Streams와 비동기적으로 이벤트 처리
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams"></a>

*Andrea Meroni, Mariem Kthiri, Nadim Majed, Alessandro Trisolini, Michael Wallner, Amazon Web Services*

## 요약
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-summary"></a>

Amazon API Gateway는 개발자가 어떤 규모에서든 API를 생성, 게시, 유지 관리, 모니터링 및 보호하기 위해 사용할 수 있는 완전 관리형 서비스입니다. API Gateway는 최대 수십만 개의 동시 API 호출 허용 및 처리에 관련된 모든 작업을 다룹니다.

API Gateway의 중요한 Service Quotas는 통합 제한 시간입니다. 제한 시간은 REST API가 오류를 반환하기 전에 백엔드 서비스가 응답을 반환해야 하는 최대 시간입니다. 동기식 워크로드에는 일반적으로 29초의 하드 제한이 허용됩니다. 그러나이 제한은 API Gateway를 비동기 워크로드와 함께 사용하려는 개발자에게 어려운 점을 나타냅니다.

이 패턴은 API Gateway, Amazon DynamoDB Streams 및를 사용하여 이벤트를 비동기적으로 처리하기 위한 예제 아키텍처를 보여줍니다 AWS Lambda. 아키텍처는 동일한 입력 파라미터로 병렬 처리 작업 실행을 지원하며 기본 REST API를 인터페이스로 사용합니다. 이 예에서는 Lambda를 백엔드로 사용하여 작업 기간을 15분으로 제한합니다. 대체 서비스를 사용하여 수신 이벤트(예: )를 처리하면이 제한을 피할 수 있습니다 AWS Fargate.

[Projen](https://pypi.org/project/projen/)은 로컬 개발 환경을 설정하고 [AWS Cloud Development Kit (AWS CDK) Toolkit](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) AWS 계정, [Docker](https://docs.docker.com/get-docker/) 및 [Node.js](https://nodejs.org/en/download/)와 함께 예제 아키텍처를 대상에 배포하는 데 사용됩니다. Projen은 [사전 커밋](https://pre-commit.com/)과 코드 품질 보증, 보안 스캔 및 단위 테스트에 사용되는 도구를 사용하여 [Python](https://www.python.org/downloads/) 가상 환경을 자동으로 설정합니다. 자세한 정보는 [의 ](#processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-tools) 섹션을 참조하세요.

## 사전 조건 및 제한 사항
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-prereqs"></a>

**사전 조건**
+ 활성 AWS 계정
+ 워크스테이션에 설치된 도구는 다음과 같습니다.
  + [AWS Cloud Development Kit (AWS CDK) 도구 키트](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) 버전 2.85.0 이상
  + [Docker](https://docs.docker.com/get-docker/) 버전 20.10.21 이상
  + Node.js 버전 18 이상
  + [Projen](https://pypi.org/project/projen/) 버전 0.71.111 이상
  + Python 버전 3.9.16 이상

**제한 사항**
+ 제한을 방지하기 위해 DynamoDB Streams에 권장되는 최대 리더 수는 2개입니다.
+ 작업의 최대 런타임은 Lambda 함수의 최대 런타임(15분)으로 제한됩니다.
+ 동시 작업 요청의 최대 수는 Lambda 함수의 예약된 동시성에 의해 제한됩니다.

## 아키텍처
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-architecture"></a>

**아키텍처**

다음 다이어그램은 작업 API와 DynamoDB Streams의 상호 작용과 이벤트 처리 및 오류 처리 Lambda 함수와 Amazon EventBridge 이벤트 아카이브에 저장된 이벤트를 보여줍니다.

![\[아키텍처 및 프로세스 다이어그램, 다이어그램 뒤에 나열된 단계.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/68a46501-16e5-48e4-99c6-fc67a8b4133a/images/29fe6982-ad81-4099-9c65-08b17c96e78f.png)


일반적인 워크플로에는 다음 단계가 포함됩니다.

1.  AWS Identity and Access Management (IAM)에 대해 인증하고 보안 자격 증명을 얻습니다.

1. `POST` 요청 본문에 `/jobs` 작업 파라미터를 지정하여 작업 API 엔드포인트에 HTTP 요청을 보냅니다.

1. 작업 API는 작업 식별자가 포함된 HTTP 응답을 반환합니다.

1. 작업 API는 `jobs_table` Amazon DynamoDB 테이블에 작업 파라미터를 저장합니다.

1. `jobs_table` DynamoDB 테이블 DynamoDB 스트림은 이벤트 처리 Lambda 함수를 간접적으로 호출합니다.

1. 이벤트 처리 Lambda 함수는 이벤트를 처리한 다음 `jobs_table` DynamoDB 테이블에 작업 결과를 넣습니다. 일관된 결과를 보장하기 위해 이벤트 처리 함수는 [낙관적 잠금](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html) 메커니즘을 구현합니다.

1. 3단계의 `/jobs/{jobId}` 작업 식별자를 로 사용하여 작업 API 엔드포인트에 HTTP `GET` 요청을 보냅니다`{jobId}`.

1. 작업 API는 `jobs_table` DynamoDB 테이블을 쿼리하여 작업 결과를 검색합니다.

1. 작업 API는 작업 결과가 포함된 HTTP 응답을 반환합니다.

1. 이벤트 처리가 실패하면 이벤트 처리 함수의 소스 매핑이 이벤트를 오류 처리 Amazon Simple Notification Service(Amazon SNS) 주제로 보냅니다.

1. 오류 처리 SNS 주제는 이벤트를 오류 처리 함수로 비동기적으로 푸시합니다.

1. 오류 처리 함수는 `jobs_table` DynamoDB 테이블에 작업 파라미터를 저장합니다.

   작업 API 엔드포인트에 HTTP `GET` 요청을 전송하여 `/jobs/{jobId}` 작업 파라미터를 검색할 수 있습니다.

1. 오류 처리가 실패하면 오류 처리 함수가 이벤트를 Amazon EventBridge 아카이브로 보냅니다.

   EventBridge를 사용하여 아카이브된 이벤트를 재생할 수 있습니다.

## 도구
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-tools"></a>

**서비스**
+ AWS Cloud Development Kit(AWS CDK)는 AWS 클라우드 인프라를 코드로 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 다양한 소스의 실시간 데이터와 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. AWS Lambda 함수, API 대상을 사용하는 HTTP 간접 호출 엔드포인트 또는 다른 AWS 계정의 이벤트 버스를 예로 들 수 있습니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.

**기타 도구**
+ [autopep8](https://github.com/hhatto/autopep8)은 Python 개선 제안(PEP) 8 스타일 가이드를 기반으로 Python 코드의 형식을 자동으로 지정합니다.
+ [Bandit](https://bandit.readthedocs.io/en/latest/)은 Python 코드를 스캔하여 일반적인 보안 문제를 찾습니다.
+ [커미티브](https://commitizen-tools.github.io/commitizen/)는 Git 커밋 검사기 및 `CHANGELOG` 생성기입니다.
+ [cfn-lint](https://github.com/aws-cloudformation/cfn-lint)는 AWS CloudFormation 린터입니다.
+ [BridgeCrew Checkov](https://github.com/bridgecrewio/checkov)는 코드형 인프라(IaC) 파일을 스캔하여 보안 또는 규정 준수 문제로 이어질 수 있는 구성 오류를 찾기 위한 정적 코드 분석 도구입니다.
+ [jq](https://stedolan.github.io/jq/download/)는 JSON을 파싱하기 위한 명령줄 도구입니다.
+ [Postman](https://www.postman.com/)은 API 플랫폼입니다.
+ [사전 커밋](https://pre-commit.com/)은 Git 후크 관리자입니다.
+ [Projen](https://github.com/projen/projen)은 프로젝트 생성기입니다.
+ [pytest](https://docs.pytest.org/en/7.2.x/index.html)는 작고 읽기 쉬운 테스트를 작성하기 위한 Python 프레임워크입니다.

**코드 리포지토리**

이 예시 아키텍처 코드는 [API Gateway 및 DynamoDB Streams를 사용한 GitHub 비동기 처리](https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk) 리포지토리에서 찾을 수 있습니다.

## 모범 사례
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-best-practices"></a>
+ 이 예시 아키텍처에는 배포된 인프라에 대한 모니터링이 포함되지 않습니다. 사용 사례에 모니터링이 필요한 경우 [CDK Monitoring Constructs](https://constructs.dev/packages/cdk-monitoring-constructs) 또는 다른 모니터링 솔루션 추가를 평가합니다.
+ 이 예시 아키텍처는 [IAM 권한](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)을 사용하여 작업 API에 대한 액세스를 제어합니다. `JobsAPIInvokeRole`를 수임할 권한이 있는 사람은 누구나 작업 API를 간접적으로 호출할 수 있습니다. 따라서 액세스 제어 메커니즘은 바이너리입니다. 사용 사례에 더 복잡한 권한 부여 모델이 필요한 경우 다른 [액세스 제어 메커니즘](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)을 사용하여를 평가합니다.
+ 사용자가 `/jobs` 작업 API 엔드포인트에 HTTP `POST` 요청을 보내면 입력 데이터는 두 가지 수준에서 검증됩니다.
  + API Gateway는 첫 번째 [요청 검증](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)을 담당합니다.
  + 이벤트 처리 함수는 두 번째 요청을 수행합니다.

    사용자가 `/jobs/{jobId}` 작업 API 엔드포인트에 대한 HTTP `GET` 요청을 수행할 때는 검증이 수행되지 않습니다. 사용 사례에 추가 입력 검증과 보안 강화가 필요한 경우를 [사용하여 API를 보호 AWS WAF 하십시오](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html).
+ 제한을 방지하기 위해 [DynamoDB Streams 설명서](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.Processing)는 사용자가 동일한 스트림의 샤드에서 두 명 이상의 소비자와 함께 읽지 않도록 합니다. 소비자 수를 확장하려면 [Amazon Kinesis Data Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)를 사용하는 것이 좋습니다.
+ 이 예에서는 `jobs_table` DynamoDB 테이블의 항목을 일관되게 업데이트하기 위해 [낙관적 잠금](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)이 사용되었습니다. 사용 사례 요구 사항에 따라 비관적 잠금과 같은 보다 안정적인 잠금 메커니즘을 구현해야 할 수 있습니다.

## 에픽
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-epics"></a>

### 환경 설정
<a name="set-up-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-dynamodb-streams-cdk.git</pre> | DevOps 엔지니어 | 
| 프로젝트를 설정합니다. | 디렉터리를 리포지토리 루트로 변경하고 [Projen](https://github.com/projen/projen)을 사용하여 Python 가상 환경과 모든 도구를 설정합니다.<pre>cd asynchronous-event-processing-api-gateway-api-gateway-dynamodb-streams-cdk<br />npx projen</pre> | DevOps 엔지니어 | 
| 커밋 전 후크를 설치합니다. | 커밋 전 후크를 설치하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | DevOps 엔지니어 | 

### 예시 아키텍처 배포
<a name="deploy-the-example-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 부트스트랩 AWS CDK. | [AWS CDK](https://aws.amazon.com/cdk/)에서 부트스트랩하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap</pre> | DevOps | 
| 예시 아키텍처를 배포합니다. | 에 예제 아키텍처를 배포하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy</pre> | DevOps | 

### 아키텍처 테스트
<a name="test-the-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 사전 조건을 설치합니다. | 워크스테이션에 [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), [Postman](https://www.postman.com/downloads/) 및 [jq](https://jqlang.github.io/jq/)를 설치합니다.[Postman](https://www.postman.com/downloads/)을 사용하여 이 예시 아키텍처를 테스트하는 것이 좋지만 필수는 아닙니다. 대체 API 테스트 도구를 선택하는 경우 [AWS 서명 버전 4 인증을](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html) 지원하는지 확인하고 [REST API를 내보내 검사할 수 있는 노출된 API 엔드포인트를](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) 참조하세요. | DevOps 엔지니어 | 
| 를 가정합니다`JobsAPIInvokeRole`. | `deploy` 명령에서 출력으로 `JobsAPIInvokeRole` 인쇄된 [를 가정](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)합니다.<pre>CREDENTIALS=$(AWS_PROFILE=$<YOUR_AWS_PROFILE> aws sts assume-role \<br />--no-cli-pager \<br />--role-arn $<JOBS_API_INVOKE_ROLE_ARN> \<br />--role-session-name JobsAPIInvoke)<br />export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)<br />export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)<br />export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)</pre> | DevOps | 
| Postman을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | DevOps | 
| 예시 아키텍처를 테스트합니다. | 예시 아키텍처를 테스트하려면 작업 API로 요청을 보냅니다. 자세한 내용은 [Python 설명서](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)를 참조하세요. | DevOps 엔지니어 | 

## 문제 해결
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| [Amazon CloudWatch Logs 로그 그룹](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs`가 이미 존재하므로 예제 아키텍처의 폐기 및 후속 재배포가 실패합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams.html) | 

## 관련 리소스
<a name="processing-events-asynchronously-with-amazon-api-gateway-and-amazon-dynamodb-streams-resources"></a>
+ [API Gateway 매핑 템플릿 및 액세스 로깅 변수 참조](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html)
+ [DynamoDB Streams의 데이터 캡처 변경](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html)
+ [버전 번호를 사용한 낙관적 잠금](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)
+ [Kinesis Data Streams를 사용하여 DynamoDB 변경 사항 캡처](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html)

# Amazon API Gateway, Amazon SQS 및 AWS Fargate와 비동기적으로 이벤트 처리
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate"></a>

*Andrea Meroni, Mariem Kthiri, Nadim Majed, Alessandro Trisolini, Michael Wallner, Amazon Web Services*

## 요약
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-summary"></a>

Amazon API Gateway는 개발자가 어떤 규모에서든 API를 생성, 게시, 유지 관리, 모니터링 및 보호하기 위해 사용할 수 있는 완전 관리형 서비스입니다. API Gateway는 최대 수십만 개의 동시 API 호출 허용 및 처리에 관련된 모든 작업을 다룹니다.

API Gateway의 중요한 Service Quotas는 통합 제한 시간입니다. 제한 시간은 REST API가 오류를 반환하기 전에 백엔드 서비스가 응답을 반환해야 하는 최대 시간입니다. 동기식 워크로드에는 일반적으로 29초의 하드 제한이 허용됩니다. 그러나이 제한은 API Gateway를 비동기 워크로드와 함께 사용하려는 개발자에게 어려운 점을 나타냅니다.

이 패턴은 API Gateway, Amazon Simple Queue Service(Amazon SQS) 및를 사용하여 이벤트를 비동기적으로 처리하는 예제 아키텍처를 보여줍니다 AWS Fargate. 아키텍처는 기간 제한 없이 처리 작업 실행을 지원하며 기본 REST API를 인터페이스로 사용합니다.

[Projen](https://pypi.org/project/projen/)은 로컬 개발 환경을 설정하고 AWS 계정, [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) [Docker](https://docs.docker.com/get-docker/) 및 [Node.js](https://nodejs.org/en/download/)와 함께 예제 아키텍처를 대상에 배포하는 데 사용됩니다. Projen은 [사전 커밋](https://pre-commit.com/)과 코드 품질 보증, 보안 스캔 및 단위 테스트에 사용되는 도구를 사용하여 [Python](https://www.python.org/downloads/) 가상 환경을 자동으로 설정합니다. 자세한 정보는 [의 ](#process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-tools) 섹션을 참조하세요.

## 사전 조건 및 제한 사항
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ 워크스테이션에 설치된 도구는 다음과 같습니다.
  + [AWS Cloud Development Kit (AWS CDK) 도구 키트](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) 버전 2.85.0 이상
  + [Docker](https://docs.docker.com/get-docker/) 버전 20.10.21 이상
  + Node.js 버전 18 이상
  + [Projen](https://pypi.org/project/projen/) 버전 0.71.111 이상
  + Python 버전 3.9.16 이상

**제한 사항 **
+ 동시 작업은 분당 500개의 작업으로 제한되며, 이는 Fargate가 프로비저닝할 수 있는 최대 작업 수입니다.

## 아키텍처
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-architecture"></a>

다음 다이어그램은 작업 API와 `jobs` Amazon DynamoDB 테이블, 이벤트 처리 Fargate 서비스 및 오류 처리 AWS Lambda 함수의 상호 작용을 보여줍니다. 이벤트는 Amazon EventBridge 이벤트 아카이브에 저장됩니다.

![\[다이어그램 다음에 설명이 있는 아키텍처 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/8a03149c-8f34-4593-84d5-accc1800a0a2/images/5e1071aa-4fbc-495c-bc22-8e62a32a136b.png)


일반적인 워크플로에는 다음 단계가 포함됩니다.

1.  AWS Identity and Access Management (IAM)에 대해 인증하고 보안 자격 증명을 얻습니다.

1. `/jobs` 작업 API 엔드포인트에 HTTP `POST` 요청을 전송하여 요청 본문에 작업 파라미터를 지정합니다.

1. API Gateway REST API인 작업 API는 작업 식별자가 포함된 HTTP 응답을 반환합니다.

1. 작업 API는 SQS 대기열에 메시지를 보냅니다.

1. Fargate는 SQS 대기열에서 메시지를 가져와 이벤트를 처리한 다음 `jobs` DynamoDB 테이블에 작업 결과를 넣습니다.

1. 3단계의 `/jobs/{jobId}` 작업 식별자를 로 사용하여 작업 API 엔드포인트에 HTTP `GET` 요청을 보냅니다`{jobId}`.

1. 작업 API는 `jobs` DynamoDB 테이블을 쿼리하여 작업 결과를 검색합니다.

1. 작업 API는 작업 결과가 포함된 HTTP 응답을 반환합니다.

1. 이벤트 처리가 실패하면 SQS 대기열은 이벤트를 DLQ(Dead Letter Queue)로 보냅니다.

1. EventBridge 이벤트는 오류 처리 함수를 시작합니다.

1. 오류 처리 함수는 `jobs` DynamoDB 테이블에 작업 파라미터를 넣습니다.

1. 작업 API 엔드포인트에 HTTP `GET` 요청을 전송하여 `/jobs/{jobId}` 작업 파라미터를 검색할 수 있습니다.

1. 오류 처리가 실패하면 오류 처리 함수는 이벤트를 EventBridge 아카이브로 보냅니다.

   EventBridge를 사용하여 아카이브된 이벤트를 재생할 수 있습니다.

## 도구
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-tools"></a>

**서비스**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)는 코드로 AWS 클라우드 인프라를 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ AWS Fargate를 사용하면 서버 또는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 관리할 필요 없이 컨테이너를 실행할 수 있습니다. Amazon Elastic Container Service(Amazon ECS)와 함께 사용합니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 다양한 소스의 실시간 데이터와 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. 예를 들어 함수, API 대상을 사용하는 HTTP 호출 엔드포인트, 다른 의 이벤트 버스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다.

**기타 도구**
+ [autopep8](https://github.com/hhatto/autopep8)은 Python 개선 제안(PEP) 8 스타일 가이드를 기반으로 Python 코드의 형식을 자동으로 지정합니다.
+ [Bandit](https://bandit.readthedocs.io/en/latest/)은 Python 코드를 스캔하여 일반적인 보안 문제를 찾습니다.
+ [커미티브](https://commitizen-tools.github.io/commitizen/)는 Git 커밋 검사기 및 `CHANGELOG` 생성기입니다.
+ [cfn-lint](https://github.com/aws-cloudformation/cfn-lint)는 AWS CloudFormation 린터입니다.
+ [BridgeCrew Checkov](https://github.com/bridgecrewio/checkov)는 코드형 인프라(IaC) 파일을 스캔하여 보안 또는 규정 준수 문제로 이어질 수 있는 구성 오류를 찾기 위한 정적 코드 분석 도구입니다.
+ [jq](https://stedolan.github.io/jq/download/)는 JSON을 파싱하기 위한 명령줄 도구입니다.
+ [Postman](https://www.postman.com/)은 API 플랫폼입니다.
+ [사전 커밋](https://pre-commit.com/)은 Git 후크 관리자입니다.
+ [Projen](https://github.com/projen/projen)은 프로젝트 생성기입니다.
+ [pytest](https://docs.pytest.org/en/7.2.x/index.html)는 작고 읽기 쉬운 테스트를 작성하기 위한 Python 프레임워크입니다.

**코드 리포지토리**

이 예시 아키텍처 코드는 API Gateway 및 SQS 리포지토리를 사용한 GitHub 비동기 처리에서 찾을 수 있습니다. 

## 모범 사례
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-best-practices"></a>
+ 이 예시 아키텍처에는 배포된 인프라에 대한 모니터링이 포함되지 않습니다. 사용 사례에 모니터링이 필요한 경우 [CDK Monitoring Constructs](https://constructs.dev/packages/cdk-monitoring-constructs) 또는 다른 모니터링 솔루션 추가를 평가합니다.
+ 이 예시 아키텍처는 [IAM 권한](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)을 사용하여 작업 API에 대한 액세스를 제어합니다. `JobsAPIInvokeRole`를 수임할 권한이 있는 사람은 누구나 작업 API를 간접적으로 호출할 수 있습니다. 따라서 액세스 제어 메커니즘은 바이너리입니다. 사용 사례에 더 복잡한 권한 부여 모델이 필요한 경우 다른 [액세스 제어 메커니즘](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html)을 사용하여를 평가합니다.
+ 사용자가 `/jobs` 작업 API 엔드포인트에 HTTP `POST` 요청을 보내면 입력 데이터는 두 가지 수준에서 검증됩니다.
  + API Gateway는 첫 번째 [요청 검증](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html)을 담당합니다.
  + 이벤트 처리 함수는 두 번째 요청을 수행합니다.

    사용자가 `/jobs/{jobId}` 작업 API 엔드포인트에 대한 HTTP `GET` 요청을 수행할 때는 검증이 수행되지 않습니다. 사용 사례에 추가 입력 검증과 보안 강화가 필요한 경우를 [사용하여 API를 보호 AWS WAF 하십시오](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html).

## 에픽
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-epics"></a>

### 환경 설정
<a name="set-up-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 리포지토리를 복제하려면 다음 명령을 실행합니다.<pre>git clone https://github.com/aws-samples/asynchronous-event-processing-api-gateway-sqs-cdk.git</pre> | DevOps 엔지니어 | 
| 프로젝트를 설정합니다. | 디렉터리를 리포지토리 루트로 변경하고 [Projen](https://github.com/projen/projen)을 사용하여 Python 가상 환경과 모든 도구를 설정합니다.<pre>cd asynchronous-event-processing-api-gateway-api-gateway-sqs-cdk<br />npx projen</pre> | DevOps 엔지니어 | 
| 커밋 전 후크를 설치합니다. | 커밋 전 후크를 설치하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | DevOps 엔지니어 | 

### 예시 아키텍처 배포
<a name="deploy-the-example-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 부트스트랩 AWS CDK. | [AWS CDK](https://aws.amazon.com/cdk/)에서 부트스트랩하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen bootstrap</pre> | DevOps | 
| 예시 아키텍처를 배포합니다. | 에 예제 아키텍처를 배포하려면 다음 명령을 AWS 계정실행합니다.<pre>AWS_PROFILE=$YOUR_AWS_PROFILE npx projen deploy</pre> | DevOps | 

### 아키텍처 테스트
<a name="test-the-architecture"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 사전 조건을 설치합니다. | 워크스테이션에 [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), [Postman](https://www.postman.com/downloads/) 및 [jq](https://jqlang.github.io/jq/)를 설치합니다.[Postman](https://www.postman.com/downloads/)을 사용하여 이 예시 아키텍처를 테스트하는 것이 좋지만 필수는 아닙니다. 대체 API 테스트 도구를 선택하는 경우 [AWS 서명 버전 4 인증을](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html) 지원하는지 확인하고 [REST API를 내보내 검사할 수 있는 노출된 API 엔드포인트를](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) 참조하세요. | DevOps 엔지니어 | 
| 를 가정합니다`JobsAPIInvokeRole`. | `deploy` 명령에서 출력으로 `JobsAPIInvokeRole` 인쇄된 [를 가정](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)합니다.<pre>CREDENTIALS=$(AWS_PROFILE=$<YOUR_AWS_PROFILE> aws sts assume-role \<br />--no-cli-pager \<br />--role-arn $<JOBS_API_INVOKE_ROLE_ARN> \<br />--role-session-name JobsAPIInvoke)<br />export AWS_ACCESS_KEY_ID=$(cat $CREDENTIALS | jq ‘.Credentials’’.AccessKeyId’)<br />export AWS_SECRET_ACCESS_KEY=$(cat $CREDENTIALS | jq ‘.Credentials’’.SecretAccessKey’)<br />export AWS_SESSION_TOKEN==$(cat $CREDENTIALS | jq ‘.Credentials’’.SessionToken’)</pre> | DevOps | 
| Postman을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | DevOps | 
| 예시 아키텍처를 테스트합니다. | 예시 아키텍처를 테스트하려면 작업 API로 요청을 보냅니다. 자세한 내용은 [Python 설명서](https://learning.postman.com/docs/getting-started/first-steps/sending-the-first-request/#send-an-api-request)를 참조하세요. | DevOps 엔지니어 | 

## 문제 해결
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| [Amazon CloudWatch Logs 로그 그룹](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/apigateway/JobsAPIAccessLogs`가 이미 존재하므로 예제 아키텍처의 폐기 및 후속 재배포가 실패합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | 
| [CloudWatch Logs 로그 그룹](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) `/aws/ecs/EventProcessingServiceLogs`가 이미 존재하므로 예제 아키텍처의 폐기 및 후속 재배포가 실패합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate.html) | 

## 관련 리소스
<a name="process-events-asynchronously-with-amazon-api-gateway-amazon-sqs-and-aws-fargate-resources"></a>
+ [API Gateway 매핑 템플릿 및 액세스 로깅 변수 참조](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html)
+ [API Gateway REST API를 Amazon SQS하고 일반적인 오류를 해결하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-rest-api-sqs-errors/)

# AWS Step Functions에서 AWS Systems Manager Automation 작업을 동기적으로 실행
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions"></a>

*Elie El khoury, Amazon Web Services*

## 요약
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-summary"></a>

이 패턴은 AWS Step Functions 와를 통합하는 방법을 설명합니다 AWS Systems Manager. AWS SDK 서비스 통합을 사용하여 상태 시스템 워크플로의 작업 토큰으로 Systems Manager **startAutomationExecution** API를 호출하고 토큰이 성공 또는 실패 호출로 반환될 때까지 일시 중지합니다. 통합을 시연하기 위해 이 패턴은 `AWS-RunShellScript` 문서 주변에 자동화 문서(런북) 래퍼를 구현하고 `AWS-RunPowerShellScript`을 사용하여 를 동기적으로 직접 호출합니다. Step Functions의 AWS SDK 서비스 통합에 대한 자세한 내용은 [AWS Step Functions 개발자 안내서](https://docs.aws.amazon.com/step-functions/latest/dg/supported-services-awssdk.html)를 참조하세요.

Step Functions****는 분산 애플리케이션을 구축하고, IT 및 비즈니스 프로세스를 자동화하고, 서비스를 사용하여 데이터 및 기계 학습 파이프라인을 구축하는 데 사용할 수 있는 로우코드 시각적 워크플로 AWS 서비스입니다. 워크플로는 장애, 재시도, 병렬화, 서비스 통합 및 관찰성을 관리하므로 더 중요한 비즈니스 로직에 집중할 수 있습니다.

의 기능인 Automation은 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Relational Database Service(Amazon RDS), Amazon Redshift 및 Amazon Simple Storage Service(Amazon S3) AWS 서비스 와 같은에 대한 일반적인 유지 관리, 배포 및 문제 해결 작업을 AWS Systems Manager간소화합니다. Automation을 사용하면 자동화의 동시성을 세부적으로 제어할 수 있습니다. 예를 들어 동시에 대상으로 지정할 리소스 수와 자동화가 중지되기 전에 발생할 수 있는 오류 수를 지정할 수 있습니다.

런북 단계, 파라미터 및 예제를 포함한 구현 세부 정보는 [추가 정보](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional) 섹션을 참조하십시오.

## 사전 조건 및 제한 사항
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ AWS Identity and Access Management Step Functions 및 Systems Manager에 액세스할 수 있는 (IAM) 권한
+ 인스턴스에 AWS Systems Manager Agent(SSM Agent)가 [설치](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html)된 EC2 인스턴스
+ 런북을 실행하려는 인스턴스에 연결된 [Systems Manager용 IAM 인스턴스 프로파일](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html)
+ 다음과 같은 IAM 권한을 가진 Step Functions 역할(최소 권한 원칙 준수).

```
{
             "Effect": "Allow",
             "Action": "ssm:StartAutomationExecution",
             "Resource": "*"
 }
```

**제품 버전**
+ SSM 문서 스키마 버전 0.3 이상
+ SSM Agent 버전 2.3.672.0 이상

## 아키텍처
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-architecture"></a>

**대상 기술 스택  **
+ AWS Step Functions
+ AWS Systems Manager 자동화

**대상 아키텍처 **

![\[Step Functions에서 Systems Manager 자동화 작업을 동기적으로 실행하기 위한 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/47c19e4f-d68d-4f91-bb68-202098757529/images/2d248aae-d858-4565-8af2-593cde0da780.png)


**자동화 및 규모 조정**
+ 이 패턴은 여러 인스턴스에 실행서를 배포하는 데 사용할 수 있는 AWS CloudFormation 템플릿을 제공합니다. (GitHub [Step Functions 및 Systems Manager 구현](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken) 리포지토리를 참조하십시오.)

## 도구
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-tools"></a>

**AWS 서비스**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 리전의 수명 주기 동안 리소스를 관리할 수 있습니다.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 AWS Lambda 함수 및 기타를 결합하여 비즈니스 크리티컬 애플리케이션을 구축하는 AWS 서비스 데 도움이 되는 서버리스 오케스트레이션 서비스입니다.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)은 AWS 클라우드에서 실행되는 애플리케이션 및 인프라를 관리하는 데 도움을 줍니다. 애플리케이션 및 리소스 관리를 간소화하고, 운영 문제를 감지 및 해결하는 시간을 단축하며, AWS 리소스를 대규모로 안전하게 관리하는 데 도움이 됩니다.

**코드 **

이 패턴의 코드는 GitHub [Step Functions 및 Systems Manager 구현](https://github.com/aws-samples/amazon-stepfunctions-ssm-waitfortasktoken) 리포지토리에서 사용할 수 있습니다. 

## 에픽
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-epics"></a>

### 런북 생성
<a name="create-runbooks"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudFormation 템플릿 파일을 다운로드하십시오. | GitHub 리포지토리의 `cloudformation ` 폴더에서 `ssm-automation-documents.cfn.json` 템플릿을 다운로드합니다. | AWS DevOps | 
| 런북을 생성하십시오. | 에 로그인하고 [CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 AWS Management Console연 다음 템플릿을 배포합니다. CloudFormation 템플릿 배포에 대한 자세한 내용은 CloudFormation 설명서의 [CloudFormation 콘솔에서 스택 생성을](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) 참조하세요. CloudFormation 템플릿은 세 가지 리소스를 배포합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.html) | DevOps | 

### 샘플 상태 머신 생성
<a name="create-a-sample-state-machine"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 테스트 상태 머신을 생성하십시오. | [AWS Step Functions AWS Step Functions 개발자 안내서](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html)의 지침에 따라 상태 머신을 생성하고 실행하십시오. 정의를 위해 다음 코드를 사용하십시오. 계정에 있는 유효한 Systems Manager 활성화 인스턴스의 ID로 `InstanceIds` 값을 업데이트해야 합니다.<pre>{<br />  "Comment": "A description of my state machine",<br />  "StartAt": "StartAutomationWaitForCallBack",<br />  "States": {<br />    "StartAutomationWaitForCallBack": {<br />      "Type": "Task",<br />      "Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",<br />      "Parameters": {<br />        "DocumentName": "SfnRunCommandByInstanceIds",<br />        "Parameters": {<br />          "InstanceIds": [<br />            "i-1234567890abcdef0"<br />          ],<br />          "taskToken.$": "States.Array($$.Task.Token)",<br />          "workingDirectory": [<br />            "/home/ssm-user/"<br />          ],<br />          "Commands": [<br />            "echo \"This is a test running automation waitForTaskToken\" >> automation.log",<br />            "sleep 100"<br />          ],<br />          "executionTimeout": [<br />              "10800"<br />          ],<br />          "deliveryTimeout": [<br />              "30"<br />          ],<br />          "shell": [<br />              "Shell"<br />          ]<br />            }<br />      },<br />      "End": true<br />    }<br />  }<br />}</pre>이 코드는 런북을 직접 호출하여 Systems Manager Automation에 대한 `waitForTaskToken` 직접 호출을 보여주는 두 개의 명령을 실행합니다.`shell` 파라미터 값(`Shell` 또는 `PowerShell`)은 자동화 문서가 `AWS-RunShellScript` 또는를 실행할지 여부를 결정합니다`AWS-RunPowerShellScript`.작업은 `/home/ssm-user/automation.log` 파일에 “이것은 자동화 WaitForTaskToken을 실행하는 테스트입니다”라고 쓴 다음, 100초 동안 휴면 상태로 있다가 작업 토큰으로 응답하여 워크플로에서 다음 작업을 릴리스합니다.대신 `SfnRunCommandByTargets` 런북을 직접 호출하려면 이전 코드의 `Parameters` 섹션을 다음과 같이 바꾸십시오.<pre>"Parameters": {<br />          "Targets": [<br />            {<br />              "Key": "InstanceIds",<br />              "Values": [<br />                "i-02573cafcfEXAMPLE",<br />                "i-0471e04240EXAMPLE"<br />              ]<br />            }<br />          ],</pre> | AWS DevOps | 
| 상태 머신의 IAM 역할을 업데이트합니다. | 이전 단계에서는 상태 머신을 위한 전용 IAM 역할을 자동으로 생성합니다. 하지만 런북 직접 호출 권한은 부여하지 않습니다. 다음 권한을 추가하여 역할을 업데이트합니다.<pre>{<br />      "Effect": "Allow",<br />      "Action": "ssm:StartAutomationExecution",<br />      "Resource": "*"<br /> }</pre> | AWS DevOps | 
| 동기 직접 호출을 검증합니다. | 상태 머신을 실행하여 Step Functions와 Systems Manager Automation 간의 동기 직접 호출을 검증합니다. 샘플 출력은 [추가 정보](#run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional) 섹션을 참조하십시오.  | AWS DevOps | 

## 관련 리소스
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-resources"></a>
+ [시작하기 AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html)(*AWS Step Functions 개발자 안내서*)
+ [작업 토큰을 사용하여 콜백 대기](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token)(*AWS Step Functions 개발자 안내서*, 서비스 통합 패턴)
+ [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) 및 [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) API 직접 호출(Boto3 설명서) 
+ [AWS Systems Manager 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)(*AWS Systems Manager 사용 설명서*)

## 추가 정보
<a name="run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions-additional"></a>

**구현 세부 정보**

이 패턴은 두 개의 Systems Manager 런북을 배포하는 AWS CloudFormation 템플릿을 제공합니다.
+ `SfnRunCommandByInstanceIds`가 인스턴스 ID를 사용하여 명령을 실행합니다.
+ `SfnRunCommandByTargets`이 대상을 사용하여 명령을 실행합니다.

각 런북은 Step Functions의 `.waitForTaskToken` 옵션을 사용할 때 동기 직접 호출을 달성하기 위한 세 단계를 구현합니다.


| 
| 
| 단계 | 작업 | 설명 | 
| --- |--- |--- |
| **1** | `Branch` | `shell` 파라미터 값(`Shell` 또는 `PowerShell`)을 확인하여 Linux`AWS-RunShellScript`용 또는 Windows`AWS-RunPowerShellScript`용를 실행할지 결정합니다. | 
| **2** | `RunCommand_Shell` 또는 `RunCommand_PowerShell` | 여러 입력을 가져와`RunShellScript`서 또는 `RunPowerShellScript` 명령을 실행합니다. 자세한 내용은 Systems Manager 콘솔에서 세부 **정보** 탭에서 `RunCommand_Shell` 또는 `RunCommand_PowerShell` 자동화 문서를 확인하세요. | 
| **3** | `SendTaskFailure` | 2단계가 중단되거나 취소될 때 실행됩니다. Step Functions [send\$1task\$1failure](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_failure.html) API를 직접 호출하며, 이 API는 상태 머신이 전달한 토큰, 실패 오류, 실패 원인에 대한 설명이라는 세 가지 파라미터를 입력으로 받아들입니다. | 
| **4** | `SendTaskSuccess` | 2단계가 성공하면 실행됩니다. 상태 머신이 전달한 토큰을 입력으로 받아들이는 Step Functions [send\$1task\$1success](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/stepfunctions/client/send_task_success.html) API를 직접 호출합니다. | 

**런북 파라미터**

`SfnRunCommandByInstanceIds` 런북


| 
| 
| 파라미터 이름 | Type | 선택 또는 필수 | 설명 | 
| --- |--- |--- |--- |
| `shell` | 문자열 | 필수 | 인스턴스 쉘은 Linux`AWS-RunShellScript`용 또는 Windows`AWS-RunPowerShellScript`용를 실행할지 여부를 결정합니다. | 
| `deliveryTimeout` | Integer | 선택 사항 | 명령이 인스턴스의 에 전송될 때까지 대기하는 시간(초)입니다. 이 파라미터의 최소값은 30(0.5분)이고 최대값은 2592000(720시간)입니다. | 
| `executionTimeout` | 문자열 | 선택 사항 | 명령이 실패로 간주되기 전에 완료해야 할 시간(초). 기본값은 1시간입니다. 최댓값은 172,800(48시간)입니다. | 
| `workingDirectory` | 문자열 | 선택 사항 | 인스턴스 상의 작업 디렉터리에 대한 경로. | 
| `Commands` | StringList | 필수 | 실행할 쉘 스크립트 또는 명령. | 
| `InstanceIds` | StringList | 필수 | 명령을 실행하려고 하는 인스턴스의 ID. | 
| `taskToken` | 문자열 | 필수 | 콜백 응답에 사용할 작업 토토큰. | 

`SfnRunCommandByTargets` 런북


| 
| 
| 이름 | Type | 선택 또는 필수 | 설명 | 
| --- |--- |--- |--- |
| `shell` | 문자열 | 필수 | 인스턴스 쉘은 Linux`AWS-RunShellScript`용 또는 Windows`AWS-RunPowerShellScript`용를 실행할지 여부를 결정합니다. | 
| `deliveryTimeout` | Integer | 선택 사항 | 명령이 인스턴스의 에 전송될 때까지 대기하는 시간(초)입니다. 이 파라미터의 최소값은 30(0.5분)이고 최대값은 2592000(720시간)입니다. | 
| `executionTimeout` | Integer | 선택 사항 | 명령이 실패로 간주되기 전에 완료해야 할 시간(초). 기본값은 1시간입니다. 최댓값은 172,800(48시간)입니다. | 
| `workingDirectory` | 문자열 | 선택 사항 | 인스턴스 상의 작업 디렉터리에 대한 경로. | 
| `Commands` | StringList | 필수 | 실행할 쉘 스크립트 또는 명령. | 
| `Targets` | MapList | 필수 | 지정한 키,값 쌍을 사용하여 인스턴스를 식별하는 검색 기준 배열. 예: `[{"Key":"InstanceIds","Values":["i-02573cafcfEXAMPLE","i-0471e04240EXAMPLE"]}]` | 
| `taskToken` | 문자열 | 필수 | 콜백 응답에 사용할 작업 토토큰. | 

**샘플 출력**

다음 테이블에는 step 함수의 샘플 출력이 나와 있습니다. 이는 5단계(`TaskSubmitted`)와 6단계(`TaskSucceeded`) 사이의 총 실행 시간이 100초 이상임을 보여줍니다. 이는 step 함수가 워크플로의 다음 작업으로 이동하기 전에 ‘sleep 100’ 명령이 완료될 때까지 기다렸다는 것을 보여줍니다.


| 
| 
| ID | Type | 단계 | Resource | 경과 시간(밀리 초) | 타임스탬프 | 
| --- |--- |--- |--- |--- |--- |
| **1** | `ExecutionStarted` |  | - | 0 | 2022년 3월 11일 오후 02:50:34. 303 | 
| **2** | `TaskStateEntered` | `StartAutomationWaitForCallBack` | - | 40 | 2022년 3월 11일 오후 02:50:34. 343 | 
| **3** | `TaskScheduled` | `StartAutomationWaitForCallBack` | - | 40 | 2022년 3월 11일 오후 02:50:34. 343 | 
| **4** | `TaskStarted` | `StartAutomationWaitForCallBack` | - | 154 | 2022년 3월 11일 오후 02:50:34. 457 | 
| **5** | `TaskSubmitted` | `StartAutomationWaitForCallBack` | - | 657 | 2022년 3월 11일 오후 02:50:34. 960 | 
| **6** | `TaskSucceeded` | `StartAutomationWaitForCallBack` | - | 103835 | 2022년 3월 11일 오후 02:52:18. 138 | 
| **7** | `TaskStateExited` | `StartAutomationWaitForCallBack` | - | 103860 | 2022년 3월 11일 오후 02:52:18. 163 | 
| **8** | `ExecutionSucceeded` |  | - | 103897 | 2022년 3월 11일 오후 02:52:18. 200 | 

# AWS Lambda 함수에서 Python을 사용하여 S3 객체의 병렬 읽기 실행
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function"></a>

*Eduardo Bortoluzzi, Amazon Web Services*

## 요약
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-summary"></a>

이 패턴을 사용하여 Amazon Simple Storage Service(Amazon S3) 버킷에서 문서 목록을 실시간으로 검색하고 요약할 수 있습니다. 이 패턴은 Amazon Web Services(AWS)의 S3 버킷에서 객체를 병렬로 읽는 예시 코드를 제공합니다. 이 패턴은 Python을 사용하여 AWS Lambda 함수로 I/O 바인딩 작업을 효율적으로 실행하는 방법을 보여줍니다.

금융 회사는 대화형 솔루션에서이 패턴을 사용하여 상관관계가 있는 금융 거래를 실시간으로 수동으로 승인하거나 거부했습니다. 금융 거래 문서는 시장과 관련된 S3 버킷에 저장되었습니다. 운영자는 S3 버킷의 문서 목록을 선택하고 솔루션이 계산한 트랜잭션의 총 값을 분석한 다음 선택한 배치를 승인하거나 거부하기로 결정했습니다.

I/O 바인딩 태스크는 여러 스레드를 지원합니다. 이 예시 코드에서 [concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3.13/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor)는 Lambda 함수가 최대 1,024개의 스레드를 지원하더라도 최대 30개의 동시 스레드와 함께 사용됩니다(해당 스레드 중 하나가 기본 프로세스임). 이 제한은 스레드가 너무 많으면 컨텍스트 전환 및 컴퓨팅 리소스 사용률로 인해 지연 시간 문제가 발생하기 때문입니다. 또한 모든 스레드가 S3 객체 다운로드를 동시에 수행할 수 `botocore` 있도록에서 최대 풀 연결을 늘려야 합니다.

이 예시 코드는 S3 버킷에서 JSON 데이터와 함께 8.3KB 객체 하나를 사용합니다. 객체는 여러 번 읽습니다. Lambda 함수가 객체를 읽으면 JSON 데이터가 Python 객체로 디코딩됩니다. 2024년 12월에이 예제를 실행한 후의 결과는 메모리 2,304MB로 구성된 Lambda 함수를 사용하여 2.3초 내에 처리된 읽기 1,000개와 27초 내에 처리된 읽기 10,000개였습니다.는 메모리 구성을 128MB에서 10,240MB(10GB)로 AWS Lambda 지원하지만 Lambdamemory를 2,304MB 이상으로 늘리면이 특정 I/O 바운드 작업을 실행하는 시간을 줄이는 데 도움이 되지 않았습니다.

[AWS Lambda Power Tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning) 도구는 다양한 Lambda 메모리 구성을 테스트하고 작업에 가장 적합한 performance-to-cost 비율을 확인하는 데 사용되었습니다. 테스트 결과는 [추가 정보](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-additional) 섹션을 참조하십시오.

## 사전 조건 및 제한 사항
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ Python 개발 숙련도

**제한 사항 **
+ Lambda 함수는 최대 [1,024개의 실행 프로세스 또는 스레드를 가질 수 있습니다](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution).
+ 새의 Lambda 메모리 제한 AWS 계정 은 3,008MB입니다. 그에 따라 AWS Lambda Power Tuning 도구를 조정합니다. 자세한 내용은 [문제 해결](#run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-troubleshooting) 섹션을 참조하세요.
+ Amazon S3는 [분할된 접두사당 초당 5,500개의 GET/HEAD 요청](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)으로 제한됩니다.

**제품 버전**
+ Python 3.9 이상
+ AWS Cloud Development Kit (AWS CDK) v2
+ AWS Command Line Interface (AWS CLI) 버전 2
+ AWS Lambda Power Tuning 4.3.6(선택 사항)

## 아키텍처
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-architecture"></a>

**대상 기술 스택 **
+ AWS Lambda
+ Amazon S3
+ AWS Step Functions ( AWS Lambda Power Tuning이 배포된 경우)

**대상 아키텍처 **

다음 다이어그램은 S3 버킷에서 객체를 병렬로 읽는 Lambda 함수를 보여줍니다. 다이어그램에는 Lambda 함수 메모리를 미세 조정하기 위한 AWS Lambda Power Tuning 도구에 대한 Step Functions 워크플로도 있습니다. 이 미세 조정은 비용과 성능 간의 균형을 유지하는 데 도움이 됩니다.

![\[Lambda 함수, S3 버킷 및 AWS Step Functions를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/828696e2-6df7-4536-9205-951c99449f4e.png)


**자동화 및 규모 조정**

Lambda 함수는 필요한 경우 빠르게 확장됩니다. 수요가 많은 동안 Amazon S3의 503 속도 저하 오류를 방지하려면 조정에 몇 가지 제한을 두는 것이 좋습니다.

## 도구
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-tools"></a>

**서비스**
+ [AWS Cloud Development Kit (AWS CDK) v2](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)는 코드로 AWS 클라우드 인프라를 정의하고 프로비저닝하는 데 도움이 되는 소프트웨어 개발 프레임워크입니다. 배포할 인프라 예제가 생성되었습니다 AWS CDK.
+ [AWS Command Line InterfaceAWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다. 이 패턴에서 AWS CLI 버전 2는 예제 JSON 파일을 업로드하는 데 사용됩니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Storage Service(Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 AWS Lambda 함수와 기타 AWS 서비스를 결합하여 비즈니스 크리티컬 애플리케이션을 구축하는 데 도움이 되는 서버리스 오케스트레이션 서비스입니다.

**기타 도구**
+ [Python](https://www.python.org/)은 범용 컴퓨터 프로그래밍 언어입니다. 유[휴 작업자 스레드의 재사용](https://docs.python.org/3.8/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor)은 Python 버전 3.8에 도입되었으며,이 패턴의 Lambda 함수 코드는 Python 버전 3.9 이상에 대해 생성되었습니다.

**코드 리포지토리**

이 패턴의 코드는 [aws-lambda-parallel-download](https://github.com/aws-samples/aws-lambda-parallel-download) GitHub 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-best-practices"></a>
+ 이 AWS CDK 구문은 인프라를 배포할 AWS 계정수 있는 사용자 권한에 의존합니다. AWS CDK 파이프라인 또는 교차 계정 배포를 사용하려는 경우 [스택 신디](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-synthesizers)사이저를 참조하세요.
+ 이 예시 애플리케이션에는 S3 버킷에서 액세스 로그가 활성화되어 있지 않습니다. 프로덕션 코드에서 액세스 로그를 활성화하는 것이 가장 좋습니다.

## 에픽
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-epics"></a>

### 개발 환경 준비
<a name="prepare-the-development-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Python 설치 버전을 확인합니다. | 이 코드는 Python 3.9 및 Python 3.13에서 특별히 테스트되었으며 이러한 릴리스 사이의 모든 버전에서 작동해야 합니다. Python 버전을 확인하려면 터미널`python3 -V`에서를 실행하고 필요한 경우 최신 버전을 설치합니다.필요한 모듈이 설치되었는지 확인하려면를 실행합니다`python3 -c "import pip, venv"`. 오류 메시지가 없으면 모듈이 제대로 설치되었으며 이 예를 실행할 준비가 되었음을 의미합니다. | 클라우드 아키텍트 | 
| 를 설치합니다 AWS CDK. | 아직 설치되지 않은 AWS CDK 경우를 설치하려면 [시작하기 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)의 지침을 따릅니다. 설치된 AWS CDK 버전이 2.0 이상인지 확인하려면를 실행합니다`cdk –version`. | 클라우드 아키텍트 | 
|  환경 부트스트랩. | 환경을 부트스트랩하려면 환경 [부트스트랩의 지침에 따라와 함께 사용합니다 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html). | 클라우드 아키텍트 | 

### 샘플 리포지토리 복제
<a name="clone-the-example-repository"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 리포지토리의 최신 버전을 복제하려면 다음 명령을 실행합니다.<pre>git clone --depth 1 --branch v1.2.0 \<br />git@github.com:aws-samples/aws-lambda-parallel-download.git</pre> | 클라우드 아키텍트 | 
| 작업 디렉터리를 복제된 리포지토리로 변경합니다. | 다음 명령을 실행합니다.<pre>cd aws-lambda-parallel-download</pre> | 클라우드 아키텍트 | 
| Python 가상 환경을 생성합니다. | Python 가상 환경을 생성하려면 다음 명령을 실행합니다.<pre>python3 -m venv .venv</pre> | 클라우드 아키텍트 | 
| 가상 환경을 활성화합니다. | 가상 환경을 활성화하려면 다음 명령을 실행합니다.<pre>source .venv/bin/activate</pre> | 클라우드 아키텍트 | 
| 종속성을 설치합니다. | `pip` 명령을 실행하여 Python 종속 항목을 설치합니다.<pre>pip install -r requirements.txt</pre> | 클라우드 아키텍트 | 
| 코드를 찾습니다. | (선택 사항) S3 버킷에서 객체를 다운로드하는 예시 코드는 `resources/parallel.py`에 있습니다.인프라 코드는 `parallel_download` 폴더에 있습니다. | 클라우드 아키텍트 | 

### 앱 배포 및 테스트
<a name="deploy-and-test-the-app"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 앱을 배포합니다. | `cdk deploy`를 실행합니다. AWS CDK 출력을 기록합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | 클라우드 아키텍트 | 
| 예시 JSON 파일을 업로드합니다. | 리포지토리에는 약 9KB의 예시 JSON 파일이 포함되어 있습니다. 생성된 스택의 S3 버킷에 파일을 업로드하려면 다음 명령을 실행합니다.<pre>aws s3 cp sample.json s3://<ParallelDownloadStack.SampleS3BucketName></pre>`<ParallelDownloadStack.SampleS3BucketName>`를 AWS CDK 출력의 해당 값으로 바꿉니다. | 클라우드 아키텍트 | 
| 앱을 실행합니다. | 앱을 실행하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html) | 클라우드 아키텍트 | 
| 다운로드 수를 추가합니다. | (선택 사항) 1,500개의 객체 가져오기 직접 호출을 실행하려면 `Test` 파라미터의 **이벤트 JSON에서 다음 JSON**을 사용합니다.<pre>{"repeat": 1500, "objectKey": "sample.json"}</pre> | 클라우드 아키텍트 | 

### 선택 사항: AWS Lambda 파워 튜닝 실행
<a name="optional-run-lamlong-power-tuning"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS Lambda Power Tuning 도구를 실행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function.html)실행이 끝나면 **실행 입력 및 출력** 탭에 결과가 표시됩니다. | 클라우드 아키텍트 | 
| 그래프에서 AWS Lambda Power Tuning 결과를 봅니다. | **실행 입력 및 출력** 탭에서 `visualization` 속성 링크를 복사하여 새 브라우저 탭에 붙여 넣습니다. | 클라우드 아키텍트 | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| S3 버킷에서 객체를 제거합니다. | 배포된 리소스를 삭제하기 전에 S3 버킷에서 모든 객체를 제거합니다.<pre>aws s3 rm s3://<ParallelDownloadStack.SampleS3BucketName> \<br />--recursive</pre>를 AWS CDK 출력의 값으로 `<ParallelDownloadStack.SampleS3BucketName>` 바꿔야 합니다. | 클라우드 아키텍트 | 
| 리소스를 폐기합니다. | 이 파일럿을 위해 생성된 모든 리소스를 삭제하려면 다음 명령을 실행합니다.<pre>cdk destroy</pre> | 클라우드 아키텍트 | 

## 문제 해결
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| `'MemorySize' value failed to satisfy constraint: Member must have value less than or equal to 3008` | 새 계정의 경우 Lambda 함수에서 3,008MB 이상을 구성하지 못할 수 있습니다. AWS Lambda 파워 튜닝을 사용하여 테스트하려면 Step Functions 실행을 시작할 때 입력 JSON에 다음 속성을 추가합니다.<pre>"powerValues": [<br />    512,<br />    1024,<br />    1536,<br />    2048,<br />    2560,<br />    3008<br />  ]</pre> | 

## 관련 리소스
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-resources"></a>
+ [Python – concurrent.futures.ThreadPoolExecutor](https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor)
+ [Lambda 할당량 - 함수 구성, 배포 및 실행](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution)
+ [Python AWS CDK 에서 작업](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-python.html)
+ [AWS Lambda Power Tuning을 사용하여 함수 프로파일링](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html)

## 추가 정보
<a name="run-parallel-reads-of-s3-objects-by-using-python-in-an-aws-lambda-function-additional"></a>

**코드**

다음 코드 조각은 병렬 I/O 처리를 수행합니다.

```
with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor:
  for result in executor.map(a_function, (the_arguments)):
    ...
```

는 스레드를 사용할 수 있게 되면 `ThreadPoolExecutor` 재사용합니다.

**테스트 및 결과**

이러한 테스트는 2024년 12월에 수행되었습니다.

첫 번째 테스트는 다음 결과와 함께 2,500개의 객체 읽기를 처리했습니다.

![\[메모리가 증가함에 따라 간접 호출 시간이 줄어들고 간접 호출 비용이 증가합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f6743412-1e52-4c4c-a51c-ac0f75b3b998.png)


3,009MB부터 모든 메모리 증가에 대해 처리 시간 수준은 거의 동일하게 유지되었지만 메모리 크기가 증가함에 따라 비용이 증가했습니다.

또 다른 테스트에서는 256MB의 배수인 값을 사용하고 10,000개의 객체 읽기를 처리하여 1,536MB에서 3,072MB 사이의 메모리 범위를 조사했으며, 그 결과는 다음과 같습니다.

![\[간접 호출 시간 감소와 간접 호출 비용 증가 간의 차이가 감소했습니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/c75d4443-74d8-4b93-9b4d-b2640869381e.png)


최상의 performance-to-cost 비율은 2,304MB 메모리 Lambda 구성이었습니다.

비교하자면 2,500개의 객체 읽기를 순차적으로 처리하는 데 47초가 걸렸습니다. 2,304MB Lambda 구성을 사용하는 병렬 프로세스는 7초가 걸렸으며, 이는 85% 더 짧습니다.

![\[순차 처리에서 병렬 처리로 전환할 때의 시간 감소를 보여주는 차트입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b46e9b16-9842-4291-adfa-3ef012b89aec/images/f3dcc44d-ac20-4b75-897d-1d71f0d59781.png)


# 실시간 분석 및 시각화 AWS Lambda 를 위해에서 OpenSearch로 원격 측정 데이터 전송
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization"></a>

*Tabby Ward, Guy Bachar, David Kilzer, Amazon Web Services*

## 요약
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-summary"></a>

최신 애플리케이션은 점점 더 분산되고 이벤트 중심이 되어 실시간 모니터링 및 관찰성의 필요성을 강화합니다. AWS Lambda 는 확장 가능한 이벤트 중심 아키텍처를 구축하는 데 중요한 역할을 하는 서버리스 컴퓨팅 서비스입니다. 하지만 Amazon CloudWatch Logs에만 의존하면 Lambda 함수를 모니터링하고 문제를 해결하는 것이 어려울 수 있으며, 이로 인해 지연 시간과 제한된 보존 기간이 발생할 수 있습니다.

이 문제를 해결하기 위해 Lambda 함수가 서드 파티 모니터링 및 관찰성 도구로 직접 원격 측정 데이터를 전송할 수 있는 Lambda 원격 측정 API를 AWS 도입했습니다. 이 API는 로그, 지표 및 추적의 실시간 스트리밍을 지원하며 Lambda 함수의 성능 및 상태에 대한 포괄적이고 시기적절한 보기를 제공합니다.

이 패턴은 Lambda Telemetry API를 오픈 소스, 분산 검색 및 분석 엔진인 [OpenSearch](https://opensearch.org/docs/latest/)와 통합하는 방법을 설명합니다. OpenSearch는 대량의 데이터를 수집, 저장 및 분석하기 위한 강력하고 확장 가능한 플랫폼을 제공하므로 Lambda 원격 측정 데이터에 이상적인 선택입니다. 특히이 패턴은에서 제공하는 Lambda 확장을 사용하여 Python으로 작성된 Lambda 함수의 로그를 OpenSearch 클러스터로 직접 전송하는 방법을 보여줍니다 AWS. 이 솔루션은 유연하고 사용자 지정할 수 있으므로 자체 Lambda 확장을 생성하거나 샘플 소스 코드를 변경하여 출력 형식을 원하는 대로 변경할 수 있습니다.

이 패턴은 OpenSearch와의 Lambda Telemetry API 통합을 설정하고 구성하는 방법을 설명하고 보안, 비용 최적화 및 확장성에 대한 모범 사례를 포함합니다. 목표는 Lambda 함수에 대한 심층적인 인사이트를 얻고 서버리스 애플리케이션의 전반적인 관찰성을 개선하는 데 도움이 됩니다.


| 
| 
| 참고:이 패턴은 Lambda Telemetry API를 관리형 OpenSearch와 통합하는 데 중점을 둡니다. 그러나 논의된 원칙과 기법은 자체 관리형 OpenSearch 및 Elasticsearch에도 적용됩니다. | 
| --- |

## 사전 조건 및 제한 사항
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-prereqs"></a>

통합 프로세스를 시작하기 전에 다음과 같은 사전 요구 사항이 있는지 확인합니다.

**AWS 계정**: 다음 AWS 리소스를 생성하고 관리할 수 있는 적절한 권한이 AWS 계정 있는 활성 :
+ AWS Lambda
+ AWS Identity and Access Management (IAM)
+ Amazon OpenSearch Service(관리형 OpenSearch 클러스터를 사용하는 경우)

**OpenSearch 클러스터**:
+ 기존 자체 관리형 OpenSearch 클러스터 또는 OpenSearch Service와 같은 관리형 서비스를 사용할 수 있습니다.
+ OpenSearch Service를 사용하는 경우 OpenSearch Service 설명서의 [Amazon OpenSearch Service 시작하기](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsg.html)의 지침에 따라 OpenSearch 클러스터를 설정합니다.
+ OpenSearch 클러스터가 Lambda 함수에서 액세스할 수 있고 액세스 정책, 암호화 및 인증과 같은 필수 보안 설정으로 구성되어 있는지 확인합니다.
+ Lambda 원격 측정 데이터를 수집하는 데 필요한 인덱스 매핑 및 설정으로 OpenSearch 클러스터를 구성합니다. 자세한 내용은 OpenSearch Service 설명서의 [Amazon OpenSearch Service로 스트리밍 데이터 로드](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html)를 참조하십시오.

**네트워크 연결**:
+ Lambda 함수에 OpenSearch 클러스터에 액세스하는 데 필요한 네트워크 연결이 있는지 확인합니다. Virtual Private Cloud(VPC) 설정을 구성하는 방법에 대한 지침은 [ OpenSearch Service 설명서의 VPC 내에서 Amazon OpenSearch Service 도메인 시작](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)을 참조하세요. OpenSearch 

**IAM 역할 및 정책**:
+ Lambda 함수가 OpenSearch 클러스터에 액세스하고에 저장된 자격 증명에 액세스하는 데 필요한 권한을 가진 IAM 역할을 생성합니다 AWS Secrets Manager.
+ OpenSearch와 상호 작용하는 데 필요한 정책 및 추가 권한과 같은 적절한 IAM `AWSLambdaBasicExecutionRole` 정책을 역할에 연결합니다.
+ Lambda 함수에 부여된 IAM 권한이 OpenSearch 클러스터에 데이터를 쓸 수 있도록 허용하는지 확인합니다. IAM 권한 관리에 대한 자세한 내용은 [Lambda 설명서의 실행 역할을 사용하여 Lambda 함수 권한 정의를](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) 참조하세요.

**프로그래밍 언어 지식**:
+ Lambda 함수 및 Lambda 확장의 샘플 코드를 이해하고 수정하려면 Python(또는 원하는 프로그래밍 언어)에 대한 기본 지식이 필요합니다.

**개발 환경**:
+ Lambda 함수 및 확장을 빌드하고 배포하는 데 필요한 도구와 종속성을 사용하여 로컬 개발 환경을 설정합니다.

**AWS CLI 또는 AWS Management Console**:
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 설치 및 구성하거나 적절한 자격 증명과 AWS Management Console 함께를 사용하여 필요한와 상호 작용합니다 AWS 서비스.

**모니터링 및 로깅**:
+ 모니터링 및 감사 목적으로 Amazon CloudWatch와 같은 서비스를 AWS포함하여에 AWS CloudTrail 대한 모니터링 및 로깅 모범 사례를 숙지합니다.
+ Lambda 함수의 CloudWatch Logs를 확인하여 Lambda Telemetry API 통합과 관련된 오류 또는 예외를 식별합니다. 문제 해결 지침은 [Lambda Telemetry API 설명서를](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html) 참조하세요.

## 아키텍처
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-architecture"></a>

이 패턴은 OpenSearch Service를 사용하여 Lambda 함수에서 생성된 로그 및 원격 측정 데이터를 저장합니다. 이 접근 방식을 사용하면 로그를 OpenSearch 클러스터로 직접 빠르게 스트리밍할 수 있으므로 CloudWatch Logs를 중개자로 사용할 때 발생하는 지연 시간과 비용을 줄일 수 있습니다.


| 
| 
| Lambda 확장 코드는 OpenSearch API를 직접 사용하거나 OpenSearch [OpenSearch 클라이언트 라이브러리](https://opensearch.org/docs/latest/clients/index/)를 사용하여 OpenSearch Service에 원격 측정을 푸시할 수 있습니다. Lambda 확장은 OpenSearch API에서 지원하는 대량 작업을 사용하여 원격 측정 이벤트를 일괄 처리하여 단일 요청으로 OpenSearch Service로 전송할 수 있습니다. | 
| --- |

다음 워크플로 다이어그램은 OpenSearch 클러스터를 엔드포인트로 사용할 때 Lambda 함수의 로그 워크플로를 보여줍니다.

![\[원격 측정 데이터를 OpenSearch 클러스터로 전송하기 위한 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/57fe8796-9f36-46cf-8304-f506242b9f04/images/283ccdcd-a0e1-40a2-a95a-3bd046bfa8ca.png)


아키텍처에는 다음과 같은 구성 요소가 포함되어 있습니다.
+ Lambda 함수: 실행 중에 로그 및 원격 측정 데이터를 생성하는 서버리스 함수입니다.
+ Lambda 확장: Lambda Telemetry API를 사용하여 OpenSearch 클러스터와 직접 통합하는 Python 기반 확장입니다. 이 익스텐션은 Lambda 함수와 동일한 실행 환경에서 같이 실행됩니다.
+ Lambda 원격 측정 API: Lambda 확장이 로그, 지표 및 추적을 포함한 원격 측정 데이터를 서드 파티 모니터링 및 관찰성 도구로 직접 전송할 수 있도록 하는 API입니다.
+ Amazon OpenSearch Service 클러스터:에서 호스팅되는 관리형 OpenSearch 클러스터입니다 AWS. 이 클러스터는 Lambda 확장을 통해 Lambda 함수에서 스트리밍된 로그 데이터를 수집, 저장 및 인덱싱하는 역할을 합니다.

이 워크플로우는 다음 단계로 구성됩니다.

1. Lambda 함수를 직접적으로 호출하고 실행 중에 로그 및 원격 측정 데이터를 생성합니다.

1. Lambda 확장은 함수와 함께 실행되어 Lambda Telemetry API를 사용하여 로그 및 원격 측정 데이터를 캡처합니다.

1. Lambda 확장은 OpenSearch Service 클러스터와의 보안 연결을 설정하고 로그 데이터를 실시간으로 스트리밍합니다.

1. OpenSearch Service 클러스터는 Kibana 또는 기타 호환 애플리케이션과 같은 도구를 사용하여 검색, 분석 및 시각화에 사용할 수 있도록 로그 데이터를 수집, 인덱싱 및 저장합니다.

CloudWatch Logs를 우회하고 로그 데이터를 OpenSearch 클러스터로 직접 전송함으로써이 솔루션은 다음과 같은 몇 가지 이점을 제공합니다.
+ 실시간 로그 스트리밍 및 분석을 통해 문제 해결 속도를 높이고 관찰성을 개선할 수 있습니다.
+ CloudWatch Logs와 관련된 지연 시간 및 잠재적 보존 제한 감소.
+ Lambda 확장을 사용자 지정하거나 특정 출력 형식 또는 추가 처리를 위해 자체 확장을 생성할 수 있는 유연성.
+ 로그 분석 및 모니터링을 위한 OpenSearch Service의 검색, 분석 및 시각화 기능과의 통합.

[에픽](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-epics) 섹션에서는 Lambda 확장을 설정하고, Lambda 함수를 구성하고, OpenSearch Service 클러스터와 통합하기 위한 step-by-step 지침을 제공합니다. 보안 고려 사항, 비용 최적화 전략 및 솔루션 모니터링 및 문제 해결을 위한 팁은 [모범 사례](#send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-best-practices) 섹션을 참조하세요.

## 도구
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-tools"></a>

**서비스**
+ [AWS Lambda](https://aws.amazon.com/lambda/)은(는) 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다. Lambda는 필요 시에만 코드를 실행하며, 일일 몇 개의 요청에서 초당 수천 개의 요청까지 자동으로 규모를 조정합니다.
+ [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/)는 클라우드에서 OpenSearch 클러스터를 쉽게 배포, 운영 및 확장할 수 AWS 있도록에서 제공하는 완전 관리형 서비스입니다.
+ [Lambda 확장은](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) Lambda 함수와 함께 사용자 지정 코드를 실행하여 Lambda 함수의 기능을 확장합니다. Lambda 확장을 사용하여 다양한 모니터링, 관찰, 보안 및 거버넌스 도구와 Lambda를 통합할 수 있습니다.
+ [AWS Lambda 원격 측정 API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html)를 사용하면 확장을 사용하여 Lambda에서 직접 향상된 모니터링 및 관찰성 데이터를 캡처하여 원하는 대상으로 전송할 수 있습니다.
+ [CloudFormation](https://aws.amazon.com/cloudformation/)는 AWS 리소스를 모델링하고 설정하여 리소스를 관리하는 데 소요되는 시간을 줄이고 애플리케이션에 더 많은 시간을 할애할 수 있도록 도와줍니다.

**코드 리포지토리**
+ [AWS Lambda 익스텐션](https://github.com/aws-samples/aws-lambda-extensions)에는 자체 익스텐션 구축을 시작하는 데 도움이 되는 및 AWS 파트너의 데모 AWS 및 샘플 프로젝트가 포함되어 있습니다.
+ [OpenSearch용 Lambda 원격 측정 통합 예](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension)는 Lambda 함수에서 OpenSearch 클러스터로 로그를 보내는 방법을 보여주는 샘플 Lambda 확장을 제공합니다.

**기타 도구**
+ [OpenSearch](https://opensearch.org/faq/)는 대량의 데이터를 수집, 저장 및 분석하기 위한 강력한 플랫폼을 제공하는 오픈 소스 분산 검색 및 분석 엔진입니다.
+ Kibana는 OpenSearch와 함께 사용할 수 있는 오픈 소스 데이터 시각화 및 탐색 도구입니다. 시각화 및 분석 구현은이 패턴의 범위를 벗어납니다. 자세한 내용은 [Kibana 설명서](https://www.elastic.co/guide/en/kibana/current/index.html)와 기타 리소스를 참조하세요.

## 모범 사례
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-best-practices"></a>

Lambda Telemetry API를 OpenSearch와 통합할 때는 다음 모범 사례를 고려하세요.

**보안 및 액세스 제어**
+ **보안 통신**: HTTPS를 사용하여 Lambda 함수와 OpenSearch 클러스터 간의 모든 통신을 암호화합니다. Lambda 확장 및 OpenSearch 구성에서 필요한 SSL/TLS 설정을 구성합니다.
+ **IAM 권한**:
  + 확장은 Lambda 함수와 동일한 실행 환경에서 실행되므로 파일 시스템, 네트워킹 및 환경 변수와 같은 리소스에 대한 동일한 수준의 액세스를 상속합니다.
  + Lambda 텔레메트리 API에 액세스하고 OpenSearch 클러스터에 데이터를 쓰는 데 필요한 최소 IAM 권한을 Lambda 함수에 부여합니다. [최소 권한 원칙을](https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html) 사용하여 권한 범위를 제한합니다.
+ **OpenSearch 액세스 제어**: OpenSearch 클러스터에서 세분화된 액세스 제어를 구현하여 민감한 데이터에 대한 액세스를 제한합니다. OpenSearch에서 사용자 인증, 역할 기반 액세스 제어 및 인덱스 수준 권한과 같은 기본 제공 보안 기능을 사용합니다.
+ **신뢰할 수 있는 확장:** 항상 신뢰할 수 있는 소스에서만 확장을 설치합니다. 와 같은 코드형 인프라(IaC) 도구를 사용하여 IAM 권한을 포함한 동일한 확장 구성을 여러 Lambda 함수에 연결하는 프로세스를 CloudFormation 간소화합니다. 또한 IaC 도구는 이전에 사용된 확장 및 버전에 대한 감사 레코드를 제공합니다.
+ **민감한 데이터 처리**: 확장을 구축할 때는 민감한 데이터를 로깅하지 마세요. 감사 목적으로 로깅하거나 유지하기 전에 페이로드와 메타데이터를 삭제합니다.

**비용 최적화**
+ **모니터링 및 알림**: 모니터링 및 알림 메커니즘을 설정하여 Lambda 함수에서 OpenSearch로 전송되는 데이터의 양을 추적합니다. 이렇게 하면 잠재적 비용 초과를 식별하고 해결하는 데 도움이 됩니다.
+ **데이터 보존**: OpenSearch에서 Lambda 원격 측정 데이터에 적절한 데이터 보존 기간을 신중하게 고려합니다. 보존 기간이 길수록 스토리지 비용이 증가할 수 있으므로 관찰성 니즈와 비용 최적화의 균형을 맞출 수 있습니다.
+ **압축 및 인덱싱**: 데이터 압축을 활성화하고 OpenSearch 인덱싱 전략을 최적화하여 Lambda 원격 측정 데이터의 스토리지 공간을 줄입니다.
+ **CloudWatch에 대한 의존도 감소**: Lambda 원격 측정 API를 OpenSearch와 직접 통합하면 CloudWatch Logs에 대한 의존도를 잠재적으로 줄여 비용을 절감할 수 있습니다. 이는 Lambda Telemetry API를 사용하면 로그를 OpenSearch로 직접 전송할 수 있으므로 CloudWatch에 데이터를 저장하고 처리할 필요가 없기 때문입니다.

**확장성 및 신뢰성**
+ **비동기 처리**: Amazon Simple Queue Service(Amazon SQS) 또는 Amazon Kinesis와 같은 비동기 처리 패턴을 사용하여 Lambda 함수 실행을 OpenSearch 데이터 수집에서 분리합니다. 이를 통해 Lambda 함수의 응답성을 유지하고 시스템의 전반적인 신뢰성을 개선할 수 있습니다.
+ **OpenSearch 클러스터 규모 조정**: OpenSearch 클러스터의 성능 및 리소스 사용률을 모니터링하고 필요에 따라 확장 또는 축소하여 증가하는 Lambda 원격 측정 데이터를 처리합니다.
+ **장애 조치 및 재해 복구**: 정기 백업과 장애 발생 시 데이터를 신속하게 복원하는 기능을 포함하여 OpenSearch 클러스터에 대한 강력한 재해 복구 전략을 구현합니다.

**관찰성 및 모니터링**
+ **대시보드 및 시각화**: Kibana 또는 기타 대시보드 도구를 사용하여 OpenSearch의 원격 측정 데이터를 기반으로 Lambda 함수의 성능 및 상태에 대한 인사이트를 제공하는 사용자 지정 대시보드 및 시각화를 생성합니다.
+ **알림 및 알림**: Lambda 함수의 이상, 오류 또는 성능 문제를 사전에 모니터링하도록 알림 및 알림을 설정합니다. 이러한 알림 및 알림을 기존 인시던트 관리 프로세스와 통합합니다.
+ **추적 및 상관관계**: Lambda 원격 측정 데이터에 요청 ID 또는 상관관계 IDs와 같은 관련 추적 정보가 포함되어 있는지 확인하여 분산 서버리스 애플리케이션에서 엔드 투 엔드 관찰성 및 문제 해결을 지원합니다.

이러한 모범 사례를 따르면 Lambda Telemetry API와 OpenSearch의 통합이 안전하고 비용 효율적이며 확장 가능하며 서버리스 애플리케이션에 대한 포괄적인 관찰성을 제공할 수 있습니다.

## 에픽
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-epics"></a>

### Lambda 확장 계층 빌드 및 배포
<a name="build-and-deploy-the-lam-extension-layer"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 소스 코드를 다운로드합니다. | 익스텐션 리포지토리에서 샘플 [AWS Lambda 익스텐션을 다운로드합니다](https://github.com/aws-samples/aws-lambda-extensions). | 앱 개발자, 클라우드 아키텍트 | 
| `python-example-telemetry-opensearch-extension` 폴더로 이동합니다. | 다운로드한 [AWS Lambda 확장](https://github.com/aws-samples/aws-lambda-extensions) 리포지토리에는 여러 사용 사례 및 언어 런타임에 대한 많은 예시가 포함되어 있습니다. [python-example-telemetry-opensearch-extension](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension) 폴더로 이동하여 OpenSearch로 로그를 전송하는 Python OpenSearch 확장을 사용합니다. | 앱 개발자, 클라우드 아키텍트 | 
| 확장 엔드포인트를 실행할 수 있는 권한을 추가합니다. | 다음 명령을 실행하여 확장 엔드포인트를 실행 가능하게 만듭니다.<pre>chmod +x python-example-telemetry-opensearch-extension/extension.py</pre> | 앱 개발자, 클라우드 아키텍트 | 
| 확장 종속 항목을 로컬에 설치합니다. | 다음 명령을 실행하여 Python 코드의 로컬 종속 항목을 설치합니다.<pre>pip3 install -r python-example-telemetry-opensearch-extension/requirements.txt -t ./python-example-telemetry-opensearch-extension/</pre>이러한 종속성은 확장 코드와 함께 마운트됩니다. | 앱 개발자, 클라우드 아키텍트 | 
| 확장을 위한 .zip 패키지를 생성하여 계층으로 배포합니다. | 확장 .zip 파일에는 확장 실행 파일이 `extensions/`있는 라는 루트 디렉터리와 확장의 코어 로직과 해당 종속성이 `python-example-telemetry-opensearch-extension/`있는 라는 또 다른 루트 디렉터리가 포함되어야 합니다.확장을 위한 .zip 패키지를 생성합니다.<pre>chmod +x extensions/python-example-telemetry-opensearch-extension<br />zip -r extension.zip extensions python-example-telemetry-opensearch-extension</pre> | 앱 개발자, 클라우드 아키텍트 | 
| 확장을 Lambda 계층으로 배포합니다. | 확장 .zip 파일과 다음 명령을 사용하여 계층을 게시합니다.<pre>aws lambda publish-layer-version \<br />--layer-name "python-example-telemetry-opensearch-extension" \<br />--zip-file "fileb://extension.zip"</pre> | 앱 개발자, 클라우드 아키텍트 | 

### 확장을 함수에 통합
<a name="integrate-the-extension-into-your-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 함수에 계층을 추가합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)Lambda 함수에 계층을 추가하는 데 대한 자세한 내용은 [Lambda 설명서](https://docs.aws.amazon.com/lambda/latest/dg/adding-layers.html)를 참조하십시오. | 앱 개발자, 클라우드 아키텍트 | 
| 함수의 환경 변수를 설정합니다. | 함수 페이지에서 **구성** 탭을 선택하고 함수에 다음 환경 변수를 추가합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | 앱 개발자, 클라우드 아키텍트 | 

### 로깅 문 추가 및 함수 테스트
<a name="add-logging-statements-and-test-your-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 함수에 로깅 문을 추가합니다. | [기본 제공 로깅 메커니즘 중 하나](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html) 또는 선택한 로깅 모듈을 사용하여 함수에 로깅 문을 추가합니다.다음은 Python에서 메시지를 로깅하는 예입니다.<pre>print("Your Log Message Here")<br />logger = logging.getLogger(__name__)<br /><br />logger.info("Test Info Log.")<br />logger.error("Test Error Log.")</pre> | 앱 개발자, 클라우드 아키텍트 | 
|  함수를 테스트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html)모든 것이 제대로 작동하면 **함수 실행: 성공이** 표시됩니다. | 앱 개발자, 클라우드 아키텍트 | 

### OpenSearch에서 로그 보기
<a name="view-your-logs-in-opensearch"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인덱스를 쿼리합니다. | OpenSearch에서 다음 명령을 실행하여 인덱스를 쿼리합니다.<pre>SELECT * FROM index-name</pre>쿼리 결과에 로그가 표시되어야 합니다. | 클라우드 아키텍트 | 

## 문제 해결
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 연결 문제 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | 
| 데이터 수집 오류 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization.html) | 

## 관련 리소스
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-resources"></a>
+ [OpenSearch용 Lambda 텔레메트리 통합 예](https://github.com/aws-samples/aws-lambda-extensions/tree/main/python-example-telemetry-opensearch-extension)(GitHub 리포지토리)
+ [Lambda 확장을 사용하여 Lambda 함수 보강](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)(Lambda 설명서)
+ [Lambda Telemetry API](https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html)(Lambda 설명서)
+ [AWS Lambda Telemetry API 소개](https://aws.amazon.com/blogs/compute/introducing-the-aws-lambda-telemetry-api/)(AWS 블로그 게시물)
+ [AWS Lambda Telemetry API를 Prometheus 및 OpenSearch와 통합](https://aws.amazon.com/blogs/opensource/integrating-the-aws-lambda-telemetry-api-with-prometheus-and-opensearch)(AWS 블로그 게시물)

## 추가 정보
<a name="send-telemetry-data-from-lambda-to-opensearch-for-analytics-visualization-additional"></a>

**로그 구조 변경**

확장은 기본적으로 로그를 중첩 문서로 OpenSearch에 전송합니다. 이렇게 하면 중첩 쿼리를 수행하여 개별 열 값을 검색할 수 있습니다.

기본 로그 출력이 특정 요구 사항을 충족하지 않는 경우에서 제공하는 Lambda 확장의 소스 코드를 수정하여 사용자 지정할 수 있습니다 AWS.는 고객에게 비즈니스 요구 사항에 맞게 출력을 조정하도록 AWS 권장합니다. 로그 출력을 변경하려면 확장의 소스 코드 내의 `telemetry_dispatcher.py` 파일에서 `dispatch_to_opensearch` 함수를 찾아 필요한 변경을 수행합니다.

# 셀 기반 아키텍처를 위한 서버리스 셀 라우터 설정
<a name="serverless-cell-router-architecture"></a>

*Mian Tariq 및 Ioannis Lioupras, Amazon Web Services*

## 요약
<a name="serverless-cell-router-architecture-summary"></a>

글로벌 셀 기반 애플리케이션의 시스템을 진입점으로 하는 셀 라우터는 사용자를 적절한 셀에 효율적으로 할당하고 사용자에게 엔드포인트를 제공하는 역할을 합니다. 셀 라우터는 user-to-cell 매핑 저장, 셀 용량 모니터링, 필요한 경우 새 셀 요청과 같은 기능을 처리합니다. 잠재적 중단 시 셀-라우터 기능을 유지하는 것이 중요합니다.

이 패턴의 셀-라우터 설계 프레임워크는 복원력, 확장성 및 전반적인 성능 최적화에 중점을 둡니다. 이 패턴은 클라이언트가 초기 로그인 시 엔드포인트를 캐시하고 셀과 직접 통신하는 정적 라우팅을 사용합니다. 이 분리는 셀-라우터 장애 발생 시 셀 기반 애플리케이션의 중단 없는 기능을 보장하여 시스템 복원력을 향상시킵니다.

이 패턴은 AWS CloudFormation 템플릿을 사용하여 아키텍처를 배포합니다. 템플릿 배포에 대한 자세한 내용이나를 사용하여 동일한 구성을 배포하려면 [추가 정보](#serverless-cell-router-architecture-additional) 섹션을 AWS Management Console참조하세요.

**중요**  
이 패턴에 제시된 데모, 코드 및 CloudFormation 템플릿은 설명 목적으로만 사용됩니다. 제공된 재료는 디자인 패턴을 설명하고 이해를 돕기 위한 목적으로만 사용됩니다. 데모 및 코드는 프로덕션에 사용할 수 없으며 라이브 프로덕션 활동에 사용해서는 안 됩니다. 프로덕션 환경에서 코드 또는 데모를 사용하려는 모든 시도는 권장되지 않으며 사용자가 리스크를 감수해야 합니다. 프로덕션 환경에서이 패턴 또는 해당 구성 요소를 구현하기 전에 적절한 전문가와 상의하고 철저한 테스트를 수행하는 것이 좋습니다.

## 사전 조건 및 제한 사항
<a name="serverless-cell-router-architecture-prereqs"></a>

**사전 조건 **
+ 활성 Amazon Web Services(AWS) 계정
+ [AWS Command Line Interface (AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html))의 최신 버전
+  CloudFormation 스택, AWS Lambda 함수 및 관련 리소스를 생성하는 데 필요한 권한이 있는 [AWS 자격 증명](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 

**제품 버전**
+ Python 3.12

## 아키텍처
<a name="serverless-cell-router-architecture-architecture"></a>

다음 다이어그램은 셀 라우터의 상위 수준 설계를 보여줍니다.

![\[셀 라우터의 5단계 프로세스입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/feb90b51-dd91-483b-b5a3-b0a5359686e3.png)


이 다이어그램은 다음 워크플로를 단계별로 보여줍니다.

1. 사용자는 셀-라우터 API 엔드포인트의 전면 역할을 하는 Amazon API Gateway에 문의합니다.

1. Amazon Cognito는 인증 및 권한 부여를 처리합니다.

1.  AWS Step Functions 워크플로는 다음 구성 요소로 구성됩니다.
   + **오케스트레이터** ‒는 AWS Step Functions 를 `Orchestrator` 사용하여 워크플로 또는 상태 시스템을 생성합니다. 워크플로는 셀 라우터 API에 의해 트리거됩니다. 는 리소스 경로를 기반으로 Lambda 함수를 `Orchestrator` 실행합니다.
   + **디스패처** ‒ `Dispatcher` Lambda 함수는 등록된 새 사용자당 하나의 정적 셀을 식별하고 할당합니다. 함수는 사용자 수가 가장 적은 셀을 검색하여 사용자에게 할당하고 엔드포인트를 반환합니다.
   + **매퍼** ‒ `Mapper` 작업은 CloudFormation 템플릿에 의해 생성된 `RoutingDB` Amazon DynamoDB 데이터베이스 내의 user-to-cell 매핑을 처리합니다. 트리거되면 `Mapper` 함수는 이미 할당된 사용자에게 엔드포인트를 제공합니다.
   + **Scaler** ‒ `Scaler` 함수는 셀 점유율과 사용 가능한 용량을 추적합니다. 필요한 경우 `Scaler` 함수는 Amazon Simple Queue Service(Amazon SQS)를 통해 프로비저닝 및 배포 계층으로 요청을 보내 새 셀을 요청할 수 있습니다.
   + **검사기** ‒ `Validator` 함수는 셀 엔드포인트를 검증하고 잠재적 문제를 감지합니다.

1. 는 셀 정보 및 속성(API 엔드포인트, AWS 리전상태, 지표)을 `RoutingDB` 저장합니다.

1. 셀의 사용 가능한 용량이 임계값을 초과하면 셀 라우터는 Amazon SQS를 통해 프로비저닝 및 배포 서비스를 요청하여 새 셀을 생성합니다.

새 셀이 생성되면 `RoutingDB`가 프로비저닝 및 배포 계층에서 업데이트됩니다. 그러나이 프로세스는이 패턴의 범위를 벗어납니다. 셀 기반 아키텍처 설계 온프레미스에 대한 개요와이 패턴에 사용되는 셀-라우터 설계에 대한 자세한 내용은 [추가 정보](#serverless-cell-router-architecture-additional) 섹션을 참조하세요.

## 도구
<a name="serverless-cell-router-architecture-tools"></a>

**AWS 서비스**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)는 규모와 관계없이 REST, HTTP 및 WebSocket API를 생성, 게시, 유지 관리, 모니터링 및 보호하는 것을 지원합니다.
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및의 수명 주기 동안 리소스를 관리할 수 있습니다 AWS 리전.
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공합니다.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Storage Service(Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 Lambda 함수 및 기타를 결합하여 비즈니스 크리티컬 애플리케이션을 구축하는 AWS 서비스 데 도움이 되는 서버리스 오케스트레이션 서비스입니다.

**기타 도구**
+ [Python](https://www.python.org/)은 범용 컴퓨터 프로그래밍 언어입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [Serverless-Cell-Router](https://github.com/aws-samples/Serverless-Cell-Router/) 리포지토리에서 확인할 수 있습니다.

## 모범 사례
<a name="serverless-cell-router-architecture-best-practices"></a>

셀 기반 아키텍처를 빌드할 때 모범 사례는 다음 AWS Well-Architected 지침을 참조하세요.
+ [셀 기반 아키텍처를 사용하여 영향 범위 축소](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html)
+ [AWS Well-Architected Framework 신뢰성 원칙: REL10-BP04 벌크헤드 아키텍처를 사용하여 영향 범위 제한](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html)

## 에픽
<a name="serverless-cell-router-architecture-epics"></a>

### 소스 파일 준비
<a name="prepare-source-files"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 코드 예시 리포지토리를 복제합니다. | Serverless-Cell-Router GitHub 리포지토리를 컴퓨터에 복제하려면 다음 명령을 사용합니다.<pre>git clone https://github.com/aws-samples/Serverless-Cell-Router/</pre> | 개발자 | 
|  AWS CLI 임시 자격 증명을 설정합니다. | 에 대한 자격 증명을 AWS CLI 사용하여를 구성합니다 AWS 계정. 이 연습에서는 AWS IAM Identity Center **명령줄 또는 프로그래밍 방식 액세스** 옵션에서 제공하는 임시 자격 증명을 사용합니다. 그러면 `AWS_ACCESS_KEY_ID`와 함께 사용할 적절한 자격 증명으로 `AWS_SECRET_ACCESS_KEY`, 및 `AWS_SESSION_TOKEN` AWS 환경 변수가 설정됩니다 AWS CLI. | 개발자 | 
| S3 버킷을 생성합니다. |  CloudFormation 템플릿으로 배포할 Serverless-Cell-Router Lambda 함수를 저장하고 액세스하는 데 사용할 S3 버킷을 생성합니다. S3 버킷을 생성하려면 다음 명령을 사용합니다.<pre>aws s3api create-bucket --bucket <bucket name> --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1</pre> | 개발자 | 
| .zip 파일을 만듭니다. | [함수](https://github.com/aws-samples/Serverless-Cell-Router/tree/main/Functions) 디렉터리에 있는 각 Lambda 함수에 대해 하나의 .zip 파일을 생성합니다. 이러한 .zip 파일은 Lambda 함수를 배포하는 데 사용됩니다. Mac에서는 다음 `zip` 명령을 사용합니다.<pre>zip -j mapper-scr.zip Functions/Mapper.py<br />zip -j dispatcher-scr.zip Functions/Dispatcher.py<br />zip -j scaler-scr.zip Functions/Scaler.py<br />zip -j cp validator-scr.zip Functions/Validator.py<br />zip -j dynamodbDummyData-scr.zip Functions/DynamodbDummyData.py</pre> | 개발자 | 
| .zip 파일을 S3 버킷에 복사합니다. | 모든 Lambda 함수 .zip 파일을 S3 버킷에 복사하려면 다음 명령을 사용합니다.<pre>aws s3 cp mapper-scr.zip s3://<bucket name><br />aws s3 cp dispatcher-scr.zip s3://<bucket name><br />aws s3 cp scaler-scr.zip s3://<bucket name><br />aws s3 cp validator-scr.zip s3://<bucket name><br />aws s3 cp dynamodbDummyData-scr.zip s3://<bucket name></pre> | 개발자 | 

### CloudFormation 스택 생성
<a name="create-the-cfn-stack"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  CloudFormation 템플릿을 배포합니다. |  CloudFormation 템플릿을 배포하려면 다음 AWS CLI 명령을 실행합니다.<pre>aws cloudformation create-stack --stack-name serverless.cell-router \<br />--template-body file://Serverless-Cell-Router-Stack-v10.yaml \<br />--capabilities CAPABILITY_IAM \<br />--parameters ParameterKey=LambdaFunctionMapperS3KeyParameterSCR,ParameterValue=mapper-scr.zip \<br />ParameterKey=LambdaFunctionDispatcherS3KeyParameterSCR,ParameterValue=dispatcher-scr.zip \<br />ParameterKey=LambdaFunctionScalerS3KeyParameterSCR,ParameterValue=scaler-scr.zip \<br />ParameterKey=LambdaFunctionAddDynamoDBDummyItemsS3KeyParameterSCR,ParameterValue=dynamodbDummyData-scr.zip \<br />ParameterKey=LambdaFunctionsS3BucketParameterSCR,ParameterValue=<S3 bucket storing lambda zip files> \<br />ParameterKey=CognitoDomain,ParameterValue=<Cognito Domain Name> \<br />--region <enter your aws region id, e.g. "eu-central-1"></pre> | 개발자 | 
| 진행 상황을 확인합니다. | 에 로그인하고 AWS Management Console[https://console.aws.amazon.com/cloudformation/]() CloudFormation 콘솔을 열고 스택 개발 진행 상황을 확인합니다. 상태가 `CREATE_COMPLETE`이면 스택이 성공적으로 배포된 것입니다. | 개발자 | 

### 평가 및 확인
<a name="assess-and-verify"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 사용자에게 셀을 할당합니다. | 를 시작하려면 다음 curl 명령을 `Orchestrator`실행합니다.<pre>curl -X POST \<br />-H "Authorization: Bearer {User id_token}" \<br />https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells</pre>는 `Dispatcher` 함수의 실행을 `Orchestrator` 트리거합니다. 는 `Dispatcher`사용자의 존재를 확인합니다. 사용자를 찾은 경우는 연결된 셀 ID 및 엔드포인트 URL을 `Dispatcher` 반환합니다. 사용자를 찾을 수 없는 경우는 사용자에게 셀을 `Dispatcher` 할당하고 할당된 셀의 잔여 용량을 평가하기 위해 셀 ID를 `Scaler` 함수로 보냅니다.`Scaler` 함수의 응답은 다음과 같습니다.`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 개발자 | 
| 사용자 셀을 검색합니다. | `Orchestrator`를 사용하여 `Mapper` 함수를 실행하려면 다음 명령을 실행합니다.<pre>curl -X POST \<br />-H "Authorization: Bearer {User id_token}" \<br />https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper</pre>는 사용자에게 할당된 셀을 `Orchestrator` 검색하고 다음 응답에서 셀 ID와 URL을 반환합니다.`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | 개발자 | 

### 정리
<a name="clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리소스를 정리합니다. | 계정에 추가 요금이 발생하지 않도록 하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/serverless-cell-router-architecture.html) | 앱 개발자 | 

## 관련 리소스
<a name="serverless-cell-router-architecture-resources"></a>

**참조**
+ [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 장애 격리 경계: 정적 안정성](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html)

**동영상**

[Physalia: Amazon EBS에서 더 높은 가용성을 제공하는 셀 기반 아키텍처](https://www.youtube.com/watch?v=6IknqRZMFic) 




[https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0](https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0)

## 추가 정보
<a name="serverless-cell-router-architecture-additional"></a>

**셀 기반 아키텍처 설계 온프레미스**

이 패턴은 셀 라우터에 초점을 맞추지만 전체 환경을 이해하는 것이 중요합니다. 환경은 세 개의 개별 계층으로 구성됩니다.
+ 셀 라우터가 포함된 라우팅 계층 또는 씬 계층
+ 다양한 셀로 구성된 셀 계층
+ 셀을 프로비저닝하고 애플리케이션을 배포하는 프로비저닝 및 배포 계층

각 계층은 다른 계층에 영향을 미치는 장애가 있는 경우에도 기능을 유지합니다.를 장애 격리 경계로 AWS 계정 사용합니다.

다음 다이어그램은 상위 수준의 계층을 보여줍니다. 셀 계층과 프로비저닝 및 배포 계층은이 패턴의 범위를 벗어납니다.

![\[라우팅 계층, 여러 셀 계정이 있는 셀 계층, 프로비저닝 및 배포 계층.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/137ac34d-43c3-42b6-95de-a365ff611ce8.png)


셀 기반 아키텍처에 대한 자세한 내용은 [셀 기반 아키텍처로 영향 범위 줄이기: 셀 라우팅을 참조하세요](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/cell-routing.html).

**셀-라우터 설계 패턴**

셀 라우터는 셀 간에 공유되는 구성 요소입니다. 잠재적 영향을 완화하려면 라우팅 계층이 최대한 얇은 단순하고 수평적으로 확장 가능한 설계를 사용하는 것이 중요합니다. 시스템의 진입점 역할을 하는 라우팅 계층은 사용자를 적절한 셀에 효율적으로 할당하는 데 필요한 구성 요소로만 구성됩니다. 이 계층 내의 구성 요소는 셀 관리 또는 생성에 관여하지 않습니다.

이 패턴은 정적 라우팅을 사용합니다. 즉, 클라이언트는 초기 로그인 시 엔드포인트를 캐싱한 다음 셀과 직접 통신을 설정합니다. 클라이언트와 셀 라우터 간의 주기적 상호 작용이 시작되어 현재 상태를 확인하거나 업데이트를 검색합니다. 이 의도적인 분리는 셀-라우터 가동 중지 시 기존 사용자에게 중단 없는 작업을 가능하게 하며 시스템 내에서 지속적인 기능과 복원력을 제공합니다.

이 패턴에서 셀 라우터는 다음 기능을 지원합니다.
+ 프로비저닝 및 배포 계층의 셀 데이터베이스에서 셀 데이터를 검색하고 로컬 데이터베이스를 저장하거나 업데이트합니다.
+ 셀 할당 알고리즘을 사용하여 애플리케이션의 새로 등록된 각 사용자에게 셀을 할당합니다.
+ 로컬 데이터베이스에 user-to-cells 매핑 저장.
+ 사용자 할당 중에 셀의 용량을 확인하고 벤딩 머신의 이벤트를 프로비저닝 및 배포 계층으로 높여 셀을 생성합니다.
+ 셀 생성 기준 알고리즘을 사용하여이 기능을 제공합니다.
+ 정적 셀의 URL을 제공하여 새로 등록된 사용자 요청에 응답합니다. 이러한 URL은 TTL(Time To Live)을 사용하여 클라이언트에 캐싱됩니다.
+ 새 URL 또는 업데이트된 URL을 제공하여 잘못된 URL의 기존 사용자 요청에 응답합니다.

 CloudFormation 템플릿에 의해 설정된 데모 셀 라우터를 자세히 이해하려면 다음 구성 요소 및 단계를 검토하세요.

1. Amazon Cognito 사용자 풀을 설정하고 구성합니다.

1. 셀 라우터에 대한 API Gateway API를 설정하고 구성합니다.

1. DynamoDB 테이블을 생성합니다.

1. SQS 대기열을 생성하고 구성합니다.

1. `Orchestrator`를 구현합니다.

1. Lambda 함수 `Dispatcher`, `Scaler`, `Mapper`,를 구현합니다`Validator`.

1. 를 평가하고 확인합니다.

사전 가정은 프로비저닝 및 배포 계층이 이미 설정되어 있다는 것입니다. 구현 세부 정보는이 아티팩트의 범위를 벗어납니다.

이러한 구성 요소는 CloudFormation 템플릿에 의해 설정 및 구성되므로 다음 단계는 설명적이고 높은 수준으로 표시됩니다. 설정 및 구성을 완료하는 데 필요한 AWS 기술이 있다고 가정합니다.

*1: Amazon Cognito 사용자 풀을 설정 및 구성*

에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/cognito/]() Amazon Cognito 콘솔을 엽니다. 앱 통합`CellRouterPool`, 호스팅 UI 및 필요한 권한을 사용하여 라는 Amazon Cognito 사용자 풀을 설정하고 구성합니다.

*2. 셀 라우터에 대한 API Gateway API 설정 및 구성*

[https://console.aws.amazon.com/apigateway/]()에서 Amazon API Gateway 콘솔을 엽니다. Amazon Cognito 사용자 풀와 통합된 Amazon Cognito 권한 부여자를 `CellRouter`사용하여 라는 API를 설정하고 구성합니다`CellRouterPool`. 다음 요소를 구현합니다.
+ `CellRouter` `POST` 메서드를 포함한 API 리소스
+ 5단계에서 구현된 Step Functions 워크플로와 통합
+ Amazon Cognito 권한 부여자를 통한 권한 부여
+ 통합 요청 및 응답 매핑
+ 필요한 권한 할당

*3. DynamoDB 테이블 생성*

[https://console.aws.amazon.com/dynamodb/]() DynamoDB 콘솔을 열고 다음 구성으로 라는 표준 DynamoDB 테이블`tbl_router`을 생성합니다.
+ **파티션 키** - `marketId`
+ **정렬 키** - `cellId`
+ **용량 모드** - 프로비저닝됨
+ **시점 복구(PITR)** - 끔

**인덱스** 탭에서 라는 글로벌 보조 인덱스를 생성합니다`marketId-currentCapacity-index`. `Scaler` Lambda 함수는 인덱스를 사용하여 할당된 사용자 수가 가장 적은 셀을 효율적으로 검색합니다.

다음 속성을 사용하여 테이블 구조를 생성합니다.
+ `marketId` - 유럽
+ `cellId` ‒ cell-0002
+ `currentCapacity` ‒ 2
+ `endPoint_1` ‒ <첫 번째 리전의 엔드포인트>
+ `endPoint_2` ‒ <두 번째 리전의 엔드포인트>
+ `IsHealthy` ‒ True
+ `maxCapacity` ‒ 10
+ `regionCode_1` ‒ `eu-north-1`
+ `regionCode_2` ‒ `eu-central-1`
+ `userIds` ‒ <이메일 주소>

*4. SQS 대기열 생성 및 구성*

[https://console.aws.amazon.com/sqs/]() Amazon SQS 콘솔을 열고 Amazon SQS 키 암호화로 `CellProvisioning` 구성된 라는 표준 SQS 대기열을 생성합니다. **Amazon SQS ** 

*5. 오케스트레이터 구현*

Step Functions 워크플로를 개발하여 라우터의 `Orchestrator` 로 사용합니다. 워크플로는 셀 라우터 API를 통해 직접 호출할 수 있습니다. 워크플로는 리소스 경로를 기반으로 지정된 Lambda 함수를 실행합니다. 단계 함수를 셀 라우터 `CellRouter`용 API Gateway API와 통합하고 Lambda 함수를 간접적으로 호출하는 데 필요한 권한을 구성합니다.

다음 다이어그램은 워크플로를 보여줍니다. 선택 상태는 Lambda 함수 중 하나입니다. Lambda 함수가 성공하면 워크플로가 종료됩니다. Lambda 함수가 실패하면 실패 상태가 직접적으로 호출됩니다.

![\[4개의 함수가 있고 실패 상태로 끝나는 워크플로의 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/fd2fbf9d-9ae4-4c27-bc32-cf117350137a/images/cfe8d029-6f30-49a1-aaad-cad503bdcbae.png)


*6. Lambda 함수 구현*

`Dispatcher`, `Mapper``Scaler`, 및 `Validator` 함수를 구현합니다. 데모에서 각 함수를 설정하고 구성할 때 함수에 대한 역할을 정의하고 DynamoDB 테이블에서 필요한 작업을 수행하는 데 필요한 권한을 할당합니다`tbl_router`. 또한 각 함수를 워크플로에 통합합니다`Orchestrator`.

*디스패처 함수*

`Dispatcher` 함수는 새로 등록된 각 사용자에 대해 단일 정적 셀을 식별하고 할당하는 역할을 합니다. 새 사용자가 글로벌 애플리케이션에 등록하면 요청이 `Dispatcher` 함수로 이동합니다. 함수는 다음과 같은 사전 정의된 평가 기준을 사용하여 요청을 처리합니다.

1. **리전** ‒ 사용자가 위치한 시장에서 셀을 선택합니다. 예를 들어 사용자가 유럽에서 글로벌 애플리케이션에 액세스하는 경우 유럽 AWS 리전 에서를 사용하는 셀을 선택합니다.

1. **근접성 또는 지연** 시간 ‒ 사용자와 가장 가까운 셀 선택 예를 들어 사용자가 네덜란드에서 애플리케이션에 액세스하는 경우 함수는 프랑크푸르트와 아일랜드를 사용하는 셀을 고려합니다. 가장 가까운 셀에 대한 결정은 사용자 위치와 셀 리전 간의 지연 시간과 같은 지표를 기반으로 합니다. 이 예시 패턴의 경우 정보는 프로비저닝 및 배포 계층에서 정적으로 공급됩니다.

1. **상태** ‒ `Dispatcher` 함수는 제공된 셀 상태(정상 = true 또는 false)를 기반으로 선택한 셀이 정상인지 확인합니다.

1. **용량** ‒ 사용자 배포는 *셀 로직의 최소 사용자 수를* 기반으로 하므로 사용자는 사용자 수가 가장 적은 셀에 할당됩니다.

**참고**  
이러한 기준은이 예시 패턴만 설명하기 위해 제공됩니다. 실제 셀-라우터 구현의 경우 보다 세분화된 사용 사례 기반 기준을 정의할 수 있습니다.

`Orchestrator`는 Dispatcher 함수를 간접적으로 호출하여 셀에 사용자를 할당합니다. 이 데모 함수에서 시장 가치는 로 정의된 정적 파라미터입니다`europe`.

`Dispatcher` 함수는 셀이 이미 사용자에게 할당되었는지 여부를 평가합니다. 셀이 이미 할당된 경우 `Dispatcher` 함수는 셀의 엔드포인트를 반환합니다. 사용자에게 할당된 셀이 없는 경우 함수는 사용자 수가 가장 적은 셀을 검색하여 사용자에게 할당하고 엔드포인트를 반환합니다. 셀 검색 쿼리의 효율성은 글로벌 보조 인덱스를 사용하여 최적화됩니다.

*매퍼 함수*

`Mapper` 함수는 데이터베이스에서 user-to-cell 매핑의 저장 및 유지 관리를 감독합니다. 등록된 각 사용자에게 단일 셀이 할당됩니다. 각 셀에는 AWS 리전마다 하나씩 두 개의 고유한 URL이 있습니다. API Gateway에서 호스팅되는 API 엔드포인트 역할을 하는 이러한 URL은 글로벌 애플리케이션에 대한 인바운드 포인트 역할을 합니다.

`Mapper` 함수는 클라이언트 애플리케이션으로부터 요청을 수신하면 DynamoDB 테이블에서 쿼리를 실행`tbl_router`하여 제공된 이메일 ID와 연결된 user-to-cell 매핑을 검색합니다. 할당된 셀을 찾으면 `Mapper` 함수는 셀의 두 URL을 즉시 제공합니다. 또한이 `Mapper` 함수는 셀 URL의 변경을 능동적으로 모니터링하고 사용자 설정에 대한 알림 또는 업데이트를 시작합니다.

*Scaler 함수*

`Scaler` 함수는 셀의 잔여 용량을 관리합니다. 각 새 사용자 등록 요청에 대해 `Scaler` 함수는 `Dispatcher` 함수가 사용자에게 할당한 셀의 사용 가능한 용량을 평가합니다. 셀이 지정된 평가 기준에 따라 미리 결정된 한도에 도달한 경우 함수는 Amazon SQS 대기열을 통해 프로비저닝 및 배포 계층으로 요청을 시작하여 새 셀의 프로비저닝 및 배포를 요청합니다. 셀 크기 조정은 다음과 같은 평가 기준 세트를 기반으로 실행할 수 있습니다.

1. **최대 사용자** ‒ 각 셀에는 최대 500명의 사용자가 있을 수 있습니다.

1. **버퍼 용량** ‒ 각 셀의 버퍼 용량은 20%입니다. 즉, 각 셀을 언제든지 400명의 사용자에게 할당할 수 있습니다. 나머지 20% 버퍼 용량은 향후 사용 사례 및 예상치 못한 시나리오(예: 셀 생성 및 프로비저닝 서비스를 사용할 수 없는 경우) 처리를 위해 예약되어 있습니다.

1. **셀 생성** ‒ 기존 셀이 용량의 70%에 도달하면 요청이 트리거되어 추가 셀을 생성합니다.

**참고**  
이러한 기준은이 예시 패턴만 설명하기 위해 제공됩니다. 실제 셀-라우터 구현의 경우 보다 세분화된 사용 사례 기반 기준을 정의할 수 있습니다.

데모 `Scaler` 코드는가 새로 등록된 사용자에게 셀을 `Dispatcher` 성공적으로 할당한 `Orchestrator` 후에서 실행됩니다. 는에서 셀 ID를 `Scaler`받으면 미리 정의된 `Dispatcher`평가 기준에 따라 지정된 셀에 추가 사용자를 수용할 수 있는 적절한 용량이 있는지 평가합니다. 셀의 용량이 충분하지 않으면 `Scaler` 함수가 Amazon SQS 서비스에 메시지를 전달합니다. 이 메시지는 프로비저닝 및 배포 계층 내의 서비스에서 검색되어 새 셀의 프로비저닝을 시작합니다.

**Validator 함수**

`Validator` 함수는 셀 액세스와 관련된 문제를 식별하고 해결합니다. 사용자가 글로벌 애플리케이션에 로그인하면 애플리케이션은 사용자 프로필 설정에서 셀의 URL을 검색하고 셀 내에 할당된 두 리전 중 하나로 사용자 요청을 라우팅합니다. URL에 액세스할 수 없는 경우 애플리케이션은 셀 라우터에 유효한 URL 요청을 디스패치할 수 있습니다. cell-router `Orchestrator`는 `Validator`를 간접적으로 호출합니다. 는 검증 프로세스를 `Validator` 시작합니다. 검증에는 특히 다음이 포함될 수 있습니다.
+ 잠재적 업데이트를 식별하고 처리하기 위해 데이터베이스에 저장된 URL을 사용하여 요청의 셀 URLs 교차 참조
+ 심층 상태 확인 실행(예: 셀의 엔드포인트에 대한 `HTTP GET` 요청)

결과적으로 `Validator` 함수는 클라이언트 애플리케이션 요청에 대한 응답을 제공하고 필요한 수정 단계와 함께 검증 상태를 제공합니다.

`Validator`는 사용자 경험을 개선하도록 설계되었습니다. 인시던트로 인해 셀을 일시적으로 사용할 수 없기 때문에 특정 사용자가 글로벌 애플리케이션에 액세스하는 데 어려움을 겪는 시나리오를 생각해 보세요. `Validator` 함수는 일반적인 오류를 표시하는 대신 지시적인 문제 해결 단계를 제공할 수 있습니다. 이러한 단계에는 다음과 같은 작업이 포함됩니다.
+ 사용자에게 인시던트에 대해 알립니다.
+ 서비스 가용성 전에 대략적인 대기 시간을 제공합니다.
+ 추가 정보를 얻기 위한 지원 연락처 번호를 제공합니다.

`Validator` 함수의 데모 코드는 요청의 사용자 제공 셀 URL이 `tbl_router` 테이블에 저장된 레코드와 일치하는지 확인합니다. 또한이 `Validator` 함수는 셀이 정상인지 여부를 확인합니다.

# VPC 엔드포인트를 통해 Amazon S3 버킷에 대한 프라이빗 액세스 설정
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint"></a>

*Martin Maritsch, Nicolas Jacob Baer, Gabriel Rodriguez Garcia, Shukhrat Khodjaev, Mohan Gowda Purushothama, Joaquin Rinaudo, Amazon Web Services*

## 요약
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-summary"></a>

Amazon Simple Storage Service(Amazon S3)에서 미리 서명된 URL을 사용하면 원하는 크기의 파일을 대상 사용자와 공유할 수 있습니다. 기본적으로 Amazon S3 미리 서명된 URL은 만료 기간 내에 인터넷에서 액세스할 수 있으므로 사용이 편리합니다. 그러나 기업 환경에서는 프라이빗 네트워크로만 제한하기 위해 Amazon S3 미리 서명된 URL에 대한 액세스가 필요한 경우가 많습니다.

이 패턴은 인터넷 순회 없이 프라이빗 네트워크의 미리 서명된 URL을 사용하여 S3 객체와 안전하게 상호 작용할 수 있는 서버리스 솔루션을 제공합니다. 아키텍처에서 사용자는 내부 도메인 이름을 통해 Application Load Balancer에 액세스합니다. 트래픽은 Amazon API Gateway와 S3 버킷의 Virtual Private Cloud(VPC) 엔드포인트를 통해 내부적으로 라우팅됩니다. 이 AWS Lambda 함수는 프라이빗 VPC 엔드포인트를 통한 파일 다운로드에 대해 미리 서명된 URLs을 생성하여 민감한 데이터의 보안 및 개인 정보 보호를 강화하는 데 도움이 됩니다.

## 사전 조건 및 제한 사항
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-prereqs"></a>

**사전 조건 **
+ 회사 네트워크에 연결된(예:를 통해)에 배포 AWS 계정 된 서브넷을 포함하는 VPC입니다 AWS Direct Connect.

**제한 사항 **
+ S3 버킷의 이름은 도메인과 동일해야 하므로 [Amazon S3 버킷 이름 지정 규칙을 확인하는 것이 좋습니다.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)
+ 이 샘플 아키텍처에는 배포된 인프라에 대한 모니터링 기능이 포함되지 않습니다. 사용 사례에 모니터링이 필요한 경우 [AWS 모니터링 서비스를](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html) 추가하는 것이 좋습니다.
+ 이 샘플 아키텍처에는 입력 검증이 포함되지 않습니다. 사용 사례에 입력 검증과 보안 강화가 필요한 경우를 [사용하여 API AWS WAF 를 보호하는 것이](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) 좋습니다.
+ 이 샘플 아키텍처에는 Application Load Balancer를 사용한 액세스 로깅이 포함되지 않습니다. 사용 사례에 액세스 로깅이 필요한 경우 [로드 밸런서 액세스 로그](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)를 활성화하는 것이 좋습니다.

**버전**
+ Python 버전 3.11 이상
+ Terraform 버전 1.6 이상

## 아키텍처
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-architecture"></a>

**대상 기술 스택**

대상 기술 스택에는 다음 AWS 서비스가 사용됩니다.
+ **Amazon S3**는 파일을 안전하게 업로드, 다운로드 및 저장하는 데 사용되는 코어 스토리지 서비스입니다.
+ **Amazon API Gateway**는 S3 버킷과 상호 작용하기 위한 리소스 및 엔드포인트를 노출합니다. 이 서비스는 데이터 다운로드 또는 업로드를 위해 미리 서명된 URL을 생성하는 역할을 합니다.
+ **AWS Lambda**는 Amazon S3에서 파일을 다운로드하기 위해 미리 서명된 URL을 생성합니다. API Gateway가 Lambda 함수를 직접 호출합니다.
+ **Amazon VPC**는 VPC 내에 리소스를 배포하여 네트워크 격리를 제공합니다. VPC에는 트래픽 흐름을 제어하는 서브넷과 라우팅 테이블이 포함되어 있습니다.
+ **Application Load Balancer**는 수신 트래픽을 API Gateway 또는 S3 버킷의 VPC 엔드포인트로 라우팅합니다. 이를 통해 회사 네트워크의 사용자가 내부적으로 리소스에 액세스할 수 있습니다.
+ **Amazon S3용 VPC 엔드포인트**를 사용하면 퍼블릭 인터넷을 통과하지 않고도 VPC와 Amazon S3의 리소스 간에 직접 프라이빗 통신을 수행할 수 있습니다.
+ **AWS Identity and Access Management (IAM)**는 AWS 리소스에 대한 액세스를 제어합니다. API 및 기타 서비스와의 안전한 상호 작용을 보장하기 위해 권한이 설정됩니다.

**대상 아키텍처 **

![\[VPC 종료를 통해 S3 버킷에 대한 프라이빗 액세스 설정\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/683ca6a1-789c-4444-bcbf-e4e80d253df3/images/1ca7ee17-d346-4eb9-bf61-ccf42528a401.png)


다이어그램은 다음을 보여 줍니다.

1. 회사 네트워크의 사용자는 내부 도메인 이름을 통해 Application Load Balancer에 액세스할 수 있습니다. 회사 네트워크와의 인트라넷 서브넷 사이에 연결이 있다고 가정합니다 AWS 계정 (예: Direct Connect 연결을 통해).

1. Application Load Balancer는 수신 트래픽을 API Gateway로 라우팅하여 미리 서명된 URL을 생성하여 Amazon S3 또는 S3 버킷의 VPC 엔드포인트에 데이터를 다운로드하거나 업로드합니다. 두 시나리오 모두에서 요청은 내부적으로 라우팅되며 인터넷을 통과할 필요가 없습니다.

1. API Gateway는 리소스와 엔드포인트를 노출하여 S3 버킷과 상호 작용합니다. 이 예에서는 S3 버킷에서 파일을 다운로드할 엔드포인트를 제공하지만 업로드 기능도 제공하도록 확장할 수 있습니다.

1. Lambda 함수는 퍼블릭 Amazon S3 도메인 대신 Application Load Balancer의 도메인 이름을 사용하여 Amazon S3에서 파일을 다운로드할 미리 서명된 URL을 생성합니다.

1. 사용자는 미리 서명된 URL을 수신하고 이를 사용하여 Application Load Balancer를 사용하여 Amazon S3에서 파일을 다운로드합니다. 로드 밸런서에는 API용이 아닌 트래픽을 S3 버킷의 VPC 엔드포인트로 전송하는 기본 경로가 포함되어 있습니다.

1. VPC 엔드포인트는 사용자 지정 도메인 이름이 있는 미리 서명된 URL을 S3 버킷으로 라우팅합니다. S3 버킷은 도메인과 이름이 동일해야 합니다.

**자동화 및 규모 조정**

이 패턴은 Terraform을 사용하여 코드 리포지토리의 인프라를에 배포합니다 AWS 계정.

## 도구
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-tools"></a>

**도구**
+ [Python](https://www.python.org/)은 범용 컴퓨터 프로그래밍 언어입니다.
+ [Terraform](https://www.terraform.io/)은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 통해 AWS 서비스와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.

**코드 리포지토리**

이 패턴의 코드는 [https://github.com/aws-samples/private-s3-vpce](https://github.com/aws-samples/private-s3-vpce) GitHub 리포지토리에서 사용할 수 있습니다.

## 모범 사례
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-best-practices"></a>

이 패턴의 샘플 아키텍처는 [IAM 권한을](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) 사용하여 API에 대한 액세스를 제어합니다. 유효한 IAM 자격 증명이 있는 사람은 누구나 API를 직접적으로 호출할 수 있습니다. 사용 사례에 더 복잡한 권한 부여 모델이 필요한 경우 [다른 액세스 제어 메커니즘을 사용할](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html) 수 있습니다.

## 에픽
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-epics"></a>

### 에 솔루션 배포 AWS 계정
<a name="deploy-the-solution-in-an-aws-account"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS 자격 증명을 가져옵니다. | 자격 AWS 증명과 계정에 대한 액세스를 검토합니다. 지침은 AWS CLI 설명서의 [구성 및 자격 증명 파일 설정을](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 참조하세요. | AWS DevOps, 일반 AWS | 
| 리포지토리를 복제합니다. | 이 패턴과 함께 제공된 GitHub 리포지토리를 복제합니다.<pre>git clone https://github.com/aws-samples/private-s3-vpce</pre> | AWS DevOps, 일반 AWS | 
| 변수를 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps, 일반 AWS | 
| 솔루션을 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps, 일반 AWS | 

### 솔루션 테스트
<a name="test-the-solution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 테스트 파일을 생성합니다. | Amazon S3에 파일을 업로드하여 파일 다운로드에 대한 테스트 시나리오를 생성합니다. [Amazon S3 콘솔](https://console.aws.amazon.com/s3/) 또는 다음 AWS CLI 명령을 사용할 수 있습니다.<pre>aws s3 cp /path/to/testfile s3://your-bucket-name/testfile</pre> | AWS DevOps, 일반 AWS | 
| 미리 서명된 URL 기능을 테스트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint.html) | AWS DevOps, 일반 AWS | 
| 정리 | 리소스가 더 이상 필요하지 않은 경우 리소스를 제거해야 합니다.<pre>terraform destroy</pre> | AWS DevOps, 일반 AWS | 

## 문제 해결
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 숫자 기호(\$1) 브레이크 URL 파라미터와 같은 특수 문자가 포함된 S3 객체 키 이름으로 인해 오류가 발생합니다. | URL 파라미터를 올바르게 인코딩하고 S3 객체 키 이름이 [Amazon S3 지침을](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html) 따르는지 확인합니다. | 

## 관련 리소스
<a name="set-up-private-access-to-an-amazon-s3-bucket-through-a-vpc-endpoint-resources"></a>

Amazon S3:
+ [미리 서명된 URLs을 사용하여 객체 공유](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html)
+ [버킷 정책을 사용하여 VPC 엔드포인트에서 액세스 제어](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)

Amazon API Gateway:
+ [API Gateway에서 프라이빗 APIs에 VPC 엔드포인트 정책 사용](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-endpoint-policies.html)

Application Load Balancer:
+ [ALB, S3 및 PrivateLink를 사용하여 내부 HTTPS 정적 웹 사이트 호스팅](https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/)(AWS 블로그 게시물)

# Amazon Bedrock AWS Step Functions 을 사용하여의 상태 문제 해결
<a name="troubleshooting-states-in-aws-step-functions"></a>

*Aniket Kurzadkar 및 Sangam Kushwaha, Amazon Web Services*

## 요약
<a name="troubleshooting-states-in-aws-step-functions-summary"></a>

AWS Step Functions 오류 처리 기능은 [워크플로](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)의 상태에서 발생하는 오류를 확인하는 데 도움이 될 수 있지만 오류의 근본 원인을 찾아 디버깅하는 것은 여전히 어려울 수 있습니다. 이 패턴은 이러한 문제를 해결하고 Amazon Bedrock이 Step Functions의 상태에서 발생하는 오류를 해결하는 데 어떻게 도움이 되는지 보여줍니다.

Step Functions는 워크플로 오케스트레이션을 제공하므로 개발자가 프로세스를 더 쉽게 자동화할 수 있습니다. Step Functions는 다음과 같은 이점을 제공하는 오류 처리 기능도 제공합니다.
+ 개발자는 문제가 발생할 때 완전히 실패하지 않는 복원력이 뛰어난 애플리케이션을 만들 수 있습니다.
+ 워크플로에는 다양한 유형의 오류를 다르게 처리하는 조건부 로직이 포함될 수 있습니다.
+ 시스템은 지수 백오프를 통해 실패한 작업을 자동으로 재시도할 수 있습니다.
+ 오류 시나리오에 대해 대체 실행 경로를 정의하여 워크플로를 조정하고 처리를 계속할 수 있습니다.

Step Functions 워크플로에서 오류가 발생하면이 패턴은 Step Functions에서 지원하는 Claude 3과 같은 파운데이션 모델(FM)로 오류 메시지와 컨텍스트를 전송하는 방법을 보여줍니다. FM은 오류를 분석하고 분류하며 잠재적 수정 단계를 제안할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="troubleshooting-states-in-aws-step-functions-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+ [AWS Step Functions 및 워크플로](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)에 대한 기본 이해
+ Amazon Bedrock [API 연결](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html)

**제한 사항 **
+ 다양한에이 패턴의 접근 방식을 사용할 수 있습니다 AWS 서비스. 그러나 결과는 AWS Lambda 이후에 Amazon Bedrock에서 평가한에서 생성된 프롬프트에 따라 달라질 수 있습니다.
+ 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전별 가용성은 [리전별 AWS 서비스](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요. 구체적인 엔드포인트는 [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)을 참조하고 서비스 링크를 선택합니다.

## 아키텍처
<a name="troubleshooting-states-in-aws-step-functions-architecture"></a>

다음 다이어그램은 이 패턴의 워크플로 및 구성 요소를 보여 줍니다.

![\[Step Functions, Amazon Bedrock 및 Amazon SNS를 사용한 오류 처리 및 알림을 위한 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/78f86c74-c9de-4562-adcc-105b87a77a54/images/d8eda499-ea1d-45e5-8a36-e04a44ad5c4b.png)


다이어그램은 Step Functions 상태 시스템에서 오류 처리 및 알림을 위한 자동화된 워크플로를 보여줍니다.

1. 개발자가 상태 시스템의 실행을 시작합니다.

1. Step Functions 상태 시스템이 상태 처리를 시작합니다. 이 경우 다음 두 가지 결과가 가능합니다.
   + (a) 모든 상태가 성공적으로 실행되면 워크플로는 이메일 성공 알림을 위해 Amazon SNS로 직접 진행합니다.
   + (b) 상태가 실패하면 워크플로가 Lambda 함수를 처리하는 오류로 이동합니다.

1. 이 오류는 다음 경우에 발생할 수 있습니다.
   + (a) Lambda 함수(오류 핸들러)가 트리거됩니다. Lambda 함수는 Step Functions 상태 시스템이 전달한 이벤트 데이터에서 오류 메시지를 추출합니다. 그런 다음 Lambda 함수는이 오류 메시지를 기반으로 프롬프트를 준비하고 Amazon Bedrock에 프롬프트를 보냅니다. 프롬프트는 발생한 특정 오류와 관련된 솔루션과 제안을 요청합니다.
   + (b) 생성형 AI 모델을 호스팅하는 Amazon Bedrock은 입력 프롬프트를 처리합니다. (이 패턴은 Amazon Bedrock이 지원하는 많은 FM 중 하나인 Anthropic Claude 3 파운데이션 모델(FMs 사용합니다.) AI 모델은 오류 컨텍스트를 분석합니다. 그런 다음 모델은 오류가 발생한 이유에 대한 설명, 오류를 해결하기 위한 잠재적 솔루션, 향후 동일한 실수를 피하기 위한 제안을 포함할 수 있는 응답을 생성합니다.

     Amazon Bedrock은 AI 생성 응답을 Lambda 함수에 반환합니다. Lambda 함수는 응답을 처리하여 잠재적으로 응답을 포맷하거나 키 정보를 추출합니다. 그런 다음 Lambda 함수는 상태 시스템 출력에 응답을 전송합니다.

1. 오류 처리 또는 성공적인 실행 후 Amazon SNS가 이메일 알림을 보내도록 트리거하여 워크플로가 종료됩니다.

## 도구
<a name="troubleshooting-states-in-aws-step-functions-tools"></a>

**AWS 서비스**
+ [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)은 선도적인 AI 스타트업과 Amazon의 고성능 파운데이션 모델(FM)을 통합 API를 통해 사용할 수 있게 해주는 완전 관리형 서비스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)는 AWS Lambda 함수 및 기타를 결합하여 비즈니스 크리티컬 애플리케이션을 구축하는 AWS 서비스 데 도움이 되는 서버리스 오케스트레이션 서비스입니다.

## 모범 사례
<a name="troubleshooting-states-in-aws-step-functions-best-practices"></a>
+ Amazon Bedrock은 훈련된 데이터에서 학습하는 생성형 AI 모델이므로 해당 데이터를 사용하여 컨텍스트를 훈련하고 생성합니다. 데이터 유출 문제로 이어질 수 있는 모든 프라이빗 정보를 숨기는 것이 가장 좋습니다.
+ 생성형 AI는 귀중한 인사이트를 제공할 수 있지만 중요한 오류 처리 결정에는 특히 프로덕션 환경에서 인적 감독이 포함되어야 합니다.

## 에픽
<a name="troubleshooting-states-in-aws-step-functions-epics"></a>

### 워크플로에 대한 상태 시스템 생성
<a name="create-a-state-machine-for-your-workflow"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 상태 시스템 생성 | 워크플로에 적합한 상태 시스템을 생성하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | DevOps | 

### Lambda 함수 생성
<a name="create-a-lam-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda 함수를 생성합니다. | Lambda 함수를 생성하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | DevOps | 
| Lambda 코드에서 필요한 로직을 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html)<pre>client = boto3.client(<br />        service_name="bedrock-runtime", region_name="selected-region"<br />    )<br /><br />    # Invoke Claude 3 with the text prompt<br />    model_id = "your-model-id" # Select your Model ID, Based on the Model Id, Change the body format<br /><br />    try:<br />        response = client.invoke_model(<br />            modelId=model_id,<br />            body=json.dumps(<br />                {<br />                    "anthropic_version": "bedrock-2023-05-31",<br />                    "max_tokens": 1024,<br />                    "messages": [<br />                        {<br />                            "role": "user",<br />                            "content": [{"type": "text", "text": prompt}],<br />                        }<br />                    ],<br />                }<br />            ),<br />        )<br /></pre>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | DevOps | 

### Step Functions를 Lambda와 통합
<a name="integrate-sfn-with-lam"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Step Functions에서 오류를 처리하도록 Lambda를 설정합니다. | 워크플로를 중단하지 않고 오류를 처리하도록 Step Functions를 설정하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/troubleshooting-states-in-aws-step-functions.html) | DevOps | 

## 문제 해결
<a name="troubleshooting-states-in-aws-step-functions-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| Lambda가 Amazon Bedrock API에 액세스할 수 없음(수행 권한이 없음) | 이 오류는 Lambda 역할에 Amazon Bedrock API에 액세스할 권한이 없는 경우에 발생합니다. 이 문제를 해결하려면 Lambda 역할에 대한 `AmazonBedrockFullAccess` 정책을 추가합니다. 자세한 내용은 *AWS 관리형 정책 참조 안내서*의 [AmazonBedrockFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)를 참조하세요. | 
| Lambda 제한 시간 오류 | 프롬프트에 따라 응답을 생성하고 다시 보내는 데 30초 이상 걸릴 수 있습니다. 이 문제를 해결하려면 구성 시간을 늘리세요. 자세한 내용은 *AWS Lambda 개발자 가이드*의 [Lambda 함수 제한 시간 구성](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockFullAccess.html)을 참조하세요. | 

## 관련 리소스
<a name="troubleshooting-states-in-aws-step-functions-resources"></a>
+ [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
+ [Amazon Bedrock API 액세스](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started-api.html)
+ [첫 번째 Lambda 함수 생성](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)
+ [Step Functions를 사용하여 워크플로 개발](https://docs.aws.amazon.com/step-functions/latest/dg/developing-workflows.html#development-run-debug)
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 

# 패턴 더 보기
<a name="serverless-more-patterns-pattern-list"></a>

**Topics**
+ [Athena를 사용한 Amazon DynamoDB 테이블 액세스, 쿼리 및 조인](access-query-and-join-amazon-dynamodb-tables-using-athena.md)
+ [GitHub Actions를 사용하여 AWS CDK Python 애플리케이션에 대한 Amazon CodeGuru 리뷰 자동화](automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.md)
+ [AWS 리소스 평가 자동화](automate-aws-resource-assessment.md)
+ [AWS SAM을 사용하여 중첩된 애플리케이션 자동 배포](automate-deployment-of-nested-applications-using-aws-sam.md)
+ [GitHub Actions, Artifactory 및 Terraform을 사용하여 다중 리포지토리 설정에서 AWS Supply Chain 데이터 레이크 배포 자동화](automate-the-deployment-of-aws-supply-chain-data-lakes.md)
+ [에서 Amazon RDS 인스턴스 복제 자동화 AWS 계정](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md)
+ [DynamoDB TTL을 사용하여 Amazon S3에 항목 자동으로 보관](automatically-archive-items-to-amazon-s3-using-dynamodb-ttl.md)
+ [CodeCommit의 모노리포지토리에 대한 변경 사항 자동 감지 및 다양한 CodePipeline 파이프라인 시작](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md)
+ [Amazon OpenSearch Service에서 멀티 테넌트 서버리스 아키텍처 구축](build-a-multi-tenant-serverless-architecture-in-amazon-opensearch-service.md)
+ [클라우드에서 고급 메인프레임 파일 뷰어 구축](build-an-advanced-mainframe-file-viewer-in-the-aws-cloud.md)
+ [AWS 서비스를 사용하여 위험 가치(VaR) 계산](calculate-value-at-risk-var-by-using-aws-services.md)
+ [여러 AWS 계정 및 AWS 리전에 걸쳐 AWS Service Catalog 제품 복사](copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.md)
+ [Java 및 Python 프로젝트를 위한 동적 CI 파이프라인을 자동으로 생성](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.md)
+ [CQRS 및 이벤트 소싱을 사용하여 모놀리식 유형을 마이크로서비스로 분해하기](decompose-monoliths-into-microservices-by-using-cqrs-and-event-sourcing.md)
+ [Amazon S3 및 CloudFront에 React 기반 단일 페이지 애플리케이션 배포](deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.md)
+ [프라이빗 엔드포인트와 Application Load Balancer 사용하여 내부 웹 사이트에 Amazon API Gateway API 배포](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md)
+ [AWS 클라우드에서 인프라를 코드로 사용하여 서버리스 데이터 레이크 배포와 관리](deploy-and-manage-a-serverless-data-lake-on-the-aws-cloud-by-using-infrastructure-as-code.md)
+ [Terraform 및 Amazon Bedrock을 AWS 사용하여에 RAG 사용 사례 배포](deploy-rag-use-case-on-aws.md)
+ [Amazon Bedrock 에이전트 및 지식 기반을 사용하여 완전 자동화된 채팅 기반 어시스턴트 개발](develop-a-fully-automated-chat-based-assistant-by-using-amazon-bedrock-agents-and-knowledge-bases.md)
+ [RAG 및 ReAct 프롬프트를 사용하여 고급 생성형 AI 채팅 기반 어시스턴트 개발](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md)
+ [Step Functions를 사용하여 IIAM Access Analyzer로 IAM 정책을 동적으로 생성하기](dynamically-generate-an-iam-policy-with-iam-access-analyzer-by-using-step-functions.md)
+ [Amazon Cognito 및 IaC 자동화를 사용하여 Amazon Quick Sight 시각적 구성 요소를 웹 애플리케이션에 임베드](embed-quick-sight-visual-components-into-web-apps-cognito-iac.md)
+ [시작 시 Amazon S3에 Amazon EMR 로깅이 활성화되었는지 확인](ensure-amazon-emr-logging-to-amazon-s3-is-enabled-at-launch.md)
+ [온디맨드 용량에 대한 DynamoDB 테이블의 비용 추정](estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.md)
+ [Amazon Personalize를 사용하여 개인화되고 순위가 다시 매겨진 추천 생성](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md)
+ [AWS Glue 작업과 Python을 사용하여 테스트 데이터 생성](generate-test-data-using-an-aws-glue-job-and-python.md)
+ [SQL Server에서 PostgreSQL로 마이그레이션할 때 PII 데이터에 대한 SHA1 해싱 구현](implement-sha1-hashing-for-pii-data-when-migrating-from-sql-server-to-postgresql.md)
+ [AWS Step Functions을 사용하여 서버리스 사가 패턴 구현](implement-the-serverless-saga-pattern-by-using-aws-step-functions.md)
+ [AWS CDK를 통해 여러 AWS 리전, 계정, OU에서 Amazon DevOps Guru를 활성화하여 운영 성능을 개선하세요.](improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.md)
+ [Step Functions와 Lambda 프록시 함수를 사용하여 여러 AWS 계정에서 CodeBuild 프로젝트 시작](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md)
+ [AWS Glue를 사용하여 Apache Cassandra 워크로드를 Amazon Keyspaces으로 마이그레이션](migrate-apache-cassandra-workloads-to-amazon-keyspaces-by-using-aws-glue.md)
+ [여러에서 공유 Amazon Machine Image 사용 모니터링 AWS 계정](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md)
+ [AWS CDK 및 GitHub Actions 워크플로를 사용하여 다중 계정 서버리스 배포 최적화](optimize-multi-account-serverless-deployments.md)
+ [를 사용하여 검증, 변환 및 파티셔닝으로 ETL 파이프라인 오케스트레이션 AWS Step Functions](orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.md)
+ [Amazon Athena를 사용하여 SQL로 Amazon DynamoDB 테이블 쿼리](query-amazon-dynamodb-tables-sql-amazon-athena.md)
+ [AWS Fargate를 사용하여 이벤트 기반 및 예약된 워크로드를 대규모로 실행](run-event-driven-and-scheduled-workloads-at-scale-with-aws-fargate.md)
+ [사용자 지정 속성을 Amazon Cognito로 전송하고 토큰에 주입](send-custom-attributes-cognito.md)
+ [Amazon CloudFront를 사용하여 VPC를 통해 Amazon S3 버킷의 정적 콘텐츠 제공하기](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md)
+ [자동화된 워크플로를 사용하여 Amazon Lex 봇 개발 및 배포 간소화](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md)
+ [AWS Lambda를 사용하여 육각형 아키텍처로 Python 프로젝트 구조화](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md)
+ [OpenSearch 및 Elasticsearch 쿼리를 위해 자연어를 쿼리 DSL로 변환](translate-natural-language-query-dsl-opensearch-elasticsearch.md)
+ [계정 간에 Amazon Redshift 클러스터에서 Amazon S3로 데이터 언로드](unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.md)
+ [AWS Fargate WaitCondition 후크 구성을 사용하여 리소스 종속성과 작업 실행을 조정합니다.](use-the-aws-fargate-waitcondition-hook-construct.md)
+ [Amazon Bedrock 에이전트를 사용하여 텍스트 기반 프롬프트를 통해 Amazon EKS에서 액세스 항목 제어 생성 자동화](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md)

# 네트워킹
<a name="networking-pattern-list"></a>

**Topics**
+ [AWS Transit Gateway를 사용하여 리전 간 피어링 설정 자동화](automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.md)
+ [AWS Transit Gateway를 사용하여 네트워크 연결 중앙 집중화](centralize-network-connectivity-using-aws-transit-gateway.md)
+ [Application Load Balancer를 사용하여 Oracle WebLogic에서 Oracle JD Edwards EnterpriseOne에 대한 HTTPS 암호화 구성](configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.md)
+ [프라이빗 네트워크를 통해 Application Migration Service 데이터 및 컨트롤 플레인에 연결](connect-to-application-migration-service-data-and-control-planes-over-a-private-network.md)
+ [AWS CloudFormation 사용자 지정 리소스와 Amazon SNS를 사용하여 Infoblox 객체를 생성](create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.md)
+ [Terraform을 AWS 사용하여에서 계층적 다중 리전 IPAM 아키텍처 생성](multi-region-ipam-architecture.md)
+ [에 대한 Amazon CloudWatch 알림 사용자 지정 AWS Network Firewall](customize-amazon-cloudwatch-alerts-for-aws-network-firewall.md)
+ [Terraform을 사용하여 AWS Wavelength 영역에 리소스 배포](deploy-resources-wavelength-zone-using-terraform.md)
+ [DNS 레코드를 Amazon Route 53 프라이빗 호스팅 영역으로 대량 마이그레이션합니다.](migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.md)
+ [F5에서 AWS의 Application Load Balancer로 마이그레이션할 때 HTTP 헤더를 수정](modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.md)
+ [여러의 인바운드 인터넷 액세스에 대한 Network Access Analyzer 조사 결과 보고서 생성 AWS 계정](create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.md)
+ [다중 계정 AWS 환경에서 하이브리드 네트워크에 대한 DNS 확인 설정](set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.md)
+ [ELB 로드 밸런서에 TLS 터미널이 필요한지 검증합니다](verify-that-elb-load-balancers-require-tls-termination.md)
+ [Splunk를 사용하여 AWS Network Firewall 로그 및 지표 보기](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md)
+ [패턴 더 보기](networking-more-patterns-pattern-list.md)

# AWS Transit Gateway를 사용하여 리전 간 피어링 설정 자동화
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway"></a>

*Ram Kandaswamy, Amazon Web Services*

## 요약
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-summary"></a>

AWS Transit Gateway는 중앙 허브를 통해 Virtual Private Cloud(VPC)와 온프레미스 네트워크를 연결합니다. Transit Gateway 트래픽은 항상 글로벌 Amazon Web Services(AWS) 백본에 머물며 공용 인터넷을 통과하지 않으므로 일반적인 악용 및 분산 서비스 거부 (DDoS) 공격과 같은 위협 벡터가 줄어듭니다.

두 개 이상의 AWS 리전 간에 통신해야 하는 경우, 리전 간 Transit Gateway 피어링을 사용하여 서로 다른 리전의 전송 게이트웨이 간에 피어링 연결을 설정할 수 있습니다. 하지만 Transit Gateway를 사용하여 리전 간 피어링을 수동으로 구성하려면 여러 단계를 거쳐야 하므로 시간이 많이 걸릴 수 있습니다. 이 패턴은 코드를 사용하여 피어링을 수행함으로써 이러한 수동 단계를 제거하는 자동화된 프로세스를 제공합니다. 다중 리전 조직 설정 중에 여러 리전 및 AWS 계정을 반복적으로 구성해야 하는 경우 이 방법을 사용할 수 있습니다.

이 패턴은 AWS Step Functions 워크플로, AWS Lambda 함수, AWS Identity 및 Access Management (IAM) 역할, Amazon CloudWatch Logs의 로그 그룹을 포함하는 AWS CloudFormation 스택을 사용합니다. 그런 다음 Step Functions 실행을 시작하고 트랜짓 게이트웨이를 위한 리전 간 피어링 연결을 생성할 수 있습니다. 리전 간 피어링을 수동으로 설정하려면 [AWS Transit Gateway를 사용하여 다른 AWS 리전의 VPC 피어링](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/peer-vpcs-different-regions-transit-gateway.html)을 참조하세요.

## 사전 조건 및 제한 사항
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정.
+ 기존 Amazon Simple Storage Service(S3) 버킷.
+ 요청자 리전 및 수락자 리전에서 생성 및 구성된 트랜짓 게이트웨이. *요청자* *리전은 피어링 요청이 시작되는 곳이고 수락자 영역은 피어링 요청을 수락합니다.* 이에 대한 자세한 내용은 Amazon VPC 설명서의 [VPC 피어링 연결 생성 및 수락](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html)을 참조하십시오.
+ 수락자 및 요청자 리전에 설치 및 구성된 VPC. VPC를 생성하는 단계는 Amazon VPC 설명서의 [Amazon VPC 시작하기에서 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) [생성을](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html#getting-started-create-vpc) 참조하십시오.
+ VPC는 태그와 값을 사용해야 합니다. `addToTransitGateway` `true` 
+ VPC의 보안 그룹 및 네트워크 액세스 제어 목록(ACL)이 요구 사항에 따라 구성됩니다. 이에 대한 자세한 내용은 Amazon [VPC 설명서에서 VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 및 [네트워크 ACL을](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 참조하십시오.

 

**AWS 리전 및 제한**
+ 리전 내 피어링은 특정 AWS 리전에서만 지원합니다. 리전 간 피어링을 지원하는 리전의 전체 목록은 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/faqs/) FAQ를 참조하십시오.
+ 첨부된 샘플 코드에서는 요청자 리전을 가정하고 수락자 리전으로 가정했습니다. `us-east-2` `us-west-2` 다른 리전을 구성하려면 모든 Python 파일에서 이러한 값을 편집해야 합니다. 두 개 이상의 리전을 포함하는 더 복잡한 설정을 구현하려면 리전을 Lambda 함수에 파라미터로 전달하도록 Step 함수를 변경하고 각 조합에 대해 함수를 실행할 수 있습니다.

## 아키텍처
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-architecture"></a>

![\[Step Functions는 Lambda 함수를 사용하여 Transit Gateway를 위한 피어링 연결을 생성합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b678bb87-c7b9-4f7b-b26e-eaac650e5d1b/images/d58f0586-659d-4111-b3a8-2fe23d578fef.png)


 

이 다이어그램은 다음 단계의 워크플로를 보여줍니다.

1. 사용자가 AWS CloudFormation 스택을 생성합니다.

1. AWS CloudFormation은 Lambda 함수를 사용하는 Step Functions 상태 머신을 생성합니다. 이에 대한 자세한 내용은 AWS [Step Functions 설명서에서 Lambda를 사용하는 Step Functions 상태 머신 생성](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-creating-lambda-state-machine.html)을 참조하십시오.

1. Step Functions는 피어링을 위해 Lambda 함수를 직접 호출합니다. 

1. Lambda 함수는 Transit Gateway 간에 피어링 연결을 생성합니다.

1. Step Functions는 라우팅 테이블 수정을 위해 Lambda 함수를 직접 호출합니다.

1. Lambda 함수는 VPC의 Classless Inter-Domain Routing (CIDR) 블록을 추가하여 라우팅 테이블을 수정합니다.

**Step Functions 워크플로우**

![\[Step Functions 워크플로는 Transit Gateway 피어링을 위한 라우팅 테이블을 수정하기 위해 Lambda 함수를 직접 호출합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/b678bb87-c7b9-4f7b-b26e-eaac650e5d1b/images/2f235f47-5d68-492c-b954-7dc170939cae.png)


 

이 다이어그램은 다음 단계 함수 워크플로를 보여줍니다.

1. Step Functions 워크플로는 Transit Gateway 피어링에 대해 Lambda 함수를 직접 호출합니다. 

1. 1분 동안 대기해야 하는 타이머 직접 호출이 있습니다.

1. 피어링 상태가 검색되어 조건 블록으로 전송됩니다. 블록은 루핑을 담당합니다. 

1. 성공 조건이 충족되지 않으면 워크플로가 타이머 단계에 들어가도록 코딩됩니다. 

1. 성공 조건이 충족되면 Lambda 함수가 직접 호출되어 라우팅 테이블을 수정합니다. 이 직접 호출이 끝나면 Step Functions 워크플로가 종료됩니다.

## 도구
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-tools"></a>
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) - AWS CloudFormation은 AWS 리소스를 모델링하고 설정하는 데 도움이 되는 서비스입니다.
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) – CloudWatch Logs는 사용하는 모든 시스템, 애플리케이션 및 AWS 서비스의 로그를 중앙 집중화할 수 있도록 도와줍니다.
+ [Identity and Access Management(IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) – IAM은 AWS 리소스에 대한 사용자의 액세스를 안전하게 제어할 수 있게 지원하는 웹 서비스입니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) — Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고 모든 컴퓨팅 리소스 관리를 수행합니다.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) – Step Functions를 사용하면 시각적 워크플로우에서 분산 애플리케이션의 구성 요소를 일련의 단계로 쉽게 조정할 수 있습니다. 

## 에픽
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-epics"></a>

### 피어링 자동화
<a name="automate-peering"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 첨부 파일을 S3 버킷에 업로드합니다. | AWS Management Console에 로그인하고 Amazon S3 콘솔을 연 다음 `modify-transit-gateway-routes.zip`, `peer-transit-gateway.zip`, `get-transit-gateway-peering-status.zip` 파일(첨부)을 S3 버킷에 업로드합니다. | 일반 AWS | 
| AWS CloudFormation 스택을 생성합니다. | 다음 명령을 실행하여 파일(첨부)을 사용하여 `transit-gateway-peering.json` AWS CloudFormation 스택을 생성합니다.`aws cloudformation create-stack --stack-name myteststack --template-body file://sampletemplate.json`AWS CloudFormation 스택은 Step Functions 워크플로, Lambda 함수, IAM 역할 및 CloudWatch 로그 그룹을 생성합니다.AWS CloudFormation 템플릿이 이전에 업로드한 파일이 포함된 S3 버킷을 참조하는지 확인하십시오.AWS CloudFormation 콘솔을 사용하여 스택을 생성할 수도 있습니다. 이에 대한 자세한 내용은 AWS CloudFormation [설명서의 AWS CloudFormation 콘솔에서 스택 생성을](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) 참조하십시오. | DevOps 엔지니어 | 
| Step Functions에서 새 실행을 시작합니다. | Step Functions 콘솔을 열고 새 실행을 시작합니다. Step Functions는 Lambda 함수를 직접 호출하고 Transit Gateway를 위한 피어링 연결을 생성합니다. 입력 JSON 파일은 필요하지 않습니다. 첨부 파일을 사용할 수 있고 연결 유형이 **피어링인지** 확인하십시오.이에 대한 자세한 내용은 AWS Steps Functions 설명서의 [AWS Step Functions 시작하기에서](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started.html) [새 실행 시작을](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started.html#start-new-execution) 참조하십시오. | DevOps 엔지니어, 일반 AWS | 
| 라우팅 테이블의 경로를 확인합니다. | Transit Gateway 간에 리전 간 피어링이 설정됩니다. 라우팅 테이블은 피어 리전 VPC의 IPv4 CIDR 블록 범위로 업데이트됩니다. Amazon VPC 콘솔을 열고 라우팅 테이블에서 Transit Gateway **Attachment**에 해당하는 Associations 탭을 선택합니다. 피어링된 리전의 VPC CIDR 블록 범위를 확인합니다. 자세한 단계 및 지침은 Amazon VPC 설명서의 [Transit Gateway 라우팅 테이블 연결을](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#associate-tgw-route-table) 참조하십시오. | 네트워크 관리자 | 

## 관련 리소스
<a name="automate-the-setup-of-inter-region-peering-with-aws-transit-gateway-resources"></a>
+ [Step Functions에서의 실행](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-state-machine-executions.html)
+ [Transit Gateway 피어링 연결](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html)
+ [AWS Transit Gateway를 사용하여 서로 다른 AWS 리전의 VPC 피어링](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/peer-vpcs-different-regions-transit-gateway.html)
+ AWS [Transit Gateway를 사용하여 여러 AWS 리전의 VPC를 상호 연결 - 데모 (비디오](https://www.youtube.com/watch?v=cj1rQqLxXU8))

## 첨부
<a name="attachments-b678bb87-c7b9-4f7b-b26e-eaac650e5d1b"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/b678bb87-c7b9-4f7b-b26e-eaac650e5d1b/attachments/attachment.zip) 파일의 압축을 풉니다.

# AWS Transit Gateway를 사용하여 네트워크 연결 중앙 집중화
<a name="centralize-network-connectivity-using-aws-transit-gateway"></a>

*Mydhili Palagummi, Nikhil Marrapu, Amazon Web Services*

## 요약
<a name="centralize-network-connectivity-using-aws-transit-gateway-summary"></a>

이 패턴은 AWS Transit Gateway를 사용하여 AWS 리전 내 여러 AWS 계정의 Virtual Private Cloud(VPC)에 온프레미스 네트워크를 연결할 수 있는 가장 간단한 구성을 설명합니다. 이 설정을 사용하면 한 리전의 여러 VPC 네트워크와 온프레미스 네트워크를 연결하는 하이브리드 네트워크를 구축할 수 있습니다. 이는 전송 게이트웨이와 온프레미스 네트워크에 대한 가상 프라이빗 네트워크(VPN) 연결을 사용하여 수행됩니다.

## 사전 조건 및 제한 사항
<a name="centralize-network-connectivity-using-aws-transit-gateway-prereqs"></a>

**사전 조건 **
+ AWS Organizations에서 조직의 회원 계정으로 관리되는 네트워크 서비스를 호스트하기 위한 계정
+ Classless Inter-Domain Routing(CIDR) 블록이 겹치지 않는 여러 AWS 계정의 VPC

**제한 사항 **

이 패턴은 특정 VPC 또는 온프레미스 네트워크 간의 트래픽 격리를 지원하지 않습니다. 전송 게이트웨이에 연결된 모든 네트워크는 서로 연결할 수 있습니다. 트래픽을 격리하려면 전송 게이트웨이에서 사용자 지정 라우팅 테이블을 사용해야 합니다. 이 패턴은 가장 간단한 구성인 단일 기본 전송 게이트웨이 라우팅 테이블을 사용하여 VPC와 온프레미스 네트워크만 연결합니다.

## 아키텍처
<a name="centralize-network-connectivity-using-aws-transit-gateway-architecture"></a>

**대상 기술 스택  **
+ AWS Transit Gateway
+ Site-to-Site VPN
+ VPC
+ AWS Resource Access Manager(AWS RAM)

 

**대상 아키텍처 **

![\[AWS Transit Gateway를 사용하여 온프레미스 네트워크를 리전 내 여러 AWS 계정의 VPC에 연결합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e23f5faf-e75e-42a3-80e3-142516a2db4e/images/1ecf7e04-bbf8-4304-88c8-6aceb7271d1e.jpeg)


## 도구
<a name="centralize-network-connectivity-using-aws-transit-gateway-tools"></a>

**서비스**
+ [AWS Resource Access Manager(AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하면 AWS 계정, 조직 구성 단위 또는 AWS Organizations의 전체 조직에서 리소스를 안전하게 공유할 수 있습니다.
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)는 Virtual Private Cloud(VPC)와 온프레미스 네트워크를 연결하는 중앙 허브입니다.

## 에픽
<a name="centralize-network-connectivity-using-aws-transit-gateway-epics"></a>

### 네트워크 서비스 계정에서 전송 게이트웨이 생성
<a name="create-a-transit-gateway-in-the-network-services-account"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 전송 게이트웨이를 생성합니다. | 네트워크 서비스를 호스트하려는 AWS 계정에서 대상 AWS 리전에 전송 게이트웨이를 생성합니다. 지침은 [전송 게이트웨이 생성](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#create-tgw)을 참조하세요. 다음 사항에 유의하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/centralize-network-connectivity-using-aws-transit-gateway.html) | 네트워크 관리자 | 

### 전송 게이트웨이를 온프레미스 네트워크에 연결
<a name="connect-the-transit-gateway-to-your-on-premises-network"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPN 연결의 고객 게이트웨이 디바이스를 설정합니다. | 고객 게이트웨이 디바이스는 전송 게이트웨이와 온프레미스 네트워크 간 Site-to-Site VPN 연결의 온프레미스 측에 연결됩니다. 자세한 내용은 AWS Site-to-Site VPN 설명서의 [고객 게이트웨이 디바이스](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html)를 참조하세요. 지원되는 온프레미스 고객 디바이스를 식별하거나 시작하고 해당 공용 IP 주소를 기록해 둡니다. VPN 구성은 이 에픽의 후반부에서 완료됩니다. | 네트워크 관리자 | 
| 네트워크 서비스 계정에서 전송 게이트웨이에 대한 VPN 연결을 생성합니다. | 연결을 설정하려면 전송 게이트웨이에 대한 VPN 연결을 생성합니다. 지침은 [전송 게이트웨이 VPN 연결](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html)을 참조하세요. | 네트워크 관리자 | 
| 온프레미스 네트워크의 고객 게이트웨이 디바이스에서 VPN을 구성합니다. | 전송 게이트웨이와 연결된 Site-to-Site VPN 연결의 구성 파일을 다운로드하고 고객 게이트웨이 디바이스에서 VPN 설정을 구성합니다. 지침은 [구성 파일 다운로드](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html#vpn-download-config)를 참조하세요. | 네트워크 관리자 | 

### 네트워크 서비스 계정의 전송 게이트웨이를 다른 AWS 계정 또는 조직과 공유
<a name="share-the-transit-gateway-in-the-network-services-account-to-other-aws-accounts-or-your-organization"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS Organizations 관리 계정에서 공유를 활성화합니다. | 전송 게이트웨이를 조직 또는 특정 조직 단위와 공유하려면 AWS Organizations에서 공유를 켭니다. 그렇지 않으면 각 계정에서 전송 게이트웨이를 개별적으로 공유해야 합니다. 지침은 [AWS Organizations 내 리소스 공유 활성화](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)를 참조하세요. | AWS 시스템 관리자 | 
| 네트워크 서비스 계정에서 전송 게이트웨이 리소스 공유를 생성합니다. | 조직 내 다른 AWS 계정의 VPC가 전송 게이트웨이에 연결되도록 하려면 네트워크 서비스 계정에서 AWS RAM 콘솔을 사용하여 전송 게이트웨이 리소스를 공유합니다. 지침은 [리소스 공유 생성](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create)을 참조하세요. | AWS 시스템 관리자 | 

### VPC를 전송 게이트웨이에 연결
<a name="connect-vpcs-to-the-transit-gateway"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 개별 계정에서 VPC 연결을 생성합니다. | 전송 게이트웨이가 공유된 계정에서 전송 게이트웨이 VPC 연결을 생성합니다. 지침은 [VPC에 대한 Transit Gateway Attachment 생성](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment)을 참조하세요. | 네트워크 관리자 | 
| VPC 연결 요청을 수락합니다. | 네트워크 서비스 계정에서 전송 게이트웨이 VPC 연결 요청을 수락합니다. 지침은 [공유 연결 수락](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-accept-shared-attachment)을 참조하세요. | 네트워크 관리자 | 

### 라우팅 구성
<a name="configure-routing"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 개별 계정 VPC에서 경로를 구성합니다. | 각 개별 계정 VPC에서 전송 게이트웨이를 대상으로 사용하여 온프레미스 네트워크 및 다른 VPC 네트워크에 대한 경로를 추가합니다. 지침은 [라우팅 테이블에서 경로 추가 및 제거](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)를 참조하세요. | 네트워크 관리자 | 
| 전송 게이트웨이 라우팅 테이블의 경로를 구성합니다. | VPC의 경로와 VPN 연결은 전파되어야 하며 전송 게이트웨이 기본 라우팅 테이블에 표시되어야 합니다. 필요한 경우 전송 게이트웨이 기본 라우팅 테이블에 정적 경로(한 예로 정적 VPN 연결을 위한 정적 경로)를 생성합니다. 지침은 [정적 경로 생성](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#tgw-create-static-route)을 참조하세요. | 네트워크 관리자 | 
| 보안 그룹 및 네트워크 액세스 제어 목록(ACL) 규칙을 추가합니다. | VPC의 EC2 인스턴스 및 기타 리소스의 경우, 보안 그룹 규칙과 네트워크 ACL 규칙이 VPC와 온프레미스 네트워크 간의 트래픽을 허용하는지 확인합니다. 지침은 [보안 그룹을 사용하여 리소스에 대한 트래픽 제어](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) 및 [ACL에서 규칙 추가 및 삭제](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)를 참조하세요. | 네트워크 관리자 | 

### 연결 테스트
<a name="test-connectivity"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC 간 연결성을 테스트합니다. | 네트워크 ACL 및 보안 그룹이 인터넷 제어 메시지 프로토콜(ICMP) 트래픽을 허용하는지 확인한 다음 VPC의 인스턴스에서 전송 게이트웨이에 연결된 다른 VPC로 핑을 실행합니다. | 네트워크 관리자 | 
| VPC와 온프레미스 네트워크 간의 연결을 테스트합니다. | 네트워크 ACL 규칙, 보안 그룹 규칙, 방화벽이 ICMP 트래픽을 허용하는지 확인한 다음 온프레미스 네트워크와 VPC의 EC2 인스턴스 간에 ping을 실행합니다. VPN 연결을 `UP` 상태로 유지하려면 먼저 온프레미스 네트워크에서 네트워크 통신을 시작해야 합니다. | 네트워크 관리자 | 

## 관련 리소스
<a name="centralize-network-connectivity-using-aws-transit-gateway-resources"></a>
+ [확장 가능하고 안전한 다중 VPC AWS 네트워크 인프라 구축](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf)(AWS 백서)
+ [공유 리소스 사용](https://docs.aws.amazon.com/ram/latest/userguide/working-with.html)(AWS RAM 설명서)
+ [전송 게이트웨이 사용](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html)(AWS Transit Gateway 설명서)

# Application Load Balancer를 사용하여 Oracle WebLogic에서 Oracle JD Edwards EnterpriseOne에 대한 HTTPS 암호화 구성
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer"></a>

*Thanigaivel Thirumalai, Amazon Web Services*

## 요약
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-summary"></a>

이 패턴은 Oracle WebLogic 워크로드의 Oracle JD Edwards EnterpriseOne에서 SSL 오프로딩을 위한 HTTPS 암호화를 구성하는 방법을 설명합니다. 이 접근 방식은 사용자의 브라우저와 로드 밸런서 간의 트래픽을 암호화하여 EnterpriseOne 서버의 암호화 부담을 제거합니다.

많은 사용자가 [AWS 애플리케이션 로드 밸런서](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)를 사용하여 EnterpriseOne JAVA Virtual Machine(JVM) 계층을 수평적으로 확장합니다. 로드 밸런서는 클라이언트에 대해 단일 접점의 역할을 하며 여러 JVM 간에 수신 트래픽을 분산합니다. 선택적으로 로드 밸런서는 트래픽을 여러 가용 영역에 분산하고 EnterpriseOne의 가용성을 높일 수 있습니다.

이 패턴에 설명된 프로세스는 로드 밸런서와 EnterpriseOne JVM 간의 트래픽을 암호화하는 대신 브라우저와 로드 밸런서 간의 암호화를 구성합니다. 이 접근 방식을 *SSL 오프로딩*이라고 합니다. EnterpriseOne 웹 또는 애플리케이션 서버에서 Application Load Balancer로 SSL 복호화 프로세스를 오프로드하면 애플리케이션 측의 부담이 줄어듭니다. 로드 밸런서에서 SSL이 종료되면 암호화되지 않은 트래픽이 AWS의 애플리케이션으로 라우팅됩니다.

[Oracle JD Edwards EnterpriseOne](https://www.oracle.com/applications/jd-edwards-enterpriseone/)은 제품 또는 물리적 자산을 제조, 구성, 배포, 서비스 또는 관리하는 조직을 위한 전사적 자원 관리(ERP) 솔루션입니다. JD Edwards EnterpriseOne은 다양한 하드웨어, 운영 체제 및 데이터베이스 플랫폼을 지원합니다.

## 사전 조건 및 제한 사항
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-prereqs"></a>

**사전 조건 **
+ 활성 상태의 계정.
+ AWS 서비스 호출 및 AWS 리소스 관리 권한이 있는 AWS Identity and Access Management(IAM) 역할
+ SSL 인증서

**제품 버전**
+ 이 패턴은 Oracle WebLogic 12c에서 테스트되었지만 다른 버전도 사용할 수 있습니다.

## 아키텍처
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-architecture"></a>

SSL 오프로드를 수행하는 방법은 여러 가지가 있습니다. 이 패턴은 다음 다이어그램과 같이 Application Load Balancer와 Oracle HTTP Server(OHS)를 사용합니다.

![\[로드 밸런서와 OHS를 사용한 SSL 오프로딩\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/2ae2d0eb-b9f3-41f8-ad86-9af3aade7072.png)


다음 다이어그램은 JD Edwards EnterpriseOne, Application Load Balancer 및 Java 애플리케이션 서버(JAS) JVM 레이아웃을 보여줍니다.

![\[EnterpriseOne, 로드 밸런서 및 JAS JVM 레이아웃\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/72ea35b0-2907-48b3-aeb7-0c5d9a3b831b.png)


## 도구
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-tools"></a>

**서비스**
+ [Application Load Balance](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)는 여러 가용 영역에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 같은 여러 대상에 수신 애플리케이션 트래픽을 분산합니다.
+ [AWS Certificate Manager(ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)는 AWS 웹사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 만들고, 저장하고, 갱신하는 데 도움을 줍니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.

## 모범 사례
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-best-practices"></a>
+ ACM 모범 사례는 [ACM 설명서](https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html)를 참조하세요.

## 에픽
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-epics"></a>

### WebLogic 및 OHS 설정
<a name="set-up-weblogic-and-ohs"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Oracle 구성 요소를 설치하고 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC, WebLogic 관리자 | 
| 도메인 수준에서 WebLogic 플러그인을 활성화합니다. | 로드 밸런싱에는 WebLogic 플러그인이 필요합니다. 플러그인을 활성화하려면:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC, WebLogic 관리자 | 
| 구성 파일을 편집합니다. | 이 `mod_wl_ohs.conf` 파일은 OHS에서 WebLogic으로의 프록시 요청을 구성합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)<pre><VirtualHost *:8000><br /><Location /jde><br />WLSRequest On<br />SetHandler weblogic-handler<br />WebLogicHost localhost<br />WebLogicPort 8000<br />WLProxySSL On<br />WLProxySSLPassThrough On<br /></Location><br /></VirtualHost></pre> | JDE CNC, WebLogic 관리자 | 
| Enterprise Maanger를 사용하여 OHS를 시작합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC, WebLogic 관리자 | 

### Application Load Balancer 구성
<a name="configure-the-application-load-balancer"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 대상 그룹을 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)자세한 지침은 [Elastic Load Balancing 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)를 참조하세요. | AWS 관리자 | 
| 로드 밸런서를 설정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | AWS 관리자 | 
| Route 53(DNS) 레코드 추가 | (선택 사항) 하위 도메인에 대한 Amazon Route 53 DNS 레코드를 추가할 수 있습니다. 이 레코드는 Application Load Balancer를 가리킵니다. 자세한 지침은 [Route 53 설명서](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)를 참조하세요. | AWS 관리자 | 

## 문제 해결
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| HTTP 서버가 표시되지 않습니다. | Enterprise Manager 콘솔의 **대상 탐색** 목록에 **HTTP Server**가 나타나지 않는 경우 다음 단계를 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)인스턴스가 생성되고 변경 사항이 활성화되면 **대상 탐색** 패널에서 HTTP 서버를 볼 수 있습니다. | 

## 관련 리소스
<a name="configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer-resources"></a>

**AWS 설명서**
+ [Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [퍼블릭 호스팅 영역 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html)
+ [프라이빗 호스팅 영역 사용](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)

**Oracle 설명서:**
+ [Oracle WebLogic 서버 프록시 플러그인 개요](https://docs.oracle.com/middleware/1221/webtier/develop-plugin/overview.htm#PLGWL391)
+ [인프라 설치 프로그램을 사용하여 WebLogic 서버 설치](https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/02-01-004-InstallWLSInfrastructure/installweblogicinfrastructure.html)
+ [Oracle HTTP Server 설치 및 구성](https://docs.oracle.com/middleware/1221/core/install-ohs/toc.htm)

# 프라이빗 네트워크를 통해 Application Migration Service 데이터 및 컨트롤 플레인에 연결
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network"></a>

*Amazon Web Services의 Dipin Jain과 Mike Kuznetsov*

## 요약
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-summary"></a>

이 패턴은 인터페이스 VPC 엔드포인트를 사용하여 프라이빗 보안 네트워크의 AWS Application Migration Service 데이터 영역 및 컨트롤 플레인에 연결하는 방법을 설명합니다.

Application Migration Service는 애플리케이션을 로 마이그레이션하는 비용을 간소화, 가속화 및 줄이는 고도로 자동화된 lift-and-shift(리호스팅) 솔루션입니다 AWS. 이를 통해 기업은 호환성 문제, 성능 중단 또는 긴 전환 기간 없이 많은 수의 물리적, 가상 또는 클라우드 서버를 리호스팅할 수 있습니다. AWS Management Console에서 Application Migration Service를 이용할 수 있습니다. 이를 통해 AWS CloudTrail Amazon CloudWatch 및 AWS Identity and Access Management (IAM) AWS 서비스와 같은 다른와 원활하게 통합할 수 있습니다.

 Site-to-Site VPN 서비스 AWS Direct Connect또는 Application Migration Service의 VPC 피어링을 사용하여 프라이빗 연결을 통해 소스 데이터 센터에서 데이터 영역, 즉 대상 VPC에서 데이터 복제를 위한 스테이징 영역 역할을 하는 서브넷으로 연결할 수 있습니다. 에서 제공하는 [인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html) AWS PrivateLink 를 사용하여 프라이빗 네트워크를 통해 Application Migration Service 컨트롤 플레인에 연결할 수도 있습니다. 

## 사전 조건 및 제한 사항
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-prereqs"></a>

**사전 조건 **
+ **스테이징 영역 서브넷** - Application Migration Service를 설정하기 전에 소스 서버에서 복제된 데이터 AWS (즉, 데이터 영역)의 스테이징 영역으로 사용할 서브넷을 생성합니다. Application Migration Service 콘솔에 처음 액세스할 때 [복제 설정 템플릿](https://docs.aws.amazon.com/mgn/latest/ug/template-vs-server.html)에서 이 서브넷을 지정해야 합니다. 복제 설정 템플릿에서 특정 소스 서버에 대해 이 서브넷을 재정의할 수 있습니다. 에서 기존 서브넷을 사용할 수 있지만이 용도로 전용 서브넷을 새로 생성하는 AWS 계정것이 좋습니다.
+ **네트워크 요구 사항** - 스테이징 영역 서브넷에서 Application Migration Service가 시작하는 복제 서버는의 Application Migration Service API 엔드포인트로 데이터를 전송할 수 있어야 합니다. `https://mgn.<region>.amazonaws.com/`여기서 `<region>`는 복제하려는의 코드 AWS 리전 입니다(예: `https://mgn.us-east-1.amazonaws.com`). Amazon Simple Storage Service(S3) 서비스 URL은 Application Migration Service 소프트웨어를 다운로드하는 데 필요합니다.
  +  AWS Replication Agent 설치 관리자는 Application Migration Service와 함께 사용 AWS 리전 중인의 Amazon Simple Storage Service(Amazon S3) 버킷 URL에 액세스할 수 있어야 합니다.
  + 스테이징 영역 서브넷은 Amazon S3에 액세스할 수 있어야 합니다.
  +  AWS Replication Agent가 설치된 소스 서버는 스테이징 영역 서브넷의 복제 서버와의 Application Migration Service API 엔드포인트로 데이터를 전송할 수 있어야 합니다`https://mgn.<region>.amazonaws.com/`.

다음 표에는 필수 포트가 나열되어 있습니다.


| 
| 
| 소스 | Destination | 포트 | 자세한 내용은 단원을 참조하십시오. | 
| --- |--- |--- |--- |
| 소스 데이터 센터 | Amazon S3 서비스 URL | 443(TCP) | [TCP 포트 443을 통한 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | 
| 소스 데이터 센터 | Application Migration Service를 위한 AWS 리전별 콘솔 주소 | 443(TCP) | [TCP 포트 443을 통한 소스 서버와 Application Migration Service 간 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Source-Manager-TCP-443) | 
| 소스 데이터 센터 | 스테이징 영역 서브넷 | 1500(TCP) | [TCP 포트 1500을 통한 소스 서버와 스테이징 영역 서브넷 간 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-1500) | 
| 스테이징 영역 서브넷 | Application Migration Service를 위한 AWS 리전별 콘솔 주소 | 443(TCP) | [TCP 포트 443을 통한 스테이징 영역 서브넷과 Application Migration Service 간 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-443-Staging) | 
| 스테이징 영역 서브넷 | Amazon S3 서비스 URL | 443(TCP) | [TCP 포트 443을 통한 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | 
| 스테이징 영역 서브넷 | 서브넷의 Amazon Elastic Compute Cloud(Amazon EC2) 엔드포인트 AWS 리전 | 443(TCP) | [TCP 포트 443을 통한 통신](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | 

**제한 사항**

Application Migration Service는 현재 일부 AWS 리전 및 운영 체제에서 사용할 수 없습니다.
+ [지원됨 AWS 리전](https://docs.aws.amazon.com/mgn/latest/ug/supported-regions.html)
+ [지원되는 운영 체제](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html)

## 아키텍처
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-architecture"></a>

다음 다이어그램은 일반적인 마이그레이션에 대한 네트워크 아키텍처를 보여 줍니다. 이 아키텍처에 대한 자세한 내용은 [Application Migration Service 설명서](https://docs.aws.amazon.com/mgn/latest/ug/Network-Settings-Video.html)와 [Application Migration Service 아키텍처 및 네트워크 아키텍처 동영상](https://youtu.be/ao8geVzmmRo)을 참조하십시오.

![\[일반적인 마이그레이션을 위한 Application Migration Service의 네트워크 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/546598b2-8026-4849-a441-eaa2bc2bf6bb.png)


다음 세부 보기는 Amazon S3와 Application Migration Service를 연결하기 위한 스테이징 영역 VPC의 인터페이스 VPC 엔드포인트 구성을 보여줍니다.

![\[일반적인 마이그레이션을 위한 Application Migration Service의 네트워크 아키텍처 - 세부 보기\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/bd0dfd42-4ab0-466f-b696-804dedcf4513.png)


## 도구
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-tools"></a>
+ [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)는 애플리케이션 리호스팅 비용을 간소화, 가속화 및 줄입니다 AWS.
+ [인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)를 사용하면 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결 AWS PrivateLink 없이에서 제공하는 서비스에 연결할 수 있습니다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않습니다. VPC와 기타 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.

## 에픽
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-epics"></a>

### Application Migration Service, Amazon EC2 및 Amazon S3용 엔드포인트 생성
<a name="create-endpoints-for-mgn-ec2-and-s3"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Application Migration Service를 위한 인터페이스 엔드포인트를 구성합니다. | 소스 데이터 센터와 스테이징 영역 VPC는 대상 스테이징 영역 VPC에서 생성한 인터페이스 엔드포인트를 통해 Application Migration Service 컨트롤 플레인에 비공개로 연결됩니다. 엔드포인트 생성:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)자세한 내용은 [Amazon VPC 설명서의 인터페이스 VPC 엔드포인트를 AWS 서비스 사용하여에 액세스를](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html) 참조하세요. | 마이그레이션 책임자 | 
| Amazon EC2의 인터페이스 엔드포인트를 구성합니다. | 스테이징 영역 VPC는 대상 스테이징 영역 VPC에 생성한 인터페이스 엔드포인트를 통해 Amazon EC2 API에 비공개로 연결됩니다. 엔드포인트를 생성하려면 이전 스토리에 제공된 지침을 따르십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html) | 마이그레이션 책임자 | 
| Amazon S3의 인터페이스 엔드포인트를 구성합니다. | 소스 데이터 센터와 스테이징 영역 VPC는 대상 스테이징 영역 VPC에서 생성한 인터페이스 엔드포인트를 통해 Amazon S3 API에 비공개로 연결됩니다. 엔드포인트를 생성하려면 첫 번째 스토리에 제공된 지침을 따르십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)참고: 게이트웨이 엔드포인트 연결은 VPC 외부로 확장할 수 없으므로 인터페이스 엔드포인트를 사용합니다. 자세한 내용은 [AWS PrivateLink 설명서](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html)를 참조하십시오. | 마이그레이션 책임자 | 
| Amazon S3 게이트웨이 엔드포인트를 구성합니다. | 구성 단계에서 복제 서버는 S3 버킷에 연결하여 AWS 복제 서버의 소프트웨어 업데이트를 다운로드해야 합니다. 하지만 Amazon S3 인터페이스 엔드포인트는 프라이빗 DNS 이름을 지원하지 않으며*,* Amazon S3 엔드포인트 DNS 이름을 복제 서버에 제공할 방법이 없습니다. 이 문제를 완화하려면 스테이징 영역 서브넷이 속한 VPC에 Amazon S3 게이트웨이 엔드포인트를 생성하고 스테이징 서브넷의 라우팅 테이블을 관련 경로로 업데이트합니다. 자세한 내용은 AWS PrivateLink 설명서의 [게이트웨이 엔드포인트 생성을](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3) 참조하세요. | 클라우드 관리자 | 
| 엔드포인트의 프라이빗 DNS 이름을 확인하도록 온프레미스 DNS를 구성합니다. | Application Migration Service와 Amazon EC2의 인터페이스 엔드포인트에는 VPC에서 확인할 수 있는 프라이빗 DNS 이름이 있습니다. 하지만 이러한 인터페이스 엔드포인트의 프라이빗 DNS 이름을 확인하도록 온프레미스 서버를 구성해야 합니다.이러한 서버를 구성하는 방법은 여러 가지가 있습니다. 이 패턴에서는 온프레미스 DNS 쿼리를 스테이징 영역 VPC의 Amazon Route 53 Resolver 인바운드 엔드포인트로 전달하여이 기능을 테스트했습니다. 자세한 내용은 Route 53 설명서에서 [VPC와 네트워크 간 DNS 쿼리 해결](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)을 참조하십시오. | 마이그레이션 엔지니어 | 

### 전용 링크를 통해 Application Migration Service 컨트롤 플레인에 연결
<a name="connect-to-the-mgn-control-plane-over-a-private-link"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 를 사용하여 AWS Replication Agent를 설치합니다 AWS PrivateLink. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)다음은 Linux에 대한 예입니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)Application Migration Service와의 연결을 설정하고 AWS 복제 에이전트를 설치한 후 [Application Migration Service 설명서](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)의 지침에 따라 소스 서버를 대상 VPC 및 서브넷으로 마이그레이션합니다. | 마이그레이션 엔지니어 | 

## 관련 리소스
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-resources"></a>

**Application Migration 서비스 설명서**
+ [개념](https://docs.aws.amazon.com/mgn/latest/ug/CloudEndure-Concepts.html)
+ [마이그레이션 워크플로 ](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)
+ [빠른 시작 설명서](https://docs.aws.amazon.com/mgn/latest/ug/quick-start-guide-gs.html)
+ [FAQ](https://docs.aws.amazon.com/mgn/latest/ug/FAQ.html)
+ [문제 해결](https://docs.aws.amazon.com/mgn/latest/ug/troubleshooting.html)

**추가 리소스**
+ [VPC 인터페이스 엔드포인트를 AWS 사용하여의 다중 계정 아키텍처에서 애플리케이션 리호스팅](https://docs.aws.amazon.com/prescriptive-guidance/latest/rehost-multi-account-architecture-interface-endpoints/)(AWS 권장 가이드)
+ [AWS Application Migration Service - 기술 소개](https://www.aws.training/Details/eLearning?id=71732)(AWS 교육 및 인증 안내서)
+ [AWS Application Migration Service 아키텍처 및 네트워크 아키텍처](https://youtu.be/ao8geVzmmRo)(비디오)

## 추가 정보
<a name="connect-to-application-migration-service-data-and-control-planes-over-a-private-network-additional"></a>

**Linux 서버의 Replication Agent 설치** **문제 해결 ***AWS *

Amazon Linux 서버에서 **gcc** 오류가 발생하는 경우 패키지 리포지토리를 구성하고 다음 명령을 사용하십시오.

```
## sudo yum groupinstall "Development Tools"
```

# AWS CloudFormation 사용자 지정 리소스와 Amazon SNS를 사용하여 Infoblox 객체를 생성
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns"></a>

*Tim Sutton, Amazon Web Services*

## 요약
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-summary"></a>

**알림**: AWS Cloud9 신규 고객은 더 이상를 사용할 수 없습니다. 의 기존 고객은 평소와 같이 서비스를 계속 사용할 AWS Cloud9 수 있습니다. [자세히 알아보기](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)

Infoblox 도메인 이름 시스템(DNS), Dynamic Host Configuration Protocol(DHCP) 및 IP 주소 관리([Infoblox DDI](https://www.infoblox.com/products/ddi/))를 사용하면 복잡한 하이브리드 환경을 중앙 집중화하고 효율적으로 제어할 수 있습니다. Infoblox DDI를 사용하면 동일한 어플라이언스를 사용하여 온프레미스와 Amazon Web Services(AWS) 클라우드의 DNS를 관리하는 것 외에도 하나의 신뢰할 수 있는 IP 주소 관리자(IPAM) 데이터베이스에서 모든 네트워크 자산을 검색하고 기록할 수 있습니다.

이 패턴은 Infoblox WAPI API를 직접 호출하여 AWS CloudFormation 사용자 지정 리소스를 사용하여 Infoblox 객체(예: DNS 레코드 또는 IPAM 객체)를 생성하는 방법을 설명합니다. Infoblox WAPI에 대한 자세한 내용은 Infoblox 설명서의 [WAPI 설명서](https://www.infoblox.com/wp-content/uploads/infoblox-deployment-infoblox-rest-api.pdf)를 참조하세요.

이 패턴의 접근 방식을 사용하면 레코드를 생성하고 네트워크를 프로비저닝하는 수동 프로세스를 제거하는 것 외에도 AWS 및 온프레미스 환경의 DNS 레코드 및 IPAM 구성을 통합적으로 볼 수 있습니다. 다음과 같은 사용 사례에서 이 패턴의 접근 방식을 사용할 수 있습니다.
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 생성한 후 A 레코드 추가 
+ Application Load Balancer를 생성한 후 CNAME 레코드 추가
+ Virtual Private Cloud(VPC) 생성 후 네트워크 객체 추가
+ 다음 네트워크 범위를 제공하고 해당 범위를 사용하여 서브넷을 생성

또한 이 패턴을 확장하여 다른 DNS 레코드 유형 추가 또는 Infoblox vDiscovery 구성과 같은 다른 Infoblox 장치 기능을 사용할 수 있습니다. 

이 패턴은 허브가 AWS 클라우드 또는 온프레미스의 Infoblox 어플라이언스에 연결되어야 하고 AWS Lambda를 사용하여 Infoblox API를 직접 호출하는 허브 앤 스포크 디자인을 사용합니다. 스포크는 AWS Organizations의 동일한 조직 내 동일하거나 다른 계정에 있으며, AWS CloudFormation 사용자 지정 리소스를 사용하여 Lambda 함수를 직접 호출합니다.

## 사전 조건 및 제한 사항
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-prereqs"></a>

**사전 조건 **
+ AWS 클라우드, 온프레미스 또는 둘 다에 설치되고 IPAM 및 DNS 작업을 관리할 수 있는 관리자 사용자로 구성된 기존 Infoblox 어플라이언스 또는 그리드. 자세한 내용은 Infoblox 설명서의 [관리자 계정 정보](https://docs.infoblox.com/display/nios86/About+Admin+Accounts)를 참조하세요. 
+ Infoblox 어플라이언스에 레코드를 추가하려는 기존 DNS 권한 영역. 이에 대한 자세한 내용은 Infoblox 설명서의 [신뢰할 수 있는 영역 구성](https://docs.infoblox.com/display/nios86/Configuring+Authoritative+Zones)을 참조하세요. 
+ AWS Organizations의 활성 AWS 계정 2개. 한 계정은 허브 계정이고 다른 계정은 스포크 계정이어야 합니다.
+ CMK는 동일한 AWS 계정 및 리전에 있어야 합니다. 
+ 허브 계정의 VPC는 Infoblox 어플라이언스에 연결해야 합니다.(예: AWS Transit Gateway 또는 VPC 피어링 사용)
+ [AWS Serverless Application Model(AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html), AWS Cloud9 또는 AWS CloudShell로 로컬에서 설치 및 구성됨.
+ AWS SAM이 포함된 로컬 환경에 다운로드된 `Infoblox-Hub.zip` 및 `ClientTest.yaml` 파일(첨부).

**제한 사항 **
+ AWS CloudFormation 사용자 지정 리소스의 서비스 토큰은 스택이 생성된 리전과 동일한 리전에서 가져와야 합니다. 한 리전에서 Amazon Simple Notification Service(SNS) 주제를 생성하고 다른 리전에서 Lambda 함수를 직접 호출하는 대신 각 리전에서 허브 계정을 사용하는 것이 좋습니다.

**제품 버전**
+ Infoblox API 버전 2.7

## 아키텍처
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-architecture"></a>

다음 다이어그램은 이 워크플로를 보여 줍니다. 

![\[AWS CloudFormation 사용자 지정 리소스와 Amazon SNS를 사용하여 Infoblox 객체를 생성.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/8d609d3f-6f5e-4084-849f-ca191db8055e/images/3594a064-e103-4211-84b7-da67c41ebb15.png)


이 패턴 솔루션의 다음 구성 요소를 보여주는 다이어그램입니다.

1. AWS CloudFormation 사용자 지정 리소스를 사용하면 스택을 생성, 업데이트(사용자 지정 리소스를 변경한 경우) 또는 삭제할 때마다 AWS CloudFormation에서 실행하는 템플릿에서 사용자 지정 프로비저닝 로직을 작성할 수 있습니다. 예를 들어, 스택을 생성할 때 AWS CloudFormation은 EC2 인스턴스에서 실행 중인 애플리케이션이 모니터링하는 SNS 주제에 `create` 요청을 전송할 수 있습니다.

1. AWS CloudFormation 사용자 지정 리소스의 Amazon SNS 알림은 특정 AWS Key Management Service(AWS KMS) 키를 통해 암호화되며, Organizations에 있는 조직의 계정으로만 액세스할 수 있습니다. SNS 주제는 Infoblox WAPI API를 직접 호출하는 Lambda 리소스를 시작합니다.

1. Amazon SNS는 Infoblox의 WAPI URL, 사용자 이름, 암호 AWS Secrets Manager Amazon 리소스 이름(ARN)을 환경 변수로 사용하는 다음과 같은 Lambda 함수를 간접적으로 호출합니다. 
   + `dnsapi.lambda_handler` – AWS CloudFormation 사용자 지정 리소스로부터 `DNSName`, `DNSType`, `DNSValue` 값을 수신하고 이를 사용하여 DNS A 레코드 및 CNAME을 생성합니다.
   + `ipaddr.lambda_handler` – AWS CloudFormation 사용자 지정 리소스로부터 `VPCCIDR`, `Type`, `SubnetPrefix`, `Network Name` 값을 수신하고 이를 사용하여 네트워크 데이터를 Infoblox IPAM 데이터베이스에 추가하거나 새 서브넷을 생성하는 데 사용할 수 있는 다음 가용 네트워크와 함께 사용자 지정 리소스를 제공합니다.
   + `describeprefixes.lambda_handler` – `"com.amazonaws."+Region+".s3"` 필터를 사용하여 필요한 `prefix ID`을(를) 검색하고 `describe_managed_prefix_lists` AWS API를 직접 호출합니다.
**중요**  
이러한 Lambda 함수는 Python으로 작성되었으며 서로 비슷하지만 서로 다른 API를 직접 호출합니다.

1. Infoblox 그리드를 물리적, 가상 또는 클라우드 기반 네트워크 어플라이언스로 배포할 수 있습니다.  온프레미스로 배포하거나 VMware ESXi, Microsoft Hyper-V, Linux KVM 및 Xen을 비롯한 다양한 하이퍼바이저를 사용하여 가상 어플라이언스로 배포할 수 있습니다. Amazon Machine Image(AMI)를 사용하여 AWS 클라우드에 Infoblox 그리드를 배포할 수도 있습니다.

1. 다음 다이어그램은 AWS 클라우드와 온프레미스의 리소스에 DNS와 IPAM을 제공하는 Infoblox 그리드용 하이브리드 솔루션을 보여줍니다.

**기술 스택  **
+ AWS CloudFormation
+ IAM
+ KMS
+ AWS Lambda
+ AWS SAM
+ AWS Secrets Manager
+ Amazon SNS
+ Amazon VPC 

## 도구
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-tools"></a>
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)을 사용하면 AWS 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, 전체 AWS 계정 및 리전에서 수명 주기 전반에 걸쳐 관리할 수 있습니다.
+ [AWS Identity and Access Management(IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)를 사용하면 사용자에 대해 인증 및 권한 부여를 제어함으로써 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있습니다.
+ [AWS Key Management Service(AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 사용하면 암호화 키를 생성하고 제어하여 데이터를 보호할 수 있습니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)는 사용자가 생성하고 중앙에서 관리하는 조직으로 여러 AWS 계정을 통합할 수 있는 계정 관리 서비스입니다.
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)를 사용하면 코드에 하드코딩된 보안 인증 정보(암호 등)를 Secrets Manager에 대한 API 직접 호출로 바꾸어 프로그래밍 방식으로 보안 암호를 검색할 수 있습니다.
+ [AWS Serverless Application Model(AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)은 AWS 클라우드에서 서버리스 애플리케이션을 구축하는 데 사용할 수 있는 오픈소스 프레임워크입니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [Amazon Virtual Private Cloud(VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 사용자의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하며 AWS의 확장 가능한 인프라를 사용한다는 이점이 있습니다.

**코드**

`ClientTest.yaml` 샘플 AWS CloudFormation 템플릿(첨부)을 사용하여 Infoblox 허브를 테스트할 수 있습니다. 다음 테이블의 사용자 지정 리소스를 포함하도록 AWS CloudFormation 템플릿을 사용자 지정할 수 있습니다.


|  | 
| --- |
| Infoblox 스포크 사용자 지정 리소스를 사용하여 A 레코드를 생성 | 반환 값: `infobloxref ` – Infoblox 참조리소스 예제:

```
ARECORDCustomResource:

  Type: "Custom::InfobloxAPI"

  Properties:

    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxDNSFunction

    DNSName: 'arecordtest.company.com'

    DNSType: 'ARecord' 

    DNSValue: '10.0.0.1'
``` | 
| --- |--- |
| Infoblox 스포크 사용자 지정 리소스를 사용하여 CNAME 레코드 생성 | **반환 값**: `infobloxref ` – Infoblox 참조**리소스 예제**:<pre>CNAMECustomResource:<br /><br />  Type: "Custom::InfobloxAPI"<br /><br />  Properties:<br /><br />    ServiceToken: !Sub arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfoblox    <br /><br />    DNSFunction<br /><br />    DNSName: 'cnametest.company.com'<br /><br />    DNSType: 'cname' <br /><br />    DNSValue: 'aws.amazon.com'</pre> | 
| Infoblox 스포크 사용자 지정 리소스를 사용하여 네트워크 개체 생성 | **반환 값**:`infobloxref ` – Infoblox 참조`network` – 네트워크 범위(`VPCCIDR`와 동일)**리소스 예제**:<pre>VPCCustomResource:<br /><br />  Type: 'Custom::InfobloxAPI'<br /><br />  Properties:<br /><br />    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction<br /><br />    VPCCIDR: !Ref VpcCIDR<br /><br />    Type: VPC<br /><br />    NetworkName: My-VPC</pre> | 
| Infoblox 스포크 사용자 지정 리소스를 사용하여 다음의 사용 가능한 서브넷을 검색 | **반환 값**:`infobloxref` – Infoblox 참조`network ` – 서브넷의 네트워크 범위**리소스 예제**:<pre>Subnet1CustomResource:<br /><br />  Type: 'Custom::InfobloxAPI'<br /><br />  DependsOn: VPCCustomResource<br /><br />  Properties:<br /><br />    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction<br /><br />    VPCCIDR: !Ref VpcCIDR<br /><br />    Type: Subnet<br /><br />    SubnetPrefix: !Ref SubnetPrefix<br /><br />NetworkName: My-Subnet</pre> | 

## 에픽
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-epics"></a>

### 허브 계정의 VPC 생성 및 구성
<a name="create-and-configure-the-hub-accountrsquor-s-vpc"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Infoblox 어플라이언스에 연결하여 VPC를 생성합니다. | 허브 계정을 위한 AWS Management Console에 로그인하고 AWS Quick Start의 [AWS 클라우드 퀵 스타트 참조 배포의 Amazon VPC](https://aws-quickstart.github.io/quickstart-aws-vpc/)에 있는 단계에 따라 VPC를 생성합니다.VPC는 Infoblox 어플라이언스에 HTTPS로 연결되어 있어야 하며 이 연결에는 프라이빗 서브넷을 사용하는 것이 좋습니다. | 네트워크 관리자, 시스템 관리자 | 
| (선택 사항)프라이빗 서브넷을 위한 VPC 엔드포인트를 생성하세요. | VPC 엔드포인트는 프라이빗 서브넷에 퍼블릭 서비스에 대한 연결을 제공합니다. 다음 엔드포인트는 필수 엔드포인트입니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html)프라이빗 서브넷용 엔드포인트를 생성하는 방법에 대한 자세한 내용은 Amazon VPC 설명서의 [VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) 섹션을 참조하세요. | 네트워크 관리자, 시스템 관리자 | 

### Infoblox 허브 배포하기
<a name="deploy-the-infoblox-hub"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS SAM 템플릿을 구축하세요. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html) | 개발자, 시스템 관리자 | 
| AWS SAM 템플릿을 배포하세요. | `sam deploy` 명령은 필수 파라미터를 가져와 `samconfig.toml` 파일에 저장하고, AWS CloudFormation 템플릿과 Lambda 함수를 S3 버킷에 저장한 다음, AWS CloudFormation 템플릿을 허브 계정에 배포합니다. 다음 샘플 코드는 AWS SAM 템플릿을 배포하는 방법을 보여줍니다.<pre>$ sam deploy --guided<br /><br />Configuring SAM deploy<br />======================<br />        Looking for config file [samconfig.toml] :  Found<br />        Reading default arguments  :  Success<br />        Setting default arguments for 'sam deploy'<br />        =========================================<br />        Stack Name [Infoblox-Hub]:<br />        AWS Region [eu-west-1]:<br />        Parameter InfobloxUsername:<br />        Parameter InfobloxPassword:<br />        Parameter InfobloxIPAddress [xxx.xxx.xx.xxx]:<br />        Parameter AWSOrganisationID [o-xxxxxxxxx]:<br />        Parameter VPCID [vpc-xxxxxxxxx]:<br />        Parameter VPCCIDR [xxx.xxx.xxx.xxx/16]:<br />        Parameter VPCSubnetID1 [subnet-xxx]:<br />        Parameter VPCSubnetID2 [subnet-xxx]:<br />        Parameter VPCSubnetID3 [subnet-xxx]:<br />        Parameter VPCSubnetID4 []: <br />        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy<br />        Confirm changes before deploy [Y/n]: y<br />        #SAM needs permission to be able to create roles to connect to the resources in your template<br />Allow SAM CLI IAM role creation [Y/n]: n<br />Capabilities [['CAPABILITY_NAMED_IAM']]:<br />        Save arguments to configuration file [Y/n]: y<br />        SAM configuration file [samconfig.toml]:<br />        SAM configuration environment [default]: </pre>Infoblox 로그인 보안 인증 정보가 `--guided` 파일에 저장되지 않으므로 매번 `samconfig.toml` 옵션을 사용해야 합니다. | 개발자, 시스템 관리자 | 

## 관련 리소스
<a name="create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns-resources"></a>
+ [Postman을 사용하여 WAPI 시작하기](https://blogs.infoblox.com/community/getting-started-with-wapis-using-postman/)(Infoblox 블로그)
+ [BYOL 모델을 사용한 AWS용 vNIOS 프로비저닝](https://docs.infoblox.com/display/NAIG/Provisioning+vNIOS+for+AWS+Using+the+BYOL+Model)(Infoblox 설명서)
+ [quickstart-aws-vpc](https://github.com/aws-quickstart/quickstart-aws-vpc) (GitHub 리포지토리)
+ [describe\$1managed\$1prefix\$1lists](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_managed_prefix_lists) (AWS SDK for Python 설명서)

## 첨부
<a name="attachments-8d609d3f-6f5e-4084-849f-ca191db8055e"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/8d609d3f-6f5e-4084-849f-ca191db8055e/attachments/attachment.zip) 파일의 압축을 풉니다.

# Terraform을 AWS 사용하여에서 계층적 다중 리전 IPAM 아키텍처 생성
<a name="multi-region-ipam-architecture"></a>

*Donny Schreiber, Amazon Web Services*

## 요약
<a name="multi-region-ipam-architecture-summary"></a>

*IP 주소 관리(IPAM)*는 네트워크 관리의 중요한 구성 요소이며 조직이 클라우드 인프라를 확장함에 따라 점점 더 복잡해지고 있습니다. 적절한 IPAM이 없으면 조직은 IP 주소 충돌, 주소 공간 낭비, 복잡한 문제 해결로 인해 중단 및 애플리케이션 가동 중지가 발생할 위험이 있습니다. 이 패턴은 HashiCorp Terraform을 사용하여 AWS 엔터프라이즈 환경을 위한 포괄적인 IPAM 솔루션을 구현하는 방법을 보여줍니다. 이를 통해 조직은 [AWS 조직의](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organization-structure) 모든 AWS 계정 에서 중앙 집중식 IP 주소 관리를 용이하게 하는 계층적 다중 리전 IPAM 아키텍처를 생성할 수 있습니다.

이 패턴은 최상위 풀, 리전 풀, 사업부 풀, 환경별 풀 등 정교한 4계층 풀 계층 구조로 [Amazon VPC IP 주소 관리자](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)를 구현하는 데 도움이 됩니다. 이 구조는 적절한 IP 주소 거버넌스를 지원하는 동시에 조직 내 적절한 팀에 IP 관리를 위임할 수 있도록 합니다. 이 솔루션은 AWS Resource Access Manager (AWS RAM)를 사용하여 조직 전체에서 IP 주소 관리자 풀을 원활하게 공유합니다.는 모든 관리형 계정에서 팀이 구축할 수 있는 IPAM 사양을 AWS RAM 분산하고 표준화합니다.

이 패턴을 사용하면 다음을 달성할 수 있습니다.
+  AWS 리전전체, 사업부 및 환경의 IP 주소 할당을 자동화합니다.
+ 프로그래밍 방식 검증을 통해 조직 네트워크 정책을 적용합니다.
+ 비즈니스 요구 사항이 진화함에 따라 네트워크 인프라를 효율적으로 확장합니다.
+ IP 주소 공간의 중앙 집중식 관리를 통해 운영 오버헤드를 줄입니다.
+ 셀프 서비스 CIDR 범위 할당을 통해 클라우드 네이티브 워크로드 배포를 가속화합니다.
+ 정책 기반 제어 및 검증을 통해 주소 충돌을 방지합니다.

## 사전 조건 및 제한 사항
<a name="multi-region-ipam-architecture-prereqs"></a>

**사전 조건 **
+ 조직으로 AWS 계정관리되는 하나 이상의 입니다 AWS Organizations.
+ IP Address Manager 위임된 관리자 역할을 할 네트워크 허브 또는 네트워크 관리 계정입니다.
+ AWS Command Line Interface (AWS CLI), [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)됨.
+ Terraform 버전 1.5.0 이상 [설치](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)
+ AWS Terraform용 공급자, [구성](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)됨.
+  AWS Identity and Access Management (IAM)에 구성된 [IP 주소 관리자](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)[AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/security-iam.html), 및 [Virtual Private Cloud(VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/security-iam.html) 관리할 수 있는 권한.

**제한 사항 **
+ IP 주소 관리자에는 [Service Quotas](https://docs.aws.amazon.com/vpc/latest/ipam/quotas-ipam.html)가 적용됩니다. 풀의 기본 Service Quotas는 범위당 50개입니다. 6개 리전, 2개 사업부 및 4개 환경에서이 배포를 실행하면 67개의 풀이 생성됩니다. 따라서 할당량 증가가 필요할 수 있습니다.
+ 리소스가 할당된 후 IP Address Manager 풀을 수정하거나 삭제하면 종속성 문제가 발생할 수 있습니다. 먼저 할당 및 을 해제해야만 풀을 삭제할 수 있습니다.
+ IP Address Manager에서 [리소스 모니터링](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)은 리소스 변경 사항 반영을 약간 지연시킬 수 있습니다. 이 지연은 약 20분 정도 걸릴 수 있습니다.
+ IP 주소 관리자는 다양한 범위에서 IP 주소 고유성을 자동으로 적용할 수 없습니다.
+ 사용자 지정 태그는 [AWS 태깅 모범 사례](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)를 준수해야 합니다. 예를 들어 각 키는 고유해야 하며 로 시작할 수 없습니다`aws:`.
+ IPAM을 조직 외부 계정과 통합할 때의 고려 사항 및 제한 사항

## 아키텍처
<a name="multi-region-ipam-architecture-architecture"></a>

**대상 아키텍처**

*IP Address Manager 구성 및 풀 계층 구조*

다음 다이어그램은 이 구성의 아키텍처를 보여줍니다. *범위는* IP Address Manager에서 가장 높은 수준의 컨테이너입니다. 각 범위는 단일 네트워크의 IP 공간을 나타냅니다. *풀*은 범위 내의 연속 IP 주소 범위(또는 CIDR 범위) 모음입니다. 풀을 사용하면 라우팅 및 보안 요구 사항에 따라 IP 주소를 구성할 수 있습니다. 이 다이어그램은 최상위 풀, 리전 풀, 사업부 풀 및 환경 풀의 네 가지 계층적 풀 수준을 보여줍니다.

![\[네트워크 계정의 단일 AWS 리전에 있는 프라이빗 범위와 4가지 수준의 풀.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/1e23b2a7-a274-4a19-9097-61d8a31dfbf8.png)


이 솔루션은 IP Address Manager 풀의 명확한 계층 구조를 설정합니다.

1. 최상위 풀에는와 같은 전체 조직 IP 주소 공간이 포함됩니다`10.176.0.0/12`.

1. 리전 풀은와 같은 리전별 할당`10.176.0.0/15`을 위한 것입니다`us-east-1`.

1. 사업부 풀은 각각 내의 도메인별 할당입니다 AWS 리전. 예를 들어 `us-east-1` 리전의 재무 사업부에이 있을 수 있습니다`10.176.0.0/16`.

1. 환경 풀은 다양한 환경에 대한 용도별 할당입니다. 예를 들어 `us-east-1` 리전의 재무 사업부에 프로덕션 환경에 `10.176.0.0/18` 대한가 있을 수 있습니다.

이 배포 토폴로지는 중앙 집중식 제어를 유지하면서 IP Address Manager 리소스를 지리적으로 분산합니다. 기능은 다음과 같습니다.
+ IP 주소 관리자는 단일 프라이머리에 배포됩니다 AWS 리전.
+ 추가 리전은 IP Address Manager가 리소스를 관리할 수 있는 [운영 리전](https://docs.aws.amazon.com/vpc/latest/ipam/mod-ipam-region.html)으로 등록됩니다.
+ 각 운영 리전은 최상위 풀에서 전용 주소 풀을 받습니다.
+ 모든 운영 리전의 리소스는 기본 리전의 IP 주소 관리자를 통해 중앙에서 관리됩니다.
+ 각 리전 풀에는 리소스를 올바르게 할당하는 데 도움이 되도록 해당 리전에 연결된 로캘 속성이 있습니다.

*고급 CIDR 범위 검증*

이 솔루션은 잘못된 구성의 배포를 방지하도록 설계되었습니다. Terraform을 통해 풀을 배포하면 Terraform 계획 단계에서 다음이 검증됩니다.
+ 모든 환경 CIDR 범위가 상위 사업부 CIDR 범위에 포함되는지 검증합니다.
+ 모든 사업부 CIDR 범위가 상위 리전 CIDR 범위에 포함되는지 확인합니다.
+ 모든 리전 CIDR 범위가 최상위 CIDR 범위에 포함되는지 확인합니다.
+ 동일한 계층 수준 내에서 CIDR 범위가 중복되는지 확인합니다.
+ 환경을 각 사업부에 적절하게 매핑하는지 검증합니다.

*CIDR 범위 할당*

다음 다이어그램은 개발자 또는 관리자가 새 VPCs 생성하고 풀 수준에서 IP 주소를 할당하는 방법의 예를 보여줍니다.

![\[네트워크 계정의 단일 AWS 리전에 있는 프라이빗 범위와 4가지 수준의 풀.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/7c3de2e3-e71b-4fc0-abcd-7e88cfab5c87.png)


이 다이어그램은 다음 워크플로를 보여줍니다.

1. 개발자 또는 관리자는 AWS Management Console AWS CLI, 또는 코드형 인프라(IaC)를 통해 `AY3` 환경 풀에서 사용 가능한 다음 CIDR 범위를 요청합니다.

1. IP Address Manager는 해당 풀에서 사용 가능한 다음 CIDR 범위를 `AY3-4` VPC에 할당합니다. 이 CIDR 범위는 더 이상 사용할 수 없습니다.

**자동화 및 규모 조정**

이 솔루션은 다음과 같이 확장성을 위해 설계되었습니다.
+ **리전 확장** - Terraform 구성을 추가 리전 풀 항목으로 확장하여 새 리전을 추가합니다.
+ **사업부 성장** - BU 구성 맵에 새 사업부를 추가하여 지원합니다.
+ **환경 유연성** - 조직의 니즈에 따라 개발 또는 프로덕션과 같은 다양한 환경 유형을 구성합니다.
+ **다중 계정 지원 -** 조직의 모든 계정에서 풀을 공유합니다 AWS RAM.
+ **자동 VPC 프로비저닝 **- VPC 프로비저닝 워크플로와 통합하여 CIDR 범위 할당을 자동화합니다.

계층 구조는 다음과 같이 다양한 위임 및 제어 규모를 허용합니다.
+ 네트워크 관리자는 최상위 풀과 리전 풀을 관리할 수 있습니다.
+ 사업부 IT 팀이 각 풀에 대한 권한을 위임했을 수 있습니다.
+ 애플리케이션 팀은 지정된 환경 풀의 IP 주소를 사용할 수 있습니다.

**참고**  
이 솔루션을 [AWS Control Tower Account Factory for Terraform(AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)과 통합할 수도 있습니다. 자세한 내용은 이 패턴의 [추가 정보](#multi-region-ipam-architecture-additional) 섹션에 있는 *프린터 플릿 상태 확인*을 참조하세요.

## 도구
<a name="multi-region-ipam-architecture-tools"></a>

**AWS 서비스**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)를 사용하면 AWS 리소스 및에서 실행되는 애플리케이션의 지표를 실시간으로 모니터링할 AWS 수 있습니다.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)는 여러을 생성하여 중앙에서 관리하는 조직 AWS 계정 으로 통합하는 데 도움이 되는 계정 관리 서비스입니다.
+ [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하면에서 리소스를 안전하게 공유 AWS 계정 하여 운영 오버헤드를 줄이고 가시성과 감사 가능성을 제공할 수 있습니다.
+ [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다. [IP 주소 관리자는](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) Amazon VPC의 기능입니다. 워크로드의 IP 주소를 계획, 추적 및 모니터링하는 데 도움이 됩니다 AWS .

**기타 도구**
+ [HashiCorp Terraform](https://www.terraform.io/docs)은 코드를 사용하여 클라우드 인프라 및 리소스를 프로비저닝하고 관리하는 데 도움이 되는 코드형 인프라(IaC) 도구입니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub의 리포지토리에 [있는 계층적 IPAM을 위한 샘플 Terraform 구현 AWS](https://github.com/aws-samples/sample-amazon-vpc-ipam-terraform)** **에서 사용할 수 있습니다. 리포지토리 구조에는 다음이 포함됩니다.
+ **루트 모듈** - 배포 오케스트레이션 및 입력 변수.
+ **IPAM 모듈** -이 패턴에 설명된 아키텍처의 핵심 구현입니다.
+ **태그 모듈 **- 모든 리소스에 대한 표준화된 태깅 방식입니다.

## 모범 사례
<a name="multi-region-ipam-architecture-best-practices"></a>

네트워크 계획의 다음 모범 사례를 고려하세요.
+ **먼저 계획** - 배포 전에 IP 주소 공간을 철저히 계획합니다. 자세한 내용은 Amazon VPC IPAM 사용 설명서의 IP 주소 프로비저닝 계획을 참조하세요.
+ **CIDR 범위가 겹치지 않도록 **- 각 수준의 CIDR 범위가 겹치지 않도록 합니다.
+ **버퍼 공간 예약** - 성장을 수용하는 데 즉시 필요한 것보다 더 큰 CIDR 범위를 항상 할당합니다.
+ **문서 IP 주소 할당** - IP 주소 할당 전략에 대한 문서를 유지 관리합니다.

다음 모범 사례를 고려하세요.
+ **비프로덕션으로 시작 -** 먼저 비프로덕션 환경에 배포합니다.
+ **Terraform 상태 관리 사용** - 원격 상태 스토리지 및 잠금을 구현합니다. 자세한 내용은 Terraform 설명서의 [상태 저장 및 잠금](https://developer.hashicorp.com/terraform/language/state/backends)을 참조하세요.
+ **버전 관리 구현** - 모든 Terraform 코드를 버전 관리합니다.
+ **CI/CD 통합 구현** - 반복 가능한 배포를 위해 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 사용합니다.

다음 모범 사례를 고려하세요.
+ **자동 가져오기 활성화 -** 기존 리소스를 자동으로 검색하고 가져오도록 IP 주소 관리자 풀을 구성합니다. [IPAM 풀 편집](https://docs.aws.amazon.com/vpc/latest/ipam/mod-pool-ipam.html)의 지침에 따라 자동 가져오기를 켭니다.
+ **IP 주소 사용률 모니터링** - IP 주소 사용률 임계값에 대한 경보를 설정합니다. 자세한 내용은 [Amazon CloudWatch를 사용한 모니터링](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html)을 참조하세요.
+ **정기 감사** - IP 주소 사용 및 규정 준수를 정기적으로 감사합니다. 자세한 내용은 [IPAM에서 IP 주소 사용량 추적](https://docs.aws.amazon.com/vpc/latest/ipam/tracking-ip-addresses-ipam.html)을 참조하세요.
+ **미사용 할당 정리** - 리소스가 폐기될 때 IP 주소 할당을 해제합니다. 자세한 내용은 [풀에서 CIDRs](https://docs.aws.amazon.com/vpc/latest/ipam/depro-pool-cidr-ipam.html).

다음 모범 사례를 고려하세요.
+ **최소 권한 구현 **- 최소 필수 권한이 있는 IAM 역할을 사용합니다. 자세한 내용은 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 및 [IPAM의 ID 및 액세스 관리](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)를 참조하세요.
+ **서비스 제어 정책 사용** - 서비스 제어 정책(SCPs 구현하여 조직에서 IP Address Manager 사용을 적용합니다. 자세한 내용은 [ SCPs](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html).
+ **리소스 공유 제어** -에서 IP Address Manager 리소스 공유의 범위를 신중하게 관리합니다 AWS RAM. 자세한 내용은 [를 사용하여 IPAM 풀 공유 AWS RAM](https://docs.aws.amazon.com/vpc/latest/ipam/share-pool-ipam.html)를 참조하세요.
+ **태깅 적용** - IP 주소 관리자와 관련된 모든 리소스에 필수 태깅을 구현합니다. 자세한 내용은 [추가 정보](#multi-region-ipam-architecture-additional) 섹션의 *Amazon SNS*를 참조하세요.

## 에픽
<a name="multi-region-ipam-architecture-epics"></a>

### IP Address Manager에 대한 위임된 관리자 계정 설정
<a name="set-up-a-delegated-administrator-account-for-ip-address-manager"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  AWS Organizations 기능을 활성화합니다. | 에 모든 기능이 활성화 AWS Organizations 되어 있는지 확인합니다. 지침은 AWS Organizations 설명서의 [를 사용하여 조직의 모든 기능 활성화 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)를 참조하세요. | 관리자 | 
| 에서 리소스 공유를 활성화합니다 AWS RAM. | 를 사용하여 다음 명령을 AWS CLI입력하여 조직의 AWS RAM 리소스 공유를 활성화합니다.<pre>aws ram enable-sharing-with-aws-organization</pre>자세한 내용은 AWS RAM 설명서의 [내에서 리소스 공유 활성화 AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)를 참조하세요. | 관리자 | 
| IP 주소 관리자의 관리자를 지정합니다. | 조직의 관리 계정에서를 사용하여 다음 명령을 AWS CLI입력합니다. 여기서 `123456789012`는 IP Address Manager를 관리할 계정의 ID입니다.<pre>aws ec2 enable-ipam-organization-admin-account \<br />    --delegated-admin-account-id 123456789012</pre>일반적으로 네트워크 또는 네트워크 허브 계정은 IP 주소 관리자의 위임된 관리자로 사용됩니다.자세한 내용은 [IP 주소 관리자 설명서의 AWS Organization의 계정과 IPAM 통합](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html)을 참조하세요. | 관리자 | 

### 인프라 배포
<a name="deploy-the-infrastructure"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 네트워크 아키텍처를 정의합니다. | 리전, 사업부 및 환경의 CIDR 범위를 포함하여 네트워크 아키텍처를 정의하고 문서화합니다. 자세한 내용은 IP Address Manager 설명서의 [IP 주소 프로비저닝 계획](https://docs.aws.amazon.com/vpc/latest/ipam/planning-ipam.html)을 참조하세요. | 네트워크 엔지니어 | 
| 리포지토리를 복제합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | DevOps 엔지니어 | 
| 변수를 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | 네트워크 엔지니어, Terraform | 
| IP Address Manager 리소스를 배포합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | Terraform | 
| 배포를 검증합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | 일반 AWS, 네트워크 엔지니어 | 

### VPCs 생성 및 모니터링 설정
<a name="create-vpcs-and-set-up-monitoring"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC를 생성합니다. | Amazon VPC 사용 설명서의 VPC 생성 단계를 따르세요. VPC에 대한 CIDR 범위를 선택하는 단계에 도달하면 리전, 사업부 및 환경 풀 중 하나에서 사용 가능한 다음를 할당합니다. | 일반 AWS, 네트워크 관리자, 네트워크 엔지니어 | 
| CIDR 범위 할당을 검증합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | 일반 AWS, 네트워크 관리자, 네트워크 엔지니어 | 
| IP 주소 관리자를 모니터링합니다. | IP Address Manager 리소스 할당과 관련된 모니터링 및 경보를 구성합니다. 자세한 내용과 지침은 [IP Address Manager 설명서의 Amazon CloudWatch로 IPAM 모니터링](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html) 및 [리소스별 CIDR 사용량 모니터링](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)을 참조하세요. | 일반 AWS | 
| IP 주소 관리자 사용을 적용합니다. | 조직의 구성원 AWS Organizations 이 VPC를 생성할 때 IP 주소 관리자를 사용하도록 요구하는에서 서비스 제어 정책(SCP)을 생성합니다. 지침은 [IP 주소 관리자 설명서의 SCPs](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html). | 일반 AWS, AWS 관리자 | 

## 문제 해결
<a name="multi-region-ipam-architecture-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| IP Address Manager 리소스를 찾을 수 없는 상태에서 Terraform 실패 | IP Address Manager 관리자 계정이 제대로 위임되었고 AWS 공급자가 해당 계정에 인증되었는지 확인합니다. | 
| CIDR 범위 할당 실패 | 요청된 CIDR 범위가 IP Address Manager 풀의 사용 가능한 범위 내에 있고 기존 할당과 겹치지 않는지 확인합니다. | 
| AWS RAM 문제 공유 |  AWS 조직에 리소스 공유가 활성화되어 있는지 확인합니다. 올바른 보안 주체인 조직 Amazon 리소스 이름(ARN)이 AWS RAM 공유에 사용되는지 확인합니다. | 
| 풀 계층 구조 검증 오류 | 하위 풀 CIDR 범위가 상위 풀 CIDR 범위 내에 올바르게 포함되어 있고 형제 풀과 겹치지 않는지 확인합니다. | 
| IP 주소 관리자 할당량 한도 초과 | IP Address Manager 풀에 대한 할당량 증가를 요청합니다. 자세한 내용은* Service Quotas 사용 설명서*의 [할당량 증가 요청](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)을 참조하세요. | 

## 관련 리소스
<a name="multi-region-ipam-architecture-resources"></a>

**AWS 서비스 설명서**
+ [Amazon VPC IP 주소 관리자 설명서](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
+ [AWS Resource Access Manager 설명서](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)
+ [AWS Organizations 설명서](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)

**AWS 블로그 게시물**
+ [Amazon VPCs IP 주소 관리자를 사용하여 VPC 및 리전 간 IP 풀 관리](https://aws.amazon.com/blogs/networking-and-content-delivery/managing-ip-pools-across-vpcs-and-regions-using-amazon-vpc-ip-address-manager/)
+ [Amazon VPC IP 주소 관리자를 사용한 대규모 네트워크 주소 관리 및 감사](https://aws.amazon.com/blogs/aws/network-address-management-and-auditing-at-scale-with-amazon-vpc-ip-address-manager/)

**자습서 및 동영상**
+ [AWS re:Invent 2022: Amazon VPC 설계 및 IPAM(NET310) 모범 사례](https://www.youtube.com/watch?v=XrEHsy_8RYs)
+ [AWS re:Invent 2022: 고급 VPC 설계 및 새로운 기능(NET401)](https://www.youtube.com/watch?v=tbXTVpwx87o)

## 추가 정보
<a name="multi-region-ipam-architecture-additional"></a>

 와 통합

이 솔루션을 AWS Control Tower Account Factory for Terraform(AFT)과 통합하여 새로 프로비저닝된 계정이 적절한 네트워크 구성을 자동으로 수신하도록 할 수 있습니다. 네트워크 허브 계정에이 IPAM 솔루션을 배포하면 VPCs.

다음 코드 샘플은 AWS Systems Manager Parameter Store를 사용하여 계정 사용자 지정에서 AFT 통합을 보여줍니다.

```
# Get the IP Address Manager pool ID from Parameter Store
data "aws_ssm_parameter" "dev_ipam_pool_id" {
  name = "/org/network/ipam/finance/dev/pool-id"
}

# Create a VPC using the IP Address Manager pool
resource "aws_vpc" "this" {
  ipv4_ipam_pool_id   = data.aws_ssm_parameter.dev_ipam_pool_id.value
  ipv4_netmask_length = 24
  
  tags = {
    Name = "aft-account-vpc"
  }
}
```

**태그 지정 전략**

이 솔루션은 포괄적인 태깅 전략을 구현하여 리소스 관리를 용이하게 합니다. 다음 코드 샘플은 사용 방법을 보여줍니다.

```
# Example tag configuration
module "tags" {
  source = "./modules/tags"
  
  # Required tags
  product_name  = "enterprise-network"
  feature_name  = "ipam"
  org_id        = "finance"
  business_unit = "network-operations"
  owner         = "network-team"
  environment   = "prod"
  repo          = "https://github.com/myorg/ipam-terraform"
  branch        = "main"
  cost_center   = "123456"
  dr_tier       = "tier1"
  
  # Optional tags
  optional_tags = {
    "project"    = "network-modernization"
    "stack_role" = "infrastructure"
  }
}
```

이러한 태그는 모든 IP Address Manager 리소스에 자동으로 적용됩니다. 이를 통해 일관된 거버넌스, 비용 할당 및 리소스 관리를 용이하게 합니다.

# 에 대한 Amazon CloudWatch 알림 사용자 지정 AWS Network Firewall
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall"></a>

*Jason Owens, Amazon Web Services*

## 요약
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-summary"></a>

이 패턴은에서 생성되는 Amazon CloudWatch 알림을 사용자 지정하는 데 도움이 됩니다 AWS Network Firewall. 사전 정의된 규칙을 사용하거나 알림의 메시지, 메타데이터 및 심각도를 결정하는 사용자 지정 규칙을 생성할 수 있습니다. 그런 다음 이러한 경고에 따라 조치를 취하거나 Amazon EventBridge와 같은 다른 Amazon 서비스를 이용해 응답을 자동화할 수 있습니다.

이 패턴에서는 Suricata와 호환되는 방화벽 규칙을 생성합니다. [Suricata](https://suricata.io/)는 오픈 소스 위협 탐지 엔진입니다. 먼저 간단한 규칙을 만든 다음 이를 테스트하여 CloudWatch 알림이 생성되고 로그되는지 확인합니다. 규칙을 성공적으로 테스트한 후에는 규칙을 수정하여 사용자 지정 메시지, 메타데이터 및 심각도를 정의한 다음 다시 한 번 테스트하여 업데이트를 확인합니다.

## 사전 조건 및 제한 사항
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-prereqs"></a>

**사전 조건 **
+ 활성. AWS 계정
+ AWS Command Line Interface Linux, macOS 또는 Windows 워크스테이션에 설치 및 구성된 (AWS CLI) 자세한 내용은 [최신 버전의 AWS CLI설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
+ AWS Network Firewall CloudWatch Logs를 사용하도록 설치 및 구성되었습니다. 자세한 내용은 [네트워크 트래픽 로깅을 참조하세요 AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html).
+ Network Firewall을 통해 보호되는 Virtual Private Cloud(VPC)의 프라이빗 서브넷에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스입니다.

**제품 버전**
+ 버전 1의 경우 1.18.180 이상을 AWS CLI사용합니다. 버전 2의 경우 2.1.2 이상을 AWS CLI사용합니다.
+ Suricata 버전 5.0.2의 classification.config 파일입니다. 이 구성 파일의 사본은 [추가 정보](#customize-amazon-cloudwatch-alerts-for-aws-network-firewall-additional) 섹션을 참조하세요.

## 아키텍처
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-architecture"></a>

![\[EC2 인스턴스 요청은 Network Firewall에서 알림을 생성하여 CloudWatch로 전달\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/da6087a9-e942-4cfe-85e3-3b08de6f3ba5/images/778d85cd-bc87-4ed0-a161-d35eb5daa694.png)


다이어그램은 다음 아키텍처를 보여줍니다.

1. 프라이빗 서브넷의 Amazon EC2 인스턴스는 [curl](https://curl.se/) 또는 [Wget](https://www.gnu.org/software/wget/)을 사용하여 요청을 보냅니다.

1. Network Firewall은 트래픽을 처리하고 알림을 생성합니다.

1. Network Firewall은 로그된 알림을 CloudWatch Logs에 전송합니다.

## 도구
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-tools"></a>

**AWS 서비스**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)를 사용하면 AWS 리소스 및에서 실행되는 애플리케이션의 지표를 실시간으로 모니터링할 AWS 수 있습니다.
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)를 사용하면 모든 시스템, 애플리케이션 및의 로그를 중앙 집중화 AWS 서비스 하여 모니터링하고 안전하게 보관할 수 있습니다.
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)는 명령줄 셸의 명령을 AWS 서비스 통해와 상호 작용하는 데 도움이 되는 오픈 소스 도구입니다.
+ [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html)은 AWS 클라우드에 있는 Virtual Private Cloud(VPC)를 위한 상태 저장형, 관리형, 네트워크 방화벽 및 침입 탐지 및 방지 서비스입니다. 

**기타 도구**
+ [curl](https://curl.se/)은 오픈 소스 명령줄 도구 및 라이브러리입니다.
+ [GNU Wget](https://www.gnu.org/software/wget/)은 무료 명령줄 도구입니다.

## 에픽
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-epics"></a>

### 방화벽 규칙 및 규칙 그룹 생성
<a name="create-the-firewall-rules-and-rule-group"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 규칙을 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자, 네트워크 관리자 | 
| 규칙 그룹을 생성합니다. | 에 다음 명령을 AWS CLI입력합니다. 이렇게 하면 규칙 그룹이 생성됩니다.<pre>❯ aws network-firewall create-rule-group \<br />        --rule-group-name custom --type STATEFUL \<br />        --capacity 10 --rules file://custom.rules \<br />        --tags Key=environment,Value=development</pre>다음은 예시 출력입니다. 이후 단계에서 필요할 `RuleGroupArn`을 메모합니다.<pre>{<br />    "UpdateToken": "4f998d72-973c-490a-bed2-fc3460547e23",<br />    "RuleGroupResponse": {<br />        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",<br />        "RuleGroupName": "custom",<br />        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",<br />        "Type": "STATEFUL",<br />        "Capacity": 10,<br />        "RuleGroupStatus": "ACTIVE",<br />        "Tags": [<br />            {<br />                "Key": "environment",<br />                "Value": "development"<br />            }<br />        ]<br />    }</pre> | AWS 시스템 관리자 | 

### 방화벽 정책 업데이트
<a name="update-the-firewall-policy"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 방화벽 정책의 ARN 획득. | 에 다음 명령을 AWS CLI입력합니다. 이는 방화벽 정책의 Amazon 리소스 이름(ARN)을 반환합니다. 나중에 이 패턴에서 사용할 수 있도록 ARN을 기록합니다.<pre>❯ aws network-firewall describe-firewall \<br />    --firewall-name aws-network-firewall-anfw \<br />    --query 'Firewall.FirewallPolicyArn'</pre>다음은 이 명령을 통해 반환된 ARN 예시입니다.<pre>"arn:aws:network-firewall:us-east-2:1234567890:firewall-policy/firewall-policy-anfw"</pre> | AWS 시스템 관리자 | 
| 방화벽 정책을 업데이트합니다. | 텍스트 편집기에서 다음 코드를 붙여 넣습니다. `<RuleGroupArn>`을 이전 에픽에서 기록한 값으로 바꾸세요. 파일을 `firewall-policy-anfw.json`(으)로 저장합니다.<pre>{<br />    "StatelessDefaultActions": [<br />        "aws:forward_to_sfe"<br />    ],<br />    "StatelessFragmentDefaultActions": [<br />        "aws:forward_to_sfe"<br />    ],<br />    "StatefulRuleGroupReferences": [<br />        {<br />            "ResourceArn": "<RuleGroupArn>"<br />        }<br />    ]<br />}</pre> AWS CLI에서 다음 명령을 입력합니다. 이 명령을 사용해 새 규칙을 추가하려면 [업데이트 토큰](https://docs.aws.amazon.com/cli/latest/reference/network-firewall/update-firewall-policy.html)이 필요합니다. 토큰은 정책을 마지막으로 검색한 이후 정책이 변경되지 않았음을 확인하는 데 사용됩니다.<pre>UPDATETOKEN=(`aws network-firewall describe-firewall-policy \<br />              --firewall-policy-name firewall-policy-anfw \<br />              --output text --query UpdateToken`)<br /> <br /> aws network-firewall update-firewall-policy \<br /> --update-token $UPDATETOKEN \<br /> --firewall-policy-name firewall-policy-anfw \<br /> --firewall-policy file://firewall-policy-anfw.json</pre> | AWS 시스템 관리자 | 
| 정책 업데이트를 확인합니다. | (선택 사항) 규칙이 추가되었는지 확인하고 정책 형식을 보려면 AWS CLI에서 다음 명령을 입력합니다.<pre>❯ aws network-firewall describe-firewall-policy \<br />  --firewall-policy-name firewall-policy-anfw \<br />  --query FirewallPolicy</pre>다음은 예시 출력입니다.<pre>{<br />    "StatelessDefaultActions": [<br />        "aws:forward_to_sfe"<br />    ],<br />    "StatelessFragmentDefaultActions": [<br />        "aws:forward_to_sfe"<br />    ],<br />    "StatefulRuleGroupReferences": [<br />        {<br />            "ResourceArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom"<br />        }<br />    ]<br />}</pre> | AWS 시스템 관리자 | 

### 테스트 경고 기능
<a name="test-alert-functionality"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 테스트용 경고 생성. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자 | 
| 경고가 로그되었는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자 | 

### 방화벽 규칙 및 규칙 그룹 업데이트
<a name="update-the-firewall-rules-and-rule-group"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 방화벽 규칙 업데이트. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자 | 
| 규칙 그룹을 업데이트합니다. | 에서 다음 명령을 AWS CLI실행합니다. 방화벽 정책의 ARN을 사용하세요. 이 명령은 업데이트 토큰을 얻고 규칙 그룹을 규칙 변경으로 업데이트합니다.<pre>❯ UPDATETOKEN=(`aws network-firewall \<br />                describe-rule-group \<br />--rule-group-arn arn:aws:network-firewall:us-east-2:123457890:stateful-rulegroup/custom \<br />--output text --query UpdateToken`)</pre><pre> ❯ aws network-firewall update-rule-group \<br />  --rule-group-arn arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom \<br />--rules file://custom.rules \<br />--update-token $UPDATETOKEN</pre>다음은 예시 출력입니다.<pre>{<br />    "UpdateToken": "7536939f-6a1d-414c-96d1-bb28110996ed",<br />    "RuleGroupResponse": {<br />        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",<br />        "RuleGroupName": "custom",<br />        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",<br />        "Type": "STATEFUL",<br />        "Capacity": 10,<br />        "RuleGroupStatus": "ACTIVE",<br />        "Tags": [<br />            {<br />                "Key": "environment",<br />                "Value": "development"<br />            }<br />        ]<br />    }<br />}</pre> | AWS 시스템 관리자 | 

### 업데이트된 경고 기능 테스트
<a name="test-the-updated-alert-functionality"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 테스트용 경고를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자 | 
| 경고가 변경되었는지 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS 시스템 관리자 | 

## 관련 리소스
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-resources"></a>

**참조**
+ [에서 Slack 채널 AWS Network Firewall 로 알림 전송](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/send-alerts-from-aws-network-firewall-to-a-slack-channel.html)(AWS 권고 가이드)
+ [Suricata를 AWS 사용하여에서 위협 방지 확장](https://aws.amazon.com/blogs/opensource/scaling-threat-prevention-on-aws-with-suricata/)(AWS 블로그 게시물)
+ [용 배포 모델 AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)(AWS 블로그 게시물)
+ [Suricata 메타 키웍스](https://suricata.readthedocs.io/en/suricata-6.0.1/rules/meta.html)(Suricata 설명서)

**자습서 및 동영상**
+ [AWS Network Firewall 워크숍](https://networkfirewall.workshop.aws/)

## 추가 정보
<a name="customize-amazon-cloudwatch-alerts-for-aws-network-firewall-additional"></a>

다음은 Suricata 5.0.2의 분류 구성 파일입니다. 이러한 분류는 방화벽 규칙을 만들 때 사용됩니다.

```
# config classification:shortname,short description,priority
 
config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1
 
# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: inappropriate-content,Inappropriate Content was Detected,1
config classification: policy-violation,Potential Corporate Privacy Violation,1
config classification: default-login-attempt,Attempt to login by a default username and password,2
 
# Update
config classification: targeted-activity,Targeted Malicious Activity was Detected,1
config classification: exploit-kit,Exploit Kit Activity Detected,1
config classification: external-ip-check,Device Retrieving External IP Address Detected,2
config classification: domain-c2,Domain Observed Used for C2 Detected,1
config classification: pup-activity,Possibly Unwanted Program Detected,2
config classification: credential-theft,Successful Credential Theft Detected,1
config classification: social-engineering,Possible Social Engineering Attempted,2
config classification: coin-mining,Crypto Currency Mining Activity Detected,2
config classification: command-and-control,Malware Command and Control Activity Detected,1
```

# Terraform을 사용하여 AWS Wavelength 영역에 리소스 배포
<a name="deploy-resources-wavelength-zone-using-terraform"></a>

*Zahoor Chaudhrey 및 Luca Iannario, Amazon Web Services*

## 요약
<a name="deploy-resources-wavelength-zone-using-terraform-summary"></a>

[AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html)를 사용하면 다중 액세스 엣지 컴퓨팅(MEC) 애플리케이션에 최적화된 인프라를 구축할 수 있습니다. *Wavelength Zone은* 통신 서비스 공급자(CSP)의 5G 네트워크 내에 AWS 컴퓨팅 및 스토리지 서비스를 포함하는 AWS 인프라 배포입니다. 5G 디바이스의 애플리케이션 트래픽은 통신 네트워크를 벗어나지 않고 Wavelength Zones에서 실행되는 애플리케이션 서버에 도달합니다. 다음은 Wavelength를 통한 네트워크 연결을 용이하게 합니다.
+ **Virtual Private Cloud(VPCs)** -의 VPCs Wavelength Zone을 포함한 여러 가용 영역에 걸쳐 확장될 AWS 계정 수 있습니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 관련 서비스는 리전 VPC의 일부로 표시됩니다. VPCs [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)에서 생성 및 관리됩니다.
+ **통신 사업자 게이트웨이** - 통신 사업자 게이트웨이를 사용하면 Wavelength Zone의 서브넷에서 CSP 네트워크, 인터넷 또는 CSP 네트워크를 AWS 리전 통해 로 연결할 수 있습니다. 통신 사업자 게이트웨이는 두 가지 용도로 사용됩니다. 즉, 특정 위치에 있는 통신 사업자 네트워크에서의 인바운드 트래픽을 허용하고, 통신 사업자 네트워크 및 인터넷으로의 아웃바운드 트래픽을 허용합니다.

이 패턴 및 관련 Terraform 코드는 Wavelength Zone에서 Amazon EC2 인스턴스, Amazon Elastic Block Store(Amazon EBS) 볼륨, VPCs, 서브넷 및 통신 사업자 게이트웨이와 같은 리소스를 시작하는 데 도움이 됩니다.

## 사전 조건 및 제한 사항
<a name="deploy-resources-wavelength-zone-using-terraform-prereqs"></a>

**사전 조건 **
+ 활성 AWS 계정
+  통합 개발 환경(IDE)
+ 대상 Wavelength Zone에 [옵트인](https://docs.aws.amazon.com/wavelength/latest/developerguide/get-started-wavelength.html#enable-zone-group) 
+ AWS Command Line Interface (AWS CLI), [설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)됨
+ Terraform 버전 1.8.4 이상, [설치](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)됨(Terraform 설명서)
+ Terraform AWS Provider 버전 5.32.1 이상, [구성](https://hashicorp.github.io/terraform-provider-aws/)됨(Terraform 설명서)
+ Git, [설치](https://github.com/git-guides/install-git)됨(GitHub)
+ Amazon VPC, Wavelength 및 Amazon EC2 리소스를 생성할 [수 있는 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 

**제한 사항 **

모든가 Wavelength Zone을 AWS 리전 지원하는 것은 아닙니다. 자세한 내용은 [Wavelength 설명서의 사용 가능한 Wavelength Zones](https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html)를 참조하세요.

## 아키텍처
<a name="deploy-resources-wavelength-zone-using-terraform-architecture"></a>

다음 다이어그램은 Wavelength Zone에서 서브넷과 AWS 리소스를 생성하는 방법을 보여줍니다. Wavelength Zone에 서브넷이 포함된 VPCs는 통신 사업자 게이트웨이에 연결할 수 있습니다. 통신 사업자 게이트웨이를 사용하면 다음 리소스에 연결할 수 있습니다.
+ 통신 사업자의 네트워크에 있는 4G/LTE 및 5G 디바이스.
+ 일부 Wavelength Zone 파트너의 무선 액세스가 수정되었습니다. 자세한 내용은 [다중 액세스를 참조하세요 AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/multi-access.html).
+ 퍼블릭 인터넷 리소스로의 아웃바운드 트래픽.

![\[통신 사업자 게이트웨이는 Wavelength Zone의 AWS 리소스를 CSP 네트워크에 연결합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/8c507de1-208c-4563-bb58-52388ab2fa6d/images/a4cc0699-0cbc-4f15-ab14-3ae569ced7f4.png)


## 도구
<a name="deploy-resources-wavelength-zone-using-terraform-tools"></a>

**AWS 서비스**
+ [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다.
+ [AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html)는 AWS 클라우드 인프라를 통신 공급자의 5G 네트워크로 확장합니다. 를 사용하면 개발자는 모바일 디바이스 및 최종 사용자에게 매우 짧은 지연 시간을 제공하는 애플리케이션을 빌드할 수 있습니다.

**기타 도구**
+ [Terraform](https://www.terraform.io/)은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [Creating AWS Wavelength Infrastructure using Terraform](https://github.com/aws-samples/terraform-wavelength-infrastructure) 리포지토리에서 사용할 수 있습니다. Terraform 코드는 다음 인프라와 리소스를 배포합니다.
+ VPC
+ Wavelength Zone
+ Wavelength Zone에서 서브넷을 생성합니다.
+ A Wavelength Zone 통신 사업자 게이트웨이로 라우팅
+ Wavelength Zone의 Amazon EC2 인스턴스

## 모범 사례
<a name="deploy-resources-wavelength-zone-using-terraform-best-practices"></a>
+ 배포하기 전에 최신 버전의 Terraform 및를 사용하고 있는지 확인합니다 AWS CLI.
+ 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 사용하여 IaC를 배포합니다. 자세한 내용은 AWS 블로그[의 AWS CI/CD 파이프라인에서 Terraform 상태 파일을 관리하는 모범 사례를](https://aws.amazon.com/blogs/devops/best-practices-for-managing-terraform-state-files-in-aws-ci-cd-pipeline/) 참조하세요.

## 에픽
<a name="deploy-resources-wavelength-zone-using-terraform-epics"></a>

### 인프라 프로비저닝
<a name="provision-the-infrastructure"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 리포지토리를 복제합니다. | 다음 명령을 입력하여 [Terraform을 사용하여 AWS Wavelength 인프라 생성](https://github.com/aws-samples/terraform-wavelength-infrastructure) 리포지토리를 환경에 복제합니다.`git clone git@github.com:aws-samples/terraform-wavelength-infrastructure.git` | DevOps 엔지니어 | 
| 변수를 업데이트합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps 엔지니어, Terraform | 
| 구성을 초기화합니다. | 다음 명령을 입력하여 작업 디렉터리를 초기화합니다.<pre>terraform init</pre> | DevOps 엔지니어, Terraform | 
| Terraform 계획을 미리 보기합니다. | 다음 명령을 입력하여 대상 상태를 AWS 환경의 현재 상태와 비교합니다. 이 명령은 구성할 리소스의 미리 보기를 생성합니다.<pre>terraform plan</pre> | DevOps 엔지니어, Terraform | 
| 배포하고 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps 엔지니어, Terraform | 

### 확인 및 정리
<a name="validate-and-clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인프라 배포를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | AWS DevOps, DevOps 엔지니어 | 
| (선택 사항) 인프라를 정리합니다. | Terraform에서 프로비저닝한 리소스를 모두 삭제해야 하는 경우 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps 엔지니어, Terraform | 

## 문제 해결
<a name="deploy-resources-wavelength-zone-using-terraform-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| 의 Amazon EC2 인스턴스에 대한 연결 AWS 리전. | [Linux 인스턴스 연결 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) 또는 [Windows 인스턴스 연결 문제를 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/troubleshooting-windows-instances.html). | 
| Wavelength Zone의 Amazon EC2 인스턴스에 대한 연결. | [Wavelength Zone에서 시작된 내 EC2 인스턴스에 대한 SSH 또는 RDP 연결 문제 해결을 참조하세요](https://repost.aws/knowledge-center/ec2-wavelength-zone-connection-errors). | 
| Wavelength Zone의 용량입니다. | [Wavelength Zone에 대한 할당량 및 고려 사항을 참조하세요](https://docs.aws.amazon.com/wavelength/latest/developerguide/wavelength-quotas.html). | 
| 통신 사업자 네트워크에서 로의 모바일 또는 통신 사업자 연결 AWS 리전. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | 

## 관련 리소스
<a name="deploy-resources-wavelength-zone-using-terraform-resources"></a>
+ [란 무엇입니까 AWS Wavelength?](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html)
+ [AWS Wavelength 작동 방식](https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html)
+ [의 복원력 AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/disaster-recovery-resiliency.html)

# DNS 레코드를 Amazon Route 53 프라이빗 호스팅 영역으로 대량 마이그레이션합니다.
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone"></a>

*Ram Kandaswamy, Amazon Web Services*

## 요약
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-summary"></a>

네트워크 엔지니어와 클라우드 관리자는 Amazon Route 53의 프라이빗 호스팅 영역에 도메인 이름 시스템(DNS) 레코드를 추가할 수 있는 효율적이고 간단한 방법이 필요합니다. 수동 접근 방식을 사용하여 Microsoft Excel 워크시트의 항목을 Route 53 콘솔의 적절한 위치로 복사하는 것은 번거롭고 오류가 발생하기 쉽습니다. 이 패턴은 여러 레코드를 추가하는 데 필요한 시간과 노력을 줄이는 자동화된 접근 방식을 설명합니다. 또한 여러 호스팅 영역을 생성할 수 있는 반복 가능한 일련의 단계를 제공합니다.

이 패턴은 Amazon Simple Storage Service(Amazon S3)를 사용하여 레코드를 저장합니다. 데이터를 효율적으로 처리하기 위해 패턴은 단순하고 Python 사전 (`dict` 데이터 유형) 을 지원하는 기능 때문에 JSON 형식을 사용합니다.

**참고**  
시스템에서 영역 파일을 생성할 수 있다면 [Route 53 가져오기](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html) 기능을 대신 사용해 보십시오.

## 사전 조건 및 제한 사항
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-prereqs"></a>

**사전 조건 **
+ 프라이빗 호스팅 영역 레코드가 포함된 Excel 워크시트
+ A 레코드, NAPTR (이름 기관 포인터) 레코드, SRV 레코드와 같은 다양한 유형의 DNS 레코드에 대한 지식 ([지원되는 DNS 레코드 유형](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) 참조)
+ Python 언어 및 해당 라이브러리에 대한 지식

**제한 사항 **
+ 이 패턴은 모든 사용 사례 시나리오에 대한 광범위한 범위를 제공하지는 않습니다. 예를 들어 [change\$1resource\$1record\$1sets](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets) 호출은 API의 사용 가능한 모든 속성을 사용하지 않습니다.
+ Excel 워크시트에서는 각 행의 값이 고유한 것으로 간주됩니다. 각 FQDN(Fulalified Domain Name)에 대한 여러 값이 동일한 행에 표시될 것으로 예상됩니다. 그렇지 않은 경우 이 패턴에 제공된 코드를 수정하여 필요한 연결을 수행해야 합니다.
+ 이 패턴은 Python용 AWS SDK(Boto3)를 사용하여 Route 53 서비스를 직접 호출합니다. `create_stack` 및 `update_stack` 명령에 AWS CloudFormation 래퍼를 사용하도록 코드를 개선하고 JSON 값을 사용하여 템플릿 리소스를 채울 수 있습니다.

## 아키텍처
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-architecture"></a>

**기술 스택**
+ 트래픽 라우팅을 위한 Route 53 프라이빗 호스팅 영역
+ 출력 JSON 파일을 저장하기 위한 Amazon S3

![\[Route 53 프라이빗 호스팅 영역으로 DNS 레코드를 대량으로 마이그레이션하기 위한 워크플로.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/a81c29ea-f0c5-4d4a-ba87-93111a0f1ee9/images/2ada844b-4147-4f9f-8883-d22605aa42d8.png)


워크플로는 이전 다이어그램에 나와 있고 *에픽* 섹션에서 설명한 대로 다음 단계로 구성됩니다.

1. 레코드 세트 정보가 있는 Excel 워크시트를 S3 버킷에 업로드합니다.

1. Excel 데이터를 JSON 형식으로 변환하는 Python 스크립트를 만들고 실행합니다.

1. S3 버킷에서 레코드를 읽고 데이터를 정리합니다.

1. 프라이빗 호스팅 영역에서 레코드 세트를 생성합니다.

## 도구
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-tools"></a>
+ [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) — Amazon Route 53은 도메인 등록, DNS 라우팅 및 상태 확인을 처리하는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)-Amazon Simple Storage Service(S3)는 객체 스토리지 서비스입니다. Amazon S3를 사용하면 인터넷을 통해 언제 어디서든 원하는 양의 데이터를 저장하고 검색할 수 있습니다.

## 에픽
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-epics"></a>

### 자동화를 위한 데이터 준비
<a name="prepare-data-for-automation"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 기록을 위한 Excel 파일을 만드세요. | 현재 시스템에서 내보낸 레코드를 사용하여 FQDN (정규화된 도메인 이름), 레코드 유형, TTL (TTL), 값 등 레코드에 필요한 열이 있는 Excel 워크시트를 만드십시오. NAPTR 및 SRV 레코드의 경우 값은 여러 속성의 조합이므로 Excel의 `concat` 방법을 사용하여 이러한 속성을 결합하십시오.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.html) | 데이터 엔지니어, 엑셀 스킬 | 
| 작업 환경을 확인하세요. | IDE에서 Python 파일을 생성하여 엑셀 입력 워크시트를 JSON 형식으로 변환합니다. (IDE 대신 Amazon SageMaker 노트북을 사용하여 Python 코드로 작업할 수도 있습니다.)사용 중인 Python 버전이 버전 3.7 이상인지 확인하십시오.<pre> python3 --version</pre>**pandas** 패키지를 설치합니다.<pre> pip3 install pandas --user</pre> | 일반 AWS | 
| 엑셀 워크시트 데이터를 JSON으로 변환합니다. | Excel에서 JSON으로 변환하는 다음 코드가 포함된 Python 파일을 생성합니다.<pre>import pandas as pd<br />data=pd.read_excel('./Book1.xls')<br />data.to_json(path_or_buf='my.json',orient='records')</pre>여기서 `Book1`은(는) Excel 워크시트의 이름이고 `my.json`은(는) 출력 JSON 파일의 이름입니다. | 데이터 엔지니어, Python 스킬 | 
| 이 JSON 파일을 S3 버킷에 업로드합니다. | `my.json` 파일을 S3 버킷에 업로드합니다. 자세한 내용은 Amazon S3 설명서의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요. | 앱 개발자 | 
| FQDNName | RecordType | 값 | TTL | 
| something.example.org | A | 1.1.1.1 | 900 | 

### 레코드 삽입
<a name="insert-records"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 프라이빗 호스팅 영역을 생성합니다. | [create\$1hosted\$1zone](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone) API와 다음 Python 샘플 코드를 사용하여 프라이빗 호스팅 영역을 생성합니다. 파라미터 `hostedZoneName`, `vpcRegion` 및 `vpcId`를 사용자의 값으로 바꿉니다.<pre>import boto3<br />import random<br />hostedZoneName ="xxx"<br />vpcRegion = "us-east-1"<br />vpcId="vpc-xxxx"<br />route53_client = boto3.client('route53')<br />response = route53_client.create_hosted_zone(<br />        Name= hostedZoneName,<br />        VPC={<br />            'VPCRegion: vpcRegion,<br />            'VPCId': vpcId<br />        },<br />        CallerReference=str(random.random()*100000),<br />        HostedZoneConfig={<br />            'Comment': "private hosted zone created by automation",<br />            'PrivateZone': True<br />        }<br />    )<br /> print(response)</pre>또한 AWS CloudFormation과 같은 코드형 인프라(IaC) 도구를 사용하여 이러한 단계를 적절한 리소스 및 속성이 포함된 스택을 생성하는 템플릿으로 대체할 수 있습니다. | 클라우드 아키텍트, 네트워크 관리자, Python 스킬 | 
| Amazon S3에서 세부 정보를 사전으로 검색합니다. | 다음 코드를 사용하여 S3 버킷에서 읽고 JSON 값을 Python 사전으로 가져옵니다. <pre>fileobj = s3_client.get_object(<br />        Bucket=bucket_name,<br />        Key='my.json'<br />        )<br />    filedata = fileobj['Body'].read()<br />    contents = filedata.decode('utf-8')<br />    json_content=json.loads(contents)<br />    print(json_content)</pre>`json_content`은(는) Python 사전이 들어 있습니다. | 앱 개발자, Python 기술 | 
| 공백 및 유니코드 문자의 데이터 값을 정리합니다. | 데이터의 정확성을 보장하기 위한 안전 조치로 다음 코드를 사용하여 `json_content`의 값에 대해 제거 작업을 수행하십시오. 이 코드는 각 문자열의 앞과 끝에 있는 공백 문자를 제거합니다. 또한 `replace` 메서드를 사용하여 고정된 (끊어지지 않는) 공백 (`\xa0` 문자) 을 제거합니다.<pre>for item in json_content:<br />    fqn_name = unicodedata.normalize("NFKD",item["FqdnName"].replace("u'", "'").replace('\xa0', '').strip())<br />    rec_type = item["RecordType"].replace('\xa0', '').strip()<br />    res_rec = {<br />                 'Value': item["Value"].replace('\xa0', '').strip()<br />                }</pre> | 앱 개발자, Python 기술 | 
| 레코드를 삽입합니다. | 이전 `for` 루프의 일부로 다음 코드를 사용합니다.<pre>change_response = route53_client.change_resource_record_sets(<br />            HostedZoneId="xxxxxxxx",<br />            ChangeBatch={<br />                'Comment': 'Created by automation',<br />                'Changes': [<br />                    {<br />                        'Action': 'UPSERT',<br />                        'ResourceRecordSet': {<br />                            'Name': fqn_name,<br />                            'Type': rec_type,<br />                            'TTL': item["TTL"],<br />                            'ResourceRecords': res_rec<br />                        }<br />                    }<br />                ]<br />            }<br />    )</pre>이 에픽의 첫 번째 단계에 있는 호스팅 영역 `xxxxxxx` ID는 어디에 있습니까? | 앱 개발자, Python 기술 | 

## 관련 리소스
<a name="migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone-resources"></a>

**참조**
+ [영역 파일을 가져와서 레코드 생성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html) (Amazon Route 53 설명서)
+ [create\$1hosted\$1zone 메서드](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone) (Boto3 설명서)
+ [변경\$1리소스\$1레코드\$1세트 메서드](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets) (Boto3 설명서)

**자습서 및 동영상**
+ [파이썬 튜토리얼](https://docs.python.org/3/tutorial/) (파이썬 문서)
+ [Amazon Route 53을 사용한 DNS 설계](https://www.youtube.com/watch?v=2y_RBjDkRgY) (유튜브 동영상, *AWS 온라인 테크 토크*)

# F5에서 AWS의 Application Load Balancer로 마이그레이션할 때 HTTP 헤더를 수정
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws"></a>

*Sachin Trivedi, Amazon Web Services*

## 요약
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-summary"></a>

F5 로드 밸런서를 사용하는 애플리케이션을 Amazon Web Services(AWS)로 마이그레이션하고 AWS에서 Application Load Balancer를 사용하려는 경우, 헤더 수정을 위한 F5 규칙을 마이그레이션하는 것은 일반적으로 발생하는 문제입니다. Application Load Balancer는 헤더 수정을 지원하지 않지만 Amazon CloudFront를 콘텐츠 배포 네트워크(CDN)로 사용하고 Lambda @Edge를 사용하여 헤더를 수정할 수 있습니다.

이 패턴은 필요한 통합을 설명하고 AWS CloudFront 및 Lambda@Edge를 사용하여 헤더를 수정하기 위한 샘플 코드를 제공합니다.

## 사전 조건 및 제한 사항
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-prereqs"></a>

**사전 조건 **
+ `if, else`를 사용하여 HTTP 헤더 값을 대체하는 구성을 갖춘 F5 로드 밸런서를 사용하는 온프레미스 애플리케이션입니다. 이 구성에 대한 자세한 내용은 F5 제품 설명서의 [HTTP::header](https://clouddocs.f5.com/api/irules/HTTP__header.html)를 참조하세요. 

**제한 사항 **
+ 이 패턴은 F5 로드 밸런서 헤더 사용자 지정에 적용됩니다. 다른 타사 로드 밸런서의 경우 해당 로드 밸런서 설명서에서 지원 정보를 확인하세요.
+ Lambda@Edge에 사용하는 Lambda 함수는 미국 동부(버지니아 북부) 리전에 있어야 합니다.

## 아키텍처
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-architecture"></a>

다음 다이어그램은 CDN과 다른 AWS 구성 요소 간의 통합 흐름을 포함하여 AWS의 아키텍처를 보여줍니다.

![\[Amazon CloudFront와 Lambda @Edge를 사용한 헤더 수정 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/00abbe3c-2453-4291-9b24-b488dced4868/images/4ee9a19e-6da2-4c5a-a8bc-19d3918a166e.png)


## 도구
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-tools"></a>

**서비스**
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) ─ Application Load Balancer는 오픈 시스템 상호 연결(OSI) 모델의 일곱 번째 계층에서 작동하는 AWS의 완전 관리형 로드 밸런싱 서비스입니다. 여러 대상에 걸쳐 트래픽을 분산하고 HTTP 헤더 및 메서드, 쿼리 문자열, 호스트 기반 또는 경로 기반 라우팅을 기반으로 고급 라우팅 요청을 지원합니다.
+ [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) – Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 더 짧은 지연 시간과 향상된 성능으로 콘텐츠를 제공합니다.
+ [Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html) ─ Lambda@Edge는 CloudFront를 통해 전달되는 콘텐츠를 사용자 지정하는 함수를 실행할 수 있게 해주는 AWS Lambda의 확장입니다. 미국 동부(버지니아 북부) 리전에서 함수를 작성한 다음 함수를 CloudFront 배포와 연결하여 서버를 프로비저닝하거나 관리하지 않고 코드를 전 세계에 자동으로 복제할 수 있습니다. 이렇게 하면 지연 시간이 줄어들고 사용자 경험이 향상됩니다.

**코드**

다음 샘플 코드는 CloudFront 응답 헤더를 수정하기 위한 청사진을 제공합니다. *에픽* 섹션의 지침에 따라 코드를 배포하세요.

```
exports.handler = async (event, context) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;


    const headerNameSrc = 'content-security-policy';
    const headerNameValue = '*.xyz.com';


    if (headers[headerNameSrc.toLowerCase()]) {
        headers[headerNameSrc.toLowerCase()] = [{
            key: headerNameSrc,
            value: headerNameValue,
        }];
        console.log(`Response header "${headerNameSrc}" was set to ` +
                    `"${headers[headerNameSrc.toLowerCase()][0].value}"`);
    }
    else {
            headers[headerNameSrc.toLowerCase()] = [{
            key: headerNameSrc,
            value: headerNameValue,
            }];
    }
    return response;
};
```

## 에픽
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-epics"></a>

### CDN 배포 만들기
<a name="create-a-cdn-distribution"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudFront 웹 배포를 생성합니다. | 이 단계에서 CloudFront 배포를 생성하여 CloudFront에 어디로부터 콘텐츠를 전송하고자 하는지와 이러한 콘텐츠 전송을 추적 및 관리하는 방법에 대한 세부 정보를 알립니다.콘솔을 사용하여 배포를 생성하려면 AWS Management Console에 로그인하고 [CloudFront 콘솔](https://console.aws.amazon.com/cloudfront/v3/home)을 연 다음 [CloudFront 설명서](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html)의 단계를 따르세요. | 클라우드 관리자 | 

### Lambda@Edge 함수 생성 및 배포
<a name="create-and-deploy-the-lambda-edge-function"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Lambda@Edge 함수를 생성하고 배포합니다. | CloudFront 응답 헤더를 수정하기 위한 청사진을 사용하여 Lambda @Edge 함수를 생성할 수 있습니다. (사용 사례별로 여러 청사진을 사용할 수 있습니다. 자세한 내용은 CloudFront 설명서의 [Lambda @Edge 예제 함수](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)를 참조하세요.) Lambda@Edge 함수를 생성하려면:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.html) | AWS 관리자 | 
| Lambda@Edge 함수를 배포합니다. | Amazon CloudFront 설명서의 *자습서: 간단한 Lambda @Edge 함수 생성*의 [4단계](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-add-trigger) 지침에 따라 CloudFront 트리거를 구성하고 함수를 배포하세요. | AWS 관리자 | 

## 관련 리소스
<a name="modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws-resources"></a>

**CloudFront 설명서**
+ [사용자 지정 오리진에 대한 요청 및 응답 동작](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) 
+ [배포 작업](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html) 
+ [Lambda@Edge 예제 함수](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html) 
+ [Lambda@Edge를 사용하여 엣지에서 사용자 지정](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)
+ [자습서: 간단한 Lambda@Edge 함수 생성](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html)

# 여러의 인바운드 인터넷 액세스에 대한 Network Access Analyzer 조사 결과 보고서 생성 AWS 계정
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts"></a>

*Mike Virgilio, Amazon Web Services*

## 요약
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-summary"></a>

 AWS 리소스에 대한 의도하지 않은 인바운드 인터넷 액세스는 조직의 데이터 경계에 위험을 초래할 수 있습니다. Network Access Analyzer는 Amazon Web Services(AWS)의 리소스에 대한 의도하지 않은 네트워크 액세스를 식별하는 데 도움이 되는 Amazon Virtual Private Cloud(VPC)입니다. Network Access Analyzer를 사용하여 네트워크 액세스 요구 사항을 지정하고 지정된 요구 사항을 충족하지 않는 잠재적 네트워크 경로를 식별할 수 있습니다. Network Access Analyzer를 사용하여 다음을 수행할 수 있습니다.

1. 인터넷 게이트웨이를 통해 인터넷에 액세스할 수 있는 AWS 리소스를 식별합니다.

1. 프로덕션 및 개발 환경을 격리하고 트랜잭션 워크로드를 분리하는 등 virtual private cloud(VPC)가 적절하게 세그먼트화되어 있는지 확인합니다.

Network Access Analyzer는 단일 구성 요소뿐만 아니라 엔드-투-엔드 네트워크 연결성 조건을 분석합니다. Network Access Analyzer는 리소스가 인터넷에 액세스할 수 있는지 여부를 확인하기 위해 인터넷 게이트웨이, VPC 라우팅 테이블, 네트워크 액세스 제어 목록(ACL), 탄력적 네트워크 인터페이스의 퍼블릭 IP 주소, 보안 그룹을 평가합니다. 이러한 구성 요소 중 하나라도 인터넷 액세스를 방해하는 경우 Network Access Analyzer는 조사 결과를 생성하지 않습니다. 예를 들어 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 `0/0`(으)로부터 트래픽을 허용하는 개방형 보안 그룹이 있지만 해당 인스턴스가 인터넷 게이트웨이에서 라우팅할 수 없는 프라이빗 서브넷에 있는 경우 Network Access Analyzer는 조사 결과를 생성하지 않습니다. 이는 충실도가 높은 결과를 제공하므로 인터넷에서 실제로 액세스할 수 있는 리소스를 식별할 수 있습니다.

Network Access Analyzer를 실행할 때는 [네트워크 액세스 범위](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html#concepts)를 사용하여 네트워크 액세스 요구 사항을 지정합니다. 이 솔루션은 인터넷 게이트웨이와 탄력적 네트워크 인터페이스 간의 네트워크 경로를 식별합니다. 이 패턴에서는가 관리하는 AWS 계정 조직의 중앙 집중식에 솔루션을 배포 AWS Organizations하고 조직의 모든 계정을 분석 AWS 리전합니다.

이 솔루션은 다음 사항을 염두에 두고 설계되었습니다.
+  AWS CloudFormation 템플릿은이 패턴으로 AWS 리소스를 배포하는 데 필요한 노력을 줄입니다.
+ 배포 시 CloudFormation 템플릿 및 **naa-script.sh** 스크립트에서 파라미터를 조정하여 환경에 맞게 사용자 지정할 수 있습니다.
+ Bash 스크립팅은 여러 계정의 네트워크 액세스 범위를 병렬로 자동으로 프로비저닝하고 분석합니다.
+ Python 스크립트는 조사 결과를 처리하고 데이터를 추출한 다음 결과를 통합합니다. Network Access Analyzer 조사 결과에 대한 통합 보고서를 CSV 형식으로 검토하거나 Security Hub에서 검토할 수 있습니다. CSV 보고서의 예제는 이 패턴의 [추가 정보](#create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-additional) 섹션에서 확인할 수 있습니다.
+ 조사 결과의 문제를 해결하거나, **naa-exclusions.csv** 파일에 추가하여 향후 분석에서 제외할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-prereqs"></a>

**사전 조건 **
+ 에서 조직의 멤버 계정으로 관리되는 보안 서비스 및 도구를 호스팅하기 AWS 계정 위한 입니다 AWS Organizations. 이 패턴에서는 이 계정을 보안 계정이라고 합니다.
+ 보안 계정에는 아웃바운드 인터넷 액세스가 가능한 프라이빗 서브넷이 있어야 합니다. 지침은 Amazon VPC 설명서의 [서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)을 참조하십시오. [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 또는 [인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)를 사용하여 인터넷 액세스를 설정할 수 있습니다.
+  AWS Organizations 관리 계정 또는 CloudFormation에 대한 관리자 권한을 위임한 계정에 대한 액세스. 자세한 지침은 CloudFormation 설명서의 [위임된 관리자 등록](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html)을 참조하세요.
+  AWS Organizations 및 CloudFormation 간에 신뢰할 수 있는 액세스를 활성화합니다. 자세한 지침은 CloudFormation 설명서의 [AWS Organizations을 사용하여 신뢰할 수 있는 액세스 활성화](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)를 참조하세요.
+ 조사 결과를 Security Hub CSPM에 업로드하는 경우 계정과 Amazon EC2 인스턴스가 프로비저닝된 AWS 리전 위치에서 Security Hub CSPM을 활성화해야 합니다. 자세한 내용은 [설정 AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)을 참조하세요.

**제한 사항 **
+ Network Access Analyzer 기능의 한계로 인해 교차 계정 네트워크 경로는 현재 분석되지 않습니다.
+ 대상은의 조직으로 관리되어야 AWS 계정 합니다 AWS Organizations. 를 사용하지 않는 경우 환경에 맞는 **naa-execrole.yaml** CloudFormation 템플릿과 **naa-script.sh** 스크립트를 업데이트할 AWS Organizations수 있습니다. 대신 스크립트를 실행하려는 AWS 계정 IDs 및 리전 목록을 제공합니다.
+ CloudFormation 템플릿은 아웃바운드 인터넷 액세스가 가능한 프라이빗 서브넷에 EC2 인스턴스를 배포하도록 설계되었습니다. AWS Systems Manager 에이전트(SSM 에이전트)가 Systems Manager 서비스 엔드포인트에 도달하려면 아웃바운드 액세스가 필요하며, 코드 리포지토리를 복제하고 종속성을 설치하려면 아웃바운드 액세스가 필요합니다. 퍼블릭 서브넷을 사용하려면 **naa-resources.yaml** 템플릿을 수정하여 [탄력적 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 EC2 인스턴스에 연결해야 합니다.

## 아키텍처
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-architecture"></a>

**대상 아키텍처**

*옵션 1: Amazon S3 버킷의 조사 결과에 액세스*

![\[Amazon S3 버킷의 Network Access Analyzer 조사 결과 보고서에 액세스하는 아키텍처 다이어그램\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/d0b08437-e5b0-47a1-abdd-040c67b5da8f.png)


이 다이어그램은 다음 프로세스를 보여줍니다.

1. 솔루션을 수동으로 실행하는 경우 사용자는 세션 관리자를 사용하여 EC2 인스턴스를 인증한 다음 **naa-script.sh** 스크립트를 실행합니다. 이 쉘 스크립트는 2\$17단계를 수행합니다.

   솔루션을 자동으로 실행하는 경우 cron 표현식에서 정의한 일정에 따라 **naa-script.sh** 스크립트가 자동으로 시작됩니다. 이 쉘 스크립트는 2\$17단계를 수행합니다. 자세한 내용은 이 섹션 끝부분에 나와 있는 *자동화 및 규모 조정*을 참조하십시오.

1. EC2 인스턴스는 S3 버킷에서 최신 **naa-exception.csv** 파일을 다운로드합니다. 이 파일은 Python 스크립트가 제외를 처리할 때 프로세스 후반부에 사용됩니다.

1. Amazon EC2 인스턴스는 `NAAEC2Role` AWS Identity and Access Management (IAM) 역할을 수임하여 Amazon S3 버킷에 액세스하고 조직의 다른 계정에서 `NAAExecRole` IAM 역할을 수임할 수 있는 권한을 부여합니다.

1. EC2 인스턴스는 조직의 관리 계정에서 `NAAExecRole` IAM 역할을 떠맡고 조직의 계정 목록을 생성합니다.

1. EC2 인스턴스는 조직의 멤버 계정(아키텍처 다이어그램에서는 *워크로드 계정*이라고 함)에서 `NAAExecRole` IAM 역할을 맡아 각 계정에서 보안 평가를 수행합니다. 조사 결과는 EC2 인스턴스에 JSON 파일로 저장됩니다.

1. EC2 인스턴스는 Python 스크립트를 사용하여 JSON 파일을 처리하고, 데이터 필드를 추출하며, CSV 보고서를 생성합니다.

1. EC2 인스턴스는 CSV 파일을 S3 버킷에 업로드합니다.

1. Amazon EventBridge 규칙은 파일 업로드를 탐지하고 Amazon SNS 주제를 사용하여 보고서가 완료되었음을 사용자에게 알리는 이메일을 발송합니다.

1. 사용자는 S3 버킷에서 CSV 파일을 다운로드합니다. 사용자는 결과를 Excel 템플릿으로 가져와서 검토합니다.

*옵션 2:에서 조사 결과에 액세스 AWS Security Hub CSPM*

![\[AWS Security Hub를 통해 Network Access Analyzer 조사 결과에 액세스하는 아키텍처 다이어그램\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/9cb4f059-dfb6-4a33-9f8d-159fe5df0d64.png)


이 다이어그램은 다음 프로세스를 보여줍니다.

1. 솔루션을 수동으로 실행하는 경우 사용자는 세션 관리자를 사용하여 EC2 인스턴스를 인증한 다음 **naa-script.sh** 스크립트를 실행합니다. 이 쉘 스크립트는 2\$17단계를 수행합니다.

   솔루션을 자동으로 실행하는 경우 cron 표현식에서 정의한 일정에 따라 **naa-script.sh** 스크립트가 자동으로 시작됩니다. 이 쉘 스크립트는 2\$17단계를 수행합니다. 자세한 내용은 이 섹션 끝부분에 나와 있는 *자동화 및 규모 조정*을 참조하십시오.

1. EC2 인스턴스는 S3 버킷에서 최신 **naa-exception.csv** 파일을 다운로드합니다. 이 파일은 Python 스크립트가 제외를 처리할 때 프로세스 후반부에 사용됩니다.

1. EC2 인스턴스는 S3 버킷에 액세스하고 조직의 다른 계정에서 `NAAExecRole` IAM 역할을 떠맡는 권한을 부여하는 `NAAEC2Role` IAM 역할을 떠맡습니다.

1. EC2 인스턴스는 조직의 관리 계정에서 `NAAExecRole` IAM 역할을 떠맡고 조직의 계정 목록을 생성합니다.

1. EC2 인스턴스는 조직의 멤버 계정(아키텍처 다이어그램에서는 *워크로드 계정*이라고 함)에서 `NAAExecRole` IAM 역할을 맡아 각 계정에서 보안 평가를 수행합니다. 조사 결과는 EC2 인스턴스에 JSON 파일로 저장됩니다.

1. Amazon EC2 인스턴스는 Python 스크립트를 사용하여 JSON 파일을 처리하고 Security Hub CSPM으로 가져올 데이터 필드를 추출합니다.

1. Amazon EC2 인스턴스는 Network Access Analyzer 조사 결과를 Security Hub CSPM으로 가져옵니다.

1. Amazon EventBridge 규칙은 가져오기를 탐지하고 Amazon SNS 주제를 사용하여 프로세스가 완료되었음을 사용자에게 알리는 이메일을 발송합니다.

1. 사용자는 Security Hub CSPM에서 조사 결과를 봅니다.

**자동화 및 규모 조정**

사용자 지정 일정에 따라 **naa-script.sh** 스크립트가 자동으로 실행되도록 이 솔루션을 예약할 수 있습니다. 사용자 지정 일정을 설정하려면 **naa-resources.yaml** CloudFormation 템플릿에서 `CronScheduleExpression` 파라미터를 수정합니다. 예를 들어 `0 0 * * 0` 기본값은 매주 일요일 자정에 솔루션을 실행합니다. `0 0 * 1-12 0` 값은 매월 첫 번째 일요일 자정에 솔루션을 실행합니다. Cron 및 rate 표현식에 대한 자세한 내용은 Systems Manager 설명서의 [cron 및 rate 표현식](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)을 참조하십시오.

`NAA-Resources` 스택을 배포한 후 일정을 조정하려면 `/etc/cron.d/naa-schedule`에서 cron 일정을 수동으로 편집할 수 있습니다.

## 도구
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-tools"></a>

**AWS 서비스**
+ [Amazon Elastic Compute Cloud(Amazon EC2)](https://docs.aws.amazon.com/ec2/)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 필요한 만큼 가상 서버를 시작하고 빠르게 스케일 업하거나 스케일 다운할 수 있습니다.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 애플리케이션을 다양한 소스의 실시간 데이터와 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. 예를 들어 AWS Lambda 함수, API 대상을 사용하는 HTTP 호출 엔드포인트 또는 다른의 이벤트 버스가 있습니다 AWS 계정.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)는 AWS 리소스에 대한 액세스를 인증하고 사용할 권한이 있는 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)는 여러을 생성하여 중앙에서 관리하는 조직 AWS 계정 으로 통합하는 데 도움이 되는 계정 관리 서비스입니다.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)는의 보안 상태에 대한 포괄적인 보기를 제공합니다 AWS. 또한 보안 업계 표준 및 모범 사례를 기준으로 AWS 환경을 확인하는 데 도움이 됩니다.
+ [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 사용하면 웹 서버 및 이메일 주소를 포함하여 게시자와 클라이언트 간의 메시지 교환을 조정하고 관리할 수 있습니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)은 AWS 클라우드에서 실행되는 애플리케이션 및 인프라를 관리하는 데 도움을 줍니다. 애플리케이션 및 리소스 관리를 간소화하고, 운영 문제를 감지 및 해결하는 시간을 단축하며, AWS 리소스를 대규모로 안전하게 관리하는 데 도움이 됩니다. 이 패턴은 Systems Manager의 기능인 Session Manager를 사용합니다.

**코드 리포지토리**

이 패턴의 코드는 GitHub [Network Access Analyzer 다중 계정 분석](https://github.com/aws-samples/network-access-analyzer-multi-account-analysis) 리포지토리에서 구할 수 있습니다. 코드 리포지토리에는 다음 파일이 포함되어 있습니다.
+ **naa-script.sh** -이 bash 스크립트는 여러에 대한 Network Access Analyzer 분석을 병렬 AWS 계정로 시작하는 데 사용됩니다. **naa-resources.yaml** CloudFormation 템플릿에 정의된 대로 이 스크립트는 EC2 인스턴스의 `/usr/local/naa` 폴더에 자동으로 배포됩니다.
+ **naa-resources.yaml** — 이 CloudFormation 템플릿을 사용하여 조직의 보안 계정에서 스택을 생성합니다. 이 템플릿은 솔루션을 지원하기 위해 이 계정에 필요한 모든 리소스를 배포합니다. 이 스택은 **naa-execrole.yaml** 템플릿보다 먼저 배포되어야 합니다.
**참고**  
참고: 이 스택을 삭제하고 재배포하는 경우 IAM 역할 간의 교차 계정 종속성을 다시 빌드하려면 스택 세트를 다시 빌드해야 합니다.
+ **naa-execrole.yaml** — 이 CloudFormation 템플릿을 사용하여 관리 계정을 포함해 조직의 모든 계정에 `NAAExecRole` IAM 역할을 배포하는 스택 세트를 생성합니다.
+ **naa-processfindings.py** **– naa-script.sh **스크립트는이 Python 스크립트를 자동으로 호출하여 Network Access Analyzer JSON 출력을 처리하고, **naa-exclusions.csv** 파일에서 잘 알려진 리소스를 제외한 다음, 통합 결과의 CSV 파일을 생성하거나 결과를 Security Hub CSPM으로 가져옵니다.

## 에픽
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-epics"></a>

### 배포 준비
<a name="prepare-for-deployment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 코드 리포지토리를 복제합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 
| 템플릿을 검토합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 

### CloudFormation 스택 생성
<a name="create-the-cfnshort-stacks"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 보안 계정에서 리소스를 프로비저닝합니다. | **naa-resources.yaml** 템플릿을 사용하여 보안 계정에 필요한 모든 리소스를 배포하는 CloudFormation 스택을 생성합니다. 자세한 지침은 CloudFormation 설명서의 [스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)을 참조하십시오. 이 템플릿을 배포할 때는 다음 사항을 유념합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 
| 멤버 계정에서 IAM 역할을 프로비저닝합니다. |  AWS Organizations 관리 계정 또는 CloudFormation에 대한 위임된 관리자 권한이 있는 계정에서 **naa-execrole.yaml** 템플릿을 사용하여 CloudFormation 스택 세트를 생성합니다. 그러면 스택 세트는 조직의 모든 멤버 계정에서 `NAAExecRole` IAM 역할을 배포합니다. 자세한 내용은 CloudFormation 설명서의 [서비스 관리형 권한으로 스택 세트 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#stacksets-orgs-associate-stackset-with-org)을 참조하세요. 이 템플릿을 배포할 때는 다음 사항을 유념합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 
| 관리 계정에서 IAM 역할을 프로비저닝합니다. | **naa-execrole.yaml** 템플릿을 사용하여, 조직의 관리 계정에서 `NAAExecRole` IAM 역할을 배포하는 CloudFormation 스택을 생성합니다. 이전에 생성한 스택 세트는 관리 계정에 IAM 역할을 배포하지 않습니다. 자세한 지침은 CloudFormation 설명서의 [스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)을 참조하세요. 이 템플릿을 배포할 때는 다음 사항을 유념합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 

### 분석 수행
<a name="perform-the-analysis"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 쉘 스크립트를 사용자 지정합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 
| 대상 계정을 분석합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | DevOps | 
| 옵션 1 — S3 버킷에서 결과를 검색합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | DevOps | 
| 옵션 2 - Security Hub CSPM의 결과를 검토합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | DevOps | 

### 조사 결과의 문제 해결 및 조사 결과 제외
<a name="remediate-and-exclude-findings"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 조사 결과의 문제를 해결합니다. | 해결하려는 모든 조사 결과의 문제를 해결합니다. AWS 자격 증명, 리소스 및 네트워크 주위에 경계를 생성하는 방법에 대한 자세한 내용과 모범 사례는 (AWS 백서)[에서 데이터 경계 구축을 AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) 참조하세요. | DevOps | 
| 정상 작동이 확인된 네트워크 경로를 가진 리소스는 제외합니다. | Network Access Analyzer가 인터넷에서 액세스할 수 있어야 하는 리소스에 대한 조사 결과를 생성하는 경우 해당 리소스를 제외 목록에 추가할 수 있습니다. 다음에 Network Access Analyzer를 실행할 때는 해당 리소스에 대한 조사 결과가 생성되지 않습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 

### (선택 사항) naa-script.sh 스크립트 업데이트
<a name="optional-update-the-naa-script-sh-script"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| naa-script.sh 스크립트를 업데이트합니다. | **naa-script.sh** 스크립트를 리포지토리의 최신 버전으로 업데이트하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | DevOps | 

### (선택 사항)정리
<a name="optional-clean-up"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 배포된 모든 리소스를 삭제합니다. | 리소스는 계정에 배포된 상태로 둘 수 있습니다.모든 리소스의 프로비저닝을 해제하려면 다음을 수행합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | 

## 문제 해결
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| Session Manager를 사용하여 EC2 인스턴스에 연결할 수 없습니다. | SSM 에이전트는 Systems Manager 엔드포인트와 통신할 수 있어야 합니다. 해결 방법:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | 
| 스택 세트를 배포할 때 CloudFormation 콘솔에 `Enable trusted access with AWS Organizations to use service-managed permissions` 프롬프트가 표시됩니다. | 이는 AWS Organizations 와 CloudFormation 간에 신뢰할 수 있는 액세스가 활성화되지 않았음을 나타냅니다. 서비스 관리형 스택 세트를 배포하려면 신뢰할 수 있는 액세스가 필요합니다. 신뢰할 수 있는 액세스를 활성화하는 버튼을 선택합니다. 자세한 내용은 CloudFormation 설명서의 [신뢰할 수 있는 액세스 활성화](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html) 를 참조하세요. | 

## 관련 리소스
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-resources"></a>
+ [신규 - Amazon VPC Network Access Analyzer](https://aws.amazon.com/blogs/aws/new-amazon-vpc-network-access-analyzer/)(AWS 블로그 게시물)
+ [AWS re:Inforce 2022 - AWS (NIS202)에서 효과적인 네트워크 액세스 제어 검증](https://youtu.be/aN2P2zeQek0)(비디오)
+ [데모 - Network Access Analyzer를 사용한 조직 전반의 인터넷 수신 데이터 경로 분석](https://youtu.be/1IFNZWy4iy0)(동영상)

## 추가 정보
<a name="create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-additional"></a>

**콘솔 출력 예제**

다음 샘플은 대상 계정 목록을 생성하고 대상 계정을 분석한 결과물을 보여줍니다.

```
[root@ip-10-10-43-82 naa]# ./naa-script.sh
download: s3://naa-<account ID>-us-east-1/naa-exclusions.csv to ./naa-exclusions.csv

AWS Management Account: <Management account ID>

AWS Accounts being processed...
<Account ID 1> <Account ID 2> <Account ID 3>

Assessing AWS Account: <Account ID 1>, using Role: NAAExecRole
Assessing AWS Account: <Account ID 2>, using Role: NAAExecRole
Assessing AWS Account: <Account ID 3>, using Role: NAAExecRole
Processing account: <Account ID 1> / Region: us-east-1
Account: <Account ID 1> / Region: us-east-1 – Detecting Network Analyzer scope...
Processing account: <Account ID 2> / Region: us-east-1
Account: <Account ID 2> / Region: us-east-1 – Detecting Network Analyzer scope...
Processing account: <Account ID 3> / Region: us-east-1
Account: <Account ID 3> / Region: us-east-1 – Detecting Network Analyzer scope...
Account: <Account ID 1> / Region: us-east-1 – Network Access Analyzer scope detected.
Account: <Account ID 1> / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour
Account: <Account ID 2> / Region: us-east-1 – Network Access Analyzer scope detected.
Account: <Account ID 2> / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour
Account: <Account ID 3> / Region: us-east-1 – Network Access Analyzer scope detected.
Account: <Account ID 3> / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour
```

**CSV 보고서 예제**

다음 이미지는 CSV 출력의 예제입니다.

![\[이 솔루션으로 생성된 CSV 보고서의 예제 1.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/55e02e61-054e-4da6-aaae-c9a8b6f4f272.png)


![\[이 솔루션으로 생성된 CSV 보고서의 예제 2.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/95f980ad-92c1-4392-92d4-9c742755aab2.png)


# 다중 계정 AWS 환경에서 하이브리드 네트워크에 대한 DNS 확인 설정
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment"></a>

*Anvesh Koganti, Amazon Web Services*

## 요약
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-summary"></a>

이 패턴은 여러 Amazon Web Services(AWS) 계정이 포함된 하이브리드 네트워크 환경에서 DNS 확인을 설정하기 위한 포괄적인 솔루션을 제공합니다. 엔드포인트를 통해 온프레미스 네트워크와 AWS 환경 간의 양방향 DNS 확인을 지원합니다 Amazon Route 53 Resolver . 이 패턴은 [다중 계정 중앙 집중식 아키텍처에서 DNS 확인을 활성화하는](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html#multi-account-centralized) 두 가지 솔루션을 제공합니다.
+ *기본 설정은* Route 53 Profiles를 사용하지 않습니다. 복잡성이 낮은 중소 규모 배포에 대한 비용을 최적화하는 데 도움이 됩니다.
+ *향상된 설정은* Route 53 Profiles를 사용하여 작업을 간소화합니다. 더 크거나 복잡한 DNS 배포에 가장 적합합니다.

**참고**  
구현 전에 *제한* 사항 섹션에서 서비스 제한 사항 및 할당량을 검토하세요. 결정을 내릴 때 관리 오버헤드, 비용, 운영 복잡성, 팀 전문성과 같은 요소를 고려하세요.

## 사전 조건 및 제한 사항
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-prereqs"></a>

**사전 조건 **
+ 공유 서비스 및 워크로드 계정에 배포된 Amazon Virtual Private Cloud(VPC)가 있는 AWS 다중 계정 환경(계정 구조에 대한 [AWS 모범 사례를 따라 AWS Control Tower를](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) 통해 설정하는 것이 좋음).
+ 온프레미스 네트워크와 AWS 환경 간의 기존 하이브리드 연결(AWS Direct Connect 또는 AWS Site-to-Site VPN).
+ Amazon VPC 피어링 AWS Transit Gateway또는 VPC 간 계층 3 네트워크 연결을 위한 AWS 클라우드 WAN. VPCs (이 연결은 애플리케이션 트래픽에 필요합니다. DNS 확인이 작동하는 데는 필요하지 않습니다. DNS 확인은 VPCs.)
+ 온프레미스 환경에서 실행되는 DNS 서버.

**제한 사항 **
+ Route 53 Resolver 엔드포인트, 규칙 및 프로필은 리전 구조이며 글로벌 조직의 AWS 리전 경우 여러에서 복제가 필요할 수 있습니다.
+ Route 53 Resolver, 프라이빗 호스팅 영역 및 프로파일에 대한 전체 Service Quotas 목록은 Route 53 설명서의 [할당량](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html)을 참조하세요.

## 아키텍처
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture"></a>

**대상 기술 스택  **
+ Route 53 아웃바운드 및 인바운드 엔드포인트
+ 조건부 전달을 위한 Route 53 Resolver 규칙
+ AWS Resource Access Manager (AWS RAM)
+ Route 53 프라이빗 호스팅 영역

**대상 아키텍처 **

**아웃바운드 및 인바운드 엔드포인트**

다음 다이어그램은에서 온프레미스 AWS 로의 DNS 확인 흐름을 보여줍니다. 도메인이 온프레미스에서 호스팅되는 아웃바운드 확인을 위한 연결 설정입니다. 다음은이 설정과 관련된 프로세스에 대한 개략적인 개요입니다. 자세한 내용은[에픽](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics) 섹션을 참조하세요.

1. 공유 서비스 VPC에 아웃바운드 Route 53 Resolver 엔드포인트를 배포합니다.

1. 온프레미스에서 호스팅되는 도메인의 공유 서비스 계정에서 Route 53 Resolver 규칙(전달 규칙)을 생성합니다.

1. 온프레미스 호스팅 도메인을 확인해야 하는 리소스를 호스팅하는 다른 계정의 VPCs와 규칙을 공유하고 연결합니다. 이 섹션의 뒷부분에 설명된 대로 사용 사례에 따라 다양한 방식으로이 작업을 수행할 수 있습니다.

![\[AWS의 인바운드 및 아웃바운드 엔드포인트에서 온프레미스로 DNS 확인 흐름.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/d69d4cad-5e2c-4481-9370-2708e8a4f8c1.png)


연결을 설정한 후 아웃바운드 확인과 관련된 단계는 다음과 같습니다.

1. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스는 `db.onprem.example.com` VPC의 Route 53 Resolver에 대한 DNS 확인 요청을 VPC\$12 주소로 보냅니다.

1. Route 53 Resolver는 Resolver 규칙을 확인하고 아웃바운드 엔드포인트를 사용하여 요청을 온프레미스 DNS 서버 IPs로 전달합니다.

1. 아웃바운드 엔드포인트는 요청을 온프레미스 DNS IPs로 전달합니다. 트래픽은 공유 서비스 VPC와 온프레미스 데이터 센터 간에 설정된 하이브리드 네트워크 연결을 거칩니다.

1. 온프레미스 DNS 서버는 아웃바운드 엔드포인트에 다시 응답한 다음 응답을 VPC의 Route 53 Resolver로 다시 전달합니다. Resolver는 EC2 인스턴스에 응답을 반환합니다.

다음 다이어그램은 온프레미스 환경에서 로의 DNS 확인 흐름을 보여줍니다 AWS. 도메인이에서 호스팅되는 인바운드 확인을 위한 연결 설정입니다 AWS. 다음은이 설정과 관련된 프로세스에 대한 개략적인 개요입니다. 자세한 내용은[에픽](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics) 섹션을 참조하세요.

1. 공유 서비스 VPC에 인바운드 Resolver 엔드포인트를 배포합니다.

1. 공유 서비스 계정에서 프라이빗 호스팅 영역을 생성합니다(중앙 집중식 접근 방식).

1. 프라이빗 호스팅 영역을 공유 서비스 VPC와 연결합니다. VPCs 간 DNS 확인을 위해 VPC-to-VPC와 공유하고 연결합니다. 이 섹션의 뒷부분에 설명된 대로 사용 사례에 따라 다양한 방식으로이 작업을 수행할 수 있습니다.

![\[온프레미스의 인바운드 및 아웃바운드 엔드포인트에서 AWS DNS로의 확인 흐름.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/a6f5348c-2041-453e-8939-2b4ee0b7ebd8.png)


연결을 설정한 후 인바운드 확인과 관련된 단계는 다음과 같습니다.

1. 온프레미스 리소스는에 대한 DNS 확인 요청을 온프레미스 DNS 서버`ec2.prod.aws.example.com`로 보냅니다.

1. 온프레미스 DNS 서버는 하이브리드 네트워크 연결을 통해 공유 서비스 VPC의 인바운드 Resolver 엔드포인트로 요청을 전달합니다.

1. 인바운드 Resolver 엔드포인트는 VPC Route 53 Resolver의 도움을 받아 연결된 프라이빗 호스팅 영역에서 요청을 조회하고 적절한 IP 주소를 가져옵니다.

1. 이러한 IP 주소는 온프레미스 DNS 서버로 다시 전송되어 온프레미스 리소스에 응답을 반환합니다.

이 구성을 통해 온프레미스 리소스는 인바운드 엔드포인트를 통해 쿼리를 적절한 AWS 프라이빗 호스팅 영역으로 라우팅하여 프라이빗 도메인 이름을 확인할 수 있습니다. 이 아키텍처에서 프라이빗 호스팅 영역은 공유 서비스 VPC에서 중앙 집중화되므로 단일 팀이 중앙 DNS를 관리할 수 있습니다. 이러한 영역은 여러 VPCs와 연결하여 VPC-to-VPC DNS 확인 사용 사례를 해결할 수 있습니다. 또는 DNS 도메인 소유권 및 관리를 각각에 위임할 수 있습니다 AWS 계정. 이 경우 각 계정은 자체 프라이빗 호스팅 영역을 관리하고 각 영역을 중앙 공유 서비스 VPC와 연결하여 온프레미스 환경과의 통합 해결을 수행합니다. 이 분산형 접근 방식은이 패턴의 범위를 벗어납니다. 자세한 내용은 Amazon [ VPCs의 여러 계정 및 VPC에서 DNS 관리 조정](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html)을 참조하세요. ** 

Resolver 엔드포인트를 사용하여 기본 DNS 확인 흐름을 설정할 때에서 Resolver 규칙과 프라이빗 호스팅 영역의 공유 및 연결을 관리하는 방법을 결정해야 합니다 AWS 계정. *기본 설정* 섹션에 설명된 대로 AWS RAM 를 사용하여 해석기 규칙을 공유하고 프라이빗 호스팅 영역 연결을 직접 공유하거나 *향상된 설정* 섹션에 설명된 대로 Route 53 Profiles를 통해 자체 관리형 공유를 통해이 작업에 액세스할 수 있습니다. 선택 사항은 조직의 DNS 관리 기본 설정 및 운영 요구 사항에 따라 달라집니다. 다음 아키텍처 다이어그램은 일반적인 엔터프라이즈 배포를 나타내는 다양한 계정의 여러 VPCs를 포함하는 확장 환경을 보여줍니다.

**기본 설정**

기본 설정에서 다중 계정 AWS 환경에서 하이브리드 DNS 확인을 구현 AWS RAM 하려면를 사용하여 Resolver 전달 규칙과 프라이빗 호스팅 영역 연결을 공유하여 온프레미스와 AWS 리소스 간의 DNS 쿼리를 관리합니다. 이 방법은 온프레미스 네트워크에 연결된 공유 서비스 VPC의 중앙 집중식 Route 53 Resolver 엔드포인트를 사용하여 인바운드 및 아웃바운드 DNS 확인을 효율적으로 처리합니다.
+ 아웃바운드 확인을 위해 Resolver 전달 규칙은 공유 서비스 계정에 생성된 다음 AWS 계정 를 사용하여 다른와 공유됩니다 AWS RAM. 이 공유는 동일한 리전 내의 계정으로 제한됩니다. 그러면 대상 계정은 이러한 규칙을 VPCs와 연결하고 해당 VPCs의 리소스가 온프레미스 도메인 이름을 확인할 수 있습니다.
+ 인바운드 확인을 위해 프라이빗 호스팅 영역은 공유 서비스 계정에 생성되고 공유 서비스 VPC와 연결됩니다. 그런 다음 Route 53 API, AWS SDKs 또는 AWS Command Line Interface ()를 사용하여 이러한 영역을 다른 계정의 VPCs와 연결할 수 있습니다AWS CLI. 그러면 연결된 VPCs의 리소스가 프라이빗 호스팅 영역에 정의된 DNS 레코드를 해석하여 AWS 환경 전체에 통합 DNS 보기를 생성할 수 있습니다.

다음 다이어그램은이 기본 설정의 DNS 확인 흐름을 보여줍니다.

![\[다중 계정 AWS 환경에서 하이브리드 DNS 확인에 대한 기본 설정을 사용합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/258e4bcd-e9c6-43b5-bab8-856ca22206b9.png)


이 설정은 제한된 규모의 DNS 인프라로 작업할 때 효과적입니다. 그러나 환경이 성장함에 따라 관리가 어려울 수 있습니다. 프라이빗 호스팅 영역 및 Resolver 규칙을 공유하고 VPCs와 개별적으로 연결하는 방법을 관리하는 운영 오버헤드는 규모에 따라 크게 증가합니다. 또한 프라이빗 호스팅 영역당 300개의 VPC 연결 한도와 같은Service Quotas는 대규모 배포에서 제약 요인이 될 수 있습니다. 향상된 설정은 이러한 문제를 해결합니다.

**향상된 설정**

Route 53 Profiles는 여러의 하이브리드 네트워크에서 DNS 확인을 관리하기 위한 간소화된 솔루션을 제공합니다 AWS 계정. 프라이빗 호스팅 영역과 해석기 규칙을 개별적으로 관리하는 대신 DNS 구성을 단일 컨테이너로 그룹화하여 리전의 여러 VPCs 및 계정에 쉽게 공유하고 적용할 수 있습니다. 이 설정은 공유 서비스 VPC에서 중앙 집중식 Resolver 엔드포인트 아키텍처를 유지하면서 DNS 구성 관리를 크게 간소화합니다.

다음 다이어그램은 향상된 설정의 DNS 확인 흐름을 보여줍니다.

![\[다중 계정 AWS 환경에서 하이브리드 DNS 확인을 위해 Route 53 Profiles와 함께 고급 설정 사용.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/55b9681d-ddb4-4a55-b4ec-fc9afa9870fa.png)


Route 53 Profiles를 사용하면 프라이빗 호스팅 영역 연결, Resolver 전달 규칙 및 DNS 방화벽 규칙을 공유 가능한 단일 단위로 패키징할 수 있습니다. 공유 서비스 계정에서 프로필을 생성하고를 사용하여 멤버 계정과 공유할 수 있습니다 AWS RAM. 프로필을 공유하여 대상 VPCs에 적용하면 필요한 모든 연결 및 구성이 서비스에서 자동으로 처리됩니다. 이렇게 하면 DNS 관리의 운영 오버헤드가 크게 줄어들고 성장하는 환경에 뛰어난 확장성을 제공할 수 있습니다.

**자동화 및 규모 조정**

 CloudFormation 또는 Terraform과 같은 코드형 인프라(IaC) 도구를 사용하여 Route 53 Resolver 엔드포인트, 규칙, 프라이빗 호스팅 영역 및 프로파일을 자동으로 프로비저닝하고 관리합니다. 일관성, 반복성 및 빠른 업데이트를 위해 DNS 구성을 지속적 통합 및 지속적 전달(CI/CD) 파이프라인과 통합합니다.

## 도구
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-tools"></a>

**AWS 서비스**
+ [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)를 사용하면에서 리소스를 안전하게 공유 AWS 계정 하여 운영 오버헤드를 줄이고 가시성 및 감사 가능성을 제공할 수 있습니다.
+ [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)는 AWS 리소스의 DNS 쿼리에 재귀적으로 응답하며 기본적으로 모든 VPCs. Resolver 엔드포인트와 조건부 전달 규칙을 생성하여 온프레미스 데이터 센터와 VPC 간의 DNS 네임스페이스를 해결할 수 있습니다.
+ [Amazon Route 53 프라이빗 호스팅 영역](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)은 도메인과 그 하위 도메인에 대하여 Route 53의 DNS 쿼리 응답 정보가 담긴 컨테이너입니다.
+ [Amazon Route 53 Profiles](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html)를 사용하면 여러 VPCs하고 관리할 AWS 계정 수 있습니다.

## 모범 사례
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-best-practices"></a>

이 섹션에서는 Route 53 Resolver 최적화를 위한 몇 가지 모범 사례를 제공합니다. 이는 Route 53 모범 사례의 하위 집합을 나타냅니다. 전체 목록은 [Amazon Route 53 모범 사례를 참조하세요](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices.html).

**Resolver 엔드포인트를 사용하여 루프 구성 방지**
+ VPC 연결을 신중하게 계획하여 재귀 라우팅을 방지하도록 DNS 아키텍처를 설계합니다. VPC가 인바운드 엔드포인트를 호스팅하는 경우 순환 참조를 생성할 수 있는 Resolver 규칙과 연결하지 마세요.
+ 계정 간에 DNS 리소스를 공유할 때를 AWS RAM 전략적으로 사용하여 라우팅 경로를 정리합니다.

자세한 내용은 Route 53 설명서의 [Resolver 엔드포인트를 사용한 루프 구성 방지](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoints.html)를 참조하세요.

**Resolver 엔드포인트 크기 조정**
+ QPS(초당 쿼리 수)가 많은 환경의 경우 엔드포인트에서 ENI당 QPS는 10,000개로 제한된다는 점에 유의하세요. 엔드포인트에 더 많은 ENIs를 추가하여 DNS QPS를 확장할 수 있습니다.
+ Amazon CloudWatch는 `InboundQueryVolume` 및 `OutboundQueryVolume` 지표를 제공합니다([CloudWatch 설명서](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html) 참조). 임계값이 특정 값(예: 10,000QPS의 80%)을 초과하는 경우 알림을 보내는 모니터링 규칙을 설정하는 것이 좋습니다.
+ 대용량 트래픽 중에 연결 추적 제한으로 인해 DNS 쿼리 제한이 발생하지 않도록 Resolver 엔드포인트에 대한 상태 저장 보안 그룹 규칙을 구성합니다. 보안 그룹에서 연결 추적이 어떻게 작동하는지 자세히 알아보려면 Amazon EC2 설명서의 [Amazon EC2 보안 그룹 연결 추적](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)을 참조하세요.

자세한 내용은 Route 53 설명서에서 [Resolver 엔드포인트 크기 조정](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-scaling.html)을 참조하세요.

**Resolver 엔드포인트의 고가용성 제공**
+ 중복을 위해 두 개 이상의 가용 영역에 IP 주소를 사용하여 인바운드 엔드포인트를 구성합니다.
+ 추가 네트워크 인터페이스를 프로비저닝하여 유지 관리 또는 트래픽 급증 중에 가용성을 보장합니다.

자세한 내용은 Route 53 설명서의 [Resolver 엔드포인트의 고가용성을](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-high-availability.html) 참조하세요.

## 에픽
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics"></a>

### Route 53 Resolver 엔드포인트 배포
<a name="deploy-r53r-endpoints"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 인바운드 엔드포인트를 배포합니다. | Route 53 Resolver는 인바운드 엔드포인트를 사용하여 온프레미스 DNS 확인자에서 DNS 쿼리를 받습니다. 자세한 지침은 Route 53 설명서의 [인바운드 DNS 쿼리를 VPC에 전달](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html)을 참조하세요. 인바운드 엔드포인트 IP 주소를 기록해 둡니다. | AWS 관리자, 클라우드 관리자 | 
| 아웃바운드 엔드포인트를 배포합니다. | Route 53 Resolver는 아웃바운드 엔드포인트를 사용하여 온프레미스 DNS 확인자에 DNS 쿼리를 보냅니다. 지침은 Route 53 설명서의 [네트워크로 아웃바운드 DNS 쿼리 전달](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html)을 참조하세요. 출력 엔드포인트 ID를 기록해 둡니다. | AWS 관리자, 클라우드 관리자 | 

### Route 53 프라이빗 호스팅 영역 구성 및 공유
<a name="configure-and-share-r53-private-hosted-zones"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 에서 호스팅되는 도메인의 프라이빗 호스팅 영역을 생성합니다 AWS. | 이 영역에는 온프레미스 환경에서 확인되어야 하는 AWS호스팅 도메인(예: `prod.aws.example.com`)의 리소스에 대한 DNS 레코드가 들어 있습니다. 지침은 Route 53 설명서의 [프라이빗 호스팅 영역 생성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)을 참조하세요.프라이빗 호스팅 영역을 생성할 때 VPC를 동일한 계정이 소유한 호스팅 영역과 연결해야 합니다. 이를 위해 공유 서비스 VPC를 선택합니다. | AWS 관리자, 클라우드 관리자 | 
| 기본 설정: 프라이빗 호스팅 영역을 다른 계정의 VPCs와 연결합니다. | 기본 설정을 사용하는 경우( [아키텍처](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture) 섹션 참조):멤버 계정 VPC의 리소스가 이 프라이빗 호스팅 영역의 DNS 레코드를 해결할 수 있도록 지원하려면 VPC를 호스팅 영역과 연결해야 합니다. 연결에 권한을 부여한 다음 프로그래밍 방식으로 연결해야 합니다. 지침은 Route 53 설명서의 [Amazon VPC와 다른 로 생성한 프라이빗 호스팅 영역 연결을 참조하세요 AWS 계정](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html). | AWS 관리자, 클라우드 관리자 | 
| 향상된 설정: Route 53 Profiles를 구성하고 공유합니다. | 향상된 설정을 사용하는 경우( [아키텍처](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture) 섹션 참조):[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)조직의 구조 및 DNS 요구 사항에 따라 여러 계정 또는 워크로드에 대해 여러 프로파일을 생성하고 관리해야 할 수 있습니다. | AWS 관리자, 클라우드 관리자 | 

### Route 53 Resolver 전달 규칙 구성 및 공유
<a name="configure-and-share-r53r-forwarding-rules"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 온프레미스에서 호스팅되는 도메인에 대한 전달 규칙을 생성합니다. | 이 규칙은 Route 53 Resolver가 온프레미스 도메인(예: `onprem.example.com`)에 대한 DNS 쿼리를 온프레미스 DNS 확인자로 전달하도록 지시합니다. 이 규칙을 생성하려면 온프레미스 DNS 확인자의 IP 주소와 아웃바운드 엔드포인트 ID가 필요합니다. 지침은 Route 53 설명서의 [전달 규칙 생성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-creating-rules.html)을 참고하십시오. | AWS 관리자, 클라우드 관리자 | 
| 기본 설정: 전달 규칙을 다른 계정의 VPCs와 공유하고 연결합니다. | 기본 설정을 사용하는 경우:전달 규칙을 적용하려면 규칙을 다른 계정의 VPC와 공유하고 연결해야 합니다. 그러면 Route 53 Resolver는 도메인을 확인할 때 이 규칙을 고려합니다. 지침은 Route 53 설명서의 [다른와 해석기 규칙 공유 AWS 계정 및 공유 규칙 사용](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-sharing.html) 및 [VPC와 전달 규칙 연결을](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-associating-rules.html) 참조하세요. | AWS 관리자, 클라우드 관리자 | 
| 향상된 설정: Route 53 Profiles를 구성하고 공유합니다. | 향상된 설정을 사용하는 경우:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)조직의 구조 및 DNS 요구 사항에 따라 여러 계정 또는 워크로드에 대해 여러 프로파일을 생성하고 관리해야 할 수 있습니다. | AWS 관리자, 클라우드 관리자 | 

### AWS 통합을 위한 온프레미스 DNS 해석기 구성
<a name="configure-on-premises-dns-resolvers-for-aws-integration"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  온프레미스 DNS 확인자에서 조건부 전달을 구성합니다. | 확인을 위해 온프레미스 환경에서 로 DNS 쿼리 AWS 를 전송하려면 인바운드 엔드포인트 IP 주소를 가리키도록 온프레미스 DNS 해석기에서 조건부 전달을 구성해야 합니다. 이렇게 하면 DNS 해석기가 Route 53 Resolver에서 확인할 수 있도록 AWS호스팅 도메인(예:의 경우 `prod.aws.example.com`)에 대한 모든 DNS 쿼리를 인바운드 엔드포인트 IP 주소로 전달하도록 지시합니다. | 네트워크 관리자 | 

### 하이브리드 환경에서 엔드 투 엔드 DNS 확인 검증
<a name="verify-end-to-end-dns-resolution-in-a-hybrid-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 에서 온프레미스 환경 AWS 으로 DNS 확인을 테스트합니다. | 전달 규칙이 연결된 VPC의 인스턴스에서 온프레미스 호스팅 도메인(예: )에 대한 DNS 쿼리를 수행합니다`db.onprem.example.com`. | 네트워크 관리자 | 
| 온프레미스 환경에서 로 DNS 확인을 테스트합니다 AWS. | 온프레미스 서버에서 AWS호스팅 도메인에 대한 DNS 확인을 수행합니다(예:의 경우 `ec2.prod.aws.example.com`). | 네트워크 관리자 | 

## 관련 리소스
<a name="set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-resources"></a>
+ [Amazon VPC용 하이브리드 클라우드 DNS 옵션](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.html)(AWS 백서)
+ [프라이빗 호스팅 영역 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)(Route 53 설명서)
+ [Route 53 Resolver 시작하기](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html)(Route 53 설명서)
+ [Route 53 Resolver를 사용하여 다중 계정 환경에서 DNS 관리 간소화](https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/)(AWS 블로그 게시물)
+ [여러 VPCs 및가 있는 Amazon Route 53 Profiles를 사용하여 DNS 관리 통합 AWS 계정](https://aws.amazon.com/blogs/aws/unify-dns-management-using-amazon-route-53-profiles-with-multiple-vpcs-and-aws-accounts/)(AWS 블로그 게시물)
+ [다중 계정 DNS 환경을 Amazon Route 53 Profiles로 마이그레이션](https://aws.amazon.com/blogs/networking-and-content-delivery/migrating-your-multi-account-dns-environment-to-amazon-route-53-profiles/)(AWS 블로그 게시물)
+ [확장 가능한 다중 계정 AWS 환경에 Amazon Route 53 Profiles 사용](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-route-53-profiles-for-scalable-multi-account-aws-environments/)(AWS 블로그 게시물)

 

# ELB 로드 밸런서에 TLS 터미널이 필요한지 검증합니다
<a name="verify-that-elb-load-balancers-require-tls-termination"></a>

*Priyanka Chaudhary, Amazon Web Services*

## 요약
<a name="verify-that-elb-load-balancers-require-tls-termination-summary"></a>

Amazon Web Services(AWS) 클라우드에서Elastic Load Balancing(ELB)은 들어오는 애플리케이션 트래픽을 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소, AWS Lambda 함수 등 여러 대상에 자동으로 분산합니다. 로드 밸런서는 리스너를 사용하여 로드 밸런서가 사용자의 트래픽을 수락하는 데 사용하는 포트와 프로토콜을 정의합니다. 애플리케이션 로드 밸런서는 애플리케이션 계층에서 라우팅을 결정하고 HTTP/HTTPS 프로토콜을 사용합니다. 클래식 로드 밸런서는 TCP 또는 Secure Sockets Layer(SSL) 프로토콜을 사용하여 전송 계층에서 또는 HTTP/HTTPS를 사용함으로써 애플리케이션 계층에서 라우팅 결정을 내립니다.

이 패턴은 Application Load Balancer 및 Classic Load Balancer에 대한 여러 이벤트 유형을 검사하는 보안 제어를 제공합니다. 함수가 호출되면 AWS Lambda는 이벤트를 검사하고 로드 밸런서가 규정을 준수하는지 확인합니다.

함수는 API 직접 호출 ([CreateLoadBalancer](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancer.html), [CreateLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerListeners.html), [DeleteLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_DeleteLoadBalancerListeners.html), [CreateLoadBalancerPolicy](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerPolicy.html), [SetLoadBalancerPoliciesOfListener](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_SetLoadBalancerPoliciesOfListener.html), [CreateListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_CreateListener.html), [DeleteListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_DeleteListener.html), 및 [ModifyListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ModifyListener.html))에서 Amazon CloudWatch Events 이벤트를 시작합니다. 이벤트가 이러한 API 중 하나를 감지하면 Python 스크립트를 실행하는 AWS Lambda를 호출합니다. Python 스크립트는 리스너에 SSL 인증서가 포함되어 있는지, 적용된 정책이 전송 계층 보안(TLS)을 사용하는지 여부를 평가합니다. SSL 정책이 TLS가 아닌 것으로 확인되면 함수는 관련 정보와 함께 Amazon Simple Notification Service(SNS) 알림을 사용자에게 보냅니다. 

## 사전 조건 및 제한 사항
<a name="verify-that-elb-load-balancers-require-tls-termination-prereqs"></a>

**사전 조건 **
+ 활성 상태의 AWS 계정

**제한 사항 **
+ 이 보안 제어는 로드 밸런서 리스너를 업데이트하지 않는 한 기존 로드 밸런서를 확인하지 않습니다.
+ 이 보안 제어는 리전별로 적용됩니다. 모니터링하려는 각 AWS 리전에 이를 배포해야 합니다.

## 아키텍처
<a name="verify-that-elb-load-balancers-require-tls-termination-architecture"></a>

**대상 아키텍처**

![\[ELB 로드 밸런서에 TLS 터미널이 필요한지 검증합니다\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/da99cda2-ac34-4791-a2bd-d37264d8d3d9/images/af92b3c8-32bb-45eb-a2a8-d8276fb3e824.png)


**자동화 및 규모 조정**
+ [AWS Organizations](https://aws.amazon.com/organizations/)를 사용하는 경우 [AWS Cloudformation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)를 사용하여 모니터링하려는 여러 계정에 이 템플릿을 배포할 수 있습니다.

## 도구
<a name="verify-that-elb-load-balancers-require-tls-termination-tools"></a>

**서비스**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) - AWS CloudFormation을 사용하면 AWS 리소스를 모델링 및 설정하고, 빠르고 일관되게 프로비저닝하고, 수명 주기 전반에 걸쳐 관리할 수 있습니다. 템플릿을 사용하여 리소스와 해당 종속성을 설명하고 리소스를 개별적으로 관리하는 대신 스택으로 함께 시작 및 구성할 수 있습니다.
+ [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – Amazon CloudWatch Events는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트의 스트림을 거의 실시간으로 제공합니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) - AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있도록 지원하는 컴퓨팅 서비스입니다.
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)-Amazon Simple Storage Service(S3)는 웹 사이트, 모바일 애플리케이션, 백업, 데이터 레이크 등 다양한 스토리지 솔루션에 사용할 수 있는 확장성이 뛰어난 객체 스토리지 서비스입니다.
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) – Amazon Simple Notification Service(SNS)는 웹 서버와 이메일 주소를 포함하여 게시자와 클라이언트 간에 메시지를 전달 또는 전송하는 것을 조정하고 관리합니다. 구독자는 구독하는 주제에 게시된 모든 메시지를 수신하며 주제에 대한 모든 구독자는 동일한 메시지를 수신합니다.

**코드**

이 패턴에는 다음과 같은 첨부 파일이 포함됩니다.
+ `ELBRequirestlstermination.zip` - 보안 제어를 위한 Lambda 코드입니다.
+ `ELBRequirestlstermination.yml` - 이벤트 및 Lambda 함수를 설정하는 CloudFormation 템플릿입니다.

## 에픽
<a name="verify-that-elb-load-balancers-require-tls-termination-epics"></a>

### S3 버킷을 설정합니다.
<a name="set-up-the-s3-bucket"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| S3 버킷을 정의합니다. | [Amazon S3 콘솔](https://console.aws.amazon.com/s3/)에서 Lambda 코드 .zip 파일을 호스팅할 S3 버킷을 선택하거나 생성합니다. 이 S3 버킷은 평가하려는 로드 밸런서와 동일한 AWS 리전에 있어야 합니다. S3 버킷 이름은 전역 수준에서 고유하며, 네임스페이스는 모든 AWS 계정이 공유합니다. S3 버킷 이름에는 선행 슬래시를 포함할 수 없습니다. | 클라우드 아키텍트 | 
| Lambda 코드를 업로드합니다. | *첨부 파일* 섹션에 제공된 Lambda 코드(`ELBRequirestlstermination.zip` 파일)를 S3 버킷에 업로드합니다. | 클라우드 아키텍트 | 

### CloudFormation 템플릿 배포
<a name="deploy-the-cloudformation-template"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| AWS CloudFormation 템플릿을 실행합니다. | S3 버킷과 동일한 AWS 리전에서 [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 열고 첨부된 템플릿 `ELBRequirestlstermination.yml`을 배포합니다. AWS CloudFormation 템플릿 배포에 대한 자세한 내용은 CloudFormation 설명서의 [AWS CloudFormation 콘솔에서 스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)을 참조하세요. | 클라우드 아키텍트 | 
| 템플릿에서 파라미터를 작성합니다. | 템플릿을 시작하면 다음 정보를 입력하라는 메시지가 표시됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/verify-that-elb-load-balancers-require-tls-termination.html) | 클라우드 아키텍트 | 

### 구독 확인
<a name="confirm-the-subscription"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 구독을 확인합니다. | CloudFormation 템플릿이 성공적으로 배포되면 입력한 이메일 주소로 구독 이메일이 전송됩니다. 위반 알림을 받기 시작하려면 이 이메일 구독을 확인해야 합니다. | 클라우드 아키텍트 | 

## 관련 리소스
<a name="verify-that-elb-load-balancers-require-tls-termination-resources"></a>
+ [AWS CloudFormation 콘솔에서 스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)(AWS CloudFormation 설명서)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) (AWS Lambda 설명서)
+ [Classic Load Balancer란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html) (ELB 설명서)
+ [Application Load Balancer란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) (ELB 설명서)

## 첨부
<a name="attachments-da99cda2-ac34-4791-a2bd-d37264d8d3d9"></a>

이 문서와 관련된 추가 콘텐츠에 액세스하려면 [attachment.zip](samples/p-attach/da99cda2-ac34-4791-a2bd-d37264d8d3d9/attachments/attachment.zip) 파일의 압축을 풉니다.

# Splunk를 사용하여 AWS Network Firewall 로그 및 지표 보기
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk"></a>

*Ivo Pinto, Amazon Web Services*

## 요약
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-summary"></a>

많은 조직에서 [Splunk Enterprise](https://www.splunk.com/en_us/products/splunk-enterprise.html)를 다양한 소스의 로그 및 지표에 대한 중앙 집중식 집계 및 시각화 도구로 사용합니다.이 패턴을 사용하면 AWS용 Splunk 추가 기능을 사용하여 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)에서 AWS [Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) 로그 및 지표를 가져오도록 Splunk를 구성할 수 있습니다. 

이를 위해 읽기 전용 AWS Identity and Access Management(IAM) 역할을 생성합니다. AWS용 Splunk 추가 기능은이 역할을 사용하여 CloudWatch에 액세스합니다. CloudWatch에서 지표와 로그를 가져오도록 AWS용 Splunk 추가 기능을 구성합니다. 마지막으로 검색된 로그 데이터 및 지표에서 Splunk의 시각화를 생성합니다.

## 사전 조건 및 제한 사항
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-prereqs"></a>

**사전 조건 **
+ [Splunk](https://www.splunk.com/) 계정
+ Splunk Enterprise 인스턴스, 버전 8.2.2 이상 
+ 활성 상태의 AWS 계정
+ CloudWatch Logs로 로그를 전송하도록 [설정](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html) 및 [구성된](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-cw-logs.html) Network Firewall

**제한 사항 **
+ Splunk Enterprise는 AWS 클라우드에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 클러스터로 배포해야 합니다.
+ Amazon EC2에 대해 자동으로 검색된 IAM 역할을 사용하여 데이터를 수집하는 것은 AWS 중국 리전에서 지원되지 않습니다.

## 아키텍처
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-architecture"></a>

![\[AWS Network Firewall 및 Splunk 로깅 아키텍처\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/c6ce254a-841f-4bed-8f9f-b35e99f22e56/images/3dd420e9-70af-4a42-b24d-c54872c55e0b.png)


다이어그램은 다음을 보여 줍니다.

1. Network Firewall은 CloudWatch Logs에 로그를 게시합니다.

1. Splunk Enterprise는 CloudWatch에서 지표와 로그를 검색합니다.

이 아키텍처에서 예시 지표와 로그를 채우기 위해 워크로드는 Network Firewall 엔드포인트를 통과하여 인터넷으로 이동하는 트래픽을 생성합니다. 이는 [라우팅 테이블](https://docs.aws.amazon.com/network-firewall/latest/developerguide/vpc-config.html#vpc-config-route-tables)을 사용하여 달성됩니다.이 패턴은 단일 Amazon EC2 인스턴스를 워크로드로 사용하지만, Network Firewall이 CloudWatch Logs로 로그를 전송하도록 구성된 한이 패턴은 모든 아키텍처에 적용될 수 있습니다.

또한이 아키텍처는 다른 Virtual Private Cloud(VPC)의 Splunk Enterprise 인스턴스를 사용합니다. 그러나 Splunk 인스턴스는 CloudWatch API에 도달할 수 있는 한 같은 VPC와 같은 다른 위치에 있을 수 있습니다.

## 도구
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-tools"></a>

**서비스**
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)는 모든 시스템, 애플리케이션 및 AWS 서비스의 로그를 중앙 집중화하여 모니터링하고 안전하게 보관할 수 있도록 도와줍니다.
+ [Amazon Elastic Compute Cloud(Amazon EC2)](https://docs.aws.amazon.com/ec2/)‬는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 필요한 만큼 가상 서버를 시작하고 빠르게 스케일 업하거나 스케일 다운할 수 있습니다.
+ [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html)은 AWS Cloud를 위한 상태 저장형, 관리형 네트워크 방화벽이자, 침입 탐지 및 방지 서비스입니다.

**기타 도구**
+ [Splunk](https://www.splunk.com/)는 로그 데이터를 모니터링, 시각화 및 분석하는 데 도움이 됩니다.

## 에픽
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-epics"></a>

### IAM 역할 생성
<a name="create-an-iam-role"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| IAM 정책을 생성합니다. | [JSON 편집기를 사용하여 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)의 지침에 따라 CloudWatch Logs 데이터 및 CloudWatch 지표에 대한 읽기 전용 액세스 권한을 부여하는 IAM 정책을 생성합니다. 다음 정책을 JSON 편집기에 붙여넣습니다.<pre>{<br />    "Statement": [<br />        {<br />            "Action": [<br />                "cloudwatch:List*",<br />                "cloudwatch:Get*",<br />                "network-firewall:List*",<br />                "logs:Describe*",<br />                "logs:Get*",<br />                "logs:List*",<br />                "logs:StartQuery",<br />                "logs:StopQuery",<br />                "logs:TestMetricFilter",<br />                "logs:FilterLogEvents",<br />                "network-firewall:Describe*"<br />            ],<br />            "Effect": "Allow",<br />            "Resource": "*"<br />        }<br />    ],<br />    "Version": "2012-10-17"<br />}</pre> | 관리자 | 
| 새 IAM 역할을 생성합니다. | [AWS 서비스에 권한을 위임하는 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)의 지침에 따라 AWS용 Splunk 추가 기능이 CloudWatch에 액세스하는 데 사용하는 IAM 역할을 생성합니다. **권한 정책**에서 사용자가 만든 정책을 선택합니다. | 관리자 | 
| Splunk 클러스터의 EC2 인스턴스에 IAM 역할을 할당합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | 관리자 | 

### AWS WAF용 애드온을 설치합니다.
<a name="install-the-splunk-add-on-for-aws"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
|  추가 기능을 설치합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 관리자 | 
| AWS 보안 인증 정보를 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)자세한 내용은 [Splunk 설명서의 Splunk 플랫폼 인스턴스에서 IAM 역할 찾기를 참조하세요](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Find_an_IAM_role_within_your_Splunk_platform_instance). | Splunk 관리자 | 

### CloudWatch에 대한 Splunk 액세스 구성
<a name="configure-splunk-access-to-cloudwatch"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| CloudWatch Logs에서 Network Firewall 로그 검색을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)기본적으로 Splunk는 10분마다 로그 데이터를 가져옵니다. 이는 **고급 설정**에서 구성 가능한 파라미터입니다. 자세한 내용은 [Splunk 설명서의 Splunk Web을 사용하여 CloudWatch Logs 입력 구성을](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_Logs_input_using_Splunk_Web) 참조하세요. | Splunk 관리자 | 
| CloudWatch에서 Network Firewall 지표 검색을 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)기본적으로 Splunk는 5분마다 지표 데이터를 가져옵니다. 이는 **고급 설정**에서 구성 가능한 파라미터입니다. 자세한 내용은 [Splunk 설명서의 Splunk Web을 사용하여 CloudWatch 입력 구성을](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_input_using_Splunk_Web) 참조하세요. | Splunk 관리자 | 

### 쿼리를 사용하여 Splunk 시각화 생성
<a name="create-splunk-visualizations-by-using-queries"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 상위 소스 IP 주소를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 관리자 | 
| 패킷 통계를 봅니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 관리자 | 
| 가장 많이 사용되는 소스 포트를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 관리자 | 

## 관련 리소스
<a name="view-aws-network-firewall-logs-and-metrics-by-using-splunk-resources"></a>

**AWS 설명서**
+ [역할을 생성하여 IAM 사용자에게 권한 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)(IAM 설명서)
+ [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-start)(IAM 설명서)
+ [AWS Network Firewall의 로깅 및 모니터링](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-monitoring.html)(Network Firewall 설명서)
+ [AWS Network Firewall의 라우팅 테이블 구성](https://docs.aws.amazon.com/network-firewall/latest/developerguide/route-tables.html)(Network Firewall 설명서)

**AWS Blog 게시물**
+ [AWS Network Firewall 배포 모델](https://aws.amazon.com/pt/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)

**AWS Marketplace**
+ [Splunk Enterprise Amazon Machine Image(AMI)](https://aws.amazon.com/marketplace/pp/prodview-l6oos72bsyaks)

# 패턴 더 보기
<a name="networking-more-patterns-pattern-list"></a>

**Topics**
+ [Session Manager 및 Amazon EC2 인스턴스 연결을 사용한 Bastion Host 액세스](access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.md)
+ [AWS Fargate, AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md)
+ [AWS PrivateLink 및 Network Load Balancer를 사용하여 Amazon ECS에서 컨테이너 애플리케이션에 비공개로 액세스](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md)
+ [AWS Managed Microsoft AD 및 온프레미스 Microsoft Active Directory를 사용하여 DNS 확인 중앙 집중화](centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.md)
+ [AWS Amplify, Angular 및 Module Federation을 사용하여 마이크로 프런트엔드용 포털 생성](create-amplify-micro-frontend-portal.md)
+ [프라이빗 엔드포인트와 Application Load Balancer 사용하여 내부 웹 사이트에 Amazon API Gateway API 배포](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md)
+ [를 사용하여 퍼블릭 서브넷에 대한 탐지 속성 기반 액세스 제어 배포 AWS Config](deploy-detective-attribute-based-access-controls-for-public-subnets-by-using-aws-config.md)
+ [퍼블릭 서브넷에 대한 예방적 속성 기반 액세스 제어 배포](deploy-preventative-attribute-based-access-controls-for-public-subnets.md)
+ [Amazon RDS에서 PostgreSQL DB 인스턴스에 대한 암호화된 연결 활성화하기](enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.md)
+ [AWS Transit Gateway Connect를 사용하여 VRF를 AWS로 확장](extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.md)
+ [에서 F5 BIG-IP 워크로드를 F5 BIG-IP VE로 마이그레이션 AWS 클라우드](migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.md)
+ [Amazon EKS Auto Mode를 활성화할 때 NGINX 수신 컨트롤러 마이그레이션](migrate-nginx-ingress-controller-eks-auto-mode.md)
+ [비 워크로드 서브넷을 위한 다중 계정 VPC 설계에서 라우팅 가능한 IP 공간 보존](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md)
+ [서비스 제어 정책을 사용하여 계정 수준에서 인터넷 액세스 방지](prevent-internet-access-at-the-account-level-by-using-a-service-control-policy.md)
+ [AWS Network Firewall에서 Slack 채널로 알림 전송](send-alerts-from-aws-network-firewall-to-a-slack-channel.md)
+ [Amazon CloudFront를 사용하여 VPC를 통해 Amazon S3 버킷의 정적 콘텐츠 제공하기](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md)
+ [AWS Elastic Disaster Recovery를 사용하여 Oracle JD Edwards EnterpriseOne에 대한 재해 복구 설정](set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.md)
+ [BMC Discovery 쿼리를 사용하여 마이그레이션 계획을 위한 마이그레이션 데이터 추출](use-bmc-discovery-queries-to-extract-migration-data-for-migration-planning.md)
+ [Network Firewall을 사용하여 아웃바운드 트래픽의 Server Name Indication에서 DNS 도메인 이름 캡처](use-network-firewall-to-capture-the-dns-domain-names-from-the-server-name-indication-sni-for-outbound-traffic.md)

# 콘텐츠 전송
<a name="contentdelivery-pattern-list"></a>

**Topics**
+ [AWS Firewall Manager 및 Amazon Data Firehose를 사용하여 Splunk로 AWS WAF 로그 전송](send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.md)
+ [Amazon CloudFront를 사용하여 VPC를 통해 Amazon S3 버킷의 정적 콘텐츠 제공하기](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md)
+ [패턴 더 보기](contentdelivery-more-patterns-pattern-list.md)

# AWS Firewall Manager 및 Amazon Data Firehose를 사용하여 Splunk로 AWS WAF 로그 전송
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose"></a>

*Michael Friedenthal, Aman Kaur Gandhi, JJ Johnson, Amazon Web Services*

## 요약
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-summary"></a>

과거에는 데이터를 Splunk로 이동하는 두 가지 방법, 즉 푸시 아키텍처 또는 풀 아키텍처가 있었습니다. *풀 아키텍처*는 재시도를 통해 전송 데이터를 보장하지만 Splunk에서 데이터를 폴링하는 전용 리소스가 필요합니다. 일반적으로 풀 아키텍처는 폴링으로 인해 실시간이 아닙니다. *푸시 아키텍처*는 일반적으로 지연 시간이 짧고 확장성이 뛰어나며 운영 복잡성과 비용을 줄여줍니다. 하지만 전송이 보장되는 것은 아니며 일반적으로 에이전트가 필요합니다.

Amazon Data Firehose와 Splunk의 통합은 HTTP 이벤트 수집기(HEC)를 통해 Splunk에 실시간 스트리밍 데이터를 제공합니다. 이 통합은 푸시 아키텍처와 풀 아키텍처의 장점을 모두 제공합니다. 즉, 재시도를 통한 데이터 전송을 보장하고 실시간에 가깝고 지연 시간이 짧고 복잡성이 낮습니다. HEC는 HTTP 또는 HTTPS를 통해 빠르고 효율적으로 데이터를 Splunk로 직접 전송합니다. HEC는 토큰 기반이므로 애플리케이션이나 지원 파일에 보안 인증 정보를 하드코딩할 필요가 없습니다.

 AWS Firewall Manager 정책에서 모든 계정의 모든 AWS WAF 웹 ACL 트래픽에 대한 로깅을 구성한 다음 Firehose 전송 스트림을 사용하여 모니터링, 시각화 및 분석을 위해 해당 로그 데이터를 Splunk로 전송할 수 있습니다. 이 솔루션에는 다음과 같은 이점이 있습니다.
+ 모든 계정의 AWS WAF 웹 ACL 트래픽에 대한 중앙 관리 및 로깅
+ Splunk와 단일 통합 AWS 계정
+ 확장성
+ 거의 실시간으로 로그 데이터 전송
+ 서버리스 솔루션을 사용하여 비용을 최적화하므로 사용하지 않은 리소스에 대해 비용을 지불할 필요가 없습니다.

## 사전 조건 및 제한 사항
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-prereqs"></a>

**사전 조건 **
+ 조직의 일부 AWS 계정 인 활성 입니다 AWS Organizations.
+ Firehose로 로깅을 활성화하려면 다음 권한으로 로그인해야 합니다.
  + `iam:CreateServiceLinkedRole`
  + `firehose:ListDeliveryStreams`
  + `wafv2:PutLoggingConfiguration`
+ AWS WAF 및 웹 ACLs 구성해야 합니다. 지침은 [시작하기를 참조하세요 AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html).
+ AWS Firewall Manager 를 설정해야 합니다. 지침은 [AWS Firewall Manager 사전 요구 사항](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html)을 참조하세요.
+ 에 대한 Firewall Manager 보안 정책을 구성해야 AWS WAF 합니다. 지침은 [AWS Firewall ManagerAWS WAF 정책 시작하기를 참조하세요](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html).
+ Splunk는 Firehose에서 연결할 수 있는 공개 HTTP 엔드포인트로 설정해야 합니다.

**제한 사항 **
+ 는의 단일 조직에서 관리해야 AWS 계정 합니다 AWS Organizations.
+ 웹 ACL은 전송 스트림과 동일한 리전에 있어야 합니다. Amazon CloudFront에 로그를 캡처하는 경우 미국 동부(버지니아 북부) 리전 `us-east-1`에서 Firehose 전송 스트림을 생성하십시오.
+ Firehose용 Splunk 애드온은 유료 Splunk 클라우드 배포, 분산형 Splunk Enterprise 배포 및 단일 인스턴스 Splunk Enterprise 배포에 사용할 수 있습니다. 이 애드온은 무료 평가판 Splunk Cloud 배포에는 지원되지 않습니다.

## 아키텍처
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-architecture"></a>

**대상 기술 스택**
+ Firewall Manager
+ Firehose
+ Amazon Simple Storage Service(Amazon S3)
+ AWS WAF
+ Splunk

**대상 아키텍처 **

다음 이미지는 Firewall Manager를 사용하여 모든 AWS WAF 데이터를 중앙에서 로깅하고 Firehose를 통해 Splunk로 전송하는 방법을 보여줍니다.

![\[Amazon Data Firehose를 통해 Splunk로 AWS WAF 로그 데이터를 보내는 것을 보여주는 아키텍처 다이어그램\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/3dfeaae0-985a-42b8-91c4-ece081f0b51b/images/669169b1-caa4-419b-9988-19806ded54eb.png)


1.  AWS WAF 웹 ACLs은 방화벽 로그 데이터를 Firewall Manager로 전송합니다.

1. Firewall Manager는 Firehose로 로그 데이터를 전송합니다.

1. Firehose 전송 스트림은 로그 데이터를 Splunk와 S3 버킷으로 전달합니다. S3 버킷은 Firehose 전송 스트림에 오류가 발생하는 경우 백업 역할을 합니다.

**자동화 및 규모 조정**

이 솔루션은 조직 내 모든 AWS WAF 웹 ALCs를 확장하고 수용하도록 설계되었습니다. 모든 웹 ACL이 동일한 Firehose 인스턴스를 사용하도록 구성할 수 있습니다. 하지만 여러 Firehose 인스턴스를 설정하고 사용하려는 경우에는 그렇게 할 수 있습니다.

## 도구
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-tools"></a>

**AWS 서비스**
+ [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)는의 계정 및 애플리케이션에서 방화벽 규칙을 중앙에서 구성하고 관리하는 데 도움이 되는 보안 관리 서비스입니다 AWS Organizations.
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)를 사용하면 Splunk와 같은 지원되는 타사 서비스 공급자가 소유한 다른 AWS 서비스사용자 지정 HTTP 엔드포인트 및 HTTP 엔드포인트에 실시간 [스트리밍 데이터를](https://aws.amazon.com/streaming-data/) 제공할 수 있습니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)는 보호되는 웹 애플리케이션 리소스로 전달되는 HTTP 및 HTTPS 요청을 모니터링할 수 있게 해주는 웹 애플리케이션 방화벽입니다.

**기타 도구**
+ [Splunk](https://docs.splunk.com/Documentation)는 로그 데이터를 모니터링, 시각화 및 분석하는 데 도움이 됩니다.

## 에픽
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-epics"></a>

### Splunk 구성
<a name="configure-splunk"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 용 Splunk 앱을 설치합니다 AWS. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html) | 보안 관리자, Splunk 관리자 | 
| 에 대한 추가 기능을 설치합니다 AWS WAF. | 이전 지침을 반복하여 Splunk용 **AWS 웹 애플리케이션 방화벽 추가 기능**을 설치합니다. | 보안 관리자, Splunk 관리자 | 
| Firehose용 Splunk 추가 기능을 설치하고 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html) | 보안 관리자, Splunk 관리자 | 

### Firehose 전송 스트림 생성
<a name="create-the-akf-delivery-stream"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Firehose에 Splunk 대상에 대한 액세스 권한을 부여합니다. | Firehose가 Splunk 대상에 액세스하고 로그 데이터를 S3 버킷에 백업할 수 있도록 허용하는 액세스 정책을 구성합니다. 자세한 정보는 [Firehose에 Splunk 대상에 대한 액세스 권한 부여](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-splunk)를 참조하세요. | 보안 관리자 | 
| Firehose 전송 스트림을 생성합니다. | 웹 ACLs을 관리하는 동일한 계정에서 Firehose에 전송 스트림을 AWS WAF생성합니다. 전송 스트림을 생성할 때 IAM 역할을 보유하고 있어야 합니다. Firehose는 이 IAM 역할을 사용하여 지정된 S3 버킷에 대한 액세스 권한을 얻습니다. 지침은 [전송 스트림 생성](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)을 참고하십시오. 다음 사항에 유의하세요.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose.html)HTTP 이벤트 컬렉터에서 구성한 각 토큰에 대해 이 프로세스를 반복합니다. | 보안 관리자 | 
| 전송 스트림을 테스트합니다. | 전송 스트림을 테스트하여 제대로 구성되었는지 확인합니다. 지침은 Firehose 설명서에서 [Splunk를 대상으로 사용하여 테스트하기](https://docs.aws.amazon.com/firehose/latest/dev/test-drive-firehose.html#test-drive-destination-splunk)를 참고하십시오. | 보안 관리자 | 

### 데이터를 기록하기 위해 Firewall Manager 구성
<a name="configure-firewall-manager-to-log-data"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| Firewall Manager 정책을 구성합니다. | 로깅을 활성화하고 로그를 올바른 Firehose 전송 스트림으로 전달하도록 Firewall Manager 정책을 구성해야 합니다. 자세한 내용과 지침은 [AWS WAF 정책에 대한 로깅 구성을 참조하세요](https://docs.aws.amazon.com/waf/latest/developerguide/waf-policies.html#waf-policies-logging-config). | 보안 관리자 | 

## 관련 리소스
<a name="send-aws-waf-logs-to-splunk-by-using-aws-firewall-manager-and-amazon-data-firehose-resources"></a>

**AWS resources**
+ [웹 ACL 트래픽 로깅](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)(AWS WAF 문서)
+ [AWS WAF 정책에 대한 로깅 구성](https://docs.aws.amazon.com/waf/latest/developerguide/waf-policies.html#waf-policies-logging-config)(AWS WAF 문서)
+ [자습서: Amazon Data Firehose를 사용하여 Splunk에 VPC 흐름 로그 전송](https://docs.aws.amazon.com/firehose/latest/dev/vpc-splunk-tutorial.html)(Firehose 설명서)
+ [Amazon Data Firehose를 사용하여 Splunk에 VPC 흐름 로그를 푸시하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/push-flow-logs-splunk-firehose/) (AWS 지식 센터)
+ [Amazon Data Firehose를 사용하여 Splunk로 데이터 수집 강화](https://aws.amazon.com/blogs/big-data/power-data-ingestion-into-splunk-using-amazon-kinesis-data-firehose/)(AWS 블로그 게시물)

**Splunk 설명서**
+ [Amazon Data Firehose용 Splunk 추가 기능](https://docs.splunk.com/Documentation/AddOns/released/Firehose/About)

# Amazon CloudFront를 사용하여 VPC를 통해 Amazon S3 버킷의 정적 콘텐츠 제공하기
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront"></a>

*Angel Emmanuel Hernandez Cebrian, Amazon Web Services*

## 요약
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-summary"></a>

Amazon Web Services(AWS)에서 호스팅되는 정적 콘텐츠를 제공하는 경우 Amazon Simple Storage Service(S3) 버킷을 오리진으로 사용하고 Amazon CloudFront를 사용하여 콘텐츠를 배포하는 것이 좋습니다. 이 솔루션은 엣지 로케이션에서 정적 콘텐츠를 캐싱하는 편의성과 CloudFront 배포를 위한 [웹 액세스 제어 목록](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)(웹 ACL)을 정의하는 기능이라는 두 가지 주요 이점을 제공하므로 구성 및 관리 오버헤드를 최소화하면서 콘텐츠에 대한 요청을 보호할 수 있습니다.

하지만 권장되는 표준 접근 방식에는 일반적인 아키텍처 제한이 있습니다. 일부 환경에서 사용자는 가상 사설 클라우드(VPC)에 배포된 가상 방화벽 어플라이언스가 정적 콘텐츠를 포함한 모든 콘텐츠를 검사하기를 원합니다. 표준 접근 방식은 검사를 위해 VPC를 통해 트래픽을 라우팅하지 않습니다. 이 패턴은 대체 아키텍처 솔루션을 제공합니다. 여전히 CloudFront 배포를 사용하여 S3 버킷의 정적 콘텐츠를 제공하지만, Application Load Balancer를 사용하여 VPC를 통해 트래픽이 라우팅됩니다. 그러면 AWS Lambda 함수가 S3 버킷에서 콘텐츠를 검색하고 반환합니다.

## 사전 조건 및 제한 사항
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-prereqs"></a>

**사전 조건 **
+ 활성 상태의 계정
+ S3 버킷에 호스팅된 정적 웹 사이트 콘텐츠.

**제한 사항 **
+ 이 패턴의 리소스는 단일 AWS 리전에 있어야 하지만 다른 AWS 계정에서 프로비저닝할 수 있습니다.
+ 제한은 Lambda 함수가 수신하고 전송할 수 있는 최대 요청 및 응답 크기에 각각 적용됩니다. 자세한 내용은 [대상으로서의 Lambda 함수의](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html) *제한*(Elastic Load Balancing 설명서)을 참고하십시오.
+ 이 접근 방식을 사용할 때는 성능, 확장성, 보안 및 비용 효율성 간에 적절한 균형을 찾는 것이 중요합니다. Lambda의 높은 확장성에도 불구하고 동시 Lambda 호출 수가 최대 할당량을 초과하는 경우 일부 요청에는 병목 현상이 발생합니다. 자세한 내용은 Lambda 할당량(Lambda 설명서)를 참고하십시오. Lambda를 사용할 때는 요금도 고려해야 합니다. Lambda 호출을 최소화하려면 CloudFront 배포에 대한 캐시를 올바르게 정의해야 합니다. 자세한 내용은 [캐싱 및 가용성 최적화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)(CloudFront 설명서)를 참고하십시오.

## 아키텍처
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-architecture"></a>

**대상 기술 스택  **
+ CloudFront
+ Amazon Virtual Private Cloud(Amazon VPC)
+ Application Load Balancer
+ Lambda
+ Amazon S3

**대상 아키텍처**

다음 이미지는 CloudFront를 사용하여 VPC를 통해 S3 버킷의 정적 콘텐츠를 제공해야 할 때 제안되는 아키텍처를 보여줍니다.

![\[VPC의 애플리케이션 로드 밸런서를 통해 Lambda 함수로 가는 트래픽 플로우입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/e0dd6928-4fe0-47ab-954f-9de5563349d8/images/b42c7dd9-4a72-4998-bf88-195c8f90ed3e.png)


1. 클라이언트는 S3 버킷의 특정 웹 사이트 파일을 가져오기 위해 CloudFront 배포의 URL을 요청합니다.

1. CloudFront는 AWS WAF에 요청을 전송합니다. AWS WAF는 CloudFront 배포에 적용된 웹 ACL을 사용하여 요청을 필터링합니다. 요청이 유효한 것으로 확인되면 플로우가 계속됩니다. 요청이 유효하지 않은 것으로 확인되면 클라이언트는 403 오류를 수신합니다.

1. CloudFront가 내부 캐시를 확인합니다. 수신 요청과 일치하는 유효한 키가 있는 경우 관련 값이 클라이언트에 응답으로 다시 전송됩니다. 그렇지 않은 경우에는 플로우가 계속됩니다.

1. CloudFront는 지정된 애플리케이션 로드 밸런서의 URL에 요청을 전달합니다.

1. Application Load Balancer에는 Lambda 함수를 기반으로 하는 대상 그룹과 연결된 리스너가 있습니다. 애플리케이션 로드 밸런서는 Lambda 함수를 호출합니다.

1. Lambda 함수는 S3 버킷에 연결하여 `GetObject` 작업을 수행하고 콘텐츠를 응답으로 반환합니다.

**자동화 및 규모 조정**

이 접근 방식을 사용하여 정적 콘텐츠 배포를 자동화하려면 CI/CD 파이프라인을 생성하여 웹사이트를 호스팅하는 Amazon S3 버킷을 업데이트하십시오.

Lambda 함수는 서비스의 할당량 및 한도 내에서 동시 요청을 처리하도록 자동으로 확장됩니다. 자세한 내용은 [Lambda 함수 조정](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html) 및 [Lambda 할당량](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)(Lambda 설명서)을 참조하세요. CloudFront 및 Application Load Balancer와 같은 다른 AWS 서비스 및 특징의 경우 AWS는 이러한 서비스 및 특징을 자동으로 조정합니다.

## 도구
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-tools"></a>
+ [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)는 전 세계 데이터 센터 네트워크를 통해 웹 콘텐츠를 전송함으로써 웹 콘텐츠 배포 속도를 높여 지연 시간을 줄이고 성능을 개선합니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 이 패턴에서는 Elastic Load Balancing을 통해 프로비저닝된 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)를 사용하여 트래픽을 Lambda 함수로 전달합니다.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하는 데 도움이 되는 컴퓨팅 서비스입니다. 필요할 때만 코드를 실행하며 자동으로 확장이 가능하므로 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [Amazon Virtual Private Cloud(VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 사용자의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하며 AWS의 확장 가능한 인프라를 사용한다는 이점이 있습니다.

## 에픽
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-epics"></a>

### CloudFront를 사용하면 VPC를 통해 Amazon S3의 정적 콘텐츠를 제공할 수 있습니다.
<a name="use-cloudfront-to-serve-static-content-from-amazon-s3-through-a-vpc"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| VPC를 생성합니다. | 이 패턴으로 배포된 리소스(예: Application Load Balancer 및 Lambda 함수)를 호스팅하기 위한 VPC를 생성합니다.  지침은 [VPC 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)(Amazon VPC 설명서)을 참고하십시오. | 클라우드 아키텍트 | 
| AWS WAF 웹 ACL을 생성합니다. | AWS WAF 웹 ACL을 생성합니다. 나중에 이 패턴에서 이 웹 ACL을 CloudFront 배포에 적용합니다. 지침은 [웹 ACL 생성](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html)(AWS WAF 설명서)을 참고하십시오. | 클라우드 아키텍트 | 
| Lambda 함수를 생성합니다. | S3 버킷에 호스팅된 정적 콘텐츠를 웹사이트로 제공하는 Lambda 함수를 생성합니다. 이 패턴의 [추가 정보](#serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-additional) 섹션에 제공되는 코드를 사용합니다. 대상 S3 버킷을 식별하도록 코드를 사용자 지정합니다. | 일반 AWS | 
| Lambda 함수를 업로드합니다. | 다음 명령을 입력하여 Lambda 함수 코드를 Lambda의 .zip 파일 아카이브에 업로드합니다.<pre>aws lambda update-function-code \<br />--function-name  \ <br />--zip-file fileb://lambda-alb-s3-website.zip</pre> | 일반 AWS | 
| Application Load Balancer을 생성합니다. | Lambda 함수를 가리키는 인터넷 연결 애플리케이션 로드 밸런서를 생성합니다. 지침은 [Lambda 함수의 대상 그룹 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html#register-lambda-function)(Elastic Load Balancing 설명서)을 참고하십시오. 가용성이 높은 구성을 하기 위해 Application Load Balancer를 생성하고 이를 다른 가용 영역의 개인 서브넷에 연결합니다. | 클라우드 아키텍트 | 
| CloudFront 배포를 만듭니다. | 생성한 애플리케이션 로드 밸런서를 가리키는 CloudFront 배포를 생성합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html) | 클라우드 아키텍트 | 

## 관련 리소스
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-resources"></a>

**AWS 설명서**
+ [캐싱 및 가용성 최적화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)(CloudFront 설명서)
+ [대상으로서의 Lambda 함수](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)(Elastic Load Balancing 설명서)
+ [Lambda 할당량](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)(Lambda 설명서)

**AWS 서비스 웹사이트**
+ [Application Load Balancer](https://aws.amazon.com/es/elasticloadbalancing/application-load-balancer/)
+ [Lambda](https://aws.amazon.com/en/lambda/)
+ [CloudFront](https://aws.amazon.com/en/cloudfront/)
+ [Amazon S3](https://aws.amazon.com/en/s3/)
+ [AWS WAF](https://aws.amazon.com/en/waf/)
+ [Amazon VPC](https://aws.amazon.com/en/vpc/)

## 추가 정보
<a name="serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront-additional"></a>

**코드**

다음 예제 Lambda 함수는 Node.js로 작성됩니다. 이 Lambda 함수는 웹사이트 리소스가 포함된 S3 버킷에 `GetObject` 작업을 수행하는 웹 서버 역할을 합니다.

```
/**

 * This is an AWS Lambda function created for demonstration purposes.

 * It retrieves static assets from a defined Amazon S3 bucket.

 * To make the content available through a URL, use an Application Load Balancer with a Lambda integration.
 * 
 * Set the S3_BUCKET environment variable in the Lambda function definition.
 */

var AWS = require('aws-sdk');

exports.handler = function(event, context, callback) {

    var bucket = process.env.S3_BUCKET;    
    var key = event.path.replace('/', '');
    
    if (key == '') {
        key = 'index.html';
    }

    // Fetch from S3
    var s3 = new AWS.S3();
    return s3.getObject({Bucket: bucket, Key: key},
       function(err, data) {

            if (err) {
                return err;
            }

            var isBase64Encoded = false;
            var encoding = 'utf8';
            
            if (data.ContentType.indexOf('image/') > -1) {
                isBase64Encoded = true;
                encoding = 'base64'
            }
    
            var resp = {
                statusCode: 200,
                headers: {
                    'Content-Type': data.ContentType,
                },
                body: new Buffer(data.Body).toString(encoding),
                isBase64Encoded: isBase64Encoded
            };

            callback(null, resp);
        }
    );
};
```

# 패턴 더 보기
<a name="contentdelivery-more-patterns-pattern-list"></a>

**Topics**
+ [Amazon CloudFront 배포에서 액세스 로깅, HTTPS 및 TLS 버전 확인](check-an-amazon-cloudfront-distribution-for-access-logging-https-and-tls-version.md)
+ [Amazon EKS 클러스터에 gRPC 기반 애플리케이션을 배포하고 Application Load Balancer를 사용하여 액세스하기](deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.md)
+ [퍼블릭 서브넷에 대한 예방적 속성 기반 액세스 제어 배포](deploy-preventative-attribute-based-access-controls-for-public-subnets.md)
+ [Terraform을 사용하여 AWS Wavelength 영역에 리소스 배포](deploy-resources-wavelength-zone-using-terraform.md)
+ [Terraform을 사용하여 AWS WAF 솔루션에 대한 보안 자동화 배포](deploy-the-security-automations-for-aws-waf-solution-by-using-terraform.md)
+ [셀 기반 아키텍처를 위한 서버리스 셀 라우터 설정](serverless-cell-router-architecture.md)
+ [Amazon Q Developer를 코딩 어시스턴트로 사용하여 생산성 향상](use-q-developer-as-coding-assistant-to-increase-productivity.md)
+ [Splunk를 사용하여 AWS Network Firewall 로그 및 지표 보기](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md)