s3

AWS-FinOps-S3-incomplete-multipart-uploads-MPU

S3는 청크 단위로 파일을 잘라서 업로드 할수있는 기능을 제공한다.

이 기능의 정식명칭은 multipart upload 이다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html

MPU라고 줄여서 부른다.

MPU는 업로드 속도를 빠르게 해줄수있는 아주 좋은 기능이지만, 업로드에 실패할 경우 완성되지 않은 청크단위의 파일들이 S3스토리지에 저장되게 된다. 업로드가 정상적으로 이루어진 경우 청크단위로 나뉜 파일을 하나의 파일로 합쳐서 객체로 보이게 되지만, 그렇지 않은 파일은 우리의 눈에 보이지 않지만 S3의 스토리지에 비용만 발생시키며, 하등 쓸모없는 상태로 저장만 되어있는다. 이런 경우를 "incomplete multipart uploads" 라 부른다.

불완전 멀티파트 업로드/완료되지 않은 멀티파트 업로드 는 Lifecycle 를 통해 삭제 할수있다. 간단한 정책을 만들어서 보여주고자 한다.

설정은 S3 버킷 에서 관리로 가면 수명주기 규칙으로 설정할수 있다.

이설정은 모든 버킷에서 통용적으로 사용할수 있는 규칙이므로 버킷을 생성할때 무조건 넣어도 좋다.

위와같이 "만료된 객체 삭제 마커 또는 완료되지 않은 멀티파트 업로드 삭제" 체크후 "불완전 멀티파트 업로드 삭제" 를 체크하면 된다. 일수는 1일이 최소값이다.

정상적으로 삭제가 동작하면 이런식으로 S3 dashboard에서 불완전한 멀티파트업로드 바이트 차트가 0B로 변경되는것을 확인할수 있다.

불완전 MPU는 대표적으로 이런경우 생성된다.

MPU 업로드 실패.
Athena 쿼리 실패
Redshift UNLOAD 실패등

AWS 서비스에서 S3로 저장하는 액션을 취하다 실패하는경우가 있다면 대부분 "불완전 MPU"가 생성될것이다.

AWS S3 대시보드를 확인하여 "불완전한 MPU" 를 확인하고 삭제해보자.

바닥에 흘리고 다니던 눈먼 동전 줍기가 될것이다.

읽어주셔서 감사하다!
앞으로도 FinOps 시리즈로 찾아 뵙겠다.

AWS-S3-directory-size

aws s3 ls s3://linuxer-wp/wp-content/uploads/2019/08/ --human-readable --summarize

aws s3 명령어만으로 조합.

aws s3 ls s3://linuxer-wp/ --recursive --recursive | grep 2020 | awk 'BEGIN {total=0}{total+=$3}END{print total/1024/1024" MB"}'

aws s3 ls + grep + awk total+=$3더한것.

AWS-S3-api-encrypt

aws bucket ls | xargs -L1 % aws s3api put-bucket-encryption \
--bucket % \
--server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

s3 api 이용한 모든버킷 AES-256 암호화.

aws-s3-delete-mfa-enable

오늘은 s3 delete 를 mfa 로 제한하는 방법에 대해서 포스팅 해보겠다.

aws 에서 s3 버킷에 대한 삭제 제한을 해야 할때가 있다.

이경우에 root access key를 생성하여야 한다.

iam 대시보드에서 mfa 와 루트 엑세스키를 생성할수 있다.

보안자격증명 관리로 이동해서 진행한다. 과정은 간단하고 쉬우니 URL을 참고하자.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa.html - MFA 활성화

https://docs.aws.amazon.com/ko_kr/general/latest/gr/managing-aws-access-keys.html -access key 생성

생성한 키로 aws cli 를 사용가능하도록 설정한다

/root/.aws/credentials 다음 위치다.

access key를 넣고 mfa 를 확인해보자

root@ip-10-0-0-12 ~]# aws iam list-virtual-mfa-devices
An error occurred (AccessDenied) when calling the ListVirtualMFADevices operation: User: arn:aws:sts:: usernumber :assumed-role/AmazonEC2RoleForSSM/i-052ebb4fb1eade551 is not authorized to perform: iam:ListVirtualMFADevices on resource: arn:aws:iam:: usernumber :mfa/

루트권한이 아닐경우 위와같은 에러가 난다 administrator 계정일경우 ListVirtualMFADevices 정책이 부여되어있어 에러가 발생하지 않을것이다. 하지만 mfa는 사용할수 없을것이라 root key여야 한다.

명령어가 정상적으로 작동하면 아래와 같이 반환된다.

{
"VirtualMFADevices": [
{
"SerialNumber": "arn:aws:iam:: usernumber :mfa/root-account-mfa-device",
"EnableDate": "2019-10-28T01:06:07Z",
"User": {
"PasswordLastUsed": "2020-03-18T00:27:36Z",
"CreateDate": "2019-07-29T13:23:03Z",
"UserId": "1",
"Arn": "arn:aws:iam:: usernumber :root"
}
}
]
}

