Route53にDNS自動登録

  • EC2インスタンスを起動すると内部DNSにAレコードを登録し、停止するとAレコードを削除するinitスクリプトを作成しました。
    ”ZONE_NAME”だけ書き換えてあとはコピペでいける!はずです!

起動停止スクリプト作成

/etc/init.d/aws_route53_edit
#!/bin/bash
# chkconfig: 2345 99 10
# description: regist A record to aws route53
# Author:



ZONE_NAME="ゾーン名"
HOST_NAME=$(aws ec2 describe-tags --output text --query "Tags[?ResourceId==`$(curl -s http://169.254.169.254/latest/meta-data/instance-id)` && Key==`Name`].Value")
IP_ADDRESS=$(curl -s http://169.254.169.254/latest/meta-data/local-ipv4)
HOSTED_ZONE_ID=$(aws route53 list-hosted-zones | grep "Id" | awk '{print $2}' | sed -e 's//hostedzone///' | sed -e 's/,//' | sed -e 's/"//g')
LOCK=/var/lock/subsys/aws_route53_edit


case "$1" in
  "start" )

  ARECORD_JSON="{
    "Changes" : [
      { "Action" : "UPSERT",
        "ResourceRecordSet" : {
          "Name" : "${HOST_NAME}.${ZONE_NAME}",
          "Type" : "A",
          "TTL"  : 60,
          "ResourceRecords": [
            { "Value" : "${IP_ADDRESS}" }
          ]
        }
      }
    ]
  }"
  touch $LOCK
  ;;

  "stop" )

  ARECORD_JSON="{
    "Changes" : [
      { "Action" : "DELETE",
        "ResourceRecordSet" : {
          "Name" : "${HOST_NAME}.${ZONE_NAME}",
          "Type" : "A",
          "TTL"  : 60,
          "ResourceRecords": [
            { "Value" : "${IP_ADDRESS}" }
          ]
        }
      }
    ]
  }"
  rm -f $LOCK
  ;;

  *)
  echo $"Usage: $0 {start|stop}"
  exit 2
  ;;

esac

自動起動停止登録

sudo chmod 755 /etc/init.d/aws_route53_edit
sudo chkconfig --add aws_route53_edit
sudo chkconfig --list aws_route53_edit

確認

  • マネジメントコンソールから落とし上げをして別ウィンドウでRoute53を監視

ハマったところ

  • ロックファイル
    /var/lock/subsys/以下にファイルが無いとうまく動かないことがしばらくわからず時間をかけてしまった。ない状態でやると起動時のレコード登録はうまくいくがレコード削除がされなかった

その他

  • 起動停止時にCloudWatch登録削除なども作成予定なのでスクリプト名やロックファイル名は”aws_サービス名_動作名”などがよさそう

続きを読む

[JAWS-UG CLI] IAM #?? IAMロールのポリシー作成 (aws-opsworks-service-policy)

AWS CLIを利用して、OpsWorks用のIAMポリシを作成してみます。

前提条件

IAMへの権限

  • IAMに対してフル権限があること。

STSへの権限

  • get-caller-identityサブコマンドを実行する権限があること。

AWS CLIのバージョン

以下のバージョンで動作確認済

  • AWS CLI 1.11.14
コマンド
aws --version

結果(例):

  aws-cli/1.11.70 Python/2.7.12 Linux/4.4.11-23.53.amzn1.x86_64 botocore/1.5.33

バージョンが古い場合は最新版に更新しましょう。

コマンド
sudo -H pip install -U awscli

0. 準備

まず変数の確認をします。

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <IAMのフル権限を許可されたプロファイル>

変数が入っていない、適切でない場合は、それぞれの手順番号について作業を
行います。

0.1. プロファイルの確認

プロファイルの一覧を確認します。

コマンド
cat ~/.aws/credentials 
       | grep '[' 
       | sed 's/[//g' | sed 's/]//g'

結果(例):

  iamFull-prjz-mbpr13
  <IAMのフル権限を許可されたプロファイル>
変数の設定
export AWS_DEFAULT_PROFILE='<IAMのフル権限を許可されたプロファイル>'

再確認

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <IAMのフル権限を許可されたプロファイル>

1. 事前作業

1.1. IAMポリシー名の決定

