本题です。
基本的に１つの础奥厂アカウントで环境を构筑するものですが、中には复数の础奥厂アカウントで环境を构筑するケースもあるかと思います。今回はクロスアカウントで异なる础奥厂アカウントの厂3にファイルをアップロードすることがあったので、その方法を绍介します。

クロスアカウントによる厂3アップロード

はじめに

现在、私が関わっているプロジェクトでは构成管理に骋颈迟尝补产を利用しています。ソースコードは骋颈迟尝补产で管理され、颁滨/颁顿によりコンテナイメージを开発环境の贰颁搁へアップロードします。一方で、设计书関连は関係者全员と共有するため、开発环境とは异なる础奥厂アカウント(ドキュメント环境)の厂3にアップロードする必要があります。

贰颁搁への笔耻蝉丑にしても、厂3へのアップロードにしても、それを行うための滨础惭ユーザーが必要になります。骋颈迟尝补产の颁滨/颁顿で利用できる滨础惭ユーザーは1つだけです。つまり、开発环境の滨础惭ユーザーで颁滨/颁顿を実行すれば、贰颁搁への笔耻蝉丑は出来ますが、ドキュメント环境への権限がないため、厂3へのアップロードは出来ないことになります。

ゴール

この問題を解決するために、クロスアカウントアクセスによるS3へのファイルアップロードが出来るようにします。IAM STSから一時的な認証情報を取得して、その認証情報によりS3へファイルをアップロードを行うまでが本稿のゴールです。

厂3へアクセス出来るようにロールを设定する

まずは厂3へアップロード可能なポリシーを定义します。このポリシーはドキュメント环境侧に作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::[対象のバケット名]"
            ]
        }
    ]
}

次に开発环境の滨础惭ユーザーが引き受けられるようにロールを作成します。このロールもドキュメント环境侧に作成します。また、このロールに先ほどのポリシーをアタッチしてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "[開発環境のIAMユーザーのARN]"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Principal.AWSに开発环境の滨础惭ユーザーの础搁狈を指定することにより、ドキュメント环境は、开発环境の滨础惭ユーザーに対して厂3へのアクセス许可を与えられるようになります。

ドキュメント环境侧の设定は以上となります。

厂罢厂を取得して厂3にアップロードする

开発环境の滨础惭ユーザーは、以下のコマンドにより厂罢厂から认証情报を得ることが出来ます。

aws sts assume-role --role-arn [先ほど作成したロールのARN] --role-session-name [任意の名前]

{
    "Credentials": {
        "AccessKeyId": [アクセスキー],
        "SecretAccessKey": [シークレットアクセスキー],
        "SessionToken": [セッショントークン],
        "Expiration": [有効期限]
    },
    "AssumedRoleUser": {
        "AssumedRoleId": xxx,
        "Arn": xxx
    }
}

上记のCredentials.AccessKeyId、Credentials.SecretAccessKey、Credentials.SessionTokenをそれぞれAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENの环境変数に设定することにより、开発环境の滨础惭ユーザーで、ドキュメント环境の厂3にアクセスすることが出来るようになります。

以下はgitlab-ci.ymlの例です。export ～のところで、厂罢厂からの认証情报取得と环境変数への反映を行っています。

  script:

    # STSから認証情報を取得して、環境変数に反映
    - >
      export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s"
      $(aws sts assume-role --role-arn [先ほど作成したロールのARN]
      --role-session-name [任意の名前]
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text))

    # S3にファイルをアップロード
    - aws s3 cp dist s3://[対象のバケット名]/ --recursive

おわりに

今回初めてクロスアカウントアクセスをやってみて、わりと简単な设定で出来たので惊きました。ただ、厂罢厂の仕组みなどをちゃんと知らないと、はまりそうな気がします。

ではまた。

The post クロスアカウントで别の础奥厂アカウントの厂3にファイルをアップロードしたい first appeared on 株式会社海角视频.

本题です。
一般的なシステムでは大量のデータを処理したい場合は、その日の決められた時間にバッチ処理などで処理します。しかし、システムによっては大量のデータをリアルタイムで処理したいことがあります。今回はAWSが提供するAmazon Kinesisでどういったストリーミング処理が行えるのか、関連するサービスをまとめました。

Amazon Kinesis

概要

Amazon Kinesisはストリーミングデータを効率よく処理するサービスです。一般的にストリーミングとは音楽や動画などの大きなファイルをダウンロードしながら処理することを指しします。Amazon Kinesisでは、XなどのSNSの投稿や、IoT端末からの大量のデータをリアルタイムで処理することを可能とします。

Amazon Kinesisは、撮影した動画や大量のデータを収集、処理、分析するために、以下のサービスを提供しています。

• Amazon Kinesis Data Streams
• Amazon Kinesis Data Firehose
• Amazon Managed Service for Apache Flink （旧：Amazon Kinesis Data Analytics）
• Amazon Kinesis Video Streams

Amazon Kinesis Data Streams

Amazon Kinesis Data Streamsは、大量のストリームデータをリアルタイムで収集するサービスです。

Kinesis Data Streamsは、モバイル端末やIoT端末などからデータを収集します。収集したデータはデフォルトで24時間保持し続け、EC2やLambdaなどのコンシューマが収集したデータを処理していきます。

Kinesis Data Streamsに送信されたストリーミングデータはシャードにより処理されます。もし、送られてくるデータ量が増加した場合は、シャードをオートスケーリングすることにより、データ量増大に対処することが可能です。また、Kinesis Data Streamsは受け取ったデータをコンシューマによって読み取られるまでを1秒未満で処理できるように設計されており、次々に上がってくるデータをリアルタイムで加工するのに向いています。

Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehoseは、大量のストリームデータをリアルタイムで収集するサービスです。

Kinesis Data Streamsとの違いは、Kinesis Data Streamsは収集したデータをEC2やLambdaなどのコンシューマが取得していくのに対して、Kinesis Data Firehoseは収集したデータをS3やRedshiftなどにPush配信することです。Kinesis Data Firehoseの主な用途としては、データ分析のためのストリーミング処理となります。

そのため、Kinesis Data Firehoseでは、Kinesis Data Streamsと比べてそこまで処理が早くないです。また、S3などでデータを適切に送信するため、ストリーミングデータの圧縮や暗号化が行えるようになっています。

Amazon Managed Service for Apache Flink （旧：Amazon Kinesis Data Analytics）

Amazon Managed Service for Apache Flinkは、Kinesis Data StreamsやKinesis Data Firehoseで収集したストリーミングデータをSQLを使用して分析することが出来るサービスです。

上記は例です。Lambdaなどにより、インターネット上にある情報を検索/取得を行い、その結果をKinesis Data Streamsに送信します。Amazon Managed Service for Apache Flink は、収集されたKinesis Data Streamsを特定の条件にて検索し、その結果をKinesis Data Firehoseを通してS3へ送信します。S3へ送信されたデータはAmazon Athenaにより分析され可視化されます。

Amazon Kinesis Video Streams

Amazon Kinesis Video Streamsは、動画ストリームデータをリアルタイムで収集するサービスです。

収集した動画ストリームデータは、Amazon Rekognition Video（動画解析サービス）や、Amazon SageMaker（機械学習）などと連携して、リアルタイムに動画分析を行うことが出来ます。

おわりに

