Cisco는 람다, 자동 확장 그룹, ELB(Elastic Load Balancing), Amazon S3 버킷, SNS 및 CloudWatch를 비롯한 여러 AWS 서비스를 사용하여 ASA 가상 방화벽의 자동 확장 그룹을 구축하기 위한 CloudFormation 템플릿 및 스크립트를 제공합니다.

AWS의 ASA 가상 Auto Scale은 완전한 서버리스 방식으로 구현되는 만큼(즉, 이 기능의 자동화와 관련된 헬퍼 VM 없음) AWS 환경의 ASA 가상 인스턴스에 수평 자동 확장 기능을 추가합니다. 버전 6.4부터 자동 확장 솔루션이 management center에서 관리하는 에서 지원됩니다.

ASA 가상 Auto Scale 솔루션은 다음을 제공하는 CloudFormation 템플릿 기반 구축입니다.

• 확장된 ASA 가상 인스턴스에 자동으로 적용되는 완전히 자동화된 컨피그레이션.

• 로드 밸런서 및 다중 가용성 영역 지원

• Auto Scale 기능 활성화 및 비활성화 지원

이 ASA 가상 AWS Auto Scale Solution의 사용 사례는 사용 사례 다이어그램에 표시됩니다. AWS 로드 밸런서는 인바운드 시작 연결만 허용하므로 외부에서 생성된 트래픽만 ASA 가상 방화벽을 통해 내부로 전달할 수 있습니다.

참고	보안 포트에는 SSL 서버 인증서 전제 조건에 설명된 대로 SSL / TLS 인증서가 필요합니다.

인터넷 연결 로드 밸런서는 Network Load Balancer 또는 Application Load Balancer일 수 있습니다. 두 경우 모두 모든 AWS 요건 및 조건이 적용됩니다. 사용 사례 다이어그램에 나와 있는 것처럼 점선의 오른쪽은 ASA 가상 템플릿을 통해 구축됩니다. 왼쪽은 완전히 사용자 정의된 것입니다.

참고	애플리케이션 시작 아웃 바운드 트래픽은 ASA 가상을 통과하지 않습니다.

트래픽에 대한 포트 기반 분기가 가능합니다. 이 작업은 NAT 규칙을 통해 수행할 수 있습니다. 예를 들어 인터넷 연결 LB DNS, 포트 80의 트래픽은 Application-1로 라우팅될 수 있습니다. 포트: 88 트래픽을 애플리케이션-2로 라우팅할 수 있습니다.

ASA 가상 인스턴스를 확장 및 축소하기 위해 Auto Scale Manager라는 외부 엔터티가 메트릭을 모니터링하고, ASA 가상 인스턴스를 추가 또는 삭제하도록 자동 확장 그룹에 명령하고, ASA 가상 인스턴스를 구성합니다.

Auto Scale Manager는 AWS 서버리스 아키텍처를 사용하여 구현되고 AWS 리소스 및 ASA 가상과 통신합니다. Cisco는 Auto Scale Manager 구성 요소의 구축을 자동화하기 위해 CloudFormation 템플릿을 제공합니다. 이 템플릿은 전체 솔루션이 작동하는 데 필요한 기타 리소스도 구축합니다.

참고	서버리스 Auto Scale 스크립트는 CloudWatch 이벤트에서만 호출되므로 인스턴스가 시작될 때만 실행됩니다.

다음 구성 요소가 Auto Scale 솔루션을 구성합니다.

CloudFormation 템플릿

CloudFormation 템플릿은 AWS의 Auto Scale 솔루션에 필요한 리소스를 구축하는 데 사용합니다. 템플릿은 다음으로 구성됩니다.

• 자동 확장 그룹, 로드 밸런서, 보안 그룹 및 기타 기타 구성 요소

• 템플릿은 사용자 입력에 따라 구축을 맞춤화합니다.

  참고	템플릿에는 사용자 입력을 검증하는 데 제한이 있으므로 구축 중에 입력을 검증하는 것은 사용자의 책임입니다.

람다 함수

Auto Scale 솔루션은 Python으로 개발한 람다 함수의 집합으로서 라이프사이클 후크, SNS, CloudWatch 이벤트/알람 이벤트에서 트리거됩니다. 기본 기능은 다음과 같습니다.

• 인스턴스에 Gig0/0 및 Gig 0/1 인터페이스를 추가/제거합니다.

• 로드 밸런서의 대상 그룹에 Gig0/1 인터페이스를 등록합니다.

• ASA 컨피그레이션 파일을 사용하여 새 ASA 가상를 구성하고 구축합니다.