ポリシー名を決めます。

変数の設定
IAM_POLICY_NAME='aws-opsworks-service-policy'

同じ名前のポリシーが無いことを確認します。

コマンド
aws iam list-policies 
        --scope Local 
        --max-items 1000 
        --query "Policies[?PolicyName == `${IAM_POLICY_NAME}`].PolicyName"

結果(例):

  []

1.2. IAMポリシードキュメントの作成

ポリシードキュメントのファイル名を決めます。

変数の設定
FILE_INPUT="${IAM_POLICY_NAME}.json" 
          && echo ${FILE_INPUT}
変数の確認
cat << EOF

        FILE_INPUT: ${FILE_INPUT}

EOF
コマンド
cat << EOF > ${FILE_INPUT}
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:*",
                "iam:PassRole",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:DescribeAlarms",
                "ecs:*",
                "elasticloadbalancing:*",
                "rds:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        }
    ]
}
EOF

cat ${FILE_INPUT}

結果(例):

JSONファイルを作成したら、フォーマットが壊れてないか必ず確認します。

コマンド
jsonlint -q ${FILE_INPUT}

エラーが出力されなければOKです。

2. 本作業

IAMポリシーの作成

変数の確認
cat << ETX

        IAM_POLICY_NAME: ${IAM_POLICY_NAME}
        FILE_INPUT:      ${FILE_INPUT}

ETX
コマンド
aws iam create-policy 
        --policy-name ${IAM_POLICY_NAME} 
        --policy-document file://${FILE_INPUT}

結果(例):

  {
    "Policy": {
      "PolicyName": "aws-opsworks-service-policy",
      "CreateDate": "2017-04-17T01:23:45.678Z",
      "AttachmentCount": 0,
      "IsAttachable": true,
      "PolicyId": "ANPAXXXXXXXXXXXXXXXXX",
      "DefaultVersionId": "v1",
      "Path": "/",
      "Arn": "arn:aws:iam:::XXXXXXXXXXXXpolicy/aws-opsworks-service-policy",
      "UpdateDate": "2017-04-17T01:23:45.678Z"
    }
  }

3. 事後作業

IAMポリシーの確認

ARNを取得します。

変数の設定
IAM_POLICY_ARN=$( 
        aws iam list-policies 
          --max-items 1000 
          --query "Policies[?PolicyName==`${IAM_POLICY_NAME}`].Arn" 
          --output text 
) 
        && echo "${IAM_POLICY_ARN}"

結果(例):

  arn:aws:iam::XXXXXXXXXXXX:policy/aws-opsworks-service-policy

ポリシのバージョンを取得します。

コマンド
IAM_POLICY_VERSION=$( 
        aws iam list-policies 
          --max-items 1000 
          --query "Policies[?PolicyName==`${IAM_POLICY_NAME}`].DefaultVersionId" 
          --output text 
) 
        && echo ${IAM_POLICY_VERSION}

結果(例)

  v1

ポリシの内容を見てみましょう。

コマンド
aws iam get-policy-version 
        --policy-arn ${IAM_POLICY_ARN} 
        --version-id ${IAM_POLICY_VERSION}

結果(例):

完了

続きを読む

Amazon EC2 Systems Managerを使ってCloudWatch Logs エージェントをインストールする

Amazon EC2 Systems Managerを使用してコマンド実行を実施する手順です。
試しに Systems Manager を使ってCloudWatch Logs エージェントをインストールしてみます。
内容としては初心者向けになっています。

事前準備

SSMエージェントのインストールは実施済みであること。
:beginner: Amazon EC2 Simple Systems Manager (SSM) エージェントのインストール

AWS マネジメントコンソールからのコマンド実行

EC2の「SYSTEMS MANAGER SERVICE > コマンドの実行」より「コマンドを実行」を選択します。

2017-06-22-17-41-30.png

今回はLinuxへのコマンド実行を行うので「AWS-RunShellScript」を選択します。

2017-06-22-17-42-39.png

今回は1台のインスタンスのみを対象とするので「手動選択」で対象の1台のみ選択します。

2017-06-22-17-45-32.png

「Commands」に実行したいコマンドを定義します。
今回はCloudWatch Logs エージェントのインストールと起動を実施します。

