Changing environment (AWS account) details
Some things we can change regarding account creation, and somethings we can’t. This document outlines what would happen if you did certain things.
Renaming an environments json file
Example
environments/sprinkler.json
to
environments/sprinkler-attachment.json
Outcome
- A new set of environments for the application
sprinkler-attachment
created as defined in the json file - The existing
sprinkler
environment would be destroyed
(This action would fail though as AWS accounts can only be manually deleted)
Takeaway
You can’t change the file name for an application. The only way to do this theoretically is to remove the application from the Terraform state, then import it under the new name. This has not yet been tested.
Change the name of an environment within the environments file
Example
"environments": [
{
"name": "development",
"access": [
{
"sso_group_name": "modernisation-platform",
"level": "developer"
}
]
}
]
to
"environments": [
{
"name": "test",
"access": [
{
"sso_group_name": "modernisation-platform",
"level": "developer"
}
]
}
]
Outcome
- A new environment for
sandbox
created - The existing
development
environment would be destroyed
(This action would fail though as AWS accounts can only be manually deleted)
Takeaway
You can’t change the name for an environment. The only way to do this theoretically is to remove the environment from the Terraform state, then import it under the new name. This has not yet been tested.
Change the github slug for an environment
Example
{
"name": "development",
"access": [
{
"sso_group_name": "modernisation-platform",
"level": "developer"
}
]
}
to
{
"name": "development",
"access": [
{
"sso_group_name": "application-team",
"level": "developer"
}
]
}
Outcome
- SSO would update giving the new team access and removing access for the old team
- For member accounts the github environments would be amended so that the new team is the reviewer and the old team is removed.
Takeaway
Changing the github slug is fine.
Change the access level for a team in an environment
Example
{
"name": "development",
"access": [
{
"sso_group_name": "modernisation-platform",
"level": "developer"
}
]
}
to
{
"name": "development",
"access": [
{
"sso_group_name": "modernisation-platform",
"level": "sandbox",
"nuke": "rebuild"
}
]
}
Outcome
- SSO would update giving the new access level
- Nuke run would be updated clear the account and rebuild it
Takeaway
Changing the access level is fine.
Change the tags for an application
Example
"tags": {
"application": "modernisation-platform",
"business-unit": "Platforms",
"infrastructure-support": "app-team@digital.justice.gov.uk",
"owner": "Modernisation Platform: modernisation-platform@digital.justice.gov.uk"
}
to
"tags": {
"application": "application-team",
"business-unit": "Platforms",
"infrastructure-support": "app-team@digital.justice.gov.uk",
"owner": "Application Team: app-team@email-address.com"
}
Outcome
- Tags for account creation will be updated with the tagging changes
- Tags for application infrastructure are generated dynamically from this data in Terraform using a data source. Any updates to the tags would be made the next time the infrastructure code for that account is run.
Note changing the business unit here is also fine as this is only used for tagging. The business unit in the environments-networking json file name and the data within that file is used for assigning networking to accounts.
Takeaway
Changing the tags is fine.