bambee83

Amazon S3는 데이터를 안전하고 내구성 있게 저장할 수 있는 스토리지 서비스이며, Amazon CloudFront는 전 세계 사용자에게 콘텐츠를 빠르고 안전하게 전달하는 CDN 서비스입니다. 둘은 함께 사용될 때 웹 애플리케이션의 성능과 안정성을 크게 향상시킬 수 있습니다.

Amazon S3 : 

Amazon S3는 인터넷 스토리지 솔루션으로, 개발자들이 웹에서 대용량 데이터를 저장하고 검색할 수 있도록 설계되었습니다. 사용자는 데이터를 '버킷'이라는 단위로 저장하고, 각 버킷은 고유한 이름을 가집니다. S3는 거의 무제한의 스토리지를 제공하며, 데이터의 안전성과 내구성을 보장합니다. S3는 정적 웹 호스팅, 백업 및 복구, 아카이브, 엔터프라이즈 애플리케이션, IoT 디바이스, 빅 데이터 분석 등 다양한 사용 사례에 적합합니다.

• Amazon S3는 AWS에서 제공하는 안전하고 내구성이 뛰어난 객체 스토리지 서비스입니다.
• 데이터를 '객체'로 저장하며, 각 객체는 고유한 키를 통해 식별됩니다. 이러한 객체는 '버킷'이라는 이름의 컨테이너 안에 저장됩니다.
• 각 객체에는 데이터 외에도 메타데이터를 포함할 수 있습니다.
• 또한, S3는 파일의 버전 관리를 지원합니다. 이를 통해 객체를 실수로 삭제하거나 수정한 경우 이전 버전으로 복원할 수 있습니다.
• 데이터를 저장할 때에는 다양한 스토리지 클래스를 선택할 수 있습니다. 예를 들어, 자주 접근하지 않는 데이터를 저렴한 비용으로 저장하려면 S3 Standard-IA (Infrequent Access) 또는 S3 One Zone-IA를 선택할 수 있습니다.
• S3는 또한 데이터 보호를 위한 다양한 기능을 제공합니다. 예를 들어, 버킷 정책을 통해 데이터의 액세스를 제한할 수 있으며, S3의 서버 측 암호화를 사용하여 데이터를 암호화할 수 있습니다.

Amazon CloudFront : 

Amazon CloudFront는 AWS의 콘텐츠 전송 네트워크(CDN) 서비스입니다. CloudFront는 사용자에게 빠르고 안전하게 데이터, 비디오, 애플리케이션, API 등을 전달하도록 최적화되어 있습니다. CloudFront는 전 세계적으로 배포된 엣지 로케이션에서 콘텐츠를 캐시하여 사용자에게 더 빠른 응답 시간과 높은 전송 속도를 제공합니다. 또한, DDoS 공격과 같은 보안 위협으로부터 콘텐츠를 보호하기 위한 기능들을 제공합니다.

• Amazon CloudFront는 AWS의 콘텐츠 전송 네트워크 (CDN) 서비스입니다.
• CDN은 사용자에게 빠른 전송 속도를 제공하기 위해 전 세계의 여러 위치에 콘텐츠를 캐시하는 네트워크입니다. 사용자의 요청이 CDN의 가장 가까운 엣지 로케이션으로 라우팅되므로, 사용자는 더 빠른 응답 시간과 높은 전송 속도를 경험할 수 있습니다.
• CloudFront는 HTTP와 HTTPS를 모두 지원하며, 동적 웹 사이트, 정적 웹 사이트, 스트리밍 비디오, 웹 애플리케이션, API 등 다양한 콘텐츠를 전송할 수 있습니다.
• CloudFront는 또한 다양한 보안 기능을 제공합니다. 예를 들어, AWS Shield를 사용하여 DDoS 공격을 방어하거나, AWS Certificate Manager를 사용하여 SSL/TLS 인증서를 무료로 제공받을 수 있습니다.
• 사용자가 처음 콘텐츠를 요청할 때 CloudFront는 콘텐츠의 원본 위치 (예: Amazon S3 버킷, EC2 인스턴스, ELB 로드 밸런서 등)에서 콘텐츠를 가져와 사용자에게 제공하고, 그 콘텐츠를 가까운 엣지 로케이션에 캐시합니다. 다음 번에 같은 콘텐츠가 요청되면 CloudFront는 원본 위치에서 콘텐츠를 다시 가져오지 않고 캐시된 콘텐츠를 바로 제공합니다. 이런 방식으로 사용자의 응답 시간을 크게 줄일 수 있습니다.
• CloudFront는 콘텐츠를 캐시하는 동안에도 세밀한 제어를 제공합니다. 예를 들어, 콘텐츠의 캐시 된 버전을 업데이트하거나 삭제할 수 있습니다. 또한 TTL(Time to Live)을 설정하여 캐시된 콘텐츠가 얼마나 오래 저장될지를 지정할 수 있습니다.
• CloudFront는 원본 서버에 대한 요청을 줄이므로 원본 서버의 부하를 줄이는 효과도 있습니다. 이는 트래픽이 급증하는 상황에서 원본 서버를 보호하는 데 도움이 될 수 있습니다.
• AWS WAF(Web Application Firewall)와 함께 사용하여 보안을 강화할 수도 있습니다. WAF는 SQL 삽입, XSS 공격 등 웹 애플리케이션을 대상으로 한 일반적인 공격을 차단할 수 있습니다.