yum install -y awslogs
service awslogs start

「Working Directory」「Execution Timeout」は必要に応じて入力して下さい。
Execution Timeoutのデフォルトは3600(1時間)です。
「Run」を選択します。

2017-06-22-19-36-34.png

コマンドの発行は成功したようなので「結果を表示」を選択します。

2017-06-22-17-55-58.png

「ステータス」が成功(Success)になっていれば最後のコマンドの終了コードが0で返ってきています。

2017-06-22-17-58-10.png

出力タブの「出力の表示」を選択しコマンドの実行結果を確認できます。
2017-06-22-18-00-40.png

yum コマンドの実行結果が表示されています。

2017-06-22-18-02-33.png

ただし「出力の表示」で出せるのは画面にも記載のある通り2500文字までなので出力結果が多い場合は、「コマンドを実行」の詳細オプションで「S3への書き込み」をチェックし設定します。

2017-06-22-18-06-27.png

CloudWatch Logs に送信されたログデータの表示

CloudWatch に移動し「ログ」画面よりロググループを選択します。
ロググループ名は「awslogs.conf」の初期値が「/var/log/messages」になっています。
また、デフォルト値のリージョンが「us-east-1」になっているのでバージニア北部へ移動します。

2017-06-22-18-51-31.png

/etc/awslogs/awscli.conf

[plugins]
cwlogs = cwlogs
[default]
region = us-east-1

/etc/awslogs/awslogs.conf

~ 省略 ~
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

ログストリーム名を選択します。
ログストリーム名は「awslogs.conf」の初期値がインスタンスのIDになっています。

2017-06-22-18-52-52.png

対象のインスタンスの「/var/log/messages」が表示されます。
CloudWatch Logs エージェントをインストールしたタイミングより前のログも取得できています。
ログの取得までは成功です。

2017-06-22-19-02-32.png

上手く行かない場合

ポリシー設定の不足の可能性

対象インスタンスに割り当てているIAMロールにて「インラインポリシー」を設定します。

2017-06-22-18-34-45.png

カスタムポリシーを選択します。

2017-06-22-18-36-49.png

「ポリシー名」「ポリシードキュメント」を設定し「ポリシーの適用」を選択します。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html

2017-06-22-18-39-29.png

2017-06-22-18-41-17.png

続きを読む

[AWS Summit2017]サーバレスアプリのアンチパターンとチューニングメモ

[AWS Summit2017]サーバレスアプリのアンチパターンとチューニングメモ

AWS Summit2017で聞いてきたサーバレスアプリのアンチパターンとチューニングのメモです。
Lambdaの仕組みの中まで知らなかったのと、気をつけるべきところが多くあったので、とても参考にさせていただいております。
プラスで自分が他に参考にしたサイトもリンクさせていただきます。

アプリが遅くなる原因

① プログラムの問題

ロジックそのものの問題は、各言語のベストプラクティス、最適化手法はそのまま当てはめるべき
Node.jsで自分は書くことが多いので、下記を参考にしている

② コンピューティングリソース不足

メモリ設定は最適にすること
メモリサイズと比例してCPU処理能力も割り当てられる
コストを気にしがちだが、メモリを増やせば処理時間は早くなるので、結果的にコストはそこまで変わらないときもある
※ ちょっとずつ変更して性能が変わらないところが最適値

③ コールドスタート

Lambdaファンクションの実行時におきていること
1. ENIの作成(10秒から30秒かかる、Durationには含まれない)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開(S3からDLやZipのファイル展開、Durationには含まれない)
5. ランタイム起動・初期化(グローバルスコープの処理もこのタイミング)
6. 関数/メソッドの実行(ハンドラーで指定した関数・メソッド、Duration値はここの実行時間)
全てを実行するのがコールドスタートという
1-5は毎回同じ内容が実行される(再利用することで効率化できる)

コールドスタートが起こる条件

  • コンテナが1つもない
  • 利用可能な数以上の同時リクエスト
  • コードや設定変更

早くするためにはどうしたらよいか?
コンピューティングリソースを増やす(メモリを増やす)
ランタイムを変える(各言語の仕様にもよる・・)
パッケージサイズを小さくする(展開に時間がかかるので)
VPCは必要でない限りしようしない(その分10ー30秒ぐらい余計に必要)
⇒ VPC内のリソースが必要であればDynamoDBStreamsとLambdaで非同期に
Global領域の遅延ロードを行えばいい

