14年目の終わり。AIの力を借りて初心を思い出す。

小林です。
先日3/1にブログを投稿したのですが、たまたま同じ日に大林さんも投稿しており図らずも小林と大林の共演が実現していました。
ということで次は中林さんを募集中です。

さて、今年でAWS認定の有効期限がいろいろ切れてしまうので、6週連続AWS再認定にチャレンジしてきました。

無事に成功しましたが、大変危険なのでよい子はマネしないでください。
※小林は特殊な訓練を受けています。

このチャレンジのトリをつとめたのはAWS認定 機械学習 - 専門知識（MLS）なのですが、試験の最中に「そういえば全く機械学習サービス使ったことないな…」と気になりはじめてしまいました。

MLSは試験時間に余裕があるので、ざっと問題の見直しをしながらぼんやりとどんな使い方をするか考えていました。
無事に合格し、ちょうどいい使い方も思いついたので、ここで試した結果を書きたいと思います。

データを集めます

今回は入社一年目のメールデータを使います。
新人のころ毎日送っていた日報を集めてきます。
（ちゃんと日報書いてたし、全メール保存しててよかった。）

Outlookを利用しているので、「対象メールを選択→名前を付けて保存」という手順でテキストファイルにメールをまとめてエクスポートできます。

データを加工します

エクスポートしたデータから日報の「所感」部分を抽出します。
幸いフォーマットがしっかりしていたので、スクリプトを使って楽に抽出できました。
（ちゃんと決まったフォーマットで送っててよかった。）

ファイル名を日付、中身を所感の文章にして保存しておきます。
※AWSにデータを送ることになるので、センシティブなデータがないかはこのタイミングでチェックしておきました。

AWSサービスで処理させるためのスクリプトを組みます

毎日の所感をAmazon Comprehendで感情分析し、一年目の感情の変動を見てみます。

フォルダに分割したファイルをまとめて置いてこう！

client = Aws::Comprehend::Client.new(
    region: "ap-northeast-1",
    access_key_id: "xxxxxxxx",
    secret_access_key: "xxxxxxxxxxx"
)

# csvのヘッダ
print "FileName" + ", " + "String" + ", " + "Positive"+ ", " + "Negative" + ", " + "Neutral" + ", " + "Mixed" + "\n"

files.each{|file|
    lines = File.read(dir + "/" + file)

    # 感情分析
    resp = client.detect_sentiment({
        text: lines,
        language_code: "ja"
    })

    # 結果の出力
    print file.gsub(/\.txt/, "") + ", " + "\"" + lines.gsub(/\n/, "\\n") + "\"" + ", " + resp.sentiment_score.positive.to_s + ", " + resp.sentiment_score.negative.to_s + ", " + resp.sentiment_score.neutral.to_s + ", " + resp.sentiment_score.mixed.to_s + "\n"
}

※Rubyです。変数dirがフォルダのパスです。

出力をcsv形式にしたので、そのままファイルに書き込みます。

結果をグラフにします

できたcsvをExeclで読み込んで、グラフにします。
感情分析の結果は、下記の4項目の割合で表されます。

• ポジティブ (肯定的)
• ネガティブ (否定的)
• ニュートラル (中立的)
• 混在

4要素の合計値がだいたい1（丸め誤差あり）になるので、「100%積み上げ縦棒グラフ」にして1日ごとの感情の割合を可視化します。

ということでこちらが入社1年目の感情の変化です。

色分けはこうです。わかりやすいように強めのコントラストです。

• 青：ポジティブ (肯定的)
• 赤：ネガティブ (否定的)
• 黄：ニュートラル (中立的)
• 緑：混在

なんだかネガティブ（赤）が目立ちますね…

でももうちょっと見やすくしたいので、グラフの見せ方を考えてみましょう。
今回は毎日の気分がポジティブ寄りかネガティブ寄りかが知りたいので、ポジティブ/ネガティブを表す点数と時系列の2次元で考えます。

ニュートラルと混在の数値はこう扱います。

• ニュートラル　→ポジティブ/ネガティブ両方に関与しないと考え、無視する。
• 混在　→ポジティブ/ネガティブ両方に均等に関与すると考え、両方に加点する。

ポジティブポイント = 「ポジティブ」の数値 + 「混在」の数値の半分
ネガティブポイント = 「ネガティブ」の数値 + 「混在」の数値の半分 * -1
上記の数式でポイントを計算し、グラフに表すとこうなります。

少し見やすくなったのではないでしょうか？
さらにどちらの数値が優勢か、ポジティブポイントとネガティブポイントの差を計算してグラフにポイントします。

やはりネガティブが優勢ですね…

さて、いくつか所感の内容を見てみましょう。

ポジティブ

8/30

金曜に続いてのテストで今日も１日中スクリーンショットを取ってました。 いいキャプチャツールを見つけたので作業がかなり快適になりました。

よかったですねぇ。

ネガティブ

2/8

Excelの機嫌が悪いのかと思ってたら、機嫌悪いのはWindowsのほうでした。

なんか苦しんでますねぇ。

混在

9/13

久々の出社です。長い休みの後なので朝起きるのがつらかったです。 ただ、頭の方はリフレッシュできたようでタスクの方はいい感じに進められた気がします。

夏休み（弊社は自由に1週間とれます）明けの出社日。
たしかに混在だ。

しっかり判定できてそうですね。
ということはやはり1年目はグラフのとおりネガティブな内容が多かったようです…

なんかシステム化したいですよね

今回はこれ以上の応用はしていないのですが、他のAWSサービスと組み合わせてもおもしろそうだと思いました。

SESでメールを受信して毎日の日報を継続的に感情分析することでチームメンバーのメンタル状態をチェックするとか、

