20200602のAWSに関する記事は13件です。

AWSのロードバランサーにLambdaを使ってWEBサーバーを自動追加

目的:アクセス集中時のみWEBサーバーを追加・負荷分散しコストダウン

 AWSのロードバランサー(ELB)を使っているサイトも多いかと思われます。ELBにはオートスケール機能があり、負荷率の上昇などをトリガーとしてスケールアウト(WEBサーバーの追加)を設定することができます。

 しかし、Auto Scalingを利用して負荷が上がってからWEBサーバーを立ち上げて追加したのでは時間がかかり、手遅れになる可能性が高いです。障害が出る前にサーバーを増設したいと思うでしょう。

 私の会社が開発しているソーシャルゲームでも、イベント開催時や広告プロモーション時には、普段の十数倍のアクセスになります。こういう負荷上昇が見込まれる場合は、あらかじめEC2インスタンスを立ち上げてELBに追加しておくことが有効でしょう。

 Lambdaのスケジュール機能を使い、アクセスの見込まれる必要な時刻にEC2インスタンス(WEBサーバー)をELBに自動的に追加し、ある程度の時間が過ぎたらELBから切り離す。これだけでは負荷分散はできてもコスト削減はできません。コスト削減のためには、EC2インスタンスを停止しなくてはなりません。EC2インスタンスの自動起動とELBに追加、ELBからの切り離しとシャットダウンが必要です。

 下記の記事リンクでLambdaを使ってEC2インスタンスの自動起動のやりかたを説明しましたので、これとあわせて設定することが必要です。
   AWSのEC2サーバーをLambdaを使って自動起動

前提条件

 すでにロードバランサー(ELBv2)を使用して、ターゲットグループにインスタンス(WEBサーバー)を追加済みで、WEBアクセスを分散している前提です。ピークにあわせて、インスタンスをターゲットグループに自動的に追加するというスクリプト関数を設定します。
 インスタンスは既に構築済みというのが、AWSのオートスケール機能と違うところです。つまり、あらかじめインスタンスを作成しておき、このインスタンスをロードバランサーに加えるというスクリプトを作ります。

AWS Lambdaコンソールで関数を作成しロールを付与

 Lambdaコンソールで関数を作成します。以前作成したEC2サーバーの起動とは別の関数名「Add_elb」にします。

Image1.jpg

アクセス権限をクリックし、ロードバランサーのターゲットグループにEC2インスタンスを追加・削除できる権限(ロール)を付与します。
IAMマネージャーから、追加のサービスポリシーを登録します。サービスを最初に選択しますが、ELBには、初期の「ELB」と、「ELB v2」があるので、「ELB v2」の方を選択します。
 次にアクションを「register」で検索すると、「DeregisterTargets」「RegisterTargets」が表示されます。これはそれぞれ、ロードバランサーのターゲットグループにインスタンスを「削除」「登録」できる権限を与えます。

Image1.jpg

EC2インスタンスをロードバランサーに追加するスクリプト

ロールの設定が終わったら、Lambdaの関数の表示する画面に戻り、下記のようにindex.jsの関数コードを書き換えます。

index.js
const INSTANCE_ID = ['i-0b1ec8e45xx6293a9','i-0a3393fcxxb68a626','i-0b01xx0783bef752d']

const ARN = "arn:aws:elasticloadbalancing:ap-northeast-1:371633xx9153:targetgroup/web/e6cccc2a33xx2c4"; // ターゲットグループ「web」

var AWS = require('aws-sdk'); 
AWS.config.region = 'ap-northeast-1';

exports.handler = function(event, context) {
    var elbv2 = new AWS.ELBv2();
    var params = {
        TargetGroupArn: ARN, 
        Targets: [ {Id: 'dummy' }]
    };
    console.log('Script Start!');

   for (let i = 0; i < INSTANCE_ID.length; i++) {
       params.Targets[i] = {Id: INSTANCE_ID[i]};
   }

    elbv2.registerTargets(params, function(err, data) {
        if (!!err) {
            console.log(err, err.stack);
        } else {
            console.log(data);
        }
    });
};

 ELBに登録するインスタンスは、下記のように複数指定することが可能ですので、同時に複数のインスタンスの追加ができます。

const INSTANCE_ID = ['i-052838b19d5xxxxx1', 'i-052838b19d5xxxxx2', 'i-052838b19d5xxxxx3']; 

 ターゲットグループの指定は、AWSのEC2>ロードバランシング>ターゲットグループでターゲット名を選択すると、arn:で始まるターゲットグループ名が表示されるので、コピーして転記します。

const ARN = "arn:aws:elasticloadbalancing:ap-northeast-1:371633xx9153:targetgroup/web/e6cccc2a33xx2c4";

設定が終わったら、コード上部の「Save」または右上の「保存」をクリックし、「Test」または「テスト」をクリックします。
 実行結果でエラーが出なければ正常ですので、ターゲットグループに指定したインスタンスが追加されているか確認してみてください。