람다 함수는 Python 패키지 형식으로 고객에게 제공됩니다.

라이프 사이클 후크

• 라이프 사이클 후크는 인스턴스에 대한 라이프 사이클 변경 알림을 가져오는 데 사용됩니다.

• 인스턴스 시작의 경우 라이프 사이클 후크를 사용하여 ASA 가상 인스턴스에 인터페이스를 추가하고 대상 그룹에 외부 인터페이스 IP를 등록할 수 있는 람다 함수를 트리거합니다.

• 인스턴스가 종료되는 경우, 라이프사이클 후크를 사용하여 대상 그룹에서 ASA 가상 인스턴스의 등록을 취소하는 람다 함수를 트리거합니다.

간편 알림 서비스(SNS)

• AWS의 SNS(Simple Notification Service)를 사용하여 이벤트를 생성합니다.

• AWS에는 서버리스 람다 함수에 적합한 오케스트레이터가 없다는 제한 때문에, 솔루션은 SNS를 일종의 기능 체인으로 사용하여 이벤트를 기반으로 람다 함수를 오케스트레이션합니다.

ASA 가상 Auto Scale for AWS 솔루션을 시작하는 데 필요한 파일을 다운로드합니다. 사용자 ASA 버전의 구축 스크립트 및 템플릿은 GitHub 리포지토리에서 제공됩니다.

주의	Cisco에서 제공하는 자동 확장용 구축 스크립트 및 템플릿은 오픈 소스 예시로 제공되며 일반적인 Cisco TAC 지원 범위에서는 다루지 않습니다. GitHub에서 정기적으로 업데이트 및 ReadMe 지침을 확인하십시오.

복제/다운로드된 GitHub 리포지토리에서 infrastructure.yaml 파일은 템플릿 폴더에 있습니다. 이 CFT는 버킷 정책을 통해 VPC, 서브넷, 경로, ACL, 보안 그룹, VPC 엔드 포인트 및 S3 버킷을 구축하는 데 사용할 수 있습니다. 이 CFT는 요구 사항에 맞게 수정할 수 있습니다.

다음 섹션에서는 이러한 리소스 및 해당 리소스가 Auto Scale에서 사용되는 방법에 대해 자세히 설명합니다. 이러한 리소스를 수동으로 구축하고 Auto Scale에서도 사용할 수 있습니다.

참고	infrastructure.yaml 템플릿은 VPC, 서브넷, ACL, 보안 그룹, S3 버킷 및 VPC 엔드 포인트만 구축합니다. SSL 인증서, 람다 레이어 또는 KMS 키 리소스는 생성하지 않습니다.

애플리케이션 요구 사항에 따라 VPC를 생성해야 합니다. VPC에는 인터넷에 대한 경로가 연결된 하나 이상의 서브넷이 있는 인터넷 게이트웨이가 있어야 합니다. 보안 그룹, 서브넷 등에 대한 요구 사항은 해당 섹션을 참조하십시오.

필요할 경우 애플리케이션 요구 사항에 따라 서브넷을 생성할 수 있습니다. 사용 사례에서처럼 작동하려면 ASA 가상 머신에는 3개의 서브넷이 필요합니다.

참고	다중 가용성 영역 지원이 필요한 경우 서브넷은 AWS 클라우드 내의 영역 속성이므로 각 영역에 서브넷이 필요합니다.

외부 서브넷

외부 서브넷에는 인터넷 게이트웨이에 대한 기본 경로가 '0.0.0.0/0'이어야 합니다. 여기에는 ASA 가상의 외부 인터페이스가 포함되며 인터넷 연결 NLB도 이 서브넷에 포함됩니다.

내부 서브넷

이는 NAT/인터넷 게이트웨이가 있거나 없는 애플리케이션 서브넷과 유사할 수 있습니다. ASA 가상 상태 프로브의 경우 포트 80을 통해 AWS 메타데이터 서버(169.254.169.254)에 연결할 수 있어야 합니다.

참고	이 AutoScale 솔루션에서 로드 밸런서 상태 프로브는 inside/Gig0/0 인터페이스를 통해 AWS 메타 데이터 서버로 리디렉션됩니다. 그러나 로드 밸런서에서 ASA 가상로 전송되는 상태 프로브 연결을 제공하는 고유한 애플리케이션을 사용하여 이를 변경할 수 있습니다. 이 경우 상태 프로브 응답을 제공하려면 AWS Metadata Server 개체를 해당 애플리케이션 IP 주소로 교체해야 합니다.

관리 서브넷

이 서브넷에는 ASA 가상 관리 인터페이스가 포함되어 있습니다. 기본 경로를 사용하는 것은 선택 사항입니다.

