728x90
반응형

In the Intermediate part of the workshop, you will:

In the Advanced part of the workshop, you will:

AWS Cloud9 (CloudShell) Setup

Clone lab resources using git

git clone https://github.com/aws-samples/cfn101-workshop

Install the latest version of AWS CLI

cd cfn101-workshop/code/solutions/cloud9
chmod +x awscliv2.sh
source awscliv2.sh
aws --version
# aws-cli/2.31.34 Python/3.13.9 Linux/6.1.155-176.282.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023

Local Development Setup

We recommend you install the AWS CloudFormation Linter . A linter 

will proactively flag basic errors in your CloudFormation templates before you deploy them.

If you are using Visual Studio Code, you should install the cfn-lint plugin.

pip install cfn-lint

Default VPC

default VPC using the Amazon VPC console

$ aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query "Vpcs[].VpcId" --region us-east-1
[
    "vpc-xxxxxxxxxxxxxaa89"
]

Basics

cd cfn101-workshop/code/workspace
aws cloudformation create-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml

template-and-stack.yaml file

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256

use the AWS CLI to create the stack - create-stack command was successfully sent, CloudFormation will return StackId

$ aws cloudformation create-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxx7753:stack/cfn-workshop-template-and-stack/xxxxxxxx-xxxx-xxxx-xxxx-0e672ed843db"
}

Challenge

객체가 삭제되거나 덮어쓰는 것을 방지하거나, 객체를 보관하여 이전 버전으로 복구할 수 있도록 S3 버킷에서 버전 관리를 활성화

- S3 리소스의 속성 섹션에 VersioningConfiguration 속성을 생성
- 상태를 enabled 설정
- 템플릿에서 변경된 내용을 반영하도록 스택을 업데이트

# add Properties
        VersioningConfiguration:
          Status: Enabled

스택 업데이트

$ aws cloudformation update-stack --stack-name cfn-workshop-template-and-stack --template-body file://template-and-stack.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxx7753:stack/cfn-workshop-template-and-stack/xxxxxxxx-xxxx-xxxx-xxxx-0e672ed843db"
}

 

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

AWS certificate  (0) 2025.11.03
[AWS] Route53 S2S VPN  (0) 2025.10.29
[AWS] Route53 query logging  (1) 2025.08.07
[AWS] ALB listener server response header on|off  (0) 2025.05.19
[AWS] Direct Connect 설정  (0) 2025.05.19
728x90
반응형

25.11.03 기준

Foundational

AWS Certified Cloud Practitioner

: CLF-C02 / 719 questions

https://www.examtopics.com/exams/amazon/aws-certified-cloud-practitioner-clf-c02/

AWS Certified AI Practitioner

: AIF-C01 / 318 questions

https://www.examtopics.com/exams/amazon/aws-certified-ai-practitioner-aif-c01/

Associate

AWS Certified Solutions Architect - Associate

: SAA-C03 / 1019 questions

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/

AWS Certified Machine Learning Engineer - Associate

: MLA-C01 / 145 questions

https://www.examtopics.com/exams/amazon/aws-certified-machine-learning-engineer-associate-mla-c01/

AWS Certified Developer - Associate

: DVA-C02 / 557 questions

https://www.examtopics.com/exams/amazon/aws-certified-developer-associate-dva-c02/

AWS Certified CloudOps Engineer - Associate

: SOA-C03 / 478 questions (C02 기준)

https://www.examtopics.com/exams/amazon/aws-certified-sysops-administrator-associate/

AWS Certified Data Engineer - Associate

: DEA-C01 / 261 questions

https://www.examtopics.com/exams/amazon/aws-certified-data-engineer-associate-dea-c01/

Professional

AWS Certified Solutions Architect - Professional

: SAP-C02 / 529 questions

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-professional-sap-c02/

AWS Certified DevOps Engineer - Professional

: DOP-C02 / 390 questions

https://www.examtopics.com/exams/amazon/aws-certified-devops-engineer-professional-dop-c02/

AWS Certified Generative AI Developer - Professional[베타 시험]

: -

Specialty

AWS Certified Machine Learning - Specialty (until March 31, 2026)

: MLS-C01 / 369 questions

https://www.examtopics.com/exams/amazon/aws-certified-machine-learning-specialty/

AWS Certified Security - Specialty

: SCS-C02 / 307 questions

https://www.examtopics.com/exams/amazon/aws-certified-security-specialty-scs-c02/

AWS Certified Advanced Networking - Specialty

: ANS-C01 / 272 questions

https://www.examtopics.com/exams/amazon/aws-certified-advanced-networking-specialty-ans-c01/

 

References: 

https://aws.amazon.com/ko/certification/

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] CloudFormation Workshop#01 - template and stack  (0) 2025.11.20
[AWS] Route53 S2S VPN  (0) 2025.10.29
[AWS] Route53 query logging  (1) 2025.08.07
[AWS] ALB listener server response header on|off  (0) 2025.05.19
[AWS] Direct Connect 설정  (0) 2025.05.19
728x90
반응형

VPN Basics

VPN allows hosts to communicate privately over an untrusted intermediary network like internet, in encrypted from

 

-

AWS 측 VPC: 10.0.0.0/16

onpremise 측 VPC: 192.168.0.0/16 (172.31.0.0/16)

 

VGW 생성

CGW 생성 (onprem-VPC의 EC2 인스턴스 퍼블릭 IP)

Site-to-Site VPN connection 생성 (static IP prefixes: 192.168.0.0/16)

 

IP Sec down

- VPN connections 우측 상단 Download configuration 버튼을 클릭하여, 각 고객 게이트웨이 디바이스 제공업체 별 configuration 파일 다운로드

- Actions > Modify VPN tunel options > 터널 1 선택하여 log group 설정(로그 기록 활성화 가능)

 

on-prem 라우터 설정

instance 설정 >

 

onprem-EC2에 strongswan 설치 및 설정

sudo yum update
sudo yum install strongswan  # Amazon Linux 2023에는 strongswan 패키지가 기본 저장소에 없음
sudo yum install libreswan -y

 

AWS-VPC 라우팅 테이블 설정

192.168.0.0/16 -> Virtual Private Gateway

Onprem-VPC 라우팅 테이블 설정

10.0.0.0/16 -> Local VPN instance

 

연결 테스트

# AWS-EC2에서

ping <onprem-EC2-private-IP>

# onprem-EC2에서

ping <AWS-EC2-private-IP>

 

-

CloudFormation Stacks > Outputs

Key
Value
Description
AppServerPrivate
192.168.2.20
Private IP of App Server
DNSServerPrivate
192.168.2.250
DNS Server IP Address on DataCenter
Router1Private
192.168.1.10
Private IP of Router1
Router1Public
3.34.31.6
Public IP of Router1

 

Transit gateway attachments > VPN type, IP Address: Router1Public, BGP ASN: 65016

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] CloudFormation Workshop#01 - template and stack  (0) 2025.11.20
AWS certificate  (0) 2025.11.03
[AWS] Route53 query logging  (1) 2025.08.07
[AWS] ALB listener server response header on|off  (0) 2025.05.19
[AWS] Direct Connect 설정  (0) 2025.05.19
728x90
반응형

AWS Route 53 resolver의 CreateResolverQueryLogConfig 시

query logs의 Destination을 bucket name으로 설정할 경우, 

aws route53resolver create-resolver-query-log-config --name "log-config-name" --destination-arn "arn:aws:s3:::s3-query-logging"

 

S3 버킷 삭제

aws s3api delete-bucket-policy --bucket s3-query-logging

Empty bucket > permanently delete

 

AssociateResolverQueryLogConfig API 실행

aws route53resolver associate-resolver-query-log-config --resolver-query-log-config-id "rqlc-12aaa456fxxx4519" --resource-id "vpc-0a53xxxxxxxxx2deb"

 

정상 생성(Active)

{
    "ResolverQueryLogConfigAssociation": {
        "Id": "rqlca-8389713dfa194521",
        "ResolverQueryLogConfigId": "rqlc-12aaa456f7394519",
        "ResourceId": "vpc-0a535fa915c062deb",
        "Status": "CREATING",
        "Error": "NONE",
        "ErrorMessage": "",
        "CreationTime": "2025-08-07T07:06:27.873745085Z"
    }
}

VPC가 타 query log config와 연결되어 있을 경우

An error occurred (InvalidRequestException) when calling the AssociateResolverQueryLogConfig operation: [RSLVR-01306] The resource is already associated with a query logging configuration that is sending query logs to the specified destination type. Trace Id: "1-689450aa-38d4c77e583b368f14ffa282"

버킷 삭제 시(Failed)

INTERNAL_SERVICE_ERROR[RSLVR-00200] Internal Service Error, trace ID: "1-6894513d-1a1dxxxxxxxxxxxxxxxx4477"

 

ACCESS_DENIED: Account is not authorized to perform this operation.

 

References: 

[1] AssociateResolverQueryLogConfig - Errors - https://docs.aws.amazon.com/ko_kr/Route53/latest/APIReference/API_route53resolver_AssociateResolverQueryLogConfig.html#API_route53resolver_AssociateResolverQueryLogConfig_Errors

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

