TIC 3.0 architecture migration for federal agencies using AWS Transit Gateway

Federal agencies operating in the cloud face a challenge with Trusted Internet Connection 2.0. All internet traffic must backhaul through on-premises infrastructure, creating bottlenecks that limit cloud adoption and degrade performance. The TIC 3.0 initiative addresses this by enabling agencies to implement security controls directly in the cloud, providing secure internet connectivity for federal workloads, including web browsing, perimeter network deployments, and data exchange between on-premises data centers and cloud environments.

In this post, we show you how to migrate from TIC 2.0 to TIC 3.0 architecture using AWS Transit Gateway while minimizing operational disruption. By implementing this migration, federal agencies can reduce latency, improve security posture, and more easily meet their compliance needs with Cybersecurity and Infrastructure Security Agency (CISA) requirements.

Understanding the TIC 3.0 shift

The TIC initiative, established in 2007 by CISA, has evolved to meet the demands of modern cloud architecture. TIC 2.0 required all federal traffic to route through consolidated access points with EINSTEIN sensors, essentially routing all traffic using on-premises data centers.

The following figure shows a typical TIC 2.0 implementation, where all the internet inbound and outbound traffic is routed through the on-premises data center.

Figure 1: A high-level typical TIC 2.0 architecture

TIC 3.0 represents a shift to an outcomes-based model that focuses on five core security objectives rather than prescriptive controls, as outlined in the reference architecture in the CISA TIC 3.0 Core Guidance Documents:

1. Manage traffic – Observation and filtering through policy enforcement points (PEPs)
2. Protect traffic confidentiality – Ensuring only authorized parties access data in transit
3. Protect traffic integrity – Preventing and detecting alterations
4. Ensure service resiliency – Continuous operation and availability
5. Ensure effective response – Responding to discovered threats

This approach gives agencies flexibility to implement security controls that align with their specific risk tolerance and operational requirements. Through TIC 3.0, agencies can use cloud-based security services such as AWS Network Firewall, AWS WAF, and Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, rather than relying on traditional on-premises security appliances. As a result, agencies can take advantage of the scalability, automation, and continuous updates that cloud-based services provide.

TIC 3.0 key concepts

TIC 3.0 introduces architectural concepts that differ from the traditional perimeter-focused model. PEPs are locations where security capabilities are applied. In this architecture, PEPs are the inspection virtual private clouds (VPCs) with Network Firewall or Gateway Load Balancer. Network Firewall is a stateful, managed, network firewall and intrusion detection and prevention service for your virtual private cloud (VPC) that you create in Amazon VPC. Trust zones represent segmented network areas with defined security levels. Each VPC represents a trust zone with specific security requirements. The framework divides security capabilities into universal (enterprise-level) and PEP (network-level) capabilities. These capabilities map to AWS services.

This distributed approach changes how agencies implement security controls. Instead of routing all cloud traffic through on-premises TIC access points, TIC 3.0 enables distributed policy enforcement across multiple PEPs. Agencies can deploy security capabilities closer to their workloads, reducing latency while maintaining robust security protections and align to federal compliance requirements.

Prerequisites

Before beginning your migration, ensure your environment is prepared. You need the following required access and planning:

• AWS account with AWS Identity and Access Management (IAM) permissions for Transit Gateway, Amazon VPC, AWS Direct Connect, and Network Firewall operations
• Non-overlapping CIDR ranges for new Amazon VPC resources to avoid routing conflicts
• Documented Direct Connect configuration, including Border Gateway Protocol (BGP) autonomous system number (ASN), allowed prefixes, and connection IDs
• Network diagram of current TIC 2.0 architecture
• Detailed Amazon VPC inventory with dependencies and communication patterns

Inspection Amazon VPC architecture options

Select the right inspection architecture based on your security requirements and operational model:

• Separate inbound and outbound inspection VPCs – Deploy dedicated VPCs for outbound and inbound traffic. Recommended for agencies requiring strict traffic flow separation and clear compliance demarcation points.
• Combined inspection Amazon VPC – A single Amazon VPC handles both inbound and outbound traffic. This is ideal for simplified management with one set of security policies and a single monitoring point.
• Distributed inspection – Deploy inspection in each VPC. This is suited for workload-specific compliance requirements or maximum application isolation.