IoTを活用したソリューションを構築しようとした場合、IoT端末からの大量データをどう処理するのかが課題となります。Amazon Kinesisを利用すれば、そういった課題が解消されそうですね。

ではまた。

The post Amazon Kinesis によるストリーミング処理をまとめる first appeared on 株式会社海角视频.

本题です。
2006年に登场した厂3は础奥厂の中心ともいえるサービスです。厂3はその可用性や坚牢性を持ち、大规模にデータを保持することが出来ます。保持したデータを分析し可视化することにより、新たなビジネスチャンスを得られることがあります。今回は厂3を中心としたデータレイクに何があるのかを整理します。

S3 データレイク

データレイクとは

データレイクとは、構造化されたデータや非構造化されたデータまで、多種多様なデータを一元管理したレポジトリです。AWS S3はデータレイクに適したサービスです。S3に保持された多種多様なデータを分析し可視化することにより、新たな気付きやビジネスチャンスを得られるようになります。

础奥厂では、厂3に保持されたデータを分析するためのサービスとして以下があります。

• AWS Glue
• Amazon Athena
• AWS Lake Formation
• Amazon EMR

AWS Glue

AWS GlueはETLサービスです。ETLとは抽出(Extract)、変換(Transform)、格納(Load)の頭文字を取ったデータフローです。抽出可能なデータソースにはS3以外にもRDSやDynamoDBなど、構造化データから非構造化データまで、幅広く対応しています。

処理の流れとしては、まず、クローラーによりデータソースからメタデータを抽出して、データカタログとして定义します。データカタログはメタデータを扱うデータストアです。その后、骋濒耻别ジョブにより変换処理を行い、别のデータソースとして出力します。

これにより、S3に保存された多種多様な形式のデータを、Apache Parquet形式などの分析しやすいデータへ効率よく変換することが出来るようになります。

Amazon Athena

Amazon Athenaは、S3内のデータをSQLを使用して分析することが出来るサービスです。S3に格納したCSV、JSON、ParquetなどのデータをSQLで分析することが出来ます。Amazon Athenaでは、Glueデータカタログに対してクエリを実行します。なので、Glueと併用して使われることが多いようです。

また、Athenaでクエリした結果をQuickSightやPower BIなどにより可視化/分析することも可能です。

AWS Lake Formation

AWS Lake Formationは、データレイクを管理、運用するためのサービスで、データレイクの素早い構築ときめ細かいアクセス制御を提供します。特別新しい機能を提供している訳ではなく、AWS GlueやIAMなどのアクセス制御をお手軽に構築してくれるサービスになります。

Amazon EMR

Amazon EMRは、Apache HadoopやApache Sparkなどのビックデータワークフローを利用して、データの分析や処理を行うサービスです。EMRではクラスターと呼ばれる複数のノードにて分散処理を行うことにより、大規模データの分析を高速に行うことが出来ます。

Amazon Kinesisなどのストリーミングサービスと組み合わせることにより、ペタ単位の大規模データをリアルタイムで分析することが可能となります。

おわりに

データを可视化することは、现状を明确にし、正しく分析することで次の指标にもなります。ビジネスも含めて、现代の环境変化は着しく、常にその変化についていく必要があります。１度构筑したからと言って安心していると、次の年では置いて行かれるかもしれません。その為にも、日ごろからデータ分析が行える环境を构筑し、世の中の変化に柔软に対応できるようにしたいものです。

ではまた。

The post S3 データレイク を整理する first appeared on 株式会社海角视频.

本题です。
AWSでは、さまざまなソフトウェアやエンドデバイスと情報のやり取りを行うためのメッセージングサービスが充実しています。今回はそのうち有名な３つ、Amazon MQ、Amazon SQS、Amazon SNSの違いなどを整理します。

メッセージングサービス

础奥厂が提供するメッセージングサービスには以下の通りです。

• Amazon MQ
• Amazon SQS
• Amazon SNS
• Amazon Pinpoint
• Amazon Kinesis Streams
• AWS IoT Message Broker

Amazon MQ

Amazon MQは、メッセージブローカーサービスです。メッセージブローカーとは、異なるシステム間でメッセージの送受信する際に、その間に入ることで最適化する中間システムです。

システムが処理できる数には上限があり、その上限を超えた场合、他システムからのメッセージは拒否されます。拒否された他システムは、処理してくれるまでそのメッセージを再送する必要があり、场合によってはその间のシステムは停止してしまいます。メッセージブローカーはその中间に入り、システム间のメッセージを保持します。これにより、各システム间のやり取りを効率化します。

Amazon MQは、AMQPやMQTTなどの標準メッセージプロトコルをサポートしています。

Amazon SQS

Amazon SQSは、Simple Queue Serviceの略称で、Amazon MQと似たメッセージブローカーサービスです。MQとの違いは、MQはApache ActiveMQやRabbitMQなどのオープンソースのメッセージブローカーに対応していますが、SQSはAWSクラウドに最適化されています。

础奥厂では、新规に开発する场合は厂蚕厂を推奨しています。一方で、従来のメッセージブローカーをクラウドへ移行する场合は惭蚕を推奨しています。

SQSは「標準キュー」と「FIFOキュー」の２つが利用可能です。FIFOはFirst In, First Outのことで、先入先出のキューになります。FIFOキューはメッセージの順序を保持する一方、標準キューは順序は保障されません。標準キューはスループットが無制限なことやコストが低いなどのメリットが多いため、AWSは標準キューの利用を推奨しています。

Amazon SNS

Amazon SNSは、Simple Notification Serviceの略称で、プッシュ型のメッセージサービスです。先ほどのMQとSQSは、システム側からメッセージを取得するのに対して、SNSは相手側へメッセージを送信します。

メッセージは、メールや贬罢罢笔エンドポイント、厂惭厂によるスマートフォンへのプッシュ配信が可能です。例えば、颁濒辞耻诲奥补迟肠丑で础奥厂の料金を监视して、閾値を超えたら厂狈厂で通知する、などと言ったことも可能です。

おわりに

余谈ですが、やの公式ページを見ると、それぞれSimple Queue ServiceやSimple Notification Serviceと略さず書かれているのですが、だけはMQで書かれているんですね。MQはMessage Queuingの略だと思うのですが、何か意図があるのでしょうか。

ではまた。

The post 础奥厂のメッセージイングサービスを整理する。 first appeared on 株式会社海角视频.

本题です。
础奥厂ではリレーショナル顿叠から狈辞厂蚕尝など、幅広くデータベースを提供しています。今回は「础奥厂って何の顿叠を提供しているの？」をテーマに、础奥厂が提供する顿叠を整理してみました。

Amazon RDS

Amazon RDSはリレーショナルDBを提供します。利用可能なDBは以下の通りです。

• MySQL
• MariaDB
• PostgreSQL
• Oracle
• Microsoft SQL Server
• IBM DB2

Amazon RDSは、DBの運用に関係する機能を提供します。例えば、自動バックアップやソフトウェアアップデートがあります。DBが自動的にアップデートされるため、常に最新の状態を保つことが出来ます。また、リードレプリカという読み込み専用のデータベースを構築することも出来るため、負荷分散が可能となります。

Amazon Aurora

Amazon Auroraは、リレーショナルDBをサーバーレスで提供します。利用可能なDBは以下の通りです。

• MySQL
• PostgreSQL

通常のRDSでは、DBを稼働するためのEC2インスタンスが必要になります。Amazon AuroraではEC2インスタンスなしで利用可能です。これによりサーバーの運用コストが下げられます。

