AWS関連のことを調べてみた2020年06月08日

AWS関連のことを調べてみた2020年06月08日
目次

AWSのセキュリティ系サービスをごく簡単にまとめる

AWSは常に成長を続けています。
サービス数もすごい勢いで増えています。
すべてのサービスをそらで列挙できる人は、もはやほとんどいないかも知れません。

今回は、セキュリティ系のものに絞って、ごく簡単に紹介します。
(すべてのセキュリティ系サービスではありません。)

# 確認テスト
各サービスがどの部分に適用されるか、把握できていますでしょうか?
簡単なパズルゲームを作ってみたので、まずは試してみてください。

ごくシンプルなAWSアーキテクチャ図に対し、下の部分にあるセキュリティサービスのアイコンを、もっとも関連性が高い箇所(赤枠)にドラッグアンドドロップするパズルです。

https://aws-puzzle.pict3.org/aws-security-puzzle/index.html

# 各サービスの3行紹介
## AWS WAF
ALB, CloudFront, API Gatewayに簡単に適用できるサーバーレスなWAFです。
マネージドルールという提供された汎用ルール群を使うパターンと、自前でルール群を運用するパターン、そのハイブリッド構成があります。
2019年

元記事を表示

AWS EC2でCron使うならタイムゾーンを意識する [for Ubuntu 18.04]

Cronを使ってLet’s Encryptの自動更新とか設定したはいいものの,自動的にスクリプトが走っていないと感じた時とかに見直したい設定がある.それが**タイムゾーン**.
AWSでは作成したインスタンスではUTC(協定世界時.日本標準時より9時間前の時刻となる)になっているので,これをJST(日本標準時)に修正してあげる必要がある.ただし,OSの設定を変えるだけでは不十分なので,いくつか追加の作業が必要.

※ Cron自体の設定方法の記事はこの世界にありふれているため,この記事ではCron自体の設定方法は取り扱わない.

# タイムゾーンの確認

“`bash
$ date #現在時刻を確認する.
$ strings /etc/localtime #設定されているタイムゾーンを確認.
“`

`strings /etc/localtime`を実行した時に最後の行にUTCとかJSTとか書かれている.これが現在設定されているタイムゾーンとなる.ここが既にJSTである場合はCronの再起動や,Cron自体のタイムゾーンを確認する.

