APC 技術ブログ

pages.awscloud.com

まとめ

ストレージと一口に言っても複数の種類があり、データ移行方法も多数あります。「移行元」「移行方法」「移行先」ごとに条件を整理して、目的に合ったサービスを組み合わせていくことが重要です。
移行先ストレージ選定や移行方法検討のお役に立てれば幸いです。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

2024-04-18

【初心者・入門】AWS VPN 接続と AWS Direct Connect の概要

AWS Cloud クラウド VPN Direct Connect

はじめに

こんにちは、エーピーコミュニケーションズクラウド事業部の高橋です。

今回のブログでは、外部環境と AWS をセキュアに接続する方法の概要について調査して書いてみたいと思います！
外部環境と AWS の接続には主に３つの方法があり、それぞれの特徴と料金体系や通信速度などにも比較してみたいと思います！
今回もよろしくお願いします！

どんなひとに読んで欲しい

外部環境と AWS 間のネットワーク接続について概要を知りたい人
VPN や Direct Connect などの AWS へのネットワーク接続の種類の違いについて知りたい人

外部環境から AWS への接続方法

まずはじめに、外部環境から AWS への接続する方法としては、大きく分けて以下の２種類があります。

・インターネット回線を使用した接続
・専用回線を使用した接続

また、「インターネット回線を使った接続」とは、VPN (Virtual Private Network) と呼ばれる仮想の専用線を設定することでインターネットを通じたプライベートなネットワーク接続であり、AWS が提供する VPN (AWS VPN) では以下の2種類のサービスがあります。

・リモートアクセス VPN
・拠点間 VPN

すなわち、VPN を使用した接続２種類と専用回線を使用した接続１種類、計３種類の方法がありますので、それぞれ確認していきたいと思います！

① AWS Client VPN
AWS Client VPN は、インターネット回線を利用して接続するリモートアクセス VPN サービスです。
名前のとおり、クライアント PC やスマートフォンやタブレットなどの様々な端末から VPN 接続にて AWS のリソースにアクセスすることができます。
そのため、端末や場所を問わずに AWS リソースにアクセスできることにより、ユーザーがリモートワークなどの柔軟なワークスタイルに対応できます！

端末側に VPN クライアントアプリケーション (VPN 接続を実現するためのソフトウェア) をインストールし、AWS 側にクライアント VPN エンドポイントを作成してターゲットネットワーク (VPC とサブネット) を関連付けすることによって通信することが可能となります。
また、AWS Client VPN は SSL-VPN 接続方式で、SSL/TLS プロトコルにて暗号化され、ブラウザから HTTPS 接続やクライアントツールから SSH 接続などでアクセスすることとなります。

以上を踏まえたうえで、AWS Client VPN を利用した EC2 インスタンスへのアクセスを簡潔に図式に表してみました。
補足ですが、端末側にインストールする VPN クライアントアプリケーションは、AWS から提供されている VPN クライアントアプリケーション以外にも、OpenVPN 等が提供している VPN クライアントアプリケーションも利用できます。
(どうやら、以前は AWS 自らの VPN クライアントアプリケーションは提供していなかったようです)

AWS が提供するクライアントを使用して接続する - AWS Client VPN
OpenVPN クライアントを使用して接続する - AWS Client VPN

② AWS Site-to-Site VPN
AWS Site-to-Site VPN は、インターネット回線を利用して接続する拠点間 VPN サービスです。
"拠点間”、すなわちオンプレミスや社内データセンターなどの拠点ネットワークと AWS 間をインターネットを経由して VPN 接続できるようにします。
また、特定の端末や拠点だけでなく複数の拠点から AWS に接続することができ、拠点ネットワーク全体から AWS に接続するので個々の端末が拠点ネットワークに接続されていれば社内 LAN のようにクラウドに接続できます。

オンプレ環境などの拠点側のルーター (インターフェイス) に紐づけるようにカスタマーゲートウェイを作成し、AWS 側では仮想プライベートゲートウェイもしくはトランジットゲートウェイを作成し、接続したい VPC にアタッチすることによって通信することが可能となります。

仮想プライベートゲートウェイとトランジットゲートウェイの違いを簡単に説明しますと、１つの拠点と１つの AWS VPC の１対１で接続する場合は仮想プライベートゲートウェイ、一方、複数の拠点と複数の AWS VPC (複数のリージョンや AWS アカウントに跨るなど) で接続する場合はトランジットゲートウェイを利用する、と認識いただけたらと思います！

また、AWS Site-to-Site VPN では、IPsec-VPN 接続方式で、IP パケットを暗号化・カプセル化し IPsec トンネルで接続します。
パケットの暗号化/カプセル化や復号/非カプセル化などは全て VPN を実装したルーター内で行われるため、基本的にクライアント端末に VPN クライアントアプリケーションなどのインストールは必要ありません。

<備考>
AWS Site-to-Site VPN は、トンネルのオプションとして、冗長性を確保するために、１つの Site-to-Site VPN 構成に異なるアベイラビリティーゾーンで２つのトンネルを設定することができます。
これにより、例えばメンテナンスにより片方のトンネルが使用できなくなったとき、もう片方の使用可能なトンネルへ自動的にルーティングされて通信することが可能となります。
当ブログでは、AWS Site-to-Site VPN の詳細なオプションや設定には触れませんが、以下の AWS 公開ドキュメントを参考にしていただけたらと思います。
Site-to-Site VPN 接続のトンネルオプション - AWS Site-to-Site VPN

以上を踏まえたうえで、AWS Site-to-Site VPN を利用した複数 VPC の EC2 インスタンスへのアクセスを簡潔に図式に表してみました！

③ AWS Direct Connect
AWS Direct Connect (DX とも呼ばれます) は、インターネット回線を利用せず、専用回線を使用した閉域ネットワーク接続できるサービスです。
インターネットから物理的に分離された専用回線であるため、不正アクセスなどに侵されにくく安全性が高く、また、他の回線からの通信量の影響を受けないために通信速度も安定します。

この接続方法で一番重要なのが AWS Direct Connect ロケーションです。
AWS Direct Connect ロケーションは、各データセンター事業者によって運営されている世界各地の AWS リージョンのコロケーションデータセンターに存在しており、そのデータセンターの AWS Direct Connect ロケーション内には AWS Direct Connect ルーターが設置されています。
また、ユーザーは AWS Direct Connect デリバリーのパートナーとキャリア契約を結び、AWS Direct Connect ロケーションがあるデータセンターにユーザー専用ルーターを設置して AWS Direct Connect ルーターと繋ぎます。
そして、オンプレ環境などの拠点とデータセンターに設置したユーザー専用ルーターを専用回線で接続することによって、AWS Direct Connect にてクラウドに接続することが可能となります。

また、Direct Connect ゲートウェイを使用することで、複数リージョンの VPC との接続や VPC を追加する際の設定が容易になるなどのメリットがあります。
(Direct Connect ゲートウェイを使用しなくとも AWS Direct Connect は構築できますが、Direct Connect ゲートウェイは無料ということもあり、要件が特段ない限り現在では使用することが基本のようです)

そして、Direct Connect ゲートウェイとトランジットゲートウェイを関連付けて組み合わせることにより、複数リージョン× AWS 内の複数 VPC 間の通信×オンプレ環境間の通信といった複雑になりがちな構成もシンプルな構成に整理することが可能となります。

以上を踏まえたうえで、AWS Direct Connect を利用した複数リージョンに存在する複数の VPC の EC2 インスタンスへのアクセスを簡潔に図式に表してみました！

各接続方法の比較

前項にて各接続方法の概要は把握できましたので、その他の特徴なども踏まえて比較表に表してみました！

＊１
専用接続とは準備されたポートを単一のユーザー占有で利用できる接続方法であり、ホスト型接続とは AWS Direct Connect デリバリーパートナーが提供しているポート対して複数のユーザーをホストし共有する接続方法です。
詳細については、以下のリンクから確認できます。
AWS Direct Connect 接続 - AWS Direct Connect
AWS Direct Connect デリバリーパートナー

＊２
AWS Site-to-Site VPN のデータ転送において、AWS 側のデータ受信については料金は発生しません。
また、アクセラレーションを有効化し、高可用・高パフォーマンスな Accelerated サイト間 VPN を利用することにより、料金が大きく変動します。
詳細については、以下のリンクから確認できます。
AWS VPN の料金
AWS Global Accelerator の料金

おわりに

今回は、外部環境から AWS に接続する３つの方法について、概要的に書いてみました！
それぞれの接続方法をいざ構築する際には、上述した内容だけでなく、さらに認証方法や冗長化など様々な要素も考慮して設計していかなければなりません。
今回のブログは、AWS における VPN 接続や Direct Connect について、概要や簡単な比較として入門的に参考にしていただけたら幸いです！

ご拝読いただき、ありがとうございました！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

2024-04-15

【初心者・入門】AWS User Notifications を設定しEメール通知を検証

AWS 検証クラウド Cloud AWS User Notifications

はじめに

こんにちは、エーピーコミュニケーションズクラウド事業部の高橋です。

３本目のブログは、AWS User Notifications という通知サービスについて、基本的な設定方法を実際に設定しながら書いてみます！
AWS には Amazon SNS や Amazon SES といった通知サービスもあるので、簡単な比較もしつつ AWS User Notifications について説明できたらと思います！
どうぞよろしくお願いします！

どんなひとに読んで欲しい

AWS の通知サービスについて概要を知りたい人
AWS User Notifications を実際に設定したり実装してみたい人
AWS User Notifications でエラー通知を受け取りたい人

AWS User Notifications とは

AWS User Notifications (日本語名だと「AWS ユーザー通知」と呼びます) は、２０２３年５月に提供を開始した比較的新しい AWS の通知サービスです。
複数の AWS アカウント/リージョン/サービスにおける AWS 通知を、AWS コンソール内で一元的に設定し、一覧で表示することができます。
サービスについては、AWS Health イベント、Amazon CloudWatch アラーム、EC2 インスタンスの状態変化、S3 のオブジェクトイベント等々、１００以上の AWS サービスに対応しています。

AWS の通知サービスとなると、他にも Amazon SNS や Amazon SES がありますので、AWS 初心者の自分としては「何が違うのか？」と疑問が湧いてきたので、簡単に比較してみました！

確認してみたところ、Amazon SES はアラートなどの通知や検知というよりも、Eメールを効率的にユーザーへ配信できるサービスということが分かりました。
また、Amazon SNS と AWS User Notifications は、どちらも障害やアラートなどの通知や検知として利用するケースが多いかと思われます。
しかし、Amazon SNS ではユーザー通知以外に他アプリ (システム) への連携や詳細なフィルタリング設定などができる分導入や構築が若干難しく、一方で、AWS User Notifications はユーザー通知に特化してコンソール上からの一元管理や一覧表示により比較的容易に導入できそうな印象を持ちました！

AWS User Notifications の基本的な設定方法

今回のブログでは、昨年からサービス提供した AWS User Notifications の基本的な設定方法を実際に検証し、どれほど簡単に設定できるのか確認してみたいと思います！