ロードバランサーからWEBサーバーを自動解除

 逆にロードバランサーからWEBサーバーを切り離すには、違う名前で例えば「Del_elb」という名前の関数スクリプトを作り、上記のスクリプトをコピー。「elbv2.registerTargets」のメゾットの行を次のように書き換えるだけです。パラメータは同じなので、「registerTargets」か「deregisterTargets」の違いだけです。

    elbv2.deregisterTargets(params, function(err, data) {

実際の運用

 先の私の記事リンクで作成した関数とあわせて運用を計画してください。

AWSのEC2サーバーをLambdaを使って自動起動

 実際の流れとしては、イベントやプロモーションの開始時間にあわせて、あらかじめ予備サーバーをスタンバイ(停止)しておき、CloudWatch/Eventで時刻になったら各関数を起動するようにCRONでスケジューリングします。
EC2インスタンスの起動に1分、最新ソースのデプロイ(更新)に最大2分程度を見込んだスケジュールです。

-開始時間5分前に予備サーバーを起動。起動スクリプトで最新ソースプログラムをデプロイ(更新反映)
-開始時間になったらロードバランサーに予備サーバーを追加
-(予備サーバーを含め負荷上昇に対して運用)
-終了時間になったらロードバランサーから予備サーバーを外す
-終了時間1分後に予備サーバーをシャットダウン

これで予定された負荷上昇への対応が自動化でき、予備サーバーは通常はインスタンスを停止しておけるので、コスト削減にも貢献できます。

もちろん負荷対応はWEBサーバーだけでは無いですが。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS SAP】Amazon Kinesis StreamsとAmazon Kinesis Firehoseの違い【頻出】

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第2弾

以下用語の違いについては押さえておいて損はありません。

・Amazon Kinesis Data Streams (KDS)
・Amazon Kinesis Data Firehose

Amazon Kinesis Data Streamsとは

(公式サイトより引用)

Amazon Kinesis Data Streams (KDS) は、大規模にスケーラブルで持続的なリアルタイムのデータストリーミングサービスです。KDS はウエブサイトクリックストリームやデータべースイベントストリームや金融取引、ソーシャルメディアフィード、ITロゴ、ロケーション追跡イベントなど何十万ものソースから毎秒ギガバイトのデータを継続してキャプチャできます。収集データはミリ秒で入手でき、リアルタイム分析をリアルタイムダッシュボードやリアルタイム異常検知、ダイナミックな価格設定などの事例に利用可能です。

Amazon Kinesis Data Firehoseとは

(公式サイトにより引用)

Amazon Kinesis Data Firehose は、ストリーミングデータをデータレイクやデータストア、分析ツールに確実にロードする最も簡単な方法です。ストリーミングデータをキャプチャして変換し、Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk にロードして、現在お使いのビジネスインテリジェンスツールやダッシュボードでほぼリアルタイムに分析できます。完全マネージド型サービスのため、データスループットに応じて自動的にスケールされ、継続的な管理は不要です。ロード前にデータのバッチ処理、圧縮、変換、暗号化が行われるため、送信先でのストレージ量を最小化し、セキュリティを強化できます。

Amazon Kinesis StreamsとAmazon Kinesis Firehoseの違い

どちらも大量のデータを高速に別のサービスに転送するためのサービス。
違いについては、以下サイトがとても分かりやすかったです。
https://dev.classmethod.jp/articles/difference-between-kinesis-streams-and-kinesis-firehose/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Lambda関数の通信先を制御してみる。

(記事を書いた2019/12/21に公開するのを忘れ半年遅れで公開となりました)

はじめに

皆さんは AWS Lambda でどのような処理を実装されていますか? AWS サービスの API (例えば、 Systems Manager の Parameter Store の API や Amazon EC2 の API )、外部のサービスにアクセスさせたりしていますか?
企業向けシステムを構築する際には、「通信先」について情報漏洩リスクにもつながるため、関心事として高いです。
当記事では、AWS Lambda 関数を利用してアプリケーションを実装する際、どのように通信先を制御を「強制するか」紹介していきたいと思います。

サマリ

  • デフォルトの Lambda 関数構成(VPC内リソースにアクセスしない)の場合、Lambda 関数に Security Group も NACL も設定できず、Lambda 関数からの通信を Lambda 関数の外で制御することができない。
  • VPC 内リソースにアクセス可能なLambda関数として構成することで、 VPC の仕組みを利用した通信先の制御が Lambda 関数の外(ロジックではなく設定)で可能になる。
  • VPC 内リソースにアクセス可能なLambdaについてはこちら

AWS Lambda 関数の起動と外部との通信

私が初めて Lambda 関数を実装したときの機能は以下を含んだものでした。

  • Lambda 関数が受け取ったデータを処理して応答する
  • データ処理をする際に外部サイトを呼び出す
  • データ処理結果を Amazon DynamoDB に格納する

上記全て問題なく実装でき動作もしました。
デフォルトの構成でアプリケーションを実装すると「どこにでも通信が可能」なのです。どこにでもというのは、インターネットに公開されたエンドポイントであればどこにでもという意味です。

これは、企業のネットワークやセキュリティ担当者からすると以下の点(それ以外にもあるかもしれませんが)が気になる点になるかと思います。
1. 受け取ったデータは安全なデータか
2. 外部サイトへのアクセスはログが残るのか
3. 許可された外部サイトにのみアクセスが行われているか

善良な開発者がプログラムを開発し、開発者とは別のレビュアやツールによってレビューが適切に行われ通信先を含め確認をすることも可能ではありますが、動的に設定される情報等で通信先が変わることもありえます。また、仮に人に頼ったレビューであれば、日々、リファクタリングやフィードバックをもとにした改善をしている場合、開発スピードの低下やレビュー漏れも発生する可能性があります。ですから静的なレビューだけではなく実行時に通信先を制御し、モニタリングし監査できる情報を確保すること重要(重要度は、そのシステムが取り扱う「情報」の重要度等に依存)になります。

そこで、今回は私が作った上記の特徴を持つアプリを例に、前述の
2. 外部サイトへのアクセスはログが残るのか
3. 許可された外部サイトにのみアクセスが行われているか
について触れていきたいと思います。

当記事における外部の定義

まずは当記事における「外部」の定義を行いたいと思います。外部の反対は「内部」となるため、内部と外部の定義をすることになります。
当記事における「外部」は「該当のLambda関数の所有者が所有または管理するネットワーク外に出る通信」を外部と定義し、「所有または管理するネットワーク内に留まる通信」は内部と定義します。

例:
- 経路が外部に該当するものはすべて外部です。
- 片方のリソースが外部ネットワークにある物も全て外部です。

FROM 中間経路 TOリソース  定義 
内部 内部 内部 内部
内部 内部 外部 外部
内部 外部 内部 外部
外部 内部 内部 外部

AWSでは、VPC(Virtual Private Cloud)というサービスがありAmazon EC2, Amazon ECS Amazon RDS, Amazon Redshiftなどのリソースを配置することができます。そしてオンプレミスのデータセンターとの専用線接続する最終的なあて先としても利用できます。

このVPCはAWSアカウント所有者でルーティングの制御ができます。また、仮想ファイヤーウォールでもあるSecurity GroupやNACL(Network Access Control List)でInbound/Outboundの制御が可能になっています。

つまり、アプリケーション用に構築したEC2やContainerがどこから通信を受けることができどこに通信可能か制御が可能になっています。つまり、VPC内で通信を行うこと、あるいは、所有者が管理する複数のVPCやオンプレミスとの専用線接続に限定して通信を許可すれば、当記事における「内部」だけに通信先を限定することがとして位置づけられるものになります。

 なお、余談ですが、2019年12月3日に発表されたVPC Ingress Routingという機能を利用すると、VPC内に入ってきたパケットの宛先を強制的に特定のENIにルーティングし、処理した上で、最終の宛先に特定するという制御も可能になっています。

VPCによる通信先制御

Lambda関数には、各関数ごとにVPC 内のリソースにアクセスするように Lambda 関数を設定することが可能になっています。
 詳細の解説はこちらの記事にあります。
 AWS LambdaのLambda関数はデフォルトでは、所有者のVPC内の制御の影響は受けませんが、VPC内のリソースにアクセスしたい場合や、VPCによる通信先制御を利用したい場合に有効化することでSecurity Group/NACLといった仮想ファイヤーウォールによるOutbound通信の制御や名前解決、そして、VPC Route Tableによる通信宛先の制御が可能となります。

 セキュリティでは予防的な統制や発見的な統制、訂正的な統制という考え方がありますが、VPCによるRoute Table/Security Group/NACLのように事前に予防策として防ぐことがこれで可能となります。さらにVPCでは、 VPC Flow Logsトラフィックミラーリングの機能も利用可能となるため、モニタリング、そして、モニタリング結果から分析や異常の検知・対応等のアクションも可能となります。

VPC 内のリソースにアクセスするように Lambda 関数 はアンチパターンなのか

2019年9月末(東京リージョン)以降、私はアンチパターンではないと考えます。これ以前は、アンチパターンでした。理由は、「VPC 内のリソースにアクセスするように Lambda 関数を設定する」を有効化することで、関数の起動時にVPC内にENIが作成されるようになるのですが、その作成時間が10秒以上かかり応答が遅延していたためでした。ただ、こちらの改善により、関数作成時(起動時ではない) にENIが作成されるようになったことや共有されるようになったことで起動時のペナルティが大幅に改善されたのです。これにより、”アンチ” ではなく、セキュアな通信を強制する場合の ”標準” になったと私は考えます

まとめ

AWS Lambdaの各Lambda関数の通信先については、VPCの仕組み(Route Table/NACL/Security Groupやログ)を活用することで予防・ロギング・モニタリングが可能となります。Lambda関数内ロジックではなく、VPCの設定で対応をすることで、関数開発者と別の役割の人が制御することになり権限分離も可能となりよりセキュアな状態になると考えます。
2019年9月(東京リージョン)以降はVPC内にアクセスするLambda関数に対する起動時のペナルティも大幅な改善がされておりますので、ご検討ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

LambdaからEC2を起動しようとしてハマった話

AWS公式ページにこちらの手順に従って、LambdaからEC2を停止&起動させようとしたところ、停止はできるが起動はなぜかうまくいかない。。。

Lambda を使用して、Amazon EC2 インスタンスを一定の間隔で停止および起動するにはどうすればよいですか?

色々試したり、サポートに問い合わせしたりした結果、原因が判明。

KMS関連の権限が不足していたためでした。
起動しようとしていたEC2にアタッチされているEBSがKMSで暗号化されていたため、kms:CreateGrant 権限が必要だったようです。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS SAP】AWS KMS と CloudHSMの違い【頻出】

AWS SAP取得に向けて勉強する中で覚えてよかったもの

以下用語の違いについては押さえておいて損はありません。

・AWS KMS
・CloudHSM

AWS KMSとは

AWS Key Management Serviceの略称。
(公式サイトにより引用)

AWS Key Management Service (KMS) を使用することで、暗号化キーを簡単に作成して管理し、幅広い AWS のサービスやアプリケーションでの使用を制御できるようになります。AWS KMS はセキュアで弾力性の高いサービスで、キーを保護するために FIPS 140-2 の検証済みまたは検証段階のハードウェアセキュリティモジュールを使用します。AWS KMS は AWS CloudTrail と統合されており、すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立ちます。

CloudHSMとは

AWS Cloud でのマネージド型ハードウェアセキュリティモジュール (HSM) のことを指します。
(公式サイトより引用)

AWS CloudHSM は、クラウドベースのハードウェアセキュリティモジュール (HSM) です。これにより、AWS クラウドで暗号化キーを簡単に生成して使用できるようになります。CloudHSM で、FIPS 140-2 のレベル 3 認証済みの HSM を使用して、暗号化キーを管理できます。CloudHSM によって、PKCS#11、Java Cryptography Extensions (JCE)、Microsoft CryptoNG (CNG) ライブラリといった業界標準の API を使用して、アプリケーションを柔軟に統合できます。

AWS KMSとCloudHSMの違いは?

■AWS KMS
AWS管理のサーバを共有で利用し、そこで暗号化キーを管理します。
システム的に他の組織へのアクセス制限はされていますが、物理的には同じサーバ上に存在します。
CloudHSMに比べると安価に利用することができます。

■CloudHSM
専用のハードウェアで暗号化キーを保管します。
CloudHSMの方がより安心してキーを管理することが可能です。
KMSに比べると高価です。

参考)
Q: AWS KMS と AWS CloudHSM にはどのような違いがありますか?
https://aws.amazon.com/jp/kms/faqs/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Lambda@Edgeで追加したいhttpヘッダをapacheの設定から持ってくる

httpd.conf → Lambda@Edge

私のサイト devel.keys.jp は、昼間は EC2 上の Apache httpd で動かしているんですが、夜中は S3 + CloudFront でホストするようにしています11

というときに、S3 でも httpd と同じヘッダを加えたいなーと思って作りました。

EC2 の httpd の設定は次のようなものです:

httpd.conf
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options nosniff
    Header append X-Frame-Options SAMEORIGIN
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

これを実現するには CloudFront の Lambda@Edge を使って、Viewer ResponseOrigin Response の両方をトリガー2にして動かす、次のような Python の Lambda を書きます。(JavaScriptで書く場合は、Amazon提供のチュートリアルを見てください)

lambda_function.py
def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']

    if int(response['status']) == 200:
        response['headers']['strict-transport-security'] = [{'key': 'Strict-Transport-Security', 'value': 'max-age= 63072000; includeSubdomains; preload'}]
        response['headers']['x-content-type-options'] = [{'key': 'X-Content-Type-Options', 'value': 'nosniff'}]
        response['headers']['x-frame-options'] = [{'key': 'X-Frame-Options', 'value': 'SAMEORIGIN'}]
        response['headers']['x-xss-protection'] = [{'key': 'X-XSS-Protection', 'value': '1; mode=block'}]

    return response

一度設定したヘッダを変えることはほとんどないと思うんですが、せっかくなので3これを自動化する Perl スクリプトを書きました。

lambda_header_convert.pl
#!/usr/bin/perl
while (<>) {
    s/^\s*(.*?)\s*$/$1/;
    if ( /^Header\s+(set|append)\s+([\w-]+)\s+"?([^"]+)"?$/ ) {
        my $h_key = lc($2);
        print "response['headers']['$h_key'] = "[{'key': '$2', 'value': '$3'}]\n";
    }
}