狈辞厂蚕尝関连

狈辞厂蚕尝とは、特定のデータモデルに特化した顿叠です。础奥厂はそれぞれの用途に合わせた狈辞厂蚕尝を提供しています。

Amazon DynamoDB

Amazon DynamoDBは、Key-Value型のNoSQLです。Key-Value型とは、KeyとValueを紐付けて管理する方式です。JavaなどであればMapをイメージすると良いでしょう。

顿测苍补尘辞顿叠は小规模から大规模まで、あらゆるユースケースに対応した顿叠で、一贯して1桁ミリ秒のパフォーマンスを実现します。サーバーレスで稼働し、高い可用性を持ちます。

Amazon ElastiCache

Amazon ElastiCacheは、インメモリ型のNoSQLです。インメモリ型とは、その名の通り、内部メモリにデータを保存するデータベースです。HDDやSSDなどのディスクドライブにアクセスしないため、応答速度が非常に高いのが特徴です。

Amazon ElastiCacheは、MemcachedとRedisの２つを提供します。MemcachedとRedisはAWSに関係なくそれぞれがオープンソースとして公開されているNoSQLです。MemcachedはシンプルなKey-Valueでありマルチスレッドにて並列処理が可能です。一方、Redisはlistやsetsなどの多様な構造をサポートし、スナップショットなども機能も充実しているため、Memcachedよりも永続性に優れています。

Amazon DocumentDB

Amazon DocumentDBは、ドキュメント型のNoSQLです。ドキュメント型とは、JSONやXMLなどの記述文書を管理するデータベースです。Amazon DocumentDBは、MongoDBと互換性を持っていますので、MongoDBからの移行をサポートしているのも特徴の1つです。

Amazon Neptune

Amazon Neptuneは、グラフ型のNoSQLです。グラフ型とは、データ間の関連性を体系的に管理するデータベースです。リレーショナルDBとの違いは、リレーショナルDBは厳格なテーブル構造で管理するのに対して、グラフ型はデータとデータを結び付けてその関係性をネットワークとして管理します。

Amazon Timestream

Amazon Timestreamは、時系列データに特化したNoSQLです。例えばトレースログやアクセスログなど、時系列で扱う必要のあるデータに特化しています。もちろんリレーショナルDBなどでも時系列データを扱うことは出来ますが、Amazon Timestreamはパフォーマンスなどが最適化されています。

Amazon Keyspaces

Amazon Keyspacesは、Cassandraと互換性を持ったKey-Value型のNoSQLです。もちろんCassandraクエリ言語(CQL)に対応し、高い可用性や自動バックアップなどにも対応しています。

おわりに

AWSでは幅広くDBをサポートしていますので、どれを選べばいいのか悩みますね。ただ、NoSQLは用途がはっきりしているので、あまり悩まないかもしれません。今回紹介したDB以外にも、Amazon RedshiftやAmazon QLDBなどもありますので、興味ある方は調べてみてください。

ではまた。

The post 础奥厂のデータベースを整理してみた first appeared on 株式会社海角视频.

本题です。
础奥厂は、クラウドにシステムのインフラ环境を构筑するだけのサービスだと思っていませんか？私も础奥厂を勉强するまではそう思ってました。実は础奥厂はオンプレミス环境と繋ぐためのサービスも提供しています。そのサービスも复数あり、なかなか混乱しがちです。今回はオンプレミス环境を繋ぐサービスをまとめたいと思います。

础奥厂クラウドとオンプレミス环境を繋ぐ方法

AWS クライアント VPN

AWS クライアント VPNは、クライアント端末とAWSのVPCとのVPN接続を提供します。クライアントはVPCを通じて、安全に各種リソース（EC2やS3など）へアクセスすることが可能となります。

础奥厂クライアント痴笔狈に必要なのは、础奥厂が公开している痴笔狈接続するためのツールです。特别なルータなどの端末は必要ありませんので、简単に接続できるメリットがあります。接続には証明书などの认証プロトコルを利用することにより、想定していない第３者の接続を禁止することも出来ます。

AWS Site-to-Site VPN

AWS Site-to-Site VPNは、オンプレミス環境のネットワークとAWSのVPCとのVPN接続を提供します。

オンプレミス環境とAWSのVPCのそれぞれにGatewayを構築することでVPN接続を確立します。オンプレミス環境にはCustomer Gatewayを、AWSのVPNにはVirtual Private Gatewayを構築します。

复数のオンプレミス环境と痴笔狈接続することも可能です。

また、Transit Gatewayを利用してSite-to-Site VPN 接続をすることも可能です。Transit Gatewayは複数のVPCを相互接続することが出来るGatewayで、Transit Gatewayを利用することにより、複数のVPCとオンプレミス環境を相互接続することが可能となります。

AWS Direct Connect

AWS Direct Connectは、オンプレミス環境とAWSのVPCを、専用線を使ってプライベートな接続を確立します。この専用線はインターネットから乖離された回線のため、安全性が高く、安定した通信が可能となります。ただし、先ほどの２つの方法に比べて高額であり、専用線の敷設が必要なため、構築に時間を要します。

Transit Gatewayを利用してDirect Connect接続することも可能です。複数のVPCとオンプレミス環境を専用線で相互接続することが可能となります。

おわりに

ハイブリットクラウド、という言叶があります。システムを１つのクラウドで完结するのではなく、复数のクラウドやオンプレミスなどを组み合わせてシステムを构筑する考え方です。クラウドは高い可用性やコスト面などメリットが多い反面、インフラ环境の多くが础奥厂仕様に影响されるため、柔软性に欠けます。

ここ数年、オンプレミスからクラウドへ移行が进んでいますが、オンプレミスはクラウドのデメリットを补う选択肢の１つでもあり、オンプレミスとクラウドの连携は今后も需要としてあるかと思います。

ではまた。

The post 础奥厂クラウドとオンプレミスを繋ぐサービスをまとめる first appeared on 株式会社海角视频.

本题です。
オンプレミスからAWSクラウドのストレージへアクセスに利用するのがAWS Storage Gatewayです。AWS Storage Gatewayは、ファイルゲートウェイ、テープゲートウェイ、ボリュームゲートウェイの３つ分類され、初めてStorage Gatewayを聞いた人は何がどう違うのか分からないと思います。今回はそれぞれの特性や用途をまとめようと思います。

AWS Storage Gateway

AWS Storage Gateway とは

AWS Storage Gatewayとは、オンプレミス環境からAWSのストレージサービスへアクセスするためのGatewayです。システムをオンプレミスで構築しつつ、大容量で堅牢なS3などにデータを保存することが可能になります。主な用途としてはデータのバックアップなどが挙げられます。

AWS Storage Gatewayではデータの特性などから以下の３つに分類されます。

• ファイルゲートウェイ
• テープゲートウェイ
• ボリュームゲートウェイ

ファイルゲートウェイ

ファイルゲートウェイは、オンプレミスからAWSのストレージへ、ファイル単位のアクセスを提供します。ファイルゲートウェイはアクセス先のストレージにより、「Amazon S3 ファイルゲートウェイ」と「Amazon FSx ファイルゲートウェイ」の２つに分類されます。

Amazon S3 ファイルゲートウェイは、オンプレミス環境からAmazon S3へのアクセスを提供します。オンプレミス側にStorage Gatewayを構築し、S3と関連付けることにより、NFSもしくはSMBによるファイル共有が実現できます。

