AWSが2006年のサービス開始から現在まで、どのような順序でサービスを拡充してきたかを時系列で整理する。基本インフラから始まり、企業向けの高度なサービス、そして業界特化型サービスへと発展していく流れが見えてくる。
サービス年表 2006年〜2019年にリリース
| 年 | サービス名 | 備考 |
|---|---|---|
| 2006 | Amazon S3 | オブジェクトストレージ。イレブンナインの耐久性で複数AZに自動複製 |
| 2006 | Amazon EC2 | 仮想サーバーをオンデマンドで借りられるクラウドコンピューティングの原点 |
| 2008 | Amazon CloudFront | CDN。世界中のエッジロケーションにコンテンツをキャッシュ配信 |
| 2009 | Amazon RDS | マネージドリレーショナルデータベース |
| 2009 | Amazon VPC | 仮想プライベートネットワーク。AWS内に専用ネットワーク空間を構築 |
| 2009 | AWS Auto Scaling | 負荷に応じてEC2台数を自動増減 |
| 2009 | Elastic Load Balancing (ELB) | 複数インスタンスへの負荷分散 |
| 2010 | Amazon Route53 | マネージドDNSサービス |
| 2011 | AWS IAM | ユーザー・権限管理。アカウント使い回しからの脱却 |
| 2012 | Amazon DynamoDB | フルマネージドNoSQLデータベース |
| 2013 | Amazon Redshift | 列指向のデータウェアハウス。大規模分析専用DB |
| 2013 | AWS CloudHSM | 専用ハードウェアによる暗号鍵管理 |
| 2014 | AWS Lambda | サーバーレスコンピューティング |
| 2014 | Amazon ECS | Dockerコンテナのオーケストレーション |
| 2015 | Amazon EMR | Hadoop/Sparkによるビッグデータ分析基盤 |
| 2015 | AWS Snowball | 物理デバイスによる大容量データ移行 |
| 2015 | AWS WAF | Webアプリケーションファイアウォール |
| 2015 | AWS IoT | IoTデバイスとの通信基盤 |
| 2016 | Amazon Pinpoint | プッシュ通知・メール等のマーケティング配信基盤 |
| 2016 | Amazon Rekognition | 画像・動画認識AI |
| 2016 | Amazon GameLift | オンラインゲームサーバーのホスティング・マッチメイキング |
| 2017 | Amazon Connect | クラウド型コンタクトセンター構築サービス |
| 2017 | Amazon SageMaker | 機械学習モデルの構築・学習・デプロイ基盤 |
| 2017 | AWS Cloud9 | ブラウザ上で動作するクラウドIDE(新規提供は終了) |
| 2017 | AWS Media Services | 動画配信インフラ一式 |
| 2018 | AWS AppSync | GraphQL APIのマネージドサービス |
| 2018 | AWS RoboMaker | ロボット向けソフトウェアの開発・シミュレーション(新規申込終了) |
| 2019 | AWS Ground Station | 人工衛星との地上局通信サービス |
| 2019 | Amazon Managed Blockchain | ブロックチェーンネットワークの構築・運用 |
サービス年表 2020年〜2026年にリリース
| 年 | サービス名 | 備考 |
|---|---|---|
| 2020 | Amazon AppFlow | SaaS間のデータ連携サービス |
| 2020 | Amazon Kendra | 機械学習ベースのエンタープライズ検索 |
| 2020 | Amazon Honeycode | ノーコードでWeb/モバイルアプリ構築 |
| 2021 | Amazon MemoryDB for Redis |
Redis互換のフルマネージドインメモリDB |
| 2021 | AWS Wavelength | 5G向け超低遅延コンピューティング |
| 2021 | AWS re:Post | AWSコミュニティQ&Aプラットフォーム |
| 2022 | Amazon EC2 Trn1 (Trainium) |
AI学習向け専用チップインスタンス |
| 2022 | AWS App Runner | コンテナ/コードから即座にWebアプリをデプロイ |
| 2022 | Amazon Redshift Serverless | サーバー管理不要の分析基盤 |
| 2022 | Amazon EMR Serverless | クラスタ管理不要のSpark/Hive実行環境 |
| 2022 | Amazon CodeWhisperer | AIコード補完(2024年にAmazon Q Developerへ改称) |
| 2022 | AWS Cloud WAN | グローバルWAN構築・管理 |
| 2023 | Amazon Bedrock | 生成AI基盤モデルを単一APIで利用できるサービス |
| 2023 | AWS Supply Chain | AI活用のサプライチェーン管理 |
| 2023 | Amazon Security Lake | セキュリティデータをOCSF形式で一元化 |
| 2023 | AWS Verified Access | VPN不要のゼロトラストアクセス |
| 2023 | Amazon Verified Permissions |
Cedarポリシー言語による認可管理 |
| 2024 | Amazon Q(→Q Developer) | 生成AIによる開発・運用アシスタント |
| 2024 | AWS Deadline Cloud | 映像・VFX向けマネージドレンダーファーム |
| 2024 | AWS App Studio | 自然言語でエンタープライズアプリ構築 |
| 2024 | Amazon Nova | AWS独自の基盤モデル群 |
| 2024 | Amazon S3 Tables | Apache Iceberg対応の分析特化オブジェクトストア |
| 2025 | Amazon Aurora DSQL | サーバーレス分散SQL、常時アクティブ構成 |
| 2025 | AWS Transform | メインフレーム/VMware/.NETのAIモダナイゼーション |
| 2025 | Amazon Bedrock AgentCore | AIエージェント構築・運用基盤 |
| 2025 | Kiro | 仕様駆動のエージェント型AI開発ツール |
| 2026 | Bedrock Fully Managed Knowledge Bases | エンタープライズRAGパイプライン構築の簡素化 |
2020年代は明らかに生成AI・エージェント系がメインの流れ。EC2/S3的な基本インフラの時代はとっくに終わって、今はAIをどう組み込むかの勝負になってる。
基本インフラ編(2006〜2011)
Amazon S3 - オブジェクトストレージ
S3は2006年3月にローンチした、AWSの中でも最古参のサービスである。通常のファイルシステムとは根本的に構造が異なり、ディレクトリ階層を持たず「バケット」の中に「オブジェクト」を置くだけのシンプルな構造になっている。アクセスはHTTP(S)のAPI経由で行われ、ローカルディスクのように直接マウントして使うものではない。
最大の特徴は耐久性の高さである。1つのオブジェクトを保存すると、裏側で最低3つのアベイラビリティーゾーン(物理的に離れたデータセンター)に自動でコピーされる。この地理的に離れた拠点間でのリアルタイム同期こそがS3の本質であり、1990年代のRAID HDDのような「1箇所に固めた冗長化」とは強度がまったく異なる。1つの建物が災害で失われても、他の拠点のコピーが生き残る設計になっている。
料金は保存量(ストレージ)と転送量(データ転送)の両方で発生する。保存料金自体は比較的安定して安いが、転送量は使われ方次第で青天井に跳ね上がる。動画配信のような大量アクセスがあるサービスでは、転送料金が主要コストになりやすい点には注意が必要である。
なお「1PBを一気にアップロードしたら破綻するのでは」という懸念については、AWS全体で数百万台規模のサーバーとエクサバイト級のストレージを常時運用しているため問題にならない。データは水平分散で書き込まれ、そもそもネットワーク帯域の制約により一瞬でのアップロードは物理的に不可能である。
Amazon EC2 - 仮想サーバー
EC2はS3の数ヶ月後、2006年8月にベータ版としてリリースされた。それまでは「サーバーが欲しければ機材を買って納品を待つ」のが常識だったIT業界において、EC2は「ブラウザでクリックすれば数分でサーバーが起動し、使った分だけ課金される」という仕組みに変えた。
元々はAmazon社内の、セール時のアクセス急増と平常時の余剰リソースという課題を解決するために作られたシステムが原型になっている。この社内インフラを外販したのがAWSの始まりである。
Amazon CloudFront - CDN
CloudFrontは2008年に開始されたCDN(コンテンツ配信ネットワーク)である。S3などのオリジンに置かれたデータを、世界中の「エッジロケーション」というキャッシュ拠点に複製配置し、ユーザーからのアクセスに対して最も近い拠点から返す仕組みになっている。
厳密にはエッジコンピューティングそのものではない。CloudFront単体が行っているのは「キャッシュの配信」であり、データの計算処理までは行わない。後年追加された「Lambda@Edge」や「CloudFront Functions」によって、エッジ拠点でのコード実行が可能になり、ここで初めて本来の意味でのエッジコンピューティングの領域に踏み込んでいる。
Amazon RDS / VPC - 企業利用の土台
RDSとVPCはともに2009年、EC2/S3の3年後にリリースされた。この時間差は、企業が本番環境として安心してAWSを使えるようになるまでの助走期間だったと考えられる。
RDSはそれまでEC2上に自前でMySQLを構築し、バックアップやパッチ適用、レプリケーションをすべて手動で行っていた運用を、クリック一つで完結するマネージドサービスに変えた。
VPCはAWS内に自分専用の仮想ネットワークを構築できる機能である。IPアドレス帯やサブネットを自由に設計できるほか、複数アカウント・複数VPC間でもインターネットを経由せずAWS内部のネットワークだけで接続する「VPCピアリング」「Transit Gateway」といった仕組みも存在する。VPC登場以前のEC2は基本的にフラットなネットワークに置かれており、ネットワーク分離が今ほど柔軟ではなかった。企業がAWSへ本格移行するための生命線となった機能である。
AWS Auto Scaling / ELB - 負荷対応の両輪
Auto Scalingは2009年に登場した、負荷に応じてEC2の台数を自動増減させる仕組みである。CPU使用率などの指標を見て、設定した閾値を超えると自動でスケールする。
ELB(Elastic Load Balancing)は複数のEC2インスタンスへアクセスを振り分ける負荷分散の仕組みである。Auto Scalingと必ずセットで機能し、Auto Scalingが台数を増減させ、ELBがその台数に対して負荷を適切に分配する、という役割分担になっている。
ELB自体は固定のDNS名(CNAME)を持っており、裏側のEC2インスタンスの実体(IPアドレス)が増減してもユーザー側から見るDNS名は変わらない。そのためDNSレコードを都度書き換える必要はない。
Amazon Route53 - DNS
Route53は2010年に開始されたマネージドDNSサービスである。ELB単体であればDNS書き換えは不要だが、独自ドメインとELBの紐付けや、複数リージョンへのルーティング、ヘルスチェック連動の自動フェイルオーバーといった、より大きな仕組みを実現するためにAWSは自社でDNS事業を持つに至った。
なお通常のCNAMEレコードはRFC仕様上、wwwなしのApexドメイン(ゾーンの頂点)には使用できない制約がある。Route53はこれを独自拡張の「ALIASレコード」で解決しており、Apexドメインでも直接ELBやCloudFrontに紐付けることができる。
AWS IAM - 権限管理
IAMは2011年、EC2/S3から実に5年後にリリースされた。それ以前はアカウントを社内で使い回すのが実質唯一の運用方法であり、誰が何をしたかの区別がつかず、退職者が出るたびにパスワードを全員分変更する必要があるなど、危うい運用が常態化していた。IAM登場によって、ユーザーごとの個別アカウント発行と、操作単位での細かい権限設定が可能になった。
データベース・分析編
Amazon DynamoDB - NoSQLデータベース
DynamoDBは2012年にリリースされたフルマネージドNoSQLデータベースである。RDB(RDS)がテーブル・行・列でスキーマを厳密に定義し、JOINを含む複雑なクエリを得意とするのに対し、DynamoDBはスキーマレスで、あらかじめ決めたキーによる一発検索に特化している。複雑な条件検索は苦手だが、その分水平方向に無限にスケールし、アクセス集中時にも強い。
用途としては「決まったキーで大量アクセスを高速に捌きたい」場面に向いており、ECサイトのセッション管理、ゲームのスコアボード、IoTセンサーログなど、大企業サービスの裏側で広く使われている。判断基準はレコード件数の多寡そのものよりも、アクセスパターン(複雑な集計が必要か、単純な高速アクセスが必要か)に置くべきである。
Amazon Redshift - データウェアハウス
Redshiftは2013年に登場したデータウェアハウスである。RDSが日々のトランザクション処理(注文登録や在庫更新など)向けの行指向ストレージであるのに対し、Redshiftは列指向ストレージを採用し、複数ノードで並列にクエリを処理するMPP方式を取っている。「過去5年分の売上データから傾向を分析する」といった、テーブルを横断する大量データの集計に特化した設計である。
単純に「RDBをもう1つ立てる」のでは代替できない。行指向と列指向という根本的なストレージ構造の違いと、並列分散処理の有無が決定的な差になる。
Amazon EMR - ビッグデータ分析基盤
EMRは2015年にリリースされた、HadoopやSparkを利用したビッグデータ処理基盤である。CloudWatchのような稼働監視ツールとは異なり、「蓄積した大量データをバッチで集計・分析する」ことが役割である。生データのままでも処理可能だが、Parquet/ORCといった列指向フォーマットへの変換やパーティション分割を行うことで、処理速度とコストが大きく改善する。
主にEC・広告・金融・IoTなど、TB〜PB級のデータを定期的に一括処理する必要がある法人利用が中心であり、個人利用や小規模サービスでの出番は基本的にない。
セキュリティ編
AWS CloudHSM - 専用ハードウェアによる鍵管理
CloudHSMは2013年に登場した、専用の物理ハードウェア(HSM)を1台丸ごと占有できるサービスである。通常のAWS標準の暗号化(KMSなど)では鍵管理もAWSインフラの中で行われるのに対し、CloudHSMは鍵の生成・保管・演算が専用ハード内で完結し、AWS側の人間ですら鍵の中身に触れられない。
金融(PCI DSS)、医療(HIPAA)、政府機関など、クラウド事業者にすら鍵を見せてはいけないという規制対応が必要な業界向けのサービスであり、個人利用の出番はまずない。鍵を紛失した場合はAWS側でも復旧不可能であり、暗号化されたデータは永久に読めなくなる。漏洩した場合は鍵のローテーションと再暗号化が必要になるが、漏洩発覚までにアクセスされていた分の情報流出は防げない。つまりCloudHSMは「AWSにも見せない」代わりに、鍵管理の全責任を利用者側が丸ごと背負う仕組みである。扱う鍵は共通鍵(対称鍵、AES256など)と公開鍵ペア(非対称鍵、RSA/ECCなど)の両方に対応しており、用途によって使い分けられる。
AWS WAF - Webアプリケーションファイアウォール
WAFは2015年にリリースされた、SQLインジェクションやXSSといったWebアプリケーションへの攻撃を検知・ブロックする仕組みである。ルールベースで動作し、AWSが用意した既製のマネージドルール(OWASPの脆弱性パターン集など)や、独自のカスタムルールを設定できる。CloudFrontやALB(ロードバランサー)の前段に設置し、リクエストがEC2やLambdaに到達する前にふるいにかける役割を持つ。
セキュリティ機能は「土台→権限→防御」の順で積み上がるものであり、WAFがEC2/S3(2006年)やIAM(2011年)より後発になったのは、応用アプリレベルの防御という性質上、順当な流れだったと言える。
コンピューティング編
AWS Lambda - サーバーレスコンピューティング
Lambdaは2014年にリリースされたサーバーレスコンピューティングサービスである。「サーバーレス」という名称は「サーバーが存在しない」という意味ではなく、「利用者がサーバーを意識しなくてよい」という意味である。裏側では通常通りサーバーが稼働しているが、AWS側がその管理を完全に隠蔽している。
EC2がOS設定・ミドルウェア導入・常時起動の管理まで利用者の責任範囲であるのに対し、Lambdaはコードだけをアップロードすれば、リクエストが来た際にAWSが実行環境を用意し、終了後に破棄する。課金もミリ秒単位の実行時間分のみで、呼ばれなければ課金は発生しない。
一方で実行時間の上限(最大15分)、初回起動時のコールドスタート遅延、ステートを保持できない制約などがあり、常時稼働のWebサーバーや長時間バッチ処理、複雑なミドルウェア依存のあるアプリケーションにはEC2の方が向いている。Lambdaは「短時間・単発のイベント駆動処理」に適した道具であり、EC2の代替品ではなく住み分ける別カテゴリのサービスである。
Amazon ECS - コンテナオーケストレーション
ECSは2014年にリリースされた、Dockerコンテナをデプロイ・起動・停止・スケーリング管理するオーケストレーションサービスである。裏側のインフラはEC2上で動かす方式と、サーバー管理そのものが不要なFargate方式の2パターンから選択できる。
サービス名に「Docker」を冠していないのは商標上の制約ではなく、AWSが自社サービス名にサードパーティの技術名をそのまま使わない一貫した命名方針によるものである(RDSが「MySQL Service」と名乗らないのと同じ理屈)。ECSは元々「AWS独自のコンテナ管理基盤」という広い括りで設計されており、Docker以外のコンテナランタイムに対応する余地も残されている。
データ移行・IoT編
AWS Snowball - 物理デバイスによるデータ移行
Snowballは2015年にリリースされた、大容量データを物理デバイス経由で移行するサービスである。数十TB〜PB級のデータをネットワーク経由で送ろうとすると、どれだけ高速な回線でも現実的に数週間〜数ヶ月かかってしまう。Snowballはこの回線の物理限界を逆手に取り、暗号化された頑丈な物理ストレージデバイスを宅配便でやり取りすることで、実質的な転送速度を大幅に向上させる。
さらに大規模なデータ移行向けには、トラック一台分のシャーシを送る「Snowmobile」というサービスも存在し、エクサバイト級のアーカイブ移行などに使われている。クラウドの最先端インフラの裏側に、規模が大きくなるほど物理輸送が最適解になるという、極めてアナログな解決策が組み込まれている点は興味深い。
AWS IoT - デバイス通信基盤
AWS IoTは2015年にリリースされた、家電・センサー・産業機器などの「モノ」がネットワーク経由でAWSと通信するための基盤である。デバイスは非力でバッテリー駆動であることが多く、通常のHTTP通信では負荷が大きすぎるため、MQTTという軽量プロトコルを用いて最適化されている。
デバイスのIPアドレスは動的に変化することが前提であり、識別にはIPではなくX.509証明書によるデバイス認証が使われる。IPベースでの管理は、数億台規模のデバイスのIP変動を追跡することになり現実的に破綻するため、証明書ベースの設計が採用されている。
AI・機械学習編
Amazon Rekognition - 画像・動画認識AI
Rekognitionは2016年にリリースされた画像・動画認識AIサービスである。顔検出・顔認証、物体・シーン認識、テキスト検出、不適切コンテンツの自動検出などが可能で、空港の顔認証ゲート、犯罪捜査の顔照合、製造ラインの不良品検出など、実運用レベルで広く使われている。
顔認証は「顔の輪郭全体」ではなく、目と目の間隔や鼻の長さ、顎のラインといった数十〜数百の特徴点をベクトル化し、登録済みデータとの類似度を計算する方式で行われる。一卵性双子はこの特徴点比率がほぼ同一になるため、誤認識率が上がるという弱点はRekognitionに限らず顔認証システム全般に共通する課題である。マスク着用時も同様に精度が低下するため、マスク検出機能の追加や部分一致モデルへの対応が進められているが、完全な解決には至っておらず、実運用では他の認証手段との併用が推奨される。
ローカルPCでも同等のアプリは動作するが、クラウド版は学習済みモデルの精度、大量画像の並列処理能力、大規模な顔DBとの突合といった点でスケールの次元が異なる。
Amazon SageMaker - 機械学習プラットフォーム
SageMakerは2017年にリリースされた、機械学習モデルの構築・学習・デプロイを一気通貫で行うプラットフォームである。RekognitionやPollyが「出来合いのAIサービスを利用する」ものであるのに対し、SageMakerは「利用者自身が独自データでモデルを一から作る」ための開発環境であり、統計・モデル選定・チューニングといった専門知識が前提となる。既製のAIサービスで対応できない独自要件がある場合にのみ検討すべき領域であり、個人開発やポートフォリオ制作では優先度は低い。
開発環境・その他サービス編
AWS Cloud9 - クラウドIDE
Cloud9は2017年にリリースされた、ブラウザ上で動作するIDEである。裏側でEC2インスタンスが起動し、ブラウザからコードエディタ・ターミナル・デバッガを利用できる。セキュリティ事故などの問題があったわけではなく、EC2常時待機のコスト効率や、ローカル開発環境・GitHub Codespacesなど競合の台頭を背景に、AWSは新規ユーザー向けの提供を終了する方針を取っている。ネットワーク接続が前提となる制約上、WSL2などのローカル開発環境の方が安定性の面で優位性がある。
Amazon GameLift - ゲームサーバーホスティング
GameLiftは2016年にリリースされた、オンラインマルチプレイゲーム向けのサーバーホスティングサービスである。単なるEC2のゲーム向けカスタムプランではなく、マッチメイキング機能(FlexMatch)によるプレイヤーの振り分け、セッション単位でのサーバー管理、プレイヤーに近いリージョンへの低遅延配置、マッチ終了後の高速なリソース解放といった、ゲーム特有の要件に特化した機能を提供している。FortniteやValorantのような大規模タイトルで実際に採用されている一方、専業のPhotonやMirrorといった競合、自社インフラを持つ大手企業も存在し、業界を独占しているわけではない。
Amazon Pinpoint - マーケティング配信基盤
Pinpointは2016年にリリースされた、プッシュ通知・メール・SMS・音声通知を統合管理するマーケティングオートメーションサービスである。ユーザーの行動データを分析してセグメント分けし、「一定期間アプリを開いていないユーザーにリマインド通知を送る」といったターゲティング配信が可能である。ECサイトのカート放置リマインドや、アプリの休眠ユーザー向け通知などの裏側で使われている。
Amazon Connect - クラウド型コンタクトセンター
Connectは2017年にリリースされた、クラウド上でコールセンターを構築できるサービスである。従来は専用の電話交換機(PBX)を物理的に導入する必要があったが、Connectはこれをクラウド化し、IVR設定、オペレーター自動振り分け、通話録音・文字起こし・感情分析までを従量課金で提供する。在宅コールセンターの構築とも相性が良く、需要が伸びている分野である。
AWS Media Services - 動画配信インフラ
Media Servicesは2017年にリリースされた、動画配信に必要なエンコーディング・ライブ配信処理・CDN連携・DRM対応を一式提供するサービス群である。Netflixのような動画配信事業者や、ライブ配信サービス、企業の社内動画配信基盤などで利用されている。自前で動画配信インフラを構築する負荷を大幅に下げる位置づけであり、個人利用の機会は基本的にない。
AWS AppSync - GraphQL APIマネージドサービス
AppSyncは2018年にリリースされた、GraphQL APIをマネージドで提供するサービスである。DynamoDBやRDS、Lambdaといったデータソースとの自動連携に加え、リアルタイム同期とオフライン対応を得意とする。モバイル回線は不安定でオフライン復帰が頻発するため、必要なフィールドだけを取得できるGraphQLの特性と、オフライン→オンライン復帰時の自動同期機能が相性が良く、モバイルアプリのバックエンドとして採用されることが多い。宅配便のスキャン端末や改札端末のような、端末とサーバー間のリアルタイム同期が必要な仕組みとも親和性が高い分野である。
AWS Ground Station - 衛星通信基盤
Ground Stationは2019年にリリースされた、人工衛星との通信を地上局経由で行うサービスである。世界中に自前でアンテナ基地を建設するコストとメンテナンスの負担を、時間貸しの従量課金に置き換えている。利用者は衛星打ち上げ企業、地球観測・気象衛星の運用機関、宇宙ビジネス系スタートアップなどに限られ、個人や一般企業には縁のない領域である。
AWS RoboMaker - ロボット向け開発基盤
RoboMakerは2018年にリリースされた、ロボットの制御ソフトウェアを開発・シミュレーション・デプロイするサービスである。ハードウェア自体はAWSが提供するものではなく、ロボット開発の標準フレームワークROSをクラウド上で利用し、実機投入前にクラウド上で物理演算シミュレーションを行える点が特徴である。2023年に新規申込みが終了しており、現在は歴史的な位置づけのサービスとなっている。
Amazon Managed Blockchain - ブロックチェーン基盤
Managed Blockchainは2019年にリリースされた、HyperledgerおよびEthereumベースのブロックチェーンネットワークをマネージドで構築・運用できるサービスである。複数の参加者間で改ざん不可能な取引履歴を共有する仕組みであり、本来は自前でのノード構築・鍵管理・参加者管理が非常に煩雑だが、これをボタン一つで完結させる。サプライチェーン管理、貿易金融、医薬品トレーサビリティなど、「複数の別会社間で取引履歴を正確に共有したいが、単一の管理者には依存したくない」というニーズを持つ法人向けのサービスである。
まとめ
2006年のS3・EC2から始まったAWSのサービス展開は、まず計算・保存・DB・ネットワークという基本インフラを整備し(2006〜2011)、その後データベースの多様化とセキュリティ・分析基盤を強化し(2012〜2015)、2016年以降は画像認識・ゲーム・IoT・衛星通信・ブロックチェーンといった業界特化型のサービスへと広がっていった。年を追うごとに法人・専門領域向けのサービスが増えていくのは、基本インフラが出揃った後のプラットフォームビジネスとして自然な成長パターンだと言える。
なお「4000サービス」といった数字は、サービスの種類数ではなく、機能追加やリージョン展開を含む累計リリース数を指していることが多く、混同しないよう注意が必要である。サービスの種類自体は現在でも300弱程度にとどまっている。