リスクを最低限に絞ってAWSのS3のファイルを別バケットへ移行する

リスクを最低限に絞ってAWSのS3のファイルを別バケットへ移行する

やなさん

やなさん

まいど。バックエンドエンジニアのやなさんです。

さて、先日、仕事であるプロジェクトの改修作業の一貫として、S3の本番環境にアップロードされているファイルを開発環境へコピーが必要となりました。

S3にアップされているファイルが少なければ、S3のコンソール画面からコピーして貼り付ければ良いのですが、マニュアルを見る限り5GBが制限だそうです。

しかし、今回対象の本番環境のファイルは5GBを超えていました。そのため、コンソール画面からではなく、コマンドライン上てファイルコピーが必要でした。

これがもし開発環境であれば、何の気兼ねもなく、

aws s3 sync コピー元バケット名 コピー先バケット名

を「えいやー」って実行するのですが、本番環境となるとそうもいきません。

本番環境に対して何かを操作するとき、本当に実行する操作やコマンドに問題・影響がないかを十二分に確認してオペレーションする必要があります。

十分に確認した上で実行しても、たまに間違いを起こしてしまうのが人間です。そういった人為的なミスをできる限りなくすべく、操作時に不要な操作が出来ないように設定する手順を、自分自身の整理のためにもまとめていきます。

まず、ポリシーとは

抜粋していますが、AWSのポリシーとアクセス許可のマニュアルには以下のような記載があります。

ポリシーとアクセス許可の抜粋
”ポリシー は AWS のオブジェクトであり、エンティティやリソースに関連付けて、これらのアクセス許可を定義します。”
”AWS でアクセスをコントロールするには、ポリシーを作成して IAM アイデンティティや AWS リソースにアタッチします。”
“ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。”

平たく説明すると、ポリシーとは、AWSを各種操作を実行する権限可否を定義したものになります。
必要な操作許可だけを与えたポリシーをユーザーに設定して操作を行えば、仮に間違えた操作を行ったとしても、操作権限により、実行出来ない状態を作ることが可能です。

バケットの準備

今回はS3のコピーを試すので、本番用バケットと開発用バケットを準備します。
ここではyana.migration-test.before(本番環境想定)とyana.migration-test.after(開発環境想定)を作成します。

ポリシーの作成

まず、以下手順に沿って、ポリシーを作成します。
①メニュー画面でIAMをクリックします。

 
②左サイドメニューのポリシーをクリックし、ポリシーの作成をクリックします。

ポリシーの作成画面で必要な機能を入力します。

 
すべて展開をクリックし、サービスにS3を選択します。

 
アクセスレベルに必要な権限を設定します。
ここではアクセスレベルに以下のものを設定します。

  • リスト : ListBucket
  • 読み込み : GetObject
  • 書き込み : PutObject


 
⑤リソースのbucketからARNの追加をクリックし、移行先バケット名(今回はyana.migration-test.after)を入力しします。

 
⑥リソースのObjectからARNの追加をクリックし、Bucket nameに移行先バケット名、Object nameに「*(アスタリスク)」を入力しします。

 
⑦移行元のバケット(今回はyana.migration-test.before)として同様に権限設定を入力します。

※注意
移行元と移行先のバケットの違いは移行元バケットには書き込み権限(PutObject)を与えないように設定してください。
移行元の権限設定が完了すれば、ポリシーの確認をクリック
 
⑧名前・説明に任意の内容を入力しポリシーの作成をクリック。

これで、ポリシーの作成が完了です。

ユーザーの作成

次にユーザーを作成します。
 
①左サイドメニューのユーザーをクリックし、ユーザーの追加をクリックします。

 
②任意のユーザー名を入力し、「アクセスの種類」にプログラムによるアクセスをチェックし、次のステップ:アクセス権限をクリック

 
③作成したポリシーをチェックし、次のステップ:タグをクリック

 
④何も考えずに、次のステップ:確認をクリック

 
⑤内容を確認し、ユーザーの作成をクリック

 
⑥成功のメッセージと共に、作成したユーザーのアクセスキーシークレットキーが発行されるので、メモしておきます。

これでユーザーの作成が完了です。

aws cliのインストール

aws sync

コマンドを実行するためにはaws cliがインストールされている必要がある為、
aws cli をインストールする前にpythonがインストールされているか確認します。

