To test a highly AWS integrated solution, such as deployments on AWS Lambda, you can test deployments on an AWS “stub”, such as LocalStack or an AWS account per developer (or even per solution). Shared AWS account models are flawed for development as the environment can not be effectively shared with multiple developers without adding a lot of deployment complexity such as naming conventions.
What are the pros and cons of choosing a stub such as LocalStack versus an account management policy such as an AWS account per developer?
When is LocalStack a good approach?
LocalStack allows a configuration of AWS endpoints to point to a local service running stub AWS endpoints. These services implement most of the AWS API allowing a developer to check that their cloud implementations have basic functionality before deploying to a real AWS Account. LocalStack runs on a developer’s machine standalone or as a Docker container.
For example, you can deploy a Lambda implementation that uses SQS, S3, SNS, etc and test that connectivity works including subscriptions and file writes on LocalStack.
As LocalStack mimics the AWS API, it can be used with AWS-CLI, AWS SDKs, Cloudformation, CDK, etc.
LocalStack (at 28th July 2024) does not implement IAM security rules so a developer’s deployment code will not be tested for the enforcement of IAM policies.
Some endpoints (such as S3) require configuration so that the AWS API responds with URLs that can be used by the application correctly.
Using a “fresh” environment for development pipelines can be simulated by running a “fresh” LocalStack container. For example you can do a System Test environment by using a new container, provisioning and then running system testing.
If you have a highly managed and siloed corporate deployment environment, it may be easier, quicker and more pragmatic to configure LocalStack for your development team then attempt to have multiple accounts provisioned and managed by multiple specialist teams.
When is an AWS Account per developer a good approach?
An AWS account per developer can remove a lot of complexity in the build process. Rather than managing the stub endpoints and configuration, developers can be forced to deploy with security rules such as IAM roles and consider costing of services as part of the development process.
However this requires a high level of account provisioning and policy automation. Accounts need to be monitored for cost control and features such as account destruction and cost saving shutdowns need to be implemented. Security scans for policy issues, etc can be implemented across accounts and policies for AWS technology usage can be controlled using AWS Organisations.
An account per developer opens a small step to account per environment which allows the provisioning of say System Test environments on an ad hoc basis. AWS best practices for security also suggest account per service to limit blast radius and maintain separate controls for critical services such as payment processing.
If the organisation already has centralised account policy management and a strong provisioning team(s), this may be an effective approach to reduce the complexity in development while allowing modern automated pipeline practices.
Conclusion
| Approach | Pros | Cons |
|---|---|---|
| LocalStack | Can be deployed on a developer’s machine. Does not require using managed environments in a corporate setting. Can be used with AWS-SDKs, AWS-CLI, Cloudformation, SAM, CDK for deployments Development environments are separated without naming conventions in shared accounts, etc. Fresh LocalStacks can be used to mimic environments for various development pipeline stages. Development environment control within the development team. | Requires application configuration to use LocalStack. Does not test security policies before deployment. May have incomplete behaviours compared to production. Note that the most common use cases are functionally covered. Developers are not forced to be aware of cost issues in implementations. Developers may implement solutions and then find policy issues when deploying to real AWS accounts. |
| AWS Account per Developer | Removes stubbing and configuration effort other than setting AWS Account Id. Development environments are separated without naming conventions in shared accounts, etc. Forces implementations of IAM policies to be checked in development cycle. Opens account per environment as an option for various development pipeline stages. Developers need to be more aware of costs when designing. Development environment control within the development team, with policies from the provisioning team. | Requires automated AWS account creation. Requires shared AWS Organisation policy enforcement. Requires ongoing monitoring and management of the account usage. Requires cost monitoring if heavyweight deployments such as EC2, ECS, EKS, etc are used. |
References
- AWS Accounts Best Practices: https://aws.amazon.com/organizations/getting-started/best-practices/
- Using LocalStack: https://docs.localstack.cloud/getting-started/installation/
- LocalStack Functional Coverage: https://docs.localstack.cloud/references/coverage/