イベントごとのアンケートの結果をアップロードすると評価を数値化してくれるとか、

機密情報などの取り扱いをどうするかという問題が出てくるのでもう少し考慮は必要そうですが、活用方法を検討すると夢が広がってきますね。

オプトアウト

さて、近ごろ話題の中心のAIサービスですが、入力されたデータを使って学習し、さらに性能を上げていくという使い方をされることがあります。

とはいえ、入力したデータを勝手に利用されたくないってことありますよね？

そういった場合はオプトアウトの設定を行うことで入力したデータが利用されることはなくなり、安全にAIサービスを利用することができます。

AWSのAIサービスでもオプトアウトの設定はサポートされています。
詳しくは公式ドキュメントに記載があるので必ず目を通しておきましょう。

docs.aws.amazon.com

おわりに

今回、新人時代の日報にひととおり目を通すことになりましたが、まさか今になって役に立つ日がくるとは。
ちゃんと毎日書いててよかったと思います。

最後に当時の先輩方にいただいた日報への返信で一番印象に残ったものを紹介しておきます。
新人のみなさんが悩むであろう（私も悩んでた）議事録が上手くなりたいという願いへのアンサーです。

初めてリリース確認会の議事録を作りましたが、話になかなかついていけず、苦労しました。 うまく議事録が取れる方法を模索中です。

こちらの所感（ネガティブ82%）への返信
　↓

その場の誰よりも会議に参加することや。

やはり経験を積み重ねることが大事ですね。

『技術書を書く技術』というテーマで、JAWS DAYS 2024に登壇しました

　こんにちは、佐々木です。
先週の土曜日（2024年3月2日）に、5年ぶりにJAWS DAYSが開催されました。参加登録者1,000人で当日も900人近くが来場され、非常に活況な勉強会でした。私もその中のセッションの1つで登壇させて頂いたので、登壇資料や補足など記しておきます。

登壇資料とセッション動画

当日の登壇資料はこちらです。

speakerdeck.com

セッション動画（2024/04/01追加）

www.youtube.com

登壇とテーマ決めの経緯

　セッションについては、CfX（Call for X）という形式でセッションやワークショップ・パネルディスカッションなどを募集する形式でした。私はセッションの形態で2つ応募して、技術書を書く技術というテーマが採択されました。後で聞いた話だと、CfXの応募総数が85件で応募倍率はなんと5.3倍とのことでした。この狭き門のなか、選んでいただいて光栄です。
　テーマとしては、自分の強みを活かせるものを選びました。採択された『技術書を書く技術』は、私個人の強みであるAWS関係書籍の執筆数が、おそらく国内１～２番目くらいに多いということを意識しています。というのもJAWS DAYSの参加者には、今後書籍を書いてみたい人・書ける実力がある人が沢山くるだろうと予想しました。私のセッションを通じて書籍を書く人が増えると、コミュニティも活性化するはずという期待を込めての内容です。選定者側でどのような議論があったのかは解りませんが、AWS要素がゼロに近いものでも無事に採択されました。
　なお、没になったもう一つのテーマはS3 Express時代のデータ分析基盤の作り方というテーマです。性能測定については下記にまとめていますが、ここから発展してデータ分析基盤の設計をどうするのかを話す予定でした。これはこれで面白いテーマだと思うので、どこかで話をしてみたいものです。

cloud.nri-net.com

tech.nri-net.com

参加者の反応

　セッションに関してのX（旧Twitter）の反応は、以下にまとめておきました。内容について、興味を持っていただいた方が多かったようで、ありがたい限りです。

togetter.com

感想

　技術的な話題ではないものの、セッションには沢山の人にご参加いただき、反応も上々でした。セッションの始まりに書籍を書いてみたい人と聞いたところ、目算で6～7割くらいの挙手がありました。書籍執筆については、思っていた以上に関心が強いようですね。当日は２０分と短いセッションで語り尽くすとまではいかなかったので、またどこかの機会に話してみます。
　最後になりますが、JAWS DAYS 2024開催に関わった実行委員の皆様、スタッフの皆様、登壇された皆様、参加されたすべての皆様に感謝を申し上げます。ありがとうございました！！

2023年3大クラウド中心のAI総まとめとオンプレtoクラウドマイグレーションをやってみよう～NRIネットコム TECH AND DESIGN STUDY #27～

こんにちは、ブログ運営担当の小嶋です。
3/19（火）19:00~20:00 当社主催の勉強会「NRIネットコム TECH & DESIGN STUDY #27」が開催されます!!

今回のTECH & DESIGN STUDYは、当社クラウドエンジニアから、2023年3大クラウド中心のAI総まとめと、AWS20分クッキング！MGNやDMSを使ってオンプレtoクラウドマイグレーションをやってみよう！についてお話します。

【1本目】2023年3大クラウド中心のAI総まとめ

2022年末にChatGPTが公開され1年以上が経ち、本格的なAIブームとなりました。
この1年間でクラウド分野に関しても各社から多くのAI関連のサービスがリリースされており、クラウドエンジニアである私にとってもAIが身近なものとなりました。
この発表では3大クラウド事業者であるMicrosoft,Amazon,Googleを中心に、2023年のAI動向を非AI技術者(クラウドエンジニア)視点で振り返ります。
※本発表は非AI技術者(クラウドエンジニア)による発表となります。AIに関する専門性の高い発表ではありません。

▼登壇者

手塚拓也
AWSを中心とした新規構築案件や既存システムのAWS移行案件に従事
2022年にAWS資格対策本を出版「AWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター - アソシエイト」
https://www.amazon.co.jp/dp/481560908X/

▼こんな方におすすめ

・AIに興味をお持ちの方
・AIの動向、大枠を知りたい方
・クラウドエンジニアの方