$ python --version
Python 2.7.10

Pythonのバージョンが表示されない場合はインストールしましょう。
※Macはデフォルトインストールされているので問題ないはずです。
 
aws cliをインストールします。

$ brew install awscli

 
aws cliのバージョンを確認し、インストールされている事を確認します。

$ aws --version
aws-cli/1.16.290 Python/3.7.5 Darwin/18.7.0 botocore/1.13.26

aws configureを設定する

aws cliで対象のアカウントに接続するために、先程作成したユーザーのアクセスキーとシークレットキーを設定します。

$ aws configure
AWS Access Key ID [****************E4GW]: AKIASWGMUGXSR2S35FSX (アクセスキー)
AWS Secret Access Key [****************p+/c]: シークレットキーを入力
Default region name [None]: 未入力
Default output format [ 未入力

region nameとoutput formatは未入力(ブランク)のままで問題ありません。

ファイルをコピーする

まず、移行元と移行先のバケット名の中身を確認します。
こちらが移行前バケットの中身。ファイルがあることを確認します。

 
次に移行先バケットの中身を確認します(今回は空であることを確認)。

 
syncコマンドを実行する

$ aws s3 sync s3://yana.migration-test.before s3://yana.migration-test.after

 
上記を実行すると、コンソール画面上に以下のようなログが出力されます。

copy: s3://yana.migration-test.before/test001/test001-01/test2.txt to s3://yana.migration-test.after/test001/test001-01/test2.txt
copy: s3://yana.migration-test.before/test1.txt to s3://yana.migration-test.after/test1.txt
...

 
上記のようなコピーコマンドが実行されることを確認した上で、移行先バケットを確認すると、

しっかりコピーされました。

ファイルがコピーできないことを確認

では権限の設定が正しくされていることを確認するため、移行先バケットを移行元バケットにsyncするコマンドを実行してみます。

$ aws s3 sync s3://yana.migration-test.after s3://yana.migration-test.before

 
そうすると、

copy failed: s3://yana.migration-test.after/test001/test001-01/test1.txt to s3://yana.migration-test.before/test001/test001-01/test1.txt An error occurred (AccessDenied) when calling the CopyObject operation: Access Denied
copy failed: s3://yana.migration-test.after/test1.txt to s3://yana.migration-test.before/test1.txt An error occurred (AccessDenied) when calling the CopyObject operation: Access Denied

と出力されます。
 
エラーメッセージは

 
An error occurred (AccessDenied) when calling the CopyObject operation: Access Denied
(訳:CopyObject操作を呼び出すときにエラーが発生しました(AccessDenied):アクセスが拒否されました)

と、s3://yana.migration-test.beforeへコピーは出来ないことが正しく確認できました。

こういった権限を設定しておくことで、オペレーションやコマンドを仮に間違えたとしても権限の制御によって致命的な操作ミスを防ぐことが可能です。

まとめ

たまに、非エンジニアの人からは簡単に「ファイルコピーするだけでしょ」と言われることがあります。ファイルコピーとはいっても、油断は禁物です。本番環境に対して操作を行う場合、(とくに途中から参画したプロジェクトの場合)本番環境に影響が発生しないように環境周辺の影響調査や、リスクを最低限に抑えるためにさまざまな調査と準備をします。

たかがファイルコピー、されどファイルコピー。

なんの間違いもなければこんな手間を掛けた手順を取る必要はないとは思います。しかし、操作するときにはリスクを最大限に小さくした上で実行するなど、お客さんの大事なデータを取り扱う立場として見えない努力をしていることをまた、非エンジニアの人にも知ってもらえればと思っています。

それではまた。やなさんでした。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る

この記事のシェア数

やなさん
やなさん テクニカルディレクター / 柳澤 宏樹

バックエンドエンジニアのやなさんです。大阪出身です。 36歳にして大阪を離れ、満を持しての東京進出です。 大阪ではシステム開発会社でプログラミングや設計や管理業務など、いろんなことしてました! 明日も笑って過ごせるように今日も1日がんばります。 あと、笑い声の制御が出来ず、ボリューム大きめです。

このメンバーの記事をもっと読む
デザイン力×グローバルな開発体制でDXをトータル支援
お問い合わせ 会社概要DL