AWS certificate  (0) 2025.11.03
[AWS] Route53 S2S VPN  (0) 2025.10.29
[AWS] ALB listener server response header on|off  (0) 2025.05.19
[AWS] Direct Connect 설정  (0) 2025.05.19
[AWS] EC2 SSM Agent connection lost  (0) 2025.05.12
728x90
반응형

ALB는 대상 응답에 서버 헤더가 없는 경우에만 awselb/2.0 값을 갖는 서버 헤더 정보를 추가한다.

이 때 서버 헤더를 비활성화(enabled false)할 경우, 헤더 정보를 추가하지 않도록 설정하여 awselb/2.0과 같은 서버 정보가 노출되는 것을 방지할 수 있다.

 자동 스캐닝 도구나 공격자가 특정 서버 소프트웨어에서 발견된 취약점을 악용하는 것을 방지한다.

while true; do 
    echo "============= $(date '+%Y-%m-%d %H:%M:%S') ============="
    curl -k -I -w "time: %{time_total}s\n" https://ALB-1234567890.us-east-1.elb.amazonaws.com
    echo "====================================================="
    sleep 1
done

 

ALB server response header 설정(save changes) 후 적용되기까지 10초 정도 소요

- 리스너 단위 설정, Edit listener attributes

=====================================================
============= 2025-05-19 16:50:52 =============
HTTP/2 503 
server: awselb/2.0
date: Mon, 19 May 2025 07:50:53 GMT
content-type: text/html
content-length: 162

time: 0.582316s
=====================================================
============= 2025-05-19 16:50:54 =============
HTTP/2 503 
date: Mon, 19 May 2025 07:50:55 GMT
content-type: text/html
content-length: 162

time: 0.599829s
=====================================================

 

true: server header on

false: server header off

aws elbv2 modify-listener-attributes \
  --listener-arn ARN \
  --attributes Key="routing.http.response.server.enabled",Value=false

 

 

References:

[1] Application Load Balancer에 대한 HTTP 헤더 수정 - 헤더 비활성화 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/header-modification.html#disable-header
[2] AWS Application Load Balancer introduces header modification for enhanced traffic control and security - https://aws.amazon.com/about-aws/whats-new/2024/11/aws-application-load-balancer-header-modification-enhanced-traffic-control-security/
[3] Securing your web applications and optimizing their performance with AWS Application Load Balancer - https://aws.amazon.com/blogs/networking-and-content-delivery/securing-your-web-applications-and-optimizing-their-performance-with-aws-application-load-balancer/?nc1=h_ls

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] Route53 S2S VPN  (0) 2025.10.29
[AWS] Route53 query logging  (1) 2025.08.07
[AWS] Direct Connect 설정  (0) 2025.05.19
[AWS] EC2 SSM Agent connection lost  (0) 2025.05.12
BIND server 구성  (0) 2025.04.17
728x90
반응형

DX 로케이션 경유하여 AWS와 사설 네트워크를 연결

AWS Cloud -(AWS 백본)- AWS DX location - IDC

 

1) DX 연결

: Connections > State: ordering > Accept

- Pending available: 계정과 물리 연결이 활성화됨

AWS Cloud - AWS DX <-> onPrem 간 호스팅 연결 활성화

 

2) Direct Connect Gateway(DXGW) 생성

: Direct Connect gateways > Create > dxgw1, ASN 65011

- DXGW - AWS DX

 

3) DXGW에 VGW(VGW1, VGW2) 연결

: 생성한 GW ID 클릭(dxgw1) > Gateway associations - Associate > Gateways: VGW1, VGW2

(Allowed prefiexs를 입력하지 않으면 자동으로 VPC1과 VPC2의 CIDR 대역이 자동으로 할당됨, DXGW는 이렇게 허용된 접두사를 온프렘(고객 라우터)으로 전파(광고)) > 5~7분 대기(State: associated로 변경됨)

- AWS Cloud 내 VPC - VGW - DXGW 연결

 

4) Private VIF 생성 (on DX1/DX2)

: Virtual Interfaces > Create > 인터페이스 유형 선택, dx1-pri-v157, connection/DXGW/VLAN, ASN(65000)

+ Additional settings: user/Amazon router peer IP, BGP 인증키 입력 후 생성

- AWS DX <-> onPrem connect 간 VIF 생성

 

5) 온프렘 라우터 설정 (VLAN 인터페이스 및 BGP Peering 설정)

# 라우터 버전 정보 확인
show version
# 설정 모드 진입
config terminal # or conf t
# 명령어 입력(exec) 모드로 나오기
end

 

라우터 콘솔 명령 - 인터페이스 IP 설정

- dot1Q: IEEE 802.1Q 표준, 802.1Q VLAN 태깅을 사용하여 VLAN 157에 대한 캡슐화 설정

# (config)#
interface InterfaceEthernet1.157
# (config-subif)#
encapsulation dot1Q 157
ip address 10.0.1.1 255.255.255.252
end

 

show ip interface brief
sh ip int br

 

Interface              IP-Address      OK? Method Status                Protocol
InterfaceEthernet1       unassigned      YES NVRAM  up                    up   
InterfaceEthernet1.157   10.0.1.1        YES manual up                    up

 

AWS 라우터까지 통신 확인

#ping 10.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

 

Your router peer IP: 10.0.1.1/30

Amazon router peer IP: 10.0.1.2/30

 

라우터에서 BGP peering 설정

- AWS console의 VIF 정보를 확인하여 BGP 설정

 

# AS 번호는 네트워크를 식별하는 고유 번호
# 64512-65534는 프라이빗 AS 번호 범위

# (config)#
# BGP 라우팅 프로세스 시작, 65000은 자신의 AS(Autonomous System) 번호
router bgp 65000
# (config-router)#
# BGP 피어(neighbor) 설정, 10.0.1.2: peer router의 ip 주소, 65011: 피어의 AS 번호
neighbor 10.0.1.2 remote-as 65011
neighbor 10.0.1.2 password BGPauthPW123!
# BGP로 광고할 네트워크 설정, 자신의 네트워크를 다른 AS에 알림
network 172.20.0.0 mask 255.255.0.0
end

 

 

 

(1) show ip bgp summary

AWS BGP peer 라우터(10.0.1.2)와 Peering이 정상적으로 이루어졌는지 확인

정상인 경우 'State/PfxRcd'에 전달받은 Prefix의 개수가 표시됨

# bgp peer(neighbor) 연결 상태
show ip bgp summary
# results
BGP router identifier 172.20.57.1, local AS number 65000
BGP table version is 4, main routing table version 4
3 network entries using 744 bytes of memory
3 path entries using 408 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1752 total bytes of memory
BGP activity 3/0 prefixes, 3/0 paths, scan interval 60 secs
3 networks peaked at 18:02:26 May 14 2025 KST (4d19h ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.1.2        4        65011   14335   15133        4    0    0 4d19h           2

 

(2) show ip bgp

AWS 측 라우터(10.0.1.2)로부터 전달받은 Prefix를 확인

VGW1와 VGW2에 연결된 VPC1와 VPC2의 CIDR 대역(10.1.1.0/24, 10.1.2.0/24)이 온프렘 라우터로 전파된 것 확인

# bgp로 전달 받은 경로
show ip bgp

BGP table version is 4, local router ID is 172.20.57.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.1.1.0/24      10.0.1.2                               0 65011 i
 *>   10.1.2.0/24      10.0.1.2                               0 65011 i
 *>   172.20.0.0       0.0.0.0                  0         32768 i

# 라우터에서 참조하는 라우팅 경로
show ip route

 

 

on-prem과 EC2 instance 통신 확인 (ping test)

- VPC(10.1.1.0/24) 내 EC2 인스턴스 IP 주소: 10.1.1.10

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] Route53 query logging  (1) 2025.08.07
[AWS] ALB listener server response header on|off  (0) 2025.05.19
[AWS] EC2 SSM Agent connection lost  (0) 2025.05.12
BIND server 구성  (0) 2025.04.17
[AWS] 사설 인증서 생성 및 등록  (0) 2025.04.16
728x90
반응형

SSM Agent 서비스 상태 문제

  • SSM Agent 서비스가 중지되었거나 충돌이 발생했을 수 있음
  • 다음 명령어로 확인/재시작 가능:
# Amazon Linux, RHEL의 경우
sudo systemctl status amazon-ssm-agent
sudo systemctl restart amazon-ssm-agent

# 로그 확인
sudo tail -f /var/log/amazon/ssm/amazon-ssm-agent.log

# Ubuntu의 경우
sudo service amazon-ssm-agent status
sudo service amazon-ssm-agent restart

인스턴스 리소스 문제

  • 메모리 부족이나 CPU 과부하로 인해 Agent가 제대로 작동하지 않을 수 있음
  • 시스템 리소스 사용량 확인 필요

SSM Agent 버전 문제

  • Agent 버전이 오래되었거나 업데이트 중 문제가 발생했을 수 있음
  • 최신 버전으로 재설치 시도:
sudo yum install -y amazon-ssm-agent  # Amazon Linux
sudo apt-get install amazon-ssm-agent # Ubuntu

 

---

System Manager

