Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

[AWS Black Belt Online Seminar] 大阪ローカルリージョンの活用とAWSで実現するDisaster Recovery 資料及び QA 公開

先日 (2018/7/17) 開催しました AWS Black Belt Online Seminar 「大阪ローカルリージョンの活用とAWSで実現するDisaster Recovery」 の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180717 AWS Black Belt Online Seminar AWS大阪ローカルリージョンの活用とAWSで実現するDisaster Recovery from Amazon Web Services Japan QA Q. ホットスタンバイ、ウォームスタンバイという言葉が出てきましたが、2つとも同様の意味と捉えて問題ないでしょうか。 A. ホットスタンバイ(マルチサイト)は、本番用のアクセスを振り向ける先としてもDRサイトをご利用いただけるケースです。ウォームスタンバイは、本番同等の機能はすべて兼ね備えていますが、本番のアクセスを振り向けるだけのインスタンスタイプや台数を用意しておらず、フル機能を兼ね備えた最小スペック・台数で構成されたDRサイトになります。以上より、意味は異なります。 Q. AWSコンソールは接続元IPアドレスの制御が可能なのでしょうか? A. AWSマネージメントコンソールのエンドポイントはインターネットに公開されております。AWS IAM(Identity & Access Management)にてユーザーを作成し、そのユーザーのIAMポリシーにて、接続元のIPアドレスを制限することが可能です。こちらにより、そのIAMユーザでAWSマネージメントコンソールにログインした場合には、IAMポリシーで指定したsource IPアドレスからのアクセス以外の場合には、アクションを拒否することができます。詳細は以下をご覧ください。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html ですが、一時的な接続元の拠点側のネットワーク不通により、指定したIPアドレスでのアクセスが困難な状況が考えられますので、IAMポリシーで指定した特定のsource IPアドレスからのアクセスのみを許可する構成は、DR対策の点において推奨いたしておりません。 Q. 大阪ローカルリージョンをメインサイトとして利用できないのはなぜですか? どなたでもご利用いただける一般用途を目的としたAWS東京リージョンでは4つのアベイラビリティゾーンがあり、メインサイトとしてご利用いただくために十分な機能を提供しております。一方で、AWS大阪ローカルリージョンは1つのアベイラビリティゾーンのみであり、メインサイトとしてご利用いただくために十分な機能を提供しているとは言えません。大阪ローカルリージョンは、東京リージョンの複数のアベイラビリティゾーン間に地理的により分離が必要な特定のワークロードを稼働しているお客様を支援するリージョンとなります。 頂いたご質問でご回答差し上げられなかったものについては、個別に弊社お問合せフォームにてご相談いただければと思います。 今後のWebinar情報 AWS Innovate Japan 2018 AWS Innovate は、AWS […]

Read More

[AWS Innovate プレセミナー] クラウドクラウド活用に必要な、クラウド推進組織の作り方・クラウド人材の育て方

〜クラウド活用に必要な、クラウド推進組織の作り方・クラウド人材の育て方〜 今、会社の規模や業種によらずAWSクラウドの活用は益々加速しています。その一方で、クラウドを使いたいけれど、クラウドのメリットを知り、正しく使える人材が足りない、といった課題をお持ちのお客様が数多くいらっしゃいます。これらの声に応えるため、AWS 技術習得を目的とした、日本初開催の大規模オンラインカンファレンス『AWS Innovate』を 8/28 より開催いたします。 一方、技術習得の裏には、クラウド推進組織や人材育成基盤の整備など、技術習得を促進するような仕組みが必要不可欠となります。本オンラインセミナーは、AWS Innovate に向けて、クラウド活用に必要なクラウド推進組織の作成、それに伴うクラウド人材育成についてのAWS ベストプラクティスをお伝えします。 開催概要 日時: 8/22 (水) 10:00-11:00 対象者: ・クラウドをこれから、または今よりさらに活用したいと考えている、クラウドを推進するような組織の方 ・クラウドを活用するのに必要な人材育成を担当されているリーダーの方 申し込み方法: こちらよりお申し込みいただけます。 視聴方法: オンラインセミナーですので、インターネットに接続できる環境からご視聴ください。 内容詳細: クラウド推進組織の作り方 (10:00-10:30) クラウドを導入するにあたり重要な役割を果たすのが「クラウド推進組織(CoE)」です。クラウド推進組織は、企業のクラウド導入に責任を持つスペシャルチームであり、その働き次第で御社のクラウド導入の成否が分かれます。クラウド導入のステージに応じて、クラウド推進組織の構成や役割が変わってくるため、御社に適したチームを組織化することが成功の秘訣です。当セッションでは、「基本編」として、クラウド推進組織の活動内容・必要な人材・組織形態について、クラウド導入ステージの観点より説明し、「実践編」として、AWSコンサル事例から導き出された10のベストプラクティスを紹介します。 スピーカー 川嶋 俊貴 AWS プロフェッショナルサービス アドバイザリーコンサルタント       クラウド人材の育て方 (10:30-11:00) AWSを技術的に使いこなせるエンジニアだけがクラウド人材ではありません。アイデアを形にすることが出来る、アイデアを柔軟に発展させていく能力のある人材が組織に増えれば、イノベーションは加速していきます。つまり、クラウド人材とはエンジニアだけの話ではありません。そのためのヒントを本セッションでは紹介していきます。 スピーカー 松本 照吾 AWS パブリックセクター セキュリティコンサルタント       皆様のご参加をお待ちしております。 AWS Innovateの詳細はこちら

