20200515のAWSに関する記事は16件です。

ACM証明書を自動更新してチャットボット経由で通知を受け取る

思い出したようにサーバー証明書の更新通知が来たので、復習を兼ねて設定方法をメモ。

ちなみに証明書はVue.jsのサンプルサイトやCloudFront+S3など、主にWebサイト系の素振り(たまに本番運用)をする際に使っている。
ドメインはRoute 53で構成。

やりたいこと

  • AWS Certificate Managerで運用している証明書の、1年ごとの更新を自動で行えるようにする
  • 更新時にチャットボットを介して通知を受け取る

使ったサービス

  • AWS Certificate Manager(ACM)
    • 2K証明書を無料で払い出し、更新するためにACMを使う。
  • AWS Chatbot(Chatbot)
    • 証明書自動更新の通知をチャットツールに送るためのチャットボットを作るのに使用。
  • Amazon Chime(Chime)
    • 普段使いしているチャットツール。ここでChabotから通知を受け取る。
  • AWS Personal Health Dashboard(PHD)
    • 自動更新の通知をマネジメントコンソール上で受け取る仕組み。
  • Amazon CloudWatch Events(CWE)
    • PHDのイベントを引っかけて処理するのに使う。
  • Amazon Simple Notification Service(SNS)
    • CWEからメッセージをPublishし、SubscribeしているChatbotに通知するための繋ぎ目として使う。

少々長いが、正しく構成すれば、

1.png

という流れで自動更新の通知が飛んで来るようになる。

イメージとしては、「証明書の自動更新」というニュースがニュースサイトに載ると、それを担当者がクリップして登録者に一斉配信し、登録者に名を連ねているボット君が配信メッセージを受け取ってチャットに投稿してくれる、といった感じ。自分でニュースサイトをウォッチしている必要がなくなるし、見落としも起きにくくなくなるメリットがある。

ACMの証明書更新について

ACMで作成した証明書は1年で切れる。
更新方法は、ドメインの所有権の検証方法(リクエストしたユーザーがドメインの管理者であることを確認するプロセス)に対応する形で二種類存在する。

検証方法 概要 更新
Eメール検証 whoisの管理者アドレスにメールを送付し、所有権を検証する 手動
DNS検証 ドメインにACMがCNAMEを作成し、レコードの存在をもって所有権を検証する 自動

以前サイト運用をしていた時はEメール検証を使っていたが、ドメインのwhois情報は一般にプライバシーを考慮してプロバイダーによる代理公開となっているため、メールが届かない。このため、更新時期にwhoisを一時的に解除して検証メールを受け取れるようにした上で承認を行う必要があり、大変面倒くさかった。
DNS検証にしておくと、ACMが登録したCNAMEがドメイン上に存在している限り自動的に検証され、whoisをいじる必要も、メールを開いて承認する必要もない。なので、よほどのことがない限りDNS検証にしておくのがおすすめ。
詳しくはこちら

通知

自動更新にしておけばほぼメンテフリーだが、一応更新の通知は受け取りたい。
証明書の更新はAWSのPersonal Health Dashboard(PHD)で捕捉できるので、これをボットに食わせてチャットツールで受け取れるようにする。

Step by Step

手順は以下の通り。
最初に「受け手」を構成し、次に「送り手」を構成する。

1. 証明書のリクエストとDNS検証の構成

マネジメントのコンソールにログインし、ACMノードを開く。
新規に証明書をリクエストし、その際ドメイン所有者の検証方法としてDNSの検証を選択する。後は手なりでOK。
ACM

2. Chime Webhookの作成

通知を受け取れるよう、チャットボットを構成していく。
まずは通知を受け取りたいChime Room(チャットツール上の部屋。Slackならチャンネル)を選択し、右上の管理ボタンから、Webhookを生成する。名前は何でもよい。
Chime Webhook1
webhook-acm-room.png

3. WebhookのURLをコピー

Webhookを作成したら、URLをコピーする。
Chime Webhook1

4. 新規Chatbotの作成

マネジメントコンソールからAWS Chatbotに移動し、新しいChatbotを作成する。
ChimeとSlackが選択可能。ここではChimeを選択。
Chatbot1

5. Chatbotの設定(1)

そのままWebhookの設定画面に進むので、先程コピーしたChime WebhookのURLを貼り付ける。
webhook-acm-config.png

6. Chatbotの設定(2)

CloudWatchにアクセスするためのIAMロール(今回はCloudWatchは関係ないが、設定上必須)と、指定したWebhookに通知を行うためのSNSトピックを指定する。ここでは、いずれも作成されている前提で進める。

IAMロール SNSトピック
role4Chatbot myTopic-NotifyMe

webhook-acm-config2.png

設定が終わったら保存。
Chatbot(Webhook)が作成され、SNSにSubscriberとしてWebhookが追加される。

【Chatbot】
chatbot.png
【SNS】
sns.png

ここまでで、SNSトピックに送られた通知をChatbotで受け取り、Chimeに送るための仕掛けができた。
2.png

ただし、「受け手」を作っただけなので、これだけではまだ更新通知は届かない。

ACMの証明書更新通知はPHDに届くので、PHDのイベントを引っかけて、SNS経由でChatbotに送るための「送り手」を構成する必要がある。

7. CWEルールの作成

PHDの通知を受け取れるよう、CWEルールを設定する。
PHDの右上にCWEへのリンクがあるので、今回はここから飛ぶ。
スクリーンショット 2020-05-15 17.00.24.png

8. CWEルール:イベントソースの設定

CWEの構成画面から、イベントソースとしてHealthを選択する(HealthはPHDを指す)。
スクリーンショット 2020-05-15 16.59.15.png

9. CWEルール:ターゲットの設定

同じく、ターゲットとしてSNSを選択する。トピックは先程Chatbotで設定したものを使う(PublisherがCWE、SubscriberがChatbotの関係)。
スクリーンショット 2020-05-15 16.59.22.png

あとはルール名を設定して完了。

受け手と送り手の構成ができたので、これで、1年ごとの証明書更新時にChimeに通知が届くようになる。
3.png

証明書更新の通知

更新日になると、DNS更新の恩恵で証明書が自動更新され、以下のようなメッセージがChimeに届く。
webhook-acm-update.png