【2本目】AWS20分クッキング！MGNやDMSを使ってオンプレtoクラウドマイグレーションをやってみよう！～デモ動画を添えて～

オンプレで構築したシステムのクラウドをリフトアップする際に検討すべき7つのR。
今回はその中からリプラットフォームを行う際によく利用されるMGNやDMSを中心に、実際に利用している様子のデモ動画も用いながら クラウドマイグレーションについてお話します。

▼登壇者

望月拓矢
クラウドエンジニア
4ヶ月で認定試験を1から全取得し、2022 APN ALL AWS Certifications Engineer認定を受ける

▼こんな方におすすめ

・オンプレシステムのクラウドリフトアップを検討されている方
・MGNやDMSに興味がある方、実際に動いている様子を見てみたい方

【日程・タイムスケジュール】

3/19（火）
19:00～19:03　オープニング
19:03～19:55　本編
19:55～20:00　アンケート・クロージング

お申し込みはこちらから

興味がある方は、是非ご参加ください！

2023年3大クラウド中心のAI総まとめとオンプレtoクラウドマイグレーションをやってみよう - connpass

SSMって20種類あんねん 〜Run Commandで定期バッチを起動する〜

どうも。小林です。
みなさん、自動化してますか？

私の課では特定の顧客のシステムを多数運用しています。
かなり多くのシステムがあり、顧客側の担当者も異なるため、弊社側でも複数のチームを組んで手分けしてシステムを担当しています。

チームも顧客担当者も異なるとなれば、当然運用のやり方はシステムごとに変わってきます。その一方で統一できる部分は統一しておかないと全体の統制は効きづらくなってしまいます。
そこで「標準化チーム」を発足し、チーム間で共用するシステムのアカウント管理やその申請ルール、顧客報告やメンバーの勤怠管理といったものの標準化を進めています。

標準化の恩恵のひとつとして、「作業が単純化できて自動化しやすくなる」という点が挙げられます。
例えばアカウント発行の申請フォーマットを統一すると、「フォーマットにしたがって記載されたテキストをバッチに読み込ませてアカウントを自動的に発行する」ということができます。

当初は手作業が多かったのですが、こういった活動を通して多くの作業を自動化することができてきました。

ここまで来るとバッチ実行すら勝手にやってほしいですよね？

さて、ではどこでバッチを動かしましょうか？
そもそも「標準化チーム」は特定のシステム担当ではないので自由に使えるサーバというものを持っていません。

どこで動かそうか…？

サーバ…サーバ…

　・
　・
　・

あ、ありました。
以前作った踏み台サーバです。

tech.nri-net.com
tech.nri-net.com

ここにバッチスクリプトを置いて、cronで自動実行を設定して…
動いた！

となったところで気付きました。
これ、個人ユーザでcronを動かしたら他の人が管理できなくない？

そうです。我々は標準化"チーム"なのです。チームメンバーみんなで運用していかねばならないのです。

少し考えて思い出しました。踏み台に使ったSSMを。
SSMの機能のひとつに「Run Command」というサーバのコマンドを実行する機能があることを。

やってみた

前置きが長くなりましたがやってみます。

構成のイメージはこうです。

この形にすればEventBridgeコンソールで実行スケジュールの管理ができ、SSMコンソールで実行結果の確認ができるはず。

今回はテストも兼ねて新しく作った勤怠管理報告用Redmineチケットの自動作成バッチを動かしてみます。

Run Commandで呼び出すコマンド

対象のバッチスクリプトはRubyで書かれており、実行環境としてgemの事前インストールが必要です。
bundlerを利用しているのですが、bundle installが完了している環境をコンテナイメージとして用意し、Run Commandからはそのコンテナを呼び出すことにしました。

こういうDockerfileを書いてビルドし、Dockerイメージを作ります。

FROM ruby:3.1.4-bullseye

WORKDIR /app
COPY Gemfile /app/Gemfile
COPY Gemfile.lock /app/Gemfile.lock
COPY *.rb /app/
RUN bundle install

ENTRYPOINT ["bundle","exec","ruby"]
CMD ["--version"]

するとこんなコマンドで特定のRubyスクリプトを実行できます。

docker run --rm <Dockerイメージ名> xxxxx.rb

SSMコンソールからRun Commandのコマンドの実行画面を開き、コマンドドキュメントの「AWS-RunShellScript」を選択します。

ここにコマンドを書いてっと…

「ちょっと待てぃ！！」

はい。ダメですね。APIキーを直接書いちゃ。
SSMの機能のひとつ、Parameter Storeに格納して変数として与えましょう。
（本来は機密情報はKMSを利用したSecureStringにする方が良いですが、ここでは一旦この形で説明します。）

動かしてみるとこんな感じでログも出ます。ログはS3やCloudWatch Logsに書き出すことも可能です。

ちょっとわかりにくいポイントなのですが、ログをS3およびCloudWatch Logsに出力するときはコマンドを実行するEC2インスタンスロールに出力先のサービスへの書き込み権限が必要となりますのでご注意ください。

EventBridgeから呼び出す

さて、これをEventBridgeから呼び出してみましょう。

EvendBridgeコンソールからスケジュールを作成します。
cron形式で指定できるのですがこのように動く日を明示してくれるのは便利ですね。

ターゲットはSendCommandを選択します。（「Run Command」は無いので要注意）
どうやらSSMの機能名が「Run Command」、API名が「SendCommand」や「CancelCommand」のようです。 docs.aws.amazon.com

入力はこう指定します。

{
  "DocumentName": "AWS-RunShellScript",
  "DocumentVersion": "1",
  "InstanceIds": [ "<インスタンスID>" ],
  "MaxConcurrency": "50",
  "MaxErrors": "0",
  "Parameters": { 
    "workingDirectory":[""],
    "executionTimeout":["3600"],
    "commands":["docker run --rm <Dockerイメージ名> xxxxx.rb"] 
  },
  "TimeoutSeconds": 600
}