よくテストしていないので、実際に使ってみたいという人はテストをお忘れなく!


  1. 無料枠が月750時間までだと24時間動かしていると他のインスタンスを立てにくいので、1〜7時までインスタンスを落として無料枠をセーブしているのです 

  2. CloudFront のキャッシュにヒットしたときは Viewer Response が、キャッシュミスした場合は Origin Response が、それぞれトリガーとして動くようになっている(らしい)です。参考: CloudFront Events That Can Trigger a Lambda Function 

  3. 最近 Perl のコードを書いてないので書きたくなって、理由を付けて書いてみました 

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Cloud9の良さを伝えたい。

プログラミングをする上で大事なのはエディタですよね。
エディタは、VScodeやAtom,Sublime Textなど色々あって何を使えばいいかわからない人など多いと思います。
今回は僕のおすすめのAWS Cloud9の良さを紹介します!!

AWS Cloud9とは

AWS Cloud9はもともと c9.io で運営されていたサービスをAWSが買収したもので、ウェブブラウザ上で開発ができるクラウドIDE(統合開発環境)です。
言語も多くの言語に対応していて、

  • C++
  • C#
  • Go
  • HTML
  • Java
  • JavaScript
  • Node.js
  • Ruby
  • PHP
  • Python

など様々な言語に対応しており、ここに記載していない言語もあります。(対応言語リスト)