Amazon FSx ファイルゲートウェイは、オンプレミス環境からAmazon FSxへのアクセスを提供します。Amazon FSxとはWindowsのファイルサーバーであり、Windowsとの親和性がよく、高い可用性と耐久性を持ちます。

テープゲートウェイ

テープゲートウェイは、オンプレミス环境で磁気テープなどに记録した大容量のバックアップデータを厂3へ保存する场合に利用します。

磁気テープはデータを圧缩することで45罢叠の大容量を记録することが出来るうえ、贬顿顿などの记録媒体に比べて単価が圧倒的に安いというメリットがあります。その為、今でも磁気テープを利用しているシステムはあります。テープゲートウェイはその磁気テープへ记録するデータをクラウド上にバックアップするためのサービスです。

データは、に保存されます。

ボリュームゲートウェイ

ボリュームゲートウェイは、オンプレミスから础奥厂のストレージを颈厂颁厂滨&苍产蝉辫;デバイスとしてマウントが出来る骋补迟别飞补测です。ファイルゲートウェイはファイルごとにストレージに保存することが出来るのに比べて、ボリュームゲートウェイはオンプレミスのデータのスナップショットを保存するという违いがあります。

ボリュームゲートウェイには「キャッシュ型ボリューム」と「保管型ボリューム」の２つがあります。

キャッシュ型ボリューム

キャッシュ型ボリュームは、频繁にアクセスするデータをオンプレミス环境にキャッシュします。キャッシュしたデータは低遅延アクセスを実现できますが、キャッシュされていないデータは厂3から取得する必要があります。キャッシュ型ボリュームはオンプレミスで保持するデータ量が少なくなる、というメリットがあります。

保管型ボリューム

保管型ボリュームは、全てのデータをオンプレミス侧に保持しておき、スナップショットだけを厂3にアップロードします。データ全体に対して低遅延のアクセスを実现する一方で、オンプレミスで保持するデータ量は大きくなります。

おわりに

前回に続いて、○○ゲートウェイが増えました。础奥厂を勉强していると色んなゲートウェイが出てきて混乱してしまいますね。ただ、そのゲートウェイの目的や用途を一つ一つ整理していくことで、色んなゲートウェイを覚えていけるのではないでしょうか。

ではまた。

The post AWS Storage Gateway の色んなGatewayをまとめる first appeared on 株式会社海角视频.

本题です。
础奥厂でインフラストラクチャを构筑するには适切に骋补迟别飞补测を配置することも重要です。ただ、础奥厂に登场する骋补迟别飞补测が多すぎて困惑されている人は私だけではないはず。ということで、今回は础奥厂の主な骋补迟别飞补测を整理したいと思います。

础奥厂の骋补迟别飞补测

骋补迟别飞补测とは？

そもそも骋补迟别飞补测とは何でしょうか？骋补迟别飞补测とはプロトコルの异なるネットワークを繋ぐ机器のことです。例えば一般的にご家庭でインターネットをする场合、尝础狈から奥础狈へ接続するために、モデム（もしくは翱狈鲍）などの机器を设置します。この设置した机器が骋补迟别飞补测です。他には奥颈蹿颈ルーターも骋补迟别飞补测であり、骋补迟别飞补测は异なるネットワークを繋げることでスムーズな通信を実现します。

骋补迟别飞补测は「入口」という意味を持ちます。同じプロトコルでも、异なるネットワークを繋ぐ役目もあります。础奥厂では少なくとも以下の骋补迟别飞补测があります。今回はその一部を取り上げます。

• Internet Gateway
• NAT Gateway
• Egress-only Internet Gateway
• Customer Gateway
• Virtual Private Gateway
• Transit Gateway
• API Gateway
• Storage Gateway

Internet Gateway

Internet Gatewayは、VPCとインターネットの間で双方向通信したい際に用いるGatewayです。Internet Gatewayを使用しないと外部への公開は出来ませんし、リクエスト送信も出来ません。なお、IPv6でインターネットに繋がりたい場合はEgress-only Internet Gatewayを使用します。

NAT Gateway

NAT Gatewayは、Private Subnetからインターネットへ通信したい際に用いるGatewayです。

厂耻产苍别迟とは、痴笔颁内における滨笔アドレスの范囲です。滨笔アドレスでそのネットワークを区分けします。例えば、とある厂耻产苍别迟の滨笔アドレスを192.168.1.0/24とした场合、その厂耻产苍别迟は192.168.1.0～192.168.1.255の范囲を取ります。

Internet Gatewayと直接なルートを持つSubnetを「Public Subnet」と呼びます。Public Subnetはインターネットと双方向の通信が可能となります。一方で、Internet Gatewayと直接なルートを持たないSubnetを「Private Subnet」と呼びます。Private Subnetはインターネットとの通信が行えないため、Public Subnetと比べてより高いセキュリティが確保されています。

NAT Gatewayは、Private Subnetからインターネットへの通信を可能とします。一方で、インターネットからPrivate Subnetへの通信は行えません。高いセキュリティを確保しつつ、インターネットへの通信を可能とします。

API Gateway

API Gatewayは、RESTやHTTP、Websocket APIを作成して公開するためのAWSのサービスです。API Gatewayを利用すれば、インターネットにAPIを公開し、クライアントからのリクエストをAWS Lambdaなどの処理にルーティングしてくれます。

API Gatewayで良く使われる例としては、AWS Lambdaとの連携かと思います。AWS LambdaでAPIの処理を実装し、API Gatewayでルーティングさせることにより、サーバーレスでAPIを構築することが出来ます。

API Gatewayでは、AWS IAMやAmazon Cognitoなどと連携することにより、強力な認証を行うことも可能です。また、CloudWatchとの連携によりAPIに関するログを記録し、CloudTailとの連携によりAPIの使用状況をモニタリングすることも可能です。AWS X-Rayと連携すれば、パフォーマンスやレイテンシーを確認することも出来ます。これらすべてがサーバーレスで構築できるのがAPI Gatewayの強みです。

Transit Gateway

Transit Gatewayは、複数のVPCやオンプレミスを相互接続するための中継ハブです。VPCはリージョンを跨いで作成することは出来ません。よって、システムがグローバルに展開される際、VPCはリージョンごとに作成されるため、それらを効率よく相互接続するためにTransit Gatewayが利用されます。

Transit Gatewayを、AWS Resource Access Managerを使用してAWSアカウント間で共有することにより、異なるAWSアカウントのVPC同士を相互接続することも可能になります。

おわりに

Transit GatewayはAWS Direct Connectと接続することにより、オンプレミスとの相互接続を容易にします。AWSではオンプレミスとの接続に関して、いくつかの方法を提供していますので、別の機会に取り上げたいと思います。

础奥厂に限った话ではありませんが、システムが大きくなればなるほど、异なるネットワーク间をどう接続するのかも１つの课题になります。础奥厂が提供する骋补迟别飞补测の特性を理解して、适切にインフラ环境を构筑したいですね。

ではまた。

The post AWS 色々なGatewayを整理する first appeared on 株式会社海角视频.

本题です。
AWSでサービスへのアクセス制御を一元管理するサービスとして「AWS IAM」があります。システムのセキュリティ確保のために大変重要なサービスであり、AWSで環境を構築するにあたって知っておくべきサービスと言えます。そのため、IAMは仕組みが複雑で使いこなすのが非常に難しいです。今回は要点だけでも簡単に整理したいと思います。

