プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

口だけ出して、仕事は人に押し付けて、手柄だけ取っていくおじさんエンジニアになった今、思うこと

おっさん化したことに気付いた瞬間

先日、同僚が「あの先輩、面倒ななことばかり言って、仕事は人に押し付けて、手柄だけ取っていくから一緒に仕事したくないんだよね。あっちの先輩も営業や客からは評判いいけど、できないことばかり並べて、自分で風呂敷を畳まないからいつも迷惑してる。」と言っているのを聞いてハッとしました。

昔なら共感したでしょう。 でも今の自分はその先輩の動きが理解できる部分が少なくありません。 むしろ近年の自分の動き方は先輩寄りです。 自分も周囲の人たち、特に若手から同じように思われているのでしょうか。

そこで今回は若手エンジニアの方々に向けて、なぜ私が口先ばかりで手柄だけ奪っていくおっさんに成り下がったのか、説明したいと思います。 未来のあなたにも起こることかもしれません。


若手の頃の働き方

私にも若手の頃がありました。 案件にどっぷり浸かって、タスクや課題をがんがんこなしてました。 そうして完了したタスクや解決した課題、案件への貢献が成果になりました。

少し成長してリーダークラスになると裁量や社内外の調整が増えましたが、案件にどっぷり浸かっている点は同じでした。 そうして苦労して成功に導いた案件が成果になりました。


おっさんはなぜ自分で仕事をしないのか

おっさんになると振られる案件の数が突然、増えます。 3倍、4倍と増えていきます。

当然、一つ一つの案件に集中することはできなくなります。 案件内の個別のタスクや課題を担当する時間はありません。

逆にやっていると上司に怒られます。 「細かい仕事は若手に任せろ!お前はビジネスをスケールさせることに集中しろ!」と。

「このタスクはチームの中で私しかできないんです。。。」 と言い訳しても聞く耳を持ってもらえません。 むしろ引き継ぎができないことを詰められます。

何度も怒られているうちにおっさんは上司が自分に求めていることを理解します。 つまり自分がいなくても案件が回るような体制を早々に作り、それが出来た案件は離れて見守り、1つでも多くの案件を回すことだと。 それが「ビジネスをスケール」させることなんだと。

そして悟ります。 人に任せることが自分の仕事の一部なんだと。 だって任せないと次の案件に行けないから。

さらに悟ります。 (うまく回っている案件に関しては)「あの人、なんのためにいるかわからないね」と悪評が立つことも仕事の一部なんだと。 だってこっちが細かく監視しているのがわかったら忖度しちゃって自分で考えないでしょ。 上司も「ビジネスをスケール(以下略)」と怒ります。 あれこれ言いたいのを我慢して、陰口を言われながら自由に動いて成長してもらった方が組織にとってもその人にとってもよいんです。

こうしてたまに変なこと言うだけで、仕事しないおっさんができあがるわけです。


おっさんはなぜ手柄を盗るのか

会社員である以上、目標設定や成果報告があります。 成果を示さないわけにはいきません。

ここで不利なのは、おっさんは案件の実行段階の大半を若手に任せないといけないという点です。 若手の頃のように「この案件をやりました!」とは言えません。 仕方がないので「この案件のXXXという側面をリードしました」みたいなことを成果として報告します。

「『リード』とか言って、俺達の手柄とってるじゃん!」

と思うかもしれませんが、上もそんな馬鹿ではありません。 誰が実行役で誰がおっさん役かなんてわかってます。 配役を決めた張本人ですから。

そして、おっさん役が「リード」とか、「XXXという側面」とか言えば、なにをやったかだいたいイメージできるんです。 そういうおっさん業界用語があって、おっさん役や上司の間ではそれで通じ合っていると思ってください。 紛らわしいですが、あなたの手柄は盗られてないので安心してください。 (中には悪い人もいるかもしれませんが)


おっさんはなぜお客の前で風呂敷を広げるのか

若手の頃はお客様の話を打ち返すことに集中してました。 そうしないと次から次へと降ってくるタスクを裁けないからです。 お客様も早く打ち返すことを喜んでくれました。

