Field Notes: How FactSet Uses ‘microAccounts’ to Reduce Developer Friction and Maintain Security at Scale

This post was co-written by FactSet’s Cloud Infrastructure team, Gaurav Jain, Nathan Goodman, Geoff Wang, Daniel Cordes, Sunu Joseph and AWS Solution Architects, Amit Borulkar and Tarik Makota.

FactSet considers developer self-service and DevOps essential for realizing cloud benefits. As part of their cloud adoption journey, they wanted developers to have a frictionless infrastructure provisioning experience while maintaining standardization and security of their cloud environment. To achieve their objectives, they use what they refer to as a ‘microAccounts approach’. In their microAccount approach, each AWS account is allocated for one project and is owned by a single team.

In this blog, we describe how FactSet manages 1000+ AWS accounts at scale using the microAccounts approach. First, we cover the core concepts of their approach. Then we outline how they manage access and permissions. Finally, we show how they manage their networking implementation and how they use automation to manage their AWS Cloud infrastructure.

How FactSet started with AWS

They started their cloud adoption journey with what they now call a ‘macroAccounts’ approach. In the early days they would set up a handful of AWS accounts. These macroAccounts were then shared across several different application teams and projects. They have hundreds of application teams along with thousands of developers and they quickly experienced the challenges of a macroAccounts approach. These include the following:

AWS Identity and Access Management (IAM) policies and resource tagging were complex to design in order to maintain least privilege. For example, if a developer desired the ability to start/stop Amazon EC2 instances, they would need to ensure that they are limited to starting/stopping only their own instances. This complexity kept increasing as developers wanted to automate their workflows using constructs such as AWS Lambda functions, and containers.
They had difficulty in properly attributing cloud costs across departments. More importantly they kept going back and forth on: how do we establish accountability and transparency around spends by groups, projects, or teams?
It was difficult to track and manage impact of infrastructure change to FactSet applications. For example, how is maintenance off underlying security group or IAM policy affecting FactSet applications?
Significant effort was required in managing service quotas and limits across various applications being under single AWS account.

FactSet’s solution – microAccounts

Recognizing the issues, they decided to take a different approach to AWS account management. Instead of creating a few shared macro-accounts, they decided to create one AWS account per project (microAccounts) with clearly defined ownership and product allocation. An analogy might be that macro-accounts were like leaving the main door of a house open but locking individual closets and rooms to limit access. This is opposed to safeguarding the entry to the house but largely leaving individual closets and rooms open for the tenant to manage.

Benefits of microAccounts

They have been operating their AWS Cloud infrastructure using microAccounts for about two years now. Benefits of the microAccount approach include:

1. Access & Permissions: By associating an account with a project they simplified which services are allowed, which resources that development team can access, and are able to ensure that those permissions cascade properly to underlying resources. The following diagram shows their microAccount strategy.

Figure 1- microAccount per project strategy

2. Service Quotas & Limits: Given most service quotas are account specific, microAccounts allow their developers to plan limits based on their application needs. In a shared account configuration, there was no mechanism to limit separate teams from using up a larger portion of the service quota, leaving other teams with less. These limits extend beyond infrastructure provisioning to run time tasks like Lambda concurrency, API throttling limits on parameter store and more.

3. AWS Service Permissions: microAccounts allowed FactSet to easily implement least privilege across services. By using IAM service control policies (SCPs) they limit what AWS services an account can access. They start with a default set of services and based on business need we can grant a specific account access to other non-common services without having to worry about those services creeping into other use cases. For example, they disable storage gateway by default, but can allow access for a specific account if needed.

4. Blast Radius Containment: microAccounts provides the ability to create safety boundaries. This is in the event of any stability and security issues, they stay isolated within that specific application (AWS account) and they don’t affect operations of other applications.

5. Cost Attributions: Clearly defined account ownership provides a simple and straightforward way to attribute costs to a specific team, project, or product. They don’t have to enforce the tagging individual resources for cost purposes. AWS account acts like an application resource group so all resources in the account are implicitly tagged.

6. Account Notifications & Operations: Single threaded account ownership allows FactSet to automatically relay any required notification to right developers. Moreover, given that account ownership is fundamental in defining who is allowed access to the account, there is a high level of confidence in the validity of this mapping as opposed to relying on just tagging.

7. Account Standards & Extensions: we manage microAccounts through a CI/CD pipeline which allows us to standardize and extend without interruptions. For example, all their microAccounts are provisioned with a standard AWS Key Management Service (AWS KMS) key, an AWS Backup Vault and policy, private Amazon Route 53 zone, AWS Systems Manager Parameter Store with network information for Terraform or AWS CloudFormation templates.

Figure 2 – Tagging strategy

8. Developer Experience: microAccount automation and guardrails allow developers to get started quickly instead of spending time debugging things like correct SCP/IAM permissions and more. Developers tend to work across multiple applications and their experience has improved as they have a standard set of expectations for their AWS environment. This is particularly useful as they move from application to application.

Access and permissions for microAccounts

FactSet creates every AWS account with a standard set of IAM roles and permissions. Furthermore, each account has its own SCP which defines the list of services allowed in the account. Based on application needs, they can extend the permissions. Interactive roles are mapped to an ActiveDirectory (AD) group, and membership of the AD group is managed by the development teams themselves. Standard roles are:

DevOps Role – Interactive role used to provision and manage infrastructure.
Developer Role – Interactive role used to read/write data (and some infrastructure)
ReadOnly Role – Interactive role with read-only access to the account. This can be granted to account supervisors, product developers, and other similar roles.
Support Roles – Interactive roles for certain admin teams to assist account owners if needed
ServiceExecutionRole – Role that can be attached to entities such as Lambda functions, CodeBuild, EC2 instances, and has similar permissions to a developer role.

