AWS-apple-MAC-instance

오오오오오오!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

macOS Catalina 10.15.7 버전을 쓸수있다.

뜨든... 인스턴스 유형은 베어 메탈뿐.. 그렇다고 해서 내가 안만들순없지 가즈아!!!!!

-_-;

전용 호스트가 필요하다....근데 전용 호스트 갯수는 not support 상태다 service quotas를 늘려야한다.

일단 바로 요청 근데 금방 안되나? 아마 지금 전세계에서 생성 중일거다..증가가 되면 바로 더 진행해 보겠다.

Maximum number of running dedicated mac1 hosts.

보류에서 할당량이 요청됨으로 변경됬다.

그리고 오늘 (12월2일) 요청은 허락되지 않고 기본 제공량이 3으로 변경됬다.

일단 전용호스트를 만들고, 인스턴스를 생성했다.

한방에 인스턴스가 전용호스트를 다 차지한다.

ssh -i linuxer.pem ec2-user@IP

ssh는 동일하게 ec2-user 계정으로 접근한다.

SSM을 이용한접근도 가능하다.

먼저 vnc 로 접근하는게 목적이므로brew로 vnc server 를 셋팅해야한다.

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -allUsers -privs -all
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvnclegacy -vnclegacy yes 
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvncpw -vncpw supersecret
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate

https://gist.github.com/nateware/3915757

귀찮아서 이페이지 복붙했다. 위 명령어를 치면 vnc 가활성화 된다.

sudo dscl . -passwd /Users/ec2-user

명령어로 ec2-user의 패스워드를 설정한다.

그리고 VNC viewer 로 접속한다.

길고긴 여정을 지나 드디어.. 접속했다.

북미라 너무 느리다..-_-; VNC로 접속하기를 마무리한다.

AWS-managed-MQ-RabbitMQ-VPC-review

관리형 RabbitMQ가 나왔다.

짤방백업봇 on Twitter: "놀라울 만큼, 그 누구도 관심을 주지 않았다.… "

놀랄만큼 아무도 관심을 가지지 않았다. 안타깝....

그래서 내가 관심을 주기로 했다.

RabbitMQ VPC 설정을 확인해 보자!

생성모드는 단일과 클러스터 두가지가 있다. 단일구성부터 보자

퍼블릭엑세스는 VPC 내에 속하며 서브넷을 선택할수 있다.

프라이빗 엑세스를 선택해야 보안그룹를 선택할수 있다. 이게 가장 큰 차이점.
그리고 한번 퍼블릭으로 생성한 MQ는 영원히 퍼블릭이다. 프라이빗은 영원히 프라이빗..

그리고 이 포스팅을 시작하게 된 가장 큰 계기..

클러스터 모드에서 퍼블릭 엑세스를 사용한 RabbitMQ 는 VPC 외부에 만들어진다.

그냥 VPC 컨트롤하는 설정이 없다.

프라이빗으로 설정하면 VPC에 생성...

같은 RabbitMQ임에도 VPC 내부 / 외부 / 보안그룹 유 /무 접근제어 방식이 다른것이 인상적이었다. RDS와 같이 VPC 내부에 만들어져서 편리하게 전환할 수 있는 방식이 아니기에 생성 초기부터 명확하게 아키텍처를 구상해야 하는 것이다.

RabbitMQ의 VPC 설정은 변경이 불가능하다!!

읽어주셔서 감사합니다!

AWS-Certified-SysOps-Administrator-Associate-review

aws sysops 시험을 봤다. 내가 본 시험유형은 SOA-C01유형이다.

사실 Associate 시험이라 연습시험도 안봤고 그냥 걱정이 크게 없었다.
그런데 시험이 다가올수록 걱정이 점점 커졌다.

SA같은 경우에는 설계를 중시하는데 SOA같은 경우에는 운영과 관리자의 입장에서 바라본 AWS의 사용법을 물어보기에 중점적인 부분은 SAA보다 깊이가 깊었다. 특히 내가 어려웠던 부분은 cloudformation 이라던가 잘사용하지 않았던 chef 같은 부분이었다.