指定時間後にRun Commandの履歴を見るとちゃんと動いてました！
（時間変更して動かしたので↑の画像とは時刻が違いますが）

これでチームメンバーにEventBridgeの操作権限とSSMの参照権限を与えれば起動設定とログのチェックがチーム全員でできますね。

まとめ

ということで、無事にやりたかったことが追加のコストをかけずに実現できました。
（DockerイメージをECRに格納する。KMSを使ってParameter Storeの格納文字列を暗号化する。などコストを掛けることで可用性やセキュリティレベルを上げることもできます。）

SSMってほんと多機能で便利ですね。
今ざっと数えると20ぐらいの機能がありました。

そして現在使っているのはこれ。

• 踏み台へのアクセスに利用している「Session Manager」
• Windows踏み台のOSパッチ適用に使っている「State Manager」
• 今回使ったコマンド実行のための「Run Command」
• 今回使ったパラメータ格納のための「Parameter Store」
• 今回使ったシェルコマンド実行方法を定義する「Documents」

まだまだ使い尽くせてはいないですね…

以前はわた推しサービスとしてDynamoDBを挙げましたが、今はSSMが最有力かなと思っています。

社会人1年目の学び3選

はじめに

初めまして。
「テキトーと適当を使い分ける」がモットーの社会人1年目SEの渡辺です。
ここで言う「テキトー」は大雑把な行為・姿勢、「適当」は文字通り適切な行動を指しています。
やるべきことはやる、手を抜けるところは手を抜くことでこれまでの人生をすり抜けてきました。

そんな私はたまに「テキトーと適当を使い分ける」の「テキトー」が強めに現れすぎてしまうときがあります。
社会人を1年経験して「テキトー」が独り歩きしミスにつながってしまったこと、そこで指摘され得た学びを紹介します。

これから社会人になる方、社会人になることに不安を覚えている方に、失敗してもそこから改善して継続すればなんとかなるということを伝えたいです。

1. 日報には意味がある

当社では新人は日報を書くというタスクがあります。

• 業務内容（何をしたか、何をする予定か）
• 業務時間
• 所感（業務で何を感じたか、学んだか）
• 雑感（思ったことをなんでも記載してよい）

上記4つの観点を記載し、日報を送信します。 私は日報送信に関してミスを犯してしまったので、その時教わったことや日々日報を書いたことで理解した日報の意味を共有させてください。

• 上長が残業時間を考慮し、タスク割り振りを考えることができる
• テレワークが多いため、よいコミュニケーションの場になる
• その日のうちに理解したことなどが間違っている時、上長が指摘できる
• 合っていた場合は、「お、分かってるじゃん」と判断できる

今日やったこと、感じたことを書くという簡単な作業ですが様々な意味があるわけですね。

ではなぜ私が日報の大切さに気付けたのか、上述したミスが大いに関係しています。
配属してから1ヵ月が過ぎたころ、
「渡辺さんの日報が意味をなしていません。インストラクターが見てあげてください」
と指摘を受けました。

それもそのはず、先ほど挙げた日報に記載する4つの観点のうち「雑感」しか記載せずにテキトーに日報を送信していました。
その後、先輩に日報の意味、書き方を改めて教わるという時間をいただき、日報を修正して今に至ります。

日報なんて意味ないじゃんと思っている人に今一度日報の大切さを考えてほしいです。
今回の件を通して、

• 　自分のミスは先輩に迷惑をかけることになる
• 　やるべきことはやる、自分で勝手な判断をすべきでない
• 　日報には意味がある

上記3点を改めて実感しました。。
自分のミスが先輩の管理ミスと判断され、自分の代わりに謝っている姿を見て本当に申し訳ない気持ちになりました。

今現在はすべての項目を埋め日報を送信していますが、下記のようにいいことだらけでした。

• 私が理解したと思って書いたことが間違っていた場合、指摘していただける
• 残業時間を見て打ち合わせの日程を再度調整していただける
• 分からないことを嘆いたら返信をいただき問題解消につながる

日報は真面目に書く
教訓です。

2.会議では発言する

• 分からないことはその場で調べる、先輩に聞く（その場で調べることができない場合は、後日調べる or 聞く）
• 質問・発言する

当たり前のことですが会議参加者が実施すべきことですね。

新人のころはまず前提知識（業務知識やIT知識）が不足しているので、なかなか質問・発言しづらいと思います。
ですが理解を深める、認識齟齬を生まないためにも、質問・発言すべきだと思います。

なぜこんな当たり前のことを書いているのか。
そうです。ミスを犯して今の渡辺があります。

配属から2ヵ月くらいが経ったころ新しいチームに参画することになり、その会議に参加していました。
まだまだ知識不足で「この単語は結構頻出だな。あとで調べよう」とメモすることも時折ありましたが、
「今のワードはどういう意味？分からない。まあ今後慣れていくっしょ」
とテキトーな気持ちでいました。
私が発言することなく会議が終わろうとしていたときに、分からないことはその場で質問すべき、と指摘いただきました。

それ以降では、会議に参加して分からないワードがあればすぐ調べる、先輩に聞くことを心がけています。
配属直後、会議している内容はほとんど理解できず、議事録を書こうにも聞き取れないことが多かったのですが、
最近では、ある程度会議の内容についていけて議事録もほぼ自力でとれるようになってきました。
分からないことを解消しつつ、徐々に知識を付けることができている証拠だと思います。

会議に参加したからにはぼーっとせず
分からないことを解消することに努め、発言できるようになりましょう。