ちなみに、AWS BudgetsなどもChatbotに対応しているので、SNS経由でAWSの利用量アラートをChime(ないしSlack)で受け取る、といったことも可能。

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

【書籍まとめ】AWSアソシエイト直前対策テキスト(用語集)③

EBS
Amazon Elastic Block Store (EBS) は、Amazon Elastic Compute Cloud (EC2) と共に使用するために設計された、スループットとトランザクションの両方が集中するどんな規模のワークロードにも対応できる、使いやすい高性能なブロックストレージサービス

ElastiCache
クラウド内の人気のオープンソース互換のインメモリデータストアをシームレスにセットアップ、実行、およびスケーリングできます。高スループットかつ低レイテンシーなインメモリデータストアからデータを取得して、大量のデータを扱うアプリケーションを構築したり、既存のアプリケーションのパフォーマンスを改善したりすることが可能

Lambda
Lambdaはサーバレスを実現するためのサービス
「AWS Lambdaを使用すれば、サーバのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。」

Route53
可用性と拡張性に優れたドメインネームシステム(DNS)ウェブサービス

OpsWorks
Chef や Puppet のマネージド型インスタンスを利用できるようになる構成管理サービスです。Chef や Puppet は、コードを使用してサーバーの構成を自動化できるようにするためのオートメーションプラットフォーム

NLB
Elastic Load Balancing)の1つでレイヤー 4に対応、TCP/UDPトラフィックの負荷分散。

CLB
ELBとは「Elastic Load Balancing」の略称で、元々はこのELBがAWSにおけるロードバランシングサービスでした。
しかしのちにALBが追加オプションとして開発された際に、ELBはその名称を「Classic Load Balancer(CLB)」に変えることになります。
そしてALBとCLBのサービスをまとめた総称として、ELBが使われるようになったのです。

CloudWatch Events
リソースを監視するCPUやメモリなど複数項目をグラフ化してダッシュボードを作れます。

CloudWatch Metrics
メトリクスとは、システムのパフォーマンスに関するデータ

CloudWatch Logs
ログを集めて監視する
Amazon Linux、RedHat、Windowsなどに対応し、インスタンスにエージェントを入れることで各種ログを取得

CloudWatch Dashboard
Amazon CloudWatch ダッシュボードは、CloudWatch コンソールにあるカスタマイズ可能なホームページ

Pub/Sub
イベントを処理するサービスとイベントを生成するサービスを切り離す非同期メッセージング サービス

STS
AWS Security Token Service (AWS STS) を使用して、AWS のサービスへのアクセスに使用できる一時的な限定権限認証情報を取得できます。

SQS
Amazon Simple Queue Service (SQS) は、完全マネージド型のメッセージキューイングサービスで、マイクロサービス、分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングが可能

SNS
Amazon Simple Notification Service (SNS) は、マイクロサービス、分散型システム、およびサーバーレスアプリケーションの分離を可能にする、高可用性で、耐久性に優れたセキュアな完全マネージド型 pub/sub メッセージングサービス

MQ
メッセージキューイングとは、異なるアプリケーションプログラム間で動作を連携させてデータを交換させる際の方式のひとつで、送るデータをキューと呼ばれるデータ領域に保持し、データを受ける側の処理が完了するのを待たずに次の処理へ移る方式のことである。

DynamoDB
Amazon DynamoDB は、フルマネージド型の NoSQL データベースサービスで、高速で予測可能なパフォーマンスとシームレスなスケーラビリティを特長としています

Redshift
Amazon Redshift は、クラウド内のフルマネージド型、ペタバイト規模のデータウェアハウスサービス

Aurora
Amazon Aurora は、MySQL および PostgreSQL と互換性のあるクラウド向けのリレーショナルデータベース

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

[Tips] AWS Amplify で既存のUserPoolを指定してAuthモジュールを使う

背景

すでに作ってある Cognito UserPool に OAuthによる認証機能を提供したいという要望があって、App Client と Hosted UIを追加した。

動作を確認するために、AWS Amplify のチュートリアルで Webアプリを作った。
https://docs.amplify.aws/lib/auth/social/q/platform/js#full-react-sample
Amplify が 使う 設定ファイル aws-exports.js を作る必要があるので、
amplify add auth コマンドで 一旦 aws-exports.js を作り、すでにある UserPool と IdentityPool の情報で書き換えた。

実行してみると、Auth モジュールの中でつくられるはずのセッションが作られてない。
調査してみると、http://cognito-identity.us-east-1.amazonaws.com/ へのリクエストが失敗していることがわかる(添付)

chrome-debug-cognito-idp-fail.png

GitHub にも同じような issue が立っていた。
https://github.com/aws-amplify/amplify-js/issues/4269

設定

IdentityProviderの Authorization Provider にも Clientの設定を追加する必要があった。

screenshot.png

余談

AmplifyのDocumentには、すでにある UserPool を使う情報が見つけられなかったので、ここに書いておくことにしました。
(前はあった気がしたのだけれど、あったとしてこの話題の記載はなかったような。。)
まあ、解決したのでよしとする。

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

EC2の機能まとめ(EBS AMI Snapshot)

目次

  1. EC2の概要
  2. AMI
  3. EBS
  4. Snapshot

1. EC2の概要
 EC2はサーバの性能やOSを自分でカスタマイズして簡単に仮想サーバを構築することが出来るサービスのことです。オンプレであれば何日もかかるようなサーバ構築が数分で構築することが出来ます。AWSで構築した個々のサーバはEC2インスタンスと呼ばれています。
 さらに複数のAZ、リージョンにサーバを建てることが出来るので高い可用性を兼ね備えていて非常に安心です。また安全性を考慮してAWSのデータセンターの場所は非公開です。
 以下ではそんな便利なEC2を支える主要な三つのキーワードについて解説していきます。

2. AMI
 AMI(Amazon Machine Image)とは一度作ったEC2インスタンスのOSやソフトウェアがインストールされている、ディスクイメージのことです。AMIを一度作ってしまえば同じ機能を持ったインスタンスを簡単に複製することが出来ます。例えば、OSがUbuntuでApacheやphpをインストールした、AMIを一度作成してしまえば、次に同じ環境のサーバを構築する際に、いちいち設定をすることなくAMIをコピーして同じ環境のインスタンスを作成することが出来ます。

