Lambdaを使ってS3にアップロードされたファイルを自動的にEC2(Windows)内にダウンロード(同期)してみる | DevelopersIO
どうも！大阪オフィスの西村祐二です。 S3にアップロードされたファイルをEC2内に自動的にダウンロードしたいと思うことはよくあると思います。 自動化する方法はいろいろあると思いますが、 今回はLambdaとSSM、AWS CLIを使って自動化してみたいと思います。 さっそくやってみましょう。 構成図 今回、想定する構成が下記の図になります。 S3にファイルがアップロードされたら、LambdaからSSMを実行し、 EC2(Windows)にてAWSCLIのS3 Syncコマンドを実行します。 この構成の利点 私が思うこの構成の利点としては、 ・EC2側はAWS CLI設定とSSM Agentのインストールだけで済み、今後の運用不可が軽減されそう ・Lambdaの実装がSSMを実行する部分のみになる はじめはEC2にFTPサーバをたてて、LambdaでS3からファイルを取得し、EC2にコピーし
OSごとのオフィシャルなAMIをまとめてみた
EC2では、Quick StartやAWS Marketplace、Community AMIsなど、様々なAMIからインスタンスを作成できます。 選択肢がたくさんあるのは素晴らしいですが、気をつけないと素性の知れないAMIを意図せず使ってしまうことになりかねません。 使いたいOSの、できるだけオフィシャルなAMIが欲しいというのが人情というもの。 （ここでいうオフィシャルというのは、Amazon公式に限りません。） そこで、OSごとのEC2オフィシャルAMIを一覧にまとめてみました。 Amazon Linux マネジメントコンソールからAmazon提供のPublic AMIの一覧が見れます。 こちらのリンクからどうぞ。 https://console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Images:filter=amazon
EC2を停止して開始した時はELBに再登録する | DevelopersIO
こんにちは、虎塚です。 今日は、ELBに紐づけたEC2を停止・開始した時に、EC2をELBに再登録する必要があることについて書きます。 これはELBを使い始めるとすぐに遭遇する問題のため、お客様からのお問い合わせが多い話題です。今月（2014年9月）すでに2件の問い合わせがあったので、書いておくことにしました。 現象 ELBと紐づけたEC2が、ELBから正しく認識されていて、リクエストを分配できる状態の時、ELBのステータスは「In Service」となります。ELBにEC2を紐づけてすぐの状態だと「Out of Service」ですが、数分たつと「In Service」になりますね。 ところが、ELBと紐づけたEC2を停止して、一定時間後に開始した後、「Out of Service」のままになることがあります。 公式ドキュメントによる解説 公式ドキュメントでは、この件について次のように書
オンラインでEC2のルートディスクを拡張する - Qiita
@ryo0301さんにEBSがオンラインで拡張できるよって教えてもらったので、試してみました。 AWSコンソールからディスクサイズを拡張 EBSのVolumesからModify Volumeを選んで拡張できます。 なんとVolume Typeも変えられるみたいです。 今回はそこは不要なので、Sizeだけ8Gから500Gに変更しました。 （増やしたら減らせません。） optimizingになればもうresize2fs可能なようです。数秒でoptimizingになりました。 completedまでは5〜10分程度でした。 resize2fs ディスクの状態を確認します。 $ df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 2014036 56 2013980 1% /dev tmpfs 2024908 0 2024
Amazon EBS 最適化インスタンスを使用する - Amazon Elastic Compute Cloud
Amazon EBS 最適化インスタンスは、最適化された設定スタックを使用し、Amazon EBS I/O 用に専用のキャパシティを追加で提供します。このように最適化することで、Amazon EBS I/O と、インスタンスからのその他のトラフィックとの間の競合を最小に抑え、EBS ボリュームの最高のパフォーマンスを実現します。 EBS 最適化インスタンスは、Amazon EBS 用に専用の帯域幅を用意します。汎用 SSD (gp2 および gp3) ボリュームを EBS 最適化インスタンスにアタッチすると、1 年で 99% の期間、プロビジョンド IOPS パフォーマンスの少なくとも 90% のボリュームが提供されます。また、プロビジョンド IOPS SSD (io1 および io2) ボリュームでは、1 年で 99.9% の期間、プロビジョンド IOPS パフォーマンスの少なくとも 9
インスタンスのステータスチェック - Amazon Elastic Compute Cloud
インスタンスのステータスのモニタリングでは、インスタンスによるアプリケーションの実行を妨げる可能性のある問題をAmazon EC2 が検出したかどうかをすばやく判断できます。Amazon EC2 は、稼働中のすべての EC2 インスタンスに対して自動チェックを実行して、ハードウェアおよびソフトウェアの問題を特定します。これらのステータスチェックの結果を表示して、具体的で検出可能な問題を識別できます。このイベントステータスデータは、各インスタンス (pending、running、stopping) の状態に関して Amazon EC2 が既に提供している情報と、Amazon CloudWatch が監視している使用状況メトリクス (CPU 使用率、ネットワークトラフィック、ディスクアクティビティ) を補足するものです。 ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のス
EC2インスタンス起動数の上限緩和について - サーバーワークスエンジニアブログ
みなさんこんにちは。 もうすぐ2年目になってしまう事に気づいた、テクニカルチームの山田です。 今回は、EC2インスタンスの上限緩和のお話です。 インスタンスタイプ毎の起動上限数 AWSアカウントを作成した直後はEC2インスタンスには起動できる上限が決まっており、上限の数を超える大量のEC2インスタンスを起動する際はAWSサポートに申請をする必要があるのはみなさんご存知の通りだと思います。 そしてこの上限数、実はインスタンスタイプ毎に決まっているのです。 その他すべてのインスタンスタイプ( t1.micro、m1.small、m1.medium、m1.large、c1.medium 等 )は、全てひっくるめてデフォルトの上限が20台になっています。 例えば m1.large で40台申請したとすると、上記画像で個別に載っていないインスタンス( t1.micro、m1.small、m1.med
EC2からNFS経由でS3オブジェクトを保管できるようになりました！[Storage Gateway] | DevelopersIO
神アップデートな予感がしてます、コンニチハ、千葉です。 2016年11月30日に、ご紹介しました[新機能]オンプレミスからNFS経由でS3オブジェクトを保管できるようになりました！[Storage Gateway]が、なんとEC2上で利用できるようになりました。 これで、EC2からもNFS経由でS３のオブジェクトを直接利用できるようになります。APIを利用してS3へアップロードする必要がなく、NFSにて利用できるのレガシーなシステムでは重宝するのではないでしょうか。 また、NFS(オンプレ/EC2) > Storage Gateway > S3 > Redshiftのような利用も考えられます。 注意点としては、Gatewayインスタンスは現状は冗長化できないという点です。ただ、種々バックアップストレージやデータ連携としてバックエンドにS3を利用できるのできるのと、直接S3にオブジェクトとし
![EC2からNFS経由でS3オブジェクトを保管できるようになりました！[Storage Gateway] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/5cef8c014e947c6d69a900c17c28496da9c46366/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAWS_Storage_Gateway.png)
Amazon EC2 セキュリティレシピ | DevelopersIO
最新のミドルウェアを使う 古いミドルウェアには脆弱性が含まれることがあります。 脆弱性によってその影響は様々です。 外部から比較的容易にサービス断を行えるものや、不正なコマンドを実行され情報を抜き取られるなどよりクリティカルなものもあります。 最新のミドルウェアを利用し定期的にアップデートするようにします。 ミドルウェアの脆弱性が見つかると、脆弱性情報データベースや各ベンダで公開されます。 Common Vulnerabilities and ExposuresやJapan Vulnerability Notesが有名です。 Amazon Linuxの場合、Amazon Linux AMI Security Centerで公開されます。 各サイトを巡回するには骨が折れるため、RSSやtwitterで情報収集されるかたも多いかと思います。 影響が大きい脆弱性については、全社周知が行われる組織
cloudpackブログ - SSL Termination(ELB)でアプリ(EC2)がHTTPSのチェックを行えない場合
今回は、先日書籍（Amazon Web Servicesクラウドデザインパターン設計ガイド）が発売されたCloud Design Pattern（CDP）の記事になります。 対象は「Multi Load Balancerパターン」です。 ELBのSSL Termination機能で、SSLの処理をEC2(Webサーバ)ではなくELBに行わせることが可能ですが、それに伴い、このパターンの「注意点」に下記の記載があります。 ELBのSSL Termination機能を用いるとEC2側はHTTPでリクエストを受けることになるのでアプリケーションでのHTTPS接続の判定が難しくなる。 直接EC2のWebサーバでSSLの設定をして、HTTPSでのアクセスを行う場合はPHPの場合、下記の環境変数でHTTPSの接続かどうかチェックしている場合が多いとお思います。 ($_SERVER[“HTTPS”]の有
EC2 Container Service(ECS)を管理して、Blue-Green Deploymentを実現するツールを書いた - tehepero note(・ω<)
2015-07-22 EC2 Container Service(ECS)を管理して、Blue-Green Deploymentを実現するツールを書いた AWS Docker ECS 最近は暑いのでめっきり外に出なくなりましたが、相変わらずDevOpsのOpsばっかりやっています。 さて、今やってるプロジェクトではAmazon EC2 Container Service(ECS)で完全にDockerベースでの開発をしています。本番運用を見越したオペレーションの作り込みをやってるわけですが、今回はBlue-Green Deploymentを実現してみたよってお話。 材料 必要な材料は以下の通り。 VPC Route53 EC2 ELB AutoScaling Group ECS 方式 最近ELBがAutoScaling Group単位での切り替えができるようになったので、これを利用します。基
ELB配下のEC2アクセスログについてあれこれ | DevelopersIO
ELB配下のEC2インスタンスは接続元がELBのアドレスになる ELB配下のEC2インスタンスが、接続元のIPアドレスなど情報を得ようとする場合、初期設定ではおそらくELBのIPアドレスが返されてしまいます。これは、ELBを経由しているので当たり前といえば当たり前ですが、これではどこからアクセスされているのか把握できません。そこで、ELBの機能を利用して接続元のIPアドレス等を取得したいと思います。 X-Forwarded-ForとX-Forwarded-Proto ELBには市販されているロードバランサー製品と同じように、接続元のIPアドレスをヘッダー情報に付けてくれます。そこで、EC2インスタンス側でその情報を取得してログとして書き出してみます。また、ELBはSSLターミネーション機能がありますので、接続元がどのプロトコル（HTTPかHTTPSか）でEC2インスタンスにアクセスしたのか
AWS Amazon Linux スワップファイル作成によりSwap領域のサイズを増やす - Qiita
はじめに AWSのEC2インスタンス(Amazon Linux)に対して、スワップファイルを作成して、Swap領域のサイズを512MBに増やす手順です。 # dd if=/dev/zero of=/swapfile1 bs=1M count=512 # chmod 600 /swapfile1 # mkswap /swapfile1 # swapon /swapfile1 対象環境 対象環境はAWSのEC2インスタンス(Amazon Linux)になります。 ・Amazon Linux (3.14.33-26.47.amzn1.x86_64) 概要 ・ミドルウェア等の動作検証の為、AWSのEC2インスタンス(Amazon Linux)を作成して動作を試す事があります。 検証用のEC2インスタンスは安価なt2.microで作成する事が多いのですが、インスタンスタイプがt2.microの場合、
AmazonLinuxでglibcをupdateした時のローカルタイムの挙動について - Qiita
ローカルタイムをJSTなどに設定しているAmazon Linuxで、glibcをupdateするとローカルタイムが元の設定に戻るという現象がおきることがあります。 これは、glibcの更新時に/etc/localtimeが書き換わってしまうからです。 よくあるトラブルとして、AutoScaleなどでインスタンスが起動したタイミングでcloud-initのsecurity updateが自動で走り、glibcが依存モジュールとして一緒に更新され、localtimeが意図せず書き換わったりします。 実験 というわけで、やってみました。 今回AMIは、amzn-ami-hvm-2014.09.1.x86_64-ebs (ami-4985b048)を使います。 glibcのパッケージは、glibc.x86_64 0:2.17-55.87.amzn1からglibc.x86_64 0:2.17-55.
Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO
ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から本番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ
Amazon EC2 インスタンスストア - Amazon Elastic Compute Cloud
インスタンスストアは、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、バッファ、キャッシュ、スクラッチデータ、その他の一時的データのように頻繁に変化する情報の一時的なストレージに最適です。また、負荷分散されたウェブサーバーのプールなど、インスタンスのフリート全体で複製する一時データを保存するためにも使用できます。 インスタンスストアは、ブロックデバイスとして表示される 1 つ以上のインスタンスストアボリュームで構成されます。インスタンスストアのサイズと、利用可能なデバイスの数は、インスタンスタイプおよびインスタンスサイズによって異なります。詳細については、「インスタンスストアボリューム」を参照してください。 インスタンスストアボリュームの仮想デバイスは ephemeral[0
Amazon AWSの約款には結構エグイことが書いてある - モスマン
EC2を使い始めてはや半年以上が経過した。セキュリティの調査目的、つまりは自分のパソコンではやりたくない作業に使おうと思って契約したのだが、あらためて約款を読んでみると、IDSを動かすのも微妙なのではないかという位にその用途を縛っていることがわかった。 「え？約款て何？？」という方も多いと思うが、EC2やS3をはじめとするAmazon AWSを使っている人は例外なく加入時に約款（ユーザーアグリーメント）を承諾しているんです。 これがその実物。http://aws.amazon.com/agreement/ こんな長い約款を読んでいる人なんていないと思うので注意すべき点を書いておく。僕もあまり真面目に読んでないので、このエントリーをみて引っかかった人は是非原文をあたって下さい。 AWSでのご法度/禁則事項 お金を払わないと強制退会になるのは当然として、AWSを使ったDoS攻撃なども全て禁止、
Amazon VPCを使ったミニマム構成のサーバ環境を構築する | DevelopersIO
よく訓練されたアップル信者、都元です。AWSにおいては、ネットワーク環境をあまり気にせず、数クリックで簡単にサーバを構築できるのは一つのメリットだと言えます。しかし、本格的に運用するシステムに関しては、ネットワーク環境をコントロールする需要も出てきます。AWS Virtual Private Cloud (VPC)を使えば、AWS上に仮想ネットワークを定義し、その上に各種サーバを配置することができます。 深く考えずに非VPC環境に構築してしまったAWSサーバ環境は、簡単にはVPC環境に移行することはできません。従って弊社では、小さなシステムであっても、最初からVPC環境にシステムを構築することを推奨しています。「非VPCが許されるのは小学生までだよねー」とボスが申しておりました。かといって、ネットワークの構成をゼロから考えて構築するのもひと苦労であるため、本エントリーでは、システムの初期段
Amazon EC2(Linux)のswap領域ベストプラクティス | DevelopersIO
ども、大瀧です。 Linuxのメモリ管理で欠かせないのがswapですよね。EC2のディスク管理には独特な仕様があるのでその辺りを踏まえつつ、EC2(Linux)でどのようにswap領域を用意するのが良いのかまとめてみたいと思います。 理屈をこねながらの解説になるので、先に本エントリーの結論を。 公式AMIにはswap領域が含まれない m1.small、c1.mediumには900MBのスワップ領域がおまけでついてくる(Amazon Linux AMIであれば、Cloud-initによって自動マウントされる) swap領域には、インスタンスストア(別名Ephemeral Disk)を使うべし では、それぞれ見ていきます。 公式Linux AMIの初期構成にはswapパーティションが無い Amazonから提供される公式のLinux AMIのブートディスクには、swapパーティションが含まれてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
