Buyer guide

Questions to ask before an AWS deployment

Before you deploy on AWS, settle what data the workload holds, which region it runs in, how available it must be, who can access it, what it may cost, how it is backed up and who looks after it afterwards. Most cloud surprises come from one of those questions being left open.

The short answer

AWS gives you a great deal of choice, which means many decisions that a hosting company would once have made for you now sit with your organisation. Before deployment, you should be able to answer seven groups of questions:

  1. Data: what the workload stores and how sensitive it is.
  2. Region: where it runs, and whether any data or backups leave Nigeria or cross further borders.
  3. Availability: how long it may be down and how much data you can afford to lose.
  4. Identity: who and what can access the account, and how.
  5. Budget: what it should cost and how you will know when it doesn't.
  6. Backups: what is backed up, where, and whether restores have been tested.
  7. Ownership: who runs, patches, monitors and pays for it after launch.

AWS describes security as a shared responsibility: AWS protects the infrastructure that runs its services, while the customer's responsibilities depend on the services they choose. The questions below are largely about your side of that line.

1. Data

  • What records will the workload hold: customer data, financial data, health information, documents, logs?
  • Does it hold personal data? If so, the Nigeria Data Protection Act 2023 (NDPA) applies, and health data counts as sensitive personal data. Sector rules may apply as well, for example from the Central Bank of Nigeria for banks and payment service providers.
  • Are there contractual requirements from customers, funders or regulators about where data is stored or who can access it?
  • How much data is there today, how fast does it grow, and how long must it be kept?
  • Which logs will contain personal data, and who can read them?

2. Region choice and data residency

AWS does not operate a public cloud region in Nigeria. Realistic options are a local data centre in Lagos or Abuja, or an AWS region abroad. The nearest large ones are Africa (Cape Town), code af-south-1, which is an opt-in region that must be enabled before use, and the European regions (AWS Regions). Check the current region list before you decide.

Choosing a region is a decision about data transfers, latency and cost, and it does not, by itself, settle compliance. Ask:

  • Are all the services you plan to use available in the chosen region?
  • Do any services, features or third-party tools you add (monitoring, email delivery, content delivery, support tooling) process data in yet another country?
  • Will backups or disaster recovery copies go to another region, and which country is that in?
  • Does your sector regulator or a public-sector customer require data to be hosted in Nigeria, for example under NITDA guidelines, the Nigeria Cloud Computing Policy or the CBN's rules? If so, a local data centre may be the only option for that data.
  • If personal data will be processed outside Nigeria, have you told people, put contractual protections in place and checked the NDPA's rules on transfers? The Nigeria Data Protection Commission (NDPC) publishes the Act and its implementation directive. Organisations remain accountable for data transferred for processing.
  • How good is the connection between your users and the region? Test latency from your offices and, for customer-facing systems, from mobile networks.

This is general information, not legal advice.

3. Availability

  • What happens to the business if this workload is unavailable for an hour, a day or a week?
  • What is the recovery time objective (how long until it must be back) and recovery point objective (how much recent data you could lose)?
  • Is running across multiple Availability Zones within one region enough, or do you need a recovery option in a second region?
  • Which parts are single points of failure: one database instance, one server, one person with the password?
  • Remember the path to the cloud as well as the cloud itself. Grid outages and a single internet link at your office can take users offline even when AWS is healthy, so plan power backup and a second link.
  • How will you know it is down before your customers tell you?

Higher availability costs more. Set the target from the business impact, not from habit.

4. Identity and access

AWS's IAM best practices are a good baseline. Ask:

  • Will people sign in through federation with an identity provider (for example, your Microsoft 365 or Google Workspace accounts) using temporary credentials, rather than long-lived individual IAM users?
  • Is multi-factor authentication required, ideally phishing-resistant methods such as passkeys or security keys?
  • Who holds the root user credentials, how are they protected, and when are they used?
  • Are permissions based on least privilege, and who reviews and removes unused access?
  • Will production, testing and development live in separate accounts, with guardrails applied across them?
  • When a staff member or contractor leaves, what is the offboarding step for AWS access?