今回の検証では、前回のブログで AWS Backup を検証したので、AWS Backup のバックアップ時に AWS User Notifications を利用して通知を Gmail に飛ばせるか検証してみたいと思います！

① 通知ハブの設定
まず、通知ハブを設定します。
通知ハブでは、通知データが保存・処理されるリージョンの選択、また、通知データが複製されるリージョンを追加することができます。(最大３リージョンまで)
余談ですが、生成された通知データが通知ハブで保存される期間は９０日間です。
Adding or removing a notification hub - AWS User Notifications

However, notifications expire 90 days after they are generated.

今回の検証では、東京リージョンを選択し、「更新」をクリックします。

② 配信チャネルの設定
続いて、配信チャネルを設定します。
今回の検証では、配信チャネルに自分の Gmail を設定して、通知が飛ぶか確認してみたいと思います！

AWS User Notifications の配信チャネルから「Eメールの追加」をクリックしてください。

画面が遷移したら、通知したいEメールアドレスとその名前を入力して、「Eメールの追加」をクリックしてください。

すると、自動的に画面が遷移し、追加したEメールアドレスが検証ステータス「保留中」となりましたので、しばらく待ちます。

５分ほど待ちつつ、何回か画面を更新しましたが「保留中」のステータスから変わりませんでした・・。
そのとき、追加したEメールアドレス宛にメールが届いていたため、確認してみると・・・、以下のように追加したEメールアドレスに AWS からEメールアドレスの検証メールが届いていました！
なので、ここは「Verify email」をクリックします。(黒字で伏せている箇所は自分の AWS アカウント ID です)

「Verify email」をクリックすると自動的に画面が遷移し、追加したEメールアドレスの検証が完了しました。

また、先ほどの検証ステータスも無事に「アクティブ」に変化していることが確認できました！
これにて、通知したいメールアドレスの配信チャネルへの設定が完了しました。

③ 通知設定 (通知したい内容の設定)
次に、通知設定、すなわち、通知したい内容を設定していきたいと思います！

AWS User Notifications の通知設定から「通知設定を作成」をクリックしてください。

すると、設定画面に遷移します。
まずは、作成する通知設定について名前を入力します。

続いて、イベントルール、すなわち、通知したい内容の設定です。
プルダウンにて、通知を受け取りたい AWS サービスを選択します。
今回の検証では「Backup」を選択します。
イベントタイプは「Backup Job State Change」を選択してみます。
リージョンは東京リージョンを選択します。

続いて、集約設定です。
表示されているように、通知の受信頻度について設定します。
ここは通知の内容にもよりけりだと思いますが、通知が来過ぎても来なさ過ぎてもダメかと思いますので、今回は推奨である「５分以内に受領」を選択します！

続いて、先ほど設定した配信チャネルを入力します。
「Eメール」を選択し、「受信者」に先ほど設定したEメールアドレスを入力します。(Eメールアドレスを入力すると自動的に名前は入力されました)
以上の入力が完了したら、右下の「通知設定を作成」をクリックしてください。

通知設定を確認したところ、無事にステータスが「アクティブ」で作成されていました！
これにて、通知内容の設定は完了です！

④ Eメールアドレスへの通知検証
それでは、Eメールアドレスに通知が届くか、実際に検証してみたいと思います！

先ほどの通知設定にてイベントタイプは「Backup Job State Change」を選択したので、AWS Backup にてバックアップジョブが動く操作を仕込んでみます。

前回のブログで作成した EC2 をバックアッププランに、改めて今回の検証用にリソースを割り当て、バックアップジョブを動かします。

しばらく待って、問題なくバックアップジョブは完了しました！

それでは、設定した Gmail にバックアップジョブの通知が正常に届いているか確認してみます・・！

無事に通知メールは届いていました！
ありがたいことに３通も！

メールの内容を確認してみると以下の内容でした。

**左が「CREATED」、中央が「RUNNING」、右が「COMPLETED」の状態で、この順番で通知が来ていました。**

前回のブログで触れたとおり、バックアップジョブが正常に流れると、ステータスは「(日本語表示で) 作成済み→実行中→完了」の順番で変化していきます。
どうやら、AWS User Notifications の通知もこのステータスの変化に合わせてメールが３通届いた模様です！
イベントタイプで選択した「Backup Job State Change」は、あくまで「State Change」なので、エラーに特化した通知設定の内容でなく、あくまでステータスが変化したタイミングで通知される設定ということです。(自分も薄々そうなんだろうな・・とは思っていましたが。。)

ただ、こういったユーザーへの通知としては、やはり問題なくジョブ等が完了したといった内容ではなく、ジョブ等がエラーになったという内容をユーザーが検知できることを目的や手段とすることが殆どかと思います。
なので、次の項目では、AWS User Notifications でエラー通知はどうすれば検知できるようになるのかを確認してみたいと思います！

一旦、この項目としては、AWS User Notifications を利用してEメールにて問題なく通知できる基本設定を確認することができました！

AWS User Notifications の通知設定をカスタムする

それでは前項を踏まえて、どうすればエラー通知を検知できるようになるか、確認していきたいと思います！

作成した通知設定からイベントルールを確認すると、クリック可能な「マネージドルール」という表示がありましたのでクリックしてみました。

すると、別ウィンドウにて Amazon EventBridge の画面が開きました。
Amazon EventBridge とは、AWS 内外のさまざまなソースやサービスから発生するイベントをトリガーとして、ルールに基づいて他のソースやサービスに橋渡しするような役割のサービスです。
どうやら AWS User Notifications にて通知設定をする際に、Amazon EventBridge 配下にルールが自動で作成される仕組みのようです。
そして、そのルールには JSON 形式の「イベントパターン」があるので、それを編集すればエラー通知としてメールを飛ばすことができると思い、早速編集しようと思います！

しかし、「編集」ボタンがグレーアウトし、イベントパターンを編集できないようになっていました・・！
また、タイプという項目が「管理」と表示され、管理者が「notifications.amazonaws.com」と表示されております・・。
どうやら、AWS User Notifications にて通知設定した際に作成された Amazon EventBridge のルールについては AWS 側で管理されているため、編集することができない模様です！

そうなると、どこで通知設定を編集することができるかと言いますと・・、以下のように通知設定のイベントルールを入力する際にオプションとして「高度なフィルター」がありましたので、ここで詳細な通知設定をしてみたいと思います！

先ほどの Amazon EventBridge にあったイベントパターンをコピーして、バックアップが「FAILED」となったときに通知が作動するルールを付け加えた JSON 式を入力し、通知設定を更新しました。

あとは、バックアップジョブが失敗するように仕込んで、エラー通知としてメールが届くか確認します！
※検証とは関係ないので割愛しますが、バックアッププランやバックアップルールの設定自体はそのままにして、バックアップを指定している EC2 インスタンスを削除することでエラーを発生させました。

しばらくしますと・・・想定通り、バックアップジョブが「FAILED」状態となった内容のメール通知が届いていることを確認できました！

おわりに

今回は、昨年提供開始した、比較的新しい通知サービスである AWS User Notifications の基本設定方法を実際に検証して確認してみました！
今回の検証では AWS Backup に関するメール通知でしたが、AWS User Notifications の通知設定におけるイベントタイプの基本設定だけではかなり粗い通知設定しか出来ないようなので、エラー検知に限らず AWS User Notifications を実装する際は「高度なフィルター」を利用した詳細な設定することは必須になるだろうと感じました！
少しでも参考にしていただけたら幸いです！

今回もご拝読いただき、ありがとうございました！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

2024-04-15

AWS Certified Data Engineer - Associate(DEA-C01)に合格できました。

AWS

はじめに

こんにちは、あるいはこんばんは、クラウド事業部の原田です。
今回は先日(2024年3月)に新しく開始となった AWS Certified Data Engineer - Associate に合格できたので、所感等を共有させていただこうと思います。

英語に自信がない為日本語版一般提供してしばらくしてから受けようかと思っていました...が

業務でデータエンジニアリング対応中
(※業務はAzureメイン。Azure Data Engineer Associateは先月取得)
一般提供開始と同時に日本語版対応していた
再試験無料キャンペーンも来てた(~4/15迄に一回目受験)
4月以降に予約すると受験料が上がる(¥5000)
範囲的にDASと被ってるっぽいので少しでもDASの記憶あるうちに...(それでも半年前)
~~ストレートに全冠！って言いたいじゃん？~~

というわけで一般リリースされて一月以内ですがチャレンジしてみることにしました。

点数

811/1000
AssociateなのにSpecialty(DAS:826)より下がってる...

勉強時間

約12h
SkillBuilderでExamPrepとPracticeTest (いつもの流れ)
ExamPrep(※英語版しかなかった。動画部分は字幕ONで1.5倍速)を視聴
Exam Prep Official Practice Question Set: AWS Certified Data Engineer - Associate (DEA-C01 - Japanese)

うろ覚えだったり理解が怪しい所をBlackBeltやブログ検索して閲覧。

試験の感想

一番懸念していたのは、『新試験なので日本語怪しい部分多いんじゃないか？』という部分だったのですが、
普通に違和感なく設問読めて良い意味で期待を裏切られました。
Amazon訳に慣れたのではなく、翻訳機能の進化を感じました。
また、Associateだからか回答欄の選択肢はシンプルなものが多く、
かなりの問題は選択肢が各1行で収まっていた印象です。

DBSも無くなるとのことで、こちらに統合されるのかと思いきや試験ガイドのドメインはほとんどDASと一緒。
試験ガイドには試験範囲の AWS のサービスと機能として
Amazon Managed Service for Apache Flink の名称がありますが、
(旧Amazon Kinesis Data Analytics) の記載に優しみを見た気がします。

DASと比較して設問、選択肢共にボリュームは減っていてシンプルになっていますが、
データ分析系のソリューションの知識以外に、関連するところとして
ストレージやセキュリティ、SQLクエリに関する問題等も出題されるので
他Associate試験と比べると試験範囲が広く、公式でも他Associate試験より高難度と言われています。
あまりいなそうではありますが、いきなりDEAに挑むよりは
まずSAA(とSOA)でストレージやセキュリティ回りを軽く抑えてから挑戦すると
データ分析系に注力しやすくなるのでおススメできそうです
体感的な難易度としては
Professionalは長文が辛すぎるのでそれよりは↓
他Associateより上述の通り範囲が広いので↑
一部Specialty(SCSやMLS)とは範囲と詳細さのトレードオフで同程度
の印象です。
~~ANS？あれは実質Professionalだと思ってる...~~

まとめ

他Associateより範囲が広く、データ分析系についてはそこそこ詳しく問われるので
データエンジニアとしてのスキルが必要ならSAA(&SOA)取得後におススメ。
ドメインは≒DASなので、過去にDAS取得済みなら良い復習になる。

ともあれこれで13冠目！

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: e_harada
普段はAzureをメインにインフラ系のご支援やPythonでコード書いたりを担当しています。
AWS13(全)冠、Azure13冠
Credly

Amazon FSxへのデータ移行をやってみる（step1）～オンプレADとAWS Managed Microsoft AD間の信頼関係構築～

AWS

こんにちは、株式会社エーピーコミュニケーションズ、クラウド事業部の松尾です。

