cli53でroute53のリソースレコードを全て削除する。

調べ物のログです。 Route53のWebコンソール上からホストゾーンの削除を試みたところ以下のエラーが出ました。 ホストゾーンを削除するには、最初に Zone Apex の NS および SOA リソースレコードセット以外のすべてのリソースレコードセットを削除する必要があります。 (HostedZoneNotEmpty 400: The specified hosted zone contains non-required resource record sets and so cannot be deleted.) 5000件以上のリソースレコードを登録しているので、流石に画面ぽちぽちで削除するのはつらいなあ… と思っていたところcli53というツールを見つけました。 barnybug/cli53 - Github 以下のコマンドでリソースレコードを全て削除できます。 cli53 rrpurge {zonename} --confirm その後、以下のコマンドでホストゾーンを削除 cli53 delete {zonename} 大量にレコードを登録したい場合も、テキストを用意してimportオプションで読み込むことができます。 cli53 import --file zonefile.txt {zonename} zonefile.txt の中身は以下のような形です。 test 0s A 8.8.8.8 test2 0s A 1.1.1.1 »

JAWS DAYS 2018に参加してきました(LTもしたよ)

先週末は下記のイベントにスカラシップで参加しました。 JAWS DAYS 2018 | テーマは「no border」2018年3月10日(土)にTOC五反田メッセ(東京)にて開催 JAWS DAYS とは JAWS DAYSは主催JAWS-UG、後援AWSJで行われるJAWS-UG最大のイベントで、全国のJAWS-UGメンバーが中心となりボランティアベースでイベントの企画・準備をし、AWSに関する幅広いテーマのセッションが行われています。 参加登録1900名ぐらいあったそうです。 めちゃめちゃ大きいイベントでした! セッション AWSクラスタに捧ぐウェブを衛っていく方法論と死なない程度の修羅場の価値〜OWASPとTop10とminiHardening〜 2017年に新しくなったOWASP TOP10を活用していこうというお話とセキュリティ演習のお話でした。 セキュリティ要件をどうすればいいか悩んでいる方にとってもOWASP TOP 10は良い判断材料になるとのこと。 セキュリティは運用フェーズでやると高コストになるので、 ちゃんと設計の段階から考えて作りましょうとかそういう話もありました。 確かに開発やってると、運用段階でセキュリティのことを考えると辛くて 直すのにとても苦労しましこともあります。 そういうのも減らすためにも、ちゃんと設計開発の段階から セキュリティのことを考える必要があるなと感じています。 OWASP TOP 10読み終わったので、活用していきたいと思います。 セッションの後半はMiniHardeningの内容でした。 セキュリティの演習環境をAWSでどうやって実現するか、 また演習ではどういうことをやっているのかを部紹介してもらいました。 本家Hardeningのカジュアル版であるMiniHardeningの裏側の話が聞けて良かったです。 実は私も2017年12月に行われたセキュリティミニキャンプ沖縄でセキュリティ演習環境を提供したことがあるあったので、今回のお話は大変貴重でした。 特に侵入テストの申請の時にIPアドレスやインスタンスIDが変わる環境においてどうやって申請したらいいのか、私も悩んでた時期があって、どうやってその辺の申請をやっているのか気になっていました。私も悩んでAWSサポートに相談交えながらも申請出したこともあり、非常に親近感のある内容でした。 AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来- AWSは2017には1430のアップデートをしているらしい。すごい…! これだけ多い新サービス、新機能のキャッチアップをどうしたら良いかという疑問に対し、 全ては不可能だから、自分の好きなものから始めたら良くて、 とにかくみんなで知見を共有することでした。 AWS認定も、とにかくドキュメントを読み込むことと、 アーキテクチャの事例を学ぶことが大事だそう。 新サービスがたくさん出てても全てが全く新しい技術というわけでもないし、 学んだことは絶対どこかで生きてくるんだろうなっていう感じでした。 英語のセッションも、レシーバーから通訳が流れてきてたので非常に助かりました。 AWS × 形式手法で人知を超えたセキュリティを手に入れろ IAMポリシーを結構書くようになって、 シミュレータと挙動が違くてうんざりしてたこともあったり 結構、経験と勘、雰囲気で書いてることもあって悩みがあって Alloyなども使ってみるなど、結構学ぶものが多かったです。 AWS のマネージドサービスを使ったセキュリティ強化のための自動化では、 WAFを利用して攻撃を自動ブロックする話や、GuardDutyでの驚異検出など サービスを守るためのセキュリティツールをフル活用していた感じでした。 コンテナを守る技術 2018 コンテナの基礎知識からProductionで運用するまでの 主にセキュリティ周りのノウハウをまるっと色々とご紹介していました。 コンテナのセキュリティもそうだけど、 »