VPC 엔드포인트 사용의 대체 방법은 관리형 인스턴스에서 아웃바운드 인터넷 액세스를 허용하는 것

이 경우 관리형 인스턴스는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 한다.

  • ssm.region.amazonaws.com
  • ssmmessages.region.amazonaws.com
  • ec2messages.region.amazonaws.com

 

References

[1] Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선 - https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/setup-create-vpc.html

 

Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선 - AWS Systems Manager

온프레미스 방화벽을 사용하고 Patch Manager를 사용하려는 경우 해당 방화벽에서 적절한 패치 기준 엔드포인트에 대한 액세스도 허용해야 합니다.

docs.aws.amazon.com

 

728x90
728x90
728x90
반응형

DNS 서버(BIND) 구축 방법

 

1. BIND 설치

- BIND (Berkeley Internet Name Domain)

# 설치
yum -y install bind bind-chroot bind-utils

 

2. 기본 설정 파일 수정 (/etc/named.conf)

# named.conf 수정
sudo vi /etc/named.conf

options {
        listen-on port 53 { any; };  # fixed
        listen-on-v6 port 53 { none; };  # or default (::1;)
        directory       "/var/named";
        dump-file      "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { any; };  # fixed
        recursion yes;
        
        dnssec-validation auto;
        auth-nxdomain no;  # fixed
};

요청한 도메인이 존재하지 않을 때 반환하는 DNS 코드 - no: RFC 표준 준수 (권장)

 

3. zone 파일 생성

# /var/named/example.com.zone 생성
sudo vi /var/named/example.com.zone

$TTL    86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023011001      ; Serial
                        3600            ; Refresh
                        1800            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      A       192.168.1.10
ns1     IN      A       192.168.1.10
www     IN      A       192.168.1.20

 

4. zone 설정을 named.conf에 추가

# /etc/named.conf에 추가
zone "example.com" IN {
        type master;
        file "example.com.zone";
        allow-update { none; };
};

    

 

5. 권한 및 소유권 설정

sudo chown root:named /var/named/example.com.zone
sudo chmod 640 /var/named/example.com.zone

 

6. 서비스 시작 및 자동 시작 설정

# 문법 체크
sudo named-checkconf
sudo named-checkzone example.com /var/named/example.com.zone
# - zone example.com/IN: loaded serial 2023011001
# - OK

# 서비스 시작
sudo systemctl start named
sudo systemctl enable named
# - reated symlink /etc/systemd/system/multi-user.target.wants/named.service → /usr/lib/systemd/system/named.service.
sudo systemctl status named

 

7. 방화벽 설정

    # firewalld 사용시
sudo firewall-cmd --permanent --add-port=53/tcp
sudo firewall-cmd --permanent --add-port=53/udp
sudo firewall-cmd --reload

# iptables 사용시
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 53 -j ACCEPT

    

 

8. 테스트

    # 로컬 테스트
dig @localhost example.com

# 특정 레코드 조회
dig www.example.com @localhost

 

# 결과

 

$ dig @localhost example.com

; <<>> DiG 9.18.33 <<>> @localhost example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45673
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a2fd5717dacbb8b201000000680b4c743807764a3f2cf3a6 (good)
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       192.168.1.10

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri Apr 25 08:48:52 UTC 2025
;; MSG SIZE  rcvd: 84

 

$ dig @localhost www.example.com

; <<>> DiG 9.18.33 <<>> 
http://www.example.com
 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e731811333abbe1101000000680b4ca5b60e5eccc01d1049 (good)
;; QUESTION SECTION:
;
http://www.example.com.
 IN      A

;; ANSWER SECTION:
http://www.example.com.
 86400   IN      A       192.168.1.20

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri Apr 25 08:49:41 UTC 2025
;; MSG SIZE  rcvd: 88

 

728x90
728x90
728x90
반응형

1. 사설 인증서 생성 (OpenSSL 사용)

# 1. 개인키(private key) 생성
openssl genrsa -out private.key 2048

# 2. CSR(Certificate Signing Request) 생성
openssl req -new -key private.key -out csr.pem

# 3. 자체 서명된 인증서 생성 (유효기간 365일)
openssl x509 -req -days 365 -in csr.pem -signkey private.key -out certificate.crt

 

2. AWS Certificate Manager(ACM)에 사설 인증서 가져오기

# 1. 인증서 체인 파일 생성 (certificate.crt 내용 복사)
cat certificate.crt > chain.pem

 

AWS Certificate Manager console 접속

Import certificate

Certificate details

Certificate body

certificate.crt 내용 붙여넣기

 
Certificate private key
프라이빗 키: private.key 내용 붙여넣기
 
Certificate chain - optionalInfo
인증서 체인: chain.pem 내용 붙여넣기
 
Import certificate

3. ALB에 인증서 등록

AWS Console에서:

  1. EC2 > Load Balancers
  2. 대상 ALB 선택
  3. "리스너" 탭 선택
  4. HTTPS 리스너 추가 또는 수정
    • 프로토콜: HTTPS
    • 포트: 443
    • 기본 작업: 대상 그룹 선택
    • 보안 정책: ELBSecurityPolicy-2016-08 (권장)
    • 인증서: 방금 가져온 사설 인증서 선택

CLI를 이용한 ALB 인증서 등록:

# 인증서 ARN 확인
aws acm list-certificates

# ALB 리스너에 인증서 추가
aws elbv2 add-listener-certificates \
    --listener-arn [리스너-ARN] \
    --certificates CertificateArn=[인증서-ARN]
# 인증서 정보 확인
openssl x509 -in certificate.crt -text -noout

# HTTPS 연결 테스트
curl -v https://saraheee.site
 
 
728x90
728x90
728x90
반응형

 

1. AWS Organizations structure 생성

 

2. Amazon VPC IP Address Manager console

- Planning > Organization settings > choose Delegate

Your IPAM is not discovering your organiziation's resources. For IPAM to discover resources in your entire organization you must delegate an account in your organization as the IPAM administrator. You cannot delegate the organization management account as the IPAM administrator.

 

3. IPAM 생성

 

4. IPAM 풀 생성

최상위 - 리전 - 사전 프로덕션 개발 풀

 

5. IPAM 풀 공유

- Resource Access Manager console - Settings > Enable sharing with AWS Organizations

- Amazon VPC IP Address Manager console - (Planning) Pools > choose Name (Pool ID) > Resource sharing > Create resource share

> Create resource share

  > Select resource type: IPAM Pools

  > Principals: Allow sharing only within your organization, select principal type: Organizational unit (OU)

 

References:

[1] Tutorial: Create an IPAM and pools using the console - https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-get-started-console.html

 

Tutorial: Create an IPAM and pools using the console - Amazon Virtual Private Cloud

For the purposes of this tutorial, the instructions will tell you to name IPAM resources in a particular way, create IPAM resources in specific Regions, and use specific IP address CIDR ranges for your pools. This is intended to streamline the choices avai

docs.aws.amazon.com

 

728x90
728x90
728x90
반응형


ALB는 수신하는 트래픽 처리를 위해 Scaling 동작을 수행하며 ALB 서비스 도메인에 대한 IP 주소가 동적으로 변경된다 [1].

1) Global Accelerator를 사용하면 고정 IP 확보는 가능하나 비용 효율적이지 않다 [2].

Global Accelerator 생성 시 기본적으로 2개의 고정 IP가 자동으로 할당된다. ALB를 엔드포인트로 추가하여 Global Accelerator의 두 고정 IP를 통해 ALB로 트래픽이 전달되도록 설정하실 수 있다.

 

2) ALB 앞 NLB를 사용하여 NLB의 대상으로 ALB를 연결할 수 있도록 배치하여 고정 IP를 사용하는 것과 동일한 효과를 얻을 수 있다 [3].

 

1), 2) 상세 내역 [4]

 

3) 2025-03-07 업데이트된 내역을 통해,
ALB가 IPAM과의 통합을 통해 ALB 노드에 IP 주소 할당을 위한 Public IPv4 주소 풀을 제공할 수 있게 되었다.
고객 소유의 BYOIPs (Bring Your Own IP addresses) 또는 Amazon에서 제공하는 인접한 IPv4 주소 블록으로 구성할 수 있는 공용 VPC IP Address Manager (IPAM) 풀을 구성할 수 있다.
이 때 ALB의 IP 주소는 IPAM 풀에서 소싱되며, 혹여 공용 IPAM 풀이 고갈되면 자동으로 AWS 관리형 IP 주소로 전환된다.

nslookup
> ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Server:		10.148.65.xx
Address:	10.148.65.xx#53

Non-authoritative answer:
Name:	ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Address: 18.97.9.137
Name:	ipam-alb-3168xxx70.us-east-1.elb.amazonaws.com
Address: 18.97.9.177
>

 

참고 사항으로, ELB 서비스가 사용하는 공인 IP는 하기 링크의 ip-ranges.json 파일에서 확인 가능하다.
us-east-1 리전에 ELB가 있는 경우, 서비스=EC2, 지역=us-east-1인 IP 주소 범위를 찾아 화이트리스트에 추가해야 한다.

(하지만 서비스가 지속적으로 성장하고 확장함에 따라 ip-ranges.json 파일도 변경될 수 있다.)