람다 서브넷

AWS 람다 함수를 사용하려면 NAT 게이트웨이가 기본 게이트웨이인 두 개의 서브넷이 필요합니다. 이렇게 하면 VPC 전용의 람다 함수가 생성됩니다. 람다 서브넷은 다른 서브넷만큼 넓을 필요는 없습니다. 람다 서브넷에 대한 모범 사례는 AWS 설명서를 참조하십시오.

애플리케이션 서브넷

Auto Scale 솔루션에서 이 서브넷에 적용되는 제한은 없지만, 애플리케이션이 VPC 외부에서 아웃 바운드 연결을 필요로 하는 경우 서브넷에 각각의 경로가 구성되어 있어야 합니다. 이는 아웃 바운드에서 시작된 트래픽이 로드 밸런서를 통과하지 않기 때문입니다. AWS Elastic Load Balancing User Guide를 참조하십시오.

제공된 Auto Scale 그룹 템플릿에서 모든 연결이 허용됩니다. Auto Scale 솔루션이 작동하려면 다음 연결만 필요합니다.

Amazon Simple Storage Service(Amazon S3)는 업계 최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 개체 스토리지 서비스입니다. 방화벽 템플릿 및 애플리케이션 템플릿 모두에 필요한 모든 파일을 S3 버킷에 담을 수 있습니다.

템플릿이 구축되면 S3 버킷의 Zip 파일을 참조하는 람다 함수가 생성됩니다. 따라서 사용자 계정에서 S3 버킷에 액세스할 수 있어야 합니다.

인터넷 연결 로드 밸런서가 TLS / SSL을 지원해야 하는 경우 인증서 ARN이 필요합니다. 자세한 내용은 다음 링크를 참조하십시오.

• 서버 인증서 작업

• 테스트를 위한 개인 키 및 자체 서명 인증서 생성

• 자체 서명 SSL 인증서로 AWS ELB 생성(서드 파티 링크)

ARN의 예: arn:aws:iam::[AWS 계정]:server-certificate/[인증서 이름]

autoscale_layer.zip은 Linux 환경(예: Python 3.9가 설치된 Ubuntu 18.04)에서 생성할 수 있습니다.

결과 autoscale_layer.zip 파일을 lambda-python-files 폴더에 복사해야 합니다.

ASA 가상 비밀번호가 암호화된 형식인 경우 필요합니다. 그렇지 않으면 이 구성 요소가 필요하지 않습니다. 비밀번호는 여기에 제공된 KMS만 사용하여 암호화해야 합니다. KMS ARN이 CFT에 입력된 경우 비밀번호를 암호화해야 합니다. 그렇지 않으면 비밀번호는 일반 텍스트여야 합니다.

마스터 키 및 암호화에 대한 자세한 내용은 AWS 문서 Creating keys 및 AWS CLI Command Reference에서 비밀번호 암호화 및 KMS에 대한 내용을 참조하십시오.

예:

$ aws kms encrypt --key-id <KMS-ARN> --plaintext 'MyC0mplIc@tedProtect1oN'
{
    "KeyId": "KMS-ARN", 
    "CiphertextBlob": 
"AQICAHgcQFAGtz/hvaxMtJvY/x/rfHnKI3clFPpSXUU7HQRnCAFwfXhXHJAHL8tcVmDqurALAAAAajBoBgkqhki
G9w0BBwagWzBZAgEAMFQGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM45AIkTqjSekX2mniAgEQgCcOav6Hhol
+wxpWKtXY4y1Z1d0z1P4fx0jTdosfCbPnUExmNJ4zdx8="
}
$

CiphertextBlob 키의 값을 비밀번호로 사용해야 합니다.

make.py 파일은 복제된 리포지토리의 최상위 디렉토리에 있습니다. 이렇게하면 python 파일을 Zip 파일로 압축하고 대상 폴더에 복사합니다. 이러한 작업을 수행하려면 Python 3 환경을 사용할 수 있어야 합니다.

구축을 위한 모든 전제 조건이 완료되면 AWS CloudFormation 스택을 생성할 수 있습니다.

대상 디렉토리의 deploy_autoscale.yaml 파일을 사용합니다.

Geneve Autoscale의 대상 디렉토리의 deploy_ngfw_autoscale_with_gwlb.yaml 파일을 사용합니다.

참고

