VPC内からLambdaを実行する際のハマりどころ

VPC内のLambdaからEC2 Run Commandを実行しようとしたら、下記のエラーが出ました

Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.

また、ログを確認すると、時間めいいっぱい使っている様子

Task timed out after 300.00 seconds.

試しにマネジメントコンソールから実行すると、即「Success」が返ってきたので 権限周りやコードに問題はなさそう…

しばらくして気が付きました

Lambdaがプライベートサブネット内にいる!

つまり、LambdaがEC2 Run Commandを実行する際に インターネットに接続できる環境でないとダメ!!

ということで、この場合はパブリックサブネットに NATサーバ or NAT Gatewayを立てれば問題なしでした^^

というか、サブネットの選択を間違えたかな。。 この場合はパブリックサブネットにLambdaを置くのがベストプラクティスになるのでしょうかー

【JAWS-UG CLI】 #64 ALB入門 に参加しました!

9/26(月)に開催されたJAWS-UGのCLI支部に久々に参加してきました!
 
ALB気になっていたのですが、案件でもまだ使用する予定もなかったのでとてもいい機会でしたー
また、AWSの中の方にも来ていただき、有益な情報も聞けました!
 
ハンズオンの資料はこちらです!
 
ALBの概要を簡単に。
・パスベースのルーティングが可能
・アクセスされるURLパスごとに優先度を分けることができる(優先度のルールは10個まで設定可能)
 ルールの値が小さい順に評価され、最初に合致した値が適用されます
・http/httpsのみ対応
・ターゲットにS3を設定することはできない
AWS内でテストした結果では、CLBよりALBの方が安くなる(ALB推奨らしい)
・過剰なアクセスがある場合は、CLB同様プレウォーミングの申請は必要
・EC2同様、削除防止機能がある
・価格設定がやや複雑(詳細は以下に記載)
・CLBからALBに移行する際の移行ツールがある(https://github.com/aws/elastic-load-balancing-tools
・ALBを削除するとリスナーなども一緒に削除される
 ※ターゲットグループは別途削除が必要
 

 
価格については、以下の2つの料金の合算する形となっています。
・1時間あたりの料金(CLBに較べて10%引き)
・LCU時間あたりの料金
 LCU…「Load Balancer Capacity Units」の略でALBの使用量の単位
 
「LCU時間あたりの料金」とは?
LCUは、下記3つの指標を計測して、最も高いものを基準に課金されるようです。
・1秒あたりの新規コネクション数
・1分アクティブなコネクション数
・データ転送量
 
1LCUには、下記のいずれかの内容が含まれてます。
・2 KBの証明書の場合: 25 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送
・4 KBの証明書の場合: 5 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送
 
Q. AWS ACMの証明書を使った場合はどうなる?
AWS ACMを使用した場合は、2KBの証明書を使用したのと同等になるそうです。(AWSの中の人からの回答)
 
 
次回のCLI支部は祝日スペシャルです!
 
 
 

Lambdaで最新AMIを取得する!(Python)

Lambda(python)で最新AMI IDを取得するプログラムを書きました。

Windowsは「Windows Servier 2012 R2 Base」、Linuxは「Amazon Linux」の最新AMI IDを取得してます。 Filters部分をカスタマイズしてもらえれば、その他にも使えると思います!    

Windows

import boto3

def lambda_handler(event, context):
    client = boto3.client('ec2')
    response = client.describe_images(
        Owners=['amazon'],
        Filters=[
            {
                'Name': 'root-device-type',
                'Values': ['ebs']
            },
            {
                'Name': 'architecture',
                'Values': ['x86_64']
            },
            {
                'Name': 'name',
                'Values': ['Windows_Server-2012-R2_RTM-Japanese-64Bit-Base*']
            }
        ]
    )
    
    list = []
    
    for x in response["Images"]:
        name = x["Name"]
        ami_id = x["ImageId"]
        list.append([name, ami_id])
    
    list.sort(key=lambda x:x[0], reverse=True)
    print list[0][1]

Linux

import boto3

def lambda_handler(event, context):
    client = boto3.client('ec2')
    response = client.describe_images(
        Owners=['amazon'],
        Filters=[
            {
               'Name': 'root-device-type',
                'Values': ['ebs']
            },
            {
                'Name': 'architecture',
                'Values': ['x86_64']
            },
            {
                'Name': 'block-device-mapping.volume-type',
                'Values': ['standard']
            },
            {
                 'Name': 'name',
                 'Values': ['amzn-ami-hvm*']
            }
        ]
    )
    
    list = []
    
    for x in response["Images"]:
        name = x["Name"]
        ami_id = x["ImageId"]
        list.append([name, ami_id])
    
    list.sort(key=lambda x:x[0], reverse=True)
    print list[0][1]

【備忘録】CloudWatchLogsのロググループ作成とログ保持期間を変更するワンライナー

以前、【備忘録】CloudWatchLogsのログ保持期間を変更するワンライナーを投稿しましたが、 今回は、少しバージョンアップして、CloudWatchLogsのロググループ作成とログ保持期間を変更するワンライナーです!

for LOGGROUPNAME in $(cat <CloudWatchLogsのロググループ名を入れたファイル>) ;do aws logs create-log-group --region ap-northeast-1 --log-group-name ${LOGGROUPNAME} && aws logs put-retention-policy --region ap-northeast-1 --log-group-name ${LOGGROUPNAME} --retention-in-days <ログ保持期間>;done

※事前に<CloudWatchLogsのロググループ名を入れたファイル>を作成しておいてください!

【備忘録】CloudWatchLogsのログ保持期間を変更するワンライナー

CloudWatchLogsのログ保持期間を変更するワンライナーです。

aws logs describe-log-groups --region ap-northeast-1 --query 'logGroups[].logGroupName' --output text| tr '¥t' '¥n' | while read LOGGROUP; do aws logs put-retention-policy --region ap-northeast-1 --log-group-name ${LOGGROUP} --retention-in-days 7; done

ロググループが50個ほどあったので楽チンに変更できました(°∀° )/

Data Migration Serviceを触ってみた!

概要

           (レプリケーション用のインスタンスの料金はオンデマンドインスタンスよりもちょっと割高)
  • レプリケーション用のインスタンスは停止することができない(起動or削除のみ)
  • データベースの同じプラットフォーム間だけでなく、異なるプラットフォームに変えることも可能
           例)OracleOracle , Oracle → Aurora
  • 移行元、移行先のどちらかがAWS上にある必要があるが、他はオンプレミスでも、DB on EC2でも、RDSでもOK
  • 移行の種類は以下の3つから選択可能
       ①"migrate existing data" (既存データの一括ロード)
       ②"migrate and then replicate" (一括コピーした後に、継続的に差分レプリケーション)
       ③"replicate going forward" (差分レプリケーションのみ実行)
 
 