그 이외에는 사실 현재 가지고 있던 지식으로 해볼만하다 생각이 들었다.

-시험시작 후 내가 좀 공부가 부족했다는 생각을 많이했다.

SOA는 깊다. 어떤 문제는 PRO에 가까이 걸쳐있는 부분도 있다고 생각되는 문제들이 한두 문제 있었다. 실무자의 입장에서 도움되는 내용이 많았다.

기본공부는 역시

jayendrapatil 아저씨의 블로그를 시작으로 공부했다.

아저씨 최고...

AWS Certified SysOps Administrator – Associate

이 다음 시험은 Developer 다. 모두의 건승을!

AWS-EC2-Root-volume-downsize-amazonlinux2-xfs

작업의 흐름은 위 포스팅을 참고하기 바란다.

지금 포스팅은 xfs grug2 를 사용하는 사용자를 위한 포스팅이다.

amazon linux2 에 소스(xvdg)와 대상(xvdf)볼륨을 연결한다.

디렉토리를 생성하고

# mkdir /mnt/new
# mkdir /mnt/org

파티션을 생성하고

# fdisk /dev/nvme1n1

파일시스템을 생성하고

# mkfs.xfs -f /dev/nvme1n1p1

마운트한다

# mount -t ext4 /dev/xvdf1 /mnt/new
# mount -t ext4 /dev/xvdg1 /mnt/org

rsync 로 데이터를 복사해주고

# rsync -av /mnt/org/* /mnt/new

싱크가 끝나면 마운트한 경로로 이동한다.

# cd /mnt/new

그리고 blkid 를 이용하여 UUID 를 확인한다.

/dev/nvme1n1: PTUUID="9986d28e" PTTYPE="dos"
/dev/nvme1n1p1: LABEL="/" UUID="030df8fc-fb40-4ba6-af3e-662df2f52270" TYPE="xfs" PARTUUID="9986d28e-01"
/dev/nvme0n1: PTUUID="83181c97-6d5e-43c9-9ede-e2f50ead5338" PTTYPE="gpt"
/dev/nvme0n1p1: LABEL="/" UUID="55da5202-8008-43e8-8ade-2572319d9185" TYPE="xfs" PARTLABEL="Linux" PARTUUID="591e81f0-99a2-498d-93ec-c9ec776ecf42"
/dev/nvme0n1p128: PARTLABEL="BIOS Boot Partition" PARTUUID="4908ae49-9d5b-423e-a23c-a507a47bacf5"

일반적으론 UUID가 있을거지만.. 그경우엔 UUID 를 넣어주자.

# xfs_admin -U 'uuidgen' /dev/xvdf1

명령어로 UUID 생성해서 넣어줄수 있다. UUID 가 보인다면 new / org 변수에 UUID 를 export 해주자 UUID 는 사람마다 다들테니 각각 잘확인해서 복붙하자.

# export new=’3a26abfe-67eb-49e4-922a-73f6cd132402’
# export org=’781f875d-4262-4f01-ba72-d6bd123785f5’
# sed -i -e "s/$org/$new/g" etc/fstab
# sed -i -e "s/$org/$new/g" boot/grub2/grub.cfg
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

위 명령어를 치면 /mnt/new 경로에서 지정한 UUID 로 fstab 안의 UUID를 변경하고 grub.cfg 안의 UUID 또한 자동으로 치환해줄거다. 그런다음 3개의 경로를 bind mount 하고 현재위치에서 chroot . 를 치면 chroot 가 현재위치로 변경된다.

# grub2-install /dev/xvdf

chroot 가 정상적으로 먹는다면 볼륨을 변경하면 정상적으로 잘부팅된다.

테스트 해보고 꼭 작업하길 바란다.

수고하시라!

AWS-EC2-Root-volume-downsize-amazonlinux1-ext4

위에서 확장한 볼륨을 축소 할거다.

축소할 인스턴스의 OS 는 amazon linux 1 로 ext4 의 파일시스템을 가지고 있고 grub1을 사용한다. 따라서 아래 과정은 amazon linux 2 에 맞지 않는다.