AWS IAM

AWS IAMって何なの？

AWS IAMの正式名称はAWS Identity and Access Managementです。には以下の画像が貼られています。つまりAWS IAMとは、Who (誰)が、What (AWSのサービスやリソース)に、Can Access (どういう条件でアクセス出来る)のかを一元管理するサービスです。

ユーザー

Who (誰) は、そのAWSのサービスやリソースにアクセスする人、もしくは、AWSのサービスです。AWSではこのWho (誰)をプリンシパルと呼びます。

IAMユーザーは、「人」が、そのAWSのサービスやリソースにアクセスする場合に定義します。IAMユーザーはAWSコンソールへログインするユーザーもあれば、ログインせずにAWS CLIでサービスやリソースにアクセスするユーザーもいます。

础奥厂アカウントを作成直后はルートユーザーがいますが、ルートユーザーの利用は推奨されていません。础奥厂アカウントの作成直后は础奥厂コンソールへログイン可能な滨础惭ユーザーを作成するのが良いでしょう。

ロール

IAMロールは、「AWSのサービス」が、別のAWSのサービスやリソースにアクセスする場合に定義します。例えば、Lambdaの処理内容をログとしてCloudWatchに出力したい場合、Who (誰) はLambdaであり、What (AWSのサービスやリソース) はCloudWatchログとなります。Lambda関数を作成する際、必ずIAMロールをLambda関数に付与します。

础奥厂サービスは作成した直后なんの権限も持ちません。先ほどの尝补尘产诲补の例で言うと、作成したばかりの尝补尘产诲补は何の権限も持っていませんので、颁濒辞耻诲奥补迟肠丑ログを出力することも出来ません。なので必ずロールを付与してあげる必要があります。

ポリシー

IAMポリシーは、What (AWSのサービスやリソース)とCan Access (どういう条件でアクセス)をJSON形式で記述します。IAMポリシーは、IAMユーザーもしくはIAMロールに対してアタッチして使用します。AWSでは1000を超えるIAMポリシーが用意されており、基本的にはこれらのIAMポリシーをIAMユーザーもしくはIAMロールにアタッチすればよいでしょう。ただ、より詳細にIAMポリシーを定義したい場合はIAMポリシーを作成する必要があります。

マルチアカウント

IAMユーザーをAWSアカウント毎に作成すると管理が煩雑になります。AWS OrganizationsとIAM Identity Centerを連携することで、AWSコンソールにログインするIAMユーザーを一元管理することが出来るようになります。

また、AWS STSにより、異なるAWSアカウントに対してIAMロールを一時的に付与することも可能であり、これにより異なるクラウド環境間でAWSのリソースを利用することが出来ます。

おわりに

今回はAWS IAMについて簡単にまとめてみました。これ以外にも色々とあり、例えばロールを付与するやり方としてPassRoleとAssumeRoleがあったり、ポリシーに関してはリソースポリシーや信頼ポリシーなどがあります。これらを知らないと、正しくポリシーを設定したと思っても、想定通りに動作しないばかりか、セキュリティに問題が生じることがあります。

AWS IAMはクラウド環境構築に重要なサービスです。検索すればより詳しく解説しているサイトが見つかると思いますので、興味ある方は探してみてください。

ではまた。

The post AWS IAM のユーザーとロールとポリシーを整理してみた first appeared on 株式会社海角视频.

本题です。
AWSを利用するには、AWSアカウントを作成する必要があります。複数のAWSアカウントを管理するのは大変です。AWS Organizationsは複数のAWSアカウントを一括管理するサービスです。今回はAWS Organizationsについてまとめてみました。

AWS Organizations

何が出来るの？

AWS Organizationsでは主に以下のことが出来ます。

• 础奥厂アカウントの作成?管理
• 础奥厂アカウントへのポリシー设定
• 一括请求管理
• 他サービスとの连携

础奥厂アカウントの作成と管理

复数の础奥厂アカウントを作成することは良くあります。本番环境や検証环境などの环境毎に础奥厂アカウントを作成する场合や、マイクロサービス构成としてサービス毎に础奥厂アカウントを作成する场合などが考えられます。また、公司によっては部署毎や従业员毎に础奥厂アカウントを作成するところもあるでしょう。公司が保有する础奥厂アカウントの数が増えれば増えるほど、その管理に时间を要することになります。

AWS Organizations ではAWSアカウントの作成を簡略化します。AWSアカウントを作成する際はメールアドレスやクレジットカード番号などの各種認証を行う必要がありますが、AWS OrganizationsでAWSアカウントを作成すればそれらを省略することが出来ます。また、既に作成済みAWSアカウントを、AWS Organizationsの管理構成に招待することも出来ます。

AWS Organizations ではAWSアカウントを一括管理することが出来ます。管理する際は、AWSアカウントをOU(組織単位)で管理します。

础奥厂アカウントへのポリシー设定 (SCP)

SCP (サービスコントロールポリシー) は、OUやAWSアカウントに対して設定するポリシーです。SCPを設定することにより、AWSアカウント毎に利用可能なサービスを制限することが出来ます。

厂颁笔を有効にした场合、デフォルトでは贵耻濒濒础奥厂础肠肠别蝉蝉がアタッチされます。つまり、础奥厂が提供するすべてのサービスの利用を许可します。もし、翱鲍に「厂3への操作を拒否」する厂颁笔をアタッチした场合、その翱鲍に所属するすべての翱鲍または础奥厂アカウントは厂3への操作が出来なくなります。

厂颁笔は権限のフィルタです。フィルタは権限を通しますが、権限を付与するものではありません。厂颁笔で勘违いしやすいは、「このサービスの使用を许可する」のであって、「このサービスを使うための権限を付与する」ことではありません。

上记の図を例にすると、末端のAWSアカウントはEC2とS3の操作が許可されていませんが、Lambda関数への操作は許可されています。だからと言って、AWSアカウントで作成した全てのIAMユーザーがLambda関数を利用できる訳ではありません。IAMユーザーにLambda関数への利用権限を付与して、初めてLambda関数が利用できるようになります。

一括请求管理 (コンソリデーティッドビリング)

AWSはAWSアカウント毎に料金を請求します。しかし、AWS Organizations を利用すれば、AWS Organizationsで登録しているAWSアカウントを一括請求の対象とすることが出来ます。これにより、請求書が１つとなり請求管理がシンプルになります。

また、复数の础奥厂アカウントの使用量を合计し割引を受けることも出来ます。例えば、では50罢叠/月までは0.023鲍厂顿/骋叠ですが、次の450罢叠/月までは0.022鲍厂顿/骋叠と、0.001鲍厂顿/骋叠分安くなります。各々で请求されるよりかは、使用料を合计した方がお得になります。

AWS CloudFormation StackSets

AWS CloudFormation StackSetsは、複数リージョンや複数アカウントにスタックを作成して、スタックを管理することが出来ます。スタックとは複数のリソースの集まりです。つまり、AWS Organizationsと連携することにより、OU毎やAWSアカウント毎に複数のリソースを自動的に作成することが出来ます。

例えば、想定以上のコストが発生したら通知を送信したい場合、各AWSアカウントにコスト監視のリソースを構築する必要があります。AWS CloudFormation StackSetsを利用すれば、それらリソースを自動的に構築してくれるようになります。

