Skip to main content

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Share your experience with the FAS IT-Playbook by taking this brief survey

Separate Accounts for Serverless

This content provides a basis for understanding the features that accounts provide to a Serverless solution, as well as to examine the use of multiple accounts as a means of both segregating work and providing security boundaries for that work.

Accounts vs. Environments

Accounts are not equivalent to environments. There are many ways to define a software environment, so starting with a typical definition:

An environment contains infrastructure for the execution of an instance for a specific purpose defined in terms of the Software Delivery Life Cycle.

An account, on the other hand, is a more encompassing larger concept that can hold multiple instances of the software, and therefore could contain multiple environments. The account does provide a security boundary, however, and it is this boundary that is most important in terms of providing separation of concerns within a Serverless solution.

The separation of accounts is intended to provide a means to:

It is worth pointing out the distinction between these last two points, as there are differences from a security perspective as to how content must be protected. Ultimately, it is just as important to protect the work of others from something gone wrong within your boundary as it is to protect yourself from something gone wrong within another's boundary.

As stated before, teams could choose to create multiple environments within a single account. This is a viable approach with many use cases and should be supported by a generalized Serverless solution. All of the environments within a multi-environment account would then be subject to the same security boundary at the account level, as well as contain their own boundaries within the account, based upon how the environments are defined by the team. The account boundary still provides a bulwark around the collected environments for security purposes.

Account Types

Although the Serverless solution should not provide an opinion as to how environments are to be organized and managed, there are standards that should be adhered to with respect to the usage of accounts.

While there may be many ways to use various accounts, this solution proposes a basic (although adaptable) topology for accounts and their creation. This fundamental organization provides a means to build a set of standard tools and solution components; the areas specifically left undefined within the topology are presented to provide a means by which tenants may customize the usage of their accounts to support their application's functional needs as well as to accommodate their desired SDLC processes. Areas where the topology is defined are designed to facilitate the use of standardized solution components to aid in the development of software solutions and the infrastructure needed to support them. Standardized solution components are designed to support specific needs in as generalized a process as possible, in an attempt to allow tenants to tailor SDLC processes to their particular needs. This provides a minimum base value to tenants, while allowing for the inevitable variation that each tenant needs to support the specifics of their system needs.

It is expected that tenants will have a minimum three accounts:

  1. The tenant's Management Account will contain all solutions that need to support across the tenant's other accounts
  2. A Production Account will be used to secure all production activities
  3. Development and Testing activities will happen in lower tier accounts; the tenant will engage FCS with an understanding of how they plan to structure their SDLC practice, and how this will affect their account usage

As long as tenants adhere to this general account usage pattern, common solution components constructed to support the most-common and most-frequently used solution and usage patterns will be applicable.

When a tenant has a need that is not supported by a solution component already available, they are free to develop their own, provided that they adhere to the requirements set forth by Security Engineering. Foundational resources will be provided to act as a basis for these custom solutions, providing the benefits of standardization to the tenant's customization efforts. It is the hope that tenants will contribute solutions not previously present to the community at large. If a tenant does not possess the capability to construct a solution, they may address the community as a whole to negotiate the creation of an adequate solution.

Management Account

The Management Account (also known as a Shared Services account) contains activities that span all other tenant accounts.

Activities that typically span the accounts include:

The use of a separate Management account provides a top-level security boundary that segregates work that supports the management of the entire SDLC process implementation from all other environments, that will hold various versions of software product "payload" being developed.

It is key to understand the distinction between the work done in support of software under development, and the target software itself. Of course, there are components that will need to be deployed within each account managed via the solutions deployed within the Management account, however these components are minimal, and act as extensions or endpoints for the workflows executed within the Management account.

Lower Tier Account(s)

Lower Tier accounts provide a workspace for all SDLC stages of the software product prior to the release to Production. As previously stated, all work could be contained within a single account, or within separate accounts, as per the needs and design of the tenant's SDLC process implementation.

Typically, there may be two accounts -- Development and Test -- each acting as a segregated workspace for one or more environments that support the Development and Test SDLC phases respectively. There could be more accounts, however, as determined by the needs of the product in development and the processes that support it.

Additional activities that are likely to happen within one or more lower tier accounts include (but are not limited to):

As discussed in the management account section, lower tier accounts will need common hooks established within them to support the management solutions executing in the management account. Typically, these would be components that define the levels of access for developers or allow the pipelines in the management account to deploy into a lower tier account.

Production Account

The Production Account is where the production version of a tenant's software system is to execute. The boundary around the production version of a tenant's software is of a critical nature, as software running within this boundary has access to the tenant's true data, and may also have access to other production software systems within GSA and beyond. The Production Account provides a natural security boundary around a tenant's production activity.

Activities within the Production Account may support more than one environment; for that reason, the solution must also provide flexibility as to how even the Production Account is used. This could be the use of a Blue/Green or Canary deployment processes, or other similar processes that would require more than one environment to be hosted within the account.

Production Deployment Strategies

