Skip to main content
GSA Logo

Cloud Economics

About

FAQ

VPCaaS Tenants

How can an endpoint in a VPCaaS VPC be reached from GFE or VDI?

Connectivity to the FCS network from the VDI or GFE requires passing through the GSA on-prem firewall. Whitelist requests can be submitted to GSA Security through the Service Now portal.

How do I create a DNS record on gsa.gov dns zone?

The GSA security operation team owns and operates the gsa.gov zone. Tenants need to put servicenow ticket through their servicenow portal. Tenant will need to submit external dns record request if dns records need to be resolved from internet, internal if dns record needs to be resolved from GSA internal network only, and select type both internal & external, if it needs to be resolved from both internet and internal network.

How can a Route 53 Hosted Zone be made resolvable?

By default, VPCaaS accounts have a public and a private hosted zone provisioned in Route 53. Newer accounts have a standardized hostname, corresponding to the FCS product and the AWS account name. The private hosted zone is associated with the VPC and the centralized FCS network services VPC, enabling automatic delegation of the private hosted zone within the GSA network. However, the public hosted zone is not enabled/delegated automatically.

  • DNS records in VPCaaS R53 private zones will be automatically resolved from GSA Internal Network, VDI, GSA Data Center etc. Note that DNS resolution from GSA laptop which uses zscaler will hide real ip during dns resolution. Zscalar will present a zscaler ip like 100.34.x.x during nslookup and is not a valid test.
  • DNS records in the VPCaaS public route53 zone will not be resolved by default. Public R53 zones created in FCS VPCaaS accounts need to establish one time delegation from GSA’s public dns servers. To enable a Route 53 public hosted zone for a gsa.gov subdomain, submit an external DNS ticket for GSA SecOps through their servicenow portal.
  • If tenants needs internal or external DNS record in under gsa.gov zone like xxxx.gsa.gov, submit an DNS ticket for GSA SecOps through their servicenow portal.

For which connection type, VPCaaS tenants need to submit a firewall change request?

VPCaaS tenant need to open firewall change request to allow three major connection types.

  • To open connectivity between internet and resources/IPs hosted in FCS VPCaaS VPC.This connection goes through an external/perimeter firewall service managed by the GSA security operation team.Submit an external/perimeter firewall ticket for this type of connection request. We also recommend standard pattern for hosting external/internet facing services.
  • To open connection from FCS VPCaaS VPC to external ip and/or URL at Internet. This connection also goes through an external/perimeter firewall service managed by the GSA security operation team.Submit an external/perimeter firewall ticket for this type of connection request.
  • To open connection to/from FCS VPCaaS VPC to/from GSA internal network which includes GSA on-prem data centers, Feild Office, VDI, Mainframe environment, Zscaler, VPN etc. This connection goes through GSA’s internal firewall service managed by the GSA security operation team. Submit an internal firewall ticket for this type of connection request.

Tenants need to open external firewall change requests through SecOps servicenow portal. Note that there are various steps like approval from ISSO/ISSM, OS & Web Scanning etc before FCR ticket is fully approved for implementation. If you need help to submit FCR tickets including how to fill FCR servicenow tickets or want more information, refer to OCISO Website or contact/email SecOps firewall team (secops-fw@gsa.gov). Any coordination needed with GSA Security Teams for FCR tickets is VPCaaS tenant responsibility.

How to open web applications hosted in VPCaaS to the internet?

Below is our recommended standard pattern for opening VPCaaS web applications to the internet. All routing, firewall integration, and edge components required to adopt this pattern are pre-created in VPCaaS. If CDN is required, AWS Cloudfront can be used. WAF rules can be applied at ALB and/or Cloudfront.

Internet User---> VPCaaS Internet Gateway (IGW) ---> SecOps Firewall Endpoint ----> Public Network Load Balancer (NLB)---> Internal Application Load balancer(ALB)---> Application server/Container