나는 root 계정에만 mfa 를 활성화 하였기에 루트 계정에서 사용하는 mfa 만 뜬것이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning --bucket linuxer-data --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam::usernumber:mfa/root-account-mfa-device <016432>"
An error occurred (InvalidRequest) when calling the PutBucketVersioning operation: DevPay and Mfa are mutually exclusive authorization methods.

linuxer-data 라는 버킷을 versioning 을 켜고 MFADelete 를 활성화 한다는 명령어인데 에러가 발생한것이다. 이때 root 계정이 아니라서 발생한 에러이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning --bucket linuxer-data --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam:: usernumber:mfa/root-account-mfa-device 926220"

정상적으로 root access key일 경우에는 그냥 명령어가 떨어진다.

root@ip-10-0-0-12 ~]# aws s3api get-bucket-versioning --bucket linuxer-data
{
"Status": "Enabled",
"MFADelete": "Enabled"
}

이후에 다음과 같이 aws s3api get-bucket-versioning --bucket linuxer-data 명령어로 정상적으로 설정이 됬는지 확인이 가능하다.

wordpress s3 cloudfront 적용하기

줄곳 고민하던 s3-uploads / cdn-cloudfront 를 적용하였다.

먼저 wordpress 의 여러 플러그인중에 대중적이며 복잡하지 않은 방식을 채택하였다.

사용한 플러그인은 두가지이다.

Amazon Web Services / WP Offload Media 

두개의 플러그인을 설치한다.

그리고 AmazonS3FullAccess 권한을 가진 사용자를 Programmatic access 방식으로 생성한다.

그리고 버킷을 생성한다. AmazonS3FullAccess full acces 권한을 줬는데 이 권한은 업로드 권한만 줘도 무방하다. 하지만 편한 테스트를위해 전체 권한을 부여하였다.

일단 모든 퍼블릭 엑세스 차단을 해제한다. 나머지는 모두 기본설정이다.
위 설정은 편한 설정을 위한 선택이므로 각자 개인의 선택을 요한다.

미리 wp-content/uploads 폴더까지 생성한다. 그리고 cloudfront 를 생성한다.

Restrict Bucket Access -yes
Origin Access Identity - Create a New Identity
Grant Read Permissions on Bucket - Yes, Update Bucket Policy
위 순서대로 선택하면 s3 버킷 정책이 자동으로 삽입된다.

{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E2BE1SUSFLL"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::linuxer-wp1/*"
}
]
}

그리고 cloudfront는 https 로만 통신하기 떄문에 route53에 도메인을 생성하여 붙여주는게 좋다. 도메인을 붙일떈 acm 을 생성하여야 한다. acm은 버지니아 북부에서 생성한 acm만 사용할수 있다.


acm은 route53을 사용하면 버튼 클릭 한번으로 생성 가능하다. 하나의 acm에는 50개의 도메인을 추가할수 있다. 간단하게 linuxer.name *.linuxer.name 을 추가하였다. 여기에 linuxer.com 이나 linuxer.kr namelinuxer.net 등 여러가지의 도메인을 한꺼번에 추가하여 사용할수 있다.

이후 cloudfront 를 생성한다. 이후에 wordpress 플러그인 설정화면으로 진입한다.

엑세스키와 시크릿키를 입력하고 save를 하면 디비에 저장이 된다.
디비에 저장하고 싶지 않을경우에 wp-config.php 파일에 추가를 한다.

그리고 플러그인 Offload Media Lite 으로 진입하여 cname 설정을 진행한다.

OFF 되어있는 버튼을 누르고 설정된 cloudfront 에 설정한 cname 을 입력한다.
이 설정을 마칠쯤이면 cloudfront 가 Deployed 상태로 변경될것이다.

그러면 이제 테스트 게시물을 작성하여 보자.

업로드가 정상적으로 이루어 지게 되면 이미지가 정상적으로 보이게되고 주소복사를 눌렀을떄 해당 페이지가 cdn 페이지로 열리면 정상적으로 upload-s3-cdn 이 구조로 생성이 된것이다.

그리고 s3 로 uploads 디렉토리를 이동하는것은 선택이다.

하지만 그부분도 진행하였다.

#aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:ap-northeast-2

aws configure 명령어를 이용하여 이전에 만든 엑세스 키를 입력하고 리전을 지정한다. 그리고 aws s3 명령어를 이용하여 sync 한다.

#aws s3 sync wp-content/uploads/ s3://linuxer-wp/설정한 경로

이전에 업로드된 파일때문에 위와같은 작업을 진행하는것이므로 새로생성하는 wordpress 의 경우엔 하지않아도 괜찮다.

이후로 업로드되는 파일은 s3로 업로드되고 view 는 cloudfront 에서 진행될 것이다.

오늘의 포스트 주제를 주신 전산직 님께 감사드린다!

좋은하루 되시라!