Blue/Green Deployment Strategy

In the Blue/Green deployment strategy, two identical production environments are maintained called Blue and Green. At any given time only one production environment is live.

For example, if blue is currently live, all the production traffic will be routed to that environment and green will be idle. New application version will be deployed to green for final testing in the production account. If no issues are found, all the production traffic will be routed to the green environment. Now the blue one is idle.

Benefits of this strategy are listed below.

  1. Reduced risk of deployment. Ability to quickly rollback. (In the above example if anything goes wrong with the new version, Tenants can easily roll back to the previous version by switching back to blue).
  2. Eliminates downtime due to application deployment.

Canary Deployment Strategy

Canary Deployment strategy can be referred to as phased rollout or incremental rollout. In this strategy, a new version of the application is rolled out incrementally to a smaller subset of users before rolling it out to all the users.

Benefits of this strategy are listed below.

  1. No downtime upgrades and easy rollbacks.
  2. Failures have limited impact. More control over release.

While it is quite possible that most tenants will opt to manage a single Production environment within their Production account, the capability of a Production account to support more than one environment provides flexibility to support solutions to unforeseen circumstances, as well as supporting a number of varied solutions that could require multiple instances of software to be segregated by namespace, such as what might be needed to support multiple versions of a product not initially intended or designed to support simultaneous deployment of different versions.

Support for Multiple SDLC Strategies

As stated previously, an account does not equate to an environment -- at least not inherently. Tenants may have reason to use their accounts in slightly different ways, as they deem necessary, in order to support the specifics of their Software Development Life Cycle (SDLC) strategy implementation. How a tenant defines and supports SDLC with their tooling is a reflection of how each SDLC subprocess supports their organization and is determined by the needs of the selected technology and how that technology is used to support the application's business functionality. Because of this highly variable nature, no one-size-fits-all SDLC solution would be capable of supporting all aspects of GSA's enterprise. As a compromise, FALCON Serverless Compute Model solutions are designed modularly, allowing them to support a number of potential SDLC implementations across a wide variety of account usage scenarios.

From an implementation perspective, an environment is defined by usage. A repository branch deployed to a set of resources in the context of a namespace for a given purpose collectively defines an environment. How the tenant determines to define and use these elements is up to them.