検証した環境

f:id:aym413:20160626190345p:plain

  • OracleOracleへ移行
  • ダミーデータは1000件(氏名、メールアドレス、生年月日等)
  • 移行の種類は上記①"migrate existing data"を選択
 
AWS DMS構築の流れ

AWS DMS用Subnet Groupの作成

f:id:aym413:20160626190346j:plain

f:id:aym413:20160626190347j:plain

 
  ↓RDS同様にAZをまたがる2つのSubnetが必要になります。

f:id:aym413:20160626190348j:plain

f:id:aym413:20160626183641j:image

 
AWS DMS用インスタンスの作成

f:id:aym413:20160626190350j:plain

f:id:aym413:20160626191923j:plain 

f:id:aym413:20160626190352j:plain

f:id:aym413:20160626190353j:plain

③移行元・移行先エンドポイント(接続情報)の作成
まずはSource Endpointから作成します。

f:id:aym413:20160626190354j:plain

 ↓接続テストを行って成功すればOKです。

f:id:aym413:20160626183656j:image

 
次はTarget Endpointを作成します。
↓こちらも接続テストを行って成功すればOKです。

f:id:aym413:20160626183653j:image

f:id:aym413:20160626190357j:plain

 
④タスクの作成
  ↓エンドポイントの選択や移行の種類、どのテーブルを移行するか等を設定

f:id:aym413:20160626183644j:image

 
⑤タスクの実行
 ↓しばらくするとStatusが「Load complete」になります

f:id:aym413:20160626192131j:plain

 
 ↓ CloudWatch Logsを見ると、1000件のデータロードが終わったことを確認できます。

f:id:aym413:20160626190400j:plain

 
検証結果

  • ダミーデータ1000件は問題なく移行できた
  • 文字コードも変わらずそのまま移行できた
  • 移行時間は1~2分程度
 
 
つまづいたところ

① 環境準備のところで…
  →環境変数文字コードを変更
AWS DMSのところで…
  • 指定したスキーマのテーブルが移行されない
  →AWS DMSで作成したエンドポイントで指定したスキーマが、タスクで使用されるデフォルトのスキーマになる
  →最初エンドポイントのスキーマで「system」等の管理者アカウントを指定したため、「ORACLE_OCM」がデフォルトスキーマとして登録された
  →エンドポイントのスキーマ設定で、移行用スキーマを指定すれば、問題なくテーブルが移行できた
 

【備忘録】Route53でドメイン買うとき

Route53で初めてドメインを購入したのですが、その際にあたふたしたのでメモ。
 
1. Route53でドメイン買う
2. ホストゾーンを作る
3. 登録したホストゾーンのNSレコード4つをメモ
4. 購入したドメインのAdd/Edit Name Serverに3でメモしたNSレコードを入力して、Updateをクリック
5. 「Domain details update for xxxxx succeeded」のメールが届く
 
画面が載せられないのが残念。。