はじめに
ゴール
環境
移行元環境へADサーバを構築
移行先環境へAWS Managed Microsoft ADを構築
- AWS Managed Microsoft ADのアウトバウンドルールを設定
- AWS Managed Microsoft ADのインバウンドルールを設定
移行元環境のADサーバで条件付きフォワーダー設定
移行元環境のADサーバで信頼関係設定
移行先環境のAWS Managed Microsoft ADで信頼関係設定
- 「検証済み」にならない場合
はまりポイント
まとめ
おわりに

はじめに

この記事は以下の手順を紹介する内容となっています。

これから5回に分けてFSxへのデータ移行を構築していきたいと思います。本記事ではNo1を紹介します。

オンプレミスのADとAWS Managed Microsoft AD間に双方向の信頼を設定する
ADMT等のツールでユーザーアカウントとグループを移行する
ファイルサーバー上のアクセス権限であるAccess Control List（ACL）を複製する
移行先へAmazon FSxを作成する
AWS DataSyncを利用し、既存のACLを保ったままファイルとフォルダをAmazon FSxに移行する

ゴール

移行元環境にEC2をADサーバとして構築
移行先環境にAWS Managed Microsoft ADを構築
AD間で双方向の信頼関係を構築

環境

移行元環境を疑似オンプレ環境と見立ててADサーバを構築していきます。

移行元環境へADサーバを構築

基本的な手順はAWS公式ドキュメントに沿っていきます。

EC2へADサーバ構築の手順は単純にADサーバ機能有効化、になるので割愛します。

移行先環境へAWS Managed Microsoft ADを構築

ディレクトリサービスのセットアップ

AWS Managed Microsoft ADを選択

DNS名は移行後環境のドメイン名を入力

管理者ユーザ（Admin）のパスワードを設定

VPCとサブネットを選択し、作成を進める

AWS Managed Microsoft ADのアウトバウンドルールを設定

参考作成したらセキュリティグループを設定していきます。 AWS Managed Microsoft ADの「ディレクトリID」をコピーして、セキュリティグループ内で検索します。このセキュリティグループはAWS Managed Microsoft AD作成時に自動作成されたものになります。初期状態では自身のセキュリティグループ宛てのみ許可されており不十分なので、通信先に移行元環境を追加します。詳しくはこちら

AWS Managed Microsoft ADのインバウンドルールを設定

インバウンドルールは自動作成されたままの状態で問題ありません。

移行元環境のADサーバで条件付きフォワーダー設定

AWS Managed Microsoft ADのドメイン名に対しては、自身のドメインコントローラではなくAWS側のDNSサーバに問い合わせさせるため、条件付きフォワーダーを設定していきます。

AWS Managed Microsoft ADのDNS名とDNSアドレスを控える

サーバマネージャ＞ツール＞DNS

DNSサーバを指定して新規条件付きフォワーダー

AWS Managed Microsoft ADのDNS名とDNSアドレスを設定する
「このドメインのすべてのDNSサーバー」を選択する

移行元環境のADサーバで信頼関係設定

参考

今回は双方向の信頼を設定していきます

新しい信頼ウィザードで設定していく

最後まで完了した状態

移行先環境のAWS Managed Microsoft ADで信頼関係設定

ディレクトリから信頼関係を作成していく

移行元ADの情報を設定していく

「追加」をクリックし暫く待つとステータスが「検証済み」になることを確認

「検証済み」にならない場合

以下の可能性が考えられます。

パラメータが正しくない
移行元ADと移行先AD間で疎通が出来ていない

私は一度目では失敗し、セキュリティグループ設定が足りないことが原因でした。

はまりポイント

今回のはまりポイントは2点 * 移行元ADサーバのセキュリティグループに移行先ADを許可すること * ピアリング設定でDNS解決を相互に許可すること

私はこの２点でつまづきました。

まとめ

今回はAD信頼関係構築までやってみました。
AWS Managed Microsoft AD側の信頼関係の設定もマネジメントコンソールで完結するので分かりやすいですが、AD間の通信設定が多いのは手間がかかるポイントでした。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

【CloudFormation】初めてのマルチアカウント環境でStackSetsを簡単に試してみる

AWS CloudFormation 検証

こんにちは！クラウド事業部の中根です。

最近マルチアカウント環境を始めて、いろいろ試しています。
今回は、CloudFormationのStackSetsをご紹介します！
AWS認定でも出題されますし、とても簡単なので、初めてやるのにぴったりだと思います！

StackSetsとは
前提条件
1. StackSetsのテンプレート作成
2. StackSetsの作成
3.メンバーアカウントをOUに追加
お掃除
まとめ
お知らせ

StackSetsとは

分かりやすい解説記事が他にたくさんありますので、ここでは超簡単に説明します。
Organizations内の設定したアカウントやOUに対し、同じスタックを自動で適用してくれる機能です。

前提条件

組織構成は以下です。
作り方はこちらの記事で紹介しているので、実際に動かす方は参考にしてください！

1. StackSetsのテンプレート作成

まずは、テンプレートファイルを準備します。
今回はお手軽さ重視で、S3バケットを作成します。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudFormation StackSets Sample Template: S3 Bucket Creation'

Resources:
  SampleS3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: !Sub '${AWS::AccountId}-sample-bucket'

2. StackSetsの作成

管理アカウントで作業していきます。
管理アカウントに切り替えたら、CloudFormationにアクセスします。
左メニューから、「StackSets」を使用し、「StackSetを作成」を押下します。

必要項目を入力していきます。

アクセス許可：「サービスマネージドアクセス許可」
テンプレートの準備：「テンプレートの準備完了」

テンプレートをアップロードし、「次へ」を押下します。
（S3バケットに格納して参照してもOK）

StackSet名と説明を入力して、「次へ」を押下します。

任意でタグと実行設定をして、「次へ」を押下します。
マネージド型の実行をアクティブにしたほうが若干早いと思いますが、今回はそんなに変わらないので、どっちでもいいです。

今回は、OU単位のデプロイを試してみます。
OU IDを、Organizationsの画面から確認し、コピーします。（画像赤丸部）

デプロイターゲットを「組織単位（OU）へのデプロイ」にし、OU IDをペーストします。

そのほかは任意で設定し、「次へ」を押下します。
最後に設定を確認して、「作成」します。

「スタックインスタンス」タブから、作成状況が確認できます。

Deployment OUのメンバーアカウントから、AWSアカウントIDをプレフィックスとしたバケットが作成されていることを確認してみましょう。
そして、Security OUのメンバーアカウントには作成されていないはずです。

3.メンバーアカウントをOUに追加

メンバーアカウントを後からOUに追加しても、ちゃんと作成してくれるのか確かめましょう。
※実施前に、管理アカウントから、スタックセットの自動デプロイがアクティブになっていることを確認してください。

注意：デフォルトのアカウント上限が10なので、余裕がない人は注意しましょう。
　　　既にあるアカウントのOUを移動させても同じことが確認できます。

メンバーアカウントの作成

Organizationsの画面に遷移し、「AWSアカウントを追加」を押下します。

アカウント名とメールアドレスを設定して、「AWSアカウントを作成」します。

シングルサインオンの設定（任意）

続いて、IdentityCenterの設定をして、アカウント切替を楽にします。
IAM Identity Center の画面に移動し、左メニューから「AWSアカウント」を選択します。
作成したアカウントを選択し、「ユーザーまたはグループを割り当て」を押下します。

グループと許可セットを設定します。

検証前の確認

新しいメンバーアカウントに切り替えて、S3バケットがまだ作られていないことを確認します。
まだOUに所属していないので、ないはずです。

いざ検証！

再び管理アカウントに切り替え、新しいメンバーアカウントをスタックセットが設定してあるOUに移動します。
Organizationの画面を開き、新しいメンバーアカウントを選択し、「アクション」＞「移動」を押下します。

OUを選択して、「AWSアカウントを移動」します。
（スタックセットで指定しているOUにすること）

OUにアカウントが追加されていることを確認します。

CloudFormationのスタックセットの「スタックインスタンス」を確認すると、一つ増えているのが確認できます。
オペレーションIDからも、新たな別の操作でスタックが作成されたことがわかります。

新しいメンバーアカウントに切り替え、S3バケットを直接確認してみます。

お掃除

管理アカウントから、CloudFormationのStackSets画面に移動します。

スタックセットを選択し、「StackSetsからスタックを削除」を押下します。

AWS OU IDにスタックセットを適用したOUのIDを入力し、「次へ」を押下します。

内容を確認し、「送信」を押下します。
スタックインスタンスを確認し、空になっていることを確認しましょう。

参考：S3バケットにオブジェクトが残っていたため、削除できなかった場合

スタックインスタンスが空になっていることを確認したら、「アクション」＞「StackSetの削除」を押下します。

CloudFormationのテンプレートが格納されているS3バケットも不要であれば忘れずに消しておきましょう。

まとめ

マルチアカウント環境で、CloudFormationのStackSetsを試してみました。
とってもお手軽に試せるので、マルチアカウントでの初検証にいかがでしょうか。
皆様の参考になれば幸いです。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: r-nakane
AWSをメインにインフラ系のご支援を担当しています。

【初心者向け】マルチアカウントでCloudTrailログを集約するまで

AWS CloudWatch 検証

こんにちは！クラウド事業部の中根です。

AWS認定のSAPやSCS等で、組織内アカウントのCloudTrailログを1つのアカウントに集約して通知する、みたいな構成をよく見かける気がします。
なんとなくイメージはできるのですが、理解を深めるため、実際にやってみました！
画面キャプチャ多めでお届けするので、実際作業するのはちょっと、、、という方にも参考になれば幸いです！

前提条件
1. CloudTrailの設定
2. CloudWatch Logsの有効化
3. お掃除
まとめ
お知らせ

前提条件

組織構成は以下です。
作り方はこちらの記事で紹介しているので、実際に動かす方は参考にしてください！

続いて、作成する構成のイメージ図です。

1. CloudTrailの設定

組織の管理アカウントに集約するパターンと、組織内のログ用メンバーアカウント（ログアカウント）に集約するパターンがあります。
今回は、ログアカウントに集約するパターンをご紹介します。
組織の管理アカウントに集約するパターンより手順が少し複雑になるので、こちらができれば両パターンに対応できるかと思います。

1-1. CloudTrailの有効化

Organizationsを開き、左メニューから「サービス」を押下します。
一覧から「CloudTrail」を探して、押下します。

「信頼されたアクセスを有効にする」を押下します。
画像だと既に有効になっていますが、最初は無効になっています。

「信頼されたアクセスが有効」になっていることを確認しましょう。

1-2. 委任された管理者を追加

CloudTrailの委任された管理者を設定します。
デフォルトだと、組織のCloudTrail証跡を作成したりするのは、管理アカウントしかできません。
委任された管理者に設定することで、ログアカウントでもそれらの操作が可能になります。
管理アカウントのまま、CloudTrailに移動し、左メニューから「設定」を押下します。

「管理者を登録」を押下します。

ログアカウントのIDを入力して、「管理者を登録」を押下します。