CORS(Cross-Origin Resource Sharing)는 웹 페이지의 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다른 출처의 리소스를 요청할 수 있도록 하는 메커니즘입니다. 이것은 웹 애플리케이션의 보안을 강화하기 위한 것인데, 동일 출처 정책(Same-Origin Policy)에 따르면 웹 애플리케이션은 동일 출처의 리소스만 요청할 수 있습니다. CORS는 이를 유연하게 하여 다른 출처의 리소스를 안전하게 요청할 수 있도록 합니다.

1. Amazon S3에서 CORS 설정:

어떤 출처가 버킷의 리소스에 액세스할 수 있는지, 어떤 HTTP 메서드(GET, PUT, POST, DELETE 등)를 사용할 수 있는지 정책 설정 

2. Amazon CloudFront에서 CORS 설정:

• HTTP 헤더 전달: CloudFront가 원본 서버에 요청을 보낼 때 CORS 관련 HTTP 헤더를 전달해야 합니다. 이를 위해 CloudFront 배포 설정에서 "Origin Request Policy"를 수정하여 "Access-Control-Request-Headers", "Access-Control-Request-Method", "Origin" 등의 HTTP 헤더를 전달하도록 설정할 수 있습니다.
• request header에 Origin을 설정
• 요청을 넣을때에 request header 에 Origin을 넣으면 response header에 access-control-allow-origin 을 넣어 내려보내준다.
• Cloudfront는 중간다리 역할이라서 원본에게 요청을 보내는 Request 세팅도 할 수 있고, Cloudfront에 접근하는 쪽(주로 클라이언트)에 응답을 하는 Response 세팅도 할 수 있다

1. EC2를 사용하여 어떤 애플리케이션을 배포한 경험이 있나요? 그 과정은 어떻게 진행되었나요? 

"저는 GitHub Actions를 이용해서 CI/CD 파이프라인을 구성하고 AWS EC2에 웹 애플리케이션을 자동으로 배포한 경험이 있습니다.

이러한 작업 흐름은 다음과 같이 이루어졌습니다:

1. 먼저, 웹 애플리케이션의 소스 코드를 Git을 통해 GitHub 리포지토리에 업로드했습니다.
2. GitHub Actions를 설정하기 위해 .github/workflows 디렉토리에 YAML 파일을 생성했습니다.
3. 이 파일에는 원격 서버(EC2 인스턴스)에 접속하기 위한 SSH 키와 AWS 접근 정보를 포함하고 있었습니다. 이 정보는 GitHub Secrets를 통해 안전하게 관리되었습니다.
4. 파일에는 또한 배포가 이루어질 때마다 실행되는 일련의 명령들을 정의하였습니다. 이 명령들은 애플리케이션의 종속성을 설치하고, 테스트를 실행하고, 애플리케이션을 빌드하고, 빌드된 애플리케이션을 EC2 인스턴스로 전송하는 것을 포함했습니다.
5. 마지막으로, 애플리케이션을 EC2 인스턴스에서 실행하는데 필요한 명령들을 작성했습니다.