Implement inspection using AWS Network Firewall or partner firewalls with Gateway Load Balancer for advanced features. For implementation details, review Deployment models for AWS Network Firewall in the AWS Networking & Content Delivery Blog.

A simplified parallel approach to migration strategy

A phased migration approach provisions a new Transit gateway with TIC 3.0–compliant security controls, establishes peering with the legacy environment, and gradually migrates VPCs one at a time.

The implementation requires these steps. In the target architecture, create a new transit gateway with appropriate route tables for inbound, outbound, spoke, and inspection traffic. Deploy your chosen inspection VPC architecture (separate, combined, or distributed) with AWS Network Firewall or Gateway Load Balancer. By directing internet access through an internet gateway, you eliminate the need to route traffic through on-premises infrastructure. Transit Gateway peering enables connectivity during migration, with Direct Connect integration deferred until completion.

Figure 2 shows an intermediary state architecture with two Transit gateways for simplified migration.

Figure 2: Intermediary state architecture

Four-step migration process

The migration follows four steps, each designed to minimize risk while maintaining connectivity.

Design and provision new transit gateway
Use the following configuration to design and provision a new transit gateway:

• Choose a unique Amazon-side ASN (amazonSideAsn) that is different from the existing transit gateway and Direct Connect gateway to avoid routing conflicts
• Enable DNS support for cross-VPC name resolution
• Disable default route table auto-association and propagation for better routing control

Create the following route tables:

• Inbound – Handles traffic from on premises (after the Direct Connect migration)
• Outbound – Manages internet-bound traffic
• Spoke – Facilitates VPC-to-VPC communication
• Inspection – Directs traffic through security controls based on your chosen architecture

Build central inspection VPCs
Deploy inspection VPCs across multiple Availability Zones for high availability. Create subnets for Transit Gateway attachments (minimum /28) and deploy firewall endpoints in dedicated inspection subnets. Enable VPC Flow Logs for detailed logging.

Configure route tables according to your inspection strategy (refer to AWS Network Firewall deployment models). Route internet traffic directly through the internet gateway. Deploy NAT gateways in public subnets (one per Availability Zone) with Elastic IP addresses. NAT Gateway charges are waived for traffic processed by Network Firewall endpoints.

Establish Transit Gateway peering for on-premises connectivity

Create a peering connection between your new TIC 3.0 transit gateway and the existing TIC 2.0 transit gateway. This temporary bridge allows migrated VPCs to reach on-premises resources through the old transit gateway’s existing Direct Connect connections.

Configure routes in both transit gateways. Add routes to on-premises CIDRs through peering in the new transit gateway and add routes to new VPC CIDRs through peering in the old transit gateway. Because Transit Gateway peering supports static routes only, plan advertisements carefully to avoid routing loops. The peering connection will be removed after Direct Connect association.

During migration, internet-bound traffic has the following flow:

1. VPC
2. New transit gateway
3. Inspection VPC
4. NAT gateway
5. Internet gateway

On-premises traffic has the following flow:

1. VPC
2. New transit gateway
3. Inspection VPC
4. Peering
5. Old transit gateway
6. Direct Connect
7. On premises

Migrate VPCs and associate Direct Connect

For each VPC, document current routing, identify dependencies, and prepare rollback procedures. Create a transit gateway attachment in the new environment and update VPC route tables with a default route (0.0.0.0/0) to the new transit gateway. Keep existing routes to the old transit gateway for quick rollback if needed.

Test connectivity by verifying internet connectivity, on-premises connectivity through peering, and security controls through firewall logs. Monitor VPC Flow Logs and Transit Gateway metrics (for example, BytesIn, BytesOut, and PacketDropCount). Complete cutover by removing old Transit Gateway routes, deleting the old attachment, and documenting lessons learned.

After VPC migration, associate Direct Connect

After all the VPCs are migrated, document current Direct Connect gateway associations, plan a maintenance window, and notify stakeholders of expected impact. During the maintenance window, disassociate the old transit gateway from your Direct Connect gateway and associate the new transit gateway. Update allowed prefixes (up to 200 per Transit Gateway association) and wait up to 60 seconds for route propagation.

In the new transit gateway, remove the static routes for on-premises CIDRs that point to the peering attachment, then enable route propagation for the Direct Connect gateway attachment. This automatically installs the on-premises prefixes learned via BGP through Direct Connect. Validate connectivity by testing from migrated VPCs to on-premises resources, verifying BGP session status, and confirming application functionality.