# タイムゾーンを設定する
“`bash

元記事を表示

Capistranoを用いた自動デプロイ

## Capistranoとは
自動でデプロイが行えるツールです。
Capistranoを使うことで、以下の2つの記事で行ったデプロイ作業が自動化できます。
AWSへのRailsアプリのデプロイ その1
AWSへのRailsアプリのデプロイ その2

## gemのインストール
まずは必要なgemのインストールから行います。

“`
group :development, :test do
gem ‘capistrano’
gem ‘capistrano-rbenv’
gem ‘capistrano-bundler’
gem ‘capistrano-rails’
gem ‘capistrano3-unicorn’
end
“`
“`
bundle install
“`
gemをインストールしたら、以下のコ

元記事を表示

AWS OrganizationsとAWS Control Towerを使って、管理可能なアカウント運用をする

# AWS OrganizationsとAWS Control Towerを使って、管理可能なアカウント運用をする

個人の趣味の開発だったりしても、AWSアカウントをマイクロサービス的な観点でいくつも作って、別々のアカウントで作業したいなあと感じたときに、でも統制が取れてなかったりセキュリティに不安があるのは嫌だなぁと感じたので、そのあたりのために必要なことをまとめました。この延長線で、業務の方も便利になっていくと良いと思い、作業録と共有を兼ねて記事にアウトプットしました。

ここは〜の方が良いなどあれば、いつでもウェルカムです!

AWS OrganizationsとAWS Control Towerにより、保護されたアカウント運用が可能となる状態を目指す。

下記がやること。

– ルートアカウントの設定
– ルートアカウントは組織管理に徹し、アプリケーションには関与しないクリーンな状態を保つ
– AWS Organizationsの設定
– アプリケーションをマイクロサービスで作成できるようにアカウントを組織として管理する
– AWS Control Tower

元記事を表示

Terraform+AWS Fargateで、タスク定義を更新(ローリング更新)してみる

# Whats?

* AWS Fargateに対するデプロイ方法は3種類あり、そのうちローリング更新を試してみたい
* 環境と更新操作は、Terraformで行う

というのをやってみたいという記事です。

# AWS Fargateでのデプロイ方法

Fargateというか、ECSでのデプロイ方法ですが。

ドキュメントによると、3つがあるようです。

[Amazon ECS デプロイタイプ](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deployment-types.html)

* ローリング更新
* CodeDeployを使用したBlue/Greenデプロイ
* 外部デプロイ

AWS内でやろうとすると、ローリング更新かBlue/Greenデプロイ(CodeDeploy利用)の2つになるということですね。

# ローリング更新

ローリング更新に関するドキュメントはこちら、ですが、あんまり書いてないですね…。

[ローリング更新](https://docs.aws.amazon.co

元記事を表示

【FX】Dockerを使ってPythonでoanda-APIを叩く

## 概要
FXの取引といえば基本手作業でぽちぽちやるものだ。
これをPythonを使ってプログラミングで自動で決済したりできると凄い楽しいことになる。
機械学習を用いて未来の価格を予測したり、決められた時間や決められたロジックで自動売買の設定だってできる。
ここではそのための最初の一歩として、 Dockerからapiを叩いてPythonを使った決済ができるようになる を目標とする。

## 前提となる環境
– oandaに口座(デモ口座でもよし)を作り、APIのtokenを発行する
– docker, docker-composeを使える環境

##oandaの設定
Pythonなどのプログラミング言語を用いてFXの売買をするためにはAPIを叩かなければいけない。
SBI証券とかDMMFXなどFXをできる業者はいっぱいあるが、国内でFX用のAPIを提供しているところはoandaくらいなので、まずはoandaで口座を作る。
バグとかがあったら大変なので、最初はデモ口座でいいだろう。15分くらいあればちゃちゃっとできる。
oanda APIを使ったFXの取引についてはQiitaだと以

元記事を表示

CloudFormationに日本語コメントを含めるとエラーになる場合の解決方法

# 前提条件
– Windowsで*.ymlに日本語コメントを含めてAWS CLIを叩いた場合のみ起こる
– マネコンから*.ymlをアップロードした場合は不明
– AWS CLIをインストーラからインストールしている場合のみ起こる
– 結論から言うとインストーラからインストールしているAWS CLIをアンインストールしてpipでgithubからインストールすればいい

# テンプレートに日本語コメントを含めるとエラーになる
“`yaml
# これは日本語だ
AWSTemplateFormatVersion: ‘2010-09-09’
Parameters:
Parameter:
Type: Number

Resources:
# 日本語だ、これは
Lambda:
Type: ‘AWS::Lambda::Function’
“`

こういうテンプレートファイルを`aws cloudformation create-stack –template-body file://hoge.yml –stack-name foo`と実行すると

元記事を表示

自宅PCのバックアップを目的とした3大クラウドのアーカイブストレージを比較してみる

# 初めに

HDDの挙動が怪しく念のためバックアップを取っておかねば…となりました。
数百GB以上となるとOneDriveやGoogle Driveを見る限り年間1万円を超えてしまいます。
(安いか高いかは人によって感覚は違うと思いますが)

今回のバックアップとしてはアーカイブストレージが目的と合致する上にコストが低く抑えられるので、
3大クラウドのサービスで比較してみることにしました。

利用したことのあるのは3大のクラウドのうち実質AWSのみ、
かつアーカイブストレージは使ったことないので実際に使ってみてではなくサービスの説明を見てという形です。
読んで明らかな間違いがありましたらご指摘いただければと思います。

また料金等の情報は記事投稿時点(2020/06/08)に準じます

# 注意書

あくまで僕の今回の用途で金額を重視した場合に限った限定的な比較ですので、
実際に業務や個人で使う場合は各々サービスの特徴を把握したうえで使っていただければと思います。
実際GCPでは通信料が多く程単価が安くなりますし、Azureは予約要領でお安く契約ができます。
また、必要な部分の