アカウントが追加されていることを確認しましょう。

1-3. ログ集約バケットの作成

ここからは、ログアカウントに切り替えて作業を行います。
S3を開き、「バケットを作成」を押下します。

バケット名を入力し、「バケットを作成」を押下します。
その他はデフォルトのままにしています。
お試しではないなら、暗号化等をしっかり設定しましょう。

1-4. 証跡の作成

CloudTrailの画面を開き、左メニューから、「証跡」を押下します。

「証跡の作成」を押下します。

証跡の設定をして、「次へ」を押下します。

証跡名：任意
組織内のすべてのアカウントについて有効化：ON
ストレージの場所：既存の S3 バケットを使用する
証跡ログバケット名：作成したログバケット名を入力
プレフィックス：任意（下に出力例が出ます）
ログファイルの SSE-KMS 暗号化：任意（実運用ならONですが、お試しだけならOFFがおすすめ）
ログファイルの検証：任意
SNS 通知の配信：任意
CloudWatch Logs：そのままでOK（後述）

ログイベントの選択をして「次へ」を押下します。
今回の手順では、デフォルトの管理イベントだけでOKです。
いろいろ試したいなら、データイベント等をONにすることを検討しましょう。

設定内容を確認して、「証跡の作成」を押下すると、証跡が作成されます。
表示されない場合は、更新してみましょう。

ログバケットを確認してみましょう。
黒く塗ってますが、組織の各アカウントIDでフォルダが分かれています。
（反映までやや時間がかかるかもしれません）

2. CloudWatch Logsの有効化

ログ集約はできましたが、通知機構を作ったり、コンソール上で簡単にログを見られるようにするため、CloudWatch Logsを有効にしてみます。
先ほどの証跡の設定画面では、グレーアウトしていて、設定ができませんでした。
これは、コンソールからは、管理アカウントからでないと有効にできないからです。

管理アカウントのみが、コンソールを使用して組織の証跡の CloudWatch Logs ロググループを設定できます。委任管理者は、 AWS CLIまたは CloudTrail CreateTrail UpdateTrail API オペレーションを使用して Logs CloudWatch ロググループを設定できます。
引用元：https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/creating-an-organizational-trail-in-the-console.html

引用に従い、CLIを使って設定します。
下準備として、ロググループとIAMロールの作成が必要です。
ついでにCLIで作った方がスマートですが、わかりやすさ重視でコンソール操作で解説します。

2-1. ロググループの作成

CloudWatchに移動し、左メニューから「ロググループ」を押下し、「ロググループを作成」を押下します。

ロググループ名を設定し、「作成」を押下します。

ロググループのARNは後で使います。

2-2. IAMロールの作成

IAMに移動し、左メニューから「ポリシー」を押下し、「ポリシーの作成」を押下します。

ポリシーエディタをJSONに切り替え、以下のJSONを張り付けます。（こちらを元に作成）
各値は環境に合わせて修正してください。（管理アカウントIDと委任された管理アカウントIDの違いに注意）
組織のIDは、Organizationsのダッシュボードから確認できます。（下に画像付）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailCreateLogStream20141101",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream"
            ],
            "Resource": [
                "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織の管理アカウントID>_CloudTrail_ap-northeast-1*",
                "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織のID>_*"
            ]
        },
        {
            "Sid": "AWSCloudTrailPutLogEvents20141101",
            "Effect": "Allow",
            "Action": [
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織の管理アカウントID>_CloudTrail_ap-northeast-1*",
                "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織のID>_*"
            ]
        }
    ]
}

組織のID

ポリシー名をつけて、「ポリシーの作成」を押下します。

続いて、左メニューから「ロール」を押下し、「ロールを作成」を押下します。

「カスタム信頼ポリシー」を選択し、下の欄に下記のJSONを張り付け、「次へ」を押下します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

先ほど作成したポリシーを選択し、「次へ」を押下します。

ロール名をつけて、「ロールを作成」を押下します。

ロールのARNは後で使います。

2-3. 証跡のCloudWatch Logsの有効化

CloudShellでCloudWatch Logsを有効にします。
CloudShellを開き、以下のコマンドを実行します。

aws cloudtrail update-trail \
        --name <証跡名> \
        --cloud-watch-logs-log-group-arn <ロググループのARN> \
        --cloud-watch-logs-role-arn <IAMロールのARN>

「An error occurred (TrailNotFoundException) when calling the UpdateTrail operation: Unknown trail」というエラーになってしまった場合、以下のコマンドを実行します。

aws cloudtrail describe-trails

出力された証跡情報のTrailARNを、<証跡名>に置き換えて再度実行します。

他のエラーが出た場合は、エラーメッセージを読んで、コマンドの各ARNや、IAMポリシーのResourceが正しいかを確認しましょう。
私はIAMポリシーのResourceに謎のコロンが入っていて、ハマりました。。。（InvalidCloudWatchLogsLogGroupArnExceptionのAccess Denied）
CloudTrailのイベント履歴から、より詳細な情報を拾うこともできます。

成功すると、証跡のロググループとIAMロールが設定できたことが確認できます。

CloudWatch Logsのロググループを確認すると、各アカウントのログストリームができていることが確認できます。
<組織ID><アカウントID>CloudTrail～という形式になっています。

2-4. 動作確認

せっかくなので、他のアカウントでのイベントがCloudWatch Logsから見れることも確認してみます。
別のメンバーアカウントに切り替え、S3バケットを作成します。

バケットを作成しました。

ログアカウントに戻ります。
作業をしたアカウントのログストリームを見てみます。

検索窓に「CreateBucket」と入力すると、S3バケットを作成した時のログが出力されています。

出てこない場合は、少し待つか（15分以内には連携されるはず）、他のログストリームも確認してください。
今回はここまでにしますが、メトリクスフィルターを使った通知や、サブスクリプションフィルターを使ったLambda呼び出しなど、いろいろ試してみてください！

3. お掃除

動作確認したアカウント

動作確認で使ったS3バケットを削除します。

ログアカウント

CloudTrailの画面を開き、左メニューから「証跡」を選択します。
作成した証跡を選択し、「削除」を押下します。

S3で、ログバケットを空にしてから、削除します。

CloudWatchのロググループも削除します。

作成したIAMロールとIAMポリシーも削除します。
ログバケットを作成した時など、KMSキーを作成していた場合は、KMSキーの削除も忘れずにしましょう。

管理アカウント

任意ですが、委任された管理アカウントの削除がしたい場合は、管理アカウントから行ってください。

まとめ

今回は、AWS認定試験でよく見る構成を実際に試してみました。
コンソールからだと有効化できなかったり、IAMポリシーの設定で少しハマったりと、地味な苦戦ポイントがあって勉強になりました！
皆様の参考になれば幸いです！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: r-nakane
AWSをメインにインフラ系のご支援を担当しています。

【AWS Organizations】意外と簡単！個人で始めるAWSマルチアカウント入門

AWS 検証

こんにちは！クラウド事業部の中根です。

AWS認定試験を受けていると、マルチアカウントの構成をよく見かけますよね。
実際に触ってみたいけど、なんだか難しそう、めんどくさそう、というイメージを持っている方も多いのではないでしょうか。
そんなイメージを払拭すべく、個人用マルチアカウントの始め方をステップバイステップで解説します！

所要時間
1. AWS Organizationsでマルチアカウントを構成する
2. IAM Identity Centerを使ってシングルサインオンを実現する
番外編
まとめ
お知らせ

所要時間

30分～1時間程度

1. AWS Organizationsでマルチアカウントを構成する

今回作るマルチアカウントの構成図はこちらです。

1-1. 組織の管理アカウント、組織の作成

まずは、組織の管理アカウントとなるAWSアカウントを作ります。
（AWSアカウント開設リンク：https://portal.aws.amazon.com/billing/signup#/start/email）

AWSアカウントができたら、ルートユーザーでログインします。
AWS Organizationsの画面を開き、「組織を作成する」を押下します。
あっけないですが、これだけ組織が作成されます！
ここから、メンバーアカウントや組織単位(OU)を追加していきます。

今のイメージ図です。

1-2. メンバーアカウントの作成

メンバーアカウントを作成します。
「AWSアカウントを追加」を押下します。
新規でAWSアカウントを作成します。（既存アカウントの追加も可能）
任意のAWSアカウント名、メールアドレスを入力します。

メールアドレスについて

こちらは任意ですが、Gmailのエイリアス機能が便利なので、簡単にご紹介します。
通常、アカウント毎にメールアドレスを準備する必要があり、今回の手順を行うと最低4つ必要になり、管理も作成も面倒です。
エイリアス機能を使うことで、異なるメールアドレスを、1つのメールアドレスに集約できます。
使う方法は、メールアドレスの「@」の前に「+<任意文字列>」を付けるだけです。
Gmail側での設定等も不要です。（受信ボックスを分けたい場合等は設定が必要）
例えば、ルートユーザーのメールアドレスが、「rootuser@gmail.com」であれば、「rootuser+devAccount@gmail.com」とします。
「rootuser+devAccount@gmail.com」宛のメールは、「rootuser@gmail.com」に届きます。
さらに詳細はこちらをご覧ください。

注意点として、組織のアカウントはデフォルトで10個までです。
一応、アカウントの上限はAWSへの申請をすれば増やせます。
アカウントを閉鎖すればまた増やせますが、閉鎖も30日間で10個までしかできないので、ご注意ください。
その他にも制限がありますので、詳しくはこちらを参照してください。

1-3. 組織単位(OU)の作成

RootのチェックボックスをONにし、アクションタブを展開し、「新規作成」を押下します。

任意の組織単位名を入力し、作成します。

今のイメージ図です。
メンバーアカウントはOUではなく、ルートに紐づいている状態です。

1-4. メンバーアカウントをOUへ移動

続いて、先ほど作成したアカウントをOUに移動します。
作成したメンバーアカウントのチェックボックスをONにし、アクションタブから、「移動」を選択します。

所属させたいOUを選択し、「AWSアカウントを移動」します。

すると、Developmentの配下にアカウントが移動しました。

今のイメージ図です。

1-5. 練習

1-2. ～ 1-4.の手順をなぞって、さらにメンバーアカウントとOUを作ってみましょう。
「メンバーアカウント名：log-account」、「OU名：Security」とした場合、以下のようになっていれば、最初の図の構成が完成です！

最終的な構成図がこちらです。

2. IAM Identity Centerを使ってシングルサインオンを実現する

マルチアカウントを作れたのは良いですが、このままだと少し面倒です。
各アカウント毎に管理IAMユーザーを作っておいて、各管理IAMユーザーに切り替えて作業する必要があります。
必須ではないですが、1つの認証情報で、各アカウントに簡単にアクセスできるようにしましょう！

IAM Identity Centerの仕組みがよくわからないという方は、これからの作業と合わせて、以下の記事で予習or復習するのもおすすめです！
AWS SSOを図解してみた | DevelopersIO

最終的にこれが

こうなります！

2-1. ユーザーの作成

管理アカウントで、IAM Identity Centerのサービス画面に移動します。
リージョンを確認して、「有効にする」を押下します。

