← ハンズオン一覧に戻る

AWS Hands-on / Compute

共有フォルダを、別のサーバーから覗く

Windows Server の EC2 インスタンスを 2 台用意し、1 台をファイルサーバーとして共有フォルダを作り、もう 1 台のクライアント役からネットワーク越しにアクセスして同じファイルが見えることを確認します。共有フォルダの置き場所には、追加でアタッチした EBS ボリュームを新しいドライブとして使います。

● Lv.3 複数のサービスを組み合わせられる人 ⏱ 所要 70〜100 分 リモートデスクトップ操作あり
01 — Prerequisites

はじめる前に

  • 必須AWS アカウントを持っていること
  • 必須マネジメントコンソールにサインインできること
  • 必須EC2 インスタンスへリモートデスクトップ接続できること(手順内で接続方法も説明します)
  • あると良いWindows のフォルダ共有・ドライブのフォーマットを操作した経験

※ ローカル端末は Windows を想定し、標準搭載の「リモートデスクトップ接続(mstsc)」を使う手順で説明します。Mac などをお使いの場合は、別途リモートデスクトップクライアントをご用意ください。

02 — References

参照する公式ドキュメント

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

03 — Background

背景・シナリオ

社内やチームでファイルを共有するとき、昔から使われている方法の 1 つが「ファイルサーバー」です。1 台のサーバーに共有フォルダを用意しておき、他のパソコンからネットワーク越しにそのフォルダを開く、というしくみです。今回は、この古典的なファイル共有の仕組みを、Windows Server の EC2 インスタンスを使って自分の手で組み立てます。

ファイルサーバー役の EC2 には、ルートボリュームとは別に追加のディスク(EBS ボリューム)を取り付け、そこを共有フォルダの置き場所にします。さらに、クライアント役の別の EC2 から、ネットワーク経由でその共有フォルダにアクセスできることを確認します。

Windows のキーペアは、SSH の鍵と同じ使い方なの?

いいえ、使い方が異なります。Linux では SSH でログインする際にキーペアの秘密鍵をそのまま使いますが、Windows インスタンスでは、起動時に自動生成された管理者(Administrator)パスワードを復号するためにキーペアを使います。復号して得られたパスワードを使って、リモートデスクトップでログインします。

共有フォルダへのアクセスは、誰からでも許可してよいの?

いいえ。今回は、ファイルサーバーのセキュリティグループで、共有フォルダ用の通信(SMB、ポート445)をクライアント役インスタンスのセキュリティグループからだけ許可します。IP アドレスの範囲ではなく、セキュリティグループそのものを許可元に指定する、実務でもよく使われる絞り込み方です。

Goal

ファイルサーバー役の EC2 に追加の EBS ボリュームをアタッチして共有フォルダを作り、クライアント役の別の EC2 からネットワーク越しにその共有フォルダへアクセスし、ファイルを作成・確認できる状態を作る。

04 — Architecture

つくる構成

同じサブネットに、ファイルサーバー役とクライアント役の Windows インスタンスを 1 台ずつ用意します。共有フォルダへの通信(SMB)は、クライアントのセキュリティグループからだけ許可します。

ファイルサーバー役
Windows Server
(例)
D ドライブ(追加EBS)
共有フォルダ
クライアント役
Windows Server
(例)
管理用のリモートデスクトップ接続(3389番)は、両方とも自分のIPからのみ許可します。
05 — Requirements

要件

以下の要件を満たし、2 台のインスタンス間でファイル共有が成立することを確認してください。

No要件
1リージョンは「東京(ap-northeast-1)」を使用する。
2同じサブネットに、Windows Server の EC2 インスタンスを2 台起動する(ファイルサーバー役・クライアント役。名前タグは自由、例:file-server / file-client)。
3ファイルサーバー役には、ルートボリュームとは別に追加の EBS ボリュームをアタッチし、サーバー内で初期化・フォーマットして新しいドライブ(例:Dドライブ)として使えるようにする。
4Dドライブの中にフォルダを作り、共有フォルダとして設定する(共有名は自由、例:SharedDocs)。
5ファイルサーバー役のセキュリティグループで、SMB通信(ポート445)をクライアント役のセキュリティグループからのみ許可する。
6クライアント役からネットワーク越しに共有フォルダへアクセスし、ファイルを 1 つ作成する。ファイルサーバー役側でそのファイルが存在することを確認する。
06 — Steps

構築の進め方