EC2インスタンスから自宅のGoogleHomeに発言させる

google-home-notifier - Github を利用すると、 「OK. Google.」のトリガーを不要にし喋らせたい内容をサーバからPUSHできる。 ただ、自宅にサーバ用途にできそうなPCもないのでどうしようかと迷ったので AWSのEC2インスタンスを使うことにした。 ただ、GoogleHomeのポートをグローバルに公開するのもなかなか危険なので VPCと自宅のFortigateでサイト間VPN接続を行うことにした。 全体構成 AWS側はVPCを作って、インスタンスを立てただけ。 自宅側はプロバイダの制約により、FortigateでPPPoE接続ができないため、 ホームルータのNAT配下に設置。 ただし、ホームルータの機能にDMZパススルー機能があるため FortigateのWAN1に接続に利用するIPアドレス 192.168.172.2 をパススルーのIPとして登録しておく。 AWSのVPN接続は、IPSecを2本張るので、BGPによる経路交換も必要となる。 (基本は1本しか使わないと思うんだけど) GlobalIPが変更になったらIPSec切れちゃうでしょとか思うですが、 契約してからここ5年くらい経つけど、GlobalIPは一度も変わってない。 auひかりの仕様では動的グローバルIPを割りあてるよって書いてあるけど、 ホームルータが認証情報を持っているのか、ハードウェアを交換しない限りはIPアドレスは変わらなさそう。 GoogleHomeは事前にWifiに接続しておいてIPアドレスを確認しておく。 AWS側作成 TerraformでVPCネットワーク部分だけを作成してみた。 書いた後に気づいたけど、ルートテーブルに自宅側のルーティング情報をルートテーブルに書いてなかったので、VPN構築後に手動追加した。 インスタンスも手動追加するので、Terraformでは記載していない。 インスタンス作成 CentOS7のAMIからインスタンスを生成, 作成したVPCネットワークに所属させる。 yarn, node, google-home-notifierのインストールを行う 自宅側 AWSでVPN接続の作成後、画面からサンプルコンフィグを落とせるのでダウンロード。 自宅のFortiOSは5.2系なのだけれどサンプルのままじゃ通らないコンフィグがあるので注意。 VPN接続の作成時に自宅側のグローバルIPアドレスを入力するため、 サンプルコンフィグではlocal-gwにグローバルIPアドレスが記述されているが、 ここはFortigateのWAN1のIPアドレス192.168.172.2に変更する必要がある。 後は、VDOMも今回は使わないので、コンフィグはこんな感じに。 コンフィグを入力してしばらくすると接続が完了する。 接続状況はAWSのVPN接続の詳細画面でアップになっているかを確認する。 実際に喋らせてみる サーバ側に用意したプログラム(ほぼサンプル)。 下記を実行すると、GoogleHomeが「こんばんは」と喋ってくれる。 const googlehome = require('google-home-notifier') const language = 'ja'; googlehome.ip('192.168.1.112', language); googlehome.notify('こんばんは。', function(res) { console.log(res); }); 雑感 自宅にサーバ置いてないので、意外と大掛かりな構成になってしまったけど、この構成ならAWSからでも発言させたい内容はPUSHできるので、自宅にサーバを置かないと決めてる方でもいけそう。(Fortiは使うし、グローバルIPは固定だけど) 本当はEC2インスタンス立てずにLambdaでやりたいけど、google-home-notifierってLambdaいけるかは分かってないので、この辺りも動作検証したい 料金見積もりしたらVPN接続とインスタンス台で毎月30ドルくらいかかっちゃうので、思ったよりはコスト高かった…(笑) AWSのVPN接続は作成か終了しかないのだけれど、「停止」も欲しいなって思った(需要あんのかな) Amazon Echo届いたので、明日からはAlexaスキル作って遊びたいと思います。 »