3. EBS
 EBSはAWS上で操作できる仮想ディスクです。EC2インスタンスの情報を保存することが出来ます。ディスクはHDDとSSDがあり、SSDの方が優れていますがHDDよりもコストがかかるのが特徴です。EBSの容量に制限はありますが、一つのEC2インスタンスに複数のEBSをアタッチ出来るので、容量が足りなくなったらEBSを追加でアタッチしましょう。

4. Snnapshot
 Snapshotはある地点でのEBSのデータを丸ごと保存してバックアップを取ることが出来ます。AMIとスナップショットは一見似ていますが用途が全然違ってきます。AMIは基本的にOSはソフトウェアの設定のイメージを保存出来るので、新規でインスタンスの設定をする際に活用することが出来ます。AMIに対してSnapshotはEBSのその時点での断面をバックアップ出来るので、ストレージの復元や複製に役立てることが出来ます。

参考文献:小笠原種高 AWSの仕組みと技術がしっかりわかる教科書
     Udemy これだけでOK!AWS認定ソリューションアーキテクトーアソシエイト試験突破講座

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

Amazon Linux 2 における sendmail の設定で詰まったこと

Amazon Linux 2 でウェブアプリを作っていて、パスワード再設定機能を実装する際、メールサーバーが必要になりました。
ただ、そこまでしっかりしたサービスではないので、別に迷惑メールに入れられてもいいから無料でやりたいってことで、Amazon Linux 2 にデフォルトで入っている sendmail を使ってみることに。

参考にしたのはこちらの記事↓
https://www.server-memo.net/server-setting/sendmail/sendmail-setting_centos7.html

この記事をしっかり読めばできると思いますが、自分が詰まった点について書いていきます。

  1. /etc/mail/sendmail.mc の設定

Dwホスト名
Dmドメイン名
define(confDOMAIN_NAME',$w.$m')dnl

を加筆するのですが、ここは好きに設定して良いようです。メールサーバーに関する知識が薄い自分としてはあらかじめ決めた何かが必要なのかと思いました。
自分は
Dw : mail
Dm : xxx.work (自分でとったウェブサーバー用のドメイン)
に設定しました。

  1. sendmail.cf作成

sudo m4 sendmail.mc > sendmail.cf

を実行したのですが、なぜかpermission deniedに、、、
sendmail-cf はインストールしたのですが。

結果的には、他の設定ファイルも読み込んでくれる

sudo make

コマンドでしっかり作成してくれました。

あとはこの記事に沿って設定すればしっかり使えると思います。
あとこれは自分の環境特有のものかもしれませんが、受信用に設定したメールアドレスにはメールの送信はできなかったので、試す際は別のメールアドレスに送信したほうが良いかもしれません。

メールに限らずですけど、通信についてはもっと勉強しないとどこで詰まってるのかもわからないですし、大変ですね。

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

SSM PortForwardでのWindows RDPもhost名でつなぎたい

前回の続きです

SSM PortForwardによるRDP接続もInstanceIDが必要・コマンドが長ったらしいのでスクリプト化してみました
通常なら下のような感じで実行し、RDPの接続先として localhost:13389 を指定することになります

aws ssm start-session --target i-xxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389" --profile yuzuriha

コードはたいして変わってませんw
awscliのところぐらいです

rdp_proxy.py
#!/usr/bin/python

import sys
import os
import subprocess
import argparse

from boto3.session import Session


def start_port_forward(profile, hostname, port):
    session = Session(profile_name = profile)
    client = session.client('ec2')
    try:
        response = client.describe_instances(
            Filters = [
                {
                    'Name':   'tag:Name',
                    'Values': [hostname]
                }
            ]
        )
    except:
        return

    subprocess.call([
        'aws',
        '--profile',
        profile,
        'ssm',
        'start-session',
        '--target',
        response['Reservations'][0]['Instances'][0]['InstanceId'],
        '--parameters',
        'portNumber=3389,localPortNumber={0}'.format(port),
        '--document-name',
        'AWS-StartPortForwardingSession',
    ])


def main():
    parser = argparse.ArgumentParser(
        formatter_class = argparse.RawTextHelpFormatter,
    )
    parser.add_argument('--profile')
    parser.add_argument('--host')
    parser.add_argument('--port', default=13389)
    args = parser.parse_args()

    start_port_forward(args.profile, args.host, args.port)

    sys.exit(0)


if __name__ == '__main__':
    main()
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ALBのデフォルトセキュリティグループをCDKからいじりたいんだって

概要

CDKでALB with Fargateを作るとSecurityGroupがフル開放されちゃいます
開発環境だったり、内部のサービスであれば、セキュリティを考えてIPを絞りたいと思うのですが、CDKだと追加は簡単だけど削除が難しかったので、その方法の共有です

手順

フルオープンSG作成

まずは変更対象のSecurityGroupを作成します

alb_sg=ec2.SecurityGroup(self, "alb-sg",
    vpc=ivpc,
    description="alb sg"
)

次にそのSecurityGroupを利用したALBを作成します

ecs_alb=elasticloadbalancingv2.ApplicationLoadBalancer(self, "alb",
    security_group=alb_sg,
    vpc=ivpc,
    internet_facing=True,
    load_balancer_name="ecs-alb"
)

そしてecs_patternsを使ってFargateServiceを作ります

fargate_service = ecs_patterns.ApplicationLoadBalancedFargateService(self, "service",
    cluster=cluster,
    task_definition=task,
    load_balancer=ecs_alb,
    cloud_map_options = ecs.CloudMapOptions(
        name = 'hoge'
    )
)

実行すると下記のように80ポートがフルオープンしたSecurityGroupが作成されることが分かります
(SecurityGroupの部分のみ抜き出してます)

$ cdk diff ecs
Stack ecs
Security Group Changes
┌───┬───────────────────────────────────────────────────────┬─────┬──────────┬────────────────────────────────┐
│   │ Group                                                 │ Dir │ Protocol │ Peer                           │
├───┼───────────────────────────────────────────────────────┼─────┼──────────┼────────────────────────────────┤
│ + │ ${prod-alb-sg.GroupId}                        │ In  │ TCP 80   │ Everyone (IPv4)                │
└───┴───────────────────────────────────────────────────────┴─────┴──────────┴────────────────────────────────┘
Resources
[~] AWS::EC2::SecurityGroup prod-alb-sg prodmonitoralbsg0D94D960 
 └─ [+] SecurityGroupIngress
     └─ [{"CidrIp":"0.0.0.0/0","Description":"Allow from anyone on port 80","FromPort":80,"IpProtocol":"tcp","ToPort":80}]