④ アーキテクチャの問題

同期でInvokeすると同時実行数の制限に引っかかる
できるだけ、非同期でInvokeするとスケーラビリティの観点ではいい
APIGatewayからの処理として、Put系であればSQSとかに流してしまう
いかに並列処理を行うかが大事
⇒ 1つあたりのイベントを小さくして、同時に並列で動かせるアーキテクチャにする

⑤ 同時実行数

同時実行数=3s/exec x 10req/sec < default1000
ストリームベースの場合は少し違う
⇒ ストリームのシャードの数だけしか同時実行数しないといけない(これはSQSやKinesisのところを変える)

アンチパターン

LambdaでRDBMS使いがち問題

コネクション数の問題がある(Lambdaからの1リクエストに対してコネクションがそれぞれに貼られるから)
また、VPC内にRDBMSがあるからコールドスタート問題がある

RDBMS使うときはDynamoDBStreamとLambdaで転送

IP固定したがり問題

証明書や署名などで担保すべき(スケーラビリティがなくなる)

サーバーレスに夢見がち問題

サーバ管理は不要だが、運用は必要
複雑なことをやろうとすると設計開発コストが上がる可能性が・・
⇒ シンプルに使おう

監視しなくていいと思っている問題

適切にモニタリングしてあげる(CloudWatchでみる)
特に、ErrorsとThrottles

その他

Lambdaは最低一回実行は保証しているので、1回しか実行しないわけではない
DynamoDBを利用するときは冪等性を担保する

続きを読む

Amazon Kinesis Streamの監視方法

Kinesis Streamのシャードには以下のような制限がある。

  • 書き込み 1シャード 最大1秒あたり1,000レコードまたは1MBまで
  • 読み込み 1シャード 最大1秒あたり5回の読み込みまたは2MBまで

シャードへの流入・流出量を上記の値を超えないように・または超えたことを検知できるように
監視していかないといけない。

そのため、CloudWatchでのKinesisの監視項目をまとめる。

どのメトリクスを見るべきか

CloudWatchでどういうメトリクスが見れるかは公式ドキュメントに記載がある。
http://docs.aws.amazon.com/ja_jp/streams/latest/dev/monitoring-with-cloudwatch.html

その中でも以下の項目を見ると、シャードを増やすしきい値が見えてきそう。

WriteProvisionedThroughputExceeded

シャードの書き込み上限の超過が発生しているか否かを判定するのなら、この項目を見ればよい。
これは指定された期間中にストリームの上限超過が発生した件数が出力される。

これが定常的に1以上になった場合は、シャードを増やしたほうが良さそう。

AWS CLIでの取得方法

profile=hoge
stream_name=hoge

aws --profile ${profile} cloudwatch get-metric-statistics 
--namespace AWS/Kinesis 
--metric-name WriteProvisionedThroughputExceeded 
--start-time 2017-06-20T12:00:00 
--end-time 2017-06-20T13:00:00 
--period 60 
--statistics Maximum 
--dimensions Name=StreamName,Value=${stream_name}

ReadProvisionedThroughputExceeded

これは上記に記載した「WriteProvisionedThroughputExceeded」の読み込み版。
こちらも合わせて見たい。

PutRecords.Bytes / PutRecords.Records

これは指定期間内にストリームに送信されたバイト/レコード数を確認することが出来る項目。
周期の最小単位が1分となっているため、指標として使うならこの値を使って1秒あたりの数値に計算しなおすとわかりやすい。

この項目を見ることにより、シャードの上限の超過の発生前に事前にシャードを増やすことができる。

PutRecordというのもあるが、KPLを使用している場合はPutRecordsを使う。

AWS CLIでの取得方法

profile=hoge
stream_name=hoge