Follow the general steps listed below to open web applications hosted in VPCaaS to the internet:

  1. Create four private subnets, in two different Availability Zones (AZs) assigned to your VPCaaS VPC

    • Two subnets will be used for hosting internal Application Load Balancers (ALBs) and two for hosting application servers.
    • You can identify the AZ assigned by looking at the AZs on which NAT gateways are deployed; generally these are use1-az4 and use-az6.
    • Use the IP CIDR range allocated to your VPC to create private subnets. Your VPC comes with a spare IPv4 CIDR range for letting teams create subnet sizes of their choice. If there are multiple IPv4 CIDRs associated with your VPC, use the CIDR that is not allocated to FN2 edge and TGW subnets. This is generally the first IPv4 CIDR listed (for VPCs migrated into FN2, it may be the second). Please do not allocate subnets from the IPv4 VPC CIDR used by FN2 subnets. Most VPCs have only one IPv6 CIDR. If allocating IPv6 CIDRs to your subnets, please reserve the first 30 /64 subnets for FN2 allocations.
    • Associate the precreated private route table with naming pattern “"xxxxxx-use1-az*-priv-work-rt" with private subnets. Note that routes are different for different AZs, so ensure subnets' AZs and routes match.
    • Do not modify or create your own route tables, as it impacts the traffic path and firewall integration. If custom routes are needed , please open FCS tickets.
    • Add routes for your new private subnets into FN2 Nat-Gateway and IGW route tables (for GSA firewall protected public egress traffic). See the Cloud Network's Private Subnet Routing Requirements

  2. Deploy AWS Internal Application Load balancer (ALB), in private subnet created in step #1. ALB listener should be https or port 443 for web traffic

  3. Launch servers in private subnets created in step #1, and install application. In the server's security group, create inbound rules whitelisting the ALB's security group or subnet CIDRs. Ensure the rule includes the port the application is listening on.

  4. Create target group and add application servers created in step #3

  5. Add target group to ALB, ensure servers are healthy and accessible through ALB

  6. Create a public AWS Network Load Balancer (NLB) in an existing (pre-created) protected public subnet with naming pattern “Protected-public-use*-az*”. NLB listener should be https or port 443 for web traffic.

  7. Make ALB created in step #2 the target of NLB. Make sure ALB security group allows connection from NLB subnet and NLB security group is open from internet IP range (0.0.0.0/0) on port 443

  8. Make sure application load balancer and network load balancer are healthy

  9. Note down the public ip address of NLB created in step# 6. You will use this public IP to put a firewall change request ticket with GSA SecOps as below. Firewall change request is submitted through the servicenow portal and needs approvals from your ISSO/ISSM and the GSA Security Operations (SecOps) Team

    • Source : Internet (0.0.0.0/0)
    • Destination : NLB public IP(s)
    • Port : Listener port configured on NLB in step 6 (TCP/443 for web Traffic)

Notes:

  • If you need a DNS hostname resolvable from the internet, like example.gsa.gov, then you will need to put an external DNS ticket for GSA SecOps team
  • All NLB, ALB and servers need to be configured for SSL where applicable, TLS 1.2 or above.
  • GSA SecOps will ask to have a clean OS/Web scan before approving a firewall change request for the internet-facing firewall. Ensure Nessus agents are installed and complete OS scan to save time later. If a web scan is needed, coordinate with your ISSO and GSA SecOps team.
  • WAF rules can be configured and applied on ALB, if desired.
  • For TLS/SSL connections, GSA SecOps will probably ask for an SSL private key to enable SSL inspection on the firewall before opening the firewall. Coordinate with the GSA SecOps team to exchange keys.
  • Once the firewall connection is opened, the application will be accessible from the internet using the NLB's public IPs.

What are the tagging requirements for VPCaaS tenants in FCS?

FCS asks that all AWS services have the following tags included:

Tag KeyTag Value Description
EnvironmentP,PP,T,D,S,L - corresponding to Production, PreProd, Test, Development, Sandbox or Lab
NameAWS Resource Name
POCEmailFirst.Last@gsa.gov. Must be a .gov address. It can be a team or group email address.
OrgOrganization for your app. Try to match with Github's Org.
AppYour app

Additional tags can be added. Tenants are encouraged to implement a standardized approach to tagging that suits their needs.

All tags should have the following characteristics:

- Pascal Case:  (PascalCase, CreateBy)
- Case sensitive: Name != name
- Avoid AWS-defined tags - all lowercase or beginning with "aws:"
- One Key One Value

Tags that may be helpful include: resource name, team responsible, promotion level, application, and location of Infrastructure as Code (IaC) configuration. Tags on AWS resources can also be used to define fine-grained permissions for IAM roles and users.

AWS publishes a Best Practices for Tagging AWS Resources whitepaper with additional considerations and recommendations.

Which AWS Regions are approved for use in FCS?

FCS-approved AWS regions include US-East-1 and US-West-2. By default, FCS permits access to only these approved regions.

If another region is needed, please submit a Jira request. Please note, per GSA policy, non-US regions cannot be enabled.

    On this page:
test