3.自分も立派なチームの一員

配属されたら自分も立派なチームの一員であり、割り当てられたタスクには責任が発生します。
新人のころはとにかく分からないことが多いため、
「先輩すごいな」「そういう作業をしているんだ」「難しいこと話しているな」
と、どこか他人事のように業務を見てしまうかもしれません。

しかしそれではだめで、
「今後自分がこの業務を実施するのか」
「自分が実施するためにはまずこれを覚えなきゃいけないな」
と、自分事として先輩の行っている業務を見るべきです。

もうお分かりかと思いますが、渡辺またミスをしたからこんなことを話しています。
配属から3ヵ月ほどが経過した頃、リリース作業に立ち会うことになりました。
基本的には、先輩の作業を見て学ぶことが私のタスクでした。

私のチームの作業が一息ついたとき、他チームの方が「〇〇の作業終わりましたか？」と問いかけてきましたが、先輩方には聞こえておらず私だけ聞き取ることができた状況でした。
その作業はすでに終えた認識だったので私は
「終わったみたいです」
と返答したところ、他人事ではないと指摘を受けました。

今後自分が実施するようになるであろう作業のため、注意して見ていたつもりでした。
しかし、確かにどこか他人事としてとらえ、自分事として考えられていなかったがために
「終わったみたい」
と発してしまいました。
自分もチームの一員であるという自覚が足りておらず、自分事として考えられていなかったわけです。
この経験から何をするにも自分事として考え、自分が作業をするときに困らないように、事前に質問・調査をするようになりました。

その成果もあり、今ではリリース作業を一通り実施できるようになりました。
新人の頃から何をする、何を見るにも自分事ととらえて日々の業務に励みましょう。

おわりに

最後までブログを読んでいただきありがとうございました。
これから社会人になる方へお伝えしたいのですが 新人がミスするのは当たり前です。
ミスした後の改善、心構えに重きを置き日々の業務に取り組みましょう。

踏み台サーバー、SSMセッションマネージャー、EC2 Instance Connect Endpoint サービスを使用したEC2インスタンスへの接続方法と特徴を比較してみた

はじめに

こんにちは。大林です。踏み台サーバーやSSMセッションマネージャーなど、プライベートサブネットに配置されたEC2インスタンスへの接続方法が増えてきたと思います。 今回のブログでは、プライベートサブネットに配置されたEC2インスタンスへの接続方法をまとめて、各種接続方法のメリットとデメリットを比較していきたいと思います。

踏み台サーバー経由で接続する方法

踏み台サーバーとは、外部から直接アクセスできないサーバーにアクセスするために配置される中継サーバーのことです。セキュリティの観点からVPC内に構築された内部向けのサーバーを外部に公開することは避けたいと思います。踏み台サーバーを使用すれば、外部へからの侵入リスクを抑えながらサーバーに接続することができます。
以下の構成図は、踏み台サーバー経由でEC2インスタンスに接続する通信経路とプライベートサブネットに配置されたEC2インスタンスからインターネットに通信する経路をまとめたものです。構成図にはNATゲートウェイがありますが、踏み台サーバー経由でプライベートサブネットに配置されたEC2インスタンスに接続するだけであればNATゲートウェイは必要ありません。プライベートサブネットに配置されたEC2インスタンスに接続してパッケージのインストールをしたい場合、インターネットへのアウトバウンドの通信経路が必要なのでNATゲートウェイが必要になります。

①セキュリティグループを作成する

EC2のマネジメントコンソールを開いてセキュリティグループを作成する。設定内容は以下です。
踏み台サーバ用セキュリティグループ

ルール	IPバージョン	タイプ	プロトコル	ポート範囲	ソース
インバウンドルール	IPv4	SSH	TCP	22	接続元IPアドレス

プライベートサブネットに配置されたEC2インスタンス用セキュリティグループ

ルール	IPバージョン	タイプ	プロトコル	ポート範囲	ソース
インバウンドルール	IPv4	SSH	TCP	22	踏み台サーバ用セキュリティグループ

②パブリックサブネットに踏み台サーバを作成する