おっさんになって同じことをすると会話が止まります。 次第に呼ばれなくなります。 将来のビジネスが怪しくなります。 上司も「ビジネ(以下略)」と怒ります。

相手はマネージャや幹部です。 多くの場合、彼らは具体的な確認事項があるわけではありません。 彼らが抱える困りごとの相談がしたいんです。 相談に乗って欲しい相手に対してポンポン打ち返していたら噛み合いません。 「あいつは相談相手にならない」と見放されます。

そして悟ります。 こういう話し合いにおいては打ち返しちゃいけないんだと。 受け止めて、広げて、課題と解決策の全体像を見せてあげて、その上で自社の強みが出る部分のお手伝いを提案させていただく。 そういうスタンスじゃないと自社の首を締めることになるんだと。

また、そういった提案を進める中では価格感、時期感などを早い段階で参考値として提示することが求められます。 見積もるための具体的な情報がほぼない状況で無理ゲーです。 無理に作った数字が後工程の担当者を苦しめることもあります。 でも出さないと商談が前に進みません。 後々、再見積もりできる可能性を残しつつ、関係各所と相談しながら、渋々、数字を作ります。

こうして営業やお客様には喜ばれるけど現場からは迷惑がられる、風呂敷おっさんができあがるわけです。


おっさんはなぜ社内向きの仕事をするのか

「社内向きの仕事 = 政治」と考えて毛嫌いする現場の人は多いと思います。 「なぜ客向きの仕事をしないのか?」と。

そんな社内向きの仕事をするおっさんを毛嫌いする人もいるも多いでしょう。 「ごますりが上手な人が出世するのか?」と。

お客様も大事です。 でも会社はお客様の要望だけ満たしていればよいというものではありません。 究極的には株式会社は株主のものであり、「株主の要望を満たす」ということはあまり語られない現実ですが、会社の大きな使命です。

主要株主の発言権は大きく、主要株主から社長->役員->幹部と落ちてきた要望の対応は会社の重要事項です。 上層部からのオーダーに応える、というのはそういうお仕事です。 ちゃんと対応しないと無理難題を押し付けられたり、いい話を逃したりして、組織の皆が不幸になります。

お客様の方だけ向いて仕事をしてればいい、というのは経営層が作った現場向けのメッセージです。 実際には両方に向き合わあってバランスを取らないと幸せな会社員生活は維持できないのだと気づきます。

加えて、2階層以上、部下がいる管理職や経営者は直属の部下をきつく締め上げる傾向があります。 部下の部下まで把握できない一方で、可能な限り全体を管理・統制したいので身近な部下を締め上げるわけです。 こういう方々の相手にするようになるとより社内向けの仕事が増えます。

こうして社内向きおっさんができあがるわけです。


いずれあなたもおっさんになるのか

以上、言い訳を書き連ねてみました。

あなたもいずれこういうおっさんになる日が来るかもしれません。

そのときはこの不思議なポエムを思い出してください。

OSSを利用した時のソースコード公開リスク

OSSの利用

今どき、OSSの力を借りずにコードを書くことは少ないでしょう。 便利なライブラリ管理機能が充実したこともあり、開発者は自然と自分のコードにOSSを組み込んでいます。

しかしOSSに適用されたライセンスをどこまで意識しているでしょうか。 趣味や学習目的で個人利用している分には問題になることはないかもしれません。 しかし、仕事として開発、配布している場合、大きなリスクが伴います。

ソースコードの公開

Copyleftとは「派生物も同じライセンスで配布すること」という考え方です。 このためCopyleftライセンスの派生物はソースコードの公開を求められることがあります。

ここで気をつけなくてはならないのは、場合によってはOSS部分だけでなく、自社で開発した独自コードも派生物と見做されて公開対象となる点です。 そうなると自社独自の技術、機能、サービスなどが外部に漏れてしまいます。 受託開発していた場合、お客様の情報が公開されてしまいます。 ビジネス上、大きなリスクです。

「派生物」とみなされる条件がライセンスによって異なることが状況を複雑にしています。 法的解釈によっても変わることもさらに事を複雑にしています。