JAWS-UG沖縄 AWS re:Invent 2017新サービスおさらい に参加してきた

新年明けましておめでとうございます。 2018年はたくさんのイベントに参加したり、 自分のためになるような記事やTipsを たくさん残せるように頑張りたいなと思ってます。 JAWS-UG沖縄 AWS re:Invent 2017新サービスおさらい に参加してきたのでその時のメモ。 re:Invent 2017 行ってきました報告 - 栄野川さん 海外旅行時のTips含め, re:Inventでの様子とか。 re:Inventのアプリが便利でキーノートの翻訳とかもあったらしい。 一度は海外イベントの雰囲気も味わいたいなって思いました。 AWS re:Invent 2017 新サービスおさらい - 與儀さん IVS CTO Night & Day】AWS re:Invent 2017 振り返り - slideshare 上記のスライドを参考におさらいをしました。 2016年もそうだったんだけど、サービス増えすぎてすごい…. EMSとFargateは使ってみたいのでそのうち検証する。 Amazon Time Sync Serviceもすごい。閏秒対策もできてて無料で利用できる。 閏秒は毎回悩む問題だけど、自分で考えなくてよくなるので良いよね。 今回Apache Active MQ互換のAmazon MQもでたんだけど、 個人的にはSQSのFIFOキューを東京リージョン対応を望んでます。 Rekognition との関わりについて - 宮里さん 自社サービスの課題解決にRekognitionを利用した話。 基本構成は、S3のFile PUTをトリガーにLambdaからRekognition呼び出して結果をDynamoDBに書き出す感じ。 当時は15人しか認識できないので、集合写真は分割して対応するなど涙ぐましい努力が。 最近では、画像内の顔を最大100個まで対応できるようになったので大抵のものには対応できそう。でも、MAX100人ってすごい…! LT LT募集してたので、私もLTしました。 ネタは、「セキュリティミニキャンプの演習環境をAWSで作成した話」なんですが、 内容はほぼほぼOWASP OKINAWA#6の内容でやりました。 資料は気が向いたらどこかにアップします。 »

沖縄でAWS SAA受験してきました(合格したよ)

去年4月にお仕事を始めてからAWSを少しずつ触るようになり、 自前でAWSアカウントを用意していろいろ遊んだりするようになったりと AWSはお世話になりっぱなしです。 AWSの勉強会とか参加していく中で、認定試験の存在も知りましたが その時は試験会場が東京、大阪、福岡くらいの3都市くらいしかなくて、 沖縄から受験するには一番近くて福岡まで遠征する必要がありました。 物理的な制約があるのでどうしようもない感じはするんですが、 東京とか行く機会があれば腕試しはしたくて Shownetで東京行った時も土日で空いてるところ探しても 運悪く見つからず諦めてました。 (ボランティアやってた時は全力で楽しんでたので、そんな余裕は無かったなと今になって思う^^;) とまあ、東京行く機会もほとんど無いので 受験はほぼほぼ諦めてたんですがそんな時に朗報が どうやら沖縄でも受験できるようになったらしい。 物理的な制約は無くなったので後はやる気だけ、 というかやる気は元々あったので 上のスライドを見たその日に勢いで受験申し込みしました。 受験日までにやったこと Qiitaとかいろいろなところで合格体験記書いてる人いますが、 実際やってることはあんまり変わらないはず。 合格する ことよりも これから先もAWSで楽しく遊べるようにいろいろなことを知る というのをモチベにやってました。 私自身はプレッシャーにすごく弱いので 合格しなきゃみたいな気持ちでやると確実に失敗するので あまり自分を追い詰めるような感じで目標は立てないようにしてます(笑) そのせいなのか、 個人的には勉強をしたというより遊んでいたっていう感覚に近かったです。 とりあえずノー勉で模擬試験を受験 今まで利用してきたサービスの見直し AWSのクラウドデザインパターンを読む Blackbeltの資料を読む サービスを利用する 気になったところは公式ドキュメントを読む 暇なときは問題集を眺める とりあえずノー勉で模擬試験を受験 お金はかかるけど模擬試験は受験しといたほうがいいです。 現状で何が理解できてて何が理解できてないのかが確認できるし、 問題がどういう感じで出されるのか UIはどんな感じなのか とか事前に分かるので これ受けてるか受けてないかは結構差が出ると思います。 模擬試験の注意事項にも書いてあるけど 問題の解答は貰えないので、解答は後で調べ直す感じで。 今まで利用してきたサービスの見直し 今まで利用してきたサービスはまず見直しました。 EBSはどのタイプを利用しているのか、 今利用しているインスタンスタイプは最適なものなのか、 ただEC2インスタンス建てて無いよねとか、 ELBはCLB,ALBどっちがお得に利用できそうかとか、 今使っているサービスがどう動いてて、他にはどういった機能があるのかとか 実際に試験を受けるまではここばっかり気にしてました。 AWSのクラウドデザインパターンを読む 実は一年以上前に買って積んでた本 Amazon Web Servicesクラウドデザインパターン設計ガイド いい機会なので1から読んでました。 デザパタはWikiのページもあるので、こっち読んでもいいはず。 知らなかったデザパタもあって結構勉強になりました。 デザパタさんありがとうございます。 Blackbeltの資料を読む Blackbeltの資料は1つ1つのサービスに対しスライドのボリュームがかなり多くて読み応えがあります。 »