EC2作成時のネットワーク設定でパブリックサブネットを指定してEC2インスタンスを作成していきます。
踏み台サーバを作成する際は以下の点に気を付けてください。
・キーペアを作成してローカルにダウンロードすること。
・パブリックIPを割り当てること。
・手順①で作成した踏み台サーバ用セキュリティグループを設定すること。 (Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

③プライベートサブネットにEC2インスタンスを作成する

EC2作成時のネットワーク設定でプライベートサブネットを指定してEC2インスタンスを作成していきます。
EC2インスタンスを作成する際は以下の点に気を付けながらプライベートサブネットにEC2インスタンスを作成してください。
・キーペアを作成してローカルにダウンロードすること。
・手順①で作成したプライベートサブネットに配置されたEC2インスタンス用セキュリティグループを設定すること。 (Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

④踏み台サーバーにプライベートサブネットに配置されたEC2インスタンスのキーペアをコピーする

以下のコマンドを使用して、ローカル環境から踏み台サーバーにプライベートサブネットに配置されたEC2インスタンスのキーペアをコピーします。

scp –i 踏み台サーバーのキーペア(.pemファイル) 踏み台サーバーからアクセスするEC2インスタンスのキーペア(.pemファイル) ec2-user@ec2-踏み台サーバーのパブリックIPアドレス.リージョン.compute.amazonaws.com:コピー先ディレクトリ

⑤踏み台サーバーにアクセスする

以下のコマンドを参考にローカルPCにダウンロードしたキーペアを使用して踏み台サーバに接続します。 ※このコマンドはキーペアが「.ssh」フォルダにあることを想定したものです。

⑥踏み台サーバーからプライベートサブネットにあるEC2インスタンスにアクセスする

以下のコマンドを使用して、踏み台サーバーからプライベートサブネットにあるEC2インスタンスに接続します。

ssh -i ~/.ssh/キーペア ec2-user@接続先EC2インスタンスのプライベートIP

SSMセッションマネージャー経由で接続する方法

AWS Systems Managerの機能の一部であるセッションマネージャーを経由してプライベートサブネットに配置されたEC2インスタンスに接続する方法を説明していきます。
セッションマネージャーを活用することにより、SSHキーの管理やEC2インスタンスへのパブリックIPアドレスの割り当てを避けつつ、プライベートサブネット内に配置されたEC2インスタンスへの接続が可能になります。
前提として、セッションマネージャーを使用してEC2インスタンスに接続するためには、接続対象のEC2インスタンスにSSMエージェントがインストールされている必要があります。Amazon Linux 2やWindows Server 2008-2022 (AWSが提供する公式AMIでのみ)などSSMエージェントがデフォルトインストールされているOSもあります。
また、セッションマネージャーを使用してプライベートサブネットに配置されたEC2インスタンスに接続するためには、SSMエージェントからのアウトバウンドの通信経路を確保することと、接続対象のEC2インスタンスに適切な権限を割り当てることも必要になってきます。 アウトバウンドの通信経路を確保するためには、VPCエンドポイントかNATゲートウェイが必要になります。今回はVPCエンドポイント使用した手順とNATゲートウェイを使用した手順の両方の手順を説明していきます。

VPCエンドポイントを使用した方法

VPCエンドポイントは、SSMエージェントがSystems Managerにアクセスするための通信経路として使用します。また、NATゲートウェイを配置することで、EC2インスタンスに接続した後にパッケージのインストールなどインターネットへの通信経路を確保できます。そのため、以下の構成図ではプライベートサブネットに配置されたEC2インスタンスに接続するだけであれば、VPCエンドポイントのみを作成すればよいです。
以下の構成図は、セッションマネージャー経由でEC2インスタンス接続する経路とプライベートサブネットに配置されたEC2インスタンスからインターネットに通信する経路をまとめたものです。上記の説明の通り、SSMエージェントとSystems Manager間の通信はVPCエンドポイントもしくはNATゲートウェイを使用する必要があります。以下の構成図だと、VPCエンドポイントとNATゲートウェイの両方があるため、SSMエージェントとSystems Manager間の通信を可能とする経路が2つ存在することになります。VPCエンドポイントを作成した場合は、SSMエージェントとSystems Manager間の通信はNATゲートウェイを通ることなくVPCエンドポイントを経由して通信が行われます。

①セキュリティグループとIAMロールを作成する

EC2のマネジメントコンソールを開いてセキュリティグループを作成します。設定内容は以下です。

VPCエンドポイント用セキュリティグループ

ルール	IPバージョン	タイプ	プロトコル	ポート範囲	ソース
インバウンドルール	IPv4	HTTPS	TCP	443	EC2が配置されているサブネットのIPv4 CIDR
アウトバウンドルール	IPv4	HTTPS	TCP	443	0.0.0.0/0

EC2インスタンス用IAMロール
EC2インスタンス用のIAMロールの許可ポリシーに「AmazonSSMManagedInstanceCore」を追加します。 (AWS IAMマネジメントコンソール)

②プライベートサブネットにEC2インスタンスを作成する

EC2のマネジメントコンソールを開いてEC2インスタンスを作成していきます。EC2インスタンスを作成する際に手順①で作成したEC2インスタンス用IAMロールを設定します。

(Amazon EC2マネジメントコンソール)

③VPCエンドポイントを作成する

VPCのマネジメントコンソールを開いて、VPCエンドポイントを作成していきます。プライベートサブネットに配置されたEC2インスタンスがSystems Managerと通信するためには、以下の3つのエンドポイントが最低限必要です。VPCエンドポイントを作成する際は、手順①で作成したVPCエンドポイント用セキュリティグループを設定します。

• com.amazonaws.リージョン.ssm
• com.amazonaws.リージョン.ssmmessages
• com.amazonaws.リージョン.ec2messages
  

上記の3つのエンドポイントが正常に作成されると、ステータスが「使用可能」になっていることが確認できます。 (Amazon VPCマネジメントコンソール)

④SSMセッションマネージャー経由でEC2インスタンスに接続する

EC2のマネジメントコンソールから「セッションマネージャー」のタブを選択して、接続ボタンをクリックすると接続することができます。 (Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

NATゲートウェイを使用した方法

NATゲートウェイを使用してSSMエージェントとSystems Manager間の通信を可能にする方法を説明していきます。この方法は、SSMエージェントからSystems Manager間の通信経路とプライベートサブネットに配置されたEC2インスタンスからインターネット間の通信経路の両方をNATゲートウェイで確保する方法です。上記のVPCエンドポイントを使用した方法と比較すると、VPCエンドポイントが必要ないため構成がより簡潔になります。

①IAMロールを作成する

EC2インスタンス用IAMロール
EC2インスタンス用のIAMロールの許可ポリシーに「AmazonSSMManagedInstanceCore」を追加します。 (AWS IAMマネジメントコンソール)

②プライベートサブネットにEC2インスタンスを作成する

EC2のマネジメントコンソールにアクセスして、EC2インスタンスを作成していきます。EC2インスタンスを作成する際は、上記の手順①で作成したIAMロールを設定します。

(Amazon EC2マネジメントコンソール)

③NATゲートウェイを作成して、ルートテーブルを編集する

VPCのマネジメントコンソールからNATゲートウェイを作成していきます。サブネットにはパブリックサブネットを指定して、接続タイプはパブリックを選択します。 (Amazon VPCマネジメントコンソール)

作成したNATゲートウェイの状態が「Available」になったら、接続するEC2インが配置されているプライベートサブネットが関連付けられたルートテーブルを編集していきます。 ルートテーブルのルート編集画面を開いて、ターゲットに上記で作成したNATゲートウェイを指定して変更を保存します。 (Amazon VPCマネジメントコンソール)

(Amazon VPCマネジメントコンソール)

④SSMセッションマネージャー経由でEC2インスタンスに接続する

EC2のマネジメントコンソールから「セッションマネージャー」のタブを選択して、接続ボタンをクリックすると接続することができます。NATゲートウェイを作成してルートテーブルを編集したとしても、EC2インスタンスに接続できるようになるまで少し時間がかかる場合があります。私が検証した際には、EC2インスタンスに接続できるようになるまでに20分程かかる時もありました。 (Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

EC2 Instance Connect Endpoint サービス経由で接続する方法

EC2 Instance Connect Endpoint サービスは、プライベートサブネットに配置されたEC2インスタンスにプライベート接続を可能とするサービスです。EC2 Instance Connect Endpoint サービスを使用することで、パブリックIPアドレスを持たないEC2インスタンスにSSH/RDP接続をすることができます。また、EICエンドポイントは、VPCエンドポイントと異なり、固定費用が発生しません。そのため、コストを抑えた接続が可能です。
一方で、1つのVPCあたりEICエンドポイントを1つまでしか作成できないといったデメリットもあります。
以下の手順では、SSH接続をする際に必要な手順をまとめています。

(画像参照元)EC2 Instance Connect Endpoint のセキュリティグループ

①セキュリティグループを作成する

EC2のマネジメントコンソールを開いてセキュリティグループを作成します。設定内容は以下です。

EICエンドポイント用セキュリティグループ
インバウンドルールは特に指定する必要はありませんが、アウトバウンドルールでSSH通信を許可しておく必要があります。

EC2インスタンス用セキュリティグループ

ルール	IPバージョン	タイプ	プロトコル	ポート範囲	ソース
インバウンドルール	IPv4	SSH	TCP	22	EICエンドポイント用セキュリティグループ

②プライベートサブネットにEC2インスタンスを作成する

EC2のマネジメントコンソールにアクセスして、EC2インスタンスを作成していきます。EC2インスタンスを作成する際は、上記の手順①で作成したEC2インスタンス用セキュリティグループを設定します。 (Amazon EC2マネジメントコンソール)

③EICエンドポイントを作成する

VPCのマネジメントコンソールからEICエンドポイントを作成します。サービスカテゴリでは「EC2 インスタンス接続エンドポイント」を選択して、上記の手順①で作成したEICエンドポイント用セキュリティグループを設定します。また、サブネットはEC2インスタンスが配置されているプライベートサブネットを指定します。 (Amazon VPCマネジメントコンソール)

(Amazon VPCマネジメントコンソール)

(Amazon VPCマネジメントコンソール)

④EC2 Instance Connect Endpoint サービスを使用してEC2インスタンスに接続する

EC2のマネジメントコンソールから「EC2 Instance Connect」のタブを選択します。「EC2 Instance Connectエンドポイントを使用して接続する」を指定して、上記の手順③で作成したEICエンドポイントを選択します。最後に接続ボタンをクリックすると接続できます。 (Amazon EC2マネジメントコンソール)

(Amazon EC2マネジメントコンソール)

各種接続方法を比較してみる

以下のようにプライベートサブネットに配置されたEC2インスタンスへの接続方法を比較してみると、接続方法はどれも一長一短だと言えます。
踏み台サーバーを使用した場合だと柔軟性がある一方、SSHキーの管理や踏み台サーバー自体のセキュリティ対策が必要になります。
VPCエンドポイントを使用したセッションマネージャー経由での接続は、SSMエージェントとSystems Manager間の通信がインターネットを経由しないためセキュアになりますが、インターネットへの通信経路を確保するためにNATゲートウェイが必要になりVPCエンドポイントとNATゲートウェイの両方の固定費用がかかってきます。
セッションマネージャー経由での接続にNATゲートウェイのみを採用した場合、VPCエンドポイントを使用しない分固定費用は抑えられますが、VPCエンドポイントを使用した場合と比べてセキュアではなくなります。
EC2 Instance Connect Endpoint サービスを使用した接続方法は、コストを抑えることができますが、冗長性という点では他の接続方法には劣ると言えます。

接続方法	メリット	デメリット
踏み台サーバーを使用した接続	・クライアントからSSH接続が可能 ・さまざまなネットワーク構成に適応できるため柔軟性が高い	・踏み台サーバーへのセキュリティ対策が必要 ・SSHキーの管理が必要
SSM(VPCエンドポイントを使用)	・SSHキーの管理が不要 ・SSHのインバウンドポートを開く必要がない ・SSMエージェントとSystems Manager間の通信がインターネットを介さないためセキュアになる	・NATゲートウェイを使用してインターネットへの通信経路を確保する場合、VPCエンドポイントとNATゲートウェイの固定費とデータ量に応じた利用料がかかる ・ EC2インスタンスにSSMエージェントをインストールする必要がある
SSM(NATゲートウェイを使用)	・SSHキーの管理が不要 ・SSHのインバウンドポートを開く必要がない ・NATゲートウェイのみの利用料でSSMセッションマネージャーとインターネットの両方に接続可能	・VPCエンドポイントとSSMセッションマネージャーを使用した接続方法よりもセキュアではない ・EC2インスタンスにSSMエージェントをインストールする必要がある
EC2 Instance Connect Endpoint サービスを使用した接続	・EIC エンドポイントの固定費用がかからない(データ転送には料金がかかる) ・パブリックIPアドレスを持たないEC2インスタンスに対してSSH/RDP接続ができる	・EICエンドポイントの冗長構成ができない→1つのVPCあたりエンドポイントを1つまでしか作成できない

おわりに

今回のブログでは、踏み台サーバを使用した接続方法、SSMセッションマネージャーを使用した接続方法(VPCエンドポイント)、SSMセッションマネージャーを使用した接続方法(NATゲートウェイのみ)、EC2 Instance Connect Endpoint サービスを使用した接続方法をまとめて、それぞれのメリットとデメリットを比較していきました。どの接続方法も特徴があるため、要件に応じた接続方法を選択していくことが重要だと思います。また、本ブログを参考にハンズオンを実施した方は特にVPCエンドポイントとNATゲートウェイの削除を忘れないようにお願いします！

資格に対する勉強のやる気 ～作業興奮と兼好法師～

こんにちは、後藤です。普段、私はAWSを使ったシステムの設計や開発をしております。
先日、AWS認定資格をすべて取得できたので振り返りたいと思います。各試験の難易度や出題内容といった話ではなく、どのように勉強し続けたのかについて書いていきます。
エンジニアの方だけでなく「勉強しないといけないけど、やる気が起きない」と思っている方にも是非読んでいて頂けたら幸いです。

はじめに

私はエンジニアになる前は営業職として働いていました。 今となっては体系的な知識を効率的に抑えることができるので資格取得の意義を感じていますが、エンジニアになりたての頃はそうでもありませんでした。
案件に入るために取らなければいけない状況だったために、しぶしぶ資格の勉強をしていました。

もともと自ら進んで勉強していたわけでもなかった私が、それでも勉強を続けてこれた理由を考えてみました。

なぜ、勉強を続けてこられたのか

それは勉強を続ける「やる気」というものをコントロールできていたからだと思います。当時から「勉強をし始めるのにやる気はほとんど関係ない、やる気がでるのは勉強をし始めてから」と考えてました。「今日はめんどくさいなぁ」といった怠惰な感情だったとしても一切関係なく「今日は5分だけ勉強する。教材読んでたらいつのまにか集中してるでしょ」というスタンスだったので、作業のとっかかりや集中力継続のハードルが下がっていたのだと思います。
気持ちの持ちようかと思っていましたが、調べてみると脳科学的にも実際にそのような仕組みはあるそうです。
脳科学用語では作業興奮と呼びます。自分の部屋の床が少し汚れていて気になって掃除していたら気づけば全体の掃除を始めていた、という経験はありませんでしょうか。あの現象です。
脳にはやる気に大きく関わる側坐核という部位があり、この側坐核は刺激をしないと動き出しません。側坐核に刺激を与えてドーパミンがでてやる気が沸く、という仕組みになっています。
今思えば、理にかなった考え方でした

勉強にやる気がでないと困っている方々、まずは５分勉強してみましょう！

とは言っても・・・

実際に行動に移すのは簡単ではありません。この「とりあえず5分」という最初の一歩がまだ重く感じると思います。この一歩を少しでも軽くできる方法を紹介します。
それは勉強を始めようと思い立った瞬間から開始するまでの時間をなるべく短くするという方法です。私はタブレットに教材や問題集を全てダウンロードしていました。
勉強机に座って、参考書を本棚から引っ張ってきて、パソコンにログインして・・・といった準備時間があると、その間に怠惰な感情が生まれやすいです。
「勉強をし始めるのにやる気はほとんど関係ない」とは言いつつも、怠惰な感情はない方が良いです。 タブレットに教材をすべて入れておけば、これらの工程はかなり省略でき、考える間もなく勉強を開始できました。

さいごに

やる気を待つのではなく、行動からやる気を引き出すというアプローチ、みなさんも試してみてください。
最近は飲み会の当日になって「やっぱり今日、行くのめんどくさいなぁ、でもドタキャンはしたくないなぁ」とよく思うのですが、とりあえず身支度をすることで作業興奮を利用しています。

おまけ

サブタイトルをおまけで回収することになってしまいましたが、エンジニアになりたての頃に教えて頂いた言葉があり、今でも刺さる言葉があったので紹介しておきます。
鎌倉時代に兼好法師が書いた随筆「徒然草」150段の一部です。現代語訳と原文を載せておきます。

現代語訳
芸能を身につけようとする人が、「下手なうちは、人に見られたら恥だ。人知れず猛特訓して上達してから芸を披露するのが格好良い」などと、よく勘違いしがちだ。こんな事を言う人が芸を身につけた例しは何一つとしてない。 まだ芸が未熟なうちから上手な人に交ざって、恥をかき笑い者になっても苦にすることなく平気でやり過ごして、センスがなくても停滞せず、またいい加減なやり方をしない人は、センスがあって努力をしない人よりも、最終的には上のレベルに達し、権威も備わり、世間にも認められて、並ぶもののない名声を得るのである。

原文
　能のうをつかんとする人、「よくせざらんほどは、なまじひに人に知しられじ。うちうちよく習ひ得えて、さし出いでたらんこそ、いと心にくからめ」と常に言ふめれど、かく言ふ人、一芸も習ならひ得うることなし。 　未いまだ堅固けんごかたほなるより、上手の中なかに交まじりて、毀そしり笑はるゝにも恥ぢず、つれなく過ぎて嗜たしなむ人、天性てんせい、そ骨こつなけれども、道になづまず、濫りにせずして、年を送れば、堪能かんのうの嗜たしなまざるよりは、終つひに上手の位に至り、徳たけ、人に許されて、双ならびなき名を得うる事なり。

成長に必要な「恥を恐れない」「上手な人に混ざる」「努力の継続」について述べられています。 響きますね。もっとアウトプットしていかないとなと思いました。