続いて、左のメニューから、「ユーザー」を選択し、「ユーザーを追加」を押下します。

プライマリ情報を入力し、「次へ」。
今回メールアドレスはメンバーアカウントと同様にエイリアスを使っています。

グループの作成は次のステップで行うので、何もせず「次へ」を押下します。
登録内容を確認して、「ユーザーを追加」すると、ユーザーが追加されています。

登録したメールアドレスに以下のようなメールが来るので、「Accept invitation」を押下します。

新しいパスワードを設定し、そのままログインします。
ユーザー名は、メールの一番下にも記載されています。（表示名とは違うので注意）
MFAの設定を行い、このような画面になればOKです！

2-2. グループの作成

管理アカウントの、IAM Identity Centerの画面に戻ります。
左メニューから、「グループ」を選択し、「グループを作成」を押下します。

グループ名を入力し、グループに追加したいユーザーを選択し、「グループを作成」します。

グループが作成され、ユーザーが追加されていることを確認します。

2-3. 許可セットの作成

左メニューから、「許可セット」を選択し、「許可セットを作成」を押下します。

今回は事前定義された許可セットの、「AdministratorAccess」を作成します。

他の設定はデフォルトのままにしました。

2-4. ユーザー/グループ×許可セットの割り当て

作成したユーザー/グループと許可セットを、アカウントに割り当てます。

左メニューから、「AWSアカウント」を選択します。
まとめて管理したいアカウントのチェックをONにして、「ユーザーまたはグループを割り当て」を押下します。
今回は、組織内の全アカウントを集約したいので、すべてのアカウントにチェックを入れました。
（dev2-memberが増えているのは無視してください。）

グループにチェックを入れ、「次へ」を押下。
今回は既にグループにユーザーを所属させているのでこれだけですが、個別でユーザーを割り当てたりもできます。

許可セットにチェックを入れ、「次へ」を押下。

内容を確認して、「次へ」を押下すれば完了です。
割り当てたグループと許可セットのアカウントタブから、それぞれアカウントが登録されていることを確認しましょう。
手順通りにやっていれば、画像とは少し違って、org-account、log-account、dev-memberの3つになっていると思います。

グループの確認

許可セットの確認

2-5. アクセスポータルにログインしてみる

左メニューの「設定」から、アクセスポータルのURLを確認できるので、アクセスします。
ちなみにURLは、画像右中央のアクションから変更が可能です！（１回のみ）

ログイン画面が出た場合は、先ほど作ったユーザーでログインします。

アクセスポータルが表示され、１つの認証情報で、各アカウントへのアクセスが可能になりました！（シングルサインオン）

アクセスしたいアカウントを展開して、許可セットのリンクを押下することで、アクセスできます。

アクセスすると、アカウントIDが、アクセスしたアカウントのものになっていることも確認できます。

番外編

ここで作ったマルチアカウントを使って、AWS認定試験でよく見る構成を試してみました。
こちらも参考になれば幸いです。

techblog.ap-com.co.jp

※組織内のアカウントでは、無料枠が共有されることに注意しましょう。

Organization（AWS Organization に基づく）は、Organization の 1 つのアカウントからのみ本オファーの特典を受けることができ、本オファーに基づく Organization による AWS サービスの使用量を計算するため、アマゾンは、Organization の全てのアカウントの使用量を総計します。

引用元：AWS 無料利用枠規約

まとめ

個人利用向けに、マルチアカウントの設定方法を紹介しました。
皆様の学習や、個人開発に役立てば幸いです。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: r-nakane
AWSをメインにインフラ系のご支援を担当しています。

2024-04-10

【入門・初心者向け】AWS Backup の基本設定方法

AWS Backup クラウド Cloud AWS Backup 検証

はじめに

こんにちは、エーピーコミュニケーションズクラウド事業部の高橋です。

２本目のブログは、AWS Backup の基本的な設定方法について、実際にバックアップを作成しながら書いてみたいと思います！
また、AWS Backup が利用できるサービスやバックアップ周期などにも簡潔に触れてみたいと思います！
どうぞよろしくお願いします！

どんなひとに読んで欲しい

AWS Backup の概要を知りたい人
AWS Backup を実際に設定したり実装してみたい人

AWS Backup の基本的な設定方法

今回のブログでは、特定の EC2 を AWS Backup を使用してバックアップする基本的な設定方法をいちから検証してみたいと思います！

① バックアップボールトの作成
「バックアップボールト」とは、バックアップしたデータを保存するコンテナです。(「ボールト (vault)」は "倉庫" という意味です)
まずは、そのバックアップボールトから作成していきます！

AWS のコンソール上から AWS Backup に移動し、左側のナビゲーションバーの「バックアップボールト」から「バックアップボールトを作成」をクリックしてください。

バックアップボールトの作成画面に遷移しましたら、バックアップボールトの名前と暗号化キーを設定します。
暗号化キーは保存したバックアップデータを暗号化して保護する際に使うキーです。
今回は AWS Backup が使用するデフォルトの暗号化キーを選びます。(選択した暗号化キーはバックアップボールトの作成後から変更することはできませんので注意してください！)
バックアップボールトの名前と暗号化キーを設定したら、右下の「バックアップボールトを作成」をクリックしてください。

すると、以下のようにバックアップボールトが作成されたことが確認できます！

② バックアッププランの作成
次に、バックアッププランを作成していきます。
ナビゲーションバーの「ダッシュボード」から「バックアッププランを作成」をクリックしてください。

バックアッププランの作成画面に遷移しました。
今回は、基本的な AWS Backup の設定ということで「新しいプランを立てる」から設定していていきたいと思います。
まず、バックアッププランの名前を設定します。

続いて、バックアップルールの項目では、バックアップルールの名前、バックアップボールトの指定、バックアップ頻度、バックアップ期間などを設定していきます。
先ほど作成したバックアップボールトを指定します。
また、今回の検証では、バックアップ頻度を「毎時」で設定し正常にバックアップが取得できるか確認していきたいと思います。

バックアップ頻度を「毎時」で設定する場合、バックアップ期間における「開始時間」について少し注意が必要です！
「毎時」を設定されるということは、１日に２４回のバックアップを取得することを想定されるかと思います。
しかし、以下の画像の黄色下線の内容のとおり、「開始時間」は１日のなかでの初回バックアップが開始される時間の設定です。
したがって、１日に２４回のバックアップを取得したい場合は、「開始時間」を「００時台」で設定しておかないと「００時台～２３時台」の計２４回のバックアップが取得できなくなりますので、注意してください！

また、「次の時間以内に開始」とは、「開始時間」から指定した期間中にバックアップを開始する時間を設定します。
上の画像を例にいうと、１時間以内に何かしらの要因でバックアップが開始しなかった場合、その回のバックアップは期限切れでエラーとなります。
「次の時間以内に完了」も同様に、バックアップが開始して指定した時間や日にちの期間中にバックアップが完了しなかった場合、その回のバックアップは期限切れでエラーとなります。

続いて、バックアップを保持する期限を設定します。
(基本的な設定方法の検証のため、ポイントインタイムリカバリとコールドストレージについては設定しません)

以上の設定が完了しましたら、右下の「プランを作成」をクリックしてください。
なお、バックアップするリソースの割り当てはプラン作成後に実施します。
また、作成した１つのバックアッププランに対して、バックアップルールを追加したり、バックアップ対象リソースを追加することもできます。

すると、以下のようにバックアップルールが作成されました！

③ リソースの割り当て
続いて、バックアップしたいリソースをバックアッププランに対して割り当てたいと思います！
作成したバックアッププランを選択し、「リソースを割り当てる」をクリックしてください。

リソース割り当ての名前とバックアップ (ここでは「復旧ポイント」と呼ばれます) 作成・管理についての IAM ロールを設定します。
今回は AWS Backup が使用するデフォルトの IAM ロールを選びます。

続いて、割り当てるリソースを選択します。
今回は特定の EC2 のバックアップを取得する検証ですので「特定のリソースタイプを含める」を選択します。
そうすると、特定のリソースを入力できる項目が表示されるので、リソースタイプとリソース ID を入力します。
※ 「すべてのリソースタイプを含める」についても後述で少し触れたいと思います

以降は、今回の検証には必要ないオプションなので、そのまま「リソースを割り当てる」をクリックします。

すると、リソースの割り当てが正常に作成されたことが確認できました！

④ バックアップジョブの動作確認
これで今回の検証のための作成や設定は完了したので、実際にバックアップジョブが動作して正常に完了するか確認したいと思います！

今回の検証では、毎時１５分でバックアップを取得するように設定をしました。
以下の画像のように、14:15 時点でバックアップジョブの状況を確認したところ・・・「作成済み」のステータスとなっていました！
※ 厳密にいうと、「作成済み」のステータスでバックアップジョブが表示されたのは 14:18 頃だったので設定時間から３分ほど経過して表示されました (14:15 を過ぎてもバックアップジョブが画面に表示されなかったので少し焦りました・・)
このステータスはバックアップジョブ自体が作成されたという状態を示していると思われます。

「作成済み」のステータスから１０分ほど経過し・・・ようやくステータスが「実行中」に変化しました。

そして、「実行中」のステータスからさらに２０分ほど経過し・・・ついにステータスが「完了」となり、メッセージカテゴリが「成功」となりました！

指定した保存先のバックアップボールトにも、復旧ポイントとしてバックアップが作成されていることを確認できました。

これにて、AWS Backup を使用したバックアップの取得は正常に完了することができました！

AWS Backup に関する補足

上述した基本的な設定方法以外にも、AWS Backup について確認できた内容を補足として記載してみたいと思います。

① EC2 のインスタンス状態
上述した検証では、EC2 のインスタンス状態は「停止済み」で行いました。
すなわち、EC2 が停止していても AWS Backup は問題なく動作することを確認できました。
もちろん、EC2 のインスタンス状態が「実行中」でも動作することは確認できています。

② 「すべてのリソースタイプを含める」について
リソースの割り当ての項目で少し触れました「すべてのリソースタイプを含める」について記載します。
「すべての～」となると、やはり選択することを躊躇しがちです・・・。
今回は検証できませんでしたが、以下の AWS 公開ドキュメントを確認するかぎり、やはりすべてのリソースタイプがバックアップされるようです。
ステップ 2: バックアッププランにリソースを割り当てる - AWS Backup

このバックアッププランでは、 AWS Backup を使用して保護するためにオプトインしたすべてのリソースタイプが保護されるようになりました。

備考
「オプトイン (opt in)」とは“参加する”とか“加入する”という意味で、「すべてのリソースタイプを含める」では AWS Backup 対象に「オプトイン」しているサービスがバックアップの対象となります。
AWS Backup における対象サービスのオプトインは、ナビゲーションバーの「設定」から有効 / 無効にて設定できます。

ただし、「すべてのリソースタイプを含める」ではタグを使用することでバックアップ対象のリソースを絞り込めるので・・・
・「すべてのリソースタイプを含める」は、タグベースでリソースを絞り込み
・「特定のリソースタイプを含める」は、特定のリソースタイプやインスタンス ID でリソースを絞り込み
所感として、このような使い分けをしてリソースの割り当てを柔軟に設計するものと思いました。