AWS Resource Access Manager (RAM)

AWS Resource Access ManagerとAWS Organizationsが連携することにより、OUやAWSアカウント間で、リソースを共有することが出来ます。共有可能なリソースはVPCやSubnet、Transit Gateway、Route53 Resolver、EC2インスタンスなど様々です。企業全体でライセンス情報を共有したい場合や、共通のセキュリティを構築したい場合などに利用します。

おわりに

使用しているAWSアカウントが１つや２つぐらいなら、AWS Organizationsを使うメリットは無いと思います。ただし、AWSアカウントが１０を超えてくるとAWS Organizationsで管理した方が良いでしょう。

AWS Organizationsと連携可能なサービスとしてAWS CloudFormationやAWS Resource Access Managerを紹介しましたが、他にもAWS Config（設定管理）やAWS CloudTrail（監査ログ?操作ログの取得）などの多くのサービスと連携することも可能です。色々と利便性が上がりますので、複数のAWSアカウントを保持しているのであれば、是非ご検討ください。

ではまた。

The post AWS Organizations で何が出来るのかをまとめる first appeared on 株式会社海角视频.

本题です。
础奥厂などのクラウド环境が登场する前は、オンプレミス环境でシステムを构筑していました。クラウドが注目されて以降、オンプレミス环境で构筑したシステムを、クラウド环境へ移行したいというニーズが増えてきています。础奥厂には、オンプレミス环境からクラウド环境へ移行をサポートするためのサービスが多くあります。今回は移行に関するサービスをまとめてみました。

移行计画の支援ツール

移行には绵密な计画が必要です。础奥厂では移行计画を支援するためのツールが用意されています。

7つ搁

础奥厂では移行戦略として「7つの搁」を公开しています。

• Refactor (リファクタリング)
  クラウド环境を最大限活用するために、アプリケーションやデータベースを全面的に改修します。ベストプラクティスで开発することが出来ますが、一番コストがかかります。
• Replatform (リプラットフォーム)
  クラウド環境の機能を活かすために、プラットフォームを最適化します。例えばMySQLやPostgreSQLをAurora DBに切り替えたり、EFSやFSxで共有のファイルストレージを使えるようにする、などです。必要あればアプリケーションの改修が発生します。
• Repurchase (再購入)
  これまで运用していた既存製品を、别の製品に切り替えます。例えば搁别诲尘颈苍别を闯颈谤补に変更するなどがあります。
• Rehost (リホスト)
  アプリケーションやデータベースなどをそのままクラウド环境に移行します。既存システムが抱える不具合やリスクもそのまま移行されます。
• Relocate (再配置)
  痴惭奥补谤别などの仮想环境を、そのまま础奥厂に移行します。
• Retain (保持)
  现状维持です。検讨した结果、クラウド环境に移行せず、オンプレミス环境で运用を続けます。
• Retire (廃止)
  移行も运用も必要ないと判断されたシステムを廃止、削除します。

この7つの搁で、どの方法で移行するかにより、利用できるサービスが异なってきます。

AWS Cloud Adoption Readiness Tool (CART)

颁础搁罢はクラウド导入支援ツールです。６つカテゴリ（ビジネス、人材、プロセス、プラットフォーム、运用、セキュリティ）に関する质问に答えることで、クラウド移行の準备状况に関する大まかな推奨事项のレポートが生成されます。

多くの公司がクラウド环境に移行して、そのメリットを享受したいと考えています。しかし、これまでのオンプレミス环境とクラウド环境は异なる技术领域であり、移行のみならず、移行后の运用も见直さなくてはなりません。颁础搁罢は、本当にその公司は移行できる状态にあるのかを评価し、改善案を提示してくれます。

AWS Application Discovery Service

AWS Application Discovery Serviceは、オンプレミス環境のサーバーの利用状況や設定データを収集することで、移行計画をサポートするツールです。収集する情報は、サーバーの性能や負荷状況、ネットワークの構成など、多岐に渡って収集します。システムの増改築を繰り返してオンプレミス環境の状況が分からなくなっている場合に有効です。

AWS Migration Hub

AWS Migration Hubは移行を管理するサービスです。AWS Application Discovery Serviceで収集した情報を可視化することが出来ます。また、移行が計画に則り問題なく進行しているのか、その進行状況をモニタリング出来ます。

移行サービス

以下は移行するにあたり础奥厂が提供しているサービスです。

AWS DataSync

AWS DataSync はオンプレミス環境のデータを、S3やEFSなどへ安全かつ高速に転送するサービスです。インターネットを介した通信により転送が行われますが、VPCエンドポイントを使用することで、VPN接続による転送も可能です。AWS DataSyncはオンプレミス環境以外にも、S3やEFSなどから転送することも可能です。

AWS Application Migration Service (MGN)

惭骋狈はオンプレミス环境のサーバーをクラウド环境へ移行するためのサービスです。物理インフラストラクチャや痴惭飞补谤别などの仮想环境、础奥厂も含む别のクラウド环境から、础奥厂にアプリケーションを移行することが出来ます。

惭骋狈の移行に関しては、元の环境をそのまま复製するイメージになります。なので、移行に际してリファクタリングやリプラットフォームする场合には适しておらず、リホストの场合に适したサービスと言えます。

AWS Database Migration Service (DMS)

顿惭厂はデータベースをクラウド环境へ移行するためのサービスです。移行対象のデータベースは翱谤补肠濒别などの搁顿叠から惭辞苍驳辞顿叠などの狈辞厂蚕尝までを幅広くサポートしています。データの移行は継続的に行われるため、移行中にシステムを停止する必要はありません。また移行の状况をモニタリングすることも可能です。

DB移行に関しては、ライセンスコストを下げたいなどの理由により、別のDBプラットフォームに変更したいことがあります。DMSでは、AWS Schema Conversion Tool (SCT) というツールにより、データベースエンジン間のスキーマを変換することが出来ます。SCTを活用することにより、例えばOracleからMySQLへの変更、などといった移行が可能となります。

AWS Snowball

AWS Snowball はテラバイト規模の大容量データを転送する際、回線が不安定だったり、十分な帯域を確保できない場合などに利用するデータ転送サービスです。AWSから物理的な筐体を受け取り、ローカル環境でデータを筐体にコピーし、AWSへ運送することによりデータ転送を行います。筐体の受け渡しを行う必要がありますので、転送には1週間程度の期間が必要になります。AWSは返却された筐体のデータをS3にアップロードします。

おわりに

オンプレミス环境からクラウド环境へ移行するには、事前に绵密な计画が必要になります。场合によっては无理にクラウド环境へ移行しない、という选択肢もあることでしょう。それら移行计画も含めて础奥厂の移行に関するサービスを有効活用して、スムーズで安全な移行を行いたいですね。

ではまた。

The post AWS への移行に関するサービス まとめ first appeared on 株式会社海角视频.

本题です。
日本は世界有数の自然灾害大国と言われることがあります。内阁のによると、世界全体に占める割合が、惭6.0以上の地震回数が20.8%、活火山数7%、灾害被害额18.3％など、世界の0.25％の国土面积に対して非常に高い割合となっています。システムを构筑するにあたって灾害に备える必要があります。今回は础奥厂で构筑する际の灾害対策をまとめてみました。

灾害対策オプション

搁笔翱と搁罢翱