https://ip-ranges.amazonaws.com/ip-ranges.json

 

References:

[1] Application Load Balancers - 가용 영역 서브넷 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/application-load-balancers.html#availability-zones

[2] AWS Global Accelerator 구성 요소 - https://docs.aws.amazon.com/ko_kr/global-accelerator/latest/dg/introduction-components.html

[3] Network Load Balancer의 대상으로 Application Load Balancer 사용 - https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/network/application-load-balancer-target.html

[4] 애플리케이션 로드 밸런서(ALB)에 고정 IP 주소 설정 및 사용하기 - https://aws.amazon.com/ko/blogs/korea/using-static-ip-addresses-for-application-load-balancers/

[5] Application Load Balancer announces integration with Amazon VPC IPAM - https://aws.amazon.com/about-aws/whats-new/2025/03/application-load-balancer-integration-vpc-ipam/

[6] Blog: VPC IPAM을 사용하여 Application Load Balancer 고정 IP 사용하기 - https://zigispace.net/1320

 

728x90
728x90
728x90
반응형

Route53 Hybrid DNS

1. VPC 생성

- cloud: 10.0.0.0/16

- onprem: 192.168.0.0/16

- subnets, route tables, nat gateways 생성

2. 인스턴스 생성

cloud-app-server

- sg: ssh anywhere, icmp 192.168.0.0/16

onprem-app-server

- sg: ssh 192.168.0.0/16, icmp 10.0.0.0/16

onprem-vpn-server

- sg: ssh anywhere, dns (udp) 192.168.0.0/16, icmp 192.168.0.0/16

3. VPN 설정

1) Virtual private gateway (cloud-vgw)

2) Customer gateways (onprem-cgw) - onprem-vpn-server의 public IP address (Specify the IP address for your customer gateway device's external interface.)

3) VGW - attach to VPC: cloud-vpc

4) Site-to-Site VPN connections (cloud-onprem-vpn-connection)

- Routing options: Static

- Static IP prefixes: 192.168.0.0/16 (onprem-vpn range)

5) download VPN connections configurations - Platform: Openswan

4. SSH 접속

brew install putty
putty

Auth - Credentials - keypair.pem 경로

Session - Saved Sessions

IP: onprem-vpn-server's public IP

login as: ec2-user

ssh -i "ap-south-1-keypair.pem" ec2-user@35.x.x.x
 % sudo su
sh-3.2# ssh -i "ap-south-1-keypair.pem" ec2-user@35.154.187.78
The authenticity of host '35.x.x.x (35.x.x.x)' can't be established.
ED25519 key fingerprint is SHA256:qOx9yHXTxD6xaC9BfiT/Y5/82Ml/mVZzr5hNXnw9FQ8.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '35.x.x.x' (ED25519) to the list of known hosts.
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-192-168-0-220 ~]$
sudo yum install libreswan
sudo vi /etc/sysctl.conf

1) Open /etc/sysctl.conf and ensure that its values match the following:
   net.ipv4.ip_forward = 1
   net.ipv4.conf.default.rp_filter = 0
   net.ipv4.conf.default.accept_source_route = 0

2) Apply the changes in step 1 by executing the command 'sysctl -p'

sudo sysctl -p

3) Open /etc/ipsec.conf and look for the line below. Ensure that the # in front of the line has been removed, then save and exit the file.
    #include /etc/ipsec.d/*.conf

이미 제거된 상태로 저장됨

cat /etc/ipsec.conf

4) Create a new file at /etc/ipsec.d/aws.conf if doesn't already exist, and then open it. Append the following configuration to the end in the file:
 #leftsubnet= is the local network behind your openswan server, and you will need to replace the <LOCAL NETWORK> below with this value (don't include the brackets). If you have multiple subnets, you can use 0.0.0.0/0 instead.
 #rightsubnet= is the remote network on the other side of your VPN tunnel that you wish to have connectivity with, and you will need to replace <REMOTE NETWORK> with this value (don't include brackets).

conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=35.x.x.x
right=13.x.x.x
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=<LOCAL NETWORK>
rightsubnet=<REMOTE NETWORK>
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer

sudo vi /etc/ipsec.d/aws.conf
conn Tunnel1
        authby=secret
        auto=start
        left=%defaultroute
        leftid=35.x.x.x
        right=13.x.x.x
        type=tunnel
        ikelifetime=8h
        keylife=1h
        phase2alg=aes256-sha1;modp2048
        ike=aes256-sha1;modp2048
        keyingtries=%forever
        keyexchange=ike
        leftsubnet=192.168.0.0/16
        rightsubnet=10.0.0.0/16
        dpddelay=10
        dpdtimeout=30
        dpdaction=restart_by_peer

5) Create a new file at /etc/ipsec.d/aws.secrets if it doesn't already exist, and append this line to the file (be mindful of the spacing!):
35.x.x.x 13.x.x.x: PSK "TOC3RK--------------------IUtns"

sudo vi /etc/ipsec.d/aws.secrets

Tunnel 1 구성 완료

sudo systemctl start ipsec.service
sudo systemctl status ipsec.service

5. Route Tables 설정 (propagation)

cloud-vpc-private-rt > Route propagation > Propagation: Enable

또는 Routes 편집 (cloud-vgw)

cloud-vpc-public-rt도 동일하게 설정

6. VPN 서버의 목적지 비활성화

Instances: onprem-vpn-server > Actions - Networking - Change Source / destination check > check Stop > Save

Route tables: cloud-vpc-public-rt > 10.0.0.0/16 instance (onprem-vpn-server)

7. Cloud Instance 접속

cloud-app-server public IP

ssh -i "ap-south-1-keypair.pem" ec2-user@3.x.x.x

 

ping (onprem-app-server)

 

From Cloud EC2 instance - Ping to on-premises App server private IP

Cloud EC2 -> VGW -> VPN Tunnel 1 -> VPN server -> App server

 

728x90
728x90
728x90
반응형

도메인 등록을 위한 DNS 서비스를 변경하고 싶은 경우 퍼블릭 호스팅 영역의 이름 서버를 가져온다.

 

1) Route 53 console의 Hosted zones 내비게이션 바 클릭 > Hosted zone name 클릭

2) Hosted zone details의 Name servers 4개 저장

3) Route 53 console의 Domains - Registered domains 내비게이션 바 클릭

4) Actions - Edit name servers

 

5) 2)에서 저장한 name servers 입력 후 저장

 

[1] 퍼블릭 호스팅 영역에 대한 이름 서버 가져오기 - https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/GetInfoAboutHostedZone.html

728x90
728x90
728x90
반응형

1. AWS VPC

VPC를 사용하면 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하다.

서브넷: VPC의 IP 주소 범위, 단일 가용 영역에 상주

라우팅: 라우팅 테이블을 사용해서 서브넷 또는 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정

게이트웨이 및 엔드포인트: 게이트웨이는 VPC를 다른 네트워크에 연결, 인터넷 게이트웨이를 사용하여 VPC를 인터넷에 연결

피어링 연결: VPC 피어링 연결을 사용하여 두 VPC의 리소스 간 트래픽을 라우팅

VPC 흐름 로그: VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처

2. Security in VPC

보안 그룹: 리소스 수준(예: EC2 인스턴스)에서 특정 인바운드 및 아웃바운드 트래픽을 허용, 인스턴스를 시작할 때 하나 이상의 보안 그룹과 연결할 수 있다. VPC의 각 인스턴스는 서로 다른 보안 그룹 세트에 속할 수 있다.

네트워크 액세스 제어 목록(ACL): 네트워크 ACL은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부한다.

흐름 로그: VPC의 네트워크 인터페이스에서 양방향으로 이동하는 IP 트래픽에 대한 정보를 캡처한다. VPC, 서브넷 또는 개별 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있다.

흐름 로그 데이터는 CloudWatch logs 또는 Amazon S3에 게시되며 과도하게 제한하거나 과도하게 허용하는 보안 그룹과 네트워크 ACL 규칙을 진단하는 데 도움이 된다.

트래픽 미러링: Amazon EC2 인스턴스의 탄력적 네트워크 인터페이스에서 네트워크 트래픽을 복사할 수 있다.

3. VPC Peering

VPC는 사용자의 AWS 계정 전용 가상 네트워크이다. AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다.

VPC 피어링 연결은 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워크 연결이다.

동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신할 수 있다. 사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있으며, VPC는 상이한 리전에 있을 수 있다.

VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성한다. 이는 게이트웨이도, VPN 연결도 아니며 물리적 하드웨어 각각에 의존하지 않는다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없다.

4. VPC Flowlogs

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능이다. 흐름 로그 데이터가 게시될 수 있는 위치는 Amazon CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose이다.

흐름 로그를 생성하면 구성한 로그 그룹, 버킷 또는 전송 스트림의 흐름 로그 레코드를 검색하고 볼 수 있다.

5. VPC PrivateLink

VPC에 인터넷 게이트웨이를 추가하여 인터넷 액세스를 허용하거나 VPN 연결을 추가하여 온프레미스 네트워크 액세스를 허용할 수 있다.