볼륨 확장은 엄청 간단하다. 콘솔에서 늘리고 명령어 두줄이면 쨘!
근데..축소는? 축소는...?축소는!!!!!!! 간단하지 않다.

20G -> 5G 로 축소할거다. 가즈아!!!!!!!!!! 축소하기 위해선 먼저 준비물이 필요하다.

축소할 인스턴스의 루트 볼륨 스냅샷
위에서 만든 스냅샷으로 생성한 볼륨하나
루트볼륨을 복사할 볼륨
그리고 작업할 인스턴스. amazon linux 1

간략하게 설명하자면 현재 잘도는 인스턴스는 두고, 스냅샷으로 볼륨을 만들어서 다른 인스턴스에 연결한뒤에 거기서 축소...실은 복사 작업을 한뒤에 인스턴스 중지후 루트 볼륨 교체를 진행할거다. 그럼 볼륨을 먼저 생성하자.

볼륨은 이런식으로 xvdf(new) / xvdg(org) 로 연결한다. 작업할 인스턴스는 amazon linux 1이다.

Disk /dev/xvda: 15 GiB, 16106127360 bytes, 31457280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/xvda1 2048 31457246 31455199 15G 83 Linux

Disk /dev/xvdf: 5 GiB, 5368709120 bytes, 10485760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/xvfg: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ADC2A980-D341-46D7-9DA4-3652574FACDF
Device Start End Sectors Size Type
/dev/xvdg1 4096 41943006 41938911 20G Linux filesystem
/dev/xvdg2 2048 4095 2048 1M BIOS boot

세개의 파티션이 연결된걸 확인할수 있다.

작업전에 먼저 복사 대상 볼륨에서 파티션을 만들고 파일시스템을 생성해준다. 아래스크린샷은 이해를 돕기위해 찍은것이다.

# fdisk /dev/xvdf -> p (현재파티션확인) -> n(파티션생성) -> p(생성된 파티션확인) -> w(저장)

파티션을 만들었으면 linux dd 명령어로 복사해줘야한다.

아직 볼륨은 마운트하지 않은 상태에서 org 볼륨의 블럭사이즈를 확인해야 한다.

e2fsck -f /dev/xvdg1 명령어로 먼저 파일시스템을 체크한다.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdg1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/1310720 files (0.1% non-contiguous), 392822/5242363 blocks

[root@ip-172-31-12-119 mnt]# resize2fs -M -p /dev/xvdg1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdg1 to 461003 (4k) blocks.
Begin pass 2 (max = 103395)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 160)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 4575)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long.

The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long. 이부분에서 461003이게 현재 blockcount 다. 여기서 16MB 의 블럭사이즈를 계산해야 한다.

blockcount * 4 / (16 * 1024) 이렇게 계산해야 한다.

461003 * 4 / (16 * 1024) = 112.549560546875 로 계산되어 걍 올림해서 113이다. 이 16mb의 블록사이즈는 113개로...

dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113 명령어로 블록단위 복사를 해줄거다.

