- 投稿日:2020-05-15T23:48:54+09:00
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に通知するための繋ぎ目として使う。
少々長いが、正しく構成すれば、
という流れで自動更新の通知が飛んで来るようになる。
イメージとしては、「証明書の自動更新」というニュースがニュースサイトに載ると、それを担当者がクリップして登録者に一斉配信し、登録者に名を連ねているボット君が配信メッセージを受け取ってチャットに投稿してくれる、といった感じ。自分でニュースサイトをウォッチしている必要がなくなるし、見落としも起きにくくなくなるメリットがある。
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。
2. Chime Webhookの作成
通知を受け取れるよう、チャットボットを構成していく。
まずは通知を受け取りたいChime Room(チャットツール上の部屋。Slackならチャンネル)を選択し、右上の管理ボタンから、Webhookを生成する。名前は何でもよい。
3. WebhookのURLをコピー
4. 新規Chatbotの作成
マネジメントコンソールからAWS Chatbotに移動し、新しいChatbotを作成する。
ChimeとSlackが選択可能。ここではChimeを選択。
5. Chatbotの設定(1)
そのままWebhookの設定画面に進むので、先程コピーしたChime WebhookのURLを貼り付ける。
6. Chatbotの設定(2)
CloudWatchにアクセスするためのIAMロール(今回はCloudWatchは関係ないが、設定上必須)と、指定したWebhookに通知を行うためのSNSトピックを指定する。ここでは、いずれも作成されている前提で進める。
IAMロール SNSトピック role4Chatbot myTopic-NotifyMe 設定が終わったら保存。
Chatbot(Webhook)が作成され、SNSにSubscriberとしてWebhookが追加される。ここまでで、SNSトピックに送られた通知をChatbotで受け取り、Chimeに送るための仕掛けができた。
ただし、「受け手」を作っただけなので、これだけではまだ更新通知は届かない。
ACMの証明書更新通知はPHDに届くので、PHDのイベントを引っかけて、SNS経由でChatbotに送るための「送り手」を構成する必要がある。
7. CWEルールの作成
PHDの通知を受け取れるよう、CWEルールを設定する。
PHDの右上にCWEへのリンクがあるので、今回はここから飛ぶ。
8. CWEルール:イベントソースの設定
CWEの構成画面から、イベントソースとして
Health
を選択する(Health
はPHDを指す)。
9. CWEルール:ターゲットの設定
同じく、ターゲットとしてSNSを選択する。トピックは先程Chatbotで設定したものを使う(PublisherがCWE、SubscriberがChatbotの関係)。
あとはルール名を設定して完了。
受け手と送り手の構成ができたので、これで、1年ごとの証明書更新時にChimeに通知が届くようになる。
証明書更新の通知
更新日になると、DNS更新の恩恵で証明書が自動更新され、以下のようなメッセージがChimeに届く。
ちなみに、AWS BudgetsなどもChatbotに対応しているので、SNS経由でAWSの利用量アラートをChime(ないしSlack)で受け取る、といったことも可能。
- 投稿日:2020-05-15T23:27:47+09:00
【書籍まとめ】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 と互換性のあるクラウド向けのリレーショナルデータベース
- 投稿日:2020-05-15T22:12:01+09:00
[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/ へのリクエストが失敗していることがわかる(添付)GitHub にも同じような issue が立っていた。
https://github.com/aws-amplify/amplify-js/issues/4269設定
IdentityProviderの Authorization Provider にも Clientの設定を追加する必要があった。
余談
AmplifyのDocumentには、すでにある UserPool を使う情報が見つけられなかったので、ここに書いておくことにしました。
(前はあった気がしたのだけれど、あったとしてこの話題の記載はなかったような。。)
まあ、解決したのでよしとする。
- 投稿日:2020-05-15T22:03:56+09:00
EC2の機能まとめ(EBS AMI 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認定ソリューションアーキテクトーアソシエイト試験突破講座
- 投稿日:2020-05-15T20:17:29+09:00
Amazon Linux 2 における sendmail の設定で詰まったこと
Amazon Linux 2 でウェブアプリを作っていて、パスワード再設定機能を実装する際、メールサーバーが必要になりました。
ただ、そこまでしっかりしたサービスではないので、別に迷惑メールに入れられてもいいから無料でやりたいってことで、Amazon Linux 2 にデフォルトで入っている sendmail を使ってみることに。参考にしたのはこちらの記事↓
https://www.server-memo.net/server-setting/sendmail/sendmail-setting_centos7.htmlこの記事をしっかり読めばできると思いますが、自分が詰まった点について書いていきます。
- /etc/mail/sendmail.mc の設定
Dwホスト名
Dmドメイン名
define(confDOMAIN_NAME',
$w.$m')dnlを加筆するのですが、ここは好きに設定して良いようです。メールサーバーに関する知識が薄い自分としてはあらかじめ決めた何かが必要なのかと思いました。
自分は
Dw : mail
Dm : xxx.work (自分でとったウェブサーバー用のドメイン)
に設定しました。
- sendmail.cf作成
sudo m4 sendmail.mc > sendmail.cf
を実行したのですが、なぜかpermission deniedに、、、
sendmail-cf はインストールしたのですが。結果的には、他の設定ファイルも読み込んでくれる
sudo make
コマンドでしっかり作成してくれました。
あとはこの記事に沿って設定すればしっかり使えると思います。
あとこれは自分の環境特有のものかもしれませんが、受信用に設定したメールアドレスにはメールの送信はできなかったので、試す際は別のメールアドレスに送信したほうが良いかもしれません。メールに限らずですけど、通信についてはもっと勉強しないとどこで詰まってるのかもわからないですし、大変ですね。
- 投稿日:2020-05-15T19:33:25+09:00
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()
- 投稿日:2020-05-15T18:33:46+09:00
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のいじり方でした
参考
- 投稿日:2020-05-15T17:00:03+09:00
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の勉強や読書、自身の好きなことに充てる時間とすることで、私生活にメリハリがでてきました。そのお陰で、勉強をする努力をし、努力が当たり前となり、しなくては落ち着かないくらいになり、勉強をする習慣がつきました。
この習慣を今まで通りの環境に変わっても続けたいと考えます。
- 投稿日:2020-05-15T16:35:10+09:00
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コンソールへアクセスし、サインインします。
リージョン
をバージニア北部
に変更します。サービスを検索する
にCertificate Manager
入力します。Certificate Manager
コンソールへアクセスします。証明証のプロビジョニング
の今すぐ始める
をクリックします。- 証明証のリクエストを行います。
- ドメイン名の追加を行います。
- 検証方法の選択を行います。
- タグの追加を行います。
確定とリクエスト
をクリックします。Route53でのレコードの作成
をクリックします。作成
をクリックします。成功
と表示されることを確認します。続行
をクリックします。- 証明書の一覧が表示されます。
- 対象ドメインに対して、作成した証明書が表示されていることを確認します。
状況
が発行済み
になっていればOKです(少し時間がかかる場合があります)。- 以上で、ACMでの作業は、完了です。
2. CloudFrontでの作業
- AWSマネージメントコンソールへアクセスします。
リージョン
をバージニア北部
に変更します。サービスを検索する
にCloudFront
入力します。CloudFront
コンソールへアクセスします。Create Distribution
をクリックします。Web
のGet Started
をクリックします。- Distributionの設定を行います。
Origin Settings
について、下記項目を設定します。 他項目は、デフォルトのままでOKです。
Origin Domain Name
:Webサイトの仮(サブ)ドメイン名
Origin Protocol Policy
:HTTP Only
Origin Custom Headers HearderName
:CLOUD_FRONT_ACCESS
Origin Custom Headers Value
:TRUE
Default Cache Behavior Settings
について、下記項目を設定します。他項目は、デフォルトのままでOKです。Distribution Settings
について、下記項目を設定します。他項目は、デフォルトのままでOKです。
Alternate Domain Names
:最終的に公開したいドメイン名
SSL Certificate
:Custom SSL Certificate
にチェックを入れて、作成したACM
を選択します。Create
をクリックします。- CloudFront Distributionの一覧が表示されます。
- 作成したDistributinonが表示されていることを確認して、
ID
をクリックします。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
- 以上で、CloudFrontでの作業は、完了です。
3. Route53での作業
- 外部から
https://ドメイン名
でアクセスする時、Route53
で作成済みのホストゾーン(Aレコードのエイリアス)
でCloudFront
のドメインがアクセス先になるように設定します。- Route53コンソールへアクセスします。
- 対象のドメインをクリックします。
レコードセットの作成
をクリックします。- レコードセットを作成します。
最終的に、対象ドメインに対して、5件分のレコード(2件の
A
、NS
、SOA
、CNAME
)が表示されていることを確認します。
以上で、Route53での作業は、完了です(実際に変更反映が完了するまで、数十分かかる場合があります)。
4. WordPressでの作業
wp-config.php
を編集します。- Macの
ターミナル
を起動します。- LightsailインスタンスにSSH接続します。
- 下記のコマンドを実行して、
wp-config.php
を開きます。bashvim /opt/bitnami/apps/wordpress/htdocs/wp-config.php
- 下記項目を変更して、保存します。
Apache
の設定を変更します。- 下記のコマンドを実行して、
httpd.conf
を開きます。bashvim /opt/bitnami/apache2/conf/httpd.conf
- 1行目に下記を追記して、保存します。
SetEnvIf CLOUD_FRONT_ACCESS "TRUE" HTTPS RequestHeader set CLOUD_FRONT_ACCESS "TRUE" env=HTTPS
Apache
を再起動します。下記のコマンドを実行します。bashsudo /opt/bitnami/ctlscript.sh restart apache
- 以上で、WordPressでの作業は、完了です。
5. HTTPS化の確認
- 投稿日:2020-05-15T16:19:42+09:00
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.htmlCloudFormationの組み込み関数
CloudFormationにはスタックの管理に便利な組み込み関数があります。ここではそれらの関数のうち2つを紹介します。便利な使い方としては、実行するまでわからない値(SAMテンプレートで作成したLambda関数のAmazonリソースネーム (ARN)だったり、SNSのTopicNameだったり)を取得してプロパティに代入することができます。
Fn::GetAtt(!GetAtt)
まずFn::GetAtt(!GetAtt)について紹介します。短縮形の構文で!GetAttとかかれることが大きので以下!GetAttとして説明します。!GetAtt組み込み関数は戻り値としてテンプレートのリソースから属性の値(リソース名やARNなど)を返します。例えばテンプレートで以下のようにLambdaを定義したとしましょう。
template.yamlResources: 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.yamlResources: 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.yamlRole: !GettAtt SampleIamRole.Arnこれを付け足すと作成したRoleのARNを取得しLambdaに紐づけてくれます。すごく便利です。
Fn::Ref(!Ref)
次にFn::Ref(!Ref)について紹介します。短縮形の構文で!Refとかかれることが大きので以下!Refとして説明します。!Ref組み込み関数は戻り値として指定したパラメータまたはリソースの値を返します。先ほどと同じようにテンプレートで以下のようにLambdaを定義します。
template.yamlResources: 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: SampleTopicLambdaのトリガー(イベント)として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やリソース名など)を取得するにしてもリソースによって使い分けなければいけない
- とにかくドキュメントに全て書いてあるから読み込む
というのがすごく大事だなと痛感しました。
- 投稿日:2020-05-15T11:19:43+09:00
【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にしか向いてなかった。
そこで青いボタンのルートテーブルの関連付けの編集をクリックする。
ルートテーブルIDを0.0.0.0/0のものを選択しをクリックし、保存。
これで10.0.0.0/16の時はlocalで、それ以外の通信の時はインターネットゲートウェイにも接続されるようになった。
これでssh接続をすると、きちんと接続できるようになった。
- 投稿日:2020-05-15T10:14:34+09:00
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にアタッチされているネットワークインターフェースを選択すると画面下にフローログのタブが表示されるので、「フローログの作成」をクリックします。
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秒なので読み替えが必要です。
- フローログを作成してから実際に送信先に出力されるまで、多少時間がかかります。
- 投稿日:2020-05-15T03:14:29+09:00
AWS RDSのバックアップからデータをサルベージする方法
はじめに
AWSのRDSを使っている方は、RDSの機能でバックアップを取っている方も多いでしょう。
とても簡単にバックアップが取れて便利ですよね!
今回はそのバックアップからデータが必要になった場合にサルベージする方法を書いていきます!最新で正確な情報は下記に記載されており、今回はそれを元に作業をした為そちらもご確認ください。
AWS 公式ドキュメント検証環境
RDS Mysql: 5.7.22
サルベージ方法
データをサルベージする方法としては現状2つ方法が存在します。
- バックアップからDBスナップショットを復元する
- DBインスタンス自体が新規作成され、そこにDBが複製されます
- バックアップデータをS3にエクスポートする
- S3へエクスポート後,Glue, Athenaを使用すればデータの解析ができるはずです
- 対象なるDBエンジンのバージョンがある為注意
Mysql 5.7.22はバージョン対象外なので、バックアップデータをS3にエクスポートする方法は今回使用できませんでした。
恐らく後者の方法の方が楽な気はします。
(5.7.24からは対応していた為、よく見ずに試してエラーが出て対象外な事に気付きました)バックアップからDBスナップショットを復元する
基本的にはAWS コンソール RDSメニュー内からスナップショットの復元を行い、DBへアクセスすればデータをサルベージできると思います!
やってみた上での注意点としては下記かなと感じました
- スナップショットの復元はRDSのインスタンス自体が新規作成される為、インスタンスサイズ等に注意
- 復元する際のデフォルトの設定が、元のインスタンスと同じ設定だったので不要に大きなインスタンスで立てそうになりました、、、
- 意外と時間がかかる。今回20GiBのインスタンスの復元をして数十分かかりました、、、
- Sequel Pro等のMysqlクライアントからDBのデータを確認するためには、踏み台サーバーを用意してあげる必要がある
今回はSequel Proからデータを確認したかった為踏み台サーバーを用意してあげて接続しました。
公式でもしっかりドキュメント用意してくれている為、特に困らず接続できました!
(踏み台ってスラング的な言葉だと思っていたのですが、公式でも言うんですね、、、)踏み台サーバーを経由してあげれば、問題なくSequel Pro等のクライアントからアクセスできると思います!
まとめ
AWS RDSはバックアップするのも簡単であれば、復元、データのサルベージも簡単で嬉しい!
- 投稿日:2020-05-15T01:01:33+09:00
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ログインできたので次の記事はそれを含めたことを書こうかな。
- 投稿日:2020-05-15T00:55:07+09:00
既に生成したインスタンスから作ったAMIでインスタンスを作成する
EC2で作ったインスタンスからAMIを作成し、そのAMIを利用してインスタンスを作ります。
手順
EC2のインスタンス画面から「アクション」の「イメージ-イメージの作成」を選択します。
イメージの作成で、イメージ名と説明を入力し、「イメージの作成」を押下します。
これAMIが作成できました。
このAMIを使ってインスタンスを立ち上げます。EC2からAMIの画面を開きます。
先程作成したAMIを選択し、「起動」を押下します。
ここからは普通のインスタンスの作成方法と同じです。
インスタンスの作成はこちらの過去記事にあります。
- 投稿日:2020-05-15T00:21:45+09:00
【初心者】Amazon CloudWatch Synthetics を使ってみる
目的
- 先日AWS東京リージョンの障害があり、「監視はAWS東京リージョンの外からしたほうがよいかも…」と思っていた時に、CloudWatch Syntheticsの話を聞いたので、どんなものか試してみる。
Amazon CloudWatch Synthetics とは(自分の理解)
- 外部からWebサーバ等の正常性監視ができるサービス。
- 監視の設定(canary)を作ると、実体としてはLambda Functionが作成される。
- 先人の記事「Amazon CloudWatch Synthetics を試してみた」や「CloudWatch SyntheticsでオンプレミスのProxyサーバーを経由して監視する 」を読んで、イメージを掴んでから実機で確認する。
- 監視対象のWEBサーバがSrcIP制限をかけているケースを想定して、固定IPでアクセスできるように、VPC Lambda + Nat Gatewayでの検証環境設定とする。
やったこと
- 監視対象のWEBサーバの作成(普通のEC2インスタンス/nginx)
- 監視対象のWEBサーバとは別のVPCにて、NAT GatewayからInternet抜けできるsubnetを作成
- CloudWatch Syntheticsの監視スクリプト(canary)を作成(上記のsubnetをlambdaの動作場所として指定)
- 固定されたSrcIP(NAT Gateway経由)から監視対象のWEBサーバの正常性監視ができることを確認
- WEBサーバにてリンク切れを発生させると、エラー検知できることを確認
構成図
手順
事前準備
- 構成図の通り、以下の環境を作成しておく。
- 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> </htmlCloudWatch Synthetics の監視スクリプト(canary)の作成
- CloudWatch - Synthetics - Canary を作成 を選択し、監視スクリプト(canary)を作成する。
- 設計図を使用する(初心者なので)
- 設計図: リンク切れチェッカー
- アプリケーションまたはエンドポイントURL: 監視対象のWEBサーバのEIP
- VPC設定: 作成したVPC2/Subnet2 を指定する。
動作確認
正常時の動作
- 監視アクセスに成功すると、成功としてカウントされ、スクリーンショット等も取得される。(私の環境では日本語は文字化けしているが…)
- WEBサーバ側のアクセスログにはcanaryのARNが保存される。
/var/log/nginx/access.logx.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になっており、それがエラー原因であることが表示される。
所感
- 監視対象とは別リージョンで起動すればリージョン障害の影響を受けずに監視ができそう。
- 簡単な監視はすぐできそうだが、監視項目をきちんと定めて動作させるには、生成されるLambda Function(node.js)の内容理解やカスタマイズが必要かも…。