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 지원을 추가할 수 있다.
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]
---------------------------------------------- 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
기업 데이터 센터를 AWS와 비공개로 연결하기 위해 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 함 공용 인터넷을 통해 사설 Site-to-Site VPN 연결
Site-to-Site VPN Connection
고객 게이트웨이가 있는 기업 데이터 센터와 가상 프라이빗 게이트웨이를 갖춘 VPC가 있음 온프레미스 고객에게 게이트웨이를 어떻게 구축해야 할까?
-> 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있음
고객 게이트웨이의 공용 IP를 사용해서 VGW와 CGW를 연결하면 됨
-> 고객 게이트웨이를 비공개로 남겨 사설 IP를 갖는 경우, 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있음 NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용해야 함
+ 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동함
+ 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 함(그렇지 않으면 연결되지 않음)
AWS VPN CloudHub
VGW를 갖춘 VPC가 있고, 고객 네트워크와 데이터 센터마다 고객 게이트웨이가 마련된 상황
Hands-on#0n - Site-to-Site VPN
1) create customer gateways
- Site-to-Site VPN 연결을 구성하기 위해서는 온프레미스 호스팅이 된 고객 게이트웨이가 필요하므로
- create Site-to-Site VPN connections ...
Direct Connect (DX)
원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 뜻함 DX를 사용할 때는 전용 연결을 생성해야 하고, AWS DX 로케이션을 사용함
VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능
설치 기간이 한 달보다 길어질 때도 있음
Direct Connect Gateway
다른 리전에 있는 하나 이상의 VPC와 연결할 경우
Direct Connect - Resiliency
복원력, 아키텍처 모드
핵심 워크로드의 복원력을 높이기 위해서는 여러 DX를 설치하는 것이 좋음 기업 데이터 센터가 2개이고 DX location도 둘일 때 중복이 발생 - 프라이빗 VIF가 하나 있는데 다른 곳에 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 DX 하나가 망가져도 다른 하나가 예비로 남아있기 때문에 복원력이 강해짐
핵심 워크로드 복원력을 최대로 끌어올리고 싶다면, (Maximum Resiliency for Critical Workloads)
각 DX location에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있음
Transit Gateway
네트워크 토폴로지 복잡성 문제로 만듦
IP Multicast할 때 사용
Transit Gateway: Site-to-Site VPN ECMP
Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리는 경우
- ECMP: Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
Transit Gateway: throughput with ECMP
VPN을 Transit Gateway로 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성됨 (동일한 Transit Gateway에 모두 전이적으로 연결되기 때문)
VPC - Traffic Mirroring
사례: 콘텐츠 검사, 위협 모니터링, 네트워킹 문제 해결
IPv6 Troubleshooting
IPv4는 VPC 및 서브넷에서 비활성화될 수 없음 IPv6가 활성화된 VPC가 있을 때, 서브넷에서 EC2 인스턴스를 실행할 수 없다고 하면 인스턴스가 IPv6를 받지 못해서가 아님 (실제로 공간이 크고 EC2 인스턴스를 위한 IPv6도 충분하기 때문)
-> 진짜 원인은 서브넷이나 VPC에 이용 가능한 IPv4가 없기 때문
-> solution: 서브넷에 IPv4 CIDR를 생성하는 것 (create a new IPv4 CIDR in your subnet)
6) Route tables - Public routes > IPv6 target: local로 설정되어 있음
Egress-only Internet Gateway
송신 전용 인터넷 게이트웨이, NAT Gateway와 비슷하지만 IPv6 전용
Hands-on#0n - Egress only internet gateway
1) create egress only internet gateway (DemoEIGW)
2) private route tables edit routes - ::/0, eggress only internet gateway
-> 사설 서브넷의 EC2 인스턴스가 IPv6로 인터넷에 액세스하지만 인터넷에는 도달하지 못함
VPC Section Summary
01. CIDR: IP Range
02. VPC: virtual private cloud, IPv4와 IPv6를 위해 작동함
03. Subnets: CIDR를 정의하는 AZ에 연결됨, public/private
04. Internet Gateway: at the VPC level, public subnet은 인터넷 게이트웨이 연결시키고, 퍼블릭 서브넷에서부터 인터넷 게이트웨이로 경로 생성
05. Route Tables: 네트워크가 VPC 내에서 흐르도록 하는 키, 수정됨, 인터넷 게이트웨이 경로들, VPC Peering connections, VPC Endpoints 등 포함
06. Bastion Host: SSH에 들어갈 수 있는 public EC2 instance, 비공개 서브넷의 다른 EC2 인스턴스들과 SSH 연결
07. NAT Instances: 퍼블릭 서브넷에 배포된 EC2 인스턴스, 프라이빗 서브넷의 EC2 인스턴스에게 인터넷 접근을 제공, 오래되었고 사용이 권장되지 않고 있기 때문에 소스 / 대상 확인 플래그를 비활성화해야 함 (그렇게 해야 작동을 할 것이고 보안 그룹 규칙을 수정할 수 있음)
08. NAT Gateway: 프라이빗 EC2 인스턴스에 확장 가능한 인터넷 접근을 제공하고, 요청의 타켓이 IPv4 주소일 때 사용
09. NACL: 네트워크 ACL, 서브넷 레벨에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙, stateless 상태라 인바운드와 아웃바운드 규칙은 항상 평가되고 있음
10. Security Groups: Stateful 상태 - 인바운드가 허용되었을 경우 아웃바운드도 자동적으로 허용되고 그 반대도 마찬가지, 보안 그룹 규칙은 EC2 인스턴스 레벨에 적용됨
11. VPC Peering: 두 개의 VPC를 연결, 겹치지 않는 CIDR을 가지는 경우에 해당, VPC 피어링 연결은 비전이적 (따라서 세 개의 VPC를 연결하고자 한다면 세 개의 VPC 피어링 연결이 필요함)
12. VPC Endpoints: 프라이빗 접근을 허용 - VPC 내의 AWS 서비스라면 Amazon S3, DynamoDB, CloudFormation, SSM 등 무엇이든 가능 (Amazon S3와 DynamoDB에는 게이트웨이 엔드포인트가 있는 것도 보았고 나머지는 모두 인터페이스 엔드포인트)
13. VPC Flow Logs: VPC 내의 모든 패킷에 관련된 로그 레벨의 메타데이터를 갖는 데 가장 좋은 방법, 허용과 비허용 트래픽과 관련된 정보도 조금 있음, VPC 서브넷이나 ENA 레벨에서 생성 (Amazon S3로 전송되어 분석되고 Athena에서 분석될 수 있었으며, CloudWatchLogs로 전송되어 CloudWatchLog Insights를 통해 분석될 수도 있었음)
VPC를 데이터 센터로 연결하기 위한 두 가지 방법
14. 1) Site-to-Site VPN: 공공 인터넷을 통한 VPN 연결이기 때문에 AWS에 버추얼 비공개 게이트웨이를 생성해야 하고 데이터 센터에 고객 게이트웨이를 생성하고 그 후에 VPN 연결을 설립, 여러개의 VPN 연결을 설립할 때 같은 virtual private gateway를 사용하면 VPN CloudHub를 사용해서 hub-and-spoke VPN모델을 만들어 사이트들을 연결할 수 있기도 함
15. 2) Direct Connect: 연결이 완전히 프라이빗 상태, 공공 인터넷을 통하지 않지만 설립하는 데에 시간이 소요됨, 데이터 센터를 Direct Connect 위치로 연결해야 작동함 (더 복잡하지만 더 보안적으로 안전함, 연결도 안정적)
16. Direct Connect Gateway: 다른 AWS 리전의 많은 VPC와 Direct Connect를 만들기 위한 것
17. AWS PrivateLink / VPC Endpoint Services: 고객 VPC에 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결하기 위한 것, 좋은 점은 VPC 피어링이나 공공 인터넷이나 NAT 게이트웨이나 라우팅 테이블을 요구하지 않음, 주로 Network Load Balancer와 ENI와만 사용됨 - VPC 내의 서비스를 네트워크를 노출시키지 않고 수백, 수천개의 고객 VPC에게 노출시킬 수 있도록 함
18. ClassicLink: EC2-Classic 인스턴스를 VPC로 비공개로 연결하기 위한 것, 사용이 권장되지 않음
19. Transit Gateway: VPC, VPN, 그리고 Direct Connect를 위한 전송 피어링 연결
20. Traffic Mirroring: 네트워크 트래픽을 ENI에서 복사하여 분석을 하는 것
21. Egress-only Internet Gateway: NAT Gateway와 비슷하지만 IPv6 트래픽이 인터넷 밖으로 가는 것을 위한 것
Networking Costs in AWS per GB - Simplified
첫번째 AZ에 EC2 인스턴스가 있을 경우 EC2 인스턴스로 향하는 트래픽은 무료
같은 가용영역 내 두 EC2 인스턴스 간 트래픽은 사설 IP로 통신할 시 무료
같은 리전 내 다른 두 AZ에 있는 EC2 인스턴스 두 개가 소통하기 위해 공용 IP나 탄력적 IP를 사용하는 경우, 청구 비용은 GB당 2센트(사설 IP를 사용할 경우 반으로 절감)
(The destination CIDR block 10.0.0.0/16 is equal to or more specific than one of this VPC's CIDR blocks. This route can target only an interface or an instance.)
VPC Endpoints (AWS PrivateLink)
프라이빗 서브넷의 EC2 인스턴스를 VPC 엔드포인트를 거쳐 직접 Amazon SNS 서비스에 연결할 수 있음, 이 때 네트워크가 AWS 내에서만 이루어짐
VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 프라이빗으로 액세스하므로 AWS에 있는 모든 서비스에 액세스할 때 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용할 수 있음
Types of Endpoints
1. Interface Endpoints (powered by PrivateLink)
인터페이스 엔드포인트는 ENI를 프로비저닝하는데 ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트임
ENI가 있으면 반드시 보안 그룹을 연결해야 함, 대부분의 AWS 서비스를 지원함
2. Gateway Endpoints
게이트웨이를 프로비저닝, 게이트웨이는 라우팅 테이블의 대상이 되어야 함
IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐임
게이트웨이 엔드포인트 대상: Amazon S3, DynamoDB
Gateway or Interface Endpoint for S3?
Amazon S3에 액세스하는 방법 중 게이트웨이를 선택하는 편이 대부분 유리함 - 라우팅 테이블만 수정하면 되기 때문
인터페이스 엔드포인트가 권장되는 경우: 온프레미스에서 액세스해야 할 필요가 있을 때, 다른 VPC에 연결할 때
Hands-on#05 - VPC Endpoints
7) PrivateInstance > Security - Modify IAM role > role 생성 후 추가
10.0.0.0 - 10.255.255.255 (10.0.0.0/8) <- in big networks 172.16.0.0 - 172.31.255.255 (172.16.0.0/12) <- AWS default VPC in that range 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) <- e.g., home networks
Default VPC Walkthrough
새로운 AWS 계정은 모두 기본 VPC가 있음, 새로운 EC2 인스턴스는 서브넷을 지정하지 않으면 기본 VPC에 실행됨
VPC in AWS - IPv4
단일 AWS 리전에 여러 VPC를 둘 수 있음, 리전 당 최대 5개까지 가능(늘릴 수 있음), VPC마다 할당된 CIDR는 다섯 개 각 CIDR의 최소 크기는 /28, IP 주소는 최소 16개(2^4), 최대 크기는 /16, IP 주소는 최대 65,536개 VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용됨 VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의할 것
VPC - Subnet (IPv4)
서브넷이란: VPC 내부에 있는 IPv4 주소의 부분 범위 범위 내 AWS가 IP 주소 다섯 개를 예약함
Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are: .0: network address .1: reserved by AWS for the VPC router .2: reserved by AWS for mapping to Amazon-provided DNS .3: reserved by AWS for future use .255: network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved
EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때, /27 서브넷은 사용할 수 없음 (32 - 5 = 27 < 29)
Hands-on#01 - Adding Subnets
1) VPC 생성 2) Public/Private Subnet 생성
Internet Gateway (IGW)
인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 하는 EC2 인스턴스나 람다 함수 등 수평 확장, VPC와 별개로 생성해야 함 VPC는 인터넷 Gateway 하나에만 연결됨 VPC에 인터넷 Gateway를 만드는 정도로는 서브넷에 인터넷 액세스를 제공하지 못함, 라우팅 테이블도 수정해야 함
∴ 공용 서브넷에 공용 EC2 인스턴스 만들기 -> 라우팅 테이블을 수정 -> EC2 인스턴스를 라우터에 연결 -> 인터넷 Gateway에 연결
Hands-on#02 - Adding Internet Gateway & Editing Route Tables
1) launch instance (BastionHost) - 퍼블릭 서브넷을 위한 자동 할당 퍼블릭 IPv4 주소 활성화 시 Network settings에서 Auto-assign public IP 활성화(enable)된 상태 2) Internet gateways 생성 및 attach to VPC - VPC에 인터넷 액세스 제공 3) public/private route table 생성 - subnet associations 추가 - routes 0.0.0.0/0 target Internet GW 추가
4) Instance connect
Bastion Hosts
사용자가 프라이빗 서브넷에 없는 EC2 인스턴스에 액세스하고자 함, 이 때 배스천 호스트를 통해 프라이빗 EC2 인스턴스에 SSH로 액세스할 수 있으며 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 함
배스천 호스트를 위해서는, - 보안 그룹이 반드시 인터넷 액세스를 허용해야 함(기업의 퍼블릭 CIDR 액세스, 사용자 인터넷 액세스만 허용하는 등 EC2 보안 그룹을 제한하여 인프라 보안상 위험 방지) - 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 함(포트 22번이 배스천호스트의 프라이빗 IP가 되거나 배스천 호스트의 보안 그룹이 되는 셈)
Hands-on#03 - NAT Instance
1) launch instance (PrivateInstance) - private, network settings - Inbound Security Group Rules custom (Allow SSH from the Bastion Host)
- 프라이빗 서브넷에 위치하므로 EC2 인스턴스로 연결할 수 없음 (∵ 인터넷 게이트웨이 라우팅 테이블을 수정하면 이 서브넷이 공개되기 때문)
2) public instance 실행 후 SSH
# copy + paste
vi EC2KeyPair.pem
chmod 0400 EC2KeyPair.pem
ssh ec2-user@(private IP) -i EC2KeyPair.pem
# doesn't work
ping google.com
- private subnet의 Amazon Linux 2 AMI에 SSH 액세스 실행
NAT Instance (outddated, but still at the exam)
NAT: 네트워크 주소 변환, 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용함 NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 함
NAT 인스턴스의 작동 방식: 공용 서브넷에 NAT 인스턴스를 생성하고, 거기에 탄력적 IP를 연결, 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 함
Hands-on#03 - NAT Instance
3) launch instance (NAT Instance)
- Community AMIs - architectures: x86_64bit, vpc-nat
- Security group name: nat-instance-sg - Security group rule: add HTTP, HTTPS 4) Change source/destination check - Stop to allow your instance to send and receive traffic when the source or destination is not itself.
- NAT 인스턴스 자체가 소스 및 목적지가 아니라면 트래픽을 송수신할 수 있어야 함
5) private Route Table 인터넷 통신하기 위한 인스턴스 추가 - routes: 0.0.0.0/0 NAT Instance 6) NAT Instance 포트 추가 - All ICMP 7) PrivateInstance ping google.com - BistionHost SSH connect > ssh Private
NAT Gateway
AWS-managed NAT, 높은 대역폭, 가용성이 높고 관리할 필요가 없음
특정 AZ에서 생성되고 탄력적 IP를 이어 받음
NAT Gateway with High Availabiltiy
AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있음
Hands-on#04 - NAT Gateway
1) create NAT gateway - subnet: public subnet A - Elastic IP allocation
2) edit private routes - 기존 NAT Instance stop/terminal 시 status: Blackhole로 변경됨 - NAT Instance network interface -> NAT Gateway로 변경
Security Groups & NACLs
NACL: 요청이 EC2 인스턴스 내부로 이동하는 것
Network Access Control List (NACL)
서브넷을 오가는 트래픽을 제어하는 방화벽 서브넷마다 하나의 NACL이 있고, 새로운 서브넷에는 기본 NACL이 할당됨
1-32766번 (우선순위가 제일 높은 것은 1) newly created NACLs will deny everything
Default NACL
연결된 서브넷을 가지고 inbound/outbound의 모든 요청을 허용하는 특수성을 가짐 기본 NACL을 수정하지 않는 것을 추천 기본적으로 NACL이 서브넷과 연결된다면 모든 것이 드나들도록 허용된다는 뜻
Ephemeral Ports
클라이언트와 서버가 연결되면 포트를 사용해야 함
Create NACL rules for each target subnets CIDR
다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함, CIDR 사용 시 서브넷이 고유의 CIDR를 갖기 때문