IAM Roleで特定のS3バケットのみアクセスが可能なユーザを作成する

久々の更新。 昨日はネットワークスペシャリストを受験してきたけど散々でした… (ちーん IAMで特定のバケットのみRead Writeを許可するユーザを作成する必要があったのでその時のメモ。 ポリシを自分で書いちゃえばいけました。 例えばhogehogeというバケットに対してフルアクセスを許可したいときは { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3::hogehoge", "arn:aws:s3:::hogehoge/*" ] } ] } 後はユーザを作成して上記のポリシをアタッチするだけでOKです。 実は下記にポリシシミュレータがあって、ポリシの検証をができるらしい。 https://policysim.aws.amazon.com/home/index.jsp 上のポリシで検証したらFailed出てS3のアクセスができないよってログが出てたのだけれど、 個別バケットの場合は、ポリシシミュレータがFailedを返すようでした。 実際に上記のポリシをアタッチしたユーザでaws-cliコマンドを叩くとそのバケットだけにアクセスできました。 »

GCPインスタンスのスナップショットを定期的に取得する

GCPインスタンスのスナップショットを定期取得・削除してみる GCPで動作するインスタンスのスナップショットはGCPのコンソールからポチポチやると 簡単に取れたり不要なものを削除したりできるのだけれど、毎日コンソールを開けて手でポチポチやるのは大変なので自動化する。 その時のメモ。 ServerlessFrameworkでは、GoogleCloudFunctionも対応してるのでこれでいけるんじゃないかと思ったのだがeventがhttpしか選択できず cron的な使い方ができないので断念。。。 Google Function Events - Serverless.com 楽に実装できそうなLambdaに逃げることに。 GCPを操作するライブラリはNodeJSで書かれたgoogle-cloud-nodeを使用しました。 GoogleCloudPlatform/google-cloud-node - Github 下記のドキュメントにサンプルコードがあるのでそれを利用してます。 スナップショットの作成 https://googlecloudplatform.github.io/google-cloud-node/#/docs/compute/0.7.1/compute/disk?method=createSnapshot スナップショットの削除 https://googlecloudplatform.github.io/google-cloud-node/#/docs/compute/0.7.1/compute/snapshot?method=delete 実際に書いたコード 328/gcp-backup-cron - Github 1つのプロジェクトだけで利用するのではなく、複数のプロジェクトにも使い回しができるよう プロジェクト情報やインスタンス名は全て環境変数(serverless.yml)に記載するように気を使ってます。 インスタンスのスナップショットはポンポン消しちゃって大丈夫なのかなって疑問に思ってたんですが、 削除時に依存関係のあるデータは全て次のスナップショットに移動されるそうです。 スナップショットを削除する - GoogleCloudPlatform »

S3 パフォーマンス改善

沖縄でもAWS 認定ソリューションアーキテクトが受験できるというのを先日知り、腕試しをしてみようと思い資料漁りをしてます。 そんな中、S3への大量のリクエストをさばくにはどうすればいいんだろうとか考えてました。S3っていつもデータぶん投げるためだけに使ってたし、勝手にスケールするんでしょ〜とか思ってたけど 大量アクセス時に負荷が高い場合の性能の引き出し方が載ってた。 http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html S3のバックエンドでは、keynameでパーティションを分割してバケットリクエストの増加に耐えるようになっているみたい。こっちにも例が載ってた。 http://aws.typepad.com/aws_japan/2012/03/amazon-s3-performance-tips-tricks-.html なので、keynameにprefixつけて運用するような設計にしておくとよきに計らってくれるみたい。(もちろんつけ方は気をつけないといけない) もちろんこれは、高負荷の時に考えるもので下記のリクエストレートが常時超えてるような場合に有効. PUT/LIST/DELETE が 100回/sec GET 300回/sec 急激な増加で下記を超える場合がありそうならサポートに連絡的なことがかいてある。 PUT/LIST/DELETE が 300回/sec GET 800回/sec でも、GETリクエストを抑えるだけなら、CloudFrontにキャッシュさせて配信させるほうが安心かも。 自分のブログはAWSに移行してから、S3 + CloudFrontで配信してる。 特にS3に大量アクセスが来るわけではないのでS3だけ使ってても良かったのだけれど…. https://www.slideshare.net/hz_ouchi/20130222-16684434 備忘録として残しておく。 そういや1年前に買った書籍 AWS クラウドデザインパターン設計ガイド 実は1年前に買って全然読んでなかったのを思い出して昨日読んでました(笑) デザインパターンはある程度知ってたけど、 実際に手を動かして環境を作って動かしてみたのは少ないので、気になるところだけでも作ってみようと思う。 さすがに75パターンあると全部試すのは結構しんどいから気になるところだけ。 AWSは進化が激しく古くなったパターンもあるようで、そこは公式読みながら補完したほうがよさそう。 Cloud Design Pattern »

EC2インスタンスのディスクを拡張する

EC2でインスタンスを建てる際にコミュニティAMIにあったCentOS7(RightScale)を選択し、ディスクを50GBにしておいたんだけど、いざログインしてみると10GB程しか認識されていない。 # df -Th ファイルシス タイプ サイズ 使用 残り 使用% マウント位置 /dev/xvda1 ext3 9.8G 1.3G 8.0G 14% / どうやったら認識されるんだろうと思ってあれこれやってたところ参考になりそうな下記のブログを見つけました。 AWSのCentOS6.7のインスタンスでボリュームが8GBしか認識しない - 渋谷で働くとあるエンジニアの適当なブログ よし、これの通りにやってみよう。 # yum install parted # parted -l モデル: Xen Virtual Block Device (xvd) ディスク /dev/xvda: 9.8GB # yum install epel-release # yum -y --enablerepo=epel install cloud-init.noarch cloud-utils-growpart # export LANG="en_US.UTF-8 # growpart /dev/xvda 1 # export LANG="ja_JP.UTF-8" # vi /etc/cloud/cloud.cfg disable_root: 0 # disable_rootを0に変更 # parted -l モデル: Xen Virtual Block Device (xvd) ディスク /dev/xvda: 53. »

CloudFrontのお話 + α

先週末あたりからAWSのCloudFrontさんを触ってみてます。 CloudFrontを触ってる理由は、証明書をEC2側で持ちたくなかったから ただそれだけです(笑) 実際に証明書の配置も楽チンだったので、今後も使っていきたい。 このタイミングで、CloudFrontの証明書の更新もお願いされてたのだけれど 同じ名前で証明書はアップロードできないので 証明書を削除 証明書を登録 という形をとりました。 証明書のアップロード後、CloudFront側で使えるようになるには少し時間がかかる。 僕の場合、2,3時間程度だった気がする。 クラスメソッドさんにはお世話になりっぱなしだ。 Amazon CloudFrontの独自ドメインSSL証明書をAWS CLIでアップロードする - ClassMethod 後は、EC2へのアクセスはCloudFrontからのみ受け付ける設定もやりました。 画面からぽちぽちやるのもめんどいので、aws-cliを使ってセキュリティグループに追加していく。 $ curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .ip_prefix' > iplist CIDRのリストが取れるのでvimでちょちょいと魔法をかけて 下記を実行。 aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 80 --cidr 13.32.0.0/15 aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 80 --cidr 52.46.0.0/18 aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 80 --cidr 52.84.0.0/15 aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 80 --cidr 52. »