Read More

Amazon RDS for MySQLの delayed replicationで障害から復旧を行う

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

Read More

Amazon Dynamo DB グローバルテーブル 東京リージョン対応のお知らせ

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   Amazon DynamoDBのグローバルテーブル機能が東京リージョンに対応しましたのでお知らせいたします。 DynamoDBはどのような規模でも信頼性が高いパフォーマンスを維持できる、完全マネージド型の非リレーショナルデータベースです。グローバルテーブルの機能により、マルチリージョン、マルチマスターのデータベースを構築することが可能となり、そのレイテンシーを 10 ミリ秒未満に維持できるようになります。選択した AWS リージョンにテーブルの更新内容を自動的にレプリケーションすることができ、また、グローバルテーブルを使用して、DynamoDB テーブルデータを他の AWS リージョンにレプリケーションすることで可用性を高めることもできます。   作成済のDynamoDBテーブルを選択すると、「グローバルテーブル」のタブが出てきます。設定作業はテーブル作成後に行うこととなりますが、テーブルが空である必要があるのでご注意ください。 ここから、機能を有効にすることができます。機能を使うためにはDynamoDB Streamsの機能をオンにする必要があります。DynamoDB Streamsは、テーブルに対して発生した変更をキャプチャし、例えばAWS Lambdaを実行させるなどに機能をつかさどります。グローバルテーブルはこの機能を用います。 そして対象リージョンを指定すると、レプリカテーブルが指定したリージョンに作成されます。 DynamoDBは今年の5月に継続的バックアップとPITR(ポイントインタイムリカバリ)に対応しより使いやすくなっています。今回のグローバルテーブル対応で、より高度な耐障害性とリージョンワイドのアプリケーションへのより高速な対応性能を備えることなりました。 – プロダクトマーケティング エバンジェリスト 亀田

Read More

SAP関連サービスやソリューションを提供するAPNパートナーへの連絡方法

AWS Partner Network (APN)は、Amazon Web Services (AWS)のグローバルパートナープログラムであり、世界中の数万社のパートナーによって構成されています。APNコンサルティングパートナーは、AWS上のワークロードとアプリケーションの企画、設計、構築、移行、および運用管理を支援します。APNテクノロジーパートナーは、AWSクラウド上でホストされている、あるいはAWSクラウドと統合されたソフトウェアソリューションを提供します。 SAP on AWSに特化したサービスやソリューションを提供するAPNパートナーをお客様が簡単に見つけられるように、AWS SAP Partner Services and Solution Directoryを作成しました。このディレクトリでは、SAP on AWS向けの以下のタイプのサービスとソリューションを見つけることができます:

Read More