こうしたリスクに対処するため自社製品に組み込まれたOSSの管理を徹底する組織が増えています。 細かいところは専門家の判断や会社のポリシーに準じるべきですが、ビジネス上、安全なライセンスと注意が必要なライセンスくらいは開発者も把握しておくべきです。


安全

Apache

Copyleftがなく、制約が非常に緩いライセンスです。 ソースコード公開は要求されません。 商用利用可です。 コードに含まれる特許が使用者にも適用されます。

BSD

Copyleftがなく、制約が非常に緩いライセンスです。 ソースコード公開は要求されません。 商用利用可です。 4条項、3条項、2条項、0条項と4つのバージョンがあります。

MIT

Copyleftがなく、制約が非常に緩いライセンスです。 ソースコード公開は要求されません。 商用利用可です。

大体安全

CDDL

比較的制約が緩いCopyleftライセンスです。 主にJava向けライセンスとして利用されます。 OSSを改変した場合、改変箇所の公開が必要ですが、独自コードの公開は不要です。 商用利用可です。 コードに含まれる特許が使用者にも適用されます。

EPL、MPL、CPL

比較的制約が緩いCopyleftライセンスです。 OSSを改変した場合、改変箇所の公開が必要ですが、独自コードの公開は不要です。 商用利用可です。

大体安全だが変更は危険

クラスパス例外を含むGPL

比較的制約が緩いCopyleftライセンスです。 主にJava向けライセンスとして利用されます。 Javaライブラリとして利用する分には、独自コードの公開は不要です。 しかしOSSを改変した場合には通常のGPLv2扱いとなり、改変ライブラリをimportした独自コードも公開対象となると考えられます。 商用利用可ですが、改変は避けるべきでしょう。

大体安全だがStatic Linkは危険

LGPLv2

比較的制約が緩いCopyleftライセンスです。 OSSDynamic Linkしたり、Javaライブラリとして利用する分には公開は不要です。 しかしStatic Linkした場合、デバッグ用データ(Object)の公開が必要です。 また、OSSを改変した場合にはGPLv2扱いとなり、改変ライブラリをimportした独自コードも公開対象となると考えられます。 商用利用可ですが、Static Linkは避けた方が無難ですし、改変は避けるべきでしょう。

危険

GPLv2

制約が強いCopyleftライセンスです。 OSSとLink(Dynamic、Static問わず)した独自コードの公開が必要です。 OSSを改変していなくても、です。 商用利用可ですが、多くの場合、避けるべきでしょう。

GPLv3

制約がとても強いCopyleftライセンスです。 GPLv2と基本、同じですが、Tivolization(STBのようなエンドユーザがSW変更不可能な形で配布すること)の禁止や、特許の扱いに関して細かい規定が追加されています。 商用利用可ですが、多くの場合、避けた方が無難でしょう。

Affero GPLv3

制約がとても強いCopyleftライセンスです。 GPLと基本同じですが、クラウドSaaSで利用した場合はソースコードの公開が必要です。 商用利用可ですが、多くの場合、避けた方が無難でしょう。

OSSライセンスを自分のコードに付けてみよう

ライセンスをつけない場合

必ずしもライセンスをつける必要はありません。 ライセンスを付けずに公開されたソフトウェアはパブリックドメイン・ソフトウェアと呼ばれ、フリーソフトウェア扱いになります。 パブリックドメイン・ソフトウェアの利用には一切の制約がありません。

ライセンスをつける意味

ではなぜライセンスをつけるのでしょう?

第1に格好いいからです。 世の中のイケてるソフトウェアは有償無償を問わず皆、ライセンスが付いています。

次に自分の気持ちを利用者に明示的に伝えることができるからです。 自分の時間を割いて開発したコードを利用者がこういう形で利用して欲しい、利用して欲しくない、という気持ちはないでしょうか?

  • 自由だけどお金儲けには使ってほしくない
  • 自由だけどコードを公開してソフトウェアコミュニティに恩返しして欲しい

そんな気持ちをライセンスという形で伝えることができます。

無償ライセンスは自作しない

ライセンスを自作するのは大変です。 有償ならともかく、無償提供するなら既存のOSSライセンスを利用するのが手っ取り早いです。

OSSライセンスの選び方

