CloudWatchの料金が高い

同僚に「CloudWatchの料金高くね?」と指摘される
Slack料金通知画面
image.png

なんか高い!
Billingを確認。
image.png

どうやら詳細モニタリングを1分間にしていたからっぽい

EC2画面でとりあえず全て無効化する。5分間隔だと無料なんですね。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-cloudwatch-new.html

image.png

あとは見守るのみ

続きを読む

CloudFormationでクロスアカウントなVPCPeeringを構築する

概要

別アカウントのVPCとVPCピアリングを行う際のCFnの書き方と、ロールの設定方法について。
なお同一アカウント内でのVPCピアリングだとロール無しでスルッと行ける。

やり方

ざっくり

  1. 前提としてピアリングを行うVPCは各アカウントで用意してあること
  2. VPCPeeringを受け入れる(accepter)アカウントでクロスアカウント許可用ロールを用意
  3. VPCPeeringをリクエストする(requester)アカウントでVPCPeeringリクエストを送信
  4. 完了

ロールの用意

テンプレート

acceptrole.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Accept VPC Peering Role
Parameters:
  AcceptAccountId:
    Type: String

Resources:
  AcceptVpcPeeringRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'AcceptVpcPeeringRole'
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Action: 'sts:AssumeRole'
            Principal:
              # ここで複数アカウントを指定することも可能
              AWS: !Join
                - ''
                - - 'arn:aws:iam::'
                  - !Ref AcceptAccountId
                  - ':root'
      Policies:
        - PolicyName: 'AcceptVpcPeering'
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action: 'ec2:AcceptVpcPeeringConnection'
                # 適宜許可を行いたいVPCを設定
                Resource: '*'

実行コマンド

$ aws cloudformation create-stack 
    --stack-name accept-vpcpeering-role 
    --template-body file://acceptvpcpeeringrole.yaml 
    --parameters ParameterKey=AcceptAccountId,ParameterValue=000000 
    --capabilities CAPABILITY_NAMED_IAM 
    --profile=accepter # profileは適宜

VPCPeeringの作成

テンプレート

vpcpeering.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: VPC Peering
Parameters:
  VpcId: 
    Type: String
    Default: 'vpc-xxxxxxxxx'
  PeerOwnerId:
    Type: String
    Default: '000000000000000'
  PeerVpcId:
    Type: String
    Default: 'vpc-xxxxxxxxx'
  PeerRoleArn:
    Type: String
    Default: 'arn:aws:iam::000000000000000:role/AcceptVpcPeeringRole'

Resources:
  VpcPeering:
    Type: "AWS::EC2::VPCPeeringConnection"
    Properties:
      VpcId: !Ref VpcId
      PeerOwnerId: !Ref PeerOwnerId
      PeerVpcId: !Ref PeerVpcId
      PeerRoleArn: !Ref PeerRoleArn
      Tags:
        - Key: Name
          Value: 'TestPeering'

コマンド

$ aws cloudformation create-stack 
    --stack-name vpcpeering 
    --template-body file://vpcpeering.yaml 
    --profile=requester # profileは適宜

続きを読む

AWS関連用語まとめ

個人的に今勉強中のAWS関連の用語をなるべく簡単にまとめてみました。(語弊がある部分もあるかもしれませんが個人的に理解できる形で落とし込んでみました)。今後も随時追加予定

EC2

仮想サーバ

S3

Amazon Simple Storage Service。オンラインストレージサービス

EBS

Amazon Elastic Block Store。オンライン外付けストレージ

ELB

Elastic Load Barancing。ロードバランサー

EIP

Elastic IP。固定のグローバルIP

RDS

Relational Database Service。クラウド型RDBMS

AMI

Amazon Machine Image。ソフトウェア構成(オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)を記録したテンプレート

IAM

AWS Identity and Access Management。AWSへのアクセスを安全に制御するための仕組み

VPC

Virtual Private Cloud。仮想プライベートクラウド。

CloudFormation

環境設定に関してソースコード化したものを読み込んでAWS上に環境構築してくれるサービス(インフラをコード化してくれるなんてすごいね)

CodePipeline

システムのリリースにおけるプロセスを監視し、自動化・視覚化してくれるサービス。GitHubでMasterブランチへのマージを検知し→ビルド→デプロイ作業を自動で行ってくれる、みたいな事ができる

CodeBuild

CodePipelineで連携している機能の一部。自動でビルドしてくれる

CodeDeploy