元記事を表示

AWS アカウント管理のためにそれ系のサービスをキャッチアップしたメモ

# AWS アカウント管理

プライベートで使っているAWSアカウントの整理と、そこから先に継続的で柔軟な開発を続けていくための下準備のために、AWSのアカウント保護や脅威検出周りで試したり、調べたことのまとめ。

まずルートアカウントの現状を整理した。アカウントは1個だけもっていたが、これをルートアカウントとして使っていき、組織を使ってサービス単位のアカウントを運用できるようにする。

– ルートアカウントからすべてのリソースを削除
– ルートアカウントの請求設定などを確認して不備があれば修正
– ルートアカウントの組織の状態を確認
– ルートアカウントに開発用のAdmin権限グループを作成
– 個人の単位でIAMユーザを作成して、Admin権限グループに追加
– 作成したIAMユーザに2要素認証を設定(IAMは基本的に、作るたびにMFAを必ずセットで有効化している)

## アカウント保護

とりあえず、目的に対してやる意義が高そうとおもった順番から書いておく。

– ControlTower
– 安全なルールで・・・複数アカウントにまたがる保護
– GuardDuty

元記事を表示

【AWS】本番環境でのエラー確認方法について

#はじめに
自分用備忘録のためにという部分も含んでいます。
本番環境で自分が困った時に行ったエラー確認について記載します!!

#エラー①
ある特定のページが開けない、下記画像のようなエラーが出る。そういったときは本番環境のcurrent/logに入りログを確認し、エラーの原因を探ります。

※本番環境でのエラー確認では、currentに入らないと細かなエラーを確認することができない

3c5c1a9def06514f46f881ecc180ce14.png

“` ruby

cd current/log

tailf production.log #これで本番環境での細かい動きが確認できる(rails s)みたいなモノ

“`

#エラー②
そもそもサイトにはいることができない。そういった

元記事を表示

AWSおぼえがき

# 本稿について
AWSについてお勉強しているうちに、へーそうなんだと思ったことを覚書して言ってます
完全備忘用です
随時更新しようと思います

### ルートテーブル
パブリックサブネットは、VPCにインターネットへ出るためのインターネットゲートウェイがアタッチされ、ルートテーブルにインターネットゲートウェイが日もづいている場合にインターネットに直接出入り可能なサブネット。

ルートテーブルにインターネットゲートウェイが日もづいておらず、VPC内のみの通信やDirect Connectなどプライベート接続のみの場合はプライベートサブネットとなる

なお、インターネットへのルーティングがない場合は、yumコマンドやapt-getコマンド、Windows Updateなどを実行できないため、プライベートサブネット上のEC2インスタンスからインターネットにアクセスしたい場合はNATゲートウェイなどを利用する必要がある
用途としては、ALB/ELBやリバースプロキシサーバなどをパブリックサブネットに配置してインターネットからのトラフィックを受けて、セキュアな情報を格納するデータベースなどを

元記事を表示

Amazon APIGatewayのSAMテンプレートを更新してcloudformation deployしたときの動作を確認する

# はじめに
AWSのAPIGatewayは使えば使うほど奥が深くて色々できて楽しい。
楽しいけど、自由度が高い分動作が謎の部分が多い。
特に、SAMテンプレートは内部動作を隠蔽してくれるので、組み合わせた場合は正しく動作検証をしていく必要があるだろう。
と思い、APIGatewayを記述したSAMテンプレートの更新をした際の動作を確認してみよう。

