►
Description
Ryan Niksch (AWS) and Thatcher Hubbard (Red Hat) highlight the most common Red Hat OpenShift service on AWS (ROSA ) implementation patters. In this session they will dive into how customers are connecting to on premises workloads as well as catering for ingress and egress of their OpenShift workloads. They also discuss various AWS services which can be used to work towards repeatability and multi cluster management.
Learn more at: https://go.aws/3CtZFy0
Subscribe:
More AWS videos - http://bit.ly/2O3zS75
More AWS events videos - http://bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers — including the fastest-growing startups, largest enterprises, and leading government agencies — are using AWS to lower costs, become more agile, and innovate faster.
#redhat #openshift #redhatopenshiftserviceonaws #rosa #AWS #AmazonWebServices #CloudComputing
A
A
B
A
A
For
production
workloads,
these
exist
in
different
AWS
accounts
or
they'll
have
a
non-prod
accounts
and
they'll
have
a
production
account.
They'll
have
a
AWS
support
attached
to
that
that
is
sort
of
developer
support,
maybe
for
the
non-prod
and
they'll
have
business
or
Enterprise
level
support
for
the
production
environment,
because
these
are
in
different
AWS
accounts.
If
we
immediately
end
up
with
two
challenges,
is
it
how
do
I
Network
all
of
this
together
in
a
larger
Enterprise
context?
A
B
A
Know
when,
when
you
say
I
have
my
own
personal
routing
layer
that
is
super
shiny.
So,
let's
slap
down
a
Transit
Gateway
over
here,
I
think
to
couple
that
many
of
our
customers
are
not
just
building
a
Transit
Gateway.
They
are
also
building
in
a
shared
services,
VPC
type
environment
in
there
as
well.
So
if
we
have
a
Transit
Gateway
in
the
environment
or
just
a
tgw
right,
I'll
go
ahead
and
try
that
you
mentioned
that
was
a
router.
A
B
Right,
if,
if
someone
were
to
show
me
a
diagram
of
their
organization,
that
was
labeled,
thus
non-prodden,
prod
I
would
say
no,
probably
not,
but
often
what
you
might
see
is
different
parts
of
a
larger
organization
might
have
their
own
cluster.
Those
two
clusters
could
have
interdependencies
on
each
other
for
services.
A
B
So
how
do
we
stitch
this
all
together,
okay,
well,
we've
got
the
tgw
drawn
and
you've
hopefully
drawn
the
route
table.
Those
little
entries
in
the
round
table
happen
when
each
of
these
vpcs
get
attached
to
a
tgw,
and
that
is
how
the
Amazon
console
actually
presents
it
as
an
attachment.
It's
an
object
that
you
create
that
Associates
a
VPC
with
the
tgw.
So
each
of
these.
A
B
The
responsibility
for,
and
a
lot
of
this
I
think
is
because
Transit
gateways
can
Bridge
accounts
the
responsibility
for
making
sure
traffic
that
originates
inside
the
VPC
has
a
route
to
describe
how
to
get
to
the
tgw
rest
with
the
whoever
administers
that
VPC.
So
we're
talking
about
an
additional
route
right.
B
A
B
But
it's
the
ttw
I
described
it
as
a
router.
It's
the
router's
job
to
make
to
manage
all
of
that
really
for
each
individual
VPC,
it's
more
about
saying
anything
that
lives
inside.
Maybe
this
big
range
you
know,
which
is
an
IP
address
management
sort
of
question
inside
an
organization
that
it's
reachable
behind
this
interface
and
the
interface
is
the
VPC
attachment.
A
B
Those
exist,
okay,
so
I,
you
know
if
you
were
asking
me
to
list
some
things
off.
The
top
of
my
head,
really
important
ones
are
often,
if
there's
a
centralized,
icicd
platform,
even
if
the
the
automation
runs,
perhaps
inside
vpcs
runners
or
that
sort
of
thing
oftentimes,
the
platform
itself
might
be
shared
on
across
various
Dev
teams.
What
are
we
talking.
A
B
B
A
You're
more
commonly
referring
to
something
like
a
third
policy
solution,
a
a
Splunk
type
environment
or
there's
any
number
of
them
out
there
right
right.
Where
would
that
typically
exist?
I'm,
assuming
it's
a
shared
services
VPC
within
the
environment,
which
is
also
connected
to
the
transit
Gateway?
It's
called.
A
B
B
A
I
typically
separate
them
because
I
see
my
art.
My
my
container
repo
is
something
where,
if
you're
in
a
non-prod
context
could
be
something
that
hasn't
been
scrutinized.
Yes,
and
if
we're
talking
about
an
artifact
repo,
you
know
the
same
ultimate
object,
but
it's
it's
gone
through
and
allowed
listing
and
blessed
process.
B
A
B
A
B
That's
also
registered
well
yeah,
which
or
maybe
where
a
rackama
is
running.
Well,
that's
what
I
love
about
Transit
gateways.
Certainly
you
can
attach
vpcs
to
them.
There's
a
lot
of
other
things
you
can
attach
to
a
Transit
Gateway
too,
and
notably
for
the
thing
you're
talking
about
you
can
land
a
VPN
Gateway,
an
AWS
VPN
Gateway
virtualized
directly
to
a
tgw,
and
you
can
also
attach
a
direct
connect
Gateway
directly
to
a
TDW.
B
A
But
you
know
as
a
capsule.
So
if,
if
we
and
keep
me
honest
here,
we
typically
see
something
like
a
on-prem
environment,
where
we
would
have
probably
most
commonly
seeing
ocp
self-managed
yeah
CP
sitting
over
there
and
and
you
mentioned
that
we're
going
to
go
Direct
Connect
and
that
would
come
directly
into
the
tgw.
Or
do
you
more
commonly
see
something
like
an
Ingress
egress
infrastructure,
I've.
B
But
yes,
so,
but
notably
these
are
attachments,
it's
in
a
different
attachment
type.
But
you
get
the
same
result
as
when
you
do
a
VPC
attachment
which
is
around
goes
on
the
route
table.
I
would
say
when
you
attach
a
VPC,
because
it's
behind
the
AWS
API
it
automatically
knows
about
the
IEP
space.
Behind
that
when
you
attach
a
VPN
or
direct,
connects.
There's
a
couple.
Extra
steps
there
to
Define
IP
ranges
that
are
reachable
behind
that
attachment.
A
I
just
want
to
come
back
here
very
quickly.
A
lot
of
customers,
I
work
with
are
creating
a
Ingress
or
egress
sort
of
VPC,
and
they
would
typically
be
some
sort
of
security
layer
that
they
control
centrally
there
so
either
making
sure
that
everything
coming
in
is
filtered
and
screened
or,
in
some
cases,
a
firewall
solution
that
very
meticulously
controls
what's
going
out
or
what
we're
exposing.
So,
if
I
look
at
Rosa,
even
if
it
was
a
production,
private
cluster,
something
like
a
private
link,
the
customer
could
re-expose
that,
through
whatever
security
device
right.
B
The
solution
there,
as
you
said,
is
this
Ingress
egress
VPC,
where
this
becomes
or
the
transit
Gateway
becomes
the
default
route
in
those
cases
for
those
isolated,
vpcs
and
then
the
transit
Gateway
knows
to
Route
traffic
for
the
public
internet
out
via
the
Ingress
egress
VPC
and,
like
you
said
there
might
be
products
right,
there
might
be
firewalls
running
there.
It's
a
variety
of
things
usually
done
for
security
purposes,
usually
quite
a
lot
of
complicated
configuration.
A
Now,
all
of
these
contexts
that
we've
spoken
about
non-prod
prod
different
accounts,
different
vpcs
on
premises
that
could
all
be
in
a
a
single
AWS
region.
What,
if
I,
had
a
customer
who
was
either
trying
to
get
closer
to
their
customer
and
they've,
got
workloads
running
in
different
regions
or
somebody
who's,
exploring
something
like
a
multi-region,
Dr
sort
of
context,
long
and
short?
What
if
there
was
another
region
that
we
needed
right.
B
It's
not
necessarily
super
explicit,
especially
if
you
look
in
the
GUI,
but
that
is
the
case
that
said
Transit
Gateway
support
where
it's
called
Gateway
pairing
and
we
could
create
another
tgw
in
another
region
and
create
a
period
relationship
between
them
that
allows
for
routing
of
traffic
between
anything
that
is
attached
to
either
of
these
tdws.
So
things
in
region,
one
could
reach
things
in
region
two
this
way,
vice
versa.
You.
A
Correct
I
think
it
is
very
application
specific.
You
know
what
are
the
application
tolerances
in
terms
of
latency?
Those
sort
of
things
right
before
also
do
I
want
to
have
these
as
hard
and
fast
separations.
Do
they
need
to
be
completely
independent
of
each
other?
The
other
element
is
Advanced
cluster
manager
that
we
have
over
here.
B
I
would
think
that,
because
it
is
more
of
a
monitoring
and
backplane
Tool
I
would
say
that
it's
probably
fine
to
run
a
single
one
in
the
network.
Obviously
you
want
some
resiliency
plan
for
Rackham,
even
if
you're
running
one
instance,
but
there's
no
reason
why.
If
you
had
a
big
enough
Fleet,
you
couldn't
actually
have.
If
you
had
business
units
that
were
largely
operated
independently,
perhaps
in
a
different
country,
it
might
make
more
sense
to
have
a
second
rack
them
depending
on
that's.
A
More
about
business
need
I,
think
yeah,
I
think
it
boils
down
to
how
invested
or
dependent
your
business
has
become
on
Rackham
as
a
tool
set.
It's
it's
a
workload
that
runs
on
top
of
openshift.
If
it's
not
there,
it's
not
overly
complicated
to
deploy
a
new
recom
instance
and
registering
through
it.
You
could
bring
that
up
relatively
quickly
and
you
you
may
or
may
not
be
using
the
provisioning
capabilities
of
it.
So,
depending
if
you're,
rolling
out
hundreds
of
clusters
or
what
your
recovery
phase
is,
it
might
not
be
that
important.
B
B
It's
an
option
to
just
have
every
attachment
use
the
default
route
table,
so
everything
can
see
everything
or
at
least
knows
where
it
lives,
and
it's
important
to
note
that
this
doesn't
bypass
the
security
groups
or
network
apples
that
exist
in
each
VPC.
You
still
have
the
ability
to
do
very
fine
grain
control
over
which
traffic
is
allowed,
where
it's
just
it's
it's
really
about.
What's
routable
tgw's
also
allow
you
to
create
and
Associate
multiple
route
tables
and
those
route
tables
are
are
associated
at
the
attachment
level.
B
A
A
B
B
A
More
likely
utilizing
something
like
AWS
organizations
and
organizations
allows
them
to
vent
these
accounts
as
they
are
being
created.
Without
non-prot
accounts
or
production
accounts.
They
can
Define
how
those
accounts
linked
to
the
billing
cycle,
their
billing
interfaces.
They
can
specify
things
such
as
who
the
owners
are
for
that.
So
A
Lot
come
from
the
organizational
management
things.
Then
there
is
AWS.
A
Service,
catalog
and
and
serverless
catalog
really
could
just
be
a
catalog
of
infrastructures.
Code
templates
that
defines
you
know
what
each
of
these
vpcs
look
like.
What
is
this
Transit
Gateway
implement
or
the
attachments
to
the
transit
Gateway
and
a
lot
of
these
are
simply
reusable
building
blocks
that
as
I
extend
this
Empire
I
am
not
needing
to
resort
to
manual.
A
From
an
open
shift
perspective,
there's
a
couple
of
things.
You
know:
infrastructures
codes
on
as
well
I'd
see
a
lot
of
customers
are
scripting
out
the
Rosa
CLI
I've,
seen
some
customers
wrap
the
Rosa
CLI
in
terraform
and
there's
a
lot
of
interesting
things
that
are
coming
down
the
pipeline
in
terms
of
capability
of
both
Rosa,
as
well
as
as
reckham
and
ocm.
So
when
you
combine
all
of
these
things
together,
there's
a
lot
of
potential
for
customers
to
get
to
a
zero
touch
environment
right.
B
And
that's
certainly
from
a
product
perspective
where
we
want
to
get
people
where
they
could
put
some.
They
could
pull
something
out
of
service
catalog
and
not
just
get
a
VPC
and
the
attachment
and
supporting
services
they
need,
but
a
potentially
a
rose
cluster
itself
as
part
of
as
part
of
instantiating.
An
entry
in
the
service
catalog.
A
Talk
to
me
about
and
might
be
stepping
outside
of
my
bounds
here,
but
in
terms
of
red
hat
Advanced
cluster
manager.
It's
able
to
manage
the
workloads
on
openshift
clusters,
move
them
around.
Do
configurations
on
the
Clusters.
Does
that
replace
something
like
red
hat
ansible
or
do
they
complement
each
other.
B
They
can
complement
each
other.
I
would
say
that
for
organizations
that
aren't
ansible
users
today
ansible
is
is
a
configuration
management
tool.
It's
very
capable,
if
you
have
significant
ansible
experience,
there's
very
good
tooling,
to
hook
ansible
into
openshift
and
Rosa,
and
you
would
be-
and
you
could
easily
use
that
if
you
already
had
the
experience.
But
if
you,
if
you
aren't
already
an
ansible
user,
I
would
say
red
hat
Advanced.
Customer
manager
would
be
the
place
to
start
with,
with
that,
with
that
level
of
sort
of
Remote,
Management
and.