Welcome to another episode of 'Back To Basics'.
I'm Akash Bhatia,
and today we will be looking at architecting for private workloads.
The Cloud has fundamentally changed the way the applications are designed and developed
by making resources available on demand and via the Internet.
However, there are certain niche use cases
that have an inherent requirement to be private and not be accessible over shared domains.
These workloads can range from security and defense,
to finance, to personal health.
In this video, we will look at some of the principles and patterns,
on how to architect for such unique workloads.
Let's start by reviewing some of the unique aspects required by these workloads.
The sensitive nature of these workloads and often related regulatory guidelines
mandate enterprise-level controls and boundaries.
Designing for non-public connectivity and enhanced real-time maintainability
via centralized monitoring and auditing.
In order to realize these, the three fundamental foundational pillars are:
structuring management and governance
through AWS Organizations and organizational units, or OUs,
enabling control through Policy Control Mechanisms
ranging from guardrails like service control policies
and IAM permission boundaries
to grants such as resource-based policies and access control lists,
and quick nationalization through Cloud Enabled Native services
like AWS PrivateLink and Amazon AppFlow.
With that, let's dive deeper into what an end-to-end architecture would look like.
We start with one of the foundational management and governance services, AWS Organizations.
AWS Organizations allows to centrally manage and govern your environment,
and to scale your AWS resources
whether through problematic APIs or workflow organization.
It is an account management service
that lets you consolidate multiple AWS accounts into an organizational unit.
With Organizations, you can create a new member account
or invite existing accounts to join your organization.
You can organize those accounts into groups
and attach centralized or specialized policy-based controls to these groups.
In our architecture, we have three OUs:
foundation infrastructure, which is horizontal across the organization,
and houses centralized logging, security and network services.
Second is a public workload organizational unit
which usually houses generic workloads that do not require the same sensitivities.
And, finally, we have private workload OUs, which house sensitive applications
divided by respective categories.
To simplify governance at scale, AWS provides AWS Control Tower.
AWS Control Tower provides the easiest way to set up and govern
a secure multi-account AWS environment called a Landing Zone.
It creates your landing zone using AWS Organizations,
providing ongoing account management and governance,
and implements best practices based on AWS's experience
of working with thousands of customers.
The advantage of using AWS Organizations and organizational units
is that it allows for application of policies at a higher level.
One such example of organizational policies is via service control policies
which can be applied at the Organization Root,
organizational unit, or even at individual accounts.
These differ from IAM policies
which are usually applied to users, groups, or roles,
and hence provide for standardization across enterprise structures.
Now let's dive deeper into some of the cloud native services
we discussed earlier.
AWS PrivateLink provides for private connectivity
between virtual private clouds, or VPCs,
other AWS services, and on-permise networks,
without exposing your traffic to the public Internet.
AWS PrivateLink makes it easy to connect different services
across multiple accounts and VPCs
to significantly simplify your network architectures.
Amazon AppFlow automates data flows
by securely integrating third-party applications
and AWS services without code,
usually between SaaS services like Salesforce,
SAP, Slack, and ServiceNow,
and AWS services like Amazon S3 and Amazon Redshift.
AppFlow automatically encrypts data in motion,
and allows users to restrict data
from flowing over the public Internet for SaaS applications
that are integrated with AWS PrivateLink,
thereby reducing exposure to security threats.
In this episode, we explored how to architect
for such private workloads which demand more granularity
and control over how they're architected.
These practices help significantly reduce the security threats
for such applications.
As always, security is job zero at AWS.
Check out the links below for more details.
Thanks for watching 'Back To Basics'.
See you next time.