またエディタ部分はAceを使用しているため、Sublime風なエディタなどに変更ができます。
(Sublimeを使用していた僕にとってはすごく嬉しい。)

クラウドIDE

クラウドIDEは、ウェブブラウザで開発ができる開発環境のことで、環境構築など一切不要のため初心者の方でも簡単に始めることができるのがメリットです。

AWS Cloud9以外にもクラウドIDEサービスはたくさんあって、有名なのだとcodeanywhereEclipse Cheなどがあります

AWS Cloud9のメリット

  • ウェブブラウザ上で開発が可能で全世界どのパソコンからもアクセスが可能になります。
    もしパソコンが壊れてしまったりしても新しいパソコンから開発環境にアクセスが可能です。

  • 1分程度で新規のプロジェクトの作成が可能。
    プロジェクトの名前やOSの選択、インスタンスサイズを指定するだけでプロジェクトが作れます。

  • 環境構築が不要で最初からRubyやPythonなどがインストールされている

  • マルチ開発が可能で、チームなどで同じエディタを共有することが可能です。
    リアルタイムに入力しているコードが反映されるのでチームでの開発に便利です。

  • AWSのSDKであればAPIなどの設定をしなくても使用することが可能です。

AWS Cloud9のデメリット

流石にメリットだけ書くのは...あれなので、、、個人的に思ったデメリットです...

  • インターネットが必要。これはクラウドIDE全部に言えることなのですが、インターネットが必要です。デザリングなどのスピードでは快適に使用できますが、飛行機などのインターネットなどは少し厳しいです。

  • カメラが使えない。これもクラウドIDE全部に言えることですが、PCのカメラが使えません。WebRTCなどを使って映像を送れば使えるのですが、めんどくさいので僕の場合はローカルで開発をするか動画ファイルをワークスペースにあげて使っています。

  • Vue.jsとNode.jsなど同時に開発するのが大変。ポートを複数使ったサービスなどは少しめんどくさいです。。。

  • マルチ開発をする場合にアクセスする人のIAMユーザを作成しないといけない。 c9.ioよりマルチ開発がめんどくさくなってしまったのはちょっと悲しかったです。個人のAWSアカウントに友達のIAMユーザを作成するのに抵抗があるため僕はデメリットだと思いました。

