Windows Server 2016 で拡張ネットワーキングをONにする【AWS】

AWS上のWindows Server 2016で拡張ネットワーキングをONにして見たいと思います。

そもそも拡張ネットワーキングとは？

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Linux の拡張ネットワーキング - Amazon Elastic Compute Cloud

ということです。
つまり有効にするだけで通信が早くなるというすぐれものです。

拡張ネットワーキングを有効にする手順

環境

• Windows Server 2016 Base
• m4.large

Intelネットワークドライバをインストールする

以下のURLからIntelネットワークアダプタドライバーをダウンロードします。

downloadcenter.intel.com

「ProWinx64.exe」というファイルがダウンロードされたかと思います。
それを「ProWinx64.zip」に拡張子を変更します。

「ProWinx64.zip」を展開します。

コマンドプロンプトを開き、「ProWinx64.zip」を展開したフォルダに移動して以下のコマンドを実行してINFファイルを追加/インストールします。

pnputil -i -a PROXGB\Winx64\NDIS65\vxn65x64.inf 

Windows Server をシャットダウンします。

拡張ネットワーキングを有効にする

ローカルのPCなどの別の環境でいかのコマンドを実行して拡張ネットワーキングを有効にします。
Trueと応答されればOKです。

AWSCLIの場合

aws ec2 modify-instance-attribute --instance-id  i-xxxxxxxxxxxxxxxx --sriov-net-support simple

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxx -SriovNetSupport "simple"

拡張ネットワーキングが有効か確認する

デバイスマネージャーを開き、「ネットワークアダプター」の下に「Intel(R) 82599 Virtual Function」があることを確認します。

インスタンスに拡張ネットワーキングの属性が設定されている確認します。
"Value": "simple"となっていればOKです。

AWSCLIの場合

 aws ec2 describe-instance-attribute --instance-id i-xxxxxxxxxxxxxxxx --attribute sriovNetSupport --query 'SriovNetSupport'

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxxx -SriovNetSupport "simple"

上記2つがOKであれば拡張ネットワーキングは有効化されています。

まとめ

有効にするだけで通信がはやくなるのでどんどん設定していきましょう！

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWSのキー管理を比較してみた【KMS/CloudHSM】

AWSで利用できるキー管理のそれぞれの利点についてまとめてみました。

KMS

キーの保存場所/制御方法

• AWSにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 定義ポリシーをAWSが実行してキーの仕様を制御する
• AWSが責任をもって実行する

料金

• キー単位と使用量単位で料金がかかる

CloudHSM

キーの保存場所/制御方法

• AWS内で実行されるHSMにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 自作のコードまたはSafenet APIでキーを管理することができる
• 自分たちで責任を持って管理する

料金

• 1時間あたりの課金
• CloudHSM Classicを利用する場合は前払い料金が発生する

3rdparty製ツール(AWS MarketPlace)

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• 1時間あたりの課金または1年単位での支払い

自作ツールでの管理

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• ツール(ベンダー)による(場合によっては安くすむかも)

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

VGWのパス決定の優先順位まとめ

VGWの外のトラフィックのパスに複数のオプションがある場合は、以下のようにパスが特定されます。

パス決定の優先順位

1→2→3→4の順にパスが特定されます。

1. 範囲の狭いIPアドレスプレフィックス
   172.24.0.0/16より172.24.1.0/24より172.24.1.1が優先される
2. 静的ルートを使用したVPN接続
3. Direct Connectのパス
4. AS_PATHを利用した動的(BGP)ルートを使用したVPN接続

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWS Well-Architected Framework 5つの柱まとめ

AWS Well-Architected Framework 5つの柱について自分なりにまとめてみました。

セキュリティ

• すべてのレイヤーをセキュリティで保護する。
• リソースの変更やインスタンス内部へのログインなどログを記録する。
• セキュリティの確保を自動化させる。

信頼性

• 障害からの復旧、回復が迅速にできるようにする。
• 障害からの復旧を自動化する。
• 可用性を向上するため適切にスケーリングを設定する。
• 長年の勘とかに頼らない。

パフォーマンス効率

• 最新の技術を導入してその恩恵をうける。
• 分単位でデプロイを行う。
• サーバレスアーキテクチャを利用する。
• 適切な技術を導入する。

コストの最適化

• 不必要なコストを排除する。
• データセンターへの投資をやめる。
• 支出を分析する。
• マネージドサービスを利用して使用量を抑える。

運用上の優秀性

• コードで運用作業を実施する。
• 変更処理を自動化する。
• 想定外の障害などに対応するためのテストを行う。
• 手順は常に最新に保つ。

参考資料

