A well-thought solution for AWS-based software development
- AWS Account is automatically created and connected to AWS Organization
- Organization Role is created inside AWS Account for sudo-like AssumeRole access
- Access to AWS account is centrally managed via AWS SSO based on Active Directory group membership eliminating need to create, administer and cleanup IAM users inside individual AWS Accounts.
- Organization Sysadmin SSH key is provisioned into AWS Account
- IP address range is centrally-managed allowing overlap-free AWS Account peering
- AWS Accounts are linked spoke-to-hub manner to AWS Transit Gateway providing truly hybrid cloud experience
- Infrastructure VPC is connected to AWS Transit Gateway providing ActiveDirectory connections for LDAP(s) authentication and easy integration for other AD-dependent services (like AD-based MS SQL Server logins or Windows EC2 instances)
- Office branches are connected to AWS Transit Gateway via IPSEC (AWS Site-to-Site VPN) extending your network space to developer’s machines. The can directly access services running in cloud without the need of tunneling, proxies, NAT or client VPN
- For the road/couch warriors AWS Client VPN (powered by OpenVPN) with built-in Active Directory authentication offers similar direct access to organization network
AWS Account scope
By AWS Account we mean on of the organization’s aws accounts connected to AWS Organization and devoted single software product development (or set of connected products).
- DNS sub-zone is created for AWS Account ready to be connected with TLD NS provider
- GitHub repos are created and managed for each product along with respective teams and CI tool access
- AWS ECR repos are created and managed for each product
- S3 buckets are created for Nexus, Chartmuseum and generic use. Solves problem of Nexus running out of disk space for next 5 exabytes.
- Centrally managed IP whitelist locks down account from unauthorized access on multiple levels – IAM SourceIP, AWS SecurityGroups, nginx allow/deny.
- Set of organization-wide settings and secrets are maintained inside AWS Account to be discovered in a predictable manner and used by local services like Jenkins and Keycloak
- Per AWS Account – GitHub repo, S3 bucket and DynamoDB for Terraform configuration of the individual account features
The cluster is a used as development environment and certain corners are cut in order to make it simple and usable. We assume that:
- cluster users can tolerate minor downtimes. Spot Instances could be externally terminated, approximately once a month
- information and deployment doesn’t need to be backed up. In case of a total disaster everything can be rebuilt from git repos which are presumed durable enough due to distributed nature of git
- authentication is enough. We don’t offer fine grained authorization for the most services and role separation is more of guardrails and policies
- firewalls limit external access, but anyone on the office network can reach cluster internals