aws --profile ${profile} cloudwatch get-metric-statistics 
--namespace AWS/Kinesis 
--metric-name PutRecords.Bytes 
--start-time 2017-06-22T12:00:00 
--end-time 2017-06-22T12:05:00 
--period 60 
--statistics Sum 
--dimensions Name=StreamName,Value=${stream_name} | jq .
response
{
  "Datapoints": [
    {
      "Unit": "Bytes",
      "Timestamp": "2017-06-22T12:02:00Z",
      "Sum": 4777677
    },
    {
      "Unit": "Bytes",
      "Timestamp": "2017-06-22T12:01:00Z",
      "Sum": 4241130
    },
    {
      "Unit": "Bytes",
      "Timestamp": "2017-06-22T12:00:00Z",
      "Sum": 5064734
    },
    {
      "Unit": "Bytes",
      "Timestamp": "2017-06-22T12:04:00Z",
      "Sum": 4647186
    },
    {
      "Unit": "Bytes",
      "Timestamp": "2017-06-22T12:03:00Z",
      "Sum": 4581718
    }
  ],
  "Label": "PutRecords.Bytes"
}
# 1分周期で取っているので、60(秒)で割って、1秒あたりのByteを計算
profile=hoge
stream_name=hoge

aws --profile ${profile} cloudwatch get-metric-statistics 
--namespace AWS/Kinesis 
--metric-name PutRecords.Bytes 
--start-time 2017-06-22T12:00:00 
--end-time 2017-06-22T12:05:00 
--period 60 
--statistics Sum 
--dimensions Name=StreamName,Value=${stream_name} | jq -r '.Datapoints[].Sum' | xargs -i expr {} / 60
response
79627
70685
84412
77453
76361

GetRecords.Bytes / GetRecords.Records

上記の「PutRecords.Bytes / PutRecords.Records」の読み込み版。
こちらも合わせて見たい。

続きを読む

LambdaでAWSの料金を毎日Slackに通知する(Python3)

はじめに

個人アカウントは基本的に無料枠で運用しているので、少しでも請求がある場合はいち早く気づきたいです。
先日、とあるハンズオンイベントで使ったリソースを消し忘れて、最終的に$30ぐらい請求が来てしまいました。。。

CloudWatchで請求アラートは設定していますが、閾値超えが想定の場合、当然見逃すことになり、最終的な請求額に驚くハメになります。

これを防ぐためにLambdaで毎日SlackにAWS料金を通知することにします。

先日LambdaがPython3に対応したので、せっかくだし勉強がてらPython3で実装したい。
ネット上にはNode.jsでの実装例が多いようで、今回はこちらを参考にPython3で実装してみます。

必要なもの

  • Slack

    • incoming-webhooks URL

    • 適当なchannel
  • lambda-uploader
    • requestsモジュールをLambda上でimportするために利用

      • カレントディレクトリにモジュールをインストールして、モジュールごとZipに固めてアップロードでもいけるはずですが、私の環境だとうまくいかなかったので
  • aws cli
    • lambda-uploaderで必要
  • AWS
    • Lambda関数用IAM Role

      • CloudWatchReadOnlyAccessポリシーをアタッチ

事前準備

lambda-uploaderをインストール

$ pip install lambda-uploader 

こちらを参考にさせていただきました。

aws cliをインストール

$ pip install awscli

credential、リージョン設定

$ aws configure

確認
$ aws configure list

コード

ディレクトリ構成

ディレクトリ名は任意です。関数名とは無関係です。

ディレクトリ構成
awscost_to_slack/
|--lambda_function.py
|--requirements.txt
|--lambda.json

lambda_function.py

超過金額に応じて色をつけるようにしています。
\$0.0なら緑、超過したら黄色、\$10超えで赤になります。

lambda_function.py
#!/usr/bin/env python
# encoding: utf-8

import json
import datetime
import requests
import boto3
import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

# Slack の設定
SLACK_POST_URL = os.environ['slackPostURL']
SLACK_CHANNEL = os.environ['slackChannel']

response = boto3.client('cloudwatch', region_name='us-east-1')

get_metric_statistics = response.get_metric_statistics(
    Namespace='AWS/Billing',
    MetricName='EstimatedCharges',
    Dimensions=[
        {
            'Name': 'Currency',
            'Value': 'USD'
        }
    ],
    StartTime=datetime.datetime.today() - datetime.timedelta(days=1),
    EndTime=datetime.datetime.today(),
    Period=86400,
    Statistics=['Maximum'])