Cloud9 Core

実は、Cloud9はGithub上にソースコードが公開されおり、自分のサーバなどに簡単に構築が可能です。
Cloud9はバックエンドがnode.jsで作成されているので、Cloud9 coreをベースに自分風のクラウドIDEの作成が可能です。

https://github.com/c9/core

個人的に言いたいこと

AWSを使っていない人から見るとAWS高そうなどのイメージがあると思いますが、サーバ代(EC2)しかかからず、使用していない時間はサーバを止める機能などがついているのですごく安く使えます。(12ヶ月の無料枠内であれば、t2.microを使用することで月/750時間は無料で使うことができます!)

AWSアカウントを使用しているなら1分もかからずワークスペースを作成できるので、一度は使ってみるといいと思います。最初から言語がインストールされていたり、テンプレートなどが用意されていてすぐに開発ができます!!

ちょっとでも興味をもったら使って見ましょう!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

高校生がCloud9の良さを伝えたい。

プログラミングをする上で大事なのはエディタですよね。
エディタは、VScodeやAtom,Sublime Textなど色々あって何を使えばいいかわからない人など多いと思います。
今回は僕のおすすめのAWS Cloud9の良さを紹介します!!

AWS Cloud9とは

AWS Cloud9はもともと c9.io で運営されていたサービスをAWSが買収したもので、ウェブブラウザ上で開発ができるクラウドIDE(統合開発環境)です。
言語も多くの言語に対応していて、

  • C++
  • C#
  • Go
  • HTML
  • Java
  • JavaScript
  • Node.js
  • Ruby
  • PHP
  • Python

など様々な言語に対応しており、ここに記載していない言語もあります。(対応言語リスト)

またエディタ部分はAceを使用しているため、Sublime風なエディタなどに変更ができます。
(Sublimeを使用していた僕にとってはすごく嬉しい。)

クラウドIDE

クラウドIDEは、ウェブブラウザで開発ができる開発環境のことで、環境構築など一切不要のため初心者の方でも簡単に始めることができるのがメリットです。

AWS Cloud9以外にもクラウドIDEサービスはたくさんあって、有名なのだとcodeanywhereEclipse Cheなどがあります

AWS Cloud9のメリット

  • ウェブブラウザ上で開発が可能で全世界どのパソコンからもアクセスが可能になります。
    もしパソコンが壊れてしまったりしても新しいパソコンから開発環境にアクセスが可能です。

  • 1分程度で新規のプロジェクトの作成が可能。
    プロジェクトの名前やOSの選択、インスタンスサイズを指定するだけでプロジェクトが作れます。

  • 環境構築が不要で最初からRubyやPythonなどがインストールされている

  • マルチ開発が可能で、チームなどで同じエディタを共有することが可能です。
    リアルタイムに入力しているコードが反映されるのでチームでの開発に便利です。

  • AWSのSDKであればAPIなどの設定をしなくても使用することが可能です。