※ 以下の画像でいうと、タグのキーと値が同じタグが付与されているリソースを対象としてバックアップされます。

加えて、「特定のリソースタイプを含める」にて特定のリソースタイプやインスタンス ID を設定する場合、(一部サービスを除いて) オプトインが無効であってもバックアップは動作することを検証で確認しました。
また、その内容について AWS 公開ドキュメントにも記載がありましたので載せておきます。
開始方法 1: サービスオプトイン - AWS Backup

リソースタイプがバックアッププランに明示的に割り当てられている場合、その特定のサービスに対してオプトインが有効になっていない場合でも、そのリソースタイプはバックアップに含まれます。これは、Aurora、Neptune、Amazon DocumentDB には適用されません。これらのサービスを含めるには、オプトインを有効にする必要があります。

③ バックアップの頻度
バックアップの頻度にも触れてみたいと思います。
「バックアップ頻度」としては１時間ごと、１２時間ごと、毎日、毎週、毎月の頻度で選択できます。
また、cron 式を用いて詳細な日時や曜日を設定できますが、AWS Backup ではバックアップジョブの頻度を６０分未満で設定することはできません。
※ 以下の画像のように、１５分頻度の cron 式でバックアップルールを作成しようとしたところエラーとなりました。

④ バックアップの保持期間
次に、バックアップの保持期間に触れてみたいと思います。
AWS Backup のバックアップルールで設定できるバックアップの保持期間については２種類あります。

・通常のバックアップ保持期間
特段名称があるわけではないですが・・・通常のバックアップ保持期間があります。
最短で１日、最長で永続を設定できるため、AWS Backup における通常バックアップ保持期間の世代制限はありません。

・ポイントインタイムリカバリの保持期間
もう１つは、ポイントインタイムリカバリ (PITR) を有効にする場合です。
一部限定されたサービスのみですが、ポイントインタイムリカバリを利用してバックアップを取得することにより１秒単位で特定の時刻を指定して復元することができます。
ポイントインタイムリカバリの保持期間は、最短で１日、最長で３５日を設定することができます。

上記の画像のとおり、ポイントインタイムリカバリを利用できるサービスは以下に限られていますので、注意してください！
・Aurora
・Amazon RDS
・Amazon S3
・SAP HANA on Amazon EC2

実際にポイントインタイムリカバリを有効にして Amazon S3 をバックアップしてみたところ、以下のように秒単位で指定して復元することが可能となります。

⑤ AWS Backup の対象サービス
先ほど上述しましたオプトインの対象となるサービス、すなわち AWS Backup の対象サービスを改めて記載しておきたいと思います！

・Amazon Aurora
・Amazon DocumentDB
・Amazon DynamoDB
・Amazon Elastic Block Store (Amazon EBS)
・Amazon Elastic Compute Cloud (Amazon EC2)
・Amazon Elastic File System (Amazon EFS)
・Amazon FSx
・Amazon Neptune
・Amazon Redshift
・Amazon Relational Database Service (Amazon RDS)
・Amazon Simple Storage Service (Amazon S3)
・Amazon Timestream
・AWS CloudFormation
・AWS Storage Gateway
・SAP HANA on Amazon EC2
・VMware CloudTAK on AWS
・VMware CloudTAK on AWS Outposts

Amazon S3 はバージョニングを有効にする、SAP HANA はいくつかの前提条件がある等、サービスによっては AWS Backup を利用するための条件があるので、オプトインのコンソール画面や AWS 公式ドキュメント等から対象サービスの条件を確認するのがよいと思います！

また、すべての対象サービスで利用できる AWS Backup の機能、一方、対象サービスやリージョンによっては利用できる機能 / 利用できない機能があります。
詳細については AWS 公式ドキュメントからぜひ確認してみてください！
すべてのサポートされているリソースで使用できる機能 - AWS Backup
リソース別の機能の可用性 - AWS Backup

⑥ AWS Backup の料金
最後に、AWS Backup の料金についても少しだけ触れたいと思います。
AWS Backup を利用するにあたっての初期費用は発生せず、以下３つの利用状況に対して月単位で従量課金されます。

・バックアップストレージ量
・バックアップから復元したバックアップデータ量
・別リージョン (クロスリージョン) へのバックアップ転送量

各サービスの料金については、以下のリンクから確認することができます。
AWS Backup の料金 | 一元化されたクラウドバックアップ | Amazon Web Services

備考
今回の検証では AWS Backup を利用して EC2 のバックアップを取得しましたが、上記の料金一覧には EC2 の項目はありません。
確認してみたところ、EC2 をバックアップした際に作成される復旧ポイントは、同じくバックアップした際に作成される対象 EC2 の Amazon Machine Images (AMI) をもとに復元されます。その AMI に紐づいた EBS ボリュームスナップショットも同様に、EC2 をバックアップした際に作成されます。
すなわち、AWS Backup を利用して EC2 のバックアップを取得する際は、EBS ボリュームスナップショットとして課金されることを確認できました。

■ 復旧ポイント

■ AMI

■ EBS ボリュームスナップショット

おわりに

今回は AWS Backup の基本設定方法を実際に検証し、その過程で確認できたことをまとめてみました！
実際に検証をしていくと思っていなかった疑問や確認が出てくるので、これからもできるだけ検証を交えたブログを作成していければと思いました！
今回もご拝読いただき、ありがとうございました！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

33 IT未経験者が参画4ヶ月で既存監視JP1を廃止しAWSサービスに移行する知られざる戦いの全貌 - YouTubewww.youtube.com

2024-04-09

一年ぶりに監視機能移行案件の振り替えりしてみた

AWS

はじめに

こんにちは、クラウド事業部の中嶋です。

今年の1月より現場が変わりばたばたしておりました・・・。