「2台立てる」→「ディスクを整える」→「共有する」→「許可を絞る」→「クライアントから確認する」の5フェーズで進めます。

  1. フェーズ1 — 2台のインスタンスを起動する
  2. マネジメントコンソールにサインインし、リージョンを合わせる

    ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック(東京)ap-northeast-1」になっていることを確認します。

  3. ファイルサーバー役のインスタンスを起動する

    EC2 コンソールで「インスタンスを起動」を押し、名前に file-server、AMI に Windows Server(最新版でよい、例:Windows Server 2022 Base)、インスタンスタイプに無料利用枠の対象(例:t3.micro)を選びます。キーペアを新規作成し、.pem ファイルをダウンロードしておきます。

    「ストレージを設定」で、ルートボリュームに加えて「新しいボリュームを追加」を押し、サイズを自由に決めて(例:8 GiB)追加のボリュームを設定してから起動します。

    セキュリティグループはいったんリモートデスクトップだけ許可

    インバウンドルールで、リモートデスクトップ(ポート3389)を自分のIPからのみ許可しておきます。SMB(ポート445)の許可は、クライアント役を作ったあとのフェーズ4で追加します。

  4. クライアント役のインスタンスを起動する

    同じ手順で、名前を file-client としたインスタンスをもう 1 台起動します。AMI・インスタンスタイプはファイルサーバー役と同じものでよく、追加のボリュームは不要です。キーペアは、同じものを使っても新規作成しても構いません。セキュリティグループは、リモートデスクトップ(ポート3389)を自分のIPから許可するルールにします。

  5. 両方の Administrator パスワードを取得する

    各インスタンスを選び、「接続」→「RDPクライアント」タブ→「Windowsパスワードを取得」を開きます。ダウンロードしたキーペアの秘密鍵ファイルの内容を貼り付け(またはアップロード)、「パスワードを復号化」を押して、Administrator パスワードを確認します。2 台分、それぞれのパスワードを控えておきます。

    起動直後はパスワードを取得できない場合がある

    インスタンスが起動してから数分間は、パスワードがまだ生成されていないことがあります。「パスワードを復号化」がうまくいかない場合は、少し待ってから再度試してみましょう。

  6. フェーズ2 — ファイルサーバー役のディスクを整える
  7. リモートデスクトップでファイルサーバー役に接続する

    Windows の「リモートデスクトップ接続」を開き、ファイルサーバー役のパブリックIPアドレスを入力して接続します。ユーザー名は Administrator、パスワードは手順5で取得したものを入力します。

  8. 追加のディスクを初期化し、新しいドライブにする

    サーバー内で「ディスクの管理」(diskmgmt.msc)を開きます。追加でアタッチしたディスクが「不明・初期化されていません」と表示されているので、右クリックして「ディスクの初期化」を行います。続けて、その領域を右クリックして「新しいシンプルボリューム」を選び、ドライブ文字(例:D)を割り当て、NTFS でクイックフォーマットします。

    初期化前は他の画面に出てこない

    追加したディスクは、初期化・フォーマットを済ませるまでエクスプローラー上には表示されません。「ディスクの管理」を開いて、まず存在を確認するのが最初のポイントです。

  9. フェーズ3 — 共有フォルダを作る
  10. Dドライブにフォルダを作り、共有設定する

    エクスプローラーで D:\ を開き、フォルダを 1 つ作成します(例:SharedDocs)。そのフォルダを右クリックして「プロパティ」→「共有」タブ→「詳細な共有」を開き、「このフォルダーを共有する」にチェックを入れ、共有名を確認して「許可」でアクセス許可(例:Everyone に読み取り/書き込み)を設定します。

    学習用のシンプルな許可設定でよい

    本来は利用者ごとに権限を細かく分けますが、今回は学習目的のため、共有のしくみ自体を体験することを優先し、シンプルな許可設定で進めます。

  11. ファイルサーバー役のプライベートIPアドレスを確認する

    コマンドプロンプトで ipconfig を実行するか、EC2 コンソールのインスタンス詳細で「プライベートIPv4アドレス」を確認し、メモしておきます。

    使うのはプライベートIP

    同じ VPC 内のインスタンス同士の通信には、プライベートIPアドレスを使います。パブリックIPアドレスでアクセスしようとすると、想定通りに動かないことがあります。

  12. フェーズ4 — 許可をクライアントだけに絞る
  13. ファイルサーバー役のセキュリティグループにSMBルールを追加する

    EC2 コンソールの「セキュリティグループ」で、ファイルサーバー役にアタッチされているセキュリティグループを開き、インバウンドルールを編集します。タイプ:カスタムTCP、ポート:445を追加し、ソースにはクライアント役にアタッチされているセキュリティグループを指定します。

    ソースにIPアドレスではなくセキュリティグループを指定する

    ソースの入力欄に sg- から始まるセキュリティグループIDを指定すると、「そのセキュリティグループが付いているインスタンスからの通信だけ許可する」という設定になります。クライアント役のIPアドレスが将来変わっても、設定を直す必要がありません。

  14. フェーズ5 — クライアントから確認する
  15. リモートデスクトップでクライアント役に接続する

    ファイルサーバー役と同様に、クライアント役のパブリックIPアドレスとパスワードでリモートデスクトップ接続します。

  16. 共有フォルダにアクセスし、ファイルを作成する

    エクスプローラーのアドレスバーに、\\<ファイルサーバー役のプライベートIP>\SharedDocs のように入力してアクセスします。共有フォルダの中身が表示されたら、適当なテキストファイルを 1 つ新規作成して保存します。

  17. ファイルサーバー役側でもファイルを確認する

    ファイルサーバー役のリモートデスクトップ画面に戻り、D:\SharedDocs を開いて、クライアント役から作成したファイルが存在することを確認します。

    これがゴール

    クライアント役で作ったファイルが、ファイルサーバー役側にもそのまま見える——この状態を確認できたら、このハンズオンの目的は達成です。

