Talked at "AWS Dev Day Online Japan" 2020.
本日のアップデートで Amazon Lightsail でコンテナが利用できるようになりました。 Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud 純粋にコンテナだけを使う AWS でコンテナを利用する場合、Amazon EC2、Amazon ECS(EC2/AWS Fargate)、Amazon EKS のいずれかを利用されていたかと思いますが、これらに加えて Amazon Lightsail が選択肢として追加されました。 AWS Fargate の登場でコンテナホストの管理から解放されるなど、随分とシンプルにコンテナ環境を利用できるようになりましたが、それでもまだ IAM ロールやログといったインフラ部分の管理を行う必要があります。 Am
背景 AWS LambdaでAPI開発をする AWS LambdaとAPI Gatewayを組み合わせることでサーバレスのAPIを開発することが可能です。サーバレスで構築することで手間をかけずにスケーラビリティやコストの最適化を手に入れることができ、さらに死活監視等が不要のため運用のコストを大幅に下げることができます。 開発パターンがまとまっていない サーバレスによるAPI開発は非常にメリットが多いのですが、開発パターンが様々あり一貫した方法があるわけではありません。例えば、Lambdaのデプロイは手動でzipをアップロードする方法や、SAM/ServerlesssFrameworkなどのデプロイ支援ツールを利用する方法、さらにオンラインエディタのCloud9を利用することもあります。関数ごとにディレクトリを分離する場合もあるし、ソースコードを共有してエントリーポイントだけ切り替える場合も
先日行われました AWS JAPAN SUMMIT ONLINE 2020 にて、「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」のテーマにて、私たちのグループで取り組んでいる全ての AWS に対する横断的な取り組みを ビジョナル CTO 竹内 と ビジョナル CIO 園田 より発表させていただきました。 今回は、その発表内容について、発表の中で伝えきれていない内容などより詳細にお話しさせていただきます。 こんにちは、システム本部 プラットフォーム基盤推進室 ORE (Organizational Reliability Engineering) グループ の 長原 です。 私が在籍するグループでは、 Visional グループの全事業のクラウドや非機能要件等に対して、横断的にエンジニアリングによる課題解決に取り組んでいます。 複数事業・マルチ
はじめに こんにちは、IT基盤部の天野です。AWSやGCPを用いたゲームインフラを担当しています。 DeNAが運用している大型ゲームでは、ステートレスなサーバにスポットインスタンスを使用しています。 スポットインスタンスはAWSに中断(=shutdown)されることがある代わりに、コストを大幅に抑えることができるインスタンスです。 AWSのイベントで見かける資料では、定常的な負荷はリザーブドインスタンスや Savings Plans を利用し、さらに負荷が増える部分で万が一落とされても問題ない範囲をスポットインスタンスで運用することが推奨されていたりします。 しかし、DeNA では web、memcached、worker等のサーバにおいて、ほとんどのリソースをスポットインスタンスで運用し、それでいてサービスは絶対に落ちない自信を持っています。 実際に DeNA でスポットインスタンスを本
一般的には、複数のAWSアカウントを持っている場合 aws configure --profile <profile> で aws cli の設定をすると思うが、これだとあらゆる aws コマンドを打つたびに --profile <profile> オプションでプロファイル名を指定しないといけないのでめんどくさい。 シェル毎に別のプロファイルをデフォルトで指すことができるようにして、tmux のウィンドウ毎にプロファイルを切り替えたい。 関連: gcloud でシェル毎にプロジェクトの切り替え設定 AWS_DEFAULT_PROFILE, AWS_PROFILE AWS_DEFAULT_PROFILE および AWS_PROFILE 環境変数でデフォルトプロファイルを切り替えられるので、この環境変数をシェル毎に設定しなおせば良い。ツールによってどちらの環境変数が参照されるかまちまちなような
つい最近、中途入社しましたバックエンドチームのid:takanamitoです。 今回は入社してすぐに会社の福利厚生をつかってAWSソリューションアーキテクト アソシエイトレベルを取得した話をご紹介します。 Amazon - Badge Verification - CertMetrics きっかけ 作戦 後に引けない状況をつくる どんな試験なのか知る どう勉強するかを考える 模試を受ける 試験当日 福利厚生 まとめ きっかけ 転職に伴いまとまった時間が確保できたことや、前職の同僚が同資格のプロフェッショナルを持っていて仕事でけっこう役立ってそうな感じでうらやましかったので取ろうと思いました。 過去に何度か時間ができたタイミングで趣味webサービスを作っていたんですが、途中で飽きたり運営がうまくいかなかったりといい結果が出ていませんでした。 そこで今回は路線変更して、資格という成果がわかりや
いよいよ明日発売開始であるAmazon Web Services 業務システム設計・移行ガイドの一貫したテーマが、「企業内でどのようにAWSを使っていくのか」です。企業内でのユースケースを元に、ネットワーク/システム設計や運用管理、移行の話をしています。その中で1章を割いて説明しているのが、AWSアカウントをどのように管理するかです。 複数(マルチ)AWSアカウント管理の重要性 AWSを利用する上で、AWSアカウントをどのように管理していくかは最重要事項です。AWSアカウント管理というと、一般的には、AWSリソースの認証認可であるIAMを使った運用方法について語られることが多いです。しかし、企業内で利用する際は、それだけでは不十分です。何故なら、企業内では1つのAWSアカウントではなく、複数のAWSアカウントを作成し運用することになるからです。いわゆるマルチアカウント運用です。 企業内での
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか? 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
こんにちは。アドテクスタジオでセキュリティエンジニアをしている岡崎です。 前回は、「AWS Management ConsoleへのSSO」について、紹介させていただきました。 今回は、「アドテクスタジオのAWSにおけるセキュリティグループの整理の仕方」と「Scout2を使った可視化」をしてみたことについて、紹介させていただきます。 今まで、ネットワークのセキュリティ設定「ファイアウォール」などはネットワークエンジニアが行っていました。しかし、AWSなどのパブリッククラウドを利用し始めてからは開発エンジニアがファイアウォール(AWSのセキュリティグループ)設定をする機会が増えており、今までファイアウォールの設定を経験をしていない開発エンジニアとっては設定に困ると思います。 そんな中、見様見真似でセキュリティグループの設定をすると、、、あとあと、 「あれ、これはなんの設定?」 「このソースI
はじめに 前回、「AWS SDK for Ruby バージョン 2 を使用したS3バケットへのオブジェクトアップロード」でS3へオブジェクトのアップロードを行いました。 でも、このままではアップロードしただけで、誰もアップしたオブジェクトにアクセスができないですね。。。 ということで、今回はアップロードしたファイルをブラウザからアクセスできるように期限付きURLの発行をしてみたいと思います。 ちなみに期限付きURLとはその名の通り、URLを発行してから10分だったり3日だったり1週間だったりと、利用できる期限を持たせたURLです。 1. アクセス先の準備 前回、「AWS SDK for Ruby バージョン 2 を使用したS3バケットへのオブジェクトアップロード」で作成したバケットを利用するので今回は省略します。 2. アクセスユーザーの用意 まずは、バケットへアクセスできるユーザーを準備
「Aurora(オーロラ)は、AWS史上、もっとも速いスピードで成長を続けているサービス」―7月28日、アマゾン ウェブ サービス ジャパンが行った報道陣向けの説明会において、同社 技術本部 エンタープライズソリューション部長/シニアソリューションアーキテクトの瀧澤与一氏は、データベースサービス「Amazon Aurora」への注目度の高さをこう表現しました。2014年の「AWS re:Invent」で発表されて以来、MySQL互換のマネージドデータベースサービスとして多くのユーザを獲得してきたAuroraですが、その勢いはリリースから2年経った現在も衰えることを知りません。なぜAuroraはこれほど力強い支持を得られているのでしょうか。説明会の内容をもとに、Auroraというデータベースエンジンのいまに迫ってみたいと思います。 説明会のスピーカを務めたアマゾン ウェブ サービス ジャパン
Using Buildkite you can scale your CI pipelines using the same techniques you use to scale production servers, which for many teams has meant creating an AWS-based Buildkite Agent cluster to horizontally scale capacity depending on your build queue. Shopify’s agent cluster for example runs 50,000 build jobs per day across a fleet of Buildkite agents, scaling up during the day for maximum performan
Microservices Meetup vol.1 @FiNC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く