https://aws.amazon.com/jp/architecture/well-architected/ http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSの設計におけるベストプラクティス

AWSでの設定におけるベストプラクティスみたいなものを自分なりにまとめてみました。

スケーラビリティを確保する

• インフラをシームレスにスケールできることがAWSの利点。
• AWSのすべてのレイヤーでスケーラビリティを活用するべき。
• 理想的なシステムはスケールアウトするだけでなく、不要なインスタンスが稼働し続けないようにシステムをスケールダウンするようなシステム。

インフラ環境を自動化する

• リソースのプロビジョニング、終了、設定は可能な限り自動化する。
• 例えば異常のあるリソースの検出と代替リソースの起動を自動化する。
• リソースの変更時に通知を受信するようにする。

リソースを使い捨てにする

• 各インスタンスの設定を同一にし、リソースのデプロイを自動化する。
• 使用していないリソースは削除する。
• 固定IPアドレスはできるだけ利用せず、新しいIPアドレスに自動的に切り替える。
• 古いインスタンスと新しいインスタンスをかんたんに置き換えられるようにしておく。

疎結合化する

• 独立したサービスでアーキテクチャを設計する。
• システムのレイヤー間にAWSのマネージドサービスを活用して疎結合化させる。
• ELBとSQSを利用するとかんたんに疎結合に近づくことができる。

AWSのサービスを最大限利用して設計する

• すべてをEC2インスタンスのサーバの内部で実施するのではなく、AWSサービスを利用することを検討する。
• マネージドサービスを利用してサーバレス化させる。

データの特性にあったデータベースを選択する

• 要件にあったデータベースを適切に選んで利用する。
• Read/Writeやストレージのサイズ、レイテンシーなどを考慮する。
• データベースにあわせて業務を決めるのではなく、業務をもとにデータベースを洗濯する。

SPOFをなくす

• 一箇所の障害によってシステム全体が停止するのを避けるため、冗長性を保たせる。
• 物理ハードが故障した場合でもサービスを維持し続けられるように設計する。

コスト効率をあげる

• コストを最適化する。
• リソースのサイズやタイプが適切かどうか確認する。
• 使用されていないリソースを終了する。
• マネージドサービスを積極的に利用し、利用料を下げる。

キャッシュを利用して通信料を抑える

• CloudFrontなどのキャッシュサービスを利用する。
• キャッシュを利用することで通信コストやレイテンシーなどを軽減することができる。

セキュリティを確保する

• ユーザには権限は利用する最小の権限しか与えない。
• データのやり取りは暗号化する。
• アクセスログを記録する。

参考資料

AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

EC2Schedulerをつかってみる

今回はEC2SchedulerというAWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールを利用してみたいと思います。

EC2Schedulerとは?

AWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールです。
EC2に起動停止の時間などを記載したタグをつけることで、インスタンスを毎日自動的に起動/停止してくれます。

EC2Schedulerをつかってみる

実際にEC2Schedulerを使ってみたいと思います。

CloudFormationテンプレートのダウンロード

以下からec2-scheduler.templateをダウンロードします。

docs.aws.amazon.com

CloudFormationスタックをつくる

マネジメントコンソールのCloudFormationから「スタックの作成」を選択します。

「テンプレートの選択」でさきほどダウンロードしてきたec2-scheduler-.templateを選択します。
選択したら「次へ」すすみます。

「スタックの名前」に任意の名前をつけます。
「パラメータ」はデフォルトのままいったん「次へ」でかまいません。

オプションも一旦そのまま「次へ」でかまいません。

CAPABILITYの「AWS CloudFormationによってIAMリソースが作成される場合があることを承認します」にチェックをいれ、「作成」を選択します。

スタックが作成されるのでしばらく待ちます。
「状況」が「CREATE_COMPLETE」となったら完了です。

インスタンスにEC2Schedulerのタグをつける

EC2Schedulerでスケジュール起動停止したいインスタンスを選択し、タグを設定します。
設定するタグの例は以下の表に示します。
時間はUTCでしか記載できないので注意が必要です。

EC2Schedulerのタグの例