VPC의 클라이언트가 프라이빗 IP 주소를 사용하여 다른 VPCs의 서비스 및 리소스에 연결할 수 있도록 AWS PrivateLink 하려면 해당 서비스 및 리소스가 VPC에서 직접 호스팅된 것처럼 사용한다.

6. NAT Instance

NAT 인스턴스는 Network Address Translation(NAT)을 제공한다. NAT 인스턴스를 사용하면 프라이빗 서브넷의 리소스가 인터넷이나 온프레미스 네트워크와 같은 VPC 외부의 대상과 통신할 수 있다. 프라이빗 서브넷의 리소스는 인터넷으로 향하는 아웃바운드 IPv4 트래픽을 시작할 수 있지만 인터넷에서 시작된 인바운드 트래픽을 수신할 수는 없다.

NAT 인스턴스는 퍼블릭 인터넷에 있어야 하며, NAT 인스턴스에는 퍼블릭 IP 주소 또는 탄력적 IP 주소가 있어야 한다.

7. NAT Gateway

NAT 게이트웨이는 NAT 서비스로, 프라이빗 서브넷의 인스턴스가 VPC 외부의 서브넷에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

퍼블릭 - (기본값) 퍼블릭 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 이지만 인터넷에서 원치 않는 연결을 수신할 수 없다. 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 한다.

프라이빗 - 프라이빗 서브넷 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다.

8. IPv6 migration

IPv4만을 지원하는 기존 VPC와 서브넷에서 IPv4만을 사용하도록 구성된 리소스가 있으면 VPC 및 리소스에 대한 IPv6 지원을 추가할 수 있다.

 

References: 

1. AWS VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html

2. Security in VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
3. VPC Peering - http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html
4. VPC Flowlogs - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html
5. VPC PrivateLink - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html
6. NAT Instance - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html
7. NAT Gateway - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html
8. IPv6 migration - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html

 

728x90
728x90
728x90
반응형

VPC DNS resolver 우선 순위

0. DNS firewall (R53 전용 Network Firewall)

 

1. Route 53 Resolver 규칙
   - 명시적으로 정의된 Outbound 규칙
   - 도메인 기반 포워딩 규칙


2. Private Hosted Zone
   - VPC와 연결된 프라이빗 호스팅 영역

$ dig example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.9 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63355
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; AUTHORITY SECTION:
saraheee.site.          900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Thu Feb 06 07:15:42 UTC 2025
;; MSG SIZE  rcvd: 129


3. Default VPC Resolver
   - VPC의 기본 .2 리졸버

$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search anycompany.corp
nameserver 192.168.2.250
nameserver 192.168.0.2

 

4. Public DNS resolve 시도 (Route 53 Public Hosted Zone 포함)

$ dig example.com
; <<>> DiG 9.18.28 <<>> example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; ANSWER SECTION:
saraheee.site.          30      IN      A       8.8.8.8

;; Query time: 1610 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Feb 06 07:15:47 UTC 2025;; MSG SIZE  rcvd: 58

 

아웃바운드 엔드포인트가 구성된 Resolver 규칙이 있는 경우, 프라이빗 호스팅 영역과 동일한 VPC에 연결되어 있을 때 리졸버 규칙이 우선적으로 적용될 수 있다.

다만 Private hosted zone이 VPC 내부에서만 작동하는 DNS라, dig +trace 시 공개적인 DNS 해석 과정이 포함된 root DNS와는 독립적으로 작동한다.

 

-

규칙이 동일한 도메인 수준에 있다면, 해당 규칙의 우선 순위는 다음과 같습니다.

  1. Resolver 규칙
  2. 프라이빗 호스팅 영역
  3. 내부 규칙

 

References: 

[1] Route 53 프라이빗 호스팅 영역의 DNS 확인 문제를 해결하려면 어떻게 해야 하나요? - https://repost.aws/ko/knowledge-center/route-53-fix-dns-resolution-private-zone

 

Route 53 프라이빗 호스팅 영역 DNS 확인 문제 해결

Amazon Route 53 프라이빗 호스팅 영역의 DNS 확인 문제를 해결하고 싶습니다.

repost.aws

 

728x90
728x90
728x90
반응형

 

본인 IP 조회

curl ifconfig.me

 

1. 데이터베이스 계정에 RDS DB 인스턴스 및 RDS 프록시 생성

2. RDS Proxy 엔드포인트에 할당된 IP 주소 식별

- dig (proxy endpoint arn) 의 Answer section

3. 데이터베이스 계정에 PrivateLink 엔드포인트 서비스 생성

1) 데이터베이스 계정에 타겟 그룹 생성

2) 데이터베이스 계정에 Network Load Balancer 생성

3) 데이터베이스 계정에 VPC 엔드포인트 서비스 생성

4. 고객 계정에서 VPC 엔드포인트 생성

5. 연결 테스트

 

psql -h <db-endpoint> -p <port-number> -d <db-name> -U <username> -W

 

psql -h nlbdb-database-ee.cluster-c78suu4aug2x.us-east-1.rds.amazonaws.com -p 5432 -d nlbdb-database-ee -U postgres

 

References:

[] Connect to an AWS RDS PostgreSQL database using PSQL - https://onticdani.medium.com/connect-to-an-aws-rds-postgresql-database-using-psql-750c00b5ceb2

[] Access Amazon RDS across AWS accounts using AWS PrivateLink, Network Load Balancer, and Amazon RDS Proxy - https://aws.amazon.com/ko/blogs/database/access-amazon-rds-across-aws-accounts-using-aws-privatelink-network-load-balancer-and-amazon-rds-proxy/
[] Use Amazon RDS Proxy and AWS PrivateLink to access Amazon RDS databases across AWS Organizations at American Family Insurance Group - https://aws.amazon.com/blogs/database/use-amazon-rds-proxy-and-aws-privatelink-to-access-amazon-rds-databases-across-aws-organizations-at-american-family-insurance-group/

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] VPC - Basic docs  (0) 2025.02.10
[AWS] VPC DNS resolver 우선 순위  (0) 2025.02.06
[AWS] SAA-C03#12: Route 53 (2)  (0) 2024.08.07
[AWS] SAA-C03#11: Route 53 (1)  (0) 2024.08.07
[AWS] ANS-C01#02: VPC fundamentals  (2) 2024.07.24
728x90
반응형

Route 53 - Routing Policies

라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 도움, DNS 관점(DNS는 트래픽 라우팅하지 않음, 트래픽은 DNS를 통과하지 않음)
- 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스에 라우팅하는 것과는 다름
- DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 됨
- DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 도움
Route 53이 지원하는 라우팅 정책: 단순, 가중치 기반, 장애 조치, 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접 라우팅 정책
(Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity (using Route 53 Traffic Flow feature)

Routing Policies - Simple

트래픽을 단일 리소스로 보내는 방식
클라이언트가 foo.example.com으로 가고자 한다면 Route 53이 IP 주소를 알려주는 것 (A 레코드 주소)
동일한 레코드에 여러 개의 값을 지정하는 것도 가능함. DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 됨 (e.g., 클라이언트가 foo.example.com으로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답할 때(A 레코드에 임베딩된 주소), 클라이언트가 셋 중 하나를 골라 라우팅에 적용함)
단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있음 - 그렇기 때문에 상태 확인은 불가

Hands-on#04. Simple

value IP 추가하면서 테스트

Routing Policies - Weighted

가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능
한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지, 각 레코드에 상대적으로 가중치를 할당함
이렇게 하면 DNS 레코드들은 동일한 이름과 유형을 가져야 하고 상태 확인과도 관련될 수 있음
사용되는 경우: 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때, 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우
- 가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있음
- 만약 모든 리소스 레코드 가중치의 값이 0인 경우는 모든 레코드가 다시 동일한 가중치를 갖게 됨

Hands-on#05. Weighted

Record ID: 가중치 레코드 설정에서 이 특정 레코드를 식별하기 위해 사용됨
- simple 레코드는 여러 개의 IP 주소를 가진 반면 weighted 세 개의 레코드는 각각 하나의 값을 가짐

Routing Policies - Latency-based

지연 시간이 가장 짧은, 가장 가까운 리소스로 리다이렉팅하는 정책
지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우 유용한 정책
지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정
(e.g., 유저가 독일에 있고 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국으로 리다이렉팅이 될 것)
- 두 개의 다른 리전에 애플리케이션을 배포할 때

Hands-on#06. Latency-based

별칭이 해당 IP가 어느 지역에 있는 EC2 인스턴스에서 왔다는 것을 알 수 없기 때문에,
값에 IP 주소를 입력해도 이 IP의 리전을 표시해줘야 함

Route 53 - Health Checks

상태 확인은 공용 리소스에 대한 상태를 확인하는 방법
e.g., (다중 지역 셋업) 서로 다른 두 지역에 하나씩 로드 밸런서가 있고 둘은 모두 공용 로드 밸런서임, 그리고 그 둘의 뒤에서 애플리케이션이 작동 중 - 지역 레벨에서 고가용성을 원하는 상황
- Route 53을 이용해 DNS 레코드를 만들 것
- 유저가 mydomain.com과 같은 URL을 이용해 접속하면 해당 유저는 가장 가까운 로드 밸런서로 연결됨 (지연 시간 기반 레코드)
만약 한 지역이 사용 불가능 상태면 유저를 보내고 싶지 않기 때문에 Route 53에서 상태 확인을 생성해야 함
- 두 지역의 상태 확인을 Route 53의 레코드와 연결할 수 있음 (DNS의 장애 조치를 자동화하기 위한 작업)
세 가지의 상태 확인(Health Check)이 가능함
- 각 상태 확인은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인 가능
1) 공용 엔드 포인트를 모니터링하는 상태 확인
- 애플리케이션, 서버, 다른 AWS 리소스
2) 다른 상태 확인을 모니터링하는 상태 확인 (계산된 상태 확인)
3) CloudWatch 경보의 상태를 모니터링하는 상태 확인
- 제어가 쉽고 개인 리소스들에 유용함

