DeepLens + Rekognition + Raspberry Pi で会議室を自動解錠する


・Rekognition API での顔認証
・Raspbery Pi のGPIO制御


AWS DeepLensを購入しました〜セットアップ編〜
AWS DeepLensを購入しました〜映像をみる、SSH接続編〜
AWS DeepLensを購入しました〜サンプルプロジェクトデプロイ編〜
AWS DeepLensを購入しました〜コミュニティプロジェクトデプロイ編〜


Automating security updates on AWS and pushing the output to Slack


Hello there! My name is Adam, an aspiring DevOps engineer who joined the Infrastructure team of Linkbal this year in February. My main focuses are optimizing the AWS environments and the server middleware. Occasionally I will make something cool and useful, most likely involving AWS, which I would like to share with you.

Today, I will be detailing how to schedule a security update script to be run on an EC2 Linux instance on a time schedule, then push the output logs to a Slack channel for everyone to see.


First, let’s consider what we want to achieve, so as to determine what the end result should be:

  1. Automatically run security updates on an EC2 Linux instance on a pre-determined schedule.
  2. Be notified of the update and see the output in a Slack channel.
  3. Be able to change the time schedule or turn on/off without having to access the instance.

The 3rd point is important as it adds a layer of convenience to the method. If it ever becomes necessary to stop the updates, we want to be able to do so quickly and easily, without having to remove what we put in place.


  • AWS account with privileges to create a CloudWatch rule and use Systems Manager.
  • EC2 Linux-based instance with AWS CLI installed.
  • IAM role attached to the EC2 instance. 
  • Permission to access the EC2 instance via SSH connection and use root credentials.
  • A Slack account with a channel for receiving the output logs and the permission to create a webhook.

Plan and script

The source code originally came from here: Slack notification via curl
The diagram was drawn using a free account in LucidChart.

# This script runs a security update then pushes the output to Slack.

VAR1=$(sudo yum update --security -y)