AWS Summit Tokyo 2018セッション一般公開お知らせとメディア系セッションのまとめ

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   AWS Summit Tokyo 2018の各セッション動画及び資料の一般公開が開始されました。これまでは、名刺情報などの登録が必須でしたが、その必要はなく自由にご覧いただくことができるようになりました。 ▼配布サイト https://summitregist.smktg.jp/public/application/add/59   また、このブログ記事では、メディア系サービスやセッションについてまとめてみたいと思います。 2020 に向けて、スポーツイベントにおける AWS 活用事例               動画               資料 【朝日新聞社様ご登壇事例】機械学習を用いた編集業務の生産性向上への取り組み               動画               資料 AWS Media Service と […]

Read More

DDoS に対する AWS のベストプラクティス – ホワイトペーパーが更新されました

あなたは分散型サービス拒否 (DDoS) 攻撃やその他のサイバー攻撃の影響からビジネスを守るために働いており、アプリケーションの可用性と応答性を確保し、サービスに対するお客様の信頼を維持したいと考えています。また、攻撃に対応するためにインフラストラクチャをスケールする必要がある場合でも、不必要なコスト上昇を避けたいと考えています。 AWS はインターネット上の攻撃を防ぎ、高可用性・セキュリティの確保および回復力を得られるように、ツール・ベストプラクティスおよびサービスを提供することをお約束します。私達は最近、2018 年版の DDoS に対する AWS のベストプラクティス(英語のみ)のホワイトペーパーをリリースしました。今回のアップデートでは、 DDoS 攻撃への対策を強化するのに役立つ、以下の新しく開発された AWS サービスを考慮に入れています: 追加された AWS サービス: AWS Shield Advanced、AWS Firewall Manager および AWS Application Load Balancer のような新世代の ELB 追加された AWS サービスの機能: AWS WAF Managed Rules、AWS WAF Rate Based Rules、新しい世代の Amazon EC2 インスタンスおよび API Gateway のリージョン API エンドポイント このホワイトペーパーは、DDoS 攻撃に対する回復力のあるアプリケーションを構築するための規範的な DDoS ガイダンスを提供します。ボリューム型攻撃やアプリケーション層に対する攻撃など、さまざまな攻撃タイプを紹介し、各攻撃タイプを管理する上で最も効果的なベストプラクティスを説明します。また、DDoS 緩和戦略に適合するサービスや機能および、それぞれがどのようにアプリケーションを保護するのに役立つのかについて要点を説明します。 原文: AWS […]

Read More

Amazon Elasticsearch Service エラーログの表示

本日、Amazon Elasticsearch Service(Amazon ES)は、Amazon CloudWatch Logs へのエラーログ出力のサポートを発表しました。 この新機能は、エラーログをキャプチャする機能が提供され、サービスの運用中に発生したエラーや警告に関する情報にアクセスできます。 これらの詳細な情報はトラブルシューティングに役立ちます。 この情報を使用して、Amazon ES の利用者と協力してドメイン上のエラーまたは警告を引き起こすシナリオのパターンを特定できます。 この機能へのアクセスは、ドメインが作成されるとすぐに有効になります。 ログを自由にオン/オフすることができ、支払いは CloudWatch の利用した分のみの料金です。 ドメインのエラーログの配信を設定する アクティブなドメインのエラーログを有効にするには、AWS Management Console にサインインし [Elasticsearch Service ]を選択します。 Amazon ES コンソールで、一覧からドメイン名を選択しダッシュボードを開きます。 次に[Logs]タブを選択します。 このペインでは、検索のスローログ、インデックススローログ、およびエラーログを CloudWatch Logs のロググループに出力するように Amazon ES ドメインを設定します。 スローログの設定に関する詳細は、AWS データベースブログのブログ記事Viewing Amazon Elasticsearch Service Slow Logsを参照してください。 エラーログの設定で、[セットアップ]を選択します。 新しいロググループを作成するか既存のロググループを使用するかを選択できます。 次のようなパスとしてロググループの名前を付けることをお勧めします。 /aws/aes/domains/mydomain/application-logs/ このようなネーミングのスキームを使用すると、CloudWatch アクセスポリシーを簡単に適用できます。このポリシーでは次のような特定のパスのすべてのロググループに権限を付与できます。 /aws/aes/domains CloudWatch ロググループにログを配信するには、Amazon ES が CloudWatch Logs […]

Read More

【開催報告】Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning for Digital Advertising from Amazon Web Services Japan 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update from Amazon […]

Read More