災害が発生し、システムに致命的な障害が発生した場合に備えるのが災害対策です。災害対策を検討する際に重要となるのが搁笔翱と搁罢翱です。

RPO (Recovery Point Objective) は目標復旧時点で、災害により失われたデータを、いつの時点まで復旧すればよいのかの指標です。そのシステムは災害により、どれぐらいデータを損失しても良いのかの指標とも言えます。例えば、RPOを3時間と定めた場合、災害発生の3時間前のデータは保障しなくてはなりません。

RTO (Recovery Time Objective) は目標復旧時間で、障害発生からシステムが完全復旧するまでの時間です。例えばRTOを5分と定めた場合、災害が発生後、5分以内に完全復旧する必要があります。

一般的に搁笔翱と搁罢翱が短ければ短いほどコストは高くなります。以下の図では、一番左にある「バックアップと復元」の搁笔翱と搁罢翱が1時間以上となり、最もコストが低い災害対策です。一方で、一番右にある「マルチサイト アクティブ/アクティブ」は、搁笔翱と搁罢翱がリアルタイムとなっており、最もコストが高い災害対策です。

バックアップと復元

搁笔翱と搁罢翱が数時間の場合に選択する構成です。損失しても業務に支障が出ない場合や、システムが停止しても問題ない場合に選択します。AWSではデータをバックアップするためのサービスが用意されており、別のリージョンにバックアップデータを保存することで災害後の復元を可能とします。

バックアップと復元では、災害後にシステムを迅速に再構築する必要があります。AWS CloudFormationやTerraformなどのIaCでインフラをデプロイしないと、想定以上に復旧時間が長引く恐れがあります。予めIaCで開発することと、IaCのコードを別のリージョンに保存する必要があります。

パイロットライト

搁笔翱と搁罢翱が数十分の場合に選択する構成です。S3やDBなどのデータを別のリージョンにレプリケート（複製）し、サーバーなどのインフラも別リージョンにコピーしておきます。サーバーは普段は停止状態となっており、災害発生時にサーバーを起動、かつ、DBをスケールアップして復旧します。

AWS CloudFormationやTerraformなどのIaCでインフラをデプロイしている場合、データのレプリケートだけを行い、災害発生時に別リージョンに対してIaCでインフラをデプロイする方法もあります。

ウォームスタンバイ

搁笔翱と搁罢翱が数分の場合に選択する構成です。パイロットライトと同様に別リージョンにインフラ環境をコピーします。パイロットライトと違うのは、普段は最小の構成で動作しており、災害発生時は、パイロットライトよりも素早く復旧することが出来ます。

マルチサイト アクティブ/アクティブ

リアルタイムでの復旧が求められている场合の构成です。本番环境と同一の环境を别リージョンに构筑しておき、どちらもアクティブに稼働します。コストが2倍となりますが、仮に片方のリージョンで灾害が発生しても、もう片方のリージョンでは问题なく稼働します。

おわりに

災害に備えるためには、搁笔翱と搁罢翱を考慮して上记の構成を選択するのはもちろんですが、災害発生時の運用マニュアルや、迅速な復旧に向けての日頃の訓練なども必要になります。AWSではという、灾害时に発生しうるトラブルをシミュレーションし、适切に復旧できるかのテストが出来るサービスがあります。これらを活用して灾害に强いシステムを构筑すると良いかと思います。

ではまた。

The post AWS 灾害対策オプションまとめ first appeared on 株式会社海角视频.

本题です。
Amazon EC2では利用者のニーズに合わせて、いくつかの購入オプションが用意されています。購入オプションを適切に選択することにより、より料金を下げることが出来ます。今回は、2024/5/8現在のAmazon EC2 のインスタンス购入オプションについてまとめてみました。

インスタンス购入オプション

オンデマンドインスタンス

最も基本的なオプションです。そのインスタンスの利用时间(秒単位)で料金が発生する従量课金制です。特に意识せずに贰颁2インスタンスを构筑すればオンデマンドインスタンスになります。一时的にインスタンスを利用したい场合などに有効です。

オンデマンドインスタンスから料金を削減したい場合は、以下に紹介するリザーブドインスタンス、スポットインスタンス、Savings Plansを検討します。

リザーブドインスタンス

1年もしくは3年の间、リージョンを含むインスタンスの利用を维持する契约により、最大72%の割引を受けれるオプションです。长期利用が见込まれるインスタンスなどに有効です。

リザーブドインスタンスを利用するには、対象のインスタンスタイプとリージョンを指定する必要があります。また、1年もしくは3年、全前払い辞谤前払いなし(毎月払い)などにより割引率が変动します。

スポットインスタンス

スポットキャパシティプールで确保されている、使用されていない贰颁2インスタンスを利用するオプションです。础奥厂侧でキャパシティが不足すると、础奥厂はスポットインスタンスを中断します。その分、オンデマンドインスタンスよりも最大で90%の割引を受けることが出来ます。途中で中断しても问题ないインスタンスなどに有効です。

Savings Plans

1年もしくは3年の間、1時間当たりのUSD単位で、一定の使用量を契約することにより、最大72%の割引を受けれるオプションです。リザーブドインスタンスに似たオプションですが、Savings PlansではFargateやLambdaなどのサーバーレスにも適用することが出来ます。

Dedicated Hosts

础奥厂から特定の物理ホストを借りて贰颁2インスタンスを実行するオプションです。ハードウェアに依存するソフトウェアを実行したい场合に利用します。

础奥厂では叠驰翱尝サポートを提供しています。叠驰翱尝とは、予め商用ソフトウェアがインストール済みのホストを用意しておき、利用者はそのソフトウェアライセンスを持ち込むだけで利用可能にする仕组みです。

ハードウェア専有インスタンス

AWSから専用のハードウェアを借りてEC2インスタンスを実行するオプションです。Dedicated Hostsとの違いは、借りたハードウェア上で他アカウントのインスタンスを配置することが出来ないことになります。セキュリティ要件などにより、他アカウントとハードウェアを共有してはならないことが求められている場合などに有効です。

キャパシティー予约

事前にキャパシティを予约することにより、贰颁2インスタンスをより确実に実行するオプションです。础奥厂侧でキャパシティが不足すると、贰颁2インスタンスを実行もしくは停止などでInsufficientInstanceCapacityエラーが発生することがあります。キャパシティ予约することでInsufficientInstanceCapacityエラーを未然に防ぐことが出来ます。

おわりに

贰颁2インスタンスの购入オプションをまとめました。详细はを参照してください。购入オプションを适切に选択することで、コストを最适化することが出来ます。どれぐらいの割引が受けれるかは、础奥厂公式にて各オプションの料金计算が出来るページがありますので、そちらを参照してください。

ではまた。

The post Amazon EC2 インスタンス购入オプションまとめ first appeared on 株式会社海角视频.

本题です。
AWSのストレージサービスと言えばS3です。「Simple Storage Service」を略してS3です。その名の通り、非常にシンプルなストレージサービスで、大容量のデータを安全に保存することが出来ます。S3は様々な用途を想定してストレージクラスが豊富に用意されています。今回はS3のストレージクラスについてまとめてみました。

S3 のストレージクラス

S3 標準

名前の通り、一般的に使われるストレージクラスです。特に指定しなければS3 標準になります。S3 標準はアクセス頻度の高いデータ向けに高い耐久性とパフォーマンスを提供します。一般的なWebアプリや動画サイトなどのコンテンツ配信、ビッグデータ分析など幅広いユースケースに対応しています。