Figure 3 – IAM Role Privileges

Networking for microAccounts

FactSet leverages AWS Resource Access Manager (RAM) to share appropriate subnets with each account. Each microAccount provisioned has access to subnets by sing AWS Shared VPCs. They create a single VPC per business unit per environment (Dev, Prod, UAT, and Shared Services) in each region. RAM enabled them to easily and securely share AWS resources with any AWS account within their AWS Organization. When an account is created they allocate appropriate subnets to that account.
They use AWS Transit Gateway to manage inter-VPC routing and communication across multiple VPCs in a region. They didn’t want to limit our ability to scale up quickly. AWS Transit Gateway is a single place to land their AWS Direct Connect circuits in each Region. It provides them with a consolidated place to manage routing tables that propagated to each VPC when they are attached.

Figure 4 – VPC Sharing for microAccounts

Automation & Config Management for microAccounts

To create frictionless self-service cloud infrastructure early on, FactSet realized that automation is a must. Their infrastructure automation uses source-control as a source of truth for defining each microAccount. This helps them ensure repeatable and standardized account provisioning process, as well as flexibility to adjust specific settings and permissions on per account needs.

Figure 5 – Account provisioning flow

By default, their accounts are only enabled in a small set of Regions. They control it via the following policy block. If they add new Region(s), they would implement that change in source-control and automated enforcement checks would add it to SCP.

{
    "Sid": "DenyOtherRegions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
        "StringNotEquals": {
            "aws:RequestedRegion": ["us-east-1","eu-west-2"]
        },
        "ForAllValues:StringNotLike": {
            "aws:PrincipalArn": [
                "arn:aws:iam::*:role/cloud-admin-role"
    }
}

Lessons Learned

During their journey to adopt microAccounts, FactSet came across some new challenges that are worth highlighting:

IAM role creation: Their DevOps Role can create new IAM roles within the account. To ensure that newly created role complies with least-privilege principles, they attach a standard permission boundary which limits its permissions to not extend beyond DevOps level.
Account Deletion: While AWS provides APIs for account creation, currently there is no API to delete or rename an account. This is not an issue since only a small percentage of accounts had to be deleted because of a cancelled project for example.
Account Creation / Service Activation: Although automation is used to provision accounts it can still take time for all services in account to be fully activated. Some services like Amazon EC2 have asynchronous processes to be activated in a new account.
Account Email, Root Password, and MFA: Upon account creation, they don’t set up a root password or MFA. That is only setup on the primary (master) account. Given each account requires a unique email address, they leverage Amazon Simple Email Service (Amazon SES) to create a new email address with cloud administrator team as the recipients. When they need to log in as root (very unusual), they go through the process of password reset before logging in.
Service Control Policies: There were two primary challenges related to SCPs:
- SCP is a property in the primary (master) account that is attached to a child microAccount. However, they also wanted to manage SCP like any other account config and store it in source-control along with other account configuration. This required IAM role used by our automation to have special permissions to be able to create/attach/detach SCPs in the primary (master) account.
- There is a hard limit of 1000 SCPs in the primary (master) account. If you have a SCP per account, this would limit you to 1000 microAccounts. They solved this by re-using SCPs across accounts with same policies. Content of a policy is hashed to create a unique SCP identifier, and accounts with same hashes are attached to same SCP.
Sharing data (typically S3) across microAccounts: they leverage a concept of “trusted-accounts” to allow other accounts access to an account’s resources including S3 and KMS keys.
It may feel like an anti-pattern to have resources with static costs like Application Load Balancers (ALB) and KMS for individual projects as opposed to a shared pool. The list of resources with a base cost is small as most of the services are largely priced based on usage. For FactSet, resource isolation is a key benefit of microAccounts, and therefore outweighs some of these added costs.
Central Inventory & Logging: With 100s of accounts, it is worth investing in a more centralized inventory and AWS CloudTrail logs collection system.
Costs, Reserved Instances (RI), and Savings Plans: FactSet found AWS Cost Explorer at the level of your primary (master) account to be a great tool for cost-transparency. They leverage AWS Cost Explorer’s API to import that data into their internal cost transparency tools. RIs and Savings Plans are managed centrally and leverage automatic sharing between accounts within the same master (primary) organization.

Conclusion

The microAccounts approach provides FactSet with the agility to operate according to specific needs of different teams and projects in the enterprise. They are currently deploying in twelve AWS Regions with automated AWS account provisioning happening in minutes and drift checks executing multiple times throughout the day. This frees up their developers to focus on solving business problems to maximize the benefits of cloud computing, so that their business can innovate and accelerate their clients’ digital transformations.

Their experience operating regulated infrastructure in the cloud demonstrated that microAccounts are pivotal for managing cloud at scale. With microAccounts they were able to accelerate projects onboarded to cloud by 5X, reduce number of IAM permission tickets by 10X, and experienced 3X fewer stability issues. We hope that this blog post provided useful insights to help determine if the microAccount strategy is a good fit for you.

In their own words, FactSet creates flexible, open data and software solutions for tens of thousands of investment professionals around the world, which provides instant access to financial data and analytics that investors use to make crucial decisions. At FactSet, we are always working to improve the value that our products provide.

Field Notes provides hands-on technical guidance from AWS Solutions Architects, consultants, and technical account managers, based on their experiences in the field solving real-world business problems for customers.

AWS Architecture Blog