AWS Cloud9のデメリット

流石にメリットだけ書くのは...あれなので、、、個人的に思ったデメリットです...

  • インターネットが必要。これはクラウドIDE全部に言えることなのですが、インターネットが必要です。デザリングなどのスピードでは快適に使用できますが、飛行機などのインターネットなどは少し厳しいです。

  • カメラが使えない。これもクラウドIDE全部に言えることですが、PCのカメラが使えません。WebRTCなどを使って映像を送れば使えるのですが、めんどくさいので僕の場合はローカルで開発をするか動画ファイルをワークスペースにあげて使っています。

  • Vue.jsとNode.jsなど同時に開発するのが大変。ポートを複数使ったサービスなどは少しめんどくさいです。。。

  • マルチ開発をする場合にアクセスする人のIAMユーザを作成しないといけない。 c9.ioよりマルチ開発がめんどくさくなってしまったのはちょっと悲しかったです。個人のAWSアカウントに友達のIAMユーザを作成するのに抵抗があるため僕はデメリットだと思いました。

Cloud9 Core

実は、Cloud9はGithub上にソースコードが公開されおり、自分のサーバなどに簡単に構築が可能です。
Cloud9はバックエンドがnode.jsで作成されているので、Cloud9 coreをベースに自分風のクラウドIDEの作成が可能です。

https://github.com/c9/core

個人的に言いたいこと

AWSを使っていない人から見るとAWS高そうなどのイメージがあると思いますが、サーバ代(EC2)しかかからず、使用していない時間はサーバを止める機能などがついているのですごく安く使えます。(12ヶ月の無料枠内であれば、t2.microを使用することで月/750時間は無料で使うことができます!)

AWSアカウントを使用しているなら1分もかからずワークスペースを作成できるので、一度は使ってみるといいと思います。最初から言語がインストールされていたり、テンプレートなどが用意されていてすぐに開発ができます!!

ちょっとでも興味をもったら使って見ましょう!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSリソースのパスワード等を、AWS上で管理する

何をしたいか

AWSで使用するDBパスワードなどの情報を、外部のパスワード管理ツールや、ましてやコード上で管理せずに、AWSサービスで管理するお話です。
今回はEC2サーバー内から利用するケースで考えます

EC2で必要とするパスワード、パラメータ

こんなものがあるかと思う

RDS, Aurora
・マスターパスワード
・ユーザーログイン情報
・エンドポイントなどの接続情報

EC2等
・OS内での保存しておきたいconfファイル
・接続情報

ユースケース

EC2から、RDSへMySQLログインする
ミドルウェア等の設定値を保存しておきたい
etc

どこで管理するのか

AWS Systems Managerのパラメータストアを使う

必要なプロセス

踏み台サーバーからRDSへアクセスするケースで考える

200531_2.png

EC2に必要なRoleを当てる

SSMへのアクセスが必要なインスタンスに、Roleをアタッチする

200531_3.png

EC2の場合、以下のポリシーをアタッチ

SSMへの必要な権限(権限を絞る場合)
※リソースもパスでもっと絞れる

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ssm:DescribeParameters",
            "Resource": "*"
        }
    ]
}

パスワードや設定値をパラメーターストアに保存する

200531_4.png
図の赤線はCLIの場合

コンソールの場合

SystemsManager > パラメータストア

スクリーンショット 2020-05-30 18.41.04.png
こんな画面で作成

設定項目に関して

利用枠
4KBもあれば、JSONパラメータをまるっと保存しても、まあまあ足りる気はするが、8KBに拡張することもできる。
この「詳細」を選択した場合の料金は、パラメータストア APIインタラクション1万回毎に、0.05USD

タイプ
「安全な文字列」は、AWSのKMSというサービスを使った
キーでの暗号化がされる
KMSのキーは、AWS管理のキーか、自身で管理したキーで暗号化するか選べる

CLIの場合の設定例

・パラメータストアに値を保存
※ "ssm:PutParameter" Actionの許可が別途必要

aws ssm put-parameter --name /sample/database/master/user --type "String" --value "user" --description "master username" --region ap-northeast-1

今回はRDSのユーザ名とする
名前:/sample/database/master/user
値:user
説明:master username

使うとき

200531_5.png

・パラメータの取得

aws ssm describe-parameters --filters "Key=Name, Values=/sample/database/master/user" --region ap-northeast-1

因みに今回は「タイプ」をStringで保存したが、暗号化した場合は"kms:Decrypt"の権限も必要。

運用のコツ

パスの管理

パラメータストアの管理は、システムの環境構成によって階層化した保存をしておくと
運用する際や、実際に引っ張ってくるときにとても楽


環境名/サーバー名/・・・
/Dev/DBServer/MySQL/db-string
/Stg/DBServer/MySQL/db-string

IAM Policyの話