世の中には無数のOSSライセンスがあります。 色々な考え方がありますが、以下のように考えれば大きく間違ってないと思います。

  1. 特定のOSSのエコシステムに参加したい -> そのOSSと同じライセンス
  2. フリーソフトウェア精神を大事にしたい -> GPLv2
  3. どうでもいい -> 2条項BSDApache

1. 特定のOSSのエコシステムに参加したい

そのままです。 説明不要だと思います。

2. フリーソフトウェア精神を大事にしたい

このようなケースではGPLのようにCopyleftが強いライセンスが有効です。 利用者は自分のコードを公開するという形でソフトウェアコミュニティに恩返しすることが求められます。 GPLの中では今日時点ではGPLv2が最も一般的な選択肢です。 大事な特許を含む場合はGPLv3。 クラウド上での恩返し回避を抑止したい場合はAffero GPLv3。 逆にCopyleftによる抑止力を少し緩めて、利用を促したい場合はLGPLv2などの選択肢があります。 しかし新しいライセンスほど利用者から敬遠される傾向が強いです。 利便性と抑止力のバランスなどを考えて選んでください。

3. どうでもいい

意外と多いのではないでしょうか。 ライセンスなしでもよいかもしれませんが、格好つけるためになにかつけたいところです。 Copyleftがない、Attribute Styleなライセンスが適しています。 手間をかけたくないなら2条項BSDが手軽です。 しかし、BSDには特許に関する記載がありません。 昨今、サブマリン特許等、特許関連の訴訟被害を恐れる人も少なくありません。 広く利用してもらいたいのであれば利用者により安心感を与えられるApacheがよいでしょう。 Apacheにはコードに含まれる特許の使用権を利用者に付与する記載があり、訴訟リスクが低いです。 ユーザの利便性と自分の手間を天秤にかけて選んでください。

4. その他

ここに紹介したOSSライセンスだと合わない、という方は比較的希望に近いライセンスを手がかりに似たOSSライセンスを探してみましょう。


OSSライセンスの適用

以下にOSSライセンスの適用方法を記載します。

GPLv2の場合

1. ライセンスファイル作成

以下のリンクからライセンスファイルを入手し、LICENSE、またはLICENSE.txt等の名前でソースのルートディレクトリに保存します。 ソフトウェア配布時にはライセンスファイルをDocumentationに含めてください。

https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

2. ソースコードへライセンス条項挿入

以下の内容を各ソースコードファイルの先頭に貼り付けます。 <最後に変更された年>は「present」とする人もいます。

/* ===========================================================
 * <ソフトウェア名> : <説明>
 * ===========================================================
 *
 * Copyright (C) <ソースコードが公開された年>-<最後に変更した年>  <制作者名/組織>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, see <https://www.gnu.org/licenses/>.
*/

3. READMEファイル編集

READMEファイルに以下のような文言を記載し、GPLv2が適用されていることを利用者に示します。

The software is licensed under the terms of the GNU General Public License (GPL) version 2.0

2条項BSDの場合

1. ライセンスファイル作成

以下の文言をLICENSE、またはLICENSE.txt等の名前でソースのルートディレクトリに保存します。 ソフトウェア配布時には下記ライセンスファイルをDocumentationに含めてください。

Copyright <ソースコードが公開された年>-<最後に変更した年> <制作者名/組織>

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

2. READMEファイル編集

READMEファイルに以下のような文言を記載し、2条項BSDライセンスが適用されていることを利用者に示します。

The software is licensed under the the BSD 2-clause "Simplified" License.

Apacheの場合

1. ライセンスファイル作成

以下のリンクからライセンスファイルを入手し、LICENSE、またはLICENSE.txt等の名前でソースのルートディレクトリに保存します。 ソフトウェア配布時にはライセンスファイルをDocumentationに含めてください。

https://www.apache.org/licenses/LICENSE-2.0.txt

2. ソースコードへライセンス条項挿入

以下の内容を各ソースコードファイルの先頭に貼り付けます。

