PostgreSQL pg_cron エクステンションによるメンテナンスのスケジューリング - Amazon Relational Database Service
PostgreSQL pg_cron エクステンションを使用すると、PostgreSQL データベース内でメンテナンスコマンドのスケジュールを組むことができます。拡張機能の詳細については、pg_cron ドキュメントの 「What is pg_cron?」 を参照してください。 pg_cron エクステンションは PostgreSQL の RDS エンジンのバージョン 12.5 以降でサポートされています。 pg_cron の使用の詳細については、「RDS for PostgreSQL または Aurora PostgreSQL 互換エディションのデータベースで pg_cron を使用してジョブをスケジュールする」を参照してください pg_cron 拡張機能バージョンは、pg_available_extensions ビューに 1.6 などの 2 桁のバージョンとして表示されます。1.6.
Extending OpsWorks Stacks Configuration Files Using Custom Templates - AWS OpsWorks
Extending OpsWorks Stacks Configuration Files Using Custom Templates The AWS OpsWorks Stacks service reached end of life on May 26, 2024 and has been disabled for both new and existing customers. We strongly recommend customers migrate their workloads to other solutions as soon as possible. If you have questions about migration, reach out to the AWS Support Team on AWS re:Post or through AWS Premi
今回は2013年2月にβ版が公開されたAWSの新たなアプリケーション管理サービスであるAWS OpsWorksについて、その概要を紹介します。 AWS OpsWorksとは AWS OpsWorks(以下OpsWorks)とは、環境構築とアプリケーションのデプロイの自動化・統合管理を実現するサービスです。OpsWorksを用いることで、柔軟に構成変更が可能な環境一式をAWS内に自動構築することができ、アプリケーションのデプロイもコンソールから指示するだけで自動的に行うことが出来ます。 AWSは以前からアプリケーション管理サービスに分類しているサービスをいくつか提供しています。AWS Elastic Beanstalkでは、アプリケーションを動かす環境一式を選択肢から選ぶだけで環境が自動構築され、アプリケーションコードだけを用意すればすぐにWebサービスを稼動させることができます。AWS C
自分用にメモ。 複数台あるMySQLスレーブサーバへの参照クエリの負荷分散は LVS(keepalived+ipvsadm)、HAproxy、またはアプライアンス製品 (BIG-IP/A10/Zeus)などで、構成するのが一般的かと思います。 AWSには言わずと知れたロードバランサー「ELB」があります。 外部(インターネット)からのトラフィックだけでなく、プライ ベートサブネット(VPC)間のトラフィックも負荷分散できます。 ※通称 内部ELB。ELB作成時にinternalにチェック ELBについて分り易い資料 http://aws.typepad.com/aws_japan/2012/06/internal-elastic-load-balancers-in-the-virtual-private-cloud.html http://www.slideshare.net/Amazon
Auto ScalingをCLIから使う AutoScalingに関する説明はほどほどにして実際にCLI（コマンドラインインタフェース）から使ってみましょう！ 環境設定 各種SDKをダウンロードしてパスを通します。 これをaws.shという名前で保存しておきます。保存先は各自パスに合わせてください。 export EC2_HOME=~/dev/aws/ec2-api-tools-1.4.4.0/ export AWS_AUTO_SCALING_HOME=~/dev/aws/AutoScaling-1.0.39.0/ export AWS_ELB_HOME=~/dev/aws/ElasticLoadBalancing-1.0.12.0/ export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/ export PATH
[追記 2014/7/28 ] 現在スポットインスタンスは各リージョンの上限数が5個、もしくはそれ以下です。こちらをご覧ください。 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html 最近おみくじは大吉が出るまで引き続ければいいんじゃない、と思い始めた小室です。 Amazon Web ServicesのメインサービスであるAmazon EC2は3タイプの料金体系を展開しています。 オンデマンド リザーブドインスタンス スポットインスタンス オンデマンドは、従量課金で利用の制約がないパターンです。一番利用されているのではないでしょうか。 リザーブドインスタンスは前金を払う事で、1年、もしくは3年の利用料金を割り引いた形で利用出来る、という物です。これは確実に利用する事が決まっているサーバを確保する
ここ(http://aws.amazon.com/jp/ec2/instance-types/instance-details/)に明確な数値が 書いてないので、インスタンスタイプ毎のAZ間のスループットを計測してみました。 東京リージョンの 1a から 1b、1c に対してnetperfで負荷を掛けています。 (AZはAWSアカウント毎にDC群が異なりますので結果は目安として下さい。) EIP間の通信ではない＆同一VPC内のプライベートネットワーク間の通信を 計測対象としています。 計測方法 ・各AZに small、large、xlarge インスタンスを立てて、 netperf -f M -H 対象ホスト でスループットを計測。 ・試行回数は30回とし、平均値を取得。 ・負荷掛け側/掛けられる側のインスタンスタイプは同じとする。 スループット計測結果 ・単位はMbps、30回の平均値。
最近、今更ながらAWSを触っています。んで、まず初心者用にと始めたのが、おなじみドットインストール。 Amazon Web Services入門 (全17回) - プログラミングならドットインストール とても面白かったです。ていうか手軽すぎて鼻血が出そう。。。こっからさき、Chefとか色々勉強せねば、という感じですが。 んでまぁ、見事にハマったんですが、違う意味でも嵌ったわけです。 どうやら今年の春からVPCが標準になったらしい。 今年の春に、割と大きな動きがAWSにあったんですね。VPC（Virtual Private Cloud)環境が、EC2・RDSともにデフォルトになりました。 VPCは仮想的なプライベート空間をAWS内に構築する、みたいな理解なのですが、まぁそれはおいておいて。 つまり、僕くらいのんびりして今くらいに会員登録して、それからインスタンスを作り始める、とかをすると、E
以前...と言っても数年前の話になりますが、『今すぐフォローすべきnode.js界のスーパーエンジニア』のエントリを着火点として、様々な領域や分野で派生エントリが作成され、大反響を呼びました。(→ 「今すぐフォローすべきスーパーエンジニア」まとめ ) 最近AWS各種サービスについて調べる事が多くなって来ていますが、その中でもやはり際立った活動・成果等を出しておられる方々がAWS界隈を見渡しても本当に多いなぁという印象を受けました。(そして恐らく、自分が認識している範囲外にも数多くの素晴らしい方々が居られる事でしょう。) そこで個人的な情報収集・整理も兼ねて、このテーマに便乗する形で『フォローすべき』素晴らしき＆スーパーな方々をピックアップしてみました。 Twitterアカウントの情報等を元に情報を整理してますが、情報が変わっている、または間違っている等ございましたらコメント欄等で御指摘を頂
2015/11/13追記：現行のサービスにおける上限値や制限値については下記のAWS公式ページに情報がまとまっているようです。サービス毎の状況を確認される場合はこちらをご参照ください。 - AWS Service Limits - Amazon Web Services - AWS サービス制限 - アマゾン ウェブ サービス AWSでインフラ構築作業を行っていると、規模によってはあっという間に(定められている)要素数の上限に達してしまいます。後述する『上限緩和申請』を行えばその上限は増やす事が出来るのですが、実際に構築を行う前にその辺りの申請はスムーズに済ませておきたいところ。と言うわけで、現在AWSで利用上限が定められている要素とそれらの上限を増やす(上限緩和申請)ための依頼フォームの情報を個人的学習目的及び今後の備忘録として整理してみました。 AWS Service Limits(A
技術者ブログ クラウド型WAF「Scutum（スキュータム）」の開発者/エンジニアによるブログです。 金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中！ はじめに クラウドサービスの代名詞でもあるAWS(Amazon Web Services)が待望の東京リージョンを開設してしばらく経ちました。我々Scutum(スキュータム)はSaaS型のWAF(Web Application Firewall)サービスであるため、AWSのEC2のようなIaaS型のインフラ上に積極的に展開をおこなっています。本エントリではその際にポイントとなる、EC2でのデータ転送量への課金について調べてみました。 (クリックで拡大します) このエントリの内容はオフィシャルのウェブページやインターネット上の情報を元にしたものであり、実情と
こんにちはAWSチームの柳瀬です。 先日cloudinitの簡単な使い方を書いたので、今度はAuto Scalingと組み合わせて使ってみたいと思います。 Auto Scalingはとても便利なサービスですが、実際に使う場合は以下のような課題が出てきます。 課題 Auto Scaling構成後にアプリケーションをリリースすると、launch-configに登録したAMIのソースコードが古くなる新しいアプリケーションをリリースする度にAMI作りなおすのマンドクセ('A`)rc.localに書いてもいいけど処理を変更するときはAMI作りなおさなきゃいけない ミドルウェアの設定は変更が少ないとしても、プログラムは定期的に新しいバージョンに変更されたりしますよね。 今回はCloudInitとSubversionを使って起動時に最新のソースコードを設置する構成を作ってみました。 ※例ではSubver
AWSのベーシックトレーニング資料です。EC2,EBS,AMIの操作をハンズオン形式でトレーニングして頂ける内容となっています。
Amazon Q Business, now generally available, helps boost workforce productivity with generative AI Amazon Q Business is now available with many new features, including custom plugins, and a preview of Amazon Q Apps, generative AI–powered customized and sharable applications using natural language in a single step for your organization. Amazon Q Developer, now generally available, includes new capab
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[AWSマイスターシリーズ] Amazon Elastic Compute Cloud (EC2)![[AWSマイスターシリーズ] Amazon Elastic Compute Cloud (EC2)](https://cdn-ak-scissors.b.st-hatena.com/image/square/6c3b8aad0f2e4c4a4d521f4e12b46b0b2ad10955/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20130313aws-meister-regenerate-ec2public-130317204207-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