使い慣れたら良いのですが、はじめからActionやResourceを絞ると大変な場合もあるので
はじめは緩めに作ってから、権限を絞るのが無難かもしれません。

SSMの良いところ

今回はパラメータストアだけ挙げましたが、安いし、運用面やセキュリティの観点でたくさんのメリットがあります。
さらに他のAWSサービスとの連携も容易で、例えばCloudFormationでテンプレートを流す際に使用することも可能です。

またちょいちょいメモしていきます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS -bash: rbenv: コマンドが見つかりませんと表示された時の対処法

rbenvのインストール

EC2にrootユーザでログインしている状態で、rbenvをインストールするために、以下を行いました。

1. 以下のコマンドをターミナルにて実行

git clone https://github.com/rbenv/rbenv.git /usr/local/rbenv

2. vi /etc/profile.d/rbenv.shにて開いたファイルに、以下を記述

export RBENV_ROOT=/usr/local/rbenv

export PATH="$RBENV_ROOT/bin:$PATH"
eval "$(rbenv init -)"

3. :wqにて保存
4. source /etc/profile.d/rbenv.shコマンドの実行 ←ここの時点で-bash: rbenv: コマンドが見つかりませんと表示されてしまいます。

解決策:
cd/usr/localのコマンドで、usr/localへ移動する。
lsコマンドでファイルの情報を確認。

bin  etc  games  include  lib  lib64  libexec  rbenv?  sbin  share  src

rbenv?となっており、正しくrbenvがインストールできていなかった。
mv rbenv? rbenvコマンドで、rbenv?を削除し、rbenvを追加。
その後、rbenvコマンドが実行できました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS EC2で環境構築メモ(初期設定編)

特に変わったことはないですが、個人的な健忘録として。

操作環境

Windows10 19H1
Terminal (Preview)@PowerShell Core

AWSの無料アカウントを作成する

特に苦労することなく作れると思います

EC2インスタンスを作成

無料枠で作成した
東京リージョン
t2.micro
Amazon Linux 2 AMI
30GB ディスク

キーペアを作成

(適当な名前).pemをダウンロード
C:\Users\ユーザー名\Documents
に置く。

SSH接続

Terminal (Preview)を起動
ssh -i "(適当な名前).pem" ec2-user@パブリック DNS (IPv4)
(インスタンスの作成の右にある接続ボタンから参照可能)
でログイン

初期設定

#パッケージ更新
$ sudo yum update
#タイムゾーン変更(UTCからJST)
$  timedatectl status
$  sudo timedatectl set-timezone Asia/Tokyo
#日本語ロケール
$  localectl status
$  sudo localectl set-locale LANG=ja_JP.UTF-8
$  sudo localectl set-keymap jp106

ログインユーザー変更

デフォルトのec2-userから変更(ここではtanuki3に変更する)

#ユーザー追加
$sudo  useradd tanuki3
#sudo権限の付与
$  sudo usermod -G wheel tanuki3
#ちゃんと出来ているか確認
$ grep wheel /etc/group
#/etc/sudoersの設定
$ sudo visudo
  #一番下の行に追加
 newuser ALL=(ALL) NOPASSWD: ALL

SSHでログインできるようにする

#ec2-userのauthorized_keysをtanuki3の.sshディレクトリにコピー
$ sudo rsync -a ~/.ssh/authorized_keys ~tanuki3/.ssh/
#必要なパーミッションの設定
$ sudo chown -R tanuki3:tanuki3 ~tanuki3/.ssh
$ sudo chmod -R go-rwx ~tanuki3/.ssh
#sudoがちゃんと出来るか確認
$ sudo su - tanuki3
$ sudo -s

ec2-userの無効化

#/etc/ssh/sshd_configの設定でec2-userのsshログインを禁止
$ sudo vi /etc/ssh/sshd_config
 #一番下の行に追加
 DenyUsers ec2-user
#/etc/ssh/sshd_config設定の反映
$ sudo service sshd reload

sshdのLISTENポート変更

デフォルトのまま(ポート:22)だと危ないので、ポートを適当なものに変更(ここでは10022に変更)

#/etc/ssh/sshd_configの編集
Port 22  #追加
Port 10022  #追加
#設定反映
$ sudo service sshd reload

一旦終了

$ exit

EC2 Management Console→セキュリティグループからポートを追加

・一旦ポート:22は残しておく
・ポート:10022を追加

Terminal Previewにて新しいポートでSSH接続

$  ssh -i "(適当な名前).pem" ec2-user@パブリック DNS (IPv4) -p 10022

接続が確認できたらポート:22を塞ぐ

#/etc/ssh/sshd_configの編集
Port 22  #削除
#設定反映
$ sudo service sshd reload

EC2 Management Console→セキュリティグループからポートを削除

・ポート:22を削除

参考

https://qiita.com/yangci/items/ef2ab9b6f0d28bad0881
https://qiita.com/nekonoprotocol/items/e1fc5c212bf6a7365f8f

なお、SSH周りで失敗すると大変です(もしなった場合はこちらを)

https://qiita.com/hardreggaecafe/items/de9bac1d9ba42f25378e

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Cloud9でRVMのアップデートをする