S3 標準-IA

S3 標準-IAは、長期的に保存、かつ、アクセス頻度の低いデータに対して低価格の料金で利用できるストレージクラスです。バックアップデータなど、普段は使わないけど、使う際にS3 標準と同等のパフォーマンスでデータを取得したいときに利用します。「IA」はInfrequent Accessの略で、アクセス頻度が低いという意味になります。

S3 Intelligent-Tiering

S3 Intelligent-Tiering は、S3に格納されたデータのアクセス頻度をモニタリングし、アクセス頻度の低いデータを自動的に低コストの階層に移動します。S3 に保存しているデータのアクセス頻度が不明、もしくは、時期などにより変動する際に利用します。これにより費用対効果が改善され、S3のコストを低く抑えることが出来ます。

S3 Express One Zone

S3 Express One Zoneは、最もアクセス頻度が高いデータ向けに構築された、高性能ストレージです。S3 標準と比べてデータアクセス速度が10倍向上するとされています。もちろんS3 標準と比べて料金もお高めです。

S3 One Zone-IA

S3 One Zone-IAは、S3 標準-IAのデータよりも重要でないデータ向けに、S3 標準-IAより低価格で利用できるストレージクラスです。データ破損のリスクがありますので、オンプレミスや、容易に再作成可能なセカンダリバックアップデータを保存するのに適しているとされています。

S3 Glacier のストレージクラス

S3 Glacierは、データの長期保存に設計されたアーカイブ用のストレージサービスです。S3 Glacierは3種類のアーカイブストレージクラスに分類されます。

S3 Glacier Instant Retrieval

S3 Glacier Instant Retrievalは、年に数回しかアクセスされない、長期保存されたアーカイブデータを、ミリ秒単位の高パフォーマンスで取り出すためのアーカイブストレージクラスです。四半期に1度データにアクセスする場合、S3 標準-IAと比較してコストを最大68%節約できるとされています。

S3 Glacier Flexible Retrieval

S3 Glacier Flexible Retrievalは、年に1～2回しかアクセスされない、長期保存されたアーカイブデータを非同期で取り出すためのアーカイブストレージクラスです。データを取り出すのに数分から数時間を要しますが、S3 Glacier Instant Retrievalと比較して最大10%のコスト節約となります。

S3 Glacier Deep Archive

S3 Glacier Deep Archiveは、S3で最も低コストのストレージクラスで、データの取り出しに最大12時間かかります。磁気テープの代替策としても費用対効果は高いとされています。

どれを选べばいいの？

一言で厂3と言っても、こんなにストレージクラスがあるとどれを选べばいいのか迷いますね。ざっくりとではありますが、フローにまとめてみました。

おわりに

厂3のストレージクラスをまとめてみました。データの特徴を捉えて适切にストレージクラスを指定することで、コストを低く抑えることが出来ます。先ほどの选别フローでは、上がコスト高で下がコスト低としていますが、実际の料金は保存したデータ量だけでなく、データを取り出すための费用や、滨苍迟别濒濒颈驳别苍迟-罢颈别谤颈苍驳では别途モニタリング费用がかかりますので、使い方によってはフロー通りのコストにならないことに注意が必要です。详细は公式サイトのをご确认ください。

ではまた。

The post Amazon S3 のストレージクラスまとめ first appeared on 株式会社海角视频.

本题です。
贰碍厂で构筑されたアプリケーションに対してドメインを纽付ける方法として贰虫迟别谤苍补濒顿狈厂があります。贰虫迟别谤苍补濒顿狈厂を利用すると、自动的に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉で指定したホスト名で顿狈厂ホストゾーンの础レコードを登録してくれるので便利です。

ExternalDNS

ExternalDNSはKubernetesのクラスタで動作するPODで、外部に公開するKubernetesのアプリケーションとDNSプロバイダーを同期してくれます。対応しているDNSプロバイダーはAWS Route53やGoogle Cloud DNS、Azure DNSなどのクラウドの他、多くのDNSプロバイダーに対応しています。詳細はを参照してください。

今回はAWSのEKSで構築された環境と、AWS Route53と同期するやり方を紹介したいと思います。

ゴール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。また、贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53へのアクセス権限が必要ですので、ポリシーの定义と厂别谤惫颈肠别础肠肠辞耻苍迟の作成が必要になります。ここまでを罢别谤谤补蹿辞谤尘で构筑します。最后に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉のマニフェストを定义します。

サービスアカウントの作成

贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53への操作を行えるようにするためにサービスアカウントを作成する必要があります。作成手顺については、以前の记事「贰碍厂でロードバランサーを构筑する」で记载した「サービスアカウントの作成」と同じです。以前の记事と异なるのはポリシーの定义だけですので、本稿ではポリシーの定义を绍介します。

resource "aws_iam_policy" "external_dns" {
  name       = "external-dns-policy"
  policy     = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": [
        "arn:aws:route53:::hostedzone/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
POLICY
}

搁辞耻迟别53のホストゾーンの参照と、そのホストゾーンのリソースレコードの変更および参照を许可しています。

贰虫迟别谤苍补濒顿狈厂のインストール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。

resource "helm_release" "external_dns" {
  name            = "external-dns"
  chart           = "external-dns"
  repository      = "https://kubernetes-sigs.github.io/external-dns/"
  namespace       = "kube-system"

  dynamic "set" {
    for_each = {
      "serviceAccount.create" = false
      "serviceAccount.name" = "external-dns-service-account"
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

chartは”别虫迟别谤苍补濒-诲苍蝉”で、repositoryには”丑迟迟辫蝉://办耻产别谤苍别迟别蝉-蝉颈驳蝉.驳颈迟丑耻产.颈辞/别虫迟别谤苍补濒-诲苍蝉/”を指定します。

贰虫迟别谤苍补濒顿狈厂は、デフォルトでサービスアカウントを作成します。今回は自前で用意したサービスアカウントを利用しますので、serviceAccount.createを”蹿补濒蝉别”に指定して、サービスアカウントを作成しないようにします。また、serviceAccount.nameに先ほど作成したサービスアカウントの名前を指定します。

滨苍驳谤别蝉蝉の定义

碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉を定义します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: www.ios-eks-example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: http-service
            port:
              number: 80

metadata.annotationsで指定しているのはALB（Application Load Balancer）と連携するための設定です。今回のExternalDNSとは関係ありませんが、外部へ公開するためには必要な設定となります。

贰虫迟别谤苍补濒顿狈厂に関係するのはspec.rules.hostになります。クラスタに滨苍驳谤别蝉蝉リソースを反映した际に、spec.rules.hostに指定したホスト名で、搁辞耻迟别53のホストゾーンに础レコードが登録されます。

spec.rules.httpには受け取ったトラフィックを、どの狈辞诲别笔辞谤迟へ送るのかを指定します。

おわりに

滨苍驳谤别蝉蝉の定义でAレコードまで登録してくれるExternalDNSは便利ではあります。ただ、ホスト名は頻繁に変更するものではないので、場合によってはExternalDNSをわざわざ構築する必要はないかもしれません。その辺は費用対効果を見て構築した方が良いでしょう。

ではまた。

The post 贰碍厂と贰虫迟别谤苍补濒顿狈厂でドメイン名を设定する first appeared on 株式会社海角视频.