タグ値の例	説明
0800;1800;utc;all	インスタンスは08:00に開始し、18:00にすべての曜日に停止します。
1000;1700;utc;weekdays	インスタンスは1000から開始し、月曜日から金曜日の17:00に停止します。
1030;1700;utc;mon,tue,fri	インスタンスは1030に開始し、月曜日、火曜日、金曜日にのみ17:00に停止します。
0815;1745;utc;wed,thu	インスタンスは0815に開始し、水曜日と木曜日のみ1745に停止します。
none;1800;utc;weekdays	インスタンスは、月曜日から金曜日の18:00に停止します。インスタンスは手動で起動する必要があります。
0800;none;utc;weekdays	インスタンスは月曜日から金曜日の08:00に開始します。インスタンスを手動で停止する必要があります。
none;none;utc;weekdays	インスタンスは手動で開始および停止する必要があります（自動アクションは実行されません）。
0800	インスタンスは08:00に開始され、Amazon DynamoDBテーブルに格納されているデフォルトのアクティブ日にデフォルトの停止で停止します。
0800;1800	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
0800;1800;utc	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
default	インスタンスは、デフォルトのスケジュールで開始および停止します。
True	インスタンスは、デフォルトのスケジュールで開始および停止します。
EMPTY	インスタンスに対して実行されるアクションはありません。
Random String	インスタンスに対して実行されるアクションはありません。

以下公式ドキュメントから抜粋
Automated Deployment - EC2 Scheduler on AWS

EC2Schedulerが実行されたか確認する

マネジメントコンソールの「CloudWatch」から「メトリクス」、「EC2Scheduler」と選択します。

「Region」を選択します。

するとEC2Schedulerを設定したインスタンスのリソースIDを設定したが表示されるので、EC2Schedulerの実行状態を確認したいインスタンスのリソースIDを選択します。

グラフが0か1になっているのがわかるかと思います。
0が停止で1が起動です。
今回は1405;1420;utc;weekdaysと設定してみましたので設定通り14:05起動(1)、14:20に停止(0)されていることがわかります。

まとめ

EC2Schedulerをつかってインスタンスの自動起動停止を実施してみました。
夜間はインスタンスを停止するなど、コスト削減の基本ですのでこういったものを利用してみるのもいいかもしれません。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

ALBでターゲットが全てunhealthyとなったときの動き

ALBでの動作

ALBでは対象のターゲットがヘルスチェックでunhealthyとなっても通信がターゲットに対して行われます。
そして、ALBでは正常なターゲットが含まれているAZがない場合、すべてのターゲットにリクエストをルーティングします。

おそらくフェイルオープンのような思想で設計されているのだと思います。

なにか障害が発生した際に全面断にするような運用をしたい場合には、セキュリティグループで拒否したり、待受ポート番号を変更したりなど、バックエンドインスタンス側に手を入れる必要があるかと思います。

参考:CLBでの動作

CLBの場合はヘルスチェックに失敗したインスタンスにリクエストをルーティングは行われない仕様で、動作に違いがありますので注意が必要です。

ですので全面断をかんたんに実装したい場合にはCLBのほうが適しているかもしれません。

Amazon Web Services　定番業務システム12パターン設計ガイド

Route53でTTLに0を設定したときの動作

Route53のTTLの設定は0から2147483647の間で設定することができます。

0を設定した場合は以下のような動作になります。

Route53でTTLに0を設定したときの動作

キャッシュせずに毎回、名前解決が実行されます。
そして、Route53からはTTL:0のレコードが返却されます。

(ただし、TTLに従って名前解決を行うかはクライアントやDNSキャッシュサーバの設定などに依存します。)

一般的にレコードをキャッシュさせたくない場合にはTTLに0などの短い値を設定するのが有効です。

参考

Nginxでのデフォルトの設定ではTTLにかかわらず名前解決を起動後の1回のみしか実施しない仕様になっています。

papix.hatenablog.com

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

旧バージョンのAmazonLinuxを利用する

マネジメントコンソール上からでは最新版Amazon Linuxしか選択することができません。

基本的には最新版の利用でかまいませんが、現行環境と環境を統一したいときなど、古いバージョンのAmazon Linuxを利用したいときがあるかと思います。

今回は最新ではないAmazon Linuxを入手する方法をご紹介します。

手順

EC2インスタンスの作成時に、コミュニティAMIを選択します。

そして検索で「Amazon Linux 2016」のように過去のバージョンを検索すると、該当のバージョンが出てきますのでそのAMIを利用してインスタンスを作成します。

ただ、コミュニティAMIは公式以外の第三者もAMIを公開しています。
公式のものが利用したい！という場合には以下のAWS CLIを実行し、amazonと表示されれば公式のものです。

aws ec2 describe-images --image-ids ami-xxxxxxxx --region ap-northeast-1 --query 'Images[].ImageOwnerAlias'

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

AWSCLIでS3全体を暗号化する

AWSCLIのaws s3 cpコマンドではオプションで--sseを指定することでAES256で暗号化することが可能です。

この際にコピー元とコピー先に同一のパスを指定することでパスを変えずに、オブジェクトを暗号化することが可能です。
具体的には以下のようにコマンドを実行します。

 aws s3 cp s3://kabegiwa-bucket/ s3://kabegiwa-bucket/ --recursive --sse