Health Checks - Monitor an Endpoint

ALB에 대한 특정 지역의 상태 확인을 한다고 하면, 전 세계로부터 15개 정도의 AWS 상태 확인이 옴
→ 우리가 루트를 설정한 공용 엔드 포인트로 모두 요청을 보냄
→ 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정함 (200 OK 코드 또는 우리가 정의한 코드를 받으면 리소스는 정상으로 간주됨)
- 간격: 30초마다 정기적으로 확인 혹은 10초마다(더 높은 비용)
- 지원 프로토콜: HTTP, HTTPS, TCP
- 18% 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주함
- 상태 확인에 사용될 위치 선택 가능
- 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 됨
텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 byte를 확인함 (응답 자체에 해당 텍스트가 있는지 보기 위해)
상태 확인의 작동이 가능하려면 상태 확인이 ALB나 엔드 포인트에 접근이 가능해야 함
Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 함 (주소 범위는 https://ip-ranges.amazonaws.com/ip-ranges.json 참고)

Route 53 - Calculated Health Checks

여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
- 조건: OR, AND, NOT
하위 상태 확인을 256개까지 모니터링할 수 있고 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있음
→ 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 유지 관리하도록 하는 경우

Health Checks - Private Hosted Zones

개인의 리소스를 모니터링하는 것은 어려울 수 있음
Route 53 상태 확인이 공용 웹에 있기 때문에 health checkers는 VPC 외부에 있음
개인 엔드 포인트에 접근 불가능 (개인 VPC나 온프레미스 리소스)
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있음
→ CloudWatch 경보를 상태 확인에 할당할 수 있음 (CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링하는 것)
메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 되고, 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 됨
→ 개인 리소스에 대한 상태 확인 완료

Hands-on#07. Health Check

1) 엔드 포인트가 될 region 인스턴스의 상태 확인을 생성 (세 리전 모두)
path: /health (엔드 포인트 자체의 상태에 대한 응답)
Advanced configuration: String matching - 첫 5120 바이트 문자열을 비교할지 여부를 선택
2) 특정 region에 있는 한 인스턴스의 보안 그룹에서 80번 포트를 차단하고 security groups의 HTTP 관련 rule을 삭제 (상태 확인 장애를 발생시킴)
3) create health check - name: calculated / status of other health checks (calculated health check)
4) create health check - state of CloudWatch alarm
- 개인 EC2 인스턴스의 상태를 모니터링할 수 있음
- 개인 리소스의 상태 확인을 Route 53 상태 확인에 연결하는 것

Routing Policies - Failover (Active-Passive)

장애 조치에 관한 것
Route 53에 대해 하나는 기본 EC2 인스턴스, 하나는 보조 EC2 인스턴스(재해 복구 EC2 인스턴스)일 때
상태 확인과 기본 레코드를 연결하는데 필수적
상태 확인이 비정상이면 자동으로 Route 53은 두번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작함
보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있음
→ 클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻음

Hands-on#08. Failover

상태 확인을 통해 장애 조치 레코드를 생성 (호스팅 영역에서 레코드를 생성)
보안 그룹 수정하여 장애 조치가 실행되는 위치를 확인

Routing Policies - Geolocation

사용자의 실제 위치를 기반으로 함 (지연 시간 기반의 정책과는 다르게)
사용자가 특정 대륙이나 국가 또는 어떤 주에 있는지 지정하는 것이며, 가장 정확한 위치가 선택되어 그 IP로 라우팅되는 것
일치하는 위치가 없는 경우는 기본 레코드를 생성해야 함
사용 사례: 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화
- 상태 확인과 연결할 수 있음
e.g., 유럽의 지도에서, 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있음, 프랑스는 프랑스어의 버전의 앱을 가진 IP로 가야 함, 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 함

Hands-on#09. Geolocation

Location이 다른 IP에 대해 테스트

Geoproximity Routing Policy

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅함
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것
→ 지리적 위치를 변경하려면 편향값을 지정해야 함, 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 됨, 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됨
리소스는 AWS의 리소스로 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나, AWS 리소스가 아닌 온프레미스 데이터 센터의 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 함
기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용함
- 편향이 없다면, 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것
- 편향으로 인해 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있음, 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생함 (편향이 높을 경우)
예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됨
- 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것

Routing Policies - IP-based Routing

클라이언트 IP 주소를 기반으로 라우팅을 정의함 → Route 53에서 CIDR 목록을 정의함 (클라이언트 IP 범위) → CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지를 정함
- 이것을 사용하면 성능을 최적화할 수 있음, IP를 미리 알고 있기 때문
- 네트워크 비용을 절감할 수 있음, IP가 어디에서 오는지 알기 때문
예를 들어 특정 ISP가 특정 IP 주소 셋을 사용하는걸 안다면 특정 엔드포인트로 라우팅할 수 있음
e.g., Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의함 (location-1: 203.x.x.x/24, location-2: 200.x.x.x/24)
→ 로케이션을 레코드에 연결 (record name: example.com / value: 1.2.3.4 and 5.6.7.8 / IP-based: location1 and location2)
- 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타냄
→ 사용자 A가 location-1 CIDR blocks에 속하는 특정 IP로 들어오면 첫번째 EC2 인스턴스인 IP 1.2.3.4로 보내짐
+ 사용자 B가 location-2에 속하는 IP 주소로 들어오면 리디렉션되어 IP 5.6.7.8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 됨

Routing Policies - Multi-Value

- 트래픽을 다중 리소스로 라우팅할 때 사용함, 그래서 Route 53은 다중 값과 리소스를 반환함
- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있음
- 각 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
- ELB와 유사해 보이지만 ELB를 대체할 수는 없음 (클라이언트 측면의 로드 밸런싱)
e.g., example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결함
클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택함, 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있음
그래서 클라이언트는 안전한 쿼리를 가질 수 있음
e.g., 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있음, 이것이 다중 값이 조금 더 강력한 레코드 유형인 이유

Hands-on#10. Multi-Value

세 리전에 대한 multi
Health checks에서 Invert health check status 체크하여 정상에서 비정상으로 변경

Domain Registar vs. DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있음, 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공함, 그래서 Amazon 호스트 이름으로 DNS 이름을 등록했다면 DNS 레코드 관리를 위한 Route 53 호스팅 존을 가짐
도메인 이름을 등록하면 네임 서버 옵션이 생기는데 사용자 정의 이름 서버를 지정할 수 있음 (Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 우측 네임 서버를 구매한 사이트(GoDaddy 등)에서 변경해야 함)
GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 네임 서버가 Amazon의 Route 53 이름 서버를 가리키고 그렇게 Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리함
- 정리: 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53을 사용 가능한데, 사용하려면 Route 53에서 공용 호스팅 영역을 생성한 뒤 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 됨
→ 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스가 다름

 

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

 

728x90
728x90
728x90
반응형

DNS: Domain Name System which translates the human friendly hostnames into the machine IP addresses

DNS Terminologies (관련 용어)

Domain Registrar(도메인 이름 등록하는 곳): Amazon Route 53, GoDaddy, ...

DNS Records: A, AAAA, CNAME, NS, ...

Zone File: contains DNS records

Name Server: resolves DNS queries

1) Web Browser가 example.com에 접근하기 위해서는 Local DNS server에 물어볼 것
* Local DNS Server: 보통 회사에 의해 할당되고 관리되거나 ISP에 동적으로 할당됨
2) Local DNS Server가 이 쿼리를 본 적이 없다면 먼저 ICANN에 관리된 Root DNS Server에 물어볼 것
→ .com은 알고 있음 (.com NS 1.2.3.4) 반환
3) 1.2.3.4에 있는 .com 도메인 서버에게 쿼리의 답을 요청 (TLD DNS Server, Managed by IANA, Branch of ICANN)
→ DNS 서버는 example.com을 모르지만 example.com 이라는 서버는 알고 있음 (example.com NS 5.6.7.8)
4) 로컬 DNS 서버(서브도메인의 DNS 서버)에 질의: 도메인 네임 레지스트라(Route 53 등)에 의해 관리되는 서버, 최종 서버
→ example.com에 대해 알고 있음. example.com은 A 레코드이고 이것의 결과로 IP 9.10.11.12를 얻음

Route 53

