You have a web portal composed of two services. Each service musts scale independently. Both services should be served under the same domain. Which configuration allows this? A. Use one AWS Classic Load Balancer. Create a redirect in the web server based on users' source IPs. B. Use two AWS Application Load Balancer; one for each service. Assign the same CNAME to both. C. Use one AWS Application Load Balancer. Specify listener rules to route requests to each service. D. Use two AWS Classic Load Balancers; one for each service. Assign the same CNAME to both.
두 개의 서비스로 구성된 웹 포털이 있습니다. 각 서비스는 독립적으로 확장해야합니다. 두 서비스 모두 동일한 도메인에서 제공되어야합니다. 어떤 구성이 가능합니까? A. 하나의 AWS Classic Load Balancer를 사용하십시오. 사용자의 소스 IP를 기반으로 웹 서버에서 리디렉션을 만듭니다. B. 두 개의 AWS Application Load Balancer를 사용하십시오. 각 서비스마다 하나씩. 동일한 CNAME을 둘 다에 지정하십시오. C. 하나의 AWS Application Load Balancer를 사용하십시오. 요청을 각 서비스로 라우팅 할 리스너 규칙을 지정하십시오. D. 두 개의 AWS Classic Load Balancer를 사용하십시오. 각 서비스마다 하나씩. 동일한 CNAME을 둘 다에 지정하십시오.
이문제는 하나의 domain 으로 두가지의 서비스가 가능한지 물어보는 서비스이다.
A. 출발지 IP 기반하여 서비스를 분기하는데 같은 IP에선 하나의 서비스만 사용할수 있다. 애초에 문제와 동떨어진 답이다.
B. 두개의 ALB를 사용하고 같은 CNAME 을 사용한다. DNS 라운드로빈으로 서비스되게 된다. 정상적인 서비스는 아니다.
C. 하나의 ALB를 사용하고 리스너 규칙을 이용하여 라우팅한다. 정답이다.
D. 두개의 CLB, B와 같이 DNS 라운드 로빈으로 작동하여 정상적인 서비스가 아니다.
그렇다면 여기에서 어떻게 하나의 리스너가 서비스 별로 분기가 가능한지 확인해 보자
리스너 규칙을 확인해 보면 현재 80->443으로 리디렉션 하고 443 리스너는 linuxer-blog-wg 로 전달한다.
https: 443 리스너의 규칙 보기를 누르면 다음과 같다.
그냥 단일로 전달하는 구성이다. 나는 여기서 같은 도메인으로 셋팅후에 /test /test2 로 조건 분기를 하려고 한다. 설정은 다음과 같다.
host는 admin.linuxer.name 이다. 이후 리디렉션으로 각각의 다른 게시물로 연결된다.
Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.
To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.
You are receiving this message because you have an Amazon RDS database instance(s) in the AP-NORTHEAST-1, AP-NORTHEAST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.
Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.
/* 구분자를 ";" 으(로) 변경 / / linuxer-blog-rds.ctekipxl.ap-northeast-2.rds.amazonaws.com 에 MariaDB (SSH tunnel) 을(를) 통해 연결 중, 사용자 이름 "admin", 암호 사용: Yes… / / SSL 매개 변수를 성공적으로 설정하였습니다. / / Attempt to create plink.exe process, waiting 4s for response … / / / SELECT CONNECTION_ID(); / 연결됨. 스레드-ID: 579 / / 문자 집합: utf8mb4 */
보안을 고려한 설계 Amazon RDS for MySQL, Amazon RDS for MariaDB 및 Amazon RDS for PostgreSQL의 읽기 전용 복제본을 생성할 때, Amazon RDS는 리전 간에 복제하더라도 원본 DB 인스턴스와 읽기 전용 복제본 간에 퍼블릭 키 암호화를 사용하여 안전한 통신 채널을 설정합니다. Amazon RDS는 안전한 채널을 제공하는 데 필요한 모든 AWS 보안 구성(예: 보안 그룹 항목을 추가)을 설정합니다.
퍼블릭키 암호화 부분이 CA를 사용하는건 아닐까하는 궁금증이었는데,
스크린샷을 찍어가며 작업한것은 아니나, CA-2015 에서 생성한 읽기전용복제본의 인증기관을 2015 로 설정하고 마스터는 CA-2019 로 변경시에 퍼블릭키를 이용한 암호화 채널에는 아무 문제가 없었다.
고로 퍼블릭 키는 별도의 퍼블릭키라 결론을 내렸다.
현재 CA-2015 에서 CA-2019로 교체이슈가 뜨겁다.
즉시적용이던 유지관리에 적용이던 얼른적용하자. 사실 RDS에서 SSL 인증을 사용하는것이 아니면 기능상의 문제는 없으나....
이벤트에 의해 강제로 리부팅되고 단절에의해 서비스에 장애가 생기는거 보단 미리하는것이 나을것이라 생각한다.
흔히들 한글도메인을 많이 사용한다. 처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.
route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.
간단하다 모든 네임서버는 한글을 인식할수 없다.
그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.
퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.
