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

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

CodeBuild + SkaffoldのCI/CD環境のビルド時間を改善した話

# 課題

 元々、PlayFrameworkアプリケーション(Scala)のビルドを、Docker ImageのビルドからECRへのImage Push、EKSへのデプロイまでをSkaffoldに内包する形で行なっていました。
 これらをGithubへのTagプッシュを契機にCodeBuild上で動かしていたのですが、新たに機械学習アプリケーション(Python)が加わり、ビルド時間が12分から20分まで伸びてしまったことで遅さが目についたので、改善に踏み切りました。

# 環境

– プラットフォーム: EKS(PlayFramework + Python)
– ビルド環境: CodeBuild + Skaffold

![CI_CD構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/316261/9184fd0f-744b-8435-8217-8086c76de31d.png)

# 改善施策

改善施策として以下の二点について対応しました。

– 並列ビルドの導入
– ビルドキャッシュ

元記事を表示

AWS Lambda@Edgeをつかって香川県からのアクセスをブロックする

# はじめに

この記事はネタ記事です。

本記事で紹介するような、特定の地域からのアクセスブロック等の行為を推奨するものでは一切ございません。また、筆者は香川県のネット・ゲーム規制条例案について反対の立場です。

ただし、香川県のパブリックコメントへの回答によると

> Q:事業者の対策・協力義務について、具体的にはどのような対策を想定していますか。香川県からのアクセス遮断なども含まれますか。

> A:事業者に自主的な取り組みを呼びかけるものと考えています。

