タグ

amazonとEC2に関するmsakamoto-sfのブックマーク (8)

  • Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした | CyberAgent Developers Blog

    技術部 サービスリライアビリティグループ(SRG)の長谷川 @rarirureluis です👳 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 はじめに Apple M1 で Arm という単語をよく耳にし、そしてその性能に驚いた方も多いと思います。Apple M1 が搭載された Mac のベンチマークはこちら そして Amazon EC2(以下:EC2)にも Arm が搭載されたインスタンスがあります。 https://aws.amazon.com/jp/ec2/graviton/ 今回はとあるサービスの全開発環境の EC2 インスタンスを m5.large から t4g.medium へ移行したら幸せになれたので、この記事を

    Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした | CyberAgent Developers Blog
  • EC2 Image BuilderによるOSイメージビルドパイプラインの自動化 | Amazon Web Services

    Amazon Web Services ブログ EC2 Image BuilderによるOSイメージビルドパイプラインの自動化 社会人になったばかりの頃、開発チーム向けのOSイメージビルドの仕事がアサインされたのを今でも思い出します。時間はかかるし、エラーはよく出るし、再作成とスナップショット再取得をなんども実行する必要がありました。さらに、ご想像のとおり、そのあとには大量の手動テストが控えていたのです。 OSを最新に保つことの重要性は現在も変わりません。場合によっては自動化スクリプトを開発してくれるチームがあるかもしれませんが、いずれにせよVMのスナップショットを手動で取得するという作業は、多くのリソースを消費し、都度エラー対処が要求される、時間のかかる作業であることに変わりはありません。今日ここで、EC2 Image Builderを発表できることを大変うれしく思います。これは、自動化

    EC2 Image BuilderによるOSイメージビルドパイプラインの自動化 | Amazon Web Services
  • AWS EC2 Amazon Linuxインスタンス起動後、最初にやることまとめ(SysVinit編) - Qiita

    AWS EC2 Amazon Linuxインスタンス起動後、最初にやることまとめ(SysVinit編)AWSEC2AmazonLinux

    AWS EC2 Amazon Linuxインスタンス起動後、最初にやることまとめ(SysVinit編) - Qiita
  • Amazon EC2再入門 2014年7月版 | DevelopersIO

    ウィスキー、シガー、パイプをこよなく愛する大栗です。 最近EC2関連の重要アップデートが出てきました。嬉しい機能が増えているのですが、昔の知識では使いこなせないので、現時点でのEC2の起動方法について纏めようと思います。 Management ConsoleからEC2を起動します。今回は東京リージョン(ap-northeast-1)でAmazon Linuxを起動する前提です。 記事のアップデートとして Amazon EC2再入門 2015年1月版 を書きました。最新情報はこちらを参照してください。 起動手順 EC2を起動していきましょう。 AMIの選択 AMI(Amazon Machine Image)を選択します。 好きなOSを選択しましょう。注意点はCPUアーキテクチャ、ハイパーバイザ、ルートデバイスです。 ここではAmazon Linux AMI 2014.03.2(HVM) -

    Amazon EC2再入門 2014年7月版 | DevelopersIO
  • [AWS運用ポイント3]仕様を知らないと使えない

    Amazon Web Services(AWS)を利用する上で知っておくべき制限事項がある。前回の「申請面でのつまずきポイント」のように、申請すれば解消する制限もあるが、ユーザーが受け入れなければならない制限がある。今回はこうした、知らないとつまずく制限事項やAWSの仕様について解説する。 つまずきポイント1:監視データを2週間しか保存できない システムを運用していると、リソースの状況を確認・分析する必要がある。AWSでは、「CloudWatch」と呼ぶサービスで、EC2やRDSなどの各リソースの状況を監視できる。EC2インスタンスのCPUの状況やRDSのI/O状況、ELBのレイテンシー状況、課金情報などが確認できる。 しかし、そうした監視データの記録には上限があり、最大2週間までしか記録されない。これを知らずに運用して、いざ2週間より前の監視データを参照しようとしても、知るすべはないので

    [AWS運用ポイント3]仕様を知らないと使えない
  • [AWS運用ポイント2]最悪の場合アカウント停止も

    Amazon Web Services(AWS)にはさまざまなサービスがあり、申請しないと利用できないものがある。運用編、第2回の今回は、申請面でのつまずきポイントである。申請を怠ると、最悪アカウントの停止を言い渡されることになる。 つまずきポイント1:EC2からメールを送信できない あるユーザーで、EC2インスタンスからメールを送信した際に、10通送ったはずなのに7通しか送信先に届かないということがあった。 これは、このユーザーがメール送信の申請をしていなかったことが理由である。 EC2インスタンスから外部(インターネット)に向けてのメール送信に、一定の制限が設けられている。具体的には、EC2インスタンスから送信できるメールの量に上限が設定されており、この上限を超えると送信先にメールが届いたり、届かなかったりといったことが発生する。EC2インスタンスが踏み台にされて、スパムメールがリレー

    [AWS運用ポイント2]最悪の場合アカウント停止も
  • AWS News Blog

    Build RAG applications with MongoDB Atlas, now available in Knowledge Bases for Amazon Bedrock Foundational models (FMs) are trained on large volumes of data and use billions of parameters. However, in order to answer customers’ questions related to domain-specific private data, they need to reference an authoritative knowledge base outside of the model’s training data sources. This is commonly ac

  • AWSよりGoogle Compute Engineを選びたくなる10の理由

    Google Compute Engineについて興味深いブログがあったので、勉強を兼ねて和訳してみました。 原文はこちらです。 以下、超訳。 昨年(訳注2012年のこと)、GCEとしてGoogleがIaaSの提供を発表した時に、amazonは心配するべきかどうか聞いてみた。18ヶ月後、Google Compute Engineは一般公開され、信頼性、価格、革新性において間違いなくAWSの競合になったと見受けられる。混雑したIaaS市場には多くの新規参入があり、そのいくつかはマイクロソフト、HPとIBMのような十分に確立された企業·ベンダーである。しかし、大多数のそうしたサービス群は限定的な機能しか持たない。彼らはAWSに対抗することは諦め、Amazon EC2の2008年相当のものに見えた。しかし、GCEはそのアプローチからして異なる。Amazon EC2の類似機能に焦点を置くのではなく

    AWSよりGoogle Compute Engineを選びたくなる10の理由
  • 1