MENU
SQL Server × Access

クラウド連携概論：AccessをAzureやAWSに持っていくアプローチ

nanikatoaccess

以下では、「クラウド連携概論：AccessをAzureやAWSに持っていくアプローチ」をテーマに、Microsoft Accessで構築したアプリケーションをAzureやAWSなどのクラウド環境に移行・連携する際に、どのような方法・視点があるかを概説します。AccessはローカルPCやオンプレミス環境で使われることが多い一方、クラウド上での高可用性や大規模データ管理を求めるニーズが高まり、「クラウド×Access」という組み合わせも検討されるようになりました。

ないものはない！お買い物なら楽天市場

1. なぜクラウド連携を考えるのか？

  1. 災害対策・バックアップ強化
    • オンプレファイル(.accdb/.mdb)だと、物理障害でファイルを失うリスクがある。クラウドなら地理冗長化や自動バックアップが充実している。
  2. リモートアクセス・複数拠点利用
    • 自宅や別拠点からVPN接続せずとも、AzureやAWS上のDBに直接接続できる設計を組める。
  3. スケーラビリティ
    • データ量やユーザー数が増えた時、クラウドDB(Azure SQLやAWS RDSなど)にスケールアップを任せられる。
  4. 保守負荷の軽減
    • WindowsサーバーやSQL Serverのパッチ適用などをクラウド側が自動で行い、オンプレ管理の手間が減る。

2. 主なアプローチ：Accessフロントエンド + クラウドDB

2.1 Azure SQL Databaseと連携

  • Azure SQL Database: Microsoft純正クラウドSQL ServerのPaaS。
  • リンクテーブルまたはパススルークエリを使い、AccessフロントエンドからODBC経由でAzure SQLに接続。
  • パフォーマンスや大規模データ管理をAzure側が担い、Accessは画面（フォーム・レポート）に専念。
  • 自動バックアップや地理冗長化を標準でサポート。

イメージフロー

  1. フロントエンド分割: Accessのフォーム/レポートを持つファイル(各ユーザーのPC)
  2. バックエンド: Azure SQLにテーブルを移行（SSMA for Accessなどを使って移行）
  3. ODBC DSN or DSNレス接続: 文字列でAzure SQLにログイン
  4. セキュリティ: Public IP経由ではなく、VPN/ExpressRouteやPrivate Endpointで安全に接続することも多い

2.2 AWS RDS (Relational Database Service) でSQL ServerやMySQLを使う

  • AWSのRDS上でSQL Serverインスタンスを立ち上げ、Accessから同様にODBC接続。
  • あるいはMySQL/MariaDBをRDSで動かし、AccessがMySQL ODBCドライバで連携する例もある。
  • AWS側で自動バックアップやスケール設定ができるメリットがある。

ポイント

  • アクセスルート: AWS RDSに接続するにはVPCやセキュリティグループ設定を行い、必要ポートのみ開放。
  • Auth: SQL Server認証やMySQL認証を設定し、AccessからDSNレス接続でUser/Passを入力して繋ぐ。

3. ファイル(.accdb)そのものをクラウド上に置く方法は？

  • 単純に「AccessファイルをOneDriveやSharePointに置く」というアプローチもあるが、マルチユーザーで同時編集するには向かない（同期が衝突しやすい）。
  • SharePointリストに変換し、Accessがそれをリンクテーブルとして使う方法もあるが、パフォーマンス・機能面で限界がある。
  • 本格的にクラウドで安定運用するなら、バックエンドをAzure SQLやAWS RDSにして、フロントエンドはローカルまたは仮想デスクトップで使う構成が実用的。

OneDriveで共有フォルダのように使うのは危険

  • 同時編集で同期衝突が起き、ファイル破損リスクが高い
  • 小規模かつ1ユーザー程度ならまだしも、多ユーザーや同時書き込みでは非推奨

4. セキュリティとネットワーク設計

  1. Azureの場合
    • Azure SQLをPrivate Endpoint化し、オンプレからVPN/ExpressRouteで閉域接続
    • Public IPで直接アクセスもできるが、IP制限やFirewall設定をきちんと行う
    • Azure AD 認証を導入することも可能で、パスワードをAccess側に持たずに済む
  2. AWSの場合
    • AWS VPC上にRDS(SQL Server/MySQL等)を配置
    • セキュリティグループで特定IPやVPN接続のみ許可
    • こうすることでインターネット上に直接DBを晒さない
  3. AccessのDSNレス接続
    • Provider=SQLOLEDB; Data Source=xxx.database.windows.net; Database=...; Uid=...; Pwd=...; Encrypt=yes; といった文字列で通信を暗号化(TLS)しつつ接続
    • Credentials（ユーザーID, パスワード）管理も慎重に行う

5. 運用上のヒントと課題

  1. ローカルPC vs 仮想デスクトップ
    • ユーザーがローカルPC上のAccessフロントエンドからクラウドDBにアクセス
    • あるいはAzure Virtual Desktop / Amazon WorkSpacesなどで仮想Windows環境にAccessをインストールし、帯域を最適化
  2. パフォーマンス
    • ネットワーク遅延が大きいと、リンクテーブルで大量データを操作すると遅い
    • パススルークエリやストアドプロシージャを活用し、サーバーサイドで集計→結果だけ送る形に最適化
  3. バックアップ
    • Azure SQL / AWS RDSの自動バックアップでロールバック可能
    • フロントエンド(.accdbファイル)はローカルかリポジトリ(OneDriveやGit)でバージョン管理
  4. コスト
    • クラウドDBは使った分だけ課金されるモデル。小規模なら月数千円程度かも
    • ピーク時の負荷に合わせたスケールアップやスケールダウンを計画し、無駄を削減

6. まとめ：Accessをクラウド化する基本指針

  1. 最適な形：フロントエンド = Access, バックエンド = Azure SQL/AWS RDS
    • AccessでUI(フォーム/レポート/マクロ/VBA)を担当し、データはクラウドDBで高可用性を享受
  2. ファイルそのものをクラウド共有フォルダに置くのは、複数ユーザーには危険（同期衝突・破損リスク）
  3. セキュリティ強化
    • VPNやPrivate Endpointで安全経路を確保し、認証はクラウドDBで行う
    • DSNレス接続文字列を安全に保持し、暗号化通信(Encrypt=yes)を使う
  4. パフォーマンス最適化
    • パススルークエリやストアドプロシージャを使い、サーバー側で重い集計を処理
    • フォーム開くときに必要最小限のデータだけ取り、無駄なフルスキャンを避ける

結果、オンプレのAccess運用でもクラウドDBへ移行すれば、災害対策や拠点間共有が簡単になり、拡張性を得られます。一方、ネットワーク環境やセキュリティ設計など新たな考慮点も増えるため、段階的な移行を行って効果とコストを検証しつつ進めるのが得策です。

関連記事

Access × Azure/AWSという選択は、小中規模業務アプリのクラウドリフトをスムーズに行う手段のひとつです。オンプレで構築していたDBをクラウドに移行することで、高可用性や拡張性を実現しながらAccessの簡易開発を活かせるアーキテクチャを目指してみてください。

DMM
ABOUT ME
まー
まー
駆け出しブロガー
入社した会社では、Accessを活用した基幹システムが長年運用されていました。しかし、開発者の高齢化により保守が困難となり、システムの維持・更新が急務に。 ほぼAccessに触れたことのなかった私は、ゼロから学びながら基幹システムを再構築してみることに。ついにはAccessによるシステム開発エンジニアとしてのスキルを身につけるまでに成長。 元々の業務のノウハウとそれを効率化するためのツール(Access)によって業務効率化システムをいくつも開発してきました。 みなさんの”なにか（業務のノウハウ）”とAccessで業務効率化を実現するお役に立てれば幸いです。 月３０万の高配当投資も行っています。最新の銘柄情報もお届けしていきます。
ないものはない！お買い物なら楽天市場
googleアドセンス
Recommend
こんな記事も読まれています
記事URLをコピーしました