Quick rollback procedure

If issues arise during the Direct Connect cutover, quickly restore connectivity by disassociating the new transit gateway from the Direct Connect gateway and reassociating the old transit gateway with the Direct Connect gateway. Re-add the peering-based routes in the new transit gateway to restore temporary on-premises connectivity through the peering connection. By doing this, you can maintain VPC connectivity to on premises while troubleshooting the Direct Connect issue. After it’s resolved, repeat the Direct Connect association process.

Decommission legacy infrastructure

After validating Direct Connect connectivity, decommission the legacy infrastructure. Verify there are no traffic flows on the old transit gateway by reviewing Amazon CloudWatch metrics for an appropriate period to confirm nothing was missed. Remove the Transit Gateway peering connection, delete all old Transit Gateway attachments (including the VPC, Direct Connect gateway, and the VPN), and delete the old transit gateway. Update all documentation to reflect the new architecture.

The following diagram shows the target state TIC 3.0 architecture.

Figure 3: Target state TIC 3.0 architecture

Benefits of this simplified approach

Benefits of the TIC 3.0 architecture for federal agencies include reduced complexity, minimized risk, enhanced security, and improved performance and operational efficiency.

Peering provides temporary on-premises connectivity, with Direct Connect association occurring after VPC migration. This clear traffic separation, where the internet is accessed through the internet gateway and on-premises infrastructure is accessed through peering, reduces routing conflicts and simplifies troubleshooting.

Both environments run simultaneously during migration, allowing gradual VPC-by-VPC cutover with validation at each step. Issues are caught early, and quick rollback capability means problems affect only the VPC being migrated, not your entire environment.

All traffic flows through centralized inspection points with multiple security layers including Network Firewall, Gateway Load Balancer, and AWS WAF. Enhanced logging supports security operations while meeting TIC 3.0 objectives and zero-trust principles.

Eliminating backhaul latency for internet traffic provides immediate performance gains. Transit Gateway supports up to 100 Gbps per VPC attachment per Availability Zone, with auto scaling security services and optimized routing.

Centralized security policy enforcement reduces complexity by eliminating on-premises components. Cost optimization removes unnecessary data transfer charges, and  infrastructure as code (IaC) support enables consistent deployments.

Validating TIC 3.0 compliance

After migration, validate compliance with TIC 3.0 security objectives:

To manage traffic:

• Verify VPC Flow Logs capture all traffic
• Confirm Network Firewall rules enforce policies
• Test Transit Gateway route table configurations

To protect confidentiality and integrity:

• Enable encryption in transit using TLS or Internet Protocol Security (IPsec)
• Validate certificate management
• Test data integrity controls

To provide resiliency:

• Verify multi-AZ deployment
• Test failover scenarios
• Confirm backup connectivity paths

To enable effective response:

• Configure CloudWatch alarms
• Test incident response procedures
• Validate log aggregation to CISA Comprehensive Log Aggregation Warehouse (CLAW) (if required)

Considerations

• For Transit Gateway design best practices, refer to the Transit Gateway best practices documentation
• Agencies with simpler architectures (a small number of VPCs using Private VIFs and Direct Connect Gateway) can implement TIC 3.0 security controls using the distributed inspection model without Transit Gateway
• If you’re transitioning towards IPv6, review the IPv6 considerations for TIC 3.0
• To complement TIC 3.0, use newly introduced VPC security features such as VPC Block Public Access, VPC Encryption Controls, and AWS WAF automatic application layer DDoS protection

Conclusion

If your agency is planning a TIC 3.0 migration, start by assessing your current TIC 2.0 architecture and engaging your AWS account team to design your target architecture. Develop a migration plan with timelines and success criteria, then conduct a pilot project with a nonproduction VPC before migrating critical workloads.

This simplified migration approach helps federal agencies modernize their network security, reduce latency, and maintain TIC 3.0 compliance while minimizing operational disruption. For additional guidance, refer to the CISA TIC 3.0 Documentation, AWS TIC 3.0 Overlays, AWS Transit Gateway documentation, and the AWS Public Sector Blog.

By embracing TIC 3.0 and using AWS Transit Gateway with this simplified migration approach, federal agencies can build secure, scalable, and modern network architectures that support their missions while helping meet federal security and compliance requirements.