[root@ip-172-31-12-119 mnt]# dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113
113+0 records in
113+0 records out
1895825408 bytes (1.9 GB) copied, 29.3328 s, 64.6 MB/s
[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdf1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/327680 files (0.2% non-contiguous), 329605/1310464 blocks

정상적으로 복사가되면 resize2fs 와 e2fsck 가 먹는다. 그럼 이제 거의 다왔다.

마운트할 디렉토리를 생성한다.

# mkdir /mnt/new
# mkdir /mnt/org

파티션을 마운트한다.

# mount -t ext4 /dev/xvdf1 /mnt/new
# mount -t ext4 /dev/xvdg1 /mnt/org

마운트 확인한다.

df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 408K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/xvda1 15G 13G 2.3G 86% /
tmpfs 389M 0 389M 0% /run/user/1000
/dev/xvdf1 4.8G 20M 4.6G 1% /mnt/new
/dev/xvdg1 20G 1.3G 19G 7% /mnt/org

정상적으로 마운트가 됬다.

amazon linux 의 path는 uuid 가 아니라 label 기반이므로 그냥 복사한 파티션에 label 을 붙여 준다. 붙여 줄 라벨은 / 다.

# e2label /dev/xvdf1 /

라벨 지정이 완료 되었다면 blkid 를 이용해서 확인한다. 아래 화면은 이해를 돕기위한 내용이다.

# blkid
/dev/xvda1: LABEL="/" UUID="781f875d-4262-4f01-ba72-d6bd123785f5" TYPE="ext4"

그리고 grub install 을 해줘야한다.

먼저 마운트를 해줘야 한다.

#cd /mnt/new
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

제일 중요한 부분은 /proc 부분이다. mount bind 해주지 않으면 정상적으로 파티션 포지션을 불러오지 않는다.

chroot 까지 정상적으로 마쳐 지면 이제 거의 다왔다.
그냥은 안되고 몇가지를 수정해줘야 한다. 근래에 사용하는 aws 의 HOST가 변경되어서 볼륨 포지션이 좀 변경되었기 때문이다. amazon linux 1 에서는 /boot/grub/device.map의 수정이 필요하다. 하이퍼 바이저가 디바이스를 호출하는 이름이 변경된것이므로 수정하지 않으면 grub-install 이 불가능하다.

전) device.map 이 없을수도 있다. 없으면 걍 만들어 줘도 괜찮다.

#cat /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdf
(hd2) /dev/sdg

후)

#vi /boot/grub/device.map
(hd0) /dev/xdva
(hd1) /dev/xvdf
(hd2) /dev/xvfg
:wq!

변경을 완료하였다면 이제 grub-install 이 가능한 상태가 되었다.

# grub-install /dev/xvdf
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/xvda
(hd1) /dev/xvdf
(hd2) /dev/xvdg

이제 복구를 위해만든 인스턴스를 종료한다.

볼륨을 분리하면 정상적으로 분리가 된다. 이제 교체할 20G 볼륨인 인스턴스를 중지하고

원본 볼륨을 분리한다.

/dev/xvda 로 볼륨을 연결한다. 정상적으로 연결이 끝나면 인스턴스를 시작한다.

드디어 인스턴스가 떳다. 그럼 파티션을 확인해보자

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 4.9G 1.3G 3.6G 27% /

정상적으로 파티션이 보이면 축소가 완료된것이다.

OS마다 방법이 다르지만 centos6 amazonlinux1 / centos7 amazonlinux2 이렇게 동일할것이다. 참고하자.

읽어주셔서 감사하다!

좋은하루 되시라!

AWS-EC2-Root-Volume-Resize-Extending-linux

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

리눅스 볼륨 확장은 이 docs 를 참고하자. 먼저 오늘 테스트할 ami 는 amazon linux 1 이다.

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 1.2G 6.6G 15% /

root 볼륨은 8G 로 1.2G를 사용중이다. 이걸 20G로 늘릴거다.

먼저 볼륨 태그를 잘확인한다.

amazon linux 1 은 ext4 에 /dev/xvda1 로 / 가 설정되고
amazon linux 2 는 xfs 에 /dev/nvme1n1p1 으로 / 가 설정 된다

확장 자체는 디바이스의 파티션을 지정해서 확장하므로 일반적으로 볼륨 하나당 하나의 파티션을 사용하는것을 권장한다. on-prem 처럼 하나의 볼륨에 여러개의 파티션을 사용한다면 확장은 힘들다.

볼륨수정을 눌러서 진행한다.

볼륨을 수정하면 optimizing 과정을 거쳐서 확장된다. 디스크를 사용중에도 확장할수 있으나, 안전한 작업을 위한다면 스냅샷을 생성하고 확장하자.

Disk /dev/xvda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/xvda1 1 16777215 8388607+ ee GPT

/dev/xvda: 21.5 GB 볼륨이 확장된게 보인다.

현재 상태는 볼륨만 확장된것이고 파티션을 확장해야 한다.

# growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=41938910,end=41943006

amazon linux 1 의 경우엔 파티션이 xvda 로 보여서 xvda 의 첫번째 파티션은 1번을 확장한다.