cost = get_metric_statistics['Datapoints'][0]['Maximum']
date = get_metric_statistics['Datapoints'][0]['Timestamp'].strftime('%Y年%m月%d日')

def build_message(cost):
    if float(cost) >= 10.0:
        color = "#ff0000" #red
    elif float(cost) > 0.0:
        color = "warning" #yellow
    else:
        color = "good"    #green

    text = "%sまでのAWSの料金は、$%sです。" % (date, cost)

    atachements = {"text":text,"color":color}
    return atachements

def lambda_handler(event, context):
    content = build_message(cost)

    # SlackにPOSTする内容をセット
    slack_message = {
        'channel': SLACK_CHANNEL,
        "attachments": [content],
    }

    # SlackにPOST
    try:
        req = requests.post(SLACK_POST_URL, data=json.dumps(slack_message))
        logger.info("Message posted to %s", slack_message['channel'])
    except requests.exceptions.RequestException as e:
        logger.error("Request failed: %s", e)

requirements.txt

pip installしたいモジュール名を書きます。

requirements.txt
requests

lambda.json

Lambda関数名、IAM RoleのARNなどは環境に合わせてください。
スクリプト本体のファイル名とハンドラの前半を一致させないと動きません。地味にハマるので注意!

lambda.json
{
  "name": "LAMBDA_FUNCTION_NAME",
  "description": "DESCRIPTION",
  "region": "ap-northeast-1",
  "handler": "lambda_function.lambda_handler",
  "role": "arn:aws:iam::XXXXXXX:role/ROLE_NAME_FOR_LUMBDA",
  "timeout": 300,
  "memory": 128,
  "variables":
    {
      "slackPostURL":"https://hooks.slack.com/services/XXX",
      "slackChannel":"#XXX"
    }
}

デプロイ

上記ファイルを配置したディレクトリに移動して、lambda-uploaderを実行します。

$ cd awscost_to_slack
$ lambda-uploader
λ Building Package
λ Uploading Package
λ Fin

Lambda環境変数設定

今回のLambda関数では、通知先SlackチャネルとWebhooks URLを環境変数で渡すようにしたので、設定します。

スクリーンショット 2017-06-23 14.51.30.png

lambda-uploaderのlambda.jsonに書けそうなのですが、書式が分からず、今回はマネコンで設定しました。
lambda-uploaderでLambda関数を更新すると消えてしまうので注意。

上記のようにlambda.jsonのvariablesで定義すれば環境変数も設定可能です。uploadのたびに消えることもありません。

Lambda定期実行設定

CloudWatchのスケジュールイベントを定義して、lambda関数をターゲットに指定します。
時刻はUTCなので注意しましょう。
毎日UTC0:00に実行されるよう設定しました。

スクリーンショット 2017-06-23 15.01.27.png

実行イメージ

スクリーンショット 2017-06-23 14.15.54.png
こんな感じで毎朝9:00に通知がきます。
今日も無料!

まとめ

Lambdaはほぼ無料でプログラムが動かせるので楽しいですね!
Python初心者なのでコードが見苦しい点はご容赦ください。

続きを読む

AWS独学メモ

頑張って学んでいきます。

サービス俯瞰

コンピューティング関連

サービス名 概要
EC2 仮想サーバー
EC2 Container Service Doker(アプリ実行環境構築ツール)運用サービス
EC2 Container Regstry Dokerイメージ保存・共有サービス。
Elastic Beanstalk .NET/PHP/Python/Ruby/Node.jsアプリを自動でAWSにデプロイ。
Lambda クライアントからのリクエスト発生時に任意プログラミング起動。イベント駆動型サービス。
Auto Scaling CPU使用率等、事前決定条件に応じ、EC2インスタンス増減
Elastic Load Balancing トラフィックに応じ、複数EC2インスタンスに負荷分散

ストレージ・コンテンツ配信

サービス名 概要
S3 ファイルサーバ。画像格納したり。
CloudFront コンテンツ配信ネットワーク。利用者から近い場所から効率よく配信
EBS EC2データを保持するストレージ。EC2のHDD,SSDのような役割。
Elastic File System EC2共有ファイルストレージ
Glacier 低価格ストレージ。仕様頻度低いけど長期保存のバックアップ用。
Import / Export Snowball ペタバイト級の大容量転送サービス。
Storage Gateway オンプレミスとAWSを接続

