Build Your Cloud Foundation
To build a reliable infrastructure, we must start with a solid foundation. Our reference architecture is designed with best practices and consistent conventions to ensure it is well-architected from the ground up. As part of this process, you’ll make critical design decisions that will shape your scalable infrastructure. Next, you’ll initialize your infrastructure repository and then begin by provisioning your AWS Organizations, accounts, networks, DNS, and fine-grained IAM roles and policies. Once your foundation is complete, you’ll be ready to build a platform to deliver your applications.
AWS IAM Identity Center Integration with Single Sign-On and Permissions Structure
1 Set up your project
- Create a GitHub repository to host your infrastructure toolchain and configurations.
- Configure repository settings, enable branch protection, and add collaborators.
- Then import the DevOps Accelerator reference architecture and prepare the Geodesic toolbox image to get ready to provision your infrastructure.
- Configuration Management: Terraform DevContainer, Ansible Semaphore UI
- Identity and Authentication: Okta + AWS IAM Identity Center
- Organizations and Multi-Accounts Management
- DNS & Network Architecture
- ECS/EKS Clusters + Serverless
- Monitoring
- Alerting
- GitOps Workflows
- Release Engineering
2 Provision New AWS Organization and Accounts
- Review how DevOps Accelerator designs and manages AWS Account architectures using Semaphore and Terraform, aligning with the AWS Well-Architected Framework.
- Begin by provisioning the Terraform state backend, which is essential before provisioning and managing infrastructure with Terraform.
- Then proceed to organize the accounts into Organizational Units (OUs), apply Service Control Policies (SCPs), and configure account-level settings.
- Using an AWS Organization: seperate Accounts into Organizational Unit, tenants
- All
management accounts
are in theou-shared-services
tenant - All
security
are in theou-security
tenant
- All
- Account Boundaries: clear resource boundaries between stages
- Allow permissive roles and policies in a given account
- Isolate experimental resources from sensitive workloads
- Easily understand cost allocation for any stage
- Service Control Policies cannot be bypassed
- Account Architecture: developer experience
-
root
+ SRE accounts +ou-applications
-
root
: Organizations + Single Sign-On + CloudTrail + Terraform State -
network
: Transit Gateway + Client VPN - CloudTrail Logs? Route 53? ECR?
-
ou_sandbox
,ou_non_prod
,ou_prod
-
3 Rollout Identity & Authentication
Learn how DevOps Accelerator sets up fine-grained access control for an entire organization using IAM roles, AWS SAML, and AWS IAM Identity Center (SSO). It addresses the challenges of using various login methods and tools and introduces a solution involving Teams and Team Roles to manage access across multiple AWS accounts. This approach ensures precise control, easy role switching, and compatibility with different identity providers. Additionally, we provide a solution optimized for cross-account Terraform access, programmatic access for GitHub OIDC, and a user-friendly login experience with AWS Identity Center (AWS SSO), using tools like Leapp to facilitate seamless authentication and access management.
How to log into AWS-
Requirements & Challenges
- Accessing AWS as a Human or as a Machine User
- Centralized Management of User Permissions
- Highly Precise Control of User Groups
- Apply Terraform for many Accounts across an Organization
- Switch Roles into other Accounts easily both in the UI and Locally
- AWS Control Tower lacks APIs
- AWS IAM Identity Center is only for Humans
- AWS IAM Roles with SAML is cumbersome
-
Integrated with Single Sign-Om
- Using AWS IAM Identity Center for Single Sign-On
-
Users
are managed with AWS IAM Identity Center -
User
can access Single Sign-On with AWS IAM Identity Center
-
- AWS Teams and Team Roles
-
Permission Sets
in Identity Center grant access to a Team -
Permission Sets
also grant direct access to Accounts
- A Team is a group of Users
- A Team Role defines permissions for a given Account
- Assume Team Roles in any Account from the centralized Team
- Use the same
AWS Config
for all User Groups - Launch into DevOps DevContainer with the same
AWS Profile
- Users can only access Roles that their Team has access to assume
- Users and Groups are managed with an external Identity Provider (IdP) such as Okta
- Users and Groups are synced into AWS IAM Identity Center from the IdP via automatic provisioning
- Groups are assigned Permission Sets in AWS IAM Identity Center
-
- Using AWS IAM Identity Center for Single Sign-On
-
Setting-up Locally: Semaphore UI
4 Deploy Network VPCs & DNS
Finally, understand DevOps Accelerator’s approach to designing robust and scalable Network and DNS architectures on AWS, with a focus on symmetry, account-level isolation, security, and reusability. We cover essential topics such as account isolation, connecting multiple accounts together using Transit Gateways, deploying AWS Client VPN for remote network access by developers, and differentiating between DNS service discovery and branded vanity domains used by customers. The solution includes reusable network building blocks, ensuring consistent deployment of VPCs and subnets, accommodating multi-region global networks, and addressing special network design considerations depending on whether you'll use ECS or EKS.
[Network] Service Discovery and DNS Domains- Challenges for Network and DNS Architecture
- Snowflake network designs are overly complex, difficult to maintain
- Support both private subnets and public subnets
- Restrict access and enforce boundaries externally and internally
- Enable service discovery inside the network
- Services need to be able to discover each other using DNS
- DNS services should be isolated and secure
- Define the network with Infrastructure as Code
- Networks need to be scale with the business
- Solution for Secure and Robust Network Architecture
-
Transit Gateway
:Transit Gateway Route Table
-
Transit Gateway Attachment
: Transit Gateway Spoke in each AWS Account
-
- Solution for DNS:
- Primary vs. Delegated Service Discovery Domains
- Vanity Domains: branded, marketing domains
When you're done with your foundation, our attention will shift to how you set up your platform to deliver your apps.