AWS7 [이미지 렌더링 최적화] node기반 Lambda@Edge 생성 https://desirelsw.tistory.com/274 Lambda@Edge / CloudFront / Singed URL / S3 트러블 슈팅최근, 이미지 get서빙 부분에 보완하면 좋겠는 점이 생겨서 아래와 같이 진행해보기로 하였다. (일부분만 발췌) CF(cloudfront)에 S3를 연동하여 인증된 사용자만 CF를 통하여 이미지를 가지고 오게함desirelsw.tistory.com 이전에 해당 글에서 python 기반으로 람다를 작성할 때, WEBP 확장자 변환을 위해 Pillow 모듈을 사용하였는데, 이제는 AVIF 확장자 변환도 해야하여 더 찾아보니 pillow 모듈만으로 해결이 안되고, AVIF 변환을 위해 추가적으로 설치해야할 모듈이 있다는 것을 찾게 되었다 (확장자 추가에 따른 추가.. 2025. 1. 14. [이미지 렌더링 최적화] CloudFront 비용절감 트러블 슈팅 (설계 및 플로우) 개편 이후 기준인 위 설계도로 수정하게 되면, 아래와 같은 목적들을 달성할 수 있다.CloudFront 의 비용 최적화 (이미지 서빙 용량 개선으로 인해)이미지 렌더링 속도 최적화 (낮아진 서빙 용량 및 캐싱으로 인해)작품 커버 이미지 화질 개선 (S3에 저장할 때 리사이징 후 저장하는 방식이 아닌, 원본 그대로를 저장함으로 인해)API 서버 리소스 부하 개선 (S3에 이미지 저장하는 주체를 클라이언트로 변경함으로 인해) 해당 결과물을 이루어내기 위해, 해야하는 작업은 간략하게만 뽑아내면 아래와 같다(기존 이미지 정책 및 하이브리드 앱의 상황을 고려했을 때 해야하는 작업이 많으나, 작업의 큰 줄기만 뽑아내면 아래와 같다)[작업 우선순위]Lambda@edge 코드 작성 (이미지 변환 및 메모리 설정)신규 .. 2025. 1. 7. Lambda@Edge / CloudFront / S3 프로젝트 최종정리 (이미지 파일 관리 개선 프로젝트) 프로젝트가 모두 완료되었다. 그 내용을 추후에 참고하기 좋게 정리 차, 글을 올리게 되었다. 프로젝트를 진행하며 실제로 작업한 내용은 ★ 프로젝트 + 트러블 슈팅 ★ 에 올려두었다. 작업내용 GCP 서버 디스크에 존재하는 이미지 파일을 AWS S3로 이관 구성도 1. Cloudfront 구성을 의도하고 설계한 이유 기존 GCP 설계구조 상, 서버 Scale-Out의 어려움 기존 GCP설계구조상, 이미지를 저장하고 있는 Disk는 단일 서버에 종속적이였음. 이로 인해 추후 이용자가 증가하여 Scale-Out을 고려해야하는 상황이 왔을 때, 이를 시행하기에 까다로운 환경임 그리고, 이미지 조회 및 업로드에 서버 리소스가 온전히 사용되고 있음. 이를 다른 쪽으로 우회시키는 게 운영상 좋다고 판단이 되었음 ⇒ .. 2024. 2. 4. [이미지 보안 이슈] pre_signed_url / CloudFront / S3 트러블 슈팅 (5) Signed Url & pre-signed url 초기 구상은 하나의 s3 버킷에 대해 Cloudfront url을 통해 get과 put을 모두 수행하는 방향으로 진행하였다. 이미지 업로드 방식은 Signed Url을 통해 업로드 하였다. 이를 위해 아래 이미지와 같이 Cloudfront와 연결된 S3의 정책을 s3:getobject와 s3:putobject 모두 가능하게 설정하였는데, 위 두 정책이 한 버킷에 포함됨으로써, get을 위해 발급된 Cloudfront url을 이용하여 put도 가능해져버리는 보안 이슈가 발생하였다. 즉, 사용자가 이미지 GET을 위해 응답해준 URL을 바탕으로, 임의로 다른 이미지를 PUT해버릴 수 있는 이미지 보안 이슈가 발생하는 거였다. 그래서 버킷정책에서 s3:put.. 2024. 1. 30. Lambda@Edge / Secret Manager / CloudFront / S3 트러블 슈팅 (3) 이슈 Lambda@Edge는 환경변수를 지원하지않아, 보안상 노출하면 안되는 정보를 코드에 적는 상황이 발생하였다. 하지만 이건 보안상 좋지 않은 것으로 판단되어 다른 방법을 찾아봐야 할 것으로 판단되었다. 해결방안 아래와 같은 방법들을 찾아보았다. 1. aws secret manager를 통해 비밀값 세팅 및 읽어오기 2. s3에 비밀값을 세팅한 후, 해당 오브젝트를 읽어 비밀값 세팅 및 읽어오기 보안상 더 유리한 1번을 택하였고, 결국 AWS의 secret manager를 쓰는 방향으로 진행하였다. 허나 이때, 매 Lambda@Edge 요청마다 secret manager를 거쳐 비밀값을 가져오며 사용하는 것은 성능상 저하를 가져올 것이기에, secret manager를 통해 얻는 값을 전역 변수에 .. 2024. 1. 10. Lambda@Edge / CloudFront / Singed URL / S3 트러블 슈팅 (2) 이전에 쓴 게시글 이후로, 이미지 get서빙할 때 암호화된 path (URI상 Path, 전체URI를 말하는 것이 아님!) 를 CloudFront가 전달되면 그것이 트리거가되어 해당 path를 복호화하는 Lambda@Edge에 대한 내용을 적고자 한다. 왜 path를 암호화했나요? > s3를 퍼블릭 제한을 걸어두어 함부로 접근은 할 수 없겠으나, 사용자에게 이미지 원본의 s3 경로를 노출하는 것은 보안상 좋지않다 판단하여 이렇게 진행함 Path 복호화 Lambda@Edge 작성과정 1. 현재 유지보수중인 php 애플리케이션 내, 기존에 활용하던 AES 암호화가 있음. 하여 해당 메서드를 그대로 활용하여 Path 암호화를 진행하였음 2. 위 메서드를 통하 여 path가 암호화되어, viewer reques.. 2023. 12. 21. 이전 1 2 다음