이런 식으로, GitHub Actions를 통해 CI/CD 파이프라인을 구축하고, 코드 변경 사항이 GitHub 리포지토리에 푸시되는 즉시 자동으로 EC2에 배포되도록 설정했습니다."

2. EC2 인스턴스의 선택과 관리에 어떤 고려 사항이 있나요? 

1. 인스턴스 유형 선택: AWS는 다양한 유형의 EC2 인스턴스를 제공하며, 이는 다른 CPU, 메모리, 스토리지, 네트워크 용량을 가지고 있습니다. 이 중에서 애플리케이션의 요구 사항과 예상 트래픽에 맞는 유형을 선택해야 합니다.
2. 비용 최적화: 각 인스턴스 유형에는 다른 비용이 연관되어 있으며, 이를 최적화하는 것이 중요합니다. 예를 들어, 상시 실행해야 하는 애플리케이션의 경우 예약 인스턴스를, 일시적이거나 비정상적인 워크로드의 경우 스팟 인스턴스를 사용할 수 있습니다.
3. 보안 그룹 설정: EC2 인스턴스의 보안 그룹을 적절하게 설정하여, 필요한 트래픽만 허용하고 그 외의 트래픽은 차단하는 것이 중요합니다.
4. 스케일링: 애플리케이션의 로드와 성능 요구 사항이 변화할 때 자동으로 EC2 인스턴스를 스케일링할 수 있는 방법을 고려해야 합니다. AWS의 Auto Scaling 기능을 사용하여 이를 처리할 수 있습니다.
5. 백업과 복구: EC2 인스턴스의 데이터를 보호하고, 시스템 장애나 데이터 손실이 발생했을 때 복구할 수 있는 전략이 필요합니다. 이를 위해 Amazon EBS 볼륨 스냅샷을 주기적으로 생성하고 관리하는 것이 중요합니다.
6. 모니터링과 로깅: AWS CloudWatch를 사용하여 EC2 인스턴스를 모니터링하고 로그를 수집할 수 있습니다. 이를 통해 시스템의 성능을 추적하고 문제를 빠르게 식별할 수 있습니다.
7. AMI 관리: Amazon Machine Image(AMI)를 사용하면 EC2 인스턴스의 설정을 빠르게 복제하고 재사용할 수 있습니다. AMI를 적절히 관리하면 인스턴스 배포를 표준화하고 빠르게 확장할 수 있습니다

3. AWS CodeDeploy를 사용한 배포 프로세스에서 어떤 문제가 발생했고, 어떻게 해결했나요? 

문제 1: 배포 실패

때때로, 배포가 실패하며 이는 다양한 원인으로 인해 발생할 수 있습니다.

해결책: AWS CodeDeploy는 배포 중에 발생한 문제에 대한 로그를 제공합니다. 이를 통해 배포가 실패한 원인을 파악하고 해결할 수 있습니다. 일반적으로, 이 문제는 애플리케이션의 종속성, 스크립트 오류, 리소스 부족 등으로 발생합니다. 이러한 문제를 해결하기 위해 해당 로그를 검토하고, 필요한 수정사항을 소스 코드에 반영한 뒤, 다시 배포를 진행합니다.

문제 2: 오래된 배포 구성

배포 과정에서 이전에 사용되었던 구성이나 설정이 여전히 존재하여, 최신 버전의 애플리케이션을 제대로 배포하지 못하는 경우가 있습니다.

해결책: 이런 경우, AWS CodeDeploy의 배포 설정을 검토하고 필요한 변경사항을 적용해야 합니다. 이에는 배포 그룹의 설정, 배포 방법, 배포 구성 등이 포함될 수 있습니다.

문제 3: 서비스 중단

일부 배포는 애플리케이션에 서비스 중단을 야기할 수 있습니다. 이는 배포 중에 새로운 버전의 애플리케이션을 실행하면서 이전 버전의 애플리케이션이 중지되기 때문입니다.