Cloud9の環境でプリインストールされている「RVM」ですが、Rubyの最新の安定版をインストールする際にRVMをアップデートしないといけなかったのでメモします。

RVMとは

RVMRuby Version Managerの略です。
Rubyのバージョンを管理するのに使います。
例えばインストール、アンインストール、バージョンの切り替えなどを実行できます。

公式サイト
RVM: Ruby Version Manager - RVM Ruby Version Manager - Documentation

RVMのサイトからキーをインストールしておく

セキュリティを確保するため、RVMでは署名をチェックしています。キーをインストールしていない場合はしておきます。

RVM: Ruby Version Manager -
からコマンドをコピーします。トリプルクリックすると便利です。

Cloud9のコンソールで、sudo(root権限で実行)の後にコマンドを貼り付けて実行します。

これでキーをインストールできました。

RVMのバージョンを確認する

rvm -v

今1.29.8ですが、これを1.29.10にしたいんです!

RVMのバージョンを更新する

アップデート(アップグレード)はgetコマンドです。
rvm get <version>

1.29.10に更新したい場合は以下のようになります。
rvm get 1.29.10

ではバージョンを指定してgetコマンドを実行します。
スクリーンショット 2020-06-01 14.50.10.png

確認のため、RVMのバージョンを表示します。
rvm -v
スクリーンショット 2020-06-02 2.38.48.png
これでアップデートできました。

(おまけ)RVMのヘルプを表示する

コマンドを調べたいときに使います。

rvm help
または
rvm
どちらでも表示されます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】API GatewayのCustomAuthorizerを設定する

概要

  • LambdaなどをAPI Gateway経由で公開することはよくあると思います
  • ですが公開したエンドポイントが誰でも叩けると困るケースもあります
  • そんな時にAPI GatewayのCustom Authorizerを使うと簡単に認証機能を付与できます
  • 今回はServerlessFrameworkを使った手順を紹介します

手順

雛形生成

  • ServerlessFrameworkで雛形を作るところからいきます
mkdir custom-auth-sample
cd custom-auth-sample
sls create -t aws-nodejs-typescript
npm i
  • 一式作成できました
tree -I node_modules
.
├── handler.ts
├── package-lock.json
├── package.json
├── serverless.yml
├── tsconfig.json
├── vscode
│   └── launch.json
└── webpack.config.js

Hello関数の動作確認

  • デフォルトでHello関数があるのでそれを確認しておきます
    • Hello関数を認証突破しないと叩けないようにする流れで進めていきます
  • handler.tsではhello関数はmessageなどをreturnするだけの処理として定義してあります
handler.ts
// handler.ts抜粋
export const hello: APIGatewayProxyHandler = async (event, _context) => {
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Go Serverless Webpack (Typescript) v1.0! Your function executed successfully!',
      input: event,
    }, null, 2),
  };
}
  • serverless.ymlでhello関数にはGET:/helloでアクセスできるように定義してあります
serverless.yml
# serverless.yml抜粋

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          method: get
          path: hello
  • デプロイしましょう
sls deploy

スクリーンショット 2020-06-02 1.31.20.png

  • ログに出てくるURLにアクセスするmessageが返ってきます

スクリーンショット 2020-06-02 1.32.23.png

Auth関数の作成

  • ユーザから送信されたトークンが正しいかどうかチェックする関数を作成します
  • handler.tsの一番下に以下の内容を追記してください
    • headerのAuthorizationにセットされた値と、事前に定義しておいたキーが一致してるかチェックしています
    • 一致した場合は後続の処理を実行する権限が付与され実行されます
handler.ts
// 省略

export const auth: CustomAuthorizerHandler = (event, context) => {
  const { authorizationToken } = event;
  if (authorizationToken === process.env.AUTH_KEY) {
    const policy = {
      principalId: 'user',
      policyDocument: {
        Version: '2012-10-17',
        Statement: [
          {
            Action: 'execute-api:Invoke',
            Effect: 'Allow',
            Resource: event.methodArn,
          },
        ],
      },
    };
    context.succeed(policy);
  } else {
    context.fail('Unauthorized');
  }
};
  • serverless.ymlにCustomAuthorizerとして登録する設定をします
    • 全量載せていませんがコメントで書いている部分を追記しているだけです
    • AUTH_KEYを直接埋め込むのが嫌なケースはdotenvなど使うといいでしょう
serverless.yml
# 省略
provider:
  # 省略
  environment:
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1
    AUTH_KEY: password@12345 # キーを環境変数として設定

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          method: get
          path: hello
          authorizer: authorizerFunc # CustomAuthorizerが適用されるように設定
  # 追加したLambda関数を登録
  authorizerFunc:
    handler: handler.auth
  • デプロイしましょう
sls deploy
  • デプロイできたら再びHello関数にアクセスしてみましょう

スクリーンショット 2020-06-02 1.42.53.png

  • 設定が適用されていれば401で弾かれているはずです
  • headerのAuthorizationにキーを設定して再度アクセスしてみます

スクリーンショット 2020-06-02 1.44.14.png

  • キーが正しいのでちゃんとアクセスできました!簡単ですね!

まとめ

  • 簡単なCustomAuthorizerの設定はServerlessFrameworkを使うと簡単に実現することができました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む