コピー元とコピー先にバケットを指定し、--recursiveで再帰的に--sseで暗号化しています。

また、このコマンドをcronなどに設定することで定期的にバケット全体を暗号化することが可能です。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

AWSCLIでS3のオブジェクトをサーバーサイドで暗号化するやりかたまとめ

サーバーサイドでS3のオブジェクトを暗号化して格納する方法をご紹介します。
(クライアントサイド暗号化はSDKなどで実装する必要があるのですこし敷居が高いです)

SSE-S3で暗号化する

SSE-S3はデフォルトの暗号化方式ですのでオプションで--sse AES256と指定してあげるだけでかんたんに暗号化することができます。

aws s3 cp wawawa.txt s3://kabegiwa-bucket/ --sse AES256

以下のようにAES256の表記は省略することも可能です。

aws s3 cp wawawa.txt s3://kabegiwa-bucket/ --sse

SSE-KMSで暗号化する

まず、KMSを使って鍵を作成する必要があります。
鍵の登録方法はこちら

www.kabegiwablog.com

SSE-KMSで暗号化する際はオプションで--sse aws:kmsというオプションを指定し、--sse-kms-keyidで利用するキーのIDを指定します。

aws s3 cp wawawa.txt s3://kabegiwa-bucket/ --sse aws:kms --sse-kms-key-id aaaaaaaa-bbbb-cc12-3456-7890-dddddddddddd

Amazon Web Services　定番業務システム12パターン設計ガイド

KMSに鍵を登録する方法

KMSに鍵を登録する

すでに登録済みの鍵を利用する場合は読み飛ばしてください。
マネジメントコンソールで「IAM」の「暗号化キー」に移動し、「今すぐ始める」を選択します。

東京リージョンを選択し、「キーの作成」を選択します。

「エイリアス」と「説明」を入力し、「次のステップ」へすすみます。

タグは任意でかまいません。

このキーを利用するユーザを選択して、「次のステップ」へすすみます。

作成するキーのポリシーのプレビューがでるのでそのまま「完了」です。

Amazon Web Services パターン別構築・運用ガイド 一番大切な知識と技術が身につく

S3で利用できる暗号化方式まとめ

S3にファイルを保存するときに利用できる暗号化方式をまとめてみました。

サーバーサイド暗号化

SSE-S3

AWSが管理する鍵をつかって暗号化する方法です。ユーザが鍵について意識する必要が無いのがメリットです。
AWSが提供するオプションです。

SSE-KMS

AWS KMSで管理されている鍵を使って暗号化します。SSE-S3と違い、ユーザごとに別の鍵を利用することも可能です。
鍵のアクセス権限の管理や、利用履歴などを確認することもできます。

SSE-C

ユーザが作成した鍵をAWSに送信し、AWSで暗号化する方式です。
AWSでは暗号化後、秘密鍵を破棄し、公開鍵のみを保持することで第三者の複合を防ぎます。

クライアントサイド暗号化

KMSのカスタマーマスターキーを利用する

単純にKMSのキーを利用して暗号化します。

クライアントのキーを利用して暗号化する

そもそもAWSの領域に入る前に自分で管理しているキーを利用して暗号化します。
この場合、暗号化された状態ですべての通信がおこなわれるのでよりセキュアな状態を保つことができます。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

Cyberduckを利用してS3とファイルをやり取りしてみる

今回はCyberduckというGUIのFTPクライアントツールを利用してAWS上のS3バケットとローカルでファイルのやりとりをしてみたいと思います。

準備

Cyberduckのダウンロード

以下からダウンロードできます。
WindowsかMacか利用しているOSに応じてダウンロードCyberduckをダウンロード/インストールしてください。

https://cyberduck.io/index.ja.html?l=ja

CyberduckをS3とつなぐ

右上から「新規接続」を選択します。

どこに接続するのかを設定する画面が開くので上部のプルダウンメニューから「Amazon S3」をえらび、S3に接続するIAMユーザの「アクセスキー」と「パスワード」の欄にシークレットアクセスキーを入力します。
入力したら「接続」を選択します。

するとS3へ接続が行われ、バケットの一覧がでてきます。

バケット名をダブルクリックするとバケットの中身がみれます。

実際の操作

S3へファイルをアップロードする

ファイルをドロップするだけでS3へのアップロードが可能です。

S3からファイルをダウンロードする

ダウンロードしたいファイルを右クリックして「ダウンロード」でかんたんにダウンロードできます。

まとめ

