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.
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 주소로 전환된다.
- 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.)
% 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).
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
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 지원을 추가할 수 있다.
특정 도메인을 담당하는 적절한 네임 서버로 DNS 쿼리를 전달하는 과정에서 DNS 쿼리를 해결하는 데 필수적인 권한 있는 네임 서버의 이름을 확인하기 위해 NS(네임 서버) 레코드를 참조한다. 이 특정 도메인에 대한 권한은 다른 네임 서버에 위임할 때 도메인의 권한 있는 네임 서버(실제 DNS 레코드를 갖고 있는 서버)인지 확인하기 위해 필요하며, 해당 도메인이 신뢰할 수 있는지 확인하기 위해 각 도메인마다 DNS 레코드 관리를 담당하는 네임 서버가 존재한다.
예를 들어, 아래와 같이 'example.com'에서 레코드명 'sub.example.com'의 NS 레코드가 생성된 상태에서, 권한 있는 'sub.example.com' 도메인의 호스팅 영역을 찾기 위해 네임 서버가 아래와 같은 'sub.example.com' 호스팅 영역을 조회한다.
이 때, 하위 도메인 'sub.example.com'에 대한 네임 서버 변경이 가능한 경우 도메인의 고유한 권한을 확인할 수 없으므로, 상위 도메인 'example.com'의 'sub.example.com'에 대한 NS 레코드를 일치시켜야 한다.