# 前提条件
– 使っているアプリケーションが[以前の記事](https://qiita.com/neruneruo/items/fc6685779f155b13601a)の続きなので、記事の内容を把握している
– Amazon APIGatewayをマネージメントコンソールからでもSAMテンプレートでも触ったことがある

# SAMテンプレートの修正
とりあえず、今回の目的はデプロイの修正であるため、SAMテンプレートの修正内容は何でも良い(以下の修正も、Lambda関数側では使用していないRequestBodyのチェックを追加したもので意味はない)ので、以下のように修正してみる。
この修正内容自体は別の記事で説明する。

元記事を表示

【AWS EC2】ログイン用の秘密鍵を無くした場合の対処法〜スクリーンショット付きバージョン〜

#はじめに
AWSのEC2ログイン用の秘密鍵をなくしてしまい、ログインできなくなってしまった。
[AWS EC2ログイン用の秘密鍵を無くした](https://qiita.com/nntsugu/items/1bcb9810c8a2cc6985b3)をもとに、何とかログインできた。しかし説明が文字だけであったり、一部おそらく貼り付けミスで重複している箇所があったため、本稿でスクリーンショットを載せつつ改めて説明したいと思う。

#概要
[AWS EC2ログイン用の秘密鍵を無くした](https://qiita.com/nntsugu/items/1bcb9810c8a2cc6985b3)内で
①新しいKey Pairを作り
②秘密鍵を無くしたEC2インスタンスのAMIを作って
③AMIからEC2インスタンスを作成する際に、新しいKey Pairを適用する

とあるがもう少し噛み砕きつつ、理由を説明すると
①秘密鍵は復元できないため、新しい秘密鍵を作る必要がある。
②AMIとは「Amazonマシンイメージ」の略。同じ設定で複数のインスタンスが必要な場合は、1つのAMIから複数のインスタン

元記事を表示

【AWS/Cloud9】Cloud9の環境が開かない場合の対処法

# 事象
Cloud9にて自身の環境を開こうとすると

>「This is taking longer than expected. If you think there might be an issue, contact AWS Support. It might be caused by VPC configuration issues. Please check documentation.」

上記のエラーメッセージがで、環境を開くことができなくなった。
同じエラーに遭遇した人はまず下記の記事を読むことをお勧めします。

https://qiita.com/Atsushi_/items/b38c18feac4708164696
https://qiita.com/somarihair/items/759d525153ae68ce4a7f

上記2記事のように再起動をしても解決しない場合、かつ**インターネットゲートウェイを消した覚えがある人**は
下記を見ていただくと解決する(かもしれません)。

## 原因
Cloud9が使用していたEC2サーバーの所属しているVPCのイン

元記事を表示

[AWS] CloudFormationの基本

#Cloud Formationとは
AWSリソース(EC2インスタンス、 RDS DBインスタンスなど)のモデル化およびセットアップに役立つサービス。テンプレートに設定を書けばその設定通りにCloudFormationがAWSリソースを作ってくれる。**無料サービス**。

#テンプレートってどうやって書くの?
JSONまたはyaml形式で次のような感じで書く。

**JSON形式**

“`
{
“AWSTemplateFormatVersion” : “2010-09-09”,
“Description” : “A simple EC2 instance”,
“Resources” : {
“MyEC2Instance” : {
“Type” : “AWS::EC2::Instance”,
“Properties” : {
“ImageId” : “ami-0ff8a91507f77f867”,
“InstanceType” : “t1.micro”
}
}
}
}
“`

元記事を表示

ヘルスチェックがInServiceにならない

#はじめに
CLBにインスタンスをアタッチしたらInServiceにならなかった時の調査アーカイブです。

##ヘルスチェックとは
調べた感じ、CLBからぶらさがってるインスタンスにPingを投げてレスポンスがなかったらOutofServiceになるらしい。
なのでミドルとかApacheとかのコンフィグに異常があるのかな?て心配はしなくてよさげ。

##CLBのパラメータ確認
![スクリーンショット 2020-06-07 20.19.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/278897/b3002255-fae0-5bea-5683-1bd7b87fc859.png)

25(SMTP)は例があまり多くないのですが、読んだ感じ25ポートが空いてれば良いっぽい。
となるとSGのインバウンドが怪しいのですが、普通に25許可してました。

##ポートがListenか疑う
となるとこれだな!と思ったのは良いが調べ方がわからないw
今回はAmazonLinux2なのですが、こんな感じで設定状況を確認で

元記事を表示

AWS備忘録 〜VPC基礎編〜

# これは何

くろかわこうへいさんの素晴らしい動画

– [くろかわこうへいのAWS講座VPC編](https://www.youtube.com/watch?v=mHi2yFWLz9M&list=PL2nCE2iR-lpmb9AR1ka1hq6WWORZ_crp2)の#1~4(チャンネル登録は[こちら](https://www.youtube.com/channel/UCirsB9lWx1Vao8jmbMK_nQg))
– [動画で学ぶAWS講座 VPC編](https://www.youtube.com/watch?v=aQpMBqn5mRY&list=PLtpYHR4V8Mg-hNPfIpCToq3ZLhvXMHFel)のsection1~4(チャンネル登録は[こちら](https://www.youtube.com/channel/UCX30pfp4p82rIiSJmBygADw))

を見て学習した内容を備忘録としてメモ。

項目毎に記事を分けても良かったのですが、自分が備忘録として見返した際に**1つの記事にまとまっている方が良いな**と思ったため、長くなってしまいました

元記事を表示

オンプレのSubversionサーバーをクラウドへ移行

# 1. はじめに

職場のオンプレのサーバー上で動かしていたSubversionを、AWSに移行した際の作業記録として記事をまとめてみました。

# 2. やりたい事

1. 今年(2020年)にサポートが切れるOS(CentOS6系)から、新しいOSに移行したい。
* OS切り替えのタイミングで、どうせならクラウドに移行して管理コストも削減したい…
2. 従来は社内からの利用、もしくは社外からVPN接続での利用に限られていたので、それと同じ形で利用したい。
* 今時は「境界防御型」のセキュリティではなく、「ゼロトラストネットワーク」と言われているので、若干時代遅れ感がありますが…
3. 従来と同様に、Subversionのバックアップをしっかり取っておきたい。
* 今までは`svnadmin dump…`コマンドで得られたダンプファイルを、NASにバックアップしていました。

# 3. 実現方法

1. 新しいSubversionサーバーは、AWS上に作成する。
* Subversionのマネージドサービスは無さそうだったので、EC2上にSubversionをイ

元記事を表示

API Gatewayでファイルアップロード(multipart/form-data)を扱う

お疲れ様です。
モバイルコムの石黒です。

先日、Amazon API Gatewayでファイルをアップロードする際、
めちゃくちゃハマったお話です。

# 事象

アプリに到達するまでにファイルのデータが消えてしまっている。
アップされたはずのファイルを参照するとnull。

# 結論

APIの「設定」でバイナリメディアタイプをサポートする設定を追加(この場合multipart/form-data)し、
**デプロイ**します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103853/adc9c751-8e26-063b-d383-3709aa99a6d7.png)

※デプロイしないと設定が反映されないことを見逃していて、めちゃくちゃハマりました。

ぶっちゃけ設定する箇所はこれくらいかも知れません。
プロキシ統合でもリソースでもVPCリンクでも特に変わらないと思われます。

元記事を表示

AWS QuickSight + AWS Athena + AWS Glueで業務ログを統計化して可視化してみた

# はじめに
新規自社サービスを開発すると、サービス利用状況の統計出力がしたくなってくる。
また、統計情報はセールスチームや開発チームなどステークホルダに広く展開するべきだろう。
毎月DBやログからデータ取ってきてexcelで図表化は大変なので、自動化&スマートなUIでさくっと仕組みを作ってしまおう。

# やりたいこと

* S3に保存されている業務ログからアクセス履歴を統計出力する
* Aurora MySQLからトランザクションデータやマスタデータを統計出力する
* 統計データは可視化されWEBブラウザで関係者に展開できる(もちろんユーザ認証は行う)
* データの更新作業は自動化する
* 本来の開発業務の時間を削ることなく、可能な限りAWSマネージドサービスを利用してサクッと作る

# やれること
QuickSightの公式を見るとイメージが湧くだろう。
https://aws.amazon.com/jp/quicksight/

# 環境
![quicksight.png](https://qiita-image-store.s3.ap-northeast-1.amazonaw

元記事を表示

OTHERカテゴリの最新記事