This Guidance helps you enable trusted communication for intellectual property (IP) design and data exchange in a secure environment. It includes a high-level architecture for well-optimized design environments to facilitate collaboration with third-party companies. Third-party companies may include foundries, independent software vendors (ISVs), and outsourced design services.
The basis of a secure collaboration chamber is a primary design chamber built in an Amazon Virtual Private Cloud (Amazon VPC).
Third-party companies develop and test their IP in their own design chambers.
To collaborate with third-party companies, create an Amazon VPC that will only be used for collaboration with infrastructure based on the primary design chamber. Create accounts, permissions, and remote desktop service endpoints for third-party remote desktops using AWS PrivateLink.
Third-party companies connect to remote desktops in the collaboration chamber using the service endpoint in their design chamber.
Third-party users can access on-premises hardware, such as emulators, using routes to an isolated virtual local area network (VLAN) through AWS Transit Gateway and Direct Connect.
When the collaboration is complete, you can delete the collaboration chamber.
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
Secure collaboration chambers allow the first-party company to work with numerous third-party companies so work can be done in parallel to achieve a faster time to market.
Collaboration on AWS allows customers to isolate design environments and separate third-party users. For example, if there is problem with an Electronic Design Automation (EDA) tool, a separate collaboration chamber is used to isolate access to only the data that is required to troubleshoot the problem with the EDA tool.
Customers can launch multiple design environments for reliability and scalability. You can provide multiple teams with secure access to the data required for the entire design workflow, and resources in the environment will scale accordingly.
Many hi-tech, electronics, and semiconductor customers have close relationships with third-party design companies and IP providers. The services in this architecture were selected to ensure collaboration across the entire workflow.
As you collaborate across multiple IP providers and third-party designers, you only have to launch the VPCs (or collaboration chambers) that are required to complete the design of the integrated circuit. Launching the minimum resources required can help you save on costs.
This architecture is scalable, allowing you to launch the exact number of collaboration chambers required to collaborate with third-party companies. This helps you avoid unused infrastructure and unnecessary resources.
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.