amazon linux 2 의 경우엔 파티션이 nvme1n1p1 으로 보이므로 실제 명령어는

# growpart /dev/nvme1n1 1

로 명령어를 쳐야 한다. growpart 로 파티션을 확장하면 Disk label type: dos -> Disk label type: gpt 변경되고,

위처럼 디스크 라벨 부터 파티션 타입까지 변경된다.

fdisk -l 명령어로 확인하며 진행하자.

이제 다음은 파일시스템의 확장이 필요하다. 파일시스템 확장은 resize2fs 명령어로 확장한다.

# resize2fs /dev/xvda1
resize2fs 1.43.5 (04-Aug-2017)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242363 (4k) blocks long.

그럼 볼륨 확장이 완료된다.

볼륨확장에 대해 정리하자면 이렇다.

실제 볼륨을 확장하고 파티션을 확장하고 파일시스템을 확장한다.

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 20G 1.3G 19G 7% /

정상적으로 확장된 파티션을 확인할수 있다.

xfs 에서 파티션 확장은 xfs_growfs 명령어를 사용한다. 참고하자.

AWS-instance-Attach to Auto Scaling Group

나는 몹쓸 고정관념이 있었다.

auto scaling group 에서 인스턴스를 분리 하게되면 재연결할수 없다고 생각했다.

아니었다..그저 연결하는 메뉴가 Auto Scaling Group에 존재하지 않았을 뿐이다.

하..멍청멍청.

ASG에서 인스턴스를 분리한다.

하나의 인스턴스만 남는다. 내 ASG는

이렇게 설정되어있고 축소정책이 없는 상태라 분리하여도 문제가 없다.

정상적으로 분리된게 확인되면 인스턴스 탭으로 이동하자.

분리된인스턴스에서 인스턴스셋팅을 보면 Attach 메뉴가 있다.

이런식으로 ASG에 인스턴스를 넣어줄수 있다.

정상적으로 추가된것까지 확인된다.

-_-;보안그룹 넣는거부터.. ASG까지..또 내가 모르는게 많았다..

ASG 액션에서 연결버튼 하나만 만들어줘도... 이런고민 안했을껀데..

음 또 나만 몰랐던 AWS의 기능... 다신 잊지 않기 위해서 포스팅한다.

AWS-Advanced-Networking-Specialty

AWS Certified Advanced Networking – Specialty

오늘 5월 17일 ANS를 합격했다.

5월6일에 SCS를 보고난 후 개인적인 도전과...
스스로에 대한 점검의 의미로 ANS를 바로 도전하기로 생각했다.

GCP-PCA-PCNE를 이어서 보면서 AWS 의 Networking 자격증 또한 취득하고 싶었다.

그래서 5월6일 SCS를 합격하자 마자 그날부터 ANS를 공부했다.

먼저 jayendrapatil님의 블로그를 이전부터 봐왔기에 ANS 가이드와 정리가 있다는것을 아고 있었다. 그래서 먼저 정독했다.

그리고 나름의 계획을 세워서 Docs 정독과 BGP - Direct Connect 를 주로 공부했다.
그외의 과목들은 SAP와 실무에서 자주하던 내용이라 깊게 고민하진 않았다.

계획대로 잘되나 했는데..연습시험이 없었다......왜??????????????
ANS만 연습시험이 없다...하...깜짝놀랐다.

Security Group 나 NACL Routing table 같은거나 VPC 디자인 같은 내용들은 SAP / SCS공부를 하면서도 반복한 내용인지라 따로 추가적인 공부를 하지 않았다.

가지고 있는 기본지식으로 문제를 풀수있을거라 생각했으므로..

DX의 사용방법이나 trensit VPC / DX HA / cloud hub 구성에 대해서 많이 찾아봤다.

Redunant Direct Connect 아키텍처

이런 이미지 들로 주로 DX를 이해하려 했다. 그리고

https://dev.classmethod.jp/?s=Direct+Connect

일본의 AWS 파트너사인 Classmethod의 블로그를 참고했다.