SGの上書き

node.default_child.add_override で上書きできるので、キーを指定して上書きします
下記2個を指定していて、フル開放されている1つしかルールが追加されてないので0番目を指定してます

  • Properties.SecurityGroupIngress.0.CidrIp
  • Properties.SecurityGroupIngress.0.Description
alb_sg.node.default_child.add_override(
    "Properties.SecurityGroupIngress.0.CidrIp",
    "1.1.1.1/32"
)
alb_sg.node.default_child.add_override(
    "Properties.SecurityGroupIngress.0.Description",
    "Google"
)

実行すると、デフォルトのTCP80 allow Everyoneが消えて指定したIPに変わります

$ SYSTEM_ENV=prod cdk diff ecs
Stack ecs
Security Group Changes
┌───┬────────────────────────────────┬─────┬──────────┬─────────────────┐
│   │ Group                          │ Dir │ Protocol │ Peer            │
├───┼────────────────────────────────┼─────┼──────────┼─────────────────┤
│ - │ ${prod-alb-sg.GroupId} │ In  │ TCP 80   │ Everyone (IPv4) │
├───┼────────────────────────────────┼─────┼──────────┼─────────────────┤
│ + │ ${prod-alb-sg.GroupId} │ In  │ TCP 80   │ 1.1.1.1/32 │
└───┴────────────────────────────────┴─────┴──────────┴─────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