CodePipelineで連携している機能の一部。自動でデプロイしてくれる

続きを読む

リザーブドインスタンスが購入できなかった時の話

概要

利用したことなかったけど、試しにリザーブドインスタンスを購入してみよう…!と、カートに入れて購入に進んだところ、以下のエラーメッセージが表示されました。

エラー : Your current quota does not allow you to purchase the required number of reserved instances (Service: AmazonEC2; Status Code: 400; Error Code: ReservedInstancesLimitExceeded; Request ID: ***********)

リザーブドインスタンスが購入できなかった時の画像.png

結論だけ、書く。

サポートの方から訊いたのですが、あまりAWSの利用実績がないアカウントだと、支払い方法が「 前払いなし (No Upfront)」の状態ではリザーブドインスタンスの購入が出来ないようになっているそうです。
支払い方法を「 一部前払い (Partial Upfront)」か「 全額前払い (All Upfront)」に変えた上で購入してね、とのことでした。

納得。
思い切って「 全額前払い 」でリザーブドインスタンス購入。チャリーン。

補足

なお、EC2 リザーブドインスタンス購入上限は、「アベイラビリティーゾーンごと、1 か月あたり 20 のリザーブドインスタンスと、20 のリージョンリザーブドインスタンス。」だそうで、ひと月の中でこの数を超えて購入したい場合は、サポートに購入上限の緩和リクエストが必要となります。

参考:AWS サービス制限 – アマゾン ウェブ サービス

続きを読む

Elastic BeanStalkの環境別のタグ付を忘れたときにどうすんの?って話

1年ぐらい前からBeanStalk使ってます。
なんつうのか、この辺のAWSのマネージドサービスっていうの?ってほんとすごいですよね。
インフラエンジニアなんか必要なくなりますよね。
AWSの機能をガリガリ使って一昔前の3-tier systemなんて、ネットワークの知識もインフラ系のIeasの知識もなくアプリ屋さんがポチポチやってればいつでも復元できるシステム!が出来上がっちゃうんですもんね。
しかもはやりのECSつかったDockerコンテナの仕組みもつかって・・・
「あ〜〜Dockerとか最近ちゃってもう最近開発とか楽でさ〜〜、インフラ屋?いるの?仕事おせえよあいつら」とかほざけるわけです。

俺なんか無職まっしぐらです。

Beanstalkってなんぞや?

さて、まぁ今更ですがBeanStalkってなんぞやって人に簡単に説明しておきますと、
要は初見殺しとも言えるAWSの「CloudFomartion」を”比較的”わかりやすいUIで設定できるというマネージメントシステムです。
基本はネットワーク層+3tier+インスタンススケーリング何かをある程度コントロールしてくれます
更にアプリケーションのデプロイはソースをまとめておくとECR上にコンテナイメージとして作成してくれたり、そこまで必要ない人でもPHP用のAMIを使ってちょっとPHPで動作させたいコンテンツを作ってデプロイしてみたいな事ができます。
この辺、コンソールでポチポチやってると、たしかに時間的にそれなりのリソースを取られますしで開発したアプリケーションのバージョン管理もソレナリにしてくれるので何度も言いますがとても便利なサービスだと思っています。

BeanStalkのアレなところ

こんなに便利そうなBeanStalkなんですが、サーバサイド(アプリケーション開発者)にはなり針を振り気味なサービスなので、少しでも込み入ったことを始めるととたんに出来ないことが出てきます。
そこで、「.ebextentions」というファイルを作ってアプリ層のレポジトリに拡張設定をおいて設定を入れたりする訳です。
まぁ、デフォルトで設定されるCloudFormationの設定項目をアプリ層に置くようにするわけで、インフラ屋のいない会社なんかだと違和感ないというかとても理にかなっているようにみえるんですが、タスクをサーバサイド・インフラサイドと別けているチームなんかだと

インフラ屋がアプリ屋に土下座をしてネットワーク設定なんかを開発アプリレポジトリに入れてもらう

なんていう状態が発生してしまい、なんとなく自分の存在意義を感じられなくなってきたりもします。

そこで、インフラ屋さんは「EBとかつかってらんねぇよ、せめてCloudFormationでやろうぜ・・・(JSON書きたくないけど)」とか言い始めるわけです。

あ、個人的にはterraformに逃げましたw

本題の環境ごとのタグの調べ方について