deploy_ngfw_autoscale_with_gwlb.yaml 파일을 구축하기 전에 AWS GWLB Auto Scale 솔루션용 Infrastructure_gwlb.yaml 파일을 구축해야 합니다. deploy_autoscale_with_gwlb.yaml 템플릿 구축 중에 생성되는 GWLB를 선택하여 GWLB-E(Gateway Loadbalancer Endpoint)를 생성해야 합니다. GWLBe를 생성한 후에는 Application Subnet(애플리케이션 서브넷) 및 default Route(기본 경로) 테이블에 GWLBe를 사용하도록 기본 경로를 업데이트해야 합니다. 자세한 내용은 https://docs.amazonaws.cn/en_us/vpc/latest/privatelink/create-endpoint-service-gwlbe.html를 참고하십시오.

입력 매개변수에 수집된 매개 변수를 제공합니다.

템플릿 구축이 완료되면, 람다 함수 및 CloudWatch 이벤트가 생성되었는지 검증해야 합니다. 기본적으로 Auto Scale 그룹에는 최소 및 최대 인스턴스 수가 0입니다. 원하는 인스턴스 수를 사용하여 AWS EC2 콘솔에서 Auto Scale그룹을 편집해야 합니다. 그러면 새 ASA 가상 인스턴스가 트리거됩니다.

인스턴스를 하나만 실행하고 그 워크플로우를 확인하고 예상대로 작동하는지에 대한 동작을 검증하는 것이 좋습니다. ASA 가상의 실제 요구 사항을 구축한 후에는 동작에 대해 확인할 수도 있습니다. AWS Scaling 정책에서 ASA 가상 인스턴스가 제거되지 않도록 최소 인스턴스 수를 축소 보호로 표시 할 수 있습니다.

이 항목에서는 Auto Scale 그룹에 대해 하나 이상의 확장 프로세스를 일시 중지한 다음 다시 시작하는 방법을 설명합니다.

확장 작업 시작 및 중지

스케일 아웃/인 작업을 시작하고 중지하려면 다음 단계를 수행합니다.

• AWS Dynamic Scaling의 경우 - 다음 링크를 참조하여 스케일 아웃 작업을 활성화하거나 비활성화할 수 있습니다.

  확장 프로세스 일시 중단 및 다시 시작

CloudWatch Cron 작업은 60분마다 Health Doctor 모듈의 Auto Scale Manager 람다를 트리거합니다.

• 유효한 ASA 가상 VM에 속한 비정상적인 IP가 있는 경우 ASA 가상가 1시간 이상 경과하면 해당 인스턴스가 삭제됩니다.

• 해당 IP가 유효한 ASA 가상 머신에 있지 않으면 대상 그룹에서 IP만 제거됩니다.

상태 모니터 비활성화

상태 모니터를 비활성화하려면 constant.py에서 상수를 "True"로 지정합니다.

상태 모니터 활성화

상태 모니터를 활성화하려면 consist.py에서 상수를 "False"로 지정합니다.

라이프 사이클 후크를 비활성화해야 하는 경우는 드물지만 비활성화되면 인스턴스에 인터페이스를 추가하지 않습니다. 또한 일련의 ASA 가상 인스턴스 구축이 실패할 수 있습니다.

Auto Scale Manager를 비활성화하려면 각 CloudWatch 이벤트 "notify-instance-launch" 및 "notify-instance-terminate"를 비활성화해야 합니다. 이 기능을 비활성화하면 새 이벤트에 대해 람다가 트리거되지 않습니다. 그러나 이미 실행중인 람다 작업은 계속 진행됩니다. Auto Scale Manager는 갑자기 중지되지 않습니다. 스택 삭제 또는 리소스 삭제로 인해 갑자기 중지하려고 시도하면 무한 상태가 발생할 수 있습니다.

AWS로드 밸런서는 둘 이상의 네트워크 인터페이스가 있는 인스턴스에 대해 인스턴스 유형 대상을 허용하지 않으므로 Gigabit0/1 인터페이스 IP는 대상 그룹에서 대상으로 구성됩니다. 그러나 현재 AWS Auto Scale 상태 확인은 IP가 아닌 인스턴스 유형 대상에 대해서만 작동합니다. 또한 이러한 IP는 대상 그룹에서 자동으로 추가되거나 제거되지 않습니다. 따라서 Auto Scale 솔루션은 이러한 두 작업을 모두 프로그래밍 방식으로 처리합니다. 그러나 유지 보수 또는 문제 해결의 경우에는 수동으로 수행해야 하는 상황이 있을 수 있습니다.

대상 그룹에 대상 등록

로드 밸런서에 ASA 가상 인스턴스를 등록하려면 Gigabit0/1 인스턴스 IP(외부 서브넷)를 대상 그룹의 대상으로 추가해야 합니다. Register or Deregister Targets by IP Address를 참조하십시오.