해결책: 이를 해결하기 위해 AWS CodeDeploy의 블루/그린 배포 방법을 사용할 수 있습니다. 이 방법을 사용하면, 새로운 버전의 애플리케이션을 배포하는 동안 서비스를 계속 유지할 수 있습니다.

4. AWS CodeDeploy의 어떤 기능을 활용하여 배포 프로세스를 최적화했나요? 

1. 블루/녹그린 배포: 이 기능을 사용하면 애플리케이션이 배포되는 동안 서비스가 중단되지 않습니다. 새 버전의 애플리케이션을 별도의 환경에서 실행하고, 배포가 성공적으로 완료되면 트래픽을 새 환경으로 전환합니다. 이렇게 하면 애플리케이션의 가용성을 높이고 배포 리스크를 줄일 수 있습니다.
2. 인스턴스 대상 묶음: CodeDeploy는 인스턴스 대상 묶음을 사용하여 복잡한 배포를 쉽게 관리할 수 있게 합니다. 이 기능을 사용하면 동일한 설정을 공유하는 인스턴스 그룹을 한 번에 업데이트할 수 있습니다.
3. 롤백: 배포가 실패하거나 애플리케이션이 예상대로 작동하지 않는 경우, CodeDeploy는 자동 롤백 기능을 통해 이전 버전으로 쉽게 되돌릴 수 있습니다. 이 기능은 배포 리스크를 크게 줄여줍니다.
4. 훅스: CodeDeploy는 배포 생명주기 동안에 실행할 수 있는 여러 훅스를 제공합니다. 이러한 훅스를 사용하여 배포 전, 배포 중, 배포 후에 커스텀 스크립트를 실행할 수 있습니다. 예를 들어, 배포 전에 테스트를 실행하거나, 배포 후에 모니터링 도구를 설정할 수 있습니다.
5. AWS 서비스와의 통합: CodeDeploy는 다른 AWS 서비스와 쉽게 통합될 수 있습니다. 예를 들어, AWS CloudWatch를 사용하여 배포를 모니터링하고, AWS Auto Scaling을 사용하여 인스턴스를 자동으로 스케일링할 수 있습니다.

5. GitHub Actions를 사용하여 CI/CD 파이프라인을 구성한 경험 및 그 과정에서 어떤 도구나 기술을 사용했나요? 

1. 소스 코드 관리: 먼저, 애플리케이션의 소스 코드를 Git을 통해 GitHub 리포지토리에 업로드합니다.
2. CI/CD 파이프라인 구성: GitHub Actions는 .github/workflows 디렉토리 내부의 YAML 형식 파일을 통해 CI/CD 워크플로우를 구성합니다. 이 파일에는 워크플로우의 트리거 조건, 실행 환경, 실행할 명령어 등을 정의합니다.
3. 빌드 및 테스트 자동화: 워크플로우 파일에는 소스 코드의 빌드와 테스트를 자동화하는 단계를 포함합니다. 이는 프로젝트에 따라 다르지만, 일반적으로 필요한 패키지를 설치하고, 코드 빌드 도구를 실행하며, 단위 테스트나 통합 테스트를 실행하는 단계를 포함합니다.
4. 배포 자동화: 배포 단계에서는 빌드된 애플리케이션을 최종 배포 환경으로 전송하고 실행합니다. 이는 AWS EC2 인스턴스, Kubernetes 클러스터, 서버리스 환경 등이 될 수 있으며, 해당 환경에 맞는 배포 도구와 명령어를 사용합니다.

6. GitHub Actions와 AWS CodeDeploy를 통합하여 어떻게 작업했나요? 이를 통해 얻은 이점은 무엇인가요? 

GitHub Actions과 AWS CodeDeploy를 통합하면 GitHub에서 코드 변경이 발생할 때마다 자동으로 AWS에 코드를 배포하는 효율적인 CI/CD 파이프라인을 구축할 수 있습니다. 이를 통해 코드 품질을 개선하고 배포 시간을 단축할 수 있습니다.

• 효율성: 코드 변경이 발생할 때마다 자동으로 테스트하고 배포하는 것으로 개발자가 배포를 위한 시간을 줄일 수 있습니다.
• 신뢰성: 모든 코드 변경이 자동으로 테스트되므로, 배포 전에 문제를 발견하고 수정할 수 있습니다.
• 속도: 코드를 더 빠르게 테스트하고 배포함으로써, 기능을 더 빠르게 사용자에게 제공할 수 있습니다.