なんか、閑話休題のボリュームがいつもまとまらず多めになってしまう訳ですが
本当に書きたかったEBで作った環境に対してのタグの後付とかに関してです。

EBで環境を作るとEBにおけるタグを設定しておけば、そのアプリケーションで起動したEC2インスタンスなどには一応Nameタグがついてくれてどの環境かわかりやすくなるのですが、SecurityGroup・ELB/ALBなどには最初にタグを付け忘れたりすると、どの環境で使っているSG・LBなのかを探すのが非常に困難になります。

具体的には例えばSecurityGroupなんかだと下記のようなタグが付くことになります
– awseb-a-3xxxxx2xxxx-stack-AWSEBSecurityGroup-HOGEFUGE1HOGE

まぁ訳わんないですよね。SGに関してはまだNameのタグを設定しておけば自分で任意に環境名をつけられますが
ELBとかだとName=「ユニークな文字列:DNS名」になっているのでAWSのコンソールやawscliコマンドの返り値だけでは一見どの環境用セット用の機材なのかが全くわからない状態になってしまっています。

また、タグ自体も起動段階で設定していないと、環境をすべてEB的に再構築しない限り(つまり環境内のすべてを捨ててもう一度構築し直す処理)を入れないと追加したNameタグなどは設定されない状況に陥ります。

これをあとでチクチクと手作業で入れることになるんですが、
– awseb-a-3xxxxx2xxxx-stack-AWSEBSecurityGroup-HOGEFUGE1HOGE

この文字列はEBの中身を見ているだけだと判別がつかない物なのです。
なぜか
この文字列自体がCloudformationで作られている物だからですwww。
なのでこのELBがどのEBアプリケーションで使われているのか?というのを調べるためには

  • まず、上記の文字列のうち、「awseb-a-3xxxxx2xxxx-stack」までの部分を抜き出し
  • CloudFormationのスタック一覧のFilterをその文字列に入れ
  • 説明欄にちゃんと記載されている「AWS Elastic Beanstalk environment (Name: ‘hogefuge-app’)」を確認するという作業が必要になります。

まぁ調べる方法がある分マシですがね・・・この辺もうデフォルトでNameダグとしてすべての環境に入れてしまってもいいと思うんですけどね

以上、ちょっとしたボヤキでした。
ちなみに、サーバサイドの方の「構築の手間が楽になるからEB使うことを強く推したい」という要望であるプロジェクトでEB使いましたがもう本サービス運用では二度と使いたくありません・・・・

続きを読む

shell scriptでEC2インスタンス内から自分についているタグを取得する

ID=`curl -s http://169.254.169.254/latest/meta-data/instance-id`
TAG_VALUE=`aws ec2 describe-tags --filter "{"Name":"resource-id","Values": ["$ID"]}" --query 'Tags[?Key==`TAG_NAME`][Value]' --region ap-northeast-1 --output text`

autoscalinggroupのtagを付ける設定で起動直後は取れないことがあるのでwhileとかで回そう

続きを読む

EC2のインスタンスタイプを変えて経費削減

はじめに

EC2の料金が高かったので、EC2のインスタンスタイプを変えることによって、安くした体験談です。
実際に対応したのは2017年8月で、awsでは、頻繁に値段が変わるので注意してください。

元の環境のインスタンスタイプ

m3.medium(200台ぐらい)

変更後の環境のインスタンスタイプ

m4.large(100台ぐらい)

スペック比較

タイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Linux/UNIX 料金
m3.medium 1 3 3.75 1 x 4 SSD $0.096 /1 時間
m4.large 2 6.5 8 EBS のみ $0.129 /1 時間

スペックは倍以上にもかかわらず価格は1.3倍!!

結果(1時間あたりの単純計算)

元の料金
$0.096×200=$19.2

変更後の料金
$0.129×100=$12.9

結果
約33%削減

注意点

インスタンスのスペックを倍にしたところでCPUを使いきれないアプリケーションだと、意味がないので気を付けてください。
(アプリケーションの設計やautoscaleのルール等を見直た方が良いです)
今回実施したアプリケーションではマルチプロセスで動いておりCPUも使い切っていたので上手く行きました。
インスタンスタイプを変えることによって思わぬことが起きたりもするので、十分テストしてから移行して下さい。

最後に

検証は必要だったとはいえ、インスタンスタイプを変えるだけで、経費削減できたのは大きかったです。
台数が減ったことにより運用負荷や他のサービスへの負荷も減っていて経費削減以外のメリットもありました。

続きを読む