function post_to_slack () {
    SLACK_URL={Slack web hook} # Replace this with your own web hook, without the braces

    case "$2" in

curl -X POST --data "payload={\"text\": \"${SLACK_ICON} ${SLACK_MESSAGE}\"}" ${SLACK_URL}
post_to_slack "Result of security update for $IP: $VAR1" "INFO"
exit 0


  1. Create a Slack web hook for the channel you want to receive the log output in. Paste the web hook into the script as the value for SLACK_URL (without the {} braces).
  2. Upload script to the instance (take a note of the path). This can be done from the command line as such:
    $ scp -i /path/to/key.pem ec2-user@{IPv4 DNS}:path/to/file
    Or you can SSH connect to the instance, make a new file and paste the code in there:
    $ ssh -i /path/to/key.pem ec2-user@{IPv4 DNS}
    $ vi /path/to/file/
    It doesn’t matter were the file goes, so long as you know where it is.
    Be sure to change the permissions on the script so that it can be executed.
    $ chmod 775 /path/to/file/
    Install the AWS SSM agent: (installed by default on AWS Linux 1 AMIs since 2017.9 and on all AWS Linux 2 AMIs)[Manually install SSM agent on Amazon EC2 Linux instances]
    Add the policy “AmazonEC2RoleforSSM” policy to the role being use by the EC2 instance.
  3. Go to CloudWatch, select “Rule” on the left toolbar and then “Create rule”. Set the time expression by either a fixed rate or a cron expression. Note that the time will be in UTC, so depending on your timezone you will need to adjust the hour and possible day values. As an example, to update at 2am UTC Monday-Friday, the expression would be:
    0 2 ? * MON-FRI *
    For help with cron expressions in AWS, please see: AWS CloudWatch – How to schedule events
    Select “SSM Run Command”.
    Select the document “AWS-RunShellScript (Linux)”
    Target key = InstanceIds (can choose a different target, if you prefer)
    Target values = {Instance ID} i.e. i-a1b2c3d4e5
    Click on the “Configure parameters” drop down.
    Commands = ./
    WorkingDirectory = /path/to/file/
    ExecutionTimeout = 100
    Select “Create a new role for this specific resource”
    Click on “Configure details”. Give it a name and a description.
  4. The CloudWatch Rule uses AWS Systems Manager to call the SSM Agent which runs the script.  The script will run the update, then pass the output to a post function which uses the Slack web hook to post the output in your channel.
    Even if there are no updates due, the message will still be sent.
  5. Success! You can customize the name and image of the web hook in the Slack settings menu.



We have now configured for security updates to run on the AWS EC2 Linux instance on a specific time schedule, with the result of the update being sent to a channel in Slack. The script can be turned on/off easily from the AWS console (or by the AWS CLI) and we can change the time schedule there as well.
Let us now consider the advantages and disadvantages of this method.


  • Quick and simple to set up.
  • The script is reusable; can be used on most if not all Linux instances on AWS. Only the Slack web hook would have to be changed if a different channel was required, otherwise no need to edit the script.
  • Only a basic understanding of AWS is required.
  • Virtually zero cost.


  • CloudWatch rule must be stopped manually. Could set up a trigger with SMS and Lambda to stop the rule without the need for human intervention.
  • Only works for Linux instances. Windows would require something different.
  • Root privileges are required to set up (possibly avoidable with AWS Systems Manager).
  • Would be easier to understand if more details concerning the instance were put into the script, such as the name tag. (Can use ec2-metadata to obtain a lot of this information, but tags are not included in this list. Could use AWS CLI to get the instance name tag.)

Overall we have achieved what we set out to do. There are ways we could improve the script, but for now this is more than suitable.

I hope you have enjoyed this post, it’s a simple start with many more things to come. See you next time!


  1. Source code:
  2. LucidChart:
  3. AWS CloudWatch – How to schedule events:
  4. AWS EC2 – Manually install SSM Agent on AWS EC2 Linux instance:
  5. Manually install SSM agent on Amazon EC2 Linux instances :









GitLabの導入(Backlog + GitHub からの移行)

いま、社内に GitLab を導入中です。数ヶ月かけて、これまで利用していた Backlog と GitHub を、GitLab に置きかえていく予定です。

Backlog は課金額がユーザ数に依存しません。そこで、いろいろな人が関わる課題管理には Backlog を利用しています。過去の履歴を見ると、2013年から 5年以上もお世話になっています。現在のアクティブユーザー数は120名ほど。

一方 Backlog の Gitリポジトリ機能はそれほど魅力的ではないため、コード管理には GitHub を利用しています。しかし GitHub はユーザ毎にお金がかかるため、コードを書く人に限定して使っています。現在のアクティブユーザー数は50名ほど。



  1. 誰かが「○○をやりたい」と提案する。誰が何を提案してもいい。要点をまとめて Backlog に proposal(提案)として登録する。
  2. やるか、やらないか、優先度はどうするか、を毎朝のミーティングで決める。
  3. やることになった案件は planning(企画)フェーズに移行し、ディレクター、デザイナー、エンジニアなど案件毎に適切な人が仕様を決める。
  4. planningフェーズの仕様をレビューして問題がなければ、dev フェーズに移行させる。課題の優先度は毎朝の会議で決める。
  5. 優先度高の課題の中から好きなものを、手が空いたエンジニアが自分で取っていく。
  6. 開発が終わったら、提案者やディレクターがテストする。問題がなければリリース待ちとなる。
  7. リリースする。「街コンジャパン」の場合、少ない日で 1件、多い日で 10件くらいのリリースをする。ただし、売上が一番多いのが土日祝であるため、休みの前日のリリースはなるべく避ける。

AWS re:Invent 2018 参加レポート : 海外カンファレンスについて

リンクバル技術部の川畑です。AWS re:Invent 2018の全日程が終了しました。。
ちなみに私は海外カンファレンスはAWS re:Inventしか参加したことないので、AWS re:Invent寄りの内容になることをご了承ください。


AWS re:Invent 2018 参加レポート : 4日目

リンクバル技術部の川畑です。AWS re:Invent 2018に参加するためラスベガスに来ています。本日もKeynoteでLambdaでのRubyサポート、そしてCOBOLも使えるようになるなど衝撃的な新サービスの発表がありました。
本日はそのLambdaのセキュリティ観点を学ぶために「Securing Serverless Applications and AWS Lambda」というワークショップを受けてきたので、その内容を簡単に共有させて頂きます。


AWS re:Invent 2018 参加レポート : 3日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。Amazon Web ServicesのCEO Andy Jassy氏による Keynote に参加してきました。毎年新たなサービスが発表されるのが恒例となっているようです。朝8時に開始にもかかわらず、朝7時に到着した時点ではすでに300メートルの10列ぐらいの行列ができていました。それでも何とか中にはスムーズに入ることができました。この辺りの誘導は手慣れたものだなと思いました。




AWS re:Invent 2018 参加レポート : 2日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。
渡米するのは今回が初めてで、すべての食事はデカくて肉ばかり、という印象を持っていましたが、AWS re:Invent で提供される食事はベジタリアンの方を考慮してか、野菜が多く提供されている印象です。ライスは食べてませんが、日本にいるより野菜と果物を多く摂取している感じです。
2日目の今日は以下の Session に参加してきました。

  • SEC322-R – [REPEAT] Using AWS Lambda as a Security Team
  • DEV315-S – Building SRE from Scratch at Coinbase during Hypergrowth
  • CON301-R1 – [REPEAT 1] Mastering Kubernetes on AWS
  • DAT401 – Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB

本日はこの中の、Uging AWS Lambda as a Secutiry Team のセッションの内容についてご紹介させて頂きます。


AWS re:Invent 2018 参加レポート : 1日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。本日は以下の Session に参加してきました。

  • Scaling Push Messaging for Millions of Netflix Devices
  • Unleash Team Productivity with Real-Time Operations
  • [REPEAT] Creating and Tuning Models with Amazon SageMaker
  • Keep Your IoT Devices Secure
  • Monday Night Live

Netflixのプッシュメッセージのアーキテクチャ、PagerDutyのDevSecOpsの事例などが聞けていろいろと参考になりました。本日は Key Note の1つである Monday Night Live について書かせて頂きます。


AWS re:Invent 2018 参加レポート : 事前準備

リンクバル技術部の川畑です。AWS re:Invent 2018に参加するためラスベガスに来ました。個人的には基調講演でEKSの東京リージョンやECSのリザーブドインスタンスやスポットインスタンスなどの発表などがあればいいなと楽しみにしています。本日はAWS re:Invent・ジャパン・ツアー・参加登録について書かせて頂きます。

AWS re:Inventとは

– AWSサービスの多様なセッション・最新テクノロジー・サービスの使い方・お客様事例などを学ぶ学習型イベント
– 基調講演による新サービスの発表
– Have Fun という 勉強したらリフレッシュするイベントも用意


AWS Lambda+Python3で複数のRDSを起動停止

aws python rds



  • boto3でRDSを操作するために高レベルAPIのResourcesを使いたかったけど、RDSは提供されていないようなので低レベルAPIのClientsを使用
  • AWSアカウントの指定リージョン全てのRDS情報を取得
  • RDS情報より指定したタグとRDSのステータスによりフィルタリング(すでに停止されているRDSを停止しようとすると、スクリプトでエラーとなるため)
  • フィルタリングされたRDSを起動停止


  • python3.6
  • boto3