An environment can be statically defined (pre-defined purpose tied to a namespace and a code branch (or branch naming convention, depending upon the tenant's branching strategy) and associated with a pre-defined deployment namespace), or an environment can dynamically defined (the purpose determined at the time of need, associated with a code branch

The purpose of a namespace within deployment is to ensure that when versions of the same or similar code are deployed, they do not have resource naming conflicts. The foundational components provided facilitate the use of a deployment namespace and automate the resource naming in accordance with the namespace value provided by the tenant. The use of deployment namespaces is what allows an account to hold more than one instance of a deployable unit, and thereby hold more than one instance of the application.

Promotion and subsequent deployment into higher environments that have been defined in this manner is triggered through the merging of code into branches; when a pipeline associated to a branch detects the changes on the branch, it is triggered to deploy the code into its associated resources (or to provision them if they do not yet exist).

Details on pipeline configuration and usage can be found in the Jenkins CI/CD Pipeline approach. Details on the capabilities and utilities provided by the FALCON Serverless Compute Model Foundational Architectural Components can be found in the Secure Reusable Application Architecture Patterns approach. Details on repository definition and usage and the implications of different repository strategies can be found within the Code Repository Organization approach.

Account Usage by SDLC Strategy

The following are brief discussions of how various strategies may require a tenant to use their lower tier account(s) in various ways, and how each use case relates to the usage of the four defining features for an environment:

  1. Purpose
  2. Code Branch
  3. Namespace
  4. Resources

These are examples only, with additional variation possible. In all examples, the Management account has been left out for simplicity.

One Environment per Account

The pipeline definition for each environment is simplified by not having to handle dynamically defined environments; this is because the namespace and the code branch are predetermined. In this example, we also see that the tenant chose to use the Account boundary as an additional barrier between their environments, requiring that each account only contain a single environment. We also see the inclusion of an environment (and subsequently an account) for the purpose of Integration, possibly used to test feature interactions across up-stream and down-stream systems.

The simplest scenario is where the tenant defines a single fixed environment within each of their accounts. In this case, the tenant has defined their pipelines to deploy to statically defined environments. Even though the environment is defined statically, there is no requirement that content be deployed within a given environment unless there is a need; the deployment name space and the code branch are predefined and dedicated to a set purpose that aligns to the tenant SDLC process.

Accounts Grouping Similar Predefined Environments

In this use case, we see that each account supports multiple environments. The environments are still fixed, in that they are statically defined; each environment associates a specific code branch to a namespace for a specific purpose and will result in a single set of resources associated with the environment.

The Development Account has two development environments (Dev 1 and Dev 2), and a single Unit Test environment, against which unit test automation is executed.

The accounts are used to group similar activities, as the same groups of people who need access to one environment within the account would also likely need access to the other environments in the account. The account still acts as a boundary, grouping similarly risky activity within a single security boundary, protecting other environments defined in other accounts.

We can see a greater diversification within the environments within the Test Account. Here, the environments are also tied strictly and statically to specific activities within the tenant's SDLC strategy implementation. The tenant has an environment dedicated to running End-to-End (E2E) testing for adherence to requirements as well as regression, in addition to an environment used for integration with other applications. We also see the addition of an environment for hosting UAT sessions against stable release-candidate code. As with all of the environments described before, there is no reason for resources to be provisioned unless there is content ready to be housed within the environment; the environment exists as a pipeline configuration with deployment namespaces and source code branches predefined and ready for use in support of a specific purpose. The actual resources will only be provisioned when the code is ready to be deployed in support of each environment's purpose.

We also see that within the Production account, the tenant has chosen to house an additional Staging environment. Both the Staging and Production environments have similar access restrictions, so it made sense to house them within the bounds of the same account. This illustrates that even the Production account need not be restricted to a single environment.

Accounts Grouping Similar Ad Hoc Environments

At first glance, this example looks very similar to the previous examples discussed; the difference lies in how the environments are defined, however. In this example, the pipelines have been configured to support ad hoc or dynamically defined environments -- environments that are defined when they are needed, and then destroyed when the work is done. The benefit is that the tenant can create environments specific to their current needs.

Because the tenant is creating the environments as they need them, each environment is created for a specific purpose that may or may not directly align with traditional SDLC phases. Instead, deployment namespaces are created to describe the more specific work that each environment is being used for, as are the code repository branch names.

In this example, we see that the tenant is working towards two releases concurrently, while also providing environments for experimental or change-specific work (the three smaller environments named for their software change requests).

This use case can easily be combined with the previous use cases that use pre-defined deployment namespaces and code branches, to provide a means to support more experimentation and process variation, while still supporting a rigorously executed promotion and deployment process.As seen previously, the account boundaries are being used to aggregate similar work, on the basis of the level of access needed, even though the environments are defined ephemerally.

Single Lower Tier Account for All Lower Environments

Here, the tenant has a single lower tier account. The environments within are depicted as being dynamically defined, however they could just as easily be statically defined. The fundamental difference is how the environments are aggregated within the account; in this example, all lower-tier SDLC activities require the same access or are deemed to be at the same level of risk.

This use case can support all of the same scenarios previously mentioned, with the exception of being able to provide a strict boundary between environments supporting development and test related work.

Connecting to Resources

The application content that will ultimately be deployed within an account will need to connect to resources not defined within the deployable unit's Stacks. Resources needing to be connected to fall into one of two forms:

Intra-application Communication

Your Lambda Functions will natively communicate with each other through the AWS network, as long as they have permission to invoke one another. The GSA Standard Application Component Library will provide support to facilitate the permission and communication of your resources to each other.

Intersystem Communication

When an application needs to access a system or resource that lives within the GSA Network, routing has to go through the appropriate firewalls. One of the primary functions of the VPC within each tenant account is to act as a basis for secure network communication. A portion of the network configuration within an account is standardized or based upon a tenant's initial cloud enablement discussions.

Function-as-a-Service implementations via AWS Lambda Functions do not natively communicate through the VPC, however they can be configured to use a VPC Endpoint, which facilitates communication between the Lambda Function and resources within the VPC without passing through the Internet. Endpoints can then be used to connect the Lambda Function to other network resources within the VPC that connect back to the GSA Network, thereby allowing communication between the Lambda Function and other resources only accessible via the VPC. In addition to this pattern, tenants may need to use additional techniques to identify and manage access to resources from their application component stacks. FALCON Serverless Compute Model provides multiple implementations that can facilitate the management of tenant resource connectivity, as well as providing foundational components usable in custom access schemes.

In Summary

Accounts provide a critical boundary for security and the separation of responsibilities. There are a minimum of three accounts that a FALCON Serverless Compute Model tenant will have. They will be used for Management, Production, and Lower Tier activities. As long as tenants divide their account activities along these divides, then FALCON Serverless Compute Model solutions will be usable within their accounts.

Lower Tier account(s) can be used in many ways, as befits the tenants' needs in the support of their SDLC processes and application. The solutions and solution components provided make few if any assumptions as to how a tenant will use their accounts, beyond the most fundamental considerations (i.e. segregation of Management and Production responsibilities from Lower Tier responsibilities).

How a tenant chooses to use their accounts beyond these basics is up to them. However, the decisions a tenant makes have ramifications as to how other problems can be solved, and how FALCON Serverless Compute Model solutions and components can be brought to bear to solve those concerns.

FALCON Serverless Compute Model solutions and components are designed to provide best-practice support for common scenarios, provide consistent access to tools, and to implement security requirements. Please continue to explore FALCON Serverless Compute Model approaches, whitepapers, and documentation to better understand how the FALCON Serverless Compute Model can be used to support your application needs.