간밤에는 오픈카톡에서 김용대님 신승광님 서노아님 등 여러분들이 참전하셔서 길을 찾아주셨다.

https://open.kakao.com/o/gMCqYXxb

여러분들과 운영해 나가는 자격증 오픈챗팅방이다.

그렇게 다양한 자료들을 흡수하며 DX를 이해하고 구성을 그렸다.

사실 잘 이해안가는건 BGP도 아닌 DX의 큰그림이 었기 때문이다.

DNS / VPC / DHCP option set 같은건 익숙했다.

그렇게 5일가량은 DX를 공부했다. 제일 도움이 됬던건

https://d1.awsstatic.com/whitepapers/aws-amazon-vpc-connectivity-options.pdf

Amazon Virtual Private Cloud Connectivity Options - white paper 정말 도움이 많이되었다.

그렇게 많은것들을 보고나서 오늘 종로 솔데스크에서 시험을 봤다.

시험을 완료하자마자 성적표가 날아왔다.

총점:  80%
주제별 등급점수:
1.0  Design and implement hybrid IT network architectures at scale: 83%
2.0  Design and implement AWS networks: 85%
3.0  Automate AWS tasks: 100%
4.0  Configure network integration with application services: 71%
5.0  Design and implement for security and compliance: 83%
6.0  Manage, optimize, and troubleshoot the network: 57%

다음과 같이 성적표까지 바로 발송되었다. 아슬아슬 했다고 생각한다.

여담으로 AWS의 시험시스템이 변경되었다고 이전에 언급했는데 당일에 점수와 결과가 발송된다.

그동안 너무 느린처리에 좀 불안하기도 하고 답답했는데 빨라져서 너무 다행이다.

일정대로 목표한 공부를 마쳤다.

시간이 난다면 sysops를 볼거 같다.

다음시험은 AZ-301을 취득하려 한다.

읽어주셔서 감사하다.

ANS 후기를 마친다.

AWS-VPC-rfc1918

요즘 ANS 공부를 하고 있다. 그러던 와중에 알게된 부분이다.

AWS에선 VPC 를 생성할때 RFC1918을 권장한다.

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

이 대역이다. 그러던중 IPv4 블록 연결제한 부분을 보게되었다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing

IPv4 CIDR 블록 연결 제한
기본 VPC CIDR 블록이 상주하는 IP 주소 범위제한되는 CIDR 블록 연결허용되는 CIDR 블록 연결
10.0.0.0/8다른 RFC 1918* 범위(172.16.0.0/12 및 192.168.0.0/16)의 CIDR 블록입니다.기본 CIDR이 10.0.0.0/15 범위에 해당되면 10.0.0.0/16 범위의 CIDR 블록을 추가할 수 없습니다.198.19.0.0/16 범위의 CIDR 블록입니다.제한되지 않는 10.0.0.0/8 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
172.16.0.0/12다른 RFC 1918* 범위(10.0.0.0/8 및 192.168.0.0/16)의 CIDR 블록입니다.172.31.0.0/16 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.제한되지 않는 172.16.0.0/12 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
192.168.0.0/16다른 RFC 1918* 범위(172.16.0.0/12 및 10.0.0.0/8)의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.192.168.0.0/16 범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
198.19.0.0/16RFC 1918* 범위의 CIDR 블록입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.
공개적으로 라우팅이 가능한 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.RFC 1918* 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다.공개적으로 라우팅이 가능한 모든 다른 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록.

간단히 정리하면 해당 RFC1918중 하나의 대역을 사용하면 다른 대역을 사용할수 없는것이다.

예로..

이런식이다..

왜이렇게 AWS에서는 RFC1918에 대한 제한을 두었는지는 알수없다.

non-RFC1918 은또 사용할수 있기 때문이다.

추측을 하자면 어제 조언을해주신..여러분들의 의견을 종합해보자면..

관리상의 측면때문일거라 생각은 드는데..

결론은 나지 않았다.

간단하게 정리한 스샷..

긴밤에 같이 고민해 주신 김용대님 신승광님 서노아님께 감사를 드립니다!

읽어주셔서 감사하다!