/*
 * Copyright <ソースコードが公開された年>-<最後に変更した年> <制作者名/組織>
 *
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

3. NOTICE作成

NOTICE、またはNOTICE.txtに以下のような内容を記載し、ソースのルートディレクトリに配置してください。

<ソフトウェアの名前>
Copyright <ソースコードが公開された年>-<最後に変更した年> <制作者名/組織>

<利用しているOSSの情報>

4. README編集

READMEファイルに以下のような文言を記載し、Apacheライセンスが適用されていることを利用者に示します。

This code is licensed under the Apache License v2.

private networkのEC2インスタンスに踏み台インスタンス経由でアクセスする

Private NetworkはInternet Gatewayがなく、Public IPアドレス割当もない、安全なSubnetです。

外部からのアクセスが必要ないEC2インスタンスはPrivate Networkに構築することが一般的です。

それらEC2インスタンスに管理上の理由で外部からアクセスしたい場合は踏み台インスタンス経由でアクセスします。

今回はPrivate Networkに構築したEC2インスタンスに踏み台インスタンスからSSH接続する手順を紹介します。


Step1 - Private Subnet作成

  • まずはPrivate Subnetを作成します
  • VPC」を開き、画面左メニューから「Subnets」を選択します
  • 既存のIPv4 CIDRをチェックして、空いているCIDRブロックを確認します
  • 「Create subnet」を押下してSubnetを作成します

  • 適切なVPCを選択します
    • 例ではDefault VPCを選択しています
  • Subnet nameを記入します
    • VPC名とAZ名を含めておくと便利です
  • AZとCIDR blockを記入します
    • 例では"us-east-1a"、172.31.96.0/20を記入しています

--

Step2 - NAT Gateway作成(Optional)

  • 次にPrivateインスタンス外部通信用(yum/apt-get等)のNAT Gatewayを作成します
  • 画面左メニューから「NAT gateways」を選択し、「Create NAT gateway」を押下します
  • 「Name」を記入します
  • 「Subnet」はPublic Subnetを選択します
  • 「Connectivity Type」はPublicです
  • Elastic IPを割り当ててください


Step3 - Route Table作成

  • Private Network用のRoute Tableを作成します
  • 画面左メニューから「Route tables」を選択し、「Create route table」を押下します
  • 「Name」と「VPC」を記入して「Create route table」を押下します

  • 「Routes」タブで「Edit routes」を選択します

  • 「Add route」を選択してNAT Gatewayへのルートを追加します

  • 最後に作成したRoute TableをPrivate Subnetに紐付けます
  • 「Subnet associations」タブで「Edit subnet associations」を選択します

  • private networkを選びます


Step4 - EC2インスタンス起動

  • 踏み台用のEC2インスタンスを起動します
    • SubnetはPublic Networkを選択します
    • Security GroupのInbound RuleではSSHを許可します
    • Security GroupのOutbound RuleでSSHを許可します
  • Private NetoworkにEC2インスタンスを起動します
    • SubnetはPrivate Networkを選択します
    • Security GroupのInbound RuleとOutbound RuleではSSHを許可します
  • 具体的な手順についてはこちらの過去記事を参照してください

architecting.hateblo.jp


Step5 - アクセス


後始末

  • 不要になったらNAT gatewayを削除して、Elastic IPを開放することを忘れないようにしましょう

AWSで安全なEC2インスタンスを立ち上げるための鉄則

EC2インスタンスハッカーに攻撃されて乗っ取られたりしたら嫌ですよね。

でも不必要に怖がっていたらクラウドなんて使えないですよね。

必要なのは正しい知識です。

AWSからBest Practiceが提示されているので理解しておきましょう。

aws.amazon.com


管理用SSHアクセスにはEC2 Instance Connectを利用する

  • EC2 Instance Connectの接続はIAMを利用して安全に管理されている
  • 接続元をAWSに限定できるので安全なSecurity Group Inbound Ruleを作成できる

rootユーザによるSSH接続を許容しない

  • AWSが提供するAMIはほとんどrootユーザによるSSH接続を許可していない

SSH接続ではパスワード認証ではなくKey Pairを使用する

  • パスワード認証を無効化することで総当り攻撃などの攻撃を無効化できる
  • AWSが提供するAmazon LinuxのAMIなどはパスワード認証が無効化されている

不明なソースからのアクセスを制限する

  • 自分のPCアドレスや、会社のネットワークなどからのアクセスのみを許可すること
  • EC2 Instance Connectを利用する場合、EC2 Instance Connectが利用するアドレス帯も許可すること

不要なプロトコルへのアクセスを制限する

  • RDP、SSHHTTPS等、必要なポート以外はSecurity GroupのInbound Ruleで制限すること

OSを最新の状態に保つ

  • 以上の全てを実行してもOSやライブラリの脆弱性をつかれてハッキングされるリスクは以前、残っている
  • 既知の脆弱性を防ぐためにもすぐに更新を実行すること
    • sudo yum update

Linux EC2インスタンスを起動してRemote Desktop接続する

前回はLinxu EC2インスタンスSSHで接続する手順を紹介しました。

architecting.hateblo.jp

しかしGUIを利用したいときもあるかと思います。

今回はAmazon LinuxのMATEというデスクトップ環境へRemote Desktopでアクセスする方法を紹介します。

この公式マニュアルがネタ元です。

docs.aws.amazon.com

注意しておきたいのが、xrdpのためにec2-userのパスワード認証を有効にしている点です。

SSHが辞書攻撃を受けても乗っ取られないよう対策してください。

以下に対策の例をいくつか挙げます。

  • Security Groupを使ってEC2 Instance Connect以外からのSSH接続を全て拒否する
  • SSHで証明書を利用する

Step1

  • Security Groupを作成します
  • Outbound Ruleは最初から入力されているので必要に応じて変更してください
  • Inbound RuleでRDP(3389)とSSH(22)を許可します。
    • SSHはxrdpの設定をするために利用します
    • SSHを許可するSecurity Groupの作成については前回の記事を参考にしてください。


Step2

  • LinuxのEC2インスタンスを作成します。
  • MATEデスクトップ環境を含んだAMIを選んでください

  • Key Pairを指定していください
    • Key Pairについては前回の記事を参考にしてください
  • 先程作成したSecurity Groupを選んでRDPとSSHを許可してください

  • 他はデフォルトで大丈夫です。

Step3

  • EC2インスタンスが起動したらEC2 Instance ConnectでSSH接続してください
    • EC2 Instance Connectで接続する手順については前回の記事を参考にしてください
  • まずはOSを最新化してください
    • sudo yum update
    • sudo reboot

Step4

  • xrdpを設定します
  • ec2-userのパスワードを設定してください
    • sudo passwd ec2-user
  • 証明書を作成して、公開鍵を/etc/xrdp/key.pemに、証明書を/etc/xrdp/cert.pemに配置してください

  • xrdpサービスが有効になっていることを確認してください
    • systemctl status xrdp

Step5

  • Remote Desktopクライアントを使って接続してください

Linux EC2インスタンスを起動してSSH接続する

LinuxのEC2インスタンスを作成してSSH接続しましょう。


Step1

  • Security Groupを作成します
    • 悪意のある攻撃を避けるため、EC2インスタンスに通信できるアドレスを制限します
  • Outbound Ruleは最初から入力されているので必要に応じて変更してください
  • Inbound RuleでSSHを許可します。
  • Inbound Ruleにはは以下の2つソースを指定するとよいでしょう
    • EC2インスタンスSSH接続するPCのアドレス
    • Instance Connectで使用されるアドレス
      • Tokyo Region: 3.112.23.0/29
      • North Virginia Region: 18.206.107.24/29


Step2

  • Key Pairをまだ作成していない場合は作成します
  • 作成するとpemファイルがダウンロードされるので失くさないよう大事に保管します


Step3


Step4

  • EC2インスタンスがRunning状態になったらチェックして「Connect」を押下します


Step5a - EC2 Instance Connectの場合

  • EC2 Instance Connectタブで「Connect」を押下します


Step5b - PCからSSH接続する場合

  • SSH clientタブを選択します
  • 表示されたsshコマンドをコピーします

  • Terminalを開いてKey Pairのpemファイルが保存されているフォルダに移動します
  • pemファイルのPermissionを変更していない場合は変更します
  • 先程コピーしたsshコマンドを実行すると接続されます