ふと落ち着いたときに過去にLT登壇した時の資料を眺めていたら、
丁度去年のこの時期に前の現場で取り組んだ案件を元に発表したスライドが出てきましたので、今回はそれを記事にしてみようと思います！
（´・ω・`).｡oO(ｲﾏｻﾗﾅﾝﾃｲﾜﾅｲﾃﾞ)

当時行った案件は、JP1という既存の監視システムをAWSのサービスに移行するといったものでした。
IT未経験で初めての現場に配属され、4か月目に担当させて頂いた案件で当時の事を振り返りながら、今の自分の視点で見えることを記事にできればと思います！

はじめに
読んでほしい方はこんな人！
案件の概要
実施内容
イベント登壇を通じて
当時を振り返った所感
まとめ
おまけ

読んでほしい方はこんな人！

今回の記事で扱う内容として、是非読んで頂きたい方は以下のような立場にいらっしゃる方と考えております！
⇒IT未経験で現場に参画された方
⇒AWSを扱っている方
⇒新卒の方
⇒経験が浅い方
⇒現場メンバーをマネジメントする方
⇒監視機能移行案件に携わっている方

私自身が冒頭にも記載した通り、IT業界に未経験で飛び込み右も左もわからない状態で、
案件一つを現場メンバーの力も借りながら完遂した時の体験になります。

ですので近しい立場になる、未経験で入社の方や新卒入社の方にはある種のしくじり先生のような感じで気軽に読んで頂ければと思います！
また、現場を管理される方には、経験の浅いメンバーが現場に配属された際、その方はどのようなことを考えているかをざっくり知ることができるかと思います。
技術面に関しても、イベント登壇に使用した資料を用いてわかりやすく説明できればと思っております。

案件の概要

今回の案件は、AWSサービスをメインで扱っている環境の監視機能（JP1）を移行するといったものでした。

↓のスライドが当時の既存環境です。本来は冗長構成ですが、今回の資料は登壇用というこもあり、割愛しておりますのでご了承ください。

Nagiosサーバと各環境内のサーバにインストールされたnrpe(Nagiosエージェント)と通信を行い、
エラーログを拾って、そのログを「notification.log」ファイルに格納します。

「notification.log」ファイルに格納されたエラーログをJP1が拾い、
そのログをメール文に乗せる際に成形＋エラーの種別を分けるために一意のIDを付与して所定のアドレスにメールを送付する。

といった構成になっておりました。
今回はJP1が担っていた4つの機能
・エラーログを拾う機能
・メール文の成形
・一意のIDを付与
・アラートメールの送信
をAWSサービスに置き換えるというものです。

実施内容

JP1からAWSサービスに移行した構成図が↑になります。
JP1の機能を、「Cloud Watch Logs」「Lambda」「S3」「SNS」の4つのサービスで補いました。

まず、Cloud Watch Logsを使用して、エラーログを収集します。
確かこの時（記憶が少しあいまいですが・・・）AWS Systems ManagerのRun Commandを実行してログ収集の設定を施しました。

そして、収集したエラーログをLambdaに引き渡すために、Cloud Watchのサブスクリプションフィルター機能を用いて、
エラーログ内の該当する文言をトリガーにLambdaに引き渡すように処理しました。

Lmbdaでは事前に作成したコードを用いて、引き受けたエラーログをメールに飛ばすにあたっての文章成型とメールに別途記載したい一意の文字列を付与します。

一意の文字列を付与するために、S3内にCSVファイルを格納しておきます。
CAVファイル内は、該当のエラーログと紐づけるために
「エラーログが吐き出されるパス」「エラーログ内の文章の一部（正規表現化）」「付与したい一意の文字列」を記載しておきます。

Lambdaの処理が走ったタイミングで、エラーログの成形＋一意の文字列付与が行われ、それがSNSに引き渡されます。

SNSはそれを受け、事前に設定した所定のメールアドレスにエラーメールを発砲するといった流れになります。

細かい実装手順については、以下の記事を参照するほうがより丁寧に記載されておりますので、
気になった方は以下をご確認ください！

イベント登壇を通じて

以上のことを実施しまして、その時の体験・苦労話をイベントに登壇することでアウトプットしました。
参加したイベントがCloud Operator Daysといったイベントでして、イベント登壇と言っても
事前に撮影したプレゼンをYouTube上にアップして期間内に視聴できるといったものです！

なので、撮り直しができる点はとても気持ちが楽でした！
（ここだけの話リテイク3~4回くらいしましたw）

今後イベントに登壇してみたい！けど人前でいきなり話すのは。。。
といった方は事前撮影系のイベントがあればそこから経験値を積むのもありかもしれませんね！

ちなみに、その時のスライドと映像が以下になります！！

speakerdeck.com

イベントはオフラインで、クロージングイベントが行われまして、初めてこういったイベントに参加させていただきました！
社外の方と生の交流をする機会が滅多とないので、非常に刺激的でためになりました！

セッションやKeynote、近年スポットを浴びている技術（この時は生成AIでした）についてのDiscussion、交流会と盛りだくさんの内容でした。
今年もイベントが開催されるようですので気になった方は↓をご覧ください！

Cloud Operator Days Tokyo - Cloud Operator Days Tokyo 2024cloudopsdays.com

当時を振り返った所感

率直に1年たった内容のものでしたが、意外と覚えてました！
初めての案件ということもあるかとは思いますが、やはりアウトプットしたことで
より記憶の深部分に刻まれている感覚ですね。

今まったく同じタスクに取り組んで、登壇するとなったらもう少し技術的な観点を深堀したことが書けたりするのかなと思いますね。
当時はとにかくタスクを進めていくのに必死で、案件が終わった後はその経験を文字に起こすのに必死だったのでね。

今の現場ではAWSは触ってはいないのですが、やっぱりAWSいいですねw

今の現場は様々なサービス（伏せておきますが。。）を使用しているので、
画面の移動や切り替えの回数が以前より多くなりその分時間を要してしまっている感覚があります。
その点AWSだとその周辺サービスで完結するので、特に未経験や経験が浅い方が触れ始めるのに適しているのではないかなと思いました。

まとめ

ここまで御覧いただきありがとうございます！！
拙い記事でしたが、いい振り返りができました。

・どこかのタイミングでの振り返りは大事
⇒過去の自分の取り組みが自信になる

・アウトプットしたら記憶に残る
⇒より人に伝えるように準備するため咀嚼回数が増える

この記事が未経験や経験の浅い方・新卒の方の微力になれば幸いです。
また、管理職の方はそういった方を優しくサポートできる一つの着眼点になればと思います。

おまけ

過去にAWS資格取得を行いまして、この時の体験も記事にしております。
資格取得にご興味がございましたら、こちらも是非読んでみてください！また、その他の記事も掲載しておきます！

【過去記事のURL】

techblog.ap-com.co.jp

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: 中嶋
AWSをメインにインフラ系のご支援を担当しています。

2024-04-09

Amazon FSxへのデータ移行をやってみる（step5）

AWS

こんにちは、株式会社エーピーコミュニケーションズ、クラウド事業部の松尾です。

はじめに
ゴール
環境
AWS DataSyncとは
DataSyncエージェントをデプロイ
サービスエンドポイントの選択
エージェントのアクティベーション
ロケーションの作成
- ソースロケーション
- デスティネーションロケーション
タスクの作成
データの移行
まとめ
おわりに

はじめに

この記事は以下の手順を紹介する内容となっています。

AWS DataSync転送の仕組み - AWS DataSync

前回までにNo4まで完了しています。本記事ではNo5を紹介します。

オンプレミスのADとAWS Managed Microsoft AD間に双方向の信頼を設定する
ADMT等のツールでユーザーアカウントとグループを移行する
ファイルサーバー上のアクセス権限であるAccess Control List（ACL）を複製する
移行先へAmazon FSxを作成する
AWS DataSyncを利用し、既存のACLを保ったままファイルとフォルダをAmazon FSxに移行する

ゴール

移行元環境のフォルダを移行先環境へ、フォルダのACLを保ったまま移行すること
移行手法はAWS DataSync
移行元環境はEC2に構築したSMB ファイルサーバ
移行先環境はAmazon FSx for Windows ファイルサーバー

環境

DataSyncAgentを移行元環境へ構築しアクティブ化を行ったのち、移行先環境へDataSyncを使ってデータを移行してみます。

AWS DataSyncとは

まず最初にDataSyncのアーキテクチャを再確認します。

AWS DataSync公式ドキュメント

によると、このような構成になります。

いくつか方法はありますが、今回DataSyncAgentはEC2として構築することにします。（移行元環境がAWSであるため）

DataSyncエージェントをデプロイ

ここからは以下を参考に実施していきます。

まずはDataSyncAgentのAMIからEC2を起動していきます。数字の新しいものを選択。

インスタンスタイプは2Xlarge以上が求められます。今回はリンク先で推奨されている「m5.2xlarge」にしてみます。

セキュリティグループは、

にインバウンド、アウトバウンドの要件がありますが、今回は検証のため、インバウンドに自端末からHTTP80の許可のみ設定し、アウトバウンドは全許可としました。 HTTP80の許可はDataSyncエージェントのアクティベーション時のみに必要で、アクティベーション後には不要になるため閉じることが推奨です。

サービスエンドポイントの選択

参考手順

今回はサービスエンドポイントは、「VPCエンドポイント」を選択してみます。

エンドポイントを作成していきます。

完成

エージェントのアクティベーション

AWS DataSync から「エージェントを作成」

パラメータを入力し「キーを取得する」
「エージェントのアドレス」はグローバルにIP到達性があることが必要そうで、EC2のプライベートIP プライベートIPでは失敗しました。今回はグローバルIPをパラメータとして進めています。

アクティベーションキーの取得に成功すると確認画面になります。エージェント名とタグを設定して「エージェントを作成する」

エージェント作成完了！

ロケーションの作成

参考手順

データを転送するには「タスク」という単位で行います。「タスク」は「ソースロケーション」から「デスティネーションロケーション」へ転送する形に設定していきます。

ソースロケーション

送信元の設定です。今回は移行元環境に構築した共有フォルダを設定します。
移行元環境にはSMB ファイルサーバを構築済みです。通信要件はこちらを参考にしてください。

「ロケーションを作成する」をクリック

パラメータを入力

パラメータ入力後、「ロケーションを作成する」をクリック

ソースロケーションの作成完了

デスティネーションロケーション

ソースロケーションと同様にデスティネーションロケーションも作成していきます。

ロケーションタイプにFSxを選択

ユーザーにはAWS Managed Microsoft ADのユーザを設定

タスクの作成

ソースロケーションとデスティネーションロケーションが作成できたので「タスク」を作成していきます。

「タスク」から「タスクを作成する」をクリック

作成したソースロケーションを選択

作成したデスティネーションロケーションを選択

タスク名の他は詳細パラメータです
今回はロギングを無効にしたのみで他はデフォルト値としました。

レビュー画面で内容を確認し「タスクを作成する」をクリック

データの移行

タスクの「アクション」から「開始」をクリックして開始する

ステータスが実行中に遷移

タスクが完了後、「履歴」から実行結果を確認する

今回は3ファイルだけだったので参考にならないがデータ転送パフォーマンスも確認可能

移行先のEC2でマウントしたファイルサーバ（FSx）にフォルダが移行されていることが確認できた

ファイル権限エラー

事象

移行後のフォルダへアクセスしようとするとエラーになってしまった。
フォルダのACL設定なのかDatasync設定なのか、別途調査予定。

原因

原因は移行したフォルダのACLで許可されていないユーザでアクセスしようとしていたためでした。
移行方法に問題は無く、確認しようとしたユーザ（AWS Managed Microsoft ADのAdmin）が間違っていた、ということになります。

対応

フォルダのACLで許可されたユーザでフォルダアクセスを確認していきます。

読み書き可能な「hr-user」では、HRフォルダへファイルを作成（書き込み）が出来ることを確認。

読み取りのみ可能な「hr-r-user」では、HRフォルダへファイルを作成（書き込み）が出来ないことを確認。

ENGフォルダへはアクセスが不可。

まとめ

AWS DataSyncAgentはAMIで提供されていたので構築は手軽でした。 DataSyncの設定としても「ロケーション」と「タスク」にアーキテクチャが分かれていて、分かりやすいものでした。
全体としては、AD構築やAD移行のフェーズも含めたため手順が増えてしまいましたが、無事データの移行まで完了できました。
実際、ファイルサーバ移行とActiveDirectory移行はセットになることは多いので、設定の流れやアーキテクチャの整理になったかと思います。セキュリティグループを広めに空けていたり、エラーとなった箇所もあったのでまだまだ改善すべき部分はありそうです。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

2024-04-08

AWS DataSyncをスケジュール設定する

AWS

こんにちは、株式会社エーピーコミュニケーションズ、クラウド事業部の松尾です。

はじめに
ゴール
環境
AWS DataSyncのスケジュール設定
まとめ
おわりに

はじめに

この記事では既に作成済のAWS DataSyncのタスクをスケジュール化することをやってみる内容となっています。

ゴール

AWS DataSyncで移行元から移行先へファイルを転送する
データ転送をスケジュール化する

環境

AWS DataSyncのスケジュール設定

移行元SMBファイルサーバに485MB程度のファイルを配置します
DataSyncの転送パフォーマンスを確認したいので少し大きめのファイルにしました。

Datasyncのタスクから「編集」

スケジュールを毎時で設定してみます

設定されたことを確認

設定した時刻経過後

履歴から設定時刻に開始していることを確認

まとめ

AWS DataSyncのスケジュール設定でも想定通りにファイルを移行することができました。
今回は移行元と移行先はVPCエンドポイントで接続していますが、インターネット回線経由の場合は帯域を上限を制限したい場合もあると思います。その場合は、タスクの転送設定（Transfer options）で帯域幅の制限をすることも出来るので使うのも良いと思います。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

2024-04-08

Amazon FSxへのデータ移行をやってみる（step4）

AWS

こんにちは、株式会社エーピーコミュニケーションズ、クラウド事業部の松尾です。

はじめに
ゴール
環境
Amazon FSx for Windows ファイルサーバーの作成
- FSx作成エラー
FSxのマウント
おわりに

はじめに

この記事は以下の手順を紹介する内容となっています。

前回までにNo3まで完了しています。本記事ではNo4を紹介します。

オンプレミスのADとAWS Managed Microsoft AD間に双方向の信頼を設定する
ADMT等のツールでユーザーアカウントとグループを移行する
ファイルサーバー上のアクセス権限であるAccess Control List（ACL）を複製する
移行先へAmazon FSxを作成する
AWS DataSyncを利用し、既存のACLを保ったままファイルとフォルダをAmazon FSxに移行する

ゴール

移行先VPCへAmazon FSx for Windows ファイルサーバーを構築する

環境

作業後

移行先環境へAmazon FSx for Windows ファイルサーバーを構築します。

Amazon FSx for Windows ファイルサーバーの作成

移行先環境のファイルサーバーを構築していきます。
今回はFSxにします。

Amazon FSxから「ファイルシステムを作成」をクリック

Windowsファイルサーバーを選択

パラメータを確認するため「スタンダード作成」で進めていきます
デプロイタイプは推奨のマルチAZにしておきます。

ストレージ容量はSSD最小の32とします

VPCは移行先のVPCを選択
セキュリティグループはこちらを参考に設定します。

バックアップは検証のため「無効」としておきました

確認画面では作成後の編集可否が表示されます
内容を確認して「ファイルシステムを作成」をクリック

あとは作成まで暫し待ちます。（手元では約50分かかりました）

FSx作成エラー

このようなエラーになってしまった場合、リンク先から確認していきます。
私の場合はセキュリティグループのルールが不足していました。

FSxのマウント

移行が正しく行われたことを確認できるように、移行先ファイルサーバ（FSx）をEC2でマウントしておきます。

作成したFSxの「アタッチ」をクリック

今回はデフォルトのDNS名を使用のコマンドをコピー

移行先VPCのEC2のコマンドプロンプトでコピーしたコマンドを実行してFSxをマウント

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

参考 : https://d1.awsstatic.com/ja_JP/training-and-certification/docs-dev-associate/AWS-Certified-Developer-Associate_Exam-Guide.pdf

2024-04-08

【AWS】AWS Certified Developer – Associate(DVA-C02) を受けてみて

AWS

はじめに

こんにちは。クラウド事業部の早房です。
AWS Certified Developer – Associate(DVA-C02) を受験し無事に合格しました。
受験に至ったきっかけや実際の試験の感想について綴ります。

出題範囲と割合について

出題範囲と割合は以下です。

• 第 1 分野: AWS のサービスによる開発 (採点対象コンテンツの 32%)
• 第 2 分野: セキュリティ (採点対象コンテンツの 26%)
• 第 3 分野: デプロイ (採点対象コンテンツの 24%)
• 第 4 分野: トラブルシューティングと最適化 (採点対象コンテンツの 18%)

筆者のステータス

AWS歴約半年
AWSでの開発経験はほぼ皆無、つい先月CloudFormationやLambdaを触り始めました。

受験に至ったきっかけ・目的

AWS 認定資格をコンプリートしたい
直近の業務でCloudFormationのテンプレートやLambdaを作成していたので、マッチする部分が多い
苦手分野の克服 (これまで何となくとっつきにくく感じていて受験を避けていました)

参考にしたサイト・ブログ記事など

動画での解説が分かりやすいです。
文字ばかりだと全然わからんという方におすすめ。
kws-cloud-tech.com

出題サービスの概要がまとめられています。
丸暗記しておいても良いかもしれません。
qiita.com

CloudFormationの組み込み関数について大変分かりやすくまとめられています。
o2mamiblog.com

「API Gateway ってなんぞや」な状態だった私でもスッと理解できました。
図解がとてもわかりやすい。
zenn.dev

結果

合格 (871点)

感想

前回 DOP に合格していたので「まあ何とかなるだろう」という心の隙があったせいか、なんとなくで覚えていた部分を上手く突かれてしまい、直近では最も手ごたえのない試験でした。(得点が伸びたのは択一式であるお陰)
業務で触れることの多いサービスに関しての問題は自信をもって回答できる問題が多かったものの、DOPであまり問われなかったり直接触ったことのないサービス (API Gateway/X-Ray)や、 CloudFormationのテンプレートの構文について深堀されるような問題は、直感に頼らざるを得ない問題がほとんどであり、サービスを頭の中でイメージするだけではなく実際に触れてみることの大切さを改めて思い知らされる試験でした。
合格できたものの、受験の目的である「苦手分野の克服」は達成できていないので復習をしたいです。

毎度のことですが無事に合格できてホッとしました。これでAWS認定資格は合計 7 つ取得することができました。(SAA,SAP,SCS,SOA,DBS,DOP,DVA)
次はANSの受験を目指して、引き続き学習を進めていきます。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

本記事の投稿者: hybs_yuuuu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/hybs_yuuuu/badges

2024-04-05

【入門・初心者向け】Amazon FSx for Windows File Server の特徴と比較

AWS クラウド Windows Amazon FSx Amazon EBS Amazon EFS

はじめに

こんにちは、エーピーコミュニケーションズクラウド事業部の高橋です。
この度、はじめてブログを書かせてもらうことになりました！これからよろしくお願いします！

記念すべきはじめてのブログは、AWS のファイルストレージサービスである Amazon FSx について書いてみたいと思います！
クラウドは、わたし自身は Azure のほうが得意で AWS はまだまだ勉強中なので、
同じように AWS 初心者でこれから頑張っていきたいと思っている人にも見ていただけたら嬉しいです！
どうぞよろしくお願いします！

どんなひとに読んで欲しい

AWS を活用したファイルサーバーを構築したい人
AWS のファイルストレージサービスの概要を確認したい人
Amazon FSx のメリットとデメリットを知りたい人

AWS が提供するファイルストレージサービス

まずはじめに、AWS が提供しているファイルストレージサービスは、大きく２種類に分けることができます！

◆ Amazon EIastic FiIe System (Amazon EFS)
１つは、Amazon EFSです。
Amazon EFS の特徴としては、 Linux / Unix 向けの共有ファイルストレージという点です。

Amazon EFS は、Network File System (NFS) というプロトコルを使用してファイルストレージに接続しています。
NFS は、Linux / Unix 向けに設計されており、ネットワークを通じて複数のコンピュータでファイルを共有することが可能です。
※ NFS は一般的に TCP もしくは UDP 2049 番ポートにて提供されていますが、Amazon EFS は NFS の Ver.4 以降の対応のために TCP のみのサポートです

◆ Amazon FSx
もう１つは、当ブログで紹介します Amazon FSx です。※「FSx」は略語ではなく正式名称です
Amazon FSx の特徴としては、４種類のファイルストレージサービスが存在し、サービスによっては Linux だけでなく、Windows と macOS にも対応しています。
その中でも、もっともポピュラーな Amazon FSx for Windows File Server は Windows 向けの共有ファイルストレージという点において、
主に Linux 向けの Amazon EFS と比較されることが多いです。

Amazon FSx for Windows File Server は、Server Message Block (SMB) というプロトコルを使用してファイルストレージに接続しています。
SMB は、ネットワークを通じて複数のWindows を中心としたコンピュータでファイルやプリンターなどを共有する Microsoft 独自のプロトコルです。
※ SMB は一般的に TCP 139 番ポートか TCP 445 番ポートにて提供されていますが、Amazon FSx for Windows File Server は SMB の Ver.2 以降の対応のために 445 番ポートのみのサポートです

また、Amazon EFS と Amazon FSx for Windows File Server について比較表で簡潔にまとめてみましたので、参考にしていただけたら嬉しいです！

備考：Windows に NFS クライアントをインストールして Amazon EFS を利用したり、逆に Linux に SMB クライアントをインストールして Amazon FSx for Windows File Server を利用することも可能ですが、特別な要件がない限り、Linux では Amazon EFS、Windows では Amazon FSx for Windows File Server を利用するのでよいと思います！

Amazon FSx の種類

上述しましたとおり、Amazon FSx には４種類のファイルストレージサービスが存在します。
Amazon FSx が提供開始された２０１９年当初は、Windows ベースの Amazon FSx for Windows File Server と Linux ベースの Amazon FSx for Lustre のみでしたが、２０２１年９月に Amazon FSx for NetApp ONTAP、同年１２月に Amazon FSx for OpenZFS が提供されました。

Amazon FSx の各ファイルストレージサービスについて簡潔に以下の表にまとめてみました！
このブログでは、この中でも最もポピュラーな Amazon FSx for Windows File Server に特化してメリットとデメリットを確認していきたいと思います！

Amazon FSx for Windows File Server のメリット

Amazon FSx for Windows File Server のメリットとしては、以下の点があげることができます！

① フルマネージドで導入や管理の負担軽減
利用するにあたっての OS、サーバー、ストレージ、ネットワークなどの構築や設定は AWS のクラウド内で管理されているため、
ユーザーはそれらを導入したり管理する負担がなく、サービスそのものを利用することができます。

② Windows との互換性や機能
サービス内部では、実際に Windows のファイルサーバーが動いています。
そのため、Windows とのネイティブな互換性があり、また、Windows のファイルサーバーが持つ機能を利用することができます。

互換要素
・ファイル共有プロトコル：SMB
・ファイルシステム：NTFS
・認証やアクセス権管理：Active Directory

ファイルサーバー機能
・データ重複排除
・ボリュームシャドウコピーサービス (VSS)
・ストレージクォータ
などなど

上記のことから、例えばオンプレからクラウドで移行する際に、既に Windows のサーバーやクライアントを利用していたり、Windows のファイルサーバー機能を利用されている場合、Amazon FSx for Windows File Server への移行は選択肢の筆頭に挙げられるのではないでしょうか。

③ その他の機能
Amazon FSx for Windows File Server における以下の機能もメリットとして挙げたいと思います。
※ Amazon FSx が提供開始された当初はできなかった機能も、現在では多く改善されているようです

バックアップの取得
標準バックアップ機能にて、日次バックアップ (９０日間まで保持可能) や手動バックアップが可能です。
また、AWS Backup を利用することで、リージョン間コピーや AWS アカウント間コピー、また、日次よりも詳細なバックアップや９０日以上の世代管理をすることができます。
バックアップの使用 - Amazon FSx for Windows File Server

アクセスログの取得
ファイルへのアクセス監査ログを、Amazon CloudWatch Logs などに出力することができます。
ファイルアクセスの監査 - Amazon FSx for Windows File Server

ホスト名の変更
Amazon FSx を任意のホスト名に変更できるため、例えば移行する際、アプリやツール等でホスト名を指定している場合も既存FQDN名をそのまま利用することができます。
DNS エイリアスを管理する - Amazon FSx for Windows File Server

ストレージ容量の拡張
基本的にサービスを停止することなく、ストレージ容量を増やすことができます。
ストレージ容量の管理 - Amazon FSx for Windows File Server

スループット容量の増減変更
スループット容量の増減を柔軟に変更することができます。
※ ストレージ容量の拡張と異なり、シングル AZ でのデプロイの場合、数分間のサービス停止が発生します。(マルチ AZ の場合は発生しません)
スループット容量の管理 - Amazon FSx for Windows File Server

Amazon FSx for Windows File Server のデメリット

続いて、Amazon FSx for Windows File Server のデメリットについても確認していきたいと思います。

① ストレージ容量の削減不可
ストレージ容量を削減することができません。
すなわち、メリットで挙げました「ストレージ容量の拡張」は可能ですが、ストレージ容量を減らしたり一度拡張した容量を戻すことはできませんので、ストレージ容量を増加する際は注意が必要です！
ストレージ容量を増やすときに知っておくべき重要なポイント - Amazon FSx for Windows File Server

増加のみ - ファイルシステムのストレージ容量は増加することのみ可能で、ストレージ容量は減らせません。

② デプロイ後のストレージタイプ変更不可 (SSD ⇒ HDD)
SSD のストレージタイプから HDD のストレージタイプへの変更は、コンソール上からはできません。
もし SSD から HDD へ変更する場合は、バックアップから HDD のストレージタイプにて復元する操作が必要です。
※ なお、HDD のストレージタイプから SSD のストレージタイプへの変更は、コンソール上から可能です
ストレージ容量の管理 - Amazon FSx for Windows File Server

ファイルシステムのストレージタイプを HDD から SSD に変更できます。ファイルシステムのストレージタイプは SSD から HDD には変更できません。

③ Amazon Elastic Block Store (Amazon EBS) と比べてコスト高？
デプロイタイプ、ストレージタイプ、ストレージ容量、スループット容量、バックアップやスナップショットなど、様々な設計要素によって料金が変わってくるため一概には言えませんが、Amazon FSx for Windows File Server はブロックストレージサービスの Amazon EBS より比較的に料金が割高となります。

以下のリンクから、Amazon FSx for Windows File Server と Amazon EBS の料金の見積もりが出せますので、ぜひ比較してみてください！
Create estimate: Configure Amazon FSx for Windows File Server
Create estimate: Configure Amazon Elastic Block Store (EBS)

おわりに

今回は Amazon FSx for Windows File Server について簡単に紹介しました！
ポピュラーなファイル共有ストレージだけあって様々な記事がありますが、できるだけ要点を分かりやすく、且つ、見やすいブログを目指しました。
この記事を読んで少しでも参考にしていただけたら幸いです！
ご拝読ありがとうございました！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp