AWS deployment
AWS deployment patterns for Access front-ends, SQL backends, and modernization.
AWS is a natural destination when IT standardizes on Amazon for infrastructure, but “run MS Access on AWS” still means choosing among several architectures. You can host the Access client on EC2 with Remote Desktop, move tables to RDS SQL Server or Aurora, or rebuild workflows as a web application on Elastic Beanstalk or containers with RDS behind it. Each option solves different problems: remote access, data durability, or long-term scalability. This guide explains what you need to know about networking, licensing, backup, and migration phasing on AWS,without assuming you will lift-and-shift a file-share ACCDB and call it cloud modernization.
Teams arrive at AWS with different mandates. Some must exit on-prem data centers quickly and want familiar Access screens tomorrow. Others need SQL stability first and browser access later. Map your pain before selecting services: file corruption and multi-user locking point toward RDS; remote work friction points toward EC2 or web; audit and integration gaps point toward application modernization.
The three dominant patterns are: (1) Windows EC2 hosting Access clients with optional RDS back-end; (2) RDS SQL Server or Aurora with split Access front-ends distributed to users or terminal servers; (3) custom web applications on Elastic Beanstalk, ECS, or Lambda with API Gateway, using RDS for data. Hybrid combinations are normal,RDS first, web second,mirroring Azure and on-prem modernization sequences described in our Access to Azure guide with service names swapped.
The fastest AWS path for pure remote access is Windows Server on EC2 with Remote Desktop Services or per-user sessions. Users launch Access from a published desktop; the ACCDB or front-end lives on EBS volumes with controlled permissions. This mirrors traditional terminal server deployments but places operations in your AWS account.
Strengths include minimal retraining and quick migration off local PCs. Weaknesses include RDP latency for distant users, session licensing complexity, and the reality that file-based back-ends on shared drives still corrupt if you never upsize to RDS. Pair EC2 with a split database and SQL back-end whenever possible,see the split database guide.
Right-size instances for concurrent interactive load, not just CPU averages. Access is interactive; storage IOPS and network path to RDS matter as much as vCPU count.
Moving tables to Amazon RDS for SQL Server (or SQL Server on EC2 when you need features RDS omits) removes Jet locking and the 2GB file ceiling. Access front-ends link through ODBC with encrypted connections inside the VPC. Security groups should allow only application subnets; public RDS endpoints are a last resort protected by strict IP allow lists.
Test query performance early. Pass-through queries and indexed views often replace Access queries that pulled entire tables across the network. The linked tables guide and T-SQL conversion article cover mechanics that apply equally on RDS.
Automated RDS backups and Multi-AZ deployments improve RPO/RTO versus file shares,details in our cloud backup strategy guide.
| Pattern | Best for | Watch-outs |
|---|---|---|
| EC2 + file ACCDB | Fast lift, few users | Corruption, scale limits |
| EC2 + RDS SQL | Stable multi-user Access UI | RDP UX, session licensing |
| Web + RDS | Browser, audit, APIs | Higher initial build, lowest long-term friction |
| WorkSpaces | Managed desktops | Per-user cost at scale |
When Access cannot meet product goals, rebuild workflows as a web application with RDS underneath. Common stacks use .NET or Node on Elastic Beanstalk or containers, Entra ID or Cognito for authentication, and S3 for document storage. API Gateway and Lambda suit discrete integrations,syncing orders, webhooks, nightly ETL,without keeping Access in the loop.
Web projects benefit from the same data modeling discipline as SQL upsizing. Many teams upsize to RDS first, validate reports, then replace screens module by module,reducing big-bang risk. Read the MS Access to web app service overview and conversion examples for phasing ideas.
Planning Access on AWS and unsure which pattern fits?
Get an AWS architecture reviewPlace database tiers in private subnets. Use Site-to-Site VPN or Direct Connect for hybrid scenarios where on-prem ERP still feeds data. Secrets Manager or Parameter Store should hold connection strings,not embedded passwords in front-end copies.
Enforce MFA on RDP bastion access or replace RDP with web where possible. CloudTrail and VPC Flow Logs support audit; application-level logging still requires web or middleware you control. Regulated workloads may need encryption at rest on RDS and S3, KMS keys, and documented access reviews,file-share Access rarely satisfied those controls.
Windows Server, RDS CALs, SQL Server licensing, and EC2 hours stack quickly. Compare total cost of ownership against managed hosting specialists if your only goal is Access online, sometimes host MS Access online partners reduce undifferentiated heavy lifting while you focus on SQL and web phases.
Use Reserved Instances or Savings Plans for steady-state EC2 and RDS. Tag resources by environment so dev/test clusters do not run production SKUs 24/7. Right-size RDS storage with autoscaling where supported.
RDS automated backups and snapshots define recovery points for SQL data. EBS snapshots cover EC2 system volumes including front-end deployments. Test restore quarterly,untested backups are wishful thinking. Cross-region snapshot copy addresses regional failure scenarios leadership asks about after the first headline-grabbing outage elsewhere.
Access files on shared EBS folders still need consistency discipline: quiesce or migrate to SQL before snapshotting active databases. Corruption restored from snapshot is still corruption.
A pragmatic sequence: (1) inventory and split database; (2) provision VPC, RDS, and security baseline; (3) upsize tables and regression-test linked Access; (4) move users to EC2 or hosted desktop if remote access is urgent; (5) pilot one workflow to web on RDS; (6) expand web modules and retire Access UI. Each gate has validation criteria,row counts, report totals, user sign-off,not merely infrastructure green lights.
Our Access database online and migration services teams align AWS architecture to business timelines so you do not pay cloud rent for an unchanged file-share design. AWS gives you infrastructure choice; phasing gives you business safety.
Compare remote access models in our VPN vs hosted desktop vs web app guide and review modernization pricing before committing to a long-term AWS footprint.
Related reads: Access database online · Host MS Access online · Remote access without VPN · Modernization pricing · Access to web app
For AWS-aligned hosting and migration planning, see our Access Database Online.
Access requires a Windows environment. You run it on EC2 Windows instances, WorkSpaces, or similar,not on Linux directly. Data can live on RDS SQL Server while Access remains the UI on Windows hosts.
Conceptually yes: tables move to a managed SQL engine and Access links via ODBC. Operationally you must configure security groups, SSL, DNS, and drivers for stable linked-table performance over the VPC.
RDS-backed Access scales better than file-based ACCDB, but EC2 session limits and application design still matter. Beyond roughly fifteen to thirty concurrent interactive users, teams usually evaluate web apps or dedicated hosting platforms.
AWS backs up infrastructure you configure,EBS snapshots, RDS automated backups,not your ACCDB unless you include it in snapshot policy or move data to RDS. Treat backup design as explicit architecture work.
Choose web when you need browser access without RDP, mobile users, fine-grained audit, or API integrations at scale. EC2 Access is a bridge; web plus RDS is the long-term application platform.