a highly, available, scalable, fully managed and authoritative DNS, DNS 레코드를 업데이트할 수 있음
DNS 레코드를 아마존 Route 53의 호스팅 존에 쓰려고 함, 클라이언트가 example.com을 요청하면 Route 53 서비스가 IP 54.22.33.44를 찾고 있다고 응답함 → 클라이언트는 바로 EC2 인스턴스에 접근함, Route 53도 도메인 이름 레지스트라로 도메인 이름을 example.com으로 등록함
Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의함
각 레코드는 도메인이나 example.com과 같은 서브도메인 이름과 같은 정보를 포함함
* TTL: DNS 리졸버에서 레코드가 캐싱되는 시간

Route 53 - Record Types

A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
- 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있음
- Route 53에서 DNS namespace 또는 Zone Apex의 상위 노드에 대한 CNAME을 생성할 수 없음
(e.g., example.com에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME 레코드는 만들 수 있음)
NS - Name Servers for the Hosted Zone
- 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있음
- 트래픽이 도메인으로 라우팅되는 방식을 제어함

Route 53 - Hosted Zones

a container for records, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
Public Hosted Zones - 쿼리에 도메인 이름 application1.mypublicdomain.com의 IP가 무엇인지 알 수 없음
Private Hosted Zones - 공개되지 않은 도메인 이름을 지원, 가상 프라이빗 클라우드(VPC)만이 URL을 resolve할 수 있음(e.g., application1.company.internal)

Route 53 - Public vs. Private Hosted Zones

Public Hosted Zones: 공개된 클라이언트로부터 온 쿼리에 응답할 수 있음, 웹 브라우저에서 example.com을 요청하면 IP를 반환함
- 퍼블릭 레코드를 위한 호스팅 존
Private Hosted Zones: 해당 VPC에만 동작, 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있음
- 프라이빗 리소스, 예컨대, VPC에서만 쿼리할 수 있음

EC2 인스턴스가 1개 있고, webapp.example.internal을 식별하고자 함
또 다른 EC2 인스턴스에서는 api.example.internal을 식별하기 원하고 데이터베이스에서는 db.example.internal을 식별하고자 함
private hosted zone에 등록하고자 하는데, 첫번째 EC2 인스턴스가 api.example.internal을 요청하는 경우 프라이빗 호스팅 존은 프라이빗 IP 10.0.0.10이라는 답을 갖고 있음. EC2 인스턴스는 데이터베이스에 연결이 필요할 수도 있는 두번째 EC2 인스턴스에 연결하여 db.example.internal이 무엇인지 물어보면 프라이빗 호스팅 존은 프라이빗 IP를 알려줌

Hands-on#01. Route 53 setting up

1) Registered domains
2) Hosted zones - Create record A
3) cloudshell

sudo yum install -y bind-utils
nslookup domain.com
dig domain.com

4) Create EC2 Instances
- 서로 다른 리전에 세 인스턴스 생성(e.g., NRT, ICN, KIX - Tokyo, Seoul, Osaka)
- proceed without a key pair
- allow HTTP traffic from the internet

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/meta-data/placement/availability-zone)
echo “<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>” > /var/www/html/index.html

- Hello World 뒤에 인스턴스 정보를 출력할 것, 인스턴스가 시작되는 가용 영역도 포함시키는 과정에서 환경 변수 $EC2_AVAIL_ZONE을 사용
5) Create Load Balancer (DemoRoute53ALB)
- create TG
6) open addresses & LB에서 DNS name이 프로비저닝 되었는지 확인
ap-northeast-1(Tokyo): 54.199.162.15x
ap-northeast-2(Seoul): 43.201.64.18x
ap-northeast-3(Osaka): 13.208.191.12x

Route 53 - Records TTL (Time To Live)

클라이언트가 DNS Route 53와 웹 서버에 접속한다고 할 때,
myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받음 (회신 내용: A 레코드, IP 주소, TTL(300초 정도))
TTL은 클라이언트에게 이 결과를 캐시하도록 요청함 (클라이언트는 300초 동안 결과를 캐시함)
→ 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 답변을 캐시에 저장해서 답을 알기 때문에 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미
하지만 캐시에도 시간이 소요되어 캐시 TTL이 발생, DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않기 때문
저장된 답변을 이용함으로써 웹 서버에 접속이 가능하고 HTTP 요청 및 회신을 보낼 수 있음
1) High TTL - e.g., 24 hr
TTL을 24시간으로 높게 설정하면 결과가 24시간 동안 캐시되므로 Route 53의 트래픽은 현저히 적음 (클라이언트가 요청을 적게 보냄)
-> 클라이언트가 오래된 레코드를 받을 가능성이 있음 (레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻)
2) Low TTL - e.g., 60 sec.
TTL을 60초 정도로 짧게 설정한다면 DNS에는 트래픽 양의 많아져서 비용이 많이 듦 (Route 53에 들어오는 요청의 양에 따라 요금이 책정되기 때문)
오래된 레코드의 보관 시간은 짧아짐 -> 레코드 변경이 빨라짐

Hands-on#02. TTL

1) Create A record - IP region
2) record name으로 사이트 접속 혹은 cloudshell nslookup or dig
3) edit Record value
- 레코드 캐시가 만료될 때까지 확인

CNAME vs Alias

AWS 리소스(로드밸런서나 CloudFrond 등)를 사용하는 경우 호스트 이름이 노출됨, 그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수 있음
myapp.mydomain.com에 로드 밸런서를 매핑하는 경우 두 가지 옵션이 있는데,
1) CNAME 레코드로 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음 (e.g., app.mydomain.com  blabla.anything.com)
- 루트 도메인 이름이 아닌 경우에만 가능 (aka. something.mydomain.com)
2) Alias: Route 53에 한정하여, 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있음 (e.g., app.mydomain.com  blabla.amazonaws.com)
- 루트 도메인과 비루트 도메인 모두에 작동함 (aka. mydomain.com, mydomain.com을 별칭으로 사용해 AWS 리소스로 향하도록 할 수 있음)
- 무료, 자체적으로 상태 확인 가능

Route 53 - Alias Records

AWS 리소스에만 매핑이 되어 있음
예를 들어 Route 53에서 example.com을 A 레코드의 별칭 레코드로 하고 그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 해보자.

기반이 되는 ALB에서 IP가 바뀌면 별칭 레코드는 바로 인식함
CNAME과 달리 별칭 레코드는 Zone Apex라는 DNS 네임 스페이스의 상위 노드로 사용될 수 있음
AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA (리소스는 IPv4나 IPv6 중 하나)
별칭 레코드를 사용하면 TTL을 설정할 수 없음 (Route 53에 의해 자동으로 설정됨)

Route 53 - Alias Records Targets

별칭 레코드의 대상은? ELB, CloudFront 배포, API Gateway, Elastic Beanstalk environments, S3 Websites(S3 버킷은 안됨, 버킷들이 웹사이트로 활성화될 시 S3 웹사이트는 가능), VPC Interface Endpoints, Global Accelerator accelerator, Route 53 record in the same hosted zone
- EC2의 DNS 이름은 별칭 레코드의 대상이 될 수 없음

Hands-on#03. CNAME vs. Alias

1) create CNAME record
- value: ALB DNS name
2) create A record
- Alias > Route traffic to ALB
- 별칭 레코드이기 때문에 Evaluate target health는 자동으로 Yes 체크되어 있음
3) create A record without subdomain

 

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] VPC 엔드포인트 서비스를 RDS 프록시에 연결 (cross-account)  (0) 2024.12.10
[AWS] SAA-C03#12: Route 53 (2)  (0) 2024.08.07
[AWS] ANS-C01#02: VPC fundamentals  (2) 2024.07.24
[AWS] ANS-C01#01: ELB  (0) 2024.07.19
AWS products  (0) 2024.07.10
728x90
반응형

Topics

What is VPC?

AWS Service scope with respect to Region, AZ and VPC

AWS Services inside and outside of VPC

VPC Addressing (CIDR)

VPC Subnets and Route Tables (Public/Private)

IP Addresses (IPv4, IPv6, Private/Public/Elastic)

Security Groups and Network ACL

NAT gateway and NAT instance

 

Transit Gateway: 2018년 출시한 네트워킹 라우터

 

VPC의 서브넷: 개별 LAN 네트워크, VPC로부터의 작은 주소 범위

서브넷이 사용자 지정 route table을 생성하여 Main Route Table을 따르지 않으면, 두 다른 AZ의 서브넷이 Local Router를 통해 연결할 수 없음

VPC의 모든 서브넷이 같은 종류의 네트워크 연결을 원할 경우 메인 루트 테이블 수정

Amazon에서 제공하는 IPv6 DNS가 없음

Security groups are stateful

 

Network Access Control List(NACL):

1) works at Subnet level

2) Stateless(inbound/outbound 별도)

3) contains both Allow and Deny rules

4) 규칙 번호 순서대로 평가

5) default NACL allows all inbound and outbound traffic
6) NACL are a great way of blooking a specific IP at the subnet level

 

Hands-on#01

1) create VPC public

2) create Internet Gateways > Attach to VPC

3) create subnet > modify auto-assign IP settings

4) create Route Table > routes 0.0.0.0/0 IGW

VPC 내 고립된 라우트 테이블

5) create VPC private

 

VPC secondary CIDR blocks

