Create, remove, back up and restore environments through NGX. No AWS console login is needed for these routine tasks once the account and platform credentials are configured.
Key Links: Environment Management · Backup and Restore · Moving existing environments
The new AWS simplified signup assigned Stockholm to the account. Selecting London requires activating advanced features; adding billing alone does not enable region choice. AWS compares the two account experiences.
Stockholm is AWS region eu-north-1. If we keep the simplified signup, files created in that account are stored in Sweden, in that region. London is eu-west-2.
Existing live NGX environment buckets, and the platform backup bucket, are in Ireland (eu-west-1). They are not in London today. Copying an environment into the Head office AWS account would store those files in whichever region that account is configured to use.
London would let us keep the destination storage in the UK and follow the intended hosting arrangement. Whether UK storage is required is an account-owner decision; Stockholm’s location in the EEA does not, by itself, settle the organisation’s data-location requirements.
The administration concern is real but specific: activation transfers account governance to the owner, removes simplified spending limits and cannot be reversed. It does not require manually creating each environment’s storage in AWS. NGX already handles that work through Platform Management. AWS explains activation.
Decision: agree the required storage location and who owns central account access and spending controls. If London is selected, enable it and configure the platform before copying files. Routine creation, removal, backup and restore then remain NGX operations, without an AWS console login.
Yes, in principle. AWS explicitly supports nonprofit organisations, including work with member and volunteer data. A charity-controlled AWS account with separate environment buckets and restricted application credentials is a reasonable technical approach; this is an assessment of the design, not confirmation that the current account has passed a security review. AWS for nonprofits.
Stockholm is not automatically a data-protection problem. The ICO lists Sweden as having full UK adequacy. Transfers covered by that adequacy do not need a separate transfer risk assessment or additional transfer safeguards solely because the destination is Sweden. Other data-protection obligations still apply. London may be preferred or required by Ramblers’ own policies or agreements, but charity status alone does not establish that requirement. ICO adequacy guidance.
Simplified signup does not remove responsibility for the data. Ramblers still needs appropriate access controls, supplier terms and recovery arrangements. Private records and backups must have suitable protection; public website images are a different access case. The assessment must cover backups, support access and other services as well as the S3 storage region. ICO cloud guidance.
Keeping the simplified Stockholm setup can therefore be reasonable if those requirements are met. Choosing London can also be reasonable. The decision should follow the charity’s data and operational requirements; neither account mode is a compliance certificate.
The parent account owns the AWS resources. Each standard environment gets its own storage and application identity; it does not need another AWS account.
flowchart TB
Admin["Platform administrator"] --> UI["NGX Platform Management"]
UI -->|"Configured provisioning credentials"| Provisioner["AWS provisioning identity"]
subgraph Account["Parent AWS account — owns the resources"]
Provisioner
subgraph Example["Example environment"]
User["IAM service user + access keys"]
Policy["IAM policy — this bucket only"]
Bucket["S3 bucket — files and images"]
User --> Policy --> Bucket
end
Provisioner -->|"Creates and removes"| User
Provisioner -->|"Configures"| Policy
Provisioner -->|"Creates and removes"| Bucket
end
App["Environment application"] -->|"Its own access keys"| User
style Account fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,color:#404143
style Example fill:#FFFFFF,stroke:#9BC8AB,color:#404143
flowchart TB
UI["Platform Management"] --> Create["Create environment"]
UI --> Backup["Back up"]
UI --> Restore["Restore"]
UI --> Remove["Remove environment"]
Create --> Resources["Bucket + service user + policy + access keys"]
Backup --> Saved["Database backup + file backup in configured storage"]
Restore --> Recovered["Selected database backup + available matching files"]
Remove --> Cleanup["Delete selected resources and report cleanup results"]
style UI fill:#FFE500,stroke:#404143,color:#404143
Create: configure storage access, create the resources above, copy selected starter assets and supply the application credentials. Platform Configuration Values is automatically kept up to date with configuration changes.
Back up: select environments and options in NGX. The platform can upload database backups to S3 and back up files and images using the configured backup destination.
Restore: select a backup and target environment in NGX. The platform retrieves and restores the database and can restore matching backed-up files. Check both database and file results in the operation logs.
Remove: confirm destruction and select the resources to remove. AWS cleanup deletes bucket contents and versions, the bucket, service user, keys and policy. Failed cleanup is reported and the environment configuration is retained. Historical backups are separate from environment cleanup.
Billing, administrative access, recovery and exceptional support remain central account responsibilities. Groups do not need AWS accounts or AWS console logins to administer their environments.