Resources
[~] AWS::EC2::SecurityGroup prod-alb-sg prodmonitoralbsg0D94D960 
 └─ [~] SecurityGroupIngress
     └─ @@ -1,7 +1,7 @@
        [ ] [
        [ ]   {
        [-]     "CidrIp": "0.0.0.0/0",
        [-]     "Description": "Allow from anyone on port 80",
        [+]     "CidrIp": "1.1.1.1/32",
        [+]     "Description": "Google",
        [ ]     "FromPort": 80,
        [ ]     "IpProtocol": "tcp",
        [ ]     "ToPort": 80

以上がCDKからALBデフォルトSGのいじり方でした

参考

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

AWS初心者が在宅勤務中にAWSの資格を取る記録 part4

■5/11(Mon)

・Udemyで座学&ハンズオン(セクション7~9)
 →S3、Well Architected Framework、信頼性の設計

感想

今までオンプレミス環境のシステム設計や構築やテストなど行ってきたが、クラウドでも基本的な考え方は同じ。
しかし、キャパシティやリソースを考慮しない考え方は今までとは正反対のアプローチなので、非常に興味深い。

■5/12(Tue)

・Udemyで座学&ハンズオン(セクション10~11)
 →Route53
  →ホストゾーン設定、ルーティング、フェイルオーバーの実装
   →以下のルーティングについて、3つのリージョンにEC2インスタンスを作成して動作確認
    ・シンプルルーティング
    ・加重ルーティング
    ・レイテンシールーティング
    ・位置情報ルーティング
    ・マルチバリュールーティング
 →データベース
  →データベースの基礎、概要について

感想

内容について、少しだけ詳細に書くことにした。

お名前.comでドメインを取得(1円/1年のやつ)し、ハンズオンを進めた。
Route53のルーティングについては、少し種類が多いので座学だけだと理解するのが面倒だと思う。

今週中にはこのコースは修了できそうなので、来週中にSAA試験の受験を画策中。

■5/13(wed)

・Udemyで座学&ハンズオン(セクション11~12)
 →データベース、ElastiCache
  →DynamoDB、Aurora、EFS、Kinesis、ElastiCache、CloudFrontのハンズオン
   →サービスを構築し、挿入や削除等のデータ操作を実施

 ※高額なサービスはハンズオン終了直後に消去しています

感想

今までの業務ではデータベースを触る機会がなく、概要を理解している程度だった。
本講義を受講することでAWSサービスにおけるDBの概念と構築方法を学べた。

また、NoSQL型のDBサービスはSQL文でなく、視覚的に理解しやすいデータ操作であることに感動した。

■5/14(Thu)

・Udemyで座学&ハンズオン(セクション13)
 →サーバレスサービス
  →SQS、SNSの概要、ハンズオン
   →サービスを構築し、メール送信等のハンズオンを実施

感想

サーバレス化によるメリットである疎結合の概念ヨシ

■5/15(Fri)

・Udemyで座学&ハンズオン(セクション13~14)
 →サーバレスサービス、環境の自動化
  →Lambda、CloudFormationの概要、ハンズオン
   →サービスを構築し、ハンズオンを実施

感想

AWSを触っていて、一番感動したのはCloudFormation。
VMwareやHyper-Vにおいても、仮想マシンのコピー作ってデプロイして。。と環境構築は簡単だったが、
CloudFormationはさらに簡単だなと思う。
パチパチとコードを書いてさらっと環境を整えられるエンジニアになりたい。

今週の総括

SAAの勉強を本格的に初めて2週間弱になりましたが、基本的にUdemyベースで進めています。

ノートをとる量が10倍くらい増えたので、おそらくCLFレベルの概要の把握だけだとダメなんだろうという気がしています。
ぼちぼち模擬試験に切り替えて、合格を目指していこうと思います。

また、在宅ワークのメリットを大いに感じています。
在宅で働くという勤務形態の最大のメリットは有効な時間の確保ができるということです。
自由な時間をAWSの勉強や読書、自身の好きなことに充てる時間とすることで、私生活にメリハリがでてきました。

そのお陰で、勉強をする努力をし、努力が当たり前となり、しなくては落ち着かないくらいになり、勉強をする習慣がつきました。
この習慣を今まで通りの環境に変わっても続けたいと考えます。

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

ACM + CloudFrontでLightsailをHTTPS化するまでの備忘録

はじめに

  • 以前、AWSのLightsailでWordPressを導入して、Webサイトを構築しました。
  • 前回、構築したWebサイト用に取得したドメインをRoute53に追加しました。
  • 今回は、AWS Certificate Manager(ACM)CloudFrontを利用して、HTTPS通信可能にしました。
  • その時の手順を備忘録としてまとめました。

動作環境

  • macOS Catalina 10.15.4

1. ACMでの作業

  • ACMでSSL認証書を作成します。ただしこの証明書は、外部で使用することはできませんが、無料かつ自動更新なので管理が非常に容易です。
  • AWSコンソールへアクセスし、サインインします。 Fig1.png
  • リージョンバージニア北部に変更します。
  • サービスを検索するCertificate Manager入力します。
  • Certificate Managerコンソールへアクセスします。 Fig2.png
  • 証明証のプロビジョニング今すぐ始めるをクリックします。 Fig3.png
  • 証明証のリクエストを行います。
    • パブリック証明証のリクエストにチェックを入れます。
    • 証明証のリクエストをクリックします。 Fig4.png
  • ドメイン名の追加を行います。
    • 下記のドメイン名(2件)を入力します。
      • Webサイトのドメイン名
      • *. + Webサイトのドメイン名
    • 次へをクリックします。 Fig5.png
  • 検証方法の選択を行います。
    • DNSの検証にチェックを入れます。
    • 次へをクリックします。 Fig6.png
  • タグの追加を行います。
    • 何も設定せずに(デフォルトのまま)、次へをクリックします。 Fig7.png
  • 確定とリクエストをクリックします。 Fig8.png
  • Route53でのレコードの作成をクリックします。 Fig9.png
  • 作成をクリックします。 Fig10.png
  • 成功と表示されることを確認します。
  • 続行をクリックします。 Fig11.png
  • 証明書の一覧が表示されます。
  • 対象ドメインに対して、作成した証明書が表示されていることを確認します。
  • 状況発行済みになっていればOKです(少し時間がかかる場合があります)。 Fig12.png
  • 以上で、ACMでの作業は、完了です。

2. CloudFrontでの作業

  • AWSマネージメントコンソールへアクセスします。
  • リージョンバージニア北部に変更します。
  • サービスを検索するCloudFront入力します。
  • CloudFrontコンソールへアクセスします。 Fig13.png
  • Create Distributionをクリックします。 Fig14.png
  • WebGet Startedをクリックします。 Fig15.png
  • Distributionの設定を行います。
    • Origin Settingsについて、下記項目を設定します。 他項目は、デフォルトのままでOKです。
      • Origin Domain NameWebサイトの仮(サブ)ドメイン名
      • Origin Protocol PolicyHTTP Only
      • Origin Custom Headers HearderNameCLOUD_FRONT_ACCESS
      • Origin Custom Headers ValueTRUE
    • Default Cache Behavior Settingsについて、下記項目を設定します。他項目は、デフォルトのままでOKです。
      • Viewer Protocol PolicyRedirect HTTP to HTTPS
      • Allowed HTTP MethodsGET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE Fig16.png
    • Distribution Settingsについて、下記項目を設定します。他項目は、デフォルトのままでOKです。
      • Alternate Domain Names最終的に公開したいドメイン名
      • SSL CertificateCustom SSL Certificateにチェックを入れて、作成したACMを選択します。
    • Createをクリックします。 Fig17.png
  • CloudFront Distributionの一覧が表示されます。
  • 作成したDistributinonが表示されていることを確認して、IDをクリックします。 Fig18.png
  • Behaviorsをクリックします。
  • Create Behaviorをクリックして、4つのBehaviorを作成します。
    • 各設定項目については、下記の表の通りです。他項目は、デフォルトのままでOKです。
項目名 Behavior1 Behavior2 Behavior3 Behavior4
Path Pattern Default(*) /wp-json/* /wp-admin/* /wp-login.php*
Viewer Protocol Policy Redirect HTTP to HTTPS Redirect HTTP to HTTPS Redirect HTTP to HTTPS Redirect HTTP to HTTPS
Allowed HTTP Methods GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Cache Based on Selected Request Headers Whitelist Whitelist Whitelist Whitelist
Whitelist Headers CloudFront-Forwarded-Proto,Host CloudFront-Forwarded-Proto,Host,X-WP-Nonce CloudFront-Forwarded-Proto,Host CloudFront-Forwarded-Proto,Host
Object Caching デフォルトのまま デフォルトのまま Customize Customize
TTL デフォルトのまま デフォルトのまま 0 0
Forward Cookies Whitelist All All All
Query String Forwarding and Caching Forward all,cache based on all Forward all,cache based on all Forward all,cache based on all Forward all,cache based on all

Fig19.png

  • 以上で、CloudFrontでの作業は、完了です。

3. Route53での作業

  • 外部からhttps://ドメイン名でアクセスする時、Route53で作成済みのホストゾーン(Aレコードのエイリアス)CloudFrontのドメインがアクセス先になるように設定します。
  • Route53コンソールへアクセスします。
  • 対象のドメインをクリックします。 Fig20.png
  • レコードセットの作成をクリックします。 Fig21.png
  • レコードセットを作成します。
    • 下記項目を入力します。
      • 名前:空のままでOK(最終的に公開したいドメイン名になるようにします)
      • タイプA-IPv4アドレス
      • エイリアスはい
      • エイリアス先CloudFrontのドメイン名(リスト表示されるので選択します)
      • ルーティングポリシーシンプル(デフォルト)
    • 作成をクリックします。 Fig22.png
  • 最終的に、対象ドメインに対して、5件分のレコード(2件のANSSOACNAME)が表示されていることを確認します。
    Fig23.png

  • 以上で、Route53での作業は、完了です(実際に変更反映が完了するまで、数十分かかる場合があります)。

4. WordPressでの作業

  • wp-config.phpを編集します。
  • Macのターミナルを起動します。
  • LightsailインスタンスにSSH接続します。
  • 下記のコマンドを実行して、wp-config.phpを開きます。
bash
vim /opt/bitnami/apps/wordpress/htdocs/wp-config.php
  • 下記項目を変更して、保存します。
    • WP_SITEURLhttphttpsに変更
    • WP_HOMEhttphttpsに変更 Fig24.png
  • Apacheの設定を変更します。
  • 下記のコマンドを実行して、httpd.confを開きます。
bash
vim /opt/bitnami/apache2/conf/httpd.conf
  • 1行目に下記を追記して、保存します。
SetEnvIf CLOUD_FRONT_ACCESS "TRUE" HTTPS 
RequestHeader set CLOUD_FRONT_ACCESS "TRUE" env=HTTPS 

Fig25.png

  • Apacheを再起動します。下記のコマンドを実行します。
bash
sudo /opt/bitnami/ctlscript.sh restart apache
  • 以上で、WordPressでの作業は、完了です。

5. HTTPS化の確認

  • ブラウザを開き、https://ドメイン名でアクセスします。アクセスできればOKです。 Fig26.png
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAMのテンプレートではリソースごとに!Refと!GetAttの戻り値が違う

はじめに

この記事では、AWS SAMテンプレートでAWS Lambda、AmazonAPI Gateway、AmazonSNSを使用したサーバレスアプリケーションを作ろうとしたときに躓いたポイントを紹介します。

AWS SAM テンプレートとは

AWS SAMのテンプレートはAWS CloudFormation テンプレートの拡張で基本的にはCloudFormationのテンプレートの書き方と同じですがSAM特有の便利なコンポーネントも追加されています。
もっと詳しく知りたい方はこちらを参考にしてみてください。
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-reference.html

CloudFormationの組み込み関数

CloudFormationにはスタックの管理に便利な組み込み関数があります。ここではそれらの関数のうち2つを紹介します。便利な使い方としては、実行するまでわからない値(SAMテンプレートで作成したLambda関数のAmazonリソースネーム (ARN)だったり、SNSのTopicNameだったり)を取得してプロパティに代入することができます。

Fn::GetAtt(!GetAtt)

まずFn::GetAtt(!GetAtt)について紹介します。短縮形の構文で!GetAttとかかれることが大きので以下!GetAttとして説明します。!GetAtt組み込み関数は戻り値としてテンプレートのリソースから属性の値(リソース名やARNなど)を返します。例えばテンプレートで以下のようにLambdaを定義したとしましょう。

template.yaml
Resources:
  SampleLambda:
    Type:AWS::Serverless::Function
    Properties:
      FunctionName: SampleFunction
      Runtime: python3.7
      CodeUri: test/
      Handler: app.lambda_handler

テンプレートにLambdaを定義しただけではLambda関数は作成されません。当然、buildとdeployをしなければなりません。buildとdeployを行うとLambda関数が作成されARNなどの値も生成されます。ということは、もしテンプレートを書いてリソースなどを定義している段階でLambdaのARNが必要になったとしてもdeployしてから手動でARNをコピーしてテンプレートに付け足してまたdeployしなければいけないの??とその時は悲しい気持ちでテンプレートを書いてました。そこで発見したのがこの!GetAttという組み込み関数です。以下の例を参考に使い方をみていきます。

template.yaml
Resources:
  SampleLambda:
    Type:AWS::Serverless::Function
    Properties:
      FunctionName: SampleFunction
      Runtime: python3.7
      CodeUri: test/
      Handler: app.lambda_handler
      Role: !GetAtt SampleIamRole.Arn

  SampleIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: 'Allow'
            Principal:
              Service: lambda.amazonaws.com
            Action: 'sts:AssumeRole'

SampleLambdaに対するSampleIamRoleというRoleを定義しました。このRoleをLambdaに紐付けるときに使用するのが!GettAtt関数です。

template.yaml
Role: !GettAtt SampleIamRole.Arn

これを付け足すと作成したRoleのARNを取得しLambdaに紐づけてくれます。すごく便利です。

Fn::Ref(!Ref)

次にFn::Ref(!Ref)について紹介します。短縮形の構文で!Refとかかれることが大きので以下!Refとして説明します。!Ref組み込み関数は戻り値として指定したパラメータまたはリソースの値を返します。先ほどと同じようにテンプレートで以下のようにLambdaを定義します。

template.yaml
Resources:
  SampleLambda:
    Type:AWS::Serverless::Function
    Properties:
      FunctionName: SampleFunction
      Runtime: python3.7
      CodeUri: test/
      Handler: app.lambda_handler
      Events:
        SNS:
          Type: SNS
          Properties:
            Topic: !Ref SampleTopic

  SampleTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: SampleTopic

Lambdaのトリガー(イベント)としてSNSのトピックを定義しました。イベントとしてSNSのトピックを設定するときはトピックのARNが必要です。そこで先ほどの!GetAtt関数を使用してARNを取得しようとしてもうまくいきません。ここが今回紹介する躓きポイントです。ドキュメントをみてみるとこんなことが書かれています。

戻り値
参照番号
トピック ARN (例: arn:aws:sns:us-east-1:123456789012:mystack-mytopic-NZJ5JSMVGFIE) このリソースの論理 ID を組み込みの Ref 関数に渡すと、Ref は次を返します: 。
For more information about using the Ref function, see Ref.
Fn::GetAtt
Fn::GetAtt 組み込み関数は、このタイプの指定された属性の値を返します。以下には、利用可能な属性とサンプル戻り値のリストが示されます。
Fn::GetAtt 組み込み関数の使用方法の詳細については、「Fn::GetAtt」を参照してください。
TopicName
Amazon SNS トピックの名前を返します。

AWS::SNS::Topicタイプリソースに対して!GetAtt関数を使用すると戻り値として返ってくるのはARNではなくSNS トピックの名前です。!Refを使用すると戻り値としてSNSトピックののARNが返ってきます。
ARNを取得しようとして!GetAttや!Refを使用してもリソースによっては!Refで取得できたり、!GetAttで取得できる違いがあるようです。

まとめ

  • 取得したい値によって!GetAttや!Refを使い分けるだけではなく、同じような値(ARNやリソース名など)を取得するにしてもリソースによって使い分けなければいけない
  • とにかくドキュメントに全て書いてあるから読み込む

というのがすごく大事だなと痛感しました。

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

【AWS EC2】ルートテーブルが作成されてないためport 22: Operation timed outが起きた

はじめに

AMIからEC2を作成する勉強をしていた。
設定をして、ssh -i ~/Desktop/hoge.pem ec2-user@該当のIPアドレス
で接続しようとするも、

ssh: connect to host 該当のIPアドレス  port 22: Operation timed out

のエラーが出ている。

解決法(今回の場合)

VPCのダッシュボードを開いてパブリックサブネットの作成内容について確認したところ、問題なさそうだった。
続いてルートテーブルの関係付けを見てみると、下記のイメージのようにlocalにしか向いてなかった。
スクリーンショット 2020-05-15 11.00.23.png

そこで青いボタンのルートテーブルの関連付けの編集をクリックする。
image.png
image.png

ルートテーブルIDを0.0.0.0/0のものを選択しをクリックし、保存。

これで10.0.0.0/16の時はlocalで、それ以外の通信の時はインターネットゲートウェイにも接続されるようになった。
これでssh接続をすると、きちんと接続できるようになった。

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

NLB に VPCFlowLogs を設定する

背景

AWS上にTCPリスナーのNLBを構築した時に、
全て正しく設定されているように見えるのに、なぜかログが出力されない事象に遭遇しました。

ALBと同じようにアクセスログを出力してくれるものだと思っていたのですが、
TCPリスナーの場合はアクスエスログを出力しない仕様でした。

VPCフローログは設定できそう、という情報をもらい

  • 存在は認識していたが、触ったことがなかった
  • なんらかの方法でトラフィックを確認できるものがあれば、、と思っていた

ので、ドキュメントを読みつつ設定を試してみることにしました。

目的

AWSのドキュメントを読んだり、実際に設定してみてせっかくなのでわかったことをまとめておきます。

VPCフローログとは

VPC内のネットワークインターフェースを行き来するトラフィックのをキャプチャするもので
主に以下のような情報が含まれます。
※詳しくはこちら

フィールド 概要
version ログフォーマットのバージョン
account-id AWSアカウントID
interface-id ネットワークインターフェイスのID(eni-とつく)
srcaddr 受信トラフィックの送信元アドレス
dstaddr 送信トラフィックの送信先アドレス
srcport 送信元のポート
dstport 送信先のポート
protocol トラフィックのプロトコル
packets 転送されたパケット数
bytes 転送されたバイト数
start 最初のパケットが受信された時間
end 最後のパケットが受信された時間
action セキュリティグループorネットワークACLで許可されているか
log-status ロギングのステータス

ログフォーマット

以下の2パターンです。

  • デフォルト形式
  • カスタム形式

カスタム形式の場合は各フィールドの出力順や、各フィールドを出力させるかさせないかをカスタマイズすることが可能です。

ログフォーマットのバージョン

2020/5時点では最新バージョンは3、デフォルトバージョンは2になっています。

VPCフローログをデフォルト形式で作成した場合、ログのフィールドに含まれるバージョン2のフィールドですが、カスタム形式だとバージョン3のフィールドも利用可能です。

ログ送信先

選択肢はCloudwatch LogsまたはS3 Bucketの2つで、それぞれの特徴は以下です。

  • Cloudwatch Logs

    • デフォルト形式のみ対応
    • Cloudwacth アラームとの連携が可能
  • S3 Bucket

    • カスタム形式の利用が可能
    • Athenaでログの検索が可能

設定方法

今回はNLBのネットワークインターフェイスに対して設定し、送信先はS3(事前に作成済み)、カスタム形式で試してみます。

コンソールでEC2 > ネットワークインターフェイス > NLBにアタッチされているネットワークインターフェースを選択すると画面下にフローログのタブが表示されるので、「フローログの作成」をクリックします。

create-vpc-flow-log.png

必要事項を入力します。
setting-vpc-flow-log.png

Filter欄では、Accept、Reject、Allの選択が可能です。
S3バケットの欄はキーを含めることも可能で、1つのS3 Bucketに複数のVPCフローログを含める、ということができそうです。

設定はこれで完了です。

発行されるログ

version account-id instance-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
3 unknown - eni-xxxxxxxxxxx 10.1.1.15 10.1.2.32 1433 57640 6 3 164 1589466553 1589466612 ACCEPT OK

所感

  • 設定は簡単
  • このログで最も確認できるのは、本当にシンプルにセキュリティグループで許可されたトラフィックか否か
  • ヘルスチェックのログがそこそこある
    • バイト数は記録されるので、ヘルスチェックのものかサービスのものかはバイト数が唯一の比較材料?
  • やはりセキュリティの観点で利用するものの印象。サービスのトラブルシューティングに使うものではなさそう

注意点

  • 送信先に関わらず、料金はCloudwatchのログが課金されます。
  • ログには最初と最後のパケットを受信した時間が記録されますが、UNIX秒なので読み替えが必要です。
  • フローログを作成してから実際に送信先に出力されるまで、多少時間がかかります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS RDSのバックアップからデータをサルベージする方法

はじめに

AWSのRDSを使っている方は、RDSの機能でバックアップを取っている方も多いでしょう。
とても簡単にバックアップが取れて便利ですよね!
今回はそのバックアップからデータが必要になった場合にサルベージする方法を書いていきます!

最新で正確な情報は下記に記載されており、今回はそれを元に作業をした為そちらもご確認ください。
AWS 公式ドキュメント

検証環境

RDS Mysql: 5.7.22

サルベージ方法

データをサルベージする方法としては現状2つ方法が存在します。

Mysql 5.7.22はバージョン対象外なので、バックアップデータをS3にエクスポートする方法は今回使用できませんでした。
恐らく後者の方法の方が楽な気はします。
(5.7.24からは対応していた為、よく見ずに試してエラーが出て対象外な事に気付きました:joy:)

バックアップからDBスナップショットを復元する

基本的にはAWS コンソール RDSメニュー内からスナップショットの復元を行い、DBへアクセスすればデータをサルベージできると思います!

やってみた上での注意点としては下記かなと感じました

  • スナップショットの復元はRDSのインスタンス自体が新規作成される為、インスタンスサイズ等に注意
    • 復元する際のデフォルトの設定が、元のインスタンスと同じ設定だったので不要に大きなインスタンスで立てそうになりました、、、
    • 意外と時間がかかる。今回20GiBのインスタンスの復元をして数十分かかりました、、、
  • Sequel Pro等のMysqlクライアントからDBのデータを確認するためには、踏み台サーバーを用意してあげる必要がある

今回はSequel Proからデータを確認したかった為踏み台サーバーを用意してあげて接続しました。
公式でもしっかりドキュメント用意してくれている為、特に困らず接続できました!
(踏み台ってスラング的な言葉だと思っていたのですが、公式でも言うんですね、、、)

踏み台サーバーを経由してあげれば、問題なくSequel Pro等のクライアントからアクセスできると思います!

まとめ

AWS RDSはバックアップするのも簡単であれば、復元、データのサルベージも簡単で嬉しい!

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

Amazon EC2(概要)

Amazon EC2とは

一言で言うと「仮想サーバー構築サービス」
まずは「メリット」と「機能の概要」だけ。後ほど個別に詳細を。

メリット

マネジメントコンソールからボタンを押すだけでできる。(用意されている物を選ぶだけ)
物理マシンを用意するための初期投資を抑えられる。
すぐ作れて、すぐ壊せる。
など

Amazon EC2の機能

1, AMI
Amazon Machine Imageの略。ソフトウェア構成を記録したテンプレート。
Linux,Windowsなどが用意されてる。

2, インスタンス
仮想コンピューティング環境。

3, リージョンとアベイラビリティーゾーン
データセンターが置いている地域。

4, インスタンスタイプ
インスタンス用のCPU、メモリ、ストレージ、ネットワーキングキャパシティの様々な構成。

5, キーペア
インスタンスに接続するとき、認証のために使用する鍵。

6, セキュリティグループ
ファイアウォール。

7, Elastic IP アドレス
固定のIPv4アドレス。

8, Amazon VPC
Amazon Virtual Private Cloudの略。AWSアカウント専用の仮想ネットワーク。

9, Amazon EBS
Amazon Elastic Block Storeの略。データを保存するところ。

以上9つの機能については後ほど詳細を書いていきます。
超ざっくりしてるけど、今EC2にMacのTerminalでsshログインできたので次の記事はそれを含めたことを書こうかな。

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

既に生成したインスタンスから作ったAMIでインスタンスを作成する

EC2で作ったインスタンスからAMIを作成し、そのAMIを利用してインスタンスを作ります。

手順

EC2のインスタンス画面から「アクション」の「イメージ-イメージの作成」を選択します。
イメージの作成で、イメージ名と説明を入力し、「イメージの作成」を押下します。
1.png

作成されたら「閉じる」を押下します。
2.png

これAMIが作成できました。
このAMIを使ってインスタンスを立ち上げます。

EC2からAMIの画面を開きます。
先程作成したAMIを選択し、「起動」を押下します。
3.png

ここからは普通のインスタンスの作成方法と同じです。
インスタンスの作成はこちらの過去記事にあります。

ここまできたら作成がAMIを使ったインスタンスの作成は完了です。
4.png

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

【初心者】Amazon CloudWatch Synthetics を使ってみる

目的

  • 先日AWS東京リージョンの障害があり、「監視はAWS東京リージョンの外からしたほうがよいかも…」と思っていた時に、CloudWatch Syntheticsの話を聞いたので、どんなものか試してみる。

Amazon CloudWatch Synthetics とは(自分の理解)

やったこと

  • 監視対象のWEBサーバの作成(普通のEC2インスタンス/nginx)
  • 監視対象のWEBサーバとは別のVPCにて、NAT GatewayからInternet抜けできるsubnetを作成
  • CloudWatch Syntheticsの監視スクリプト(canary)を作成(上記のsubnetをlambdaの動作場所として指定)
  • 固定されたSrcIP(NAT Gateway経由)から監視対象のWEBサーバの正常性監視ができることを確認
  • WEBサーバにてリンク切れを発生させると、エラー検知できることを確認

構成図

syn00.png

手順

事前準備

  • 構成図の通り、以下の環境を作成しておく。
    • VPC1/Subnet1: Webサーバ(EC2インスタンス/nginx)を起動させる用のSubnet。(Public Subnet)
    • VPC2/Subnet2: canary(監視スクリプト)の実体となるLambdaを起動させる用のSubnet。Nat Gatewayでのインターネットアクセス可能にしておく。

監視対象のWEBサーバの作成

  • 監視対象のWEBサーバ(nginx)を作成し、EIPを付与してインターネット公開する。
  • index.html のコンテンツを以下とする。
index.html
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        <title>Test Page for the Nginx HTTP Server on Amazon Linux</title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    </head>
    <body>
        <h1>Synthticsからアクセスされるページ</h1>
        <p>
        <a href="mikan.html">mikan: みかんの説明ページ</a>
        </p>
        <p>
        <a href="ringo.html">ringo: りんごの説明ページ</a>
        </p>
    </body>
</html

syn01a.png

CloudWatch Synthetics の監視スクリプト(canary)の作成

  • CloudWatch - Synthetics - Canary を作成 を選択し、監視スクリプト(canary)を作成する。
    • 設計図を使用する(初心者なので)
    • 設計図: リンク切れチェッカー
    • アプリケーションまたはエンドポイントURL: 監視対象のWEBサーバのEIP
    • VPC設定: 作成したVPC2/Subnet2 を指定する。

syn10a.png
syn11a.png

動作確認

正常時の動作

  • 監視アクセスに成功すると、成功としてカウントされ、スクリーンショット等も取得される。(私の環境では日本語は文字化けしているが…)

syn12a.png

  • WEBサーバ側のアクセスログにはcanaryのARNが保存される。
/var/log/nginx/access.log
x.x.x.x - - [12/May/2020:16:03:22 +0000] "GET /mikan.html HTTP/1.1" 404 3665
 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Hea
dlessChrome/75.0.3738.0 Safari/537.36 CloudWatchSynthetics/arn:aws:synthetics:ap
-northeast-1:xxxxxxxxxxxxxx:canary:mksamba-canary" "-"

リンク切れ発生時の動作

  • WEBサーバにて、index.html内でリンク先として指定しているringo.htmlを削除後、再度監視アクセスを行うとエラーになる。ringo.htmlが404 Not Foundになっており、それがエラー原因であることが表示される。

syn13a.png

所感

  • 監視対象とは別リージョンで起動すればリージョン障害の影響を受けずに監視ができそう。
  • 簡単な監視はすぐできそうだが、監視項目をきちんと定めて動作させるには、生成されるLambda Function(node.js)の内容理解やカスタマイズが必要かも…。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む