ENI: IP 주소 제공, 네트워크 통신 가능하게 하는 VPC의 논리적 구성 요소, 가상 네트워크 카드

IP주소는 EC2 인스턴스를 실행할 때 AWS가 만드는 ENI를 이용해 할당됨

 

Bring Your Own IP

 

Hands-on#02

EC2 인스턴스 2개 - app / DB server

Domain-name = corp.internal

 

Steps

1) Create a VPC with Public & Private subnet

2) (Optional) Create DHCP Option set with domain as corp.internal and associate with your VPC

- Domain name: corp.internal / Domain name servers: AmazonProvidedDNS

- Edit VPC settings: option set - corp.internal

3) Launch one EC2 instance in Public subnet (say app) and one instance in Private subnet (say db).

- Allow SSH (source type: My IP) and ICMP IPv4 (source type: 10.0.0.0/16) in the security group

4) Create Route 53 Private hosted zone and associate with the VPC

- NS, SOA + app (10.10.0.206), db (10.10.1.173)

5) Create A records for ec2 instances pointing to their Private IPs

6) SSH into Public EC2 instance and ping to other instance using it's DNS name

- cat /etc/resolv.conf : nameserver

- ping db.corp.internal or ping db

VPC DNS with custom DNS server

Step - Setup a VPC and launch instances

- Create a VPC with public and private subnets

- Launch DNS server ec2 instance: Security group to allow UDP 53 from VPC CIDR, SSH (22)

- Launch an app server & db server ec2 instances: Security group to allow SSH (22), ICMP IPv4 All (ping)

 

----------------------------------------------
Step 4a – Configure on-premise DNS server
----------------------------------------------
1. Login to on-premise DNS server (via SSH into VPN server first)
2. Install DNS server packages

sudo su
yum update –y
# DNS를 위한 패키지 설치, util을 binding
yum install bind bind-utils –y

 

3. Create file /var/named/corp.internal.zone

$TTL 86400
@ IN  SOA     ns1.corp.internal. root.corp.internal. (
  2013042201  ;Serial
  3600        ;Refresh
  1800        ;Retry
  604800      ;Expire
  86400       ;Minimum TTL
)
; Specify our two nameservers
IN  NS    dnsA.corp.internal.
IN  NS    dnsB.corp.internal.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
dnsA IN  A   1.1.1.1
dnsB IN  A   8.8.8.8
; Define hostname -> IP pairs which you wish to resolve
@ IN  A   10.0.11.191
app IN A   10.0.11.191
db IN A   10.0.0.221

# APP 10.0.11.191
# DB 10.0.0.221

 

4. Create file /etc/named.conf [Replace X.X with your DNS server IP]

options {
  directory "/var/named";
  dump-file "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
  allow-transfer { localhost; 10.0.11.191; };
  recursion yes;
  forward first;
  forwarders {
    10.0.0.2;
  };
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside auto;
  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";
  managed-keys-directory "/var/named/dynamic";
};
zone "corp.internal" IN {
    type master;
    file "corp.internal.zone";
    allow-update { none; };
};

# DNS 10.0.11.191

 

5. Restart named service

service named restart
chkconfig named on

 

+ create DHCP Option sets

+ edit VPC DHCP option set

+ reboot App, DNS, DB server


----------------------------------------------
Step 5b – Configure on-premise DNS server
----------------------------------------------
1. Add following to /etc/named.conf. Replace ENDPOINT IPs with Route53 inbound resolver IPs.

zone "cloud.com" { 
  type forward; 
  forward only;
  forwarders { INBOUND_ENDPOINT_IP1; INBOUND_ENDPOINT_IP2; }; 
};

2. Restart named service
sudo service named restart

 

VPC DNS & DHCP exam essentials

- VPC has a default DNS server AmazonProvidedDNS

 

References

Udemy, AWS Certified Advanced Networking Specialty, Section 3

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] SAA-C03#12: Route 53 (2)  (0) 2024.08.07
[AWS] SAA-C03#11: Route 53 (1)  (0) 2024.08.07
[AWS] ANS-C01#01: ELB  (0) 2024.07.19
AWS products  (0) 2024.07.10
[AWS] SAA-C03#10: VPC lab(3)  (1) 2024.07.02
728x90
반응형

ALB는 여러 Listener를 가지며, 한 listener 당 한 가지 이상의 rule이 존재

e.g., Listener 1이 target group에 트래픽을 보내는 한 가지 규칙이 있을 때

target group은 여러 target을 갖고 있음 EC2 인스턴스나 health check 등

 

ALB는 TG에 등록된 target으로 요청을 라우팅하기 전에 사용자를 인증할 수 있음

ALB에 SSL, TLS, SSL 인증서를 로드할 수 있음

 

NLB는 두 AZ 사이에 있고, 클라이언트는 NLB에 연결되어 있음

NLB는 고정된 IP 주소가 있어서 고정 IP로 ENI에 연결됨

NLB는 AZ당 고정 IP가 하나 있어서 elastic IP를 할당할 수 있음

EC2 instance가 NLB의 다른 VPC에 있다면, 이 인스턴스를 NLB에 ID로 등록할 수 없음

 

ID로 인스턴스를 등록하거나 ECS 작업 내에서 자동으로 클라이언트의 IP는 보존되고 EC2 인스턴스는 클라이언트로부터 직접 발생하는 트래픽을 봄

NLB가 3개의 AZ로 활성화되어 있고 NLB DNS 이름에 대한 DNS 쿼리를 하면 3개의 IP를 갖게 됨, 활성화되어 있는 3개의 AZ와 부합함

NLB는 각 노드에 대해 DNS 이름을 갖고, 사용 가능한 AZ에 기반해 DNS name을 써서 IP 주소 하나만 확인할 수 있음

Connection Idle Timeout

client-ELB connection & ELB-target connection

 

NLB works without cookies

SSL - Server Name Indication (SNI): 다중 SSL 인증서를 하나의 웹 서버에 로딩하는 문제를 해결함 (다중 웹사이트와 도메인을 지원하는 서버)

 

Hands-on#01: ALB X-Forwarded Headers

1) create instance

instance user data

#!/bin/bash
# Use this for your user data (script without newlines)
# Installs httpd (Linux 2 version)
yum update -y
yum install -y httpd.x86_64
systemctl start httpd
systemctl enable httpd
echo "Hello World from $(hostname -f)" > /var/www/html/index.html

2) create ALB

- create TG

 

3) connect ssh

4) Edit the file httpd.conf, edit the LogFormat section with the following

sudo nano /etc/httpd/conf/httpd.conf

<IfModule log_config_module>

#

# The following ... a CustomLog directive (see below).

>> LogFormat "%{X-Forwarded-For}i %{X-Forwarded-Proto}i %{X-Forwarded-Port}i ...

 

5) Reload Apache

sudo systemctl reload httpd

 

6) Run the following command to watch your Apache Access Logs

sudo tail -f /var/log/httpd/access_log
172.31.x.x - - [19/Jul/2024:09:26:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
172.31.y.y - - [19/Jul/2024:09:27:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
...
- - - 172.31.x.x - - [19/Jul/2024:09:28:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
- - - 172.31.y.y - - [19/Jul/2024:09:29:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
15.248.a.a http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
15.248.b.b http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- 기존에는 X-Forwarded 헤더가 없지만, ALB DNS name으로 접속(새로고침) 시 IP, protocol, port 정보 확인

 

Hands-on#02: NLB Proxy Protocol

1) create instance (same user data)

2) create NLB

- create TG

  - choose type IP addresses

  - VPC subnet: EC2 instance private addresses

3) repeat #01 6)

# public IP
15.248.a.a - - [19/Jul/2024:10:02:22 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
# NLB DNS
172.31.x.x - - [19/Jul/2024:10:02:28 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

4) edit TG attributes

- Traffic configuration: enable Proxy protocol v2, Preserve client IP addresses

5) Verify the module mod_remoteip loaded successfully

sudo /usr/sbin/httpd -M | grep -i remoteip

You'll have the following output

> remoteip_module (shared) - 원격 IP 모듈이 응답으로 공유되었다면 모듈이 성공적으로 로드됐다는 의미

6) edit the file

sudo nano /etc/httpd/conf/httpd.conf

Add this line to enable Proxy Protocol - Listen 80 다음 줄에 삽입

>> RemoteIPProxyProtocol On

7) repeat #01 5), 6)

# NLB DNS
15.248.a.a - - [19/Jul/2024:10:12:26 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- NLB와 EC2 instance 사이에 proxy protocol이 작동한다는 것을 증명

 

References

Udemy, Pass the AWS Certified Advanced Networking Specialty Certification ANS-C01. Taught by an AWS Networking and VPC Expert!, Section 18: Elastic Load Balancers

 

728x90
728x90

'Networking > AWS' 카테고리의 다른 글

[AWS] SAA-C03#11: Route 53 (1)  (0) 2024.08.07
[AWS] ANS-C01#02: VPC fundamentals  (2) 2024.07.24
AWS products  (0) 2024.07.10
[AWS] SAA-C03#10: VPC lab(3)  (1) 2024.07.02
[AWS] SAA-C03#09: VPC lab(2)  (0) 2024.07.02

+ Recent posts