07 — Pitfalls

つまずきポイント

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

Pitfall 01 — \\IP\共有名 でアクセスできない

「クライアント役から共有フォルダを開こうとすると、見つからないと表示される」

①入力したIPアドレスがプライベートIPになっているか②ファイルサーバー役のセキュリティグループに、ポート445・ソースをクライアント役のセキュリティグループとするルールが追加されているかを見直しましょう。どちらか一方が欠けていると接続できません。

Pitfall 02 — 追加したディスクがエクスプローラーに出てこない

「Dドライブを使いたいのに、PCの画面に表示されない」

「ディスクの管理」を開き、ディスクの初期化・新しいシンプルボリュームの作成・ドライブ文字の割り当てまで、すべて完了しているか見直しましょう。アタッチしただけのディスクは、初期化前は「不明」な状態のまま表示されません。

08 — Checklist

完了チェック

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。

  • ファイルサーバー役の「ディスクの管理」で、追加したディスクがオンライン状態のDドライブとして表示されている。
  • ファイルサーバー役のセキュリティグループのインバウンドルールに、ポート445・ソースがクライアント役のセキュリティグループのルールが存在する。
  • クライアント役のエクスプローラーから \\<プライベートIP>\SharedDocs を開くと、中身が表示される
  • クライアント役で作成したファイルが、ファイルサーバー役の D:\SharedDocs にも同じ名前で存在している。
09 — Think

考えてみよう

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

  1. SMB通信の許可元を「すべて(0.0.0.0/0)」にせず、クライアント役のセキュリティグループだけに絞ったのには、どんな意味があるでしょうか。
    ヒント
    共有フォルダの通信が世界中から届く状態を想像してみましょう。許可する相手を「特定のセキュリティグループを持つインスタンスだけ」に絞ることで、意図しないアクセスを防げる、という最小権限の考え方がヒントです。
  2. 共有フォルダの置き場所を、ルートボリュームではなく追加でアタッチしたEBSボリュームにしたのには、どんな利点が考えられるでしょうか。
    ヒント
    データ用のディスクをOS用のディスクと分けておくと、OSを入れ替えたり、ディスクだけをバックアップ・移動したりする際にどんな違いが出るか考えてみましょう。
  3. 今回はプライベートIPアドレスを直接指定してアクセスしましたが、サーバーの台数が増えてプライベートIPが変わりやすくなった場合、どんな仕組みがあると管理しやすくなるでしょうか。
    ヒント
    IPアドレスの代わりに名前でアクセスできる仕組みがあれば、サーバーを入れ替えてもクライアント側の設定を直さずに済みます。そのような名前の仕組みについて調べてみましょう。
10 — Clean up

後片づけ

作成した2台のインスタンスを終了し、リソースを整理しましょう。

  1. 両方のインスタンスを終了する:EC2 コンソールの「インスタンス」で file-serverfile-client を選び、「インスタンスの状態」→「インスタンスを終了(Terminate)」を選びます。
  2. 追加したボリュームが残っていないか確認する:左メニュー「ボリューム」を開き、追加でアタッチしたボリュームが、インスタンス終了とともに削除されているか確認します(ルートボリュームと同様に「終了時に削除」が有効になっていれば自動的に削除されます)。
Caution — 追加ボリュームの「終了時に削除」設定を確認する

設定によっては、ボリュームだけ残って課金が続く

追加でアタッチしたボリュームは、ルートボリュームとは別に「終了時に削除」の設定を持つ場合があります。インスタンス終了後にボリューム一覧を確認し、削除されずに残っているボリュームがあれば、忘れずに個別に削除してください。デフォルトVPCやデフォルトのサブネットは消さないようにしましょう。

コストに関する注意: Windows Server の EC2 インスタンスは、Linux に比べて時間あたりの料金が高めに設定されています(OSのライセンス料金が含まれるためです)。今回は2台起動するため、課金額にも注意してください。追加でアタッチした EBS ボリュームにも、容量に応じた料金が時間単位でかかります。短時間で終えれば少額にとどまりますが、後片づけを忘れて2台のインスタンスを放置すると課金が継続します。最新の料金は AWS の公式料金ページで確認してください。なお、VPC・サブネット・ルートテーブル・セキュリティグループ自体には料金はかかりません。