[【全22問】「1日60分までの根拠は」「なぜ議事録がないのか」―― 香川県「ネット・ゲーム依存症対策条例(仮称)」、議会事務局との一問一答]( https://nlab.itmedia.co.jp/nl/articles/2002/06/news075.html)

との回答が得られており、万が一この条例が可決されれば、*事業者による自主的な取り組み*の一部として、香川県からのアクセスブロックを行う可能性は否定できません。

条例が可決された場合には、香川県からのアクセスをブロックすることが技術的に可能であるかを検証すると

元記事を表示

Apache2.4でテスト環境を構築する話

##はじめに
こんにちは、はるちゃです。
開発環境に**AWS**を使用しています。
テスト環境に移行した際に社外の人に見られたくない。。。
と思ったので、メモとして置いときます。

###前提
– AWSのアカウントを所持していること
– インスタンスを生成していること
– apacheをインストールしていること

私はAWS初心者なので **Amazon Linux 2 AMI (HVM), SSD Volume Type**を使用しています。

## 目次
1.ip制限をかける
2.Basic認証の導入
3.ip制限、Basic認証の併用

###ip制限をかける
“`httpd.conf


# Require all granted #ここのコメントをオンにすると全体から閲覧できるようになります。
Require ip XXX.XXX.XX.X #IPアドレスを挿入します。


“`
この方法が一番簡単です。
自社の人なら誰でも見ていいよーって時はこの方法でいいと思います。

###

元記事を表示

AWSのちょっとしたコストを節約した話

みなさま、こんにちは。

**今回はAWSの利用でちょっとしたものだけど地味にお金がかかる部分とそのコスト削減する方法をお伝えします!**

少しのお金でも放っておくとちりつもで洒落にならない金額になることもあるので、この機会に是非見直してみてください。

# その1 EBSのスナップショット:cold_sweat:

意外と見落としがちなこちら!
EBSのスナップショットです。

そんなのあまり作ったことないなーという方もいるかと思います。

ですが、**AMI**はどうでしょうか。

実はAMIとは裏側ではEC2のインスタンス情報とEBSのスナップショットで構成されています。

そのため、AMIを作ったことのある方はもれなくEBSスナップショットを作っています!

しかもここからが怖いところでして、、

### なんとAMIを解放したとしてもEBSスナップショットは削除されません!!

そのため削除する仕組みを別でこさえなければ永遠に増えていきます。

削除する方法はこちらがおすすめです。
https://coatiblog.sios.jp/ami登録解除時、スナップショットを自動

元記事を表示

AWS Cloud9で共有環境を用意する手順

AWS Cloud9の利点の1つが、同じ環境を複数人で共有できることです。
同じファイルを同時に更新したり、チャットでコミューケーションをとったりできます。
AWS Cloud9で共有環境を用意し、複数人で開発を行えるようにするまでの手順をまとめました。

# [1] IAMユーザーを用意する
Cloud9にアクセス出来るユーザーを準備します。

## [1-1] ユーザー権限の違い
AWSCloud9Administrator, AWSCloud9User, AWSCloud9EnvironmentMember、3種類のポリシー(権限)が存在します。
3種類の違いは、大雑把にまとめると以下の通りです。

| ポリシー | 作成 | 編集(*1) | 削除 | アクセス |
|—————————-|——|———|——–|——–|
| AWSCloud9Administrator | OK | OK | OK | OK |
| AWSClou

元記事を表示

AWS経験4年がクラウドプラクティショナーにギリギリ合格した方法

# 概要
AWS経験4年が、クラウドプラクティショナーになんとか合格しました。
点数はまだ出てないですが体感ギリギリだったので、ここが大変だったよという意味でまとめたいと思います。

# AWS経験
フルスタックを名乗っていますが、経験としてはインフラよりはアプリケーション寄りです。
とはいえサービスの監視もやって来ましたし、LambdaやSQSなどを駆使したサーバレスアーキテクチャなども組んできました。

# 試験までの準備
## [AWS Cloud Practitioner Essentials](https://www.aws.training/Details/Curriculum?id=34408)
経験者だと知ってる内容が何十分もひたすら説明されることになり、正直飽きます。
序盤だからこそだとは思いますが、そこにたどり着く前に脱落しました。
動画は本でいう「飛ばし読み」みたいなことがしづらいですし、時間効率悪いなーと思い本主体の勉強方法に変えました。

## [AWS認定アソシエイト3資格対策](https://amzn.to/31sBVay)
資格系は鮮度が命ということで

元記事を表示

[チュートリアル] Amazon SageMakerでの学習・デプロイ

本記事では,Amazon SageMakerを用いて機械学習モデルの学習・デプロイを行うための必要最低限の知識を説明します.普段,仕事や学業で機械学習プロジェクトに携わっているけどAWSにあまり馴染みのないという方のお役に立てば幸いです.

また本記事は,AWSの3daysインターンシップで取り組んだことを題材に,インターンシップでチームを組んだ中田勇介さん([nakata_yusuke](https://twitter.com/nakata_yusuke))と一緒に作成しました.コードは[github](https://github.com/ku2482/sagemaker-tutorial)上で公開しています.

## Amazon SageMakerとは

[Amazon SageMaker](https://aws.amazon.com/jp/sagemaker/)とは,**機械学習モデルを高速に開発・学習・デプロイするためのマネージドサービス**です.よく利用されるEC2は,主にインフラ(やフレームワーク等)を提供するためのサービスなので,EC2の1つ上のレイヤのサービスと

元記事を表示

[AWS]Ubuntu18.04などでlocal TLDが名前解決できない問題

# Problem
内部リソースのドメイン名として、`.local`とするケースはよくあると思いますが、AWSで運用しているサーバをUbuntu18.04にアップグレードした途端、これまでアクセスできていた`.local`の内部リソースにアクセスできなくなるというトラブルに遭遇しました。

実は、Ubuntu18.04では TLDが`.local`のものは名前解決できません。これはOS(systemd-resolved)の仕様です。

## 原因

https://www.freedesktop.org/software/systemd/man/systemd-resolved.html
そもそも`.local` はマルチキャスト DNS のために予約されたドメイン(`.local`TLDは RFC6762 にて非推奨)であり、Ubuntu 18.04 における systemd-resolved の挙動は独自の実装ではなく RFC の規約に準拠したものとのこと。

`.local` ドメインの名前解決を DNS サーバに対してではなく LAN に対するマルチキャストによって行おうとす

元記事を表示

AWS Lambdaでカナリアリリースする

# LambdaのVersionとAlias
AWS LambdaではPublishすると固有のVersion番号が割り当てられる。
Versionには任意の名前のAliasをつけることが可能で、Aliasに関連付けるVersionを変更することで、Aliasを指定してFunctionを呼び出しているユーザが利用するVersionを変更することができる。
![Lambda_Version_Alias.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/13038/02427f6b-9a54-a781-62a1-0305578379c9.png)

# Additional versionを用いて、新しいVersionをカナリアリリースする
Aliasには Additional versionというオプションが存在し、主として指定したVersionとは異なるVersionとその呼び出し割合を指定することができる。
Additional versionの有無や呼び出し割合は任意のタイミングで変更ができ、新しいVe

元記事を表示

AWSルートアカウントのMFA(2段階認証)用の携帯が手元にない場合、着信1回で取らないと無限ループになる

# はまった問題

https://aws.amazon.com/jp/premiumsupport/knowledge-center/lost-broken-mfa/

– AWSルートアカウントの二段階認証番号が昔の電話番号に向けて送られているため、ログインできない状態。新しい電話番号に設定したい
– 上記URLの「unusable~」から専用フォームで問い合わせ、電話が来るのを待つが、いちど不在着信で取れずかけなおすことに
– かけなおすと、カスタマーサポートの自動音声が流れ、AWS関係を問い合わせる番号はなく、とりあえずその他を押す
– AWSがわからない人が出てきていろいろ言われるが何も意味はなくもう一度2に戻る

## なぜこうなったのか

おそらく、Amazonのユーザ側のカスタマーサポートが出てきちゃうので何もできなかったんだと思います。

さらに、どうやら日本のカスタマーサポートは中国人の方が非常に多くたまたまその人にあたってしまったのも大きそうです。

英語と日本語でサポート言語が選べますが、日本語の場合対応が遅いので英語のほうが絶対よかったと思いました。

##

元記事を表示

CloudWatchのログをlocalにdownload

# CloudWatchのをlocalにdownloadしたい

get-log-eventsで落とせるとおもったけど、これloopさせないと全部取れないんですね。

“`download.sh
#!/bin/bash
log_group_name=$1
log_stream_name=$2
response=`aws logs get-log-events –log-group-name ${log_group_name} –log-stream-name “${log_stream_name}” –start-from-head`
next_token=`echo $response | jq -r ‘.nextForwardToken’`
while [ -n “${next_token}” ]; do
echo ${response} | jq -r .events[].message
response=`aws logs get-log-events –log-group-name ${log_group_name} –log-stream-nam

元記事を表示

【AWS】EC2へのMetabaseの導入

以前、Elastic Beanstalkで構築しようとしたのですが、望んだとおりの結果が得られなかったので、自分でEC2へ導入してみようと思いました。

# EC2インスタンスの用意
今回は「t3.small」を利用することにしました。
EBSは`汎用SSD`の`10GB`にしました。
※ Metabaseはポート3000で起動するので、3000にアクセスできるようにセキュリティーグループの設定をしてください。
※ Metabaseにアクセスする為に、Public IPアドレスを付与してください。
  インスタンス生成時の設定 or Elastic IP

# EC2へDockerをインストールする

## yumアップデート
まずは、yumをアップデートします。

“`sh:yumのアップデート
sudo yum update -y
“`
`complete!`が表示されれば完了です。

## Dockerインストール
Dockerをインストールします。

“`sh:Dockerのインストール
sudo yum install docker -y
“`

## Dockerの

元記事を表示

AWS Solution Architect Professional合格レポート

昨日AWS Solution Architect Professionalを受験し、無事合格できましたのでまとめておきます。

合格とは言っても、点数は合格ギリギリなので参考程度に見て下さい。

先日AWS Certified DevOps Engineer – Professionalも一応合格していて、同じくレポート書いてます。

[⇛AWS DevOps Professional合格レポート](https://qiita.com/jusotech10/items/f315d90ceac282b93f53)

## 資格取得状況

| 資格 | 取得日
| ——– | ——– |
| AWS Certified Solutions Architect – Associate (SAA) | 2019-03-01 |
| AWS Certified Developer – Associate (DVA) | 2019-08-29 |
| AWS Certified SysOps Administrator – Associate (SOA)

元記事を表示

AWS学習 もくじ

##まえがき このページはAWSの学習用のメモです。

####学習の目的
・AWSの基礎学習
・AWS認定ソリューションアーキテクト-アソシエイト試験の合格
・ハンズオンでAWSの操作方法を学習

##1.学習した項目

####IAM
####EC2
####VPC
###[S3(Simple Storage Service)](https://qiita.com/takuma-yoshida/items/2bb4e51900cb124efda5)
####Route53
####RDB
####ハンズオン

##2.学習方法

Udemy

##3.その他
~ Linux学習 ~

###参考

元記事を表示

Aurora(MySQL互換)で、外部キーが絡んだINSERT/UPDATEによるデッドロックが検知されない問題

# 何が起きたのか
たまーにproduction環境でデッドロックが発生した

デッドロック発生時のログや各処理ごとで実行されるSQLのログから調査して
デッドロックが発生するクエリは特定できたがstagingやローカルでは再現せず

| 環境 | DB |
|:—————–|:——————|
| production | MySQL互換Aurora
| staging | MySQL
| development| dockerのMySQL

各環境は上記の状態だったため
Aurora独自の何かがあるのでは?と思い検証をしてみることに

### デッドロック発生後の対処
デッドロック発生時、mysqlコマンドでDBにつないで
原因となるクエリをKILLしてみたが解決せず
リードレプリカをフェイルオーバーさせることで対応した

# 検証開始
## デッドロックが起きていたテーブル群

– offers
– offer_child_1
– offer_child_2
– documents
– document_offer_child

元記事を表示

syslog受信 → S3保存 してくれるDockerコンテナ お手軽セット

https://github.com/yagrush/docker-td-agent-syslog-to-s3
↑成果物は、こちらへどうぞ!

# 実現したかったこと

syslogをS3に勝手に保存してくれる環境を、簡単に量産できるようにしたい!

# 作ったもの概要

ポート514にsyslogを送ると S3にgzipで1時間毎に保存してくれるDockerコンテナが、すぐ作れます。
(実際は、Dockerコンテナの中で td-agent が常駐しています)

# 必要なもの

## syslogを保存するS3バケット

## S3バケットにアクセス権限を持つIAMユーザー

## `docker`, `docker-compose` が入ったEC2インスタンス

Amazon Linux release 2 (Karoo) で動作確認済。
ポート514の受信許可(セキュリティグループの設定)もお忘れなく。

→ 必要でしたら [こちら(AWS EC2 AmazonLinux2 のdockerホスト用初期設定)](https://qiita.com/yagrush/items/e85

元記事を表示

aws cli S3でよく使うコマンド

aws cli S3でよく使うコマンドについて記載。

“`
#バケットの内容を表示
$aws s3 ls s3://bucket-name/path

#バケットを作成
$aws s3 mb s3://bucket-name

#バケットを削除(空の場合は削除されない)
$aws s3 rb s3://bucket-name

#バケットを削除(強制削除)
$aws s3 rb s3://bucket-name –force

#バケット内のファイルを削除
$aws s3 rm s3://bucket-name/file-name

#バケット内のフォルダを削除
$aws s3 rm s3://bucket-name/file-name –recursive

#ローカルのファイルをバケットにコピー
$aws s3 cp {ファイルパス} s3://bucket-name/path

#ローカルのファイルをバケットに移動
$aws s3 mv {ファイルパス} s3://bucket-name/path

#バケットをローカルのフォルダと同期(追加・更新のみ)
$aws

元記事を表示

aws cliを複数のプロファイルで使う

aws cliで複数のプロファイルを使う方法について記載

すでにaws cliインストール、デフォルトのプロファイルが設定されている前提。

1.新しいプロファイルを作成する

“`
$aws configure –profile new-user

AWS Access Key ID [None]: xxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxx
Default region name [None]: ap-northeast-1
Default output format [None]: json
“`
Default output formatについては以下のような感じ、

json – JSON 文字列形式で出力されます。
yaml – YAML 文字列形式で出力されます。(AWS CLI バージョン 2 でのみ利用できます。)
text – 複数行のタブ区切り文字列値の形式で出力されます。これは、grep、sed、または awk などのテキストプロセッサに出力を渡すのに役立ちます。
ta

元記事を表示

「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート – ④アクセスキーのローテーションと削除

# はじめに

AWSには、アカウントやリソースへの脅威検知に対応した、**AWS IAM Access Analyzer**, **AWS Security Hub**, **Amazon Inspector**, **Amazon GuardDuty**, **AWS CloudTrail**, **AWS Config** などのサービスが用意されています。

また、[**CIS AWS Foundations Benchmark**](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) という**セキュリティガイドライン**が公開されており、このガイドラインは、**AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定**を集めた**ベストプラクティス集**として活用できます。自身のAWSアカウントがこのガイドラインにどの程度準拠しているのかを確認/監査する手段として、**AWS Security Hub**で、**CIS AWS Foundation

元記事を表示

「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート – ③CISに準拠するためのモニタリングと通知の設定

# はじめに

AWSには、アカウントやリソースへの脅威検知に対応した、**AWS IAM Access Analyzer**, **AWS Security Hub**, **Amazon Inspector**, **Amazon GuardDuty**, **AWS CloudTrail**, **AWS Config** などのサービスが用意されています。

また、[**CIS AWS Foundations Benchmark**](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) という**セキュリティガイドライン**が公開されており、このガイドラインは、**AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定**を集めた**ベストプラクティス集**として活用できます。自身のAWSアカウントがこのガイドラインにどの程度準拠しているのかを確認/監査する手段として、**AWS Security Hub**で、**CIS AWS Foundation

元記事を表示

OTHERカテゴリの最新記事