マネジメントコンソールでもおなじようなことは可能ですが、このようなツールを利用することでより厳密なアクセス制限をかけることも可能なので検討してみるのもいいかもしれません。

補足

IAMロールをつかってCyberduckを利用する方法を書きました。 www.kabegiwablog.com

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

S3を社内のファイルサーバとして利用する

概要

S3を複数のユーザで利用するファイルサーバ(ファイルストレージ)として利用する方法をご紹介します。
S3を作成して共有するだけでファイルのやりとりは可能ですが、すべてのユーザがrootユーザとしてアクセスすることになるのでセキュリティ上よろしくありません。IAMユーザとIAMグループを作成し、適切に権限を付与させていきます。

手順

S3バケットの作成

マネジメントコンソールの「S3」から、「バケットを作成する」を選択します。

バケット名とリージョンを入力し、ウインドウ左下の「作成」を選択します。

バケットができました。

IAMユーザの作成

マネジメントコンソールの「IAM」を開き、サイドメニューから「ユーザー」を選択します。

「ユーザを追加」を選択します。

「ユーザ名」を入力して、「プログラムによるアクセス」にチェックをいれて「次のステップ：アクセス権限」へすすみます。

一旦アクセス権限は飛ばします。
そのまま「次のステップ：確認」へすすみます。

「ユーザの作成」を選択します。

するとユーザが作成され、アクセスキーとシークレットアクセスキーが表示されます。
この情報はS3とのファイルのやり取りに必要になりますので「表示」を押してメモをとっておくか、「.csvのダウンロード」で情報をダウンロードしておきます。

確認したら「閉じる」を選択します。

IAMグループの作成

サイドメニューから「グループ」にすすみ、「新しいグループの作成」を選択します。

「グループ名」を入力し、「次のステップ」を選択します。

「グループの作成」を選択します。

続いて作成したグループにユーザを追加します。
グループを選択して、「グループのアクション」から「グループにユーザーを追加」を選択します。

IAMユーザの作成で作成したユーザを選択して「ユーザの追加」でユーザーをグループに追加します。

IAMポリシーの作成

サイドメニューから「ポリシー」にすすみ、「ポリシーの作成」を選択します。

「独自のポリシー」を選択します。

ポリシー名に任意の名前をつけ、「ポリシードキュメント」の欄に以下のJSONをコピーします。
kabegiwa-bucketの部分はバケット名ですのでアクセス許可を与えたいS3の名前に変更してください。 それぞれ入力したら「ポリシーの作成」を選択します。

ポリシードキュメント例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::kabegiwa-bucket",
                "arn:aws:s3:::kabegiwa-bucket/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::kabegiwa-bucket/*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBucket",
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

このポリシーは以下の3つのことを許可するポリシーです。

1. kabegiwa-bucketのすべて(/*)に対してすべての許可であるs3:*を許可
2. kabegiwa-bucketに対してs3:ListBucket,s3:GetBucketLocationでバケット一覧の取得とバケットの場所の取得を許可
3. S3全体にs3:ListAllMyBucketsで存在するバケットの一覧取得を許可

IAMグループにポリシーをアタッチする

作成したポリシーから「アタッチされたエンティティ」タブを選択し、「アタッチ」をクリックします。

IAMグループの作成で作成したグループを選択し、「ポリシーのアタッチ」を選択します。

以上でAWS側の設定は完了です！

AWSCLIで実際にファイルのやり取りを行う

コンソールやコマンドプロンプトを開き以下のコマンドを実行し、ユーザ作成時に控えておいたアクセスキーとシークレットアクセスキーを入力します。
リージョンは東京リージョンの場合はap-northeast-1と入力します。
最後のoutput formatは空白のままそのままEnterでかまいません。

kabegiwa: ~$ aws configure
AWS Access Key ID [None]: アクセスキー
AWS Secret Access Key [None]: シークレットアクセスキー
Default region name [None]: ap-northeast-1
Default output format [None]: そのままEnter

そしてs3コマンドを使ってS3を操作します。

コピーする場合

kabegiwa: ~$ aws s3 cp wawawa.txt s3://kabegiwa-bucket/

移動する場合

kabegiwa: ~$ aws s3 mv wawawa.txt s3://kabegiwa-bucket/

バケットにファイルを置くことができました！

kabegiwa: ~$ aws s3 ls s3://kabegiwa-bucket
2017-10-31 21:31:14          0 wawawa.txt

まとめ

S3を利用してセキュリティを確保したファイルサーバを作成することができました。
CLIの利用が面倒な場合はCyberduckなどのGUIツールを利用するのがよいかもしれません。

Cyberduckを利用する方法はこちらから

www.kabegiwablog.com

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく