S3를 CloudFront로 제공하기

먼저 S3의 대한 기본 개념이나, CloudFront의 기본 개념을 다루지 않을 예정이다. 이점 참고 바란다.
 

1. S3를 CloudFront로 제공하는 이유

보안과 관련이 있는 public Access를 닫아둘 예정이다. 그렇다면, 사용자가 접근할 수 있는 방법 여러 가지가 있지만, 몇 가지만 보겠다. 
 
1. AWS내에서 동작하고 있는 Application을 통해서
2. AWS Cognito를 이용하여 자격 증명을 받은 경우
3. presigned URL을 통해서 임시 자격 증명을 받은 경우
 
1번의 경우 S3를 사용한다면, 보통 AWS에 서비스를 올리기 때문에 역할과 Bucket Policy를 명시하면 된다. 하지만 2, 3번은 별도로 작업이 필요하다. 이때 CloudFront를 사용하면 이러한 과정을 생략할 수 있고, 여러 가지 이점도 얻을 수 있다. 
 
이점은 다음과 같다.
 

1.  성능

정적 리소스에 대해서 캐시를 사용할 수 있다. (ex html, jpg 등등) 따라서 성능상의 이점을 얻을 수 있다. 주의점은 적절한 캐시 시간 설정이 필요하다. 수동으로 캐시를 날릴 수는 있다.

 

2. 보안 이점

CloudFront를 통해서만 들어올 수 있기 때문에 유저가 S3로 직접 접근하는 경로를 막을 수 있기 때문에 보안을 높일 수 있다.
 
물론 데이터를 수신하는 비용은 증가할 수 있다. CloudFront는 Saving Plans로 절약이 가능하므로, 성능과 보안을 가져갈 수 있다는 점에서 투자할만한 가격이다. 

 

3. 글로벌 서비스

 CloudFront는 생성한 리전에 속하진 않는다. 이때 엣지 로케이션이라는 캐싱 서버에 캐싱되며, 이 서버들은 AWS의 초고속 망으로 내부 서비스들에 트래픽을 전달한다. 따라서 리전 데이터 센터에 속하는 S3의 데이터를 전 세계에서 요청한다면, 응답이 지역별로 느릴 수 있는데, CloudFront를 사용한다면, 엣지 로케이션을 통해서 전 세계 사용자들에게 빠르게 응답할 수 있는 이점이 생긴다.

 

3. S3와 CloudFront  연동

먼저 S3를 만들자. 이름은 example-cloudfront로 하고, 별도의 설정은 건드리지 않고, public access는 차단으로 만든다. default가 public access 차단이므로 건드리지 않아도 된다. 

 

3-1. S3 만들기

 

 

완성이 됐다면 이미지 파일을 아무거나 하나 올리는데, 권한에서 public Access를 켜두고, 경로로 접근해보자. 

 

 

정상적으로 접근된다.

 

보안을 위해 Public Access 끄고 이제 접근해보겠다. 

 

 

Public Access를 차단했기에 접근이 안되는 것을 볼 수 있다. 

 

3-2. cloudfront 배포 

 

cloudfront 배포를 누른후 만든 버킷을 오리진으로 설정한다. 원본 엑세스 제어 설정을 누르고, OAI를 생성해 준다. 

 

도메인과 SSL 설정을 건너뛸 예정이므로 바로 생성해주면 된다. 그러면 아래와 같이 정책을 복사할 수 있다. 

 

 

정책을 복사하고, S3 버킷의 Bucket Policy에 넣어주면 된다. 

 

이제 cloudfront 경로 + S3 버킷의 경로로 요청해보자. 나 같은 경우는 경로가 다음과 같다. http://d3nekwiugzqwrb.cloudfront.net/example.png 

 

해당 경로로 접근하니 권한 거부가 뜨던 것이 잘된다.

 

 

4. 결론

 
가격은 조금 증가할 수 있지만, 성능과 보안적인 측면에서 CloudFront를 사용하는 것은 좋은 방안이다. 따라서 정적 리소스를 제공할 때는 S3의 객체를 제공할 때는 CloudFront를 활용하자.