대상 그룹에서 대상 등록 취소

로드 밸런서에 ASA 가상 인스턴스를 등록 해제하려면 Gigabit0/1 인스턴스 IP(외부 서브넷)를 대상 그룹에서 삭제해야 합니다. Register or Deregister Targets by IP Address를 참조하십시오.

AWS는 Auto Scale 그룹에서 인스턴스 재부팅을 허용하지 않지만 사용자가 인스턴스를 스탠바이 상태로 설정하고 이러한 작업을 수행할 수 있도록 허용합니다. 그러나 이는 로드 밸런서 대상이 인스턴스 유형인 경우에 가장 적합합니다. 그러나 복수의 네트워크 인터페이스 때문에 ASA 가상 머신은 인스턴스 유형 대상으로 구성할 수 없습니다.

인스턴스를 스탠바이 상태로 설정

인스턴스가 스탠바이 상태가 되면 대상 그룹의 해당 IP는 상태 프로브가 실패할 때까지 계속 동일한 상태로 유지됩니다. 따라서 인스턴스를 스탠바이 상태로 설정하기 전에 대상 그룹에서 각 IP를 등록 취소하는 것이 좋습니다. 자세한 내용은 대상 그룹에서 대상 등록 취소를 참조하십시오.

IP가 제거되면 Temporarily Removing Instances from Your Auto Scaling Group을 참조하십시오.

스탠바이에서 인스턴스 제거

마찬가지로 인스턴스를 스탠바이 상태에서 실행 중 상태로 이동할 수 있습니다. 스탠바이 상태에서 제거한 후에는 인스턴스의 IP를 대상 그룹 대상에 등록해야 합니다. 대상 그룹에 대상 등록의 내용을 참조하십시오.

문제 해결 또는 유지 보수를 위해 인스턴스를 스탠바이 상태로 설정하는 방법에 대한 자세한 내용은 AWS 뉴스 블로그를 참조하십시오.

Auto Scale 그룹에서 인스턴스 제거/분리

Auto Scale 그룹에서 인스턴스를 제거하려면 먼저 스탠바이 상태로 이동해야 합니다. "Put Instances on Stand-by"를 참조하십시오. 인스턴스가 스탠바이 상태가 되면 제거하거나 분리할 수 있습니다. Detach EC2 Instances from Your Auto Scaling Group을 참조하십시오.

인스턴스를 종료하려면 스탠바이 상태로 설정해야 합니다. 인스턴스 스탠바이을 참조하십시오. 인스턴스가 스탠바이 상태가 되면 종료를 진행할 수 있습니다.

Auto Scale 그룹에서 특정 인스턴스가 실수로 제거되는 것을 방지하기 위해 축소(scale in) 보호로 설정할 수 있습니다. 인스턴스가 축소(Scale-In) 보호 상태에 있을 경우 해당 인스턴스는 축소 이벤트로 인해 종료되지 않습니다.

인스턴스를 축소 보호 상태로 전환하려면 다음 링크를 참조하십시오.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html

중요사항	상태가 양호한 최소 인스턴스 수(대상 IP는 EC2 인스턴스가 아니라 정상이어야 함)를 축소 보호하는 것이 좋습니다.

컨피그레이션의 변경 사항은 이미 실행중인 인스턴스에 자동으로 반영되지 않습니다. 변경 사항은 향후 디바이스에만 반영됩니다. 이러한 변경 사항은 기존 디바이스에 수동으로 푸시해야 합니다.

ASA Virtual 관리자 비밀번호 변경

ASA 가상 비밀번호를 변경하려면 사용자가 실행중인 인스턴스에 대해 각 디바이스에서 비밀번호를 수동으로 변경해야 합니다. 새 ASA 가상 디바이스를 온보딩할 경우, ASA 가상 비밀번호는 람다 환경 변수에서 가져옵니다. Using AWS Lambda Environment Variables을 확인하십시오.

Auto Post Group, Launch Configuration(컨피그레이션 시작), CloudWatch 이벤트, 확장 정책 등 AWS 사후 구축에서 여러 가지 사항을 변경할 수 있습니다. 리소스를 CloudFormation 스택으로 가져 오거나 기존 리소스에서 새 스택을 생성할 수 있습니다.

AWS 리소스에서 수행되는 변경 사항을 관리하는 방법에 대한 자세한 내용은 Bringing Existing Resources Into CloudFormation Management를 참조하십시오.

CloudWatch 로그를 내보내려면 Export Log Data to Amazon S3 Using the AWS CLI를 참조하십시오.