7. GitHub Actions를 사용한 배포 프로세스에서 보안 관련 고려 사항은 무엇인가요? 

1. 비밀 관리: 비밀(예: API 키, 비밀번호 등)은 절대로 워크플로우 파일이나 소스 코드에 직접 포함시키지 않아야 합니다. 이러한 비밀은 GitHub Actions의 "Secrets" 기능을 사용해 안전하게 저장하고 워크플로우에서 참조해야 합니다.
2. 최소한의 권한 원칙: 워크플로우에서 사용하는 AWS 계정이나 비밀은 필요한 최소한의 권한만을 부여해야 합니다. 이렇게 하면 잠재적인 보안 위협이 발생했을 때도 피해를 최소화할 수 있습니다.
3. 코드 리뷰 및 병합 정책: 모든 코드 변경은 코드 리뷰를 통해 검증되어야 합니다. 또한, 보안 측면에서 중요한 변경(예: 워크플로우 파일이나 보안 설정 변경)은 권한이 있는 사람만 병합할 수 있어야 합니다.
4. 외부 동작의 사용: GitHub Actions에서는 외부 동작(actions)을 사용할 수 있습니다. 이들 동작은 소스 코드를 검토하고 신뢰할 수 있는 소스에서만 사용해야 합니다. 가능한 경우, 동작의 버전을 지정하여 무작위 변경으로부터 보호할 수 있습니다.
5. 로그 및 모니터링: 워크플로우 실행에 대한 로그를 수집하고 모니터링해야 합니다. 이를 통해 잠재적인 보안 문제를 조기에 발견할 수 있습니다.

8. 배포 과정에서 롤백을 처리한 경험은 있나요? 어떻게 처리했나요? 

9. 애플리케이션 모니터링 및 로깅에 사용한 도구나 전략은 무엇인가요? 

애플리케이션의 모니터링과 로깅은 시스템의 안정성과 성능을 유지하고 문제를 신속하게 해결하는 데 중요합니다. 이를 위한 다양한 도구와 전략이 있습니다.

1. 로깅 도구: 애플리케이션의 작동에 대한 정보를 로깅하고 분석하는 데 사용되는 도구입니다. AWS CloudWatch, ELK 스택(Elasticsearch, Logstash, Kibana), Grafana, Splunk 등이 대표적인 예입니다.
2. 성능 모니터링 도구: 시스템의 성능을 실시간으로 모니터링하고 분석하는 데 사용되는 도구입니다. 이를 통해 CPU 사용률, 메모리 사용, 네트워크 트래픽, 디스크 IO 등을 모니터링하고 문제를 신속하게 파악할 수 있습니다. AWS CloudWatch, New Relic, Datadog, Prometheus 등이 대표적입니다.
3. 에러 트래킹 도구: 애플리케이션에서 발생하는 에러를 실시간으로 추적하고, 에러의 원인을 분석하고 보고하는 데 사용되는 도구입니다. Sentry, Rollbar, Bugsnag 등이 이에 해당합니다.
4. 분산 추적 시스템: 마이크로서비스 아키텍처와 같이 분산 시스템에서 요청이 어떻게 처리되는지를 추적하는 데 사용되는 도구입니다. Zipkin, Jaeger, AWS X-Ray 등이 대표적입니다.
5. 로깅 및 모니터링 전략: 로깅 및 모니터링 전략은 어떤 데이터를 수집할 것인지, 얼마나 오래 보관할 것인지, 어떻게 분석하고 사용할 것인지 등을 결정합니다. 이는 회사의 요구사항, 규제 준수, 데이터 저장 및 분석 비용 등을 고려하여 결정됩니다.

10. 병렬 또는 블루/그린 배포와 같은 다른 배포 전략에 대해 경험이 있나요? 

1. 병렬 배포: 병렬 배포는 모든 서버 또는 인스턴스에 동시에 업데이트를 배포하는 전략입니다. 이 방식은 매우 빠르지만, 만약 새로운 버전에 결함이 있다면 전체 시스템에 영향을 미칠 수 있습니다. 따라서 이 전략은 테스트가 철저히 이루어진 경우나, 전체 시스템에 빠르게 변경사항을 적용해야 하는 경우에 적합합니다.
2. 블루/그린 배포: 블루/그린 배포는 두 개의 동일한 프로덕션 환경(블루와 그린)을 두고 한 환경에는 실제 트래픽을, 다른 한 환경에는 새로운 버전의 애플리케이션을 배포하는 전략입니다. 새로운 버전이 정상적으로 동작한다면, 트래픽을 새로운 환경으로 점진적으로 이동시킵니다. 이 방식은 실제 사용자에게 서비스 중단 없이 새로운 버전을 안전하게 배포할 수 있으므로, 신뢰성이 중요한 애플리케이션에 적합합니다.

이 두 가지 전략 모두 장단점이 있으며, 특정 상황에 따라 적합한 전략을 선택해야 합니다. 예를 들어, 신뢰성이 중요하다면 블루/그린 배포를, 빠른 배포가 필요하다면 병렬 배포를 선택할 수 있습니다.

EC2 (Elastic Compute Cloud) : 

• Amazon EC2는 AWS에서 제공하는 가상 서버 서비스입니다. 사용자는 이를 통해 필요한 만큼의 가상 서버를 확보하고, 원하는 운영체제를 설치하고, 필요한 어플리케이션을 배포할 수 있습니다. 사용자는 필요에 따라 EC2 인스턴스의 사양을 조정하거나, 여러 인스턴스를 동시에 운영할 수 있어, 확장성이 뛰어납니다.
• EC2는 Amazon Web Services (AWS)의 핵심 컴퓨팅 서비스로서, 사용자가 필요에 따라 가상 서버를 생성하고 관리할 수 있게 해줍니다. 이런 가상 서버를 EC2 인스턴스라고 부릅니다. 사용자는 EC2 인스턴스에서 원하는 운영 체제를 실행할 수 있고, 여기에는 Ubuntu를 비롯한 여러 가지 Linux 배포판과 Windows 등이 포함됩니다.
• EC2를 사용하면 물리적 서버를 직접 관리하는 것에 비해 많은 유연성과 효율성을 얻을 수 있습니다. 예를 들어, 서버의 성능을 업그레이드하거나 다운그레이드하는 것이 단순히 새로운 인스턴스 유형을 선택하는 것만큼 간단해집니다. 또한, 수요가 증가하거나 감소함에 따라 인스턴스를 추가하거나 제거함으로써 사용 중인 컴퓨팅 리소스를 쉽게 조절할 수 있습니다.

CodeDeploy : 

• AWS CodeDeploy는 사용자가 빠르게 애플리케이션을 배포하고 업데이트하는 데 도움을 주는 서비스입니다. CodeDeploy는 자동화된 배포 절차를 제공하므로, 수동 배포에서 발생할 수 있는 오류를 줄이고, 빠른 반복 배포를 가능하게 합니다. AWS EC2 인스턴스 뿐만 아니라 온프레미스 환경에서도 사용할 수 있습니다.

• AWS CodeDeploy는 사용자가 자신의 애플리케이션을 신속하고 안정적으로 업데이트하고 배포할 수 있도록 돕는 서비스입니다. CodeDeploy는 AWS 클라우드에서 물론, 사용자의 온-프레미스 환경에서도 작동하므로 사용자가 소프트웨어를 어디서든지 배포하는 데 유용합니다.CodeDeploy를 사용하면, 개발자는 각 배포 단계에서 실행되는 명령어 시퀀스를 지정할 수 있는 배포 스크립트(앱스펙 파일)를 작성해야 합니다. 이런 방식으로 CodeDeploy는 사용자가 필요로 하는 특정 작업을 수행하면서 애플리케이션 코드를 배포합니다. 이는 서버 설정, 애플리케이션 종속성 설치, 애플리케이션 시작 등을 포함할 수 있습니다.
• CodeDeploy는 애플리케이션 업데이트를 자동으로 EC2 인스턴스에 배포하며, 이러한 과정에서 애플리케이션 중단 시간을 최소화합니다. 이 서비스는 롤아웃 트래킹, 배포 중인 인스턴스 상태의 실시간 보기 등의 기능을 제공합니다.

Route 53와 Elastic Load Balancer는 아마존 웹 서비스(AWS)의 서비스 중 일부입니다.

각각 DNS 서비스와 로드 밸런싱 서비스를 제공합니다.

Route 53 : 

Amazon Route 53은 AWS에서 제공하는 확장 가능한 도메인 이름 시스템 (DNS) 웹 서비스입니다. Route 53은 사용자가 웹사이트나 웹 애플리케이션을 실행하는데 필요한 세 가지 기본 기능을 제공합니다.

도메인 등록 : 사용자가 도메인 이름을 등록할 수 있게 해줍니다.

DNS 라우팅 : 사용자가 DNS 트래픽을 Amazon EC2 인스턴스, Elastic Load Balancers 또는 Amazon S3 버킷과 같은 AWS 리소스로 라우팅할 수 있게 해줍니다.

건강 검사 : 애플리케이션이 원활하게 작동하는지 검사하고, 문제가 있는 경우 사용자에게 알릴 수 있습니다.

• Route 53은 AWS의 관리형 DNS(Domain Name System) 서비스입니다. DNS는 도메인 이름과 IP 주소 간의 매핑을 관리하는 시스템으로, 사용자가 도메인 이름을 입력하면 해당 도메인 이름에 대응하는 IP 주소를 반환해줍니다.
• Route 53은 고가용성과 확장성을 제공하며, 전 세계의 DNS 서버에 분산하여 사용자에게 신속하고 안정적인 DNS 조회를 제공합니다.
• Route 53은 DNS 레코드를 관리하는 기능을 제공하며, 도메인 등록, DNS 쿼리 로깅, 트래픽 라우팅, 상태 검사 등 다양한 기능을 제공합니다.

Elastic Load Balancing (ELB) : 

ELB는 AWS에서 제공하는 로드 밸런서 서비스로, EC2 인스턴스로 들어오는 애플리케이션 또는 네트워크 트래픽을 자동으로 분산시킵니다. 이 서비스는 단일 EC2 인스턴스가 다운되거나 과부하 상태가 되는 것을 방지하며, 애플리케이션의 가용성과 내결함성을 증가시킵니다. ELB는 세 가지 유형의 로드 밸런서를 제공합니다: Classic Load Balancer, Network Load Balancer, Application Load Balancer.

Classic Load Balancer는 요청을 여러 EC2 인스턴스로 분산시키는데, 이는 프로토콜 레벨에서 동작합니다.

Network Load Balancer는 초당 수백만 개의 요청을 처리할 수 있으며, TCP, UDP 및 TLS (전송 계층 보안) 연결에서 최고 성능을 제공합니다.

Application Load Balancer는 HTTP 및 HTTPS 트래픽에 최적화되어 있으며, 요청 수준에서 (7 계층) 라우팅하는 능력이 있습니다.

이러한 서비스는 AWS의 클라우드 인프라에서 고 가용성과 확장 가능한 웹 애플리케이션을 구축하는데 중요한 역할을 합니다.

• Elastic Load Balancer는 클라우드 환경에서 트래픽을 여러 대의 EC2 인스턴스 또는 컨테이너 인스턴스로 분산하는 로드 밸런서 서비스입니다.
• ELB는 여러 개의 가용 영역에서 인스턴스를 로드 밸런싱하여 고가용성을 제공합니다. 고객의 요청을 여러 인스턴스로 분산시켜 부하를 분담하고, 장애 발생 시 다른 인스턴스로 트래픽을 자동으로 전환하여 서비스의 지속성을 보장합니다.
• ELB는 클라이언트의 요청을 받아 인스턴스 그룹으로 트래픽을 분산하는 기능을 수행하며, 사용자 정의 세션 설정, SSL/TLS 종료, 상태 검사 등 다양한 기능을 제공합니다.
• ELB는 Application Load Balancer(ALB), Network Load Balancer(NLB), Classic Load Balancer(CLB)로 구분됩니다. 각각의 유형은 서비스 제공 요구사항에 맞게 선택하여 사용할 수 있습니다.