5. Budget

  • What is the expected monthly cost, as estimates in US dollars with the naira equivalent, and what assumptions is it based on (usage, storage growth, data transfer)? AWS bills in dollars, so exchange-rate movement is part of the budget.
  • Who receives budget alerts? AWS Budgets can notify you when actual or forecast spending passes a threshold, but AWS notes there can be a delay between incurring a charge and receiving the notification, so alerts are not a hard spending cap.
  • Are resources tagged by project, environment and owner so costs can be allocated?
  • Who reviews the bill monthly and has authority to switch off what is not needed?
  • Have you considered commitments or reserved capacity only after usage is stable?
  • How will the dollar invoice actually be paid, and who in finance owns that process?

For ongoing cost control, see how growing companies cut cloud costs.

6. Backups and recovery

  • Which resources are backed up, how often and for how long?
  • Are backups managed centrally, for example with AWS Backup, which supports backup plans, cross-Region and cross-account copies, and a vault lock that prevents deletion of backups or changes to retention?
  • Are backup copies kept somewhere that a compromised administrator account cannot delete?
  • When was a restore last tested, and how long did it take?
  • Are application configuration, infrastructure definitions and secrets recoverable too, not only data?

A backup you have never restored is an assumption. Our backup and disaster recovery service covers this in more depth.

7. Ongoing ownership

  • Who owns the AWS account and the billing relationship?
  • Who applies operating system, database and application updates?
  • Who monitors alerts outside business hours, and what are they expected to do?
  • Is the environment defined as code, so it can be rebuilt and reviewed?
  • Where is the documentation: architecture, access, runbooks and recovery steps?
  • When will the design be reviewed? The AWS Well-Architected Framework describes a review process for reliable, secure, efficient, cost-effective and sustainable workloads.

Pre-deployment checklist

  • Data types, sensitivity and applicable data protection obligations documented.
  • Region chosen, with every service and third-party tool checked for where it processes data.
  • Backup and disaster recovery locations confirmed, including which countries hold copies.
  • Recovery time and recovery point objectives agreed with the business.
  • Sign-in through federation, with MFA required; root user secured.
  • Separate accounts or environments for production and non-production.
  • Monthly cost estimate in US dollars and naira, budget alerts and tagging in place.
  • Backup plan configured and a test restore completed.
  • Monitoring and alert recipients defined, including outside business hours.
  • Named owners for the account, billing, updates and incident response.
  • Documentation and runbooks stored somewhere the team can reach during an outage.

Limitations

These questions apply to most business workloads but are not a full architecture review. Regulated workloads, such as those at banks, payment service providers, insurers or health data custodians, will have further requirements. If AWS is one option among several, the same questions help compare it with other providers and with local data centres.

Next step

If you want help answering these questions or reviewing an existing AWS environment, see AWS deployment and cloud engineering. For broader migration planning across providers, see cloud services and migration.

Sources and further reading

Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.

  1. AWS Regions, Amazon Web Services documentation
  2. Shared Responsibility Model, Amazon Web Services
  3. Security best practices in IAM, Amazon Web Services documentation
  4. Managing your costs with AWS Budgets, Amazon Web Services documentation
  5. What is AWS Backup?, Amazon Web Services documentation
  6. AWS Well-Architected Framework, Amazon Web Services documentation
  7. Nigeria Data Protection Act, GAID 2025 and guidance, Nigeria Data Protection Commission

This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.

Talk to Promatics

Get a straight answer for your situation

General advice only goes so far. Tell us about your environment and we will tell you what we would do, what it would cost and what to watch out for.

  • A named specialist who owns the outcome, not a chat window
  • Advice checked against your actual systems, contracts and risks
  • Written scope and costs in NGN before any work starts