hyuckang의 블로그

엣지 로케이션과 리저널 엣지 캐시엣지 로케이션(edge locations) 또는 POP(point of presence)사용자와 가장 가까운 캐시로 사용자에게 콘텐츠를 직접 제공CloudFront Functions은 POP에서 동작리저널 엣지 캐시(regional edge caches)엣지 로케이션과 오리진 사이에 존재Lambda@Edges는 리저널 엣지에서 동작CF 동작 방식CF는 POP에 컨텐츠가 없다면 리저널 엣지 캐시에서 객체를 가져와 캐싱하고리저널 엣지에도 객체가 없다면 오리진에서 리저널 엣지로, 리저널 엣지에서 POP으로 캐싱하고 컨텐츠를 전달합니다.캐시 무효화를 하게 되면 POP과 리저널 엣지 캐시 모두에서 객체가 제거되고, 다음에 사용자가 객체를 요청할 때 오리진에서 객체를 가져오게 됩니다..

Verified Access 등장 배경대부분의 기업 고객이 AWS 내의 어플리케이션에 접근하려면 VPN과 기업에서 관리하는 장비를 사용하여야 합니다.이는 결국 여러가지 정책을 여러 팀에서 관리하게 만들고, 어플리케이션에 접근하지 못하는 문제를 여러 포인트에서 찾게끔 만듭니다.Verified Access는 Zero Trust에 기반하여 VPN 없이 웹브라우저로만 어플리케이션에 접근 할 수 있도록 해줍니다.AVA(AWS Verified Access)는 유저가 어플리케이션에 접근할 때 Trust Provider에서 가져온 정보와 정책을 비교하여 어플리케이션에 대한 액세스 권한을 부여합니다.AVA는 모든 액세스 시도를 로깅합니다.사용 예시주요 컴포넌트VA instance어플리케이션 액세스 요청을 평가하고 보안 ..

VPC Lattice 등장 배경최근 비용을 절감하고 프로그램을 빠르게 확장할수 있는 서비스 지향 아키텍처가 대중화되고 있으며,서비스 지향 아키텍처를 구현하는 가장 효과적인 방법은 다중 Account와 다중 VPC을 사용하는 것입니다.다중 Account와 다중 VPC 전략에서 Account와 VPC가 서비스 간의 경계(Boundary)라고 생각할수 있지만 인증을 고하려면서 적절한 경계를 구축하기는 어렵습니다.그렇기 때문에 일반적인 네트워크 복잡성과는 또 다른 네트워크 복잡성을 불러일으킬 수 있습니다.VPC 피어링, TGW, 프라이빗 링크, SG, NACL 등을 사용하여 현대화 된 아키텍처를 구축할 수 있지만,단일 실패지점이 되거나 IP 기반의 통제만으로는 중장기적으로 인증되고 인가된 서비스가 연결이 되어있..

alias : 자주 사용하는 명령어를 별칭으로 사용할수 있는 기능 alias 적용하기 /etc/profile : 전체사용자의 환경설정 /etc/bashrc : 전체 사용자의 BASH 환경설정 /etc/zshrc : 전체 사용자의 ZSH 환경 설정 ~/.bashrc : 개별 사용자의 Bash 환경설정 ~/.zshrc : 개별 사용자의 ZSH 환경설정 alias 등록 예시 alias ps_java='ps -ef | grep java' alias port_LISTEN='netstat -nutplea | grep LISTEN'

kubectl 구문 kubectl [COMMAND] [TYPE] [NAME] [FLAGS] COMMAND : 리소스에 수행하는 동작을 지정(create, get, describe, delete 등) TYPE : 리소스 타입을 지정(node, pod, service) NAME : 리소스 이름을 지정 FLAGS : 부가적을 설정할 옵션(--helo, --dry-run, -o yaml 등) kubectl 약어(shortname) ns -> namespace sa -> serviceaccount no -> node po -> pod rs -> replicaset deploy -> deployment sts -> statefulset ds -> daemonsets svc -> service ing -> ingre..

Provider와 Provider maintainer Terraform은 Provider라고 하는 플러그인을 통해 클라우드 제공자(AWS, GCP, …)나 기타 서비스와 상호 작용합니다. Provider는 컴퓨팅 머신, 서브넷, 스토리지와 같은 리소스를 개별 단위로 정의합니다. Provider maintainer는 클라우드 제공자나 기타 서비스의 API가 변경되면 provider를 업데이트하고 관리합니다. Terraform Registry에서 Provider들을 확인할 수 있으며 직접 작성할 수도 있습니다. Providr 버전 관리 Provider 버전을 적절히 지정하지 않으면 버전 제약 조건 내에서 최신 버전을 다운로드하며 이로 인해 예상하지 못한 인프라 변경이 발생할 수 있습니다. 여러 사용자가 동일..

dependency(의존성) 리소스나 모듈로 생성한 자원 간에는 의존성 있을 수 있으며 테라폼은 이를 확인하여 자원을 생성하거나 삭제할 순서를 정합니다. 종속성은 implicit dependency(암시적 의존성)과 explicit dependency(명시적 의존성)이 있습니다. implicit dependency(암시적 의존성) 암시적 종속성은 테라폼이 리소스간의 관계를 이해하는 일반적인 방법입니다. 예를 들어 aws_eip.ip에서 aws_instance.example_a.id를 참조하는 것이 암시적 종속성입니다. resource "aws_instance" "example_a" { ami = "ami-05fa00d4c63e32376" instance_type = "t2.micro" } resource..

Data Source data source를 사용하면 API나 다른 terraform state backend에서 데이터를 가져올 수 있습니다. 사용 예시는 AWS의 AMI ID, 다른 테라폼 구성의 output 등을 예로 들 수 있습니다. data source는 configurationd을 보다 유연하고 동적으로 만들수 있습니다. data source는 data..으로 참조할 수 있습니다. data source 블럭 aws_availability_zones는 aws에서 가용영역을 조회하는 data source입니다. data "aws_availability_zones" "available" { state = "available" filter { name = "zone-type" values = ["av..

출력 변수 출력 변수(output values)를 사용하면 리소스에 대한 데이터를 내보낼 수 있으며 child module(자식 모듈)에서 root module(루트 모듈)로 데이터를 공유할때 필요합니다. 내보낸 데이터를 사용하여 다른 인프라의 구성에 활용하거나 데이터 소스로 사용할 수 있습니다. output 선언은 모든 구성파일의 모든 위치에서 가능하지만, outputs.tf에 선언 할 것을 권장합니다. output values는 루트 모듈의 상태 파일에 저장됩니다. terraform output는 output에 query하는 명령입니다. 출력 변수 선언 Output Blocks description은 선택사항이지만 작성할 것을 권장합니다. terraform의 표현식의 결과를 value로 사용할 수도 ..

variables / 입력 변수 입력 변수(Input variable)를 사용하면 테라폼 구성 파일을 수정하지 않고 유연하게 정의할 수 있습니다. 입력 변수는 테라폼이 실행 되기 전에 할당되기에 인프라를 보다 안전하게 정의할 수 있습니다. 변수 선언은 모든 구성파일의 모든 위치에서 가능하지만, variables.tf에서 선언 할 것을 권장합니다. 변수 선언 블럭 description : 변수의 목적을 문서화하는 간단한 설명 type : 변수의 데이터 타입 default : 변수의 기본 값 모든 변수에 대해 description과 type을 지정하고, 가능한 경우 default까지 설정하는 것이 좋습니다. variable "aws_region" { description = "AWS region" type ..