DB関連

サービス名 概要
RDS DB(MySQL/Oracle/SQL Server/PostgreSQL/Aurora)が利用できる
Database Migration Service 最小限停止時間でDBを移行。オンプレミスのDBサーバからの移行等に用いる
DynamoDB NoSQLデータベスサービス構築/運用。
ElastiCache クラウドでのメモり内キャッシュの管理サービス
Redshift ビッグデータを分析

ネットワーク

サービス名 概要
VPC プライベートネットワーク構築サービス。
Direct Connect オンプレミスのネットワークとAWSのVPCネットワークを直接接続。
Route 53 DNS(ドメイン名とIPアドレスを対応)

開発者用ツール

サービス名 概要
CodeCommit プライベートGit
CodeDeploy 開発アプリを実行環境に自動配置
CodePipeline 継続的デリバリ使用したアプリのリリース

開発ツール

サービス名 概要
CloudWatch AWSリソース監視サービス
CloudFormation テンプレート利用したリソースの作成と管理
CloudTrail ユーザアクティビティとAPI使用状況確認
Config リソースのイベントリ変更の追跡
OpsWorks Chef利用し操作の自動化
Service Catalog 標準化製品の作成と使用
Trusted Advisor パフォーマンスとせきゅりてぃの最適化

セキュリティ

サービス名 概要
IAM AWS認証
Directory Service Active Directoryのホスティングと管理
Inspector アプリのセキュリティ分析
CloudHSM 暗号鍵管理の専用ハードウェア
Key Management Service 暗号鍵作成と管理
WAF 攻撃から保護するファイアウォール

分析

サービス名 概要
EMR Hadoopフレームワーク
Data Pipeline オーケストレーションサービス
Kinesis リアルタイムストリーミングデータとの連携
Machine Learning 機械学習
QuickSight 高速ビジネスインテリジェンスサービス

モバイルサービス

サービス名 概要
Mobile Hub モバイルアプリの構築/テスト/監視
API Gateway RESTful APIの構築/管理
Cofnito ユーザID及びアプリデータの同期
Device Farm iOS/Android/FireOSアプリのテスト
Mobile Analytics アプリ分析の収集/表示/エクスポート
Mobile SDK モバイルソフトウェアの開発キット

アプリケーションサービス

サービス名 概要
AppStream ストリーミングサービス
CloudSearch マネージド型検索サービス
Elastic Transcorder メディアと動画変換
SES Eメール送受信
SNS プッシュ通知サービス
SQS メッセージキューサービス
SWF アプリ同士を連携ワークフローサービス

大企業向け

サービス名 概要
WorkSpaces クラウド上仮想デスクトップパソコンサービス
WorkMail セキュリティ保護、企業向けEメール及びカレンダー
WorkDocs ファイル共有サービス

S3について

用語

用語 意味
バケット データの入れ物
オブジェクト 格納ファイル

ステップ

  1. バケット作成
  2. オブジェクト格納

EC2について

用語

用語 意味
EC2 仮想サーバ。オンプレミスのWindowsサーバやUNIXサーバに相当。
インスタンス 1台の仮想サーバ
EBS(Elastic Block Store) サーバのHDDに相当する仮想ディスク
AMI(Amazon Machine Image) サーバにインストールするOSやミドルウェアやアプリのイメージ。新インスタンスを複数生成時、AMIを利用。
yum パッケージ管理システム
scp(secure copy) SSH機能を用いて、安全にファイル転送する

EC2にSSH接続した

参考ページ1
参考ページ2

ミドルウェアをインストール

yum更新
$ sudo yum -y update
httpdインストール
$ sudo yum  install -y httpd
httpd起動
$ sudo service httpd start
httpd自動起動を確認
$ sudo chkconfig --list httpd
httpd自動起動を設定
$ sudo chkconfig  httpd on
$ sudo chkconfig  httpd off

scp(コンテンツをアップロードする)

【現在ここで躓き中!】
→ 突破!!

参考ページ1

HTTPコンテンツをコピー

HTTPコンテンツのコピー

$ sudo cp /home/ec2-user/index.html /var/www/html/

【現在ここで躓き中!】index.htmlへアクセスできない

続きを読む